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

A FPGA Disk Controller S100 Bus Board
  FPGA_DC Board (Prototype)
      

Introduction.

Our "IDE Disk Controller board" first released back 2009 is one of our most popular board. Well over 300 have been distributed worldwide! The board went through a number of versions, the last being a GAL based V3 version.

The board has proved itself to be very reliable and relatively simple to build.  However it suffered from two disadvantages. 
1.  It worked only with "real" IDE hard disks or more commonly,  using an adaptor with CF cards. 
2.  It utilized five TIL 311A LED HEX displays. These are becoming rare and expensive  (~$20 each from places like Jameco).

We will now utilize  a Cyclone IV FPGA to formulate a new board with enhanced characteristics.
With the power of this FPGA we can consider expand the capability of the IDE Disk controller board.

Beside the two IDE/CF card interface slots we will add two SD cards. These have become way more common than CF cards these days.
The TIL 311A Hex displays will be replaced by common/cheap standard 7 bar LED displays ($2 each).
For easy construction/debugging the FPGA can be configured  initially to act the same as the above original IDE/CF card disk controller board. In this mode CPM3 can be run unchanged from your current CF cards. However in this "test mode" the LED HEX display will not work and the SD cards do not work.

We will call this board an
FPGA Disk Controller board (FPGA_DC board).

If you are not familiar with FPGA's you need to read up on them. We have used them successfully on a number of our recent boards (e.g. a Z80 and 80286 SBC)
Much of what is written here assumes you are familiar with those boards.  There are introductions to FPGAs there as to how to program and use them.  If this is your first FPGA board you really have to read the write-ups on these boards first.  All the text below assumes this.

We will utilize the same Waveshare Cyclone IV board as we have done in the past.  This board contains all the circuitry to program the FPGA as well as onboard ROM etc.

The great thing about utilizing an FPGA chip like this is we can program it to act exactly like a very fast (12mHz) Z80 CPU with its own programmable ROM.  While RAM could also be programed into the FPGA , I have decided to add an external 256K RAM chip (a
256K HM628512).  This is way overkill, but in the future it would allow the Z80 to provide some sophisticated disk buffering -- something not implemented in the current software below.

I have changed the software interface between the S100 bus CPM (or MSDOS) BIOS and the two disk types on the board.  With the high speed Z80 onboard we can provide any S100 bus BIOS access to all disk sectors with only a few one byte commands.  This is the approach we utilized on our ZFDC floppy disk controller board.  It makes writing (or changing) an operating system BIOS very simple.  One set of commands is used for all the cards, all operating systems and all CPUs.   Everything passes through two S100 bus I/O ports.   No DMA is required even the slowest CPU (e.g. a 6502) can easily handle the data stream.   The on-board 12 MHz FPGA Z80 does all the heavy lifting.   The S100 bus simply specifies the drive, track & sector and whether it's a read or write.  That's it!

Unfortunately to do all this we really have to very carefully program the FPGA, both in terms of ROM Z80 software and actual FPGA circuits.  It absolutely has to be bullet proof with good redundancy in the case of errors.  The good news is we have total control of the FPGA Z80 . It's always in control.  We have its total 64K address space at our disposal.  We will utilize the bottom 32K for ROM code and the top 32K for RAM.  32K of ROM allows us to write quite elaborate assembly language code.  So much so that in fact we have three types of interfaces to the disks on the board.  

In the first mode, the Z80 can boot up as a typical Z80 "monitor".  All external communications are via an onboard USB port to an external PC  software TTY text window.    All the typical Z80 monitor commands you have seen in the past are there.  Here is a picture of the monitor menu.
  
    Monitor Menu2
Amongst the typical command Z80 menu  commands are ones to interface with the  IDE/CF card and the SD cards. 
We will talk about these later, but most are self evident.  These commands simply read/write disk sectors to the onboard RAM on the board itself.  Any S100 bus CPU is completely unaware of this process.  While its critical to the board build/debug process, for an S100 bus CPU/operating system it is not utilized.

The Second Mode of action is the one we normally use when the board is built.  It completely bypasses the above monitor and simply looks at two I/O ports on the S100 bus.  From an external point of view that's all the S100 bus operating system BIOS sees. The FPGA_DC board on power up and after initialization simply looks at these ports waiting for an "activating handshake" signal (byte) sent from the S100 bus CPU.  It then kicks into action doing whatever 8 bit command the S100 bus sends it.  This is the communication gate between the two systems.  It has to be simple and fast.  There is a status port and data port. The status port bits set/reset automatically depending on the data process.  The complete circuit resides within the FPGA and its Z80 module.  The S100 bus provides the sINP, sOUT, pWR, and pDBIN signals together with the S100 bus data in/out lines to the FPGA.  All S100 bus signals are switched to the 3.3V levels required by the FPGA with 74LVC245 IC's. The FPGA Z80 monitor can be configured to show in real time the commands being exicuted.
      
Here is a snap-shot example of the display coming over the USB port:-
     
   Runtime CMDs
   
This stream of messages will come over the USB port continuously as you boot and run a disk operating system. This makes BIOS debugging easier.  If bit 0 of the IOBYTE port (SW1), is closed of course the board runs at full speed but no "breadcrumbs" trail is sent.

