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

Panasonic Lens Fix (Again)

A few posts ago I fixed a Panasonic lens:

https://trochilidae.blogspot.com/2019/12/fixing-panasonic-h-fs014042-lens-i-use.html

When i got it the flanges that mount the lens to the camera had broken off. I suspected this was due to the lens and camera being dropped. Well, I can now confirm that if you drop this camera and lens combination the flanges do indeed break off. Because I have dropped it and they broke off from my 3d printed fix. Not only that, but I also broke the battery door catch, which is a small plastic part. The door is spring loaded and becomes very vulnerable to being snapped off if the catch doesn't work. So, two things to fix now.

The lens mount was a pretty simple fix, I printed another lens mount and did all the manual fiddling, and it worked as well as the first one. Excellent.

The battery clip was a bit harder. It doesn't have a flat surface to use as a bottom surface, and is quite small.

I decided to print the part at 100% infill and use support material. I was expecting to have to manually fit the part anyway, so removing support material is just part of that. I had green filament in the printer, so I used that. These are some prototype parts, and the final part together with an unbroken clip that I removed from another GF1 I have:

The final part I am now using is the one next to the real part. I had to thin down the body of the clip so it fitted in the space it had available for sliding. There is a spring clip that provides a latching action, I hand finished that area with a soldering iron as the printer couldn't manage a good version of that shape. It's the recess with the bar at the bottom of these parts. The part on the right has the raw 3D printed version and it's not any use at all.

Here's the clip in the retracted position:

And in the extended position:

The clip is a bit obvious in green, but it's a signal that it may feel different when using it.

I wish I hadn't dropped it, but, it's fixed...

OpenSCAD file is here:

https://www.thingiverse.com/thing:4174540