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