ADFFS 2.69 (auch via PackMan) verfügbar

2018-11-08 00:43

Jon Abbott vom JASPP hat die Verfügbarkeit von ADFFS 2.69 verkündet. Nur ein kleineres Update gegenüber 2.68, hauptsächlich um die neueste Version nebst allen frei verfügbaren und unterstützten Spielen via Paket-Management (sprich !PackMan) verfügbar zu machen. Außerdem wird das USBJoystick-Modul nun automatisch beim Startup geladen, und es gab einige kleienre Bugfixes sowohl bei den Game-Start- und Patch-Scripts als auch in ADFFS selbst.

Die primäre Testplattform ist übriens inzwischen der Raspberry Pi 3, also quasi die maximale Inkompatibilität gegenüber den alten Kisten (RISC OS 5.24, ARMv8).

Seit dem letzten ADFFS-Update hat Jon auch noch ein paar alte Spiele sauber paketiert freigegeben, S.W.I.V. dürfte darunter das bekannteste (und aus meiner Sicht auch das beste) sein. Ein paar weniger bekannte Spiele von Cambridge International Software sind auch mit dabei, das bekannteste darunter dürfte MicroDrive sein, ein Golf-Spiel nach Leaderboard-Art, das angeblich eines der realistischeren seines Genres sein soll. Mein absolutes RISC OS-Lieblingsspiel, Spheres of Chaos, hat inzwischen auch das Licht der Welt erblickt. Auf einem A3000 mit Gamer’s Upgrade – 4 Spieler am Joystick, einer an der Maus und drei an der Tastatur – wäre zu versuchen, ob das mit ADFFS und USBJoystick nun wieder möglich wäre. Ein Projekt für die Weihnachtsfeiertage.

Danke an Jon und an Alan Buckley für die neue Variante via Paket-Management – das sollte die Sache für viele Benutzer stark vereinfachen.

Schnellere Grafik für ARMX6 und mini.m

2018-10-28 22:12

R-Comp hat die Verfügbarkeit eines Grafiktreibers für die Beschleunigung diverser Videooperationen für iMX6-basierte Systeme verkündet. Von Adrian Lees implementiert (die Älteren erinnern sich: der ARM-Magier, der uns Aemulor und Geminus gebracht hat) und für die Kleinigkeit von 30 UKP käuflich zu erwerben. Ob zukünftig ausgelieferte Maschinen dieses Feature bereits kostenlos mitliefern, ist unklar.

Hier ist die Ankündigung von R-Comp nachzulesen. Wer der Preis vermisst: so sind sie halt, die Briten. Wer auf der R-Comp-Webseite stattdessen danach sucht, wird derzeit ebenfalls nicht fündig. Details, welche Dinge beschleunigt werden, sind ebenfalls nur über die Mailingliste zu erfahren. Aber: man kann dieses Add-On immerhin über !Store kaufen, den Online-Shop-als-Application von R-Comp. Ja, das Dingens mit der gruselig unsicheren Zahlungsweise.

Was als „up to 10x better real-world performance“ angekündigt wurde, entpuppt sich jetzt als klassische hardwarebeschleunigte Rectangle Copy. Sicherlich schön, aber nicht gerade bahnbrechend. Immerhin schließen jetzt an dieser Performance-Ecke ARMX6 und mini.m endlich zu Titanium, IGEPv5, PandaBoard, Raspberry Pi, IYONIX pc und RiscPC+ViewFinder auf. Ja, alle diese hatten von Anfang an diese Beschleunigung aktiv. Siehe auch hier die Benchmark-Ergebnisse, der ARMX6 dort ist natürlich noch ohne die neue Beschleuniger-Funktion vermessen worden.

Glückwunsch, R-Comp!

RISC OS demnächst unter Apache-Lizenz

2018-10-23 00:49

Es gibt Bewegung an der RISC OS-Lizenz-Front. Vor wenigen Stunden kam die für mich überraschende Nachricht, dass die von vielen ungeliebte Castle-Lizenz demnächst durch die Apache 2.0 License abgelöst wird.

