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
    Make sure you have a newish Arduino IDE (1.6.10+)
  1. In Preferences, add board source:
  2. Board Manager, update, add STM32
  3. Maple drivers: download, use "drivers\win\install_drivers.bat" and "drivers\win\install_STM_COM_drivers.bat"
  4. 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
  5. Set up Arduino IDE: Tools -> Board: "Generic STM32F1 Series", Board Part Number: "Bluepill F103C8", Upload method: "Maple DFU Bootloader original"
  6. 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.
  7. 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)"
Very nice!
Do you have any plans to make a more user-friendly version that could be hooked up to a MB without needing to microsolder 17 wires? For some of the older calculators like the TI-81, TI-82 and TI-85, you could use the holes intended for the ViewScreen instead of soldering directly on the pads for the LCD, assuming you want to support those as well...

Just throw on one of these...

I guess that wouldn't be very useful for the newer calcs like the TI-83 [Plus], TI-89 [Titanium] and TI-86 because the pads for the ViewScreen connector are even smaller and closer together than the ones for the ribbon cable.
Hopefully you can get this working on an LCD with a horizontal buffer Smile
Thanks for the support, mr womp womp! While I'd like to come up with a friendlier method of attaching it than 17 tiny wires, using the holes/pads you pointed to unfortunately still leaves the course ribbon cable in use, and I want to bypass both the coarse and fine ribbon cables for the highest longevity.

Thanks! The problem is that I can't find an LCD that is (a) the right size, (b) the right resolution, and a distant (c) parallel and (d) cheap. If anyone runs across a relevant monochrome LCD, please let me know!
Fantastic initiative Kerm! I think it is a great idea as you are 100% correct that we are seeing this issue more and more lately.
KermMartian wrote:
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.

My Voyage 200 ended up with about 3 lines of pixels (horizontally) still being able to display. It has now become an interesting challenge to try to do things on it, and a question more of remembering everything you previously typed than anything. Smile I attempted to fix it a few years back, but I didn't have much luck. Someone managed to replace their screen with an Arduino screen, but I have neither the knowledge, time, or money to try that.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum