|Re: [hatari-devel] TOS 3.06 does not boot from ACSI|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Thomas Huth schrieb:
> OK, thanks, that's good to know ... but apparently, TOS 3.06 also reads
> the value from the VME bus GPIO register ... maybe as a fall back if the
> NVRAM is not containing a sane value?
A small clarification: $ffff8e09 is *not* a VME bus register as such,
but it is a GPIO register of the TT's SCU. So the VME bus is not
involved in any way.
Also, here is part of the code that you omitted:
00E00B14 move.b ($FFFF8E09).w,d0
00E00B18 and.w #$F8,d0
00E00B1C move.w d0,($A00).w
00E00B20 bne.s loc_E00B3E
00E00B22 pea ($A00).w
00E00B26 move.w #2,-(sp)
00E00B2A clr.l -(sp)
00E00B2C jsr sub_E0208C
.... where the last JSR jumps into the NVRAM reading subroutine that then
overwrites the boot selection in $A00. Hence, one can see that if the
upper 5 bits of this GPIO register (note the AND.W #$F8,D0) are
non-zero, this takes preference over the NVRAM.
Now, sadly I don't own a TT to test this theory, but I suppose that the
GPIO register is preserved across a reset and thus allows a one-time
(not permanently stored in NVRAM) boot selection.
Also note that the least significant bit of $ffff8e09 is used for a
different purpose -- that I didn't further investigate. I'm not sure if
it's correct to simply set this to 0x01 as Hatari now does.
Christian Zietz - CHZ-Soft - czietz@xxxxxxx
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA