|Re: [hatari-devel] Possible 1.7 regression|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On sunnuntai 16 kesäkuu 2013, Troed Sångberg wrote:
> 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
Do those TOS versions work differently if you use "--fast-boot off"
option also with them, maybe also with "--rtc off --fastfdc off"?
> 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
> 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
Among many possible explanations is change in when interrupts are
started. Maybe your program corrupts TOS memory (e.g. stack) and
with Hatari, interrupts happen to occur at such a moment that result
is more visible?
(I'll mail more about this in another mail thread.)
> > 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
> *) 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
Roger reported this to emutos-devel. It's not going to be fixed
for 0.9.1, but will be looked at later.