Home S-100 Boards History New Boards Software Boards For Sale
Forum Other Web Sites News Index    

The S-100 Bus FPGA V2 Board.     
  V2 FPGA Board

The original S100 bus FPGA board has proven to be a very useful development board.  The board can be morphed into many functions.  If you are not familiar with that board it is essential you read up on that board before going any further here.  Much of what is written here assumes you are familiar with the "V1" board.  There also is an introduction to FPGAs and how to program and use them.

This "V2" board is an extension of the original board.  All the board chips are the same and in general much of the software is the same so a switch and replace should be easy.
That said, this V2 FPGA board has a number of useful enhancements.

1.  A set of four 8X2 pin "shield sockets" has been added to the board so that various separate FPGA shield mini-boards can be separately fabricated and used with the same board.  This is modeled on the Arduino Shields board concept.  Such simple 2 layer boards can be simply fabricated by any PCB manufacture.

2.  There is a prototype area on the board (as the was on the original board),  but now a
Arduino Uno circuit is also added with its corresponding Arduino Shields sockets.  This would allow one to interface the FPGA with an ATMEGA 328 CPU or run it separately.

3. Every usable I/O pin from the Cyclone IV FPGA is brought out to the "FPGA Shields Sockets".  Most are drive through 3.3V to 5V level converters. Some 8 are connected directly to the FPGA I/O pins and thus run at 3.3V levels.

4. Every major S100 bus line is interfaced to the FPGA I/O pins such that the S100 bus can be run as a bus master or bus slave.

5. A number of minor errors/improvements have been corrected. The principal change being  the removal of the two 74LS245 data bus drivers (U8 & U9) on the V1 Board. These were not needed -- even for a 21 slot motherboard.  The 74VLC245s appear to have adequate drive and fan-out capability. Also the S100 Reset signal (pin 75) can be brought directly into the FPGA.

The Board.
As for the V1 board, broadly speaking our first FPGA board will be loosely modeled on our Edison II board.  With programming,  this FPGA board can (in theory), be configured to behave as almost any S100 bus board. Either as 1970's legacy boards or our own recent S100Computers boards. 

One thing that actually takes a bit of time to realize is how programmable these chips are. As we will see below, even with every major S100 bus pin "taken care of"  in our applications,  we have not used up even close to 1% of the FPGAs total gates capacity.   The CoreEPC10 unit has a total of 244 programmable GPIO pins.  The Cyclone IV actually has more, but they are used on the adaptor board for programming, diagnostic LEDs etc.  With that number of GPIO pins one feels like a kid in a candy store.  Unlike situations like for example the Edison CPU board,  where one has to multiplex pins,  in this case we almost always can work with dedicated I/O pins.    These pins BTW can be configured as inputs, outputs or bidirectional.   Our first "application" will be to program the board to behave as a simple port I/O board.  Later we will work up to more complete situations where the board will act as a true CPU driven bus slave or indeed a bus master.    Yes, amongst the code libraries for the Cyclone IV are very powerful CPU libraries!  There require very complex FPGA coding, but again, it's all done for us as a "black box" which one can easily utilize.

Here is a very oversimplified diagram of the board layout.
  Board layout 

The board has four 2X8 0.1" connector sockets  to attach your custom FPGA shield boards. There is actual a small patch area on the board itself as well. As for the V1 board the shield boards may be used for any application you might come up with. At any time one has absolute control and access to any S100 bus line. In a bus master configuration it could be in fact be the only CPU in the S100 bus.  As for the V1 board this is a 4 layer board.

Here is the pinout for the FPGA Shields board.  Please make a printout of it and always refer to it during construction.
    Shields Pinout
Please note that while most of the pins are 'buffered" via the 74VSL245 level shifters (and run at 5 Volts),  a few however have direct connections to the FPGA I/O pins. 
These pins must never see a voltage greater than 3.3V.  Please use extreme care with this. You can blow out an FPGA I/O pin or the whole FPGA itself with voltages greater than 3.3 Volts. They all reside on the P11 connector. They are there primarily for bidirectional interface I/O pins.

