One ROM – Praxisbeispiel: ZX81 mit 24-Pin Fire One ROM

One ROM – Praxis: ZX81 mit 24-Pin Fire One ROM

Nach den bisherigen C64-Projekten diesmal ein etwas anderes System:
Ein modifizierter ZX81 – minimalistisch, offen aufgebaut und genau deshalb perfekt für Experimente.

Der Kandidat: Ein etwas anderer ZX81

Das hier ist kein klassischer ZX81 im Originalgehäuse:

• Gehäuse: nur obere und untere Kunststoffplatte
• Tastatur: von einem TI/99 adaptiert
• offener Aufbau, gut zugänglich

👉 Genau die Art System, bei der man gerne „mal eben“ etwas ausprobiert.

Das Herzstück: Z80 + externes ROM

Wie beim ZX81 üblich:

• CPU: Z80
• externes ROM
• relativ einfache Logik

👉 Perfekt geeignet für ein One ROM als Ersatz.

Umbau: One ROM statt Original-ROM

Zum Einsatz kommt:

• One ROM Fire 24 (24-Pin Version, Rev. E)
• direkt im ROM-Sockel

👉 Damit ersetzt das One ROM das komplette Original-ROM.

Warum gerade der ZX81 ideal ist

Der ZX81 ist fast schon ein „Lehrbuch-Beispiel“:

• klar strukturierter Bus
• wenig Timing-Tricks
• überschaubare ROM-Größe

👉 Genau deshalb funktioniert der Einsatz hier besonders unkompliziert.

Vorteile des One ROM im ZX81

Der Umbau bringt mehrere Vorteile:

🔁 Schnelle ROM-Updates

• kein EPROM-Brenner nötig
• Änderungen in Sekunden über USB

🧪 Experimentieren ohne Risiko

• verschiedene ROM-Versionen testen
• eigene Modifikationen ausprobieren

🧩 Mehrere ROMs möglich

• alternative ZX81-ROMs
• eigene Erweiterungen
• Debug-Versionen

Typischer Workflow

Der Ablauf ist wie bei den anderen Projekten:

1. ROM-Image vorbereiten
2. per Web oder CLI flashen
3. USB abziehen
4. ZX81 starten

👉 Der ZX81 läuft dann direkt mit dem neuen ROM.

Besonderheiten beim ZX81

Ein paar Dinge sollte man beachten:

⚠️ Spannungsversorgung

• ZX81 arbeitet mit klassischen 5V
• One ROM ist dafür ausgelegt, aber Pinout prüfen

⚠️ Timing

• ZX81 ist relativ tolerant
• trotzdem bei exotischen Mods im Hinterkopf behalten

⚠️ Mechanik

• offener Aufbau → Vorsicht bei Kurzschlüssen
• gerade bei provisorischen Gehäusen

Der Charme dieses Aufbaus

Was dieses Projekt besonders macht:

• kein „sauberer“ Serienzustand
• sondern ein gewachsenes Bastelprojekt
• offen, zugänglich, veränderbar

👉 Genau dafür ist One ROM ideal.

Persönliches Fazit

Der ZX81 zeigt sehr schön:

👉 One ROM ist nicht nur für „große“ Systeme wie den C64 interessant
👉 sondern auch für einfache, klassische Rechner

Und gerade dort macht es besonders Spaß:

• schnell testen
• schnell ändern
• direkt sehen, was passiert

Fazit

Mit dem One ROM wird aus dem ZX81:

• eine flexible Entwicklungsplattform
• ein Experimentiersystem
• ein moderner Ersatz für alte EPROMs

👉 Und das alles ohne großen Umbau.

Ausblick

Mögliche nächste Schritte:

• eigene ZX81-ROM-Erweiterungen
• alternative BASIC-Versionen
• Debug-ROMs für Hardware-Analyse

Praxisbeispiel von: ILHA, Mitglied des VzEkC e. V.

TAGS: One ROM

One ROM – Praxisbeispiel: Bank-Switching im C64

One ROM – Praxis: Vom Kernal-Turm zum sauberen Bank-Switching im C64

Manchmal stolpert man über alte Projekte und denkt sich:
👉 „Das war damals eine gute Idee… aber heute würde ich das anders machen.“

Genau so ging es mir mit meinem allerersten Commodore 64.

Der Ausgangszustand: „So hat man das damals gemacht“

Mein erster C64 ist… sagen wir mal… „gewachsen“ 😄

Verbaut sind:

• Reset-Taster
• 2 Schalter für Reset-Routing:
  • nur Floppy
  • nur C64
  • beide
  • keiner
• 4-fach Drehschalter für bis zu 4 Kernals
• zweifarbige LED zur Statusanzeige

👉 Ja, genau so hat man das damals gemacht.

Innenleben: Der berüchtigte „Kernal-Turm“

Im Inneren sieht es entsprechend aus:

• mehrere EPROMs übereinander
• viel Verdrahtung
• unterschiedliche CS-Leitungen
• mechanisch… sagen wir: herausfordernd

👉 Und natürlich:
Eine Litze hat sich mal wieder gelöst 🙄

Ziel: Weniger Chaos, gleiche Funktion

Was wollte ich erreichen?

• mehrere Kernals behalten
• weniger Verdrahtung
• stabilerer Aufbau
• einfachere Umschaltung

👉 Und natürlich:
Ein guter Grund, One ROM einzusetzen 😄

Lösung: One ROM + Dynamic Bank Switching

Ich habe mich für folgendes Setup entschieden:

• One ROM 24 als Ersatz für mehrere ROMs
• Dynamic Bank Switching für mehrere Kernals
• Umschaltung über nur zwei Leitungen (X1, X2)

👉 Ergebnis:

• deutlich weniger Kabel
• keine gestapelten EPROMs mehr
• sauberer und robuster Aufbau

Der große Unterschied zur alten Lösung

Früher:

• 3× CS-Leitungen hin
• 1× CS zurück
• +5V und GND separat
• komplexe Verdrahtung

Heute:

• +5V
• GND
• X1
• X2

👉 Fertig.

Nebenbei optimiert: LED-Ansteuerung

Ein netter Nebeneffekt:

• die 5V-Leitung konnte ich gleich für die Dual-LED nutzen
• weniger zusätzliche Verdrahtung nötig

👉 Die „gefährlichen“ Header-Pins für 5V/GND sind hier tatsächlich sinnvoll eingesetzt

Dynamic Bank Switching – unterschätzt, aber genial

Was mich überrascht hat:

👉 Ich habe kaum Beispiele dafür im Web oder Studio gefunden

Dabei ist das extrem praktisch:

• mehrere ROMs gleichzeitig verfügbar
• Umschaltung ohne Reflash
• keine Neustart-Prozedur nötig

👉 Perfekt für:

• verschiedene Kernals
• SpeedDOS / FastDOS
• Tests und Experimente

Meine Konfiguration

Hier meine verwendete Device-Konfiguration:

{
   "$schema": "https://images.onerom.org/configs/schema.json",
   "version": 1,
   "description": "Mandatory description about this config",
   "detail": "Extra detail about ths configuration",
   "notes": "Notes that appear after the list of sets",
   "rom_sets": [
       {
           "type": "banked",
           "description": "Multiple C64 ROMs",
           "roms": [
               {
                   "file": "http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/c64/kernal.901227-03.bin",
                   "description": "C64 Kernal ROM, 901227-03",
                   "type": "2364",
                   "cs1": "active_low"
               },
               {
                   "description": "Speed Dos",
                   "file": "C:/Xgpro/UserData/c64_speed_dos.bin",
                   "type": "2364",
                   "cs1": "active_low"
               },
               {
                   "description": "Fast Dos",
                   "file": "C:/Xgpro/UserData/c64_fast_dos.bin",
                   "type": "2364",
                   "cs1": "active_low"
               }
           ]
       }
   ]
}

TAGS: One ROM

One ROM – Praxisbeispiel: Entwickler-Workflow mit Makefile

One ROM – Praxis: Entwickler-Workflow mit Makefile und automatischem Flash per CLI

Im letzten Beitrag ging es darum, One ROM als EPROM-Ersatz für schnelle Firmware-Tests zu verwenden.
Diesmal gehen wir noch einen Schritt weiter:

👉 Wie sieht ein wirklich praxisnaher Entwickler-Workflow aus, wenn Kompilieren, Flashen und Testen möglichst schnell gehen sollen?

Genau hier spielt One ROM seine Stärken voll aus.

Das Ziel

Wer an Firmware für ältere Rechner, Eigenbau-Systeme oder EPROM-basierte Hardware arbeitet, möchte in der Regel immer das Gleiche:

• Quellcode ändern
• Firmware neu bauen
• sofort ins Zielsystem übertragen
• direkt testen

Mit einem klassischen EPROM-Programmiergerät ist das auf Dauer mühsam.
Mit One ROM lässt sich dieser Ablauf deutlich verkürzen.

Der Grundgedanke

Die Idee ist einfach:

1. Firmware wird auf dem PC gebaut
2. das erzeugte Binary wird automatisch an One ROM übertragen
3. danach wird das Zielsystem neu gestartet oder zurückgesetzt
4. die neue Firmware läuft sofort

👉 Statt „EPROM ziehen, brennen, einsetzen“ reicht dann oft ein einziger Befehl.

Typischer Aufbau

Für so einen Workflow braucht es nicht viel:

• einen PC oder Laptop zum Entwickeln
• One ROM im Zielsystem
• USB-Verbindung zum One ROM
• die One ROM CLI
• ein Build-System, zum Beispiel make

Das Zielsystem selbst bleibt dabei unverändert.
Für den Rechner oder die Platine sieht One ROM weiterhin einfach wie ein normales ROM oder EPROM aus.

Der klassische Ablauf – und warum er nervt

Ohne One ROM sieht eine Änderung oft so aus:

1. Code ändern
2. Build starten
3. EPROM programmieren
4. alten Chip entfernen
5. neuen Chip einsetzen
6. testen

Das funktioniert – aber es kostet Zeit und macht gerade bei vielen kleinen Änderungen keinen Spaß.

Der moderne Ablauf mit One ROM

Mit One ROM kann derselbe Vorgang so aussehen:

1. Code ändern
2. make flash eingeben
3. wenige Sekunden warten
4. Reset drücken
5. testen

👉 Genau dieser Unterschied macht One ROM beim Entwickeln so interessant.

Ein einfaches Beispielprojekt

Nehmen wir an, dein Projekt erzeugt am Ende eine Datei namens firmware.bin.

Die Verzeichnisstruktur könnte zum Beispiel so aussehen:

projekt/
├── src/
├── build/
├── Makefile
└── firmware.bin

Das ist natürlich nur ein Beispiel – entscheidend ist nur, dass dein Build am Ende ein ROM-Image erzeugt.

Der erste Schritt: Nur bauen

Bevor wir das Flashen automatisieren, sollte der normale Build bereits sauber laufen.

Ein sehr einfaches Makefile könnte so aussehen:

PROJECT = firmware
BUILD_DIR = build
IMAGE = $(BUILD_DIR)/$(PROJECT).bin

all: $(IMAGE)

$(IMAGE):
	mkdir -p $(BUILD_DIR)
	@echo Erzeuge $(IMAGE)
	@copy /b src\firmware.bin $(IMAGE)

clean:
	rmdir /s /q $(BUILD_DIR)

Das Beispiel ist bewusst simpel gehalten.
In einem echten Projekt würdest du hier natürlich Assembler, C-Compiler oder Linker aufrufen.

Der nächste Schritt: Flashen per CLI

Jetzt kommt One ROM ins Spiel.

Sobald dein Binary erzeugt wurde, kann es direkt per CLI übertragen werden.
Der eigentliche Flash-Befehl sieht dabei zum Beispiel so aus:

onerom program build/firmware.bin

Danach ist die neue Firmware im One ROM gespeichert.

Makefile mit Flash-Ziel

Spannend wird es, wenn du den Flash-Vorgang direkt in dein Makefile einbaust.

Ein einfaches Beispiel:

PROJECT = firmware
BUILD_DIR = build
IMAGE = $(BUILD_DIR)/$(PROJECT).bin
ONEROM = onerom.exe

all: $(IMAGE)

$(IMAGE):
	if not exist $(BUILD_DIR) mkdir $(BUILD_DIR)
	@echo Erzeuge $(IMAGE)
	copy /b src\firmware.bin $(IMAGE)

flash: $(IMAGE)
	$(ONEROM) scan
	$(ONEROM) inspect
	$(ONEROM) program $(IMAGE)

clean:
	if exist $(BUILD_DIR) rmdir /s /q $(BUILD_DIR)

Damit reicht unter Windows später:

make flash

👉 Das Makefile baut dann zuerst das Binary und überträgt es anschließend direkt auf das One ROM.

Variante unter Linux

Unter Linux oder macOS sieht das Ganze fast genauso aus, nur mit anderen Shell-Kommandos:

PROJECT = firmware
BUILD_DIR = build
IMAGE = $(BUILD_DIR)/$(PROJECT).bin
ONEROM = ./onerom

all: $(IMAGE)

$(IMAGE):
	mkdir -p $(BUILD_DIR)
	@echo "Erzeuge $(IMAGE)"
	cp src/firmware.bin $(IMAGE)

flash: $(IMAGE)
	$(ONEROM) scan
	$(ONEROM) inspect
	$(ONEROM) program $(IMAGE)

clean:
	rm -rf $(BUILD_DIR)

Warum scan und inspect sinnvoll sind

Man könnte natürlich direkt program aufrufen.
In der Praxis ist es aber oft sinnvoll, vorher noch zwei Dinge zu tun:

• scan prüft, ob das Gerät überhaupt gefunden wird
• inspect zeigt den aktuellen Zustand des One ROM

👉 Gerade wenn man mit mehreren Geräten arbeitet oder verschiedene Testaufbauten auf dem Tisch hat, spart das viele Missverständnisse.

Noch komfortabler: Alles mit einem einzigen Befehl

Der eigentliche Charme liegt darin, dass du dir einen sehr kurzen Zyklus aufbauen kannst:

make flash

Das ist dann der gesamte Entwicklungsablauf:

• ändern
• bauen
• flashen
• testen

Mehr braucht es oft nicht.

Optional: automatischer Neustart

Wenn dein Aufbau es zulässt, kannst du nach dem Flashen auch noch einen Neustart des One ROM auslösen:

flash: $(IMAGE)
	$(ONEROM) scan
	$(ONEROM) inspect
	$(ONEROM) program $(IMAGE)
	$(ONEROM) reboot

Ob das im konkreten Aufbau sinnvoll ist, hängt vom Zielsystem ab.
Oft reicht auch ein manueller Reset am Rechner oder an der Testplatine.

Mehr Sicherheit durch eigenes Flash-Ziel

In der Praxis ist es oft sinnvoll, nicht all automatisch zu flashen, sondern dafür ein eigenes Ziel wie flash zu verwenden.

Der Grund ist einfach:

👉 Nicht jeder Build soll sofort auf die Hardware geschrieben werden.

Manchmal will man nur kompilieren, manchmal disassemblieren, manchmal vergleichen.
Mit einem eigenen Ziel bleibt das sauber getrennt.

Beispiel für einen typischen Tagesablauf

Ein realistischer Workflow könnte dann so aussehen:

1. Quellcode ändern
2. make zum schnellen Test des Builds
3. make flash, wenn das Binary auf die Hardware soll
4. Gerät resetten
5. Verhalten prüfen

Das klingt banal – spart aber im Alltag enorm Zeit.

Noch besser: verschiedene Firmware-Varianten

Besonders elegant wird es, wenn du mehrere Firmware-Varianten parallel baust.

Zum Beispiel:

• normale Version
• Debug-Version
• Test-Version mit zusätzlichem Logging

Ein Makefile könnte dafür mehrere Ziele bekommen:

flash-release: build/release.bin
	$(ONEROM) program build/release.bin

flash-debug: build/debug.bin
	$(ONEROM) program build/debug.bin

👉 So kannst du gezielt genau die Variante flashen, die du gerade brauchst.

One ROM statt EPROM-Brenner

Gerade an dieser Stelle merkt man, wie groß der Unterschied zur klassischen Arbeitsweise ist.

Früher:

• Brenner anschließen
• EPROM löschen
• EPROM programmieren
• Chip wechseln

Heute:

• make flash
• fertig

Das spart nicht nur Zeit, sondern auch mechanischen Verschleiß an Sockeln und Chips.

Typische Stolperfallen

Natürlich klappt auch so ein Workflow nicht immer auf Anhieb.

Kein Gerät gefunden

Wenn scan kein One ROM findet, liegt das oft an:

• schlechtem USB-Kabel
• fehlender Verbindung
• einem noch geöffneten Web-Interface
• mehreren angeschlossenen Testgeräten

Gerade der letzte Punkt ist wichtig:
Wenn mehrere Geräte am Tisch liegen, sollte man sauber mit Seriennummern oder getrennten Setups arbeiten.

Falsches Binary geflasht

Auch das passiert schneller als man denkt.

Deshalb lohnt es sich:

• Ausgabedateien sauber zu benennen
• Release und Debug klar zu trennen
• alte Builds regelmäßig zu löschen

Reset vergessen

Nach dem Flashen muss das Zielsystem die neue Firmware natürlich auch wirklich neu einlesen.

Je nach Aufbau bedeutet das:

• Reset-Taster drücken
• Rechner neu starten
• Versorgung kurz aus- und wieder einschalten

Wo dieser Workflow besonders stark ist

Das Ganze lohnt sich vor allem bei:

• Eigenbau-Computern
• 8-Bit- und 16-Bit-Systemen
• Monitor- oder Boot-ROM-Entwicklung
• Diagnosesoftware
• experimentellen Firmware-Versionen

Überall dort, wo häufig kleine Änderungen getestet werden, spart dieser Ablauf enorm Zeit.

Praxistipp: erst klein anfangen

Auch wenn die komplette Automatisierung reizvoll ist:

👉 Am Anfang lieber klein starten.

Also zuerst:

• Binary sauber erzeugen
• per CLI manuell flashen
• danach Flash-Schritt ins Makefile übernehmen

So lässt sich jeder Schritt einzeln testen und Fehler sind leichter zu finden.

Fazit

One ROM ist als EPROM-Ersatz nicht nur praktisch – mit CLI und Makefile wird daraus ein richtig angenehmer Entwickler-Workflow.

Die Kombination aus:

• Build-System
• One ROM CLI
• schnellem Flashen per USB

macht aus einem früher eher mühsamen Prozess einen sehr direkten Ablauf.

👉 Gerade für Firmware-Entwicklung an älteren oder EPROM-basierten Systemen ist das ein echter Gewinn.

Ausblick

Ein sinnvoller nächster Schritt wäre dann zum Beispiel:

• mehrere Firmware-Versionen parallel verwalten
• automatische Vergleichstests
• ein Setup mit Debug- und Release-ROM im selben One ROM

TAGS: One ROM, One ROM CLI

One ROM – Praxisbeispiel: One ROM als EPROM-Emulator

One ROM – Praxis: One ROM als EPROM-Emulator für schnelle Firmware-Tests

