Rungler Synthesizer auf Game Boy in Assembler

Game-Boy-Synthesizer: Den Rungler in Assembly bauen

Entwicklung eines Software-Synthesizers für Game Boy (DMG/CGB), inspiriert von modularer Synthese und Sequenzierung. Das Projekt startete mit der Emulation des Rungler-Schaltkreises – ein Design von Rob Hordijk mit zwei Oszillatoren und einem Schieberegister für chaotische Modulation. Umgesetzt in Sharp SM83-Assembly, getestet ausschließlich auf BGB- und SameBoy-Emulatoren.

Hintergrund und Inspiration

Die Idee entstand nach der Entdeckung der Arbeiten von Ess Mattisson: sein Ein-Spur-Jam auf dem Dirtywave M8 und das Junior-Plugin für 4-Bit-Synthese à la LSDJ. RetroPlug erlaubt es, einen Game-Boy-Emulator als VST mit MIDI-Steuerung in die DAW einzubinden. Ziel? Chaotische Klänge – Piepston, Blubs und Rauschen – aus der Game-Boy-APU zaubern (4 Kanäle: 2x Puls, Welle, Noise).

Rungler-Schaltkreis: Zwei Oszillatoren, wobei einer einen 3-Bit-Linear-Feedback-Shift-Register (LFSR) triggert. Sein Ausgang (0–7) moduliert die Frequenzen der Oszillatoren. Chaostheorie live – winzige Parameteränderungen erzeugen völlig unterschiedliche Klänge.

Technische Möglichkeiten des Game Boy

Zerlegung der APU und CPU zur Machbarkeitsprüfung:

• Schieberegister: 8-Bit-Byte mit Bit-Operationen (Shift, OR). Einfach umzusetzen.
• Oszillatoren: Kanäle 1–2 (Puls mit Duty Cycle). Frequenz ab 64 Hz, plus Counter für Downsampling. Kanal 1 mit Sweep.
• Modulation: Schreiben in Audio-Register (z. B. $FF17 für CH1-Volumen). Keine Hardware-Multiplikation – stattdessen Bit-Operationen. Volumen: 4-Bit (0–$F). Frequenz: NR13/NR14, angewendet am Frame-Ende ohne Retrigger.
• Oszillatoren auslesen: Nur auf GBC (undokumentierte Register), unterstützt von BGB/SameBoy.
• UI: Sprites in VRAM, VBlank-Unterbrechung (~60 Hz, 4560 Zyklen) für Updates. Kachelbasierte Grafik bei 160x144.

Echtzeit-Fallen: Retriggern verursacht Klicks; Frequenzmodulation ist sanfter.

Assembly-Entwicklung

Tools: RGBDS + VSCode-Plugin. Warum Assembly statt C? Echtzeit-Optimierung – Analyse fremder C-Codes zeigte massives Inline-Assembly.

Haupt-Herausforderungen:

• VBlank-Timing: Logik in Unterbrechung, unter 1500 Zyklen (Profiler-geprüft). Überläufe verursachen Tearing (Bildmüll).
• 16-Bit-Rechnung: Manuelles Jonglieren mit A-Register, Carry manuell tracken.
• Bit-Operationen: Kein Mul/Div – Lookups oder Shifts/OR/XOR.
• Speicher: VRAM-Schreibvorgänge nur während VBlank (Scanlines 0–153).

Einstieg: Tutorials, Pandocs, KI-Hilfe für „Hello World“. UI: Cursor, Parameter (Frequenzen, Modulation), reaktive Updates.

Umsetzung und Einschränkungen

• LFSR-Logik: Getriggert von osc1, gegatet von osc2 für Input. 3 Bits → DAC (0–7) → Skalierung + Bias → Register.
• Sequenzierung: LFSR für Trigger, periodische Retriggers.
• Optimierungen: Bildschirm löschen, Cursor zeichnen, LFSR-Visualisierung. Profiler sichert sichere Zone.

Ergebnis: Kein vollwertiger Blippoo Box (4-Bit- und Timing-Limits), eher wie Double Knot. Klänge: Von Puls zu Noise.

Wichtige Erkenntnisse:

• Game-Boy-APU eignet sich für LFSR-Modulation, aber Echtzeit ist durch Retriggers und 4-Bit-Auflösung begrenzt.
• VBlank ist entscheidend für UI (<1500 Zyklen); Assembly essenziell für Puffer.
• GBC-Oszillator-Register undokumentiert, emulatorabhängig.
• Bit-Operationen ersetzen Multiplikation: Genug für Chaos-Effekte.
• Skalierbares Projekt: Wave-CH3, Karplus-Strong als Nächstes.

Zukunftspläne

Als Nächstes: 4-Bit-Synth (CH3-Welle), Karplus-Strong/Risset-Drum, audiovisuelle Performances (à la Robert Henke), Profiler-Debugging, 16-Bit-Rechenlimits ausreizen.

— Editorial Team