The FPGA_DC.brd contains the FPGA "schematic" for this and all the modules within the FPGA.  Its fairly complex and should be studied carefully to understand how this board works.  That said,  everything within the FPGA can be treated as a "Black Box" in terms of getting the board to operate as a disk controller board. You should not have to modify any of the circuits for normal use.

There is a Third Mode where we program the FPGA to act in the S100 bus from a software point of view exactly like the original IDE/CF card board.   Any CF cards containing CPM  that runs on your IDE/CF board should run unaltered on this board in this mode (in both slots). This mode is not normally used, it is there to help build/debug this board.   The SD card slots do not work and the new HEX LED displays do not work. While not in the current FPGA code,  all this can be programmed into the FPGA later if desired but it defeats the purpose of using mode 2 which provides a much simpler BIOS interface.


The SD Card Interface
One major advantage of using an FPGA is that interfacing to an SD card is simple.  We use just 4 pins from the FPGA (an SPI interface with Card Select, CLK, Data Out & Data In).   The board has two independent SD cards and CF cards working together on the board.  The board utilized two Adafruit Micro SD Card adaptors.
       
  SD ard Adaptor 
   
In an earlier version of the board I also had an option for SparkFun adaptors as well.  I found unfortunately they do not work well together when sharing the same SPI bus data lines. Also one nice thing about the Adafruit adaptor it has its own surface LED that flashes when the adaptor is active.

All the SD card interactions are completely contained within the FPGA.  Since the voltages levels of the SD card are 3.3V we don't even need a voltage shifter for the FPGA.  
The two Adafruit Micro SD card adaptors also have a line that flags if each actually contains a card. Two independent lines are brought into the FPGA so the Z80 software can act accordingly.

Finally the cards are capable with a very high speed clock (2 MHz), however for initialization the clock has to be at a low 400 KHz rate.  A switch within the FPGA circuit does the trick, switching from 400KHz to 2MHz.  All that said,  in comparison to the CF cards,  sector reads and writes in "bit bang" SD mode are slower than reads and writes with CF cards.

The IDE/CF Card Interface.
For compatibility with the original IDE/CF Card this board also contains a two IDE interfaces.  Unlike the SD cards interface this interface does require hardware external of the FPGA.  In fact I brought across the exact 8255A circuit utilized on our IDE board.  At first this might seem unnecessary. Certainly an 8255 circuit can be formulated within the FPGA.  However when you total up all the external FPGA pins require for the 8255 "emulator" and the fact they have to shifted to 5V levels and they have to be bidirectional ports (all 3 of them), the board real estate is best served with a single good old fashioned 8255A.  Also this makes the FPGA Z80 code very easy since the code used in all our prior Z80 monitors can be spliced in directly. 

Both the SD and CF cards have way more capacity than CPM can be configured for and possibly for MSDOS in some cases as well, so in most case we will utilize only the early sectors on the "drives". 

Here is the circuit for the 8255A based IDE/CF card interface on the board:-
    
  IDE FPGA Schematic
    
In this day and age you are probably not going to use a real IDE hard drive with a cable.  Instead the drive is built to accommodate an IDE to CF card adaptors so an actual CF cards can be used.  They typically cost about $6-$20.   I have been using the "SYBA Multimedia IDE to CF Adapter" adaptor shown here:-
   
  IDE_Adaptor_1
 
