|Re: [hatari-devel] Possible 1.7 regression|
[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]
This just got even more strange.
Recap: I have an image, an .ST file, that I put something I develop on and test with Hatari. I also every now and then convert that very same .ST file to HFE format and load on my HxC Floppy Emu and test on a real STE. The content on that .ST file (normal files, normal image) works fine on Hatari 1.6.2 (and earlier) as well as on my STE. I change the files on this image regularly while developing.
When I tried a Mac build of 1.7 my program suddenly crashed. I debugged it extensively, and even though all calls to gemdos are correct and return the correct values the actual _content_ I load into memory (files, different ones, using F_READ) have the first 10*256 bytes replaced with what looks like the first track of the _disk_ (at least the FAT is visibly there), although there seems to be some layout difference. The rest of the file loads correctly (60-80kb depending on which). This with TOS, tested with 1.4/1.62/2.06, and only when loaded from AUTO. It works with EmuTOS however, as well as with TOS when loaded from desktop.
The update: When creating a stripped down version for you to test with, I had problems recreating the error. Finally, frustrated, I took the _same_ files (verified with diff!) and put on a new image - and that new image works fine on the Hatari 1.7 build as well.
The files are _the same_ - and it cannot be a case of corrupt image since the original image works on other versions of Hatari as well as on target hardware (converted by the HxC software). I use Hatari to create the images, and they are of the same configuration (80/9).
I'm at a loss, sorry. It does however indicate, in my view, that this should be treated as a freak incident and not affect any release schedules on your part. I can (and have been for a few hours, testing all possible combinations) still replicate this issue at will with the original image and copies of it made on my host system of course - but that doesn't really help anyone.
At a future unspecified point in time I'll happily share the image (copies have been made if it should suddenly correct itself) - but I will stop spending time on this issue myself now since the few hours of Atari-time I can extract I want to spend with the content of the image instead ... :P
Do those TOS versions work differently if you use "--fast-boot off"
option also with them, maybe also with "--rtc off --fastfdc off"?
Among many possible explanations is change in when interrupts arestarted. Maybe your program corrupts TOS memory (e.g. stack) and
with Hatari, interrupts happen to occur at such a moment that result
is more visible?
I agree that could be possible. Since I tested changing the memory address I load to using F_READ the overwriting of data at that specific location must be connected to it, however, instead of being the result of a random memory clash.
|Mail converted by MHonArc 2.6.19+||http://listengine.tuxfamily.org/|