One ROM – Praxisbeispiel: Junior Computer

One ROM – Praxis: Junior Computer mit RAM- und ROM-Erweiterung

Dieses Praxisbeispiel stammt von einem Forumsmitglied („obbi“) und geht deutlich über einen einfachen ROM-Ersatz hinaus:

👉 Ziel war es, einen Elektor Junior Computer gleichzeitig mit zusätzlichem RAM und einem One ROM aufzurüsten.

Ausgangssituation: Erweiterung wie in den 80ern

Der Junior Computer war von Anfang an modular gedacht:

• Erweiterungen über Systembus
• RAM- und ROM-Karten optional
• Aufrüstung oft schrittweise (Kosten!)

Damals üblich:

• kleine SRAM-Bausteine (z. B. 6116 → 2 kB)
• EPROMs der 27xx-Serie

👉 Große Speicher waren schlicht teuer.

Der erste Ansatz

Bereits vor dem One ROM hatte obbi sein System erweitert:

• Einsatz eines 62256 (32 kB SRAM)
• Zusammenlegen von TM + PM in ein einzelnes EPROM

👉 Dadurch wurde ein Sockel frei.

Die Idee:

• diesen Sockel mit One ROM nutzen
• zusätzlich RAM bereitstellen

Problem: RAM und ROM gleichzeitig

Hier kam die erste wichtige Erkenntnis:

👉 (Aktuell) kann One ROM nicht gleichzeitig RAM und ROM in beliebiger Kombination bereitstellen

Zusätzlich:

• nur begrenzte SRAM-Emulation möglich
• nicht ausreichend für das gewünschte Setup

Neue Strategie

Statt alles über One ROM zu lösen:

Plan:

1. 32 kB SRAM (62256) separat
2. One ROM für TM + PM + weiteres ROM

Adressbereiche:

• RAM: 0x2000 – 0x9FFF
• ROM: 0xA000 – 0xDFFF

👉 Klassische Speicheraufteilung

Die eigentliche Herausforderung: Adressdekodierung

Hier wird es spannend – und lehrreich.

Ausgangspunkt:

Adressleitungen:

• A15, A14, A13

Ziel:

• Auswahl von:
  • Board
  • RAM
  • ROM

Wahrheitstabelle

Die ursprüngliche Tabelle beschreibt, welcher Bereich wann aktiv ist.

Das Problem:

👉 Die direkte Umsetzung ist komplex
→ viele Gatter nötig

Vereinfachung durch Kompromisse

Um die Logik handhabbar zu machen, wurden bewusst Vereinfachungen akzeptiert:

• Reset-Vektor nicht zwingend im Original-ROM
• etwas „Verschnitt“ im RAM
• Spiegelungen im Adressraum erlaubt
• weniger parallele ROMs

👉 Klassischer Trade-off:
einfachere Hardware vs. perfekte Speicheraufteilung

Ergebnis: Stark vereinfachte Logik

👉 nur noch notwendig:

• 3 Inverter
• 1 AND
• 1 OR

Trick: Alles mit NAND-Gattern

Da:

👉 NAND = universelles Gatter

kann man das OR ersetzen durch:

• Kombination aus NAND

Ergebnis:

👉 ca. 6 NAND-Gatter (≈ 1,5× 7400) reichen aus

Alternative Lösung

Später fiel auf:

👉 Ein 74145 wäre ebenfalls geeignet gewesen
(Open Collector!)

👉 aber:
Die diskrete Lösung wurde trotzdem umgesetzt

Umsetzung

• zusätzliche Logik auf kleiner Zusatzplatine
• Kombination aus SRAM + One ROM
• saubere Integration ins System

Besonderheit: 27xx vs. 23xx ROM-Typen

Ein weiteres Problem:

• Junior erwartet 27xx EPROMs
• One ROM Multi-Sets → 23xx Typen

👉 Lösung:

• Sockel per Drahtbrücken angepasst
• vollständig rückbaubar

