I remember the first time I saw Ballblazer, the 1984 game, running on a friend's Atari 800. The split-screen 3d graphics and fast action blew my socks off.

Ballblazer screenshot

Looking back, I get the impression there are some advanced 3d graphics techniques that appear to be used, but that would be either incredibly unique or impossible to achieve on mid-1980s 8-bit computers and consoles. The "rotofoil" players look like 3d polygonal modeling, which I am not aware of being used for any other fast-action 3d games on 8-bits. There were ground-breaking 16-bit games, like Arcticfox and Carrier Command that used polygonal modelling, but these games only managed wireframe 3d when ported to 8-bit machines. Another famous 8-bit game limited to wireframe was Elite. So, Ballblazer seems to be an early 3d standout with its solid, flat-shaded models.

Additionally, the 3d play field shows correct perspective at a high frame rate and looks like texture mapping to me. This almost has to be a programming trick.

Ballblazer was very successful, which led to many ports to other 8-bit systems. To my eye, the original Atari 800 and the Atari 7800 console versions look the best. The C64 version is also pretty true to the original.

How did Ballblazer appear to pull off these advanced 3d rendering techniques for 8-bit micros of the day, especially since all other games using these techniques only appeared on 16-bit systems years later? Are there any tell-tale signs of known programming tricks?

  • 6
    I'm no expert on Atari, but the resolution seems to be quite low. They probably made use of frame swapping to achieve smooth background graphics, and hardware sprites for foreground objects. Elite (on the BBC Micro) could do neither of these since there were no hardware sprites and not enough memory for frame swapping.
    – Mick
    Commented Mar 11, 2017 at 18:49
  • 5
    Carrier Command has filled 3d graphics on the ZX Spectrum (and therefore probably the Amstrad) — youtube.com/watch?v=a1vts4wvw60 . And it's far from alone, e.g. see also youtube.com/watch?v=U5HOQc2BRxE or youtube.com/watch?v=ud3nXIbdJXY ; filled polygon 3d was perfectly achievable on 8 bit computers. Ballblazer isn't real 3d though.
    – Tommy
    Commented Mar 11, 2017 at 22:49

4 Answers 4


There are two elements:

  • The background
  • The sprites

The background is very straightforward:

The vanishing point never changes so you have one graphic with a checkerboard in perspective. That graphic takes 2 bits per pixel so that you have the 2 checkerboard colors and the edges of the field color. It just needs to be the width of the screen + 4 tiles (2 more checkerboard cells and 2 being the edge tiles).

so, if on a given scan line you can see 5 tiles, the line would be like this:

0 1 2 1 2 1 2 1 0

0 being the border color 1 and 2 being the tiles color.

The rest is simply horizontal scroll: since you can, in this example, display 5 tiles at once, when you are on the play field you do a fine scroll until you have moved to the next tile and then you jump back:

let's assume that the visible area is between brackets:


As you can see, you can loop it again and again to make the screen look as wide as you want. Once you reach the virtual edges, you just leave the color 0 be displayed. This is handled for free through the display list since you can change the display address and horizontal scroll registers automatically, per scan line.

The vertical motion is even simpler since it only requires to change the palette every scan line, essentially inverting the colors of the checkerboard pattern. All is needed is a lookup table for perspective and to know when to do the changes as the position determines where you start in the table (which just needs 2 more lines than what is visible as well, exactly the same way as the horizontal motion, since you're looping your start position between the 2 top cells). This can be done through the Atari 800's display list interrupts.

Regarding the sprites, there are stored at different sizes and orientations; knowing that you can double and quadruple their display size horizontally; also you can instruct the DMA to double up every line vertically as well, but this was not commonly used.

You can run your logic in 2d, all you need to do is a projection, which is essentially a division, to find the sprite size; The 6502 can't do divisions but since we're talking about a very simple case here (distance between the camera and the sprite on a single axis.. a subtraction), you can use a lookup table.

The game looks impressive, but it is technically very simple. If anything is not clear, just ask, I'll clarify the post.

  • 5
    Great answer. I've been comparing the various ports using the video: youtube.com/watch?v=_tkwWD_BWWQ. Comparing the C64 and Atari versions, it really looks like vertical scrolling is where the C64 version fails. This makes perfect sense, since ANTIC display list processing is more sophisticated than what the VIC-II interrupts allow. But C64 does well moving in the horizontal dimension, because hardware for horizontal scrolling is similar to Atari's. Of course, the "lesser" 8-bit graphics machines fail in multiple ways. Still like Atari version, even over the ST port.
    – Brian H
    Commented Mar 21, 2017 at 0:15
  • 1
    The Atari 800 and Amiga have the perfect hardware to make this game!
    – Thomas
    Commented Mar 21, 2017 at 0:22
  • 1
    @BrianH if comparing and contrasting, also check out some of the home ports of Space Harrier. They're usually doing pretty much the same thing, except that now the camera is no longer at a fixed height.
    – Tommy
    Commented Mar 21, 2017 at 14:48
  • @Thomas or the other way round, the game was designed to take maximum advantage of the 8-bit Ataris’ capabilities (and the Amiga is the descendant of the 8-bit Ataris). Commented Mar 22, 2017 at 14:37
  • yes, that's a good point; Wikipedia says that the game was Atari 8 bit first, so you're most likely right. I remember two similar games without the horizontal scroll: en.wikipedia.org/wiki/Trailblazer_(video_game) and en.wikipedia.org/wiki/Rainbow_Walker
    – Thomas
    Commented Mar 22, 2017 at 14:40

The gameplay can be implemented without any 3D calculations (or very little, depending on your definition of 3D calculations):

  • The checkerboard never rotates, so it can be drawn using affine segments and fills (y = ax + b); the players never get close enough to the edges (on the goal sides) for the vanishing point to be an issue. The checkerboard isn't texture-mapped, it's drawn using only two colours.
  • The rotofoils are only ever shown in one of three angles, and are constructed with easily-scalable polygons (although "easily-scalable" would probably involve table-based calculations given the 6502's lack of mathematical prowess). The in-game rotofoils are much simpler than those shown in the title screen.
  • The ball is always above the play field and is just a scaled, filled circle.

So basically to draw the 3D effects all that's needed is to figure out the scaling factor given an object's distance to the player. Redrawing the whole screen for every frame wasn't too difficult on the 8-bit Ataris.

Ballblazer's graphics and speed are still an impressive programming feat, but not as impossibly impressive as you seem to think.

  • Simplifying the polygonal modeling problem by limiting rotation to a few viewpoints and precalculating scale factors makes sense. I don't get what you are saying about the play field, though. It constantly rotates and changes to indicate your speed and direction, right? What sort of fast line draw and poly fill is at work there (note the anti-aliasing)?
    – Brian H
    Commented Mar 12, 2017 at 17:24
  • 1
    The play field just shifts left-right, the checkerboard is always built from trapezoids with horizontal lines. (So it would actually be possible to build the display with a line-scanning algorithm, no polyfills involved.) On the original hardware there is no anti-aliasing (see this video), although CRTs would have smoothed things out a little. Commented Mar 12, 2017 at 18:35
  • 3
    To clarify the “shifts left-right” claim somewhat, the angles change, which involves some calculation, but it’s just a “line to the vanishing point” calculation — no 3D matrix multiplication and projection involved. The horizontal lines’ position can probably be determined using the same scaling adjustment as the rotofoil and ball. Commented Mar 12, 2017 at 18:57
  • You can even just store it as a lookup table. For each line, have pre-calculated (i) start value; (ii) slice length, both in a suitable fixed point scheme. At the left, draw (slice length - start value) pixels. Then repeatedly draw runs of slice length pixels until you exit the right. If you want to move the floor 1/16th of a square to the right, run down and add 1/16th of slice length to start value. All just adding and single colour fills. You can even pretty easily difference two frames and do the minimal amount of work to modify an existing draw to the next.
    – Tommy
    Commented Mar 12, 2017 at 23:03
  • The rotofoils were implemented (at least on the C64) as sprites, not polygons. It's unlikely it was polygons on the Atari 800, either.
    – Almo
    Commented Mar 19, 2021 at 22:38

A simpler way of putting the above very good explanations is... they cheated ;)

It's not proper 3D. If it was, you could face and move in something other than the four cardinal directions. Ever wonder why the movement feels so strange? It's because of that faked checkerboard motion as you move around the pitch. And that's the only "rendered" part; everything else is just flat sprites, drawn to look like 3D objects (again, the limited number of directions they can face massively reduces the data load of this precalculation), and moved and scaled by the machine's hardware (or on other platforms, just by CPU horsepower) on top of the playfield.


While all these answers make up part of the reason for the great screen refresh rate, there is one big item that actually makes the game work so smoothly, blitter chip. The 'Ballblazer' cartridge was unique out of all the carts that were produced. It was the only cart that had this chip incorporated into it. The blitter chip is/was basically a graphics processor unto itself, so the game would send the data to this chip and continue working as the blitter would process the info and manipulate it for the screen. That is it in a VERY basic form. This chip is used in a couple Full standing coin-op arcade machines that I repair. 'Robotron', 'Bubbles', 'Stargate', 'Sinistar' and 'Splat' from Williams Games all used this blitter chip. Unfortunately this great chip is no longer available so these games are not repairable if the blitter chip dies.

  • This is very interesting; do you have any references to further information on this? A cartridge teardown would be great, as would information about the chip itself indepndent of its use in this cartridge.
    – cjs
    Commented Nov 17, 2019 at 16:59
  • 2
    This is quite interesting, but the only references I find online about a custom chip in the Ball Blazer game is actually the Pokey chip, for handling sound. It looks like the blitter chip was integrated not in those cartridges but starting with the Atari Mega ST 2 (see en.wikipedia.org/wiki/Blitter and en.wikipedia.org/wiki/Ballblazer ). That's what I found online at least, I don't have the cartridge myself.
    – ChatterOne
    Commented Nov 18, 2019 at 8:07
  • 4
    Also it was released on tape and disk in Europe, no blitter then.
    – Alan B
    Commented Nov 18, 2019 at 12:07
  • 1
    Hopefully even more definitively to put a nail in this coffin, see the Atari 8-bit cartridge pinout e.g. here. There is no physical way for a cartridge to become a bus master; it is impossible for an Atari 8-bit cartridge to include a blitter.
    – Tommy
    Commented Aug 17, 2022 at 15:47
  • 2
    The Atari 800 version was not a cartridge, so no possible blitter chip added for the game on that platform. However, the Atari 7800 version was a cartridge and did include a Pokey chip for sound, but that was its only purpose and all graphics were handled with the 7800's native capabilities. IIRC, there was never a 2600 version.
    – bjb
    Commented Aug 17, 2022 at 17:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .