• Please review our updated Terms and Rules here

CPU Startup - What Happens?

P

pearce_jj

Veteran Member
Joined
May 14, 2010
Messages
2,808
Location
UK
Hi, I'm just wondering what happens when we 'hit the button' and turn on a computer. Obviously the CPU starts executing..., but how does it know from where to execute?

A bit a trawling suggests that MC68000 chips simply start at address 0, but how do Intel chips work given that address 0 (in real mode) is RAM?

Many thanks!
 
A CPU's instruction pointer will always be loaded with a reset exception vector during a reset or power on cycle. The value is architecture dependent. For x86, the effective physical address is 0xffff0. The segment/offset varied slightly across models.
 
Thanks very much. So how is the value of that reset exception vector set?
 
Depends on the processor. Z80/8080 simply starts execution at address 0 (equivalent to RST #00.) 6502 loads its initial execution address from 0xFFFC. 68000 loads the initial stack pointer from 0x00000000 and execution address from 0x00000004 and jumps to that point. 8086 loads its address from 0xfffff0 (ffff:0000 in segment/offset.) So all but very old kit computers and minicomputers are going to have ROM mapped to the appropriate region in the address space, so that the CPU has some idea what it's supposed to be doing.
 
Many thanks indeed for all the replies on this.

So to an extent then the criticism at Microsoft for creating the infamous 640KB limit was a bit unfair then, since the underlying architecture required at least the last segment to be ROM. With that in mind the design choice seems pretty logical.
 
pearce_jj said:
Many thanks indeed for all the replies on this.

So to an extent then the criticism at Microsoft for creating the infamous 640KB limit was a bit unfair then, since the underlying architecture required at least the last segment to be ROM. With that in mind the design choice seems pretty logical.
Click to expand...
Microsoft didn't create the 640KB limit, they only respected it when they developed DOS. The limit was set by IBM, and it was kept for reasons regarding backwards-compatibility.
 
Many thanks for that. Seems obvious now you've written it (since they made the things).
 
As a demonstration, I captured some address lines, the reset signal and the clock source:

power286.png


* Until second 0, the clock feeds the processor but the reset signal is high, so there is no activity on address lines
* When reset line goes down the processor starts to work
* The first change in address lines is the A0-A3 changing to low, the rest are high (I only sniffed A0-A8, but the rest are high too). That means 11111111111111110000 or 0xFFFF0
* Then there are some changes:
* A1 changes to HIGH, it means that the processor is accessing 0xFFFF2
* A1 changes to LOW and A2 to HIGH, it means that the processor is accessing 0xFFFF4
* A1 changes to HIGH, it means that the processor is accessing 0xFFFF6
This is a 286 processor, so it reads two bytes at once. That is why A0 doesn't change when reading this sequential addresses.
In these bytes read, the ROM has code to jump to another location. That is what happens a bit later when all address lines change.
 
Superb! This is simulated, presumably? (As those traces look incredibly clean.)
 
pearce_jj said:
Superb! This is simulated, presumably? (As those traces look incredibly clean.)
Click to expand...

Looks like a DSO display to me. They all look like that.

There were many 8086/8088 early systems that populated the entire address space (1008K RAM + 16K ROM for example).

On x80 systems, CP/M does create a problem in that the 8080/85 and Z80 all reset to location 0000, but CP/M uses low memory for system interface use (0005=BDOS jump, 0004 = IOByte, 005C = FCB, etc.), so just putting ROM in low memory (a la TRS-80 Model I) isn't really an option. There's a huge problem if the system designer wants to use the Z80 NMI interrupt as it vectors to location 0066, right in the middle of CP/M's FCB area. Some fancy hardware logic is usually employed to get around this, or the NMI simply isn't used.

Some implementations controlled the ROM mapping with an I/O port, allowing it to be mapped into memory space under program control. Others simply held the bus low (00 = x80 no-op instruction), causing the CPU to execute no-operations until it reached the ROM in high memory. An interesting approach was used by the Amstrad "Joyce"--the gate array IC that handled the printer interface forced a boot sequence of instructions onto the bus at boot time. It worked, but the downside is that it's impossible to change this boot sequence.
 
Last edited:
@Chuck, I really have no idea how (or why!?) you know all this stuff! As ever, absolutely facinating stuff and please keep it coming :)

@Nestor, thanks for taking the time to explain. Looking at signals on my old Golstar scope, they rarely look anything like the traces you have there!
 
It's a digital logic analyser not an analog scope. It will only show highs and lows. DSOs will do the same thing in pure digital mode.
 
You must log in or register to reply here.
Back
Top