When we talk about ‘Retro games’ connoisseurs of the genre, there are actually several very different things we are talking about. Let me see if I can break it down in to eras.

Pre-Microcomputer era; this is really the era of the Intellivision and Atari 2600. This is basically 1975 to 1982.

Microcomputer era; this found it’s stride with the Commodore 64 and Apple ][. Essentially 1980 to 1988.

The release of the Amiga is a gray zone between the above and the ‘Mainstream PC market’ that you would say took over in the late 80s and lasted until 1995.

Finally after some small chaos you have what amounts to the ‘Modern PC era’ which essentially began when Windows ’95 released. It found full stride in 2001 with Windows XP.

What is surprising is when you look back at the power level of the computers at the time, it tells quite a different story. The Commodore 64 was released in 1982. Well, so was the 80286 — a 16 bit machine.

Ultima IV was released for the Apple ][ in 1985. This was an 8 bit game. However, in the same year, the 32-bit 80386 was released. By 1990, the SNES was released; by all accounts it was a 2d powerhouse. In actuality, the SNES was probably 4x to 5x more powerful than a C64 in every conceivable way. This was in 1990. But a year earlier, the 80486 was released.

There’s really a schizm here, as the world split in 1990 between 16 bit and 32 bit computing. Ironically, for a while, 16 bit would win (in terms of games, the SNES had a clear advantage), but the raw power of the 32 bit platform — in 1985 — could no longer be denied.

1985. The same year “Back to the Future” was released, as well as a dozen other iconic movies and a dozen other cult classics.

So really the question is, what is going on here? What is meant by the term “Retro”? I think that it has much less to do with 8, 16 and 32 bit processors and much more to do with RAM and the PPU/GPU. Thus I have broken retro gaming into four main areas.

1. The under 64k era (1978-1988)

This refers to the C64, C128, Apple ][ and so on. This era is dominated by 8 bit processing and 64k usable ram or less. You can include older consoles here, but they almost deserve their own era due to extreme RAM limitations. Often times, the processor was just as good as a 6502, but would have under 4k of RAM. The Atari 2600 famously had only 128 bytes of RAM.

2. The 128k to 640k era (1985-1995)

This era is somewhat deceptive, as it really bridges the 8bit and 16 bit worlds. The Amiga 500 sits squarely in the middle of this era. It ends in with with the release of the 80386 in 1995, when 1MB ram became standard.

People often underestimate the SNES (1990) because it had a modified 6502 and only 128k RAM. But it was a cartridge based system with a very strong PPU and sample based playback. Pound for pound, it could compete with a stock 80386, whose weak point in gaming was no dedicated PPU or audio chip.

3. The era of 1mb to 8mb RAM (1995-)

In 1996 the N64 was released with SGI’s reality engine and 2 to 4mb (up to 8mb with expansion) RAM. This system was approximately 100 times the power of a Super Nintendo and defines the end of an era. While the SNES was a 2d powerhouse and could compete with any PC in gaming at the time, this ended with the release of 3d graphics acceleration.

The defining systems of the era were probably the early consoles, the C64 to Apple II, the SNES alongside the 16 and 32 bit Amigas and PCs, and the N64.

In terms of speed and RAM these are the ideas:

0.5 MIPS and 4-16k ram for early consoles. The difficulty with these are that there is no real OS. I liked those games but they were always a step behind.

a. The “1985” — 1 MIPS and 256k for the C64 to Apple ][ era. This era was defined by RAM size. Not by speed. The reason why the RAM is much larger is that we do not have ROM, a VIC-II, or a SID chip. Everything must be stored in RAM. This approximates what you would normally have with a bit of breathing room. We are not masochists, after all.

b. The “1990” — 5 to 10 MIPS and 1mb RAM for the SNES era. Perhaps even 5 MIPS is a bit fast for this era, but you want to cover some of the faster 680×0 and PC era chips. You also have to understand this is the era of the SNK Neo Geo and Sega System 32, so you want to include some extra speed if you want to explore the arcade side of things.

Why 1mb? Although we have a PPU and APU that offloads from RAM, I might reverse this. But the real reason to keep 1MB in any case is the reality of a cart-based system. Having data on-CART is like having it in memory; in fact with fast ROM enabled, SNES cartridge ROM was often faster than RAM. This is the big misunderstanding about consoles like the SNES; They had 128k RAM, but they had had several megabytes of data in ROM — making the 128k RAM somewhat misleading.

125 MIPS and 4mb RAM for the N64 era. In fact, if you increase this to 8mb you catch the tail end of the 80386 era — the launch of 32 bit. The policy of allowing approx. 2x the performance and RAM to make up for the lack of CDs, cartridges, graphics cards, etc. proves true.

These three eras are the main targets. How can you replicate games of this era?

Use 128×128 mode for anything prior to the C64 era. Use 320x200x16 mode for the C64/Apple ][ era. use 256x224x256 for the SNES era.

The N64 era is very interesting. The internal framebuffer for most games was 320×240. However, it could use up to 640×480 — yet so few games did because it was too demanding on the hardware.

So, final targets?

a) 1.28 MIPS and 256k RAM for the C64/Apple ][ era. This is “Mode 1985”. With 64k taken by video, 64k by ram, there is 64k to 128k of RAM to use, but is hard to use because it is not contiguous. Feels about right.

b) “Mode 1990”. 10 MIPS and 1mb RAM for the SNES era. MIPS feels a bit fast, but you want to cover some of the better PC-era games too and possibly cover for the lack of multitasking (the 286 was released in 1982) — we have one thread to do everything on (including the PPU and audio). Even the SNES, though a single core processor, had its PPU and SPC working at the same time. A kind of multitasking. It may be that 10MIPS is about right!

