Resurrecting Prodigy’s Dead Graphics Language
November 9th, 2026 by Joe HammondHow a childhood memory, a forgotten online service, and two years of reverse engineering led me to bring NAPLPS back to life.
A before-and-after look at an image translated into NAPLPS format.
[ Please welcome Joe Hammond, a graphic designer and amateur software developer who has spent the past couple of years reverse-engineering NAPLPS — the graphics language that powered PRODIGY — so that authentic new NAPLPS files can be created again. Below, he tells the story of how a childhood memory turned into one of the deepest technical rabbit holes he’s ever fallen into. –Benj ]
Every programmer has a moment that starts it all.
For me, it was PRODIGY.
When I was a kid, my father subscribed to PRODIGY. At the time I didn’t appreciate what he had really given me. To me it was just this incredible place that existed inside our computer. I could play games, read news, send messages, and explore. The modem would shriek while it connected, and moments later this colorful world appeared on the screen.
Those afternoons sitting in front of that monitor with my dad were my introduction to technology. Looking back now, I can honestly say that without those experiences I probably wouldn’t have become a software developer.
Thirty years later, after becoming involved with Prodigy Reloaded, I discovered something I never knew as a kid: those graphics I’d spent so much time looking at had a name: NAPLPS.
That discovery sent me down one of the deepest technical rabbit holes I’ve ever fallen into.
The Graphics You Never Knew You Were Looking At
If you used PRODIGY during the late 1980s or early 1990s, you’ve seen NAPLPS, even if you’ve never heard the name. It rendered colorful, blocky artwork that was efficient to download over the low-speed modem links of the day.
NAPLPS — North American Presentation Layer Protocol Syntax — grew out of Canada’s Telidon project and became the graphics language that powered services like PRODIGY. Instead of sending images, it sent drawing instructions: set a color, draw a polygon, place some text. The terminal reconstructed the picture locally.
At 1200 baud, every byte mattered. Sending instructions instead of bitmaps was an ingenious solution to a very real problem, but as bandwidth increased and the web arrived, NAPLPS quietly faded into history.
An Innocent Question
When I joined the Prodigy Reloaded project, I simply wanted to make new graphics. Surely there had to be a modern tool for that, I assumed, but there wasn’t.
There were viewers, old editors, scattered specifications, and abandoned software — but no modern pipeline capable of producing authentic NAPLPS that period software would actually accept. That simple question — “Can we still create real NAPLPS today?” — became an obsession and a digital archeology project.
The ANSI specification was helpful, but it wasn’t enough. Specifications tell you what should happen. Old software tells you what actually happens. So I started collecting period tools and opening them in Ghidra. Viewers, graphics editors, BBS communications software, icon converters — anything that still understood the format.
My Rosetta Stone was TURSHOW, a Turbo Pascal viewer from 1993. Reading its opcode decoder revealed details no specification ever documented. I cross-checked those discoveries against surviving DOS-era C source so I could be confident that my encoder would produce files interpreted exactly as software from the early 1990s expected.
Building the Encoder
The format is wonderfully strange by modern standards. Coordinates are fixed-point values with X and Y interleaved and packed across bytes. Colors come from a tiny palette. Every byte has to remain printable because these graphics were designed to survive transmission over text terminals.
Eventually I built a complete toolchain: PNG to SVG to authentic NAPLPS. I also wrote a decoder so every file could be round-tripped back into SVG for verification. Along the way I accidentally built an entire toolkit including a browser renderer, text placement tool, optimizer, and debugging utilities.
But writing for a 1983 graphics system forces you to unlearn modern assumptions. There is no transparency. No gradients. Filled polygons are painted in order. Text isn’t artwork — the viewer supplies the font. Line width is global. Even something as simple as a donut shape can’t have a hole.
An embarrassing amount of debugging came down to a single byte in the header. The limitations weren’t bugs. They were the design language.
Proving It
To prove everything worked, I recreated PRODIGY’s MadMaze “An Ending” screen as a genuine .nap file — not a screenshot, but a file that renders inside TURSHOW running under DOSBox-X exactly as period software expects.
For me, that moment was surreal. I wasn’t just looking at a successful test. I was looking at the same technology that had captured my imagination as a kid, now being spoken by software I’d written decades later.
The biggest surprise I encountered in this project wasn’t technical. I learned that the quality of the source artwork matters more than clever encoding. Automatic vector traces produce tiny sliver polygons that leave visible seams no amount of byte tweaking can eliminate. The artists who created these graphics in the 1980s understood the medium intimately, and after fighting with it myself, I finally understood why they worked the way they did.
When I started this project, I thought I was resurrecting an obsolete graphics protocol. Somewhere along the way, I realized I was reconnecting with the technology that first made me fall in love with computers.
My dad had no way of knowing that bringing home PRODIGY would shape the rest of my life. To him it was simply an online service. To me it became the doorway into programming, software, and eventually a career.
Technology moves fast. Formats disappear. Software is abandoned. Knowledge quietly fades away. Every now and then it’s worth preserving one of those forgotten pieces — not because the world needs it again, but because understanding where we’ve been helps us appreciate how we got here.
If this project has accomplished anything, I hope it’s helped keep one small piece of computing history alive.
Where to Try It Yourself
The encoder, decoder, browser renderer, converter, and supporting tools are available on GitHub: https://github.com/Hmmnd0/NAPLPS-Converter. You can also try out an online image-to-NAPLPS converter yourself here, hosted on Netlify.app.
—–
More writings about Prodigy from Benj Edwards and friends:
Reverse Engineering Prodigy, Part 2 (VC&G, 2021)
Reverse Engineering Prodigy, Part 1 (VC&G, 2021)
Prodigy Reverse-Engineering Tools Released (VC&G, 2017)
Benj’s 1992 Christmas List (VC&G, 2017)
Huge Gallery of Prodigy MadMaze Screenshots Now on Flickr (VC&G, 2017)
Classic Prodigy Game Recreation MadMaze-II Updated to Support Chrome and Firefox (VC&G, 2017)
How 25-year-old Prodigy screenshots got rescued (Fast Company, 2016)
Exploring the Lost World of Prodigy (PCWorld, 2016)
The Prodigy Preservation Project (VC&G, 2014)
Where Online Services Go When They Die (The Atlantic, 2014)
The New Prodigy (Retro Scan) (VC&G, 2014)
MadMaze-II Now Hosted on Vintagecomputing.com (VC&G, 2013)
