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. Commented Jul 25, 2016 at 9:40
  • 2
    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
    Commented Jul 25, 2016 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
    Commented Nov 5, 2017 at 20:12

6 Answers 6


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.

  • 2
    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
    Commented Jan 8, 2018 at 23:23
  • Actually, triple-faulting was one of the methods used to reset 286 back to real mode, I seem to recall the keyboard controller chip could also do it.
    – paxdiablo
    Commented Feb 18, 2022 at 16:52

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.

  • The question might be off-topic somewhat, but what was the situation on the early Macintosh computers? Was ROM low or high? Commented Jul 26, 2016 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
    Commented Jul 26, 2016 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? Commented Sep 21, 2016 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
    Commented Sep 21, 2016 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
    Commented Nov 28, 2016 at 16:23

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.


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
    Commented Aug 7, 2018 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
    Commented Jul 26, 2016 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
    Commented Jul 26, 2016 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
    Commented Aug 7, 2018 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.

  • 1
    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.
    – user461
    Commented Apr 8, 2019 at 6:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .