Software

Anwendungen und Tools rund um RISC OS

Sunfish und Moonfish auf GitHub unter MIT-Lizenz

2021-01-01 15:19

Man soll das Jahr ja immer mit guten Nachrichten beginnen. Mit der Überschrift ist eigentlich auch schon alles gesagt: Alex Waugh hat seine unverzichtbaren Tools Sunfish und Moonfish auf GitHub publiziert und umlizenziert von der ungeliebten GPLv2 auf die sehr viel liberalere MIT-Lizenz. Hier ist der Sourcecode.

Wer es nicht weiß: Sunfish ist ein NFS-Client für RISC OS ab Version 3.11. NFSv2 und NFSv3 werden unterstützt, sowohl über TCP als auch über UDP. Alles Notwendige für saubere Cross-Platform-Behandlung von Dateinamen und -typen ist an Bord, und es gibt ganz feingranulare Konfigurationsoptionen, damit sich die RISC OS-Seite mit der Unix-Natur von NFS gut versteht. Man kann Sunfish sowohl im „Dateisystem auf der Iconbar“-Modus betreiben als auch als „Image-File als Mountpoint in einem beliebigen Verzeichnis“-Modus. Ja, man wünscht sich einen aktuellen SMB-Client, der auch alle diese Optionen unterstützen würde.

Moonfish ist das Gegenstück, ein NFS-Server. Auch NFSv2 und NFSv3 (hier sogar mit partieller Unterstützung für NFSv4), sowohl über UDP oder TCP.

Ich verwende Sunfish seit ewigen Zeiten zum Zugriff aller physischen und virtuellen RISC OS-Maschinen auf mein NAS. Sowohl bei der Entwicklung von Software als auch z.B. für Backup-Zwecke und zum allgemeinen Datenaustausch absolut unverzichtbar. Durch dieses Setup musste ich bisher Moonfish nie verwenden, weil das NAS als Server ja „always on“ ist. Wer aber einen Ersatz für ShareFS sucht (z.B. weil RPCEmu es nicht gut unterstützt), kann mit der Sunfish-Moonfish-Combo den Peer-to-Peer-Ansatz von ShareFS nachbauen.

Wie es aussieht, hat Alex die Gelegenheit genutzt und gleich all seinen Sourcecode auf GitHub abgelegt. Am bekanntesten dürfte der SVN-Client und WebJames sein. Sehr schön!

In diesem Sinne: ich wünsche allen Lesern ein erfolgreiches, friedliches und gesundes neues Jahr 2021.

CDVDBurn 3 Status-Update

2020-10-17 17:10

Seit 2007 arbeite ich – mit schwankender Intensität, auch mal mit jahrelanger Pause bei der Codierung – an einem „großen“ Update von CDVDBurn, das ich zunächst mal CDVDBurn 3 getauft habe – das originale CDVDBurn begann ja mit Version 2.00, als Kontinuität von CDBurn, das von 0.99 bis 1.64 versioniert daherkam.

Jetzt habe ich in den letzten Tagen ein wenig Aufwand investiert, um vor allem mal in der Breite USB-Laufwerke auf ARNX6, Raspberry Pi und Titanium zu testen. Und auf dem Raspberry Pi 4, bekanntlich der erste Cortex-A72 im RISC OS-Universum, zwar auch ARMv8 wie sein Vorgänger RPi 3, aber man weiß ja nie – auf dem RPi 3 hat es ja eine böse Überraschung gegeben, da wird man vorsichtig. Die gute Nachricht: tut bisher alles einwandfrei auf dem neuesten Pi, auch die RISC OS-Version scheint schon stabil. Famous last words…

Laufwerke, mit denen ich bisher getestet habe, allesamt USB-Modelle (also nicht S-ATA-mit-USB-Adapter):

  • Samsung DVD-Brenner
  • LG DVD-Brenner
  • Samsung BD-Brenner
  • LG BD-Brenner
  • Asus BD-Brenner
  • Pioneer BD-Brenner

