Multicore-RISC OS für Experimentierfreudige

Zwei Wochen nach der ersten Ankündigung hat Jeffrey Lee Nägel mit Köpfen gemacht: hier ist Schritt zwei auf der langen Reise zu einem Multicore-RISC OS. Das dort verlinkte Archiv enthält die entsprechenden Sourcen und ein fertiges Raspberry Pi RISC OS-ROM-Image mit dem SMP-Modul, um auf RPi 2 und RPi 3 auf den drei bisher brachliegenden Cores Code zur Ausführung zu bringen.

Meine Zeiten als Low-Level-Frickler sind lange vorbei (mit der sporadischen Ausnahme, ATAPI/SCSI-Commands über den Bus zu schicken), und so überlasse ich gerne der Assembler-Fraktion das Feld für erste Experimente. Sagt mir Bescheid, sobald die Unterstützung für Ada-Tasking verfügbar ist :-)

Archimedes-Emulation im MAME

Heißt es „im MAME“ oder „in MAME“? Ich kann mich nicht entscheiden. Egal.

Durch einen Thread auf stardot.org.uk bin ich darauf aufmerksam geworden, dass im MAME (Multi Arcade Machine Emulator) inzwischen auch ein Archimedes-Emulator („Driver“ nennt sich das in der MAME-Sprache) seine Heimat gefunden hat.

MAME entstand ursprünglich als Emulator-Framework zur Emulation von klassischen Spielautomaten. Später gab es ein Schwesterprojekt namens MESS, das sich mit der Emulation von Computersystemen und Spielekonsolen befasste. Inzwischen sind beide unter dem Dach von MAME vereinigt, der damit eher zum „MME“ wurde.

Das erste Mal mit MAME in Kontakt kam ich durch den RISC OS-Port von Gareth S. Long, der auch Mitinitiator des MESS-Projekts ist. Ich denke es war 1998, die MAME-Version war 0.30 und im spieleunterversorgten RISC OS-Reich war es einer der wenigen Lichtblicke. Klar, ein StrongARM war vonnöten, und die emulierten Arcade-Automaten waren älteren Datums (Pac-Man, Frogger, Donkey Kong, Zaxxon, Bomb Jack, 1942, Xevious…), aber es machte trotzdem eine Menge Spaß.

Nun gibt es also für Windows, Linux und Mac eine weitere Möglichkeit neben Arculator und ArcEm um die goldene Archimedes-Zeit per Emulator neu zu erleben.

Ein erster Erfahrungsbericht folgt demnächst.

Multicore ante portas

Jeffrey Lee war nicht faul über die Feiertage und macht uns aktuell das Maul wässrig.

Klar, es ist immer noch ein riesiges Stück entfernt vom eigentlichen Ziel, einem multi-threading multi-core all-singing all-dancing RISC OS. Aber ein Schritt nach dem anderen.

RISC OS-Wünsche zum neuen Jahr 2017

Zu Weihnachten 2015 hatte ich neben den Weihnachtsgrüßen einen kleinen Wunschzettel verfasst. Diese Tradition will ich hier fortsetzen. Nebenbei: meinen Lesern alles Gute fürs Jahr 2017. Here we go again.

Unglücklicherweise sind die 5 Punkte von letztem Jahr noch offen, deshalb wiederhole ich sie hier:

  • neues CDVDBurn-Release
  • Basis-Multicoreunterstützung in RISC OS
  • die Vervollständigung der 32bit-ung von Impression-X
  • Runderneuerung der Filesystem-Architektur in RISC OS
  • BeagleBoard-X15 mit RISC OS-Port

Ersteres ist besonders ärgerlich, aber es gibt zwei „must haves“, die noch nicht fertig sind: Unterstützung für S-ATA auf dem Titanium-Board, und verbesserte Medienkompatibilität auf zumindest einem noch aktuell erhältlichen Laufwerk (BD-R, BD-RE, DVD-RAM, DVD+RW und DVD+R und/oder DVD-R).

Neue (zusätzliche) Wünsche habe ich auch noch:

  • Lösung des RISC OS-Browser-Problems (entweder durch Weiterentwicklung von Netsurf oder Verbesserung der WebKit-basierten Otter und QupZilla)
  • Verfügbarkeit einer Ready-to-run-VM für GCCSDK und Portierungen
  • WLAN-Unterstützung und IP-Stack-Update
  • Portierung aktueller VCS wie Git und Mercurial

Aus meiner Sicht ist die mangelnde Verfügbarkeit von WLAN-Unterstützung und gescheitem Browser genau das, was RISC OS von einer „allgemein nützlichen Lösung“ jenseits der Legacy-User trennt. Gerade mit Verfügbarkeit des On-Board-WLANs beim RPi 3 wird dieser Mangel noch ärgerlicher.

ADFFS 2.60 verfügbar

Jon Abbott hat die Verfügbarkeit von ADFFS 2.60 verkündet. Wichtigste Neuerung ist die neue Implementierung der 50Hz-Synchronisation, um die originale Spielgeschwindigkeit in Verbindung mit tearing-freier Grafikdarstellung zu ermöglichen. Dazu kommen reichlich Bugfixes und die Vervollständigung der Kompatibilität auf den Pis zu solch großartigen Spielen wie Mig 29M Fulcrum oder Interdictor.

Leider zickt mein A3000 gerade etwas, so dass ich meine Testaktivitäten wohl hin zum RPi verlagern werde. Erste Maßnahme: Grafikausgabe auf echte 50Hz einstellen, ich hoffe mein Monitor spielt da mit.

Fireworkz 2.20 verfügbar

Stuart Swales hat die Verfügbarkeit der neuesten Version von Fireworkz verkündet. Detaillierte Informationen über die enthaltenen Änderungen kann man in der Release History nachlesen. Hervorzuheben scheint mir die jetzt integrierte Unterstützung fürs „Global Clipboard“. Fireworkz wirkte in der Vergangenheit – vermutlich aufgrund der Tatsache, dass es von Anfang an eine cross-platform-Software war – nicht immer optimal in RISC OS integriert. Da ist die Unterstützung für das Clipboard ein sehr guter Schritt. Die interne Struktur der Application wurde nun auch RISC OS-artiger gestaltet, mit separierten Sprites und der üblichen Ressourcen, mit der Vorbereitung für anständige i18n-Möglichkeiten.

Letzteres mag gar dazu führen, dass irgendwann eine eingedeutschte Version möglich ist – dann schließt sich der Kreis, meine erste RISC OS-Anwendung war die deutsche Version von PipeDream 3.

Die neue Version wird wie immer auch über !PackMan bereit gestellt.

SCSI2SD – eine schöne Massenspeicherlösung für alte Geräte

Wer meine Vorbereitungen zur CC2016 mitverfolgt hat, kennt das Problem – ein alter Rechner, in den nur alte Platten passen, womöglich SCSI und kein IDE. Wie kriegt man da einen bezahlbaren und zuverlässigen Massenspeicher ran?

Meine CC2016-Lösung bestand darin, eine SCSI-IDE-Bridge mit einem IDE-SD-Adapter zu verbinden. Um es vorsichtig zu formulieren – tut zwar, aber ist teuer und irgendwie auch hässlich. Genauere Recherchen ergaben, dass der Australier Michael McMaster eine optimale Lösung speziell für Retro-Zwecke entwickelt hat: SCSI2SD.

Nun ist SCSI2SD keine „simple“ Lösung, die einfach nur unter einer SCSI-ID eine microSD-Karte als Massenspeicher zur Verfügung stellt. Nein, die Lösung ist ungewöhnlich flexibel:

  • Bereitstellung von bis zu vier SCSI-Devices unter konfigurierbaren IDs
  • unter jeder SCSI-ID ist konfigurierbar, welche Bereiche der microSD-Karte bereitgestellt werden (z.B. um alten Betriebssystemen weiszumachen, dass sie eine 2 GiB- oder gar nur eine 512 MiB-Platte angeschlossen haben)
  • konfigurierbar bezüglich Parity und Unit Attention-Verhalten
  • läuft im asynchronen Modus für maximale Kompatibilität
  • kann sich allein über die Termpower des Hostadapters mit Strom versorgen, normalerweise kein extra Stromanschluss notwendig
  • flexible Blockgröße – irgendwas zwischen 64 Bytes und 8 KiBytes

Mein einziger Kritikpunkt ist die suboptimale Performance, es sind so etwa 2,5 MiB/s möglich, was doch deutlich unter dem Maximum des synchronen Übertragungsmodus (10 MiB/s) liegt. Aber seien wir ehrlich: die alten Schätzchen schaufeln ja nicht ständig megabyteweise die Daten über den Bus.

Ich habe die v5-Hardware geordert und derzeit am A3000 in Betrieb. Harmoniert prächtig mit dem HCCS-SCSI-Controller, ich habe 4 Partitionen zu je 499 MB angelegt. Versuche, unter weiteren IDs weitere Geräte zur Verfügung zu stellen und mit MOFS aka MagOpt von Hugo Fiennes anzusprechen, scheiterten. Komisch, bisher kannte ich dieses FS als sehr unempfindlich und kompatibel. Vielleicht habe ich was verkonfiguriert. Aber dabei fiel mir wieder ein und auf, dass es unter RISC OS wirklich an einem generischen, partitionsfähigen Filecore-FS fehlt, wo man einfach untendrunter einen Blocktreiber hängt und fertig ist das FS.

Im Moment ist die v6-Hardware in der Reifephase – schon verfügbar, aber an der Software wird noch gearbeitet. Besondere Features: hat einen SD-Karten-Slot statt microSD-Slot, unterstützt den synchronen Übertragungsmodus und erreicht bis zu 10 MiB/s, kann bis zu 7 SCSI-IDs repräsentieren, kann auch via USB Massenspeicher anbinden.

Bezugsquellen:

The Icon Bar ist wieder aktiv

Laut eigener Aussage „the longest running RISC OS portal“, hatte „The Icon Bar“ in letzter Zeit eine eher sparsame Artikelpublizierfrequenz hauptsächlich bestehend aus Show-Ankündigungen für Wakefield oder die London-Show – nur in den Foren gab es die eine oder andere aktive Diskussion.

