I have been experimenting with several pocket computers over the years. The brands of these pocket computers are usually either Sharp or Casio. The Radio Shack models are either rebranded Sharp or Casio models as well.

Whether it be a Sharp or Casio device, each has their proprietary peripherals, such as printers, cassette interfaces, and serial ports. Very few have peripherals with parallel ports, which is convenient for using standard line printers.

As time goes on, it becomes more and more difficult to find these obscure and vintage printers, cassette interfaces and interface boxes. Several hobbyists have created their own interfaces for connection to PCs for example, and many are decades old by now.

As I have experimented with various models of pocket computers, each has their own printer, for example, and each usually has some obscure quirk rendering them almost obsolete these days.

For example, one particular printer I have needs aluminum coated paper which is all but unobtainable these days. Others use tiny plotter pens, also unobtainable these days. Fortunately there were some pocket computer printers which were thermal and had used paper that is still available today. Even so, these are not easy to find these days.

A New Project – Vision and Scope

In the age of inexpensive microcontrollers, I wanted to experiment to see if I could use one of these microcontrollers to interface with a pocket computer.

Ideally, it would be useful to have a single device that can be connected to various Sharp and Casio models and software configurable as to which device it is connected to.

The device would then emulate the pocket computer’s respective printer and cassette interface for example.

The device would plug into the pocket computer and effectively be a bridge to a standard parallel or serial printer and perhaps a MicroSD card as a cassette storage emulator. This would allow anyone with only the pocket computer and this device to be able to print to a printer and save and load programs.

The benefit of this device would be twofold. One, it would allow for those who may have only the pocket computer and none of the peripherals to be able to save and load programs as well as print. Finding the respective printers and cassette interfaces these days is difficult and can be expensive.

Second, this device could be built quite inexpensively by those who might have some basic electronics skills, or, purchased pre-assembled, again, at a lower price compared to sourcing the original peripherals on auction sites.

The device could eventually be compatible with several models of both Casio and Sharp Pocket computers as well as others.

The device itself would be simple, using a microcontroller with onboard flash to store the firmware, a serial port and a parallel port. Power for the device would need to be provided, either by a battery or USB connection for example.

Computers these days do not necessarily have RS-232 ports, and USB based serial ports are common. This device can have a USB port with a serial port embedded providing both a serial port for a PC connection for additional integrations and it could also be an optional power source for the device itself.

For the first round of features, I will not be focusing on the bigger expansion bus found on some models, such as the Casio PB-1000, Sharp PC-1500, or the FX-880P. I will instead focus only on the simpler interface pinouts, such as the Casio PB-100 series and the Sharp PC-1211 for example.

The printer I plan to use is an inexpensive Epson POS thermal receipt printer. These printers are fast, use inexpensive paper and are easy to obtain.

Inexpensive Microcontrollers

There are several microcontroller platforms to choose from, including the Pico, ESP32, Arduino, and others. All of these options are far less expensive and capable these days compared to 25 years ago as an example.

My last experience with microcontrollers was with a Motorola 68HC12 and programming in assembly. The project was a digital answering machine using a series of ISD voice recorder ICs, an audio multiplexer, an LCD display and some buttons.

At the time, this was the late 90s, and a development kit for the HC12 was well over $300. A debug tool would then cost a few hundred dollars more. On a college budget, this was expensive.

Not to mention the flash on the HC12 was rated for only about 100 erase cycles. This meant that I was bound to loading my program in its RAM for development, and flash only working subroutines.

After watching a series of videos released by Cornell University on the Raspberry Pi Pico, and being familiar with the Raspberry Pi in general, I decided to look into a design centered around a Pico.

These days, a Raspberry Pi Pico board is around $4 each, mounted to a typical DIP style package.

This package at $4 is similar to my HC12 kit back then. It has all of the supporting components needed on the PCB such as a clock, reset, bootloader, debug connector, and a power supply circuit.