Die schlechte Nachricht ist, dass keiner dieser Brenner „out-of-the-box“ so gut funktionierte wie es mal die Lite-On-IDE-Brenner auf dem IYONIX pc und dem Risc PC taten. Die gute Nachricht ist, dass CDFS inzwischen fast problemlos mit allen Laufwerken funktioniert, ebenso der „Disc Extractor“ von CDVDBurn. Und auch die Extraktion von Audio-Tracks ist problemlos.

Beim Schreiben war es dann ganz duster. Daten-CD war noch meistens funktionierend, Audio-CD im Track-at-once-Verfahren eher durchwachsen, Audio-CD im Disc-at-once-Verfahrung (genauer: Session-at-once) hat bei keinem dieser Brenner funktioniert.

Inzwischen konnte ich aber durch Anpassungen der Disc-at-once-Schreibroutine die Kompatibilität teilweise erhöhen, zumindest was die Asus- und die Samsung-Laufwerke angeht. Das fühlt sich fast wie ein Meilenstein an. Und ich konnte gleich eine Merkwürdigkeit fixen, wo trotz prinzipiell multitaskendem buffer-inspection-driven-writing mit Hourglass und partiellem single-tasking gearbeitet wurde.

Was ist noch zu tun? Mindestens die Prüfung von DVD+RW, DVD-RAM, DVD+R, BD-R und BD-RE, dann kann ich über ein initiales Release nachdenken. Ich fürchte, das wird die Liste der unterstützten Laufwerke weiter eindampfen. Ein Schwerpunkt bei den Laufwerken wird wohl Samsung sein (inzwischen „TSSTcorp“ – „Toshiba Samsung Storage Technology“), weil sowohl R-Comp beim ARMX6 als auch Elesar beim Titanium diese Laufwerke standardmäßig verbauen.

Im Bereich „Kür“ verbleiben dann: DVD-R (DL), DVD-RW, DVD+R DL, BD-R DL und XL, BD-RE DL, Titanium S-ATA, IYONIX IDE, S-ATA-Laufwerke an USB-S-ATA-Adapter, Performance-Verbesserungen (vor allem beim Disc Extractor), und natürlich die Verbesserung diverser UI-Nicklichkeiten, die die letzten Jahre unbeschadet überdauert haben. Aber diese Liste ist lang. Wobei man sich an UI-Hakeleien eher gewöhnen kann als an „brennt nicht“.

SparkFS 1.46

2020-07-14 19:37

David Pilling hat einen nicht unwichtigen Bug in SparkFS gefixed. Erstaunlich, dass nach all den Jahren hier immer noch Unschärfen auftreten, aber es ist ja immer ein gutes Zeichen, wenn Software fleißig auch in neuen Szenarien genutzt wird sowie Bugs gefixed werden – auch 28 Jahre nach dem ersten Release der Software.

Der Bug tritt auf, wenn sehr viele Archive gleichzeitig geöffnet sind – das kann z.B. passieren, wenn eine Suchsoftware über viele Archive läuft und auch – dank Image Filing System – deren Inhalte durchsucht.

Also: updaten. Die Read-Only-Version gibt es zum freien Download. Über die pillingsche Mailing-Liste haben die Nutzer der Vollversion auch einen Update-Link bekommen.

Frischfleisch: FontInfo von Anton Reiser

2020-04-20 15:25

Anton „Toni“ Reiser hat die Verfügbarkeit eines neuen Tools verkündet, und FontInfo ist der Name.

Der Name ist Programm: FontInfo zeigt allerhand nützliche Informationen zu beliebigen RISC OS Outline-Fonts an, und zwar auf Glyphen-Basis. Dazu zieht man entweder die Outline-Datei eines Fonts auf das FontInfo-Icon auf der Iconbar, oder man bedient sich des Menüs zur Auswahl eines beliebigen dem System bekannten Font. Es öffnet sich ein Übersichtsfenster aller Glyphen, die im jeweiligen Font definiert sind. Eine Glyphe kann dann zusätzlich per Click (Tipp: es gibt einen cleveren Unterschied zwischen Links- und Rechtsclick) im Detail inspiziert werden, mit verschiedenen Visualisierungsoptionen: nur die Outline oder „richtig“ gefüllt, die Baseline, die Bounding Box, die Definition der Outline mit den Scaffolds und den Handles – eben alles, was so eine Glyphe im RISC OS-Fontmanager ausmacht. Zusätzlich können die Glyphen als Draw-Datei exportiert werden.

