Erste Schritte mit MAME und der Archimedes-Emulation

Zwei Tage ist es her, dass ich über die Archimedes-Emulation in MAME zuerst gestolpert und dann berichtet habe. Nun gibt es einen ersten Erfahrungsbericht über den langen, schmerzhaften Weg bis zum vertrauten Anblick des RISC OS-Desktops.

Zunächst: das MAME-Team scheint nicht viel von Dokumentation zu halten, zumindest die Dinge, die von der MESS-Seite eingebracht wurden sind sehr sparsam dokumentiert. Und irgendwie wird man das Gefühl nicht los, dass die MAME-Philosophie zwar sehr gut auf Spielautomaten-Emulation passt, bei Computern aber eher holprig ist. Aber aller Anfang ist ja bekanntlich schwer, und vermutlich liegt das nur an meinem einsetzenden Altersstarrsinn, dass sich doch gefälligst alle Emulatoren dieser Welt auch ähnlich verhalten sollten.

Aber ins Detail. Die Archimedes-Emulation (aa310 in der MAME-Abkürzung) hat zum Beispiel eine ganz genaue Vorstellung davon, welche Dateien unbedingt vorhanden sein müssen, bevor ein Start möglich ist. Dazu gehören ROM-Images und CMOS-Dateien. Die Dokumentation schweigt sich darüber aus, welche Dateien mit welchem Namen erwartet werden, aber man kann per

mame -listxml aa310

sich alles anzeigen lassen. Man erfährt dann, dass Arthur 0.30 und 1.20 sowie RISC OS 2.00, 2.01, 3.00, 3.10, 3.11 und 3.19 möglich sind. Benannt nach keinem einheitlichen Muster oder einheitlich in 4-ROMs-sind-4-Dateien-Form. Schade, schließlich gibt es ja die RISC OS Classic ROMs Collection, die hätte man ja durchaus als die kanonische Form verwenden können.

Merkwürdig: es wird auch eine CMOS-Datei erwartet (getrennt nach RISC OS 2 und RISC OS 3, aber keine speziell für Arthur), die ebenfalls – wie bei MAME üblich für ROMs – eine CRC und SHA1-Summe hinterlegt hat, also einen ganz bestimmten, vorbestimmten Inhalt haben muss. Seltsam für eine im Kern variable Datei – wöllte man fix gewisse Inhalte vorgeben, warum sie dann nicht gleich in MAME fest hinterlegen?

Wenn man dann sich entweder die benötigten Ressourcen selbst zusammengefrickelt hat (z.B. funktioniert es, wenn man die von anderen Emulatoren bekannten ic24.rom bis ic27.rom nebst cmos_riscos3.bin (z.B. von Arculator) ins Verzeichnis aa310 ins ROM-Verzeichnis kopiert) oder in den Weiten des Internets ein entsprechendes aa310.zip gefunden hat (nicht zu verwechseln mit dem alten, für MESS tauglichen a310.zip), kopiert man das in das ROM-Verzeichnis von MAME (egal ob noch im ZIP verpackt oder extrahiert in das Verzeichnis aa310).

So gerüstet, kann man nun das erste Mal die Emulation starten – entweder direkt MAME starten und sich durch die vielen emulierten Systeme hangeln, oder direkt per Kommandozeile

mame aa310 -bios 311

ein RISC OS 3.11 ordern. Nicht vom fehlschlagenden Selbsttest (roter Bildschirm) irritieren lassen, einfach kurz warten und das vertraute RISC OS-Startup-Banner begrüßt uns.

So weit, so gut. Und wie kriegt man jetzt die Software ins System? Wie immer bei Emulatoren: über Disketten-Images. MAME wird im Moment erweitert, um neben den üblichen ADF-Images auch APD und JFD zu unterstützen. Also ein paar ADFs nach mame\software kopiert, und man steht vor dem nächsten Rätsel: wie mounted man nun das Image? Des Rätsels Lösung: MAME bietet ein On-Screen-Menü, das man per Tastendruck auch „Scroll Lock“ aufrufen kann. Kleines Problem in meinem Falle: die Laptop-Tastatur hat keine „Scroll Lock“-Taste anzubieten. Aber es gibt Abhilfe: man kann über eine Kommandozeilenoption eine andere Taste definieren – exemplarisch für die Tab-Taste:

mame aa310 -uimodekey TAB -bios 311

Und schon kann man über den Menüpunkt „File Manager“ ein Floppy-Image auswählen, mit verschiedenen Mount-Optionen wie Read-Only oder Read-Write.

Ich wünsche fröhliches Experimentieren. Wer ein gescheites Frontend für MAME findet, bitte Meldung machen.

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.