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.

Monitore am A3000

Auf der CC2016 wurde ich auf das Problem angesprochen, wie man Hardware wie den Acorn A3000 am besten mit einem Monitor verbindet. Aufgrund der Flexibilität des VIDC gibt es recht viele Anschlussvarianten, die ich im Folgenden erörtern will. Bei den späteren Modellen wie dem A540, A5000, A3010, A3020 und A4000 liegt der Fall noch mal etwas anders.

RISC OS 3.1 wird hier mal als Mindestvoraussetzung festgelegt – mit RISC OS 2 ist alles noch viel komplizierter.

Drei Dinge müssen am A3000 eingestellt bzw. konfiguriert werden, je nachdem welchen Monitor man anschließen will. Zunächst ist der „MonitorType“ wichtig. Relevant sind hier:

  • MonitorType 0 – TV/RGB/Scart mit 15kHz Zeilenfrequenz und 50Hz Bildwiederholfrequenz, also PAL. Darunter fallen z.B. C64/Amiga-Monitore vom Schlage eines Commodore 1084S oder Philips CM8833, auch Acorn hatte entsprechende Modelle mit dem AKF11 und AKF12 im Angebot; auch RGB-Scart-fähige Fernseher fallen in diese Kategorie
  • MonitorType 1 – ein echter Multiscan-Monitor, der typischerweise eine Zeilenfrequenz von 15-40kHz synchronisieren kann und z.B. zwischen 45Hz und 80Hz Bildwiederholfrequenz unterstützt; Beispiele: Acorn AKF18, AKF50, AKF52 und AKF53, NEC MultiSync II und 3D, Mitsubishi EUM1491, Microvitec Deltascan 1402, Taxan Multivision 7070, Tystar TY-1411, Eizo 9060S, Idek MF-5015/5017/5021, Commodore 1950 (AOC CM314) und 1960
  • MonitorType 4 – „S-VGA“ genannt, typischerweise auch Multiscan, aber unterstützt nur Zeilenfrequenzen jenseits der 31kHz, Bildwiederholfrequenzen oft ab 50Hz, manchmal erst ab 60Hz. Im Standardzustand (24 MHz-Quarz für den VIDC) ist der A3000 nicht in der Lage, ein präzises VGA-Signal zu generieren – dazu braucht man dann einen VIDC-Enhancer. Besser ist aber, einen Monitor zu haben, der die etwas krummen Signale des A3000 verarbeiten kann. Und noch ein kleiner Haken: die PAL-Modi werden als „Letterbox-Modus“ dargestellt, so dass das Seitenverhältnis meist nicht richtig stimmt – außerdem verdoppelt sich die genutzte DMA-Speicherbandbreite, so dass einige sensible Spiele aus dem Takt kommen bzw.

Zweite wichtige Einstellung: benötigt der Monitor ein kombiniertes Sync-Signal (auch „Composite Sync“ oder „CSync“ genannt), oder braucht er separate Sync-Signale (HSync und VSync). Hier gibt es zwei Einstellungen softwareseitig beim A3000:

  • Sync 0 – separate Sync-Signale (HSync und VSync)
  • Sync 1 – kombiniertes Sync-Signal (CSync)

Faustregel: MonitorType 0 braucht Sync 1, MonitorType 4 braucht Sync 0, MonitorType 1 kann oft beides mit Tendenz zu Sync 0.

Und leider muss man ggf. auch noch hardwareseitig Jumper setzen, um statt CSync (Auslieferungsdefault) HSync/VSync zu erzeugen. Beim A3000 sind das folgende:

  • LK24 Jumper auf 1-2 (NORTH) – erzeugt HSync statt CSync auf Pin 4 des Videoausgangs
  • LK25 Jumper setzen – erzeugt VSync statt Mode auf Pin 5 des Videoausgangs

Dann gibt es noch zwei Jumper für die Sync-Polarität (LK26 und LK27), ich kenne aber keinen Fall wo man die anfassen musste.

Wenn man kein Bild sieht, ist es oft schwierig, die notwendigen Kommandos zum Umkonfigurieren von Sync und MonitorType zu tippen. Deshalb kann man über die Methode „Taste drücken und gedrückt halten, dann einschalten“ sowohl Sync als auch MonitorType konfigurieren. Und das geht so:

  • Power-on-Reset mit „R“: CMOS-Clear und Sync auf 1
  • Power-on-Reset mit „T“: CMOS-Clear und Sync auf 0
  • Power-on-Reset mit „0“ auf dem Zehnerblock: MonitorType auf 0
  • Power-on-Reset mit „1“ auf dem Zehnerblock: MonitorType auf 1
  • Power-on-Reset mit „4“ auf dem Zehnerblock: MonitorType auf 4

Letzter Stolperstein: der A3000 hat den alten 9poligen Sub-D-Stecker als Monitoranschluss. Glücklicherweise funktionieren übliche 9to15-Adapter wie dieser hier problemlos.

Eine absolute Notlösung gibt es auch noch: Verwendung des Chinch-Monochrom-Anschluss – hier wird ein BAS-Signal ausgegeben. Sollte alles, was einen FBAS-Eingang hat, darstellen können (also selbst alte Fernseher ohne Scart mit 6pol.-DIN-Videoanschluss). Hier ist MonitorType 0 Pflicht.