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.

Neu im RISC OS-CVS: ADFS-Patches, OmniNFS, EtherUSB, VFP

Auch in 2018 habe ich ein Auge auf das ROOL-CVS-Repo, weil man dort aus den Commit-Kommentaren und den geänderten oder hinzugefügten Sources recht gut ablesen kann, wo in der RISC OS-Welt (m Sinne von Kern-OS) gerade Hand angelegt wird.

ADFS wurde gepatcht, um etwas unempfindlicher gegenüber neueren Devices zu sein – bekanntlich scheren sich viele Geräte nicht um Standards, vor allem nicht um veraltete wie den ATA-Standard aus der Zeit von PIO-Mode 0. Der Patch basiert auf Vorarbeiten und -Analysen von Jon Abbott mit RISC OS 3.1 und dem ewigen Rätsel, warum in A3020/A4000/A5000 das ADFS so wählerisch mit vielen CompactFlash-Karten und manchen Platten ist, während 3rd-party-IDE-Podules damit eher weniger Probleme haben. DRQ-Timeout-Handling ist das Stichwort. Jedenfalls steht jetzt ein ROMPatch für die ADFS-Versionen von RISC OS 3.50 bis 4.02 zur Verfügung.

Der NFS-Client für OmniClient wurde wiedererweckt – vermutlich ist jemand über eine Diskette mit Quellcode von 1992 gestolpert…alle normalen Menschen verwenden seit Urzeiten ImageNFS und etwas später dann Sunfish als NFS-Client.

Das EtherUSB-Backend für den Pegasus-Chipsatz wurde gefixed, da gab es seit dem letzten EtherUSB-Update Probleme. Wenn ich mich recht erinnere, betraf das u.A. das BeagleBoard-xM. Erfahrene RISC OS-Ethernet-Geschädigte haben natürlich immer eine große Auswahl an USB-Adaptern mit unterschiedlichen Chipsätzen in der Bastelkiste, um gegen derartige Unfälle gewappnet zu sein.

Im Bereich VFP gab es einen merkwürdigen Bug, wo das WIMP beim Taskswitching in Verbindung mit Poll-Post-Filtern den VFP-Kontext nicht richtig behandelte. Symptom: SciCalc semmelte bei Tastatureingabe ab, wenn gleichzeitig das KeyExtend-Modul (wird z.B. von StrongEd benötigt) aktiv war. Jeffrey Lee hat es souverän analysiert und gefixed – ich will nicht wissen, wie lange das gedauert hat, diese abstruse Kombination zu debuggen.

Weiterhin gibt es Bewegung und Aufräumen in Richtung RISC OS 5.24, vor allem beim Wandboard (aka ARMX6). Ich bin leider immer noch nicht dazu gekommen, einen der Nightly Builds fürs Wandboard auszuprobieren.

USB-Stack – des Updates erster Schritt

Das Bounty-System von ROOL ist nicht gerade erfolgsverwöhnt. Es mangelt neben Spendenbereitschaft vor allem an interessierten und ausreichend talentierten Entwicklern, die sich der zahlreichen Aufgaben annehmen wollen.

Eine der aus meiner Sicht wichtigsten Bounties kreist rund um USB. Bekanntlich stammt das RISC OS 5-USB-Subsystem genau wie der Netzwerkstack von *BSD ab, wurde aber schon längere Zeit nicht auf den aktuellen Stand der Dinge gebracht, abgesehen von gezielten Codeübernahmen aus dem Original. Hauptsächlich deshalb, weil es kein “plain port” ist, sondern aufgrund der maximalen nicht-UNIX-heit von RISC OS eben großflächig angepasst werden musste. Das erschwert das Synchronhalten mit der Quelle erfahrungsgemäß enorm.

Nun wurde für Teil 1 des USB-Bounties Vollzug gemeldet. Hier zum Nachlesen der Umfang von Teil 1. Neben den notwendigen strukturellen Änderungen, um näher am BSD-Original zu sein und eine saubere Trennung zwischen den Hardware-Treibern und dem eigentlichen Stack halte ich die Bereinigung des Chaos rund um das bisherige Schmalspur-USB-wenn-gebootet-wird für besonders erwähnenswert. Schon auf dem IYONIX pc war das ein Ärgernis – es funktionierten zum Boot-Zeitpunkt nur ganz einfache Tastaturen an einem ganz bestimmten USB-Port.

In Colin Granvilles USB-Ecke gibt es entsprechende Updates, um den Isochronous-Modus nutzen zu können. USB Audio ist weiterhin ein Stiefkind im RISC OS-Universum, aber irgendwann werden hoffentlich die entscheidenden Lücken geschlossen werden. Vermutlich um dieselbe Zeit, wenn USB3-, WLAN- und Bluetooth-Unterstützung Einzug in RISC OS hält.

