|Re: [hatari-devel] Possible 1.7 regression|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On sunnuntai 16 kesäkuu 2013, Eero Tamminen wrote:
> 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:.
It doesn't respect bootdrive setting, but it can be forced to boot
from floppy with Hatari GEMDOS emulation. To do that:
- add "--fast-boot off" to Hatari options to get EmuTOS startup screen
- press ALT in EmuTOS startup screen to skip C:
Then you should have Hatari GEMDOS tracing with EmuTOS booting your
program from floppy AUTO directory.
> (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?