USB-Stack – des Updates erster Schritt

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

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

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

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

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

Von RISC OS, ARMX6 und dem Wandboard Quad

Aufmerksame Beobachter der RISC OS-Szene kennen natürlich den ARMX6 von R-Comp, ein schönes wenn auch recht preisintensives Stück Hardware (auf Basis des Freescale i.MX6 auf einem Wandboard Quad sitzend) das als erster RISC OS-Rechner die Plattenperformance des IYONIX pc durch S-ATA zu übertreffen wusste. Schönheitsfehler war immer, dass R-Comp eine „commercial licence“ von RISC OS 5 hatte und deshalb nicht verpflichtet war, sofort alle notwendigen Änderungen und Hardwaretreiber usw. an ROOL zurückzuspiegeln.

Offenbar ist jetzt die Zeitschranke für das Feedback der Anpassungen abgelaufen, denn es gibt nun im ROOL-Downloadbereich den i.MX6/Wandboard-Teil, wo ein aktueller Nightly Build zur Verfügung steht.

Endlich gibt es also (sofern das ROM vollständig alle Features abdeckt, das habe ich noch nicht geprüft) für Interessierte eine Low-Cost-Möglichkeit, sich ein RISC OS-Gerät mit anständiger Platten-I/O für überschaubares Geld zusammenzustöpseln. Das Wandboard Quad (die Variante, die S-ATA on board hat) liegt derzeit bei nominell 119US$, in Europa scheint eine noch lieferfähige Bezugsquelle Mouser Electronics zu sein, die haben es für knapp 150€ im Programm. Wobei ich überraschenderweise gesehen habe, dass Watterott im Moment das TI OMAP5432-EVM für unter 200€ verkauft. Aber soweit ich weiß gibt es dafür keine frei verfügbare S-ATA-Implementierung für RISC OS, ist also nur bedingt als Ersatz geeignet, von der Micker-Auflösungsproblematik der OMAP5-Reihe ganz abgesehen.

Inwiefern andere Boards mit i.MX6 damit funktionieren – keine Ahnung. CuBox-i4Pro, SABRE Lite oder das MarS Board wären interessante Kandidaten. Aus der Efika MX6-Serie ist wohl nie was geworden – schade, MX Smartbook und MX Smarttop sahen in der i.MX5-Variante schon sehr elegant aus.

Zwei Clares-Klassiker wieder verfügbar

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

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

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

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

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

Frohes Fest, guten Rutsch, auf ein Neues in 2018

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

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

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

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

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

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

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

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

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

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

ADFFS 2.63 verfügbar

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

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

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

Hier kann man ADFFS 2.63 runterladen.

Titanium-Komplettsystem bei a4com

Auf der Suche nach einem Titanium-System (meine Lust auf Eigenbau hielt sich in Grenzen) bin ich mir mit Detlef Thielsch von a4com handelseinig geworden. Im Gegensatz zu den Vorgängerprodukten BIK (BeagleBoard-in-Kiste – in England von R-Comp als „ARMini“ verkauft), PIK (PandaBoard-in-Kiste – in England von R-Comp als „ARMiniX“ verkauft) und WBK (Wandboard-in-Kiste – in England von R-Comp als „ARMX6“ verkauft) sind beim Titanium aufgrund dessen Standard-Konformität – das Board ist kompatibel mit ATX-Gehäusen und ATX-Netzteilen, USB-Ports stehen sowohl intern als auch extern reichlich zur Verfügung, mit 4 S-ATA-Ports kann man problemlos SSD und optisches Laufwerk integrieren ohne auf USB-SATA-Adapter zurückgreifen zu müssen – keine größeren Handstände notwendig.

Folgerichtig bietet a4com nun das „TIK“ an, „Titanium-in-Kiste“. Die Preise ab 900 EUR sind geradezu ein Schnäppchen, bei R-Comp zahlt man für die „TiMachine“ denselben Betrag in Britischen Pfund, bei fragwürdigem Mehrwert (zum von R-Comp so gelobten tollen Softwarebundle werde ich zu gegebener Zeit ein paar Worte schreiben). Bei CJE sieht es beim RapidO Ti nicht besser aus. Also: das a4com-Angebot ist absolut konkurrenzfähig und empfehlenswert.

