|Re: [hatari-devel] TOS 3.06 does not boot from ACSI|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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!