Since it is now much later than the 90s, USB, WiFi and Bluetooth are ubiquitous these days. Many of these types of microcontrollers have these onboard.

There is plenty of onboard flash and RAM, and no worry of wearing out the flash erase cycles (it is now rated at hundreds of thousands of cycles).

Reverse Engineering

Plenty of hobbyists have built their own interfaces for these pocket computers, and some have provided documentation on the circuits and software. I have found quite a bit of documentation on the PB-100 series bus interfacing, and quite a bit on the Texas Instruments TI-85, 86, 92, and other graphing calculators from the 1990s.

For the other models, I can reverse engineer the bus interfaces using the peripherals I own and a logic analyzer for example.

I could combine documentation which others have provided, the service manual for the expansion port pinout, a scope, and logic analyzer for discovering the interface protocol.

As an example, I started with the Tandy PC-6 pocket computer. It uses a 12-pin peripheral port, and is compatible or the same as the PC-4 and PC-5. It is also compatible with the Casio PB-100 series (including the PB-410 for example) and the FX-780 and FX-790 as well as many others.

The printer for these was the FP-12S which is quite a small thermal printer and not too commonly found these days.

The FP-40 is a bigger thermal printer, but the interface packs needed to connect it to these models is rarely available anywhere these days.

PC-6 Architecture

To provide an example of the type of interfacing used in these pocket computers, the PC-6 can be inspected and used as a reference. The PC-6 uses two 4-bit CPUs which share control of the display and keyboards (upper and lower), and a gate array (IC4) provides the interface to the RAM:

Notice the RAM does not have any address lines from the CPU. Only 4 data lines, CE, OP are used to address, read, and write to the RAM. The gate array must control the addressing, reading and writing to and from the RAM.

The PC-6 service manual includes the pinout for the 12-pin peripheral port:

The peripheral data bus is also 4-bit and has two voltages present (VDD1 and VDD4), two chip enable pins (CE1 and CE2) and 3 other pins, 1, 2, and OP.

The pins D1 through D4 are the 4-bit data bus, as those are connected to IC4 and the two processors, IC1 and IC2. IC4 interfaces the memory to the bus and is controlled via opcodes. Since several devices are connected to the data bus, each device must support three states: input, output, and high impedance. If I am to attach anything to these pins, it must also support these three states, defaulting to a high impedance state (appearing as if it is disconnected from the circuit).

Pins 1 and 2 are clock signals, since they are inputs to C1 and C2 on IC4.

OP is an input to the IC4 gate array, but is both an input and output for both CPUs (IC1 and IC2). Since my circuit will need to control IC4, my interface will need to be an input and an output.

VDD1 is connected to the power switch, while VDD4 is a signal indicating the power state of the system, i.e. “on” or in an auto power off state.

Observation

In order to observe what the PC-6 expansion port pins are doing when connected to a printer or cassette interface, I would need to connect the PC-6 to its printer and then probe each line.

I connected the PC-6 expansion port to a breadboard, then the printer to the breadboard. This provides for points to connect a scope, logic analyzer, and the Pi Pico.

First, I would be curious what level VDD1 and VDD4 are at. Before going any further, I checked the voltage levels on the PC-6, specifically VDD1 and VDD4 compared to the GND pin on the port. The Pi Pico uses CMOS logic levels, that is levels of 0V and 3.3V. This is not the same as TTL logic levels of 0V and 5V. There are buffer ICs that can handle the voltage translation between these two types of interfaces.

I needed to determine if the PC-6 was using CMOS or TTL logic levels.

When using the GND pin as a reference, VDD1 was -5V and VDD4 was -5V. VDD4 is not present when auto power off occurs. This means the voltage at VDD4 will be present only when the computer is on. Further, all of the other signals were 0V or -5V, not what I initially expected. I measured this with a scope.

If I use the GND pin as a ground reference, the logic signals on the bus will be 0V and -5V, which is not within range of what the Pi Pico will handle. I would have expected levels between 0V and 5V.

