Re: [hatari-devel] Possible 1.7 regression

Hi,

Well, now I at least have some news ;)

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

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:

Thanks - that indeed allowed me to test my program with EmuTOS. The result is that it works* - with the pre v1.7 of Hatari that doesn't work with TOS! When I say "with TOS" I mean I've tried with ST/1.4, STE/1.62 and STE/2.06 - all combinations that work fine with Hatari 1.6.2 and real hardware.

So this does indeed look like a regression with Hatari 1.7 and TOS (any version) specifically. As to what triggers it I still don't have any more details.

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

Start my program, break, set breakpoints before I call the gemdos methods to verify the input parameter, continue, set new breakpoints after to verify D0, continue. They're all correct.

There's also no way I know of to have F_READ read 80KB of file data correctly but replace the first 10*256 bytes with the FAT/first track through faulty parameters :P

/Troed

*) Well, the way I reset an ST through software doesn't work on EmuTOS - but I haven't debugged why. I copy the following code to address $200 (OEM reserved range), push that address to the stack and have later code RTS to it. There are good reasons as to why ..

movea.l $46e,a0 * monitor changed vector

jmp(a0)