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

The S-100 Bus FPGA 80286 SBC Board.
Under Construction
   Stage3
 
Introduction

The original S100 bus FPGA board, "V2" FPGA Prototype board and FPGA Z80 SBC have proven to be a very useful development boards.  The boards can be morphed into many functions.  If you are not familiar with these boards it is essential you read up on the FPGA_Z80_SBC board before going any further here.  Much of what is written here assumes you are familiar with those boards.  There are also  introductions to FPGAs and how to program and use them.

We will now (again), move things up a notch and use the full power of the Cyclone IV FPGA. We will construct and program the FPGA to be a S100 Bus 80286 CPU board.  The board will act as a fully self contained S100 bus "Single Board Computer (SBC), somewhat similar to our earlier S100 bus Z80 SBC and 80286 CPU board-- but much more powerful.
The board contains:-

A "real' 80286 CPU and 80288 Bus Controller chip set.
An 80X40 line VGA character terminal with its own ROM character table and 4K graphics RAM
An FPGA internal ROM 64K 16 bit wide ROM containing the 80286 monitor along with diagnostics support for the SD cards.
An IBM PC PS2 keyboard input port (with input converted to standard ASCII)
A USB serial I/O port at speeds up to 38K to a PC
A "real" 8259A interrupt controller for onboard and S100 bus interrupts.
Two SD micro Card slots and an interface to boot MSDOS V4.01
A Parallel printer port with Strobe/Ack etc.
An 4 bit IOBYTE input port and 4 status LEDs.
There is an FPGA interface to the onboard clock/calendar RTC chip with battery backup.
The board has 1M of onboard 16 bit wide RAM that is addressable locally to the 80286
Onboard CPU Reset switch

While the board internally is quite complex,  externally it looks and behaves very simple. It will be an ideal board for somebody new getting into building an S100 bus system since with this board alone and a simple USB/FPGA programmer they can have a complete MSDOS system. Then gradually the user can inactivate various sections within the FPGA code and activate the corresponding old/new S100 boards they have in their system.   They can start off looking upon the FPGA as a black box.   In fact to get started you don't even need an S100 bus -- just hookup 8V to a jumper on the board and connect the onboard USB port to you PC system to act as a  TTY character terminal.

Keeping in mind the above potential audience, I will try and over-explain some things below.  Our "hard core" audience can just skip ahead.  That said,  this is NOT a board for a complete electronic novice. Minimally you should have some soldering experience and knowledge of electronic circuits.  You should for example be comfortable with web sites that describe Arduino or Raspberry circuits.  You should have a basic understanding what a Field Programmable Gated Array (FPGA) is. If not, look them up on web.  In summary, these chips allow you to lay down any circuit you might come up with within the chip just like you might do by soldering hundreds of TTL/74xxx chips together as in the old days.  Its all done in software. The resulting code/pattern is then programmed into the chip.

What Is Needed
The FPGA we will use here is an Altera/Intel Cyclone IV FPGA.  This chip is currently in about the middle range of the programming capacity of FPGA's.   The actual chip uses a "Ball Grid Array" method of soldering it to a printed circuit board.  This requires very specialized equipment, so normally one purchases an "adaptor board" for these chips with the chip on it.  Besides providing "normal" pin attachments to (in our case), the main S100 board,  these adaptors contain a number of voltage regulators, Flash RAM, a programming socket  and other components these FPGAs require to operate.

As for our previous boards we will use the WaveShare "CoreEPCE10" Cyclone IV board adaptor. Its schematic can be seen here.
    
  CoreEP4CE USB Blaster Adaptor Sockets 
   
The second thing you will need is a device to program the FPGA chip itself. 
There are many FPGA programmers available. I really like the USB Blaster (V2) that Waveshare sells.  Its simple and reliable.  And importantly, works directly within Intel's Quartus V12 (see below). The good news is; with this board you will not need to purchase a separate EEPROM burner, GAL programmer or CPLD programmer.

Somewhat unexpectedly you will need to pay particular attention to the special very tightly spaced pins on the above adaptor board.  Because there are so many FPGA output pins, its not practical to have a connector with the standard PC board 0.1" pin spacing.  The above WaveShare unit uses unusual 2 mm dual row pin connectors.  Unlike to normal 0.1" connectors these are quite rare an expensive.  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. 

