Hardware

RISC OS-geeignete Hardware

Das Titanium-Board und die Suche nach dem passenden Netzteil

Der IYONIX pc war bekanntlich das erste RISC OS-taugliche Mainboard, das mit Standard-ATX-Netzteilen zusammenarbeitete. Auf dem langen Weg vom ersten Archimedes (vermutlich war die Parallelschnittstelle die einzige “standardkonforme” Schnittstelle – die serielle war RS423 statt RS232, der Monitorausgang war 9polig aber immerhin signaltechnisch weitgehend “PC-kompatibel”, der Floppyanschluss war zwar Shugart-kompatibel aber eher wählerisch) über den A5000 (IDE, Parallel, Seriell, VGA, Floppy – alles weitestgehend kompatibel zum damaligen PC-Standard, aber immer noch die merkwürdige Acorn-Tastatur mit dem integrierten Busmaus-Anschluss) bis zum A7000 (endlich PS/2 sowohl für Maus und Tastatur) war man immer näher an die Welt der Standardkomponenten und -schnittstellen gerückt. Nur Gehäuse und Netzteil blieben bis zuletzt proprietär.

Mit dem IYONIX pc fielen auch diese beiden Bastionen – die Platine im ATX-Format, und das Netzteil dazu passend. Allerdings stellte sich bald heraus, dass der IYONIX eine echte Mimose war wenn es um die Zusammenarbeit mit der PC-Netzteil-Welt ging. Das Problem: er brauchte zu wenig Strom, vor allem auf dem 12V-Zweig. Und so war es eine gute Idee, das Gehäuse mit Platten und Brennern vollzustopfen, was dann die häufigeren Problemchen beim Kaltstart weitestgehend eliminierte.

Das Titanium-Board von Elesar ist in gewisser Hinsicht der natürliche Nachfolger des IYONIX. Nicht nur, weil das Hauptdesign von derselben Person stammt. Sondern auch weil das Board eben in gewöhnliche ATX-Gehäuse passt und mit ATX-Netzteilen zusammenspielen soll. Soll. Denn ganz so einfach ist es auch diesmal nicht. Die Basisanforderungen scheinen noch einfach zu erfüllen zu sein: ATX 2.3 oder neuer muss es sein, und der Mainboard-Connector ist der ältere 20Pin-Typ, so dass nur Netzteile mit der 20+4-Konfiguration in Frage kommen. 4 S-ATA-Stromstecker wären auch gut, denn das Board unterstützt bekanntlich (und das ist ein echtes Alleinstellungsmerkmal) 4 S-ATA-Geräte. Aber wie immer steckt der Teufel im Detail.

Inzwischen ist die PC-Welt ja bezüglich des Leistungsbedarfs eines Rechners weit enteilt. Unter 400W kann man ja fast nur riskieren, wenn man mit Chipsatz-Grafik auskommt und nicht allzu viele Laufwerke betreiben will. Beim Titanium wäre ein 200W-Netzteil eher angebracht. Und Schaltnetzteile brauchen nun mal in den meisten Konstruktionen eine gewisse Mindestlast, um sicher anzuspringen und stabile Spannungen zu liefern. Ironischerweise gab es zuletzt ein Update an der PC-Front, damit die Netzteile auch die extrem stromsparenden C6/C7-“Deep Power Down”-Modi der Intel-Prozessorgeneration ab Haswell funktionieren.

Drei Netzteile habe ich mit dem Titanium-Board zusammen getestet: ein No-Name-550W-Netzteil, ein be quiet! Pure Power 10 300W und ein be quiet! Straight Power 10 400W. Ergebnis: nur das Straight Power 10 funktioniert ohne Macken und Zucken mit der von mir definierten Minimallast “Titanium-Board und SSD”, die anderen Kandidaten brauchten nicht weniger als 3 Brenner, bis der Startup absolut zuverlässig funktionierte. Ob das mit dem laut Datenblatt “Zero Load Design” zu tun hat, weiß ich nicht – eine Gegenprobe mit dem preiswerteren System Power 8 wäre interessant, das Pure Power 10 hat dieses Feature nicht.

Das Straight Power 10 ist auch sonst eine absolute Empfehlung. Der 135mm-Lüfter ist nahezu unhörbar, es hat absolut ausreichend Anschlüsse für S-ATA-Geräte sowie althergebrachte Molex- und Berg-Stecker (auch in S-ATA-Zeiten oft noch nützlich für Zusatzgeräte wie interne USB-Hubs oder Cardreader). Bisher bin ich so zufrieden, dass das Straight Power wohl auch den Weg in meinen nächsten Selbstbau-PC finden wird. Die fünf Jahre Herstellergarantie sind ebenfalls vertrauenserweckend.

