Casio FX-502P SD Card Gadget Prototype

 Casio FX-502P SD Card Gadget Prototype

A while back I made a gadget that attached to a Casio FX-502P via an FA-1 and stored programs and data on an SD card instead of a cassette . 

https://trochilidae.blogspot.com/2017/06/fx502p-cassette-interface.html

It decoded the frequencies that the FA-1 sent to a cassette recorder and wrote the data to an SD card attached to an Arduino Due. I had to use a Due as it was the only combination of  clock frequency and RAM that could keep up with the data stream coming out of the FA-1. 

The advantage of using this approach was that the cassette interface was a well-known format and fairly easy to decode. The disadvantage is the bulk of the final package. To get the data onto the tiny little SD card you need the FA-1 cradle and the gadget. A few weeks ago I suddenly realised that I could cut down on a lot of the hardware needed by attaching a gadget to the expansion port on the top of the FX-502P. This would involve interacting with the protocol that goes over the expansion port, but that shouldn't be a problem. There's a lot of detail here about the expansion port of the FX-602P and FX-700P.

As a base for a prototype I used the Sharp PC-G850 gadget, using the Blue Pill processor and the OLED display. The expansion port signals are attached to the 11 pin Sharp interface connector on the gadget using a cable.

The protocol that the expansion port uses is a bit odd. It seems to be the bus that the processor in the calculator uses to talk to the LCD controller. It has a single bi-directional  serial data line, a chip select, a command/data control line and a clock for the serial data. The data packets are of variable length, which makes it a bit hard to decode. Most packets are 6 bits long, there is one two bit packet and a 16 bit long data packet (holding an RS232 type character format that encodes a single byte of data. The clock edge that the data is latched on is different for transmitted and received data. And the data is inverted logic (0 is 3V and 1 is 0V, not forgetting that the calculator uses 3V as it's 'GND' and -3V as its VDD).

Once the signal levels are sorted (use 0 and 3V to power the STM32, invert data to get levels that match the known commands for the FX-602P) the data and clock can be fed to GPIO lines on the STM32, The bus runs at around 200kHz, so there's not a lot of time to process the packets. It is not feasible to have any delays so I run the decoding code purely in interrupts (one on the SP or clock line and one on the CE signal). The timing is so tight that initially I had problems with the serial port disabling interrupts (I presume that is what it was, disabling serial IO removed the problem), those problems went away with later code, but I can still disable the serial port access when packets are received.

The data that is sent and received is held in a RAM buffer, there is no time for access of the SD card, so the RAM buffer is stored and loaded from SD card when needed.

After quite a lot of reverse engineering of the interface (the FX-502P is not quite the same as the FX-602P) including capturing traces of communication between the calculator and an FA-1 adapter, I got some working code that could both send and receive data files from the calculator.

This gives a gateway between the calculator and the outside world. The calculator has a limited number of ways to send information over the interface. It can send or receive a single number (this is the quickest transfer), it can send or receive all memories

At this point the prototype was limiting the code as there isn't sufficient flash memory on a Blue Pill (STM32F103C8) to implement the features I wanted to add. The basic idea had been proven with the prototype, time to move on to a better platform. For that I chose the STM32F103RE device. Or, more accurately I chose the 64 pin QFP package. The STM32F103 family has nice pin compatible genetics, so several devices of different capacities will fit onto a particular footprint. Using the 64 pin QFP I can got up to 1M of flash and 96K of RAM down to 16K of flash and 6K of RAM. There's also a lot of GPIO on this package, way more than I need for this gadget.

It has a small 0.96" OLED display, an SD card module and a programming header that uses an STLINk V2. It also has a serial data header with TX and RX, and a header with 8 GPIOs on it (and power):

The PCB plugs into the connector on the top of the calculator. Optionally the PCB can supply power to the calculator, or it can run off batteries, there's a jumper for that. It's the red one. 

I have also used a USB socket breakout board for the USB connection, which supplies poiwer for the PCB and also provides a serial connection. I use a breakout board as the USB sockets have a habit of ripping off the PCBs and taking tracks with them. This way the tracks are on a disposable PCB, not the more valuable one. I've already replaced the USB socket and breakout board on the is PCB...

The code is based on the Arduino platform, so it can connect to the serial monitor of the IDE.

What can it do? Well, it can save and load programs and memories to and from the SD card, that's the basic function. It also uses several 'special' values to do other things. Things like displaying programs on the OLED display:

 With GPIO lines you can interface any I2C device, such as a real time clock. This is the STM32 displaying time in a display mode set up by the 502, using a DS3231 RTC module:

You can also read the time (and date) into calculator memories:

Of course, it is useful to be able to print things out now and again. Interfacing a simple thermal printer isn't difficult. The one I used accepts serial data so I attached it to the serial data header .The calculator can set up a print flag that sends programs and memories to the printer as well as SD card.

This printer does require a 2A supply, so can't run off the USB direct from the PCB.  

There was a printer that attached to the FX-502P, but it used magic metallised paper which is pretty much impossible to find these days, so a thermal paper option is a nice alternative. See here for more magic metallised paper experiments:

https://trochilidae.blogspot.com/2019/12/magic-metal-paper-in-seventies-casio.html
https://trochilidae.blogspot.com/2020/01/more-magic-metallised-paper-experiments.html

As well as the RTC, I've attached a sensor module and an accelerometer, but haven't done much with them other than read registers. There's also a text mode where the calculator has a text screen that it can place ASCII text on, and a graphics screen that it can place pixels on.

More information on these videos.

The gadget should work perfectly fine with an FX-501P, as it's the same code and hardware in the calculator as shown in this video:

The FX-602P and FX-601P use the same interface but a slightly different command set. It should be possible to get it to work, though, with some changes to the firmware on the gadget. 

The FX-702P tantalisingly uses the same connector as the 502/602 series calculators, and the same command set as the FX-602P, but unfortunately uses 5V signalling rather than the 3V of the 502/602. The pins used on the STM32 for the calculator interface are 5V tolerant, but there's a couple of issues. The first is that the STM32 should be able to sense the 5V logic levels correctly, but may have trouble driving 5V levels due to 5V tolerant pins still driving at 3V3. The second issue is that the data line is bi-directional and the 5V tolerance on STM32 devices only works when it is configured as an input. I have serial resistors on the calculator interface lines, which might help, but if there's a time when driving the interface that I drive the data line as an output and the calculator does the same then there could be problems. I may try this in the future, as it may work.