Solution to the Negative Logic Levels

After quite a bit of thinking, looking over the schematic in the service manual, more thinking, I figured out that if I use VDD1 as a ground reference, all of the logic lines on the bus then fall into the range I expect, 5V or 0V.

Now that I had the logic levels sorted out, the next step was to take a peek at the bus when the computer is printing.

Logic Analyzer

Since I do not have access to lab-grade equipment and to make it a bit easier to visualize, I used an inexpensive USB logic analyzer, which has 8 ports. These cost around $12 USD.

I can look at up to 8 lines at once with this device, which is a bit easier than using a scope for looking at more than 2 or 4 lines at once. I connected the logic analyzer to the bus, specifically pins CE2, CE1, CLOCK 1, CLOCK 2, OP, D1-D3 as a start. I then printed something to the printer while running a capture:

This along with the documentation others have provided on this particular bus interface was quite helpful in developing a hardware and software solution to interface with pocket computers using a tri-state TTL bus.

Texas Instruments Graphing Calculators

The Texas Instruments graphing calculators from the 90s and early 2000s used a 3-wire serial interface to link two calculators together, and to link up to a PC. The calculators included a graph link cable in the box, and the PC link kit could be purchased separately.

These PC link connection kits were a bit expensive, as I had one myself. I used it for transferring programs and screen captures which could be printed.

These days, these interface kits can be found on auction sites, or they can be built. Most these days use USB connections. There is even a library, TILP, a platform for interfacing to these graphing calculators. This library works very well and can use the TI graph link cables.

The link interface uses 5 volt TTL levels. One pin is ground, the two other pins are used for sending and acknowledging. The sender will pull one line low (the line pulled low indicates either a zero or one, depending on which line is pulled low), and the receiver will pull the other line low to acknowledge. The sender raises their line, the receiver raises their line, and the process repeats.

This type of serial connection works without a specified baud rate. It works as fast as the interface itself can support and the processing speed on both ends. Since each bit is acknowledged, it is fairly reliable and robust.

Adding support for this to the pocket computer universal interface would be straightforward. All that would be needed is a 2 wire TTL interface similar to I2C or SPI.

PCUI Hardware Design

Based on the examples described above, the PCUI will need to interface with 5 volt TTL level logic. It will need to support open drain or open collector style interfacing as well as tri-state bus interfacing.

Since the Pico uses CMOS or 3.3 volt logic, voltage level shifting will be required. Since the Pico can be powered by USB and it has a built-in power supply, it can drive both it’s own power needs at 3.3 volts, and other 5 volt devices can be powered from the USB bus supply.

However, since the PCUI might be used in a portable environment, or without a USB host, it would benefit from having its own power source, such as a rechargeable lithium ion battery. This battery could be charged from the USB port.

Since most components these days are surface mount, fewer and fewer components are available in through-hole versions. This means breadboarding or simple home-made PCBs are not practical.

Inexpensive Hobbyist PCB Prototyping

There are several PCB manufacturers that can make prototype boards inexpensively. Technology and automation have made this a reality for those who need to manufacture very few boards, such as less than 100 boards as an example. This was not the case years ago.

This type of readily available on-demand manufacturing allows hobbyists to design a PCB layout and send off the design for manufacture.

The PCB design is performed using EDA software such as KiCad, an open source platform. KiCad can be used to create a schematic of a circuit or layout, and then a PCB designer feature is utilized to layout the components and traces on a PCB.

The image above is from the 3D viewer inside the KiCad PCB designer. The components are models which can be downloaded and copied to a library in KiCad. This allows the designer to actually see the layout with pad and footprint clearances before actually manufacturing anything.

Prototyping and Testing

Once the layout is completed, fabrication files can be exported from KiCad and sent off for manufacturing of the PCB. Some manufacturers can also place the components as well, although this costs more.

The PCUI has a main PCB with all of the components needed for interfacing between pocket computers, printers, PCs, and more.

