14 Jul
2010
14 Jul
'10
9:14 p.m.
On 7/14/10, Sebastian Brueckner <sb at thebackend.de> wrote:
On 14.07.10 19:59, Henk Gooijen wrote:
They do, though on the Amiga, for example, $00000000 is routinely filled
with $0000 and $00000004 contains a pointer into the master library
vector through which all OS resources are accessed, but TRAP and IRQ
vectors are definitely at the bottom of the 16MB map.
... the EPROM will sit in $FFFF0000-$FFFFFFFF
(you need some
ROM there for the reset vector) and the RAM sits at $00000000...
I thought all interrupt vectors started from address 0. What do you need A23 and the high addresses for?
From the designs I have experience with, to make it
easy to glom onto
upper bits to trivially slice and dice the memory map into swaths
of RAM,
ROM, I/O, etc. For the COMBOARD, A23 and A22 are used to divide
the entire memory map into 4 zones - RAM at the bottom, then up to 4MB
of addresses that map one-to-one over to Unibus or Qbus locations for
the host (there's no scatter-gather circuit - you just MOVE buffers into this
space and hardware initiates NPR cycles and such), then I/O (with *lots*
of mirrors and holes, then ROM (with lots of mirrors). It's an embedded
design that was only ever manufactured with 2MB of physical RAM and
a 22-bit DMA zone, so the decoding circuit is simple. Workstations and
other designs that need to maximize RAM space are typically more complex
in terms of address zone decoding.
As for "why ROM on top?", I'd say it's because most designers in the
1980s
had experience with machines where either RAM or ROM had to be on top
or bottom of the memory map because of some architectural requirement
(like the 6502, in particular), so they made their 68K designs look familiar.
I've read about designs that map ROM to $00 on
boot to load stack
pointer etc. and remap to RAM later on to allow the user program to
modify the interrupt vectors.
Yes. I think every 68K design I've seen allows for vectors in RAM, but I've
seen many techniques to accomplish it.
How do I know then to remap the memory? I'd
imagine it's done by the
monitor program, but I seem to recall that it was a hardware-only
solution. Have to find the article (German c't magazine's "Kat-CE" I
think it is).
"Know" is a difficult question to resolve. In the case of the Amiga, the
ROM code does some very simple checks for things (like ROM signatures,
IIRC) then jumps from "low ROM" to "high ROM" before banking out
"low ROM" and letting "low RAM" shine through (some Amigas have RAM
in the middle, so called $C000000 RAM, so their maps are not contigious,
but it's a complex design to be sure). For embedded stuff I've done, I've
seen it rigged up so writes to "low ROM" really end up as writes to underlying
RAM, so you just copy a routine then push ROM away and fall into RAM,
or you jump to some previously established init routine in "high ROM" and
use an I/O register to whisk away low ROM. Later designs I've seen
keyed off of A23 for a "registerless" solution - but your init code in low ROM
had better be doing a jump as the first access above $8000000 or I can
see bad things happening.
Also, are there any grave disadvantages in leaving the
ROM at address
$00 and using a jump table in RAM for the interrupts?
Speed. More code to execute between the initiation of the interrupt and
the beginning of the real ISR. Also if you are a _real_ speed freak,
as Henk mentioned, you can treat the bottom 64K as a sort-of zero
page and run with 16-bit pointers to spend less time setting up registers
and such, keeping your code size smaller and your execution times
slightly lower if you have RAM at the bottom.
I am getting more and more tempted to try and built my
own 68k SBC.
Being born in '84 it seems I missed out on all the interesting computers...
If you got your start after age 10, the Wintel monoculture was already
well established. Fortunately, there are many, many existing "interesting"
machines to study, and plenty of ways to emulate them in hardware or
software or both.
-ethan