Transputer: Stack Based With OS in Hardware

Picoputer: RP Pico Hardware Transputer

 

The transputer was and still is an odd beast. It has hardware support for processes (hence OS in hardware, well, sort of), and its assembly language is such a pain that Occam is a much better way to program it. It's a language that is close to the hardware and allows parallel processing to be built in at a basic level. They have four fast (for the time) 10mbps (20mbps later) links that are used to communicate between devices and other systems. As the processors improved in capabilities and speed, the links remained compatible.

The later transputers have floating point in hardware, which makes them useful for computationally intense work, especially when configured in networks.

The only real downside is that the chips were expensive, so they never really made it into common usage in embedded applications. Quite a few parallel processing systems using transputers were made, though.

I read all about transputers when they came out but never had a chance to use any. Recently, though, I was looking at vintage processors and transputers came up, which triggered some memories. Unfortunately, the downside of high cost seems to still exist, and vintage transputers are quite expensive. Not as expensive as when they were new, but costly enough that I didn't just buy a few. 

If you want to run some meaningful code on a transputer then you also need to add some RAM, as the chip itself only comes with about 2K onboard. A common 'unit of computing' using a transputer is the TRAM (TRAnsputer Module) which is a transputer plus some RAM. These are very expensive to buy, to the extent that creating a system with more than one processor in it is just not economically sensible.

Raspberry Pi Pico

At around the same time, the Raspberry Pi Pico came to my attention. This is a modern micro-controller board that uses the RP2040 device, which is interesting for me as it has a set of four intelligent hardware GPIO processors. I'm think that these are very useful for interfacing to old hardware buses, such as the FX702P display bus I sniffed with a Blue Pill, or the FX502P external interface bus. When I implemented these projects I used firmware to interface to the bus, which was just about possible using the Blue Pill as it has a high clock rate relative to the bus. Interrupts were necessary in the case of the FX502P bus. The RP2040, though, has programmable hardware that can operate at frequencies of tens to a few hundreds of MHz. This, hopefully, should make it possible to interface to some devices that have higher clock rates.

 

While I was looking at the RP2040, it suddenly occurred to me that the four links on a transputer could be implemented using the eight PIO state machine son an RP2040. Each state machine handles data in one direction, leaving the processor(s) free for other work. What other work? Well, how about running an emulator of a transputer on the core? That would give you a hardware emulation of a transputer. How fast would it be? Well, the original transputers were running at about 20MHz, and the Pico runs at 135MHz. So it probably wouldn't run at the same speed as an original, but it would only be about an order of magnitude slower, maybe. And you can, of course, just add more transputers (real or emulated)  to speed things up...

The links that the Pico provides can easily run at the standard 10MHz link speed (10Mbps) and running at the faster 20MHz shouldn't be a problem either. In fact, if only emulated transputers are talking then a faster link rate could maybe be used.

Host Communication

The transputer links can't be attached to a modern PC, but INMOS made some link adapter ICs (The IMSC011). These are fairly easy to buy, and provide two 8 bit data buses, one for the LinkIn direction and one for LinkOut. Adding one of these to an Arduino would give a way to interface a transputer to a PC.

 

As these are devices that run off 5V I decided to use an Arduino Mega Embedded, partly because I had one. The parallel buses can be wired up to the Mega, together with the Valid and Ack signals. these are used to signal that the data is valid (when Valid is active) and also allow data to be acknowledged (by Ack). The Arduino can then do whatever is needed with the data. i decided to send the data over USB to a host PC as that is the arrangement that the transputer originally used. The host PC then runs a server that handles the 'SP Protocol' which allows input and output on a terminal and keyboard and also allows access to files in the file system.

Booting

A transputer can be booted either from ROM or from a link. I didn't want to boot from ROM, although a program can easily be stored in flash and executed at startup. It's more flexible to book from a link as the host can then supply the code which can be compiled Occam, or C, or any of the other languages that can generate transputer object code. I'm particularly interested in Occam.

Booting from a link is built in to hardware and involves sending a small (up to 255 bytes) bootstrap loader. This then executes and loads further data (the boot loading phase). That boot-loader then loads more chunks of code over the link.

For the host, this is all rather simple, all it does is send the boot file to the transputer link. The format of the data is set up to drive the three stage boot process.

Using PIOs As Transputer Links

The transputer links use a protocol that is very similar to asynchronous serial data. You can view data packets as having a start bit, a type bit and eight data bits followed by a stop bit. An ACK packet follows much the same format, except the data bits are missing. The type bit is 1 in a data packet and 0 in an ACK packet. I started with the serial UART PIO code in the Pico examples and adjusted it to use the transputer protocol. I have a bit of work to do concerning the ACK packet, as I treat the ACK packet as a 10 bit frame at the moment, just with trailing zeros. This could possibly lead to problems if serial data is sent within 7 bit times of an ACK packet, but is working OK for now.

I used one PIO for LinkOut and one for LinkIn, and for the prototype I generate a 5MHz clock with a PIO for the IMSC011 ClockIn pin. 

 Once fired up and wired up this PIO code was capable of driving the IMSC011 and successfully sending and receiving data.

Host Code

The host code will eventually run an SP protocol which will give the full range of IO and file access. For a first pass, just a simple display of data coming in to the host was implemented, as a test of the links. The Arduino Mega sends the link data over a simple (and inefficient) protocol over USB to the host. Using this setup I was able to run a simple hello world program I found on the internet and have the text appear on the host once the Picoputer was booted.

I toyed with the idea of compiling the INMOS server tools

Real Hardware

Just for interest, I also ran this prototype set up using a real transputer that I managed to source. It's actually a motherboard for a larger system, but it has a transputer on it. I applied power and then reverse engineered some signals (most importantly the BootFromROM signal had to be de-asserted). Once this was done, the host code booted the hello world program which then ran and resulted in the 'Hello World' display.

Running Occam on the Pico

While running precompiled binaries is fine for a test, what I'd like to do is run Occam on the Pico. This turns out to be tricky as I can't find a compiler that runs on Linux and, most importantly, generates transputer object code. There's the KROC and the SPOC compilers, but they generate machine code for other processors. About the only option seems to be the original INMOS compilers. They, however, run on older operating systems, DOS being the one for the PC hardware platform. 

I have found a useful VM image on the geekdot website which allows me to run one of the INMOS compilers, so I can actually compile Occam, and then link and collect it down to transputer machine code. At the moment I'm copying the files on and off the VM using a virtual floppy disk image file. Not hugely convenient, hopefully I will be able to compile on a transputer, or maybe recompile the compiler for Linux.

I found a simple Occam program, which looks like this:

#INCLUDE "hostio.inc"  -- contains SP protocol
PROC simple (CHAN OF SP fs, ts)
  #USE "hostio.lib"
  [1000]BYTE buffer :
  BYTE result:
  INT length:
  SEQ
    so.write.string    (fs, ts,
                            "Please type your name :")
    so.read.echo.line  (fs, ts, length, buffer, result)
    so.write.nl        (fs, ts)
    so.write.string    (fs, ts, "Hello ")
    so.write.string.nl (fs, ts,
                             [buffer FROM 0 FOR length])
    so.exit            (fs, ts, sps.success)
:

This uses the 'SP Protocol' to perform input and output using the host system. After some fiddling (porting a third emulator and writing some SP protocol functions and various bug fixes), the host system displays this:

 

Port name:/dev/ttyUSB0
Bootfile:SIMPLE.BTL
Serial port OK
Sending boot file
Boot file sent
Please type your name :AndrewwHello Andrew

The key line here is the last one. The Occam program prompted for my name as it should, then I typed my name in and it displayed the result. OK, the newline is a 'w' and it took a few seconds to run, but it ran. The '.btl' file (BooT Link, or object file) for this program is 3935 bytes long, so a sizeable chunk of code that was loaded using the three stage bootloader mechanism. No bad opcodes, either.

The whole arrangement is not optimised for speed at all, it is optimised to get it working, so running this program does take a while. With some changes I should be able to get a binary transfer of code running, hopefully that will be faster. The emulator could be sped up a little, perhaps, but when single stepping it doesn't seem to be particularly inefficient.

The RP2040 is dual core, which means that I could run an emulator per core and have two transputers on the one board. Due to some excellent design, the transputer link architecture makes no distinction between hardware links and internal communication links, the code has no idea what it is dealing with. this should make it easy to set up communication between the two cores over links.

But, it works!

 

 Reverse Engineering an LCD Display

I have a DAB radio which started to irritate me in various ways. Finally fed up with it, I bought another radio and decided to free up the space that the old radio takes up by tearing it down.

This is the DAB radio taken apart:

 

Nice display 16 char 2 line dot matrix.

Looking at PCB, it seems to have a three wire interface:

Scoping up the lines, one looks like a reset:

Others have data and clock:

Looking at the data, there's a different voltage level in there. I2C has an ACK which comes from a different computer to the one generating the data, so different level makes sense.

As this is probably I2C, switching on the decoder in the scope shows what is being sent:

Now we know the I2C slave address and some data. It does look like I2C. What device is it though? Searching the internet gives a few options. It could be a standard I2C GPIO expander attached to an LCD controller.

After power up there's an initialisation sequence:

That's the first byte in a longer sequence that goes:

0x39, 0x14, 0x7f, 0x57, 0x6b, 0x0c, 0x01,0x06, 0x38, 0x40.

There also seem to be two bytes for every bte of data transmitted, the initialisation bytes have a ledaing byte of 0x00, the data bytes have a value 0f 0x40.

Using this sequence we could maybe find the controller that is used. After more searching there's a possible match. The Winstar WO1602I-TFH- AT module has an initialisation sequence that is similar.  The datasheet  shows the initialisation sequence to be:

0x38, 0x39, 0x14, 0x74, 0x54, 0x6f, 0x0c, 0x01

This is similar enough to probably be the same controller with a slightly different LCD attached. The datasheet is useful. It says the controller is an ST7032, and the first byte of the two that are sent is a control byte. It holds Co and RS. RS is the command/data bit, while Co is a continuation bit that allows more than one control byte to be sent. The datasheet shows the RS bit as bit 6 which matches the trace on the scope. It looks like this is indeed the controller in the display.

Excellent, we have enough data to probably drive this display.

 Re-using a Broken Television as a Monitor

or

What To Do With a Broken Television when You Can't Fix It

I was given a broken television.  Technically this television was doubly broken: once when the HDMI inputs stopped working and once when everything stopped working. After the first fault it was taken to a television repair shop (yes, they do still exist) and they couldn't fix it as the parts are not available. I had a look at it on that occasion and found that some RGB inputs did still work, so we fed a signal in there and that allowed the television to live a little longer.

After the second failure nothing appeared on the screen at all, and the backlight did not switch on, so I was given the television to see if I could fix it or do something with it.

The television is an LG 39LE4900 and looks like almost every other television on the planet. Once opened I found a power supply PCB

 and a control PCB:

I also found an inverter PCB, under a metal cover, which powers the backlights:

and what I later found out was a TCON PCB, also under a metal cover:

I had a quick look at the boards and nothing seemed to be obviously wrong. When I powered the television up nothing appeared on the screen and the backlights were off. The remote control worked, in that it turned the television on, but nothing appeared on the screen. I used a torch to see if the LCD was displaying something even though the backlights were off and it wasn't.

I managed to find a service manual on the internet for a similar model, but the control PCB was the only board that the manual had schematics for. I thought this was a bit odd at the time, but it actually makes sense, I'll explain later. unfortunately, as the service manual model wasn't exactly the model I had, all of the component numbers were different to my PCB. I could work out that there was basically one large, presumably custom, chip that controlled almost everything. I checked voltages of power supplies and everything seemed fine.

I also tried to find a serial output from the board that worked, but no luck.

The next step was to get some replacement PCBs from ebay. I did this and eventually replaced all of the PCBs and found that the television still didn't work. This was a bit odd. I then took the step of buying a complete new screen (and a couple more PCBs) to see if that would work with the old and new PCBs. It didn't. This was a bit surprising as I had expected to get something working at this point. 

I then started looking at the PCBs in more detail and found that the TCON board and inverter were made by AUO, and there was actually a datasheet for them. Well, sort of. There was a datasheet for the LCD and backlight and TCON and inverter PCBs, all bundled as a module. AUO seems to sell this as a module that manufacturers can use in their products. LG have done this and then added a PSU and controller PCB. This explains why the controller was the only PCB with schematics in the service manual. The  rest of the electronics was bought in. (Except maybe the PSU which I think is a standard LG board).

The LCD/backlights/TCON/Inverter can be thought of as a larger version of a 16x02 LCD module. That also has a display, backlight, and driver circuit. The only difference is the size of the LCD and the interface used. With the AUO datasheet I now had details of the two connectors that the module provides, one for data and one for backlight. The data input is LVDS.

After another search, I found that the schematic for the PSU PCB was also on the internet, which was useful as I could then hardwire the supply to the LCD backlights. After having done this, I found that the backlights worked fine on both screens. This was good news.

 I then decided that fixing the television wasn't really practical, but I might stand a chance at turning it into a monitor. I'd recently fixed the display on my Novena

 

 laptop so had played around with LCD panels and knew I could get cheap driver PCBs that would take VGA or HDMI and drive an LVDS interface.

I decided to make a hacked together VGA to LVDS adapter PCB attached to a flat cable connector adapter PCB. The VGA/LVDS adapter needs +5V, whereas the PSU PCB in the television only provided +24V or +12V so I had to also use a DC-DC converter to power it. I hardwired the LVDS signals from the adapter PCB to the flat cable PCB using wires. I cut the connector that the adapter PCB supplied off the end.

Once this monster was all wired up and attached to the television, power was applied and a laptop supplied a VGA signal. And it worked. the picture was upside down, but the laptop could flip that and once done the television now displayed a nice stable picture. Well, it did when I could accurately and firmly attach the flat cable from my PCB to the TCON board. I'd been unable to get the connector that the LG control board used, so I'd bought the one that the TCON board used. This connector rather than being the FPC type connector that attaches to the end of the flat cable, attached to a connector that fits round the end of the cable. 

 

This meant that I had to use a piece of folded paper to hold the bare flat cable in ot the connector. I also tried 3D printing a flat spacer to wedge in the socket, but it wasn't ideal. In the end I bought a couple of new cables that were the same length as the original but had the connector on both ends rather than just one end. These work perfectly.

 With this mess of wires and boards working I decided to make a PCB. This would mean that the electronics and wiring could be tidied up and I could use one PCB rather than two or three. 

 

The VGA LVDS adapter was mounted on the new PCB, as was the DC-DC converter. The footprint I used for the converter was a very generic one, which lets me wire almost any DC-D converter I can find on to the board. The wiring holds the converter in place.

I also put a footprint for a Blue Pill on this PCB so I have the option of using that to perform housekeeping functions like turning the supply on and off and providing a timer to turn off the screen after a certain time. I haven't used the Blue pill to do this yet, I just turn the monitor on and off at the mains.

I can also use this PCB as a general Blue pill breakout PCB. I have five PCBs and will probably only ever use two, so the other three can be repurposed.

The PCB fits nicely in on the mounting holes that the AUO module provides, and the VGA connector is accessible once some metalwork has bee cut away.

I've been using the monitor for a few weeks now and it seems ot work fine. I'm making a PCB for the second screen as well, so I'll have that up and running too, I hope. I checked the screen with the first PCB I made and it does also work.

Why the televisions didn't work with the new control PCBs I don't know. I have tested every other PCB I bought and they all work fine. Are the controllers broken? Or do they need some magic setup? I don't know. I'm going to strip them for parts.

Details

The connection between the TCON PCB and the VGA-LVDS adapter:

The 12V supply was used to power the TCON board. The VGA-LVDS PCB needed +5V so the DC-DC converter was used to provide that. I used a variable DC-DC onverter and set it to +5V running from the +12V supply. I measured about 500mA drawn by the adapter so used 1.5A or 2A converters.