For pocket computers, many have different styles of connectors, all proprietary. The concept with the PCUI is to be able to use the same device for interfacing, with one software platform, but have different connectors for each pocket computer. Each connector or “interface pack” will have its own trace layout for interfacing with the PCUI main board. A standard ribbon cable style connector is used for each variation.

For the PCUI project, I ordered in batches of 5 PCBs at a time, since I knew I would likely have several revisions. In fact, in earlier prototypes, I would tack on bodge wires, lift pins, and perform other cost saving measures to get as much testing as possible before ordering another revision.

From the very first prototype, I added pin headers on the layout so that I could easily solder them in if needed, at strategic spots on the circuit. For example, I added header pins to all serial lines, on the I2C bus, and on various points on the power rails.

I tested each major functional section at a time, soldering on components one section at a time. This allowed for testing each circuit somewhat independently. If I soldered on every component in one pass, I would have a more difficult time troubleshooting an issue, not to mention possibly wasting some components.

The silkscreen (lettering on the PCB) is extremely helpful for component placement (when done by hand). For example, all pads have a component label for ensuring the correct placement, polarity indicators are used where helpful, and labelling on ports and connections, as well as jumper pads.

Surface Mount Components

As mentioned earlier, the choice of using surface mount components was practicality. Most often, the component I wanted to use was available only in SMT. Further, if I chose a through-hole component, often times it was being phased out. The down side to SMT is that it is more difficult to solder them onto a PCB by hand. It is not however impossible.

Another downside to SMT is breadboarding is more costly. In a DIP style package, you can press a component into a breadboard and test an idea. With SMT, more often than not, some creative solutions are needed for breadboarding. For example, on the bus interface IC I chose, it is available only in SMT, and I ended up using an SMT to DIP PCB. I soldered the component to this PCB then used the pins on the other side for a breadboard and direct test clip leads.

Of course the breadboarding was quite easy compared to soldering the component itself onto the PCB. A fine soldering tip with the correct heat setting, the right flux, magnifier glasses, and a steady hand proved to be successful.

In some cases, creative methods are needed for breadboarding. I ended up using BS138 FETs for voltage level shifting and these were readily available as SMT. I ended up soldering small bodge wires to each pin and inserting those into the breadboard.

Very rarely was an SMT part overly difficult to solder to the PCB. The exception was an inductor needed on the power supply circuit which had two pads underneath the component.

Software Design

The software for the PCUI utilizes the C SDK for the Pico, as opposed to the Python SDK. I had no desire to use Python and I have decades of experience in C and similar languages.

Since I am using an I2C bus for many ICs and the OLED, the challenge in the software design is in the interfacing with the pocket computers themselves, not the basics like MicroSD card usage, OLED, Parallel, Serial, memory management, and user interfaces.

I found it extremely difficult if not impossible to successfully interface using the GPIO method with a single interrupt. My timing was off, there were missed pin changes, complex and confusing logic to try to implement workarounds for the single interrupt issue using GPIO methods.

I ended up taking advantage of the Pico’s state machine feature, or PIO. With the Pico, you can have up to 8 state machines running independently from the two cores. PIO has an assembly language and each state machine program can be up to 32 lines of code.

As a POC, I implemented the TI graph link protocol for sending and receiving in PIO assembly. I have one state machine handling receiving and another handling transmitting.

Each state machine can push or pop to and from a FIFO via DMA and can generate interrupts for the cores for processing.

The PIO state machine instructions operate in a single clock cycle, which is extremely fast. For example, the Pico is fast enough to directly generate VGA signals directly from PIO and leave the two cores available to process information.

The PIO state machines support a clock divider to step down the processing speed or instruction cycle to best match the needs of what it is connected to.

The PCUI software will utilize the OLED and four soft keys for a user interface for selecting various modes and options for interfacing with various pocket computer models and printers.

It will use a MicroSD card to store data, screen captures, programs and more.

Useful Methods and Process

