Device-based removable media replacement problem

[Eugeny1]

I am developing device-based driver for floppies. Performing DIR in DOS2 after diskette replacement lists directory properly, but if I go to Nextor disk-BASIC and perform FILES in there, I see part of previous disk's directory just after floppy disk is replaced. Second time I perform FILES it may give better results (more files listed from new media), and if performing FILES 3rd time directory listing from new media seems to be correct. Driver reports disk change properly (it performs diagnostic output to the screen). I am afraid that on first FILES run after disk replacement I do not see required sectors being read to display new media properly. I report 0 sectors for floppies in LUN_INFO (expecting kernel to read boot sector when needed to find out media geometry). When reading changed disk, kernel reads boot sector at least 3 times (why does it do this as it must be enough to read it once...) Same problem happens with 720k and 1.44 disks. Tried kernel in openMSX with drive-based disk-basic 1.0 and FILES seems to work properly after virtual diskette change.

[Eugeny1]

Update: after I change 720k floppy with 1.44M floppy, then following actions are performed by FILES:

• boot sector is read 7 times
• sector 0x07 (directory location for 720k floppy) is read.

FILES displayed garbage, because new diskette is 1.44M and has directory at sector 0x13.

Next time FILES is invoked, without changing the disk, it performs the following action:

• only one sector is read, 0x13, which is a correct location for 1.44M diskette.

FILES displays proper directory listing.

Seems that kernel updates DPB after reading the sector of location of the directory for previous diskette format. This problem will never be noticed in 720k-diskette-only environment, as its directory sector is always located at sector 7 (in standard format). As I said before DIR in DOS2 always lists directory properly, thus issue is in algorithm of FILES execution.

[Eugeny1]

Further investigation shows that kernel seems being losing disk change flag after if performs first call to DEV_STAT. The interesting thing is that it does not happen all the times. Sometimes DEV_STAT returning A=2 is followed by the boot sector and other sectors' read, and causing correct FILES output, but most of the times kernel does not call DEV_RW, calling DEV_STAT several times, and of course on second and all further calls DEV_STAT returns 1 (not changed).

[Eugeny1]

Here's the test kernel for you. It uses two disk images: first is Nextor DOS2 one of 720k size (so that kernel boots into DOS2 mode), and second is DOS1 360k size. Disk switching is performed by putting zero (first image) or non-zero (second image) value into FFFD using POKE&HFFFD,x. Put breakpoints to the kernel JP addresses, and perform switching images using POKE and doing FILES afterwards seeing what routines are being invoked. I see that most of the times DEV_STAT loses A=2 at its first call after issuing FILES (it must actually lose 0ffh in B as you translate A=2 -> B=FF and then flags NZ/NC), and of course displays wrong contents afterwards. I have changed bootable file names in the images, thus do not think these are corrupt outputs, these are correct names so that kernel does not try to boot without proper file content (images do only contains boot, FAT and directory, no file contents).

The problem is here at address 348F at kernel page 0: you operate bit 5 at (ix+05), current value is 035h. If it is in this value, kernel skips all further reading. However if I manually reset the value to 015h (resetting bit 5) then kernel performs correctly, reading structures of the diskette and displaying proper directory listing.

What is this flag for, and why it is set wrongly?

[Konamiman]

Fixed in v2.1.0