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: https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
  2. Board Manager, update, add STM32
  3. 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"
  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.
That is impressive wiring . those glued ribbon cables.... Fortunally there are some models which have those ribbons properly soldered to the pads and allow rework, example ti 89 :

https://drive.google.com/file/d/126MdYl45EFK_tI9SAFsfRVKZ5wAMFmcE/view?usp=sharing
Hi!
Can I see the source code for the STM controller? I am also interested in this project. There is a small idea.
Sorry, I use an online translator. My English is weak for fluent communication.
US $8.40 | Большой размер 36PIN COG 12864 ЖК-дисплей экран ST7565R контроллер синяя/белая подсветка 3,3 V
https://a.aliexpress.com/_Agkxnw
TIny_Hacker wrote:
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.
This is great! And exactly what I'm trying to do with this project. Thanks for bringing this forward.

Freezer wrote:
US $8.40 | Большой размер 36PIN COG 12864 ЖК-дисплей экран ST7565R контроллер синяя/белая подсветка 3,3 V
https://a.aliexpress.com/_Agkxnw
Unfortunately, this has the same problem (relative to this project) of all the other ST7565R LCDs: it has its data oriented down columns instead of across rows, which means Surget needs to work faster to translate each including byte of data from the calculator into 8 different bytes of its own internal cache, and also queue those bytes to be updated on the replacement LCD. I had a bit of trouble having the STM32 keep up with the calculator doing all of this. The biggest issue was large LCD writes or worse, continuous LCD writes, where by doing 8 times as much work as the LCD (i.e., splitting every byte of 8 pixels across 8 different buffer bytes, the STM could never catch up). There may be a solution I'm overlooking.

Freezer wrote:
Hi!
Can I see the source code for the STM controller? I am also interested in this project. There is a small idea.
Sorry, I use an online translator. My English is weak for fluent communication.
I'm happy to clean up the code a bit and post it up.
I don't have a calculator, but the display is the same. I have a car dashboard. The display is controlled by an H8 / 3042 processor (HD6433042F). But between the display and the processor is the U6264AS1A memory. It serves as a buffer. Perhaps using such memory in your project will help solve this problem.

post merge by admin: Sorry, I misunderstood your problem. Now understood Smile STM does not have time to quickly convert data for the display. Hence, a different algorithm must be applied.
How about overclock?
http://amitesh-singh.github.io/stm32/2018/06/17/overclocking-blue-pills.html

128MHz
Overclocking seems like a bad option to me- it may not work at all, or if it does it may not be reliable.

Ready availability of LCDs seems like an important issue however; I wonder if a different controller might work better for this application. I first thought the PIOs on an RP2040 might work well, but I suspect those datapaths aren't wide enough for your needs- perhaps your approach could be modified to buffer columns in SRAM and write those out in sequence? Sacrificing some LCD timing by buffering might provide enough efficiency to meet your timing requirements, and seems more amendable to using hardware acceleration (possibly in the form of RP2040 PIOs being driven with DMA).

The RP2040 seems like an attractive alternate processor since it's available in a similar form factor and for similar cost to the STM32 boards in the form of the Raspberry Pi Pico, the PIO blocks allow pushing huge amounts of data with minimal CPU cost, and its raw clock speed is very high- two cores at up to 133 MHz, not to mention the large memory bandwidth you get from its memories being aggressively split into multiple banks.
Thanks for the feedback, both. Overclocking would maybe get me in the ballpark of pushing enough pixels through, but using something like the PIO engine on the RP2040 to work smarter rather than faster sounds much more what I should be trying (and probably lower power consumption to boot).
Are you going to rewrite for RP2040? Can you send the source code for STM to the my email? I will try with overclocking.

Still waiting for an answer Smile
Freezer wrote:
Are you going to rewrite for RP2040? Can you send the source code for STM to the my email? I will try with overclocking.

Still waiting for an answer Smile
I'll try to clean up that source when I have a chance.

Relevantly, I also received some RPi Picos from England, because the US doesn't have any.
Recently, I’ve gotten into the business of buying bulk orders of TI graphing calcs on Ebay listed for parts of repair, mostly because I’ve started getting into the collection and documentation of old hardware revisions. I’ve found that, in most cases, screen issues caused by both ribbon cables can be fixed by nothing more than a soldering iron. For the 17-contact ribbon cable, I set my soldering iron to the lowest temperature (150C) and press firmly on the glue on each of the contacts in 2-3 places per contact using the tip of the soldering iron for about 2 seconds. For the LCD cable, I press firmly on the ribbon cable contact strip with the iron while slowly dragging the iron across the cable (with the plastic sheath still on the cable). Though this isn’t the best way to do it, it has succeeded in fixing every TI-83 I have attempted to fix, except in a couple cases where the ribbon cable was partially severed and I had to solder my own connections. I measure the resistance of the connections before I put the calc together, and redo connections with resistances above about 8 Ohms.

