S100 Computers - My System IDE Drive Interface Board

A FPGA Disk Controller S100 Bus Board


Introduction.
Let me say first -- this are not an easy boards to build! I spent over a year on it with some different 8 hardware prototypes. The Z80 assembly language is over 7000 lines of Z80 assembly code! The difficulties are not due to complex FPGA/electronic circuits but rather the large number of possible software and hardware configurations. The "final" board should be the last S100 bus disk controller you should ever need! It will handle most IDE hard drives, most CF cards, most SD cards (with adaptors min & max sizes). Almost all 8" floppy disk formats (Single & Double Density, Single and Double Sided). Almost all 5" Floppy disks and 3.5" floppy disks. In fact the only floppy disk types not covered are hard sectored Northstar and Micropilis disks. Examples of a CPM3 BIOS are added for some common disks and formats. In all cases the approach is to vastly simplified the CPM3 bios by having it issues simple one byte commands to the 40mHz Z80 CPU within the FPGA on the board. This controller handles all disk access including initialization, sector read writes etc. Except for some tables within the CPM3 BIOS, CPM3 has no knowledge of the disk hardware -- nor does it care to! Everything is taken care of by this FPGA Disk controller board.

The early board prototypes started life as self contained S100 bus single board computers. Indeed this one board in the bus could in theory boot up and run CPM.   This was the basis of molding the system into a relatively complex hardware setup to present the onboard disk hardware to an external S100 bus master (or slave) CPU.    The bridge between the onboard drives/software and the "external" S100 bus is via two S100 bus 8 bit bidirectional data ports. Everything on the S100 bus side goes across this I/O port bridge. There is no DMA, no S100 bus wait states etc. This command driven approach makes for very simple disk operating system BIOS's and is of course completely CPU independent.

In one sense this board is a combination of the hardware on our "IDE Disk Controller board" first released back 2009 and our ZFDC Floppy Disk Controller first releases back in 2010. Well over 400 of these boards have been distributed worldwide!   Instead of using a traditional GAL or Z80 CPU, we utilize an Intel Cyclone IV FPGA. A Z80 CPU emulator within the FPGA (running at speeds up to 40MHz) handles all the software. In particular at this speeds floppy disk sector access is so fast as to be able to read even Double Density Floppy disk sector data "on the fly" without DMA/wait states etc.

Unfortunately all this comes at a cost of some considerable complexity. Realizing that many of our members are new to FPGA's I have decided to present this board in 3 different formats of increasing complexity. In all 3 cases the same Waveshare FPGA module is used and the exact same software is utilized.

The boards are:-
FPGA_DC + IDE Board. This board is in essence an FPGA driven version of our IDE/CF Card Disk Controller board It can be configured into 3 different hardware "modes" (See below). To help get people started it has a default mode (Mode 0), where it behaves exactly like the IDE/CF Card Disk Controller board. In this way you can boot any IDE/CF card version of CPM3 directly from this new FPGA Board unmodified.    (This unfortunately raised the complexity of the board and its software considerably and caused me a lot of headaches initially!).

In this mode the actual sector read and writes are done directly via the S100 bus with the 8255A IO Chip. Any "old" IDE/CF card BIOS does not know it is talking to a new disk controller. However the FPGA DC Board actually initializes the IDE/CF card hardware before transferring control to the S100 bus. A second initialization by old BIOS software does no harm but actually is not required. The actual sector R/W routines are very simple (and fast), but are not single byte "command driven" as the board is really setup for. This mode is there to get users quickly started with a working disk system. As an extra, a 5 segment LED Hex display always shows the current Drive, Track and Sector. Another mode (Mode 1), allows the IDE/CF/SD Cards to be accessed in a simple one byte command driven approach.

FPGA_DC + FDC Board. This board is in essence an FPGA driven version of our ZFDC Controller Board This board interfaces the Western Digital 2793 Floppy Disk Controller to a Z80 emulator within the Cyclone IV FPGA. The Z80 runs very fast -- for the core disk sector data transfers 40MHz, so the CPU is not the rate limiting step and so can run in a simple chip status mode without DMA or wait states. Utilizing the disk parameters table driven approach of the ZFDC board, any 8", 5" or 3.5" disk format can be easily utilized. Again understanding what is going on is fairly complicated but this time the board is completely byte command driven as was done for the ZFDC Board. Again a CPM3 Single Density Single Sided 8" disk should boot unchanged with this board. As for the ZFDC board, a 4 segment LED Hex display always shows the current Track and Sector.

FPGA_DC + IDE + FDC Board. This board is a combination of the two above boards. Needless to say it is much more complex. For beginners in particular I highly recommend you start with the above two boards first. BTW, the same FPGA software is used for all three boards. Two jumpers on each board redirects the FPGA to the relevant circuits.

Finally all three boards contain a Clock/Calendar chip which can be utilized by a CPM3 BIOS to time stamp files.

I will now go through a detailed description of each board and its build process.

