Artificial Retro

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.