Jetzt wurde neue Aktivität entfaltet – 3 Artikel seit dem 30. Oktober sind für RISC OS-Verhältnisse beinahe schon in der Kategorie „hektische Betriebsamkeit“ zu verorten. Wäre schön, wenn die Freunde von der Insel generell wieder etwas aktiver werden, in letzter Zeit waren nur noch RISCOSitory und The RISCOS Blog einigermaßen regelmäßig am Start.

Mark Stephens hat das Heft in die Hand genommen und versorgt uns jetzt bei The Icon Bar wieder mit Neuigkeiten. Vorbildlich. Auch wenn noch etwas Verwirrung verbreitet wird bezüglich Fireworkz vs. Fireworkz Pro. Ich habe hier versucht es auseinanderzuklamüsern.

Der fast perfekte Retro-Monitor

Hier hatte ich mich schon damit beschäftigt, welche Monitore mit alter Hardware – im Beispiel ein Acorn A3000 – am besten harmonieren und wie man heute erhältliche TFTs an die alten Schätzchen anschließen kann, ohne zuviele Nachteile erleiden zu müssen.

Nach einer Diskussion im stardot-Forum bin ich auf einen aktuell erhältlichen 19″-TFT von BenQ mit dem schönen Namen BL912 aufmerksam gemacht worden. Die Besonderheit: nicht nur kann dieser Monitor problemlos 50Hz vertikal synchronisieren (und eignet sich damit hervorragend für das MIST) und versteht sich auch mit den krummen, nicht-so-ganz-VGA-Signalen eines A3000, nein, die eigentliche Sensation ist: er kann 15kHz-Signale verarbeiten. Also der optimale Monitor für die alten Kisten.

Ich habe das Dingens natürlich sofort geordert und gestern kurz am A3000 im MonitorType 1 (aka „true Multiscan“) getestet. Ergebnis: die 15 kHz-Modi werden einwandfrei dargestellt und per „Auto-Adjust“ beim Moduswechsel in sehr kurzer Zeit auch anständig zentriert. Versuche mit diversen guten alten Demos aus der ARM2-Zeit zeigten keinerlei Probleme, auch die Darstellungsqualität (nativ hat das Dingens 1280×1024, also 5:4) war sehr gut. Auch die „nahezu-VGA-Modi“ von 25-28 werden einwandfrei dargestellt. Nur bei den „Multiscan-Modi“ 18-21 mit 50Hz (640×512) gab es ein „Out of range“ – ein nur kleiner Wermutstropfen, denn real stiften die kaum mehr Nutzen als die 640×480-Modi.

Ich konnte noch nicht herausfinden, ob auch CSync funktioniert, der A3000 ist derzeit auf HSync/VSync konfiguriert und gejumpert. Mit dem MIST und 15kHz-Cores (disableter Scandoubler) muss ich auch noch testen.

Ganz billig ist das Teil nicht – für so einen mittelguten 19″er knapp 150€ zu bezahlen ist in Zeiten von 22″er in Full-HD mit Lautsprechern für unter 100€ nur vertretbar, wenn es ein Alleinstellungsmerkmal gibt. Und das ist hier ja zweifellos der Fall.

ADFFS 2.59 verfügbar

Jon Abbott hat die Verfügbarkeit von ADFFS 2.59 angekündigt. Ab sofort wird der Raspberry Pi 3 (ARMv8, AArch32) unterstützt, und die Unterstützung für den RPi 2 (ARMv7) ist nun vollständig – was in der Theorie auch die Lauffähigkeit auf OMAP3 (BeagleBoard, BeagleBoard-xM, OpenPandora, BIK, ARMini), OMAP4 (PandaBoard, PIK, ARMiniX, PandaRO), iMX6 (ARMX6) und OMAP5 (Titanium, IGEPv5, TiMachine, RapidO Ti, RapidO Ig) ermöglicht, aber weitgehend ungetestet ist.

Auf den 32bit-Plattformen (also auch dem IYONIX) sollte nun durchgehend per Ctrl+Shift+F12 die Rückkehr aus dem Spiel zum Desktop möglich sein.

Ich bin inzwischen auch Teil des JASPP und unterstütze das Projekt durch Testaktivitäten – im Moment prüfe ich alle möglichen Spiele auf dem A3000 auf Lauffähigkeit mit ADFFS 2.59. Danach ist der RPi 3 dran.

Zeitgleich mit ADFFS 2.59 wurden auch noch folgende Spiele im Rahmen des JASPP freigegeben:

  • Blaston (1991) (Eterna)
  • Cartoon Line part one (1991) (Eterna)
  • Empire Soccer ’94 (1995) (Empire Software)
  • Oh, No! More Lemmings (1992) (Krisalis Software)

Spieleseitig sollte ADFFS nun (bis auf die unvermeidlichen Bugs) feature-complete sein – aber das Projekt heißt ja „software preservation“ und nicht „games preservation“. Mal sehen, was sich Jon als nächstes vornimmt. Er hat immer wieder angedeutet, auch WIMP-Dinge über ADFFS emulierbar zu machen.