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?

  • 1
    That's a good question. i can't say I have an answer for you, but I guess it could have something to do with how the Amiga 1000 loads the Kickstart into memory from the floppy drive. So that portion of the address space needs to be writeable until it's write-protected later in the bootprocess. Hopefully someone with better knowledge will be able to say for sure. – Wilson Jul 25 '16 at 9:40
  • 1
    Actually, most of the 68k-based home computers of that time had RAM at the lower addresses - All of the the various Atari ST computers did so as well. The Sinclair QL was a notable exception with ROM in the lower 48k – tofro Jul 25 '16 at 22:38
  • The Apple Lisa's ROM was at the top. The Apple Macintosh's ROM was at $400000 as the top of RAM was reserved for expansion slots. The Atari ST has OS ROMs at $E00000 and $FC0000 and has I/O at the top of RAM. – Tim Locke Nov 5 '17 at 20:12

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 double 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.

  • 1
    An additional advantage of having RAM low in the memory map is that 16 bit absolute addressing could have been used, similarly to the .COM conventions of the MS-DOS world. Although on 68k computers this was quickly superseded as all of them had more memory available at the start, the only remaining usefulness is the shorthand for move.l $4.w,a6 to fetch the ExecBase from location 0x00000004. – chexum Jan 8 '18 at 23:23

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 much more flexible in 68020 and greater systems.

  • The question might be off-topic somewhat, but what was the situation on the early Macintosh computers? Was ROM low or high? – Wilson Jul 26 '16 at 9:38
  • 2
    Actually, the classic Mac had the very same concept with low memory RAM and a bit of glue logic that screened in ROM at $0 during RESET. $0-$[whatever your RAM size would be upto 512k] is RAM, ROM starts at $600000. – tofro Jul 26 '16 at 11:43
  • Good answer (+1), but without wanting to nickpick, the last line is missing a word, or two, I think: That meant that boot loader ROMs could be placed at $0 [which is] much more flexible in 68020 and greater systems. However, even which is doesn't sound quite right... What did you mean to say? – Greenonline Sep 21 '16 at 18:27
  • 1
    @Greenonline I must admit that after some months I can't really remember what I meant to say with that sentence ;) , but admittedly it doesn't really make much sense to me today. Will try to re-work... – tofro Sep 21 '16 at 19:00
  • 1
    The 68010 supports VBR as well, not that it was used in any Amiga computers other than as a drop-in user upgrade for 68000 models. – mnem Nov 28 '16 at 16:23

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.

  • In such a hypothetical machine with Chip RAM at a high address, such a subtraction wouldn't be required because the designers would have also arranged for the start address to be at a multiple of 512kiB. The higher bits would be ignored by the register (i.e wouldn't even have latches) and thus the address effectively taken modulo 512kiB. The proposed increase beyond 2MiB of Chip RAM in the never-shipped A3000+ would have probably used such a scheme. – pndc Aug 7 '18 at 10:15

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.

  • 2
    Not entirely true. A lot depended on the CPU - 6502's would start execution at the address in $FFFC-FFFD so it made sense for ROM to be there (as well as 0-page and the stack as you've mentioned), but the Z80 started at address 0 for boot execution, so on many of those machines ROM is in the lower memory area. – Joe Jul 26 '16 at 0:53
  • 2
    @joe Z80: With the exception of any of the very common computers that could run CP/M - They need RAM at lower addresses (because the CP/M TPA starts at 100H) and normally use concepts similar to the 68k based computers to overlay ROM during boot. – tofro Jul 26 '16 at 13:11
  • Indeed any 8080-based system or Z80 system that's trying to be compatible with 8080 software and which wants to support loadable device drivers needs to have RAM at low addresses, because that's where the reset vectors are (which you need to be able to change in order to support hardware interrupts in your device drivers, unless you're using the Z80 extended interrupt modes). Another approach rather than having a ROM that is moved is to simply provide a fixed sequence of bytes to the processor at startup, which produces much the same result but may be easier in some designs. – Jules Aug 7 '18 at 16:14

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.

  • Can you specifically identify any systems which operated this way? Most of the home computers from this era I'm familiar with -- including PC compatibles! -- executed code directly from ROM. "BIOS shadowing" didn't emerge until the 1990s. – duskwuff Apr 8 at 6:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.