Re: [hatari-devel] TOS 3.06 does not boot from ACSI

[Thomas Huth <th.huth@xxxxxx>]

Am Wed, 5 Oct 2016 19:10:40 +0200
schrieb Thomas Huth <th.huth@xxxxxx>:

> Am Wed, 5 Oct 2016 19:01:25 +0200
> schrieb Thomas Huth <th.huth@xxxxxx>:
> 
> > Am Sat, 24 Sep 2016 21:50:25 +0200
> > schrieb Uwe Seimet <Uwe.Seimet@xxxxxxxxx>:
> >   
> > > Hi,
> > > 
> > > "Boot faster by patching TOS" is disabled. Enabling it does not
> > > make a difference.    
> > 
> > OK, ... I assume it's HD-Driver, but I've got to ask anyway: Which
> > kind of hard disk driver do you have installed on that disk image?
> > 
> > I've got a disk image here that seems to have AHDI v5.00 in its boot
> > sector and it also does not work in TT mode. TOS 3.06 successfully
> > loads its boot sector and jumps into the boot code, but apparently
> > that code is doing some strange TOS date check and refuses to work
> > if the TOS date does not match its requirements:
> > 
> >  000018C6 2078 04f2        MOVEA.L $000004f2,A0
> >  000018CA 2028 0018        MOVE.L (A0, $0018) == $00000958,D0
> >  000018CE 4840             SWAP.W D0
> >  000018D0 b0bc 1987 0422   CMP.L #$19870422,D0
> >  000018D6 6404             BCC.B #$00000004 == $000018dc (T)
> >  000018DC 4e75             RTS   
> 
> Never mind, that was a red hering ... it always returns there, even if
> the BCC is not taken. But I'm still not sure yet why it does not
> properly loads the HD driver there yet.

OK, got it now - I just pushed a fix to the repository.

That was a quite strange bug, not sure whether there is any proper
documentation for this available somewhere, so here's a short summary:

Apparently TOS 3.06 uses the value of the first VME bus GPIO register
and passes this value as some kind of partition selector to the hard
disk driver code in the boot sector of the ACSI disks:

 00E00B14 1038 8e09                MOVE.B $ffff8e09,D0
 00E00B18 c07c 00f8                AND.W #$00f8,D0
 00E00B1C 31c0 0a00                MOVE.W D0,$00000a00
 ... (omitted loading of the boot sector and checksum calculation) ...
 00E00B94 2078 04c6                MOVEA.L $000004c6,A0
 00E00B98 263c 444d 4172           MOVE.L #$444d4172,D3
 00E00B9E 3e04                     MOVE.W D4,D7
 00E00BA0 eb47                     ASL.W #$00000005,D7
 00E00BA2 3a38 0a00                MOVE.W $00000a00,D5
 00E00BA6 2f04                     MOVE.L D4,-(A7)
 00E00BA8 2f39 0000 0476           MOVE.L $00000476,-(A7)
 00E00BAE 4e90                     JSR (A0)

The AHDI boot sector code then uses the value in D5 for the selection
of the partition, as far as I can see.
Since Hatari was returning 0xff when reading the 0xff8e09 register, the
boot sector code of AHDI did not find any valid partition and thus
simply returned. I've now changed the implementation of 0xff8e09 in
Hatari to return 0x01 instead and AHDI finds a partition and seems
to work fine now!

 Thomas