Re: [hatari-devel] Possible 1.7 regression

On Wed, Jun 12, 2013 at 11:10 PM, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:

Can you reproduce your issue with EmuTOS? As debug symbols and
sources are available for that, it's much nicer for debugging TOS
call related issues.

The breakpoint and tracing stuff would indeed make things easier - currently I'm stepping through the code with the rudimentary built in debugger. However, after having downloaded Emutos 0.9 (the latest off Sourceforge) I discovered that it doesn't seem to support the AUTO folder .. (!?). At least with Emutos my program doesn't even start*, with the same floppy image that's working fine with TOS.

As far as the actual gemdos calls I've already verified that they receive the correct input parameters and that their return values are correct (and the same as when launched from non-AUTO, when everything's ok). It's the resulting content of the buffer read into by F_READ that differs. There's no part of my program that does direct sector access so there should be no sane reason for the FAT to appear in that part of memory. (It's not there before the gemdos call either, of course).

I've also just now tried changing the memory address I read to but the result is exactly the same. This invalidates the very far sought theory I had that TOS on Hatari 1.7 for some reason used that specific memory address as a track buffer after the F_READ.

/Troed