Re: [hatari-devel] emutos-ram and GEMDOS drive emulation

[Thomas Huth <th.huth@xxxxxx>]

Am Thu, 31 Mar 2016 21:29:39 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> On 03/31/2016 04:09 AM, Thomas Huth wrote:
> > Am Thu, 31 Mar 2016 01:11:30 +0200
> > schrieb Vincent Rivière <vincent.riviere@xxxxxxxxxxx>:
> >  
> >> On 07/03/2016 00:34, Vincent Rivière wrote:  
> >>> 1) Hatari must allow to initialize the GEMDOS emulation a second
> >>> time  
> >>
> >> For the same reason, Hatari GEMDOS drive emulation does not work
> >> after a software reset (Ctrl+Alt+Del).  
> >
> > That's also true for the original TOS (at least for those versions
> > that support that keyboard combination, like TOS 2.06).
> > I've committed a fix now (slightly based on your original patch).
> > Thanks for your detailed report!  
> 
> While EmuTOS works with this version, and TOS >= v2,
> all the older TOS versions get now double bus error
> right at start if GEMDOS HD or tracing is enabled:
> -----------
> Bus error wput at 0041fffe
> Bus Error at address $41fffe, PC=$fc0170 addr_e3=fc0174 op_e3=3302
> Illegal instruction: 000a at 08FA02E2 -> 04FC0B0A
> -----------
> 
> I.e. for some reason PC value returned by WinUAE M68000_GetPC()
> has garbage data on the highest byte, and therefore your check
> for cartridge area address doesn't match.

Ouch, looks like older TOS versions are not clearing the uppermost byte
of the entry function before jumping to it - the uppermost byte is used
for some configuration bits, see cart_asm.s:

  dc.l	sys_init+$08000000

I've now added a test for 24-bit addressing mode, so that the uppermost
byte now gets ignored on old TOS versions, thus it should be working
fine again.

BTW, why did you change the indentation in the old UAE core's
OpCode_SysInit() function? ... that now looks completely strange to me.

 Thomas