Konfiguration (One ROM)

{
    "$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": "multi",
            "description": "Junior TMPM",
            "roms": [
			{   	   "file": "C:/Users/oblaenan/Desktop/Junior/Software/junior monitor roms/pmtmx2.BIN",
              			   "description": "TM, PM und PME",
                  		   "type": "2364",
          		           "cs1": "active_low"
			},
			{          "file": "C:/Users/oblaenan/Desktop/Junior/Software/junior monitor roms/Elektor_Junior_ROMx8.bin",
		     		   "description": "Aux + Vektors",
		     		   "type": "2364",
		     		   "cs1": "active_low"
			}
                  ]
        }
    ]
}

👉 aktuell:

• 2× TM/PM
• 8× Monitor-ROM

Ergebnis

👉 Mission accomplished

Das System läuft:

• One ROM liefert TM/PM + Zusatz-ROM
• 32 kB SRAM verfügbar
• stabile Adressdekodierung

Fazit

Dieses Projekt zeigt sehr schön:

👉 One ROM ist nicht nur „EPROM ersetzen“

sondern kann Teil eines größeren Systems sein:

• in Kombination mit SRAM
• mit eigener Adresslogik
• mit durchdachten Kompromissen

Persönlicher Kommentar

Ein besonders schöner Aspekt:

Der Junior lädt zum Experimentieren ein

Und genau das zeigt dieses Projekt:

• ausprobieren
• vereinfachen
• neu denken
• verstehen

👉 Genau im Sinne des Originals.
PS: Hier der Link zum Original-Thread.

Ausblick

Mögliche Erweiterungen:

• komplexere Speicheraufteilung
• alternative Dekoder (74138/74145)
• größere ROM-Sets

TAGS: One ROM

One ROM – Praxisbeispiel: BIOS-EPROM ersetzen

One ROM – Praxis: BIOS-EPROM auf einem 386/486 ISA Mainboard ersetzen

Nach C64, ZX81 und Mikrocontroller-Projekten diesmal eine etwas andere Anwendung:
👉 Einsatz des One ROM als BIOS-EPROM auf einem klassischen PC-Mainboard.

Der Kandidat: Typhoon 486/386 ISA Mainboard

Zum Einsatz kam ein:

• 386DX / 486 ISA Mainboard
• Hersteller: Target Micro (Typhoon-Serie)
• klassisches AT-Design

👉 Als BIOS-ROM ist hier ein STM27C512 verbaut.

Ziel des Umbaus

Das Ziel war denkbar einfach:

• originales EPROM ersetzen
• BIOS bequem per USB programmieren
• keine EPROM-Brenner mehr notwendig

👉 Klassischer One-ROM-Usecase – aber auf PC-Hardware.

Einbau: One ROM statt 27C512

Zum Einsatz kam:

• One ROM (passend für 27C512 / 28-Pin)

Da es mechanisch etwas eng wurde (USB-Stecker!):

👉 einfache, aber effektive Lösung:

• mehrere 28-polige Fassungen übereinander gesteckt
• dadurch genügend Höhe geschaffen

👉 Klassischer Bastler-Trick – funktioniert erstaunlich gut 😄

Programmierung: WebUSB mit Edge

Das BIOS wurde direkt über das Web-Interface programmiert:

• Browser: Microsoft Edge
• Verbindung über WebUSB
• Image auswählen und flashen

👉 Kein zusätzliches Tool notwendig

Ablauf in der Praxis

Der typische Workflow:

1. BIOS-Image vorbereiten
2. One ROM per USB verbinden
3. im Web-Interface flashen
4. USB abziehen
5. Mainboard starten

👉 Danach läuft das System direkt mit dem neuen BIOS.

Warum das hier besonders interessant ist

Im Gegensatz zu vielen Retro-Systemen:

👉 arbeitet ein PC-BIOS oft sehr timingkritisch

Und trotzdem:

• das One ROM funktioniert hier problemlos
• ersetzt das originale EPROM vollständig

👉 Das zeigt, wie robust das Konzept ist.

Typische Vorteile in diesem Setup

• 🔁 schnelles Testen verschiedener BIOS-Versionen
• 🔧 kein EPROM-Brenner nötig
• 🧪 ideal für Experimente mit alten Boards
• ♻️ kein Verschleiß an Sockeln durch häufiges Wechseln

Mechanische Besonderheit

Der „Sockel-Turm“ ist hier kein Bug, sondern Feature:

👉 ohne zusätzliche Höhe würde:

• der USB-Stecker nicht passen
• oder mechanisch kollidieren

👉 Die Lösung mit gestapelten Fassungen ist:

• schnell
• reversibel
• völlig ausreichend

Kleine Einschränkungen

Wie bei allen One-ROM-Setups:

• USB während Betrieb nicht sinnvoll nutzbar (Standard-Firmware)
• nach Flashen → Neustart notwendig

👉 Für BIOS-Tests aber absolut unkritisch.

Fazit

Dieses Beispiel zeigt sehr schön:

👉 One ROM funktioniert nicht nur in klassischen 8-Bit-Systemen
👉 sondern auch in PC-Hardware wie 386/486 Mainboards

Und wieder gilt:

• weniger Aufwand
• mehr Flexibilität
• schnelleres Arbeiten

Persönlicher Eindruck

Gerade bei alten PC-Boards, bei denen man:

• BIOS-Versionen testet
• Reparaturen durchführt
• oder einfach experimentiert

ist das One ROM ein extrem praktisches Werkzeug.

Ausblick

Mögliche Erweiterungen:

• mehrere BIOS-Versionen per Bank Switching
• Debug-BIOS + Original parallel
• Kombination mit Diagnosekarten

💡 Update: One ROM mit hochgestelltem USB-C – ideal für enge Einbauorte

Für meinen Aufbau habe ich mir noch mit gestapelten Sockeln geholfen, um genügend Platz für den USB-Stecker zu schaffen.

Inzwischen gibt es jedoch auch One ROM Varianten mit hochgestelltem USB-C-Anschluss.

👉 Das bringt gleich mehrere Vorteile:

• weniger Bauhöhe nötig
• kein „Sockel-Turm“ mehr erforderlich
• mechanisch deutlich stabiler
• sauberer Einbau direkt im ROM-Sockel

Gerade bei klassischen PC-Mainboards, bei denen der Platz zwischen Steckkarten, Netzteil und Laufwerken sehr begrenzt ist, ist das ein echter Vorteil.

👉 Für solche Anwendungen ist diese Variante daher klar die bessere Wahl.

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

TAGS: One ROM

One ROM – PCB Fertigung

Wenn ihr selbst One ROMs fertigen lassen wollt, dann zeigt dieser Beitrag die grundlegende Vorgehensweise: Leiterplattenfertigung mit Bestückung bei JLCPCB (Quick Guide).

Die notwendigen Gerber-Dateien, Stückliste (BOM) und Positionsdatei (CPL) findet man auf der One ROM GitHub-Seite: https://github.com/piersfinlayson/one-rom/

Bei den kleinen Abmessungen der Platinen und gerade dann, wenn man eine größere Stückzahl fertigen lässt (>= 50 Stück), empfiehlt es sich die Platinen auf Panels fertigen zu lassen (wählt Panel by JLCPCB). Beim Panel Typ „V-CUT“ können später die einzelnen Platinen ganz einfach auseinander gebrochen werden. Gebt beim Panel Format 5 Spalten und 2 Reihen an ohne Zwischenabstand (column/row spacing = 0 mm).  Da ein Panel eine Mindestgröße haben muss (70×70 mm), ist hier zusätzlich ein 5 mm breiter Randstreifen oben und unten zu definieren (Edge Rails: On top and bottom size).

