Norma; 'boot sequence' for a CPU?

[Active8]

On Sun, 31 Oct 2004 15:39:05 -0500, Active8 wrote:

On Fri, 29 Oct 2004 18:44:02 -0700, Jamie wrote:

snip

Most CPUs fetch a vector (start pointer) from a fixed location in ROM,
which then starts executing BIOS code in ROM, which will eventually
copy the OS from a disk file into RAM and jump into that.

John

if memory serves, the 0700:0000 rings a bell.
or something like that as to where the
boot loader gets it code loaded into form the
boot sector.

for PCs its 0xAA55 or 0x55AA - i forgetted

nah. That's the boot signature. 0700:0000 doesn't ring any bells for
me though. I need to relocate my notes on all that PC sheisse.
--
Best Regards,
Mike

 

[Active8]

On Fri, 29 Oct 2004 18:44:02 -0700, Jamie wrote:
<snip>

if memory serves, the 0700:0000 rings a bell.
or something like that as to where the
boot loader gets it code loaded into form the
boot sector.

0x7c00

http://www.geocities.com/riskyfriends/x86/download/MsDoSbootSect.txt

--
Best Regards,
Mike

 

[Rich Grise]

On Sun, 31 Oct 2004 16:05:34 -0500, Active8 wrote:

On Sun, 31 Oct 2004 15:39:05 -0500, Active8 wrote:

On Fri, 29 Oct 2004 18:44:02 -0700, Jamie wrote:

snip

Most CPUs fetch a vector (start pointer) from a fixed location in ROM,
which then starts executing BIOS code in ROM, which will eventually
copy the OS from a disk file into RAM and jump into that.

John

if memory serves, the 0700:0000 rings a bell. or something like that as
to where the boot loader gets it code loaded into form the boot sector.

for PCs its 0xAA55 or 0x55AA - i forgetted

nah. That's the boot signature. 0700:0000 doesn't ring any bells for me
though. I need to relocate my notes on all that PC sheisse.

I think 0700:0000 is just the address after the reserved block for
the BIOS interrupt vectors, which were at 0400:0000. Someone else
mentioned 7C00:0000 as the execution address of the bootloader.

I suppose I could boot my Athlon 2400+ to DOS, and see what DEBUG
says. ;-)

Cheers!
Rich

 

[Chaos Master]

Quoting Rich Grise [rich@example.net], that posted to sci.electronics.basics on
Mon, 01 Nov 2004 00:24:02 GMT under article
<pan.2004.11.01.00.28.50.951751@example.net>:

I was a pretty good hacker in my day, back before "they" perverted the
word.

I still keep my old hex editor for MS-DOS, that can convert opcode(s) ->
instruction and instruction -> opcodes, for x86 processors.

However, I don't think it handle any new CPU features like 3DNow that is on AMD
CPU's.

Sometimes I think about 'F0 0F C7 C8'.


--
Chaos MasterŽ, posting from Brazil.
"And if I bleed, I'll bleed / knowing you don't care. "

http://marreka.no-ip.com | http://tinyurl.com/46vru | http://renan182.no-ip.org

 

[john jardine]

"Roger Johansson" <no-email@home.se> wrote in message
news:Xns9591C47468E2986336@130.133.1.4...

John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote:

It starts running, reading the first RAM memory address.

But there's nothing in RAM yet. That would be insta-crash.


I have used static RAM as ROM myself, that is why I said RAM.
Most people would maybe call a programmed memory a PROM, even if it
actually is a battery-backed static RAM, which is a lot easier to handle
for experimental work, because there is no need for a special programmer
or eraser.

And it doesn't crash, if the first address is empty or not connected it
will just try the next address.

If I recall correctly a memory content of nothing, zero, makes the cpu
execute a NOP, a no operation operation, and it goes on to the next
address.

Even if you have no memory connected you can see the addresslines count
up, trying to find some content other than zero.

Maybe I should add that my knowledge in this field is 20 years old, and
maybe not correct in all details. It was in 1984 I was playing with a
Z80 and static RAM. And I am too lazy to check it up now.


--
Roger J.

I once made a 16 bit counter for a triangle generator using just a Z80 with
it's 8 data lines tied to 0V. At power up it goes to location 0, reads in
the 8 data bits, knows them as a NOP so puts out next address, reads
another NOP etc. Address lines get to 2^16 and roll back round to 0 again.
External variable clock set the count rate.
regards
john

 

[phil]

