How fast is a Modern Microcontroller?

At the time of writing, the Raspberry Pi Pico has just been released, so can be considered modern. How fast is it? Compared to the object of a recent project, the Psion Organiser II from the 80s, it is pretty fast. fast enough, in fact, to be able to pretend to be an EPROM in the Psion datapak.

Some Technical Psion History

The Psion Organiser II has two storage slots that were designed to hold data in a similar manner to hard drives on a PC. The sizes range from 16K up to 1Mb, although around 32K was a more usual size. The hardware in a datapak was simple: it was an EPROM. Later paks held RAM (and a battery) or flash for the very latest devices. Using more modern technology had a big advantage in that a UV eraser wasn't needed to clear the data on the pak. EPROMs had to be erased before allocated space could be re-used.

The storage devices in a pak are directly connected to a data bus on the slot connector, but the address bus was different. Due to a desire to reduce the number of connections required, the address bus on the storage device is attached to the outputs of a counter. To set up an address the clock on the counter is pulsed until the address is correct. Control signals then orchestrate the reading or writing of data.

Using this scheme the number of connections on a slot connector is kept to 16, even though datapaks up to 1Mb can be used. Larger address ranges would require a large number of clock pulses, slowing down the data rates, so larger datapaks use extra counters as page and/or segment counters. These control higher address lines and reduces the number of clock pulses needed to move to different addresses.

The Psion technical manual is available on the web and details all of the signals.

Pico

With the RP Pico arriving, I was very interested to see if I could use the programmable IO (PIO) feature to interface to older hardware. Creating a datapak for the Organiser II seemed to be one of those projects. The PIOs are small, fast processors or state machines that can perform tasks that are closely coupled to the GPIO lines on the Pico. As EPROMs (and RAM and flash) devices are usually found attached to processor buses they are inherently fast devices. The datapak doesn't run at high data rates, however, as the processor in the Organiser, a 6303, only runs at 900kHz. The interface code that drives the datapak slot signals drives them with no delays so, for example, the assertion of the slot select signal to read data is just three instructions:

Assert select

Read Data

De-assert select

With 3 or 4 cycles to execute these instructions we end up with a pulse width of about 200kHz or so.

This is well within the capabilities of the PIOs in the Pico, so I decided to go ahead and build a Pico powered datapak breakout board. this plugs in to one of the slots in the Psion and has an OLED display and some switches as well as level shifters (the Organiser is 5V, the Pico is 3V3). The idea is to present the RAM (or some of it) within the Pico as a datapak plugged in to the slot.

There's no commitment concerning GPIO assignment and the PIOs when creating a circuit with the Pico as the PIOs can use any GPIO, and can be disconnected from them entirely if code is to control them. So, I built a circuit before I had prototyped the method it would work under.

As it happened I had to make three boards as I messed up the slot connections on the first board (so it would only work upside down, not useful), and on the second board the level shifters I chose (YE08s) just didn't work. The third board using 74LVC245s worked perfectly. Well, the hardware did. As i looked at the PIO program that would be needed I started to realise that maybe the PIOs couldn't handle this interface. The problem was twofold:

1. The address counters were hard to implement as only one register (X) in the PIO could be changed by one in a PIO program. And it could only be decremented. Only decrementing wasn't too much of a problem, but there were also up to three counters in a datapak. Synchronising the address lines could be tricky.

2. The second problem was more of a show stopper. The address counters have to be combined and then be used to address the RAM buffer in order to get the data to be read or written. I couldn't see how to do this, which put a stop to me using the PIOs

Speed

Coming to the rescue, however, is the sheer speed of the processors in the RP2040 (the Pico processor). There's two cores running at over 100MHz and this is enough processing power to handle the datapak interface in firmware. I had to run the address counter handling on one core and the control signal handling on the other. I also found that interrupt latency was too high and have to poll the GPIOs in a loop. This means that the code has to run in two modes, one that is handling the pak protocol, and one that is driving a UI. This isn't much of a limitation as the Psion only talks to the datapak when reading or writing and actually powers the paks down when not using them. (This power down behaviour means that I have to power the Pico pak with a USB cable otherwise it is turned off between accesses).

After quite a lot of coding and interface investigation I managed to get this working and the code is capable of emulating a 32K datapak. With 235K of RAM on the RP2040 it shoul dbe possible to emulate 64K, and maybe 128K paks.

Space

The best form factor for a datapak emulator is, well, that of a datapak. So can the RP2040 fit in that footprint? Well, yes it can. The level shifters fit as well, as does a small OLED display and some buttons. In fact, the breakout board circuit can be shrunk down to fit in the datapak enclosure (holes for buttons and the display are needed, and for the USB connector).