We will plug the above adaptor into a right angled 20X2 row of 0.1" pins and that into a 20X2 female connectors in
P9 and P1 (see below).
There are other are adaptors. There is a nicer more compact one (#2 below), but the IDE pin socket order is flipped around.  That one needs to be plugged into a 20X2 connectors in
P10 and P15. So be careful of the socket pin numbering for all these adaptors. Pin 1 is always to the left of the notch on the IDE socket (top row), see above.  Check if the adaptors have the pins switched around.
Also while you can add sockets for
P9 & P10 and P1 & P15 if you are using adaptors in P9 and P1, the fit is better without the P10 and P15 sockets above it.
      
     CF Adaptors

You will notice there is also another set of 22X2 pin slots on the board (
P16 & P20). I added these for 44 pin "laptop" IDE adaptors versions with 2 mm pin spacing's (#3 above).  Unfortunately I could not get these CF card adaptors to work with software in the FPGA (spent 3 days on it!). For those that would like to try the relatively rare 22X2 pin header is DigiKey # 23-0877584416-ND.  The good news is the #2 adaptors are very common Amazon or the web in general. Use these if you can.
                                                                                                                                                                                                                                                                                                                                             
Board Height.
While on adaptors and sockets, there is one major decision you have to make, and that is the spacing distance between this board and the next board in the S100 bus.   You can either add a 20X2 female socket and a "standard" 20X2 right angled dual row header to connect it to the adaptor. This raises the adaptor above the board so that the HEX LED display chips can be placed in IC sockets, (see picture below).   Alternatively you can use a special 20X2 right angled dual row header to connect it to the adaptor directly.  This is a tight fit. You must use the longer pins for the IDE adaptor, the shorter pins just make it to the back side of teh board.  In this case the HEX LED display chips should be soldered directly to the board (see picture below). A better socket is the (DigiKey #
S2141E-20-ND) socket which has longer pins. .   This makes for a nicer low profile board with plenty of space before the board in front of it.
   
   IDE Socket1       IDE Socket2          IDE Socket3
   
The Drive, Track, Sector LED HEX Display Interface.
While clearly not essential for the board to function,  it's nice to always have a runtime display of the actual drive/track/sector the BIOS is working on.  In the past we used five TIL 311A LED HEX display on our IDE and ZFDC boards.  These are wonderful HEX display LEDs. They convert 4 bits directly into the characters 0,1,2...E,F.  Unfortunately they are no longer manufactured by HP and are in short supply and are thus expensive. The also tend to burn out and are power hungry.    All modern day 7 segment displays only decode the digits 0-9 from a 4 bit nibble.  In order to "hammer them into shape" you need to address the 7 segments directly starting with the 16 possible 4 bit nibble values.  Trivial to do in our FPGA Z80,  but you also need to latch the outputs for each digit (using a 74LVC373) and drop the current with an inline resistor network.  The 74LVC373 also up's the voltage to 5V.  Here is the circuit for one digit.
    
  Hex Display Circuit
   
A very straightforward circuit but unfortunately requiring some 15 IC's for all 5 Hex LED displays.  I could have used some SMT chips but I know some or our users have difficulty soldering these.  This circuit uses most of the space on the right hand side of the board. You will see that all 5 digits are latched in place with separate digit lines from the FPGA. They are not continuously sequentially scanned in -- saving a major drain on the Z80 overhead. This gives a nice very steady display.

Notes on CHS and LBA Addressing
On a PC (at least the early ones),  sectors are defined is terms of Cylinders, Heads & Sectors (CHS format). Parameters in early MS-DOS versions were passed via software interrupt INT 13H for sector reads and writes. INT 13H  designates sectors in a somewhat convoluted way (for historical reasons), parameters passed are always as follows:-
   
AH = 02h
AL = number of sectors to read/written (must be nonzero)
CH = low eight bits of cylinder number
CL = sector number 1-63 (bits 0-5)
high two bits of cylinder (bits 6-7, hard disk only)
DH = head number
DL = drive number (bit 7 set for hard disk)
ES:BX -> data buffer
   
Because only 16 heads are allowed with this format, a hard disk can only get to 512MG in size.   This is not a problem for 8 bit CPM systems since disk capacity was always less than 10 MG. To go to higher disk capacities with later version of MSDOS, the PC BIOS's utilized the so called "LBA" sector addressing mode.   In this case sectors are numbered on the disk as just one long number. Starting at 0 and working upwards. There are no tracks or heads. We use this format on our IDE board.

CF cards can be accessed in both CHS and LBA modes. Our FPGA code assumes all access to the CF card is in LBA mode, starting at sector 0,1,2,3...  SD cards don't even have the CHS mode option. All sectors are accessed 0,1,2,3...

However for CPM (and MSDOS) BIOS software we will work with drives, tracks and sectors.  We will allow up to 4 drives of 0FFH tracks and 0FFH sectors. All sectors will be 512 bytes in size.

For ease in debugging etc. the 5 digit HEX LED display will display the current drive, track, sector being accessed in this format.  The operating system never has to know about the CHS to LBA translation taking place within the FPGA.

Here is a typical display:-
       
   Hex Display
 
This would be the IDE CF card 1: with the current sector being Track 12 sector 34.


Step By Step Building the FPGA DC 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 voltage regulators.  Also do not add the MicroSD Card Adaptors yet. Please be sure you put the resistor arrays in with the correct orientation of pin 1, (the square pad). 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.  

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 either Mouser chips # 595-SN74LVC245AN.   The WaveShare Cyclone IV adaptor can be obtained directly from Waveshare or Amazon 

The WaveShare unit uses unusual 2mm dual row female pin connectors. Unlike to normal 0.1" connectors these are quite rare an expensive (Digi-Key #S5750-30-ND). You need to carefully cut them to size, carefully cutting off the extra pins with a wire cutter.  Better sockets are available from Mouser (Preci-dip 833-87-038-10-001101)  as part 437-8338703810001101 for $3.04 each.

Please note the Digi-Key #S5750-30-ND 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.  The Mouser ones don't have this problem but you  need two of then for the FPGA side pins. All sockets need to be trimmed to the requires pin number.  The 2mm spaced male pin headers are DigiKey #0877584416.


To remove the FPGA 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.

The USB serial Adaptor and Micro SD Card adaptors are from Adafruit.

Note there are two sockets for the Pololu 5V and 3.3V regulators. While the older ones (D24V25F5 and
D24V25F3) are still available and use P3 and P4, it seems Pololu is suggesting users use the newer D24V22F5's (5V, 2.5 Amp) units, it has a different pinout, use this one in P2 (not P3).  More recently they also added the equivalent D24V22F3 3.3V regulators. Unfortunately in their wisdom they again changed the pinout connections. You must use the Pololu D24V25F3 3.3 V regulator in P4 or the D24V22F3 regulator in P21.   Be sure you get these regulators/ correct. To be safe once inserted check the voltage in your system on a 5V and 3.3V IC, (see the schematic) with no chips yet inserted on the board.

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.
         
At this point insert the board into your system and check your Z80 monitor boots fine.  If not check for solder bridges etc. Also do one last check to be sure every IC solder pin is soldered.  Seems trivial, but I don't know how many times I got caught with this error.
 
Next we need to solder in the three ICs U10, U15 & U16
directly to the board.  If possible use known working 74LVC245's from a previous board.  You don't want to have to remove a faulty one later. Take care not to scorch the chips. If possible have the chip pin just barely show on the back of the board for soldering.

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.  Previously programmed by you FPGA boards of course will not.

In any event open the  Quartus FPGA_DC project folder (the expanded
FPGA_DC.ZIP download, see bottom of this page) and program the FPGA using the FPGA_DC.brd file.  This is a somewhat tricky process. You need to look at and understand the previous FPGA board entries (e.g. a Z80 and 80286 SBC) if this is new to you. 

Now would be a good time also to study in detail the FPGA.brd  file to understand how the board "works".  Remember the FPGA utilized its own internal 12 MHz Z80 and so utilizes  a .HEX file for its ROM code.  This .HEX file resides in the
FPGA_DC\ROM_HEX_FILES sub-folder.  The source  for this file  is FPGA_DC.Z80.  You don't need to alter this file for normal use but its also provide in case you need to.  

Should you wish to "play around" with this file,  I supply it and its components in the folder
FPGA_Disk_Controller Board where it can be assembled on a PC using Altair.com etc.
Be sure to move the final
FPGA_DC.HEX file to the Quartus FPGA_DC\ROM HEX FILES folder when done as Quartus is counting on finding the Z80 Monitor.HEX file there.

If you program the onboard Cyclone IV FPGA at this point nothing will happen except the LED D10 (Board Active) LED will pulse.  This must happen. Do not go further unless it does.

Next install the following IC's:-
U4, U7, U2, U8 and the RAM chip U5.

Install the Sparkfun FT231x USB adaptor. Note it has a jumper on its back for 3.3V operation, use 3.3v not 5V. Add the two Adafruit SD card adaptors in "
3:" and "4:"  You can solder these adaptors directly to the board or use sockets.  See the section above on soldering sockets. I suggest direct soldering.  Note the USB FT231x  adaptor actually has 3 sockets. The two side ones are not used here and are only there to steady the adaptor on the board. I use only pin 1 in each case. You can also use the Adafruit CP2104 USB adaptor equivalent adaptor.  Perhaps it's just me,  but sometimes I've had problems getting this adaptor to link up with my PC's.

The default software on this board assumes a USB port running at
38,500 BAUD, 2 stop bits, no parity.  (This can be changed within the FPGA_DC.brd file).  There are a number of Windows/PC programs you can use to receive and display the data.  I like Absolute Telnet  from Celestial Software, but others are free.

The board has an "IOBYTE" switch (
SW1), which defines what the FPGA_DC Z80 monitor does on power up.  The default mode, all switches open, (no switch) causes the Z80 monitor to get 0FFH from port 46H after a reset.  This is the boards normal mode of operation but we will not use it yet.   Currently only two switches are utilized:-

Bit 0 (Pos 8), (Reading left to right), when closed, (xxxxxxx0H), this causes the board to send status information to the USB port during every step of its operation.  A remote PC can thus watch how commands sent from the S100 bus are operating during "disk" operations. This slows down the Operating System BIOS a little but is invaluable for debugging etc. When open no commands are sent.

Bit 7, (Pos1), when closed, (0xxxxxxxH), this causes the board upon reset to bypass the S100 interface and go directly to its onboard monitor.  The onboard monitor contains all the "normal" commands for a Z80 CPU, display/change RAM, ports etc.  but it also contains two very special command I and U
.

Here is a picture of the board at this stage:-
       
   Stage 1
   

Place the board in the S100 bus with
SW1 positions 8 and 1 closed.  Power up and again load the FPGA_DC.BRD file into the FPGA. Upon reset the FPGA will boot up its Z80 monitor. You should see the following display:-
     
    Monitor Menu
 For now just use the Z command.  This will bring you directly to the FPGA Z80 CPU monitor. You should see the following:-
   
    Monitor Menu2
Most of these commands should be familiar to our users. (The
X command BTW, is not yet implemented).

Play around with the regular Z80 monitor commands (except
I, U and X)) at this stage to get comfortable with the interface. 
For example the A command will show you the "Memory Map" for the Z80 on the board. 
    Memory map
 