So weit, so schön. Für wen ist nun ein Titanium-System erste Wahl? Für alle, die nicht zwingend auf höchste Bildschirmauflösungen angewiesen sind („dank“ des verwendeten TI OMAP5 sind ohne einen Monitor, der die beiden Videoausgänge des Titanium „side by side“ anzeigt, maximal 1920×1200@60Hz drin – in Zeiten von bezahlbaren QHD- und 4K-Monitoren definitiv zuwenig) und den anspruchsvollen Preis nicht scheuen. Denn sowohl was CPU-Leistung (der Cortex-A15 ist nicht nur aufgrund der 1,5GHz-Taktung konkurrenzlos, sondern auch bei der Leistung pro Takt mit 3,4 DMIPS/MHz den Cortex-A9-Konkurrenten i.MX6 (Wandboard, ARMX6) und OMAP4 (Pandaboard, ARMiniX) mit lediglich 2,5 DMIPS/MHz weit überlegen – übrigens nicht nur in der Theorie, auch Benchmarks untermauern das) als auch I/O-Leistung (4 S-ATA-Ports, echtes Gigabit-Ethernet – Benchmarks folgen noch) angeht ist ein Titanium-System weit vorne. Für Budget-Fetischisten würde ich eher einen Pi3 empfehlen – 4K-Video, verhältnismäßig schnelle CPU (jedenfalls deutlich vor der Cortex-A9-bestückten Hochpreiskonkurrenz), nur bei der I/O-Leistung (Netzwerk 100MBit/s und über USB2.0, Massenspeicher über SD oder USB2.0) fällt er natürlich deutlich ab – you get what you pay for.

Praxisberichte mit Titanium vs. ARMX6 folgen hoffentlich demnächst.

Das Titanium-Board und die Suche nach dem passenden Netzteil

Der IYONIX pc war bekanntlich das erste RISC OS-taugliche Mainboard, das mit Standard-ATX-Netzteilen zusammenarbeitete. Auf dem langen Weg vom ersten Archimedes (vermutlich war die Parallelschnittstelle die einzige „standardkonforme“ Schnittstelle – die serielle war RS423 statt RS232, der Monitorausgang war 9polig aber immerhin signaltechnisch weitgehend „PC-kompatibel“, der Floppyanschluss war zwar Shugart-kompatibel aber eher wählerisch) über den A5000 (IDE, Parallel, Seriell, VGA, Floppy – alles weitestgehend kompatibel zum damaligen PC-Standard, aber immer noch die merkwürdige Acorn-Tastatur mit dem integrierten Busmaus-Anschluss) bis zum A7000 (endlich PS/2 sowohl für Maus und Tastatur) war man immer näher an die Welt der Standardkomponenten und -schnittstellen gerückt. Nur Gehäuse und Netzteil blieben bis zuletzt proprietär.

Mit dem IYONIX pc fielen auch diese beiden Bastionen – die Platine im ATX-Format, und das Netzteil dazu passend. Allerdings stellte sich bald heraus, dass der IYONIX eine echte Mimose war wenn es um die Zusammenarbeit mit der PC-Netzteil-Welt ging. Das Problem: er brauchte zu wenig Strom, vor allem auf dem 12V-Zweig. Und so war es eine gute Idee, das Gehäuse mit Platten und Brennern vollzustopfen, was dann die häufigeren Problemchen beim Kaltstart weitestgehend eliminierte.

Das Titanium-Board von Elesar ist in gewisser Hinsicht der natürliche Nachfolger des IYONIX. Nicht nur, weil das Hauptdesign von derselben Person stammt. Sondern auch weil das Board eben in gewöhnliche ATX-Gehäuse passt und mit ATX-Netzteilen zusammenspielen soll. Soll. Denn ganz so einfach ist es auch diesmal nicht. Die Basisanforderungen scheinen noch einfach zu erfüllen zu sein: ATX 2.3 oder neuer muss es sein, und der Mainboard-Connector ist der ältere 20Pin-Typ, so dass nur Netzteile mit der 20+4-Konfiguration in Frage kommen. 4 S-ATA-Stromstecker wären auch gut, denn das Board unterstützt bekanntlich (und das ist ein echtes Alleinstellungsmerkmal) 4 S-ATA-Geräte. Aber wie immer steckt der Teufel im Detail.

Inzwischen ist die PC-Welt ja bezüglich des Leistungsbedarfs eines Rechners weit enteilt. Unter 400W kann man ja fast nur riskieren, wenn man mit Chipsatz-Grafik auskommt und nicht allzu viele Laufwerke betreiben will. Beim Titanium wäre ein 200W-Netzteil eher angebracht. Und Schaltnetzteile brauchen nun mal in den meisten Konstruktionen eine gewisse Mindestlast, um sicher anzuspringen und stabile Spannungen zu liefern. Ironischerweise gab es zuletzt ein Update an der PC-Front, damit die Netzteile auch die extrem stromsparenden C6/C7-„Deep Power Down“-Modi der Intel-Prozessorgeneration ab Haswell funktionieren.

