Hardware

RISC OS-geeignete Hardware

Aktuelle Retro-Projekte

Nachdem ich einige alte Acorn-Rechner aus der RISC OS-Frühzeit mein Eigen nenne – vom A310 über den A3000 bis zum A5000 – interessiere ich mich auch für aktuelle Projekte rund um die Retro-Schätzchen. Vor allem die Verbindung der alten Welt mit aktueller Hardware interessiert mich immer – ich bin weniger der Typ für “100% Retro”, sondern will einfach rund laufende Hardware betreiben – ob es Ende der 80er schon Flash-Speicher oder optische Mäuse gab, ist mir eigentlich wurscht, zumal die Originalhardware inzwischen empfindlich teuer ist. Zentrale Informationsstelle ist für solche Projekte das Stardot-Forum Abteilung 32bit. Ich will einige davon kurz vorstellen.

Wie bekannt sein dürfte, ist das Thema “Massenspeicher” ein ständiges Ärgernis. Frühe Rechner wie der A310 oder der A3000 und auch der weit verbreitete A3010 hatten weder das damals noch verbreitete MFM/ST506 an Bord (das gab’s nur in der A4xx-Familie) noch das brandneue IDE und auch nicht die damals gängige Profi-Variante SCSI. Und die späteren Rechner mit IDE on board bis inklusive RiscPC und A7000(+) scheitern häufig an mangelhafter Kompatibilität mit heute wünschenswerten Lösungen wie SD-Cards im IDE-Adapter. Also braucht man ein IDE- oder SCSI-(Mini-)Podule. Nun sind die aber gebraucht eher rar und teuer, und im Falle von SCSI wird es durch das dann sinnvollerweise benötigte SCSI2SD noch teurer.

IanS aus dem Stardot-Forum hat deshalb ein einfaches IDE-Interface gebaut (nach dem Vorbild der alten ICS-ideA-Podules von Ian Copestake) und bietet regelmäßig sowohl Standard-Podules (alle A-Rechner außer A3010, A3020 und A4000) als auch Mini-Podules (A3000, A3010, A3020, A4000) oft inklusive IDE-Flash-Modul an. Als Software kommt John Kortinks ZIDEFS zum Einsatz, das insgesamt bezüglich Laufwerkskompatibilität und Features einen guten Ruf hat. CJE Micro’s bietet die Dinger auch an, allerdings zu den üblichen Mondpreisen.

In die gleiche Kerbe schlägt das Projekt von Dave Hitchins (daveejhitchins im Stardot-Forum), der die alten IDE-Podules von Baildon Electronics (Dave Prosser und Dave Hitchins, verkauft als Arcin und Blitz von APDL sowie als Awesome von MicroDigital) erneut in Kleinserie bauen (lassen) will. “Baildon Electronics IDE Interfaces – Replication” heißt der Thread auf Stardot zum 16bit-Podule (Arcin), und hier der Nachfolgethread zum Arcin32/Blitz/Awesome. Beide Projekte scheinen kurz vor der Fertigstellung zu sein.

Ein ambitioniertes Projekt von Stardot-User myelin hört auf den Namen “Arcflash” – hier der Thread, hier die Hardware und Software auf GitHub. Dahinter verbirgt sich eine Flash-ROM-Lösung für alle Acorn-Rechner vom A310 bis zum Risc PC. Was sich einfacher anhört als es ist, weil die Konfiguration und Position der ROM-Chips eher uneinheitlich sind – zwei oder vier Chips, unterschiedliche Sockelabstände – schwer, da eine universelle Lösung zu finden. Außerdem soll es ja “in situ” neu flashbar sein, und man will einen eigenen Bootloader haben, um beim Booten auswählen zu können, welche RISC OS-Variante man denn haben will. Bisheriger Stand: das Flashen soll über USB funktionieren, 16 MiB Flash-ROM sollen aufs Board, und der Bootloader ist wohl auch schon recht weit fortgeschritten. Zusätzlich wird experimentiert, welche Acorn-Rechner (außer Risc PC und A7000, die das von Haus aus beherrschen) mit 4 MiB ROM statt den üblichen 2 MiB umgehen können, ggf. mit einem kleinen “Patch” des Mainboards. Das Projekt scheint kurz vor der Fertigstellung zu sein.

Sowohl für RiscPC/A7000 als auch für die alten Archimedes-Kisten ist Arcflash hochinteressant. Ironischerweise hilft es auch gegen das Massenspeicherproblem, weil damit sehr einfach ein gepatchtes ADFS ins ROM könnte, das die Kompatibilität zu IDE-Geräten drastisch verbessert. Und bei den alten Rechnern kann man problemlos zwischen Arthur, RISC OS 2 und RISC OS 3.1 umschalten, sowie gegebenenfalls ein aktualisiertes RISC OS 3.2 bauen mit Wünsch-Dir-Was-Komponenten wie Nested WIMP, Toolbox-Modulen und TCPIP-Stack nebst Netzwerkkartentreiber – alles das, was beim Softload auf den Rechnern mit typischerweise maximal 4 MiB RAM richtig schmerzt. Allerdings ist es traditionell eher schwierig, ein funktionierendes ROM-Image zu bauen, umso wichtiger wäre eine Hardware, die in den eher empfindlichen Sockeln verbleiben kann während man am Entwickeln ist.

Und noch ein Projekt: eins der üblichen Probleme für alle Rechner vor dem A7000 ist das Mausproblem, vor dem Risc PC auch das Maus- und Tastaturproblem. Denn vor PS/2 gab es Acorn-proprietär (Tastatur) und Busmaus (eher selten im Rest der IT-Welt). Wäre es nicht super, wenn man – ohne absurde Mengen Geld in ein USB-Podule zu stecken oder einen der seltenen und teuren PS/2-Adapter zu ergattern – einfach so eine x-beliebige USB-Maus anschließen könnte? Genau das will Stardot-User cmj6502 per Podule lösen. Scheint aber eher noch in einem frühen Stadium zu stecken – Hardware steht, aber die Software noch nicht.

Zuletzt noch ein interessantes Projekt für die Hardware-Reparier-Front: zu Acorn-Zeiten gab es ein wirklich seltenes Stück Hardware namens “POST box”. Standardmäßig haben die Acorn-Rechner einen Selbsttest, und wenn der fehlschlägt, blinkt die Floppy-Lampe ein Binärmuster um den Zustand dieses Selbsttests zu signalisieren. Es werden aber viel mehr Informationen während des Selbsttests vor dem eigentlichen Bootprozess generiert, und eben diese sind über den POST-Port verfügbar. Es sind Bemühungen im Gange, diese POST Box nun nachzubauen auf Basis eines kleinen preiswerten Microcontroller-Boards. Hier das zugehörige Projekt auf GitHub.

Wie man sieht: die Retro-Szene ist auch im RISC OS-Bereich aktiver denn je. Es bleibt spannend.

In gespannter Erwartung: Raspberry Pi 4 ante portas

Update 2019-06-30: Ethernet-Anbindung korrigiert, USB3-Anbindung präzisiert, Cachegrößen nachgepflegt, USB-Strombegrenzung aus dem Datenblatt erwähnt, Dual-Head-Unklarheit bezüglich 4K@60Hz erwähnt.

Die Raspberry Pi Foundation hat mal wieder alle überrascht (und vorher auch reichlich Nebelkerzen geworfen, im Einklang mit Broadcom): der brandneue Raspberry Pi 4 ist ab sofort verfügbar, und er basiert weiterhin auf einem Broadcom-Chip. Nach dem RPi 3B+ wurde ja reichlich spekuliert, dass die Broadcom-Reihe nun ausgereizt sei und man möglicherweise sogar auf einen anderen SoC-Hersteller wechseln müsse. Pustekuchen.

