We know the TI-99 and Tomy Tutor are related. We just don’t know how.


The TI-99/4A arrived in 1981. Tomy introduced the Pyuuta (ぴゅう太) in Japan in 1982, followed by the American Tomy Tutor in 1983. They came from different companies, served different markets, and belonged to separate software ecosystems.

Yet they share one wonderfully misleading physical detail: a TI-99 cartridge fits perfectly into the Tutor’s cartridge slot—even though the electrical pinout is completely different. Mechanically compatible, electrically incompatible.

The connection goes much deeper than the cartridge shell.

In 2020, AtariAge user KL99 (Klaus Lukaschek) turned a community disassembly thread into a public investigation of the Tutor’s software ancestry. He did more than identify similar commands or programming style: he adapted preserved TI Extended BASIC source files to assemble at the Tutor’s memory locations, removed the portions that were absent from the Tomy implementation, and compared the resulting binary directly against the Tutor ROM.

The result was a continuous match from addresses >9029 through >B90F: approximately 10.5 KiB of Tutor BASIC reconstructed from minimally modified TI Extended BASIC source code. That provides reproducible evidence of direct code ancestry between the two systems, although it does not answer whether the code was licensed, transferred through a development partner, or obtained through some other arrangement.

KL99 also recorded a video presentation explaining the discovery. Its current location has not yet been recovered; when found, it will be linked here alongside the original thread and source comparison.

What we still do not know is how that relationship happened.

No internal Tomy Japan engineering records, source archives, licensing agreements, or design documents are publicly available. What appeared to be a collection of original Pyuuta development documentation surfaced once in a Japanese auction, but the winning bidder never released it. Until those records reappear, the exact path from Texas Instruments to Tomy remains an intriguing gap in computer history.

We know the machines are related. We can prove that they share both architectural ideas and software ancestry. What we cannot yet prove is whether Tomy licensed TI technology, collaborated with TI or one of its partners, inherited an abandoned design path, or arrived at the final machine through some other arrangement.

That mystery is part of what makes this project so compelling.

Hardware background


The relationship is visible in the silicon:

These are not identical computers, but they speak closely related hardware dialects.

That similarity creates an unusual opportunity: instead of emulating an entire TI-99/4A, could we rebuild only the missing environment and allow TI software to run through the Tutor’s real CPU, video, and sound hardware?

The answer became Tutor TI Compatibility 3.0.

It is a 16 KiB replacement BIOS that bridges the differences in firmware, memory layout, cartridge services, GPL execution, keyboard and joystick input, video access, sound, and timing—allowing selected TI-99/4A cartridges to cross onto a real Tomy Tutor/Pyuuta.

This is not a complete TI-99 emulator. The idea is to reuse everything the machines genuinely have in common and translate only the parts that differ.

Watch the TI Demonstration running on physical hardware:

https://www.youtube.com/watch?v=G_nsBboMJFg

The hardware trick

Two boards form a matched system:

TI GROM is serial memory with 6 KiB of useful data in each 8 KiB logical slot. The cartridge contains ordinary parallel EPROM instead. The build tools remove each unused 2 KiB tail and pack as many as four GROM payloads into its 24 KiB ROM space.

The module still requests familiar logical addresses such as >6000, >8000, >A000, and >C000. The compatibility BIOS silently translates every virtual-GROM read into the correct physical EPROM byte.

What the BIOS has to impersonate

The ESE compatibility core implements the behavior cartridge software can observe:

The launcher is data-driven. Cartridge names and GPL entry addresses are read from standard module headers rather than compiled into the BIOS.

The especially strange part: native TI code can cross too

Some TI cartridges contain TMS9900 machine code in addition to GPL. Because the Tutor’s TMS9995 belongs to the same CPU family, suitable code does not need instruction-by-instruction CPU emulation, but it does require relocation and hardware adaptation.

The experimental mixed-module path keeps the original GPL front end, relocates compatible native code into spare cartridge ROM, and connects it to stable Tutor services through the TTBI/TTEX extension interface.

Tombstone City is the first physical proof of this GPL/native method. A speechless Parsec port has reached sustained emulator gameplay and is the next physical-hardware stress test.

What works today

The current RC6 hardware candidate has physically exercised:

PHM3031 The Attack remains a diagnostic case and is not qualified.

Automated smoke tests also boot additional pure-GROM modules, but a bounded boot test is not being presented as complete gameplay qualification.

More physical-hardware demonstrations:

Why make this?

This project is part compatibility layer, part digital archaeology, and part preservation experiment.

It asks a fun question:  can a cartridge cross into a computer it was never designed for?  Then, it answers with memory maps, disassembly, bus behavior, test ROMs, traces, physical EPROMs, and a great deal of exact failure analysis.

The broader goal is a reusable service layer, not a pile of game-specific patches. When a module exposes a missing GPL instruction or console contract, the shared implementation is corrected and the complete regression suite is run again.

Everything original to this project, including source, architecture notes, conversion documentation, compatibility records, tests, traces, and build tools, will shortly be available here:

https://github.com/hexbus/ESE-TI-Compatibility

Most documentation is there now, but the scripts and other code will follow after I have a chance to clean them up.

What comes next

If you enjoy TI architecture, obscure Japanese home computers, GPL/GROM internals, firmware archaeology, or making four-decade-old computers do something they were never supposed to do, follow the project, and bring any contributions with you!  I would prefer not to do this on my own!