Auf der Fontebene gibt es zusätzliche Informationen zu den Unicode-Blocks, zu denen die Glyphen jeweils gehören. Klickt man einen Block an, werden die zugehörigen Glyphen farbig hinterlegt.

Vorsichtig, wie Toni ist, heißt die derzeitige Versionsnummer 0.02. Für dieses frühe Stadium macht das Tool aber schon einen sehr schicken Eindruck. Also: runterladen und Fonts inspizieren gehen.

Aemulor 2.53 verfügbar

2020-02-29 03:02

Der erste Artikel im neuen Jahr erst Ende Februar. Schande über mich.

Adrian Lees hat die Verfügbarkeit der neuesten „Development Version“ (also eine Testversion im weitesten Sinne) von Aemulor mit der schönen Versionsnummer 2.53 verkündet. Download wie immer hier.

Die große Neuigkeit ist die Verfügbarkeit einer Variante für den Raspberry Pi 4 (und das vor offiziellem Release der RISC OS-Version für diese Maschine!) und ggf. weitere Boards mit einem Cortex-A72 als ARM-Core. Ansonsten gab es kleinere UI-Verbesserungen und einfacherer Zugang zur Online-Dokumentation sowie etwas hilfreichere Fehlermeldungen beim Start der RPCEmu-Version in Verbindung mit ungepatchten RISC OS 5-Versionen. Wenn ich es richtig verfolgt habe, müssen die allerneuesten RISC OS 5.27-Varianten nicht mehr gepatcht werden.

Die Veröffentlichung von 2.51 hatte ich noch hier auf dem Schirm, aber 2.52 ist mir irgendwie durchgerutscht. Die damaligen Verbesserungen betrafen hauptsächlich Impression, sobald die upgedateten 32bit-Module wie GDraw und DitherExtend am Start waren anstatt der originalen 26bit-Varianten, um auf RGB-Zielsystemen wie Titanium und ARMbook stets korrekte Farben auf den Bildschirm zu bringen.

Und irgendwann schreibe ich auch noch einen Blogartikel über das RISC OS-Spriteformat und BGR-vs.-RGB. Versprochen.

In der Zwischenzeit: Happy Aemuloring!

Neue Testversion von Aemulor verfügbar

2019-09-08 18:27

Korrektur 2019-09-24: die vormals hier stehenden Infos zum ARMBook von R-Comp waren falsch. Es basiert auf dem Pinebook, nicht auf dem Pinebook Pro wie vormals fälschlicherweise hier geschrieben (vermutlich war der Wunsch Vater des Gedankens – eine sehr optimistische Interpretation der vorliegenden Informationen). Was wieder zeigt, dass auch knapp fünf Jahre nach diesem Blogeintrag die Problematik der Transparenz von Informationen weiterhin gegeben ist.

Adrian Lees, Entwickler von Aemulor (wer aus unverständlichen Gründen nicht weiß, was Aemulor ist und wozu es gut ist, kann es hier detailliert nachlesen), hat die Verfügbarkeit einer neuen Test- bzw. Entwicklungsversion verkündet. 2.51 ist die Versionsnummer, Download von hier.

Was ist neu? Eine der ungünstigen Nebenwirkungen von Aemulor war immer, dass nicht nur der Application Memory Slot (aka Wimpslot) für die emulierten 26bit-Anwendungen auf die unter RISC OS 4 und früher üblichen 28 MiB RAM eingeschränkt wurde, sondern auch der für alle anderen Anwendungen. Die neue Entwicklungsversion schafft hier nun etwas mehr Platz als früher: durch Anpassungen der Memory Map stehen nun 52 MiB RAM im Wimpslot zur Verfügung. Diese Anpassung ist optional, man kann auch mit der alten Konfiguration arbeiten.

