Visualizing ROMs 1: Diode Matrix ROM

As a part of my BarCamp Fall 2013 presentation about visualizing ROMs, I decided to build a Diode Matrix ROM at Interlock this week. I should note that this is not practical, but it was a fun exercise in making physical data.

To start with, ROMs come in a few different varieties.

The most well known are EPROMs.  These are ICs with a quartz window on the top, through which you can see the storage array on the silicon.  This window is used to erase the ROM with ultraviolet(UV) light, then you can use a programmer to re-burn the ROM with other data.  It remains mostly non-volatile, unless it's erased with UV light again, via an eraser or by leaving it in the sun for a couple weeks.  These kinds of ROMs are useful for when you need to reprogram the content, or if the production runs are relatively small. These are often used in video arcade machines, as the program or graphical data might need revisions, and production runs are not in the "millions".

Another kind of ROM is the PROM, which is progammable once. It does not have a window on the top, and cannot be re-erased, as the bits are stored by actually burning out links on the IC.

Yet another kind of ROM is the Masked Rom. (Not related to Zorro or Mask Man.) This is not programmable at all, as its data is formed in the IC fabrication process.  Many mass-produced devices use this, like BIOS ROMs for PCs, Kernel ROMs for the Commodore 64, Kickstart ROMs on Amigas and so on.

Another way to produce a ROM is to actually physically build one using diodes at each of the bit positions. This makes for physically large ROMs, but is useful for very small production runs of very small amounts of data. In the past, Diode ROMs were used for boot programs for early mainframes like the DEC PDP-11, and are currently used for model railroading electrical logic.  I decided to make one of these.

Documentation on how to build one is a bit sparse, as not many people have bothered to make one, for obvious reasons. I went forward anyway and "winged it".  I built what you see in this in one evening at Interlock. I will attempt to describe the basic theory of operation in this post.


The data in a ROM is generated when an address is fed into the chip, and an enable line is activated.  This goes into the ROM chip, and activates the data bits at that address.  Those bits are then reflected out to the data output of the ROM itself.

For my example, we will make a 24 pin "part" that simulates use of a 2716 ROM, using its pinout.  We will plug this into my EPROM reader/programmer to dump out the contents.  More on this later...  Due to the nature of this circuit, I will be ignoring all of the address bits above A1, the activate/latch functionality (OE) as well as the programmability of a standard EPROM.

We will only look at address bits A0 and A1.  This means that there are four possible addresses we can use. A0 and A1 from the chip socket are wired into a "demultiplexer" chip, 74LS139. When A0 and A1 are (0,0) the '139 will enable only Output 0.  When they are (0,1) it will enable only Output 1, and so on.  Since the upper bits are ignored, once this reaches past (1,1), and becomes (1,0,0), we will read it as (0,0) and we will produce the same outputs. This means that our content will repeat over and over again, since I ignore bits A2-A10 of the address lines.

In the diagram above, the upper chip pinout sketched is the '139.  the two inputs are on pins 2 and 3, and the outputs are on pins 4,5,6,7.  The lower diagram shows the 2716 part pinout.  A0 and A1 from pins 7 and 8 go to the '139. Data output from our diode matrix goes to pins 9-11,12-17, to be read by the EPROM reader.

The above is shown in this diagram as the top two chips.  The diode matrix is shown below.  The orange lines are the outputs from the '139 part, as AD0, AD1, AD2, and AD3.  It will output 0v (active low) on only the selected line, and +v for the three other outputs.  Our diode matrix has 8 data bits shown as D7..D0 above.  Those are weakly pulled up to +v.  At the junction of any of the address lines (orange), and any data line (black), a diode can be added to signify a digital "0" as the diode will pull the current from the pullup'ed data line down to 0v.  If no diode is present, it will remain pulled up, tp +v, or a digital "1".  I should note that the values for each of the data pins are 0x80 (1000 0000) for D7, 0x40 (0100 000) for D6 and so on down to to 0x01 (0000 0001) for D0.

We want to output "Hi! ", repeating in the rom, so the four bytes we need to store are the ascii values for these characters, 0x48, 0x69, 0x21, 0x20... in binary form, this is (0100 1000), (0110 1001), (1101 0001), and (0010 0000).  As you can see above, if you look at the first of these, and read across you will see the presence of a diode where a '0' is signified, and lack of a diode where a '1' is.

The above image shows the physical interpretation of this circuit, annotated.  The 2716 connector is in the top right, '139 demultiplexer just below it on the right.  Its outputs become horizontal traces on the back (see the below image) to which the diode cathodes are connected, and the data bits become vertical wires on the front, to which the diode anodes are connected.  The pullups are at the top, connected to a +5v bus at the top. (Note: after this photo was taken, the blue data lines at the top were crazy-glued down to tidy them up a bit.)

The back of the board (kinda) shows the horizontal traces.  Trust me... it's there.  Stripboard isn't always easy to understand by looking at it. ;)

Since the Needhams EMP-10 requires a parallel port, and a MS-DOS based software package, I have dedicated my old Toshiba Libretto 50 only for running it.  It has Windows 95, a 10 gig disk, and not much else.  You can see it running scandisk as it boots Windows 95. Fun.  I could buy a new programmer, but why bother when this works well, and a new programmer is expensive.

So I built this board, and put it into my Needhams EMP-10, and I can retrieve the content out of it.  The notch on the right is so that I can use the latching lever in the ZIF socket.

And here you can see the buffer read in by the programmer.  The physical rows of diodes have become non-physical data inside of the computer. It's sorta like the digitizer in TRON, but not really. ;)

Bonus picture...

The following picture shows when it was not working correctly, before it was debugged.  There are a few things wrong, starting with some accidental shorts on the back tying some data lines together (not shown), but there's also one major issue here, and a bunch of minor issues here which are visible in the following photo.  See if you notice them...

Do you see the mistakes?

To start with, the 3rd data line from the left (D5 or 0x20) is both running to the wrong side of the diode, and is also not soldered to it.  The mistake harder to see is that the top two horizontal rows of diodes are completely not soldered to the data lines at all.  If they outputted anything it was accidental.  This is what happens when you're tired and too quick to plug it in and try it out without visually inspecting it.  Oops!

Update:  This article was featured in Hack A Day on October 18th, 2013.  Hello friends!