An S-100 80386 CPU Board.
I am only
aware of one commercial S-100 80386 CPU board. It was advertized by Macrotech in 1998.
Few (if any) of these boards were ever produced because the company folded
at about that time. I have no further information about it. No
schematic was ever published, worse the board had almost a dozen PALS of
This was unfortunate because the 80386 for a number of years represented the
apex of microprocessor development for Intel and indeed for microprocessors
in general. It is still to this day a very popular CPU in stand alone
powerful dedicated systems. The 80386 is a true 32 bit CPU with 4GB
RAM addressing capability and tremendous protected and paging mode power.
Yet at the same time upon a hardware reset it starts off in an 8086 like
I have for a long time dreamed of having my own 80386 S-100 computer where I
had complete knowledge and control of all the hardware and could bring up not
only MSDOS, windows but Linux or my own software starting with my own EPROM
BIOS. Spurred on by our success with
68000 CPU S-100 boards, I felt the time was now right to tackle an 80386 S100
Shoehorning a powerful chip like the 80386 into the S100 bus has a number of
unique challenges. First, many of the CPU status and control signals of
the earlier Intel CPU's now have quite different timing parameters (or are simply
absent). These will have to be synthesized to work with standard S-100 IEEE
like boards. Second the sheer number of address and data lines
required to interface the chip taxes the real estate available on an S-100
CPU board. However the biggest challenge is the fact that the 4GB of
RAM that the CPU can address can be up to 32 bits wide. The S-100
bus itself is only an 8 or 16 bit wide data bus. Fortunately the 80386 has a
special pin (BS16*,C14) that will force the CPU to talk to the data bus only in 16
bit wide data bits at a time. 32 bits of data is sent/received sequentially
as two back to back 16 bit packages. A further limitation is the fact
the S100 bus has only 24 address lines limiting its RAM capacity to 16 MB.
While decent for early DOS like programs, is far below the capacity of the
To cut a long story short, I decided to utilize the S-100 bus for "low"
RAM addressing with 16 bit capability but to have a 32 bit data and address
bus ribbon cable at the top of the board connecting the CPU to one or more
"daughter" boards. These boards would sit in S-100 bus slots for power
and a few other signals but would communicate directly (and only) with the 89386
pins. All 80386 I/O and interrupt signals go through the S-100 bus to
the other S100 boards as does 80386 RAM/PROM access to (a switch
configurable) amount or low RAM. All other 80386 RAM access is via the
special "over the top" ribbon cable bus to one or more daughter boards.
One nice thing about the AMD 80386 CPU's is the fact that the clock speed
can be varied (all the way from 0 to their max rate). This BTW is not
the case for the Intel chips. The second trick I use is to
have a different CPU clock speed if the S-100 bus is being utilized
(currently 12 MHz) and a much faster clock speed for the daughter RAM
board(s). These we will run at the maximum CPU clock speed, 33MHz
currently. Since the 80386 will spend most of its time in high RAM it
will be able to run code very fast.
Finally because Gigabytes or DRAM these days are so common and cheap, and
far exceed the capacity of static RAM chips, it makes sense to stock the
daughter board with common DRAM SIMMS and use a dedicated DRAM refresh
controller to maintain them.
All this sounds simple and great in theory. Putting it into practice is
another thing. With Andrew Lynch we decided to tackle this program in
Build and debug Master/Slave S-100 80386 CPU board such that it is completely
self-contained and can run MS-DOS in the system on the S-100 bus.
Build a ribbon cable connected S100 daughter RAM board utilizing very high
capacity static RAM chips (16M chips).
Build the same type of board utilizing very high capacity DRAM SIMMS
Currently this page is a status report. This is by far the most
challenging S-100 board undertaking Andrew and I have started. I will detail
things as we go along and welcome comments and suggestions along the way.
The First S-100 Bus 80386 Prototype Board
below shows our first prototype board. Extra chips ware added to the board
to allow considerable experimentation to get the board to work in the
S100 bus along with the many other boards available.
The top connector pins to hook up the daughter board cable is not yet
implemented. The original 80386 schematic for this board can be
here. Before discussing the board in detail it might be useful to
review the 80386 pins in detail.
The address lines of the 80386 (all 32 of them) are fairly standard there are just more of
them. Unlike the later 80486, they have limited drive capacity and
except for small dedicated systems need drivers. Since we will be
driving potentially up to 20 other cards in the S100 bus and one or more
daughter RAM boards, we will clearly need 74LS244's or 74F244's.
Because the 80386 can address bytes (8 bits), words (16 bits), or double
words (32 bits) there is no address line A0 and A1. Instead there are 4
"Bank Enable", lines BE0*-BE3* that select byte word or double word
memory access. I'm assuming that you understand this concept if you
are reading about a CPU of this complexity. If not there are countless
descriptions/illustrations on the web. While on this topic, if you
will be interested in later building a board like this you should get one of
Barry Brey's "The Intel Microprocessors" books. There are many editions,
the later the better. I have the 7th edition.
Another essential reference is the Intel 80386 hardware manual. It can be
As in the case of the earlier 8086 and 80286 CPUs (which had only one "BHE"
line (and A0)) , we will need to generate address lines A0 and A1 for the
S-100 bus. Intel suggested the following circuit:-
We have two other requirements. We will need circuitry to determine if
the 80386 is addressing RAM due for S-100 bus access or daughter board
access. We use our well tried 74LS682
circuit to determine if the current address is above a certain value (set
with a switch). If it is the 80386 essentially ignores this board and the
S-100 bus RAM and communicates directly with the daughter board .
Normally the trigger point would be at the 1 M or 16 M boundary (FFFFFH or
FFFFFFH). This correspond to the top of an 8086 address space or the limit
of the S-100 bus itself.
Here is a schematic for this circuit:-
The all important S100_SEL signal directs all access traffic on the board.
It also adjusts the CPUs clock speed. It's very important this signal
is clean and fast.
The second "complication" we have on the address lines is something we first
utilized on the 80286 board. The 80386 always starts at
FFFFFFF0H upon reset. This is at the
very top of the CPU's 4 GB memory address space. In contrast, the
8086 starts at 0FFFF0H (at the top of its 1 MB address space). It's
usually convenient to write one BIOS/Monitor for both CPU's. We play a
trick on the 80386 in that whenever its top 12 address lines are all high
(only at the top 64K of the 4GB address space), these 12 address lines in
hardware show up as all low on the S-100 bus. Thereby an 8086 BIOS/monitor
ROM can be utilized. A two line to one line converter (U95, a
74LS157) is used to accomplish this in the following circuit:-
With K11 jumpered 2-3, when pin 1 of each 74LS157 is low (Address lines A20
-A31 are all high to U6) the "a" inputs (GND) are passed through to the "Z'
outputs. When pin 1 is high the normal 80386 lines are passed through
to the "Z' outputs. BTW, this also conveniently gets around the
16 MB address space limitation
of the S-100 bus.
This is where things start to
get complicated. Data to/from the 80386 can be up to 32 bits wide. However
it can also be 16 or 8 bits wide and unlike the 68000, can start on
any 8 bit
memory boundary. Address lines are numbered A2 - A32 with
special lines (called BHE0, BHE1, BHE2 & BHE3) to select 8, 16 or 32 bit
access to RAM. This is like the BHE/A0 lines of the 8086 for high and low bytes
of a 16 bit access except this time there are 4 possibilities. Now the
challenge here is to convert these signals into an S100 SXREQ* signal and
generate A0, and A1 and deliver the data to the appropriate RAM location.
The circuit described above generates these signals.
Again these lines need to be clean and fast. The good news is they are not needed
for the RAM daughter board. That board can talk to the 80386 directly.
The actual circuit we use to deliver the 8 or 16 bit data to the S100 bus
is, the by now, well worked out (see the
80286 boards). It has
proven to be a reliable circuit. Here is the circuit used on this 80386
It turns out that it is important that U78 is a 74LS244 (and not a faster
The Control Signals
The control signals of the 80386 are quite different from the earlier Intel CPU's.
While intrinsically far simpler, we have to emulate those of the S-100 bus.
The trick is to utilize ADS* as the start signal for each bus cycle.
We latch the CPU M/IO, R/W, C/D signals with a 74LS75 with ADS and
then decode them with a 74LS138. Each of the output pins of the 74LS138
contains a single control signal. These are combined to generate the
appropriate S-100 signals. The following circuit does the job:-
The only difficulty with the above circuit for the S-100 Bus is that the pWR* signal comes
up too early and stays too long. On some S-100 bus RAM cards the address lines
yet "settled" or it hangs around after the RAM memory select
address is valid. After trying a number of things I found the most
reliable way to correct this problem was to synthesize our own pWR*
signal one clock cycle later and end it before the address lines changed
with the following circuit.
This turned out to be very reliable and is largely clock speed independent. Allowing
for a 24MHz 80386 CLK2 clock and a 12 MHz S-100 master clock.
Much to my relief the interrupt INTA signal worked reliably without any
modifications using an 8259A Interrupt controller on our
MS-DOS Support board.
The board modified to conform to the above circuitry has proven itself quite
reliable using five I/O wait states for both RAM and I/O and INTA cycles on
the S-100 bus at the above speeds. I hope minimally to be able to run
the future DRAM daughter board(s) at these speeds with no wait states.
Second 80386 CPU Board
Learning form the first above prototype board we made a second prototype
board. Here is a picture of this board. The schematic can be seen
Many of the jumpers
present on the first board were removed. They were there to "try out"
various circuit arrangements but are now no longer needed. The basic core
control circuits still remain as shown above. As I experimented with the
board it was quite clear that the key signal still remains the pWR* on the
S-100 bus. I tried delaying, speeding up and extending the signal but in
every case the circuit shown above seemed to work best. This is
frustrating because I still feel the signal is too short, bring the board
down to this lowest common denominator.
Nevertheless the board works very reliable in a 10 slot S100 system with a
clock (CLK2) of 24MHz and a bus clock of 12MHz. In my larger 21
slot system I can not get it to this speed. It is however 100% reliable with
a 20MHz clock. (The next lowest oscillator I currently have. I have ordered
22MHz oscillators). In both case only one Memory and I/O wait
state was needed.
One reason for the second prototype board was to see if we could fit
connections to the daughter board connector. It's crowded but we could
Third 80386 CPU Board
Learning form the first and second above prototype boards we made a third prototype
board. Here is a picture of that board.
The schematic can be seen
This board worked fine with up to 16 MB of RAM in the S-100 bus with a
32 MHz CPU clock input (3 I/O & PROM wait states).
However when I connected
up the static RAM daughter board via the top connectors/ribbon cable, there
were problems switching the clock speed from 8 to 32 MHz when one started
accessing the static RAM on the daughter board. See
8MB Static RAM Board and
32MB Static RAM Board for more information about these boards.
The Final Pre-Production Run 80386 CPU Board
The problem of switching the CPU clock frequency when accessing the
daughter RAM boards was fixed by adding a circuit to make sure "runt" CPU clock cycles did not occur
when the CPU clock frequency was changed.
Learning form the above three prototype boards (and two prototype RAM
boards), we made a fourth prototype
board. Below is a picture of that board. The schematic can be seen
The board fine tunes and corrects some minor errors in the previous boards.
It now looks like a remarkable simple and clear interface to the S-100 bus.
Simpler in fact than our previous 8086 or 80286 boards. The 80386 does not
require a separate bus controller of clock generator for example. Also
the control signals are consistent and simple.
Note in all cases I have used the AMD 80386 CPU chips. I chose these
because the clock in the AMD can actually be reduced to 0 and restarted. The
ability to change the clock frequency "on the fly" is important here because
the clock speed for RAM and I/O access to the S-100 bus is dynamically
halved to that of the RAM on the daughter board. The original Intel
CPU had a minimum clock frequency requirement. I have not tested the
ability to change its frequencies in mid stream. AMD CPU's are common so
this should not be a problem.
I have not really checked this board out with a wide range of old S-100 bus
RAM boards. As best I can tell it should run with any IEEE-696 that
has 16 bit R/W capability. It works fine for example with the
Godbout 128K static RAM and
BG Computers 256K Static RAM boards. It will not work with 8 bit
only RAM boards and I doubt with older S-100 bus DRAM boards. I really
recommend the board be run with our fast
4MB Static RAM board.
With the 80386, the timing of the address lines and status outputs can be
controlled so the outputs become valid before the end of the previous bus
cycle. This technique allows bus cycles to be overlapped and is called "Pipelining".
Address pipelining increases bus throughput without decreasing allowable
memory (or I/O) access times. Pipelining is controlled by the
status of the CPU NA pin . High = pipelining off, Low = pipelining on
(Jumper K2 on this board). Because pipelining is turned off for 16 bit
data access/conversions it will be ignored for S-100 bus access.
However for our extended memory boards it can be utilized and makes a real
difference. BTW, I find it best to turn off pipelining if you are
testing memory boards in an extender card connected to the CPU board in the
bus with two 8" ribbon cables. For the normal 1" connectors it is
In order to really utilized the full power of this CPU you need more memory.
This is a work in progress. Currently we now have two prototype Static RAM
8MB Static RAM and
32MB Static RAM for a full description of the 80386 daughter RAM boards to use
with the above CPU board. Later I hope to build a very high
capacity DRAM board. To run this board with MSDOS and our
MSDOS-Support Board its
essential that U6 on that board be a 74F244, otherwise you will get false
Using a Cyrix 80486 CPU.
The 80486DLC was Cyrix's first serious entry into the mainstream X86 market,
and made possible many people's first taste of 486 performance.
It was introduced in 1992 and was 100% pin compatible with the Intel/AMD
80386. The 486DLC can be described as a 386DX with the 486 instruction
set and 1 KB of on-board L1 cache. It does not have a math coprocessor
however. I managed to obtain off eBay a 33MH version and popped
it on the board. I found that the board could not attain the
32MHz of the AMD 80386-40 chip but worked fine at 27MHz (the next lowest
oscillator I happen to have). Interestingly however even at 27MHz
it ran MSDOS software about 10% faster than the 80386 chip at 32MHz.
I later switched to a 40MHz rated Cyrix chip. Whit this chip I could achieve
a 40 MHz Oscillator/speed.
Here is a picture of the board with the 80486DLC chip:-
Changing the CPU Clock Circuit.
It became quite clear that the clock circuit is critical to
obtain a reliable board at high speeds. Unfortunately setting an input
clock frequency for an 80386 is complicated. First the 80386 requires its
"CLK2" input signal to the CPU be exactly 2X the speed the basic bus clock
signal. Almost no slew/delay between the two clocks can be
tolerated. Both of these signals (typically used in extended
RAM/Protected mode), are several times the maximum frequency the S-100 bus
can tolerate. The latter typically being 10-12MHz. Now it would be
nice if we could have a separate clock/oscillator for the S-100 bus Phi
signal, so when the 80386 uses the S-100 bus it switches over its CLK2
signal to that clock. The problem with such an arrangement is
that because the clocks are not synchronized, "runt" clock signals can occur
depending on the time clock switching takes place. I spent
quite a bit of time utilizing circuits that allowed clock switching without
shortened/runt cycles. I could not get one that acted reliably.
In the end I decided to work from a single board clock signal and divide it
down as needed. This places some restrictions on what frequencies are
optimal. In particular you have to determine if you want an optimum speed
for S-100 access or extended RAM/Protected Mode access. Again, after
trying a number of circuits I decided on the 74HCT93 chip. This chip
contains a divide by 2 and 8 series of FF's. It is somewhat flexible
and also is pin compatible wit a few other signal divider chips. Note the
74HCTxx choice, the 74LSxx chips are quoted for speeds only up to
30MHz, the 74HTC93 can get to at least 50Mhz. (I could not find 74S, 74F or
even 74ALS varieties of this chip). A single chip with jumpers contains the
circuit nicely. See here:-
I tested this arrangement using a "dead bug" upside down chip patch to make
sure the circuit was reliable. It was, I could get to
using a 40MHz oscillator with both the 80386 and Cyrix 80486 CPU's.
Here is a picture of the modified board:-
This board is now being fabricated as a new prototype board.
Running the 80386 Board in a
Multiprocessor S-100 Environment.
This S-100 80386 board can be configured for the S-100 bus is a number of
different configurations of increasing complexity.
Let me first caution you that some of the above configurations are somewhat
complex. Not only in terms of hardware but also in terms of software.
Particularly if the system is utilizing interrupts. I would recommend #4 for
example, only for seasoned individuals.
The 80386 CPU is the Bus Master Calling a
It is important to understand how the IEEE-696 protocol handles multiple
CPU's (or DMA controllers) on the S-100 bus. In a system with
one bus master and a second (slave) controller the slave device can request
access to the bus by lowering its S-100 HOLD* line (pin 74).
In this situation (case #2 above), after a reset and prior to this request, the slave
controller is not visible on the bus. Its address, data, status and control
lines are all tri-stated (inactive). When the master CPU is ready to
release the bus, (and only then), it will return back an acknowledge that it
will do so by raising the S-100 HLDA line (pin 26). Then timed by the
bus master clock Phi signal (pin 24), the master controller will go through
two S-100 special clock cycles XFERI and XFREII. In the XFERI
phase, the master controller disables its address, status and data lines. At
the same time the slave activates its control
lines. For a brief moment (one Phi clock cycle), both the master and
slave controllers are driving the S-100 bus control lines (pSync, pWR*,
pDBIN an pSTVAL*). That is why BTW, on CPU boards these lines have a
10 ohm resistor to the bus so as not to overload the bus drivers.
Next, for the XFERII phase, the master controller releases its control lines
and the slave activates its address, status and data lines. This whole
process happens very fast. However it is a very ordered process with no
lines left temporally hanging in the process.
When the slave controller is done, it hands controller back to the bus
master in exactly a reverse of the above process.
Here is the relevant section of our 80386 board that carries out the above
process (The 80386 is assumed to be the bus master in this case).
The HOLD* is lowered by the external requesting slave controller. This
is clocked high into the 80386 via U98A, pin 6.
When the 80386 is ready, it returns HOLDA high
into U63B pin 3. This is returned to the S-100 bus via U79D (pHLDA*) low.
U63B pin 4 is clocked out of U97B pin 8 (high), which goes to the board
XFERII line (K10, pin 4), raising it, (thereby inactivating the 80386
address+data+status lines). This same signal is clocked into U97A pin
2, and its output goes to the board XFERI line (K9 pin1). This
inactivates the 80386 control lines (to U55).
On the corresponding slave controller (not shown here), during the XFERI
phase its S-100 control lines are activated.
During XFERII its remaining address+data+status lines are activated.
What is a bit confusing is the XFERI & XFERII terminology for the master and
slave is the same, but the order of the address+data+status lines and
control lines activation/inactivation is different. At a mid-point in
the process however both boards are briefly driving the S-100 control lines.
This way no unexpected "glitches" occur.
Another CPU is the Bus Master Calling
our 80386 Slave Controller
For the case where another board is controlling the bus after reset and our
80386 (as a slave) requests temporary control of the bus (case #3 in the
list above) the process is different and the board circuit below is
We activate the slave board by lowering any one of the four S-100 DMA lines
(DMA0*, DMA1*, DMA2* or DMA3*). The board actually has an S100 I/O
port (EDH or DDH) that also allows you to do this directly simply by
inputting from this port. In any event the input to pin 1 of
U50A goes low. This is clocked by U53A which lowers the S-100
HOLD* bus line (pin 74). This signals to the bus master (usually a
Z80) that it wants control of the bus. At the same time via
jumper K9-3, the XFERI line is lowered, activating the boards control lines
to U55. As described above meanwhile, the bus master is inactivating
its adderss+data+status lines. One clock cycle later, via
U53B the 80386 boards own adderss+data+status lines are activated. One clock
cycle later via U57A and U59A the reset line to the 80386 CPU is released
allowing the CPU to control the bus.
Note that while we call the second CPU above the slave or temporary
controller, there is nothing temporary or short time about it. Once transfer
is given to the slave controller (the 80386 in our case) it has control of
the bus as long as it wants. All day if necessary!
Transfer is given back to the bus master by inputting again from the same
port reversing exactly the sequence of events described above.
While probably not needed, in theory the S-100 bus could have up to 15
possible slave controllers, indeed more, if onboard port activations are
used. Thinking ahead with long term multi-board layout plans I have
decided that I will always assign DMA0* to the
80386 family of CPU boards (using one
in the bus at a time). Likewise I have assigned the DMA1* line
for the 68000, 68010
and any future Motorola CPU's. This leaves the DMA2* and DMA3*. This
in the future, in combinations, would allow up to four other slave
controllers on the bus. I will be doing a DMA controller board
in the future that will utilize these lines. Note however that because
our boards also have an "activation" ports on board there is no limit to
number of slave controllers in the bus. For example while our
6502 CPU slave board
could be activated by lowering DMA2*, it can also be activated via its own
I should point out the IEEE-696 specification actually goes further than
this. It allows the 1+15 Controllers to on the fly, prioritize
which one has the bus at any one time by giving each board a priority number
(4 bits, via a switch). See page 258 of the Sol Libes and Mark Garetz
book Interfacing to the S100 Bus for example. The problem
with this approach is the software overhead becomes very complex. Minimally
you would have to have a general circuit to read the status of the DMA lines
as well as a number of processor specific routines to handle randomly
striking interrupts etc.
With the approach I have here things are somewhat less complicated because
the port calling program always knows the status of the CPU/DMA controller
it is working with.
Another CPU is the Bus Master Calling
our 80386 Slave Controller
An extension of the above case where
our slave 80386 board (already in control) has a request from another
controller for (temporary) control of the bus. This is case #4 above.
There are two ways to handle such a situation. In the IEEE-696 mode you
would give the new controller a higher DMA priority number, this would
inactivate our 80386 board, the new controller would do its thing, release
the bus and the 80386 would reboot as described above. Doable for sure, the
only thing is on our boards the CPU's come on starting from a reset state.
With software flags etc this could be overcome. I decided
an easier way is to use two of the S-100 unused lines NDEF1 (pin 21) and
NDEF3 (pin 66) and a type of secondary set of HOLD* and HLDA lines.
We will utilize the following circuitry on our 80386 board.
In this situation the 80386 is in active slave mode, so HOLD* is low and
pHLDA is high (see above). Now when another controller wants to
but in charge (typically a DMA controller for a video board or disk
controller) it will pull NDEF1 low. This signal is clocked through
U98A, eventually raising the HOLD signal pin of the CPU (K13,3).
When the 80386 is ready, it will raise
its HOLDA pin and the input pin 3 of U63B. The acknowledge is sent
back to the requesting DMA controller via a raised NDEF3 S-100 line.
Meanwhile U63B pin 4 is clocked out of U97B pin 8 (high), which goes to the board
XFERII line (K10, pin 4), raising it, (thereby inactivating the 80386
address+data+status lines). This same signal is clocked into U97A pin
2, and its output goes to the board XFERI line (K9 pin1). This inactivates
the 80386 control lines (U55). You will note this sequence of events
is exactly the same as for when the 80386 is a bus master (case #2 above),
however instead NDEF1 and NDEF3 lines are used.
Again remember the new DMA controller can remain as long as it likes on the
bus. When done it hands control back to the 80386 which in turn later
can hand control back to the S-100 bus master.
A typical configuration might be:- Z80-->80386-->DMA
An 80386 ROM MONITOR
To really enjoy working with the 80386 you need to be able to utilize the 32
bit capability of the chip. First you need a ROM based monitor. To get
started with this I modified extensively the software for our old "8086 Monitor" to
accommodate the 32 bit registers of the 80386. Again it was a
First, simply utilizing the memory addressing and 32 bit registers of the
80386 in real mode. Then adding code to switch the CPU into its protected
mode. This is a fairly complex and specialized process. It
requires considerable time and reading. See
for a complete description of this process. From there you can download of the 80386 ROM based monitor
for the above board. With this monitor in protected mode you can
display all the CPU's registers, single step, check interrupts (soft, and in
hardware) and examine RAM anywhere in its 4GB address space etc.
Note the 80386 CPU board can be configured as either a bus master or bus
slave. In the former case it comes up immediately after power on/reset
as the bus controlling CPU. As a bus slave it lays dormant until
activated by (typically) a Z80 CPU. For the real hardware die hard's
there is even circuitry on the CPU card to allow one to use bus DMA in slave
mode (U97,U98, K13 etc). This is not an IEEE-696 specification but
When the final production boards arrive. I will provide basic step by step
assembly and testing construction notes for the board as I have done for
other boards. I
would like to point out however that this is a complex board. If you have
not built some of our other CPU boards I would recommend you first start
with our 8088 board.
now collecting the names of people that would like to get their hands on this
fairly sophisticated board set. If you have an
interest in such a bare board, let Andrew know via e-mail at:-
The links below will contain the most recent schematic of this board.
Note, it may change over time and some IC part or pin numbers may not correlate
exactly with the text in the article above.
80386 Hardware Reference Manual
CURRENT 80386 CPU BOARD SCHEMATIC
(V3.9, Prototype, 12/25/2013)
CURRENT 80386 CPU BOARD LAYOUT (V3.9
MOST CURRENT 8MG STATIC RAM DESCRIPTION (V2 Prototype, 4/15/2013)
CURRENT 8MG STATIC RAM DAUGHTER BOARD SCHEMATIC
(V1-3 Prototype, 4/15/2013)
CURRENT 8MG STATIC RAM DAUGHTER BOARD LAYOUT
CURRENT 32MG STATIC RAM DESCRIPTION
(V1-3 Prototype, 4/15/2013)
CURRENT 32MG STATIC RAM DAUGHTER BOARD SCHEMATIC
(V1-3 Prototype, 4/15/2013)
CURRENT 32MG STATIC RAM DAUGHTER BOARD LAYOUT
CURRENT 32 MB MEZZ BOARD SCHEMATIC
CURRENT 32 MB MEZZ BOARD LAYOUT
Other pages describing my S-100
hardware and software.
This page was last modified