I used Verilog to do a simple test to estimate the machine’s top clock speed. I kept increasing the clock rate until the validation test suite started failing, and it topped out at about 2.63MHz. That feels respectable for a home-built machine. In reality I think I can go faster than that, since the timing data for my Verilog simulation is built around the worst-case estimates. Depending where the critical path is (I didn’t investigate to see), I may also be able to speed it up further by using a two-phase clock. Of course this all assumes I’m not limited by signal noise or some other intrusion of physics into the digital domain!

Time to celebrate! I powered through the remainder of the microcode for the core machine instructions, along with a full test suite to verify each instruction, and it all works. That’s 50 different instructions, and a couple of hundred individual tests. The test suite program alone fills more than half the machine’s ROM. Whew! I’m beat.

What I call the “core” instructions are the overlap between the 6502 instruction set (from which I’ve largely adopted the assembler syntax) and BMOW’s instruction set. That means jumps, subroutines, branches, math, boolean operators, comparisons, stack manipulation… everything you would need to write a real program. It obviously doesn’t include instructions related to 6502-specific features, like the Y register and zero-page addressing. It also doesn’t include planned BMOW-specific instructions and addressing modes; these will come later, but they aren’t essential. The core instructions provide all the functionality needed for most programs.

I resolved the problem regarding overwritten condition codes with the quick and dirty solution I first thought of. The machine saves and restores the CC’s on the stack during the instruction’s execution. ADC, SBC, ROL, and ROR all faced this problem, and my solution adds 3-4 clock cycles to those instructions. That stinks, but at least it works.

Ultimately, I think I may implement the extra carry pseudo-flag I described previously. That would let me reclaim the lost clock cycles on those four instructions, and also save a cycle on several other instructions in certain cases. Perhaps more importantly, it would also remove the need for many other instructions (like branches, or anything using x-indexed addressing mode) to modify the condition codes.

Here’s the source for BMOW Microcode 1.0. The microcode syntax is mostly self-explanatory. Each line is prefixed by a set of condition codes. A prefix of “*” means the line should be used no matter what the values of the condition codes, while a prefix like c=1 means the line should only be used if the carry flag equals 1. Each line (or pair of lines, in cases like c=0, c=1) represents one phase (one clock cycle) of the instruction’s execution.

The longest instructions are BRK (all the machine state must be saved) and ROR (rotate right is performed by repeated rotate lefts). Each is 16 cycles. At the other extreme, INX, DEX, ASL, TAX, and TXA are all 1 cycle, and many others are 2 cycles.

Uh oh. I was cranking through the microcode implementation for BMOW’s instruction set, making good progress. I’d finished about two-thirds of the microcode, when I came to ADC absolute, X-indexed. That’s when the wheels came off the cart.

This instruction (add with carry) is supposed to take an absolute memory address, adjust the address by adding the contents of the X register, then add the value at the effective address to the accumulator, plus whatever value was already in the carry bit of the condition code register. Unfortunately, I don’t see how I can reasonably implement it with my current hardware design.

The reason that ADC $NNNN,X is problematic is that it modifies the condition codes (to test and propagate a carry from the low byte to the high byte of the effective address when adding X), but it also depends on the current value of the condition codes (for the carry flag). The effective address computation destroys the carry bit that’s needed for the add step. SBC $NNNN,X (subtract with carry, absolute, X-indexed) has the same problem.

I see two possible ways to fix this, neither one great:

• Store the old condition codes somewhere before computing the effective address, then restore them for the add step. That would make this instruction unreasonably slow, however. It might not even fit within the 16-clock limitation for a single instruction.
• Add a fifth pseudo-flag to the condition code register for handling the carry propagation during effective address computation. This flag would be invisible to the programmer, and only accessible at the microcode level. But that would give me 5 bits in my 4-bit condition code register, and also require compensatory changes in the control subsystem and microcode assembler.

Poop.  I’m half hoping that if I stare at it for a while, I’ll think of a better solution.

I think I may be getting too concerned about potential optimizations to the hardware design, before I’ve even built or simulated the initial design. A couple of possible optimizations occurred to me recently.

Improved CC Register: I described earlier how the condition codes are stored in a 4-bit shift register with parallel output, enabling the control circuitry to read all the flags simultaneously. Copying the condition codes to/from a register is done serially, requiring 4 clock cycles of bit shifting.