Was steckt drin, vor allem im Unterschied zum 3B+? Die Kurzfassung: ein BCM2711 (Quad-Cortex A72@1,5 GHz), Gigabit Ethernet über einen schnellen internen Bus angebunden, USB3.0 über PCIe, Dual-Head mit je 4K@60Hz-Unterstützung (einzelne Quellen sprechen allerdings auch davon, dass im Dual-Head-Betrieb nur je 4K@30Hz möglich wären, eventuell ist das aber nur eine vorübergehende Treiberschwäche), und Modelvarianten mit 1, 2 oder 4 GiB RAM das zudem als LPDDR4-2400 ausgeführt ist. Und da man wegen der 2x microHDMI für Dual-Head-Unterstützung sowieso nicht mehr kompatibel zu den alten Gehäusen sein konnte, hat man die Stromversorgung nun auf USB Typ C umgestellt – endlich nicht mehr peilen, wie rum der microUSB-Stecker rein muss…warum man auch noch die Position von Ethernet und USB getauscht hat, erschließt sich hingegen nicht direkt, eventuell wegen der Positionierung der PoE-Pins.

Also: neues Netzteil (das offizielle Netzteil leistet 15W – durch 2x USB3 statt den bisherigen USB2 liegt allein der Stromverbrauch bei voller Auslastung durch angeschlossene USB-Geräte ja schon 800mA höher, weil USB3 900mA zusichert, gegenüber 500mA bei USB2 – irritierenderweise redet das vorläufige Datenblatt von einem Limit in Summe über alle 4 Buchsen von 1,1A – das ist so niedrig, dass ich einen Druckfehler vermute), neues Gehäuse, neue HDMI-Kabel sind angesagt. Die microHDMI-Buchsen liegen relativ nah beieinander, von einer Adapterlösung microHDMI-auf-Standard-HDMI würde ich nach erster Betrachtung eher abraten, das könnte platztechnisch eng werden.

Was kann man über die Performance sagen? Eigentlich nur Gutes. Obwohl die CPU taktmäßig nur einen kleinen Sprung gemacht hat, gilt der Cortex-A72 pro MHz als deutlich leistungsfähiger gegenüber dem vorher verwendeten Cortex-A53 im Pi 3. Grob sagt man dem Cortex-A53 etwa 2,3 DMIPS/MHz nach, dem Cortex-A72 hingegen 4,6 DMIPS/MHz. Erreicht wird das durch die üblichen Maßnahmen, die die x86-Welt seit Jahren vormacht: tiefere Pipeline, bessere branch prediction, ausgefuchsteres Out-Of-Order-Execution-Handling, mehr Parallelisierung beim instruction decoding. Und weil gleichzeitig ein Prozess-Shrink bei der Fertigung mit einfloss (28nm statt 40nm), soll der Stromverbrauch sich weiterhin in einem ähnlichen Rahmen wie bisher bewegen. Erste Messungen zeigen ähnlichen Stromverbrauch bei Volllast und etwas Höheren in Ruhe – welcher Anteil da auf die CPU entfällt, was auf den neuen Videocore VI und was auf den Rest vom Board – keiner weiß es im Moment.

Zu den CPU-Caches gibt es ebenfalls positive Details zu vermelden. Der Cortex-A72 hat 48 KiB instruction cache und 32 KiB data cache zu bieten auf der L1-Ebene, und 1 MiB L2-Cache – das ist deutlich mehr als der Cortex-A53 des RPi 3 B(+) zu bieten hatte (16 KiB I+16 KiB D-L1, 512 KiB L2). Die ersten Linux-Benchmarks zeigen einen Nettogewinn von 60-80%, was darauf hinweist, dass sowohl das schnellere RAM als auch die größeren Caches ausreichen, um die CPU-internen Fortschritte nicht über Gebühr auszubremsen.