Raspberry Pi – gute Gehäuse, schlechte Gehäuse

Angesichts seiner Einsatzuniversalität türmen sich langsam die RPis bei mir auf dem Schreibtisch. Und so habe ich hier einen Sack voll Gehäuse für die Dinger stehen und kann demzufolge qualifiziert darüber berichten, welche Gehäuse nach meiner Meinung super sind und welche unbrauchbar. Und welche irgendwo dazwischen. Während beim originalen RPi 1 noch praktisch jedes Gehäuse mehr oder weniger brauchbar war, liegt die Sache seit der RPi eine microSD-Karte schluckt etwas anders – die Full-Size-SD-Karte stand so weit aus dem Gehäuse, dass sie problemlos bei jedem Gehäuse wechselbar war, bei der microSD ist die Geschichte komplizierter, zumal nur B+ und B 2 einen Federmechanismus für die Karte haben, während sie beim B 3 nur gesteckt wird. Es gibt Gehäuse, wo man die microSD-Karte schlicht nicht greifen kann um sie herauszuziehen.

Ich betrachte hier nur die Modellvariante B für alle RPi-Varianten.

Das fiktive ideale Gehäuse

Mein Wunschgehäuse wäre stabil, die Innereien einfach zugänglich, mit einfach zugänglicher microSD-Karte, im geschlossenen Zustand GPIO-fähig, stapelbar, schick und in verschiedensten Farben erhältlich (zur einfachen Unterscheidung verschiedener Einsatzzwecke ohne weitere Beschriftung – bei mir am Start: RPi B+, RPi 2, RPi 3, RISC OS, Linux, RetroPi, Kodi…).

Corkea Aluminium-Gehäuse

Mein derzeitiger Favorit. Passgenau, mit anständiger Öffnung um die microSD-Karte auch wieder rauszubekommen, in fünf verschiedenen Farben erhältlich, und beigelegt auch noch ein Satz Kühlkörper sowie ein Schraubendreher. Dazu sauber rechteckig, also auch stapelbar.

Wird bei Amazon.de für 12-13€ verkauft, hier der Link zur schwarzen Variante.

Als Nachteil mag empfunden werden, dass geschraubt werden muss – an Stirnseite und Rückseite jeweils 4 Schrauben halten das Teil bombenfest zusammen, die RPi-Platine wird mit dem Gehäuseboden verschraubt. Aber man kann das Ding halt nicht “kurz mal” aufmachen. Zumal Deckel und Boden etwas hakelig aufeinander geclipst werden.

Offizielles Raspberry Pi-Gehäuse

Auch ein sehr gutes Gehäuse. Komplett gesteckt ohne Schrauben, mit anständiger Öffnung um die microSD-Karte auch wieder rauszubekommen, leider nur in zwei Farben erhältlich, wovon eine der grauenvolle Versuch ist, eine Art Himbeerfarbe darzustellen. Der Deckel weist eine Rundung auf, so dass Stapelung nicht wirklich funktioniert.

Kostenpunkt knapp 10€, hier der Link zur schwarzen/dunkelgrauen Variante bei Amazon.

Obwohl nur gesteckt und aus Kunststoff, ist das Gehäuse durchaus hochwertig und stabil. Braucht man Zugriff auf die GPIOs, kann man entweder den Deckel weglassen oder das Wandelement.

Durchwachsene Gehäuse

  • FabLabShop Holz-, Plexiglas- und Design-Gehäuse – im Prinzip super, wird einfach zusammengesteckt und hält bombenfest, dazu individuell gravierbar und trotzdem preisgünstig. Haken: die microSD-Karte ist faktisch nicht mehr zugänglich ohne das Gehäuse zu demontieren.
  • Tek-Berry Design-Gehäuse – für dieses Gehäuse gibt es einen VESA-Adapter, der eine einfache Montage an der Rückseite eines Fernsehers oder Monitors nach VESA 50/75/100-Standard erlaubt. Dafür ist es extrem schlecht belüftet (die Lüftungslöcher sind zur Unterseite der RPi-Platine hin!) und die microSD-Karte ist kaum zu greifen. Typische Plastik-Snap-In-Befestigung, Auseinanderbau also eher schwierig und lieber nicht so oft aufgrund akuter Gefahr des Abbrechens diverser Plastiknasen. Kostet dafür auch nur knapp 5€. Gibt es in drei “Farben” schwarz, weiß und transparent.
  • Ein namenloses schwarzes Gehäuse – etwas fummelig in der Montage, microSD-Karte kaum zu greifen, dafür preiswert.
  • CamdenBoss Gehäuse in Transparenz-Carbon-Optik – ich hatte noch die Vorgängerversion, wo die microSD-Karte nur nach Gehäuse-Demontage erreichbar war, nach den Bildern zu urteilen ist das nun besser gelöst. Hauptproblem dieses Gehäuses: Snap-In-Montage, und bei der Demontage kann sehr leicht was abbrechen (sprich: bei mir ist was abgebrochen). Die 10€ meiner Ansicht nach nicht wert.

