Revised Verilog debounce module

A while back I wrote a post (here) about the Verilog module I used to debounce input pins. As I noted in a reply to that post, that module had a flaw that caused a single sample of the opposite polarity to be reported as an edge, even though the state output didn't change.

Later I found another problem. My modified Lattice iCEblink demo board has a clock frequency of 10 MHz. My Digilent Spartan 3E Starter board has a clock frequency of 50 MHz, and my Digilent Atlys board has a clock frequency of 100 MHz. There is no point in sampling the input pin at 100ns, 20ns, or 10ns intervals, as doing so would require a very long debounce FIFO. To address this I divided the system clock down to provide a clock enable input of a more reasonable 100 KHz, resulting in the input being sampled every 10 microseconds (remember, the printer position sensor signals are only asserted for 500us, and exhibit no appreciable bounce). However, this meant that the edge detection outputs on the iCEblink were asserted for 100 clock cycles, which then required the modules using the debounce module to do edge detection on the edge detection outputs. That's silly.

M-32TL Timing: Why three position sensors?

While reviewing my last post I realized that I'd left out an interesting behavior that happens after the printer hammer fires.

Let's look at a couple of waveforms captured using an intact P170-DH calculator. All of these are taken from the same capture, covering the printing of the first 6 characters on a line. The sensor signals are labeled based on the operation I expected when I started working with this printer rather than the nomenclature I use now.  In each case I've placed cursors at the leading (falling) edges of the "Rotation Index" signal; these mark the start and end of one complete revolution of the print wheel.

EP-102 to M-32TL Glue logic

I decided to spend some time this weekend moving the interface to the Epson M-32TL printer forward.

The Busicom 141-PF calculator had a Shinshu Seiki (the predecessor of Epson) Model 102 drum printer. A drum printer has a cylinder (or drum) with rows of characters embossed across its width. The drum spins at relatively high speed, while a set of hammers on the other side of the paper presses the paper against the drum's surface at the right moment to print the desired characters. A full revolution of the drum is required to print all the characters on the line.

Here's a picture of a Shinshu Seiki Model 102 printer:

Since this printer can print 18 columns, it has 18 separate print hammers. Thus the i4004 software generates 18 signals in parallel using a pair of i4003 shift registers to activate the correct hammers at the correct time.

The Epson M-32TL printer, on the other hand, prints one character at a time by moving the print mechanism across the paper from right to left. Obviously some translation is required.

M-32TL Printer timing revisited

While browsing through my accumulated datasheets related to this project I found one for the Toshiba TC83230-0015 calculator chip. The information in it is sparse but it specifically mentions the Epson M31/M31A printer. The suggested system block diagram includes one tiny clue:

More thoughts on i4004 clocking

Much of my concern, as expressed in previous posts like A clocking nightmare, have been based on the assumption that reflections on one of the two clock lines could cause multiple edges and thus multiple clocking of edge-sensitive circuits. While this would be correct with modern edge-clocked flip-flops, I don't think it applies to the original 4004 circuitry.

Fighting router's block

I've been quite busy at work -- you know, the thing that pays the bills -- so I haven't had much time to work on my hobby projects. When I have had time, I've found myself tinkering with small layout details and not making much progress in the routing of the board as a whole. I think of it as "router's block", akin to writer's block where you just can't seem to make much progress.

Rattling around in the back of my mind is still the question of how bad the clock distribution on my discrete component i4004 boards is. I'm hoping to find time to sit down at my electronics bench and really take a look at what the clock signals look like now. But how would I tell how adding a second (and, later, a third, fourth, and fifth) board would affect this?

Late one night it occurred to me that when I had the Instruction Pointer board fabricated I got two boards. The idea was to avoid a situation where I screwed up one board and had to wait for another to be fabricated and shipped from Europe, and it would serve as a reference if I wanted to check connectivity. Since the essential BSS83 MOSFET is no longer available I have little use for this second board. So why not use it to help test the clock distribution behavior!

All I need to do is mount connectors on this board and I have a ready-made second board to add to the board stack. Since I don't need this board to be functional, I can add whatever loads I might want to the clock lines and see what effects it would have while probing with my 'scope.

Now all I have to do is find the frelling thing. I've found the packaging these boards were shipped in (seven years ago!) but it's empty. I looked in all the obvious places for it, such as the box containing most of the components for this project, but thus far I haven't found it. This might actually be the incentive I need to properly organize my electronics lab.

Flipping the P170-DH board in KiCad

After flipping the power subsystems from the front of the board to the back and fixing up the layouts, the only parts remaining on the front of the board are the VFD, a filter capacitor, and the power fuse. Everything else is going to be mounted on the back. Thus it occurred to me that when I do most of my work with this board, I'm going to be looking at the back. That's where almost all of the components are. And once the board is mounted in the calculator's upper shell behind the keypad, the back is the only side I'll be able to see.

KiCad allows me to flip the display of the board in the pcbnew board editor. However, if I print an image of the board it's still the view from the front that gets printed. That means I'd either have to be looking at the board layout on a computer when placing parts and debugging, or mentally transpose component positions from a printed image. That didn't sound appealing.