Zuvor gab es die Ankündigung, dass RISC OS Developments Ltd. (im Prinzip Andrew Rawnsley von R-Comp/RCI und Richard Brown von Orpheus Internet/GeneSys Developments Ltd. neben ein paar ungenannten Investoren, gegründet im April 2017, einzig bisher sichtbares Ergebnis: das OBrowser-Frontend zum Otter-Browser-Port, und keinesfalls nicht zu verwechseln mit der angekündigten, aber nie vollzogenen Umbenennung von RISCOS Ltd. nach RISCOS Developments Ltd. von anno 2004 beim letzten großen RISC OS-Lizenzkrach) die Rechte an RISC OS komplett durch die Übernahme von Castle Technology erworben hat – ein paar Details nebst ein wenig historischem Kontext dazu bei RISCOSitory.

Was bedeutet das in der Praxis? Man weiß es nicht. Wer bisher aufgrund der „aber es ja gar nicht echtes Open Source!“-Problematik nicht an RISC OS mitarbeiten wollte, hat nun keine Ausreden mehr. Oder besser gesagt: diese eine Ausrede gibt es nicht mehr, aber es ist natürlich immer noch nicht GPL (die Lieblingslizenz derer, die lieber schwätzen als machen) und der Compiler wird vermutlich auch nicht unter der APL freigegeben (dazu gibt es zumindest noch keine Infos), d.h. die Mitentwicklung an RISC OS erfordert weiterhin, ein paar Euros in die Hand zu nehmen.

Als problematisch empfinde ich, dass der Zwang der Castle-Lizenz zum Feedback von Änderungen von kommerziellen Lizenznehmern nun wegfällt. Das bedeutet prinzipiell eine Fork-Gefahr durch kommerzielle Verwender, was das fragile RISC OS-Gebilde doch sehr beschädigen könnte. Hätte R-Comp die bei der ARMX6-Entwicklung vorgenommenen Änderungen wirklich in die Mainstream-Version zurückgespeist? Da bin ich unsicher. Die wenigen Firmen, die noch im RISC OS-Markt tätig sind, sind aus meiner Sicht nicht gerade als große Verfechter der Open Source-Idee bisher in Erscheinung getreten, sondern eher als Schmarotzer der großen Open-Source-Welt. Die Versuchung, billige ARM-Boards mit einer RISC OS-Portierung in teure RISC OS-Maschinen zu verwandeln und die notwendigen Treiber für sehr relevante Zeiträume (also deutlich länger als die bisher durch die Castle-Lizenz maximal vorgegebenen 12 Monate) Closed-Source zu halten, dürfte riesig sein.

Im Prinzip könnte solch einer Fehlentwicklung nur durch eine starke Community begegnet werden, die den Open-Source-Gedanken hochhält und Firmen weitestgehend boykottiert, die diese Ideen konterkarieren wollen. Leider ist die RISC OS-Community nach meiner Einschätzung ungefähr das glatte Gegenteil – die Neigung, aufgrund irgendwelcher Versprechungen irgendwem reichlich Geld in den Rachen zu werfen scheint mir ungebrochen – „to support the market“, wie es immer so schön heißt. Spricht aber eben nicht für einen gesunden Markt, wenn man Geld für etwas zahlt, was man eigentlich nicht haben will oder zumindest nicht für den aufgerufenen Preis.

Aber es freut mich, dass die ewige Lizenzdiskussion nun hoffentlich endgültig ein Ende hat. RISC OS ist jetzt echtes Open Source! So richtig OSI! Ohne wenn und aber! Die letzten Signale waren nicht gerade so, dass man das erwarten durfte, Relicensing von altem IP-Zeugs ist immer eine Aufgabe, zumal bei der vorliegenden Historie von RISC OS von mehr als 30 Jahren.

Demnächst ist die RISC OS London Show, da gibt es eventuell mehr Details zu erfahren.

ADFFS 2.68 verfügbar

2018-08-29 23:17

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

2018-05-06 23:35

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

2018-05-06 00:06

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

2018-04-19 16:39

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

2018-04-08 23:21

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

2018-03-28 14:29

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

2018-02-17 19:05

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.