MSX BDOS - Detecting disk changed?

By Sandy Brand

Master (186)

Sandy Brand's picture

22-04-2019, 19:20

(continued from my earlier question MSX-DOS 1 BDOS error codes?)

I am having a problem reading files using BDOS after changing the disk. The BDOS function _RDBLK (27h) will just report an error value after having partially read some of the file, but the error handler installed via ERRADR (F323h) is not even called.

I have tried a couple of things, including first search for files before opening _SFIRST (11h) and even 'resetting' the disk _DSKRST (0Dh), but nothing seems to work.

I am nearly 100% certain that the problem is not in my code (as in, it is not mutilating any memory outside of the TPA or anything) because I still have the problem in very simple use cases.

I am beginning to suspect that it has something to do with the disk system not 'knowing' that the disk has been changed. Thus, probably BDOS is still accessing the disk using the old FAT tables (or DPBs, whatever these are?) that is still cached in memory.

I have been trying to figure out where the FAT is stored in memory. Through DPBLIST (F355h) I think the FAT should be located at E597h in memory and higher. When I look at that memory, there is some readable stuff in there (such as the file names). Whenever I open a file using BDOS _FOPEN (0Fh) I see some of that memory change, but it is not clear what it means to me, because some data changes there, even if I hadn't switch the disk yet.

So while digging on the internet and this website, I found a mention of this DISK ROM function: 4013h (DSKCHG)

Effect:	Check if disk has been changed.

Input:  A = Drive number (0=A:)
        B = Media descriptor
        C = Media descriptor
        HL = Base address of DPB

Output: F = Carry set on error, carry reset on success
        A = If error: errorcode (see DSKIO)
        B = if success: 1=Disk not changed, 0=Unknown, -1=Disk changed

Note:   If the disk has been changed or may have been changed (unknown) read
        the boot sector or the FAT sector for a disk media descriptor and
        transfer a new DPB as with GETDPB

It seems to suggest that it will make sure that the correct FAT and such is loaded in memory again, which may solve my problem, but I have no idea how to safely call this function (either directly or indirectly)?

Any help would be much appreciated :)

Login or register to post comments


Enlighted (5560)

NYYRIKKI's picture

23-04-2019, 00:33

You really should not need to know about this stuff.

... but have you been messing around with interrupt hooks?
In case you overwrite the interrupt hooks, you may lose track of disk changes.

By Eugeny_Brychkov

Paragon (1153)

Eugeny_Brychkov's picture

23-04-2019, 11:32

In general driver of the related hardware (e.g. floppy disk subsystem) must call this routine before any new hardware access and I/O error, and perform "reset" of the control structures if disk is indicated as changed, or state is unknown. Thus you either have badly designed custom driver, or hardware issue thus system not sensing disk change properly (e.g. bad cable, replaced with reworked floppy drive).

By zeilemaker54

Champion (278)

zeilemaker54's picture

23-04-2019, 19:17

I you are looking to DSKCHG, you are looking at the wrong place. This routine is a low level routine, your problem is wirh a high level BDOS call.
May be you could post your code (the part with the bdos calls) somewhere to have it analysed.
Note the remark about the interrupt handler as many diskdrivers (not all) depend on it.
Also note the size of the fcb structure with rdblk and wrblk wirh small recordsizes, as the structure is 1 bytes larger (37 bytes) because of the recordnumber at offset 33 (4 bytes)

By Sandy Brand

Master (186)

Sandy Brand's picture

23-04-2019, 23:26

Omg you guys are amazing!

Interrupts were enabled on the Z80, but bit IE0 got accidentally reset in VDP R1 due to a stupid bug in my function to switch screen modes. So no actual V-Blank interrupts were generated, doh! oO

Man, this one had me puzzled for quite a while, because the strange thing was that it wasn't the first file that failed to load after switching disks, it was the 2nd or 3rd one that then suddenly started failing.

Anyways, BIG thanks for everyone helping with this (especially you, NYYRIKKI!) Big smile