Step By Step Building the FPGA Board
The build instructions are fairly simple for this board but because it is a complex board building it should not be rushed.  As always, first examine the bare board carefully for scratches or damaged traces, use a magnifying glass if need be.  A broken trace is almost impossible to detect by eye on a completed board.
Solder in all the required IC sockets, resistors, resistor arrays, capacitors, jumpers, and the Pololu 5V and 3.3V (LM3940) voltage regulators.  Do not add the LED's yet. Also do not add the MicroSD Card Adaptor. Be sure you put the resistor arrays in with the correct orientation of pin 1. Check their values before soldering (they are difficult to remove).  Insert all jumper arrays.  Note there are two sockets for the Pololu 5V regulator. While the older ones are still available, it seems Pololu is suggesting users use the D24V22F5's (5V, 2.5 Amp) units. 

The 3.3V LM3904 3.3V regulator requires the removal of two or three of the fins on the LHS to fit under the Pololu 5V regulator. Here is a close-up picture.  Use a Jameco #70658 heat sink.  This regulator does not get even warm, but I always like to use heat sinks. 
    Heat Sink
Please take care to not "slobber" solder on the sockets. They are very closely spaced on this board with vias often close to a socket pin - particularly for the FPGA adaptor sockets.
For prototype boards I generally use "double swipe" IC sockets. For a critical board like this I prefer to use "Machine Tooled" IC sockets.  However they are more expensive and you have to be particularly careful not to bend the IC pins.  The 2MHz clock oscillator can have its own special sockets (e.g. Jameco #133006) but actually I find the "Machine Tooled" IC sockets make a better connection.  I in fact solder the 2MHz oscillator (P7) directly to the board since it will never be changed.   Solder in the buzzer SP1 with the "+" pin on the RHS. You may wish to play around with the buzzer sound volume by replacing the 100 Ohm resistor R11 with a lower one say 75 Ohms or 33 Ohms to get a louder buzzer sound later. So solder it high on the board for easy removal.
Place the board in the bus without any chips inserted. There are two separate voltage rails on this board 5V and 3.3V. Carefully examine the schematic and check the voltage to the individual sockets are either 5V or 3.3V.    

Your system should boot and run correctly with its Z80 master CPU board. If not, you have a serious solder bridge somewhere on the board.  Before you do anything else with a magnifying glass go over every socket on the board and examine for proper solder joints. I like to "reheat" each joint just to be on the safe side. The silk screen/varnish on these boards us quite thick. It's easy not to have a good solder joint for the ground pins.  Double check.   Extra time here will save you hours later, (Been there, done that! ). 

There is one major construction decision you need to make with this board right at the start.   The WaveShare unit uses unusual 2 mm dual row pin connectors. Unlike to normal 0.1" connectors these are quite rare and expensive (Digi-Key #S5750-30-ND) .  If you solder these female sockets to the board the WaveShare adaptor sits quite high on the board and will prevent the next S100 bus slot from being used.  If you carefully remove the JTAG socket top border edge with a wire cutter - all around about 1/8 "  It will fit into most S100 bus motherboards without taking up two slots. Alternatively you can solder the adaptor directly to the S100 board. Of course removing the adaptor is all but impossible in this case.  The actual pins for the adaptor are unusual. You will need to cut the above DigiKey 60 pin socket with a wire cutter to the required lengths. Cut the pin past the required length and file the cut end plastic to clean things up. Don't rush this process. Its critical it sits correctly on the board. First solder in each socket at two points. Insert the FPGA adaptor, then solder all the socket pins.

Likewise  if you are using a specialized "Shields Board" you might consider soldering the connector pins on that board to the corresponding holes on this main board.  However in almost all cases we will use 8X2 connector sockets on the main FPGA board.

BTW, the KiCAD footprint for the FPGA adaptor board took me three prototype boards to get it exactly right. If you ever want to do your own board I suggest you start from this board. The large number of close pins allow absolutely no margin in the fitting. 

Programming The FPGA.
We will first program the WaveShare/Cyclone IV FPGA just to flash the 4 LEDs on the Waveshare FPGA adaptor board. For this all we need is the two above voltage regulators and the WaveShare adaptor attached to the S100 board. 

Launch Quartus Prime and load the Project Demo_01.qpf and then the actual program,
Demo_01.bdf.   All the .qpf and .bdf files we will use are supplied at the bottom of this page.  Typically you would make a folder:


It is very useful to have before you a printout of the FPGA board schematic and the WaveShare schematic in the steps below.  The latter for example shows the FPGA pins for the on-board LEDs. In all our programs its critical the correct FPGA pins are associated .bdf file pins.  Also make sure that Quartus Prime knows/assumes you are, (in this case), utilizing the Cyclone IV EP4CE10F17C8 chip.  Before going forward, now is a good time to take another look at the ClockFabrick Electronics Academy video.

First is the very simple
Demo_01.bdf program.  It simply flashes the 4 LEDs on the WaveShare adaptor board. There is no interaction of the other FPGA pins with the S100 bus circuits. Note the file Demo_01.sof resides in the output_files directory. Also be sure your device is a EP4CE10F17.
If you have watched this video,  the above
.bdf program is obvious and trivial.
Here is a picture of the relevant Programming Dialog Box.
    Programmer Dialog Box
The board only contains the 5V and 3.3V regulators and filter caps. Be sure you have 3.3V and 5V going to the appropriate pins on the Waveshare FPGA adaptor socket.
The actual compiling and programming process does take longer than you might expect (~30 seconds for the above).
Note a "virgin" Cyclone IV Adaptor board from WaveShare has the FPGA preloaded with a program (in the
EPCS16 Flash RAM) that already pulses the 4 onboard LEDs.
Before programming the board note the rate/order at which the LEDs flash.

Upload the Demo_01.bpf  project and load the
Demo_01.brf file and program the FPGA with the Demo_01.sof file. The rate/order of the LEDs should change. 
Power down and re-power up the board. The original WaveShare rate/order of the flashing LEDs should return. 
This is because so far, for now, we are just dumping the FPGA code into the chip (not the Flash RAM).

You must get the above
Demo_01.bdf program to work before going further.

Once you have assured yourself that your ability to program the FPGA is sound remove the WaveShare FPGA adaptor. 
Be very careful doing this. Leaver one corner at a time up a little going around and around.

Add the 10 LED's.
Before soldering them in place, and without the FPGA Adaptor, place the board in the S100 bus and ground the appropriate pins on the FPGA socket P6 to be sure they light up.    Be careful to stick a very narrow wire into pins  P6, 18-32. Also pin 18 of P7 (BOARD_ACTIVE).  Don't damage the socket pins. 

Next (carefully with a probe) jumper pin 12 of the U12 socket to ground and orientate the dual color (3 pin) LED in K2 so it shines
Green (not Red). 
Also ground pin 8 of P20 so the LED D10 lights up.
If all clear, then solder in and clip the extra wires of each LED.
(BTW, I always use a blue LED for D9 "Slave Active"  in my systems). 

Add back the FPGA Adaptor board and reprogram the FPGA with the above
Demo_01.brf program.
The D9 LED (
BOARD_ACTIVE*) should flash.

Next add U10 and U28.  Jumper the LHS FPGA Shields Connector P4, 7-8 (XRDY).   Jumper K1 2-3. K1 is under U17.

From your Z80 monitor display RAM

Your system should continuously scroll through your RAM display. 
With this process running, upload the
Demo_01.bdf program.
You should see the Z80 pauses and restart continuously as the S100 bus
XRDY lime pulses low.

While this is a very simple program it shows that your FPGA is able to control the S100 bus (via
XRDY).     This is important because you are using the U10 3.3V level shifter to activate the 5V XRDY line.

Next we will use our FPGA board to do something useful.  Again starting off very simple.   We will program the FPGA board to display on it 8 LEDs (D1-D8) the 8 bit value sent to the S100 bus I/O port
68H.  (Assuming port 68H is unused in your system. Use your Z80 Master  monitor "R" command to check)).

