Hubersn

Alte Spiele, neues ADFFS

Jon Abbott hat das Release der neuesten Version von ADFFS, 2.55 beta, verkündet (hier das passende JASPP-Forum-Posting dazu mit allen Details).

Was ADFFS macht und kann, habe ich in einigen früheren Blogposts schon beschrieben.

Was gibt’s neues? Es ist das erste Release, das den Fokus auf den Raspberry Pi legt – das Original, also nicht die Versionen 2 und 3, da sich ADFFS zunächst um die Emulation auf ARMv5-Plattformen (also eben jenem Raspberry Pi 1 (A, B, B+, Zero) und quasi nebenbei als Abfallprodukt auch dem IYONIX pc) kümmert. ARMv7-Unterstützung ist rudimentär enthalten, hat aber noch viele Einschränkungen.

Voraussetzung für die neue ADFFS-Version ist eine aktuelle Version von RISC OS 5, namentlich 5.23 nach dem 6. April 2016, und zwar ein unveränderter Build mit High-Vector-Semantik und relocated zero page. Das gilt logischerweise nicht für die auch weiterhin unterstützten klassischen Plattformen wie Archimedes und Risc PC, da tut es jede alte schäbige RISC OS-Version.

Der “Game Count”, also die Zahl lauffähiger Spiele, liegt nun bei beeindruckenden 130 – vermutlich werden selbst eingefleischte RISC OS-Nutzer Probleme haben, mehr als 50 Spiele für die Plattform zu benennen. Im Rahmen des JASPP-Projekts wurden weitere 17 Spiele zum freien Download veröffentlicht, hauptsächlich alte Minerva-Titel aus den 80ern, aber auch ein paar bekanntere Spiele von den Portiermeistern von Krisalis (Lemmings 2, Manchester United, Pipe Mania).

Besonders die nun sauber unterstützten 50Hz-Modi (auch auf dem Pi, wenn der Monitor/Fernseher mitspielt) und die vielen Verbesserungen im Sound-Bereich lassen auf erhöhten Spielspaß hoffen. Vielleicht dann auch demnächst auf den ARMv7-Plattformen.

JavaScript-JIT für Otter und QupZilla

Die Portierung von Qt5 durch Lee Noar, die die Basis für Qt5WebKit und damit die Portierungen von Otter und QupZilla durch Chris Gransden ermöglichte, steht vor dem nächsten großen Schritt. Bisher konnte die JavaScript-Engine nur im Interpreter-Modus betrieben werden. Neben dem offensichtlichen Performance-Problem war auch zu sehen, dass der Interpreter-Modus eine Menge mehr Bugs und Unschärfen hatte, schlicht weil die anderen Plattformen ihn nicht (mehr) verwenden.

Nun ist es Lee Noar gelungen, die Probleme der JavaScript-JIT-Engine weitgehend zu beheben (für Detalverliebte: Revision 7074 im GCCSDK-SVN-Repo), wie Chris Gransden mitteilt. Sogar aufwändige JavaScript-basierte Seiten wie OpenStreetMap.org scheinen nun – genügend CPU-Power vorausgesetzt (Cortex-A15 empfohlen…) – anständig zu funktionieren. Zweifellos ein großer Schritt für die RISC OS Browsing Experience.

Testversionen sollen demnächst zur Verfügung stehen.

Raspberry Pi 3 verfügbar

Heute hat die Raspberry Pi Foundation den Raspberry Pi 3 offiziell vorgestellt. Er ist bereits (im Gegensatz zum RPi Zero, der immer noch bei der Verfügbarkeit schwächelt) in kleinen Stückzahlen bei den üblichen Verdächtigen lieferbar. Preise liegen bei rund 40€.

Jetzt gibt es also harte Fakten. Die weichen gar nicht so sehr von den Gerüchten ab, die ich vorgestern eingesammelt habe:

  • SoC 1,2 GHz BCM2837 Quad-Core Cortex-A53 – also ARMv8 64bit, aber mit AArch32-Unterstützung (wichtig für RISC OS)
  • WiFi (802.11n) und Bluetooth (4.1) über BCM43438 on board

Rest ist unverändert zum RPi 2 – 1GB RAM, 4x USB2.0, 100MBit Ethernet über USB angebunden, analog Video/Audio out über Klinke, HDMI für digital Video/Audio, microSD-Slot. Es wird ein 2,5A-Netzteil empfohlen, wenn man die 4 USB-Ports voll belasten will. Alle Ports sind an der gleichen Stelle wie beim RPi B+ und RPi 2 B, die Gehäuse sind also kompatibel.

