The Insane Innovation of TI Calculator Hobbyists • &> /dev/null

In the mid-to-late 2000s, you either knew, or were, that kid in grade school.
You know. The one who could put games on your graphing calculator.
You may be surprised to learn that some of these people didn’t exist totally in a vaccuum.
There was in fact a thriving scene of hackers who had bent these calculators to their will, writing games, math software, and more generally hacking on the platform just for the sake of it.

True to my interests, it’s all deeply embedded, pushing the limits of platforms that were obsolete when they were released.
I’ll take you through some of the highlights of Texas Instruments calculator hacking done over the past two and a half decades, along with an explanation of why these projects are so technically impressive.

College Board issues aside, I have fond memories of TI-BASIC, writing in it a 3D graphing engine and a stock market analyzer. With enough patience, I could make anything ... but friends. (Although with my chatterbot experiments, I certainly tried.) — This is xkcd #768. There are also 768 bytes in the RAM buffer used to hold TI display bitmaps. This is not a coincidence because nothing is ever a coincidence with xkcd.
(source)

Note
Wow, it’s been a while since I’ve written anything.
In the space of a year I’ve gotten a new job, bought a house, moved.
Life comes at you fast.
Thanks to everyone who has emailed to check on me—and I apologize for not being super responsive over email.
I do plan to continue the articles I’ve started!

The platform

Throughout the 90s and 2000s, TI released a succession of z80-based graphing calculators.
You might have heard of the z80—it was an improved version of the Intel 8080 developed by Zilog.
Yeah. It’s old.^{They were quite nice 45 years ago when they were released!
All TI calculators generally had similar low-end specs:}

z80 processor usually clocked at 8 or 10MHz—and note that the z80 can only retire one instruction every 4 cycles.
96×64 black and white LCD (a few models had a larger screen but this was by far the most common. The latest models finally have higher resolution color screens.)
A link port which (ab)used the 2.5mm headphone jack connector
Generally, 32KB of RAM, and on the 83+ and later, anywhere from 100KB to 2MB of flash storage (“archive”)
TI’s operating system “TI-OS” (they call it “EOS” but nobody else does). TI-OS has:
- Arithmetic and graphing engine
- TI-BASIC scripting language
- On the models with flash, support for launching large “apps” stored exclusively in flash

Needless to say, this is the very definition of a constrained environment.

The most popular graphing calculators were of course the TI-83/84 Plus, which every American student for the past decade and a half has probably seen.
I will use “TI-84 Plus” throughout here because it’s very likely the model you’re familiar with; however, it was more often referred to as the TI-83 Plus because they were basically identical.
The 84 Plus had USB and a redesigned case, but the system was the same.

Programming model

The z80 assembly^{programming environment was pretty spartan: there was no supervisor or memory protection, so if you had a bug you were probably going to crash the calculator (the dreaded “RAM Cleared” message).
The z80 is an 8-bit machine, with 16-bit pointers, so although archive was technically memory mapped, it wouldn’t all fit—it was actually paged in to a 16KB “window”:}

This diagram is heavily simplified, but you’ll notice the lack of any horsepower at all.

There were several guides for learning assembly, but the best was by Sean McLaughlin, Learn TI-83 Plus Assembly in 28 Days.
TI provided a very good SDK documentation about subroutines provided by TI-OS (and official support for Asm() programs), and with that you pretty much had free rein over the system.

Software projects

Those who followed calculator hacking news will surely recognize the individuals I’m calling out here, either by their name or, more likely, by their handle.
For my own part, I was almost entirely a lurker, largely due to the influence of my parents who were not keen on talking to people online.
(Remember, high school.)
I was, however, a pretty good self-taught calculator programmer—more on that in a later article&mldr;

Note
A fair number of these links are starting to rot because development happened 20 years ago. Please do email me with corrections if you find a newly dead link. And of course massive kudos to the Internet Archive for preserving it all!

Phoenix

Easily the most famous^{graphing calculator game is Phoenix by Patrick Davidson.
It’s a top-down space shoot-em-up similar to the arcade game Galaxian.
The reason it is famous is not because it is fun—although it is—nor because it’s well implemented—although it is.
Rather, this game is famous because it is one of the oldest, and Patrick and others have ported it to nearly every single z80 calculator ever released.}

Grayscale on the TI-84 Plus

The first thing I remember being really wowed by was an RPG game called Desolate by Patrick Prendergast (tr1p1ea), which boasted four level grayscale.
On top of that the game was not just a tech demo; it had a fully featured storyline and pretty good sprite art.

Most emulators were able to detect that the application was doing grayscale and produce a clean rendering of it

How was this possible on a device with only a black and white screen?
The answer was that if you flickered pixels on and off fast enough, they would appear gray.
Naïve attempts at this led to horrible jittery messes and found it difficult to get over 3 colors (black, white, gray).
In contrast, Durk Kingma’s grayscale library that Desolate used achieved really nice 4-gray art by careful timing and by dithering the flickered pixels so that not all were on or off at once.
Graphics consumed the majority of the compute budget for the game—but such is life for most video games!

