Hubersn

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 CD2600 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 http://www.hubersn-software.com/, 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.

Zero Page und RISC OS 5 – Update

Wer sich nicht mehr erinnert – seit Juli 2015 haben alle RISC OS 5-Development-Builds die Zero-Page verschoben und laufen in der sogenannten „high processor vectors“-Konfiguration. Das ermöglicht einen deutlich stabileren OS-Betrieb, führt aber dazu, dass so manche Software, die bisher einwandfrei lief, aufgrund von (vermutlich) unkritischen NullPointer-Zugriffen den Abgang macht. Auch zu Diagnosezwecken, aber auch zur Wahrung der Rückwärtskompatibilität wurde deshalb das ZeroPain-Modul erfunden, das Zugriffe auf die Zero Page loggt. So mancher Uralt-Bug wurde dadurch erfolgreich ausgemerzt.

Ursprünglich war angedacht, ab 1.1.2016 ZeroPain wieder abzuschaffen. Das war wohl viel zu optimistisch, und es gab meines Wissens erheblichen Widerstand von R-Comp und CJE, die bekanntlich fertige RISC OS-Rechner inklusive eigens getesteter RISC OS 5-Versionen für die weniger bastelfreudigen User verkaufen. Letztlich das alte RISC OS-Problem: zuwenige Entwickler, die sich um die Pflege der Software kümmern können, dazu einige Software ohne verfügbaren Quellcode.

Jetzt gibt es eine neue Marschrichtung: einen Kompatibilitätsmodus, „compatibility page“ genannt. Per OS_Memory 20 auch softwaremäßig kontrollierbar. Ich denke, das ist ein guter Kompromiss – es ermöglicht allen Parteien, zu einem gemeinsamen ROM-Build zurückzukehren und je nach Zielgruppe zwischen maximaler Rückwärtskompatibilität oder gescheiter Entwicklerunterstützung einfach umschalten zu können. Software, die zu Emulationszwecken die Zero Page selbst simulieren will (ADFFS ist da ein Kandidat, siehe Post zur Verfügbarkeit von Version 2.62), kann ebenfalls entsprechend agieren. ZeroPain ist für Entwickler und Benutzer, die Entwickler unterstützen wollen, weiterhin verfügbar.

Zap und ARMv8

Während StrongEd von Fred Graute kontinuierlich weiterentwickelt und ständig an neue CPU- und OS-Erfordernisse angepasst wird, liegt Zap maintenancemäßig seit längerer Zeit brach. Tank hat initial die 32bit/ARMv7-Version gebaut und ein paar aufgetauchte Bugs gefixed, dann hat André Timmermans Bugfixes beigesteuert, und nun hat Rick Murray ein paar ARMv8-Showstopper bereinigt (siehe dieser Thread im ROOL-Forum).

Im August letzten Jahres hat Ex-Zap-Mitentwickler James Aylett das Zap-CVS nach Git konvertiert und auf GitHub zur Verfügung gestellt. Ein „offizieller“ neuer Maintainer hat sich leider noch nicht gefunden – es bleibt zu hoffen, dass die Zap-Interessierten das irgendwie koordiniert kriegen und sich nicht gegenseitig mit lokalen Änderungen und insonsistenten Patches und Versionen ins Knie schießen.

Als überzeugter StrongEd-Benutzer greife ich trotzdem ab und zu auf Zap zurück, wenn ich nicht gerade Ada programmiere, es wäre schlicht eine Schande wenn ein solch feines Stück Code nicht mehr in einer aktuellen und gepflegten Version zur Verfügung stünde.

Leider hat sich auch noch keiner gefunden, der den Zap-Ada-Mode nach 32bit konvertiert…leider bin ich kein routinierter Assembler-Programmierer, wird vielleicht Zeit die alten Kenntnisse wieder aufzufrischen.

Neue VNC Server-Version