This will involve reading the S100 bus ports 16 address lines and the CPU's 8 bit S100 bus Data Out lines. When
sOUT goes high and pWR* goes low, the data to be displayed on the LEDs is latched.  There are numerous ways this can be programmed into the FPGA.  For simplicity,  I will use the 74xxx library approach in the .bdf file. 

The first thing one always has to consider is if the board is going to be considered a
SLAVE or MASTER bus board.  This critically defines the direction 74LVC245 level shifters to the S100 bus address, status and control lines.   We are clearly talking SLAVE mode here.  The FPGA will INPUT all these lines from the S100 bus and act accordingly.   This critical decision is set by the "DIRECTION" signal from jumper P21

LOW (Gnd)
DIRECTION = Slave Mode, S100 bus data from the bus to the FPGA.  (P21 jumpered 2-3, LED K2 Green, when U12 is inserted)
HIGH (3.3V)
DIRECTION = Master Mode, data from the FPGA to the  S100 bus.    (P21 jumpered 1-2, LED K2 Red, when U12 is inserted)

BTW, this
DIRECTION can be read on pin L16 of the FPGA if you need the information in programming the FPGA. 
For those more experienced, by jumpering K2 2-4, you can dynamically change the bus direction (
F_DIRECTION_SET, pin G16).  More on this later.

