Hi all
Chris gave me a copy of the boot ROM and I played around with it a bit.
I threw the 4KB of boot ROM in Ghidra and confirmed a couple things:
- At boot, ROM is mapped to 0, and then remapped either by a write
to the location or by a cycle counter: The initial stack pointer at
0x0 is 0x0001fffe and the initial program counter at 0x4 is
0x00ffc026, indicating the ROM is normally located at 0x00ffc000.
- The ROM freely interchanges addresses in the
0x00ffc000..0x00ffffff range and addresses in the
0xffffc000..0xffffffff range, which is annoying to deal with in Ghidra.
The code takes advantage of the 68000 sign-extend on absolute short
addressing mode, like move.b #$00, $8011. IDA correctly disassembles
this to "move.b #0,($FF8011).w". I assume Ghidra if sign-extending
it all the way to FFFF8011?
- I/O devices appear to be in the 0x00ff8000..0x00ffbfff range, all
of the devices accessed via the bootstrap seem to be barely above 0x00ff8000.
- Only NMI, bus error, interrupt 2, and interrupt 5 are set up by
the bootstrap.
Yup.
- The bootstrap is very bare-bones but still has a bunch of
indirection in it; itâs obviously written in assembly, but it does
seem to have parameterization so it may support both console and serial I/O.
I suspect either some low-level high-level language, or massive use
of macros (which is in effect a low-level high-level language :-) Code like:
; Called with A6 pointing to a length and a string address
00FFCA4C : 48E7 8080 MOVEM.L D0,A0,-(A7)
00FFCA50 : 3016 MOVE.W (A6),D0 ; length
00FFCA52 : 48C0 EXT.L D0
00FFCA54 : 206E 0002 MOVEA.L +2(A6),A0 ;
pointer to string
00FFCA58 : 508E ADDQ.L #8,A6 ; clear stack
00FFCA5A : 5380 SUBQ.L #1,D0
00FFCA5C : 6B0E BMI $00FFCA6C ; done
00FFCA5E : 518E SUBQ.L #8,A6 ;
make space on stack again
00FFCA60 : 1D58 0001 MOVE.B (A0)+,+1(A6) ;
one character on stack
00FFCA64 : 4EB8 C566 JSR $00FFC566
00FFCA68 : 51C8 FFF4 DBF D0,$00FFCA5E ; loop
00FFCA6C : 4CDF 0101 MOVEM.L (A7)+,D0,A0
00FFCA70 : 4E75 RTS
I suspect that I can figure out from the pattern of I/O accesses
which devices are at which address in the memory map, at least if I
bring up an emulation in MAME. That should at least allow writing
new code for it, and _maybe_ even figuring out which CRT controller
the video hardware uses and where in the memory map it is. (I
suspect the 6845 and/or 6847 just from the time period, but who
knows? Gotta see what it actually do when trying to show the âIPL
IN PROGRESSâ string contained in the ROM, or one of the couple
error strings
)
Chris
