This is the day 3 build picture again, where you see two EEPROMs sitting unwired at the bottom of the board:

These are clearly salvaged from something. One is marked so that they can be easily identified and put in the correct places in whatever I pulled them out of. Which means they've been programmed. Which raises one additional question in the "how am I going to use these?" camp.

It's not a given that they'll be usable.

Presumably, whatever device they came from was using them as updatable storage. So they probably do work as such. Sometimes manufacturers have funny tricks they can play for their customers, though: custom settings in the hardware that make it not quite adhere to the datasheet specifications. And I wonder if that's going to be the case for these.

Normally, when you write to an EEPROM, you can simply set the data lines correctly and a byte gets written. There are optimizations for writing multiple bytes at once, but they're just an extension of that model. But there's a way to further protect the contents of the device.

It took a little work to find the exact datasheet for this manufacturer, but it confirms that these have a software protection mode. If you write special bytes to certain memory locations in a given order, it activates this mode - where, if you want to write to the device again, you have to go through another little dance (figures 9 and 10). Whether or not these two chips are protected that way, I don't yet know. So it's time to build an EEPROM programmer to find out.

I grabbed an Arduino Uno and some already-chained 'HC595 bit shift registers to cobble together a clone of the EEPROM programmer that Ben Eater built. You'll see three 'HC595s on mine, here on the left:

... that's not because I needed them. It's because I had those wired up from another project. If you only need two, you only have to pay attention to the first two chips in series. Which is what I'm doing.

The EEPROM you see on the left is not connected. There's another under the mass of wires, and with a little debugging of my messy wiring, I can confirm - both chips are programmable. I did throw the "software protect disable" commands at both of them, but I don't actually think they were protected; I think I was just fighting a bit of a wiring problem.

No matter! We're off to the races.

Now, before I call this day done: I've obviously built out the boards a little. This goes hand in hand with some planning about what's going to go where so that I can place an order for the parts I'm going to have to *sigh* BUY, because I don't have the right pieces in my junk stock at all.

Notable ICs I'm going to need to order:

One adder. I have one 74LS83, which gives me 4 bits of adder. I need another 4.

A pile of bus transceivers. I've only got one more 4-bit bidirectional transceiver; I'm going to need many for the ALU that I've designed. Which will be total overkill of course. :)

Two XORs. Only because I want an XOR assembly instruction in my computer. For no real reason other than a love for completeness. I have AND and OR gates; I want XOR too, and don't have the gates to craft it out of my supplies.

A good number of LEDs. As you can see from the RAM output section, I've started having to mismatch the LEDs; my LED bin is almost empty! I never thought the day would come. I'm partial to 3mm LEDs these days, so I'll order three different colors, 16 each, which might be enough for this project.

One 1-megaohm potentiometer. The small black trim-pot on my clock board is 10k ohms. That doesn't give me a lot of variation on the clock speed, and I'm finding myself replacing capacitors to change speed while playing around. I would like that to be more flexible, and I don't have any potentiometers sitting around that are in the mega ohms range.

Some more EEPROMs. I had thought I'd make this a Von Neumann architecture machine - where the program and data are both stored in the same memory space in that 8k RAM chip. But having only an 8-bit bus means there's a bigger challenge here: if I enable the high 5 bits of RAM through an off-the-bus "PAGESEL" kind of instruction then I'd be able to address the RAM fine... but it will be tricky to change pages, keep the program running, and have all of the data that the program needs in the same page with the code it's executing. It would certainly be possible but this feels like a complication I don't need or want.

Which leads me back to the Harvard Architecture, where the program and data spaces are totally independent. It's much more tractable to deal with RAM pages separately from code pages. I could use the other RAM I've got for the program space, and add some toggle switches and buttons to manually input data. That also sounds like complication I'm not looking for. I would like to be able to program this thing, have it run, turn it off and on again, and still have it run. So I'm going to need at least one EEPROM to hold the program.

But I've got two! Which would be fine, if there were only 8 different actions that could be performed in hardware (actions like "put the RAM contents on the bus" or "store the bus contents in Register X"). A quick count shows I've got 15 different actions in my plan. I could come up with some clever 555 timer hack, driving a bit of EEPROM address space and enabling one of two output latches with 8 bits of EEPROM output; then a second 8 bits of EEPROM output. And again, that sounds like it's just a little out of reach with the parts I've got in the bin.

So: two EEPROMs will drive the control logic; another one for the program. Check.

And last but not least: two magnitude comparators. I want a comparison function that sets the Carry status flag in a way that can be used for conditional branching. Which means I need comparators to tell which of the registers being compared is greater.

Okay. Order placed. This sits for a few days and I'll design the ALU, instruction set, and microcode while I'm waiting...