On Fri, 29 Oct 2004 08:37:05 GMT, "Tom Biasi"
<tombiasi@REMOVETHISoptonline.net> wrote:

Its been quite a while since I messed with a Z80.

You might try your question here:comp.arch.hobbyist

Cheers, will do. All advice welcome.

 

[Peter Bennett]

On Fri, 29 Oct 2004 07:40:13 GMT, pdmim@hotmail.com (phil) wrote:

I'm curious, please indulge me - what is the normal 'boot sequence'
for your average old CPU?

Let's take a Z80 for example - when a board with a Z80 (and relevant
RAM, ROM and support chips) is powered on, what is the sequence of
events that takes place?

The processor fetches and instruction from a specific location in
memory (location 0 for the 8080/Z80, may be elsewhere for other
processors). What happens after that depends on the instruction it
finds, and on the rest of the program.

Does the CPU, for example, first expect an interrupt from some other
part of the circuit?

No,

Does it immediately try and access RAM or ROM via
the address lines? Etc.

Yes

Or is there a web site somewhere with this info?

Consult the databook for the processor you are interested in.

I'd really like to know this as it will help my understanding
considerably.


Thanks
Phil

--
Peter Bennett VE7CEI
email: peterbb4 (at) interchange.ubc.ca
GPS and NMEA info and programs: http://vancouver-webpages.com/peter/index.html
Newsgroup new user info: http://vancouver-webpages.com/nnq

 

[Jonathan Kirwan]

On Fri, 29 Oct 2004 07:40:13 GMT, pdmim@hotmail.com (phil) wrote:

I'm curious, please indulge me - what is the normal 'boot sequence'
for your average old CPU?

Let's take a Z80 for example - when a board with a Z80 (and relevant
RAM, ROM and support chips) is powered on, what is the sequence of
events that takes place?

Does the CPU, for example, first expect an interrupt from some other
part of the circuit? Does it immediately try and access RAM or ROM via
the address lines? Etc.

Or is there a web site somewhere with this info?

I'd really like to know this as it will help my understanding
considerably.

Basically, just think of the CPU as having some internal registers and control
bits that are initialized to specific values as the CPU comes "out of reset."
(Most processors have a carefully designed reset state, preceding the moment
when they actually start to 'run'.)

Some CPUs will set their instruction pointer to 0, some to a 'large number', but
all of them set it to a predictable value before they start executing.
Sometimes, this points to some memory inside the CPU. Sometimes, to external
memory (suggesting the CPU actually supports an external memory bus.) Either
way, this memory hopefully will be non-volatile memory of some kind. It's up to
the system designer or the programmer to make sure that some useful code is
there.

What happens after that will depend on the code.

In your IBM PC, it's the BIOS flash or ROM that sits at this point and helps to
start up your PC. In many embedded systems, using small microcontrollers, it's
entirely code you write for your application, forced to be placed at the right
location by a locating linker.

Jon

 

[Glenn Gundlach]

Roger Johansson <no-email@home.se> wrote in message news:<Xns95917B86C791E86336@130.133.1.4>...

Active8 <reply2group@ndbbm.net> wrote:

Those spec sheet thingies? My best suggestion is for the OP to start
reading those. They're priceless and free.

The Z80 reference manual:

http://www.zilog.com/docs/z80/um0080.pdf

Inside that pdf file, look at page 28, a minimum system.

See the reset circuit connected to the -reset pin, it is only a resistor from plus 5 Volt and a capacitor to ground.
When the power supply starts the capacitor is charged, and Z80 starts.
It then starts executing the first RAM memory address.

That simply cannot be. The 'first' RAM address contains garbage data
since it was just powered up. I suspect the reset vector points to a
ROM address and execution procedes from that instruction. I'm not
familiar with the Z-80, only MCS-51 and 6805/08 bugs but those two are
essentially the same. The Moto bugs get the reset vector programmed
in. The MSC-51 bugs have fixed vectors but you must execute program
from a known value i.e. EPROM/PROM/flash/non volatile, etc.
GG

 

[Jamie]

John Larkin wrote:

On 29 Oct 2004 08:53:36 GMT, Roger Johansson <no-email@home.se> wrote:


pdmim@hotmail.com (phil) wrote:


Let's take a Z80 for example - when a board with a Z80 (and relevant
RAM, ROM and support chips) is powered on, what is the sequence of
events that takes place?

It starts running, reading the first RAM memory address.



But there's nothing in RAM yet. That would be insta-crash.