RAM is the same idea. Accounting for cartridges, 1MB of RAM sounds fair for this era. It’s more RAM, but actually not as much as you would find on some cartridges. The extra RAM helps balance that.

c) “Mode 1996” 125 MIPS and 4mb to 8mb for the N64 era. This is the realistic max power level on today’s hardware. You can see the shift to raw CPU power here for graphics performance; More RAM remained the limiting factor for complexity in gaming. The extra RAM in an N64 mainly going towards graphics, very few games had more depth than those on the SNES. For example, as good as Ocarina of Time was, can we really say it is a “larger” game than A Link to the Past? Well, A Link to the Past has more dungeons, but Ocarina of Time has longer dungeons. In gameplay terms it takes twice as long to go through the dungeons, but it’s not necessarily a “bigger” game. It is bigger, just not by much. Isn’t that interesting?

Now here’s my plan to allow people to funnel themselves into one of the three above camps.

A. Change system speed. There can be different levels. 0.5 MIPS, 1.28 MIPS, 6.4 MIPS, 12.8 MIPS, 40 MIPS, and 125 MIPS. These six speeds cover almost everything in the N64 and previous generations of consoles and computers.

B. Selection by Graphics Mode. There should be 1 or 2 “iconic graphics modes” for every level. So far we have 40×25 and 80×25 text (3 modes), 320x200x16 graphics mode, 256x224x256 graphics mode, and 128x128x16 mode. We need to possibly add: 512x256x256 mode (double bank mode), a 320×240, 480×360 and/or 640×480 mode for the later era.

Those will all be 256 color modes, as we already have too many graphics modes. The 512×256 mode probably isn’t going to be useful. The 320×240 and 480×360 mode are N64 specific. This leads me towards the idea of a configurable framebuffer. I will investigate this.

Finally the choice of audio. Sample based playback opens many doors. However, we do have access to the JavaScript oscillator for free, which covers most of the early era. Sound is the choice of the programmer and falls roughly into those main camps.

Ok, looks like this has been worked out, I’ll put it into a “Replicating Retro Games” tutorial later. Good!

I’m going to use the term ‘Artificial Retro’ here. Not ‘Ersatz Retro’. What’s the difference?

Ersatz retro is like PICO-8. Pico 8 is just a Lua game engine — that’s all. It only allows you to use 16 colors (from a pallette) and it provides access to a 128×128 “screen”. But everything else about it is just part of a game engine. You could do the exact same thing in Python/PyGame by limiting yourself to a 128×128 window and 16 colors.

Artificial Retro is like the Commodore C64U. It’s not based on a 6510. It uses an AMD Xilinx Artix-7 FPGA to run software emulation of the original 1982 hardware. The software does hardware emulation, and it’s very good. No one should complain about that.