Performancetechnisch wird die Steigerung vermutlich bei 50% gegenüber dem RPi 2 liegen – etwas höherer Takt, und höhere Effizienz des Cortex-A53 gegenüber dem Cortex-A7. NEON soll deutlich schneller geworden sein.

Ben Avison hat ein paar interessante Details zur Rückwärtskompatibilität im ROOL-Forum gepostet. Es scheint diesmal kein übles Ei wie die Änderung der non-word-aligned-memory-access-Geschichte bei ARMv7 vs. ARMv6 zu geben, nur Kleinigkeiten die vermutlich nur das OS betreffen.

In Summe ist der RPi 3 eine super Sache – gleicher Preis wie bisher, und man hat die Chance preiswert einen realen 64bit-ARM zu betreiben. Mal sehen, ob oder optimistischer forumliert wann RISC OS den Sprung in die schöne neue 64bit-Welt schafft. Ohne einen maschinellen Weg, den Assembler-Code in seni 64bit-Pendant zu überführen, sehe ich da wenig Chancen.

Enger wird es nun für die teureren Angebote vom ARMX6 bis zum IGEPv5 oder Titanium. Diese haben natürlich immer noch Alleinstellungsmerkmale wie S-ATA oder Gigabit Ethernet, aber CPU-technisch dürfte der 1,2 GHz Cortex-A53 dem 1,2 GHz Cortex-A9 des ARMX6 ebenbürtig sein, und dem 1,5 GHz Cortex-A15 des IGEPv5 und Titanium zumindest auf den Pelz rücken. RISC OS-technisch hoffen wir also auf einen Raspberry Pi 4 nächstes Jahr mit einem Cortex-A72, der legt bei der Single-Core-Performance nochmal eine ordentliche Schippe drauf. Dann wird es allerdings Zeit, RISC OS die Nutzung mehrerer Cores beizubringen.

Mal sehen, ob man aus dem “hardware virtualization feature” des Cortex-A53 was machen kann (beherrscht auch schon der Cortex-A15). Jon Abbott (Schöpfer von ADFFS) hatte dazu interessante Ideen.

Raspberry Pi 3 im Anmarsch

Der heise-Newsticker hat es vermeldet: der nächste Streich der Raspberry Pi Foundation ist im Anmarsch, im Moment von der Presse Raspberry Pi 3 getauft. Sicher scheint zu sein, dass WLAN und Bluetooth serienmäßig mit an Bord sind. Laut diesem Titelbild von der kommenden Ausgabe des MagPi-Magazins können wir uns auch auf 64bit (also ARMv8) und 1,2 GHz freuen. Laut diesem Bild einer Seite des CPC-Katalogs wird der UK-Preis bei 26,38 UKP liegen (netto vermutlich), im Innern steckt ein Broadcom BCM2837 SoC – es bleibt also beim Quadcore. WLAN und Bluetooth wird durch den BCM43143 bereitgestellt.

Ansonsten sieht er dem Raspberry Pi 2 Model B zum Verwechseln ähnlich. microSD, USB, Ethernet, Analog-Audio und -Video über die vierpolige Klinkenbuchse, 40pin-GPIO.

Die offizielle Ankündigung der Raspberry Pi Foundation steht noch aus. Aber demnächst feiert der Raspberry Pi seinen vierten Geburtstag, da wäre es doch passend.

Mal sehen, ob diesmal die Anpassung von RISC OS auch so flott geht wie beim Pi 2 und dem Pi Zero.

RISC OS Remote per VNC

Wer mehrere Rechner betreibt, wird früher oder später mit dem Thema “Remote Desktop” konfrontiert werden, also der Möglichkeit, auf einem Rechner den Desktop eines anderen Rechners im Netzwerk anzuzeigen. Einzige Ausnahme dürfe die Linux-Kommandozeilen-Fraktion sein, die mit einer ssh-Shell auskommt.

Prinzipiell gibt es drei Technologien, die Remote Desktop erlauben: RDP (“Remote Desktop Protocol”) aus der Microsoft-Ecke, X Window System als grundsätzlich netzwerkfähiges Fenstersystem auf unixoiden Systemen und VMS sowie last but not least VNC (“Virtual Network Computing”, Open Source seit 1998) als plattformübergreifende Lösung aus der Zeit, als man NCs für das nächste große Ding hielt. Die Historie und Details dieser Technologien soll hier nicht Thema sein, wer Lust hat kann da ein paar Stunden Wikipedia-Recherche betreiben.

