Program Counter! The computer needs one of these. It keeps track of what memory location is going to execute next. Should be pretty straightforward: it needs to (a) store an 8-bit number; and (b) increment it on demand.

I guess I'd like to be able to branch, which means I'll also need to be able to (c) arbitrarily set it to a new value.

This is going to be interesting.

It would make sense to build this out of two counters; where the "add 1" instruction comes from the CPU's control logic ("hey, I just read from program memory! Increment now please"). But I don't have any two matched counters: I have two different unmatched counters.

I have one 74LS161AN, a synchronous 4-bit counter; and one DM74LS193N, a Synchronous 4-Bit Binary Counter with Dual Clock.

This picture is from testing how those are going to work. Also: I've obviously selected one RAM chip, picked out two bus drivers, and set aside two EEPROMs. Ignoring those for the moment, let's stick with the counters.

The counter on the left, shown here with the lit yellow LED under it, is the '193. The '161 is a clocked adder, perfect for the job I want to do; while the '193 is an unclocked counter with both an "increment" and "decrement" line but no explicit clock. Not a big deal. If I use the '161 as the low order 4 bits, then its carry-out can trigger the '193's add. Easy peasey.

Except for one minor bit: the "carry" line is set high on the '161 when all of its outputs are 1. That is, the carry is set the clock cycle before the '193 needs to increment. If these were two '161s, this would mean that on the next clock cycle's rising edge, a second high-order '161 would notice that the carry-in flag was set and increment. But since the high order bits are a '193 and it's not clock-triggered, it happens immediately.

That means that these two counters count together like this, in binary, from 8 onward:

Whaa? 13, 14, 31, 16, 17 ... obviously not what you'd expect - but because the carry bit is set whenever all of the low bits are on, and the '193 performs that action immediately instead of waiting for the next clock pulse, that's the way it plays out with this pair.

Now, technically, I don't have to fix this. We could just say that this is the order in which instructions are run. It's not intuitive, and would certainly cause some headaches while trying to program the computer; but as long as the sequence is deterministic, there's nothing stopping us from using this very odd counting scheme. The last byte of the next 4-bit memory half-page is used first, that's all.

I'm confused just trying to write it down.

So no, obviously I'm not going to do that. Instead let's add a little bit of complexity in the electronics to bring back simplicity to the counting. Tomorrow.