Homebrew S100 - CPU Board

[MykeLawson]

Well, after many months of digging through documents, schematics, and websites, I have finally gotten my CPU card designed, and built. Part of it is based on the STD bus Z-80 board I use in my development system and the rest is based on designs from Ithaca, Vector Graphics, Wameco, Cromemco, and a few others. You will notice that I have some circuitry (A3 area of the drawing) that disable the data bus drivers whenever there is a memory read or write. Since all of the RAM & ROM is local to the CPU board, there is no reason to have the data bus be active in order to prevent any bus contention. Granted this has not been tested out yet, but the board is wired and ready for test once I get the I/O board (serial/printer/keyboard) designed and built.

The I/O board will drive a VT-100 emulator card (Uterm-S) to provide PS/2 keyboard and VGA output, has a standard RS-232 interface to connect the the PS/2 file server I have written some software for, a Centronics printer port, and a parallel ASCII keyboard (modified Osborne keyboard kit posted at VCF). So, I'd love to hear any comments in case I overlooked or did something boneheaded in designing this thing.

Also, I will probably have to tweak the circuit at some point when I put in the S-100 video card I'm trying to conjure up. But since the board is wire-wrapped, that should be easy enough. Thanks, Myke

 

[hmb]

Well, after many months of digging through documents, schematics, and websites, I have finally gotten my CPU card designed, and built. Part of it is based on the STD bus Z-80 board I use in my development system and the rest is based on designs from Ithaca, Vector Graphics, Wameco, Cromemco, and a few others. You will notice that I have some circuitry (A3 area of the drawing) that disable the data bus drivers whenever there is a memory read or write. Since all of the RAM & ROM is local to the CPU board, there is no reason to have the data bus be active in order to prevent any bus contention. Granted this has not been tested out yet, but the board is wired and ready for test once I get the I/O board (serial/printer/keyboard) designed and built.

The I/O board will drive a VT-100 emulator card (Uterm-S) to provide PS/2 keyboard and VGA output, has a standard RS-232 interface to connect the the PS/2 file server I have written some software for, a Centronics printer port, and a parallel ASCII keyboard (modified Osborne keyboard kit posted at VCF). So, I'd love to hear any comments in case I overlooked or did something boneheaded in designing this thing.

Also, I will probably have to tweak the circuit at some point when I put in the S-100 video card I'm trying to conjure up. But since the board is wire-wrapped, that should be easy enough. Thanks, Myke

It sounds like you are designing an S100 Z80 CPU board that meets your own system specs, and you are not too concerned with making this board compatible with most other S100 boards. That being the case the following issues may not be important to you, yet they would be if you were aiming for more complete S100 compatibility:
- the board does not support the S100 RDY or XRDY signals (so no ability to extend bus cycles for slow peripheral boards). Probably need a pullup resistor on Z80 pin 24 if you are not going to use its /WAIT input
- the board does not support /INT (so no support for hardware interrupts)
- the Z80 /BUSAK output is driving the signals /CDSB, /SDSB, /ADSB, and /DDSB causing these signals to float as soon as /BUSAK becomes active. Normally these signals are driven by the slave when it is fully ready to take over the bus - which may not always happen at exactly the same time the Z80 /BUSAK becomes active on your CPU board.
- S100 bus signal 49 (/CLK) should be a fixed 2MHz clock, and it does not need to be synchronous with the system clock
- S100 bus signal 24 (PHI) should be the same as the CPU clock
- S100 bus signal 25 (/pSTVAL) goes active as soon as address and status signals are valid at the start of a bus cycle
- all three of the above should be driven with a bus driver, not an driver with an open collector output
- you need a pullup resistor on S100 bus signals 75 (/RESET), 74 (/HOLD)
- S100 bus signal 53 should just be grounded. It is not used in anything but an original Altair.
- S100 bus signal 98 should be left disconnected. It is not used by most systems.

As you pointed out you may end up reversing your design decision to disable the data out bus drivers on a memory write cycle, if you want to implement a memory mapped video board in future.

 