The 83+ and earlier calcs are significantly easier to work on than the 84 and later. On some calcs, like my 84 Pocket SE, dead lines may be caused by connections between the LCD panel and ribbon cable that are inaccessible because they are physically beneath the LCD. I have yet to figure out how to fix calcs with this issue, as I do not know how to separate the LCD from the PCB beneath it without breaking the fragile glass.
On the topic of preserving TI-8X calculators for the next 20 years...
Have you been documenting old revs? If so, I'm happy that we're on the same page about these needing to be documented before its too late.
Can you hook us up with pics of these PCBs pls Smile

  • Voyage 200 factory I rev B
  • TI-83 Plus SE factory S rev D
  • TI-82 factory I rev T
  • TI-83 factory I rev F
  • TI-83 factory I rev G
  • TI-83+ factory N rev D
  • TI-84+ factory S rev A
  • TI-84+ factory P rev N
  • TI-84+SE factory S rev D
  • TI-85 factory I rev J


I'm not sure if you already have this but here is the link to the ghseets where we have all been documenting everything.
Sam wrote:
Recently, I’ve gotten into the business of buying bulk orders of TI graphing calcs on Ebay listed for parts of repair, mostly because I’ve started getting into the collection and documentation of old hardware revisions. I’ve found that, in most cases, screen issues caused by both ribbon cables can be fixed by nothing more than a soldering iron. For the 17-contact ribbon cable, I set my soldering iron to the lowest temperature (150C) and press firmly on the glue on each of the contacts in 2-3 places per contact using the tip of the soldering iron for about 2 seconds. For the LCD cable, I press firmly on the ribbon cable contact strip with the iron while slowly dragging the iron across the cable (with the plastic sheath still on the cable). Though this isn’t the best way to do it, it has succeeded in fixing every TI-83 I have attempted to fix, except in a couple cases where the ribbon cable was partially severed and I had to solder my own connections. I measure the resistance of the connections before I put the calc together, and redo connections with resistances about about 8 Ohms.
Good stuff! Unfortunately, tests that notipa/CVSoft and I performed a few years ago suggest that this method of repair doesn't last long.
I am not sure if anyone has ever tried that, but I want to see if a failed fine ribbon cable can be replaced with fine enameled wires that were pre-arranged such that they rigidly remain correctly spaced apart. For example, by placing them on adhesive tape, hot glue or the like. This could allow them to be soldered somewhat similarly to a regular SMD package with small pin pitch.

If anyone has a calculator with a failed fine ribbon cable and is willing to ship it to Germany, I would really like to try this - but as a word of caution, I cannot guarantee that whatever I do will not destroy the calculator.
KermMartian wrote:
Sam wrote:
Recently, I’ve gotten into the business of buying bulk orders of TI graphing calcs on Ebay listed for parts of repair, mostly because I’ve started getting into the collection and documentation of old hardware revisions. I’ve found that, in most cases, screen issues caused by both ribbon cables can be fixed by nothing more than a soldering iron. For the 17-contact ribbon cable, I set my soldering iron to the lowest temperature (150C) and press firmly on the glue on each of the contacts in 2-3 places per contact using the tip of the soldering iron for about 2 seconds. For the LCD cable, I press firmly on the ribbon cable contact strip with the iron while slowly dragging the iron across the cable (with the plastic sheath still on the cable). Though this isn’t the best way to do it, it has succeeded in fixing every TI-83 I have attempted to fix, except in a couple cases where the ribbon cable was partially severed and I had to solder my own connections. I measure the resistance of the connections before I put the calc together, and redo connections with resistances about about 8 Ohms.
Good stuff! Unfortunately, tests that notipa/CVSoft and I performed a few years ago suggest that this method of repair doesn't last long.
Could you elaborate on the tests you and CVSoft ran? By "doesn't last long" do you mean it doesn't last more than a few weeks, or more than a year? I would certainly agree that my method is not in the best interest on the calculator's longevity, but I still think that heat+pressure may be the best option overall, if I had a better setup than a normal soldering iron. I'd like some sort of very blunt iron that can cover a much larger flat area than a soldering iron, to hopefully reseat the whole cable's glue as though it was factory.
  
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 2
» All times are UTC - 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

 

Advertisement