Vergangenes Wochenende war mal wieder GAG-Treffen in Siek, und traditionell war ich wieder mit dabei. Inzwischen ist das GAG-Treffen beinahe die einzige Möglichkeit in Deutschland, Gleichgesinnte in Sachen RISC OS persönlich zu treffen – dies auch ein Hinweis auf die Jungs von der Arche e.V., mal wieder ein Treffen im Unperfekthaus zu organisieren. Und vielleicht sogar einen Hinweis an mich selbst, ein allerletztes Treffen im wilden Süden zu veranstalten?
Jedenfalls ist das GAG-Treffen für mich immer eine Chance, lange aufgeschobene Dinge in Angriff zu nehmen. Diesmal auf der Tagesordnung stand z.B. der Otter-Browser (eine Qt-WebKit-Portierung), den ich einer intensiven Prüfung unterzog. Performance ist hier das große Thema, denn für RISC OS-Verhältnisse ist die Software riesig – der Startup dauert ewig (Raspberry Pi 2 mit schneller SD-Karte: knapp 30s), was nicht zuletzt an der neuen Welt der Shared Libraries liegt – viele kleine Dateien dauern eben länger als eine große Datei. Hier kann der Einsatz der RAM-Disc Wunder bewirken, was wieder mal zeigt, dass das ganze File-IO-Thema unter RISC OS dringend einer grundlegenden Überarbeitung bedarf – anständiges Buffering und Cacheing wären ein guter Anfang. Etwas frustrierend war die Tatsache, dass wir den Otter nur auf dem RPi 2 zum Laufen bekommen haben, nicht jedoch auf PandaBoard und IGEPv5. Grund weiterhin unklar.
Prinzipiell halte ich den Otter-Browser für einen großen Schritt in die richtige Richtung, auch wenn die derzeitige Lösung noch stark holpert. Die Frage ist, ob man auf der Qt-Basis eine performante und anständig in RISC OS integrierte Lösung ans Laufen bringt, oder ob man das große Rad drehen und WebKit direkt an RISC OS anflanschen muss.
Genug von der Browser-Geschichte. Ein Highlight war die Kurzdemo der neuen Khronos-Library, die von Lee Noar entwickelt wurde und die praktisch ein Wrapper-Modul um Linux-Code ist, der diverse Hardware-Features des Raspberry Pi (alle Varianten) zur Verfügung stellt, darunter Video-Overlays und Open GL. Die verfügbaren Beispiele sind noch sehr rudimentär und durchaus absturzwillig (wobei dann das Overlay erhalten bleibt und nur ein Reset hilft), aber die Software ist noch jung, gerade mal seit etwa einer Woche in der mehr oder weniger freien Wildbahn.
Ich widmete mich auch noch intensiv einer anderen Front: Emulation. ADFFS, ArchiEmu und ArcEm standen auf dem Programm. ADFFS war ein kompletter Fehlschlag – ich konnte keines der angeblich auf dem Pi unterstützten Spiele zum Laufen bringen, und finde das Handling zum Starten der Spiele sehr unergonomisch. Ich werde mich dieser Tage mal ins JASPP-Forum begeben, um die Probleme aufzuarbeiten. ArchiEmu habe ich nur kurz angetestet, hier erntete ich nur direkte Abstürze. ArcEm war etwas vielversprechender, aber die Ergonomie ist stark suboptimal – so muss man z.B. zu verwendende Floppies und Harddiscs nach einer bestimmten Konvention benennen, um sie verwenden zu können. Und es ist mir nicht gelungen, den selbstextrahierenden SparkPlug unfallfrei auf die emulierte MFM-Platte zu bekommen. Immerhin hat der Boot sowohl nach RISC OS 2 als auch RISC OS 3.10 geklappt. Ich denke, darüber gibt es mal einen eigenen Blog-Artikel.
Den ARMX6 (i.MX6-Basis) gab es ebenfalls zu sehen. Sauschnell (vor allem in Sachen Platte – S-ATA statt USB zahlt sich aus), aber eben leider mit dem üblichen üblen R-Comp-Preisaufschlag. Und wie sich rausgestellt hat gibt es doch an der einen oder anderen Stelle noch Kompatibilitätsprobleme zu beheben, aktuell macht Photodesk Probleme.