ADFFS 2.68 verfügbar

Jon Abbott vom JASPP hat die Verfügbarkeit von ADFFS 2.68 verkündet. Hauptneuheit ist partielle Unterstützung für WIMP-basierte 26bit-Spiele wie Aldebaran, Elite oder Sim City – also Spiele, die zunächst sich nach dem Start auf der Iconbar wie eine normale RISC OS-Anwendung installieren, dort begrenze Interaktion erlauben (Highscores anschauen, Version anschauen, Einstellungen vornehmen) und nach Click aufs Icon erst den Bildschirm vollständig übernehmen. Auch die Unterstützung von USB-Joysticks ist nun erstmals in einer Release-Version verfügbar. Dazu wie üblich eine größere Menge Bugfixes und Erweiterungen, um weitere Spiele ans Laufen zu kriegen – insbesondere die wenig bekannten Topologika-Titel waren wohl eine harte Nuss.

Einfach mal testen – und nicht vergessen: “Boot floppy” verwenden zum Start der Spiele! Das JASPP hat auch ein paar neue Spiele in den letzten Monaten freigegeben, einfach regelmäßig hier nachschauen. Die 32bit-Version von Exodus ist sicher das Highlight, dazu Lemmings 2 und die CD-Version von Dune II, für die Jon extra eine aufgebohrte Version von CDFaker gebaut hat (siehe hier).

Happy (Retro) Gaming!

RISC OS 5.24 ist da

Ich bin etwa 2 Wochen zu spät dran, RISC OS 5.24 wurde zur Wakefield-Show veröffentlicht. Aber besser spät als nie…hier das Original-Announcement von RISC OS Open Ltd.

Eine Menge Neues gibt es in RISC OS 5.24 (hier die Liste stellvertretend für die OMAP4-Plattform) – natürlich nicht für diejenigen, die öfter mal eine der Entwicklungsversionen mit Namen 5.23 verwenden, aber gegenüber der letzten Release-Version 5.22 ist der Fortschritt natürlich erheblich. Während 5.22  noch auf IOMD (Risc PC, A7000(+)), IYONIX, BeagleBoard (OMAP3) und PandaBoard (OMAP4) beschränkt war, gibt es 5.24 nun als offizielles Release auch für die diversen Raspberry Pi-Modelle sowie das Titanium-Board. Wandboard und OMAP5 (IGEPv5) haben es nicht ganz geschafft, aber CJE Micro’s (Rapido-Ig, also IGEPv5) und R-Comp (ARMX6, also Wandboard) haben für ihre Kunden natürlich eine Distribution äquivalent zu 5.24 auf Lager.

Kurz aus meiner Sicht die Highlights:

  • High-Vector-Konfiguration ist jetzt Standard, aus Kompatibilitätsgründen gibt es eine “compatibility page” anstelle der ZeroPage. Entwickler können weiterhin ZeroPain verwenden, um aussagekräftige Logs zu erhalten bei ZeroPage-Zugriffen
  • EDID-Unterstützung
  • 4K-Sektor-Unterstützung in FileCore für bis zu 2 TiB pro Partition
  • ARMv6/v7/v8- und VFP-Befehle in BASIC
  • diverse Verbesserungen für den UTF-8-Betrieb (!Chars, !Draw)
  • RAM-Disc-Größe bis 512 MiB
  • SpriteExtend unterstützt moderne JPEGs (und ChangeFSI ebenfalls)
  • OmniClient komplettiert durch den alten NFS-Kern und den nicht ganz so alten Access-Kern, so dass “Omni” nun wieder besser als Name passt
  • ein aktualisiertes Handbuch (der “User Guide”)

Vermutlich am Wichtigsten ist aber, dass es endlich nach der langen Zeit der Release Candidates für den Pi nun wirklich eine als stabil gekennzeichnete RISC OS-Version gibt – das wird es hoffentlich ermöglichen, wieder Teil des NOOBS-Images zu werden.

Jetzt werde ich nach und nach meine Systeme aktualisieren – die RPis, ARMX6, Titanium, PandaBoard ES, BeagleBoard-xM und BIK, IYONIX, RPCEmu und vielleicht teste ich auch auf einem der Risc PCs mal den Softload. Leider gibt es ja keine 32bit-Treiber für den ViewFinder, was die Nützlichkeit der Risc PC-Version für meine Zwecke doch ziemlich einschränkt.

RPCEmu 0.9.0 ist da

Im Oktober 2017 gab es die erste RPCEmu-Testversion, die auf Qt statt auf Allegro basierte – hier meine damalige kurze Zusammenfassung der Vorteile der Qt-Implementierung gegenüber Allegro. Vor allem die neue Software-Skalierung im Fullscreen-Modus ist Gold wert, weil es im Windows-Umfeld sehr sauber und problemlos funktioniert, und die Software-Skalierung oft sogar bessere Ergebnisse liefert als die Skalierungsfunktion von Betriebssystem oder Bildschirmhardware.