It is very important to appreciate that the boards bus level shifters (U7, U6, U5, U3, U4, U14 and U20 all 74LVC 245's) are directly connect to the S100 bus lines (on their 5V side).    These are powerful drivers.  You must always take care the their
OE* pin 19 is always HIGH unless you wish to interact with the S100 bus.   As you build your board below, always check that all their pin 19's are HIGH before adding the chip.  Fortunately all pins on the Cyclone IV are high on power up and before programming.  Carefully consider each 74LVC245s direction and OE* at all times. You do not want a bus conflict with your Z80 CPU boards buffers for example.

There are many ways a circuit could be programmed with the Cyclone IV and this board to write to an S100 I/O port.  Rather than be smart/elegant I will use a simple brute force approach.    This is one of the things you quickly realize using FPGA's is that there is almost endless supply of gates.  It is doubtful you will ever get close to using up the chips programming capacity, so you can afford to be "sloppy" duplicating circuits, overkilling "what if" scenarios etc.  You will find yourself laying down circuits that you would never consider on a 5"X10" S100 board with 74LSxx chips.  That said,  I cannot over-emphasize the importance of adding functionality one step/circuit at a time as you build your circuit.  Use the four onboard LEDs (L1-L4) of the WebShare adaptor board to flag/indicate your process.    Finally, I recommend you save your
.brf file (as a different name) as you step things along. That way if all fails, you can fall back to a previous version.  (Saved my neck several times already).

Quartus Prime is very powerful with almost endless options.  I do find it's somewhat "finicky" however with cut and past of circuits in your
.brf file.  Its best to add circuits from the top menus as you need them. 
Remove the above FPGA Shields Connector Jumper P4, 7-8 (XRDY).
Add U12 and be sure to have jumper P21 2-3 (
Slave Mode). 
Add U7, U6, U5, U4, U14, U20 and U17.  Place the card in the bus and check pins 1 & 19 of each chip is HIGH.  The LED K2 should be
U17 pin 19 will always be low and its pin 1 high.

Open the Project FPGA_Board_Port_Output_Test.qpf and the file
FPGA_Board_Port_Output_Test.bdf from the bottom of this page. 
If you have built any of our many S100 Bus boards in the past you will have no difficulty understanding the FPGA "circuit". 
Essentially the FPGA reads the bus address lines
A0-A15 and sends them to a pair of 74684 comparators.  If it detects a bus output (sOUT high) for port 68H it will send the eight S100 bus Data Out lines to internal latches which are read by the eight onboard LED's.
Here is the core
.bdf circuit.
Using our Z80 CPU board and its Master monitor to output to port
68H should set the LEDs. For example:-

As you can see the circuit is dirt simple. In writing programs/circuits like this you do have to be very careful that you assign the correct FPGA pin number to each signal. 
As mentioned above, always be careful with the 74LVC245
OE* pins.

Next will write a simple FPGA program to allow our Z80 to read a value from port 68H.
Add U3.  Again check pins 1 & 19. 
We will use the onboard 4 position dip switch
SW2 to define the upper and lower nibbles of the port data. 
This time open the Project FPGA_Board_Port_Input_Test.qpf and the file
FPGA_Board_Port_Input_Test.bdf.  The circuit is essentially the same as the previous one except this time we use the Z80 master monitor to input a value from port 68H.

QI68, 00110011

The core circuit is shown here.

You should always see the 4 bit value from SW2 in the upper and lower nibbles from your Z80 master monitor. If not don't go further until you resolve the problem.  For example enter the following Z80 code in RAM at 0H and jump to it.

DB 68
C3 00 00

Add LED "flags" (L1,L2,L3 or L4 on the FPGA Adaptor) at various points in the .bdf to see where the problem is for debugging.

Now let us combine the two circuits. We will have an output port and input port at
68H.  The circuit is essentially a combination of the two above circuits with some bells and whistles.  Load the Project Port_IO_Test.qpf and the file Port_IO_Test.bdf and program the FPGA.
In this mode when you output to port
68H in your Z80 monitor you should see the LED's display the correct Hex value.
When you input from port
68H you should get the same value back.


The FPGA Board as a Bus Master
Now lets move things up a notch in terms of complexity, lets configure the board to temporary
Master mode and have it control the S100 bus lines rather than reading them.  We will have the board act as a Temporary bus master (just like our many previous CPU boards such as our 8086, 80486, 68030 etc.).   Note this configuration is not for everybody.  Switching S100 bus control is tricky (see here), the vast majority of applications for this board will probably be as a bus slave. Nevertheless since the Cyclone IV has its very own internal Neos II CPU, a bus master role is interesting.

First we jumper P21 1-2 so
DIRECTION is HIGH (3.3V). The LED K2 should now be Red.  This way the 74LVC245 buffers U7, U5, U3,U4, U14 and U20 are outputting to the S100 bus.  Critically however, in every case the OE* pin is High.  (All FPGA pins are high on power-up). 

Add U11 and U16. Jumper the LHS FPGA Shields Connector P4 1-2 and P2 4-5. Add jumper JP15 for the buzzer.  Jumper P2 4-5 (TMA0*).

Next just as for our many other CPU boards,  we need a circuit to transfer control from the Z80 CPU board (the Bus master) to our new Temporary Bus Master on the S100 bus.  This process is explained in some detail here.  After reading that article the FPGA_Board_AddressLinesTest.qpf project and
FPGA_Board_AddressLinesTest.bdf file (see the bottom of this page), should make sense. Here is the key Master/Slave transfer circuit.  For simplicity we will generate a PHI clock of 1MHz.  (By changing the Clock PLL01_50 it can be anything up to about 10MHz).

The two above signals XFERI and XFERII are then utilized in the sequential transfer of control of the Z80 Address, data, status and control lines to the FPGA board.
The SMB actually requires a valid pSYNC, pSTVAL and pDBIN to latch the address lines into that boards HEX digital display. These are synthesized by the circuit below.
    Control Signals
To run this "program", boot up your Z80 and load up the FPGA code. Then transfer control to
TMA0 from your Z80 Monitor ("O"  command).  You should see the S100 bus Address lines and Data lines continuously change in value.  Please see the short video I made of this using the V1 Board.
As for the V1 Board, pressing the SW1 switch will hold the address & data lines. The buzzer should also sound.  Releasing the SW1 button and the count process should continue.
Please study and understand everything in the FPGA_Board_AddressLinesTest.bdf file before proceeding further.  It is essential that you understand ever aspect of that file before going further. From now on almost everything is going to be FPGA programming! 

Add all remaining IC's to the board. We will utilize the almost 60 spare pins of the Cyclone IV to adapt the board to our own custom circuits or old S100 Bus Board emulations.

Future FPGA Code/Configurations will be listed below.

Burning FPGA Code to Flash RAM
Up until now whenever we programmed our FPGA via  the JTAG socket the data is lost whenever the power is turned off.   While fine for code development etc. it is not desirable for a final board configuration.  Like most FPGA applications the "final" code is saved in Flash RAM and immediately loaded by the FPGA each time upon power-up.  This is a standard and common characteristic of most FPGA's. Some older models in fact had a ROM onboard.    Our Cyclone IV Adaptor board has 16MB of Flash RAM on board for this purpose -- way more than we are ever going to need!
The tricky part is programming this Flash RAM.  I found the documentation poor and confusing.  A summary of the process for the V1 FPGA board is described here. We do the exact same for this board.

The Arduino UNO section.
The central section of the patch area contains support circuitry to run a ATMEGA 328 CPU.  The four shield sockets have the same pinout as the Arduino UNO and that of our Mega 328-2560 Board. If you wish to use this feature please see the Mega 328-2560 Board page write-up.  There is sufficient space in the patch area to place a simple circuit. There are a number of spare pins on P61, P4 and P60 to allow a linkage with the FPGA.   Of course standard Arduino Shield boards should also work. 

Under Construction
Please come  back later. Below this point text is invalid.

V2 FPGA Board & Code Circuits.

This section, over time, will contain separate page links on this site to new FPGA code and board circuits using the above V2 board. There are now almost limitless examples of FPGA code in the public domain for most major digital electronic circuits. Two popular sites are OpenCores and fpga4fun. If you develop a useful FPGA application with this board please consider sending it to me, I will place it in this section.

      Board Circuit Name  (Click to Select)          Board Description  
  UART_PORT_V2   A simple UART port interface to the S100 Bus.  
   1602 LCD Display_V2    Interfacing to a dual line 1602 LCD Display Module 
    A VGA PONG GAME_V2   A simple VGA interface demo. 
    RAM_DEMO    A 4K OnChip Static RAM Circuit 
    PS2_KEY    A simple PS2 keyboard input port example 
    PS2_LCD    Display a PS2 keyboard input on a 1602 LCD Display 
    SPI INTERFACE    An SPI 16 bit Communications Interface to a Digital Potentiometer
    I2C INTERFACE    An I2C Communications Interface to an EEPROM
    SPI_INTERFACE V2    An improved SPI interface with 8, 16, 24, 32, 40 or 48 bits 

No known bugs at this stage. 

A Production S-100 Board

Realizing that a number of people might want to utilize a board like this together with a group of people on the  Google Groups S100Computers Forum, a "group purchases" is now open. Contact and join the group if you would like to be involved in this project.  Please see here for more information.
Please note the final verson of this board (V2.0b) differs very slightly in the placement of some of the components shown on this page. 

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.

Most current KiCAD files for this board         (V1.1a  Prototype zip  files  10/12/2018)
Most current Gerber files for this board       (V1.1 Prototype zip  files  10/3/2018)
Most current Schematic for this board         (V1.1a Prototype zip  files  10/12/2018)
Parts layout this board                               (V1.1a Supplied by Rick Bromagem  10/13/2018)
BOM for board (XLS File)                          (V1.1a Supplied by Rick Bromagem  10/13/2018)
BOM for board (.PDF File)                       (V1.1a Supplied by Rick Bromagem  10/13/2018)

Demo_01.zip    (V1.0  9/5/2018)
PortInTest.zip    (V1.0  9/5/2018)
PortOutTest.zip   (V1.0  9/5/2018)
Port_IO_Test.zip     (V1.0  9/5/2018)
 (V1.0  9/5/2018)

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

This page was last modified on 01/30/2019