Next we will install the IDE/CF card circuit.
Install the 82C55 U26 chip.
Add U9 and U12. Note U12 is a regular 74LS245 (or better 74F245).  Add U1, U13 and U14. Add U20 and U21.
Add both jumpers SW3 (both horizontally). A switch could also be used here -- it controls the 5V power to the IDE interface.
Jumper K1 and K2 2-3  (top two pins in each case).
Install the 8 jumpers between P27 and P25  and between P23 and P24.
Install your one or both of your IDE adaptors each with a CF cards.
Also install one or both AdFruit Micro SD Adaptors
Power up, load up the FPGA again and from the USB port menu select the "1" menu option.
The board should look like this at this stage:-
   
   Stage 2
  
The IDE Sub-menu should come up as shown here:
             
     IDE Card Menu
    
What remains is the circuit to display the current Drive, Track and Sector in the LED Hex Displays.
Before adding the chips please re-read the section above about "Board Height".  Add a the chips with or without sockets (see above).
Be careful with the
MN71A HEX displays they are a little fragile.
Here is a picture of the board at this stage (without the IDE Adaptors).
    
     Bare Board 4
   
The board is now fully setup. What remains to be done is understand the fairly extensive software menus and commands.

THE FPGA Z80  MONITOR COMMANDS
As described above the board can initialize in three completely different ways.  If Bit 7 & 0, (Pos1+8), is closed, the Z80 reads (0xxxxxx0H) from the IOBYTE port (
46H) and goes into its internal monitor mode.  There is in fact no connection with the S100 bus. The only communication with the outside world is via the USB port.