Der einzige verfügbare VNC-Server unter RISC OS, derzeit bei Tausendsassa Jeffrey Lee in der Pflege, hat ein Update erfahren. Zwei signifikante Bugs wurden gefixed: er funktioniert nun auch, wenn der Bildschirmspeicher auf non-packed-scanlines basiert (existiert so derzeit nur auf dem Pi, für Details siehe hier). Und es wurde ein Bug beim Clipboard-Handling im RAM transmit protocol gefixed, der im Zusammenspiel mit StrongEd aufgefallen war.

Ich selbst benutze den VNC-Server auf meinem ARMX6, um bequem vom Laptop im Wohnzimmer auf RISC OS zugreifen zu können. Funktioniert immer besser über die Jahre – die ersten Versionen von VNC Server waren nahezu unbrauchbar, vor allem bei großen Farbtiefen und Auflösungen. Inzwischen funktioniert das leidlich gut.

ADFFS 2.62 verfügbar

Man mag mir meine kurze Blog-Abstinenz verzeihen, ich hatte kurzfristig mit einem entzündeten Schleimbeutel im Ellenbogen zu kämpfen. Zum Wiedereinsteig gibt es natürlich nichts besseres als ein altes Lieblingsthema von mir: ADFFS.

Gar nicht lange nach 2.61 hat Jonathan Abbott heute die Verfügbarkeit von Version 2.62 verkündet.

Es kehrt mehr Benutzerfreundlichkeit ein – ADFFS ist nicht mehr länger auf ein aktives SparkFS angewiesen, um die JFD-Images zu lesen, die technisch ja nichts anderes als ZIP-Archive sind. Das ist in vielerlei Hinsicht positiv – viele Problemmeldungen von Benutzern hatten mit nicht aktivem SparkFS zu tun, d.h. Jon hat jetzt weniger Arbeit beim Support. Zudem ist es speichertechnisch vor allem auf den alten Maschinen ein Segen, obwohl SparkFS jetzt kein ausgewiesener Speicherfresser war. Aber bei einem typischen Maximum von 4 MiB RAM zählt jedes Byte.

Weitere Verbesserungen im Detail beziehen sich vor allem auf die Kompatibilität mit neuesten RISC OS 5.23 Nightly Builds, wo es ja erneut Änderungen am Handling der Zero Page gab (Beitrag folgt noch). Bugfixes für einige Spiele sind auch inklusive, z.B. für Stunt Racer 2000 sowie einem Spiel, das m.W. in Deutschland immer noch nicht genannt werden darf.

Also: 2.62 runterladen und Spaß haben. Nicht vergessen: auf den Pis muss EDID deaktiviert werden, damit die GPU das Scaling übernimmt.

Neues vom ROOL-Repository

Immer wieder 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.

Aktuell wird am Filecore nebst ADFS und HForm rumgeschraubt, um idlen auf 21 Bits zu erhöhen. Damit kann man dann die maximal erlaubte Anzahl von Objekten in einer Filecore-Partition hochschrauben, was es wiederum erlaubt, bei gleicher Partitionsgröße die LFAU etwas kleiner zu wählen, was wiederum die Platznutzung vor allem bei vielen kleineren Dateien (und was würde RISC OS mehr auszeichnen als die Vielzahl kleiner Dateien – nicht nur die !Run- und !Boot-Skripte sind sehr klein, sondern auch !Sprites und !RunImage und leider oft auch !Help – ich spreche aus Erfahrung) deutlich verbessert. Allerdings wird die Map auch wieder entsprechend größer.

Es scheint auch etwas in Richtung USB3-Unterstützung zu geschehen, am XHCI-Treiber wird gearbeitet. Ab und an sind auch Einsprenkel aus den Arbeiten rund um die Multicore-Unterstützung zu sehen. Und sogar der gute alte Maestro hat eine Pflegekraft gefunden. Wohl nur Teilzeit, aber immerhin.