Drei Netzteile habe ich mit dem Titanium-Board zusammen getestet: ein No-Name-550W-Netzteil, ein be quiet! Pure Power 10 300W und ein be quiet! Straight Power 10 400W. Ergebnis: nur das Straight Power 10 funktioniert ohne Macken und Zucken mit der von mir definierten Minimallast „Titanium-Board und SSD“, die anderen Kandidaten brauchten nicht weniger als 3 Brenner, bis der Startup absolut zuverlässig funktionierte. Ob das mit dem laut Datenblatt „Zero Load Design“ zu tun hat, weiß ich nicht – eine Gegenprobe mit dem preiswerteren System Power 8 wäre interessant, das Pure Power 10 hat dieses Feature nicht.

Das Straight Power 10 ist auch sonst eine absolute Empfehlung. Der 135mm-Lüfter ist nahezu unhörbar, es hat absolut ausreichend Anschlüsse für S-ATA-Geräte sowie althergebrachte Molex- und Berg-Stecker (auch in S-ATA-Zeiten oft noch nützlich für Zusatzgeräte wie interne USB-Hubs oder Cardreader). Bisher bin ich so zufrieden, dass das Straight Power wohl auch den Weg in meinen nächsten Selbstbau-PC finden wird. Die fünf Jahre Herstellergarantie sind ebenfalls vertrauenserweckend.

Aemulor 2.40 ist da

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

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

 

20 Jahre CD(VD)Burn

Man schrieb den 31.Oktober 1997. In London fand die Acorn World statt, und CDBurn wurde dort im Vertrieb von WSS (Warm Silence Software) zum ersten Mal öffentlich vorgestellt.

Man erinnere sich zurück: es war die letzte Acorn World, der Risc PC war noch „state of the art“ und hatte gerade durch den StrongARM eine Frischzellenkur erhalten. CD-Brenner waren teuer und nur als SCSI-Geräte erhältlich. CD-R-Medien kosteten mindestens 10 DM, oft auch 15 DM. 74min/650MiB waren die maximal erhältliche Kapazität. Fast unendliche Weiten in Zeiten, wo die Festplatten noch im deutlich einstelligen GB-Bereich unterwegs waren, vor allem in der Geschmacksrichtung SCSI waren 2 GB schon fast High-End. Ironischerweise wurde die Software selbst noch auf Floppy Disc verkauft. DD 800 KiB wohlgemerkt.

Der einzige unterstützte Brenner war der Philips CDD2000, die Variante CDD2600 folge kurz darauf. Ich hatte damals das Glück, dass ich einen Brenner gekauft hatte, der eine öffentlich zugängliche Doku zum Command Set hatte – die Konkurrenz von Teac, Sony und Yamaha war da wesentlich verschlossener, man musste tatsächlich NDAs nach USA faxen, und die Antwort brauchte teilweise Monate. Von Teac habe ich bis heute nix gehört.

Die erste CDBurn-Version war „gerade so“ fertig geworden (und meine Entscheidung, die Software in Ada zu schreiben, ist im Rückblick auch nur durch eine Mischung aus Optimismus und Wahnsinn zu erklären) – die Audio-CD-Funktionalität war schon recht ausgereift, aber bei den Daten-CDs haperte es noch gewaltig. Es gab noch keine Möglichkeit, ein ISO-Image zu erzeugen, ehrlicherweise war es deshalb auch die Versionsnummer 0.99 – deshalb wurde ein quick’n’dirty port von mkisofs beigelegt, um zumindest nominell dieses Feature abhaken zu können. Auf der Acorn World sprach ich mit vielen potenziellen Käufern und versprach baldige Lieferung des ISO9660-Formatters – ein Versprechen, das viele vom Kauf überzeugte und das ich Gott sei Dank noch im selben Jahr mit dem Release 1.00 (ein kostenloses Update) halten konnte.

Einzige Konkurrenz damals war CDScribe von Eesox – die verkauften aber die Software nur im Bundle mit dem Laufwerk, und dieses auch noch gut doppelt so teuer wie das Laufwerk alleine kostete. Audiotechnisch war die Software auch stark unterbelichtet, und der beigelegte ISO9660-Formatter war auch nicht der Weisheit letzter Schluss. Vermutlich deshalb eroberte CDBurn den Markt im Sturm, obwohl gemessen an der PC-Konkurrenz doch eher featurearm und nicht billig.

Über die Jahre wurde featuretechnisch kräftig aufgerüstet, die Updates blieben kostenlos: Multisession-Unterstützung, Joliet-Unterstützung und konfigurierbares Namemapping für ISO9660, CD-RW-Unterstützung, Unterstützung aller MMC-kompatibler Laufwerke, IDE-Unterstützung für Risc PC/A7000, APDL/Microdigital und Simtec/RiscStation, Upgrader um endlich neue Versionen per Download anbieten zu können, und schließlich 32bit-Kompatibilität und Unterstützung für den IYONIX pc. Abfallprodukt der IYONIX-Kompatibilität war die abgespeckte Version CDBurn Lite, die jedem Castle IYONIX pc beilag.

