A VFD module for the calculator?

One of the problems with converting a stock calculator to emulate a Busicom 141-PF is that most calculators these days max out at 12 digits, while the 141-PF was a 15-digit calculator. The example Tim McNerney gives in his PIC-based printer emulator test data is:

//                   111111 1 1
//          123456789012345 7 8
/* ============================= */
/*          3.1415926535897 x    */
/*                        2 =    */
/*          6.2831853071794   *  */
/*                               */
/*                     -456 /    */
/*                     2.37 =    */
/*         -192.40506329113   *  */
/*                               */
/* ============================= */

Thus it's not as simple as dropping a couple of digits to truncate the output to 12 digits. Nor would that account for the two special characters that appear in columns 17 and 18. One way I'm considering handling this is to replace the P170-DH's fluorescent display with an LCD module.

One I'm considering is the CFAH2002A-TMI-JT module from Crystalfontz, a company I've bought from before. This module is a negative transmissive LCD with a blue foreground and white LED backlit characters. This is important because the P170-DH has a blue-colored plastic bezel, and I think this combination is most easily viewable compared to a the typical yellow-green transflective display. It displays two lines of 20 characters each, so I could either show the last two lines printed or display status on the second line. It's fairly inexpensive at about $15, but presents some mounting challenges.

Still, the idea of using a Vacuum Fluorescent Display module has stuck in my head. Most of the VFDs I've found haven't been suitable, but I just came across the DS2029H from Noritake-Itron. Not only does this module appear to be an almost perfect fit for the P170-DH, it's less than $30 in sample quantities from the manufacturer.

Of course VFDs require some strange power supplies (+5Vdc and +35Vdc in this case) but that's manageable. This module includes a controller that looks much the same as those found in LCD modules so I don't need to deal with segment drivers and the like. They also sell VFD modules that look just like LCD modules (including one they're discontinuing that is being sold at only $18), but like the LCD modules they wouldn't fit as well.


Edited to add: I ordered a DS2029H Vacuum Fluorescent Display from Noritake-Itron Wednesday. It just shipped, so I should have something to play with next week.

Another reminder to myself

I was reading some old posts to this blog when I came across a good idea that I'd since forgotten: separate the external I/O driver Vdd from the internal logic Vdd. This would allow the external I/Os to be driven to 3.3V instead of 5V, easing the interface to modern electronic components such as FPGAs. I haven't tested this idea on a breadboard yet, but it seems like it ought to work. I'm writing this posting so I don't forget the idea again.

And what about the EP-102? I got it working, mostly. There's a weird hiccup that causes additional lines to be "printed" to the serial port, but I suspect that's a glitch in the test module and not the printer emulation.

I also looked at some LCD and OLED character modules. I'm torn between 20x1, 20x2, and 16x2 modules. The 20x1 would be most readable, but might not fit in the space available. A second line would allow me to display other info like the OVR indicator, along with the characters that should be in columns 17 and 18 in the case of a 16x2. I'm also somewhat constrained by the blue-colored window in the calculator's case.

EP-102 emulation

One of my goals, like so many i4004 hobbyists, is to recreate the Busicom 141-PF calculator. This was a printing calculator, using one of the earliest small digital printers from the company that became Epson. Some have done it with a compatible printer while others have used microprocessors to scan the hammer driver outputs and convert the results to ASCII.

I'm a professional software engineer, and have been writing software since learning Fortran in 1977. While I've written a fair amount of code for hobby projects it's not something that excites me anymore. Verilog and VHDL, on the other hand, are interesting to me because they require a different mindset and I love learning new things.

So I set out to develop an EP-102 emulator that would print on the Epson M-32TL printer in the Canon P170-DH calculator that I planned to cannibalize. Since I've been unable to find a datasheet for the M-32TL, I decided to put that off a bit and generate ASCII output on a serial interface. I can also emulate the keyboard with a serial interface, allowing me to run the real 141-PF firmware in an FPGA emulating the entire system while using a PC for input and output.

There are a lot of UART implementations available in VHDL and Verilog, but I wanted to write my own. Since I'm not looking for a full 16550 emulation it only took a few evenings to code and debug, including testing it on a Spartan-6 reference board. I'd hoped to test it on the Lattice iCE40-HX8 breakout board, but I'm having a minor but blocking issue with USB configurations (udev rules to disconnect one of the FT2232H interfaces from the serial driver, if you're curious).

