The throughput problem

The Super Nintendo master clock is 21.48 MHz (derived from 21.477272727272...). Normally, everything you do from the SNES derives from the clock speed. Super FX speed is 21.48 MHz. SA-1 speed is 10.74 MHz, which is 21.48 MHz / 2. FastROM speed is 3.58 MHz, which is 21.48 MHz / 6, etc.

Let's say I would like to make my own 3D game or a special 2D rendered game, via a frame buffer. In other words, instead of using the SNES PPU core, I'm gonna render the game using the SNES, SA-1 or Super FX CPU.

Disregarding the V-Blanking limitations, the internal SNES screen is 256x224. Normally, we can do 192x192.

• A 192x192 screen is 36,864 pixels.
• We normally have 60 frames per second.
• This means we have to draw around 2,211,840 pixels per second.

If we divide the 21.477272 MHz master clock by the number of pixels, we have around 9.71 cycles per pixel. Alternatively, we have 19,42 cycles per pixel in case we want 30 FPS.

Only being able to do 20 operations per pixel to achieve a 30 FPS stable gameplay is way too small.

For the SA-1 chip, this means we can only do 5 operations per pixel, since the CPU runs at 10.74 MHz and the fastest 65c816 CPU opcode requires at least 2 cycles. The fastest store opcode requires at least 3 cycles. The same situation applies for Super FX, with the difference of you being able to use the cache (512 byte acceleration memory cache) which lets you do operations on a single 21.48 MHz cycle.

With so little time available, it's pretty much impossible to use techniques such as z-buffer, texture mapping or matrix transformations, which the latter two usually requires using arithmetic operations (add, subtract, multiply and divide) which are slower than a simple load and store operations.

It's not impossible, of course. Games that relies on polygons without (usually) textures such as Star Fox can spend +- 100 operations for calculating the first pixel of a polygon line and for the rest of the line, we can reuse part of the calculations in a way that we can optimize to only use 5-10 operations per pixel. That's the path for optimizing the game for a better speed which makes the 30 FPS dream patch for the Star Fox not impossible.

Yet, the throughput problem is real for the SNES. The next generation consoles, with CPUs being able to scale nearby 100 MHz with a 32 or 64-bit data bus makes it much easier to deal with pixels than the 16-bit consoles.

For clarifying once again, the issue is not that the consoles are not able to do 3D calculations or projections, the issue is simply that there's too much pixels to be done per second for a satisfactory performance. We could of course make 3D games that runs between 5-10 FPS or have an extremely small resolution (like 128x64) which reduces the thoughput pressure drastically, but it harms the final user experience.

We are lucky that the Moore's law made the CPUs capabilities expand drastically in the 2000s to the point of the throughput problem not being an issue anymore. Still, for who wants an extra challenge, definitely making real-time 3D games for the 16-bit consoles is the way for taking the console limits into the extreme.