For bulk storage I added an SD card slot so datapak images (in .opk format) can be read and written to and from the RAM buffer in the RP2040. That provides enough storage to easily store every datapak image I can find. Any of these can be swapped in to the RAM buffer and used as required. You can also write data to the RAM buffer and then write that to the SD card, providing almost unlimited memory to the organiser.

The wires are for programming the RP2040, they solder to pads on the PCB. The display is mounted 180 degrees from where I want it due to a PCB layout problem. The idea is to have the entire unit fit in the space of one datapak, which it should do when V2.0 fixes the issues on this PCB. 

The package used by the RP2040 turned out to not be a massive issue when hand soldering, using some extra solder and a hot air gun I was able to solder two devices with no problems and a third has some unknown issues which were solved by removing it and replacing with a new device.

The breakout board:

The datapak sized board:

The datapak form factor board, and the gadget plugged in to a model LZ organiser.

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.

Sony MZ-R37 LCD Reverse Engineering

Sony MZ-R37 LCD Reverse Engineering

I'd had a Sony MZ-R37 in the workshop for quite a while. I can't remember where I got it, I think it came in a job lot of something. It had battery leakage so I left it for later clean up. Unfortunately when I recently came to look at it again I found that the batteries had leaked out of the device and onto my shelf. It had turned from a possible recovery situation to a tear down and parts salvage. There's a video of the strip down here:

During that process I found that the display was an interesting little PCB with what looked like a serial interface. What made it particularly interesting was that it has a six character dot matrix display as part of the layout. This means that it could maybe display arbitrary character on it and make it a useful part to repurpose.

A very nice discovery was the service manual for the MZ-R37. This is very complete and had the pinout for the LCD controller flexi cable. It is indeed a serial interface. The interesting signals are:

DATA

CLOCK

STB

A0

DATA and CLOCK are serial data and clock respectively. STB is a strobe or chip select signal. The A0 line is a command/data selection signal. With this information it was easy to scope the signals up and see how the dot matrix data is transmitted. There's a block of 30 bytes clocked out with a preceding command byte of 0x0A. The bytes are columns of each 5x7 character, in sequence from left to right. The row order is not logical and has to be reordered from a standard top to bottom order. Only seven of the 8 bits in each byte is a dot matrix segment, the remaining bit (bit 0) controls an icon in the top right of the display.

I grabbed a trace of the matrix data for the Vr1.20 display, it is:

0x0a,                                           // Command code (A0 low)
0xe2, 0x14, 0x08, 0x18, 0xe2,                   // First matrix character data
0x7c, 0x20, 0x40, 0x40, 0x40,                   // Second matrix character data
0x00, 0x80, 0x80, 0xfe, 0x00,
0x00, 0x08, 0x00, 0x00, 0x00,
0x8c, 0x1a, 0x2a, 0x2a, 0xc8,
0xf4, 0x1a, 0x2a, 0x4a, 0xf4

As the data is jumbled it was difficult to decode this. I wasn't even sure that the matrix data was segment data, but 30 bytes was a bit too much for 6 characters of text if it was ASCII data. Counting the number of 1 bits in the data gave the same number as the number of segments in Vr1.20: 66 bits.

So it was definitely segment data. It took a lot of fiddling and test programs to work out the jumbling, but I did manage to work out the row order. 

I attached a Wemos D1 to the LCD PCB and replayed the 30 byte packet I captured earlier and the Vr1.20 appeared in the dot matrix area. I used voltage dividers on the GPIO lines and supply to drop the 3V3 to 3V0, just in case the display can't handle 3V3.

Once that was working I wrote a small test program that sent the 30 byte packet using a 5x7 font and jiggled row data. This allows arbitrary data to be displayed in the matrix characters. I also sent a second burst of data which is segment data for the left hand side of the display. The icons on the top right of the display are sent in bit 0 of each byte of the 30 character burst as mentioned above.

The switches are wired up with two signals that use voltage dividers to give different voltages for each key press. There's also a signal (WP) which pulses low when a key is pressed. Another signal (HOLD) is pulsed by the controller, but at the moment I'm not sure why. There's only one analog channel on the WEMOS D1 so I can't read both signals. At the moment the keys don't return different voltages when attached to the WEMOS, but do when attached to the MZ-R37 processor. I'm not sure why at the moment, but I'm not too worried about the switches, it was the display I was after.

Bus Sniffing Replacement Display for Fx702p

