MEGA65+C65: missing F011 disk change signal, anomalies on disk change

[lgblgblgb]

Xemu uses a shared F011 emulation core between both of MEGA65 and C65 emulation for emulating the internal disk drive. It seems it has a problem: on disk change, the previous disk's free capacity can be seen as 'free blocks'. Probably this means, that CBM DOS caches some information and only re-validate that, if disk was changed. Indeed, F011 has a disk change signal which was not implemented in Xemu.

Note: it can be a dangerous bug. Who knows what CBM DOS caches if it does not see the disk change signal, which can even lead to corrupt disk images caused by a write after a disk change, still thinking having the cached previous BAM or whatever in the memory ...

Workaround: COLLECT BASIC command should be issued after disk change.

Original bug reporter (thanks): Snoopy, on Forum64.

[lgblgblgb]

I've tried to implement disk change signal according to c65manual.txt. Status register "B", bit 7 is DSKCHG. It's set in case of a disk change, and the bit is cleared if drive is deselected. I've implemented this behaviour, even the debug messages says it happens this way now, everything is correct. Still, the problem remained.

Now I wonder if it's bug of CBM DOS itself :-O

[lgblgblgb]

I've checked this on a real MEGA65, the bug is there too!! So I guess it can be:

• CBM DOS ROM bug, F011 emulation in Xemu, F011 implementation in MEGA65 is correct
• Some unknown F011 revision is needed with some extra feature for the used ROM on MEGA65 and Xemu, the source of the problem that CBM ROM expects something different we (=MEGA65 and Xemu) do in the name of F011

Should we "escalate" this bug to the level of the mega65 project itself? Has anybody anything to add and/or correct my theory?

(real) MEGA65 testing method was:

• power-on, with default MEGA65.D81, DIR command, 1 blocks free (quite crowded a disk ...)
• restore -> mount another disk image -> resume
• DIR command, the correct directory shown (of the new D81) but with 1 blocks free, still!
• Issuing the COLLECT command, then DIR -> now the correct blocks free info can be seen

Remark: COLLECT actually does "V"alidate the disk, which can be dangerous (if it's a GEOS disk for example) so it's merely an example only.

[lgblgblgb]

Posted in mega65-core as well: https://github.com/MEGA65/mega65-core/issues/234

[lgblgblgb]

The commit above does not solve the issue unfortunately, but indeed missing disk change signal was a thing, at least.

[lgblgblgb]

Breaking news

Xemu's F011 emulation used bit 7 of "B" status register as "DISK CHANGED" signal, but it's bad, it should be bit 0! Snoopy has noticed it.

[lgblgblgb]

Note: #219 to implement second disk could be ended in an unstable stage because of this bug with the wrong bit used!

[lgblgblgb]

Wondering if I can close this issue now, or still anomalies left ...

[lgblgblgb]

Maybe this was causes by the wrong bit emulated? Closing now.