Für die nicht-so-RISC OS-Erfahrenen: das 28 MiB-Limit kommt aus der 26bit-Zeit, also alles bis einschließlich RISC OS 4, als die CPU wie zu Zeiten des ARM2 1986 den Programmcode nur innerhalb der ersten 64 MiB ausführen konnte – weil der Program-Counter, also das Register (R15 übrigens), das die derzeitige Ausführungsadresse enthält, nur die unteren 26bit für die Adresse verwendete. Und dann hat Acorn zur Vereinfachung der restlichen Hardware (damit die MMU genannt „MEMC“ eben nur diese adressieren können muss) kurzerhand diese 64 MiB in gewisse Blöcke aufgeteilt wie die RMA, das ROM, den System-Heap und IO-Bereiche. Hier ist die vollständige Übersicht zu sehen. Wenn man so will, ganz ähnlich wie die DOS-Memory-Map mit ihrem 640 KiByte-Problem.

Und um keine Missverständnisse aufkommen zu lassen: das 28 MiB-Limit bedeutet nicht, dass eine Anwendung nur 28 MiB nutzen kann. Es bedeutet nur, dass der ausgeführte Programmcode maximal 28 MiB groß sein darf – Daten können auch (seit RISC OS 3.5 und dem ARM6xx – seither können nämlich die vollen 32 Bit adressiert werden) in den sogenannten „dynamic areas“ liegen. Die Erhöhung von 28 MiB auf 52 MiB ist also bei den RISC OS-typischen eher kleinen Programmen tatsächlich nur für spezielle Anwendungen interessant. Dort aber potenziell lebensrettend.

Und wie läuft er nun, der neue Aemulor? Kann ich noch nicht sagen. Bin mitten in den Vorbereitungen für die DoReCo-Party kommendes Wochenende, da ist für die Kür erst Zeit, wenn die Pflicht erledigt ist. Interessant auf jeden Fall, dass diese Aemulor-Version auf dem brandneuen ARMBook von R-Comp (ein Pinebook mit RISC OS) schon getestet wurde. Im Pinebook dreht ein Allwinner A64, also grob gesagt Cortex-A53 mit Mali-400, coretechnisch also identisch mit dem Raspberry Pi 3(+). Solange also „bekannte“ Cores am Start sind, scheint die Produktion von kompatiblen Aemulor-Versionen für Adrian keine besondere Herausforderung zu sein.

Wieder nix in 2018, neuer Versuch in 2019

2018-12-23 19:52

2018 neigt sich dem Ende, und im Jahresendspurt passiert erfahrungsgemäß vor lauter anderen Verpflichtungen eher wenig. Nachfolgend die Liste der Softwareprojekte, die ich „eigentlich“ in 2018 erledigen wollte, die aber weiter ihrer Finalisierung harren. Oft fehlen nur Kleinigkeiten, oder „nur noch das letzte Feature“, oder etwas Feinschliff.

CDVDBurn

Der Klassiker gleich zu Anfang. Das letzte offizielle Release, Version 2.02b (auch wenn als Beta gelabeled), war Feburar 2007. Seither plane ich ein neues Release. Was ist seither passiert? DVD-RAM kann geschrieben werden. Blu-Ray kann als BD-R und BD-RE geschrieben werden. Ein Extraktor ist nun integriert, mit dem man unabhängig von CD(ROM)FS Daten-CDs/DVDs/BDs anschauen kann und Dateien extrahieren kann, inklusive Unterstützung für Joliet und ein Subset der Rockridge-Extensions (soweit unter RISC OS sinnvoll). Dazu wurde die Lauffähigkeit unter ARMv7 und ARMv8 sichergestellt (ein echtes Abenteuer mit dem uralten Ada-Compiler). USB-Unterstützung für RISC OS 5 ist an Bord, ebenfalls S-ATA-Unterstützung fürs neue ADFS (z.B. auf Titanium und IGEPv5).

