While working with the TI-80 graphing calculator, I've come across many units having the common issue of columns of pixels missing or nothing rendering at all. I started to wonder if I could replace the LCD with something else. While the TI-80 firmware is locked in ROM, we have the datasheet for the T6B79 LCD controller and conveniently all the LCD pins are wired to an unused ViewScreen port. With a bit of soldering, I can imagine wiring a ribbon or flex cable to this unused port and to some controller that would drive a different screen.



As a proof of concept, I wired in a Raspberry Pi Pico to this bus while keeping the LCD connected. The Pico just acts as a monitor waiting for LCD /CE to be asserted, observing the read/write transaction, and updating an internal state machine. Wired on the other side of the Pico is an SSD1306 244mm (0.96in) monochrome OLED screen where I push the pixels out.

A bit of the firmware architecture. I split the controller into 3 discrete state machines:
1. PIO block waiting for /CE assertion and reading all data and control pins at the appropriate time
2. Main thread running on Core 0, handling data from PIO, updating LCD state machine, managing /STB interrupts, and passing data to OLED controller
3. OLED controller running on Core 1. This likely could run on Core 0, but I didn't want to risk starving the PIO RX FIFO and missing a command.

Proof of concept video running both self test and Input exploit. Since the OLED (128x64) is larger than the TI-80 LCD (64x48), but not large enough to upscale, I added a pixel Texas and TI-80 text at the top. When /STB is asserted, the firmware draws a border.


I'm not sure how far I'll go with this concept, but I'd like to see if I can get a thin lithium ion battery to replace the power. I wired in level shifters into this proof of concept so the Pico can run at its 3.3V and the calculator 5-6V, but I've tested running the entire setup on 3.3V from the Pico itself and there were no issues. I'm also looking for a more appropriately sized OLED screen since this one is very small and not the correct ratio. Given how simple this is, firmware on RPi is likely overkill and a small CPLD or FPGA might be able to handle it.

I've wanted to do this sort of thing for a long time tbh. Nice job.

Funny how the RP2040 cores are probably leagues faster than the TI-80's CPU lol

You say that the ti80 can have COLOR???

Neat! Every time somebody has mentioned using a Pi Pico with a calculator lately I've though of how GPIOs on RP2350 are now officially rated for operation at 5V logic levels, so there might be a chance you can rig up a solution that runs off the normal calculator batteries without any level shifting.