Retro?

Somewhere in between there’s this nagging question. The Artix-7 in the C64U has 128MB of RAM, thousands of times more than a C64. It’s many times faster, with some variants being capable of running the emulator at 100x speed.

Just like the SD-8516. We lock the CPU at 4mhz equivalent (4x faster than a C64) but due to the advanced ISA and lack of register pressure it’s already more like 8-10x faster. And if we unlock it, it could be 100 times faster than it is right now.

So the question is, what are we doing? Why are we lowering the speed and introducing artificial constraints? Easy question. When there are constraints placed on the system you get more creative. But what constraints, and why? Constraints become ludicrous when they are packaged with advanced graphics and sound libraries, modern languages and codecs, SDKs, and a very smooth ecosystem. These ersatz retro “consoles” easily outpace high-end mid 90s arcade boards like an SNK Neo Geo without even blinking. What’s the point?

This is precisely the problem I have now with the PPU and APU. Until now, at 4mhz, drawing lines on the framebuffer was a little bit slow. To be honest, just as fast as what you would expect. Perfectly normal and era-authentic.

Yet I started getting frustrated, angry. I wanted to write an ELITE clone. But I wanted to do it in BASIC. Then I realized, I’m the one that set the speed limit in the first place, so why am I complaining that I can’t do what I want? What I really needed to do was learn how to push the system to do what it could do. Not what I wanted it to do. The days of me being able to do whatever I wanted as a game designer needed to end. This was a different world. But I crumbled. I told myself, even an NES has a PPU. Even the C64 has hardware sprites.

So I wrote a PPU. I just wanted to get some decent sprite capabilty. That was the moment I fell from grace. Suddenly we can do 8,000 sprites at 30fps. That’s modern arcade quality, not retro fantasy console. Not even 2000s fantasy arcade. We’re talking stuff that doesn’t even really exist. Namco System 246, Taito Type X, Sega Model 3 / Naomi are basically just PC graphics cards. Polygon renderers. No one does 4000+ sprites a frame. No one. Oh, except fake retro consoles like PICO-8 and the SD-8516. My grandmother would be ashamed. But what can you do?

The original Amiga MOD had 4 voices. A SNES had 8. We can do 2000 without thinking and have a gigabyte of multi-megabyte 96khz samples. But doesn’t something feel off? And here’s the issue, if I introduce artificial constraints, why? Why the constraint?

I think that a good authentic limit to this madness would be to require the programmer to store sprites and samples in RAM. No limit on the codecs or draw speed, just the RAM. A SNES had 128k ram, and 64k each for audio and graphics. The Amiga 500, IIRC, 512k. When you add up what comes on a cartridge — often, even ram expansion — it may be possible to get away with 512k ram or up to 1mb.

Then, maybe, the constraints don’t make sense. You don’t have to use ADPCM because it’s artificially imposed, you use it or you don’t have the RAM for samples. You don’t need to use 4bpp 320×200, but you do, or you won’t have space to store your sprites. You see? You’re constrained by the system. Because it makes sense. Because there is a legitimate hardware reason behind the decision. But if you’re smart, you can play your cards just right and use every square inch of power the system has. And maybe, just maybe, you can make something special.

You see, retro isn’t in a system, like a C64, Amiga, SNES or Neo Geo. It’s not found in 64k ram, 8 bits, or 4mb cartridge limits. Those systems always impressed — but maybe not for the reason you think. Not because of the constraints. But because they made up for the constraints by pushing the system. They made up for it, simply, with great game design. Iconic titles that will never die. Legends of the genre. A lesson to learn, perhaps, the only lesson.

A more powerful system demands more powerful game design to be effective. A more powerful system on it’s own means nothing. If you are not being constrained by the limits of your system, your game design is not strong enough.

The original console games were not great because they were written on constrained systems. They were great in spite of it.

Today, people write games that don’t explore the limits of their system. They have become lazy because there are no limits. So games don’t feel fun anymore. They feel small. Too well animated. But lacking any real depth. They lost the narrative; the SD-8516 is here to bring it back.

Here you will find news and updates regarding the SD-8516. Here are a few sources to get you started:

• The Official SD-8516 Wiki
• The r/sd8516 forum on Reddit
• Fantasy Consoles 2.0 on Discord