CPU and addressing schemes

So, after putting the CPU in an breadboard, it’s time to start thinking about how memory, ROM and peripherals should be addressed. Now, there are som considerations here that makes things more or less complicated. For this, we need to understand what the CPU does when powered on. As all CPU’s, the MC680x00 have defined way of doing stuff. Both in terms of where to start executing code, as well as defining where to look for interrupt and exception routines.

One thing to keep in mind, all addressing in the MC68010 is 32-bit, and we will cover that at an later post.

Startup

When the CPU is powered on it does the following:
– It select address 0x00000000 and read the longword value(4 bytes, an 32-bit value) that should contain the address to the stackpointer (SP) and sets the SP register (A7) to that value. Of course this address value should point to RAM, as it needs to be writable

– Then the CPU steps to address 0x00000004 to read the longword address value for the program counter (PC), and set the PC register to this value, and then jumps to this address to fetch the first instruction there, in effect start running code. As we understand, to be able to present the above values, they have to be present on the data bus when address 0x000000 is selected, and of course, the easy way is to have a ROM that is programmed with these values connected to the CPU.

Exception and interrupt vectors

Now, in addition to the two longwords above for SP and PC, the CPU expects certain addresses to contain address values to jump to if certain exceptions occurs. These are so called exception vectors and are quite well defined, starting at address 0x000008 all the way up to 0x0000FC

VectorAddress(hex)Condition
0000Initial supervisor stack pointer
1004Initial program counter
2008Bus error
300CAddress error
4010Illegal instruction
5014Divide by zero
6018CHK instruction
701CTRAPV instruction
8020Privilege violation
9024Trace
10028Line A (1010) emulator
1102CLine F (1111) emulator
12030Unassigned, reserved
13034Unassigned, reserved
14038Unassigned, reserved
1503CUninitialized interrupt vector
16040Unassigned, reserved
17044Unassigned, reserved
18048Unassigned, reserved
1904CUnassigned, reserved
20050Unassigned, reserved
21054Unassigned, reserved
22058Unassigned, reserved
2305CUnassigned, reserved
24060Spurious interrupt
25064Level 1 interrupt autovector
26068Level 2 interrupt autovector
2706CLevel 3 interrupt autovector
28070Level 4 interrupt autovector
29074Level 5 interrupt autovector
30078Level 6 interrupt autovector
3107CLevel 7 interrupt autovector
32-47080-0BCTRAP 0-15 instruction vector
48-630C0-0FCUnassigned, reserved *
64-255100-3FCUser interrupt vectors
* Between 0C0-0FC later versions (68020/030/040) have vectors for MMU and FPU conditions

So if the CPU get for example an “Divide By Zero” exception, it will look at exception vector address: 0x000014, read the data at that address (containing an address), and jumps to that address and executes whatever user defined code there for dealing with the exception.

Starting at address 0x00000100 there are reserved space up to 0x000003FC for user defined interrupt vectors. This means that in total 1024 bytes starting at 0x00000000 are used for CPU internal stuff. And the easy way is just to put that in ROM as well right? It depends…..if you now that the exception code will never change, sure, it could reside in rom, but what if you would like to add new peripherals that suddenly use IRQs? Any changes to the exception code would require an new ROM to be programmed, making this approach clumsy and not very pracital. Now, here is the reason for me selecting the MC68010 instead of MC68000. The original MC68000 have no way of using any other addresses for the vectors, so computers using that CPU had ways of working around it by during boot, load SP and PC, copy the exception vecktors to RAM, and then disable the ROM and place the copied RAM at address 0x00000000. By doing this, the exception vectors could be altered without programming new ROMs.

Now, the MC68010/020/030/040/060 have an additional 32-bit register caled VBR or Vector Base Register. What this means that by setting this register to an address in RAM space, there is no need to swap out ROMs any more. This makes things alot easier, even if swapping out rom would give som extra space for RAM. If you have an 1 MB ROM and only use a few KB, there is a lot of waste. But for simplicity, I will start my project with 1 MB of ROM at 0x00000000, and 1 MB RAM at address 0x00001000.

Peripherals

Now, ROM and RAM is one thing, but to communicate with the outside, we will need some ways of communication, Serial, keyboard, mouse, video etc, they all ned a way of interact with the CPU, and just as memory, this is done by mapping the devices on the address bus. This is called memory mapped I/O, and was an common way of interact with peripherals back in the day. Nowadays an CPU have in addition to the address and data bus, separate channels for communication with external devices. If you ever wonder why there are 1500+ pins on an CPU of today, one of the reason is the dedicated channels for communicating with devices such as PCI Express, that back in the day was done directly with data and address bus.

Now, this means that I need to decide where to place any external devices address wise, and how much space we should reserve. I have come up with the following addressing scheme for my initial design_

AddressDescription
0x00000000 – 0x000FFFFFROM ( 2 x 512K)
0x00100000 – 0x001FFFFFOnboard RAM (2 x 512k)
0x00200000 – 0x00CFFFFFSpace for additional (12 MB) RAM
0x00D00000 – 0x00FFFFFFI/O space (2 MB)

As we can see above, I have 2 MB och addressing space for I/O devices, and that could for some look like a waste of space, but i kept it big just in case i would like use RAM as an frame buffer, wich is an much later topic.

So with an basic memory map we are ready to start connecting wires between address/data bus and ROM/RAM. Som may note that I use 2 x 512 chips above, and that is for an good reason that I will cover in the next post

Leave a Reply

Your email address will not be published. Required fields are marked *

Please reload

Please Wait