In den bisherigen Artikeln ging es um fertige ROM-Sets und komplexe Konfigurationen.
Diesmal schauen wir uns einen der praktischsten Einsatzzwecke an:

👉 One ROM als EPROM-Ersatz beim Entwickeln und Testen von Firmware

Ausgangssituation

Wer mit älteren Systemen oder Eigenentwicklungen arbeitet, kennt das Problem:

• Firmware wird geändert
• EPROM muss neu gebrannt werden
• Chip ausbauen
• einsetzen
• testen

👉 Das kostet Zeit – und nervt auf Dauer.

Ziel dieses Setups

Mit One ROM wollen wir:

• ein EPROM dauerhaft ersetzen
• Firmware schnell per USB aktualisieren
• Änderungen sofort testen

👉 Kein Brenner, kein Ausbauen, kein Verschleiß.

Typischer Aufbau

Das Setup ist denkbar einfach:

• One ROM im EPROM-Sockel
• USB-Verbindung zum PC
• Zielsystem eingeschaltet

👉 Das One ROM verhält sich wie ein normales ROM.

Workflow in der Praxis

Jetzt kommt der eigentliche Vorteil.

🔁 Klassischer Ablauf (früher)

1. Firmware kompilieren
2. EPROM brennen
3. Chip einsetzen
4. testen

⚡ Mit One ROM

1. Firmware kompilieren
2. Image flashen (Web, Studio oder CLI)
3. Reset drücken
4. testen

👉 Fertig in Sekunden.

Beispiel: Firmware-Update per CLI

onerom program firmware.bin
onerom reboot

👉 Danach läuft sofort die neue Version.

Alternative: Web-Interface

Noch einfacher:

1. https://onerom.org/web/ öffnen
2. verbinden
3. „Local Image“ wählen
4. flashen

👉 Ideal für schnelle Tests ohne Terminal.

Verhalten im Zielsystem

Für das Zielsystem sieht alles ganz normal aus:

• gleiche Adressen
• gleiche Signale
• gleiche Funktion wie ein echtes EPROM

👉 Kein Unterschied zur Original-Hardware.

Wichtige Hinweise

⚠️ Timing

Die meisten Systeme funktionieren problemlos – aber:

• sehr timingkritische Designs können empfindlich sein
• im Zweifel testen

⚠️ Spannungen

• One ROM arbeitet typischerweise mit 5V-kompatiblen Signalen
• trotzdem Pinbelegung prüfen

⚠️ Reset-Verhalten

Nach dem Flashen:

👉 meist Reset oder Neustart notwendig

Erweiterte Möglichkeiten

Hier wird es richtig interessant:

🔀 Mehrere Firmware-Versionen gleichzeitig

• verschiedene Builds im One ROM speichern
• per Jumper oder Schalter umschalten

👉 Perfekt für A/B-Tests

🧪 Debug vs. Release

• Debug-Version mit Logging
• Release-Version für echten Betrieb

⚡ Schnelle Iteration

• kleine Änderungen testen
• sofort Feedback

👉 Ideal für Entwicklung.

Typische Einsatzbereiche

• Retro-Computer
• Eigenbau-Computer
• Steuerungen mit EPROM
• Reparatur und Fehlersuche

Vorteile gegenüber klassischem EPROM

• kein Brenner nötig
• kein Chip-Wechsel
• extrem schnell
• weniger Verschleiß

👉 Besonders bei häufiger Änderung ein riesiger Vorteil.

Erfahrungen aus der Praxis

Gerade beim Entwickeln ist das ein echter Gamechanger:

• Änderungen dauern Sekunden statt Minuten
• weniger Fehler durch mechanisches Handling
• deutlich angenehmer Workflow

👉 Einmal benutzt – will man nicht mehr zurück.

Fazit

One ROM eignet sich hervorragend als EPROM-Emulator:

• ersetzt klassische EPROMs vollständig
• beschleunigt Entwicklung massiv
• vereinfacht Tests und Experimente

👉 Genau der Anwendungsfall aus dem Forum – und einer der stärksten überhaupt.

Ausblick

Mögliche nächste Themen:

• Nutzung mit Eigenbau-CPU-Systemen
• Timing-Optimierung
• Kombination mit Debug-Tools

TAGS: One ROM, One ROM CLI, One ROM Web

One ROM CLI – Bedinungsanleitung

One ROM – Arbeiten mit der CLI (Command Line Interface)

Neben Web-Interface und One ROM Studio gibt es noch eine dritte Möglichkeit, mit One ROM zu arbeiten: die Command Line Interface (CLI).

👉 Damit kannst du dein One ROM direkt über die Kommandozeile steuern – schnell, skriptbar und ohne GUI.

Was ist die One ROM CLI?

Die CLI ist ein Kommandozeilen-Tool zur Verwaltung deines One ROM:

👉 Typische Aufgaben:

• Geräte finden
• Firmware flashen
• ROM-Inhalte lesen und schreiben
• Debugging und Analyse

Start der CLI

Unter Windows startest du z. B.:

👉 Dann bekommst du die Hilfeübersicht mit allen Befehlen.

Grundsyntax

Verfügbare Commands

Hier die wichtigsten Befehle aus deiner CLI:

🔍 scan – Geräte finden

👉 Sucht nach angeschlossenen One ROM Geräten.

⚡ program – Firmware flashen

👉 Schreibt ein Image auf das One ROM.

🔎 inspect – Gerät untersuchen

👉 Zeigt Informationen zum angeschlossenen Gerät (read-only).

🎛️ control – temporäre Aktionen

👉 Führt temporäre Aktionen aus (z. B. Umschalten).

💾 update – dauerhafte Änderungen

👉 Speichert Änderungen dauerhaft im Gerät.

📖 peek – Daten lesen

👉 Liest Daten aus dem aktuell laufenden ROM.

✏️ poke – Daten schreiben

👉 Schreibt Daten ins laufende ROM.

🔁 reboot – Neustart

👉 Startet das One ROM neu.

🏗️ firmware – Firmware verwalten

👉 Build, Analyse und Verwaltung von Firmware-Images.

🔌 plugin – Plugins anzeigen

👉 Listet verfügbare Erweiterungen.

❓ help – Hilfe

👉 Zeigt Hilfe zu Commands.

Wichtige Optionen

Diese Optionen gelten global:

Gerät auswählen

👉 Auswahl über Seriennummer

USB-ID verwenden

👉 Beispiel:

Unbekannte Geräte zulassen

👉 Für neue oder nicht erkannte One ROMs

Automatisch bestätigen

👉 Überspringt Rückfragen

