Auf dem LCD steht „OSSC fw. 1.08a, 2014-2023 marqs“. Wenn ich ehrlich bin: dieses Banner zeigt mir das Gerät seit Ewigkeiten, ich war einfach nie in der Stimmung das mal aufzuräumen. „Läuft ja“ hat sich da über die Jahre breit gemacht. Seit 1.08a sind inzwischen viele Releases erschienen, der Sprung von 1.10 bis 1.21 hat eine Menge mitgebracht: Lumacode, Shadow-Mask-Presets, ein komplett neu geschriebenes SD-Profil-Handling und ein Stück mehr Display-Kompatibilität. Und ab 1.20 funktioniert sogar das Update selbst endlich vernünftig. Also Zeit, das mal sauber durchzuziehen.
Wer den OSSC nicht kennt: kurz vorweg, warum das Teil bei mir seit Jahren auf dem Tisch liegt und nicht im Karton.
Was ist der OSSC eigentlich?
Der Open Source Scan Converter (OSSC) ist ein FPGA-basierter Line-Multiplier von Markus „marqs“ Hiienkari. Schaltpläne und Firmware liegen komplett offen auf github.com/marqs85/ossc. Auf dem Board sitzt ein Altera Cyclone IV, der analoges Video von Retro-Konsolen und Computern aufnimmt und digital per HDMI wieder ausspuckt. SNES, Mega Drive, N64, PS1/PS2, Saturn, Dreamcast, Amiga, Neo Geo, frühe PCs mit VGA, der C64 über entsprechende Adapter, alles was RGB, Component oder Composite/S-Video raushaut, kommt rein.
Der eigentliche Trick ist nicht das Skalieren an sich, sondern wie der OSSC skaliert. Er arbeitet Zeile für Zeile und benutzt keinen Frame-Buffer. Eine eingehende Scanline wird sofort mehrfach (Line2x, Line3x, Line4x, Line5x) ausgegeben, das war’s. Geräte wie der Framemeister scalen über einen kompletten Frame-Buffer und addieren dadurch im Worst Case einen ganzen Frame Latenz oder mehr. Der OSSC liegt im Bereich weniger Mikrosekunden plus den Pixel-Delay des Displays. Auf einem ordentlichen 1080p- oder 4K-Monitor sieht ein 240p-Konsolensignal damit pixelgenau scharf aus, und das ohne dass sich der Controller anfühlt als hätte er einen halben Sekundenschlaf eingelegt.
Pro Konsole lassen sich Sample-Modi und Custom-Profile abspeichern, dazu kommen optionale Scanline-Simulation und seit den neueren Firmwares Shadow-Mask-Presets, also so eine Art simulierter Lochmasken-Look wie auf einer alten Trinitron-Röhre. Mein Gerät ist eine Hardware-Revision v1.6 mit Audio-Support im roten Acrylgehäuse, also nehme ich die -aud-Variante der Firmware. Mehr dazu gleich beim Flashen.
Auf der Oberseite lesbar: AV1-SCART-IN für RGB-Signale per SCART, AV2-YPBR-IN für Komponenten-Video oder VGA über einen entsprechenden Adapter, AV3 IN als optionaler Composite/S-Video-Eingang. Daneben der HDMI-Out (DVI-kompatibel, mit Audio auf meiner Revision), zwei Taster BTN0 und BTN1 für Navigation ohne Fernbedienung, die JTAG-Pins für Bastler und der für den Update-Vorgang interessante mSD-Slot.
Wofür ich das Ding eigentlich benutze
Bei mir landet der OSSC immer dann auf dem Tisch, wenn alte Hardware an einen modernen Bildschirm soll und dabei auch noch sauber auf dem PC aufgezeichnet werden muss. HDMI raus aus dem OSSC, in einen USB-HDMI-Grabber rein, fertig ist die Aufnahme. Das geht eben nicht nur für die offensichtliche Schiene 386er oder Spielekonsole. Auch ein alter Videorecorder, eine analoge Kamera die ich für jemanden repariere oder einfach mal eben auslesen muss, eine 8-Bit-Maschine die plötzlich wieder einen Use-Case bekommt, all das geht über denselben Weg ins Bild. Mein guter alter C64 hängt mit ein paar Handgriffen am OSSC und ist sofort auf dem 27-Zoll-Monitor zu sehen, statt umständlich einen kleinen Röhrenmonitor aus dem Schrank zu wuchten.
Zwei Beispiele aus meinem YouTube-Kanal, beide via OSSC aufgenommen, damit man sich vorstellen kann was am Ende rauskommt:
Was sich seit 1.08a getan hat
Zwischen meiner alten 1.08a und der aktuellen 1.21 hat marqs in mehreren Releases einiges nachgelegt. Die spannendsten Punkte aus den offiziellen Release-Notes in der Reihenfolge wie sie aufgetaucht sind:
- 1.10: Erste Lumacode-Unterstützung, HDMI-VRR-Flag, reduzierter Sampling-Jitter in den Optimized-Modes, MSX-Sync-Erkennung gefixt, neue High- und Optimal-Sampling-Raten für Passthru.
- 1.11: Lumacode auch für NES, 480p/576p im Line3x-Modus, Settings-Export wieder eingebaut, neue Display-Kompatibilitätsoptionen (ADC-/FPGA-PLL-Bandbreite, HPLL2x-Controls).
- 1.12: Lumacode auf Atari GTIA und VCS erweitert, HDR-Infoframe-Wiederholung gefixt, Default-ADC-PLL-Bandbreite reduziert für mehr Display-Kompatibilität, Full-VSYNC-Bypass für MDA-Karten.
- 1.20: Volle FAT32/exFAT-Unterstützung für die SD-Karte, neues Profil-Format mit deutlich verbesserter Kompatibilität zwischen Firmware-Versionen, Shadow-Mask- und Lumacode-Presets laden und speichern direkt von SD, OSD-Cursor-Farbe wählbar, DIY-Latency-Tester und Panasonic-Hack wieder verfügbar, alternativer Firmware-Slot im internen Flash, 480p/576p-Pillarbox-Option für Widescreen-Displays ohne Aspect-Ratio-Control.
- 1.21: Lumacode-Support finalisiert, Profil-Speichern und -Laden über SD gefixt.
Für mich relevant: das neue SD-Profil-Handling und die paar Display-Kompatibilitätsschrauben. Lumacode ist eine andere Geschichte (ein Trick um Composite-only-Konsolen wie NES oder Atari VCS auf Luma-Ebene farbgetrennt einzulesen, dafür brauche ich aber spezielle Lumacode-Kabel und passe heute eher).
Pre-1.20 heißt: dd, nicht copy
Hier ist der Knackpunkt, an dem viele beim Update straucheln. Der Bootloader auf dem OSSC erwartet die Firmware ab Sektor 0 der microSD, also als rohes Disk-Image. Eine FAT32-Partition mit der .bin drin reicht ihm nicht. Erst ab Version 1.20 wurde der Update-Mechanismus umgebaut, danach genügt der simple Datei-Copy in ein /fw/-Verzeichnis auf einer FAT32- oder exFAT-formatierten Karte. Wer wie ich von 1.08a kommt, muss diesen Schritt einmal mit dd machen, und ab dem nächsten Mal ist die SD-Karte dann nur noch ein Datenträger und kein Bootloader-Trick.
Heruntergeladen habe ich ossc_1.21-aud.bin direkt vom v1.21 Release. Die Datei ist 391 KB groß. marqs liefert in den Releases selbst keine Prüfsumme mit, also habe ich nach dem Download lokal eine SHA256 gezogen, damit ich beim Schreiben weiß dass die Datei nicht unterwegs verstümmelt wurde:
sha256sum ossc_1.21-aud.bin 12703269c8a2e9ff94dfc37b9baa3e2865476196739baa551c0a93a174b18965 ossc_1.21-aud.bin
Dann auf die microSD. Eine beliebige Karte tut es, idealerweise eine kleine die man nicht für etwas Wichtiges braucht, das Image überschreibt eh den kompletten ersten Bereich. dd ist gnadenlos, einmal das falsche Device erwischt und die Systemplatte ist Vergangenheit. Also vorher mit lsblk oder dmesg | tail sicher feststellen, welches /dev/sdX die SD-Karte ist. Bei mir hier /dev/sdc, aber das ist auf jedem System ein anderes Ziel.
sudo dd if=ossc_1.21-aud.bin of=/dev/sdc bs=1M conv=fsync status=progress sudo sync
Kurzer Reminder, weil das hier wirklich wehtut wenn man es verbockt: das of= zeigt auf das ganze Device, nicht auf eine Partition. Also /dev/sdc, nicht /dev/sdc1. Und nicht die Systemplatte erwischen, ich weiß ja nicht ob ich das oft genug schreiben kann.
Am Gerät
Karte raus aus dem Card-Reader, rein in den mSD-Slot am OSSC. Gerät einschalten, mit der Fernbedienung (oder den beiden Tastern am Gehäuse) durch das Menü zu Settings → Fw. update und einmal bestätigen. Der OSSC liest das Image direkt von der microSD, schreibt es ins interne Flash und meldet nach ein paar Sekunden Erfolg. Danach aus, microSD raus, wieder an. Im Bootscreen steht jetzt brav „OSSC fw. 1.21“, und das alte „2014-2023“-Banner ist weg. Kein Drama, keine Fehler, einfach erledigt.
Eine Sache die in den Release-Notes explizit erwähnt wird und auf die man sich einstellen sollte: Profile und Settings sind zwischen Firmware-Versionen nicht garantiert kompatibel. Bei dem Sprung von 1.08a auf 1.21 erst recht nicht. Alles was an Custom-Sample-Phasen, Modi und Per-Console-Tweaks gespeichert war, muss einmal neu konfiguriert werden. Ab 1.20 ist das neue Profil-Format dann deutlich stabiler und überlebt zukünftige Sprünge eher, das war ja Teil des Cleanups in dem Release.
Ab 1.20 wird’s bequem
Das nächste Update bekomme ich jetzt geschenkt. Eine FAT32- oder exFAT-formatierte microSD, ein Ordner /fw/ im Root, die .bin reinkopiert, Karte in den Slot, im Menü das Update starten. Kein dd, kein „war das jetzt das richtige Device“, keine Karte die ich danach erst neu formatieren muss damit andere Geräte sie wieder anfassen. Das einmalige Holperstück dd war also nur weil ich so lange mit der alten Firmware unterwegs war. Wer schon auf 1.20 oder 1.21 ist, kommt nie wieder in die Verlegenheit.
Fazit
Der Aufwand für so ein Firmware-Update ist überschaubar, der Effekt aber spürbar. Ein paar weniger Display-Quirks, ein wirklich brauchbares Profil-Handling und das gute Gefühl dass das Gerät auf dem aktuellen Stand ist, das ein Hobby-Entwickler aus Finnland inzwischen über zehn Jahre pflegt. Open Source Hardware in der Praxis: ein einzelner Mensch, ein offenes Repository, ein FPGA und eine kleine Community von Retro-Enthusiasten die das Ding am Leben halten. Genau die Sorte Projekt, die ich gerne unterstütze, sei es nur indem ich auch mal Bug-Reports oder Erfahrungen rausschicke.
Wer selbst einen OSSC zu Hause hat und noch auf einer Firmware vor 1.20 ist, dem kann ich nur raten: einmal die saure dd-Pille schlucken und auf 1.21 hochziehen. Ab dann ist Updaten so langweilig wie Datei kopieren, und genau so soll es ja sein.
Siehe auch: TC1 Multifunction Tester: Open-Source-Firmware flashen (anderes Gerät, gleiches Open-Source-Spielprinzip), Commodore Floppy Disk Preservation mit xum1541 (für die C64-Diskettenseite des Retro-Stacks) und VC-64 Turbo Tape (1986).
Fragen oder eigene OSSC-Geschichten? Einfach melden.
Schreibe einen Kommentar