Auch die Access-Einbindung in OmniClient könnte demnächst ein Comeback feiern – wenn ich mich recht erinnere, lagen die Rechte für den Code bei einer anderen Firma, offensichtlich hat man sich da nun geeinigt.

Es gibt nun ein BASICVFP-Modul, quasi ein BASIC64 mit VFP statt FPE.

Zuletzt wurde noch ein interessanter Bug im EDID-Umfeld gefixed – die Bootsequenz kam zum Erliegen mit einem bösen Absturz, wenn man keinen Monitor angestöpselt hatte bzw. dieser keine sinnvollen EDID-Daten zurücklieferte (z.B. EDID-Infos mit Länge 0, was laut Standard wohl valide ist). Es gibt jetzt einen sicheren Fallback in Form des klassischen Mode 27 – quasi wie beim PC-BIOS.

ADFFS 2.61 verfügbar

Ein gutes halbes Jahr ist vergangen seit dem Release von Version 2.60, und so hat Jonathan Abbott nach zahllosen Verbesserungen und Bugfixes heute die Verfügbarkeit von Version 2.61 verkündet.

Hauptänderung ist die Verwendung eines 26bit-BASIC-Moduls unter JIT-Kontrolle anstatt des bisherigen Ansatzes, das Original Maschinen-BASIC zu patchen. Außerdem wurden viele der Patch-Skripte verbessert, so dass nun eine ganze Reihe Spiele problemlos auf dem Pi laufen – Highlights sind hier sicherlich die StrongARM-Versionen von Chocks Away Compendium und Stunt Racer 2000, sowie Syndicate+ und X-Run.

Also, runterladen und ausprobieren. Läuft inzwischen auf jedem Pi inklusive des ARMv8-RPi 3. Man muss eigentlich nur beachten, dass bei zu neuen RISC OS-Versionen die Umschaltung der Auflösung weiterhin von der Pi-GPU übernommen wird, damit AnyMode sein Werk tun kann. Dazu braucht es die Zeile disable_mode_changes in der CMDLINE.TXT im Pi-Bootloader. Besitzer eines klassischen Archimedes müssen sich um solche Feinheiten natürlich nicht kümmern, dürfen zum Ausgleich aber lange Ausschau nach einem funktionierenden Monitor halten.

Raspberry Pi – gute Gehäuse, schlechte Gehäuse

Angesichts seiner Einsatzuniversalität türmen sich langsam die RPis bei mir auf dem Schreibtisch. Und so habe ich hier einen Sack voll Gehäuse für die Dinger stehen und kann demzufolge qualifiziert darüber berichten, welche Gehäuse nach meiner Meinung super sind und welche unbrauchbar. Und welche irgendwo dazwischen. Während beim originalen RPi 1 noch praktisch jedes Gehäuse mehr oder weniger brauchbar war, liegt die Sache seit der RPi eine microSD-Karte schluckt etwas anders – die Full-Size-SD-Karte stand so weit aus dem Gehäuse, dass sie problemlos bei jedem Gehäuse wechselbar war, bei der microSD ist die Geschichte komplizierter, zumal nur B+ und B 2 einen Federmechanismus für die Karte haben, während sie beim B 3 nur gesteckt wird. Es gibt Gehäuse, wo man die microSD-Karte schlicht nicht greifen kann um sie herauszuziehen.

Ich betrachte hier nur die Modellvariante B für alle RPi-Varianten.

Das fiktive ideale Gehäuse

Mein Wunschgehäuse wäre stabil, die Innereien einfach zugänglich, mit einfach zugänglicher microSD-Karte, im geschlossenen Zustand GPIO-fähig, stapelbar, schick und in verschiedensten Farben erhältlich (zur einfachen Unterscheidung verschiedener Einsatzzwecke ohne weitere Beschriftung – bei mir am Start: RPi B+, RPi 2, RPi 3, RISC OS, Linux, RetroPi, Kodi…).

Corkea Aluminium-Gehäuse

