Hardware

RISC OS-geeignete Hardware

RISC OS-Hardware – Der aktuelle total subjektive Einkaufsführer

Einführung

Wer hätte das gedacht, dass man für RISC OS-Rechner mal einen Einkaufsführer braucht. In den 80ern und 90ern war klar: teurer ist besser, und zwar in jeder Beziehung. Und meist hatte Acorn auch nur wenige Rechner parallel im Angebot, so dass Entscheidungshilfen meist überflüssig waren.

Aber jetzt ist alles neu, dank der Öffnung des Quellcodes von RISC OS 5 und vielen fleißigen Händen läuft unser allerliebstes Betriebssystem auf einer ganzen Menge Hardware. Hier der aktuelle Überblick.

Preise sind Momentaufnahmen von Reichelt, Watterott, Amazon. Nicht alle Features der Boards werden detailliert besprochen, wenn sie unter RISC OS nicht nutzbar sind (z.B. die DSPs bei den TI-Cores, Video-Encoding/Decoding-Funktionen etc.).

Den Raspberry Pi Zero habe ich bewusst ausgespart, da er bis heute nicht in vernünftigen Stückzahlen den deutschen Markt erreicht, so dass man tatsächlich mal ohne langfristige Vorbestellung zuschlagen könnte.

Wer an Benchmarks interessiert ist, wird hier fündig. Nicht besonders übersichtlich und nicht immer aussagekräftig – möglicherweise werde ich da mal eigene Messungen durchführen mit Real-World-Benchmarks – da habe ich schon früher große Erfolge gefeiert.

Raspberry Pi (1)

Der Übersichtlichkeit halber: ich betrachte nur das Modell Raspberry Pi B+.

ARM11 (BCM2835 von Broadcom, ARMv6), 700 MHz, 512 MiB RAM, 100 MBit/s Ethernet (intern über USB angebunden), microSD-Card, Massenspeicher über USB, Video und ggf. Sound über HDMI, zusätzlich noch ein FBAS-Videoausgang (nur über ein 4pol-Miniklinke-Spezialkabel erreichbar), jede Menge I/O-Pins. Derzeitiger Preis: 30€. Für ein Komplettsystem fehlt dann noch ein microUSB-Netzteil, eine microSD-Karte und ein Gehäuse. Je nach Qualitätsanspruch landet man so bei etwas über 50€, mehr geht natürlich immer.

Nachdem die großen Brüder Raspberry Pi 2 B und 3 B(+) nur wenig teurer ist, stellt sich natürlich die Frage, was denn überhaupt noch für “das Original” spricht. Die Antwort ist RISC OS-spezifisch: Rückwärtskompatibilität, und verhältnismäßig geringer Performancenachteil. Ersteres, weil der ARM11 noch eine ARMv6-Architektur hat und im ARMv5-Kompatibilitätsmodus betrieben werden kann (unter anderem wird dadurch das “alte” Verhalten bei den rotated loads bei unaligned addresses wieder wirksam), was ihn ohne weitere Umstände (wie z.B. Aemulor) weitestgehend kompatibel zu jeder IYONIX-Software macht. Zweiteres, weil RISC OS auf den späteren Modellen nur einen von vier CPU-Cores nutzen kann. So schrumpft der Performancenachteil gegenüber dem 2 B auf vielleicht 30-50% im Realbetrieb. Und die RPi 3-Goodies wie WLAN und Bluetooth sowie der größere Speicher sind unter RISC OS nicht nutzbar oder eher unwichtig. Erst beim 3 B+ sorgt das Gigabit-Ethernet trotz Schmalspur-Anbindung für einen echten Performancevorteil im I/O-Bereich.

Raspberry Pi 2

Auch hier: ich betrachte nur das Modell Raspberry Pi 2 B.

Quad-Core Cortex-A7 (BCM2836 von Broadcom, ARMv7, zumindest in der Version 1.1), 900 MHz, 512 MiB RAM, 100 MBit/s Ethernet (intern über USB angebunden), microSD-Card, Massenspeicher über USB, Video und ggf. Sound über HDMI, zusätzlich noch ein FBAS-Videoausgang (nur über ein 4pol-Miniklinke-Spezialkabel erreichbar), jede Menge I/O-Pins. Derzeitiger Preis: 35€. Komplettsystem also für etwas über 55€.

Die (goldene?) Mitte der Raspberry Pi-Modellvielfalt. Eine ganze Ecke schneller als der Original-RPi, nicht nur aufgrund seines höheren Taktes und des moderneren ARM-Cores, sondern auch weil die Speicherbandbreite erheblich verbessert wurde. In der Theorie wäre es auch die goldene Mitte bei der Kompatibilität: ARMv7 statt ARMv8 und damit bliebe das SWP-Fiasko erspart. Aber: die aktuell verkaufte RPi 2-Variante basiert nicht mehr länger auf dem Cortex-A7, sondern auf dem Cortex-A53 des Nachfolgers RPi 3. Heilige Versionsvielfalt! Version 1.2 ist die “aktuelle” Revision, 1.1 die ursprüngliche und aus RISC OS-Sicht bessere.

Raspberry Pi 3

Auch hier: ich betrachte nur das Modell Raspberry Pi 3 B(+).

Quad-Core Cortex-A53 (BCM2837 von Broadcom, ARMv8), 1200 MHz, 1024 MiB RAM, 100 MBit/s Ethernet (intern über USB angebunden), microSD-Card, Massenspeicher über USB, Video und ggf. Sound über HDMI, zusätzlich noch ein FBAS-Videoausgang (nur über ein 4pol-Miniklinke-Spezialkabel erreichbar), jede Menge I/O-Pins. Derzeitiger Preis: 40€. Komplettsystem also für etwas über 60€.

Kaum teurer als ein Raspberry Pi 2, dafür deutlich schneller – was spricht gegen einen Kauf? Leider die ungelöste Kompatibilitätsfrage. Der Cortex-A53 gehört zu den Kernen auf Basis der ARMv8-Architektur. Und – leider schon Gewohnheit – hat uns hier ARM wieder ein Kompatibilitätsei ins Nest gelegt, diesmal wurde kurzerhand der Befehl SWP entfernt, der seit ARMv2a (ARM3) verfügbar war. Was noch schlimmer ist: eigentlich gibt es gar keinen richtigen Ersatz. Auch ungünstig: die UnixLib verwendete diesen Befehl, zahlreiche andere Software auch. Das heißt: nach 26bit->32bit und 32bit->ARMv7 steht die nächste Recompilieraktion an. Danke dafür, ARM.

Inzwischen ist die meiste noch gepflegte Software kompatibel, aber in den Weiten des Internets gibt es natürlich noch jede Menge vom alten Zeug, über das der unbedarfte Benutzer stolpern kann.

Seit März 2018 hat die Raspberry Pi Foundation nochmal nachgelegt: der RPi 3 B+ hat das Licht der Welt erblickt. Traditionell blieb der Preis unverändert. Aufgerüstet wurde vor allem die CPU (1,4 GHz statt 1,2 GHz, und mit Heatspreader ausgestattet), WLAN (uninteressant für RISC OS), und endlich ist Gigabit LAN mit an Bord – mit kleinem Haken: intern weiterhin über den einzigen USB2.0-Kanal angebunden, kann man natürlich das Gigabit nichr ausreizen. Trotzdem kann man den Geschwindigkeitsgewinn unter RISC OS deutlich spüren. Hier habe ich kurz zusammenfassend über den RPi 3 B+ berichtet und über dessen 4K-Video-Fähigkeit referiert.

ARMX6

Der ARMX6 von R-Comp ist ein Vertreter der Komplettsysteme aus dem schönen Britannien. Das Herz ist ein Freescale i.MX6, der auf einem Wandboard Quad lebt. Quad-Core Cortex-A9 (ARMv7), 1000 MHz, 2048 MiB RAM, Gigabit Ethernet (intern limitiert auf 480 MBit/s), S-ATA (ein Port).

Der ARMX6 ist insofern etwas besonderes, weil er die erste Maschine ist, die den IYONIX in praktisch jedem relevanten Punkt performancetechnisch entweder erreicht oder deutlich übertrifft. So erlaubt die Videosektion zum Beispiel auch den Betrieb bis zu 4K-Auflösungen bei 30 Hz. Der S-ATA-Port ist schneller als die UDMA100-IDE-Schnittstelle des IYONIX. Endlich gibt es wieder Gigabit Ethernet, das zudem nicht über CPU-fressendes USB angebunden ist (auch wenn intern im i.MX6 der Durchsatz auf 480 MBit/s limitiert ist, was er im IYONIX theoretisch nicht ist, aber durch die PCI-Anbindung auch nicht turboschnell war).

Aber es gibt auch Haken. Der exorbitante Preis beispielsweise. Dass nur ein S-ATA-Port verfügbar ist und man deshalb leider nur eine Platte bei anständiger Geschwindigkeit betreiben kann und nicht z.B. auch einen Blu-Ray-Brenner (ok, ein möglicherweise etwas egoistischer Kritikunkt http://www.hubersn-software.com/). Inzwischen gibt es bei ROOL aber “freie” ROMs für das Herz des ARMX6, das Wandboard Quad. Das könnte die Sache deutlich preiswerter gestalten.

Weitere Details bei R-Comp (wobei: mehr relevante Details als in diesem kleinen Abschnitt stehen dort auch nicht).

Man sollte sich übrigens nicht zuviel vom versprochenen “impressive software bundle, comprising both commercial and custom-written software” erwarten. Das Disc-Image ist zwar durchaus gut strukturiert und reichhaltig, besteht aber zu weiten Teilen aus der bekannten freien und kostenlosen Software der RISC OS-Welt. Wenn ich mal Zeit habe, werde ich das genauer auseinanderdröseln.

IGEPv5 (und RapidO-Ig)

Das IGEPv5 von ISEE war das erste erhältliche Board auf Basis der OMAP5-Plattform von TI. Dual-Core Cortex-A15, 1500 MHz, je nach Variante 1 GiB oder 4 GiB RAM, Gigabit Ethernet, S-ATA, USB3.0. CPU-technisch zusammen mit dem Titanium die derzeitige Spitze der verfügbaren RISC OS-Hardware. Und zwar nicht nur aufgrund des höchsten Takts, sondern aufgrund der überlegenen inneren Struktur des Cortex-A15 gegenüber seinen diversen Vorgängern (und teilweise auch Nachfolgern). Der Cortex-A15-Core wird grob mit 3,5 DMIPS/MHz angegeben, der Cortex-A9 hingegen mit lediglich 2,5 DMIPS/MHz, der Cortex-A8 mit gar nur 2,0 DMIPS/MHz. Und tatsächlich zeigen die Benchmarks auch entsprechende Unterschiede. Aus ARMs Sicht war der Erfolg des Cortex-A15 durchwachsen, denn die hohe Geschwindigkeit wurde mit einem für ARM-Verhältnisse hohen Strombedarf erkauft, was in den Zielmärkten nicht auf viel Gegenliebe stieß. Aber bei einem stationären Rechner

Die USB3.0-Fähigkeit ist im Moment noch akademisch, da keine RISC OS-Treiber verfügbar sind.

CJE Micro’s bietet das IGEPv5 als Teil eines fertig konfigurierten Systems in verschiedenen Gehäusen an. CJE verwendet die 4 GiB-Variante des Boards, unter RISC OS sind derzeit 2 GiB davon nutzbar. Preise ab 725 UKP.

Der OMAP5 hält übrigens noch eine weitere Herausforderung für RISC OS bereit: die RGB-Byte-Order im Bildschirmspeicher hat sich geändert. Alle Programme, die direkt in den Bildschirmspeicher schreiben, müssen angepasst werden (beispielsweise Artworks). RISC OS-interne Mittel wie Sprites wurden natürlich angepasst. Das ist generell ein schon länger schwelendes Problem, das auf anderen Plattformen wie dem IYONIX oder schon beim Risc PC mit ViewFinder durch mehr oder weniger clevere Hardware- und Software-Tricks vermieden wurde.

Titanium (und TiMachine und RapidO-Ti)

Das Titanium-Board wurde von Elesar Ltd. (dahinter steht Robert Sprowson aka Sprow) entwickelt auf Basis der OMAP5-Plattform von TI. Dual-Core Cortex-A15, 1500 MHz, 2 GiB RAM, Gigabit Ethernet, S-ATA, USB3.0, Dual-Head DVI. Dazu 2 PCIe-Steckplätze, für die es tatsächlich auch schon eine Karte mit RISC OS-Treibern gibt – der klassische Parallel-Port. 8 MiB Flash-ROM ist auch an Bord, mehr als ausreichend für das RISC OS-Image. Es gibt 4 S-ATA-Ports, die voll von RISC OS unterstützt werden. Zwei serielle Ports sind auch noch mit dabei.

Das Board ist vom Formfaktor her ATX-kompatibel, ein entsprechendes ATX-Shield für Standardgehäuse ist erhältlich. Neben RISC OS wird auch Linux gepflegt, man kann Linux direkt aus RISC OS heraus starten. Das nackte Board gibt es für 500 UKP.

Auf Basis des Titanium-Boards gibt es fertige Systeme von CJE Micro’s (RapidO-Ti) ab 900 UKP und von R-Comp (TiMachine) ebenfalls ab 900 UKP. Deutschen Usern lege ich a4com ans Herz, dort habe ich mein Titanium-System zusammenbauen lassen.

Schön am Titanium-Board: man kann direkt von RISC OS Open Ltd. die RISC OS-Images holen, alles ist komplett offen, vom Ethernet-Treiber bis zum neuen ADFS mit S-ATA-Unterstützung.

Ein Haken ist die eher sparsame Unterstützung für zeitgemäße Bildschirmauflösungen. Bei Full-HD ist quasi Ende bezüglich der gängigen Auflösungen, weder QHD noch 4K werden unterstützt. Aber: das Dingens unterstützt Dual Head. Mit bestimmten Monitoren, der zwei Videoeingänge “side by side” darstellen können, gehen dann doch wieder 4K – habe ich aber noch nicht selbst geprüft.

Hier habe ich von meinen ersten Erfahrungen mit dem Titanium berichtet.

BeagleBoard-xM

Der Urvater der RISC OS-geeigneten SBCs (ok, das nicht-xM-Modell ist noch uriger). TI OMAP3 Cortex-A8 (ARMv7), 1000 MHz, 512 MiB RAM, 100 MBit/s Ethernet (intern über USB angebunden), microSD-Card, Massenspeicher über USB, Sound nur analog, zusätzlich noch ein SVideo-Videoausgang. Derzeitiger Preis: knapp über 150€. Das einzige einfach erhältliche Gehäuse liegt bei 8€, dazu ein 5V-Netzteil mit 2,5mm-Hohlstecker für etwa 10€, eine kleine microSD-Karte (denn da kommt nur das OS drauf) und ein USB-Stick als Massenspeicher, fertig ist das Komplettsystem.

Während die CPU und die Hauptspeichergröße sicher auch heute noch ausreichend für die allermeisten RISC OS-Aufgaben ist, so zeigt die Video-Sektion ihre Schwächen – bei der heute üblichen Full-HD-Auflösung 1920×1080 erreicht das BeagleBoard nur maximal 30 Hz, und das fressen leider nicht alle Monitore. Aus meiner Sicht ist daher das BeagleBoard nicht mehr empfehlenswert, der Raspberry Pi 2 kann eigentlich alles besser. Zudem ist das BeagleBoard-xM auch nur noch schwer erhältlich, weil der Rest der Welt inzwischen das preiswertere BeagleBone Black verwendet, für das aber keine RISC OS-Portierung verfügbar ist.

PandaBoard ES

Der Nachfolger des BeagleBoard. TI OMAP4 mit Dual-Core Cortex-A9 (ARMv7), 1200 MHz, 1024 MiB RAM, 100 MBit/s Ethernet (intern über USB angebunden), SD-Card, Massenspeicher über USB, Sound über HDMI oder analog. Derzeitiger Preis: rund 200€. Dazu ein 5V-Netzteil mit 2,5mm-Hohlstecker für etwa 10€, eine SD-Karte dazu, fertig ist das Komplettsystem – allerdings “nackt”, weil es m.W. derzeit kein preiswertes, fertiges Gehäuse für das gute Stück gibt. Also schnell noch bei a4com ein PIK (Pandaboard-in-Kiste) kaufen.

CPU-technisch ist das PandaBoard ES immer noch sehr gut bestückt. Die Video-Sektion meistert die 1920×1200 bei den üblichen 60Hz ohne Probleme, dann ist aber Schluss. Die Goodies Dual-Head, Bluetooth und WLAN sind unter RISC OS nicht nutzbar.

200€ fürs nackte Board, da muss man schon schlucken – in Anbetracht des nicht sonderlich langsameren Raspberry Pi 2, der zudem sehr breite Unterstützung durch Dritthersteller hat, fällt es schwer, hier eine Empfehlung auszusprechen. Auch die Verfügbarkeit ist eher mau – beim Distributor Digi-Key ist derzeit eine Lieferzeit von 16 Wochen anberaumt. Und die offizielle PandaBoard-Webseite ist auch nicht mehr existent. Keine zukunftsträchtige Empfehlung.

Fazit

Die Qual der Wahl – wann hatte man die schon mal in der langen RISC OS-Geschichte? Meine Empfehlung: überlegen, wo die persönliche Priorität liegt. Preis? CPU-Performance? I/O-Performance? 4K Video? Kompatibilität? Zum Einstieg tut es sicher ein RPi B+, oder bei mehr Experimentierfreude auch ein RPi 3 B+. Wer dann dringend mehr I/O-Performance benötigt, kann sich die preisintensiveren Angebote anschauen.

Alle genannten Plattformen sind übrigens inzwischen dank Adrian Lees Aemulor-tauglich.

Raspberry Pi 3 B+, 4K und RISC OS

Zum Pi-Day (14.3. – mathematisch vorgebildete Leser müssen die englische Datumsnotation berücksichtigen, um den Gag zu kapieren, alle andern müssen zusätzlich Pi auf zwei Nachkommastellen genau kennen) hat die Raspberry Pi Foundation mal wieder nachgelegt und eine neue Modellvariante des allseits beliebten “SBC” auf den Markt geworfen. Gegenüber dem Vorgänger hat sich der maximale Takt leicht von 1,2 GHz auf 1,4 GHz erhöht, der SoC hat einen metallischen Headspreader bekommen um die Wärme besser abführen zu können, WLAN wurde verbessert indem ac unterstützt wird und auch das 5 GHz-Band bedient wird, und es ist nun endlich Gigabit Ethernet an Bord – da gibt es zwar den kleinen Haken, dass es intern weiterhin am USB2.0 hängt und damit physisch auf 480 MBit/s abzüglich USB-Protokolloverhead abzüglich der Bandbreite anderer angeschlossener USB-Geräte limitiert ist, aber nichtsdestotrotz sind die erreichbaren Übertragungsraten dadurch trotzdem deutlich höher als zuvor.

Seit wenigen Tagen gibt es nun im RISC OS-Nightly-Build die erweiterte Version von EtherUSB, die in der Lage ist den Netzwerk-Chip korrekt anzusteuern. Gelegenheit für mich, eine frische RISC OS-Version auf die Pis zu bringen und gleichzeitig mich mal um die passende Ansteuerung meines nagelneuen 4K-Monitors (iiyama G-MASTER GB2888UHSU-B1, ein 28-Zöller mit besagten 3840×2160 Pixeln Auflösung).

4K ist leider keine Auflösung, die der Pi “einfach so” kann, da muss man frickeln. Außerdem hatte ich noch kein passendes MDF für die RISC OS-Seite, und dann war da noch die potenzielle Problematik inwiefern die HDMI-Kabel das mitmachen und inwiefern der HDMI-Switch (nominell 4K-fähig) in die Suppe spuckt.

Der HDMI-Switch machte keine Probleme, die Kabel konnten es ebenfalls, und so präsentiere ich hier nun den 4K@24Hz MDF-Eintrag, erzeugt mit Chris Gransdens Portierung von cvt http://www.riscosports.co.uk/cvt.zip, der zusätzlich MDF-Einträge erzeugen kann (läuft offenbar noch nicht auf dem Pi 3):

# 3840 x 2160 (24.00Hz) Reduced Blanking (CVT)
startmode
mode_name:3840x2160 CVT
x_res:3840
y_res:2160
pixel_rate:209750
h_timings:32,80,0,3840,0,48
v_timings:5,17,0,2160,0,3
sync_pol:3
endmode

Damit der Pi diese Auflösung kann, muss man folgendes in die config.txt bringen (komplette für RISC OS geeignete config.txt, nicht nur die für 4K notwendigen Teile!):

fake_vsync_isr=1
init_emmc_clock=100000000
kernel=RISCOS.IMG

# needed for correct RGB ordering for RISC OS
framebuffer_swap=0

# disable overscan
disable_overscan=1

# Ignore EDID
hdmi_ignore_edid=0xa5000080

# no disabling of HDMI in DPMS mode
hdmi_blanking=0

# 1 = DVI, 2 = HDMI (with sound)
hdmi_drive=2

# 0-11 - 5 is default, try 7 if interferences are seen
config_hdmi_boost=5

# force HDMI screen mode
# group=0: EDID auto detect, group=1: CEA, group=2: DMT
hdmi_group=2

# screen mode
# CEA modes:
# 16 = 1920x1080@60
# 16,31,32,33,34 = 1920x1080@60,50,24,25,30 Hz
# DMT modes:
#  4 = 640x480@60 Hz
#  9 = 800x600@60 Hz
# 16 = 1024x768@60 Hz
# 77 = 2560x1600@60 Hz
# 84 = 2048x1152 reduced blanking
# completely custom mode definition:
# hdmi_cvt=<width> <height> <framerate> <aspect> <margins> <interlace> <rb>
# margins=0 no margins, 1=margins
# aspect=3 16:9, 1 4:3, 5 16:10
# interlace=0 progressive
# rb=1 reduced blanking
# hdmi_mode=87 selects this custom mode for DMT, 65 for CEA
hdmi_cvt=3840 2160 24 3 0 0 1
hdmi_mode=87

# special timings - sometimes needed for specific monitor needs if generic CVT does not work
# hdmi_timings=<h_active_pixels> <h_sync_polarity <h_front_porch> <h_sync_pulse> <h_back_porch> <v_active_lines> <v_sync_polarity> <v_front_porch> <v_sync_pulse> <v_back_porch> <v_sync_offset_a> <v_sync_offset_b> <pixel_rep> <frame_rate> <interlaced> <pixel_freq> <aspect_ratio>
hdmi_timings=3840 1 48 32 80 2160 1 3 5 54 0 0 0 24 0 211190000 3

# only provide the modes specified above
hdmi_force_mode=1

# force larger framebuffer - includes possible overscan!
framebuffer_width=3840
framebuffer_height=2160
max_framebuffer_width=3840
max_framebuffer_height=2160

# pixel frequency limit
hdmi_pixel_freq_limit=400000000

# GPU memory in megabytes, default is 64, minimum is 16
gpu_mem=64

# Set USB power limit to 1,2A for all ports
max_usb_current=1

Es gibt keine Garantie, dass der Pi das abkann. Es gibt Berichte im Netz, dass man das Dingens zusätzlich übertakten muss, sowohl CPU als auch GPU. Bei mir war das im Falle des Pi 3B+ nicht notwendig, bei den anderen Modellen steht der Test noch aus.

Und dann noch für unfallfreie ADFFS-Anymode-Unterstützung folgendes in die cmdline.txt:

disable_mode_changes

Mit diesem Eintrag nagelt man den Pi-Videooutput auf genau eine Auflösung fest und überlässt dem Videoscaler des Pi die Anpassung der RISC OS-Auflösung an die Hardware-Auflösung.

4K ist echt super…auf 28″ vielleicht ein wenig klein, aber ich bin ja noch jung 🙂 Mit demselben MDF-Eintrag kann übrigens auch der ARMX6 (Wandboard Quad) 4K@24 Hz.

Inwiefern höhere Bildwiederholraten funktionieren, muss ich noch prüfen. In Zeiten von LCDs ist deren Nützlichkeit ja aber eher begrenzt, solange der Monitor es syncen kann, da scheint der Iiyama sehr flexibel.

Von RISC OS, ARMX6 und dem Wandboard Quad

Aufmerksame Beobachter der RISC OS-Szene kennen natürlich den ARMX6 von R-Comp, ein schönes wenn auch recht preisintensives Stück Hardware (auf Basis des Freescale i.MX6 auf einem Wandboard Quad sitzend) das als erster RISC OS-Rechner die Plattenperformance des IYONIX pc durch S-ATA zu übertreffen wusste. Schönheitsfehler war immer, dass R-Comp eine “commercial licence” von RISC OS 5 hatte und deshalb nicht verpflichtet war, sofort alle notwendigen Änderungen und Hardwaretreiber usw. an ROOL zurückzuspiegeln.

Offenbar ist jetzt die Zeitschranke für das Feedback der Anpassungen abgelaufen, denn es gibt nun im ROOL-Downloadbereich den i.MX6/Wandboard-Teil, wo ein aktueller Nightly Build zur Verfügung steht.

Endlich gibt es also (sofern das ROM vollständig alle Features abdeckt, das habe ich noch nicht geprüft) für Interessierte eine Low-Cost-Möglichkeit, sich ein RISC OS-Gerät mit anständiger Platten-I/O für überschaubares Geld zusammenzustöpseln. Das Wandboard Quad (die Variante, die S-ATA on board hat) liegt derzeit bei nominell 119US$, in Europa scheint eine noch lieferfähige Bezugsquelle Mouser Electronics zu sein, die haben es für knapp 150€ im Programm. Wobei ich überraschenderweise gesehen habe, dass Watterott im Moment das TI OMAP5432-EVM für unter 200€ verkauft. Aber soweit ich weiß gibt es dafür keine frei verfügbare S-ATA-Implementierung für RISC OS, ist also nur bedingt als Ersatz geeignet, von der Micker-Auflösungsproblematik der OMAP5-Reihe ganz abgesehen.

Inwiefern andere Boards mit i.MX6 damit funktionieren – keine Ahnung. CuBox-i4Pro, SABRE Lite oder das MarS Board wären interessante Kandidaten. Aus der Efika MX6-Serie ist wohl nie was geworden – schade, MX Smartbook und MX Smarttop sahen in der i.MX5-Variante schon sehr elegant aus.

Titanium-Komplettsystem bei a4com

Auf der Suche nach einem Titanium-System (meine Lust auf Eigenbau hielt sich in Grenzen) bin ich mir mit Detlef Thielsch von a4com handelseinig geworden. Im Gegensatz zu den Vorgängerprodukten BIK (BeagleBoard-in-Kiste – in England von R-Comp als “ARMini” verkauft), PIK (PandaBoard-in-Kiste – in England von R-Comp als “ARMiniX” verkauft) und WBK (Wandboard-in-Kiste – in England von R-Comp als “ARMX6” verkauft) sind beim Titanium aufgrund dessen Standard-Konformität – das Board ist kompatibel mit ATX-Gehäusen und ATX-Netzteilen, USB-Ports stehen sowohl intern als auch extern reichlich zur Verfügung, mit 4 S-ATA-Ports kann man problemlos SSD und optisches Laufwerk integrieren ohne auf USB-SATA-Adapter zurückgreifen zu müssen – keine größeren Handstände notwendig.

Folgerichtig bietet a4com nun das “TIK” an, “Titanium-in-Kiste”. Die Preise ab 900 EUR sind geradezu ein Schnäppchen, bei R-Comp zahlt man für die “TiMachine” denselben Betrag in Britischen Pfund, bei fragwürdigem Mehrwert (zum von R-Comp so gelobten tollen Softwarebundle werde ich zu gegebener Zeit ein paar Worte schreiben). Bei CJE sieht es beim RapidO Ti nicht besser aus. Also: das a4com-Angebot ist absolut konkurrenzfähig und empfehlenswert.

So weit, so schön. Für wen ist nun ein Titanium-System erste Wahl? Für alle, die nicht zwingend auf höchste Bildschirmauflösungen angewiesen sind (“dank” des verwendeten TI OMAP5 sind ohne einen Monitor, der die beiden Videoausgänge des Titanium “side by side” anzeigt, maximal 1920×1200@60Hz drin – in Zeiten von bezahlbaren QHD- und 4K-Monitoren definitiv zuwenig) und den anspruchsvollen Preis nicht scheuen. Denn sowohl was CPU-Leistung (der Cortex-A15 ist nicht nur aufgrund der 1,5GHz-Taktung konkurrenzlos, sondern auch bei der Leistung pro Takt mit 3,4 DMIPS/MHz den Cortex-A9-Konkurrenten i.MX6 (Wandboard, ARMX6) und OMAP4 (Pandaboard, ARMiniX) mit lediglich 2,5 DMIPS/MHz weit überlegen – übrigens nicht nur in der Theorie, auch Benchmarks untermauern das) als auch I/O-Leistung (4 S-ATA-Ports, echtes Gigabit-Ethernet – Benchmarks folgen noch) angeht ist ein Titanium-System weit vorne. Für Budget-Fetischisten würde ich eher einen Pi3 empfehlen – 4K-Video, verhältnismäßig schnelle CPU (jedenfalls deutlich vor der Cortex-A9-bestückten Hochpreiskonkurrenz), nur bei der I/O-Leistung (Netzwerk 100MBit/s und über USB2.0, Massenspeicher über SD oder USB2.0) fällt er natürlich deutlich ab – you get what you pay for.

Praxisberichte mit Titanium vs. ARMX6 folgen hoffentlich demnächst.

Das Titanium-Board und die Suche nach dem passenden Netzteil

Der IYONIX pc war bekanntlich das erste RISC OS-taugliche Mainboard, das mit Standard-ATX-Netzteilen zusammenarbeitete. Auf dem langen Weg vom ersten Archimedes (vermutlich war die Parallelschnittstelle die einzige “standardkonforme” Schnittstelle – die serielle war RS423 statt RS232, der Monitorausgang war 9polig aber immerhin signaltechnisch weitgehend “PC-kompatibel”, der Floppyanschluss war zwar Shugart-kompatibel aber eher wählerisch) über den A5000 (IDE, Parallel, Seriell, VGA, Floppy – alles weitestgehend kompatibel zum damaligen PC-Standard, aber immer noch die merkwürdige Acorn-Tastatur mit dem integrierten Busmaus-Anschluss) bis zum A7000 (endlich PS/2 sowohl für Maus und Tastatur) war man immer näher an die Welt der Standardkomponenten und -schnittstellen gerückt. Nur Gehäuse und Netzteil blieben bis zuletzt proprietär.

Mit dem IYONIX pc fielen auch diese beiden Bastionen – die Platine im ATX-Format, und das Netzteil dazu passend. Allerdings stellte sich bald heraus, dass der IYONIX eine echte Mimose war wenn es um die Zusammenarbeit mit der PC-Netzteil-Welt ging. Das Problem: er brauchte zu wenig Strom, vor allem auf dem 12V-Zweig. Und so war es eine gute Idee, das Gehäuse mit Platten und Brennern vollzustopfen, was dann die häufigeren Problemchen beim Kaltstart weitestgehend eliminierte.

Das Titanium-Board von Elesar ist in gewisser Hinsicht der natürliche Nachfolger des IYONIX. Nicht nur, weil das Hauptdesign von derselben Person stammt. Sondern auch weil das Board eben in gewöhnliche ATX-Gehäuse passt und mit ATX-Netzteilen zusammenspielen soll. Soll. Denn ganz so einfach ist es auch diesmal nicht. Die Basisanforderungen scheinen noch einfach zu erfüllen zu sein: ATX 2.3 oder neuer muss es sein, und der Mainboard-Connector ist der ältere 20Pin-Typ, so dass nur Netzteile mit der 20+4-Konfiguration in Frage kommen. 4 S-ATA-Stromstecker wären auch gut, denn das Board unterstützt bekanntlich (und das ist ein echtes Alleinstellungsmerkmal) 4 S-ATA-Geräte. Aber wie immer steckt der Teufel im Detail.

Inzwischen ist die PC-Welt ja bezüglich des Leistungsbedarfs eines Rechners weit enteilt. Unter 400W kann man ja fast nur riskieren, wenn man mit Chipsatz-Grafik auskommt und nicht allzu viele Laufwerke betreiben will. Beim Titanium wäre ein 200W-Netzteil eher angebracht. Und Schaltnetzteile brauchen nun mal in den meisten Konstruktionen eine gewisse Mindestlast, um sicher anzuspringen und stabile Spannungen zu liefern. Ironischerweise gab es zuletzt ein Update an der PC-Front, damit die Netzteile auch die extrem stromsparenden C6/C7-“Deep Power Down”-Modi der Intel-Prozessorgeneration ab Haswell funktionieren.

Drei Netzteile habe ich mit dem Titanium-Board zusammen getestet: ein No-Name-550W-Netzteil, ein be quiet! Pure Power 10 300W und ein be quiet! Straight Power 10 400W. Ergebnis: nur das Straight Power 10 funktioniert ohne Macken und Zucken mit der von mir definierten Minimallast “Titanium-Board und SSD”, die anderen Kandidaten brauchten nicht weniger als 3 Brenner, bis der Startup absolut zuverlässig funktionierte. Ob das mit dem laut Datenblatt “Zero Load Design” zu tun hat, weiß ich nicht – eine Gegenprobe mit dem preiswerteren System Power 8 wäre interessant, das Pure Power 10 hat dieses Feature nicht.

Das Straight Power 10 ist auch sonst eine absolute Empfehlung. Der 135mm-Lüfter ist nahezu unhörbar, es hat absolut ausreichend Anschlüsse für S-ATA-Geräte sowie althergebrachte Molex- und Berg-Stecker (auch in S-ATA-Zeiten oft noch nützlich für Zusatzgeräte wie interne USB-Hubs oder Cardreader). Bisher bin ich so zufrieden, dass das Straight Power wohl auch den Weg in meinen nächsten Selbstbau-PC finden wird. Die fünf Jahre Herstellergarantie sind ebenfalls vertrauenserweckend.

Raspberry Pi – gute Gehäuse, schlechte Gehäuse

Angesichts seiner Einsatzuniversalität türmen sich langsam die RPis bei mir auf dem Schreibtisch. Und so habe ich hier einen Sack voll Gehäuse für die Dinger stehen und kann demzufolge qualifiziert darüber berichten, welche Gehäuse nach meiner Meinung super sind und welche unbrauchbar. Und welche irgendwo dazwischen. Während beim originalen RPi 1 noch praktisch jedes Gehäuse mehr oder weniger brauchbar war, liegt die Sache seit der RPi eine microSD-Karte schluckt etwas anders – die Full-Size-SD-Karte stand so weit aus dem Gehäuse, dass sie problemlos bei jedem Gehäuse wechselbar war, bei der microSD ist die Geschichte komplizierter, zumal nur B+ und B 2 einen Federmechanismus für die Karte haben, während sie beim B 3 nur gesteckt wird. Es gibt Gehäuse, wo man die microSD-Karte schlicht nicht greifen kann um sie herauszuziehen.

Ich betrachte hier nur die Modellvariante B für alle RPi-Varianten.

Das fiktive ideale Gehäuse

Mein Wunschgehäuse wäre stabil, die Innereien einfach zugänglich, mit einfach zugänglicher microSD-Karte, im geschlossenen Zustand GPIO-fähig, stapelbar, schick und in verschiedensten Farben erhältlich (zur einfachen Unterscheidung verschiedener Einsatzzwecke ohne weitere Beschriftung – bei mir am Start: RPi B+, RPi 2, RPi 3, RISC OS, Linux, RetroPi, Kodi…).

Corkea Aluminium-Gehäuse

Mein derzeitiger Favorit. Passgenau, mit anständiger Öffnung um die microSD-Karte auch wieder rauszubekommen, in fünf verschiedenen Farben erhältlich, und beigelegt auch noch ein Satz Kühlkörper sowie ein Schraubendreher. Dazu sauber rechteckig, also auch stapelbar.

Wird bei Amazon.de für 12-13€ verkauft, hier der Link zur schwarzen Variante.

Als Nachteil mag empfunden werden, dass geschraubt werden muss – an Stirnseite und Rückseite jeweils 4 Schrauben halten das Teil bombenfest zusammen, die RPi-Platine wird mit dem Gehäuseboden verschraubt. Aber man kann das Ding halt nicht “kurz mal” aufmachen. Zumal Deckel und Boden etwas hakelig aufeinander geclipst werden.

Offizielles Raspberry Pi-Gehäuse

Auch ein sehr gutes Gehäuse. Komplett gesteckt ohne Schrauben, mit anständiger Öffnung um die microSD-Karte auch wieder rauszubekommen, leider nur in zwei Farben erhältlich, wovon eine der grauenvolle Versuch ist, eine Art Himbeerfarbe darzustellen. Der Deckel weist eine Rundung auf, so dass Stapelung nicht wirklich funktioniert.

Kostenpunkt knapp 10€, hier der Link zur schwarzen/dunkelgrauen Variante bei Amazon.

Obwohl nur gesteckt und aus Kunststoff, ist das Gehäuse durchaus hochwertig und stabil. Braucht man Zugriff auf die GPIOs, kann man entweder den Deckel weglassen oder das Wandelement.

Durchwachsene Gehäuse

  • FabLabShop Holz-, Plexiglas- und Design-Gehäuse – im Prinzip super, wird einfach zusammengesteckt und hält bombenfest, dazu individuell gravierbar und trotzdem preisgünstig. Haken: die microSD-Karte ist faktisch nicht mehr zugänglich ohne das Gehäuse zu demontieren.
  • Tek-Berry Design-Gehäuse – für dieses Gehäuse gibt es einen VESA-Adapter, der eine einfache Montage an der Rückseite eines Fernsehers oder Monitors nach VESA 50/75/100-Standard erlaubt. Dafür ist es extrem schlecht belüftet (die Lüftungslöcher sind zur Unterseite der RPi-Platine hin!) und die microSD-Karte ist kaum zu greifen. Typische Plastik-Snap-In-Befestigung, Auseinanderbau also eher schwierig und lieber nicht so oft aufgrund akuter Gefahr des Abbrechens diverser Plastiknasen. Kostet dafür auch nur knapp 5€. Gibt es in drei “Farben” schwarz, weiß und transparent.
  • Ein namenloses schwarzes Gehäuse – etwas fummelig in der Montage, microSD-Karte kaum zu greifen, dafür preiswert.
  • CamdenBoss Gehäuse in Transparenz-Carbon-Optik – ich hatte noch die Vorgängerversion, wo die microSD-Karte nur nach Gehäuse-Demontage erreichbar war, nach den Bildern zu urteilen ist das nun besser gelöst. Hauptproblem dieses Gehäuses: Snap-In-Montage, und bei der Demontage kann sehr leicht was abbrechen (sprich: bei mir ist was abgebrochen). Die 10€ meiner Ansicht nach nicht wert.

Muss-Ich-Noch-Testen-Gehäuse

Die folgenden Gehäuse stehen noch auf meiner Merkliste und werden irgendwann den Weg ins Testlabor finden.

  • oneninedesign RPi Quattro-Gehäuse – endlich mehr Platz als nur für den RPi selbst!
  • Alu-Gehäuse gibt es in verschiedenen Farben
  • Orbital Case – ein schöner Kontrast zum Rechteck-Boxen-Einheitsbrei, aber der direkte Zugriff auf die microSD-Karte scheint hier auch nicht möglich zu sein

iMX6-HAL erreicht das ROOL-Repository

Ich hatte es früher schon erwähnt: es lohnt sich immer, die Bewegungen im ROOL-Repository im Auge zu behalten. Seit einiger Zeit hat nun endlich der iMX6-HAL seinen Weg dorthin gefunden. Nebenbei: man hofft, dass der Code fehlerärmer ist als die Commit-Kommentare.

Der iMX6, der im Herzen des ARMX6 von R-Comp (und ja, ich würde gerne auf eine ARMX6-Seite verlinken, aber R-Comp ist eben R-Comp) in Form des Wandboard Quad schlägt, erhielt seine RISC OS-Weihen in proprietärer Form von R-Comp. Klar, wer entwickelt, will damit auch Geld verdienen. Die kommerzielle RISC OS-Lizenz von Castle hat für diesen Fall eine Spezialklausel: gegen ein paar Euro (maximal 10 UKP pro verkaufter Lizenz) müssen geänderte OS-Quellen zunächst nicht an ROOL zurückfließen, sondern man kann sich bis zu 2 Jahre Zeit erkaufen. Die waren im Falle des iMX6 jetzt rum.

Nächste Aufgabe: iMX6-ROM bauen aus den aktuellen Quellen.

SCSI2SD – eine schöne Massenspeicherlösung für alte Geräte

Wer meine Vorbereitungen zur CC2016 mitverfolgt hat, kennt das Problem – ein alter Rechner, in den nur alte Platten passen, womöglich SCSI und kein IDE. Wie kriegt man da einen bezahlbaren und zuverlässigen Massenspeicher ran?

Meine CC2016-Lösung bestand darin, eine SCSI-IDE-Bridge mit einem IDE-SD-Adapter zu verbinden. Um es vorsichtig zu formulieren – tut zwar, aber ist teuer und irgendwie auch hässlich. Genauere Recherchen ergaben, dass der Australier Michael McMaster eine optimale Lösung speziell für Retro-Zwecke entwickelt hat: SCSI2SD.

Nun ist SCSI2SD keine “simple” Lösung, die einfach nur unter einer SCSI-ID eine microSD-Karte als Massenspeicher zur Verfügung stellt. Nein, die Lösung ist ungewöhnlich flexibel:

  • Bereitstellung von bis zu vier SCSI-Devices unter konfigurierbaren IDs
  • unter jeder SCSI-ID ist konfigurierbar, welche Bereiche der microSD-Karte bereitgestellt werden (z.B. um alten Betriebssystemen weiszumachen, dass sie eine 2 GiB- oder gar nur eine 512 MiB-Platte angeschlossen haben)
  • konfigurierbar bezüglich Parity und Unit Attention-Verhalten
  • läuft im asynchronen Modus für maximale Kompatibilität
  • kann sich allein über die Termpower des Hostadapters mit Strom versorgen, normalerweise kein extra Stromanschluss notwendig
  • flexible Blockgröße – irgendwas zwischen 64 Bytes und 8 KiBytes

Mein einziger Kritikpunkt ist die suboptimale Performance, es sind so etwa 2,5 MiB/s möglich, was doch deutlich unter dem Maximum des synchronen Übertragungsmodus (10 MiB/s) liegt. Aber seien wir ehrlich: die alten Schätzchen schaufeln ja nicht ständig megabyteweise die Daten über den Bus.

Ich habe die v5-Hardware geordert und derzeit am A3000 in Betrieb. Harmoniert prächtig mit dem HCCS-SCSI-Controller, ich habe 4 Partitionen zu je 499 MB angelegt. Versuche, unter weiteren IDs weitere Geräte zur Verfügung zu stellen und mit MOFS aka MagOpt von Hugo Fiennes anzusprechen, scheiterten. Komisch, bisher kannte ich dieses FS als sehr unempfindlich und kompatibel. Vielleicht habe ich was verkonfiguriert. Aber dabei fiel mir wieder ein und auf, dass es unter RISC OS wirklich an einem generischen, partitionsfähigen Filecore-FS fehlt, wo man einfach untendrunter einen Blocktreiber hängt und fertig ist das FS.

Im Moment ist die v6-Hardware in der Reifephase – schon verfügbar, aber an der Software wird noch gearbeitet. Besondere Features: hat einen SD-Karten-Slot statt microSD-Slot, unterstützt den synchronen Übertragungsmodus und erreicht bis zu 10 MiB/s, kann bis zu 7 SCSI-IDs repräsentieren, kann auch via USB Massenspeicher anbinden.

Bezugsquellen:

Der fast perfekte Retro-Monitor

Hier hatte ich mich schon damit beschäftigt, welche Monitore mit alter Hardware – im Beispiel ein Acorn A3000 – am besten harmonieren und wie man heute erhältliche TFTs an die alten Schätzchen anschließen kann, ohne zuviele Nachteile erleiden zu müssen.

Nach einer Diskussion im stardot-Forum bin ich auf einen aktuell erhältlichen 19″-TFT von BenQ mit dem schönen Namen BL912 aufmerksam gemacht worden. Die Besonderheit: nicht nur kann dieser Monitor problemlos 50Hz vertikal synchronisieren (und eignet sich damit hervorragend für das MIST) und versteht sich auch mit den krummen, nicht-so-ganz-VGA-Signalen eines A3000, nein, die eigentliche Sensation ist: er kann 15kHz-Signale verarbeiten. Also der optimale Monitor für die alten Kisten.

Ich habe das Dingens natürlich sofort geordert und gestern kurz am A3000 im MonitorType 1 (aka “true Multiscan”) getestet. Ergebnis: die 15 kHz-Modi werden einwandfrei dargestellt und per “Auto-Adjust” beim Moduswechsel in sehr kurzer Zeit auch anständig zentriert. Versuche mit diversen guten alten Demos aus der ARM2-Zeit zeigten keinerlei Probleme, auch die Darstellungsqualität (nativ hat das Dingens 1280×1024, also 5:4) war sehr gut. Auch die “nahezu-VGA-Modi” von 25-28 werden einwandfrei dargestellt. Nur bei den “Multiscan-Modi” 18-21 mit 50Hz (640×512) gab es ein “Out of range” – ein nur kleiner Wermutstropfen, denn real stiften die kaum mehr Nutzen als die 640×480-Modi.

Ich konnte noch nicht herausfinden, ob auch CSync funktioniert, der A3000 ist derzeit auf HSync/VSync konfiguriert und gejumpert. Mit dem MIST und 15kHz-Cores (disableter Scandoubler) muss ich auch noch testen.

Ganz billig ist das Teil nicht – für so einen mittelguten 19″er knapp 150€ zu bezahlen ist in Zeiten von 22″er in Full-HD mit Lautsprechern für unter 100€ nur vertretbar, wenn es ein Alleinstellungsmerkmal gibt. Und das ist hier ja zweifellos der Fall.

Monitore am A3000

Auf der CC2016 wurde ich auf das Problem angesprochen, wie man Hardware wie den Acorn A3000 am besten mit einem Monitor verbindet. Aufgrund der Flexibilität des VIDC gibt es recht viele Anschlussvarianten, die ich im Folgenden erörtern will. Bei den späteren Modellen wie dem A540, A5000, A3010, A3020 und A4000 liegt der Fall noch mal etwas anders.

RISC OS 3.1 wird hier mal als Mindestvoraussetzung festgelegt – mit RISC OS 2 ist alles noch viel komplizierter.

Drei Dinge müssen am A3000 eingestellt bzw. konfiguriert werden, je nachdem welchen Monitor man anschließen will. Zunächst ist der “MonitorType” wichtig. Relevant sind hier:

  • MonitorType 0 – TV/RGB/Scart mit 15kHz Zeilenfrequenz und 50Hz Bildwiederholfrequenz, also PAL. Darunter fallen z.B. C64/Amiga-Monitore vom Schlage eines Commodore 1084S oder Philips CM8833, auch Acorn hatte entsprechende Modelle mit dem AKF11 und AKF12 im Angebot; auch RGB-Scart-fähige Fernseher fallen in diese Kategorie
  • MonitorType 1 – ein echter Multiscan-Monitor, der typischerweise eine Zeilenfrequenz von 15-40kHz synchronisieren kann und z.B. zwischen 45Hz und 80Hz Bildwiederholfrequenz unterstützt; Beispiele: Acorn AKF18, AKF50, AKF52 und AKF53, NEC MultiSync II und 3D, Mitsubishi EUM1491, Microvitec Deltascan 1402, Taxan Multivision 7070, Tystar TY-1411, Eizo 9060S, Idek MF-5015/5017/5021, Commodore 1950 (AOC CM314) und 1960
  • MonitorType 4 – “S-VGA” genannt, typischerweise auch Multiscan, aber unterstützt nur Zeilenfrequenzen jenseits der 31kHz, Bildwiederholfrequenzen oft ab 50Hz, manchmal erst ab 60Hz. Im Standardzustand (24 MHz-Quarz für den VIDC) ist der A3000 nicht in der Lage, ein präzises VGA-Signal zu generieren – dazu braucht man dann einen VIDC-Enhancer. Besser ist aber, einen Monitor zu haben, der die etwas krummen Signale des A3000 verarbeiten kann. Und noch ein kleiner Haken: die PAL-Modi werden als “Letterbox-Modus” dargestellt, so dass das Seitenverhältnis meist nicht richtig stimmt – außerdem verdoppelt sich die genutzte DMA-Speicherbandbreite, so dass einige sensible Spiele aus dem Takt kommen bzw.

Zweite wichtige Einstellung: benötigt der Monitor ein kombiniertes Sync-Signal (auch “Composite Sync” oder “CSync” genannt), oder braucht er separate Sync-Signale (HSync und VSync). Hier gibt es zwei Einstellungen softwareseitig beim A3000:

  • Sync 0 – separate Sync-Signale (HSync und VSync)
  • Sync 1 – kombiniertes Sync-Signal (CSync)

Faustregel: MonitorType 0 braucht Sync 1, MonitorType 4 braucht Sync 0, MonitorType 1 kann oft beides mit Tendenz zu Sync 0.

Und leider muss man ggf. auch noch hardwareseitig Jumper setzen, um statt CSync (Auslieferungsdefault) HSync/VSync zu erzeugen. Beim A3000 sind das folgende:

  • LK24 Jumper auf 1-2 (NORTH) – erzeugt HSync statt CSync auf Pin 4 des Videoausgangs
  • LK25 Jumper setzen – erzeugt VSync statt Mode auf Pin 5 des Videoausgangs

Dann gibt es noch zwei Jumper für die Sync-Polarität (LK26 und LK27), ich kenne aber keinen Fall wo man die anfassen musste.

Wenn man kein Bild sieht, ist es oft schwierig, die notwendigen Kommandos zum Umkonfigurieren von Sync und MonitorType zu tippen. Deshalb kann man über die Methode “Taste drücken und gedrückt halten, dann einschalten” sowohl Sync als auch MonitorType konfigurieren. Und das geht so:

  • Power-on-Reset mit “R”: CMOS-Clear und Sync auf 1
  • Power-on-Reset mit “T”: CMOS-Clear und Sync auf 0
  • Power-on-Reset mit “0” auf dem Zehnerblock: MonitorType auf 0
  • Power-on-Reset mit “1” auf dem Zehnerblock: MonitorType auf 1
  • Power-on-Reset mit “4” auf dem Zehnerblock: MonitorType auf 4

Letzter Stolperstein: der A3000 hat den alten 9poligen Sub-D-Stecker als Monitoranschluss. Glücklicherweise funktionieren übliche 9to15-Adapter wie dieser hier problemlos.

Eine absolute Notlösung gibt es auch noch: Verwendung des Chinch-Monochrom-Anschluss – hier wird ein BAS-Signal ausgegeben. Sollte alles, was einen FBAS-Eingang hat, darstellen können (also selbst alte Fernseher ohne Scart mit 6pol.-DIN-Videoanschluss). Hier ist MonitorType 0 Pflicht.