The PSU was hardwired to power on. This was done with a wire link on the PSU PCB. Using the schematic I managed to find an appropriate supply and signal to use. (PWR_ON connected to 3V5).

Connections between TCON and LVDS adapter:

VGA-LVDS                TCON

O0+    O0-                CH1_0+    CH1_0-

O1+    O1-                CH1_1+    CH1_1- 

O2+    O2-                CH1_2+    CH1_2-

GND                         GND

OC+    OC-               CH1_CLK+    CH1_CLK-

O3+    O3-                CH1_3+    CH1_3-

E0+    E0-                CH2_0+    CH2_0-

E1+    E1-                CH2_1+    CH2_1- 

E2+    E2-                CH2_2+    CH2_2-

GND                         GND

EC+    EC-               CH2_CLK+    CH2_CLK-

E3+    E3-                CH2_3+    CH2_3-

                                  VDD  +12V

                                LVDS_SEL: Open (HS)

(Closed is JEIDA, which didn't seem correct from the AUO datasheet)

 

Videos

I have a series of videos that show the work I did.

 

 

 

Miele Induction Hob Problems 2.0

 Miele Induction Hob Problems 2.0

The Miele hob has gone wrong again. The previous fix was a relatively simple capacitor replacement. This time things are not so straightforward. The initial fault was that the hob tripped the RCB in our fuse box when an attempt was made to turn on either of the front two rings. This happened several times. 

The hob was removed to the workshop to see what could be done. Once wired up there the controls report an FE60 error whenever the hob is turned on.

I managed to find some documents online that said that FE60 was a communication error. After a few hours of going round in circles I decided to buy some replacement PCBs. After swapping all of them into the hob I continued getting the FE60 error. So still no working hob. A cheap-ish hob came up on ebay so I bought that and tried that out. Absolutely amazingly that hob came up with the exact same FE60 error. After ruling out an airborne electrical virus of some sort I finally found out what the problem was when I tried operating the hob with the lights out in the workshop. The lights I was using were interfering with the touch sensors used to control the hob. I suspect the code saw that as a communication error with the push button PCB and reported the FE60 error. 

How do you fix FE60?

Operate the hob with the dark glass cover in place. 

So, hob was replaced in the kitchen with a completely new set of PCBs. As I now have two hobs and about three sets of PCBs I have enough spares to last for a while and can completely swap electronics.

A few days later the RCB trips again. This is with completely different PCBs, so I now think that there's a dodgy piece of equipment somewhere in the house and that caused the leakage current to go up. Induction hobs are known to have high leakage and that pushed the RCB over it's trip limit.

At least I now have spares for the hob for about three decades...

Novena Laptop Fix

Novena Laptop Fix

I got a Novena laptop from Crowd Supply several years ago. 

 

 

I didn't use it too much and that probably contributed to the batteries not being charged enough to maintain good health. That lead to some magic smoke being released from the battery charger PCB. It looks OK in this photo, but it's not.

 

 

The laptop was dead at that point. Being open hardware, though, means that I have all the schematics, gerbers and firmware for the system, so it should be fixable.

I decided to change the Novena to a desktop system, so I removed the battery charger PCB and tried powering from the power socket that is on the main PCB. That seemed to work, in that it powered the main PCB, but the LCD didn't come up and there seemed to be a configuration problem. The push button at the front of the machine also didn't work.

It turns out that to run the Novena as a desktop you need a different PCB where the Senoko PCB lives. It's called the 'Senoko pass through' PCB and the Gerbers are available. I had some made and populated a couple. 

 

 

 

Once fitted in the Novena all was well and the power supply can now be turned on using the button on the front of the case.

The display still didn't work, though. After looking at the schematics I came to the conclusion that a high voltage had travelled down the I2C bus that the battery controller was on and had destroyed anything on there. That unfortunately included the LVDS to eDP video converter chip. Well, that's not too much of a problem as the chip is still available ( I bought a few) and the PCB gerbers are available as well. So I had a few of those made up and populated two of them. 

 

 

 

This PCB was much harder to populate as the BOM wasn't online (I subsequently got a copy) and so some of the components I used weren't exactly the right footprint. The packages used by these components were also in the 'nasty to handsolder' category.  I tried both PCBs and neither came up with a display on the LCD. Was it the layer stack up? Maybe as I just had the PCBs made using my usual cheap supplier and didn't pay any attention to layer stack up. Was it my soldering or the footprint problems? More likely. Either way I still had no LCD display. Did the LCD get blown up? That was possible, so I bought a second LCD panel and tried that. 

 

 

 

No output on any eDP PCB. 

 

I then noticed that you can buy cheap HDMI to eDP converter boards and got a couple of those. Attached to the HDMI port of the Novena and attached to the second LCD I had bought, we had output. The HDMI output still worked and I had verification that the LCD I had bought worked. having an HDMI cable running from the external connector into the case and through a converter PCB to the LCD was untidy though. 

Could I have damaged the mainboard somehow and the LVDS was broken? Maybe, so I bought a new mainboard as they were on sale. I tried that and the same result. No LCD output. 

 

After more searching online I found that you can buy LVDS to eDP converter PCBs that use the same chip that the Novena eDP board uses. I bought one of those and started to investigate wiring it up to the LCD and the Novena mainboard. It wasn't an easy job. Before I finished doing that (or actually, even started wiring), I remembered that I had some spare LVDS to eDP chips that I bought to populate the eDP PCBs. I could remove the chip from the eDP board I got with the Novena and put a new one on. That board wouldn't have the possible layer stack up problem or footprint/component problems of the boards I'd made from scratch. I swapped the chip and tried that. Still no luck. This wasn't looking good. I swapped the mainboards around and still no luck. 

The debug serial port spits out information about the setup as the Novena boot sand I noticed that the LVDS to eDP chip was recognised but didn't get powered up. I fiddled with the EEPROM settings but still no display. The chip seemed fine though, so my swap seemed to be OK.

I then booted into recovery mode, I can't remember why now, probably as it was another option to investigate the disabling of the LCD. I had the Novena facing me (the case opens in the opposite way to a normal laptop), so the LCD was facing away from me. As I booted I suddenly noticed that there was a reflection of the LCD on the screen of my logic analyser. the LCD had started up!

This was good news, but why was it on now? The only thing I could think of was that the disabling of the LCD was now a software problem, the hardware was functioning. Normal boot on the mainboard I had in the Novena was disabling the LCD for some reason. Which main board was I using? Well, it was the new one that I had bought, and that was part of a 'just the board' kit, so it may not have been configured for an LCD, rather to run as a server. I swapped the SD cards between mainboards and rebooted. The LCD worked fine. So maybe that theory was correct and my later problems after the chip swap were due to the SD card configuration. I've not found the setting for the LCD disable, partly due to taking a break after all the kerfuffle.

 Battery Leakage Again

A recent purchase:

It's a Casio FX502P in pretty much perfect cosmetic condition. Unfortunately the display isn't. It's not displaying anything very well at all. It's attempt at displaying Pi shows how bad the LCD is:

Once I opened it up, the problem was immediately obvious. It was battery leakage again. It's not very obvious in this photo but the batteries have leaked in the area of the battery contacts (which are remarkably clean) and the LCD. 

The LCD is fortunately connected with zebra strips on this calculator, not heat seal:

This meant that I could dismantle the display and clean it. I also cleaned the tracks that had had leakage on them. the solder resist was loose so I removed it on any affected tracks. You can see that tracks I've cleaned are missing their resist and appear gold in this photo:

Once re-assembled, the LCD is working perfectly. It's got good contrast and the filter is completely free of scratches. It's the best example of a FX502P I've got.

Using a Thermal Printer Mechanism

 Using a Thermal Printer Mechanism

The Casio CP-10 is a neat calculator that has a thermal printer attached. The calculator also has a built-in clock and can do useful tasks such as printing this month's calendar. The date range is also useful as it ends in 2099. The printer is a small mechanism that take standard 38mm thermal paper. I found out that the mechanism is the same one that the FP-12 printer uses. This is a small printer that is designed to attach to a variety of calculators and pocket computers.

I bought a CP-10 to see if I could re-use the printer mechanism instead of the receipt printers that I have bought off ebay in the past. They are relatively expensive (over £20) whereas the CP-10 can be had for half the price, if the CP-10 is listed as non-working. Unfortunately the CP-10 has a NiCd battery pack, as the printer mechanism take a fair current when running and the pack is used to supply that. This means that a lot of CP-10s have suffered battery leakage and failed. This is what had happened to my example. After a brief attempt to revive it I cut off the printer mechanism and attached a blue pill and some extra circuitry.

There's seven transistors, one for each thermal element, and one transistor that drives the motor. There's an input for the home position switch as well. The mechanism has a tachometer output that gives a series of pulses as a magnet rotates near a coil. The magnet is attached to the motor, so this arrangement gives a reading of the motor speed. The pulse may also be used for dot timing. Unfortunately my mechanism seems to have a broken tachometer output. The coil reads 25M resistance, which is a bit high for a coil of wire. (I have since bought a second CP-10, this one shows signs of life and its coil reads 82R, so is much healthier). After trying my own tacho circuit, then copying the CP-10 circuit, then building a higher gain circuit with an op-amp I decided that the tacho output wasn't reliable enough to use. This may not be too much of a problem if the motor is run off a stable supply as the speed of the motor should be fixed. I should be able to time the motor moving from home position back to home position and scale the dot timings appropriately if need be.

The output from my working CP-10 is like this:

That's the calendar printout from the CP-10. The FP-12 has a print width of 20 characters, the CP-10 also seems to have a print width of 20 characters.

My first attempt at printing was a little more basic than a calculator. I turned the motor on and fired one element of the print head repeatedly:

This is a start, at least I'm getting dots. The motor drive also performs line feeds and the dots show that. The horizontal dots are the feed across the paper. the sloping dots are where the head is returning and the paper is being fed. After some work with the code, including adding a font table and using the input from the home switch, this is the output:

This is a test printout that is printing the parameters of the code that printed that section. I am also using 20 characters as the width here, simply because the mechanism is set up for it. There's a row at the top of the characters that is faint, I think this is to do with the ground wiring I have used.

There is also an interesting effect which is best shown in the lines of asterisks. They are darker on the right hand side of the line. I'm pretty sure this is down to the heating of the printhead as elements are turned on. Every time a dot is printed, the printhead warms up a bit. This means that to get an equivalent dot, you don't need to turn the element on quite as long the next time. In the printout above, I have a parameter called 'DEC_PERIOD' which controls part of my correction for this thermal heating effect. You can see that the second from bottom section has a DEC_PERIOD of 1 and the asterisks are darker to the right hand side of the line. The section above it has a DEC_PERIOD of 2 and the asterisks are printed more evenly.  The correction code counts the number of elements that have fired, accumulates those counts and uses them to create a 'temperature' for the printhead.  The DEC_PERIOD value controls the cooling of the printhead. This does lead to a working correction as can be seen above.

I think the CP-10 code must also be doing something similar, as the calendar printouts above show an even darkness across all the lines.

The CP-10 must also be correcting for supply voltage variations. It runs off four NiCd cells which will present a range of voltages to the motor and hence different speeds of printing. I have attached my working CP-10 to a power supply and varied the voltage. The time to print a line definitely changes, but the characters printed remain in the correct positions. The printout is fainter when the voltage is lower. The code could be using the tachometer signals from the mechanism. I can't do this but I could measure the time taken to print a blank line and use that to adjust the dot timings. Interestingly it appears that the CP-10 does print one blank line after it is powered on. I wonder if that is a timing line and the CP-10 is doing what I will probably have to do if I want to correct for voltage?

Next step? probably a PCB. But do I use a blue pill or STM32 chip? Given the size of the mechanism, a blue pill is a bit on the big side, so I think a chip would be better. The only problem is that there is quite a shortage of STM32s at the moment. I've got a few so that is probably OK.

There's a video here of the prototype: