September 2019

You are browsing the site archives by month.

DoReCo Party #11 – Ein Rückblick

Vergangenes Wochenende fand – unter überraschend großer Beteiligung diverser RISC OS-Nutzer – die DoReCo-Party #11 statt. Drei Tage Retro-Spaß, Freitag bis Sonntag. Mit Aufbau Freitag und Abbau Sonntag, also Samstag als Hauptkampftag. Und mitten im Nirgendwo mit dem schönen Ortsnamen “Anröchte-Altenmellrich” in der dortigen Schützenhalle. Es waren also keine externen Ablenkungen zu befürchten.

Michael Hönsch hatte die ehrenvolle Idee, das schon länger ins Auge gefasste RISC OS-Bundestreffen (mit allen noch aktiven RISC OS-Nutzern in Deutschland, also einer hohen einstelligen Zahl) dort abzuhalten – quasi die Party in der Party – und übernahm die organisatorischen Details wie Tische und Reservierung, und Herbert zur Nedden schlug vor das gleich mit dem GAG-Treffen 2019 in einen Topf zu werfen. Und so geschah es.

Typischerweise standen in der Vergangenheit die GAG-Treffen mehr im Zeichen neuer Hard- und Software und der jeweils aktuellsten Version von RISC OS. Diesmal hatte ich mir vorgenommen, passend zum Retro-Thema unserer Gastgeber (ähnlich wie damals bei der Classic Computing 2016 zu Nordhorn), eher eine Mischung aus alten und neuen Geräten an den Start zu bringen. Am Ende war es ein A5000, der per 10b2-Ethernet über Access mit einem Raspberry Pi B+ (RISC OS 5.26) und einem Core i3-Windows 7-Netbook (V-RPC Adjust, also RISC OS 4.39) redete. Dazu noch ein MISTer mit dem Archimedes-Core, der “Zarch” als Daueraufgabe bekam. Dazu zwei Monitore, und schon war der Tisch voll.

Thomas war mit an Bord mit KlappPi (einem Laptop-Eigenbau auf Raspberry Pi-Basis), BiKo (BeagleBoard im Koffer, akkubetrieben) und einer RiscStation R7500 mit der seltenen ISA-USB-Karte. Also im Prinzip drei Einzelstücke. Und Michael hatte aus dem Bereich “aktuelle RISC OS 5-Systeme” seinen ARMX6 dabei, nach wie vor eines der besten und ausgewogensten Geräte aus der neuen RISC OS-Rechner-Generation.

Einige aktuelle und ehemalige RISC OS-Benutzer kamen ebenfalls zu Besuch. Vor allem der Risc PC ist vielen noch in guter Erinnerung. Impression, TechWriter und Artworks kennen und lieben die meisten, dazu die nostalgische Verklärtheit bei der Erwähnung der PC-Karten-Lösung. Alle sind sich immer noch einig, dass RISC OS – bei all den bekannten Schwächen – was die grafische Oberfläche angeht nach wie vor der Benchmark ist. Mit Thomas L., den ich aus dem VzEkC-Acorn-Forum kannte, unterhielt ich mich wirklich lange über unsere diverse RISC OS-Hardware und die Zicken, die die alte Hardware ab und an macht.

Die erste Aufgabe: Mark (mit dem ich vorab schon Mailkontakt hatte wegen einer Acorn-Maus), ein Stammgast auf der DoReCo-Party, hatte seinen A3010 mitgebracht und wollte ein Parallelport-ZIP-Laufwerk (100 MB) anschließen. Mit Bootdiskette und so. Also eine Übung in Datentransfer zwischen alten und neuen Systemen mit erhöhtem Schwierigkeitsgrad, denn mein A5000 hat unglücklicherweise einen Batterieschaden der den internen Floppy- und IDE-Controller bzw. die Buchsen und/oder was drumrum gekillt hat, und so war der direkte Weg – schreiben einer Diskette – verbaut. Zusätzliche Hürde: der A3010 hatte nur 2 MiB RAM, womit viele Ideen, die die RAM-Disc als Zwischenspeicher nutzen, direkt flach fallen. Der Plan: einen Weg austüfteln, um aus dem Internet heruntergeladene .adf- und .apd- und .jfd-Floppy-Images auf dem A3010 lauffähig zu bekommen. Nicht trivial, weil die RAM-Knappheit die Nutzung des offensichtlichen Wegs – auf einem PC auf ein DOS-ZIP-Medium die Disc-Images zu packen und dann auf dem A3010 mittels ADFFS zur Verfügung zu stellen – leider verunmöglichte. Da musste ich erst mal drüber schlafen. Inzwischen habe ich mehrere Varianten ausgetüftelt, die allerdings eher komplex erscheinen – ich werde demnächst einen eigenen Artikel dazu veröffentlichen. An alle anderen der Ratschlag: alte RISC OS-Rechner außer in Sonderfällen immer gleich mit 4 MiB RAM kaufen. Das erspart eine Menge Probleme, selbst wenn man auf den ersten Blick “nur spielen” will.