Some of the most useful process and methods are what makes projects like this easier to succeed. First, I found that it is crucial to label the PCB with a board revision and save a corresponding PDF of the schematic with the same revision labelling. Sometimes you might want to test something with a spare or leftover board, and revision is key. Then you may want to consult the schematic for that revision. If you do not save copies of previous revisions, you are left with more work tracking down a problem.

Not to mention, if any PCB revision makes its way out into the world, labelling of revisions and having the corresponding schematic for that revision could help others troubleshoot or repair.

Another crucial step in the design process is breadboarding and prototyping. Each circuit should be tested on a breadboard and its integration with the rest of the circuit tested as well. Otherwise, you will find yourself ordering more revisions of your PCB than you should be. Not only is this a waste of money, it adds delay to your timeline.

Component choice is also important, not only for cost, but for longevity. For example, choosing a battery that is commonly used is helpful for projects sold as a kit for others to build. If a battery is chosen which becomes discontinued or difficult to obtain, the kit is more difficult to assemble.

Similarly, finding a microcontroller that will likely be around for awhile, and one which will likely see a compatible successor is key. Not only will it be helpful to have something commonly used for advice and help, your software will not need a complete rewrite for another microcontroller when your existing design choice is obsolete.

Another example is the choice of OLED screen. I chose one which I can easily acquire for around $1 each and is commonly used. Lastly, if a project requires connectors, a choice of a common inexpensive connector style is key. This ensures product longevity and avoids the infamous proprietary connector issue we most often see with pocket computers.

Finally, I found it most useful to track a bill of materials for each revision. This way I can quickly and easily reorder components either all at once in various quantities and also be able to share the component list with others who might want to built their own as a kit.

This tracking can be done in a spreadsheet or in software. KiCad and Mouser for example can do this for me.

Final Thoughts

This is my biggest project of its kind that I started a few months ago now. It will likely continue to evolve until a useful version is ready for sharing.

If this is successful, my plan is to offer this device as a DIY kit. The kit will have all of the parts with instructions for assembly.

Since the interest in something like this is small, production of this device pre-assembled would be cost prohibitive. The hobbyist community could likely build these themselves.

Perhaps a few dedicated hobbyists can assemble these for others for a nominal and fair fee.

The software will be pre-flashed on the Pico, and is easily updatable by downloading the latest image and dropping it into the folder which appears when it is plugged into a Mac or PC.

I plan to publish more posts and videos as the PCUI is closer to production ready. If you are reading this and have interest in this kit, please reach out to me via my contact page on this blog.

Behind the Scenes

Below are some photos I have taken along the way as I finished some of the hardware and software components for the project.

There was quite a bit of breadboarding of SMT components and testing level shifting, lots of thermal paper used for failed attempts at printing and scaling of screen captures.

Before making the first PCB, the amount of wires needed to sniff the bus on a PB-410 as an example was unwieldy.

Since the TI graphing calculators support screen captures, this was the primary feature built out first, screen capture to print out on an attached serial or parallel printer. Scaling was also implemented to take advantage of the available paper sizes.

Epson ESC/POS provides for graphics or bitmap printing, and some printers need workarounds or specific methods to print a bitmap image without any line gaps.

Since printing a screen shot might not be the only useful feature, the PCUI generates a PNG image of each screen capture and writes them to the MicroSD card. Below is an example of a PNG screen capture from a TI-92 displaying a 3D graph:

Plugging the PCUI into a PC or Mac can be done using the micro USB port. The PCUI appears as a drive, exposing the MicroSD card to the PC or Mac. This allows for easy copying of the PNG captures for using them in manuals, publications, or elsewhere.

Finally, the PCUI has a TI Graph Link “passthrough” mode. This mode translates between the graph link port and the RS-232 port. This allows the PCUI to become a “gray link” cable. The gray link cable was a TI produced cable which connected a calculator to a PC via the serial port. This allows the PCUI to work with TiLP, without the need for a TI interface cable.