After restructuring half the project to add an overflow flag and all the necessary support for it, I got back to routing. I took a much more liberal, placement-centric approach to laying out and routing, and this changed some of the wiring on the buffers to make sure traces don't cross. It makes perfect sense in retrospect, of course, but if you pinswap enough, the number of vias on the board can be reduced a lot. As a result, you get more PCB estate to play with. The result is an elegant looking, clean Major Register board. This one plays host to the AC, PC and DR registers, their increment logic, and also the Zero flag (Z).

The render isn't all it could be, but it shows that things are working out.

The ALU

I've also started routing the ALU. The original revision of the ALU had it on two boards because of the sheer amount of logic and the six DIP32 packages taking up so much space. Some of the logic has moved off-board now, and I'm confident I can fit all six ROMs on one board if I use PLCC32 packages. This feels a bit weird to me because PLCC32 has that ‘modern’ look to it, and also because I have very little experience placing and routing PLCCs. PLCC packages appear to be cheaper, though. I'll just have to build a DIP32-to-PLCC32 adaptor for my Flash programmer.

The Software Side

Last week, I finally managed to get 32-bit division working. It's horrendous and long and nowhere near as elegant as 16-bit division, but that's only to be expected. The PDP-8's code isn't that clean either — you have to do a lot of repetitive tasks. I'm starting to think I should add proper macro facilities to cftasm.

The Verilog Side

The Verilog simulation of the CPU works again, even after including all the new changes. This needs to be put to the test, though. Which brings me to...

Testing

I need to start using the test framework again. To do so, I need to make sure both the Verilog simulator and the emulator itself produce output that the testing framework can use. This shouldn't be too difficult — it just greps for keywords in the output, after all. I need to enhance the collection of tests to cover:

• All instructions
• All addressing modes
• All combinations of minor operations
• As many combinations of instruction sequences as I can (this could be hairy, if all combinations of everything are attempted)
• As many combinations of ALU operands as I can (quick enough for logic functions, shifting, etc. Not so quick with the four billion combinations of two 16-bit operands for additions)
• Branching on all combinations of flags
• Interrupts
• As much peripheral hardware (e.g. interrupt controller, memory banking) as I can
• Basic algorithms