Mein derzeitiger Favorit. Passgenau, mit anständiger Öffnung um die microSD-Karte auch wieder rauszubekommen, in fünf verschiedenen Farben erhältlich, und beigelegt auch noch ein Satz Kühlkörper sowie ein Schraubendreher. Dazu sauber rechteckig, also auch stapelbar.

Wird bei Amazon.de für 12-13€ verkauft, hier der Link zur schwarzen Variante.

Als Nachteil mag empfunden werden, dass geschraubt werden muss – an Stirnseite und Rückseite jeweils 4 Schrauben halten das Teil bombenfest zusammen, die RPi-Platine wird mit dem Gehäuseboden verschraubt. Aber man kann das Ding halt nicht „kurz mal“ aufmachen. Zumal Deckel und Boden etwas hakelig aufeinander geclipst werden.

Offizielles Raspberry Pi-Gehäuse

Auch ein sehr gutes Gehäuse. Komplett gesteckt ohne Schrauben, mit anständiger Öffnung um die microSD-Karte auch wieder rauszubekommen, leider nur in zwei Farben erhältlich, wovon eine der grauenvolle Versuch ist, eine Art Himbeerfarbe darzustellen. Der Deckel weist eine Rundung auf, so dass Stapelung nicht wirklich funktioniert.

Kostenpunkt knapp 10€, hier der Link zur schwarzen/dunkelgrauen Variante bei Amazon.

Obwohl nur gesteckt und aus Kunststoff, ist das Gehäuse durchaus hochwertig und stabil. Braucht man Zugriff auf die GPIOs, kann man entweder den Deckel weglassen oder das Wandelement.

Durchwachsene Gehäuse

  • FabLabShop Holz-, Plexiglas- und Design-Gehäuse – im Prinzip super, wird einfach zusammengesteckt und hält bombenfest, dazu individuell gravierbar und trotzdem preisgünstig. Haken: die microSD-Karte ist faktisch nicht mehr zugänglich ohne das Gehäuse zu demontieren.
  • Tek-Berry Design-Gehäuse – für dieses Gehäuse gibt es einen VESA-Adapter, der eine einfache Montage an der Rückseite eines Fernsehers oder Monitors nach VESA 50/75/100-Standard erlaubt. Dafür ist es extrem schlecht belüftet (die Lüftungslöcher sind zur Unterseite der RPi-Platine hin!) und die microSD-Karte ist kaum zu greifen. Typische Plastik-Snap-In-Befestigung, Auseinanderbau also eher schwierig und lieber nicht so oft aufgrund akuter Gefahr des Abbrechens diverser Plastiknasen. Kostet dafür auch nur knapp 5€. Gibt es in drei „Farben“ schwarz, weiß und transparent.
  • Ein namenloses schwarzes Gehäuse – etwas fummelig in der Montage, microSD-Karte kaum zu greifen, dafür preiswert.
  • CamdenBoss Gehäuse in Transparenz-Carbon-Optik – ich hatte noch die Vorgängerversion, wo die microSD-Karte nur nach Gehäuse-Demontage erreichbar war, nach den Bildern zu urteilen ist das nun besser gelöst. Hauptproblem dieses Gehäuses: Snap-In-Montage, und bei der Demontage kann sehr leicht was abbrechen (sprich: bei mir ist was abgebrochen). Die 10€ meiner Ansicht nach nicht wert.

Muss-Ich-Noch-Testen-Gehäuse

Die folgenden Gehäuse stehen noch auf meiner Merkliste und werden irgendwann den Weg ins Testlabor finden.

  • oneninedesign RPi Quattro-Gehäuse – endlich mehr Platz als nur für den RPi selbst!
  • Alu-Gehäuse gibt es in verschiedenen Farben
  • Orbital Case – ein schöner Kontrast zum Rechteck-Boxen-Einheitsbrei, aber der direkte Zugriff auf die microSD-Karte scheint hier auch nicht möglich zu sein