Most CPUs fetch a vector (start pointer) from a fixed location in ROM,
which then starts executing BIOS code in ROM, which will eventually
copy the OS from a disk file into RAM and jump into that.

John

if memory serves, the 0700:0000 rings a bell.

or something like that as to where the
boot loader gets it code loaded into form the
boot sector.

 

[Glenn Gundlach]

Roger Johansson <no-email@home.se> wrote in message news:<Xns95924558BF4786336@130.133.1.4>...

stratus46@yahoo.com (Glenn Gundlach) wrote:

When the power supply starts the capacitor is charged, and Z80 starts.
It then starts executing the first RAM memory address.

That simply cannot be. The 'first' RAM address contains garbage data
since it was just powered up.

Not if it is a programmed static RAM, which then works just like a
ROM/PROM.

I suspect the reset vector points to a
ROM address and execution procedes from that instruction.

After reset it starts from memory location zero, and executes the
instruction it finds there. What kind of memory, in a technical sense,
you are using doesn't matter, static RAM, ROM, PROM, EPROM, hardware
switches, diode matrix, or whatever.

(You probably associated to dynamic RAM when I said RAM, but there are
other kinds of RAM memory, which can have a predictable (programmed)
content.)

Have you actually done this or is this an assumption? You might note
that I DID mention several varieties of memory that would be usable
for boot code. You say that 'static RAM' would be OK and that is just
not the case. Static RAM is only static as long as the power is on.
Obviously a battery backed static RAM (non volatile RAM) could work.
From a powered off condition, the RAM contents is random garbage and
is useless as code.

The start address is device dependant and may or may not be '0'. For
example, the 68HC908 reset vector is $FFFE. The value stored there is
the address to begin execution. For that bug it is most certainly not
0.

The 8031 does start at 0 but since the other vectors are in the low
addresses, you need to jump to the start of the code.

gg

 

[Glenn Gundlach]

Roger Johansson <no-email@home.se> wrote in message news:<Xns95923D6E2A91C86336@130.133.1.4>...

stratus46@yahoo.com (Glenn Gundlach) wrote:

You say that 'static RAM' would be OK and that is just
not the case. Static RAM is only static as long as the power is on.
Obviously a battery backed static RAM (non volatile RAM) could work.
From a powered off condition, the RAM contents is random garbage and
is useless as code.

If you read the latest messages in the newsgroup before you post you
can save yourself, and others, a lot of unnecessary work.
Somebody may have already answered your question already.

Sir, I didn't HAVE a question. I was respoding to your assertion that
the processor began running from RAM at address zero.

gg

 

[Rich Grise]

On Sun, 31 Oct 2004 15:49:33 -0500, Active8 wrote:

On Fri, 29 Oct 2004 22:44:48 GMT, Rich Grise wrote:

On Fri, 29 Oct 2004 18:43:55 +0000, Jonathan Kirwan wrote:

On Fri, 29 Oct 2004 07:40:13 GMT, pdmim@hotmail.com (phil) wrote:

I'm curious, please indulge me - what is the normal 'boot sequence' for
your average old CPU?
...
What happens after that will depend on the code.

In your IBM PC, it's the BIOS flash or ROM that sits at this point and
helps to start up your PC. In many embedded systems, using small
microcontrollers, it's entirely code you write for your application,
forced to be placed at the right location by a locating linker.


A Locating Linker? Sheesh! I just wrote my code right at its target
address. My assembler would generally put out a .hex file, which I'd
send to the programmer or emulator.

That's pretty passe` IMO. I've never heard of "locating" linker -
linker/loader, yes. I write my embedded code to be relocatable, but I can
specify where certain blocks go in the linker script, for e.g., the reset
& ISR vector must be placed just so and sometimes I'll force data
registers to be on a specific page so I don't have to force page switches
to access data within a routine when all the data should all be in the
same page.

ORG - never use it anymore.
RORG - the original (?) relocation linker directive.

You can still write PC code in asm. - exe files have a special header
starting at 0x00, .com programs are ORG 0x100, and .sys files are ORG
0x00. The rest of the code can be roelocatable.

I was a pretty good hacker in my day, back before "they" perverted the
word.

I wrote a dumb terminal once in C, just for the fun of it, and stole
somebody else's interrupt handler by using a popup debugger.

I wrote a TSR that intercepted the keypress interrupt, and made a little
click through the PC speaker. I notice that these days keys make their
own noise. ;-)

Now, I drag & drop widgets. Sigh.

Cheers!
Rich