Normally one would not go to the
Z command but would select one of the 4 "Drives" 1,2,3 or 4.

The sub-menu
"U" (SD cards) or "I" (CF Cards) are essentially the same for both "drive" types -- on the surface. 
Of course within the Z80 code they are very different, but you as a user don't need to worry about this.
Here is the sub menu for the IDE drive:-
   IDE Menu 2

The "current sector" under consideration is always shown.  In this case
Drive 1: Track 0, Sector 0.
If we enter "R" we will display its contents  (all 512 bytes):-
  
    Sector Display
Most of the commands are self explanatory. The copy command copies the current sector to another specified sector location on the same disk. The verify command checks they are identical.
The
"Y" command displays information about the "disk".
    Disk parameters
A few non-obvious shortcuts:

If asked for a sector number, a CR will enter the current Track, Sector.
All track, sector information are in hex values in the format xx,xx (+CR).  So a maximum of FFH,FFH tracks and sectors on a drive.
So a "R" command above followed by a CR will display the sector on Track 0, Sector 0
The "R" with 12,34 then a CR will display the sector on Track 12, sector 34.
While we will see later when we operate from the S100 bus, in this "local" mode you cannot move/view etc. sectors across drives.
To explore a different drive enter ESC and select from the menu another drive.

On the drive menu, you will note that the drive menu 1,2,3 or 4 will have a "*" beside it if it was previously initialized.
On the drive menu , you will note a message for drives 3 & 4 if no SD card is present in the adaptor.  Unfortunately IDE cards don't have this option.
Finally you will note that usually all drives are 0FFH Tracks and 0FFH sectors/track.  There is an option to change this which we will discuss later.   
   No Card menu


THE S100 BUS INTERFACE
Having satisfied ourselves that we have the onboard hardware working correctly we will now proceed to have the board interface with the S100 bus as a true disk controller  board. That said,  do not go to the S100 bus mode unless all the above commands work flawlessly.

First we open Bit 7, (Pos 1) of SW1.  This dramatically changes how the FPGA Z80 operates after reset.  The FPGA_DC board now comes up in normal work mode.  Initially its Z80 scans the S100 input port waiting to receive a "Handshake CMD". This is a
21H byte sent out on the S100 bus to output port (81H).  It responds by echoing this byte back on the S100 bus input port 21H.  With this the S100 bus Disk Operating system BIOS knows the FPGA_DC board is alive and well.  The two then continuously interact with other via series of single byte commands.  Normally this is done in your operating system BIOS. 

This CMD driven approach was first used with our ZFDC Floppy disk controller board now some 10 years ago!  It turned out to be very successful and reliable allowing a very simple CPM BIOS to access 8", 5" and 3.5" floppies is over 50 different formats with a few very simple set of byte commands.  It used the same idea we have here,  the boards local Z80 does all the dirty work of finding a sector on a requested drive given just the track and sector number.  I am doing a V2 of that board currently which now has as well two IDE/CF card adaptors (like we have here).  In order to simplify the BIOS software with all 3 boards this FPGA_DC board will use the same CMD format. We will just add a few extra commands not found on the original ZFDC board commands.
Here are the main commands for this FPGA_DC board:-

CMD_SEL_DRIVE       EQU 5H      ;**** (Re)select an already initilized drive
CMD_SET_TRACK       EQU 7H      ;**** This will set head request to a specified track (ONLY)
CMD_SET_SECTOR      EQU 9H      ;**** This will set sector request to a specified sector (ONLY)
CMD_READ_SECTOR     EQU 10H     ;**** Read data from the CURRENT sector (on current track,(side),drive).

CMD_WRITE_SECTOR    EQU 11H     ;**** Write data to the CURRENT sector (on current track,(side),drive).
CMD_FORMAT_TRACK    EQU 16H     ;**** Format the disk in the of the CURRENT drive using the current format assigned to that disk

CMD_INIT_DRIVE      EQU 30H     ;Select AND Initilize the current drive
CMD_SET_TRK_SEC     EQU 31H     ;Set new current TRACK AND SECTOR on current drive
CMD_GET_DRV_TRK_SEC EQU 32H     ;Get current TRACK/SECTOR on current DC Board drive
CMD_CLEAR_SEC       EQU 33H     ;This will set all current drive sector bytes to a specified byte value
CMD_MOVE_SEC        EQU 34H     ;Copy/Move one sector to another location on current drive
CMD_VERIFY_SEC      EQU 35H     ;Verify two sectors are the same on the current drive

CMD_BUMP_SEC        EQU 36H     ;Point to the next disk sector
CMD_BACK_SEC        EQU 37H     ;This will set "head" to the previous sector
CMD_GET_BUFFER      EQU 38H     ;Get contents of RAM sector buffer on DC board
CMD_RD_N_SEC        EQU 39H     ;Read N sectors
CMD_WR_N_SEC        EQU 3AH     ;Write N Sectors
CMD_CPM_BOOT        EQU 3BH     ;Send CPM Boot image to S100 system (CPM$SEC$COUNT sectors)
CMD_DRIVE_COPY      EQU 3CH     ;Copy one complet drive to another
CMD_SD_DISK_STATUS  EQU 3DH     ;Get status of cards in SD Disk adaptors
CMD_START_WATCHDOG  EQU 3EH     ;Start watchdog timer hardware (not currently active)
CMD_GET_NSCTRS      EQU 3FH     ;Get SEC/TRACK for defined drive


