Appledog

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
= How to Write Retro Games on the SD-8516

== Introduction
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 "128x128 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:

^ Era ^ Computer ^ RAM ^ Speed ^ Graphics ^ Sound ^
| 1985 | 8-bit computer/console | 256k | 1 MIPS | Mode 1, 2, 3 (320×200, INT 18h) | INT 11h |
| 1990 | 16-bit console/PC | 1MB | 10 MIPS | Mode 3, Mode 4 (256×224), PPU sparingly | INT 11h / ASU |
| 1991 | 32-bit computer | 2MB | 40 MIPS | 640×480 + PPU | ASU |
| 1996 | N64 | 8MB | 125 MIPS | 320×240, 480×360, 640×480 + PPU | ASU |

=== Early Consoles
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 the KERNAL only for memory-mapped I/O, and do not use the PPU or the APU.

== C64, Apple ][,  NES and SNES
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 this but was a higher end machine. But 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 not just came on huge carts but had 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; it's in cases like this that the 8 to 10 MIPS will really pull it's weight.

The 10 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.

== PC Gaming to N64
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. W

== Limit System Speed

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.

=== Why Limit Speed?

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.

== Limit RAM

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.

== How to Add RAM

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.

== Limit PPU and ASU Use

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.

== Choose the Right Graphics Mode

  * 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.

== Bonus: Limit the ISA

[[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.

== Conclusion

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.