Why is the Amiga ROM at a high memory location, and RAM in low memory?

Question

When a 68000 CPU powers up, it reads a few words at memory location zero to get the initial stack pointer and program counter. That suggests to me that a computer system designer would put the system ROM at memory location zero, where the 68000 would read the initial SP and PC when coming out of reset.

However the Amiga puts RAM at location zero, and the ROM at the very far end of the address space. It has a hardware switch which causes the system address decoding to place a second copy of the ROM at location zero, hiding the RAM. At reset, this hardware switch is "on", so the 68000 reads the initial SP and PC from this mirrored copy of the ROM and starts executing. Then the ROM firmware switches the hardware switch "off" to remove the mirrored ROM and reveal the RAM again.

This seems to me like an overly complex solution. Why did the Amiga's designers decide to place the ROM where they did and add this extra addressing logic to make it work?

Answer 1

It was part of the 68000 system architecture in which all the interrupt vectors are low in the memory map.

The first 1024 bytes are reserved for these vectors and if a program / os need to change these, hardcoding into ROM wouldn't work.

The vendor (Motorola) had application notes in which on a cold boot or reset, the ROM was mapped low. The idea came from the vendor not the implementation.

Thus will RAM mapped low after reset, the OS can setup the vectors in ram and setup a warm-boot reset vector.

This is analogous to how the hack on 286 was done to get out of protected mode. The program saved data in a known area below 1 meg and triple-faulted which caused the processor to reset into real mode. The OS checked the special location to determine if this was a cold boot or coming out of protected mode to continue to the right function.

Answer 2

All of the 68k-based computers (Amiga, Atari ST and Sinclair QL, as well as the classic Macintosh) went to market in a rush. And all of them went to market before the OS (and, thus, the ROMs) were really "finished". The QL initially had an outboard ROM extension that later on had to be replaced with the "final" ROMs (so, the computer had to be sent back to the factory for an upgrade), Amiga and Atari used a minimum loader that loaded the OS from floppy disk into low RAM (which was obviously much easier to upgrade).

In order to be able to use the vector tables in the first 1k of memory, those loadable OSs needed RAM there (otherwise, all TRAP and interrupt handlers would have had to be compiled into fixed places in later versions of the operating systems which would have been a severe hassle...)

An additional advantage of having RAM at lower addresses was that TRAPs and interrupt vectors could easily be re-directed to user-defined OS extension routines. Any piece of add-on hardware that used interrupts needed that feature. The Sinclair QL with ROM there had to use secondary vector tables in RAM for that purpose, effectively diverting trap and interrupt vectors through writable memory, adding additional complexity and latency.

Motorola realized this inconvenience and added a vector base register (VBR) to later versions of the 68k series, allowing the programmer to put the vector table anywhere in addressable memory. That meant that boot loader ROMs could be placed at $0 (or rather, anywhere), thus in a much more flexible way in 68010 and greater systems without hard-coding the vector addresses.

Answer 3

I'm not allowed to comment, so I'll add this here. The ROM overlay reset 'hack' was not limited to 68000's, and was well-established in the industry by the time the 68000 was introduced. (Intel 8080 systems did this, as did 8085 and Z-80 successors.) The usual reason is that reset and interrupt vectors are located together, and that (for interrupts, at least) they're really only useful if they can be changed, which means they need to be in RAM. Mapping ROM over RAM, at least for a few cycles after reset, means that the system can startup cleanly in ROM and then bootstrap itself to RAM-based operation, maintaining full flexibility. It had nothing to do with rushing product to market.

Processors that did NOT do this, e.g. 6800 and its successor the 6502, theoretically were 'easier' to design into a system, yet ended up harder to use in practice for general-purpose systems because the vectors were immutable. Given that the Intel-style 'hack' was only a couple of flip-flops in the address decoder, which was almost certainly discrete logic at this point in time in the industry, the cost was nearly negligible in order to self-start and yet be maximally flexible. It is most telling that Motorola, whose first effort (6800) put the vectors in ROM space (as in: far from the RAM addresses, which would have been page zero), in their next effort (68000) did it the Intel way.

I have no idea why Sinclair did not use this well-established technique in the QL.

CP/M TPA started at 100h in order to avoid the RST/interrupt vectors. Even when using the Z-80's IM2 enhanced interrupt system, you still needed to support the RSTx instructions. It would have been a woeful computer indeed that prevented you from using some valuable instructions because the system designer had not done his homework!

By adding the VBR in the 68010+, virtualization became possible. (All of the 68010 changes were to support virtual memory and virtualization, with the exception of the performance-oriented 'loop mode'.) Otherwise you'd have to engage in a massive 1kB swap-in/out to change the entire vector table for every context switch, while disabling ALL interrupts for the duration, and likely while editing some of them to keep the virtual host behavior while merging with target behavior. Very messy. VBR was not done for the convenience of any particular customer.

Answer 4

I don't believe there has ever been an official explanation to the "ROM overlay" behavior at power on, so the following is just my speculation.

As a matter of fact, Agnus/Agnes (the Address GeNErator) does not have any "Chip RAM base address" register, so even if the bus address decode external logic could have been made to have the Chip RAM appear (from the point of view of the 68000) at any address other than 0 (to leave space for ROMs at the beginning of the address space), the chips themselves would still have seen the Chip RAM as a block of RAM starting from address 0.

This would have required all program to do admittedly trivial pointer arithmetic (basically subtract the Chip RAM start address to any pointer programmed in the chips' registers).

Still, in 1983/84/85, when all cycles counted and programming was in assembly, this was probably seen as adding inconvenient burden to developers. Since in any case in the A1000 the whole bus address decode / chip select / RAM access logic is made with external logic (*), adding the ROM overlay logic would not have added much in cost, so Commodore went for keeping Chip RAM at 0 and the ROM to somewhere else.

Later models of course kept the same memory map for compatibility reasons.

(*) the original 48-DIP 8361/8367 Agnus/Agnes really has no bus arbitration logic; that was later added to the A500/A2000 "Fat" Agnus.

Answer 5

I don't know the true answer, but it did seem to be the trend with the earlier microcomputers to have ROM all the way at the top of the memory map and RAM always starting from 0.

The reason I can think of is that it is easier for hardware and software to always know that RAM starts at 0x0000 than it is to have to figure out what offset it begins at. (think: KickStart 1.3 was 256KB, 2.04+ was 512KB). Address lines for decoding ROM only need to exist in the higher region rather than needing to understand all 16/24/32 address lines.

I don't think that it applies to the 68000 series, but at least on earlier 6502 based platforms the zero page (0x00-0xFF) and stack page (0x100-0x1FF) had special meaning and thus forced ROM to be high. Perhaps it was simply an old habit in that respect.

Answer 6

In computers of that era, the MOS PROMs used for the initial program load were much slower than the RAM memory so Operating System would be loaded into RAM to be executed. This also allowed for adding features to the OS e.g. drivers for expansion cards. (Another reason is for "self-modifying code", which today is considered a programming no-no.) Note that today's computers load that initiation software from an 8-bit PROM into 64-bit RAM to start the system.