Then I turned to emulating the EP-102. This is a tiny drum printer with 18 columns and 13 sectors per column. From the left, the first 15 columns can print the digits 0 to 9, a decimal separator (period or "full-stop"), or a "minus" sign. The 16th column is non-printing, and the 17th and 18th columns have various special characters. (This raises a problem with my plan to use the P170-DH, as it has a 12-digit printer. Maybe I'll replace the 12-digit VFD with a 20-character LCD or LED instead.)

When Tim McNerney analyzed the 141-PF for the i4004's 35th Anniversary he included notes on the operation of the EP-102. From these I constructed a Verilog module that looks like an EP-102 on one side and outputs a stream of ASCII characters when the "paper" is advanced on the other. This took another few evenings. I still have a bug in the synchronization of the sector timing (e.g. when I try to print 1s ASCII 2s are generated) but it's getting close.

I'm thinking it might be fun to create a "141-PF on a board" using the iCE40-HX8K breakout board, so I decided to build it for the iCE40 to see how big it is. Including the EP-102 emulation, UART transmitter, and a simple test "top" module I'm using 458 of the 7680 logic cells, or about 6%. To create a full system I'll need to add a 4004 CPU, 5 4001 ROMs, 2 i4002 RAMs, 3 4003 shift registers, the UART receiver, and the as-yet unwritten ASCII-to-keyboard converter. Will it fit? Stay tuned!

Thou shalt check up

One of the commandments that any engineer worth his salt follows is this:

Thou shalt not assume. Thou shalt check up and make damned sure.

In July 2012 I was trying to determine how many transistors of each type I should buy. At the time a BSS83 cost 27.6¢/ea when ordered in quantity, while the FDV301 cost only 4.7¢/ea. I'd discovered the FDV301 worked well in a grounded-source configuration but the gate protection diode could be a problem in other configurations. To help with the decision I created a spreadsheet. It breaks the 1749 FETs needed into three categories:

• 1041 with the source connected to GND
• 105 with the drain connected to VDD
• 603 fitting neither of the above two configurations

Clearly those in the first category were a good fit for the FDV301. The drain-to-VDD configuration wasn't suitable for the FDV301 because pulling the gate to ground could forward-bias the protection diode pulling the source to ground too. But it would guarantee that the body diode would remain reverse-biased, making another FET like the DMN26 a candidate.

When I went back to this spreadsheet this morning to see how many extra BSS83s I had on hand I got a real scare. I'd settled on using the FDV301 only in the grounded-source configuration and the BSS83 for the rest. That meant I needed 1041 FDV301s and 708 BSS83s.

I only purchased 700 BSS83s. And there are no more to be had.

I have a few short strips of tape with a few extra BSS83s I bought for experimentation but haven't used, but it'd be close. If any got lost or damaged I could end up not being able to complete the project. I bought 1200 FDV301s even after having identified a suitable replacement in the DMN26, but the BSS83 was a Unicorn. What had I been thinking??

I started thinking about replacing some of the BSS83s in the second and third categories with either FDV301s or DMN26s. The reason I hadn't done so before was the difficulty in creating an automated process for identifying those that have to be a BSS83.

Then it occurred to me that I'd already looked at one such second-category situation: push-pull drivers. I'd identified 58 places where the FDV301 would work better than the BSS83. More importantly, I'd made the substitution before purchasing the FETs, meaning I actually need 1099 FDV301s and only 650 BSS83s.

Instead of being short 8 BSS83s I have 50 extra, plus any in my little strips.

I'd have trouble respinning any of the boards, but if I don't screw up I have enough. To double-check this I reran an Eagle user-language program I'd written to count components on each board. The results of an early version of this program can be seen at the end of my posting on partitioning, but that version didn't differentiate between the transistor types. The updated version does and confirms the transistor counts above.

Whew!

The demise of the BSS83

I learned yesterday that the NXP BSS83 has been discontinued  as "non-manufacturable" and is no longer available. The last order date was December 2014 and the last delivery date December 2015. When I bought components for this project my intention was to order more than enough for the complete board set, but now I'm going to have to make sure what I have on-hand is enough. Fortunately 4-terminal FETs are only required in the pass-gate configuration and a few other critical spots.

I heard this from someone who is also interested in building a discrete component version of the 4004. Welcome to my insanity, Aston!

Over the years I've come across various FETs that could be used for such a project. The BSS83 RF FET was a good choice because it has a reasonable threshold voltage and a low gate capacitance (1.5pF), though it was N-channel rather than the 4004's P-channel construction. Others I identified included the N-channel Calogic SST215 (which might be a drop-in replacement for the BSS83) and the P-channel Micrel MIC94050. Tim McNerney suggested using the P-channel dual-FET BSS84 with the two transistors wired in series source-to-source (or drain-to-drain).

Aston has started experimenting with the MIC94050, which is now manufactured by Microchip. He asked whether it would work in the bootstrap load circuit given its low on-state resistance. My answer is it depends on what you're trying to do with it. My attempt to recreate the bootstrap load circuit was only to understand why this circuit was needed and how it worked.  My test circuit added several other components including current-limiting resistors, and I was able to recreate the circuit's operation well enough to understand it.

Tim McNerney, who is far more focused on recreating the exact design than I am, told me that Federico Faggin told him not to try to recreate the bootstrap load in a discrete component implementation because he'd never be able to match the characteristics with off-the-shelf components. I concur. You  end up with a complicated circuit where a simple resistor will do the job.

Fortunately bootstrap loads aren't necessary if you use true resistors as loads, as resistors don't turn off when the voltage across them drops below a FET's turn-on threshold the way FET loads do.

What other challenges might a hobbyist face when using the MIC94050 rather than a BSS83? I'd guess speed and power consumption will be the biggest factors. The MIC94050 has an input capacitance of 600pF, compared to the BSS83's 1.5pF and the FDV301's 9.5pF. For a given load resistor value, this will greatly increase propagation delays. To put some numbers to it, let's look at the rise-times with a 4.7K load pulling up the gate of a single FET. Trc with a BSS83 is about 7ns, and with an FDV301 about 45ns. With the MIC94050 it's 2.8us, which is more than double the 1.35us cycle time of the 4004.

To achieve a 45ns rise time we'd need to use 75 ohm load resistors, which would draw 67mA when pulled low. Assuming half of the 473 resistors are being pulled low at any time that's 14 amps at 5 volts, or about 72 watts. That'd keep your hands warm in the winter!

Worse, I haven't yet identified the longest combinational path through the 4004 logic. My recreated Instruction Pointer board appears to work quite nicely with a 2.0us cycle time, with the rest of the CPU emulated by an FPGA, but I think the critical path is in the ALU circuits. Thus I'm not sure even 45ns is fast enough to achieve a 1.35us cycle time.

Also consider the drive requirements for the CLK1 and CLK2 paths. CLK1 has to drive 28 FETs in parallel, and CLK2 has to drive 51. A little math says that's 17,000pF and 31,000pF respectively. The TC4427A Power MOSFET driver I used on my FPGA interface board is specified to drive 1,000pF at 5V in about 50ns, and has performance curves that show it driving 2,200pF in about 90ns, but we're still off by a factor of about x14.

All is not lost. The leakage current in modern discrete components is a lot lower than it was early in the development of integrated circuit technology. My DRAM test circuit appeared to hold its state for several seconds, while the 4004 refreshed its IP and Scratchpad registers every 500us or so. Since running a recreated 4004 built with MIC94050s at 741KHz isn't going to be an option, take advantage of the low leakage and run the system at a (much) lower speed. That will make everything easier to work with too (not everyone can splurge on a 1GHz digital oscilloscope).

More musing on a 6th board

As I mentioned a few days ago, I'm considering a sixth board. This one would carry a modern FPGA and components and serve two purposes:

1. An easily reconfigurable test board to allow testing of any single board or set of boards in the i4004 CPU board stack.
2. A system emulator for the i4004 CPU board stack, emulating the rest of the components of a Busicom PF-141 calculator.

A bigger, almost as cheap FPGA experimenter's board

When I started looking at inexpensive FPGAs reference boards a few years back one I considered was the Lattice Semiconductor iCE40-HX1K. My Verilog i4004 implementation consumes 42% of the logic cells (and more than 58% of the 1280 PLBs). I expect I could probably squeeze the emulation for a few other MCS-4 chips needed for a simple system into it, but there wouldn't be a lot of resources left for anything else. Routing in an FPGA starts to become the limiting factor at some point even when there are free logic cells (75% seems to be a commonly quoted number).

The same line of Lattice chips has 4K and 8K parts. The 4K part comes in a 144-lead TQFP with 0.5mm lead pitch, which is manageable, but the 8K only comes in BGA packages. At the time there were no reference boards for these but that's changed; there is now a breakout board for the iCE40-HX8K:

This breakout board costs only $43 makes 120 I/Os available to the experimenter.

If the 1K part and only a few I/Os suits your needs, the iCEblink board seems to have been supplanted by the iCEstick, which is not much bigger than a large memory stick. It's dirt cheap at $22.