My recent wire-wrapping progress has been painfully slow: I’ve timed myself at about 2 minutes per wire. You might wonder how it could possibly take that long, but all the measuring, stripping, threading, wrapping, and squinting time really adds up. But despite my slow speed, I’m still moving steadily towards a working homebrew CPU.

Yesterday I finished the control section, which is the most complicated part of the CPU. That puts me somewhere in the 25% to 30% range for total CPU completion. As I was nearing the end of the control section, I realized I was running out of wire, and began to worry that I would run out before finishing the last connection. As it turned out, I finished the control section with a bare spool and about 2 inches of wire remaining. Now I’m on a forced hiatus until my replacement wire stock arrives.

The control section by itself doesn’t do much, since there’s no program for it to run, and no registers, ALU, or memory for it to control. But due to some lucky accidents, I was actually able to run and test a program of sorts. Here’s a photo of the setup:

There’s no program ROM, so nothing from which to load opcodes. The opcode register with unconnected inputs appears to default to an opcode of 0xFF, so I programmed the micro-ROMs with a test micro-program for that opcode. My test micro-program exercises all of the various control output signals, which don’t currently do anything. However, I was able to verify their operation with the logic analyzer, and make sure everything is working so far.

I only ran into one problem, with the /DRALU signal that will drive the ALU output. Occasionally it’s a 1 when it should be a 0. More careful examination showed that the bogus 1 value only ever appears immediately after a valid 1, as if it were “stuck” on 1 for an extra clock cycle. The problem also only happens within the first second or two after power-up. After that /DRALU always looks fine, even if I reset the CPU while keeping the power applied.

I also looked at the /DRALU signal with the oscilloscope, and it goes from a nice clean 0 volts for a logical 0, to a nice clean 5 volts for a logical 1, to OH DEAR GOD horrible noise for one clock cycle, then back to a clean 0 volts. So clearly there’s noise that sometimes causes what should have been a 0 to become a 1, but I’m not certain why.

My first guess was a bad/flaky connection on one of the /DRALU pins. However, I can’t see why a flaky connection would only be a problem during the first couple of seconds after power-on, and only during certain clock cycles. And once the machine was warmed up, I wasn’t able to reproduce the problem, no matter how much I jiggled the board, chips, or wires.

My second guess was that I was getting unpredictable behavior, because some of the micro-ROM address inputs are still unconnected. However, the data in the micro-ROM is organized such that the data value will be the same regardless of whether those unconnected address inputs are 1’s or 0’s.

Once I get more wire, I plan to connect up the remaining unconnected micro-ROM address inputs, and see if the problem goes away.  If not, I’ll try cutting out and re-wrapping the wires that carry the /DRALU signal. If that still doesn’t fix it, then I’m going to be in for some difficult debugging.