Dadurch, dass nun das Gigabit-Ethernet endlich vom USB2 weg ist und an einen eigenen High-Speed-Bus direkt am SoC angedockt wurde, steigert sich der Netzwerkdurchsatz laut ersten Messungen nahe an das theoretische Maximum von 1 Gbit/s, während vorher eher so 300 MBit/s angesagt waren. Und vor allem kollidiert das nicht mehr mit dem USB-Massenspeicher – bisherige Pis hatten alles an einem einzigen USB-Kanal.

USB3 ist für heutige Massenspeicher wie schnelle SSDs natürlich auch ein gewaltiger Fortschritt, von theoretisch 480 MBit/s auf 4 GBit/s Durchsatz. Durch die Anbindung sowohl des USB2-Hosts und des USB3-Hosts über PCIe ist hier eine signifikante Performanceverbesserung drin. Mal sehen, was davon in der Praxis übrigbleibt, bei Konkurrenz-ARM-Boards gab es da öfter mal böse Überraschungen.

Das neue RAM-Maximum von 4 GiB ist vermutlich aus RISC OS-Sicht die unwichtigste Verbesserung – schon das eine GiB ist doch die meiste Zeit leer. Aber wer weiß, wenn es mal eine aktuelle Browser-Portierung gibt…ob RISC OS überhaupt so ohne weiteres mit den 4 GiB klarkommen wird, ist momentan noch unklar – bisher lag das Maximum bei 2 GiB. Der Preisaufschlag für 4 GiB statt 1 GiB liegt z.B. bei Reichelt Elektronik bei nicht ganz zu vernachlässigenden 21€.

Für RISC OS ebenfalls nicht so interessant, aber bei Einsatz als Mediacenter nützlich: die eingebauten Hardware-Decoder im neuen Videocore VI können nun H.265 in 4K@60Hz decodieren.

Und der Vollständigkeit halber: Bluetooth ist jetzt bei 5.0 angelangt gegenüber 4.2 beim Vorgängermodell. WLAN wie bisher – 802.11ac in der 2,4- oder 5-GHz-Variante.

Ich bin gespannt, wie die Praxis-Benchmarks unter der besonderen RISC OS-Situation aussehen werden. Es steht zu erwarten, dass die bisherigen Performancekönige Titanium und IGEPv5 zumindest CPU-technisch die Krone abgeben müssen, da deren Cortex-A15 typischerweise mit 3,5 DMIPS/MHz eingeordnet wird. Ebenso spannend, an welchen Stellen RISC OS das Gebotene wirklich ausnutzen kann – der TCPIP-Stack ist nicht bekannt für Top-Performance, mal sehen was da vom echten Gigabit übrig bleibt. USB3-Unterstützung gibt es im USB-Stack bisher noch gar nicht – umso wichtiger, dass das USB-Stack-Update-Bounty mal in die Gänge kommt. Bei Bluetooth und WLAN bleibt die Situation so traurig wie zuvor. Ob der Cortex-A72 ein paar Überraschungen bereithält, wie es beim Cortex-A53 bei einigen ARMv8-“undefined behaviour”-Dingen passiert ist, ist noch unbekannt.

Nicht unwichtig für uns RISC OSler: die Foundation sichert zu, dass der RPi 4 bis Januar 2026 “in production” bleiben wird. Wenn das mal keine guten Zukunftsaussichten sind. Denn es wird zunehmend unwahrscheinlich, dass es bei 32bit ARM-Geräten in der Zukunft noch große Sprünge geben wird, weil der Rest der Welt mit Riesenschritten zu AArch64 wechselt. Was aus RISC OS-Sicht im Prinzip einem Wechsel auf x86 oder AMD64 entspricht.

Außerhalb der RISC OS-Welt ist der RPi nun wieder ein ernstzunehmender Kandidat für allerhand Anwendungsfälle, die zuletzt eher zur Konkurrenz abgewandert sind – vom NAS übers Mediacenter bis zum Desktop-Ersatz ist der RPi 4 nun für alle Anwendungsfälle gerüstet. Denn entscheidende Performanceschwächen wurden allesamt behoben. Es bleibt spannend.

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: