Date   : Thu, 19 May 1983 16:57:00 PDT (Thursday)
From   : MMOON.ES@parc-maxc.arpa
Subject: Re: How to use Mem. mapping.

OOPS.  You will note that there is a 4k block of memory on that card, I
believe.
If so, you may place the memory management code in that block and option it as
"global" ram, i.e., it will reside in *each* 64k page.  If I am wrong you
will need
another card (surprise!) such as Godbout's System Support 1, which I *know* has
4k of ram which can be made global.  Note that using a block of global ram
means that you may have to option all your memory cards to have those
addresses permanently in tri-state, i. e., disabled, in order to avoid bus
contention.  This would definitely be true using the System Support 1, but may
not be the case if the CPU has the ram on-board; the CPU's internal address
logic
may allow you to switch this block in and out of memory on yet another port
and then disable the data-in buffers on the card while reading the on-board
memory; this effectively gives the on-board ram precedence when switched in. 
Take a long look at your owner's manual. 

A second alternative *does* exist, although it is extremely clumsy & may
require
hardware hacks (risky ones at that on your new toy; can void the warranty). 
Which board in your system handles boot-strap?  If another card in the system,
such as the disk controller has this job, you are sunk.  The CPU, since it
contains the port which handles the bank switching, *must* bootstrap the
system.  Reason is, the only other way to handle the vanishing code trick is to
have code in *every* bank in the system, at the same location, which picks up
the program and handles entry once the bank switch has been accomplished. 
This in turn requires, that the memory be initialized from a boot rom which has
instructions to transfer said code into a 64k bank, switch to the next
bank, and
repeat the operation until all banks have been initialized.  To do this,
the rom
must be the only *readable* memory in the system, at least until the boot
operation is complete.  This is easiest done by the CPU hardware itself,
in much
the same manner as described above.  Basically, at cold boot, the hardware
sets a
latch which disables the data-in buffers on the s-100 bus for all memory reads
when the rom is selected and concurrently allows ony the card's internal data
bus to be read.  The data-out buffers are still functional, memory external
to the
CPU is now "write-only" (no kidding) until some point after the bank
initialization when the rom program unsets the latch holding the data-n buffers
in tri-state. This latter can lead to the same problem if the last code address
executed from the rom is not physically contiguous with the first insrtuction
executed from ram after the latch unset.  This is beacause the latch unset,
will,
most other designs (JADE{ugh!} or QT), deselect the rom.  

Confused? stick with 64k & use ZCPR2; bank switching is a poor substitute for
real memory management.  Good luck.

               --MMoon.es