CBM DOS does not sense disk change and cache things over disk change too?

[lgblgblgb]

During Xemu development Snoopy from Forum64 reported a bug in Xemu/MEGA65: https://github.com/lgblgblgb/xemu/issues/118

Summary: after disk change the "free blocks" (of DIR command) shows info on the previous disk (the the correct directory is shown for the new disk). This indicates CBM DOS caches some information and this situation can be dangerous (ie, what if the BAM is cached too, and a writes happens after disk change?). Initially I found that a bug of Xemu itself, since disk change signal was not emulated. However now it seems:

• the situation remains even after proper implementation of the disk change bit
• more over: it seems MEGA65 itself is affected as well, this is the reason I reported here too

Interesting, that I implemented disk change bit at my own, not looking the VHDL code of mega65-core (but only the c65manual.txt) so we can say, we have two different implementations (xemu and mega65-core), still, both of them seems to be affected of this problem.

(real, rev2 PCB) 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.

Can anyone other confirm this problem? Also, I'm not sure "what to blame" here for this problem. It can be simply a ROM bug from Commodore. Or a slightly different method it want to use, not the same as documented on F011 (what we used to implement it ...). Or it can be a testing mistake of mine :) Or whatever ...

[gardners]

Its quite possible that the diskchange line handling in the FDC is broken in some way. This needs to get fixed.

[lgblgblgb]

What consider a bit strange here, that the chance of having bad disk change signal implementation in mega65-core is lower, since I met the same problem with xemu, where I implemented that disk change signal now with debug messages, and indeed, the bit sets and resets when it needs to be, but still, the problem remained! Maybe a ROM disasm/etc would be needed to see what CBM DOS actually does to try to detect disk change (if it tries at all, who knows ...). Though, just wondering that maybe the bit should have inverted meaning what I assumed, hmmm .. ?

[gardners]

Well, I'll investigate it when I get the chance. I did notice when I implemented the auto track seek that I wasn't convinced I was seeing the disk change line doing what it should. So we will see. But it might be a while before I attack it.

[adtbm]

I have to add, since Snoopy is still experimenting with it here: [https://www.forum64.de/index.php?thread/103179-disc-change-bug-in-c65-rom/] When swapping images the number of free blocks remains the same -known-

BUT... This bug only happens on the real MEGA65 when swapping images NOT when swapping real floppy discs.

Snoopy patched the 911001 ROM, this results, that the image swapping bug is gone, but now there are problems accessing the real floppy drive.

So i am not sure, if Snoopys patch is OK and there is something wrong with the real drive implementation or if it is something else

[gardners]

Can you please confirm if this occurs with the latest 138-hdmi-audio-27mhz branch builds, as those have some fixes for making the drive step to the right place, and if I remember correctly, some tweaking of the disk change stuff.

[adtbm]

Yes i can confirm i've used the 138-5503-HD bitstream.