Retro game enthusiasts know that the key to the retro games experience is the constraints that programmers had to work around to write games on older hardware. As they say, an animal is most dangerous when cornered; and it is precisely when we are restrained by hardware can we realize our vision in the most creative way possible.

Each system has it's fingerprint; From the 128 bytes of RAM on the Atari 2600 to the register pressure of the 6502, to the superscalar sprites of a Sega System 32; it is the particular set of restraints that hardware places upon us that most strongly evokes the feel of retro gaming. These are not arbitrary restraints like “128×128 graphics” or “32 colors”, but they had real meaning, deriving from the hardware of the time.

This guide explains how to constrain the SD-8516 to era-authentic specs. Now your games will not merely be awesome – they will be awesome and they will look and feel exactly like in your vision, in your dream.

The cheat sheet:

For pre-1982 hardware (Atari 2600, ColecoVision, Intellivision, VIC-20), drop the speed to 0.3 MIPS and follow that system's RAM and cartridge budget. Use only CORE-I and CORE-II opcodes, and only use the KERNAL for memory-mapped I/O. Don't use the PPU or the APU.

These are all based around a 6502 and 64k to 128k RAM. But the big issue is the ability to package games on cartridge. The Apple ][ didn't have carts but was a higher end machine in other ways. For everything else, you need to increase the RAM to match the cartridge.

The reasoning: the SNES had 128k RAM but several megabytes of cartridge ROM, so 1MB is a fair budget for period-accurate games – depending on the cart. Games like Chrono Triger came on 4mb cartridges, so if you have to load in from disk and do extra processing, the extra MIPS will help with that, but 1mb should be enough to port a game like Chrono Trigger. On the other hand, games like Street Fighter Alpha II really needed the fast RAM access. They even came with special co-processor chips to stream data in as fast as possible. For games like this you might even want to bump the ram to 2mb or 3mb. It's in cases like this that the 8 MIPS will really pull it's weight. But for most SNES titles, 5 mips and 1mb ram will be more than enough.

The 8 MIPS rate will also account for the PPU and ASU running in parallel on real hardware; the SD-8516 emulates everything on a single thread, including user input, so the CPU has to work harder to keep things smooth.

The four tiers above are calibrated to reproduce the look and feel of their eras as closely as a single-threaded emulator allows. The logic for the post-SNES era is the same. If you want to emulate a PS1, which is 30 mips, you might need 40, 50 or 60 mips to keep up. The same with a PC style game like Doom. Whereas a ~50 MIPS 486 or Pentium could run Doom at 30fps, you would need more like 90 MIPS to run it on the SD-8516; there is simply no 3d emulation, and you would need to do it in software.

The N64 is the theoretical upper limit; and then, only if 3d acceleration was enabled, and I don't plan on adding it. This machine is intended for the pre-3d acceleration era, and the N64, much like the PS1, was a polygon machine. In terms of 2d/2.5d however, the SD-8516 has you covered.

The first thing you can consider is limiting the system speed (or increasing it) to match your era.

INT $19, AH=$02 sets the CPU rate. B holds the desired speed in MIPS × 100.

  LDAH $02
  LDB #128         ; 1.28 MIPS
  INT $19

  LDAH $02
  LDB #1           ; 0.01 MIPS = 10,000 instructions/sec
  INT $19

  LDAH $02
  LDB #1250        ; 12.5 MIPS
  INT $19

  LDAH $02
  LDB #12500       ; 125 MIPS
  INT $19

Values above 65000 are “unlocked.” This will probably matter around 2050, by which point we'll be on the SD-9532.

Two reasons. First, era-authenticity: many original games had no frame timer because the hardware was the timer. They ran as fast as the system could go, and that was the gameplay speed. Writing under the same constraint reproduces that feel.

Second, discipline. If the CPU is too fast, you lean on speed instead of writing tight code. Era-authentic games came from era-authentic constraints. Run at 1 MIPS and the constraints write themselves.

The system boots with 4 banks of 64k each — 256k total — laid out as:

• Bank 0: free space (64k)
• Bank 1: KERNAL
• Bank 2: framebuffer
• Bank 3: audio

If you don't use a graphics mode and don't call any KERNAL functions, you can reclaim most of banks 1, 2, and 3 — though a few KERNAL-space addresses (the keyboard buffer, for example) are written by hardware regardless. Realistic budgets:

• Text mode without KERNAL: 192k usable across banks 0, 2, 3
• Mode 3 (graphics): 128k across banks 0 and 3
• C64 / Apple ][ feel: just use bank 0 — 64k is plenty
• Tighter (16k–32k programs): swap to disk for anything larger, or take the 64k

For Amiga/PC- or SNES-era games, request more RAM. 1MB is appropriate for SNES-tier work, 4MB is a safe upper limit, 8MB gives breathing room. Above 4MB and you start losing the era-authentic feel.

INT $19, AH=$05 grows system RAM. B holds the desired total bank count.

  LDAH $05
  LDB #16          ; grow to 16 banks (1MB)
  INT $19

RAM can grow up to 256 banks (16MB, the 24-bit address ceiling). It cannot shrink. Request only what you need — megabytes of RAM on an Atari 2600 emulation is a tell.

For early consoles, don't use either. At 1.28 MIPS, software sprites are fast enough for the microcomputer era; if you do use the PPU there, cap at 8 sprites of 16×16 or smaller.

For NES/SNES-era games: 64–128 PPU sprites, ASU at 4–8 channels.

For early 32-bit and N64-era games: up to Neo Geo levels — 200–400 sprites, 16-channel ASU. Beyond that you've left the era.

• Modes 1, 2, 6 — text. Use for early OS-style and bsdgames-style terminal games.
• Mode 3 (320×200×16) — C64 / Apple ][ era. For 160×200, write two pixels per byte by poking the same nibble into both halves (color 2 = $22, color 9 = $99). For 160×100, write each pair of Y rows together — close enough to Atari 2600 / Intellivision.
• Mode 4 (256×224×256) — SNES era. For ColecoVision or NES feel, restrict yourself to 16 colors.
• Mode 8 (128×128) — a Pico-8 nod. Workable for early-console-style games.

VGA- and N64-style modes are on the roadmap.

Appendix 4 Instruction Set Architecture groups every instruction into four tiers:

• Core-I
• Core-II
• Extended
• CISC

For early console games, Core-I only. For 80s microcomputer games, Core-I and Core-II. Extended adds quality-of-life — indexed addressing, auto-stepping loads and stores — and several Extended opcodes compact 3–5 steps into one.

CISC is the dangerous tier. CVTAN, CASE, SKPC, INSQUE and friends roughly double the system's effective power: jump tables, tokenization, and ATOI/ITOA become trivial. They're tempting. Avoid them on systems that didn't have anything like them. The SD-8516 already has effectively single-cycle MUL — it's dangerously fast for retro work without piling more on.

To produce a period-accurate game, a de-make, or anything with the genuine feel of its era, work inside the era's constraints — not arbitrary ones, the real ones:

• The right graphics mode
• The right RAM budget
• The right CPU speed
• The right level of PPU and ASU use
• The right ISA tier

Constrain the system, and the era follows.