Clients für die verschiedenen Technologien gibt es für RISC OS schon sehr lange – Avalanche von James Peacock ist der vermutlich beste VNC-Client gefolgt von ViNCe von Vincent Lefevre. VNCViewer von Leo White ist leider nicht 32bit-fähig, genauso wenig wie !VNC von Simon Truss. Für RDP ist der RDPClient von Andrew Sellors das Mittel der Wahl. Auch X-Server (ja, beim X Window System ist die Terminologie “Client” und “Server” durchaus erklärungsbedürftig…) gab es vereinzelt, eine ultrateure Kaufsoftware von Gnome (nein, nicht der GNU Object Model Environment-Desktop), etwas eher experimentelles von Vincent Sanders und schließlich RiscX von Leo White – allesamt älteren Datums und nicht 32bit-fähig.

Sehr viel dünner sieht es auf der Server-Seite aus. Anno 2002 gab es einen VNC-Server von Henrik Bjerregaard Pedersen (Autor von ProSound, StudioSound und CineWorks), der aber sehr experimentell und langsam war und den ich zudem nie richtig ans Laufen brachte. Dieser Server wurde inzwischen gründlich überarbeitet, zunächst von David Llewellyn-Jones und schließlich von Jeffrey Lee.

Und tatsächlich ist es mir mit der neuesten Version 0.13 von Jeffrey endlich gelungen, RISC OS einigermaßen vernünftig remote bedienbar zu machen, zunächst mal (damit es nicht an der Hardware scheitert) meinen ARMX6. Versuche mit Raspberry Pi (2) und PandaBoard ES werden folgen.

Was sind die Stolperfallen? Die Performance ist bescheiden, weil RISC OS keine vernünftige Schnittstelle hat, um Interessenten mitzuteilen, was sich denn auf dem Bildschirm geändert hat (Jeffrey Lee hat in diesem Thread im RISC OS Open-Forum angedeutet, dass er hier Verbesserungen anstrebt). Es wird letztlich immer direkt in den Framebuffer geblittet. Und so muss der VNC-Server den Framebuffer auf Änderungen scannen, was logischerweise nicht besonders effizient ist. Deshalb sollte man unterstützend eingreifen und einen Bildschirmmodus mit geringer Farbtiefe wählen (256 Farben bieten sich an). Der Redraw-Performance hilft es, wenn das Pinboard einfarbig ist, weil dann viel weniger Daten übertragen werden müssen.

Interessant ist, dass die verschiedenen VNC-Viewer, die ich unter Windows ausprobiert habe, ganz unterschiedlich gut mit dem RISC OS-VNC-Server harmonierten. TightVNC, den ich bisher für VNC unter Windows und Linux verwende, wollte überhaupt nichts darstellen, sondern stürzte direkt ab nach Eingabe des Passwortes. UltraVNC, normal meine zweite Wahl, verhielt sich sehr komisch bezüglich der Darstellung des Mauszeigers und hinterließ manchmal die schwarze Silhouette des Mauszeigers irgendwo auf dem Schirm. RealVNC, eigentlich das Original, ist inzwischen mehr oder weniger Kaufsoftware geworden – vor dem Download “darf” man erst mal ein paar persönliche Daten eingeben, um dann herauszufinden, dass die Software “for time limited evaluation only” ist. Als Alternativen habe ich jetzt TurboVNC und TigerVNC getestet, die beide sehr gut funktionieren, bei TurboVNC ist das Fullscreen-Handling aber deutlich besser. Also bekommt TurboVNC hier meine Empfehlung.

Ein Problem sind die drei Maustasten. Es ist mir nicht gelungen, einen Viewer so zu konfigurieren, dass er schlicht die drei Tasten meines Laptop-Touchpads durchreicht. Also braucht man Notlösungen. Ich habe dazu unter RISC OS 3rdButton von Thomas Milius installiert, in einer leicht gepatchten Form von Raik Fischer um nicht die Windows-Popup-Menü-Taste (die es auf meiner Laptop-Tastatur nicht gibt) sondern die rechte Strg-Taste als Menütaste umzukonfigurieren. Ich hatte kurz versucht, einfach auf die rechte Maustaste (aka “Adjust”) zu verzichten und im VNC-Server den Modus “zweite Maustaste ist die Menütaste” über vncserv_swap_adjust_menu 1 zu aktivieren. Aber ich habe schlicht festgestellt, dass ich ständig die rechte Maustaste verwende, insbesondere bei der Navigation durch Filer-Fenster.

