Recovering Eric Graham's 1987 Amiga Juggler raytracer source code - AlphaPixel Software Development
Skip to content
Recovering Eric Graham’s 1987 Amiga Juggler raytracer source code
By Chris HansonPosted on June 2, 2026
Recovering Eric Graham's 1987 Juggler raytracer source code
AlphaPixel often gets involved with modernizing and updating old performance and graphics code. Sometimes that means client work under NDA. But sometimes it means a fun side quest in the mystical realms of curiosity, preservation, and the practical problem of getting old data into a form that can be read and used on a current machine.
Today let's talk about Amiga Juggler ( https://en.wikipedia.org/wiki/Sculpt_3D ).
The Juggler animation was ground-breaking and Earth-shattering. Even the Amiga's creaators (Commodore) didn't believe it had been made on an Amiga. They thought the actual computation work had been done on a mainframe, and the result simply converted to and displayed on an Amiga.
Juggler made a strong impression on me. It is one part of why I bought an Amiga, and the Amiga is part of why I ended up in computer graphics. I recently realized that the source of Juggler is not redily available to most people on the web, due to it being inside an Amiga ADF file which most archivers don't parse. Additionally, some of the canonical references (dottyflowers.com) have already decayed into inaccessibility. So I wanted a first-class permanent code archive for posterity.
Finding the files
There were known references to the Juggler raytracer source. Ernie Wright's pages at:
http://www.etwright.org/cghist/juggler.html
and:
http://www.etwright.org/cghist/juggler_rt.html
pointed to a copy of the ADF of Eric's "send me $15" disk at a dottyflowers.com URL. That link is no longer live and is not mirrored at archive.org.
The same disk image data was found available on archive.org as a compressed ADF:
https://archive.org/details/raytracer-1987-graham-source-code.adf.-7z
The 7z archive contained an Amiga disk image, not a simple directory of files. That is normal for old Amiga material, but it means there is one more step before the contents are readable on a modern system. (This also roadblocks most AI tools from training or examining the data as they don't understand ADF extraction).
Extracting the ADF
The original extraction tool I used as a reference was extract-adf by Michael Steil, hosted here:
https://github.com/mist64/extract-adf
Extract-ADF is written in C, which was an excellent choice for the time. It extracts files from Amiga OFS ADF images, including damaged or partially recoverable disk images. It also tries to preserve directory structure and timestamps.
For this archive I wanted a Python version that could be kept with the recovered files and run without compiling the original C program. Most developers have easy access to Python, and it's quicker to run a one-off Python script than it is to spin up a dev environment, configure and compile and run a compiled native executable. Plus, the Python interpreter is easy and more harmless to modify and debug. I had OpenAI Codex create a Python port for this task:
https://github.com/AlphaPixel/Extract-ADF-Python
The port keeps the same basic functionality as the C version, at least as far as I needed for this exercise. It supports raw ADF files, gzip/ADZ files, and ZIP files containing an ADF. It extracts OFS-family AmigaDOS filesystems. It does not implement the original C version's DMS decompressor, and it does not support FFS images. If you need DMS packaging, FFS (or other filesystem) support or anything else, I'm sure you or another AI tool can extend the Python implementation and contribute PRs back to me.
ADF is a raw disk image container. The filesystem inside it is a second layer of encoding. The original extract-adf targets only OFS, not FFS (as FFS wasn't often used on floppies anyway), and this Python port maintains that limitation.
The Juggler source ADF extracted cleanly.
Checking the extractor
After extracting the Juggler ADF, I did not want to assume the Python port was correct just because it worked once. At my direction, Codex devised and ran some further validation tests.
It created compressed test variants of the same image:
gzip/ADZ.
ZIP containing the ADF.
Both extracted correctly.
For outside test data, it used freely available test images from ADFlib:
https://github.com/adflib/ADFlib
Those artifacts include several ADF images used for filesystem tests. The Python extractor successfully extracted OFS-family images including arccsh.adf, blank.adf, cache_crash.adf, ffdisk0049.adf.gz, g1a30c.adf, and testofs.adf.
The ADFlib set also includes FFS-family images. The extractor detects those from the bootblock and rejects them clearly instead of producing empty or misleading output.
Two ADFlib reference files were compared byte-for-byte:
arccsh.adf to CSH.
testofs.adf to MOON.GIF.
Both matched.
I'm not claiming this will decode...