Muss-Ich-Noch-Testen-Gehäuse

Die folgenden Gehäuse stehen noch auf meiner Merkliste und werden irgendwann den Weg ins Testlabor finden.

  • oneninedesign RPi Quattro-Gehäuse – endlich mehr Platz als nur für den RPi selbst!
  • Alu-Gehäuse gibt es in verschiedenen Farben
  • Orbital Case – ein schöner Kontrast zum Rechteck-Boxen-Einheitsbrei, aber der direkte Zugriff auf die microSD-Karte scheint hier auch nicht möglich zu sein

iMX6-HAL erreicht das ROOL-Repository

Ich hatte es früher schon erwähnt: es lohnt sich immer, die Bewegungen im ROOL-Repository im Auge zu behalten. Seit einiger Zeit hat nun endlich der iMX6-HAL seinen Weg dorthin gefunden. Nebenbei: man hofft, dass der Code fehlerärmer ist als die Commit-Kommentare.

Der iMX6, der im Herzen des ARMX6 von R-Comp (und ja, ich würde gerne auf eine ARMX6-Seite verlinken, aber R-Comp ist eben R-Comp) in Form des Wandboard Quad schlägt, erhielt seine RISC OS-Weihen in proprietärer Form von R-Comp. Klar, wer entwickelt, will damit auch Geld verdienen. Die kommerzielle RISC OS-Lizenz von Castle hat für diesen Fall eine Spezialklausel: gegen ein paar Euro (maximal 10 UKP pro verkaufter Lizenz) müssen geänderte OS-Quellen zunächst nicht an ROOL zurückfließen, sondern man kann sich bis zu 2 Jahre Zeit erkaufen. Die waren im Falle des iMX6 jetzt rum.

Nächste Aufgabe: iMX6-ROM bauen aus den aktuellen Quellen.

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:

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.

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.

Alte Geräte, alte Netzteile

Hatte nicht neulich jemand die Robustheit alter Geräte gelobt? Stimmt, das war ich ja selbst. In einer neuen Ausgabe der Serie “wenn man den Tag vor dem Abend lobt” hat sich heute Morgen das Netzteil meines A3000, den ich in liebevoller Kleinarbeit gerade für die Classic Computing 2016 vorbereite, mit einem lauten Knall verabschiedet. Super.

Ersatz musste her. Als erstes habe ich recherchiert, wieviel Output das gute Stück denn lieferte – ganze 22W. Irgendwie wenig, aber dann doch auch wieder viel, wenn man nicht gleich ein PC-Netzteil anklemmen will (und das ist seit ATX ja auch gar nicht mehr so einfach, da viele Netzteile nur Saft geben, wenn ein Mainboard dranhängt und “Power Good” signalisiert). Erste Idee: eins der Floppy-/Festplatten-Netzteile mit 4pin-Molex-Ausgang zum externen Anschluss von S-ATA- oder IDE-Geräten. Alle, die ich habe, liefern aber nur 2A@5V. Hmmmm. Trotzdem schnell einen Molex-Y-Adapter geschnappt, zwei Drähte gekappt, zwei Crimp-Stecker drangemacht, an den A3000 angeklemmt – läuft soweit. Ohne Floppy natürlich, aber die kann ich über ein zweites solches Netzteil versorgen, wenn ich sie denn wirklich brauche.