Insgesamt bin ich mit der Lösung jetzt recht zufrieden, sie scheint besser zu funktionieren als über einen PC mit RPCEmu oder Virtual-RPC in Verbindung mit VNC unter Windows – RDP ist hier keine Option, weil merkwürdigerweise beide Emulatoren darüber nicht funktionieren. So richtig Spaß macht die Bedienung von RISC OS über Remote noch nicht, aber da setze ich meine Hoffnungen auf Jeffrey.

Und wer das Mausbutton-Problem besser gelöst bekommt, mag mir bitte eine Mail schreiben!

Connector-Comeback

Es war Anfang der Neunziger. Die ersten postzugelassenen Modems zu moderaten Preisen kamen auf den Markt – man wollte sich ja nicht auf die schiefe Bahn begeben durch den Betrieb dieser höchst illegalen Import-Modems – und so erstand ich ein Telejet 2400. 2400bps, MNP5, und ein wirklich schön klackerndes Relais für die damals übliche Pulswahl.

Auf dem A3000 war es gar nicht so einfach, ein anständiges (und am besten kostenloses) Terminal-Programm zu finden. Es gab Grapevine, das hatte nur partiell eine WIMP-Oberfläche für das Telefonbuch und Datei-Upload und -Download, aber die eigentliche Terminal-Emulation fand im Fullscreen statt. Und zur Dateiübertragung gab es auch nur XModem. ARCterm 3 gab es noch, lief aber nur begrenzt gut. Ich fing damit an, ein eigenes Terminal-Programm namens “LambdaComm” zu schreiben, wurde aber nie fertig. Es gab eine partielle ANSI-/VT100-Emulation und XModem/YModem sowie die Anfänge von ZModem.

Eine Zeitlang ärgerte ich mich noch mit ZAnsi rum, kaufte dann frustriert die “RISCOS Terminals+”. Aber dann kam die Erlösung aus deutschen Landen: Andreas Zieringer veröffentlichte den Connector, ein großartiges Terminalprogramm. Flexibel, mit ZModem, und kompetenter ANSI-/VT100-/VT102-Terminal-Emulation. Und sogar CEPT für die letzten Zuckungen von BTX.

Irgendwann kam die Zeit des Internets, und Terminal-Programme wurden nur noch selten gebraucht – in meinem Falle eigentlich nur, um beim ZyXEL-ISDN-TA per XModem eine neue Firmware hochzuladen. Konsequenterweise gab es auch nie eine 32bit-Version für den IYONIX pc. Aber mit dem BeagleBoard änderte sich plötzlich die Lage – es gab einen seriellen Port, der für Debugzwecke sehr gut geeignet ist (z.B. während des Boot-Prozesses, um Ausgaben zu erhalten bevor der Bildschirm hell wird). Und um den Output zu verarbeiten, käme ein Terminal-Programm natürlich gerade recht.

Nun schreiben wir 2016, und es ist passiert: Connector feiert sein Comeback. Ich weiß nicht ob das irgendwo verkündet wurde, ich habe es beim routinemäßigen Lesen der CVS-Historie bei RISCOS Open Ltd. bemerkt. Ab sofort ist im “Bonus Binaries”-Download Connector mit an Bord.

Es werden zusätzlich die “Serial Blockdrivers” benötigt. Ggf. auch noch der Blockdriver für den Pi.

RISC OS-Projekte: Ein kompetenter BASIC-Compiler

Im RISC OS Open-Forum läuft gerade eine Diskussion zum Thema BBC BASIC und der Verfügbarkeit von BASIC-Compilern. Eigentlich trage ich mich schon länger mit dem Gedanken, einen Blog-Eintrag mit dem Thema “BBC BASIC – Fluch und Segen für RISC OS” zu verfassen. Die Diskussion hat mich nun dazu motiviert, weniger negativ (“Fluch”) über die Sache zu denken, sondern die Chancen darin zu sehen.

