Re: [hatari-devel] Possible 1.7 regression

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

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
> TOS!

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

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

Roger reported this to emutos-devel.  It's not going to be fixed
for 0.9.1, but will be looked at later.


	- Eero