Busicom keyboard interface

Now that I know the replacement board's keypad works, I started thinking about how to interface this to the emulated Busicom 141-PF calculator's "circuitry".

The Busicom scanned its keyboard using two MCS-4 family chips: a i4001 ROM and a i4003 shift register. A ROM may seem to be an odd device to use in this situation, but the i4001 also provided a 4-bit I/O port. The shift register provided 10 output pins and a simple way to walk a "0" bit down the outputs in sequence. Thus the keyboard was arranged electrically as 8 x 4 matrix. The shift register selects which of the eight columns is being read, and the I/O port reads which of the four rows contains a pressed key, if any. The last two "columns" selected by the shift register return 4-bit coded values from two slide switches.

This dictates the interface my emulation must present.

Keypad and Switch tests

For some reason I've been hesitant to test my keypad design. Maybe because it's something that is either going to work right or I'm going to have to scrap the board and have another one fabricated. But I figured it was time to find out.


High on my eventual success with the keyclick sounder, I decided to test the keypad and associated slide switches. My original plan was to do a simple "walking ones" test to make sure each keypad column could be driven high or low. However, because I decided to put Schmitt trigger inverters between the keypad row tracks and the FPGA pins, I couldn't do the same for the rows. To see what the row inputs were getting I decided to drive the 32-bit debug connector with both the column outputs and the row inputs. Having gone that far I added the inputs from the slide switches to the debug connector too.

Keyclick sounder tests

Today dawned dreary and rainy, so I decided I needed to spend some time working on the Canon P170-DH calculator rebuild. I pulled out my checklist of things that needed testing and decided to start with the audible keyclick sounder.


Before I decided I could make the fluorescent display of the P170-DH work, I decided that it would be advantageous to provide an audible feedback to indicate that a key had been pressed and recognized. I described my search for the "right" sound in my posting Tick... tick... tick... a couple of years ago, and I did a proof of concept using a 556 dual timer and a piezoelectric sounder. But I'd never actually tried driving the final circuit from an FPGA, figuring there really wasn't much to test with such a simple circuit.

Treating CLK1/2 signals as global latch gate signals

If I were to change the Verilog i4004 emulation to treat the MCS-4 system CLK1 and CLK2 signals as latch gates and not as clock enables, it seemed it might make sense to treat them as I would global clock signals.

Emulating old tech in an FPGA

When I started this project I had a couple of goals. The first was to learn about CPLDs and FPGAs, and how they were programmed using HDLs like Verilog and VHDL. My second was to understand how the i4004 CPU functioned internally, and recreate one in an FPGA. Somehow this second goal morphed into a third goal, which was to build an i4004 CPU from discrete components.

But my prime focus has always been on the learning, not on producing a result.

Spartan-6 distributed RAM confusion

Okay, I'm utterly confused.

According to the documentation. dual-port distributed RAM has one read/write port and one read-only port. It is is created by allocating twice as many LUTs as needed for single-port RAM; the write port writes both LUTs, but each read port addresses only one of the two LUTs. Thus one might expect a dual-port RAM to use twice as many LUTs as a single-port RAM.

Previously I created a test that instantiated one of the four dual-port 20x4-bit "registers" in an emulated i4002 RAM chip. Since the docs say a Spartan-6 LUT can be used either as a 64x1-bit RAM or as a 32x2-bit RAM, I expected XST to allocate two LUTs per port for a total of four LUTs per register. The "technology schematic" generated by ISE showed four RAM32X1D library primitives, yet the synthesis summary showed six LUTs allocated as dual-port RAM.

I could see four with things packed as I described above, or I could see eight if the synthesis used the 64x1 rather than the 32x2 configuration. But six LUTs made no sense. Changing the array size from 20 to 32 had no effect. So I created another test with the full complement of four registers.

Testing the External I/O interface

I finally got time to test the new P170-DH board's external I/O interface with the Spartan-3E Starter Kit's PS/2 interface. I found the results most interesting, and not quite what I expected.