Hello, Guest the thread was called602 times and contains 16 replays

last post from adtbm at the

Disc change bug in C65 ROM

  • I started a new thread for common questions and answers about the Xemu (xc65) emulator (as wished here).


    Today I found an error in Xemu (in this new version):



    If I attach a new D81 file with the right-mouse menu "ATTACH D81", the new attached disc shows the free bytes from the disc which was first attached.


    Maybe I can show it with some screenshots:


    This disc is very full and have only 82 blocks free:



    I now attached the second disc with only one program on it and I'm also get only 82 blocks free shown:




    Ok, I restarted Xemu and first attach the disc with one program. I'm shown 866 free blocks:



    Now I attached the almost full disc and also get 866 blocks free shown:


  • Interesting, since it's a C65 ROM issue, as Xemu cannot tell anything about free blocks or so (it does not know anything about the disk content or what it means just the raw data of the blocks whatever it's sane or not), that's already done by the DOS code in the C65 ROM. What I have the suspect though, that CBM DOS somewhere stores some information in the RAM and may not refresh it. It can be a C65 ROM bug (as C65 was never released, it can happen easily). The other possibility that it checks some kind of 'disk changed' signal or so (thus invalidating CBM DOS caching of free blocks - maybe others too - if a disk change detected), if there is any at all in case of F011 disk controller. It's an interesting question since it can happen that it stores not just free block info but like BAM/etc, thus can even cause corrupting disk image if you write them after "changing" D81 image. I'm really unsure now, but this can even affect MEGA65 itself too, if it's really some disk change signal should be handled and it's not done there yet either. But it's also possible - as I've said - that it's a C65 DOS ROM bug. Or at the other hand, disk change signal must be emulated, if there is any at C65 hardware level :)


    Just to clarify: since F011 emulation core is shared between Xemu/MEGA65 and Xemu/C65, it can be problem at both cases, that's why I mentioned MEGA65 / C65 kinda mixed in this post. Btw, can you see this behaviour in case of MEGA65 too? You should, but if not, it's really interesting then ...


    Sorry about the blah-blah here, but it needs some research to see how it really worked in case of a (real) C65. Or at least how MEGA65 handles this, if it does at all. Stay tuned. And thanks.

  • Hmm yes, so as I more or less expected, it's maybe the missing piece of disk change signal which would instruct the CBM DOS ROM code to forget cached information. So I need to figure out what kind of disk change signal is missing or such from the emulation.


    Btw: resetting MEGA65 and having the "disk still in the drive" is not a problem though, but exactly the desired behaviour, as HYPPO mounts the MEGA65.D81 automatically and that is overridden by Xemu to external source (HYPPO itself does not know about Xemu, it mounts the default D81 from the SD-card on a real MEGA65 as well ... Xemu just "hijacks" those SD card block I/O if external D81 mount was requested, but HYPPO still thinks it sees the default D81 image on the SD-card).


    https://github.com/lgblgblgb/xemu/issues/118

  • Add:


    The error occures also in the C64 mode (after GO64). After attached a new disc, LOAD"$" and LIST only show the free blocks from the disc before. Sadly the BASIC 2.2 doesn't have the COLLECT command for the workaround.

    BASIC 2.x COLLECT goes this way: ->

    Code
    1. OPEN 15,<Device>,15,"V<Drive>":CLOSE 15

    Where Device = deviceNr, anddrive = 0 or 1, where single-drive floppies always needs 0 here ;-)


    Add.: COLLECT is in fact -> Validate, and as anybody knows DONT'T VALIDATE GEOS DISKS!

  • It's an interesting question since it can happen that it stores not just free block info but like BAM/etc, thus can even cause corrupting disk image if you write them after "changing" D81 image.

    I played a little with this error.


    First, I attached a D81 disc with over 3000 blocks free. Then I attached a D81 disc which has only 1 block free.


    DIR shows me the (wrong) free blocks (> 3000) from the first disc.


    Then I load a BASIC 10 program from the attached disc, which is about 50 blocks and saved it with DSAVE and another filename to the attached disc.


    Although were is only 1 block free, the BASIC program with 50 blocks seems to be written correctly on the disc. DIR shows the name and the shown free blocks are reduced about the 50 blocks of the program.


    All seems done correct. There was no error message or another message about the not enough free blocks.


    But the problem is: The program isn't saved. It can't be loaded. It has no content.


    I tried it with xc65 and xmega65 and with the Nexys board.


    The error about not recognizing a disc change could be a problem of unnoticed data loss.

  • Yes, I thought so, if DOS caches anything which uses then and 'forget to forget' :) on disk change, it's almost certainly will affect something other too, not just the "free blocks" kind of "cosmetic" issue, indeed. However currently there is no clear clue what could cause this, especially since it can be seen in Xemu and in mega65-core well, even when we know the implementation is independent in this regard (ie I haven't seen before how mega65-core implements this at VHDL level). So I agree, it can be a serious issue, that's why I marked it so, even before. Meanwhile I've also posted the issue already to mega65-core itself as well. Hmm maybe tomorrow (it's kinda bed time here since a while ...) I'll try with several older C65 ROMs, I'm curios now. In fact, as main source of implementation was "c65manual.txt" it's not impossible that disk change works differently in real C65 models which use this ROM we tend to use, and c65manual.txt was written for an older method, only older ROMs uses. There is even example for that, eg "SWAP bit" (not connected to this topic, just an example to have different hardware revisions in terms of the F011 controller) was introduced at some point which hadn't been existed in older F011s ...

  • Have you tried to send an I command (Initialize)? That should refresh the FAT from disk.

    I suppose you mean the BAM. Indeed, however this shouldn't be the solution, the problem that it should be done automatically. In case of an 1541 too, you don't need to initialize the disk after a disk change and fear of data corruption and other anomalies :-/

  • Yes (sorry for the typo). I only meant the Initialize command, because it is always fast and straightforward enough, and mostly harmless, too (unlike the above-mentioned Validate, which starts to look for allocated sectors and free them up etc.), thus it can be issued at any time, e.g. before every LOAD or SAVE attempt in an actual program. It doesn't fix the errors of the DOS code, of course, but might be a kind of workaround.

  • Yes (sorry for the typo). I only meant the Initialize command, because it is always fast and straightforward enough, and mostly harmless, too (unlike the above-mentioned Validate, which starts to look for allocated sectors and free them up etc.), thus it can be issued at any time, e.g. before every LOAD or SAVE attempt in an actual program. It doesn't fix the errors of the DOS code, of course, but might be a kind of workaround.

    The I command is named DCLEAR in BASIC 10 and works for a workaround.

    Be aware that the "changed disc" error also exists in the C64 mode with BASIC 2.2.


    And it's just a workaround for selfwritten programs. Any existing program (for the C64) who writes on disc doesn't know about such an "changed disc" error and write to disc if there are enough "free blocks" shown.

  • I made a new patch "AG" for the C65 ROM (911001.bin) in which I made a bug fix for this "disc change error" (besides all changes of my other patches are included).


    It works in Xemu (xc65 and xmega65) and with the Nexys board. I made several disc changes and the free blocks are always shown correct. I saved and loaded some programs and formated a disc with HEADER without problems.


    Maybe someone could test it an a real Mega65?


    The get the patched ROM see steps 1.) to 4.) in this post: Patch for C65 ROM


    ...


    5.) Patch the file with this command:


    bspatch 911001.bin 911001_ag.bin patch_ag.bin


    6.) The created file '911001_ag.bin' is the patched rom and you can rename and use it for your needs. E.g. for Xemu 'c65-system.rom' or 'MEGA65.ROM' for Mega65 or the Nexys board.





    In the original ROM I found the routine in which the status address $D083 from the F011x was shifted right and sets the carry flag if it was a disc change. Depending on the carry flag, the address $0198 was set (bit7 for disc 0 and bit6 for disc 1).



    The problem is, that $D083 seems to not holding the actual disc change bit (maybe a hardware error in the F011x?). But $D080 seems to have it, although where were other infos in the "C64DX SYSTEM SPECIFICATION" (section "2.5.3. Registers"). Maybe there were some changes during the development of the ROM?


    I changed the address to $D080 and the disc changes are now recognized.



    Here is the text with the changes made in patch "AG" against the original ROM (911001.bin)


    Maybe a mod can change the thread title to something more suitable to the content? E.g. "Disc change bug in C65 ROM"?

  • adtbm

    Changed the title of the thread from “Xemu - Q&A + wishlist” to “Disc change bug in C65 ROM”.
  • Hi Snoopy,


    thanks for your patch, i've already patched the 911001 and i'll give it a try, when i am at home tonight after work !