ACHTUNG: Nach der Panel-Definition bezieht sich die Stückzahl auf die Anzahl Panels!

Bei einer Mindestabnahmemenge von 5 Panels bekommt man 50 fertig bestückte One ROMs für ca. 190,- EUR inkl. FedEx Express Versand. Da kommen dann noch Steuer und Gebühren dazu, und am Ende zahlt man insgesamt ca. 240,- EUR. Damit kostet dann ein One ROM ca. 4,80 EUR.

Die noch fehlenden Rundloch Stiftleiten können günstig bei AliExpress erworben werden.

TAGS: One ROM

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.

Meine Konfiguration

{
  "major_version": 0,
  "minor_version": 6,
  "patch_version": 8,
  "build_number": 1,
  "commit": [
    97,
    55,
    100,
    57,
    53,
    52,
    102,
    0
  ],
  "stm_line": "Rp2350",
  "stm_storage": "Storage2MB",
  "freq": 150,
  "overclock": false,
  "swd_enabled": true,
  "preload_image_to_ram": true,
  "bootloader_capable": false,
  "status_led_enabled": true,
  "boot_logging_enabled": false,
  "mco_enabled": false,
  "rom_set_count": 1,
  "count_rom_access": true,
  "boot_config": [
    255,
    255,
    255,
    255
  ],
  "build_date": "Apr  2 2026 18:28:02",
  "hw_rev": "fire-24-e",
  "rom_sets": [
    {
      "data_ptr": 268500992,
      "size": 65536,
      "roms": [
        {
          "rom_type": "Rom2364",
          "cs1_state": "ActiveLow",
          "cs2_state": "NotUsed",
          "cs3_state": "NotUsed",
          "filename": "zx81 version 2 'improved' rom (Sinclair).rom"
        }
      ],
      "rom_count": 1,
      "serve": "AddrOnCs",
      "multi_rom_cs1_state": "NotUsed"
    }
  ],
  "pins": {
    "data_port": "Port0",
    "addr_port": "Port0",
    "cs_port": "Port0",
    "sel_port": "Port0",
    "status_port": "Port0",
    "rom_pins": 24,
    "data": [
      7,
      6,
      5,
      0,
      1,
      2,
      3,
      4
    ],
    "addr": [
      23,
      22,
      21,
      20,
      19,
      18,
      17,
      16,
      15,
      14,
      13,
      11,
      12,
      255,
      255,
      255
    ],
    "cs1": 10,
    "cs2": 12,
    "cs3": 11,
    "reserved2a": 255,
    "reserved2b": 255,
    "reserved2c": 255,
    "x1": 9,
    "x2": 8,
    "ce": 11,
    "oe": 10,
    "x_jumper_pull": 0,
    "swclk_sel": 26,
    "swdio_sel": 27,
    "sel0": 25,
    "sel1": 24,
    "sel2": 26,
    "sel3": 27,
    "sel4": 255,
    "sel5": 255,
    "sel6": 255,
    "sel_jumper_pull": 8,
    "status": 29,
    "extended": 1,
    "data2": [
      255,
      255,
      255,
      255,
      255,
      255,
      255,
      255
    ],
    "addr2": [
      255,
      255,
      255,
      255,
      255,
      255,
      255,
      255,
      255,
      255,
      255,
      255,
      255,
      255,
      255,
      255
    ]
  },
  "parse_errors": [],
  "extra_info": {
    "rtt_ptr": 537399060,
    "usb_dfu": true,
    "usb_port": "Port0",
    "vbus_pin": 28,
    "fire_pio_default": true,
    "runtime_info_ptr": 537395200
  },
  "metadata_present": true,
  "version": {
    "major": 0,
    "minor": 6,
    "patch": 8,
    "build": 1
  },
  "board": "fire-24-e",
  "model": "Fire",
  "mcu_variant": "RP2350",
  "runtime_info_ptr": 537395200
}

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)