For a CPM (or MSDOS) BIOS only the 5 commands in yellow are needed. The rest are extra for testing and diagnostic purposes.
That said the commands absolutely have to be bullet proof and 100% reliable.  The S100 bus OS BIOS does not know or care what type of disk is talking to. 
It also has to be fast. There is a single 8 bit port bridge between the two systems and a second status 2 bit port.  The core of FPGA_DC.BDR circuit is shown here:-
   
    S100 Interface ports
  
While it is not necessary to understand this circuit to use the board you might want to study it to get a feel how the board works.  In essence the FPGA Z80 just sits waiting for its port
80H (bit 0) to get a CMD byte (21H) from the S100 bus.  It reads the byte  automatically sending back to the S100 bus port 80H an acknowledge byte (21H) that the data has been read.  The FPGA Z80 then processes further commands each time sending a "CMD Complete" byte indicating the work is done.  Commands may have follow on bytes of data. For sector reads and writes for example there will be 512 of these.   The interface status ports (bits 0 & 7) on both sides is port 81H.

While this sounds complicated in actual reality writing BIOS software is very simple. 
Further for debugging, as I mentioned above if  we open Bit 0, (Pos 8) of SW1 each and every command processed by the FPGA Z80 will first be listed on the USB TTY output. 
Here is a "breadcrumbs" trail of where we initialize an SD card in drive 3:
Copy its Track, Sector 00,00 to Track, Sector 12,34
We then verify that both sectors are identical:-
  
    Sector Copy
  
This brings us to the next part of the software --  the S100 Bus diagnostic program.

The FPGA_DC Diagnostic Program
Before we take on the fairly complicate task of writing a full blown CPM3 BIOS to utilize this unique board it would be quite useful to have a S100 bus diagnostic program that sits in RAM at
100H upwards to test the board interface.  We essentially transplant the FPGA Z80 monitor disk commands to the S100 bus.  As we will see we elaborate on them to allow multi disk transfers, reliability checks and anything else that assures us the board can handle a CPM3 or MSDOS BIOS.

For debugging etc.  I have written a Z80 program (
DC_DIAG.Z80)  that resides in the S100 bus RAM at 100H.  It assumes the FPGA_DC ports are 80H and 81H and the Console IO is our Propeller Console IO board (ports 0H and 1H). Because it resides at 100H it can be loaded with CPM (later!), but for now you must download it from your PC via a serial link and the Z80 Master monitor X command (X100).  By now this process should be familiar to most of our users.  There are other ways to do this, but in the end you need to have the DC_DIAG.COM (or DC_DIAG.HEX) reside at 100H in RAM and jump to 100H from a Z80 S100 bus monitor.

It will sign on as follows:-
   
     DIAG_DC
 
After you select the drive you wish to work with the above menu will appear.
As you can see this is a more elaborate version of the onboard FPGA monitor commands.

Again most of these commands are self-evident. A number take one or more follow-on single byte parameters.  Some return to the S100 bus one or more single byte values.  In all cases they must return the
CMD_COMPLETE (F0H) byte value confirming to the S100 bus BIOS that the requested operation completed successfully.  Anything else is regarded as an error and the BIOS must act accordingly.

On the
FPGA_DC Z80 monitor side the interpretation of these commands can be quite involved but on the S100 bus side (all the user has to be concerned with in writing a BIOS) it makes things very simple. In fact almost all the commands are one of five commands:-
 
CMD_SEL_DRIVE       EQU 5H      ;**** (Re)select an already initilized drive
CMD_SET_TRACK       EQU 7H      ;**** This will set head request to a specified track (ONLY)
CMD_SET_SECTOR      EQU 9H      ;**** This will set sector request to a specified sector (ONLY)
CMD_READ_SECTOR     EQU 10H     ;**** Read data from the CURRENT sector (on current track,(side),drive).

CMD_WRITE_SECTOR    EQU 11H     ;**** Write data to the CURRENT sector (on current track,(side),drive).
CMD_INIT_DRIVE      EQU 30H     ;Select AND Initilize the current drive

All 4 drives are always available. The default drive format is up to 0FFH tracks, 0FFH sectors/track and 512 byte sectors. 
These parameters can be easily changed by a "Disk Parameter Table" at the end of the FPGA Z80 monitor code (or by setting
bits 5 & 6 of the IOBYTE switch, see below).

For those that have built and used the ZFDC floppy disk controller board they will recognize this command driven approach.   However because CF and SD cards are quite different the actual commands and the Disk Parameter Tables are different. The Z80 IX register always points to the start of this table. 
Here is the Disk Parameter table for an SD Drive:-