I've had bad experiences with heat seal connectors in the past (Casio PB220) and wasn't very happy to find that a broken Casio fx-702p had a heat seal connection from its main PCB to the LCD. The display wasn't working and when I had a look at the connector it had broken tracks. After buying some conductive paint (water based carbon), I had a go at repairing the tracks. This was going well until I pulled the LCD end of the connector ribbon at one side and the connections to the LCD just ripped off. The ease with which this happened might have been a clue as to why the fixes I was doing with paint didn't seem to be affecting the bad display at all. It looks like the LCD connections were dodgy as well. Fixing the LCD end of the connections is not something I think I will have much success at, so I ripped the entire connector off.

This made repairing the device out of the question at the moment as I have no way to connect the LCD to the PCB. After a bit of thought I wondered about attaching a totally different display to the LCD connections and get display output that way. This is theoretically possible, but as the LCD signals are multi-level (essentially analogue) and there are a lot of them (dozens) it would be difficult to capture the data needed to rebuild the display. The decoding of the signals isn't trivial either.

So I had a bit of a think and decided that an easier way to get a display would be to attach a sniffer to the bus that the processor uses to talk to the display controllers. Then I could capture the data going to the display controllers and put that on an external display. The fx702p would not have it's original display but at least I'd be able to use it. Then I thought about what else was on the bus and it got even better. The RAM chips that give the 702p its memory are also on the bus, so I could snoop reads and writes to the RAM and have an idea about what the programs stored in the RAM looked like. And any other data in there. This was looking feasible and interesting.

After some wiring

 I had a logic analyser attached to the bus and I managed to capture bus traffic:

This actually shows the message that the 702p displays at power on. The bus is four bit, though, so you only get nibbles displayed, and the 702p doesn't use ASCII for it's characters. The values starting 1 5 in the photo are the sequence:

1 5 4 4 0 4 3 4 8 5 F 0 F 4

If you turn these into bytes (reversing each pair of nibbles) you get:

51 44 40 43 58 0F 4F

If you check out a 702p character set map (such as this one http://www.pisi.com.pl/piotr433/fx702cod.png) you will see that these character decode like this:

51 R

44 E

40 A

43 D

58 Y

0F (space)

4F P

This is obviously the start of the 'READY P0' message that is displayed at power on.

Interestingly, this appears to be data sent to the display controller. When the CE lines for the RAM chips are examined, there appears to be no access to the RAM chips at all at start up. It looks like initialisation of the memory is done within the internal memory of the processor.

The next step was to use a logic analyser to decode as much of the display data as I could and then display it on the LCD. The final sketch uses interrupts to handle the bus accesses to the two display controllers and the main loop of the code to display the data.

My logic analyser has a slow 9600 baud connection for dumping traces, so using it to capture bus traces was time consuming when I was transferring the data from the analyser to a PC. Because of this I created a build option for the sketch that captured traces very similar to my logic analyser trcaes in the ISR. These traces are then decoded by the main loop and the data is displayed from them. This leads to a fairly large (2 or 3 seconds) delay before data from the ISR is displaye don the LCD, and also sometimes causes a trace buffer overflow and loss of cycles. It's a lot faster when looking at bus cycles, though, as the serial port runs at 2Mbps.  In normal ISR mode I also dump display data over the serial port so whatever is displayed on the 702p is available as a serial data stream.

There's a video showing it working and some description here:

The connections inside the fx702p require some fiddly soldering, but several signals can be taken from test pads, which is easier than soldering to an IC pin (which some signals have to come from).

I connected the signals to the blue pill using a milled PCB which makes the wiring much simpler than point to point. The physical layout of the board and components was for ease of debug and there are logic analyser connectors which aren't necessary any more. The whole thing could probably be designed to be much more compact.

The fx702p is normally powered by two 2032 button cells, which poses a problem as that can give a maximum of 6V when fully charged. The blue pill is a 3V3 device with 5V tolerant inputs. I therefore power the fx702p from the 5V supply of the blue pill and make sure that all signals from the calculator are going to 5V tolerant pins. This keeps the signals from the fx702p within safe levels. The calculator seems to run it's circuitry at the battery supply voltage, there's no regulator.

The latest incarnation of the display uses a milled PCB to simplify the signal connection from the calculator to the processor. 

The arrangement could be shrunk down, this PCB was a breakout board and has connectors for logic analyser signals, and was definitely not designed to be compact. I don't think the new electronics would fit into the case of the fx702p very easily, and I haven't seen a display that would fit in the space left by the old one. A better layout could be done though, and I may do that now I have the code and hardware essentially working.

Some sample displays. This is the power on display:

The 8 BB is part of a debug display of the annunciator data.
This is the MODE 1 display:

And this is a calculation ready to be evaluated:

There's some extra annunciators on that last display