Reichen die 2A? Keine Ahnung. Die 22W müssen ja reichen für ein Podule und ein Mini-Podule, die Floppy, eventuell Econet und das Board. Ich habe vorsichtshalber weiter gesucht und bin auf ein 2,5A@5V-Netzteil gestoßen, das ich zum Betrieb meines Amstrad CPC6128plus ohne den dazugehörigen Monitor bevorratet hatte. Dazu hatte ich zur 12V-Versorgung meines Schneider CPC6128 bei meiner letzten Reichelt-Bestellung ein fertig konfektioniertes Kabel mit 2,1mm-Hohlsteckerbuchse auf der einen und blankem Kabel auf der anderen Seite geordert. Das habe ich jetzt als Gegenstück zum 2,1mm-Hohlstecker des Netzteils genutzt – gekürzt, Crimp-Stecker dran, Atem anhalten – A3000 läuft. Ich habe das alte Netzteil nebst Netzkabel nun entfernt und werde bei Gelegenheit ein gescheites Netzteil einbauen. Jetzt muss erstmal die fliegende Verdrahtung ausreichen.

Ich hoffe, das war jetzt die letzte Überraschung vor der CC2016.

Classic Computing 2016 (4) – Der Raspberry Pi

Der dritte Kandidat unter der Hardware, die ich bei der Classic Computing 2016 zeigen will, ist der Raspberry Pi Model B+. Der Raspberry Pi startete 2012 die Revolution der wirklich preiswerten SBCs, die trotzdem genügend CPU-Power haben um für allgemeine Anwendungen nützlich zu sein – auch wenn die Linux-Fraktion am ersten Modell, das mit sparsamen 256 MB RAM ausgerüstet war, sehr rumgemäkelt hat. RISC OS-Nutzer konnten das nicht nachvollziehen, gelten hier doch 256 MB RAM als unendliche Speicherweiten.

Aus RISC OS-Sicht ist der Raspberry Pi etwas Besonderes. Zum einen unterhält RISC OS Open Ltd. eine besondere Beziehung zur Raspberry Pi Foundation – dadurch ist eine sehr gute und aktuelle Unterstützung der Hardware gelungen, wann immer eine neue Variante auf den Markt kommt, ist meist die passende RISC OS-Version direkt verfügbar. Zum anderen sind die Treuhänder der Raspberry Pi Foundation teilweise alte Bekannte. Von David Braben stammt das legendäre Spiel Zarch, ein (nein, DER) Launch-Titel des Acorn Archimedes. Alan Mycroft ist das “croft” im Norcroft-Compiler, der unser aller Lieblingsbetriebssystem baut. Und die anderen hatten bestimmt mal einen Acorn BBC Model B oder Electron.

Warum das alte Modell mit dem ARM11? Das hat seinen Grund in der Zielrichtung “Retro”. Der Ur-Pi hat noch eine ARMv6-CPU intus, die im ARMv5-Kompatibilitätsmodus laufen kann. Das macht den Ur-Pi am besten kompatibel zur Software der IYONIX pc-Zeit, und er ist die am besten unterstützte RISC OS 5-Plattform von ADFFS, welches es ermöglicht, die guten alten Spiele von Ende der 80er/Anfang der 90er auf aktueller Hardware zu zocken. Abgesehen davon profitiert RISC OS nicht so dramatisch wie andere Betriebssysteme von den neueren Multicore-Modellen und performt auf der ollen 700MHz-Kiste sehr ordentlich.

Also habe ich den Raspberry Pi B+ aus seinem schäbigen Plastikgehäuse befreit, wo er seit dem Kauf sein Dasein fristet, und ihn in ein Original-Pi-Gehäuse in stylishem Grau-Schwarz verfrachtet. Die RISC OS-Installation war auf dem Stand von 2015, also kurzerhand eine frische schnelle Transcend-microSD-Karte geschnappt und eine neue Installation hochgezogen. RISC OS Nightly Build, aktuellste RPi-Firmware von Github geholt, nur die alte config.txt blieb erhalten. Alles mit SystemDisc eingerichtet, microSD-Karten getauscht, und…startet, sieht aber komisch aus, wie Falschfarbendarstellung. Kurzes Googeln bringt es an den Tag: es gab Änderungen beim Default der Farbkonfiguration des VideoCore. Jetzt braucht es den Eintrag framebuffer_swap=0 in der config.txt. Wer auf “merkwürdig bunt” steht, kann es natürlich auch lassen, denn auf gewisse Art und Weise erinnert die Falschfarbendarstellung durchaus an die Archimedes-Anfangszeiten mit Arthur als Betriebssystem. Bei der Gelegenheit konnte ich gleich den Overscan deaktivieren – wie sich ein solches Rudiment aus der Röhren-Analog-Monitor-und-Fernseher-Zeit so lange halten kann…

An Software habe ich die gängigen Anwendungen wie Zap, StrongEd, Pipedream, Fireworkz, Vector, OvationPro, DPingScan, SparkFS usw. am Start, aber natürlich soll der Schwerpunkt auf “Retro” liegen. Dabei helfen ADFFS, A310Emu und ArchiEmu als Emulationsplattformen für die gute alte Welt. Man wird also den 1:1-Vergleich zwischen Original, FPGA-Simulation und verschiedenen Emulationstechniken ziehen können.

Besonders ADFFS hat mich lange Zeit an den Rand des Wahnsinns getrieben. Einmal deshalb, weil die JASPP-Archive mit den Spielen in einem Format sind, das ADFFS gar nicht direkt nutzen kann – man muss stattdessen die Disc-Images auspacken, Filetypen und umbenennen. Aha. Dafür habe ich vorsichtshalber ein kleines rudimentäres Java-Programm geschrieben, das dieses automatisch erledigt und gleich so Feinheiten wie “Zeichen in Dateinamen, die RISC OS und Filecore nicht unterstützen” berücksichtigt und die überlangen Namen sinnvoll einkürzt, damit sie auch auf einen A3000 passen.

Das andere Problem: ADFFS braucht für die Emulation zwingend im MDF den Screenmode, den das Spiel verwenden will – hat man den nicht, kommt es zu lustigen Effekten wie Multiplikation des Bildschirminhalts inklusive übler Flackerei. Gott sei Dank gibt es hier mit AnyMode von Steve Harrison eine komfortable Lösung – dank der Flexibilität des Pi-Videoprozessors, der beliebige Auflösungen automatisch auf die Auflösung des Monitors skalieren kann, reicht AnyMode einfach jede beliebige Mode-Anfrage an diesen weiter und signalisiert der Anwendung: Auflösung ist möglich! Zur Ehrenrettung von ADFFS: dass auf dem Pi AnyMode von Vorteil ist, ist durchaus dokumentiert.

Jetzt habe ich erstmal alles Notwendige auf der microSD-Karte, kann mich also dem Finetuning und Test widmen. Etwas schade: leider gibt es noch keinen USB-Treiber für klassische digitale Joysticks, der die Acorn-SWIs unterstützt – das wäre doch ein schönes Projekt für “Live-Messe-Coding”. Aber Joystick-Unterstützung war in Archimedes-Spielen schon immer eine Seltenheit.

Und ich wollte noch drei Info-Blätter mit den technischen Daten meiner drei Gerätschaften erstellen.

Übrigens habe ich noch gerade rechtzeitig heute vier kleine Gimmicks mit der Post bekommen, die am GAG-Stand auf der CC2016 begutachtet und bewundert werden können.

Classic Computing 2016 (3) – Das MIST-Board

Der zweite Kandidat unter der Hardware, die ich bei der Classic Computing 2016 zeigen will, ist das MIST-Board, manchmal auch “MIST FPGA computer” genannt oder einfach schlicht MIST (was im Deutschen natürlich kontextabhängiges Verstehen erfordert). Ich hatte schon früher darüber berichtet.

In aller Kürze: das MIST ist ein FPGA-basierter Computer. Ein FPGA ist ein reprogrammierbarer Chip. Für das MIST gibt es eine ganze Menge sogenannter Cores, die den FPGA so programmieren, dass er sich (mehr oder weniger) genau wie diverse Retro-Hardware verhält. Computer-Beispiele: Acorn Archimedes, Commodore Amiga, Atari ST, Commodore 64, Schneider CPC, Sinclair ZX Spectrum, Apple II+, Commodore 16, Acorn BBC Model B, Apple Macintosh, MSX, Sam Coupe, Sinclair QL. Spielkonsolenbeispiele: Atari VCS 2600, Sega Master System, Nintendo Entertainment System, NEC PC Engine, CBS ColecoVision. Hardwareseitig wird das unterstützt durch zwei Joystickports für die guten alten digitalen Joysticks mit 9-poligem Anschluss (früher auch als “Atari-kompatibel” bekannt), zudem kann man Maus und Tastatur (und auch Joysticks oder Joypads) per USB anschließen. Unterm Strich: Es steckt viel Spaß im MIST.