Heute ist RPCEmu 0.9.0 erschienen, die erste Qt-basierte Release-Version nach einer Reihe von Testversionen, um diverse obskure Bugs zu fixen. Der Qt-Branch wurde gleichzeitig wieder in das Hauptrepository (Mercurial) gemergt .

Meine Wünsche für die Version 1.0:

  • konfigurierbarer Pfad für HostFS – dann kann es auch wieder einen Windows 7ff-tauglichen Installer geben, damit die Software nach “Programme” und die Daten woandershin können
  • Unterstützung von MimeMap in HostFS (ich arbeite noch dran, die RPCEmu-Entwickler davon zu überzeugen, dass das eine gute Idee ist)
  • multiple Mounts für HostFS – System-Profile-Definitionen, um einfach zwischen verschiedenen RISC OS-Versionen, RAM-Configs und HostFS-Mounts zu wechseln
  • Bug bezüglich IDE-Emulation für RISC OS 5 fixen
  • Erscheinungsdatum noch 2018 🙂

Update: ich habe meine Seite “Emulatoren für RISC OS” auch auf den neuesten Stand gebracht.

ADFFS 2.65 public beta und Joysticks

Jon Abbott hat ADFFS 2.65 als “public beta” zum Download bereitgestellt. Ein großer Schritt nach vorne, arbeitet es doch eng verzahnt mit Richard Walkers USBJoystick-Modul zusammen, um endlich die Freuden des Knüppels abseits der Originalhardware bereitzustellen.

Joystick-Unterstützung war immer ein schwieriger Fall bei Acorns 32bittern. Erst der A3010 hatte eingebaute Joystick-Ports, und erst mit dem darauf ausgelieferten RISC OS 3.10 bequemte sich Acorn dazu, eine SWI-Schnittstelle zur sauberen Joystick-Unterstützung bereitzustellen. Offenbar waren Spiele auf Computern zu unseriös für die auf den Bildungsmarkt zielenden Acornianer.

Der geneigte Joystick-Nutzer und Archimedes-Zocker war also lange Zeit (wie schon auf den BBC-8bittern) auf 3rd party Interfaces angewiesen – The Serial Port, Vertical Twist, RTFM, Voltmace, LogikJoy, Gamer’s Upgrade, JoyConnect…man ahnt es schon, jedes einzelne nur zu sich selbst kompatibel. Eine Ausnahme – RTFM und LogikJoy, beide steckte man in den meist ungenutzten Econet-Steckplatz, waren Hardware-kompatibel. Und später gab es immerhin für fast alle Hardware-Interfaces ein Modul, welches Kompatibilität mit den Acorn-SWIs herstellte. Nicht unerwähnt soll auch Ian Haylocks Joystick-Interface für den Parallel-Port bleiben, das hatte ich jahrelang erfolgreich am Risc PC betrieben.

Jedenfalls hat sich Jon Abbott die Mühe gemacht, quasi alle Spiele die es je für RISC OS gab auf ihre Joystick-Kompatibilität zu prüfen. Ursprünglich basiert das auf der Analyse des Codes und welche SWIs drin genutzt werden, inwieweit diese Liste inzwischen experimentell erhärtet wurde weiß ich nicht.

Unverzichtbar auf den modernen Plattformen ist Richard Walkers USBJoystick-Modul. Im Prinzip unterstützt es alle HID-kompatiblen USB-Joysticks, egal ob analog oder digital. Im Moment muss ggf. noch händisch gemappt werden, welcher Knopf denn nun Feuerknopf 1 ist und welche Achsenbewegungen auf x- und y-Achse wirken. Als Besonderheit im Zusammenwirken mit ADFFS kann ADFFS die über USBJoystick bereitgestellten Informationen so bereitstellen, als wenn ein RTFM-Interface diese ausgelesen hätte – notwendig für einige Spiele älteren Datums, die direkt die Hardware des RTFM-Interfaces angesprochen haben.

Wenn man Jons Erkenntnisse so im Zusammenhang liest, muss man sich teilweise wundern, dass die Spiele damals überhaupt auf der Originalhardware liefen. Dass damals gerne mal am Betriebssystem vorbei programmiert wurde, ist ja lange leidvolle Erfahrung und ein steter Quell von Inkompatibilitäten aller Art.

Meine eigenen Experimente mit ADFFS und meinen diversen USB-Joysticks stehen noch aus. Ich muss mal in den diversen Bastelkisten kramen, aber ich habe auf jeden Fall folgendes am Start:

  • Competition Pro USB (in der goldenen Jubiläums-Edition)
  • PS3-Joypad
  • USB-PS2-Joypad-Adapter
  • diverse USB-Gameport-Adapter und ebenso diverse Gameport-Joysticks vom Competition Pro (Mini) bis zum Gravis Analog Joystick

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.

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.