S100 Computers

Home S-100 Boards History New Boards Software Boards For Sale
Forum Other Web Sites News Index    
An S-100 80386 CPU Board.
Final Prototype 80386

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 unknown layout.

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 mode.

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 Z80, 6502, 8088, 8086, 80286 and 68000 CPU S-100 boards,  I felt the time was now right to tackle an 80386 S100 board.

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 80386.

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 three phases:-
   1   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.
  2 Build a ribbon cable connected S100 daughter RAM board utilizing very high capacity static RAM chips  (16M chips).
  3 Build the same type of board utilizing very high capacity DRAM SIMMS  (1GB 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
The picture 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.

80386 Prototype #1

The top connector pins to hook up the daughter board cable is not yet implemented.   The original 80386 schematic for this board can be seen here.  Before discussing the board in detail it might be useful to review the 80386 pins in detail.

Address Lines
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 downloaded here.

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:-
  Address Lines A0+A1
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:-
  Upper PROM Address
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, t
his also conveniently gets around the 16 MB address space limitation of the S-100 bus.  

Data Lines
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 8086 & 80286 boards). It has proven to be a reliable circuit. Here is the circuit used on this 80386 board:-
  Data Lines
It turns out that it is important that U78 is a 74LS244 (and not a faster 74F244) however.

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:-
  Control Signals
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 have not 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. 
  Delayed pWR
  Write Signals

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.
A 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 here.

 Prototype 3
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 fit everything. 

A 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 here.
  Prototype V4
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 here.  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.

 Final 80386 Prototype
Address Pipelining
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 fine.

RAM Boards.
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 boards. See 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 ints.

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:-
  Clock Schematic   Clock Table
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:-
  New Clock Picture
This board is now being fabricated as a new prototype board.

Under Construction
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 Slave Controller
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 utilized.


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 8088, 8086, 80286 & 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/O port.

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 Disk Controller-->80386-->z80.


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 multi-step process. 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 80386 Monitor 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 potentially useful.

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

We are 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:-  lynchaj@yahoo.com

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.

The Intel 80386 Hardware Reference Manual

MOST CURRENT 80386 CPU BOARD SCHEMATIC  (V3.9, Prototype, 12/25/2013)
MOST CURRENT 80386 CPU  BOARD LAYOUT   (V3.9 Prototype, 12/25/2012)


MOST CURRENT 32MG STATIC RAM DESCRIPTION   (V1-3 Prototype, 4/15/2013)
MOST CURRENT 32 MB MEZZ BOARD SCHEMATIC  (V1Prototype, 10/27/2013)
MOST CURRENT 32 MB MEZZ BOARD LAYOUT  (V1 Prototype, 10/27/2013)

Other pages describing my S-100 hardware and software.
Please click here to continue...

This page was last modified on 02/21/2014