Re: [hatari-devel] Possible 1.7 regression

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On torstai 13 kesäkuu 2013, Troed Sångberg wrote:
> On Wed, Jun 12, 2013 at 11:10 PM, Eero Tamminen <oak@xxxxxxxxxxxxxx> 
> > 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.

EmuTOS most definitely supports AUTO folder programs.

However, it seems that it doesn't respect the bootdrive so you need
to remove any GEMDOS drives from your configuration to use it,
otherwise it boots from C:, not A:.

(This will mean that Hatari GEMDOS tracing cannot be used, I'll
report this issue to EmuTOS developers.)


> 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).

Did you use Hatari's tracing facility for verifying the arguments
(with normal TOS), or something else?


	 - Eero