Ich hatte die Hoffnung, auf zumindest einem gängigen USB- und S-ATA-Laufwerk das DVD-R-Schreiben hinzukriegen, bin aber gescheitert. Einen Versuch habe ich mir noch vorgenommen (Incremental Writing statt DAO/TAO mit reserved track), und dann wird endgültig released, egal ob mit oder ohne DVD-R-Unterstützung. Dual-Layer-Unterstützung für BD-R und BD-RE wäre auch noch schön. Das Update wird kostenpflichtig werden, ich hatte einige Investitionen in Laufwerke und andere Hardware.

TapirMail

David Llewellyn-Jones hat 2018 den Sourcecode für TapirMail auf GitHub freigegeben. Mein Plan war, den Sourcecode etwas aufzuräumen, mit aktueller OSLib und aktuellem GCC und DDE baubar zu machen (so richtig mit Makefile und so…) und dann per Pull-Requests die weitere Entwicklung voranzutreiben. Beispielsweise die Unterstützung für Secure POP3/SMTP, und ggf. auch IMAPS. Da bin ich mittendrin steckengeblieben – bauen tut alles, aber Weiterentwicklung ist nicht geschehen, und ich stecke noch in den Überlegungen, wie so ein RISC OS-Projekt unter GitHub anständig strukturiert sein sollte. Jetzt, mit Jeffreys Git-Client (oh, darüber wollte ich ja auch noch bloggen…), ergeben sich da neue Möglichkeiten.

Isofier

Aus der Reihe „Java-basierte Software für RISC OS, aber nicht unter RISC OS“: ein ISO9660/Joliet-Image-Erzeuger. Die Kommandozeilenvariante funktioniert prächtig, das grafische UI nicht so wirklich. Die Besonderheit ist die volle Unterstützung für die HostFS-Implementierungen von RPCEmu und VirtualRPC, es werden also die Filetype-Extensions automatisch in CDFS-Extensions gewandelt, unter Berücksichtigung der VRPC-extensions-Konfiguration und einer MimeMap-Datei.

ImageTransformer

Aus der Reihe „Java-basierte Software für RISC OS, aber nicht unter RISC OS“: ein Konverter für das CDVDBurn-Fake-Image-größer-als-2-GiB-Format. In beide Richtungen natürlich. Nützlich, um unter RISC OS erzeugte Images dann auf dem PC brennen zu können, oder auf dem PC erzeugte Images (z.B. mit oben genanntem Isofier) unter RISC OS brennen zu können.

SpriteConverter/SpriteViewer

Aus der Reihe „Java-basierte Software für RISC OS, aber nicht unter RISC OS“: SpriteConverter ist ein Kommandozeilentool zur Konvertierung einer Sprite-Datei (also allen oder einzelnen Sprites darin) in PNG, JPEG, GIF oder was auch immer als Java ImageIO-Plugin zur Verfügung steht. SpriteViewer setzt auf demselben Code auf und zeigt in einer grafischen Oberfläche den Inhalt einer Sprite-Datei an, einmal in einer !Paint-artigen Übersicht, dann aber auch per Doppelclick in Originalgröße mit Zoommöglichkeit und Palette. Man kann einzelne Sprites daraus auch direkt als PNG, JPEG oder GIF exportieren. Geplant als kostenlose Software.

ArchiveViewer

Aus der Reihe „Java-basierte Software für RISC OS, aber nicht unter RISC OS“: eine grafische Oberfläche zur Anzeige der Inhalte typischer RISC OS-Archivdateien wie Spark, ArcFS, PackDir, Squash und ZIP, mit voller Filetype-Unterstützung. Basiert hauptsächlich auf der großartigen Vorarbeit namens riscosarc von James Woodcock. Geplant als kostenlose Software.

BBC BASIC Detokenizer