Game Boy emulator for the TI-84 Plus

TI wasn’t the only company using z80 processors.
The original Game Boy used them too!
A natural question arises: maybe, possibly, could you run a Game Boy game on a calculator in some sort of hypervisor?

Brendan Fletcher (calc84maniac) put a ton of engineering into TI-Boy SE, which does exactly that!
A Game Boy cartridge is fairly large—Pokémon Red’s ROM is 1MB—so TI-Boy solves this by packing the ROM into a “shell” flash app using a PC program.
Of course, you had to bring your own Game Boy cartridge ROM.

The next problem is that many Game Boy cartridges have more RAM (up to 128KiB) than the TI-84 Plus (32KiB).
(The Game Boy had only 8KiB built in, but cartridges could supply extra.)
Here we’d seem to be stuck: how can you possibly emulate extra RAM?

Xavier Andréani (critor) observed that TI calculators did in fact have extra RAM because the ASIC containing the z80 had more RAM than was exposed by default.
TI-Boy reverse engineered the special commands to the hardware to bank-switch these into address space!

The result is impressive:

TI-Boy playing Legend of Zelda — TI-Boy playing *Legend of Zelda*
(via ticalc.org)

Shells

On calculators released before the TI-83 Plus, there was no official way to launch assembly language programs.
These calculators had to be hacked using various techniques.
The solution for end users was a shell – a launcher program that handled the annoying bits of transferring control from the OS.
Many shells also provided additional routines a program could call.

On the TI-82, the Ash shell accomplished this by sending a specially-crafted memory backup to the calculator.
When the calculator next handled a keypress, the memory image redirected the CPU into the setup code.
In a sense, this technique is one of the oldest exploits for any TI calculator.

The shell that you are most likely to remember is MirageOS for the 84+.
MirageOS was a popular tag-along with games shared peer-to-peer with a link cable, because the games needed it to run.
It was also a flash app, so it persisted through RAM clears.
I remember not being entirely clear on why its splash screen was so elaborate when I first encountered it, but now I appreciate the artwork!

Shells got more elaborate over time, culminating in Doors CS by Christopher Mitchell (KermMartian), which had icons for assembly programs, a cursor-based UI, and a bunch of routines for programs to use.

TI-84+ USB mass storage driver

The 84+ had a really wacky USB port: it was an On-the-Go port, very obscure when it was released.
This technically meant that the 84+ could act as a USB host.
Dan Englender’s Usb8x supplied the missing driver code, allowing you to use a mouse (of questionable utility), keyboard, or more importantly, a flash drive.

The calculator’s boot code provided low-level USB routines for get/send, but the impressive part is the upper USB stack including the mass storage and FAT16 driver “msd8x”—all, of course, in z80 assembly!

Usb8x enabled, among other things, a hilarious demo: Michael Vincent may be one of the only people to have ever watched The Matrix on his calculator.

(via ticalc.org)

KnightOS

Drew DeVault (SirCmpwn) was working on a promising project replacing TI-OS entirely with a from-scratch Unix-inspired, multitasking system called KnightOS.
The cool part about this system is that it drew a lot from the multitasking paradigms we take for granted on a Mac or Linux box, but did it all with barely any help from the hardware.
Programs were relocatable, there was preemptive multitasking, and there were loadable libraries that worked exactly like shared objects do in Unix.
There was also a “real” filesystem with directories, flash wear leveling, and a protocol to connect to a computer.
(It even has its own USB PID—0xCA1C.)
Of course, the whole thing was all carefully implemented in z80 assembly, and kernel and library routines documented the contents of each register.

It’s not vaporware; there’s autogenerated builds you can download and install on your calculator, and the source is on GitHub.
Unfortunately its broad scope prevented it from achieving a stable release, but the bones are there and they are cool.

I actually contributed a little to this project: I remember just having learned about synchronization primitives (mutexes and condition variables) and I easily knew enough about the z80 to be able to implement them for KnightOS.

The Axe Parser project

As you might imagine, there are two problems with writing assembly programs.
First, you generally need a PC to do it properly, and most budding programmers were in school for most of their day.
Second, and more importantly, z80 assembly is pretty arcane if you’re coming from BASIC.

With the Axe Parser^{, Kevin Horowitz (Quigibo) attempted to solve these problems by creating a new programming language that compiled into native code on the calculator.
Axe is an app that reads a “TI-BASIC program” written with the built-in editor, but Axe redefined the grammar and semantics to provide a language that was very well suited to writing games.}

It’s quite an elegant solution: using the built-in editor means Axe didn’t have to ship an editor for its language.
Rather, Axe is a compiler—it spends its engineering budget on producing better assembly code, with pages and pages of forum threads devoted to optimization.
And further, Axe is extensible with new primitives provided as “Axioms”—plugins that further manipulate the grammar of the language.

Here’s a hello world program in Axe.
The Str1 token has been co-opted into a 16-bit pointer variable—this compiles on-calculator to an assembly program called HELLO!

