Menu

#1105 Filesystem Image DXX: Error - Could not find data sector

v3.3
open
nobody
None
Drives
2019-10-07
2019-02-28
No
  • VICE 3.3 (also 3.2 checked with the same result)
  • compiled from source under macos 10.11.6
    When using DolphinDOS3 1541 ROM (as attached) with 1541 memory expansion $6000-$7fff, and running attached program, the error messages:
Filesystem Image DXX: Error - Could not find data sector of T:17 S:19.
Filesystem Image DXX: Error - Could not find data sector of T:17 S:20.

appear and DOS error is returned to the emulated computer. Running the same program on actual hardware, equipped with the same DOS ROM, returns no errors and completes correctly.

1 Attachments

Discussion

  • Silver Dream !

    Silver Dream ! - 2019-02-28

    Compiled and checked all full release versions back to 2.4 where this problem is NOT present. Seems all 3.x releases are affected.

     
  • gpz

    gpz - 2019-02-28

    it would be super helpful if you'd check what revision exactly broke this

     
  • Silver Dream !

    Silver Dream ! - 2019-02-28

    You mean like revision between 2.4 and 3.0? For this I'd need more time but can possibly do.

     
  • gpz

    gpz - 2019-02-28

    yes please

     
  • Silver Dream !

    Silver Dream ! - 2019-10-01

    After uneven confronation with SF's SVN and its constant errors "during SSL communication" I was able to narrow it down to the following:

    • the "original" 2.4 tarball, which I presume is revision #26490 (any easy way to check which exact revision the tarball was created from?) does not have the problem
    • revision #27818, which seems to be the earliest I can still compile on my current machine, already exhibits the problem
     
  • gpz

    gpz - 2019-10-01

    you can look it up in the tags directory: https://sourceforge.net/p/vice-emu/code/HEAD/tree/tags/v2.4/

    no chance to narrow it down further? also please give the exact settings required to reproduce this (starting from defaults) and perhaps a link to the ROMs you are using

     
  • Silver Dream !

    Silver Dream ! - 2019-10-01
    • My question was about whether there is an easy way to check what revision the downloaded "tarball" sources were generated from. I think they're the initial 2.4, which would mean r26490 but can't be sure today.
    • I can't compile revisions earlier than #27818. There were issues even with later ones (ffmpeg, giflib, ..) but I worked them around. With 27817 and earlier I didn't notice any fast workaround.
    • sources are configured only with --disable-ffmpeg (starting from a revision that doesn't work anymore with current lib) and under macos also with --disable-bundle. The rest remains at default
    • I supplied the drive ROM needed to reproduce the issue in the first post. All other ROMs are default ones (901225-01, 901226-01, 901227-03). I attach once more here. This time additionally with a D64 (as earlier revisions don't auto-create it).
    • The command line used to start the emulator:
    cp Filesystem_Image_DXX_Error/test.d64 Filesystem_Image_DXX_Error/dotest.d64 && src/x64sc -chargen 901225-01.bin -basic 901226-01.bin -kernal 901227-03.bin -dos1541II Filesystem_Image_DXX_Error/3dosa_c_27c256_payload.bin -parallel8 2 -drive8ram6000 -truedrive --autostart Filesystem_Image_DXX_Error/dotest.d64
    

    I copy the D64 image to a working one because disk gets formatted as part of the test.

     

    Last edit: Silver Dream ! 2019-10-01
  • gpz

    gpz - 2019-10-02

    The tarball is generated after creating the tag, so the revision should be same :)

    i will have a look if i can reproduce this

     
  • gpz

    gpz - 2019-10-02

    ok the offending commit was r27111. lets see....

    .... ugh. its that one giant commit with all the SPS VIA fixes. oh well. it'll take someone more familiar than me with this stuff to fix it.

     

    Last edit: gpz 2019-10-02
  • Silver Dream !

    Silver Dream ! - 2019-10-07

    I see. Thanks for trying. Do we have contact to the original contributor, maybe? In the meantime a friend of mine will try to give a stab at it too (although he also wasn't too optimistic after seeing the commit).

     

Log in to post a comment.

MongoDB Logo MongoDB