Please note the 2 mm dual row pin connectors (Digi-Key #1212-30-ND sockets) for the WaveShare adaptor are quite tricky to fit on to the board.  I found the best way to do this (after trimming to size), is to push them half way on to the adaptor pins and then wiggle them to fit the whole unit on to the S100 board.  Figure on spending 10 minutes on this step!  Do not solder them to the board first and then try and press the adaptor down on them. They are very fragile and internally the leaves will bend if socket angles are not exactly correct.  When in place, check each pin is visible on the back of the board before soldering.  Only then solder all around.  Add as little solder to each pin as possible - the narrow pins have a tendency to wick up solder internally.  Better sockets are the Digi-Key #1212-1786-ND  100 pin sockets (carefully clipped to size).

The rest of the boards components are standard -- available from Jameco, Mouser, Digi-Key etc. 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 actual IC pins. 
 

Programming the Cyclone IV FPGA
As mentioned above, in order to actually implement a circuit the FPGA must be programmed.  During board development the code is passed to a Flash RAM on our adaptor board from which the FPGA has enough intelligence to load it from there and run.   This means that if we power down the board that code is lost and the chip has to be re-programmed.  As we shall see below' when one is satisfied with the code there is a separate process to burn it into the chip so it is not lost upon power up.  This is a slower process and so is not normally done.  You can however program by both methods essentially an infinite number of times. 

There are two major languages to program FPGA's Verilog and VHDL.

Verilog was created by Prabhu Goal, Phil Moorby, Chi-Lai Huang and Douglas Warmke around 1984. Originally, Verilog was only intended to describe and allow chip hardware simulation. The automated synthesis of subsets of the language to physically realizable gates etc. was developed after the language had achieved widespread usage. Verilog stands for the words "verification" and "logic". There were many upgrades/extensions over the years. The last major version appeared in 2005.

VHDL was originally developed for the U.S Department of Defense in order to document the behavior of the ASIC chips that supplier companies were including in equipment. Because of this background much of the syntax was based on the Ada programming language. The language has undergone numerous revisions and has a variety of sub-standards associated with it that augment or extend it in many ways, the last major release being in 2008.

Usage between the two tends to be polarized. Probably because of its ADA/Pascal style VHDL seems to be more popular in Europe.  The "C'" style syntax Verilog seems to be more popular in the US. 

With both the above languages you can write programs line by line just like is C or Java etc. Alternatively you can use a newer graphic diagram approach which in the background converts your graphic diagrams into Verilog or VHDL code -- totally transparent to the user.  This approach uses  a special file called a
"Block Diagram File" (.bdf) (for Altera/Intel chips). The whole process is somewhat like writing a web site page.  You can either write the whole page yourself in HTML or use something like I'm using here (Expression Web),  to "draw" a web page in blocks, graphics etc.

Again, usage between the two approaches by people tends to be polarized.  The good news is that within IDE's you can import and export modules for both types.  You can for example see/export the Verilog code that makes up a complex
.bdf module or you can convert a Verilog module into a .bdf module.

Coming from by now, years of experience using KiCAD to lay out over a 100 of S100 bus PC boards I personally found the .bdf approach of programming an FPGA very easy. Within a day or two I was up and running programming an FPGA with quite complex circuits.   This was possible because the Quartus IDE (see below), supplies libraries for things like all the common 74xx logic chips, many of the common VSLI style chips (e.g.. UARTs) etc. It contains many libraries of many extremely complex/useful modules such as CPUs.  While you can drill down for detail,  at a top level they behave as "black boxes". You just supply the wire or bus connections -- which you draw as lines.   It would take me months of learning to do the equivalent in raw Verilog code.  I will illustrate this below. 

BTW, there is one well known/subscribed source code site for FPGA's called OpenCores  where you will find an enormous list of FPGA projects/code.  There numerous other excellent FPGA code applications on the web. For example Javier Valcare's FPGA home page and fpga4fun.

Quartus Prime.
For Altera/Intel FPGA's the program of choice to program them is called Quartus Prime.  This a very large Windows based IDE interface. It is completely self contained with everything you need to write FPGA code and program the chips. Its an expensive software package. Fortunately Intel supplies a "Quartus Lite" free version for students and people like us.  Even this is way overkill for our use.  The most recent version can be downloaded from this Intel site.  The package will take ~20 minutes to install on Windows 10.  You may want to first review this video about the installing process. Please see the Notes section at the bottom of this page for more help installing Quartus.
 
Please keep in mind that programming an FPGA is different from the normal linear/sequential programming approach you may be used to.  On an FPGA everything is potentially happening at once.  Good FPGA programmers take years to excel and currently are in high demand.   Timing and power distributions across the chip almost become an art form.  Fortunately out needs will be far simpler.   Also there seems to be an excellent community of experienced people ready to help -- beginners.  I have found the Altera forum to be very useful and helpful.   However by far the best way to get started is to look at a few YouTube demonstrations.   

One outstanding YouTube video to get you going with Block Design File FPGA programming is this one by ClockFabrick Electronics Academy.  A text summary is provided here.  If you cannot get to that YouTube video you can directly view it in the video below.
Note, click on the "full screen icon" for easy viewing. Use ESC to return.   
Also please allow a few minutes for it to download.  It's a very large (50 minutes) video file.
         
 
 
  
For absolute FPGA beginners, rest assured,  you can more or less use the FPGA code examples below as "Black boxes" to get this board up and running. However you will be missing one major aspect of the board. By stepping along and understanding how the FPGA code works you will in the end have the ability to modify the board in amazing ways.

Before we start, a few things about our FPGA code file directory structures.   We will "build" our FPGA code in steps of increasing complexity. I have found out the hard way, that that you have to be very careful with Quartus where you place your files.  The actual Quartus "Project file" work 
80286_FPGA.qpf  should reside in the main folder you will build your programs. In my case it happens to have a path:-

C:\intelFPGA_lite\18.0\quartus\MyFPGAPrograms\80286_FPGA\Z80_FPGA.qpf

The above path (in yellow) is the root below which we will build all files in this project. Your path may be different but the 80286_FPGA directory must exist. The actual Z80_FPGA.bdf in this directory is our current "work file" which when compiled we use to program the FPGA.

You will notice in the download (see bottom of this page) , numerous
80286_FPGA1.bdf, 80286_FPGA2.bdf, 80286_FPGA3.bdf...... files.  these are the main 80286_FPGA.bdf file of increasing complexity as we add FPGA components/modules  to our board.  The file 80286_FPGA.bdf is always the most sophisticated and current file constructed. It will get more complex over time. 

In every case as we build,  we first "Close" the current
80286_FPGA.bdf file it within Quartus.  Note not the project file (80286_FPGA.qpf).
We then go outside of Quartus into windows and delete (or rename) it.
We then take the next more complicated
80286_FPGAx.bdf file (80286_FPGAx+1.bdf) and rename it 80286_FPGA.bdf
We then go back to Quartus and open this
80286_FPGA.bdf file and work on it.

The key thing here is Quartus does not know we switched files on it.  This way all pin designations, ROM and RAM preloaded .HEX files remained unchanged.  Plus other things.  If you start flipping files around renaming them etc., within Quartus it gets confused -- without telling you.

I cannot stress enough the trick of saving old
.bdf files, renaming them etc. along the way. This way you can easily fall back to the last good working example.  Saved my neck many times!

A few things about Quartus.

1. It constructs a number of sub-directories as it constructs its FPGA code below the 80286_FPGA directory. You don't  have to bother about them.

2. As Quartus compiles your code,  it seems to send out endless information in messages. Again don't bother about them unless it tells you (in red text) that there are errors at the end.


3. Be very careful when you place copies of a logic item. Sometimes when you click you can place one item exactly over another yet the item appears as only one unit. For example a NOT or a NOR gate. The compiler will insist the gate has no input when in fact there is a hidden gate under it.

4. Be careful when you join up and input or output port to a wire or bus line. Make sure they join by dragging them apart.

5. Some gates are negative true. I use names like pWR- to signify this. Quartus does not accept pWR*.

6. Be sure you assign actual pin numbers to FPGA inputs and outputs. Quartus does not tell you if they are unassigned.

7. As I said above build a circuit in stages of increasing complexity saving versions along the way.

8. Be sure the designated FPGA for a new project is a EP4CE10F17C8  FPGA for the above WebShare board.

BTW, the actual compiling and programming process takes longer than you might expect (~3minutes for the complete program).



Step By Step Building the FPGA Z80 SBC 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.  Also do not add the MicroSD Card Adaptor or the RTC crystal yet. Please be sure you put the resistor arrays in with the correct orientation of pin 1. An incorrect orientation is one of the most difficult things to detect/debug on a board if not noticed. 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 (D24V25F5) are still available, it seems Pololu is suggesting users use the D24V22F5's (5V, 2.5 Amp) units.  

When adding the LED's be sure to orient them correctly. (Usually the longer lead in the square pad).
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. 
Here is a picture of the board at this stage (With the WaveShare FPGA Inserted):-
   
    Stage 0
   
For testing remove every S100 bus board in your system except (if you have one, the S100 Bus SMB and/or the Bus Display Board).  If you have neither of these boards you must press the reset button (
SW1) on the board itself to run the actual FPGA program (after uploading it). As we shall see below during the software build, there are two options for the 80286 monitor console IO. If you have a Propeller Console IO Board, great, use it. If not, you will need to use the onboard USB port connected to a TTY terminal on your PC for monitor IO.  The former option is much better and far easier to get going. It will be a few steps down before you have a working USP port. Except for looking with a logic probe at critical signals you will be in a sense flying blind in that case.

Lets get started, Place the board as shown above in the bus without any chips  inserted, (including the Waveshare FPGA adaptor). 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.  Be sure you have 3.3V and 5V going to the appropriate pins on the Waveshare FPGA adaptor socket.   

If you are comfortable with the above, carefully insert the WaveShare Cyclone IV adaptor in its sockets.   Power on the  computer.  "Virgin" Cyclone IV Adaptor boards from WaveShare seem to have the FPGA preloaded with a program (in the EPCS16 Flash RAM) that already that pulses its 4 onboard LEDs.  Note the flashing rate.

Within the Quartus FPGA project folder (the expanded
FPGA_80286.zip download, see bottom of this page), erase 80286_FPGA.bdf and copy 80286_FPGA0.bdf to 80286_FPGA.bdf.

Please note the actual 80286
_FPGA.bdf file in the above 80286_FPGA.zip download is the final (Step 16 or later steps, see below) FPGA code.  It is there only for experts that have used Quartus and know how to code FPGA's using .bdf files.  Everybody else should delete it and step things along (80286_FPGA0.bdf ,1,2...15) as described below. 

Let's get started...

Load Quartus and open the Project file 80286_FPGA.qpf, then open the file 80286_FPGA.bdf. When loaded, "
Compile the Design", then "Program the Device" and then hit the "Start" button.  The LED's on the Waveshare adaptor should flash differently. To confirm, kill the power and reboot the computer. The code in the FPGA is lost so the original flashing rates should reappear.   Note,  if you are using a previously programmed FPGA adaptor with code "burnt" into the FPGA the power-on flashing will probably not be present.  In fact,  Waveshare may in the future supply adaptors without the flashing code in them.   Here is a picture of the 80286_FPGA.bdf file:-
   
   

Very important the LED
D1 "BOARD_ACTIVE" should be flashing.
This is your first connection of the FPGA adaptor to the outside world!  Do not go forward until you see this response.

 
1. The IO PORT Test.
The easiest way to get this board going is to use a real pair of  EEPROMs in the "RAM" sockets U1 and U9 with a very simple program.
We will start with this approach.  You will need some way to program a pair of EEPROMs.   If you don't have access to a PROM burner you can proceed to the next step below where we setup a PROM pair within the FPGA.

Lets get started.
First add U3,U4,U5, U7,U8, U33 U35,U34,  U22,U23,  U25,U26,U27 U10,U23,  U28,U31, U2 and U15. Add the 80286 U12 and the Bus Controller U16

Jumper JP1, JP2 and JP3.
Jumper P9 1-2.

Please note the sockets U1 and U9 are really intended for the onboard static RAM chips (see below). We will use two 14 pin 28C256 EEPROMs in the rightmost pins of the 32 pin sockets as shown here:-
  
     Onboard ROMs

We also need to jumper K5 2-3, K4 2-3, K6 2-3 and K7 2-3.

We will load a simple FPGA program to test our S100 bus address, data and control lines are connected to the bus correctly.
Within Quartus, close the current 80286_FPGA0.bdf file.  Note,  not the project file (80286_FPGA.qpf).
Then go outside of Quartus and into windows and delete (or rename) it.
Then take the next more complicated file, 80286_FPGA
1.bdf, and rename it 80286_FPGA.bdf
Then go back to Quartus and open this 80286_FPGA.bdf file and study it.

We will configure the board such that it is a S100 "Bus Master".  Upon reset, the 80286 always has the S100 bus. The relevant FPGA circuit in 80286_FPGA.bdf is shown here.
   
     MASTER_SLAVE CIRCUIT

The 80286 CPU will immediately boot from the U1 & U8 ROMs at
FFFF0H after reset. 


Any CPU read address between
FF800H and FFFFFH will select the ROMs. The 2X8 bit data output from these ROMs will go directly to the CPU data input lines (via EEPROM pins D0-D7 and D8-D15). Most important at the same time any data input from the actual S100 bus data lines is inhibited via DATA_IN_OE* (U7) .  Please study this 80286_FPGA.bdf file. It is most important that you see and understand how the FPGA distinguishes between data it sends directly to the external CPU data lines and how in other cases the CPU receives data directly from the S100 bus and sends it directly to the CPU.  As we build up the complexity of the FPGA circuits this process will get more complex. The 80286 CPU does not know or care where it is getting or sending its data -- its up to the FPGA circuits to decide.

Currently we have a very simple situation -- the CPU will simply read the EEROMs (at FFFF0H), which tell it to continuously send
3's to the console IO port 01H:-

START: MOV    AL,33H       
B0 33
       OUT    01H,AL       
E6 01
       JMP    START        
EB FA



As we will also see below,  the maximum capacity for a pair or ROMs within the FPGA is 128K.  Since the are no 128K EEPROMs we will use the "top half" of ATMEL 28V256 256k EEPROMs.
The above code is so simple you can directly edit the two EEPROMs using software such as that for a Wellon VP299 (or later) Programmer from here:-

http://www.weilei.com/dow.asp

and install it. (You do not need Wellon hardware to run it).  To save time however the .HEX files can be downloaded as:-
  
TEST_OUT_33_TO_01_PORT_LOW.HEX  and TEST_OUT_33_TO_01_PORT_HIGH.HEX.

from the bottom of this page. You then need to the "Burn" these two .HEX files into the LOW and HIGH byte EEPROMs. 
Here is the contents of the Low ROM.  The high ROM will be identical except that the 3 bytes will be
33, 01, FA.
            
  Low ROM Data
    
When you compile and run the 80286_FPGA.bdf file you should see the following output on your Propeller Console IO board after hitting the reset button.
    
    Output 3's
      
 
If you don't  have a Propeller Console IO board try whatever port you intend to use as console IO.
This is the simplest possible configuration of this board. You must get the above output working before going further.

Next we will make a small change. From now on we will configure the board for testing as a S100 bus slave. Modify your 80286_FPGA.bdf  as follows:
  
     Master Slave 2
  
Within Quartus, close the current 80286_FPGA0.bdf file.  Note,  not the project file (80286_FPGA.qpf).
Then go outside of Quartus and into windows and delete (or rename) it.
Then take the next more complicated file, 80286_FPGA2.bdf, and rename it 80286_FPGA.bdf
Then go back to Quartus and open this 80286_FPGA.bdf file and study it.

When you re-compile and run the
80286_FPGA.bdf file you should see the same 3's output on your Propeller Console IO board after hitting the reset button.


2. Adding an FPGA ROM.
One nice thing about these FPGA's you can internally build your own ROM's. Since the 80286 has a 1M address space (in real mode) it would be nice to have a real big/elaborate ROM monitor. Alas, our Cyclone IV will allow us only room for 128K (or 2X64k) ROMS.  This is still plenty to have a very elaborate monitor as we will later see.  We will place our EEROMs at
FF800H-FFFFFH within the FPGA code.  Further to get going we will start again with the above 3's output test program -- just this time the ROM is provided by the FPGA.

The actual ROM module is obtained from one of the Quartus IP libraries. 
It's  important you select the Intel File format and the .HEX file ends up correctly in the correct position within the FPGA "ROMs".  We fool the Wellon into thinking the VP299 (or later) Programmer its programming a 27128 EPROM.  The critical code is at
3FF0H to 3FFFH which in the FPGA ROMs will be FFFF0H-FFFFFH.

For experts, we could alter the two 8 bit  FPGA ROMS to one 16 bit ROM and go with one simple .HEX file, but by having a separate LOW and HIGH ROM we can in fact use code from "real" 28C256 EEPROMS and by jumpering them as described above test the FPGA code ROMs with "real" ROMs back and forth.

Remove the two "real" EEPROMS in U1 & U9.
Add U37 & U18.

Within Quartus, close the current 80286_FPGA1.bdf file.  Note,  not the project file (80286_FPGA.qpf).
Then go outside of Quartus and into windows and delete (or rename) it.
Then take the next more complicated file, 80286_FPGA
3.bdf, and rename it 80286_FPGA.bdf
Then go back to Quartus and open this 80286_FPGA.bdf file and study it.

A lot more is going on here than you might first think.  Because the S100 bus can dynamically act as an 8 or 16 bit bus and the 80286 always sends and receives even byte data on its D0-D7 lines and odd byte data on its D8-D15 lines we have to within the FPGA direct data to/from the S100 bus.  This is done by controlling the 3 buffers
U7, U8 & U6.  You should understand the process by reading up on a write-up for our earlier RAM cards. See here and here

Again, for real experts,   I initially tried bringing these three buffers into the FPGA where only two external 74LVC
373's would be needed.  Wasted a week on it, I found at high speeds,  the CPU needed the 5V 74LS373 on the bus.

While hopefully you will not need them, during development I wrote FPGA ROM Hex files to test a number of different S100 bus situations.  They are all in the ROM_HEX_FILES directory.

TEST_OUT_33_TO_01_PORT_LOW_BYTE.HEX,    TEST_OUT_33_TO_01_PORT_HIGH_BYTE.HEX   
TEST_OUT_33_TO_04_PORT_LOW_BYTE.HEX,    TEST_OUT_33_TO_04_PORT_HIGH_BYTE.HEX   
TEST_OUT_01_IN_01_LOW_BYTE.HEX,              TEST_OUT_01_IN_01_HIGH_BYTE.HEX
TEST_CONSOL_IO_LOW_BYTE.HEX,                   TEST_CONSOL_IO_HIGH_BYTE.HEX

  

3. Adding RAM and the 80286 Monitor.
Next we need to add the actual FPGA ROM 80286 monitor, but before we do this, because the monitor needs a valid stack we must add RAM access. 
While we could use an S100 bus 8/16 bit, we will add 1MG of static RAM to the board. We will use two HM628512LP static RAM chips.  We have had great success with these chips in the past.
So add them to the U1 and U9 sockets..
We also need to jumper K5 1-2, K4 1-2, K6 1-2 and K7 1-2.

Within Quartus, close the current 80286_FPGA.bdf file.  Note, not the project file (80286_FPGA.qpf).
Then go outside of Quartus and into windows and delete (or rename) it.
Then take the next more complicated file, 80286_FPGA
4.bdf, and rename it 80286_FPGA.bdf
Then go back to Quartus and open this 80286_FPGA.bdf file and examine it.


Then load the two monitor HEX files:-
FPGA_80286_MON_LOW_28C128.HEX,   FPGA_80286_MON_HIGH_28C128.HEX (see below)
Compile and run the FPGA code. After a reset the 80286 monitor should boot up as shown here.
 
     Monitor Signon
 
One of the most common problems I ran into building this board was loading code into the two FPGA ROMs. In theory simple enough, but it you do it often mistakes happen. It was my number one reason why a configuration did not boot. For this reason I will elaborate on the process more.

First unlike the above test programs the 80286 monitor will normally be developed/modified from the
80286.A86 source code file.  This (normally) will be in a completely different directory than your Quartus source files. You need to note where the final NASM 80286.BIN file is written.  In my case the path is:

C:\Users\John Monahan\Documents\S100\NASM\FPGA_80286 monitor\FPGA_80286.BIN
   
To construct the two .HEX files for the LOW/HIGH Quartus ROMs we again use the software for a Wellon VP299 (or later) Programmer from here:-

http://www.weilei.com/dow.asp.

The software is setup this time to program a 27128 EEPROM.  We don't of course use an actual EPROM we just generate two .HEX files for them.
Hopefully these pictures explain the process.  First load the Even/Low Byte ROM:-
Check it "looks" OK as shown in the second picture, then save is as a .HEX file.
   
    ROM_LOAD1-3

Then do exactly the same thing for the ODD/HIGH byte ROM. Again starting with the
FPGA_80286.BIN file, ending up with a FPGA_80286_ODD.HEX file
Note the complete path to where these two files are stored in your system.

Then within Quartus, right click on the ROMs, select "IP Parameter Editor", and when asked provide the correct path to your .HEX file as shown here:-
  
    Quartus Hex file Location

Do this for both FPGA ROMS.
 
Note you only have to do this if you change the ROM .HEX filenames.  Quartus will always find and reload them for each compile of the total
FPGA_80286.bdf file.  This is both a good and bad thing.   It saves time, but if you forgot you somehow chanced the .HEX files contents a while back, the "new" files will be incorporated into your .bdf file without a warning.
Here is a picture of the board at this stage.
  
       Stage 1
  

      
4. Adding the IOBYTE Switches and Diagnostic LEDs.
As with the FPGA_Z80_SBC board we will use a bit pattern from a designated S100 I/O port to redirect the monitor I/O to various components on the board.  This concept is used throughout our S100 bus CPU boards. The default "IOBYTE Port" we will use here is port
0CEH.  We will use the lower 4 bits as switch inputs and the upper 4 bits as outputs to 4 indicator LED's D2-D5.  The status of the 4 indicator LED can actually be read as the 4 upper bits of input port 0CEH
.

While on the subject of I/O ports,  while the 80286 can address 64K of them, normally we work with the first 256  of them on the S100 bus.  To simplify the FPGA .bdf schematic further we will just use even address ports.  We will use a bunch of them together for various board components using the following circuit.
   
  Port Addressing
   
On this board in its current final form (see below), there are 4 different I/O possibilities for a Console for the 80286 Monitor (and MSDOS).
1.  The Propeller Console IO board.
2.  A USB port connected to a PC and a TTY character terminal.
3.  For both of the above,  the keyboard can instead come from a PS2 keyboard connected to the boards PS2 socket P3 or P12
4.  For all 3 of the above,  the Console output can instead go to a VGA display connected to the boards VGA socket J1 or P2

The decision in the 80286 monitor is based on the lower 3 bits of the 8 bit IOBYTE port. Defined as follows.
 
xxxxxx11 All console IO goes via the Propeller Console I/O board.  
xxxxxx10  All console IO goes via the USB port/PC TTY terminal
xxxxxx0x  Input for the console (above) is  overridden and always comes from the PS2 keyboard.
xxxxx0xx  Output for the console (above) is overridden and always goes to the onboard VGA display.

So for example if the IOBYTE port is absent/ non-functioning (11111111),  all Console IO will be via the Propeller Console I/O board.  
If the IOBYTE port is xxxxx00x the PS2 Keyboard and VGA display would be the Console.
Please note these functions have not been added yet to our FPGA code. We will do so below in stages.

For now set the dip switch
SW1 to all open. 

Within Quartus, close the current 80286_FPGA.bdf file.  Note, not the project file (80286_FPGA.qpf).
Then go outside of Quartus and into windows and delete (or rename) it.
Then take the next more complicated file, 80286_FPGA
5.bdf, and rename it 80286_FPGA.bdf
Then go back to Quartus and open this 80286_FPGA.bdf file and examine it.

Compile and run the 80286_FPGA.bdf program.

Use the 80286 monitor
QO
CE commands to alter the (diagnostic LED's).
For example QO
CE, FF should turn all 4 LEDs  off, while QOCE,0F should turn them all on.
Here is a picture with all 4 LED on.
  
    LED On



5. Adding a Serial/USB port
We will now add a USB Port for Console I/O to the board. 
This will be a relief to those that do not have the Propeller Console IO Board and may have been flying almost blind up to now. 

This also is the first time we will be using Public Domain software modules.  As I said above, these are available for chips like the Cyclone Series in many places on the web.  I mention in particular OpenCoresJavier Valcare's FPGA home page and fpga4fun.   In most case however the source is in VHDL or Verilog "raw" format.  
Fortunately Quartus allows you to convert the module to a .bsf file so it can be used directly in our (growing) 80286_FPGA.bdf file.

In this case we use the UART.V file from OpenCores Then under the File menu:- Create\Update, Create a Symbol File from current file. We create uart.bsf.
Then within the Quartus Symbol Tool, under Project, you will find uart. Drag that into your growing .bdf file --  I always add components at the bottom.
This is how one adds software modules in Quartus.  Its already loaded for you however in our next version of 80286_FPGA4.bdf.
So again repeating the drill:-

Within Quartus, close the current 80286_FPGA.bdf file.  Note,  not the project file (
80286_FPGA.qpf).
Then go outside of Quartus and into windows and delete (or rename) it.
Then take the next more complicated 80286_FPGA
6
.bdf file and rename it 80286_FPGA.bdf
Then go back to Quartus and open this 80286_FPGA.bdf file and work on it.

Here is the core circuit.
     
USB FPGA Code
   
The above circuit is actually an RS232 UART circuit.   We use one of the common RS232->USB adaptors to convert the bidirectional data to a USB format. 
I like to use the SparkFun FT231x.  It's simple and reliable and uses a USB micro connection.  It can run at 5V or 3.3V.  Since we are connecting the chip to the FPGA directly you need to jumper the chip on the back to 3.3V.  Sparkfun also supplies a Sparkfun FTDI "Basic" converter which uses the older USB mini connector -- same pin connections.
   
Adfruit (and others) also supply similar converters -- unfortunately they are not pin for pin compatible.
Be sure you configure either converter to 3.3V with the jumper on the back of the unit.

On the receiving side you will need a PC TTY terminal. Again there are many . I like the Telnet Program Absolute Telnet.  Under "Options", select "Properties", then select "Connection". Your SparkFun windows driver should appear as a COMx port. If you pull out the USB cord that COM port should disappear from the "port" dropdown menu.  It will reappear if you reconnect.  Set to 9600 baud, 1 Stop bit, No parity.  Another good Telnet program is Tera Term. This one can be downloaded for free from here

Here is a picture of the USB Port Adaptor attached to the board.
  
   

The default data USB data port is at
0C0H.  So from the 80286 monitor if you enter:-

QOCO,33

You should see a "3" on the TTY terminal.

If you set the RHS switch of the Dip Switch's (SW3) to closed (ground) and reset the board the 80286 Monitor should sign on at the USB TTY terminal as shown below.
This is because the 80286 Monitor Console I/O routines are programmed to recognize the USB port as an option:-
   
    USB Signon
   
Only the A,D,F,G,H,J,K,M,O,Q,R,S,T,U,V and W commands work at this stage. 
Note currently, the W command only works with the console assigned to the Propeller Console IO board and the data from the PC coming in via the USB port.


Remember, data from the IOBYTE port and USB port will be coming into the board via the FPGA internal modules and not the S100 bus, as explained above,  we must send the data to the 80286 in data bus directly from the FPGA. We prevent the S100 bus tri-state buffers from becoming active using this circuit.
      
  USB port Circuit 2
   
BTW you only need to use a single row socket (P15) for these USB adaptors. The side pins (P
11,P16)  are not actually used. (I actually use one pin, at position #2, each side to steady the adaptor).
Also the pin holes for P
15 are small enough that you don't normally need to solder the USB unit to the board until it is tested/working.  You have to carefully press/force the unit into them. I recommend however when all is working to solder the unit to the board.

6.  Adding CPU Interrupts and the 8259A Controller.
We Unlike the FPGA_Z80 SBC and its software , 8086 systems make extensive use of interrupts.  MSDOS minimally requires interrupts for keyboard input and time updates.   While some FPGA Interrupt modules are in the public domain, I could not find a free one the exactly emulates the 8259A hardware interrupt controller.  Any interrupt hardware absolutely has to be 100% MSDOS compatible and completely reliable.  I decided to add a "real" 8259A controller chip to the board.  Is 8 data lines interface directly to the low 8 bit data lines of the 80286 -- thus setting up a fast and simple interface. We will allow for up to 8 S100 bus interrupt inputs.  Here is the core circuit.
      
    8259A Circuit
           
If you are not familiar with CPU interrupts and the 8259A Interrupt controller you should read more about it here.
We will initially use the Interrupt controller to respond to test the Propeller Console IO interrupt sent on the S100 pin 5
VI1* line.
 
For hardware first solder to the board a known functional 74LS240 (U13). Over it insert the 8259A Chip (U11).  Jumper K1 1-2. Jumper P11 3-4.  This allows passage of the Propeller Console IO Board keyboard input interrupt to reach pin 19 of the 8259A.  On the Propeller Console IO board (V2.51), make sure P74 is jumpered 3-4. 
The board should look like this.
   
    Stage 3
    
The remainder of the circuit resides in the FPGA.

One subtle point, the 8259A requires two address for status and configuration. For all our past boards we used ports
20H and 21H (as did the IBM PC). Because the 80286 communicates data on its even address lines on D0-D7 and for odd address lines D8-D15, we shall simplify the board circuit by using ports 20H and 22H. This way all the 8259A data goes over the CPU data lines D0-D7.   A quick check of my other 80286,80486 etc. CPU boards with a modified version of our MSDOS Support Board confirmed that a change in the CPU ROM BIOS alone is all that is needed to run MSDOS "out of the box", i.e. unmodified.  MSDOS does not interact with the Interrupt controller directly.
So again:-

Within Quartus, close the current 80286_FPGA.bdf file.  Note,  not the project file (80286_FPGA.qpf).
Then go outside of Quartus and into windows and delete (or rename) it.
Then take the next more complicated 80286_FPGA7.bdf file and rename it 80286_FPGA.bdf
Then go back to Quartus and open this 80286_FPGA.bdf file and work on it.

You will note in this version we are now running the CPU with a clock speed of 10MHz. For reasons that are unclear to me,  booting MSDOS (see below) at low speeds (1-2MHz) does not work reliably using our IDE-CF Card Board

Bring up the monitor "L" command.  This command will test your 8259A interrupt circuit. Any character typed on the keyboard, will generate an interrupt on the S100 bus pin
VI1* which triggers the interrupt vector "keyhnd" routine in the ROM Monitor via the 8259A.  The code is described at "IRQ1 - KEYBOARD DATA READY" in FPGA_80286.A68 ROM monitor (see below).
Whatever keyboard character you type should appear on your console output.  Do not go further until you get this result.
   
     Keyboard Test

You should now be able to boot "standard" MSDOS from your IDE/CF Card S100 board if you have it installed with our earlier boards.
The MSDOS Support board should not be present since the keyboard interrupt is now working from this board. 
You will however not have automatic file time/date stamping yet,  that's next.


7.  Adding the SPI interface/Real Time Clock-Calendar.
We will now  add the Clock/Calendar Maxim DS1305 chip U14 to the board. Add the small 32.768 KHz crystal. Add a CR2032 3V "coin battery).
This is a simple, but an extremely powerful, 16 pin DIP  chip.  It will handle almost any date/time requirement you have.  It is described in detail here. 
As you can see the interface can be via a SPI or I2C connection.  I have chosen an SPI interface (Pin 9 of the DS1305 to Vcc33). 

We will now add the Clock/Calendar Maxim DS1305 chip U14 to the board.  Add the small 32.768 K  H. (Also add the CR2032 3V “coin" battery).   This is a simple, but an extremely powerful, 16 pin DIP  chip.  It will handle almost any date/time requirement you have.  It is described in detail here.  As you can see the interface can be via a SPI or I2C connection.  I have chosen an SPI interface (Pin 9 of the DS1305 to Vcc33). 

The trick was integration the interface into the MSDOS compatible ROM BIOS.

The usual  FPGA programming drill, to add this module to our growing FPGA program

Within Quartus, close the current 80286_FPGA.bdf file.  Note,  not the project file (80286_FPGA.qpf).
Then go outside of Quartus and into windows and delete (or rename) it.
Then take the next more complicated 80286_FPGA8.bdf file and rename it 80286_FPGA.bdf
Then go back to Quartus and open this 80286_FPGA.bdf file and examine it.

Then compile and run the 80286_FPGA.bdf file.

In order to test the chip/interface a short 80286 program was written called SPI_RTC.A86
.  This is a standard S100 bus program that can be downloaded from your PC via the FPGA monitors "X" command.  It starts in RAM at 500H.
So we use X500
Then G Segment = 0, Offset = 500
The program allows you to test the chip. For example set and read the time.  
Here is a picture of the main menu:-
    
    SPI_RTC_Menu
  
A useful feature of this chip is a 96 byte NV RAM storage area, (Provided you have battery backup). 
Upon power on (no battery backup) the chip must be "activated". With battery backup you only need to do this one time. If you do it again/later it will reset the time to 0's. 
This RAM storage area BTW is very useful for MSDOS variable storage.

For those that want to see what the SPI signals look like. Here is a picture with the Menu command "1", to read he seconds register.
   
    SPI-RTC-Capture

Under Construction
Text beyond this point is invalid.

8.  Adding the PS2 Keyboard and VGA Video Interface.
n alternate for the Z80 Monitor Consol. We will add a PS2 Keyboard for input and a VGA Video display option for output. 
If bit 1 of the IOBYTE switch is 0 then all Console input will come from the PS2 keyboard socket.
If bit 2 of the IOBYTE switch is 0 then all console output will go to the VGA socket.
 
Within Quartus, close the current 80286_FPGA.bdf file.  Note,  not the project file (80286_FPGA.qpf).
Then go outside of Quartus and into windows and delete (or rename) it.
Then take the next more complicated 80286_FPGA7.bdf file and rename it 802860_FPGA.bdf
Then go back to Quartus and open this 80286_FPGA.bdf file and understand it.

Examine, compile and run the 80286_FPGA.bdf file.

Both the PS2 and VGA modules have been described and used with our V2 FPGA board.  Please see here for the PS2 module and here for the VGA module.

Both circuits are imported unchanged.  The only modification to the original 80286_FPGA.bdf file is we need to allow the VGA data and cursor data to go directly to the 80286 by again modifying the S100 Bus interface.   
   VGA data Input
  
Here is a close-up picture of the dip switches etc.
    
   PS2_VGA

Note both the PS2 and VGA outputs can be connected to ribbon cables and connected to the back of your S100 Box. The pin-out is the same as for our earlier boards. Here is the VGA Signon image you should get upon reset.
  
    VGA Display
The above two modules do illustrate the power of these FPGA's. Such a circuit with standard TTL/CMOS chips would easily consume a whole S100 board!

Remember however that this redirection of Console output works within the 80286 Monitor.
If you load MSDOS or other software they too will have to examine the IOBYTE port for data redirection.


7.  Adding a Parallel Port Printer
We will next add a parallel port printer interface for the 26 pin connector
P18.
Add U23 by soldering it directly to the board (inside the U
xx socket).  If possible, use a "known working chip" from elsewhere on the board.

The port is compatible with the IBM PC printer port (in simple output mode).  While it does not use
8212's, from a software perspective it behaves the same.   As described for the Z80_FPGA SBC, you have to lower the 8 data lines to zero after the acknowledge bit was returned from the printer.  If I let them float with their previous value until Busy came back you may get printer errors.  This may be unique to my HP printers,  but with the following circuit printing was always 100% reliable. 
    
    PrinterStatus

To test the printer enter the ^P (Control P) character as a command to the 80286 monitor.  The onboard 80286 Monitor is programmed to send all console output characters that goes to the Propeller Console to the printer ALSO until the next ^P is sent.  Note the port addresses used are, 
0C6H & 0C7H -- unlike the port addresses used on our other parallel ports boards.
 
 
To test the printer, assemble a 25 pin ribbon cable as shown in the schematic for
P18.  This layout is inline with the common old PC parallel printer port.   Only 8 data lines, the Strobe, Ack and Busy lines are used here. Please note the position of the printer cable pin 1 in the picture below.
  
    PrinterStatus

The usual drill, to add this module to our growing FPGA program

Within Quartus, close the current 80286_FPGA.bdf file.  Note,  not the project file (80286_FPGA.qpf).
Then go outside of Quartus and into windows and delete (or rename) it.
Then take the next more complicated 80286_FPGA6.bdf file and rename it 80286_FPGA.bdf
Then go back to Quartus and open this 80286_FPGA.bdf file and work on it.

Examine, compile and run the 80286_FPGA.bdf file.
Here is a picture of what you should get if you set the IOBYTE switches as shown above.  
 
    Printer Output
Printers like the HP LaserJet's generally only print a page at a time.  So until you send a full page of characters the printer will not print -- it stores them in RAM. You can override this by sending, at any time, an ASCII Form Feed (
FF, 0CH) character.  In our monitor if you send a '@' menu item this will always send a FF to the printer. 
 
  



10.  Adding The SD Card Interface.
This is perhaps the most complex aspect of this board.  Not only in terms of the software but because today SD cards come in all shapes and sizes.  There are numerous articles on the web describing how to determine the type of SD card present and even more articles describing how to "initialize" them.  Three good articles that help me a lot are:

Secure Digital (SD) Card Spec and Info
What is the correct command sequence for microSD card initialization in SPI?
and the excellent code example by CC Dharmani, see here

The interface is a complete transplant from the FPGA Z80 SBC board.  The code below will read and write to today's very common Type 2 SD cards.  It would have to be modified to work with the older Type 1 cards.  These require a different initialization sequence.  Experienced SD programmers may note during the card initialization sequence I add valid CRC bytes to the initialization commands before turning off CRC checking.  I also actually set the sector size to 512 bytes .  Many programs do not do this but the are reports of some Type 2 SD cards actually requiring these steps.

As to the actual Type 2 cards themselves, they come in two sizes of "Micro" adaptors.  This board can use one Adfruit Micro SD adaptor (Pxx) and one SparkFun Micro SD adaptor (Pxx). In other words you can have two SD card drives A & B. You just have to adjust the heights of the connector sockets and pins so the SparkFun micro SD adaptor fits over the Adfruit Adaptor. See below.
     
    SD Card Adaptors
   
Because we are interfacing the SD card with our 3.3v FPGA we can essentially connect the SD card directly to the FPGA. This is what these adaptors do.  The Adfruit adaptor runs with the 3.3V supply pin input.

Using an FPGA really illustrates the utility of these FPGA chips.  We use our now tried and true SPI interface to talk to the SD cards.  Here is the core SD card SPI interface module.
   
     SD Card  SPI module
   
We will allow for two slave/SD drives. These are selected outside the above module by outputting a bit to the CS*  pin of the SD card (SD_CS_PORT)

You will note that we use two SPI clock frequencies.  This is because during a cold start, SD cards only communicate over the SPI lines at a slow (~100-200KHz). Once Initilized, this can be jacked up. I use
10MHz here.  The 21mux controls this by a high/low bit from the SPEED_PORT.
We will require four I/O ports.

SD_CARD_BASE EQU 06CH

SD_DATA_OUT     EQU    SD_CARD_BASE     ; (6CH) Data to SD CONTROLLER
SD_DATA_IN      EQU    SD_CARD_BASE     ; (6CH) Data from SD CONTROLLER
SPEED_PORT      EQU    SD_CARD_BASE+1   ; (6DH) HIGH TO READ/WRITE SECTORS WITH HIGH SPEED SPI CLOCK
SD_CS_PORT      EQU    SD_CARD_BASE+2   ; (6EH) SD Card CS* Select Port
SD_STATUS       EQU    SD_CARD_BASE+2   ; (6EH) SD CARD Status Port
SD_RW           EQU    SD_CARD_BASE+3   ; (6FH) Port to pulse SPI Read/Write interface


Initialization of Type 2 SD Cards.
You can skip this section if you like since what is here is already in the
Z80 SD_CARD software describe below.

In order to use an SD card you must first "initialize" it.  This requires a series of 48 bit SPI commands.  These must be sent in the correct sequence, not continuing forward until the correct response from the previous command is obtained.  Sometimes this involves repeated sending of a command. 

The commands themselves all have the following structure.
  
    
    SD Card SPI format
  
The first byte contains the actual "Command". All SD card commands have the following format
01XXXXXXB.
Here is a list of the commands we use:-

CMD_0:   DB 40H,00H,00H,00H,00H,95H,0FFH ;   (0+64)  CMD0   To Reset the SD Card interface,
CMD_1:   DB 41H,00H,00H,00H,00H,0F9H,0FFH ;  (1+64)  CMD1   Activate Init Process
CMD_8:   DB 48H,00H,00H,01H,0AAH,87H,0FFH ;  (8+64)  CMD8   To check Card Voltage
CMD_9:   DB 49H,00H,00H,00H,00H,8FH,0FFH ;   (9+64)  CMF9   Read SD Register (CSD)
CMD_13:  DB 4DH,00H,00H,00H,00H,081H,0FFH ;  (13+64) CMD13  Get SD card status
CMD_16:  DB 50H,00H,00H,02H,00H,081H,0FFH ;  (16+64) CMD16  Set Sector size to 512 Bytes
CMD_17:  DB 51H,00H,00H,00H,00H,0FFH,0FFH ;  (17+64) CMD17  Read a single block (Block 0, Used to load boot sector only)
CMD_41:  DB 69H,40H,00H,00H,00H,077H,0FFH ;  (41+64) CMD41  Activates the card's init. process.
CMD_55:  DB 77H,00H,00H,00H,00H,065H,0FFH ;  (55+64) CMD55  Application specific command NEXT
CMD_58:  DB 7AH,00H,00H,00H,00H,0FDH,0FFH ;  (58+64) CMD58  Read SD Cards OCR register
CMD_59:  DB 7BH,00H,00H,00H,00H,0FDH,0FFH ;  (59+64) CMD59  Turn off CRC checking


You will note there is always a "stuffer" byte 0FFH byte sent before a return response byte(s)  from the SD Card.  The return Flag byte contains the error code if any.  Generally (but not always),  you want to receive 00H.

The sequence to initialize Type 2 SD cards is as follows.

Drive the
CS* pin from high to low
Send 12 or more dummy
0FFH bytes
Then send the following 6-byte command,  First byte:
0x40 (CMD0), Next four bytes: 00000000H, then the CRC byte (95H), then send another dummy byte 0FFH byte.
Read the returned byte from the SD Card.  If its not
01H,  repeat this command until 01H is returned.
This means the card is in the "idle state" and we are good to go.

Next send the following 6-byte command,  First byte: 0x48 (CMD8), Next four bytes: 000001AAH, then the CRC byte (87H), then send another dummy byte 0FFH byte.
Read the returned byte from the SD Card.  If it is 01H you probably have a
Type 1 SD card. We want a 05H returned, indicating a Type 2 card.
We confirm this by reading the next 4 bytes from the SD card.  If its 000001AAH, we have a Type 2 card for sure.

Next we "activate" the
Type 2 card by sending two back to back commands CMD55 and CMD41 exactly as done above for the CMD0 command.
Repeat the latter two commands continuously until you get a return
0H byte.

The SD card specifications says that only
CMD0 and CMD8 should have a valid CRC byte in SPI mode, however there are reports that some SD cards (like Transcend ones) seem to require a proper CRC for CMD55/CMD41 commands as well. To be on the safe side I add the byte.
Also between every command above,  the SD card
CS* line needs to be lowered and raised when done.

Based on other web postings, I also send
CMD59 to specifically turn off CRC checking and CMD16 to set the sector size to 512 bytes/sector. 
I'm not convinced these are essential but it's best to play safe.
Here is an example picture of the main SPI signals using the
CMD8 command:
   
     SD Card Signals
   
    
I have written a small 80286  program to initialize, read and write sectors to the A and B SD drives. It is called
SD_CARD.A86. And can be downloaded at the bottom of this page.  Again, this is a standard S100 bus program that can be downloaded from your PC via the FPGA monitors "X" command.  It starts in RAM at 500H. So we use X500.  The program allows you to test the SD Cards interface.
Here is a picture of the main menu:-
 
    SD CArd Signon1   SD CARD SIGNON2
  
Please note this is not a "bullet proof" program. Little command error checking etc. is done.  The sector numbering is only
0-FFFFH, but that should be enough for most needs.  In fact some older Type 2 cards may not accept a sector number this large.  You may have to hit the CMD0 command twice to initialize a newly inserted card or on power up.

Note. These SD cards can read and write multiple sectors with one command. I have not added this feature yet.
 

Of course before you run the above program you need to add the above SD Card interface module to our growing FPGA program. 

Within Quartus, close the current 80286_FPGA.bdf file.  Note,  not the project file (80286_FPGA.qpf).
Then go outside of Quartus and into windows and delete (or rename) it.
Then take the next more complicated80286_FPGA9.bdf file and rename it 80286_FPGA.bdf
Then go back to Quartus and open this 80286_FPGA.bdf file and work on it.

Examine, compile and run the 80286_FPGA.bdf file. 

Do spend some time studying the FPGA ports and the above 80286 code. 
All the critical routines: 
Initialize, Read Sector, Write Sector etc. are written as self-contained returnable calls which should make it easier to incorporate them as a MSDOS BIOS etc. The source is in .A86 format for use with NASM.


Here is a picture of the final setup:-
    
    Live SD Cards

The card LED's (D
21 or D20) will light up if a SD card is not inserted.

One final note, a useful PC program to see/check what is written on any sector of an SD Card is HxD Hex Editor.
It can be downloaded from here.




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 Intel documentation poor and confusing.  Here is a summary of the process: 
  
Within Quartus you need to "convert" your normal JTAG FPGA .sof programming file to a special file .jic to program the Serial Flash RAM chip on the Weveshare board.

Within Quartus, click on the File Menu and select "Convert Programming files". The dialog box below will popup.
From the dropdown box on the "Programming File Type"  select a .jic file type.
This is the file format that is required to program the onboard serial Flash RAM.
For the Options/Boot info select EPCS16. Leave Active Serial as is.
You can name the .jic output file anything you like. I usually just leave it output_file.jic.
Note it will be in the Quartus generated "output_files" folder within your work directory.

Next click on Flash loader within the lower "Input Files to Convert", then click on the highlighted "Add Device" button.
You will get a popup dialog box as shown below.
Select Cyclone IV  and EP4CE10.  Note Quartus takes some time to allow you to actually select these options -- seems to be doing things in the background!
Next click on "SOF Data" and "Add File".  You should see your "normal" FPGA program .sof file in your "output_files" folder within your work directory.
Finally click the "Generate" button.
You should get a popup dialog saying "Generated output_file.jic successfully.
Note the name and location of the converted file. Then close that dialog box.  See the pictures below.
  
                
    Programming 1     Programming 2
 
Programming 3 Programming 4
   
Programming 5
  
Next we need to actually flash the Waveshare boards RAM chip.
Click on the normal "Program Device (Open Programmer)" you normally use. If its not already open,  give it time to come up as a dialog box.
Make sure your board has power.  To be safe click the Auto Detect button. your normal xxx.sof file should display with the device set as EP4CE10F17.

First delete the above line xxx.sof  |  EP4CE10F17 etc.
Click on Add File and select the xxx.jic file you just generated above.
Click on the Program/Configure little square character boxes.
The chip diagram below should show only 2 chips as shown. If more right click on any 'extra' one and delete it. The dialog box must look as shown below.
The Start button should highlight.
Click on this and you will flash the RAM chip.  Follow the Progress bar until it is done -- it takes about 1 minute.
You can power off and re-power your computer.
Your FPGA board should (after reset), start with whatever FPGA code is within the chip.
  
Programming 8
 
Note when you close the above dialog box, normally you do NOT save the changes.
Typically you want the chip to be quickly reprogrammable.

Notes

No other hardware changes have been noted to date.

 

 

A Self Contained Board

This Board is a completely self contained S100 Bus Master as defined by the IEEE-696 Specs.  It can therefore be run outside the S100 bus if you simply provide power to it.  There are two pins P31 for ground and P30 for 8-10V input to do this.  Please use the upmost care in doing this. Make sure the board is sitting on an insulated background (glass/wood etc.).    Of course you will want to configure the IOBYTE to the USB port or VGA and PS2 keyboard.

 

Parts

There appears to be a few variations of the 74LVC245 20 pin DIP level Shifters chips with "A", "AN" etc after the 245.   As best I can tell so long as they are 20 pin DIPs they are all OK. I use Mouser chips # 595-SN74LVC245AN.  

The WaveShare Cyclone IV adaptor can be obtained directly from Waveshare
You also might want to get the USB Blaster/Programmer from them.

The WaveShare unit uses unusual 2mm dual row pin connectors. See the writeup above. The best sockets are the Digi-Key #1212-1786-ND  100 pin sockets (carefully clipped to size).

The USB serial Adaptor is from Sparkfun F1231x.  The Micro SD Card adaptor is from AdaFruit.


Please note the sockets for the WaveShare adaptor are quite tricky to fit on to the board.  I found the best way to do it is (after trimming to size), push them half way on to the adaptor pins and then wiggle them to fit the whole unit on to the S100 board.  Figure on spending 10 minutes on this step!  Do not solder them to the board first and then try and press the adaptor down on them. They are very fragile and internally the leaves will bend if socket angles are not exactly correct.  When in place, check each pin is visible on the back of the board before soldering.  Only then solder all around.  Add as little solder to each pin as possible - the narrow pins have a tendency to wick up solder internally. 

To remove the adaptor,  leaver each corner up a little going round and round. The first time its quite difficult to get the adaptor out. It gets easier with time.
 
Installing Quartus Lite on Windows 10.
In spite of its name the
Quartus Lite IDE is a large program.  When fully installed the Quartus folder is over 15GB in size.  Installing it makes Microsoft's Vusual Studio seem lightening fast! 
 
That said,  its an excellent IDE.  Figure on 1 hour to install and get it right.  For our purposes we will only be using probably 5% of its capabilities, but I have found if you try and get smart by not downloading or removing sections you run into problems later during usage. 

The Intel Quartus download page  offers a number of download options and versions.  Select the
Lite version, and V18.0 version for windows. Just ignore all the individual files etc. and download the complet "Combined Files" package (Quartus-lite-18.0.0.614-windows.tar).  This is a 5.8GB file. When downloaded,  you need to unpack it with something like 7-Zip, WinRAR etc. Expand it into a local (temporary) folder and examine the "Components" folder. It should contain the following files:-
 
  
    Quartus Install Files 

I'm also including it at the bottom of this page in case you have difficulties reaching the Intel download site.

Click on the
QuartusLiteSetup-18.0.0.615-windows.exe program.  Your computer will show the hour-glass icon for almost 2 minutes! Nothing appears to be happening. This I assume is because its unpacking the compressed files in RAM.
Eventually, it gets back to you, with the usual legal/folders questions. After that the whole process is completely automatic/self-contained.  It just takes a long time.

Now while you can place your own FPGA files anywhere you like,  if you wish to have all the steps above proceed without really changing anything, all your FPGA files must be in this folder path:-
C:\intelFPGA_lite\18.0\quartus\MyFPGAPrograms\80286_FPGA

Note, I have located the ROM .HEX files to a sub-folder within 80286_FPGA called
ROM_HEX_FILES.  During any compile Quartus uses the file 80286_FPGA.qsf to locate ROM hex files (and other things).  Not finding them it would give errors, you have to set your own path.  By having all HEX files as a subfolder everything is self-contained.

  
Building the FPGA Z80 SBC Board as an S100 bus Slave CPU Board.
It is relatively easy to reconfigure the above 80286_FPGA SBC board to act as an S100 bus slave board where you would boot up with your "normal" Z80 CPU board and with the Z80 master monitor 'O' command transfer control over to this board -- just as we do for our many other slave CPU boards. 

Its very importand not to get the FPGA directory and files mixed up however with those for the above bus master configuration described above. They will reside in the following directory:-
   
C:\intelFPGA_lite\18.0\quartus\MyFPGAPrograms\80286_FPGA_SLAVE
 
and can be downloaded from the bottom of this page.

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 closed.  Please see here for more information.  Please do not contact me directly.

FPGA Z80 (V1.1) - FPGA Z80.zip                                      This .zip file contains all the KiCAD components to build the S100 board   (V1.1  9/6/2019)
FPGA_Z80 (V1.1)  Schematic.pdf                                     
This .pdf file contains the complete board schematic  (V1.1  9/6/2019)
FPGA Z80 SBC (V1.1b) Gerber.zip                                    Gerber files to manufacture the board.  (V1.1 b  9/10/2019)

Main Quartus Z80-FPGA Folder (Build Steps 0-16).zip       
  This .zip file contains the FPGA_Z80 build steps 0 to 16 described above     (V1.2  11/10/2019)
SBC-MON2.zip                                                                 This .zip file contains the Z80 monitor and FPGA .HEX files       (V1.1  9/6/2019)   
Quartus-lite-18.0.0.614-windows.tar                                
 This is a .tar file containg Quartus Lite and support programs. Note it's almost 6MB in size    (11/10/2019) 
Z80_FPGA CPU Board S100 Bus Programs.zip                    
This .zip file contains a number of small Z80/S100 bus programs to test the board    (V1.1  9/6/2019)
Z80_FPGA Board Layout                                                   
Supplied by Rick Bromagem  (V1.0 11/11/2019)
)
Z80_FPGA Board BOM (.xls)                                             
Supplied by Rick Bromagem  (V1.0 11/11/2019)
)
Z80_FPGA Board BOM (.pdf)                                              Supplied by Rick Bromagem  (V1.0 11/11/2019))
 



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

This page was last modified on 03/04/2020