Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#279 +D in memory disk image corrupted after save?

v1.1
closed-fixed
nobody
None
5
2013-04-20
2013-02-10
Fredrick Meunier
No

Crisis on WoS says that the in memory disc image in +D gets corrupted after a save:

Working with the +D in this beta i have found 2 problem from which 1 already occured in the stablefuse with +D
point by point,
1) a-- after saving a discImage via the rollbar menu the disk suddenly cat NOT be read any more giving the error 0:1 sector error, meaning the very first sector on the very first track is not readable. If i now insert the just saved discimage (even without ejecting) all sofware is available.
1) b-- i had this some times in the stablefuse version aswell, but ONLY with disc 2.

Related

Bugs: #299

Discussion

  • Philip Kendall
    Philip Kendall
    2013-02-10

    Do we know if this is reproducible, and if so, do we have an exact set of steps that can be used to reproduce this?

     
  • This seems to be easily reproducible:
    1) Enable +D
    2) Hard reset
    3) Insert +D disk
    4) RUN
    5) Enter 10 PRINT "Hello World!"
    6) SAVE d1;"Test"
    7) Media->Disk->Drive 1->Save
    8) CAT 1
    9) 0:1,SECTOR error, 0:1
    10) Media->Disk->Drive 1->Insert... the saved image
    11) CAT 1
    12) Catalogue works

     
    Last edit: Fredrick Meunier 2013-02-11
    Attachments
  • I'm new to disk routines but as far as I've seen, the disk image is managed in memory and saved to disk on user request, so saving of disk image should be transparent to the floppy disk drive or floppy disk controller emulation.

    disk_write() modifies private data of disk_t for reading tracks and sectors. However these private data are accesed by the floppy disk drive too, so saving of disc image alters the emulation.

    The attached hack restores the position of the current data after saving the disc image.

     
    Attachments
  • This patch indeed solves this bug and as you say feels like a hack - we shouldn't have to do this kind of save and restore of the other controller.

    The obvious change would presumably to move the track, clocks, fm, weak and i members of disk_t to a new structure and require the DISK_SET_TRACK macro and similar code to have a separate parameter to the disk status to use/modify.

    We had a similar issue in the tape code in libspectrum which was addressed by the addition of the libspectrum_tape_block_state type member of the libspectrum_tape struct - I would propose that a similar approach is the ideal fix here but suggest that your attached hack would be a sufficient fix.

     
    Last edit: Fredrick Meunier 2013-02-24
  • Sounds like a good idea but seems too much rework before v1.1.

     
    • status: open --> pending-fixed
     
  • Committed by revision 4902 as this is the only solution for the time being.

     
    • status: pending-fixed --> closed-fixed