IDE_DRIVE_1:
    DB 0FFH       ;0 Disk HW_BYTE
    DB 0FFH       ;1 Default Card Present
    DB IDE_CS_1   ;2 DRIVE_CS, actual Drive CS* Line
    DB 1          ;3 Drive NUMBER
    DB 0          ;4 INITILIZED, unutilized
    DB 2          ;5 512 Bytes/sec flag
    DB 0          ;6 Tracks set aside for operating system (egg CPM 2 for floppies)
    DB '1'        ;7 ASCII of Drive #

    DW 512        ;8 <------ 512 Bytes/sec
    DW 00FFH      ;10 SECTORS PER TRACK:- (Was 3CH (60)for my on old CPM3 for Kingston CF 8G).
    DW 00FFH      ;12 Max Tracks
    DW 0000H      ;14 TRK, Current Track
    DW 0000H      ;16 SEC, Current Sector
    DW 0000H      ;18 LBA_TRK, Current LBA Trk
    DW 0000H      ;20 LBA_SEC, Current LBA Sec
    DB 'IDE/CF Card Drive 1 ',0
          
The advantage of this command driven approach is that the current S100 bus CPU does not have to go into DMA mode or sync the bus with wait states when reading or writing sectors. Any of our S100Computers CPU boards, in fact in theory, any manufactured CPU board,  should work in this system.  The downside is that disk access is a little slower.  Not as slow as you might think however because while the requested sector parameters are passed back and forth with above commands and handshaking,  the actual 512 bytes of data transfer across as a block over the connecting bridge port one byte immediately after the other using the Z80 block IO instruction.  Normally you will notice no difference with say a few sectors moved with CPM or even MSDOS.  However a total disk copy from one drive to another will be slow.  The monitor in fact has a special disk copy command to help with this (
CMD_DRIVE_COPY EQU 43H) a little.  Remember these CF and SD cards have an enormous capacity -- way outside early days CPM or MSDOS.  Copying the first few "tracks" usually is all that is required.

For those that wish to play around with the software there is 512K of RAM available to the Z80 FPGA. Some fancy sector caching routines could be implemented.  Also for MSDOS,  multiple sectors could be written or read with a single command.  If you develop code improvements please let me know.

Hardware/Software Debugging.
This is  a relatively complex board. Things are complicated by the fact that much of the circuits reside within the FPGA.  However I have split the FPGA_DC.brd file into discrete sections such as the Z80/ROM section, the serial/USB port section, the SD cards section, the IDE/CF cards section etc. 

There are three basic levels of difficulty:-

1. You cannot get to the main menu of the onboard Z80 monitor
2. Some of the SD/CF card routines don't work correctly
3. The S100 interface does not work correctly with the board.

Option #1 difficulties are the most serious.  Most lightly they are due to a bad solder joint, a bad IC socket or IC,  or an incorrect placement of the latter.  A key flag is if the "Board Active" LED
(D10) pulses when the FPGA is programmed.  If this does not occur rip out every IC on the board except the FPGA adaptor. If it still does not work you have either a power problem a faulty Cyclone IV adaptor or a programming problem. If you have a flashing LED,  then step things along adding one IC at a time.
 
If you have a flashing LED D10  you might next suspect the FPGAs access to the onboard RAM chip (
U5).  See if the RAM read/write pins are pulsing. The address lines are changing and the data lines are pulsing.

Next up is to suspect your Serial/USB port adaptor interface.  If you have another board with a similar serial/USB port check your PC can interact with it at the same
38500 BAUD.  If it's OK check you are seeing the LED on the Adafruit adaptor pulse as it sends data to your PC.

If these are OK you may need to modify the code for the FPGA Z80.  Bring up the
FPGA_DC.Z80 file. You will see :-
;
H_TEST1       EQU    FALSE           ;For initial hardware debugging
H_TEST2       EQU    FALSE
H_TEST3       EQU    FALSE
H_TEST4       EQU    FALSE
H_TEST5       EQU    FALSE

One at a time set the
EQUATE TRUE.   For example setting:-
   
H_TEST1     EQU TRUE
 
you should see an
'@' character on the USB port/PC TTY windows terminal.  Step things along within the monitor code to determine where the problem is.
Remember the board must work 100% reliably in local mode before you activate the S100 interface
(SW1-8 closed, bit 7 = 0). 

If you run into #2 problems with the SD or (less lightly) CF cards your first option should be to reformat the cards in windows.  Failing that, try a different card.  It appears all these cards don't behave the same -- particularly initializing the SD cards.  You will have better luck with the older (
a few GB) Type II cards than with the new very high capacity cards.   As a last resort you could try changing some of the software short time delays in the SD cards SPI interface code.  Here is a picture of some of the cards I use that are 100% reliable:-
        
     4 CF Cards
   
Type #3 problems tend to be the easiest to fix.  They will center around the four port bridge interface between the FPGA_DC board software/hardware and the corresponding S100 bus.  First be absolutely sure you do not have any other board in your system using ports
80H & 81H  The board assumes IEEE-696 signals for pSYNC, pDBIN, sINP, pWR* and sOUT.  Also address 16 address lines and the 8 data in and out lines.  16 bit port IO addressing is assumed (the upper 8 lines being zero), though this can be easily bypassed within the FPGA.

In every case you can step the FPGA_DC board along by simply sending one command byte at a time to out port
80H, wait for the acknowledge byte to come back on the in port 80H.  

There is one special CMD called
CND_ECHO (00H) that is quite useful.  This commands sets the FPGA_DC board/S100 interface up to simply take a keyboard character entered on the S100 bus side and simply echo/return it.  It should repeat every character you type -- no matter how fast. The ESC character terminates this command.  Again this command must work 100% reliably.

