The oldest TI-8x calculators are now over 30 years old, and they're starting to show their age. We've long known that there are two failure modes, depending on what's actually aging in the calculator. The root of the problems is the fact that TI designed most of the TI-8x calculators, from the TI-80 to the TI-86 (and with a slightly different design, the TI-89/TI-92/Voyage 200) calculators with two flexible plastic ribbon cables, one connecting the calculators' mainboard and LCD driver PCB, and the other connecting the LCD driver PCB and the LCD itself. Although using slightly different technologies, both of these ribbon cables rely on conductive glue on one or both ends to make a connection, and over time, this glue dries out. When the so-called "coarse" ribbon cable between the mainboard and LCD driver PCB dries out, it manifests itself as pixel noise on the display, sporadic functionality, and in extreme cases, the LCD only being able to display all black or even nothing. In 2010, I discovered that this coarse ribbon cable could relatively easily be replaced by soldering 17 thin wires in place.
However, the "fine" ribbon cable remained elusive. Fine ribbon cable failure is primarily indicated by missing rows or columns in a calculator's LCD, and they tend to be grouped together. Techniques tested by various Cemetech members including CVSoft, including using foam to place pressure on the ribbon-LCD connection and heating it, revealed that none lasted long-term. To date, I'm not aware of any lasting solution, and these days, you'd be hard-pressed to find a TI-82 or even a TI-83 without at least some sign of ribbon cable failure. Here at Cemetech, there's a substantial amount of interest not just on what we can do with calculators today, but being able to preserve the ability to show off these unique devices and the tens or hundreds of thousands of pieces of software written for them for decades to come. Emulators help, but there's nothing like physical hardware.
One solution is to put an emulator on embedded hardware, stuffed into a calculator case, like incomplete projects by Muessigb (the Pi84--) and me (the TI-87). If we can't keep the calculator's own LCD, though, the next best option would be to only replace the LCD + driver PCB, and retain the remainder of the calculator, including its native CPU, RAM, EEPROM, ASIC, and keyboard. Thus, I've long envisioned a project to build a replacement LCD + PCB that would understand the calculator's display protocol, could be slotted into an existing calculator, and would look as close to a native LCD as possible. Muessigb's Pi84-- project gave me renewed interest in the idea, since he found 128x64-pixel monochrome LCDs of just the right size to fit into a TI-8x's portrait-orientation case. Unfortunately, by the time I had the change to poke at this idea a year after Muessigb became inactive here, the LCD he used was no longer available from the European distributor he used. Thus, I set out to design a project around a new LCD plus a SoC or FPGA to translate the display protocol.
The resulting project-in-progress is called Surget, Latin for "it will rise", to reflect the project's goal of resurrecting "deceased", unusable TI calculators for posterity. I started by selecting a monochrome LCD, settling for now on the DisplayTech 64128 FC BW-3, a $21, 128x64-pixel monochrome transflective LCD with somewhat-removeable backlight and ST7565R LCD controller, incidentally the same one that Muessigb's display used. I also chose a TI-83 Plus Silver Edition that would serve as my testbed, and with any luck, the first recipient of a Surget LCD. Although the calculator's LCD protocol (familiar to ASM programmers as the stuff we write to ports 10h and 11h) is well-documented, the calculators mainboard-to-LCD driver PCB pinout was not, and I needed to figure it out. I found a website with just such a reverse-engineered pinout, but it turned out to be wrong. I set out to reverse-engineer it, armed with a logic analyzer and knowledge of the minimal set of pins needed to control a Toshiba T6K04, the calculator's original LCD driver (+3.3V and ground, 8 parallel data lines, read/write, enable, data/command, reset, and standby). After having been introduced to the platform by Geekboy1011, I chose to use the STM32F103 "Bluepill" board to read data and commands being sent by the calculator and dump them to a serial console to verify I had the pinout right.
Once I succeeded, it was time to stare at the new LCD's datasheet and find enough sample code for other platforms to let me communicate with this new LCD. Happily, this turned out to be a significantly easier problem - the bigger problem turned out to be finding the proper capacitors in my collection during a marathon HCWP session to properly power the LCD.
The current phase of the project is to put thing A and thing B together: parsing commands from the calculator using the Bluepill, translating them into commands for the new LCD, and sending them along. Several obstacles have cropped up, both of which have a significant negative impact on the speed at which I can transfer pixels from the calculator to the LCD. First, the calculator's original LCD has bytes of LCD buffer arranged across the display: on the 96x64-pixel LCD of the TI-83, for example, the LCD's buffer contains 64 rows 16 bytes each, 12 of which are visible as the 96 pixel width of the LCD. To make drawing text on the new LCD easier, however, it arranges the buffer into columns, so that you could write 8-pixel-tall, n-pixel-wide characters onto the LCD without needing to do any read-modify-write operations. Therefore, every 8-pixel write from the calculator must be translated into 8 bitwise operations on a pixel buffer in the STM32's RAM, then 8 data writes to the LCD itself, each of which consists of 3 command writes to set the column and row, followed by a data write to set the pixels accordingly. The second, related obstacle is that while fast (up to 72MHz), the STM32 doesn't seem to be fast enough to do all of this in the 1.8 microseconds between sequential out commands on a 6MHz z80 calculator. My current solution is an interrupt that captures data and command writes from the calculator and stuffs them into a ring buffer, with a main loop that process information in that ring buffer as fast as it can. I hypothesize that with the time necessary to determine what to draw to the LCD in even the fastest LDIR-type screen write on the calculator, my code will be able to keep up. Since graphing a function writes pixels particularly slowly, I was able to get a relatively rendition of a scaled sine graph to demonstrate that most of the components of this proof-of-concept are in place.
After solving the speed problem, the next step will likely be to design and fabricate a PCB that can serve as a permanent home for the LCD and SoC, either incorporating the unbelievably inexpensive Bluepill (~$3 USD) or a bare STM32F103. If I can't solve the speed problem, finding an LCD that has a horizontal buffer and ideally is a bit cheaper would be the best option, and long-term, I'd love to make this project FPGA-based for both speed and power consumption.
Any suggestions/comments/feedback? Let me know!
LCD Resources and Research
Bluepill/STM32 Resources
Setting up STM32Duino
However, the "fine" ribbon cable remained elusive. Fine ribbon cable failure is primarily indicated by missing rows or columns in a calculator's LCD, and they tend to be grouped together. Techniques tested by various Cemetech members including CVSoft, including using foam to place pressure on the ribbon-LCD connection and heating it, revealed that none lasted long-term. To date, I'm not aware of any lasting solution, and these days, you'd be hard-pressed to find a TI-82 or even a TI-83 without at least some sign of ribbon cable failure. Here at Cemetech, there's a substantial amount of interest not just on what we can do with calculators today, but being able to preserve the ability to show off these unique devices and the tens or hundreds of thousands of pieces of software written for them for decades to come. Emulators help, but there's nothing like physical hardware.
One solution is to put an emulator on embedded hardware, stuffed into a calculator case, like incomplete projects by Muessigb (the Pi84--) and me (the TI-87). If we can't keep the calculator's own LCD, though, the next best option would be to only replace the LCD + driver PCB, and retain the remainder of the calculator, including its native CPU, RAM, EEPROM, ASIC, and keyboard. Thus, I've long envisioned a project to build a replacement LCD + PCB that would understand the calculator's display protocol, could be slotted into an existing calculator, and would look as close to a native LCD as possible. Muessigb's Pi84-- project gave me renewed interest in the idea, since he found 128x64-pixel monochrome LCDs of just the right size to fit into a TI-8x's portrait-orientation case. Unfortunately, by the time I had the change to poke at this idea a year after Muessigb became inactive here, the LCD he used was no longer available from the European distributor he used. Thus, I set out to design a project around a new LCD plus a SoC or FPGA to translate the display protocol.
The resulting project-in-progress is called Surget, Latin for "it will rise", to reflect the project's goal of resurrecting "deceased", unusable TI calculators for posterity. I started by selecting a monochrome LCD, settling for now on the DisplayTech 64128 FC BW-3, a $21, 128x64-pixel monochrome transflective LCD with somewhat-removeable backlight and ST7565R LCD controller, incidentally the same one that Muessigb's display used. I also chose a TI-83 Plus Silver Edition that would serve as my testbed, and with any luck, the first recipient of a Surget LCD. Although the calculator's LCD protocol (familiar to ASM programmers as the stuff we write to ports 10h and 11h) is well-documented, the calculators mainboard-to-LCD driver PCB pinout was not, and I needed to figure it out. I found a website with just such a reverse-engineered pinout, but it turned out to be wrong. I set out to reverse-engineer it, armed with a logic analyzer and knowledge of the minimal set of pins needed to control a Toshiba T6K04, the calculator's original LCD driver (+3.3V and ground, 8 parallel data lines, read/write, enable, data/command, reset, and standby). After having been introduced to the platform by Geekboy1011, I chose to use the STM32F103 "Bluepill" board to read data and commands being sent by the calculator and dump them to a serial console to verify I had the pinout right.
Once I succeeded, it was time to stare at the new LCD's datasheet and find enough sample code for other platforms to let me communicate with this new LCD. Happily, this turned out to be a significantly easier problem - the bigger problem turned out to be finding the proper capacitors in my collection during a marathon HCWP session to properly power the LCD.
The current phase of the project is to put thing A and thing B together: parsing commands from the calculator using the Bluepill, translating them into commands for the new LCD, and sending them along. Several obstacles have cropped up, both of which have a significant negative impact on the speed at which I can transfer pixels from the calculator to the LCD. First, the calculator's original LCD has bytes of LCD buffer arranged across the display: on the 96x64-pixel LCD of the TI-83, for example, the LCD's buffer contains 64 rows 16 bytes each, 12 of which are visible as the 96 pixel width of the LCD. To make drawing text on the new LCD easier, however, it arranges the buffer into columns, so that you could write 8-pixel-tall, n-pixel-wide characters onto the LCD without needing to do any read-modify-write operations. Therefore, every 8-pixel write from the calculator must be translated into 8 bitwise operations on a pixel buffer in the STM32's RAM, then 8 data writes to the LCD itself, each of which consists of 3 command writes to set the column and row, followed by a data write to set the pixels accordingly. The second, related obstacle is that while fast (up to 72MHz), the STM32 doesn't seem to be fast enough to do all of this in the 1.8 microseconds between sequential out commands on a 6MHz z80 calculator. My current solution is an interrupt that captures data and command writes from the calculator and stuffs them into a ring buffer, with a main loop that process information in that ring buffer as fast as it can. I hypothesize that with the time necessary to determine what to draw to the LCD in even the fastest LDIR-type screen write on the calculator, my code will be able to keep up. Since graphing a function writes pixels particularly slowly, I was able to get a relatively rendition of a scaled sine graph to demonstrate that most of the components of this proof-of-concept are in place.
After solving the speed problem, the next step will likely be to design and fabricate a PCB that can serve as a permanent home for the LCD and SoC, either incorporating the unbelievably inexpensive Bluepill (~$3 USD) or a bare STM32F103. If I can't solve the speed problem, finding an LCD that has a horizontal buffer and ideally is a bit cheaper would be the best option, and long-term, I'd love to make this project FPGA-based for both speed and power consumption.
Any suggestions/comments/feedback? Let me know!
LCD Resources and Research
- LCD 64128M FC BW-3 on Digikey: https://www.digikey.com/product-detail/en/64128M+FC+BW-3/1756-1041-ND/6650335/?itemSeq=328633473
- LCD 64128M FC BW-3 examples: serial interface, parallel interface
- LCD 64128M FC BW-3 physical specs: https://cdn.displaytech-us.com/sites/default/files/display-data-sheet/64128M%20series.pdf
- ST7565R Controller Datasheet: https://cdn.displaytech-us.com/sites/default/files/driver-ic-data-sheet/Sitronix-ST7565R.pdf
- On the Repair of TI-83+ LCDs: https://www.cemetech.net/forum/viewtopic.php?t=5161
- Possible (incorrect, for my calculator) LCD pinout: https://ripitapart.com/2013/03/02/making-use-of-an-old-ti-83-plus-lcd-screen/
Bluepill/STM32 Resources
- Assorted installation instructions: https://www.dprg.org/wp-content/uploads/2019/09/Moving-Up-To-ARM.pdf
- How to Program a Bluepill with Arduino: https://idyl.io/arduino/how-to/program-stm32-blue-pill-stm32f103c8t6/
- Bluepill Development: https://satoshinm.github.io/blog/171212_stm32_blue_pill_arm_development_board_first_look_bare_metal_programming.html
- STM32duino-bootloader: https://github.com/rogerclarkmelbourne/STM32duino-bootloader
- Uploading a sketch: https://stm32duinoforum.com/forum/wiki_subdomain/index_title_Uploading_a_sketch.html
- Bluepill Pinout: https://idyl.io/wp-content/uploads/2018/07/stm32f103-pinout-diagram.png
Setting up STM32Duino
- Make sure you have a newish Arduino IDE (1.6.10+)
- In Preferences, add board source: https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
- Board Manager, update, add STM32
- Maple drivers: download https://github.com/rogerclarkmelbourne/Arduino_STM32/archive/master.zip, use "drivers\win\install_drivers.bat" and "drivers\win\install_STM_COM_drivers.bat"
- Plug in Bluepill, use Zadig to set WinUSB drivers for 1EAF 0003 (the Bluepill); it should show up as Maple DFU (not Maple 003) in libusb-win32 devices in Device Manager
- Set up Arduino IDE: Tools -> Board: "Generic STM32F1 Series", Board Part Number: "Bluepill F103C8", Upload method: "Maple DFU Bootloader original"
- Probably due to the pullup resistor being the wrong value, I (used to) need to repeatedly press my Bluepill's reset button when uploading a sketch.
- For serial output: make sure in Tools, "U(S)ART Support" is set to "Enabled (General 'Serial')" and "USB Support" is set to "CDC (Generic 'Serial' supersedes U(S)ART)"
