Prev: TASM (Borland, v3.2) read floating point number from file
Next: Beth aka "BethStone21"
From: Terence on 18 Dec 2007 17:24
That's Intel. That's because the Intel EPROM boot code is switched in
first, before being switched out again.
There was a time before EPROMS.

I used Nixie tubes and double triodes before there was even ferrite
core memory.
I used to walk into a Mercury Star holding boxes of replacement valves
("tubes") before a run in the fifties.

I am a long way pre-Intel, worked on building an early UK computer in
1952-53, worked for IBM UK at Hursley and La Goude Labs 1961-64, and
had my own hand-built computer using discrete chips, before the
Lancaster TV monitor hack.
I also know some control cpu chips quite well, such as used in a Fax
machine, because I rewrote the on-board code.
I'm the "UK Hacker" of the book "The Hackers"; three actually
mentioned by name were Bill and the two Steves..
From: H. Peter Anvin on 18 Dec 2007 18:10
Phil Carmody wrote:
>>
>> Some processors, e.g. the Zilog Z80, *do* start at address 0, but that
>> was a choice the designer of that particular architecture made.
>
> Absolutely, and some processors start by jumping to the address read
> from location 0. There must be other behaviours out there too.
>

Some CPUs boot by sucking in a chunk of data into its caches (the
address of which is determined in any of a number of ways) and start up
as if the cache was local RAM. This often means the load address and
the execution address are totally different.

-hpa
From: Terence on 17 Dec 2007 18:08
CPU chips always reset to start at memory address 0000.
This is the no-power memory pointer contents.
This is what happens on power-loss.

The computer board electronic design can manipulate where memory
(actual chips) are physically mapped on start-up by controlling the
memory address lines. So a read-only memory chip (sometimes re-
writablea0 with a boot program pre-loaded, is usually what the cpu
address pointer address lines are pointing to initially; then a final
signal turns off the special connection (inhibits one or more upper
memory address lines), and allows processing to continue from
writeable memory.

This is why there are conflicts of opinion expressed here.
From: Bill Leary on 19 Dec 2007 20:45
"Wolfgang Kern" <nowhere(a)never.at> wrote in message
news:fk6our$l8p$1(a)newsreader2.utanet.at...
> Bill Leary answered:
> ((..omitting much of your response, we're largely in agreement so I have
> no reply..))

>> I *DID* see the ROM repeated at the top of memory DURING reset, but on
>> the PC machines, it disappeared when the main-board was released from
>> reset. I guess I'd assumed that was normal, for a PC, but now you've
>> got me wondering.
>
> What you see 'during reset' will never reach the CPU ;)

Of course. My point was that it appeared that the BIOS was echo'd to the
top of the address space until the hardware came out of reset, at which
point the echo disappeared.

> The interesting point would be after the raising edge of the RESET-line,
> IOW: what are the contents of AD0..32(..52) when the CPU becomes
> active ?

I don't recall ever noticing that, and I no longer have the means to look.

My background at that time for system programming had been PCs, so I
expected the BIOS to be at the top of the first meg. On this machine, a
non-PC but with some PC compatibility, it was there, but when I set the ICE
trap at 0x000FFFF0 the machine just booted right up. I think this was an
80386, maybe a 80486. Anyway, I looked up the reset state in the book
(which I still have) and under 10.2.3 it says "After RESET, address lines
A31-20 are automatically asserted for instruction fetches. This fact,
together with the initial values of CS:IP, causes instruction execution to
begin at physical address FFFFFFF0H." I set the ICE for that, and got a
trap.

This piqued my curiosity, so I put the ICE on the PC I was using for
development and watched what happened. With RESET held active, the BIOS
appeared at the expected location at the end of 1M (128K of it, as I recall)
and again at the end of the overall memory space. As soon as RESET was
released, the one at the end of memory disappeared.

> btw: x86 CPUs idle for a few hundred cycles after RESET is released.

I believe you, and won't bother to look it up. I may even have known it
then, because I remember there was some setting I had to make in the ICE so
it would handle trapping the first instruction after a reset correctly. But
it slowed the instruction stepping down something awful, so you'd usually
turn it on, do the reset, then stop the thing and turn it off again. Or
you'd set the trap for the second instruction after reset.

> Where could you connect your ICE ?

This has been an awfully long time now, but as I recall, you pulled the CPU,
put the "head" in it's place, and plugged the CPU into the head. Then there
was a smaller cable that went to somewhere else on the target. If memory
serves it was to drive reset. There was some logic on the "head," then a
cable (a couple of 50 conductor ribbon cables) went to a box about three or
four feet away then that connected to a PC via a parallel port.

One thing I was always surprised about was that I could see memory with the
machine in reset. From what I was reading about the chipset, especially the
memory controller, I'd expected that I wouldn't be able to see anything
until I let the chipset out of reset. But I could read memory. ROMS
anyway, RAM returned all ones.

> my old workstation got a CPU-socket-link-cable.

Sounds like that might be what I was using. This was back in the 386/486
days. All of the newer ones I've used connected via JTAG.

> Or are you talking about a BUS-scanner connected to a PCI-slot ?

I'm not aware of having used anything like a BUS scanner. I know it didn't
connect to a PCI slot.

- Bill

From: H. Peter Anvin on 19 Dec 2007 21:21
Bill Leary wrote:
>
> I don't recall ever noticing that, and I no longer have the means to look.
>
> My background at that time for system programming had been PCs, so I
> expected the BIOS to be at the top of the first meg. On this machine, a
> non-PC but with some PC compatibility, it was there, but when I set the
> ICE trap at 0x000FFFF0 the machine just booted right up. I think this
> was an 80386, maybe a 80486. Anyway, I looked up the reset state in the
> book (which I still have) and under 10.2.3 it says "After RESET, address
> lines A31-20 are automatically asserted for instruction fetches. This
> fact, together with the initial values of CS:IP, causes instruction
> execution to begin at physical address FFFFFFF0H." I set the ICE for
> that, and got a trap.
>
> This piqued my curiosity, so I put the ICE on the PC I was using for
> development and watched what happened. With RESET held active, the BIOS
> appeared at the expected location at the end of 1M (128K of it, as I
> recall) and again at the end of the overall memory space. As soon as
> RESET was released, the one at the end of memory disappeared.
>

It's actually rather simple: on RESET, CS.base = 0xffff0000 even though
CS = 0xf000; however, the CPU is still in real mode. When the first CS
load (i.e. far jump) happens, CS.base <- CS << 4, which drops the high bits.

If the firmware doesn't want to run in low memory, it can do a near jump
which doesn't reload CS, and enter protected mode directly(*).

-hpa


(*) Note that the LGDT instruction requires a pointer in memory. Since
all the segments have limit = 0xffff at this stage, CS is the only
segment that can access the ROM area in high memory. Thus, the LGDT
instruction will need a CS override.
 |  Next  |  Last
Pages: 1 2 3
Prev: TASM (Borland, v3.2) read floating point number from file
Next: Beth aka "BethStone21"