Long term users of the IDE/CF board will remember that there was an issue with CPM BIOS code and the assigned sectors/track format (see here).  To recap,  it was originally written for use with the board and a "real" IDE hard disk, a Seagate Medalist 6531 ULTA ATA drive.  This was a fairly popular drive at the time (1998), and is still often seen today on eBay.  It had 13446 cylinders, 15 heads and 63 sectors/track,  (6.5 GB Capacity).  In order to have only one CPM3.SYS image on all disks and all CF cards we used a  format of 61 sectors per track (with the possibility if need be, to use the spare sectors if needed for bad sectors).  This complicates the BIOS unnecessarily. Some changed the format to 6F sectors/track. Somewhat better. 

For all CF and SD cards here,  we will use 0FFH sectors/track.  This is the default table in the current FPGA Z80 code.   However to facilitate copying files for the two "old formats" The FPGA Z80 code can be modified with
SW1 bits 6 & 5  for drive 1: and bits 4 & 3 for drive 2:

SW1
x01xxxxx  FFH tracks,   61 sectors per track for IDE/CF drive 1:
SW1 x10xxxxx  FFH tracks,   6F sectors per track for IDE/CF drive 1:

SW1 x11xxxxx  FFH tracks,   FF sectors per track for IDE/CF drive 1:


SW1
xxx01xxx  FFH tracks,   61 sectors per track for IDE/CF drive 2:

SW1 xxx10xxx  FFH tracks,   6F sectors per track for IDE/CF drive 2:

SW1 xxx11xxx  FFH tracks,   FF sectors per track for IDE/CF drive 2:


Please note this designation is only activated with a board reset when each CF card is initialized (or by pressing the reset button SW2 on the board).  For example if you initialize drive 1: with SW1
x01xxxxx the FPGA Z80 code will assume that card has a format of FFH tracks, 61 sectors per track.  This allows one to conveniently transfer files from an "old formatted" CF card to the new more efficient format.  This option is only rarely used, it should be used with extreme care remembering the "old formatted" CF cards must have been written with a CPM BIOS of 61 or 6F sectors/track and the "new" (2:), disk CPM BIOS is set to expect 0FFH sectors/track.
  
    SW1
  
The initial drive selection menu will always show you the current IDE drive format assumed by the FPGA Z80 code:-     
   No CF Card Menu


Mode 3.
One final debugging option is "Mode 3"  mentioned above. Again this will be rarely used. To use this board debug mode you need to load a completely different .brd file into the FPGA. Its called FPGA_IDE.brd  (see bottom of page).  This is a rearrangement of the FPGA code which is written to directly read the data from the 8255 via the S100 bus exactly like the original IDE/CF board.  Any CF card running CPM on our IDE/CF board should run immediately and unchanged in this mode.  No changes to the board are required

The FPGA code connects the 8255 chip via IN/OUT buffer directly to the S100 bus (via U9 and U12) -- just as in the IDE/CF board.  It allows you the test the IDE/CF card circuit.  Note in this mode the LED HEX displays will only show the current drive  (1 or 2).  While one could fabricate the track/sector circuits within the FPGA as was done in the original IDE/CF card I have not had time to do this yet.   Also remember the SD drives are not active in this test mode.  This mode  is really here only for test purposes.

Software

Installing CPM3 On The FPGA_CF Board.
In order for this IDE card to be of any practical use we need to install CPM (and later, other disk operating systems) on drives interfacing to it.  We could start with CPM version 2.2, but it is actually far easier to write a BIOS for CPM3 because CPM3 takes care of buffer sizes greater than 128 bytes internally (all IDE and SD drive sectors are 512 byte sectors) and is in general is a more practical and expandable system. 

I should add if somebody wants to use CPM V2.2 you only need to change the Disk Parameter Table to 128 byte sectors (instead of 512) -- wasteful,  but "drive" capacity is never an issue here.

Before writing a CPM3 BIOS for this board please read the write-up I have in the software section of this site about setting up a CPM3 system on a floppy disk system and the original IDE/CF Board. Please read here  and  here

If you have written a CPM BIOS before you will find hammering one into shape for this FPGA_DC board is in fact fairly easy.  If you have not written a CPM3 BIOS you will have to spend some serious time studying the above web pages. 

To get people going I have include a basic CPM3 BIOS that assumes just a Propeller Console IO board for Console I/O and this board.
I have include a program
DCSYSGEN.Z80 to write the built Digital Research CPM3 operating on to the IDE/CF Drive #3 or #4 system tracks.
This CPM3  BIOS assumes only 4 drives. Two CF cards and two SD cards, no floppies, printer etc.

Please go to the software section of this web site for instructions and relevant files for Install CPM3 on the FPGA_DC board. (
the be added later)

Source of chips
Most of the IC's use on this board are common 74LSxx chips available from numerous sources such a Jameco, Mouser & DigiKey. 



Bugs
No reported bugs so far.

     

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, "group purchases" will be offered soon.  Please keep an eye on the Google Groups S100Computers Forum for an announcement.

 


The links below will contain the most recent schematic of the above boards.
Note, it may change over time and some IC part or pin numbers may not correlate exactly with the text in the article above.

 

(To be added later....)

MOST CURRENT FPGA_DC BOARD SCHEMATIC (V1.0)
Most current KiCAD files for FPGA_DC V1.0 
MOST CURRENT PARTS LIST (V1.0) 
Software for FPGA_DC Board 


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


This page was last modified on 02/26/2021