Warten wir also geduldig und hoffen auf die alsbaldige Vollzugsmeldung bei USB-Bounty Teil 2!

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.

Zwei Clares-Klassiker wieder verfügbar

Christopher Bazley, in RISC OS-Kreisen kein Unbekannter und unter anderem verantwortlich für die Neuauflage von Star Fighter 3000, hat die Verfügbarkeit von zwei Klassikern aus dem Clares-Stall (später in den Händen von APDL) in aktualisierter, ARMv7-kompatibler Form verkündet. Hier geht’s zur Download-Seite. Clares war zu RISC OS-Hochzeiten (sofern es die je gab) einer der großen Anbieter neben Computer Concepts, Longman Logotron und Beebug/Risc Developments.

Es handelt sich zum einen um Schema 2, eine Tabellenkalkulation die zu den zwei führenden auf dem RISC OS-Markt gehörte – die eine Hälfte des Marktes hatte Eureka, die andere Hälfte Schema, und ein paar versprengte dazwischen noch Pipedream und Fireworkz. Schema war auch in abgespeckter Form in Acorn Advance enthalten, dem Versuch von Acorn in den 90ern ein “integriertes Office-Paket” zu bauen, quasi in Konkurrenz zu Microsoft Works oder ClarisWorks (später AppleWorks). Die Älteren erinnern sich vielleicht noch an StarOffice, Borland Office/Novell PerfectOffice/Corel WordPerfect Office oder Lotus Symphony. Es war mal sowas wie ein Trend.

Schema 2 verfügt neben den “üblichen” Spreadsheet-Funktionalitäten auch über Import-Möglichkeiten für diverse andere Klassiker wie Lotus 1-2-3 oder ältere Excel-Versionen (von Toni Reiser gibt es hier ein aktualisiertes Update des Excel-Konverters). Charts können ebenso erstellt werden, und macrobasierte Programmierbarkeit ist ebenfalls am Start.

Der zweite Kandidat ist WimpBasic. Irgendwie haben RISC OS-Benutzer ja einen besonderen Hang zu BASIC, weil der erste Programmierkontakt normalerweise das integrierte BBC BASIC V ist – sowas prägt halt. Aufgrund dessen Limitierungen waren natürlich Alternativen immer gefragt, vor allem welche, die sich der Vereinfachung der WIMP-Programmierung annahmen. WimpBasic war einer der neueren und sehr leistungsfähigen Versuche. Fast schon eine IDE.

Ausprobieren kostet nix! Ob das Zeug wohl auch auf dem Pi3 (ARMv8) läuft? Und werden wir noch weitere Clares-Klassiker wie Rhapsody, Render Bender, Illusionist, ProArtisan, Composition oder Serenade auf den modernen Maschinen außerhalb eines Emulators erleben? Es bleibt spannend.

Frohes Fest, guten Rutsch, auf ein Neues in 2018

Zunächst: allen treuen Lesern dieses Blogs wünsche ich ein Frohes Fest und einen guten Start in 2018 – ich bedanke mich für die entgegengebrachte Aufmerksamkeit und das viele Lob.

2017 empfand ich RISC OS-technisch als eher durchwachsen. An der Hardwarefront wurden ARMX6 und Titanium durch verbesserte OS-Versionen verfeinert, der RPi 3 und damit ARMv8 etablierte sich und zog den üblichen Versionswahnsinn nach sich, weil ARM ja mal wieder etwas sparsam bei der Rückwärtskompatibilität war.

RISC OS selbst war auch eher sanften Verbesserungen unterworfen. Hauptpunkt vermutlich die EDID-Unterstützung, die aber immer noch teils überraschende Effekte zeitigt. RC15 für die Pis war sicher ein Meilenstein, für Newcomer und Zurückkommer ist es nun wieder deutlich unkomplizierter, einen RPi unter RISC OS ans Fliegen zu kriegen. Nachdem Filecore nun mit 4KiB-Sektoren umgehen kann, ist nun auch der Betrieb von 2 TiB-Platten möglich – wir warten aber weiterhin auf eine Version von HForm, die das auch formatieren kann, und natürlich auf die Möglichkeit vernünftig Partitionen unter ADFS und SCSIFS zu verwalten. Fortschritt gab es an der Dokumentationsfront, das “User Manual” hat große Fortschritte zu verzeichnen, und das BBC BASIC-Referenzhandbuch gibt es in einer überarbeiteten Neuauflage. Auf echtem Papier. So richtig gedruckt.

