Januar 2017

You are browsing the site archives by month.

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.