• Please review our updated Terms and Rules here

Homebrew S100 - I/O Board

MykeLawson

Experienced Member
Joined
Mar 21, 2014
Messages
387
Since my S-100 will only have boards, besides the CPU Board (https://forum.vcfed.org/index.php?threads/homebrew-s100-cpu-board.1245502/), I noticed something that may be an issue. The I/O Board uses a couple 74LS138s for port decoding, and the port decode for the two 8251A serial chips go straight to the /CS pins. This would mean that any address put on the bus that has the values associated with those two devices would cause the 8251A's to be selected. That would probably not be an issue since the IO Read and IO Write signals would not be active. However, out of the abundance of caution, I took the /IOREQ signal from the Z-80 on the CPU and connected it to an used S-100 bus pin. That signal could be used on the I/O Board to prevent either 8251A to be selected unless an IO operation is occurring. I may, or may not implement this.

The I/O Board contains two serial ports, one for the system console, and one for transferring data to & from an external source (my PS/2 File Server), a parallel printer port (identical to the printer card on my STD bus machine), and a parallel ASCII keyboard (modified from the Osborne keyboard kit another user here posted).
 

Attachments

  • IO Board.pdf
    90.3 KB · Views: 12
Hi,

Are you going to provide full documentation for us non-engineers to use the board in our Altair 8800c computers? Also, the Gerber files and BOM so we can build one for ourselves?


.
 
well, you see, this current project of mine is 100% wire wrap and the schematic is about all I have at the moment. I have to start testing and debugging it soon, so I can figure out, and correct, any design flaws. Both the CPU and I/O boards are an amalgamation of various boards I have documentation on. If you wanted to wire wrap one, the parts you would need are shown in the schematic. I would have no issues if anyone wanted to spin this thing into an actual board at some point. For me, this is my therapeutic hobby.... Here are the front and back pics of the I/O Board
 

Attachments

  • IMG_20231201_224831534.jpg
    IMG_20231201_224831534.jpg
    4.5 MB · Views: 23
  • IMG_20231201_224808712.jpg
    IMG_20231201_224808712.jpg
    3.5 MB · Views: 23
Last edited:
Nice WW job. Wish there was a cost-effective supplier for those Wrap-ID cards in various sizes (pin-count and width). Guessing that yours are NOS from BITD? I wonder if one could print them up on card-stock and then use a laser cutter to trim and punch holes?
 
Thanks. Actually, I have found them a lot on eBay. I have bought quite a few, and that does make it easier.
 
Since my S-100 will only have boards, besides the CPU Board (https://forum.vcfed.org/index.php?threads/homebrew-s100-cpu-board.1245502/), I noticed something that may be an issue. The I/O Board uses a couple 74LS138s for port decoding, and the port decode for the two 8251A serial chips go straight to the /CS pins. This would mean that any address put on the bus that has the values associated with those two devices would cause the 8251A's to be selected. That would probably not be an issue since the IO Read and IO Write signals would not be active. However, out of the abundance of caution, I took the /IOREQ signal from the Z-80 on the CPU and connected it to an used S-100 bus pin. That signal could be used on the I/O Board to prevent either 8251A to be selected unless an IO operation is occurring. I may, or may not implement this.

The I/O Board contains two serial ports, one for the system console, and one for transferring data to & from an external source (my PS/2 File Server), a parallel printer port (identical to the printer card on my STD bus machine), and a parallel ASCII keyboard (modified from the Osborne keyboard kit another user here posted).
What is your intended use for the circuitry that routes the S100 vector interrupt signal lines onto the S100 data input bus during a read to I/O port 07 ? Where you planning to repurpose the S100 vector interrupt signal lines for some other use?
 
What is your intended use for the circuitry that routes the S100 vector interrupt signal lines onto the S100 data input bus during a read to I/O port 07 ? Where you planning to repurpose the S100 vector interrupt signal lines for some other use?
Instead of the vectored interrupt lines used for interrupt purposes, since my system doesn't utilize interrupts; I will be using it as a 'polling' port for whatever application needs to access something connected. An example is the parallel ASCII keyboard. As with the 8251A having a status register to see if the buffer is empty to send, or full to receive, the polling port is checked to see if a key was depressed. The printer likewise has a built-in (sort of) status port it utilizes. I did not combine them in order to maintain some commonality with my STD bus system and code, and to match the IBM and Centronics implementations.
 
Since my S-100 will only have boards, besides the CPU Board (https://forum.vcfed.org/index.php?threads/homebrew-s100-cpu-board.1245502/), I noticed something that may be an issue. The I/O Board uses a couple 74LS138s for port decoding, and the port decode for the two 8251A serial chips go straight to the /CS pins. This would mean that any address put on the bus that has the values associated with those two devices would cause the 8251A's to be selected. That would probably not be an issue since the IO Read and IO Write signals would not be active. However, out of the abundance of caution, I took the /IOREQ signal from the Z-80 on the CPU and connected it to an used S-100 bus pin. That signal could be used on the I/O Board to prevent either 8251A to be selected unless an IO operation is occurring. I may, or may not implement this.

The I/O Board contains two serial ports, one for the system console, and one for transferring data to & from an external source (my PS/2 File Server), a parallel printer port (identical to the printer card on my STD bus machine), and a parallel ASCII keyboard (modified from the Osborne keyboard kit another user here posted).
The best signal to use if you only want an active /CS input on the 8251 when (a) it is being addressed and (b) during input/output port cycles, is to AND the address select along with S100 bus signals sINP OR sOUT. That is one of the intended purposes for sINP and sOUT, and avoids having to implement a nonstandard S100 signal bringing /IOREQ directly from the CPU board.
 
I would advise against wire wrap boards for new projects on S-100 boards. That is is there is any chance somebody might want to use them in a SOL-20 at least.

The method results in long pins poking out one side of the board, which effectively doubles the board thickness. The board therefore uses up two card slots as the pins prevent fitting a card in the adjacent slot. And depending on the card cage and total number of available slots can be limiting.

Also, the IC socket pins are just begging to be shorted out on something nearby.

I think it is much better to hand wire the board with soldered connections with the wire wrap wire. If this is done with the correct wire routing method, it gives a very reliable and tidy result. The method involves making sure that the link wires generally do not run over the standard IC socket pins, so that soldering access is maintained as the wiring job proceeds. Also the power and ground connections are completed prior to the insulated wiring.

There is a photo of this technique I developed for hand wired boards on pages 11 & 12 of this article including a close up photo of how the link wires are routed and also retained to the board's surface too, with tie down (soldered down) links:


It might take a little longer than wire wrap, but the result is much more compact and better looking too. The individual link wires need to be prepared and the exposed ends pre-soldered to make sure each join is 100% perfect and after it is finished the flux cleaned off for the final inspection as the close up photo shows. Therefore it does rely on good soldering skills, where the wire wrap method doesn't. With this method the card can run with cards on either side in the card cage of a SOL-20 too. I'm not sure about the spacing of other S-100 card cages.
 
Last edited:
At a glance, I can’t see a need to use /IOREQ on the S100 bus.
The Chip Select pin is the most important input to assert access thus (sinp or sout) to indicate an I/O request should be used in conjunction with the i/o address.
Raw sinp and sout may be sufficient to drive the RD and WR input pins.
(Being a non-purist) I would use a GAL or SPLD to simplify the I/O decoding and glue logic.
 
Back
Top