Zwischenzeitlich diskutierte ich mit dem Eigner über seine eigentliche Leidenschaft, den guten alten Commodore Plus/4, der es seinerzeit bekanntlich gegen den C64 nicht geschafft hat, sich aber in Retro-Kreisen steigender Beliebtheit erfreut (man schaue sich mal das aktuelle Spiel “Alpharay” an, ein R-Type-artiger Shooter – sehr beeindruckend). Überraschend, an wie viele Details von früher ich mich erinnerte, ohne jemals einen C16 oder C116 oder Plus/4 besessen zu haben – von den 121 Farben über den TED, BASIC V3.5 bis zur 1551. Und natürlich die nur zu sich selbst kompatiblen Spezialjoystick-Ports. Ein schrulliges Gerät, mit dem sich Acorn-Fans natürlich eher identifizieren können als mit einem erfolgreichen Produkt wie dem C64.

Beim A3010 zeigte sich auch ein momentan nicht erklärbares Phänomen: das von RetroBargains aktuell verkaufte Busmaus-USB-Adapterchen (“ArcMouse” – man beachte: die daran angeschlossene USB-Maus muss einen PS/2-Modus besitzen!) verweigerte seinen Dienst am A3010, funktionierte aber ganz prima an meinem A5000 bzw. dessen Tastatur. Sehr dubios. Kurz entschlossen tauschte ich einen meiner PS2MouseMini-Adapter inklusive klassischer Logitech-3-Tasten-ohne-Mausrad-Maus gegen den ArcMouse-Adapter nebst optischer Microsoft-USB-Maus. So kann ich demnächst mal prüfen, was dieser Adapter an anderen Gerätschaften wie einer Ur-A310-Tastatur, einem A3000 oder einem Risc PC macht. Es wäre mir nicht bekannt, dass es bei den Mäusen in irgendeiner Weise Inkompatibilitäten zwischen den verschiedenen Acorn-Rechnern gab.

Das andere Problem mit diesem A3010: zuerst war er über den HF-Ausgang mit dem Monitor verbunden, der gleichzeitig einen TV-Tuner hatte. Aber die so erzielbare Qualität ist natürlich unterirdisch. Über dessen VGA-Eingang gab es aber nix zu sehen. Dubios. Mit meinem BenQ-TFT vom A5000 funktionierte hingegen der A3010 wunderprächtig, der Videoausgang war also einwandfrei. Es stellte sich heraus: es lag am Kabel. Tausch des VGA-Kabels, und auch der Monitor des Besitzers funktionierte.

Die zweite Aufgabe: ein etwas indisponierter Risc PC, den einer der anderen Teilnehmer (Tom Phobos) mitgebracht hatte und der beim Hochfahren nur die berühmte Diskette anzeigte (für Uneingeweihte: man muss dann eine Boot-Diskette mit dem konfigurierten Territory einlegen, damit es weiter geht) – typisches Anzeichen für entweder kaputtes CMOS oder kaputtes Bootmedium. Kurze Inspektion – das Board war in sehr gutem Zustand, der Akku wurde rechtzeitig entfernt und durch einen separaten AAA-Batteriehalter ersetzt. Zwei Podules waren drin, ein MCS Connect32 SCSI-Controller und ein Simtec/STD Unipod. Eine klassische Ein-Slice-Maschine mit dem schwächeren Netzteil (70W). Als 5,25″-Laufwerk war ein SCSI-CD-Brenner eingebaut. Einen CMOS-Reset später, und die Kiste bootete sauber durch, allerdings mit mehreren Disc Error 21-Meldungen, was typischerweise auf eine Festplatte in den letzten Zügen hinweist. Es stellte sich dann aber zunächst heraus, dass der Stützakku hinüber war und die CMOS-Werte nicht behalten wurden. Kurz ausgetauscht gegen eine Eneloop Pro aus meinem Bestand – lief. Und dann begann die Jagd nach den rätselhaften Phänomenen. Wo kam der Disc Error 21 her? Erst mal die Maschine runtergestrippt und nur mit der Festplatte selbst betrieben – also ohne Podules und ohne Backplane und ohne Floppy. Ergebnis: lief einwandfrei, keine Fehler mehr. Aha. Also erstmal optimistisch wieder alles zusammengebaut, und der Fehler war wieder da. Hmmm. CD-Brenner abgeklemmt und den Connect32 rausgeworfen: Fehler ist weg. Hmmmmmm. Also mit dem Besitzer geredet und den Plan gefasst: wenn schon ein IDE-Unipod drinsteckt, und ansonsten keine SCSI-Geräte gebraucht werden, am besten ein IDE-CD-ROM einbauen. Ein paar Minuten später lagen zwei zur Auswahl auf dem Tisch, ich entschied mich für das mit dem niedrigeren Stromverbrauch – denn das schwächere Risc PC-Netzteil bringt auf der 12V-Schiene nur 2,05A, dann sind Laufwerke die da mal locker 2A ziehen nicht zu gebrauchen. Durch eine großzügige Spende eines nichtessentiellen IDE-Kabels aus meinem A5000 das Laufwerk an das Unipod angeschlossen und…Disc Error 21. Sollte es doch am Netzteil liegen? Schnell das IDE-CD-ROM mit einem externen Netzteil versorgt (und dabei festgestellt, dass der Mechanismus der Laufwerkschublade zu allem Überfluss auch nicht mehr funktionierte) und…immer noch Disc Error 21. So langsam wurde es rätselhaft. Das IDE-CD-ROM vom Flachbandkabel entfernt – immer noch Disc Error 21. Das Flachbandkabel aus dem Unipod gezogen – jetzt lief es wieder. Was??? Gegenprobe mit dem Connect32. SCSI-Kabel steckt drin -> Disc Error 21. SCSI-Kabel steckt nicht drin -> alles lief. Nun gut. Manche Phänomene muss man wohl einfach hinnehmen. Ich habe keine Vorstellung, was hier der Grund sein könnte, schließlich hing die IDE-Platte mit den Fehlern ja im internen IDE – vielleicht hätte ein Wünschelrutengänger bei der Analyse helfen können? Wie dem auch sei, der Besitzer war leidlich glücklich mit der neuen Situation – ein einwandfrei laufender Risc PC, aber eben ohne CD-Laufwerk. Man kann sich Schlechteres vorstellen. Übrigens hatte dieser Risc PC ein äußerst seltsames VRAM intus, das ich so noch nicht gesehen habe – 2 MiB, und irgendwie “asymmetrisch” gebaut. Die linke Platinenhälfte war niedriger als die rechte, die Chips links waren waagrecht angeordnet und die Chips rechts senkrecht. Keine Ahnung, was für ein Spezialteil das war.

Am Samstag gab es einige Vorträge zu diversen Retro-Themen. Besonders interessant fand ich einen Vortrag von Slamy, der über seine Entwicklung eines Spiels namens “Tiny Little Slug” für den Amiga berichtete. Ein Jump’n’Run im weitesten Sinne (Held der Geschichte ist eine Schnecke, was mit “Springen” und “Rennen” nun normalerweise nicht direkt in Verbindung gebracht wird – hier mehr Infos zum Spiel), für einen Amiga 500 in der Basisausstattung. Was bedeutet: mehr als 512 KiB RAM stehen nicht zur Verfügung. Eine echte Herausforderung, zumal das Spiel komplett in C bzw. C++ per Crosscompile mit GCC unter x86-Linux entstehen sollte. Was mich später zu einem längeren Gespräch mit Slamy veranlasste, der allerlei interessante Details zu GCC, dem 68k-Backend, Bare-Metal-NDOS-Entwicklung, AmigaOS, MorphOS und einer Toolchain-Automatisierung namens Yocto zu erzählen wusste. Kurze Abschweifungen inklusive – zu USB-Floppycontrollern, CAN-Bus, FlexRay, ARM-Core-Varianten, aktuelle Entwicklungen in der Welt von C++, Ada und GNAT…sehr erfrischend und spannend. Mit vielen interessanten Einblicken vor allem in die Welt des Amiga, wo die “backward compatibility breaking changes” noch häufiger als unter RISC OS stattgefunden haben.