In der RISC OS-Welt hat BBC BASIC eine besondere Stellung. Vom BBC Micro über den Acorn Archimedes bis zum neuesten Titanium oder Raspberry Pi steckt der BBC BASIC-Interpreter überall standardmäßig drin. Die Handbücher früher beschrieben ausführlich den Einstieg in die Programmierung mit BBC BASIC. Letztlich war also BBC BASIC für viele RISC OS-Benutzer der erste Kontakt mit Softwareentwicklung. Jemand, der für RISC OS programmiert und nicht BBC BASIC kennt, ist quasi undenkbar.

Regelmäßig auftauchende Fragen sind: Ich habe BBC BASIC nun gemeistert, wohin als nächstes? Ich will ein komplexes Stück Software entwickeln, BBC BASIC erscheint mir dafür nur begrenzt geeignet, was verwende ich stattdessen? Unglücklicherweise gibt es unter RISC OS mehr oder weniger nur eine Antwort: C. Mit Einschränkungen auch C++. Alternativen mit Exoten-Status sind Lua und Charm. Das war’s dann aber.

Nach meiner Erfahrung gibt es nur wenige, die den Sprung von BBC BASIC nach C vollziehen – zu unterschiedlich die Konzepte, die Syntax, dazu die Umstellung vom Interpreter zum Compiler. Man profitiert eben kaum von seiner gesammelten Erfahrung mit BBC BASIC.

Nun ist es leider so, dass der BBC BASIC-Interpreter noch stark in den 80ern verhaftet ist. Der leistungsfähigste unterstützte Datentyp ist das Array. Strings sind auf 255 Zeichen Länge limitiert (und single byte encoding natürlich). Records kann man nur quasi-händisch über Speicherblocks simulieren. Die Abstraktionsmöglichkeiten enden bei den Konstrukten Prozedur und Funktion. Die Verwendung von C-Bibliotheken ist faktisch nur möglich, wenn diese in ein Modul mit SWI-Interface überführt werden. Unnötig zu erwähnen, dass man keine RISC OS-Module in BASIC schreiben kann. Dazu die typischen Interpreter-Probleme wie suboptimale Performance und fehlender globaler Syntaxcheck – besonders lustig, wenn man im Error-Handler einen Syntaxfehler eingebaut hat.

Könnte man den BBC BASIC-Interpreter denn erweitern? Bisherige Erfahrungen zeigen: sehr schwierig, vor allem wenn man die Rückwärtskompatibilität erhalten will. Basalt von Steve Drain versucht sich an diversen Erweiterungen, m.E. aber mit syntaktisch schwer verdaulichem Ergebnis.

Ausgehend von diesen Überlegungen rege ich (nach dem großen Erfolg der Ideen “Ein kompetenter Browser” und “Qt portieren”) die Entwicklung eines BASIC-Compilers an. Das Potenzial der vielen kundigen BBC BASIC-Codern wird im Moment verschleudert durch die vielen Einschränkungen des Interpreters.

Wie könnte man dieses Projekt angehen? Am besten nicht nach der typischen RISC OS-Art, unter Vermeidung aller “not-invented-here”-Komponenten eine 100% hausgemachte Lösung zu brauen. Ziel muss es sein, eine dauerhafte Lösung zu bauen, die ohne größere Schmerzen es erlaubt, auch die nächsten paar ARM-Generationen zu überleben (man erinnere sich an die bisherigen Herausforderungen: StrongARM, 32bit, ARMv7). Also sollte man bestrebt sein, die Komplexität der eigentlichen ARM-Code-Erzeugung den Tools zu überlassen, die sowas schon seit langem beherrschen und aller Wahrscheinlichkeit nach das auch in Zukunft können werden.

Dazu gibt es prinzipiell zwei denkbare Wege: entweder, man übersetzt den BASIC-Code in C-Code und ruft dann einen C-Compiler auf, oder man implementiert ein neues Frontend für GCC. Für ersteres gibt es Beispiele für andere BASIC-Dialekte – BCX oder BaCon. Sogar in der RISC OS-Welt gibt es einen solchen Ansatz mit BBC_C32. Für letzteres gibt es meines Wissens keine frei verfügbaren Beispiele, aber jede Menge Dokumentation wie man derartige Frontends baut.

