Re: [hatari-devel] Possible 1.7 regression

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

On Sun, Jun 16, 2013 at 9:48 PM, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:

Do those TOS versions work differently if you use "--fast-boot off"
option also with them, maybe also with "--rtc off --fastfdc off"?

No difference.

Among many possible explanations is change in when interrupts are
started. 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.

/Troed