Topic: Building a ROM/RAM board for the S-100 bus
Date:  2012 JAN 30

After finally coming across another IO-2 board, I started gathering parts to assemble a dedicated 1702A ROM board for reading some of the old 1702A ROMs I’d accumulated, as well as for dumping the contents of the 1702A ROMs in my Ohio Scientific gear. Until the completion of my S-100 1702A ROM board, I had no way (other than the Ohio Scientific itself) to read 1702A ROMs at home. Since I wouldn’t be using the IO-2 ROM board for dedicated ROM service, I decided to add a pair of 2101 RAMs as well, which would allow me to test the small quantity of 2101s in my parts bin before commiting them to projects.

I originally stumbled on the IO-2 board through a very cheap listing on a popular auction site. That board eventually became my S-100 Debug Board. I was impressed with the versatility of the IO-2 and started looking for another board to be used as a dedicated 1702A ROM board – one of the uses suggested in the manual. Since 1702A PROMs are 256 byte devices, the board provided memory decode in 256 byte segments when used with PROMs, which made it convenient to add a pair of 2101 Static RAMs. The manual (courtesy Dave Dunfield’s classiccmp.org page is mirrored here: Glitch Works File Dump.

First Step: Address Decode and Bus Buffering

Address decode, by the manual, calls for the connection of the SM solder pad to pin 47 of the S-100 bus, SMEMR. In the original configuration, this provided a fully decoded active-low Chip Enable to the 1702As and no further decoding was required. Since I was planning on using 2101 Static RAMs on my board, I had to modify the address decoding somewhat to allow for memory writes. This ended up being trivial: pull SM high via the 1K pullup strip as you would with an I/O board, connect the SI pad to SMEMR (pin 47) and the SO pad to MWRITE (pin 68). This turns the OUT STB signal into a active-high WRITE signal, and the INP STB signal into an active-high READ signal. I also cut the trace from /PWR (pin 77) and provided a jumper to tie it low on the address decode side of the cut. This can be done at the right-hand edge of the bottom most prototype area on the left side of the IO-2. Without cutting this trace, S-100 systems that use a front panel won’t be able to write to the 2101 RAMs.

The IO-2 manual calls for the data and address buses of the 1702As to be brought directly to the S-100 connector with no buffering. While this is probably OK for the original Altair, I wanted to buffer both the address and data buses to lighten the TTL load on the bus. The 1702A does tristate its output bus when its Chip Enable isn’t asserted, but the Intel manual doesn’t say whether the address lines are tristated as well. I decided to buffer the low 10 bits of the address bus with a pair of 74LS367 hex bus buffers, which should provide ample drive current for the board. But what about the two 8-bit-wide data buses?

The IO-2 is largely prototype area, but there are a few functions defined in copper. That includes two I/O ports based around the Intel 8212 8-bit latch. The Intel databook describes it as having tristate input/output pins, and it can obviously be interfaced directly to the S-100 bus since that was its primary function in the IO-2. The timing diagrams seemed to suggest that it should make a satisfactory bus buffer, even though the application notes and the IO-2 manual didn’t describe using it in such capacity. As such, the first real test of the board was to see if the 8212 was fast enough to capture a write to memory space and latch it.

Two HDSP-0962 hex displays were inserted into one of the yet-unwired 1702A sockets and attached to the write buffer’s output. Their input latch lines were tied false, so that they displayed whatever was latched on the write buffer. The 8212s can be connected to the address decode exactly as they would be for an I/O board at this point. After setting the address switches for 0x2000 (all switches except #3 off), I wrote bytes to 0x2000 - 0x20FF and, as seen above, got the expected behavior. Success: the 8212 is fast enough to use as a memory bus buffer!

Device Selection and a BOARD ENABLE Signal

My device select scheme ended up being a bit more involved than the original IO-2 manual’s design. Rather than fixing each device at a defined segment in the board’s address space, I soldered eight machine pin sockets to the output pads of the 7442 BCD-to-decimal decoder. This allows the insertion of 24 AWG wire jumpers between the 7442 output pins and the devices on the board:

With this arrangement, any device on the board can be addressed at any 256 byte segment in the board’s address space. Since the IO-2 is now configured to use its 8212s as data bus buffers, we also need to provide a BOARD ENABLE signal to turn the bus buffers on whenever the board is being written to or read from. To accomplish this, I used a 74LS30 eight-input NAND gate with all eight inputs pulled high through 2.2K resistors. The inputs of the 74LS30 are hardwired to the device select sockets at the devices themselves. Therefore, we can generate an active-high BOARD ENABLE from the 74LS30’s outputs that will go high whenever any 256 byte address segment select goes active, as long as that segment is jumpered to a device. This prevents the bus buffers from turning on when no devices are responding to the currently addressed segment, which will be important later…

Our active-high BOARD ENABLE is of limited use (it does drive a LED through a 2N2222 transistor), so it is inverted through one inverter of a 74LS04 and becomes active-low. Thus, whenever a jumpered address segment is selected, BOARD ENABLE goes low. The active-low /BOARD ENABLE can be tied to both 8212 /DS1 pins (pin 1). With DS2 (pin 13) tied to INP STB for the lower 8212 (the read buffer) and OUT STB for the upper 8212 (the write buffer), our bus buffers will only be active on memory reads and writes to jumpered address segments in the IO-2’s switch-specified address range.

Adding the Devices

Time to add actual memory devices to the board! I ended up placing two 1702As in the 24-pin footprints at the top-right of the board, as well as two more in the large DIP space in the middle of the board, for four 1702As total – a whopping ONE KILOBYTE of ROM! Two 2101 Static RAMs were placed at the bottom-left of the board. The 2101 is a 0.4 inch DIP, so it straddles the center power traces unevenly. Speaking of power, the 1702A requires -9V in addition to a +5V supply, so a second linear regulator is also required. Fortunately, SSM provided space for a second TO-220 regulator and heatsink in the upper-left corner of the board. Power supply capacitor placement for the -9V supply is a little tricky, but I ended up with a dipped radial tantalum capacitor between pins 1 and 2 of the regulator and an axial tantalum between two of the “capacitor pads” below the +5V regulator.

And, in case you were wondering what this much circuitry looks like when wired as a point-to-point project:

So, Why Such Old Devices?

In short, because it’s fun! This project also provided me with a means to read 1702A PROMs, as well as testing 2101 Static RAMs. I plan to build a COSMAC ELF at some point in the future, and 2101 SRAMs are used there as well. Since I have a fairly feature-complete set of S-100 boards, interfacing devices to the S-100 bus makes them easy to read or test. I stuck to older bus buffers and discrete components in this project for practice in an upcoming build…more to come on that!

Future Features

While this board is pretty much complete, I do have two possible future additions. The first addition would most likely be a /PHANTOM assertion circuit, which would allow 256-byte blocks to appear scattered through contiguous RAM provided by other RAM boards, as long as they support /PHANTOM. The second would be a wait state generator, which would allow the board to be used with faster S-100 systems without jumpering the CPU card down a few wait states. Both depend on being able to generate a /BOARD ENABLE signal for only the devices that are actually jumpered to segments on the board.