:.HELLO:"Hello World"→Str1:Disp Str1

Unity: Native code on the TI-81

The TI-81 was an absolute potato of a calculator. Not only did it lack archive memory, it also lacked a link port, and lacked the Asm() command, meaning you were stuck with TI-BASIC.

Stuck, that is, until Ben Moody (floppusmaximus) released Unity, a loader that exploited a buffer overflow in the primitive TI-OS, then installed itself to help load other assembly programs.

With no link port, how did you get Unity or other assembly programs on the calculator?
You typed them in, by hand!
The installation instructions are reminiscent of typing in BASIC programs out of BYTE magazine:

I suspect Randy Compton, who originally discovered the OS bug, did so by dumping the ROM with physical disassembly.
z80 assembly is extremely amenable to reverse engineering because it’s hand-written.

Operating system hacks

While most projects ran on TI-OS, some ran up against TI-OS in order to make the hardware do things that TI preferred they didn’t do.

There were scruples.
Most people wanted to avoid the ire of Texas Instruments because (a) even the threat of lawyers tends to have a chilling effect on high school students and (b) people generally wanted to avoid besmirching the community’s image.
And so there were certain things that were mostly considered off-limits, namely programs that were designed to help cheat on tests.

Signing keys

Really all anyone wanted to do was run their own code on their own hardware.
TI had a crude but effective cryptographic signature check for apps and operating systems, which used the Rabin cryptosystem.
They had released the signing key for TI-83 Plus apps as part of the SDK.
However, the other keys that allowed signing OS images for the 83+, 84+, and apps and operating systems for the TI-89, were still secret.

Using math against calculator enthusiasts—what did TI expect to happen?!
Ben Moody realized that the state of the art in 2009 was enough to directly crack the ten year old 512-bit keys.
His post (enigmatically titled “Fun Number Theory Facts”) revealed that he had found the prime factors of the public key for the 83+ operating system.

Initially flabbergasted, the community threw together a BOINC cluster which cracked all the remaining keys in a few weeks without breaking a sweat.

Texas Instruments threw a tantrum, lobbing legal threats that were, frankly, 100% bullshit abuses of the DMCA.
The Electronic Frontier Foundation intervened on the hobbyists’ behalf, explaining to TI that there is nothing illegal about knowing the prime factors of certain integers.
The whole thing earned its own Wikipedia article.
Today, you can easily find these keys on any enthusiast site, including right here.

arTIfice

Fairly recently (late 2020), TI decided what everyone really needed was a cold shower, and announced they’d be disabling all this assembly business with a software update for the TI-84+ CE (the newest color calculator), dubiously claiming that this would improve exam security, etc, etc.

To quote Lionel Debroux:

This slam shuts [sic] a golden age of over two decades (!) of native code being officially supported on at least one actively maintained TI graphing calculator.
[&mldr;]
Like all true calculator enthusiasts, we have hard feelings about the matter. The community had always been nice to TI – nothing really damaging for TI’s business was ever released over 20+ years! – but a moral barrier has probably been broken today&mldr;

As an olive branch they offered Python bindings; everyone immediately pointed out that Python is wicked slow in embedded environments and absolutely cannot replicate what native code can do.^{If you’ve read this far, you’ll note this isn’t the first time TI has been a little tone-deaf toward enthusiasts.}

Enter arTIfice^{– a proper jailbreak for these calculators. You simply install the CabriJr geometry app, and open a special data file with it, and suddenly you’re presented with a menu allowing you to run whatever you like.}

What’s cool about this is that it’s a jailbreak, not just a sweet hack that uses the hardware.
Just like you may be familiar with jailbreaking an iPhone or Xbox, starting from within the sandbox and getting out, this abuses bugs in the wildly complicated CabriJr geometry app (signed and blessed to run by TI) to reenable arbitrary code execution and literally pop a shell or install hooks into the OS.

The arTIfice exploit is just 927 bytes, and it packs a simple UI and loader in behind the shellcode.
Being this small, the underlying exploit is probably the lowest hanging fruit of plenty of zero-days in this and other TI software.

So yeah, now exams are secure, or something.

Whence from here?

For every project I listed, there were ten others that I didn’t.
(And if I missed yours, I mean no disrespect!)
The breadth and depth of tinkering is staggering: I haven’t even touched the scene for the ARM-based Nspire.

There are always challengers to Texas Instruments’ entrenchment in high schools; Casio in particular has made some attractive devices.
There has been a modest amount of scene releases for Casio calculators as well.

The startup Numworks makes calculators based on a very capable STM32F429 microcontroller.
Until recently, the Numworks had an open-source operating system and I had half-hoped that it might spark a renaissance of handheld calculators.
The hardware is available and pretty nice, but they’ve closed the source code license, so I don’t think it will see any grassroots adoption by the calculator scene.

But no matter the platform, the steady stream of bored nerds in high school cannot be quenched, and they will have the support of smart engineers with free time.
In the true hacker spirit, I suspect people will continue to push the boundaries of whatever hardware they find in their hands.