Hallo zusammen,
wie sich vielleicht einige erinnern, arbeite ich immer noch an einem vollständigen Disassembly und einer Kommentierung des Vortex F1-X Modul-ROMs (V 2.11-X). Ohne eine laufende CPU, die den Code auch wirklich ausführt, ist das keine leichte Aufgabe. Deshalb habe ich die letzten gut 3 Tage genutzt, um mit der Hilfe von Claude mein eigenes Tool zu entwickeln.
Ich möchte euch CPC X-Ray vorstellen, ein Open-Source-Tool (GPL-3.0), das ich gebaut habe, um CPC-Code zu zerlegen: ROMs, Programme – einfach alles, was auf einem 464, 664 oder 6128 läuft.
Wofür es gedacht ist
CPC X-Ray ist ein Analyse-Tool, das zufällig einen Emulator enthält – nicht umgekehrt. Seine Aufgabe ist es, dir beim Disassemblieren und Verstehen von bestehendem Code zu helfen und daraus einen kommentierten sjasmplus-Quelltext zu erzeugen, der sich wieder Byte für Byte exakt zum Original assembliert. Es führt die echte Firmware, BASIC, AMSDOS und Erweiterungs-ROMs aus und lässt dich alles beobachten, was der Code so treibt:
- Haltepunkte in zehn Varianten – PC, M1, Speicher-Lese-/Schreib-/Zugriffe, I/O In/Out, ROM-Auswahl, Interrupt – mit Bereichen, Portmasken und Paging-Bedingungen
- Ein Befehls-Trace mit Aufruftiefe und geänderten Registern, damit du nach einem Stopp zurückgehen und nachvollziehen kannst, wie der Code dorthin gelangt ist
- Ein Bus-Trace für jeden einzelnen Zugriff (M1, Lesen, Schreiben, I/O) mit Erklärung: welche Firmware-Variable angefasst wurde, was auf den Stack gelegt wurde, was ein Schreibzugriff auf einen Port bewirkt
- Speicheransichten, farblich hervorgehoben nach Firmware- und AMSDOS-Variablen, dem Paging, dem Stack und Firmware-Namen für alle drei Maschinen
- Eine Analyse eines ROM- oder RAM-Bereichs: Code vs. Daten, in den RAM kopierter und dort ausgeführter Code, RST-Aufrufe mit Inline-Daten – woraus dann der Quelltext wird
- Dekodierung verschlüsselter ROMs (das Schema des Vortex X-Moduls, bei dem Opcode-Fetches und Daten-Lesezugriffe unterschiedlich dekodiert werden)
Es verfügt außerdem über einen MCP-Server, sodass Claude Code (Anthropics KI-Coding-Assistent) die gesamte Maschine steuern kann: booten, tippen, Haltepunkte setzen, Einzelschritte ausführen, Speicher sowie Traces auslesen und die Analyse starten. In der Praxis arbeitet man sich gemeinsam durch ein ROM – die KI beobachtet, was der Code zur Laufzeit wirklich tut, und hilft dabei, Routinen sowie Variablen zu benennen und Kommentare zu verfassen.
Wofür es nicht gedacht ist
Es ist kein Allzweck-Emulator und versucht keineswegs, mit WinAPE, ACE, CPCEC und Co. zu konkurrieren – nutzt diese, um Spiele zu spielen und Demos laufen zu lassen. CPC X-Ray spart bewusst überall dort Ressourcen ein, wo es für die Code-Analyse keine Rolle spielt:
- Der Z80 arbeitet auf Befehlsebene: Jeder Buszugriff erfolgt in der richtigen Reihenfolge mit den korrekten Signalen, und er besteht ZEXALL sowie die 1,6 Millionen SingleStepTests – es gibt jedoch keine T-States innerhalb eines Befehls
- Der CRTC besteht lediglich aus seinen Registern, ohne Raster-Timing; Interrupts und VSYNC folgen einem vereinfachten Modell
- Kein Sound, keine Kassette, kein Drucker; PPI/PSG bieten nur das, was Tastatur und VSYNC zwingend benötigen
- Es läuft ungefähr in Echtzeit – bei aktivierter Analyse und Traces entsprechend langsamer
Firmware, BASIC, AMSDOS und Diskettenzugriffe funktionieren einwandfrei. Rastertricks, Mid-Line-Splits und alles, was auf exaktes Cycle-Timing angewiesen ist, funktionieren nicht, und das wird sich auch nicht ändern – das ist eine Designentscheidung, kein offener To-do-Punkt.
Bezugsquelle
Das Release 0.9.0 (Beta) enthält ein Python-Paket sowie fertige Binärdateien für Windows und Linux; die Standard-Amstrad-ROMs sind bereits enthalten:
Der Code ist für das, was ich für Version 1.0 geplant hatte, vollständig; was jetzt noch fehlt, ist der Praxiseinsatz. Feedback, Fehlerberichte und Ideen sind herzlich willkommen – entweder hier oder im GitHub-Issue-Tracker.
Nutzt es einfach für das, was es ist – aber betrachtet es bitte nicht als Konkurrenz zu anderen Emulatoren, da ein Großteil der Hardware gar nicht implementiert ist – nicht einmal der CRTC oder das Gate-Array.
Der Bildschirm wird beispielsweise nicht vom Gate-Array gerendert, sondern von einem Renderer, der einfach das Bildschirm-RAM ausliest und in einen normalen RGB-Frame packt, damit er dargestellt werden kann.