Besonders die 32bit-Kompatibilität halte ich bis heute für ein Wunder, das nur durch Dummenglück erklärbar ist. Klar, es hilft auch, wenn man einen Martin Würthner kennt, der mal kurzerhand eine GNAT-Runtime patchen kann. Aber dass das ARM-Backend des GCC 2.7.2.1 tatsächlich ARMv8-kompatiblen Code erzeugen kann, ist auch als so ein Wunder zu bewerten.

2004 gründete ich dann hubersn Software, um den Vertrieb in die eigene Hand zu nehmen. Es folgte die Integration der DVD-Unterstützung für die neue Generation DVD-Brenner, was die Umbenennung in CDVDBurn nach sich zog, um schon namentlich klar zu machen, dass nun sowohl CDs als auch DVDs gebrannt werden konnten.

Und damit endet die Geschichte der offiziellen Releases – bis heute sind die Ergebnisse der weiteren Entwicklung nicht in einem neuen Release gemündet, sondern werden nur an Interessierte als Beta-Testversionen verteilt. Dazu gehört die DVD-RAM-Unterstützung, die USB-Unterstützung für RISC OS 5, die Blu-Ray-Unterstützung, der CD/DVD/Blu-Ray-Extraktor, die ARMv7-/ARMv8-Kompatibilität für die neue Hardware-Generation vom BeagleBoard bis zum Raspberry Pi 3, die Unterstützung für das neue S-ATA-taugliche ADFS im Titanium.

Der letzte Plan war, all diese Erweiterungen in einem „20th anniversary release“ zu bündeln, aber es fehlte etwas Zeit, um die Sache abzurunden: BD-R und BD-RE in der Dual-Layer und XL-Variante ist noch nicht unterstützt, DVD-R kann nach wie vor nicht geschrieben werden, und an der Kompatibilität mit den modernen (sprich: noch im Handel verfügbaren) Laufwerken hapert es auch noch. Ziel wäre, ein USB-Laufwerk und ein S-ATA-Laufwerk zu finden, mit dem problemlos CD-R/CD-RW/DVD+R/DVD+RW/DVD-RAM/BD-R/BD-RE geschrieben werden können.

Sollte es doch dieses Jahr noch ein Release geben – Arbeitstitel „CDVDBurn 3“ – Leser dieses Blogs erfahren es als erste.

RPCEmu demnächst Qt-basiert

Über die RPCEmu-Mailingliste kam heute die Bitte von Peter Howkins, sich am Test von RPCEmu 0.8.99 zu beteiligen.

Was ist neu in dieser Version von RPCEmu? Endlich wurde die unselige Allegro-Bibliothek über Bord geworfen, stattdessen wird jetzt Qt5 verwendet. Was gleichzeitig dazu führt, dass das UI (Menüs, Einstellungen) jetzt unter Windows, Mac und Linux vollwertig ist und nur einmal gepflegt werden muss.

Das Screenmode-Handling wurde im Fullscreen-Modus dahingehend geändert, dass nun auf die native Auflösung skaliert wird und nicht mehr der Bildschirmmodus selbst verändert wird, was bekanntlich unter nicht-RISC OS-Betriebssystemen erstaunlich oft zu Problemen führt – in meinem Fall hat Windows regelmäßig fälschlicherweise nach Rückkehr aus dem Fullscreen-Modus gemeldet, ich würde nicht die native Auflösung des Displays verwenden und solle das doch bitte ändern.

Gleichzeitig wurde auf das Qt-Threadingmodell umgestellt, so dass nun die Emulation sauber im Hintergrund weiterläuft, während man die Menüs öffnet oder Einstellungen anpasst. Auch gefreut hat mich der neue Warndialog, der einen auf den bevorstehenden Reset hinweist wenn man die Einstellungen ändert.

Ein paar Bugfixes bei der ARM-Emulation sind auch eingeflossen.

Ironischerweise hilft die Umstellung von Allegro auf Qt5 auch für eine RISC OS-Portierung – Chris Gransden, Meister der tausend Portierungen, hat direkt die Maschinerie angeworfen und eine mehr oder weniger lauffähige „RISC OS 5 on RISC OS 5“-Emulation vermeldet. Performancetechnisch sparsam (angezeigte 18 MIPS auf einem Titanium, also etwa ARM3-Speed – kein Wunder, enthält RPCEmu doch nur einen x86/x64-JIT und muss bei ARM-on-ARM rein interpretierend arbeiten), mit einigen Nicklichkeiten wie nicht funktionierender Tastatureingabe, aber ansonsten funktionsfähig.

Update

Chris Gransden hat einen Teaser-Screenshot veröffentlicht, RISC OS 4 in RPCEmu auf RISC OS 5-Titanium.