Verbose-Ausgabe

👉 Mehr Details im Output

Log-Level

👉 Für Debugging sehr hilfreich

Typischer Workflow

Ein realistischer Ablauf:

Zusammenspiel mit Web und Studio

👉 Die CLI ergänzt die anderen Tools perfekt:

• Web → schnell testen
• Studio → Projekte verwalten
• CLI → automatisieren

💡 Typisch:

1. Image im Studio erstellen
2. mit CLI flashen
3. im Gerät testen

Typische Fehler

❌ „No matching One ROM devices found“

• USB nicht verbunden
• falsches Kabel
• Web-Interface noch offen

👉 Wichtig:
Nur ein Tool gleichzeitig darf auf das Gerät zugreifen

❌ Zugriff verweigert

• unter Linux fehlende Rechte
• falsches Gerät ausgewählt

❌ Flash schlägt fehl

• falsches Image
• Verbindung instabil

Tipps aus der Praxis

• immer zuerst scan
• inspect vor Änderungen nutzen
• mit --verbose debuggen
• kleine Schritte testen

Fazit

Die One ROM CLI ist das ideale Werkzeug für:

• fortgeschrittene Anwender
• Automatisierung
• schnelle Workflows ohne GUI

👉 In Kombination mit Web und Studio ergibt sich ein sehr mächtiges Setup.

Ausblick

Mögliche nächste Themen:

• automatisierte Flash-Skripte
• Serienprogrammierung
• Integration in Build-Systeme

TAGS: One ROM, One ROM CLI

One ROM Studio – Bedienungsanleitung

One ROM – Arbeiten mit dem One ROM Studio

Neben dem Web-Interface gibt es noch ein zweites, sehr mächtiges Werkzeug: das One ROM Studio.

Während das Web-Tool perfekt für den schnellen Einstieg ist, richtet sich das Studio an alle, die komplexere Setups erstellen, speichern und wiederverwenden möchten.

👉 Das Projekt findest du hier: One ROM Studio

Was ist das One ROM Studio?

Das One ROM Studio ist eine eigenständige Anwendung zur Erstellung und Verwaltung von One-ROM-Images.

👉 Im Unterschied zum Web-Interface kannst du hier:

• Projekte speichern
• Konfigurationen versionieren
• komplexe Multi-ROM-Setups erstellen
• Images reproduzierbar erzeugen

Kurz gesagt:
Das Studio ist das Werkzeug für strukturierte und wiederholbare Arbeit.

Installation

👉 Unterstützt werden typischerweise:

• Windows (x86 64-bit und ARM)
• macOS
• Linux (Ubuntu/Debian, x86 und ARM, z. B. Raspberry Pi)

Installation unter Windows

• passende Version herunterladen
• ggf. entpacken
• Programm starten

👉 Keine zusätzliche Installation nötig.

Installation unter Linux / Raspberry Pi

• ARM- oder x86-Version wählen
• ausführbar machen (chmod +x)
• starten

Installation unter macOS

• herunterladen
• ggf. Sicherheitsabfrage bestätigen
• starten

💡 Tipp:
Die angebotenen SHA256-Prüfsummen helfen dir, die Datei zu verifizieren.

Wichtiger Workflow: Web und Studio kombinieren

👉 Ein großer Vorteil von One ROM:

Images aus dem Web-Interface können im Studio weiterverwendet werden – und umgekehrt.

Das bedeutet konkret:

• Im Web schnell ein funktionierendes Setup erstellen
• Image exportieren
• im Studio weiter bearbeiten, dokumentieren oder erweitern

👉 Perfekter Einstieg:

1. Im Browser testen
2. funktionierendes Image exportieren
3. im Studio als Projekt weiterführen

Grundprinzip im Studio

• ROM-Dateien werden organisiert
• Konfigurationen gespeichert
• daraus wird ein Image erzeugt

👉 Vorteil: Alles bleibt nachvollziehbar und wiederholbar.

Aufbau eines Projekts

Ein typisches Studio-Projekt besteht aus:

📁 ROM-Dateien

Hier liegen deine:

• Kernal-ROMs
• Basic-ROMs
• Character-ROMs
• ggf. weitere Images

⚙️ Konfiguration

Hier definierst du:

• ROM-Slots
• Zuordnung der Dateien
• Hardware-Parameter
• Umschaltlogik

👉 Das entspricht den Einstellungen im Web-Interface – nur dauerhaft gespeichert.

🏗️ Build / Image

Am Ende erzeugt das Studio:

• ein fertiges One-ROM-Image
• das du direkt im Web-Interface flashen kannst

Beispiel: C64 Multi-ROM Setup

Nehmen wir das bekannte Setup:

• Original-ROM
• JiffyDOS
• Diagnose-ROM

Im Studio würdest du:

• mehrere Sets definieren
• jeweils ROM-Dateien zuweisen
• Umschaltung konfigurieren

👉 Der Vorteil:
Das komplette Setup ist jederzeit reproduzierbar.

Typischer Workflow

Ein typischer Ablauf sieht so aus:

1. Studio starten
2. neues Projekt anlegen
3. ROM-Dateien hinzufügen
4. Konfiguration erstellen
5. Image bauen
6. im Web-Interface flashen

👉 Das Studio ergänzt das Web-Tool – es ersetzt es nicht.

Vorteile gegenüber dem Web-Interface

Das Studio spielt seine Stärken besonders hier aus:

• 📄 Konfigurationen sind speicherbar
• 🔁 Builds reproduzierbar
• 🧩 komplexe Setups übersichtlicher
• ⚡ Automatisierung möglich

Typische Einsatzfälle

• Entwicklung eigener ROMs
• mehrere Projekte verwalten
• komplexe Mapping-Setups
• Austausch von Konfigurationen

Tipps für den Einstieg

• zuerst mit einem einfachen Setup starten
• funktionierende Web-Konfiguration übernehmen
• Schritt für Schritt erweitern
• Projekte sauber benennen und speichern

👉 Besonders hilfreich:
Ein funktionierendes Web-Image als Ausgangspunkt nutzen.

Häufige Fehler

❌ Image funktioniert nicht

• falsche ROM-Zuordnung
• falsche Größen

❌ Build schlägt fehl

• fehlende Dateien
• falsche Pfade

❌ Verhalten anders als im Web

• Konfiguration nicht identisch
• Mapping unterschiedlich

Fazit

Das One ROM Studio ist die ideale Ergänzung zum Web-Interface:

• mehr Kontrolle
• bessere Struktur
• reproduzierbare Ergebnisse

