Re: [hatari-devel] Possible 1.7 regression

Hi,

No news (I'm on vacation) - just acknowledgement that I intend to follow it up:

You're correct in that I'd rather not hand out the image :P I made a separate program just now only testing my basic hypothesis* below and that _didn't_ trigger it - but in my real program a lot of code that changes timer values etc has been run beforehand and is probably not exiting cleanly.

I'm away from my real STE for 5-6 weeks atm, but swapping between the v1.7.0 build and v1.6.2 still shows the problem whenever I test it.

I expect to find time during the next few day to make a proper stripped down version.

/Troed

*) I made a separate program doing an F_READ of an image directly to the screen buffer expecting it to show garbled data on v1.7 but it worked just fine.

On Sat, Jun 15, 2013 at 7:48 PM, Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:

If so I guess a good description of the problem would be that when my
program uses gem bdos file access after having been executed from AUTO
the F_READ will have the first 10*256 bytes replaced with the first
track (although, with the 512 -> 1024 offset difference so there's
something else to it). The rest of the loaded content is fine.

Without having looked at the Hatari source it almost sounds like
leftover debug code.

this looks really strange to me, I don't remember any debug code that would do this, nor any special behaviour in Hatari depending on the use of the AUTO folder or not on a floppy.

Assuming you don't want to spread your program for now, can you make a stripped down version that only does the file access and see if it still fails from the auto/ folder ?

It would be much easier to track if we could run the program ourselves.