Ein C64-Fan stellte mir den aktuellen Stand der Dinge an dieser Front vor. Entsprechende Peripherie vorausgesetzt, kann man sich inzwischen über WLAN in Internet-Mailboxen “einwählen”. Auf dem C64 eine besondere Herausforderung, weil die Bildschirmauflösung für eine anständige 80-Zeichen-pro-Zeile-Darstellung nicht ausreicht. Jedenfalls gibt es hier eine aktive Retro-BBS-Szene, da lohnt sich mal ein genauerer Blick drauf. Ich habe ja eine FidoNet- und Mailbox-Vergangenheit, vielleicht mal den Kollegen Stefan Brück fragen, ob er noch ein Backup der ArcPool-Mailbox (damals in Wolfsburg beheimatet) hat. In der RISC OS-Welt ist meines Wissens die Arcade BBS die einzige Überlebende der glorreichen Mailbox-Zeit.

Interessant auch ein Acorn BBC Model B, den mir Markus (Fragg) zeigte, der am Tube-Port einen Raspberry Pi mit dem Pi-Tube-Kit (auch als “co-processor tube hat adapter” bekannt) von RetroClinic hängen hatte. Damit kann man alle damals erhältlichen Zweitprozessoren emulieren, vom Z80 über den 80286 bis zum original ARM-Entwicklungssystem. Und als Sonderbonus der direkte Zugriff auf den native ARM des Raspberry Pi. Was man damit anfangen kann? Keine Ahnung, aber cool, dass es geht! Die gängige Demo-Software dafür ist die Executive-Version von Elite, die den Turbo-6502-Coprozessor nutzt. Ansonsten ist die Softwareunterstützung dieser Wunderwerke eher sparsam. Die für Archimedes-Archäologen hochinteressanten verschiedenen Zwischenstände der Arthur- und ARX-Entwicklung aus der ARM-Frühzeit sind meines Wissens für immer verloren.

Und sonst? Das zentrale Event war die Versteigerung diverser Gerätschaften und anderen Retro-Dingen für den guten Zweck, einem Kinder-Hospiz. Großartige Gegenstände, inspirierend angepriesen von Hellcat. Den höchsten Einzelpreis erzielte nach meiner Erinnerung die handsignierte Debüt-CD von Chris Hülsbeck. Sehr cool fand ich ein Space-Invader-Mosaik aus 3,5″-Disketten. Großen Zuspruch fand auch ein holzfurniertes C64-Gehäuse, das ein Vereinsmitglied gebastelt hatte. Und zwischendurch beispielsweise der limitierte, goldene USB-Competition-Pro-Joystick oder auch das Spiel Top Gun auf Kassette für den C64. Das blieb im Gedächtnis. Zwei optische Highlights unter den Ausstellungsstücken will ich auch noch erwähnen: eine handgestrickte Abdeckung für den C64 (hier neben anderen Fotos auf Seite 3 zu finden) und ein beleuchteter Sinclair Spectrum in Transparenz-Optik, wobei die Beleuchtung das Spectrum-Regenbogenlogo simulierte (vermutlich dieses Gehäuse). Sehr cool. Die Kreativität im Retro-Bereich ist unverändert hoch.

Die gesamte Atmosphäre der Veranstaltung fand ich sehr angenehm, auch wenn in meinem fortgeschrittenen Alter die ständige Hintergrundbedröhnung durch Musik und den Versteigerungsevent etwas verstärkten Einsatz der Stimmbänder und höchste Konzentration beim Zuhören erforderte. Allerdings muss ich sagen, dass die Playlist wirklich exzellent zusammengestellt war, so dass nicht die Musik selbst störend war, sondern nur ab und an die Lautstärke. Mein Kompliment. Auch hinsichtlich der Organisation der Veranstaltung gibt es nichts zu mosern.

Außerdem stelle ich fest, dass ich es sehr genieße, mal in einer Zusammenkunft vieler Menschen NICHT der exotische Nerd zu sein. Sondern einer unter vielen. Wo findet man schon 100 oder mehr Leute auf einem Haufen, die bei der Ankündigung der Versteigerung einer Chris-Hülsbeck-CD nicht erstmal fragen “Häh? Wer soll das denn sein?” Mir kam die legendäre Szene aus dem Film “Voll normaaal” mit Tom Gerhardt in den Sinn: “Endlich normale Leute”.