👉 Die Kombination aus beiden Tools ist besonders stark:

• Web → schnell testen
• Studio → sauber aufbauen und verwalten

Ausblick

Mögliche nächste Themen:

• fertiges Beispielprojekt zum Download
• automatisierte Builds
• komplexe Multi-ROM-Setups

TAGS: One ROM, One ROM Studio

One ROM – Praxisbeispiel: C64 Setup mit JiffyDOS

One ROM – C64 Setup mit Original, JiffyDOS und Diagnose-ROM

Im letzten Beitrag haben wir ein fertiges Setup (set-c64) verwendet.
Jetzt gehen wir einen Schritt weiter und bauen uns ein eigenes Multi-ROM-Setup.

👉 Ziel:

• Original C64-ROM
• JiffyDOS
• Dead Test Diagnose-ROM
• Umschaltbar per Hardware

Alles in einem einzigen One ROM.

Warum dieses Setup sinnvoll ist

Dieses Setup deckt praktisch alle Anwendungsfälle ab:

• 🟢 Original-ROM → maximale Kompatibilität
• ⚡ JiffyDOS → deutlich schnelleres Laden
• 🧪 Diagnose-ROM → Fehlersuche

👉 Früher hätte man dafür mehrere EPROMs gebraucht.

Vorbereitung der ROM-Dateien

7

Du brauchst folgende Dateien:

1. Original-ROMs

• Kernal (901227-03)
• Basic (901226-01)
• Character (901225-01)

2. JiffyDOS Kernal

• Ersatz für das Kernal-ROM
• gleiche Größe wie Original

👉 Wichtig: JiffyDOS ersetzt nur das Kernal-ROM, nicht Basic oder Character.

3. Dead Test ROM

• Diagnose-Kernal (781220)
• wird ebenfalls im Kernal-Slot verwendet

Aufbau der Custom-Konfiguration

Jetzt bauen wir unser eigenes Image im Web-Interface:

👉 https://onerom.org/web/

Schritt 1: Custom Image auswählen

• Verbinden
• „Custom Image“ öffnen

Schritt 2: ROM-Sets definieren

7

Jetzt legst du drei Sets an:

🧩 Set 0 – Original

• Kernal: 901227-03
• Basic: 901226-01
• Character: 901225-01

👉 Das ist dein „Fallback“

⚡ Set 1 – JiffyDOS

• Kernal: JiffyDOS
• Basic: unverändert
• Character: unverändert

👉 Ergebnis: schnelleres Laden bei voller Kompatibilität

🧪 Set 2 – Diagnose

• Kernal: Dead Test 781220
• Character: 901225-01

👉 Basic wird hier meist nicht benötigt

Mapping und Umschaltung

Die Umschaltung erfolgt wie beim vorherigen Artikel:

👉 über die Image Select Pins

Typische Belegung:

• 00 → Set 0 (Original)
• 01 → Set 1 (JiffyDOS)
• 10 → Set 2 (Diagnose)

💡 Das kannst du z. B. mit einem kleinen DIP-Schalter realisieren.

Flashen des Custom Images

• „Program“ klicken
• warten bis fertig

👉 Danach ist alles im One ROM gespeichert.

Einbau im C64

7

Wie im vorherigen Artikel:

• One ROM in den Kernal-Sockel
• Verbindungen herstellen:
  • Basic CS → X1
  • Character CS → X2

Optional:

• DIP-Schalter für Umschaltung einbauen

Test der drei Modi

Nach dem Einschalten kannst du direkt testen:

🟢 Original

• normales BASIC-Startbild

⚡ JiffyDOS

• schneller Start
• neue DOS-Befehle

🧪 Diagnose

• Dead Test startet sofort
• ideal bei defekten Geräten

Typische Stolperfallen

❌ JiffyDOS funktioniert nicht

• falsches ROM geladen
• Größe stimmt nicht

❌ Kein Unterschied zwischen Sets

• Umschaltung falsch verdrahtet

❌ System startet nicht

• falsches Mapping
• Leitungen vertauscht

Erweiterungsmöglichkeiten

Wenn du Blut geleckt hast 😄:

• weitere Kernal-ROMs hinzufügen
• mehr als 3 Sets nutzen
• externe Umschalter einbauen
• automatische Umschaltung per Logik

Erfahrung aus der Praxis

Dieses Setup ist mein persönlicher Favorit:

👉 90 % aller Fälle sind damit abgedeckt

• Alltag → JiffyDOS
• Kompatibilität → Original
• Reparatur → Diagnose

Und alles ohne Umbau.

Fazit

Mit einem Custom Image holst du das Maximum aus One ROM heraus:

• mehrere ROMs in einem Chip
• flexibel umschaltbar
• perfekt für Entwicklung und Reparatur

👉 Gerade beim C64 ein echter Gamechanger.

Ausblick

Mögliche nächste Themen:

• Bank-Switching mit mehr als 4 ROMs
• Timing-Probleme und Lösungen
• Einsatz in anderen Systemen (z. B. Amiga, Arcade)

One ROM – Praxisbeispiel: Pre-built image: set-c64

One ROM – Praxis: Einsatz im Commodore C64 mit „set-c64“

In den letzten Artikeln ging es um Grundlagen und Custom Images.
Diesmal wird es richtig konkret: Wir setzen ein One ROM direkt in einem Commodore 64 ein – mit einer fertigen Konfiguration aus dem Web-Interface.

👉 Ziel: Mehrere originale ROMs + Dead Test in einem einzigen Baustein

Ausgangssituation beim C64

Der C64 nutzt gleich mehrere ROMs:

• Kernal-ROM
• Basic-ROM
• Character-ROM

Normalerweise sind das einzelne Chips – oder EPROM-Ersatzlösungen.

👉 Mit One ROM kannst du alle gleichzeitig ersetzen.

Verwendete Konfiguration

Wir nutzen genau das Setup aus dem Screenshot:

• Model: Fire
• PCB Revision: Fire 24 E
• MCU Variant: RP2350
• Firmware: v0.6.8
• ROM Config: set-c64

Diese Konfiguration bringt bereits alles mit, was wir brauchen.

Was steckt in „set-c64“?

Das Image enthält mehrere komplette ROM-Sets:

🧩 Set 0 (Standard)

• Kernal ROM 901227-03
• Basic ROM 901226-01
• Character ROM 901225-01

👉 Das entspricht einem normalen C64

🧪 Set 1 (Diagnose)

• Dead Test Kernel 781220
• Character ROM

👉 Perfekt für Fehlersuche – startet auch ohne funktionierenden RAM

🔀 Set 2 (Alternative Kombination)

• Kernel + Basic Varianten

👉 Für Experimente oder Modifikationen

Einbau im C64

6

👉 Wichtig: Das One ROM wird im Kernal-Sockel eingesetzt.

Verkabelung (laut Image-Anleitung)

Zusätzlich musst du zwei Verbindungen herstellen:

• Basic ROM CS (Pin 20) → SDRR Pin X1
• Character ROM CS1 (Pin 20) → SDRR Pin X2

👉 Hintergrund:
Das One ROM übernimmt alle drei ROMs und muss wissen, wann welches aktiv ist.

Besonderheit beim Character-ROM

Im Screenshot steht:

Character ROM CS2 is set to ‘ignore’

👉 Das liegt daran, dass diese Leitung im C64 fest auf +5V liegt.
Daher ist sie immer aktiv und muss nicht extra angeschlossen werden.

Umschalten zwischen den ROM-Sets

Jetzt kommt der spannende Teil:

👉 Die Auswahl erfolgt über die SDRR Image Select Jumper

• 0 (alle offen) → Set 0 (Standard)
• andere Kombinationen → Set 1 / Set 2

💡 Tipp:
Wenn du einen Schalter statt Jumper verwendest, kannst du bequem zwischen den Sets wechseln.

Flashen des Images

Das ist der einfachste Teil:

1. https://onerom.org/web/ öffnen
2. Verbindung herstellen
3. „Pre-built Image“ auswählen
4. set-c64 wählen
5. Program klicken

👉 Fertig – dauert nur wenige Sekunden.

Test im Betrieb

Nach dem Einbau:

• Gerät einschalten
• je nach Jumper-Stellung startet:
  • normales BASIC
  • oder Dead Test

👉 Gerade der Dead Test ist extrem hilfreich bei defekten Geräten.

Typische Fehler beim C64-Setup

❌ Schwarzer Bildschirm

• falsche Verkabelung der CS-Leitungen
• One ROM falsch herum eingesetzt

❌ Nur ein ROM funktioniert

• X1 / X2 nicht korrekt verbunden

❌ Umschaltung ohne Wirkung

• Jumper falsch gesetzt
• kein definierter Pegel

Warum dieses Setup so gut ist

Gerade beim C64 bringt One ROM enorme Vorteile:

• ersetzt 3 ROM-Chips gleichzeitig
• integrierter Dead-Test
• kein EPROM-Brennen mehr
• schnelles Umschalten

👉 Besonders für Reparaturen ein riesiger Gewinn.

Erfahrung aus der Praxis

Wenn man einmal so ein Setup hat, will man nicht mehr zurück:

• Kein ständiges Chip-Wechseln
• Kein Brenner notwendig
• Sofort verschiedene Konfigurationen testbar

Gerade bei Fehlersuche spart das richtig Zeit.

Fazit

Das set-c64 Image ist der perfekte Einstieg für den Einsatz im C64:

• sofort einsatzbereit
• durchdacht vorkonfiguriert
• extrem praktisch im Alltag

👉 Für mich aktuell die eleganteste Lösung, um mehrere C64-ROMs in einem System zu vereinen.

Ausblick

Mögliche nächste Schritte:

• eigene Kernal-ROMs einbauen (z. B. JiffyDOS)
• noch mehr ROM-Sets hinzufügen
• Umschaltung über externe Schalter erweitern

One ROM – Praxisbeispiel: Zwei Firmware-Versionen

One ROM – Praxisbeispiel: Zwei Firmware-Versionen in einem Retro-System

Nach den bisherigen Grundlagen und den Custom Images schauen wir uns diesmal ein konkretes Beispiel aus der Praxis an.

👉 Ziel: Zwei unterschiedliche ROM-Inhalte in einem Gerät nutzen – umschaltbar per Hardware

Das ist einer der Fälle, in denen One ROM seine Stärken voll ausspielt.

Ausgangssituation

Viele Retro-Systeme (z. B. alte Computer, Steuerungen oder Spielekonsolen) arbeiten mit fest verbauten ROMs.

Typische Probleme:

• Original-ROM ist schwer zu bekommen
• EPROMs müssen gebrannt werden
• mehrere Versionen lassen sich nur umständlich testen

👉 Genau hier kommt One ROM ins Spiel.

Ziel des Projekts

In diesem Beispiel wollen wir:

• Original-Firmware behalten
• modifizierte Firmware testen
• zwischen beiden Versionen umschalten können

Und das Ganze ohne EPROM-Brenner.

Benötigte Hardware

• One ROM (Fire oder Ice – je nach Aufbau)
• Zielsystem mit gesockeltem ROM
• optional: Jumper oder Schalter für Umschaltung

Vorbereitung der ROM-Dateien

1. Original-ROM
   → ausgelesen oder aus dem Netz
2. Modifiziertes ROM
   → gepatcht / angepasst

Wichtig:

• beide müssen die gleiche Größe haben
• typischerweise .bin-Dateien

👉 Falls die Größe nicht passt, kannst du sie mit Tools einfach anpassen (padding).

Custom Image erstellen

Jetzt geht’s ins Web-Interface: https://onerom.org/web/

Schritt 1: Verbinden

• One ROM anschließen
• „Connect“ klicken

Schritt 2: Custom Image auswählen

Im Bereich Programming → Custom Image wechseln.

Schritt 3: ROM-Slots belegen

• Slot 0 → Original-ROM
• Slot 1 → modifiziertes ROM

Beide bekommen:

• gleiche Größe
• gleiche Adresszuordnung

Schritt 4: Umschaltung konfigurieren

Jetzt kommt der spannende Teil.

Du definierst, wie zwischen den ROMs gewechselt wird:

• über einen GPIO-Pin
• oder eine Steuerleitung (z. B. Axx / CS)

👉 Einfachste Variante:
Ein Pin wird als „Select“ verwendet:

• LOW → Slot 0
• HIGH → Slot 1

Schritt 5: Flashen

• „Program“ klicken
• warten, bis „Erasing“ und „Programming“ durch sind

👉 Fertig.

Einbau ins Zielsystem

Jetzt wird das One ROM wie ein normales ROM eingesetzt:

• in den Sockel stecken
• auf richtige Ausrichtung achten (!)

Falls du einen Umschalter nutzt:

• Schalter zwischen GND und Signalpin
• ggf. Pull-Up/Pull-Down beachten

Testlauf

Beim Einschalten kannst du jetzt testen:

• Stellung 1 → Original-Firmware
• Stellung 2 → modifizierte Version

👉 Das Umschalten funktioniert je nach System sogar im laufenden Betrieb – aber vorsichtig testen!

Typische Anwendungen

Dieses Setup ist extrem vielseitig:

• Debug vs. Release-Firmware
• verschiedene Software-Versionen
• Sprachversionen
• Test- und Experimentierumgebungen

Häufige Fehler

❌ System startet nicht

• falscher ROM-Typ eingestellt
• Adressleitungen passen nicht

❌ falsche Inhalte

• ROM falsch zugeordnet
• Image nicht korrekt erstellt

❌ Umschaltung funktioniert nicht

• falscher Pin gewählt
• kein sauberer Pegel

👉 Tipp: Erst mit nur einem ROM testen, dann erweitern.

Erfahrung aus der Praxis

Gerade beim Experimentieren ist das ein riesiger Vorteil:

Früher:

• EPROM brennen
• einsetzen
• testen
• wieder rausnehmen
• EPROM mit UV-Löschgerät löschen

Heute:

• im Browser klicken
• flashen
• fertig

👉 Das spart enorm Zeit – und schont die Hardware.

Fazit

Dieses Beispiel zeigt sehr gut, warum One ROM so interessant ist:

• ersetzt mehrere EPROMs gleichzeitig
• ermöglicht schnelles Testen
• reduziert Hardware-Aufwand

Und das alles mit einem kleinen Board und einem Browser.

Ausblick

Mögliche nächste Themen:

• Mehr als zwei ROMs (Bank-Switching)
• komplexe Mapping-Strategien
• Timing-Probleme und Lösungen
• konkrete Systeme (z. B. C64, Arcade-Boards, etc.)

One ROM Web – Custom Images

One ROM – Arbeiten mit Custom Images

Im letzten Beitrag ging es um das Web-Interface und die grundlegende Bedienung.
Diesmal schauen wir uns eine der spannendsten Funktionen von One ROM an: Custom Images.

Denn damit wird aus dem kleinen Board erst so richtig ein universeller ROM-Ersatz.

Was sind „Custom Images“?

Mit Custom Images kannst du dein One ROM genau an deine Anwendung anpassen:

• eigene ROM-Daten verwenden
• mehrere ROMs kombinieren
• verschiedene Chip-Typen emulieren
• Speicheraufteilung frei definieren

Kurz gesagt: Du baust dir dein eigenes „virtuelles EPROM“.

Einstieg über das Web-Interface

1. https://onerom.org/web/ öffnen
2. Verbindung herstellen
3. Im Bereich „Programming“ → „Custom Image“ wechseln

Dort kannst du dein eigenes Image zusammenstellen.

Aufbau eines Custom Images

Ein Custom Image besteht im Prinzip aus mehreren Bausteinen:

🧩 ROM-Slots

Hier legst du fest:

• welche ROM-Datei geladen wird
• wie groß sie ist
• an welcher Adresse sie liegt

Je nach Konfiguration kannst du mehrere ROMs gleichzeitig nutzen.

⚙️ Hardware-Konfiguration

Wichtige Einstellungen sind zum Beispiel:

• ROM-Typ (z. B. EPROM, Mask ROM)
• Adressbreite
• Datenbreite
• Chip-Select-Verhalten

Das klingt erstmal komplex – ist aber meist schnell verstanden, wenn man das Zielsystem kennt.

🔀 Mapping / Umschaltung

Eine der stärksten Funktionen von One ROM:

👉 Mehrere ROMs können über Steuerleitungen umgeschaltet werden

Das ist z. B. interessant für:

• verschiedene Firmware-Versionen
• mehrere Betriebssysteme
• Debug-Varianten

Typischer Anwendungsfall

Schauen wir uns ein konkretes Beispiel an.

Beispiel: Zwei ROMs in einem Gerät

Du möchtest:

• Original-Firmware behalten
• modifizierte Version testen

Dann kannst du:

1. zwei ROM-Dateien laden
2. beiden Slots zuweisen
3. Umschaltung konfigurieren

👉 Ergebnis: Per Jumper oder Signal kannst du zwischen beiden Versionen wechseln.

Eigene ROM-Dateien verwenden

Custom Images leben davon, dass du eigene Daten einbringst.

Typische Quellen:

• ausgelesene EPROMs
• BIN-Dateien aus Projekten
• Firmware-Images aus dem Netz

Wichtig ist:

• richtige Größe
• korrektes Format (meist BIN)

Falls das ROM kleiner ist als erwartet, wird es in der Regel automatisch aufgefüllt.

Grenzen und Besonderheiten

Ein paar Dinge solltest du im Hinterkopf behalten:

• Maximale Gesamtgröße ist durch den Flash begrenzt
• Timing muss zum Zielsystem passen
• nicht jede exotische ROM-Logik lässt sich 1:1 abbilden

👉 In der Praxis funktioniert aber erstaunlich viel „out of the box“.

Wann lohnt sich Custom Image wirklich?

Custom Images sind besonders sinnvoll, wenn du:

• mehrere ROMs ersetzen willst
• viel experimentierst
• eigene Firmware entwickelst
• seltene oder schwer beschaffbare ROMs nutzt

Für einfache Fälle reicht oft ein fertiges Image – aber sobald es individueller wird, führt kein Weg daran vorbei.

Alternative: Vorbereitung am PC

Für komplexere Projekte kann es sinnvoll sein, das Image außerhalb des Browsers vorzubereiten.

Das offizielle Projekt auf one-rom GitHub repository bietet dafür:

• Tools
• Beispiele
• weiterführende Dokumentation

Damit kannst du sehr gezielt und reproduzierbar arbeiten.

Tipps aus der Praxis

• Erst mit kleinen Konfigurationen anfangen
• Schritt für Schritt erweitern
• immer testen, bevor du komplex wirst

Und ganz wichtig:

👉 Funktionierende Konfigurationen abspeichern!

Fazit

Custom Images sind der Punkt, an dem One ROM richtig mächtig wird:

• maximale Flexibilität
• individuelle Anpassung
• viele Einsatzmöglichkeiten

Am Anfang wirkt es etwas komplex – aber nach den ersten Versuchen wird schnell klar, wie viel damit möglich ist.

Ausblick

In einem der nächsten Beiträge könnten wir uns anschauen:

• Multi-ROM-Umschaltung im Detail
• Timing und Kompatibilität
• Einsatz in konkreten Retro-Systemen