FPGA_DC + IDE Board
In a certain sense this is the simplest board. For one, there is no disk signal adjustments or a multitude of different disk formats to deal with.

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.

Please read:- FPGA Programming for S100Computers Boards

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 (40mHz) 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.

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 drives, all operating systems and all S100 bus 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 40 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 (~8000 lines of code). So much so that in fact we have three types of interfaces to the disks on the board.

In the Monitor 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.

Amongst the typical command Z80 menu commands are ones to interface with the IDE/CF card (and the Floppy disks -- not used with this board). 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 Disk Controller 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 a command (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 as we will see below to show in real time the commands being executed., which drive, track, sector is been utilized etc.

Here is a snap-shot example of the display coming over the USB port:-

This stream of messages will come over a USB port from the board continuously as you boot and run a disk operating system. This makes BIOS debugging easier. If bit 0 of the IOBYTE port (SW1) on the board is open 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.

Within this Disk Controller Mode there are 3 sub-modes in which the IDE/CF card part of the board can work.

IDE Mode 0. In this mode the IDE circuit acts identically to the original dual IDE/CF board mentioned above. The 8255 appears on the S100 bus exactly as for that board. All software (e.g.. a CPM BIOS), works unchanged. You should be able to boot any operating system on your old CF cards directly in this mode. This comes at a price. There is limited diagnostic real time information passed back on the USB port terminal. The external 8255 port writes do trigger an interrupt in the FPGA Z80 so it displays the current drive, track and sector being accessed -- but no more than that.

IDE Mode 1. In this mode the IDE/8255 circuit is brought under the direct control of the FPGA. This mode will not work with the old CPM3 BIOS software - unmodified. All BIOS functions are sent to the FPGA with a few simple Byte commands. All CF card initialization, drive, track, sector requests can be contained in a few very simple commands. This exact same command structure approach is used for all the Floppy BIOS requests as well. In IDE Mode 1 a more extensive run time display of drive access is sent to the USB port terminal.

IDE Mode 2. This mode is a hybrid of modes 0 and 1. The IDE circuit is again external to the FPGA but more diagnostic information is passed back to the FPGA. Card initialization and checkout for example is still done within the FPGA. For this mode any current BIOS will need to be slightly modified. The changes are relatively quick and simple however.

In all cases the BIOS routines for all types of disk access is the same. Its essentially as we have done for the ZFDC Floppy disk controller board. Here are a few commands as examples:

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

CMD_SET_SECTOR EQU 9H ;This will set sector request to a specified sector

CMD_READ_SECTOR EQU 10H ;Read data from the CURRENT sector.

CMD_WRITE_SECTOR EQU 11H ;Write data to the CURRENT sector.

The important concept to remember with this board is the same commands are used for all drives/cards (IDE, mini SD, micro SD) and as we shall see later for the FDC version of the board 8", 5" and 3.5" drives). The operating system BIOS does not have to know anything about the drive initialization, track/sector seeks etc. As you might expect the is a slight overhead involved for disk access with this approach. Since the FPGA_DC Z80 is running at 40MHz for floppy access the bottleneck is always the disk drive -- even for high capacity double density disks. For the IDE/CF/SD drives/cards there is a slight delay -- about 2X for sector R/W's. This is unnoticeable when running CPM3 but does show up in for example a "pure" disk copy of one card to another. This is why we have IDE Mode 2. In this mode the actual core sector R/W routines reside in the (CPM) BIOS.

The IDE/CF Card Interface.
For compatibility with the original IDE/CF Card this board also contains a two IDE interfaces. 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:-

In this day and age you are probably not going to use a real IDE hard drive with a cable (but you can). 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-$10.   I have been using the "SYBA Multimedia IDE to CF Adapters". We will plug the above adaptor into a right angled 20X2 row of 0.1" pins and that into a 20X2 female connectors in P1/P9 and P15/P9 (see below).

Since the original IDE/CF Card board came out (in 2004) SYBA Multimedia has come out with a smaller version of the adaptor. It behaves exactly the same BUT the IDE connector orientation has been flipped around. As you look at the front of the adaptor pin 1 is at the back top row on the right (#2 below). This adaptor needs to be plugged into P1 and P9. The older adaptors plug into P10 and P15. Be sure you add the adaptor to the correct socket. If you use the "old" adaptor (#1 below), its best not to add the socket for the new adaptor to positions P1 and P9.

To utilize SD cards in early designs of this board I utilized SPI SD card adaptors such as the Adfruit or Sparkfun Adaptors. While they worked fine, actual card access was 10X slower that for CF Cards. This is due to the single bit SPI public domain interface rather than the 4 bit licensed interface. Fortunately again there are IDE to SD card adaptors that completely take care of the complex process if SD card initialization and access at CF card speeds. Here is a picture of the ones I currently use.

There are also mini to micro SD card adaptors that fit into these units. So our IDE sockets can accommodate either:-

A Ribbon cable connected "real" IDE hard disk.
A CF Card
A Mini SD Card
or a Micro SD Card.

As far as the software is concerned (see below) all behave the same.


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

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.

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 used this format on our IDE/CF Card board and will use it here as well.

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 for 2 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:-

This would be the IDE CF card A: with the current sector being Track 12 sector 34.

Step By Step Building the FPGA DC + IDE 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. 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.

One final point here, you will see that many traces go between the FPGA socket pins on the front of the board. I always worry that the socket pins during soldering would melt the varnish and contact one of these traces. So I always insert the sockets just enough to see the pins on the back side of the board. In other words the socket is slightly above the board. Probably overkill!

BTW, 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.

I use the Adafruit USB serial Adaptor, but the equivalent SparkFun unit also works fine.

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 D24V 25F3 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. 5V and 3.3V going to the correct pins of the FPGA adaptor. (5V going to the 3.3V pins will blow the unit!).

Note recently the above Pololu regulators have gotten hard to find and have become expensive. Pololu now has more options to pick from. Examine the pinout of any of their 5V or 3.3V regulators and place them in one of the two sets of slots above.

When adding the LED's be sure to orient them correctly. (Usually the longer lead in the square pad).

The 20 pin DIP version of the Maxim RTC chip is currently in short supply. In case people cannopt obtain one I have added a footprint for the SMD version of the chip as well.   They both work exactly the same. Be sure not to add the U13 DIP socket if you intend to use the SMD chip.

There are many types/sizes of 3V coin batteries and adapters. Jameco sells many holders. The 1" #236996 with a CR2032 is common. So long as it's 3V types don't matter. The RTC chip battery should last for years!

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 S100 bus 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.

While on soldering! Many board traces run between the pins of the FPGA adaptor.   I always worry about a short from a nearby pin. I like to place the FPGA connector sockets so they just show through to the back side of the board. This way the socket is well above the front of the board with no danger of shorting.   Try for at least a papers tickness of sepearation at least between the socket and the front side of the board.

Here is a picture of (a prototype version) the board at this stage:-

If you are not completely familiar with programming the Cyclone IV FPGA please study in detail this write-up Programming a Cyclone IV FPGA.

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.

Now would be a good time also to study in detail the FPGA_DC.brd file to understand how the board "works". Remember the FPGA utilized its own internal 30-40 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 FPGA_DC.HEX file there (or readjust the ROM Module Properties in the .brd file)

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, and the RAM chip U5.

To activate the IDE/CF Card circuit within the FPGA jumper K4 1-2 and K2 2-3.
IEEE-696 16 bit S100 bus port IO addressing is assumed (the upper 8 lines being zero) for this board. This can be easily bypassed within the FPGA (Jumper K1 1-2). Do so if your CPU board does not zero the high address lines for port I/O. To be safe we will jumper K1 1-2 for now. Note 16 bit CPU's will probably require K1 2-3.

Install the Sparkfun FT231x USB adaptor. Note it has a jumper on its back for 3.3V operation, use 3.3v not 5V. You can solder the adaptor 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.


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:-

For now just use the Z command. This will bring you directly to the FPGA Z80 CPU monitor. You should see the following:-
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.

Next we will install the IDE/CF card circuit.
Install the 82C55, U26 chip.
Add U9 and U12 and U11 and U14. Note U12 & U11 are regular 74LS245s (or better 74LS645s).
Add U1, U6, U20 and U21.
Jumper K1 2-3, K3 1-2 and P25.

Install one or both of your IDE adaptors each with CF cards.
Power up, load up the FPGA again and from the USB port menu select the "A" menu option.
The board should look like this at this stage:-

The IDE Sub-menu should come up as shown here:

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 -- the pins are a little fragile.
Here is a picture of the board at this stage.

Finally you can add RTC Chip and 32.768 KHz Oscillator and coin battery holder. One or two sizes can be used but be sure to have the + terminal on the RHS.

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 two "Drives" A or B.
Here is the sub menu for the IDE drive:-

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):-

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

A few non-obvious shortcuts:-
If asked for a sector number, a CR will enter the current Track and , 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.

THE S100 BUS INTERFACE WITH THE FPGA_DC + IDE CIRCUIT
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 IDE 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. I 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.   In order to simplify the BIOS software with all 3 boards in this series of FPGA_DC boards 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_INIT_DRIVE      EQU 30H     ;Select AND Initilized 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 complete 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:-

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 (start) copying CF card in drive A: to B:

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:-

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 Initilized the current drive

All 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 1 & 2 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 CF Card Drive:-

IDE_DRIVE_1:
    DB     CFCARD        ;0 (0FFH), Disk HW_BYTE (Default IDE Card/Drive)
    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 FLAG/unitilized
    DB     2             ;5 512 Bytes/sec flag
    DB     0             ;6 Tracks set aside for operating system (e.g. CPM 2 for floppies)
    DB     0AH           ;7 HEX of Drive letter
    DB     'A'           ;8 ACCII Character for Drive
    DB     0             ;9 First sector #

    DW     512           ;10 <------ 512 Bytes/sec
    DW     00FFH         ;12 SECTORS PER TRACK:- (Was 3CH (60)for my on old CPM3 for Kingston CF 8G).
    DW     00FFH         ;14 Max Tracks
    DW     0000H         ;16 TRK, Current Track
    DW     0000H         ;18 SEC, Current Sector

    DB     0             ;19 For Floppy Formatting (Not used for CF/SD cards)
    DB     0             ;20   "
    DB     0             ;21   "
    DB     0             ;22   "
    DB     0             ;23   "
    DB     0             ;24   "
    DB     0             ;25   "
    DB     0E5H          ;26 CPM Sector data fill byte
    DB     0             ;27   "
    DB     0000H         ;28   "
    DB     0             ;30   "
    DB     0000H         ;31   "
    DB     'CF Card A: ',0 ;33 Drive name/description

So the value of Bytes/Sector would be (IX+SEC_SIZE_BYTES), where SEC_SIZE_BYTES = 0AH.

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.

The Real Time Clock (RTC).
All 3 boards have a DS1305 RTC chip. This is one example where using a FPGA really shines. With its 3 wire SPI connection to the FPGA with one chip you get a complete RTC read and write circuit. Whole S100 boards in the past were required for this function. The Calendar/Time settings can be set within the Z80 Monitor or from the above FPGA S100 Bus diagnostic program (see below). The circuit and software is identical for all three boards. The chip defaults to 24 hour format. You must have the coin battery present and you must use the Monitor to initialize the chip for the very first time (Monitor B, A CMDs).
Here is a picture of the interface using the FPGA S100 Bus diagnostic program:-

The data returned to the S100 Bus with the 81H Command is in the format of the following 14 character string:-
20210722131004

All ASCII characters. The format is 24 hours.

Please skip to here.

FPGA_DC + FDC Board
This board has much in common with the above FPGA_DC _IDE Board. Instead of an 8255A and two IDE sockets we have a Western Digital 2793 Floppy Disk controller and two ribbon cable connectors along the top of the board to hook-up floppy disks.

The build instructions are exactly the same as is the software. The main difference is the replacement of the 8255A with the WD2793 chip. Study this chips circuitry carefully in the schematic. Critical are the two 0-50K Ohms Pots (RV1 and RV2) and the 0-50pF Cap C12. Solder these carefully to the board taking care to place them in their correct orientations for the center tap. We will adjust them later.
Note the Diode D14 should be at least a IN4005 1Amp diode. It's there to reduce the voltage going to the HEX displays so they don't run too hot.

Solder in all the sockets, jumpers, resistors, caps and the 50 and 34 pin connectors P9 and P1.

Be sure the Pololu 5V and 3.3V regulators are the correct types and deliver the correct voltages to the WaveShare FPGA adaptor before inserting it.
Here is a picture of the board at this stage:

Next solder directly to the board the three 74VLC245s U10, U15 and U16. If possible use known working chips you don't want to remove a faulty one later.

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.

Now would be a good time also to study in detail the FPGA_DC.brd file to understand how the board "works". Remember the FPGA utilized its own internal 30-40 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 FPGA_DC.HEX file there (or readjust the ROM Module Properties in the .brd file)

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, U10 and the RAM chip U5.

To activate the FDC Card circuit within the FPGA jumper K6 2-3 and K5 1-2.   Note it's very important you get these two jumpers correct.
IEEE-696 16 bit S100 bus port IO addressing is assumed (the upper 8 lines being zero) for this board. This can be easily bypassed within the FPGA (Jumper K1 1-2). Do so if your CPU board does not zero the high address lines for port I/O. To be safe we will jumper K1 1-2 for now. Note 16 bit CPU's will probably require K1 2-3.

Install the Sparkfun FT231x USB adaptor. Note it has a jumper on its back for 3.3V operation, use 3.3v not 5V. You can solder the adaptor 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.

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.


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:-

As for the FPGA_DC IDE board first utilize the Z command to checkout the "standard" Z80 commands. They must work correctly before going further.

WD2793 Hardware
Like the earlier 1791/1795 chips the WD2793 consists of a 40 pin chip with many of the same data and control lines as the earlier 179x series. In order to fully understand their function you should read the detailed description of how the WD2793 FDC chip works. The complete data sheet can be seen here. You should read this data sheet in detail to understand much of what I have below.
Let us first look briefly at the function of the 40 pins:-

Most of the pins are fairly straightforward and should need no further discussion. Pins #26 and #33 as we shall see, do need to be adjusted, but Western Digital (by this stage) made it easy to do with a special test pin (#22). The one complication in any system is if you intend to use the chip with both 8" and 5" drives mixed together. Because the data rate of a 5" drive is half that of an 8" drive the clock frequency has to be divided in two. Pin #25 is set aside for this use.

One very important control pin is INTRQ (#39). This pin pulses high (very briefly) when every a command is completed. We will gate the output of this pin going to the NMI pin of the Z80 such that (if desired) the FPGA Z80 will experience a NMI interrupt whenever the WD2793 completes its current command (seek, read a sector, format a track etc.). This is a very convenient and efficient way to synchronize the two chips and make sure the system does not "hang" with for example a false disk command or data.

WD2793 Software
All Western Digital FDC chips have at their base port a key "status" port that continuously displays important information about the chips actions and results. This is reflected in a series of bit flags. The actual meaning of these bits changes depending on what the chip has being doing. Here is a summary of the bit flags for the most common uses:-

The challenge with any disk controller is matching the data rate of the stream of data bits coming in from the disk surface with the capability of a CPU's ability to place the corresponding bytes in memory AND at the same time decide when the job is done. In the early S-100 days when only 4MHz Z80's were available, the Z80 simply could not keep up. In other words the Z80 was not fast enough to continuously monitor the status register status bits AND at the same time take data from the data port and place it in RAM -- particularly in double density modes. Two basic ways around this were used. One was to use a dedicated DMA controller on board (which was fast enough) -- but this sometimes caused conflicts with other (pre-IEEE 696) S-100 boards. The other simply took account of the fact that IF there are no errors, one knows exactly how many bytes to expect (or send) and you can lock the data rate of the FDC to that of the Z80 utilizing the Z80's block I/O instructions by inserting CPU wait states during each bytes transfer at the same time counting the total number of bytes processed.

Fortunately utilizing our 40MHz FPGA Z80 we don't have to use these round about approaches. The Z80 can simply input individual disk bytes AND at the same time look at the WD2793 status port to see when the next byte is available (bit 1, the DRQ bit goes high). That said things are still very tight. You really have to watch your clock cycles. To input a sector here is the key code I use:-

READ_SECTOR:
         LD      B,Sector_Size
         LD      HL,DMA_Address
         LD      C,Data_Port
CHK_STAT:
         IN    A,(WD2793_Status)
         RRA
         RRA
         JR   NC,CHK_STAT        ;Very fast way to check the DRQ status bit
         IN   A,(C)              ;Very fast way to input data from [C] port
         LD   (HL),A
         INC HL
         DJNZ CHK_STAT

Using this very efficient code a 40 MHz Z80 is able to keep its head above water! Interestingly using the special Z80 INI instruction did not work with the circuit on this board. It's unclear to me why. Even with the above code the FPGA Z80 clock needs to be 40 MHz. A faster CPU makes no difference and indeed may be unreliable since you are way outside the specs of the WD2793 chip. Code like this in fact can be utilized to read or deposit a whole track on a disk.

All of the above is perfectly fine so long as there are no errors. However if for some reason the WD2793 comes up short in getting bytes from a sector (a wrong formatted disk was used for example), the system will hang. There is not enough time to incorporate a software timeout counter in the loop.

What we do, in hardware, is trigger a 74LS123 pulse generator. Before we read or write a sector we trigger/activate the 74LS123 (Watch-Dog Timer). IF a sector is not read before the timer times out, it triggers a NMI interrupt on the Z80 which then causes the Z80 to brake out of the above loop and act accordingly. If the sector is read/written properly in time it turns off the watchdog timer.

As an extra safety net, the Z80 NMI line is also triggered by the INTRQ pin of the WD2793 pin which always pulses when an WD2793 operation is complete. I have the hardware where this line too can be activated to trigger an NMI instruction. The software is a little tricky but is documented in FPGA_DC.Z80 code below.

The above arrangement makes for a very reliable WD2793 arrangement to seek, read/write sectors or tracks etc. There are no wait states, no DMA controllers or inserted HALT opcodes.

WD2793 Commands
Exactly like the earlier 1791/1795 chips the WD2793 contains five 8 bit registers which completely control all the chips functions. They are:-

Data Register.         This is the register to/from which sector byte by byte data is obtained.
Track Register.        The require disk track is placed in this register. Upon a track seek (with verify) the new track can be read from here
Sector Register.       The require sector to be read/written to is placed in this register.
Command Register   This is the most important register it determines what next the chip will do.
Status Register        This register contains various flag bits to describe command success or errors.

Tracks on a disk are laid down in the format:-
Track header...gap...(Track/Sector ID..gap..Data..gap) x N times, ...End of Track

The Track/Sector ID consists of 6 bytes:-
Track#, Side (0 or 1), Sector#, Sector Size flag (,1,2,3 or 4) , and a 2 byte CRC check.

The command register accepts 11 different commands with very precise bit patterns. They are summarized in this table.

First you will notice that the commands are grouped into 4 groups.

The Type I commands control the head movement. Bits 0 and 1 determine how fast the head will move from track to track. For most modern drives the maximum speed so these bits are 0,0. The V bit determines if the chip will verify if it is on the correct track after the head to track movement is complete. Normally a 1 but for disk formatting it is set to 0. The h bit determines if the head is to be lowered on to the disk before or after the command function is complete.

The Type II commands are clearly the most important (but the most complex). Bit 0 of a Write sector 'a0' has to do with disk formatting and need not concern us here and is set to 0.

F1 is another story. This bit simply determines if the chip is to check if the active head is reading from the requested side of the disk. If 0 the WD2793 chip skips this side check. If 1 it checks that the active head is really on the requested side. The side of the disk is contained in the Track/Sector ID field. The second byte of this field is 0 for side A (or a single sided disk). It is 1 for side B.

The E bit determines if there is to be a slight time delay (15 ms) in setting the chip's busy flag after lowering the head.

F2 on a WD2793 chip is relevant if F1 was set to 1 (enable side compare). If it is 0 the sector side field must also be 0 (Side A). If it is 1 then the sector side field must also be 1 (Side B).

Finally the m bit allows you to read/write contiguous sectors on a track. Very fast, but unfortunately difficult to incorporate in CPM BIOS code because multiple sectors often are on different tracks.

The Type III command either reads the above track/sector ID field or a whole track. The write track command is primarily for disk formatting.

The Type IV command, force interrupt command is to pull the chip out of a lockup situation. It's basically a chip reset command.

Use the Z command to bring up the monitor and then use the U command to bring up the Floppy disk menu. (Please allow a second or two for the disk to come on).

It is this sub menu we will concentrate on for this board.
Let us go through the commands one at a time.

First add U3, U23, U6, U11 (a 74LS645), U21, U14, U12 (a 74LS645), U9 and U20.
Add U19, U22, U17, U26, U25, U29, U28, U22, U1.
Add U8 and U13 (the DS1305 RTC Chip).
You can also add the four HEX displays.
Finally add the WD 2793 FDC chip U18.
At this point all IC sockets on the board should be full.

We will start with a single standard IBM format 8" Single Density, Single Sided disk configured as Drive A: as far as the disk drive is concerned
Jumper P28 2-3 & 4-5. Since we are going to use motor on with head load -- no jumpers on P29. (See your disk drive for this option).
Jumper P29 1-2 and close JP3.
While not really needed here (is for the IDE circuit), jumper K3 1-2 and close P25.
Jumper K2 2-3.
P20 is for some old 8" drives. Jumper (vertically) 1-2 and 2-3.

Hookup your 8" Floppy disk ribbon cable. Be sure you have the cable correct. All signals are on the P9 connector even pins (top row). All ground pins are on the odd pins.
Here is a close-up picture:-

The first thing we will do is check the WD2793 is receiving data from the FPGA. With the "U" test we will continuously send Track and sector data to the chips Track and Sector registers (Ports F1 & F2). We will read them back. They must be the same. Here is an example:-

Next we will "Restore" the drive head to Track 0 (X CMD). The Track 0 LED D15 should light up. Then use the "H" command to step the head in one track. Each time you press "H" you should hear the head move. The Track 0 LED D15 should be off. The "X" command will restore the head back to track 0 and the Track 0 LED should come back on. This is a very simple test but it must work. It is completely independent of the read/write drive electronics. Do not waste time going further until you get this working. BTW, whenever the disk is rotating the IP LED (D16), should be faintly flashing. The Head Load LED (D19) should light up also. For 8" Single Density Disks LED D18 should not light up and the Side A LED D20 should be on and the 8" Disk LED D12 should be on.

Next we need to do actual disk sector reads and writes. Before doing this however the internal WD 2793 chip data separator needs to be fine tuned.

Adjusting the Data Separator setting of the WD2793.
One thing that often scares people away from these early FDC chips is the need to fine tune the data separator/analogue signal of the raw data coming in from the disk. I have found that the WD2793 works with almost any setting for 8" single density drives. Not so for the double density 5" floppy disks however. Early FDC boards often had elaborate hardware that sometimes required careful adjustment to get a reliable signal, particularly for Double Density modes. Western Digital greatly simplified this process with the WD2793 chip. All that is required is one 50K Potentiometer and a 5-50pF variable capacitor. The adjustment process is as follows:-

Reset the WD2793 chip (Reset on the S-100 system).
Start the boards Z80 Monitor program Z command.

Output 40H to Port F5H. Use QOF5,40. This will set the WD2793 chip to double density mode, 8" disk. The LEDs D18 and D12 should be on, (the others don't matter).
This should set the WD2793 pin 37 low and its pin 17 high.

Then Jumper JP1. This sets the WD2793 "TEST" pin (pin 22) to ground. (It will not work if JP1 is installed before the above reset).

Then with a scope or logic analyzer observe the continuous 2mHz pulse on pin 24 of U18, or P23, pin 4.

Adjust the 50K pot on pin 18 (RV1) so the signal on U18 pin 29 or P23 pin 3 has a width of 250ns.

Next adjust the variable capacitor (C12) so that U18 pin 16 (DIRC), or P25, pin 1 has a width of 1uS

You can use a scope, digital analyzer of simple handheld frequency counter.

When done be sure to remove the jumper on pin 22 JP1.

The "Write Precomp Width" control Pin 33, does not seem to be critical. I leave RV2 at about 25 KOhms. Try adjusting it if you get a lot or reseeks while reading double density disks.

The above sounds more complicated than it actually is. In fact I have found if the pot and cap are roughly in the middle of their range the chip works fairly reliable. A poor man's approach might be to do continuous disk sector reads and adjust things on the fly!

Below are pictures of my adjusted board using a YEAPOOK ADS1013D digital storage analyzer. (An excellent machine, reasonably priced.)

When you are satisfied with the above settings, reboot your system (remember to remove the JP1). In the default mode the FDC menu comes up with floppies B: & C: as 8" Single Density Single Sided disks.
Use the "X" Command to restore the head to track 0.
Use the "H" Command to step the head in one track.
Then use the "Y" Command (Get Track ID) to have the WD2793 read the "Track ID". This is a very important test. It reads from the disk 6 bytes into RAM the "ID" of a track. It can be any sector but it must be Track 1.
Here is an example

The format is:-

The first byte must be the correct track number. 01H in this case.
It is absolutely essential you get the "Y" command working before going father. It utilizes almost all the functions of the WD2793 chip circuit.

You can then move on to the "Z" Command that randomly seeks to different disk track and reads the track ID.
The "Current Track" in the WD2793 register should always match the first byte of the Track ID.
Here again is an example:-

Next we will do an actual read sector. Start with Track 0, Sector 1, (There are no 0 sectors on floppies). You should see something like this -- again with no errors.

Hitting a CR will show the next sector. An ESC will drop you back to the floppy menu. This test does require a properly formatted floppy disk!

The rest of the menu items are hopefully obvious.
If you have added the HEX LED displays they should be continuously updated BTW.

THE S100 BUS INTERFACE WITH THE FPGA_DC + FDC CIRCUIT
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 FDC 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. I 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.   In order to simplify the BIOS software with all 3 boards in this series of FPGA_DC boards 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 initialized 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 Initilized 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 complete 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:-


Hardware/Software Debugging.
These are relatively complex boards. 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 card or FDC sections 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 or FDC 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

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.   Here is a picture of some of the cards I use that are 100% reliable:-

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 (Jumper K1 1-2).

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 working with files for the two "old formats", the FPGA Z80 code can be modified with SW1 bits 1 & 2 for drive A: and B: as follows:-

SW1 xxxxxx0x FFH tracks,   3CH sectors per track for IDE/CF drive A: and B:
SW1 xxxxx0xx FFH tracks,   3FH sectors per track for IDE/CF drive A: and B:

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). 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 3CH or 3FH sectors/track. Note this really only speeds up disk copying etc. The FPGA software is completely independent of the disk BIOS software. Normally you will use 0FFH sectors/track -- its just some sectors will not be used by the BIOS.

The initial drive selection menu will always show you the current IDE drive format assumed by the FPGA Z80 code:-

LED's
These boards have quite a number of LEDs. Lets go through them one at a time.

The FPGA_DC+IDE Board
The 6 LEDs (D2, D3, D4, D5, D6, D7) are on all 3 boards. On this board only D2 and D3 (Labeled C: and B:) are utilized in the current FPGA Software. They light up AFTER an IDE Drive/Card is fully initialized on power on. They should then stay on all the time. They are NOT Drive select LEDs. If either LED does not light up there is a problem with the drive/card hardware.
The two LED's D12 and D1 (beside the IDE Adaptors) are true Drive Select LEDs that come on when a R/W drive is active.
The two S100 Status LEDs D8 and D9 flash when data travels to/from the S100 bus. These are really only there for debugging purposes.
Finally the FPGA Active LED D10 should always be flashing. Its there to show the FPGA is active. If it does not flash something is seriously wrong with the FPGA code.

The FPGA_DC+FDC Board
The 6 LEDs (D2, D3, D4, D5, D6, D7) are on all 3 boards. On this board only D4, D6, D7 and D7 (Labeled C: to F:) are utilized in the current FPGA Software. They light up AFTER a Floppy Drive is fully initialized on power on. They should then stay on all the time. They are NOT Drive select LEDs.
The two S100 Status LEDs D8 and D9 flash when data travels to/from the S100 bus. These are really only there for debugging purposes.
Finally the FPGA Active LED D10 should always be flashing. Its there to show the FPGA is active. If it does not flash something is seriously wrong with the FPGA code.

There are some key WD2793 FDC related LEDs:-

D13 lights up if the current Disk Drive software wishes to inform the user that the current disk is write protected. It's the responsibility of the BIOS software to determine this by looking at the WD2793 status register. Bit 6 will be 1 if a disk is write protected.
D22 will flash each time the WD2793 triggers its INTRQ* pin 39 (or each DRQ* Pin 38). Which one is determined by Jumper K4 (1-2 = DRQ, 2-3 = INTRQ)
D20 will be on if side A of a disk is being accessed.
D17 will be on if the current disk drive indicates its ready to operate (P9 pin 22 or P1 pin 34 from the drives themselves).
D12 will be on if the WD2793 is configured to be talking to an 8" drive.
D21 is really for debugging purposes to indicate the FPGA is waiting to break out of a loop during a sector read or write by an interrupt.
D15 will light up whenever the current disk head is on Track 0.
D18 will light up if the WD2793 is configured to be talking to a double density drive.
D19 will light up whenever the drive head is lowered on to the disk surface.
D16 will flash whenever the disk index hole is detected during a disk rotation.

All three drives have two jumpers Test_1 and Test_2. These are TTL level outputs from the FPGA than can be used for debugging the Z80 software.

Software
The software for these 3 boards is fairly complex. There is no way around it, to accommodate the wide verity of cards and disks possible. In theory at least most beginners should not have to alter the software at all. To facilitate the installations all three boards use the exact same software (both within the FPGA and the DC_DIAG.COM diagnostic program). In fact the CPM DC_DIAG.COM will also work with the old IDE/CF board. I should also mention that the current software is nowhere near allowing these boards to attain their full capacities. Currently for example only a few Floppy disk formats are covered. The ZFDC Controller Board still currently stands as the better board in this respect. That said, there is no reason why any soft sectored floppy, IDE drive, CF or SD card cannot be utilized by this board. You should have fun modifying the code to do so. I have made a special effort to extensively comment the sections.
Here is how the FPGA_DC.Z80 code is structured:-

Program Equates
Setup Stack and Interrupts
Move the Drive Tables from ROM to RAM
Initialize the IDE Drives and Tables
Initialize the Floppy Drives and Tables
Check IOBYTE Port to see if a jump to the Z80 Monitor is required

Enter the main program Loop (START_CMD:)
Process each Command sent from the S100 Bus

The Commands code

Code to update the HEX LED Display
Code to send Info to the USB Terminal

The Z80 Monitor Menu and code/loop
The Local IDE/CF Card Menu and code/loop
The Floppy Disks Menu and code/loop

Core WD2793 Routines
General software support routines
Core IDE Drive Routines

Real Time Clock routines

Disk parameter tables
Menu strings
ASCII Text/messages

RAM variables (starting at 9000H in RAM).

Remember if you do modify the above code be sure Quartus knows where the new ROM ZFDC.HEX file is located when compiling the ZFDC_DC.brd file.

Likewise the Quartus FPGA_DC.brd file is fairly well structured. The FPGA board "components" are layered top down as follows:

Clock Generator
Z80 CPU module
S100 Address Lines and key signal inputs
Internal Z80 Bi-directional data bus
RAM interface & ROM Module
UART Interface
IO Ports and Switches
Local IDE Interface
External IDE Interface
S100 Bus Interface
Floppy Disks interface
Hex LED Display circuits
S100 Bus bridge to FPGA Ports
SPI Real Time Clock Interface

Installing CPM3 On The FPGA_CF Board.
For this Disk Controller 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.

Software for this board.
Over time I anticipate a fair amount of software for these boards, so I have setup a separate web page for all FPGA_DC Board related software here:-

FPGA_DC Board Software

All the links below in fact go to that page. If you develop software for these boards please send it to me and I will post it there.

Bugs
No reported bugs so far.

To Order 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" is now open.

Note this is for the FPGA_DC + IDE Board only. (The other two boards will come later).

Please go here to order one or more bare boards.

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.

(Note more files will be added later....)

FPGA_DC + IDE Board Schematic (V1.0 IDE Only) FINAL .PDF File (8/8/2021)
KiCAD files for FPGA_DC (V1.0 IDE Only) FINAL   .ZIP File      (8/8/2021)
Gerber files for FPGA_DC (V1.0 IDE Only) FINAL .ZIP File     (8/8/2021)

BOM of FPGA_DC+IDE Board (PDF File)                             (8/22/2021) Contributed by Rick Bromagem
BOM of FPGA_DC+IDE Board Excel File)                             (8/22/2021) Contributed by Rick Bromagem
Board Layout of FPGA_DC+IDE Board (PDF File)                   (8/22/2021) Contributed by Rick Bromagem

QUARTUS FPGA_DC .BRD Files .ZIP File           (7/26/2021)
Z80 Monitor software for FPGA_DC.BRD .ZIP             (7/27/2021)
Z80 Monitor software for FPGA_DC.BRD .PDF File       (7/27/2021)

DC_DIAG.ASM Source Code .ZIP                       (7/27/2021)
DC_DIAG.ASM Source code PDF File               (7/27/2021)

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

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