Some mapping on the ROM images

[inbarraz]

Loading addresses:

U17 base address is 0x800000 U15 base address is 0x808000

This means they are adjacent and consecutive. ROM code contains some hardcoded addresses which helped figure this out.

[the1stArchyx]

Both ROMs start with a complete 680x0 Exception Vector table (to which the Vector Base Register, VBR, is initially set to point to), which is 0x400 bytes long. The whole table is full of hard-coded 32-bit pointers. The first pointer sets the initial Interrupt Stack Pointer, which reveals a 16 KiB patch of memory at 0xC00000. The second pointer sets the Program Counter for the CPU to start executing code.

I dug deep enough into the code to figure out some of the memory map:

• 0x0000 0000 – 0x001F FFFFF : The main RAM is likely here. Some pointers are written to 0x0 and 0x4 and code is executed from 0x1000 and 0x1100. This feels like Operating System bootstrapping.
• 0x0070 0000 – 0x007F FFFFF : something is here
• 0x0080 0000 – 0x0080 7FFFF : ROM
• 0x0080 8000 – 0x0080 FFFFF : ROM
• 0x0090 0000 : MMIO for optional hardware ?
• 0x00A0 0000 – 0x00A0 FFFF : Serial console MMIO (the 8-bit UARTs are byte-addressed with an odd address)
• 0x00A1 0000 – 0x00A1 FFFF : Serial console MMIO
• 0x00A2 0000 – 0x00A2 FFFF : Serial console MMIO
• 0x00A3 0000 – 0x00A3 FFFF : Serial console MMIO
• 0x00A7 0000 : MMIO for something
• 0x00B0 0000 : MMIO for optional hardware ?
• 0x00C0 0000 – 0x00C0 3FFF : Shared RAM (16 KiB) – some function code is executed from this memory.
• 0x00C0 0400 – 0x00C0 07FF : Vector Base register for the "slave" CPU is set up here in ROM code (at 0x80d208). At this point I'd expect the Operating System routines to take over as the next three jsr instructions execute code from the small RAM before stopping the CPU to wait for an interrupt.
• 0x00C0 3800 : Top of Interrupt Stack of a CPU
• 0x00C0 4000 : Top of Interrupt Stack of another CPU
• 0x00D0 0000 : The small battery-backed-up configuration memory lives here ?
• 0x00E0 0000 : MMIO (SCSI and front panel LEDs ?)

It's incomplete, of course, but still a good starting point to dig even deeper.

[c-logic]

any function in the (virtual) memory mapping still has to map the RAM to 0x0, the processor runs normally with the exception table on address 0x0 (SP) with reset address 0x4.

[the1stArchyx]

any function in the (virtual) memory mapping still has to map the RAM to 0x0, the processor runs normally with the exception table on address 0x0 (SP) with reset address 0x4.

The ROM(s) are briefly mapped to 0x0 to get the CPU(s) started after reset, just like in a classic Amiga. Once a 680x0 CPU runs code, those two memory addresses become irrelevant to CPU function.

The base model 68000 is the only CPU that'll actually require RAM (or ROM) at the start of the memory map as the Vector Base Register is fixed at 0x0, the exception vectors starting from 0x8. All other CPUs in the 680x0 family have a modifyable VBR and can have the exception vector table at any even address (preferably aligned to 32-bit word size, possibly required for the externally 32-bit CPUs) within the accessible memory space.

[ewenmcneill]

FTR, there's a shared Ghidra repo, where various people have gone a fair way into reverse engineering the ROMs. And the Ghidra project has the known memory map defined in it.

https://github.com/misterblack1/plexus-p20/tree/main/ghidra-project

has details of how to access the Ghidra server with the shared project. I believe anonymous access is enabled for read-only access; or direct message 'mxshift' on the Usagi Discord server (which Adrian's Digital Basement has a couple of channels in now) to get an account with write access too. (There's a lot more discussion in the #plexus-p20 channel on the Usagi Discord server; IIRC most of Adrian's recent Plexus videos should have a link to the Discord server.)

Ewen