My latest improvement idea is to use a GAL to make a custom 4-bit register with two independent parallel load inputs, one connected to the ALU and one connected to the low 4 bits of the data bus. That would permit loading of all the condition codes from a stored value in a single clock cycle. The outputs of this GAL-register could also drive the data bus, either directly or through the ALU, making it possible to store all the condition codes in a single clock cycle as well.

These improvements would only benefit instructions that load/store the condition codes, though, which really only happens during interrupt processing, so maybe it’s not worth the effort. There are also a few problems regarding how to connect the GAL-register output to the data bus that I would need to resolve.

An Extra Data Register: A while ago, I considered adding a Y register to the machine, but ran into the limit of 8 possible load destinations. Now that I’ve increased the limit to 16, adding a Y register would be as simple as adding 2 more chips to store and drive the data. The required load enable and output enable lines are already there.

Unlike the A and X registers, the Y register would be connected to the right ALU input, which presents some problems. The T (temporary) register is connected to the right ALU input as well, which means it would be impossible to directly compute any functions of Y and T. For example, to add a constant value to X, the machine can load the constant into T, add X and T, and store the result where needed. But to add a constant value to Y, it would first need to copy X to T, load the constant into X, add X and Y, then restore the old value of X from T.

That would give the machine the odd property that operations involving Y are slower than those involving X and A. To be most useful, the proposed Y register really needs to be connected to the left ALU input, but that input is already “full”, and I don’t think I can relocate or remove any of the existing left inputs.

Too Many GALs? In my drive to optimize the design and reduce chip count, I’m beginning to wonder if I’m using too many GALs. I keep finding more and more places where two or more 7400-series parts could be replaced by a single GAL. For example, every combination of a ‘377 register and ‘244 output driver could be replaced by a single GAL, and the 16-bit pointer registers could be built from two GALs each, instead of four ‘569 counters. In fact, I could replace almost every chip with a GAL, except for the ALU, memory, field decoders, and a few drivers. In that case, looking at the schematic wouldn’t tell you anything at all about how the machine worked, and you’d have to read the GAL program data to understand anything.

I’m not sure I like that idea. Although it would still be a real hardware implementation, it would feel more like a simulation in many ways. It would also once again raise the question of why not just implement the bulk of the machine as a single FPGA?

For the sake of comparison, I estimate that using GALs as much as possible would reduce the component count to about 40, while not using GALs at all would increase the count to about 60.

I’ve finished the design changes for interrupts. It worked out pretty much how I’d outlined earlier, using a GAL to implement the special OP register that has both a load enable and a clear input, since no such 7400-family part exists. I also added an interrupt enable bit that can be set and cleared from the microcode. When OP is about to be loaded with the next instruction, and interrupts are enabled, and an interrupt is pending, then the OP register will be synchronously cleared upon the next clock edge. This will force the machine to execute opcode 0, IRQ, which saves the processor state and jumps to an interrupt service routine.

I also made a necessary hardware change to support multitasking: making the stack pointer loadable from microcode, so it can be saved and restored across processes. The machine now has 10 possible destinations for storing data, instead of the 8 it had previously. That change required me to spend my last unused control ROM bit to make the store destination a 4-bit field rather than 3 bits. If I end up needing another control ROM bit for something else later, it’s going to be a problem. I also had to add a second 74LS138 to decode the additional store destinations, so now the component count is up to 51.

Condtion Code Optimization: I originally planned to use 8K control ROMs, with 13 address lines: 8 for the opcode, 4 for the phase, and 1 for the current condition code. That’s why the condition codes are stored in a shift register. If the desired condition code isn’t already in the least-significant bit of the shift register, then it must be right-shifted until it’s in the right spot. Since it takes one extra clock cycle for each shift of the condition codes, this design results in the somewhat bizarre property of testing the carry flag being faster than testing the negative flag, which itself is faster than the other flags.

It turns out that the most commonly-available (and cheapest) ROMs now are 64K or 128K. A 64K ROM has 16 address lines, providing enough width for the 8-bit opcode, 4-bit phase, and all 4 condition codes simultaneously. No more shifting! That simplifies the microcode, and also puts all the flags on even par with one another with regards to testing time.

Although bits are no longer shifted out of the condition codes in order to test them, the shift register is still needed for a different reason. When restoring the condition codes after an interrupt, the old values are shifted in, one at a time. Since the parallel load inputs of the register are connected directly to the ALU, there’s no other way to set the condition code values without adding extra multiplexing hardware.

I made an accounting of all the components needed by my design as it stands today. It totals up to 50 components altogether, with a combined cost of $114.32.