Aus der Reihe „Java-basierte Software für RISC OS, aber nicht unter RISC OS“: ein kleines Tool, um tokenisiertes BBC BASIC V/VI in plain text umzuwandeln. Mit oder ohne Zeilennummern. Geplant als kostenlose Software.

FilecoreImageReader

Software, um Sprites zu lesen, um Archive zu lesen, um BBC BASIC zu lesen…wofür das alles? Auslöser war der vorerst letzte Teil aus der Reihe „Java-basierte Software für RISC OS, aber nicht unter RISC OS“: ein mächtiges Werkzeug, um Filecore-Images (.adf, .hdf) anzuschauen und Dateien und/oder Verzeichnisse daraus zu extrahieren. Unterstützt D, E(+) und F(+)-Format, minimaler Speicherverbrauch auch bei riesigen Images. Anzeige des Verzeichnisbaumes mit den „echten“ RISC OS-Icons. Anzeige der Inhalte von Sprite-Dateien, Archiv-Dateien, Plain-Text-Dateien und BASIC-Dateien (andere Dateitypen werden in einer Hexdump-View angezeigt). Im Moment baue ich gerade echte Acorn Latin 1 Codepage-Unterstützung, um sowohl die Plain-Text-Anzeige als auch die Konvertierung der Dateinamen besser hinzukriegen. Und ich hätte gerne eine Filer-like-Ansicht für einige Inhalte, damit das eleganter aussieht. Und es gibt noch irgendwo einen Bug, der bei einem Disc-Image das mir vorliegt bei, Scannen der Verzeichnisstruktur in eine Endlosschleife gerät. Mindestens das Erkennen der Endlosschleife mit sauberem Abbruch des Lesevorgangs wäre Voraussetzung für ein baldiges Release. Außerdem würde ich gerne automatisch die !Sprites-Dateien von Apps direkt zur Visualisierung verwenden.

Ein Projekt wie FilecoreImageReader ist natürlich in ständiger Gefahr, dem „Feature Creep“ zu erliegen. Man könnte doch bekannte Filetypes aus der PC-Welt auch noch direkt als Inhalt anzeigen (Grafikformate, PDF, PostScript…). Und generell die UI Filer-like machen. Und noch ein RISC OS-artiges Look&Feel für Swing bauen. Und eine Anzeige von Draw-Files ermöglichen. Und Templates. Und Impression…und Artworks…

Auf jeden Fall wird es eine kostenpflichtige Version mit all den coolen Features geben, und eine freie Version wo man nur den nackten Verzeichnisbaum mit Extraktionsmöglichkeit hat, möglicherweise auch limitiert auf Floppy-Images.

PipeDream 4.56 verfügbar

2018-12-22 17:24

Stuart Swales hat die Verfügbarkeit von PipeDream 4.56 verkündet (inzwischen durch 4.56.01 mit minimalem Bugfix ersetzt). Genauere Details kann man der länglichen Release-Historie entnehmen. Interessanterweise sind – neben den unvermeidlichen Bugfixes – einige UI-Änderungen in Richtung Style-Guide-Compliance eingeflossen. PipeDream war da schon mindestens seit Version 3 (die erste, die ich selbst benutzt habe) im Detail doch häufig abweichend von dem, was unter RISC OS so gängig war. Vom Save/Discard/Cancel-Dialog bis zu den Feinheiten des Save-As-Fensters.

Schön auch, dass die genutzten Ressourcen nun sprach-/ländertechnisch sauber separiert wurden, was eine deutsche Version stark vereinfachen würde. Nur die Älteren werden sich erinnern, dass PipeDream 3 zu RISC OS2-Zeiten eine der wenigen Anwendungen war, die komplett auf Deutsch verfügbar war. Aber dann eben nur auf deutsch, der geneigte Benutzer konnte nicht für die englische Originalversion optieren. Aus dieser Zeit stammt auch noch das rudimentäre deutsche Wörterbuch für die Rechtschreibprüfung.

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!