Für die CC2016 steht natürlich der Archimedes-Core im Mittelpunkt – wir sind schließlich die GAG, die German Archimedes Group, da ist der Name Programm. Ich habe eine SD-Karte mit RISC OS 3.11 vorbereitet mit ein paar echten Spieleklassikern. Dazu gibt es natürlich die beiden unvermeidlichen Competition Pro-Joysticks, auch wenn die Auswahl an Spielen, die sowohl auf dem MIST funktionieren als auch das vom MIST emulierte Acorn-Joystickinterface unterstützen sehr begrenzt ist. Als Bildschirm habe ich einen alten 20″-LCD dabei im klassischen 4:3-Format, der bis 50 Hz problemlos synchronisieren kann – ein Muss für den MIST-Betrieb.

Der Archimedes-Core ist insofern eine Besonderheit, dass er der einzige 32bit-Vertreter auf dem MIST ist. Der Core funktioniert für viele Dinge zwar schon prächtig, ist offiziell aber noch im Beta-Status. Am meisten vermisse ich die Harddisc-Emulation, so dass man ausschließlich mit Diskettenimages arbeiten muss – und hier wird leider nur das ADF-Format unterstützt, und es werden nur Images akzeptiert die genau 800KiB groß sind. Sehr pingelig. Es war eine Herausforderung, die problemlos lauffähigen Spiele herauszufiltern. Leider ist es mir nicht gelungen, im Verbund mit ADFFS kopiergeschützte Original-Images zum Laufen zu kriegen – irgendwie vertragen sich ADFFS und der Archimedes-Core nicht so recht.

Im Moment bin ich bei folgender Spieleauswahl angelangt, die nach kurzem Testspielen einwandfrei zu funktionieren scheinen:

  • Aldebaran
  • Chocks Away
  • Conqueror
  • E-Type
  • Elite
  • Oh No! More Lemmings
  • Pac-Mania
  • Populous
  • Zarch

Wer sich ein MIST kaufen will: der Dragonbox-Shop (bekannt durch Pandora, Pyra etc.) ist eine deutsche Bezugsquelle. Wer Doku und Sourcen inspizieren will, hat auf Github die Chance, denn das Projekt ist komplett Open Source – sowohl die Software als auch die Hardware. Ein deutschsprachiges Forum gibt es auch. Sogar mit eigenem Unterforum für den Archimedes-Core.

SD-Karte am A3000 – eine gewagte Konstruktion

Auf meiner Suche nach einer geeigneten Massenspeicherlösung für den A3000 habe ich nun eine sehr gewagte Konstruktion am Laufen. In Ermangelung geeigneter SCSI-Platten aus dem Bestand (oder des Mangels an Lust, sie zu suchen) habe ich aus meinem Hardware-Fundus folgendes zusammengebaut: eine 32 GB-SD-Karte, am Raspberry Pi per Cardreader und HForm auf eine RISC OS 3.1-kompatible Größe gebracht (499 MB – Filecore-Experten erkennen sofort: damit bleibt man gerade noch bei einer LFAU von 1024 bytes!). Die Karte steckt in einem SD-IDE-Adapter, stromversorgt mit einem Netzteil von einem USB-IDE/S-ATA-Adapter. Der SD-IDE-Adapter wiederum steckt in einer Acard AEC-7720U SCSI-IDE-Bridge (ursprünglich mal ins Auge gefasst, um für CDBurn, damals noch ohne IDE-Unterstützung, den Kunden im Angesicht immer exklusiver werdenden SCSI-Brennern eine preiswerte Lösung zum Anschluss an ihr SCSI-Subsystem anzubieten) die ihrerseits dann am HCCS-SCSI-Podule des A3000 hängt.

Gut, meine schwäbische Seele zuckt kurz bei dieser Verschwendung an Speicherplatz, aber es war gerade keine kleinere SD-Karte zur Hand. Alternativ gab es noch einen CompactFlash-IDE-Adapter zur Auswahl, aber meine größte CompactFlash-Karte die spontan zur Hand war hatte nur 256 MB, aus der Zeit, als für Digitalfotografie noch 3,2 Megapixel ausreichten und bei der Kamera ernsthaft eine 16 MB-CF-Karte mitgeliefert wurde. Das schien mir etwas knapp.

Im Moment – quasi als soak test – kopiert der A3000 fleißig den Inhalt der Quantum 100MB SCSI-Platte auf die SD-Karte. Bisher erst ein Lesefehler. Daumen drücken.

Dann mal sehen, ob ich den alten HCCS-Formatierer noch finde, denn es wurden prinzipiell vier Partitionen unterstützt, damit wäre ich bei fast 2 GB Gesamtspeicherplatz, das hört sich doch verlockend an. Ah, schon gefunden – nicht die Originaldiskette, sondern bei Chris’ Acorns.