Was sollten die ersten Ziele sein? Die Unterstützung von etwas, was ich “well-formed BBC BASIC” nennen würde. Also für das, was vernünftige Menschen in BBC BASIC programmieren würden, nicht für Code, der aussieht, wie wenn er durch einen zu intelligenten BASIC-Cruncher gelaufen wäre. Sogar das Nachdenken über Unterstützung von EVAL sollte unter Strafe gestellt werden. Der ARM-Inline-Assembler ist IMHO zu Anfang ebenso verzichtbar. Über eine stringentere Fassung des Typsystems sollte man nachdenken. Unterstützung für beliebig lange Strings sollte automatisch abfallen. Konstanten sollten möglich sein. Also kurz: alles, was “programming in the small” ausmacht. Schleifen, Entscheidungen, Prozeduren, Funktionen.

Was stünde langfristig auf dem Plan? Unterstützung für Record-Strukturen, anständiges Speichermanagement (dynamische Allokation und auch Freigabe statt des statischen DIM-Zeugs), Unterstützung für weitergehende Abstraktion möglicherweise sogar objektorientierter Natur, sinnvolle Erweiterungen in punkto Sichtbarkeits- und Gültigkeitsregeln, Unterstützung für Modularisierung (Erweiterung des LIBRARY-Konzepts), Unterstützung zum Bau von RISC OS-Modulen, Integrationsmöglichkeit von C-Bibliotheken. Vielleicht sogar eigene Schlüsselwörter zur WIMP-Programmierung?

Also, die Vorarbeit ist geleistet, die Finalisierung überlasse ich wie immer gerne anderen. Für Syntaxvorschläge stehe ich gerne zur Verfügung.

Übrigens gab es über die Jahrzehnte durchaus bereits Versuche, BASIC-Compiler am Markt zu etablieren. ABC (“Archimedes BASIC Compiler”, bis heute Teil des RISC OS DDE), RiscBASIC, HelixBasic, WimpBasic. Die Ergebnisse waren wenig überzeugend – zu gering der Performance-Vorsprung, und der Versuch, BBC BASIC möglichst präzise zu emulieren, verurteilte die Versuche zum Scheitern. Mit Blick auf die Microsoft-Welt könnte man sagen: VisualBasic wurde nicht deshalb so erfolgreich, weil es möglichst weitgehend QBasic-kompatibel war.

Die gehackte Webpräsenz

Irgendwann zwischen Weihnachten und Neujahr ist es passiert – genauer ließ es sich nicht rekonstruieren. Meine Webpräsenz wurde gehackt. Alle vier WordPressInstallationen und die Drupal-Installation waren betroffen. Die dahinter liegenden Datenbanken waren Gott sei Dank sauber.

Wie äußerte sich der Hack? Einige Benutzer berichteten von Redirects auf Phishing-Seiten, die meisten waren aber nur von schlechterer Performance betroffen, weil in die HTML-Daten JavaScript injected wurde, das auf gewisse Fremdseiten zugriff, die unglaublich schlechte Antwortzeiten hatten. oil-hockey.ch und rardec.co.uk waren darunter. Das verzögerte den Aufbau der Webseiten erheblich.

Klassifiziert war das Problem als “JS:Injection-A” (Avast) oder “Mass Injection Website 19” (Symantec). Für mehr Details hier ein Link zu Symantec. Es dauerte nicht lange, bis die Webpräsenzen bei mindestens einem Dienst (Norton Safeweb) auf der Blacklist standen. Das zieht dann weitere Kreise – vor allem Firmen haben oftmals automatische Verfahren, um Zugriffe aus dem Intranet auf Seiten auf Blacklists zu unterbinden. Gott sei Dank gab es bei Norton Safeweb eine relativ unkomplizierte Möglichkeit, eine Reevaluierung des Zustands zu veranlassen.

Seit einer Woche ist nun wieder alles bereinigt – WordPress- und Drupal-Neuinstallation nebst zwei WordPress-Theme-Wechseln (die alten sind noch verseucht, die muss ich noch aufräumen) hat das Problem gelöst. Dazu natürlich die Routine-Dinge wie Wechseln aller Passwörter. Scheiss-Aufwand, aber man lernt ja was dabei (man soll ja alles positiv sehen).

Ich danke meinen aufmerksamen Blog-Lesern, die mich über das Problem informiert haben, weil ihre Sicherheitssoftware angesprungen ist. Wer seine Webpräsenz schnell online auf Malware checken will, dem sei der Online-Security-Scanner von Sucuri empfohlen.

Und was lernt man daraus? Früher war alles besser – da hätte man schnell ein paar alte Versionen der HTML-Dateien eingespielt und fertig wäre die Säuberungsaktion. In der heutigen Welt der CMS-Systeme mit ihrem üblen PHP-Verhau dauert eine Analyse viel länger. Und: nur weil eine Webpräsenz eine überschaubare Anzahl Besucher hat – man sollte also denken, dass so ein Hack ein wirklich schlechtes Preis-Leistungs-Verhältnis hat – heißt das nicht, dass nicht doch ein paar üble Gesellen Hand anlegen. Abgesehen davon ist es nie schlecht, regelmäßig Backups zu machen – ok, das ist eine IT-Binsenweisheit, das sollte man schon vorher gewusst haben.

MiST-Board Archimedes-Core Schnelltest

Seit einiger Zeit bin ich stolzer Besitzer des MiST-Boards (im alten Blog-Post kann man auch nachlesen, was es mit diesen FPGAs so auf sich hat). Vorrangiger Zweck ist die Befriedigung nostalgischer Sehnsüchte – Bomb Jack, Commando, Ikari Warriors und Barbarian auf dem Schneider CPC, IO und Armalyte auf dem Commodore 64. Dazu auch Ausflüge auf die 16bitter, die ich nie selbst besaß (Atari ST, Commodore Amiga). Da werden die Competition Pros angestöpselt und los geht’s.

Und weil auf dem MiST-Board eine Menge Exoten vertreten sind, gibt es auch einen Core für den Exoten schlechthin: den Acorn Archimedes, Urvater aller ARM- und RISC OS-Rechner. Ich hatte schon kurz darüber berichtet. Passend zum Exoten-Status ist es auch gar nicht so einfach, den Core erfolgreich ans Fliegen zu bekommen. Unter all den Cores, die ich ausprobiert habe (und das waren fast alle), ist es sogar am Schwierigsten, obwohl ich RISC OS-technisch auch was die alten Kisten angeht schon einen reichhaltigen Erfahrungsschatz habe.

Ein Problem: bootet man das MiST mit einem anderen Core und wechselt dann zum Archimedes-Core, funktioniert nach meiner Erfahrung gar nix. Es startet nicht. Man benötigt definitiv eine eigene SD-Karte mit dem Archimedes-Core als Default, und man muss manchmal das MiST-Board resetten damit der Archimedes-Core startet. Der Thread zum Archimedes-Core im Atari-Forum ist leider eingeschlafen, was nichts gutes heißt für die Weiterentwicklung. Ab und zu scheint das Video-Setup auch nicht korrekt zu sein und der Bildschirm flimmert unerträglich. Ein Shift+Ctrl+Break-Reset (warum der nur mit Shift geht? Keine Ahnung…) bringt das normalerweise wieder ins Lot. Also versuchen wir mal mit dem zu leben, was wir heute haben.

Was könnten die Gründe sein, überhaupt den Archimedes-Core betreiben zu wollen? Na klar, die klassischen Games wieder zu zocken. Anwendungssoftware ist etwas schwerer vorstellbar, da die Emulation einer Festplatte leider noch fehlt, und mit zwei Floppies wird es doch eher mühsam. Nicht unmöglich (ich habe einige Zeit mit einem A3000 mit nur einer Floppy gearbeitet – man muss halt gut organisiert sein, was die Disketten angeht, und bootet am besten so, dass die üblichen Module direkt im RAM landen, sonst wird die Diskette mit !System und !Fonts der beste Freund des Disc-Jockeys), aber mühsam. Wobei diese Erinnerung hauptsächlich durch RISC OS 2 geprägt ist, wo quasi jede Anwendung zusätzlich die SharedCLibrary laden musste nebst ColourTrans und FPEmulator. Und die Fonts waren natürlich auch disc-based. Das wurde mit RISC OS 3 Gott sei Dank anders, wo man allein mit den ROM-Inhalten schon relativ weit kam.