Es gab ein neues DDE-Release, Nummer 28. Auch hier eher Evolution als Revolution. Bei einem Toolset, dass das Betriebssystem baut, keine schlechte Strategie.

Ansonsten war es softwaretechnisch m.E. eher verhalten. Die Webkit-basierten Browser erfuhren einige Verbesserungen, und es gab mit dem OBrowser den Versuch, die RISC OS-Integration dieser Browser mit einfachen Mitteln zu verbessern.

Adrian Lees hat Aemulor kostenlos freigegeben in der Version 2.40, die nun auch ARMv8-Unterstützung hat und auf aktuellen RISC OS-Builds in High-Vector-Konfiguration läuft – meine diversen Versuche auf Pi3 und Ti zeigten aber noch einige Ecken und Kanten. Demnächst mehr dazu auf diesem Blog.

Eines der wenigen Tools, die seit Jahren stetig weiterentwickelt werden, ist ADFFS – Jon Abbott ist hier unermüdlich dabei. Was anfangs ein simpler ADFS-Emulator war um auf den alten Archies mit Floppy-Disc-Images arbeiten zu können, ist inzwischen ein kompletter High-Performance-Emulator, um die Spiele der 80er auf allen RISC OS-Maschinen bis zum neuesten ARMv8-Pi 3 wiederaufleben zu lassen. Nebenbei hat Jon auch gleich das Geheimnis des IDE-ADFS-Problems gelöst, warum die alten Kisten z.B. mit CF-IDE-Adaptern oft nicht richtig zusammenarbeiten können.

Auch Fred Graute mit StrongEd ist emsig an der Weiterentwicklung und reagiert sehr schnell auf etwaige Bugs. Kompliment von mir.

Aus deutschsprachigen Landen sind Thomas Milius mit seiner SmartHome-Steuersoftware zu nennen und Anton Reiser, dessen neueste Schöpfung ein Utility zur Behandlung von Photoshop-Dateien ist. Auch Martin Würthner hat nach fünfjähriger Kunstpause mit Artworks 2.X3 endlich wieder ein neues Upgrade am Start.

Was kommt 2018? Endlich das neue Release von CDVDBurn. Versprochen. Und ich hoffe auf Fortschritte bei der Emulator-Front – RPCEmu auf Qt-Basis und damit eventuell auch eine RISC OS-Version davon, die Archimedes-Emulation in MAME, Fortschritte bei ArchiEmu, Aemulor-Verbesserungen, und die vage Hoffnung auf eine Fortentwicklung des Archimedes-Core in MIST und MISTer.

ADFFS 2.63 verfügbar

Jon Abbott vom JASPP hat die Verfügbarkeit von ADFFS 2.63 verkündet. Es gab viele Verbesserungen und Bugfixes, insbesondere für ARM7-basierte Systeme (Risc PC mit ARM710, A7000(+)) und für den IYONIX, der jetzt auf Augenhöhe mit dem Pi bezüglich der Spielekompatibilität sein sollte – wichtig ist hier, ein entsprechendes MDF am Start zu haben mit den für Spiele typischerweise notwendigen Auflösungen. Nebst einem Monitor, der diese auch verarbeiten kann.

Unter den Spielen, die nun unter ADFFS funktionieren, ist sicher Heroes of Might and Magic 2 am bekanntesten.

Außerdem wurden diverse Spiele von Alpine Software im Rahmen des JASPP freigegeben. Dabei handelt es sich um klassische Grafik-/Text-Adventures, neudeutsch “Interactive Fiction”, die noch den Geist der 80er atmen. Und tatsächlich teilweise aus den späten 80ern stammen. Cool: mit ALPS wurde auch das Authoring-System freigegeben, mit dem der geneigte User selbst solche Adventures kreieren kann.

Hier kann man ADFFS 2.63 runterladen.

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.

Aemulor 2.40 ist da

Adrian Lees hat sein Versprechen wahr gemacht und hat aktuelle Entwicklungsversionen von Aemulor für alle relevanten Plattformen veröffentlicht. Hier gehts zu den Downloads. Zum ersten Mal ist auch der Pi3 (Cortex-A53, ARMv8) unter den unterstützten Plattformen. Ebenfalls sollte diese Aemulor-Version nun mit den neueren RISC OS-Versionen zurecht kommen – Stichwort Zero Page Protection und High Vectors.

Alle Plattformen, für die es jemals Aemulor gab? Nein, die Formulierung “alle relevanten Plattformen” war mit Bedacht gewählt. Denn der A9home ist nicht darunter…arme kleine blaue Kiste.