In the magical mid-1990s, when we already had got our (second-hand) 486 PC and I had both a NES and SNES, I for some reason got my paws on an old Atari "XE Game System" (8-bit, 1987). It had a cartridge called "Flight Simulator II" which was very fascinating to me, even though I was able to run DOOM.

The reason it was so fascinating to me was the way it drew "real 3D" graphics, albeit very primitive wireframe such, and at a very low FPS. I remember sitting there figuring out how to fly around with this virtual air plane and just watching the scenery and being amazed by how that ancient machine could draw such environments which even the SNES seemed to struggle with. Starwing (AKA Starfox) used a special chip in the cartridge and still wasn't as impressive to me, since it was so limited in where you could go. It was "on rails".

In contrast, this "flying game" was really some kind of simulation, where I could explore the 3D world as freely as the air plane would let me move around. Nevermind the fact that there was virtually nothing in it; the few objects that were there were extremely cool to me. In my mind, not at all understanding technical limitations other than "this is quite old", there was a real chance that I could fly away and find some exciting new areas if I just spent long enough watching the screen and making sure the plane didn't crash. There was truly a sense of wonder, even though it was ridiculously outdated even back then.

But wasn't this machine roughly the same in power as a NES? And the NES not only did never get a port of this game/simulation, but had nothing like it that I know of. And, as mentioned, even the SNES (16-bit, next generation) didn't even have this kind of free-roaming simulation. The "Mode 7" visuals were also very cool, but kind of "cheating" and "flat" somehow. And the fanciest 3D games for that console, such as Stunt Race FX, had to use expensive special chips inside the cartridges.

Was there a technical reason for the lack of a NES port of this? Maybe that primitive computer/console was inferior in every way to the NES (not to mention the SNES), but had the one "pro" in that it was able to draw real 3D environments in a way which both failed to accomplish? But why would that be? I find that difficult to believe.

Or was the reason simply that they didn't think the simulation would be fun to play/attractive for the NES audience? I can think of countless NES games that were released which would've been deadly dull to me as a kid -- far more boring than this 3D world, even if I didn't care at all about the fact that it was a flight simulation.

  • 1
    What a great question. Well written, well researched and generating interesting answers. Commented Sep 18, 2020 at 6:50

3 Answers 3


The NES's architecture isn't really ideal for anything that involves all-pixel-addressable plotting such as vector graphics. It's instead strongly optimised for 2d backgrounds made of repeating 8x8 tiles and a small number of sprites on top.

However, there is a NES port of Elite (see here on YouTube), a vector 3d game which is much sparser but faster, and proves the technical capability subject to a bunch of caveats.

The NES doesn't have memory for tiles built in. The cartridge has to provide that memory. In many games it's just ROM; for a vector title like Elite the cartridge instead has to use RAM, which is more expensive, and therefore there's a cost-benefit analysis to be made considering the possible audience.

Elite came out for the NES in 1991 (i.e. a full seven years after its debut on other platforms) when costs will have been a lot lower and the NES had peaked in terms of its audience. It came out only in Europe since American publishers weren't interested.

So I think your guess that there were few 3d vector titles for the NES (possibly no others?) because of assumptions about the audience is probably correct once the additional costs of manufacturing such a title are factored in.

That said, to offer a more thorough comparison:

The NTSC NES has a 1.79Mhz 6502 derivative; the Atari XE is actually almost exactly the same hardware as the Atari 400/800 of the late 1970s and also has a 1.79Mhz 6502. So you would prima facie expect the two machines to be equally good at 3d calculation.

The Atari offers plain bitmapped modes, and from eyeballing it I would imagine Flight Simulator is using a 160px four-colour mode. The NES produces a higher pixel density than that, though it is generally in four colours (subject to different tiles not having to share palettes), so would likely need to draw more pixels. Suppose it wanted to fill its width as the Atari does and therefore probably cover the same amount of a TV that probably requires 256/160 = 1.6 times as much drawing.

That's before you factor in that, unless you've added address translation hardware to your cartridge, the NES is also going to have to put more work into addressing because it needs to think in terms of tile + row.

So the NES was indeed the technically weaker machine for this type of title — drawing would be more expensive in general, and you'd need the cartridge to assist by providing RAM and suitable timing logic.

Other 8-bit computers overcame worse though, and Elite seems to contradict any claim of impossibility.

For other instances of Atari does what Nintendon't, see e.g. The Eidolon, Stunt Car Racer or Way Out (all YouTube links). Stunt Car Racer is a recent port, but it's from the C64 version so it's fully representative of 1980s coding.

Also, the game isn't great, but some programmers were able to do pretty well on the base SNES hardware — no SuperFX or any other acceleration whatsoever. See Race Drivin'.

Potential performance now seems to be a matter under discussion; let's go ahead and assume supercat's ballpark figure of 400 bytes/frame writing to a hypothetical cartridge-with-a-framebuffer is accurate.

I looked at:

I manually counted frames for half a minute. They're sufficiently slow that this isn't problematic. Results were:

  • Atari: 35 frames;
  • C64: 23 frames.

So let's call the target 1fps. In each case it's about half the display that's being redrawn.

On a NES, half the display occupies 32 * 112 * 2 = 7,168 bytes.

So — if it were the bottleneck — the necessary framebuffer access speed on NTSC? 7168 / 60 = 119 bytes/frame.

I therefore disagree that there is a bandwidth problem here.

  • Some NES carts with built-in RAM were able to produce bitmap graphics, but the update performance was nowhere near adequate to meet the needs of something like Flight Simulator with graphics that are even as good as a 1970s Apple ][+.
    – supercat
    Commented Sep 18, 2020 at 20:51
  • @supercat I disagree; answer edited to provide the necessary arithmetic.
    – Tommy
    Commented Sep 19, 2020 at 1:36
  • 1
    I thought I remembered performance as being faster than that. That level of performance might be achievable on the NES without doing anything terribly exotic, but bandwidth would still be an issue because of when data would need to get transferred. One would need enough RAM on the PPU to hold two copies of the display so as to prevent partial updates from showing, and one wouldn't be able to start sending the data for a region of the screen to the PPU until all updates on that region were complete. If one used a cart with 32K of RAM on the PPU...
    – supercat
    Commented Sep 19, 2020 at 16:28
  • ...I suppose it might be practical to use a couple of 2K buffers in CPU RAM to hold 32-pixel-high strips of the screen. Render everything in the top 32 pixels to one bufffer, then spend 8 frames sending that at a rate of (assuming extended vblank) about 256 bytes/frame while rendering the next 32 pixels stripe, etc. If the display window occupies 128 scan lines, that would yield a peak frame rate of about 2Hz, but much of the line drawing logic would need to be run four times for each rendered frame.
    – supercat
    Commented Sep 19, 2020 at 16:33
  • 1
    Perhaps something like that might be reasonable on the homebrew scene, though I think one would want custom mapper which would cause the color-select fetches to be taken from different places on alternate scan lines, so as to allow half the scan lines to use one set of four colors while the other half used a different set. The hardware for that wouldn't be hard (recognize tile shape fetches based upon address, and use those to set or clear a latch which would be used to generate a substitute address bit for fetches from row 30 or 31 of the tile map).
    – supercat
    Commented Sep 19, 2020 at 16:48

Making a game like Flight Simulator work with any kind of reasonable frame rate, especially on an NTSC NES, would require using either a dual-port RAM, two RAM subsystems which could be switched between the CPU and PPU buses, or two RAM subsystems along with a means of quickly copying data from one to the other. While the technology would have existed in the 1980s or early 1990s to make such a thing possible, the cheapest way of implementing the display subsystem would have probably been to use two 8Kx8 SRAM chips, twelve 8-bit bus driver chips (three to connect the first RAM chip to the CPU bus, three to connect it to the PPU bus, three to connect the second RAM chip to CPU, and three to connect that chip to PPU), along with a bunch of control circuitry, the cost would have been outrageous, especially considering that doesn't even include the ROM or supplemental RAM needed to run the game logic.

Elite was able to kinda sorta work on European PAL machines because those machines allow the CPU access to the display memory during a relatively long vertical blanking interval. The NTSC machines in the US only allow the CPU access to display memory for a much shorter time each frame. Even insanely optimized display code would be limited to writing less than 400 bytes to the display buffer per NTSC frame. If a program used a 4K display buffer to show monochrome graphics and included a little hardware assistance to facilitate writing every other byte, rewriting the whole buffer would take about ten frames even under insanely optimistic assumptions. And that would be to yield a flight simulator with monochrome graphics inferior to those of late 1970s computers like the Apple II.


If you are satisfied with 64×56 pixel, use my NES driver.

Remember subLOGIC's Flight Simulator 1 for TRS-80 was also lo-res!

You must log in to answer this question.

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