Star Fox should not exist. Not in the mystical sense—in the arithmetic sense. A 1993 Super Nintendo cartridge had to produce a moving 3D scene using a coprocessor that, in its first shipping revision, ran at roughly half the clock speed of the chip that followed it. The interesting question is not whether the result was impressive. It is what the frame budget actually looked like, and which wall the frame rate hits when it falls.
This is a budget model, not a capture log. No original frame-time measurements are presented here, because none were available for this piece. What follows is built from documented hardware behavior and labeled reasoning—the kind of model a tinkerer can test with a logic analyzer and a high-speed camera, rather than a verdict handed down from a spec sheet.
What the Super FX actually is
The Super FX is a coprocessor on the graphics support unit (GSU) added to select SNES cartridges, primarily to facilitate advanced 2D and 3D graphics. It was designed by Argonaut Games, which co-developed Star Fox with Nintendo specifically to demonstrate the polygon rendering the chip made possible (Super FX, Wikipedia).
Architecturally, it is typically programmed as a graphics accelerator: it draws polygons into a frame buffer in RAM sitting adjacent to the chip, and that buffer is periodically transferred into the console’s main video memory via DMA so it can be displayed. That two-stage path—render to local buffer, then shovel the buffer into VRAM—is the spine of the whole frame budget.
The core is small and specific. Per the SNESdev wiki, the Super FX has 14 general-purpose 16-bit registers, 98 instructions, and a 512-byte cache (SNESdev Wiki: Super FX). That cache figure matters more than it looks. A 512-byte instruction cache is not a luxury; it is a constraint that makes instruction mix and code locality part of the performance story, not an implementation detail.
The clock, and the revision that changed it
The first version of the chip takes a 21.4 MHz signal but divides it internally to 10.7 MHz. The later GSU revision reaches 21 MHz. All versions are functionally compatible at the instruction-set level; the differences are packaging, pinout, and internal clock speed (Super FX, Wikipedia).
Star Fox‘s cartridge is listed with the Mario Chip at 10.5 MHz (21 MHz / 2), 8 MBit of ROM, and 256 KBit of work RAM. That is the launch configuration—the slow one. Later Super FX titles shipped on faster silicon and, in some cases, larger ROM and work RAM. The chip in the Star Fox box is the constrained case, and any honest frame-budget discussion has to start there.
The SNES-side wall: VRAM is not always open
Here is the constraint that turns a compute problem into a scheduling problem. On the SNES, all video memory can be accessed only during V-Blank or forced blank. Video memory is not mapped to the CPU bus; it is reached only through I/O ports, and larger transfers are usually done via DMA (fullsnes, nocash SNES hardware specifications).
Read that again in the context of the Super FX pipeline. The GSU can render whenever it wants, into its own adjacent RAM. But the handoff into VRAM has a window. The frame buffer does not become visible because the GSU finished drawing; it becomes visible when the DMA transfer lands inside the permitted access period. Compute and transfer are serial costs sharing one frame.
Building the budget model
Treat each displayed frame as three serial costs:
- GSU work: transforms, polygon setup, and rasterization into the adjacent frame buffer.
- Frame-buffer DMA: moving that buffer into SNES VRAM inside the V-Blank or forced-blank window.
- Main-CPU and PPU overhead: everything the 5A22 and the PPU must do around the transfer—game logic, sprite and background setup, HUD, audio communication.
All three have to fit inside the time between one displayed frame and the next. The clock divider sets the ceiling on cost one. The V-Blank-only VRAM access rule sets the ceiling on cost two. Neither is negotiable by clever coding; both are hard walls. This three-part model is my framing, not a documented Nintendo budget—but it follows directly from the documented hardware behavior above, and it is the model I would hand to anyone instrumenting the cartridge.
Where the frame rate breaks
If the model is right, frame-rate drops should correlate with whichever cost grows first. Three candidates, each testable:
Cache-hostile scenes. With a 512-byte cache, a scene that forces the GSU through a wider or less local instruction mix pays a penalty that raw polygon count does not capture. A tinkerer should expect drops to track code behavior, not just object counts. This is a hypothesis, not a measured result.
DMA contention. The frame buffer has to cross into VRAM during a restricted window. If the transfer is large or the window is crowded by main-CPU work, the handoff becomes the binding constraint even when the GSU has cycles to spare.
Main-CPU overhead. The 5A22 still has to run the game. On a cartridge with 256 KBit of work RAM, the main CPU and the GSU are sharing a small, fixed resource pool, and the main CPU’s own work does not pause while the coprocessor draws.
Which one binds first is an empirical question. The model tells you where to look; it does not tell you what you will find.
Budget triage: polygons where they matter, bitmaps where they don’t
The most instructive thing about Star Fox‘s rendering is what it refuses to render in 3D. The game uses the chip for hundreds of simultaneous 3D polygons, but it uses scaled 2D bitmaps for lasers, asteroids, and other obstacles, while ships are rendered as 3D polygons (Super FX, Wikipedia).
Read that as budget triage rather than a technical compromise. GSU cycles go where silhouette and motion read as three-dimensional—the ships you are chasing and dodging. Scaled bitmaps cover the elements where a flat sprite under motion is indistinguishable from geometry at the speed the game moves. That is not a shortcut born of weakness; it is a designer spending a scarce resource where the player will notice. The chip earned the compliment; the cartridge earned the constraint.
The natural experiment: Super FX 3
There is now a way to probe the compute-bound-versus-transfer-bound question directly. An emulated Super FX implementation written by Randy Linden, dubbed “Super FX 3,” runs on a Raspberry Pi RP2350 inside a 2025 physical re-release of Doom for the SNES, at 150 MHz, replicating Super FX functionality with improvements such as a higher frame rate. A later ROM hack of Star Fox takes advantage of that implementation (Super FX, Wikipedia).
This is a natural experiment, and it should be treated as one. If raising the effective clock lifts the frame rate substantially, the original was compute-bound and the GSU work cost dominated. If the frame rate barely moves, the DMA/V-Blank window was the binding constraint all along. The existence of the hack does not settle the question; a measured comparison would. No such measurement is presented here, and any claim about the hack’s specific frame rate would be unsupported.
What a tinkerer should actually measure
The model is only useful if it produces a measurement plan. Four things would confirm or refute it:
- V-Blank duration and DMA transfer size per frame. Bound the transfer window and see how much of it the frame buffer consumes.
- GSU cache-miss proxies. Instrument or emulate the instruction stream and look for correlation between cache behavior and visible slowdowns.
- Frame-time captures on original hardware. High-speed camera or emulator frame-step, to establish where the frame rate actually drops rather than where it looks like it should.
- A direct comparison against the Super FX 3 hack. Same scenes, same camera path, two clocks. That is the cleanest test of which cost binds.
Until those captures exist, the honest position is that Star Fox ran because Argonaut built a small, cache-sensitive RISC core, put a frame buffer next to it, and scheduled the handoff into a VRAM window that the SNES would not open on demand. The frame rate breaks where one of those three costs outgrows its share of the frame. Which one breaks first in any given scene is a question for a logic analyzer, not a spec sheet.
FAQ
Did the Super FX run at 21 MHz in Star Fox?
No. Star Fox‘s cartridge is listed with the Mario Chip at 10.5 MHz (21 MHz / 2). The later GSU revision reaches 21 MHz, but that is not the chip in the launch cartridge.
Why does the frame buffer have to be transferred by DMA?
Because SNES video memory is not mapped to the CPU bus and can only be accessed during V-Blank or forced blank. The Super FX draws into adjacent RAM, and that buffer reaches the display through a DMA transfer into VRAM inside the permitted window.
Is the frame rate limited by the chip or by the transfer?
That is the open question. The model says it depends on which cost grows first—GSU work, DMA transfer, or main-CPU overhead. A measured comparison between original hardware and the Super FX 3 implementation would answer it; no such measurement is presented here.
Why are asteroids and lasers 2D bitmaps if the chip renders polygons?
Budget triage. The GSU renders ships as 3D polygons and uses scaled 2D bitmaps for lasers, asteroids, and other obstacles—spending cycles where three-dimensional silhouette and motion matter most.