I'm not aware of any documentation that's been reverse-engineered for the LCD connections on other 8x calculators where the LCD is on a separate board from the rest of the system, but it seems like this architecture could also be adapted to those (but there's still the challenge of the "zebra strip" connectors that are basically impossible to rework).

To clarify, this is a monochrome (one color) OLED display. It still uses OLED technology, but just has one color.


Wow, that's really neat! I hadn't heard about the official validation of 5V tolerant GPIO on the RP2350 so thanks for bringing that up. I am very aware of RP2350 Errata 9 from the A2 stepping, but looks like that is addressed in A4 as well. This might make some of the other tests on TI-80 that i've been doing a lot easier - just need to remember to keep IOVDD powered or can still damage the pad when connected to 5V.

This sounds very much aligned with Surget. Relevant to Tari's mention, I've been failing to find the time to port Surget to the RP's PIOs; maybe your work here is the kick in the pants I need.

Very neat project queueRAM! I don't have a TI-80 myself, but this looks.. really impressive! It would be cool to see more colours on the TI-80, but unfortunately with the current (but honestly probably best) setup, it would probably not be possible. I don't know though, so maybe you can add data in the pixels or something like that.

That aside, this is a very cool project with the Raspberry Pi Pico module, and I would like to see extra progress on it! This most certainly should go on the projects of the month newsletter.

Wow, your Surget project is really neat - I had not come across it yet so thanks for pointing it out. It certainly aligns with some of my goals here. RPi Pico's PIOs certainly make catching events on bus manageable, however, given these are parallel buses and often have latching signals, some form of CPLD or FPGA may be cheaper, lower power, and better suited. Hardware like that may not be as easily accessible for approachable as a Pico.

In terms of display panels, I'm currently using a tiny OLED (244mm / 0.96in!) because I happen to have one on hand and was just using it in another project. Looking elsewhere, I've had my eye on the Sharp Memory in Pixel displays since they are very clean and low power. I don't know how the technology works, but it has the feel and power consumption of e-ink but the refresh rate of LCD. Sharp makes all kinds of sizes of the panels, but very few are available from distributors or on breakouts, so I haven't ordered anything yet. If you've ever seen the display in a Playdate, that handheld uses one of these displays. The displays are allegedly very easy to interface with microcontrollers, only requiring power, 3-wire serial comms, and 3 caps.


From the Memory Pixel Product List, there are some reasonable size options. For the TI-80, I was looking at the LS022B7DH03 which is 54.1mm/2.16in (outline 48.54x35.48x0.745mm) at 320x240 or a 5:1 ratio of TI-80's 64x48. I am having a hard time finding this for sale and will likely reach out to Sharp to see if they have recommendations. As an example of what a larger 2.7" display looks like, this is it being used in am embedded linux handheld project.

At an electronics store, I came across a DVI sock which can be connected to Raspberry Pi Pico and use PicoDVI FW to combine PIO, PWM, and DMA to generate valid DVI signals. This is all wired out an HDMI connector. I thought it would be fun to try to wire in an HDMI "ViewScreen". It took much longer than I expected, but was fun to learn a bit about DVI and cooperation between cores and generating scan lines.

Wiring to the calculator is mostly the same, but I need to shift the GPIOs to make room for the DVI sock. Large FW changes had to be made to allow for DVI to use one PIO and calculator GPIO for the other. To save memory, the DVI implementation is scan line based instead of framebuffer, so needed to redo a bit of the pixel generation logic. Below is the wiring and a picture of my setup.
Edit: forgot to mention that I entirely switched to running the calculator at 3.3V (was 5V) and removed the level shifters to simplify the design relative to the OLED one in previous posts.


This is running 640x480 60Hz with 1bpp. For convenience, I scale pixels by 8 so each calculator pixel is one byte in the scan line. Standby is still implemented by rendering a rectangle. This could be improved with colors or monitoring the contrast values and doing something clever, but I think this is where I'm going to leave the DVI project for now.

Hehe modern TI-Presenter, nice job

I still haven't been able to find the Sharp Memory-In-Pixel LS022B7DH03 (2.13", 320x240) display anywhere and haven't heard back from the vendor, so I picked up the next best thing, the LS027B7DH01 (2.7" 400x240). It's a bit too big for the TI-80, but the interface is the same as the smaller display so makes for a good experiment. I also wired in a 1mm FFC connector into the View-Con pads. I know the ViewScreen TI-80 uses a vertical connector, but I wanted to find something that may fit with the back cover on, so found a horizontal connector that barely has enough clearance to open the lever and slide the flex in.

I swapped out the tiny OLED display for this one and wrote a driver for the Sharp controller. It's a bit awkward to interface with since you have to push an entire line (row) at a time, the row numbering starts at 1 (not 0), and there are commands that need to alternate between high and low. It is also LSbit first SPI which is not compatible with the RPi Pico SPI controller, so for now, just swapped the bits in FW. Aside from that, I think the display looks real nice though! I'm running this at 3.3V, but the display breakout board I have include voltage regulators to supply the required inputs.

Wouldn't you need increased performance to run an oled screen smoothly. If the device was designed for monochrome the bottleneck would be the processor, right?

queueRAM is using an RP2040 to interface with the OLED, so the OLED does run smoothly. The RP2040 reads the data from the TI-80's screen connector directly.

It does make me wonder... would the RP2040 have the ability to emulate the TI-80 directly? Surely it has enough RAM, Flash ROM, and processing cycles? I found these:
https://github.com/djbottrill/rp2040_z80_emulator
https://github.com/udo-munk/RP2xxx-GEEK-80
https://zuzebox.wordpress.com/2023/12/31/raspberry-pi-pico-rp2040-retro-vintage-home-computer-emulation/

That's exactly right, I'm using a Raspberry Pi Pico with RP2040 which is a dual ARM Cortex-M0+ at 133MHz and separate PIO block for handling the parallel I/O on the LCD bus. The OLED I was originally using was like this very cheap 0.96" with SSD1306 controller which is around $1-2 USD. I was using it because it was the only display I had on hand, but it is not a good replacement due to size and power. This is why I've moved on to the Sharp Memory-In-Pixel displays which is excellent with power, but not so good on cost or control.


I haven't tried it, but the RP2040 likely can support emulating the TI-80. The RP2040 has 264K SRAM which is plenty to support the TI-80's 16K SRAM and framebuffers. The Pico uses 2M flash which would be plenty to store the ROM and emulator code. If your goal was to replace the TI-80 ASIC, RAM, ROM, but keep the form factor and LCD, might not be enough I/O on the Pico as it requires 12 for LCD control and 17 for key scans and On button and the Pico only supports 26 GPIOs. Other boards break out all 30 GPIO.

Since one of my TI-80s apparently has a bad ROM chip, I've also been kicking around the idea of replacing the ROM and LCD with an RP2040 and keep the T6M53A ASIC and the external RAM. This would require 15 address, 8 data, 2 chip enables, 1 write. Not only could this resurrect a calc with a broken ROM chip, but could also open the door for custom ROMs for testing or adding features.

ROM and display emulation in one microcontroller might be challenging due to timing requirements for ROM, but ROM alone is definitely doable. Have you seen PicoROM?

Both ROM and LCD would have pretty tight timing constraints, but I think with PIO and one ARM core juggling the ROM and LCD I/O and the other ARM core handling the graphics processing, I think it's doable. Especially since the RP2040 can run 133 to 200MHz. It is definitely something that would have to be measured and planned for before committing.


I have not seen this before, no, but it provides some good background so thank you for sharing. It specifies storing the ROM in RP2040 RAM to reduce access cycle time. However, it implements that I/O on the ARM cores which if that's all its doing is probably fine, but I'd like to push as much down to PIO as possible.