Also: Schwerpunkt Spiele. Aber auch bei Spielen braucht man natürlich das Betriebssystem, und das ist die erste Hürde. Ähnlich wie beim Amiga ist auch RISC OS – selbst in den ältesten Versionen – nicht für Emulationszwecke lizenzfrei nutzbar. Zwar gibt es Downloadquellen, aber wir wollen uns ja nicht außerhalb der Legalität bewegen. Gott sei Dank muss man nicht einen der alten, seltenen Acorn-Rechner kaufen und das ROM rippen, sondern kann direkt online shoppen bei RISCOS Ltd.. “Classic ROM Collection” heißt das gute Stück und beinhaltet nahezu alles der prä-RISC OS 4-Ära: neben den Urgesteinen Arthur 0.30 und 1.20 (da diskutiert man noch, ob das schon den Namen “Betriebssystem” verdient) und dem Exoten RISC OS 2.01 (die spezielle A540-Version) sind auch die Mainstream-Versionen RISC OS 2, RISC OS 3.10/3.11 und RISC OS 3.70/3.71 am Start. Für diese nahezu vollständige Sammlung – aus deutscher Sicht fehlt leider RISC OS 3.19, die deutsche Version von RISC OS 3.11 – sind die 10 UKP doch gut angelegt.

Und welche OS-Version hätten wir gerne? Die weitestgehende Kompatibilität bietet definitiv RISC OS 3.11. Nur ein paar ganz alte Schätzchen laufen nur unter RISC OS 2, und da fällt mir spontan doch überhaupt kein spielenswerter Kandidat ein. Also RISC OS 3.11.

Fehlt also noch die Software. Wer sich für die damals mitgelieferte Software interessiert, findet im Apps-Ordner die sich im ROM befindlichen Anwendungen wie Draw, Paint, Edit und Alarm. Dazu kann man in die Disketten Apps1, Apps2 und Support reinschnuppern, die als ZIP-Archiv bei der Classic ROM Collection mitgeliefert werden. ZIPs entpacken geht natürlich mit SparkPlug von David Pilling – aber wie auf die MiST-SD-Karte bringen? Zwei Möglichkeiten: entweder per Computer und Emulator auf ein Floppy-Image kopieren, oder ein fertiges Floppy-Image von Wockis Acorn-Site runterladen. Wer sich ernsthaft mit der klassischen RISC OS-Software beschäftigen will, wird nicht drumrumkommen, einen Weg zu etablieren, Downloads aus dem Internet auf Floppy-Images zu transferieren. Wenn ein gewöhnlicher Windows-PC am Start ist, bieten sich RPCEmu, RedSquirrel oder Arculator an. Linux-Freunde nehmen RPCEmu oder ArcEm. Wer in der glücklichen Lage ist, unter RISC OS zu arbeiten, dem ist A310Emu oder ArchiEmu zu empfehlen.

Lange Vorrede, aber wie sieht jetzt das Setup der SD-Karte aus? Simpel: aktuelle MiST-Firmware, Archimedes-Core r1028 als core.rbf und das RISC OS 3.11-ROM als riscos.rom ins Hauptverzeichnis, dazu die gewünschte Auswahl von Disc-Images im Format ADF – es empfiehlt sich hier, die Dateinamen kurz und knackig zu wählen, sonst werden sie im MiST-OSD schnell schwer zu lesen.

Empfehlenswerte Spiele – hier sind nur die “Originale” aufgelistet, keine Umsetzungen von anderen Systemen, es sei denn die RISC OS-Version ist signifikant besser:

  • Zarch
  • Conqueror
  • E-Type
  • Chocks Away
  • Elite

Eigentlich empfehlenswert, aber der Core ist derzeit zu langsam:

  • Star Fighter 3000

Eigentlich empfehlenswert, ich hab’s aber nicht zum Laufen gebracht:

  • Spheres of Chaos
  • Cataclysm
  • Stunt Racer 2000

Gute Online-Quellen für Software – bitte Copyright beachten!

Zum Otter der QupZilla

Chris Gransden, Meister der tausend Portierungen, hat wieder zugeschlagen. Basierend auf der Qt5-Portierung von Lee Noar hat er einen weiteren Browser zum Laufen gebracht: QupZilla. Auch dieser basiert letztlich auf WebKit bzw. der Qt-Integration davon namens QtWebKit, genau wie der Otter-Browser.

Download der Testversion hier.

Allerdings wird QupZilla ab Version 2.0.0 auf QtWebEngine umsatteln, die auf Chromium basiert. Da wird eine RISC OS-Portierung deutlich herausfordernder aufgrund der asynchronen Multi-Prozess-Architektur von Chromium. Da wird es sinnvoller sein, die Optimierungsbemühungen in die Qt-Portierung zu stecken und ggf. die WebKit-Innereien zu separieren und ein echtes RISC OS-Frontend drumrum zu bauen.