[MykeLawson]

Thank you so much for taking a look at this. Yes, you are correct, I am not IEEE-696 compliant. None of the source material I used for this project is for the most part, so I can live with that. But I did want to at least give you the courtesy of going through what you found. Thank you...

RDY (72) & XRDY (3) wouldn't be needed in my system. The disk board, I/O board, and the video board (TBD) do not use them so I never made allowances for them.

/NMI ( 12) & /INT (73) are not used by anyhting else in the system either. Of note is that I have hijacked the VI-0 thru VI-7 lines to use for a port that I can poll for status or for servicing something that does not generate it's own ready status. The ASCII Parallel keyboard and the printer would fit this role. The 8251A UART generates it's own ready status.

BUSRQ & BUSAK kind of fit into the 'they are there is I need them' fashion. I don't ever see a slave processor at this point. But then again, wire-wrap makes for easy changes......

/CLK (49), PH1 (25), & PH2(24) are really just what I fashioned since I had a 16NHZ clock, and the CPU needed 4MHZ and the I/O board needed 2MHz. And to get those I needed a couple 74LS74's so I figured, why not.

/pSTVAL (25) is odd because the old Ithaca, Vector, & Wameco (Mikos) boards show this pin as the PH1 clock, so I kept it like that and used the last of the D flip flop gates

/RESET (75) & /HOLD (74) are both pulled up on the S-100 motherboard

As for pins 53 & 98, I'm using the N8VEM S-100 Motherboard v4, and since I don't have anything using them, I am just letting them be however the motherboard has them.

 

[hmb]

Thank you so much for taking a look at this. Yes, you are correct, I am not IEEE-696 compliant. None of the source material I used for this project is for the most part, so I can live with that. But I did want to at least give you the courtesy of going through what you found. Thank you...

RDY (72) & XRDY (3) wouldn't be needed in my system. The disk board, I/O board, and the video board (TBD) do not use them so I never made allowances for them.

/NMI ( 12) & /INT (73) are not used by anyhting else in the system either. Of note is that I have hijacked the VI-0 thru VI-7 lines to use for a port that I can poll for status or for servicing something that does not generate it's own ready status. The ASCII Parallel keyboard and the printer would fit this role. The 8251A UART generates it's own ready status.

BUSRQ & BUSAK kind of fit into the 'they are there is I need them' fashion. I don't ever see a slave processor at this point. But then again, wire-wrap makes for easy changes......

/CLK (49), PH1 (25), & PH2(24) are really just what I fashioned since I had a 16NHZ clock, and the CPU needed 4MHZ and the I/O board needed 2MHz. And to get those I needed a couple 74LS74's so I figured, why not.

/pSTVAL (25) is odd because the old Ithaca, Vector, & Wameco (Mikos) boards show this pin as the PH1 clock, so I kept it like that and used the last of the D flip flop gates

/RESET (75) & /HOLD (74) are both pulled up on the S-100 motherboard

As for pins 53 & 98, I'm using the N8VEM S-100 Motherboard v4, and since I don't have anything using them, I am just letting them be however the motherboard has them.

If your CPU board is only to be used with other S100 boards of your own design then - agreed - none of the points I mentioned are important.

The /pSTVAL signal (S100 pin 25) is an IEEE-696 signal, which is why you didn't see it on the really old S100 processor boards you had been looking at. This was originally defined as "clock phase 1" of the two-phase 8080 CPU clock, which had no equivalent for any other CPU (like the Z80) hence the reason it was redefined. Again, of course not a problem if you want to repurpose this signal line for use in a system made up exclusively of your own S100 boards.

 

[MykeLawson]

I have come up with a slight tweak that I may wind up needing to incorporate based on my I/O Board (https://forum.vcfed.org/index.php?threads/homebrew-s100-i-o-board.1245774/). It would place a buffered /IOREQ signal from the Z-80 CPU onto an unused S-100 pin.