Jedenfalls ist die DoReCo-Party auf der Liste der Events, bei denen man dabei sein sollte. Leider gibt es da reichlich Konkurrenz: das klassische GAG-Treffen, die Classic Computing, das Xzentrix…und es gibt eben viele konkurrierende Hobbys. Mal sehen, was 2020 ansteht.

Neue Testversion von Aemulor verfügbar

Korrektur 2019-09-24: die vormals hier stehenden Infos zum ARMBook von R-Comp waren falsch. Es basiert auf dem Pinebook, nicht auf dem Pinebook Pro wie vormals fälschlicherweise hier geschrieben (vermutlich war der Wunsch Vater des Gedankens – eine sehr optimistische Interpretation der vorliegenden Informationen). Was wieder zeigt, dass auch knapp fünf Jahre nach diesem Blogeintrag die Problematik der Transparenz von Informationen weiterhin gegeben ist.

Adrian Lees, Entwickler von Aemulor (wer aus unverständlichen Gründen nicht weiß, was Aemulor ist und wozu es gut ist, kann es hier detailliert nachlesen), hat die Verfügbarkeit einer neuen Test- bzw. Entwicklungsversion verkündet. 2.51 ist die Versionsnummer, Download von hier.

Was ist neu? Eine der ungünstigen Nebenwirkungen von Aemulor war immer, dass nicht nur der Application Memory Slot (aka Wimpslot) für die emulierten 26bit-Anwendungen auf die unter RISC OS 4 und früher üblichen 28 MiB RAM eingeschränkt wurde, sondern auch der für alle anderen Anwendungen. Die neue Entwicklungsversion schafft hier nun etwas mehr Platz als früher: durch Anpassungen der Memory Map stehen nun 52 MiB RAM im Wimpslot zur Verfügung. Diese Anpassung ist optional, man kann auch mit der alten Konfiguration arbeiten.

Für die nicht-so-RISC OS-Erfahrenen: das 28 MiB-Limit kommt aus der 26bit-Zeit, also alles bis einschließlich RISC OS 4, als die CPU wie zu Zeiten des ARM2 1986 den Programmcode nur innerhalb der ersten 64 MiB ausführen konnte – weil der Program-Counter, also das Register (R15 übrigens), das die derzeitige Ausführungsadresse enthält, nur die unteren 26bit für die Adresse verwendete. Und dann hat Acorn zur Vereinfachung der restlichen Hardware (damit die MMU genannt “MEMC” eben nur diese adressieren können muss) kurzerhand diese 64 MiB in gewisse Blöcke aufgeteilt wie die RMA, das ROM, den System-Heap und IO-Bereiche. Hier ist die vollständige Übersicht zu sehen. Wenn man so will, ganz ähnlich wie die DOS-Memory-Map mit ihrem 640 KiByte-Problem.

Und um keine Missverständnisse aufkommen zu lassen: das 28 MiB-Limit bedeutet nicht, dass eine Anwendung nur 28 MiB nutzen kann. Es bedeutet nur, dass der ausgeführte Programmcode maximal 28 MiB groß sein darf – Daten können auch (seit RISC OS 3.5 und dem ARM6xx – seither können nämlich die vollen 32 Bit adressiert werden) in den sogenannten “dynamic areas” liegen. Die Erhöhung von 28 MiB auf 52 MiB ist also bei den RISC OS-typischen eher kleinen Programmen tatsächlich nur für spezielle Anwendungen interessant. Dort aber potenziell lebensrettend.

Und wie läuft er nun, der neue Aemulor? Kann ich noch nicht sagen. Bin mitten in den Vorbereitungen für die DoReCo-Party kommendes Wochenende, da ist für die Kür erst Zeit, wenn die Pflicht erledigt ist. Interessant auf jeden Fall, dass diese Aemulor-Version auf dem brandneuen ARMBook von R-Comp (ein Pinebook mit RISC OS) schon getestet wurde. Im Pinebook dreht ein Allwinner A64, also grob gesagt Cortex-A53 mit Mali-400, coretechnisch also identisch mit dem Raspberry Pi 3(+). Solange also “bekannte” Cores am Start sind, scheint die Produktion von kompatiblen Aemulor-Versionen für Adrian keine besondere Herausforderung zu sein.