Der RISC OS-Quellcode lebt jetzt in Git

2019-08-24 15:45

RISC OS hat bekanntlich eine lange Historie. Und alle Softwareprojekte mit Historie haben normalerweise auch eine Historie was die Quellcodeverwaltung angeht. So auch RISC OS. Ursprünglich mit RCS unterwegs (quasi der Urvater der Unix-VCS-Welt nach SCCS, das auf System/370 entwickelt wurde) und dann zum natürlichen RCS-Nachfolger CVS gewechselt, ist man jetzt den heutzutage quasi unvermeidlichen Weg weiter zu Git gegangen. Als Schnittstelle zur Außenwelt wird GitLab verwendet. GitLab hat natürlich noch ein paar andere Features für all das, was man heute unter „DevOps“ zusammenfasst, was davon Stand heute von RISC OS Open Ltd. verwendet wird entzieht sich meiner Kenntnis. Die Nightly Builds der RISC OS-ROM-Images ist ja ein eher komplexer Prozess, da RISC OS weiterhin nur mit der Norcroft-Toolchain baubar ist zuzüglich ein paar exotischer nur nativ unter RISC OS laufender Tools. Wenn ich mich recht erinnere ist deshalb eine Spezialversion von ArcEm noch mit am Start, um den kompletten Build unter unixoiden Plattformen überhaupt zu ermöglichen. Inwiefern das zur vorgedachten GitLab-Build-Pipeline passt – keine Ahnung. Stand heute wird das CI/CD-Zeugs von GitLab jedenfalls nicht (öffentlich einsehbar) verwendet.

Was mich daran erinnert, dass es wirklich mal ein schönes Projekt wäre, RISC OS komplett mit GCC und asasm baubar zu machen.

Die von CVS gewohnte, übersichtliche Historie der Änderungen über das Webinterface ist nun leider nicht mehr da, die Git-Struktur scheint etwas komplexer zu sein, mit dem selten genutzten Git-Feature „Submodules“. Vermutlich bräuchte es da etwas Code, der die Aufbereitung für Rails (die technische Plattform der RISC OS Open-Webpräsenz) übernimmt. Allerdings ist es schon viel besser geworden – also nicht vergessen: regelmäßig hier nachschauen was es Neues im RISC OS-Code gibt. Man kann direkt über das GitLab-Interface auch die akzeptierten Merge-Requests anschauen, das ist auch manchmal erhellend.

Und wie greift man nun von RISC OS aus auf Git zu? Jeffrey Lee hat dazu SimpleGit portiert.

Und noch was nebenbei, weil ich öfter Teil solcher Diskussionen war: „Veraltetes CVS“ war eine der gerne genutzten Ausreden, warum man ja leider nix zu RISC OS beitragen könne. Vermutlich nach „die Castle-Lizenz ist nicht echtes Open Source“ am öftesten gehört. Beides ist nun Geschichte. Nun bleibt noch „ich muss für das DDE bezahlen“ – mal sehen, wann diese Ausrede auch Geschichte ist. Dann wird man sehen, dass es trotz bester Rahmenbedingungen nur sehr wenige Menschen gibt, die sich in der gebotenen Tiefe mit einem Randgruppenbetriebssystem in ihrer Freizeit befassen wollen.

In gespannter Erwartung: Raspberry Pi 4 ante portas

2019-06-27 23:43

Update 2019-06-30: Ethernet-Anbindung korrigiert, USB3-Anbindung präzisiert, Cachegrößen nachgepflegt, USB-Strombegrenzung aus dem Datenblatt erwähnt, Dual-Head-Unklarheit bezüglich 4K@60Hz erwähnt.

Die Raspberry Pi Foundation hat mal wieder alle überrascht (und vorher auch reichlich Nebelkerzen geworfen, im Einklang mit Broadcom): der brandneue Raspberry Pi 4 ist ab sofort verfügbar, und er basiert weiterhin auf einem Broadcom-Chip. Nach dem RPi 3B+ wurde ja reichlich spekuliert, dass die Broadcom-Reihe nun ausgereizt sei und man möglicherweise sogar auf einen anderen SoC-Hersteller wechseln müsse. Pustekuchen.

Was steckt drin, vor allem im Unterschied zum 3B+? Die Kurzfassung: ein BCM2711 (Quad-Cortex A72@1,5 GHz), Gigabit Ethernet über einen schnellen internen Bus angebunden, USB3.0 über PCIe, Dual-Head mit je 4K@60Hz-Unterstützung (einzelne Quellen sprechen allerdings auch davon, dass im Dual-Head-Betrieb nur je 4K@30Hz möglich wären, eventuell ist das aber nur eine vorübergehende Treiberschwäche), und Modelvarianten mit 1, 2 oder 4 GiB RAM das zudem als LPDDR4-2400 ausgeführt ist. Und da man wegen der 2x microHDMI für Dual-Head-Unterstützung sowieso nicht mehr kompatibel zu den alten Gehäusen sein konnte, hat man die Stromversorgung nun auf USB Typ C umgestellt – endlich nicht mehr peilen, wie rum der microUSB-Stecker rein muss…warum man auch noch die Position von Ethernet und USB getauscht hat, erschließt sich hingegen nicht direkt, eventuell wegen der Positionierung der PoE-Pins.

Also: neues Netzteil (das offizielle Netzteil leistet 15W – durch 2x USB3 statt den bisherigen USB2 liegt allein der Stromverbrauch bei voller Auslastung durch angeschlossene USB-Geräte ja schon 800mA höher, weil USB3 900mA zusichert, gegenüber 500mA bei USB2 – irritierenderweise redet das vorläufige Datenblatt von einem Limit in Summe über alle 4 Buchsen von 1,1A – das ist so niedrig, dass ich einen Druckfehler vermute), neues Gehäuse, neue HDMI-Kabel sind angesagt. Die microHDMI-Buchsen liegen relativ nah beieinander, von einer Adapterlösung microHDMI-auf-Standard-HDMI würde ich nach erster Betrachtung eher abraten, das könnte platztechnisch eng werden.

Was kann man über die Performance sagen? Eigentlich nur Gutes. Obwohl die CPU taktmäßig nur einen kleinen Sprung gemacht hat, gilt der Cortex-A72 pro MHz als deutlich leistungsfähiger gegenüber dem vorher verwendeten Cortex-A53 im Pi 3. Grob sagt man dem Cortex-A53 etwa 2,3 DMIPS/MHz nach, dem Cortex-A72 hingegen 4,6 DMIPS/MHz. Erreicht wird das durch die üblichen Maßnahmen, die die x86-Welt seit Jahren vormacht: tiefere Pipeline, bessere branch prediction, ausgefuchsteres Out-Of-Order-Execution-Handling, mehr Parallelisierung beim instruction decoding. Und weil gleichzeitig ein Prozess-Shrink bei der Fertigung mit einfloss (28nm statt 40nm), soll der Stromverbrauch sich weiterhin in einem ähnlichen Rahmen wie bisher bewegen. Erste Messungen zeigen ähnlichen Stromverbrauch bei Volllast und etwas Höheren in Ruhe – welcher Anteil da auf die CPU entfällt, was auf den neuen Videocore VI und was auf den Rest vom Board – keiner weiß es im Moment.

Zu den CPU-Caches gibt es ebenfalls positive Details zu vermelden. Der Cortex-A72 hat 48 KiB instruction cache und 32 KiB data cache zu bieten auf der L1-Ebene, und 1 MiB L2-Cache – das ist deutlich mehr als der Cortex-A53 des RPi 3 B(+) zu bieten hatte (16 KiB I+16 KiB D-L1, 512 KiB L2). Die ersten Linux-Benchmarks zeigen einen Nettogewinn von 60-80%, was darauf hinweist, dass sowohl das schnellere RAM als auch die größeren Caches ausreichen, um die CPU-internen Fortschritte nicht über Gebühr auszubremsen.

Dadurch, dass nun das Gigabit-Ethernet endlich vom USB2 weg ist und an einen eigenen High-Speed-Bus direkt am SoC angedockt wurde, steigert sich der Netzwerkdurchsatz laut ersten Messungen nahe an das theoretische Maximum von 1 Gbit/s, während vorher eher so 300 MBit/s angesagt waren. Und vor allem kollidiert das nicht mehr mit dem USB-Massenspeicher – bisherige Pis hatten alles an einem einzigen USB-Kanal.

USB3 ist für heutige Massenspeicher wie schnelle SSDs natürlich auch ein gewaltiger Fortschritt, von theoretisch 480 MBit/s auf 4 GBit/s Durchsatz. Durch die Anbindung sowohl des USB2-Hosts und des USB3-Hosts über PCIe ist hier eine signifikante Performanceverbesserung drin. Mal sehen, was davon in der Praxis übrigbleibt, bei Konkurrenz-ARM-Boards gab es da öfter mal böse Überraschungen.

Das neue RAM-Maximum von 4 GiB ist vermutlich aus RISC OS-Sicht die unwichtigste Verbesserung – schon das eine GiB ist doch die meiste Zeit leer. Aber wer weiß, wenn es mal eine aktuelle Browser-Portierung gibt…ob RISC OS überhaupt so ohne weiteres mit den 4 GiB klarkommen wird, ist momentan noch unklar – bisher lag das Maximum bei 2 GiB. Der Preisaufschlag für 4 GiB statt 1 GiB liegt z.B. bei Reichelt Elektronik bei nicht ganz zu vernachlässigenden 21€.

Für RISC OS ebenfalls nicht so interessant, aber bei Einsatz als Mediacenter nützlich: die eingebauten Hardware-Decoder im neuen Videocore VI können nun H.265 in 4K@60Hz decodieren.

Und der Vollständigkeit halber: Bluetooth ist jetzt bei 5.0 angelangt gegenüber 4.2 beim Vorgängermodell. WLAN wie bisher – 802.11ac in der 2,4- oder 5-GHz-Variante.

Ich bin gespannt, wie die Praxis-Benchmarks unter der besonderen RISC OS-Situation aussehen werden. Es steht zu erwarten, dass die bisherigen Performancekönige Titanium und IGEPv5 zumindest CPU-technisch die Krone abgeben müssen, da deren Cortex-A15 typischerweise mit 3,5 DMIPS/MHz eingeordnet wird. Ebenso spannend, an welchen Stellen RISC OS das Gebotene wirklich ausnutzen kann – der TCPIP-Stack ist nicht bekannt für Top-Performance, mal sehen was da vom echten Gigabit übrig bleibt. USB3-Unterstützung gibt es im USB-Stack bisher noch gar nicht – umso wichtiger, dass das USB-Stack-Update-Bounty mal in die Gänge kommt. Bei Bluetooth und WLAN bleibt die Situation so traurig wie zuvor. Ob der Cortex-A72 ein paar Überraschungen bereithält, wie es beim Cortex-A53 bei einigen ARMv8-„undefined behaviour“-Dingen passiert ist, ist noch unbekannt.

Nicht unwichtig für uns RISC OSler: die Foundation sichert zu, dass der RPi 4 bis Januar 2026 „in production“ bleiben wird. Wenn das mal keine guten Zukunftsaussichten sind. Denn es wird zunehmend unwahrscheinlich, dass es bei 32bit ARM-Geräten in der Zukunft noch große Sprünge geben wird, weil der Rest der Welt mit Riesenschritten zu AArch64 wechselt. Was aus RISC OS-Sicht im Prinzip einem Wechsel auf x86 oder AMD64 entspricht.

Außerhalb der RISC OS-Welt ist der RPi nun wieder ein ernstzunehmender Kandidat für allerhand Anwendungsfälle, die zuletzt eher zur Konkurrenz abgewandert sind – vom NAS übers Mediacenter bis zum Desktop-Ersatz ist der RPi 4 nun für alle Anwendungsfälle gerüstet. Denn entscheidende Performanceschwächen wurden allesamt behoben. Es bleibt spannend.

30 Jahre Acorn A3000

2019-06-25 01:15

Vor 30 Jahren (genauer: im Mai 1989) kündigte Acorn die Verfügbarkeit des A3000 an. Im Prinzip ein abgespeckter Archimedes A310 im damals gängigen Tastaturgehäuse (auch One-Box-Design genannt) ähnlich der zeitgenössischen Homecomputer-Konkurrenz wie dem Amiga 500 oder dem Atari ST 520/1040. Gegenüber der doch recht preisintensiven Archimedes-Geräte war der angekündigte Preis von 649 britischen Pfund geradezu sensationell niedrig – gegenüber einem Amiga 500 allerdings immer noch ziemlich hoch. In Deutschland wurden angesichts des damaligen Pfundkurses nahezu unvermeidliche 2199 DM veranschlagt.

Aber es war ja kein schäbiger 16-bittiger 68000er, sondern ein „echter“ Archimedes – ARM2, 8 MHz, 1 MiB RAM. Ein „reinrassiger 32bit-RISC-Computer“, der, wie sich später herausstellte, gar nicht so reinrassig war, sondern einen sparsamen 26bittigen Program Counter sein Eigen nannte, um gleich noch 6 Flag-Bits darin unterzubringen, vermutlich um die typischerweise kritischen Interrupt-Latenzzeiten möglichst niedrig zu halten. Später fiel das Acorn (oder genauer deren Nachfolgern und den treuen Usern) auf die Füße, weil es größere Handstände beim Sprung von 26bit auf 32bit erforderte und – nach dem StrongARM-Update – die zweite große RISC OS-Software-Krise auslöste, und zum RISC OS-Split in die 26bit-Welt (RISC OS 4 und SIX) und die 32bit-Welt (RISC OS 5) führte. Aber ich schweife ab.

Wie schaffte Acorn damals diesen Kampfpreis? Durch allerhand Entfernen überflüssiger bis als weniger wichtig betrachteter Features. Beispielsweise wurde die Erweiterungsfähigkeit des A3000 gegenüber A3xx/A4xx stark eingeschränkt – statt 4 Podules konnte nur noch eines betrieben werden, und zudem stand dort nur 5V statt wie zuvor auch +/-12V zur Verfügung. Überhaupt war das ganze Design eher stromsparend ausgelegt, das Netzteil lieferte sparsame 22W. Die Floppy war 5V only, man sparte sogar am Anschlusskabel: statt den vollen 34 Polen hatte das Flachbandkabel nur 32 davon. Der serielle Port war zwar als Buchse herausgeführt, aber die beiden entscheidenden Chips (65C51 und LT1133) glänzten durch Abwesenheit und mussten ggf. nachgerüstet werden. Um auch intern Erweiterungskarten zu unterstützen, erfand Acorn kurzerhand eine 8-bit-Version der eigentlich 16-bittigen Podules und nannte sie „Mini-Podules“. Nominell konnte man die 1 MiB RAM on board nur mit einem zusätzlichen MiB auf 2 MiB erweitern. Alle Chips bis auf die genannten für die serielle Schnittstelle, die vier ROMs und der Controller für die Tastatur (ein 8051 – Intel inside!) waren eingelötet, was spätere Upgrades z.B. des ARM2 auf den ARM3 doch sehr erschwerte, zumal im Tastaturgehäuse recht wenig Bauhöhe zur Verfügung stand. Nur der Slot für die Econet-Erweiterung – der war natürlich heilig und auch im A3000 zu finden.

Serienmäßig wurde der A3000 mit dem damals fast brandneuen RISC OS 2 ausgeliefert – nach dem anfänglichen Arthur-Desaster der originalen Archimedes-Reihe ein würdiges Betriebssystem, stabil, leistungsfähig, multitaskingfähig, schnell. Erst 1992 wurde es durch RISC OS 3.10 abgelöst, mit dem der A3000 selbstverständlich aufgerüstet werden konnte.

Anno 1990 gab es dann – ungewöhnlich für Acorn in der nach-8bitter-Zeit – eine vollständig eingedeutschte Version des A3000. Deutsche Tastatur (ohne die roten Funktionstasten, die für die damaligen Acorns beinahe identitätsstiftend waren und denen noch heute gehuldigt wird http://shop.elesar.co.uk/index.php?route=product/product&path=18_63&product_id=61), deutsche Handbücher, und einige der vorwiegend englischen Softwarehäuser brachten deutsche Versionen ihrer Programme heraus. Tatsächlich war das für mich – angesichts meiner heutigen Vorliebe für die englische Sprache in allen Computerdingen überraschend – der Trigger für den Einstieg in die Acorn-Welt. Der deutsche Distributor für Süddeutschland, Anagram Systems aus München, bot einen Schülerrabatt von 200 DM an, und so fand ein A3000 in der Grundausstattung für 1999 DM den Weg in mein Computerzimmer und gesellte sich zum guten alten Schneider CPC (übrigens eine interessante Parallele – der CPC464 hatte in der englischen Variante auch eine sehr bunte Tastatur, die von Schneider für den deutschen Markt durch etwas weniger Auffälliges ersetzt wurde). Wie damals üblich kostete ein vernünftiger Monitor dazu praktisch ähnlich viel – NEC MultiSync 3D, 1333 DM. Damit war mein Budget restlos ausgeschöpft.

Weil bei 1 MiB RAM und nur mit einer 800 KiB-Floppy die Dinge oft etwas länger dauerten, konnte ich ausdauernd in den überraschend gut übersetzten deutschen Handbücher schmökern, insbesondere das BBC-BASIC-Handbuch war wirklich erstklassig. Zwei interessante Fehler in der Übersetzung sind mir im Gedächtnis geblieben: im „Welcome Guide“ ging das Ohm-Symbol verloren, und so stand neben dem 3,5mm-Kopfhörer-Anschluss der erklärende Text „Anschluss für 32 persönliche Kopfhörer“. Und im „User Guide“ stand als Erklärung für das CLI-Kommando „*spool on“: „Schaltet die automatische Spulfunktion ein“. Nicht hilfreich.

Der Spieltrieb wurde mit dem unvermeidlichen Zarch befriedigt, aber auch E-Type und Conqueror waren meine Favoriten. Ebenso Interdictor 2 und später das grandiose Spheres of Chaos. Nachdem ich mir dann die deutsche Version von Pipedream 3 von Colton Software gegönnt hatte (ein sehr intelligentes Produkt, das äußerst elegant eine Textverarbeitung mit einer Tabellenkalkulation integrierte), wurde klar, dass z.B. bei intensiver Nutzung der Outline-Fonts man mit 1 MiB RAM und Floppy nicht glücklich wurde. Und so kamen als Upgrades relativ schnell 4 MiB RAM, SCSI-Mini-Podule und 105MB-Quantum-SCSI-Platte ins Haus nebst externem SCSI-Gehäuse, das später auch noch einen leisen Canon-Lüfter verpasst bekam – echte Qualität, funktioniert heute noch. Damit konnte man arbeiten.

Während die A4xx-Modelle (A410/1, A420/1, A440/1) der Archimedes-Reihe z.B. dank der möglichen Coprozessor-Schnittstelle im Full-Features-Podule, der Unterstützung für Full-Width-Podules, MFM- bzw. ST506-Festplattencontroller on board, 4 Podule-Slots, gesockelter ARM-CPU und offizielle Erweiterbarkeit bis 4 MiB RAM sowie dem High-Resolution-Monochrom-Monitor-Modus noch ausreichend Alleinstellungsmerkmale hatte, sah Acorn für den A3xx keine Zukunft mehr – mit Erscheinen des A3000 wurde die Produktion nach knapp 2 Jahren eingestellt. Der A4xx wurde dann auch erst Ende 1991 durch den A5000 würdig ersetzt – der bereits Mitte 1990 erschienene A540 (der letzte „echte“ Archimedes), in dem der ARM3 debüttierte, war eher dem Profi-Bereich vorbehalten und war über doppelt so teuer, auch dank SCSI-Podule serienmäßig und damals unvorstellbar großer 100 MiB-Platte.

Der A3000 bekam dann schließlich im September 1992 gleich zwei Nachfolger – der A3010 zielte mit seinen zwei eingebauten Joystickports nebst HF-Modulator für den direkten Fernseher-Anschluss auf den Heimcomputermarkt, der A3020 war eher für den Schulmarkt gedacht. Es war gleichzeitig die Geburtsstunde des „SoC“: der ARM250 vereinte in einem Chip die CPU (ARM2), den Memory-Controller (MEMC), den Video-Chip (VIDC) und den IO-Controller (IOC). Aber wer es darauf anlegte, konnte den A3000 durchaus entsprechend aufrüsten, um weiter mitzuhalten: das Sockeln des ARM2 ermöglichte die Verwendung des ARM3 bis zur 36 MHz-Variante, der VIDC-Enhancer erlaubte das Hochschrauben des Pixeltakts auf 36 MHz für 800×600 Bildpunkte bei 16 Farben und 56 HZ (SVGA!), mit der Möglichkeit eines externen echten Podules war die Erweiterbarkeit sogar besser als beim A3010 und A3020 (beispielsweise mit einem schnellen SCSI-Podule), und die Econet-Schnittstelle wurde für allerhand Erweiterungen vom Sound-Sampler über ein SCSI-Interface bis zum Joystick-Interface zweckentfremdet. Wer löten konnte, konnte gar die DD-Floppy auf HD aufrüsten – WD1772 gegen ein höher taktbares Exemplar tauschen, Taktfrequenz verdoppeln, ein wenig Software-Magie, und natürlich eine HD-fähige Floppy – fertig. Dazu gab es für mehr CPU-Bumms das Turbo-Upgrade von Ingmar Weigel http://legacy.huber-net.de/TurboA3000.zip, das es erlaubte, den ARM2 nebst dem RAM-Bus auf bis zu 16 MHz hochzuschrauben, sofern es RAM und auch die ROMs vertrugen. 12 MHz ging aber immer, 13,3 MHz fast immer. Das war nicht nur für die reine CPU- und RAM-Geschwindigkeit gut, sondern erlaubte auch das erheblich bequemere Arbeiten bei hohen Auflösungen oder Farbtiefen, da die CPU nicht ständig durch das Video-DMA ausgebremst wurde. Anno 1992 kam mein erster Laserdrucker dazu, zusammen mit dem CC TurboDriver und CCs Impression Style DTP-Software konnte man damit richtig seriöse Dokumente erstellen.

Der mir bekannte Maximalausbau des A3000 bestand aus einem auf 40 MHz übertakteten ARM3, VIDC-Enhancer, Turbo-A3000-Upgrade mit 16 MHz, HD-Floppy-Umbau, Gamer’s Upgrade (ein 4-Joystick-Port-Ausbau, der sich an den I2C-Bus ankoppelte und damit keine der wertvollen „offiziellen“ Schnittstellen belegte), Econet, 4-Podule-Backplane mit nachgelöteter Decoder-Logik für den gleichzeitigen Betrieb aller Podules, gesockeltem MEMC und 8 MiB-RAM-Upgrade. Dieser Über-A3000 wohnte dann allerdings in einem handgedengelten Tower-Gehäuse, denn im Tastaturgehäuse war schlicht nicht ausreichend Platz für all diese Upgrades. Und die Hauptplatine war weit gereist: der Besitzer wohnte in Holland, er hatte mir damals das Board geschickt für den Umbau für das Turbo-Upgrade, dann ging es nach England zu Simtec für das Sockeln von ARM2 und MEMC und Einbau des 8 MiB-Upgrade, das eigentlich für den A4xx bestimmt war, und wieder zurück nach Holland.

Mein eigener A3000 war dagegen fast schon konventionell aufgerüstet: Selbst gelötetes Turbo-Upgrade auf 13,3 MHz, selbst gelöteter VIDC-Enhancer, 4 MiB RAM (es stellte sich bald heraus, dass Acorn mit dem „2 MiB RAM max“ geflunkert hatte und alle Signale für ein 4-MiB-Upgrade an der RAM-Expansion-Stiftleiste verfügbar waren), LogikJoy-2-Port-Joystick-Interface im Econet-Slot, HCCS-SCSI-Mini-Podule, Serial Upgrade, und schließlich das Dual Serial Podule mit zwei 16550er für anständige Geschwindigkeiten am seriellen Port, denn der serienmäßige 6551 schaffte nur schäbige 19200 Baud, für die gerade anbrechende ISDN-Zeit definitiv zu wenig. Das Podule leistete auch später im Risc PC noch gute Dienste, denn wem reichte schon ein einziger serieller Port? Das HD-Floppy-Upgrade hatte ich zwar geplant und auch alle notwendigen Bauteile beschafft, aber nie durchgeführt. Meine ersten Schritte im Internet habe ich auch mit dem A3000 gemacht, mit einem 2400bps-Modem über einen Einwählzugang an der Uni Stuttgart nebst selbstgedengeltem SLIP-Dialler. Für Telnet und FTP waren 2400bps gerade noch so erträglich, und mein Hauptaugenmerk lag damals DFÜ-technisch noch im Fido-Netz, wo ich dank Binkley und FidoMail einen Fido-Point bei der Piraten-Box von Alexander L. Kastl betrieb.

Erst 1995 wurde mein A3000 durch einen Risc PC 700 abgelöst, als das RAM zu eng, die CPU zu langsam und die Grafik zu schwach wurde. Und die langsam übermächtige Konkurrenz aus der PC-Welt schien durch die PC-Karte durch den Risc PC elegant mit RISC OS vereinbar, das ich inzwischen doch liebgewonnen hatte. Aber das ist eine andere Geschichte – hier gibt es den passenden Artikel zur Würdigung des Risc PC zu seinem 25-jährigen Jubiläum http://riscosblog.huber-net.de/2019/04/25-jahre-acorn-risc-pc/.

25 Jahre Acorn Risc PC

2019-04-20 20:45

Vor 25 Jahren (genauer: am 1994-04-15) kündigte Acorn den Risc PC an, eine neue Generation Hardware nach dem Archimedes (A3xx/A4xx/A540/A3000) und der A-Serie (A3010/A3020/A4000/A5000/A4). Mit stark verbesserten Grafikfähigkeiten (z.B. TrueColour-Unterstützung, bis zu 2 MiB VRAM), bis zu 256 MiB RAM, verbessertem Betriebssystem (RISC OS 3.50) und zukunftsfähiger Architektur – CPU auf einer Steckkarte (zu Anfang ein 30 MHz ARM610), zweiter CPU-Steckplatz für eine zum damaligen Zeitpunkt für Q4/1994 angekündigte PC-Karte („zwei Computer in einem“) und einem innovativen Gehäusekonzept, das eine modulare Erweiterung (quasi scheibchenweise – englische Bezeichnung: „Slice“) ermöglichte. Beim angedachten Maximalausbau mit 4 Slices war Platz für 4 5,25″-Laufwerke und 5 3,5″-Laufwerke nebst 8 Erweiterungskarten („Podules“) und einer Netzwerkkarte („NIC“).

Ungewöhnlich für die damalige Zeit, und vermutlich eine vorbeugende Maßnahme gegenüber eventuellen Unkenrufen, dass das wieder enden würde wie beim A540, der bekanntlich auch eine CPU-Karte hatte, aber nie ein Upgrade dafür bekam: Acorn garantierte bereits damals Upgrade-Preise für zukünftige CPUs wie den ARM700 und den ARM800. Letzterer erschien nie, weil durch glückliche Fügung bereits 1996 der DEC StrongARM mit phantastischen 200 MHz zur Verfügung stand und als das vermutlich beste Performance-Update eines Computers überhaupt in die Geschichte einging.

Die originalen Pressemitteilungen aus dieser Zeit ist immer noch bei Google Groups nachlesbar: Acorn Risc PC Press Releases​

Ein echtes Zeitdokument findet sich auch auf YouTube mit der Video-Aufzeichnung des „Launch Events“ in London am 1994-04-16: Acorn Risc PC Launch – 16th April 1994

Obwohl schon fertig, hatte Acorn auf der CeBIT 1994 im März den Risc PC nur der Fachpresse im Hinterzimmer gezeigt – die Jungs von ARM wussten das aber nicht und hatten einen Medusa-Prototyp auf ihrem Stand, den Eingeweihte trotz ungewöhnlichem Gehäuse sofort als den kommenden Risc PC identifizieren konnten (ohne den Namen damals zu kennen) – an der Masse der Besucher ging dieses Kleinod aber natürlich komplett vorbei. Stattdessen wurde der Risc PC auf der international unbedeutenden Education-Messe in Harrogate der „breiten“ Öffentlichkeit zum ersten Mal präsentiert. Eine weitere Kuriosität in der langen Geschichte der „epic marketing fails“ seitens Acorn.

Kritik regte sich recht schnell bezüglich diverser Details jenseits der üblichen Einschätzung „zu wenig für zu viel Geld“ im Angesicht der berüchtigten Sparsamkeit Acorns bezüglich Hauptspeicher- und Festplattengrößen:

  • Der ARM610 mit sparsamen 30 MHz und weiterhin 4 KiB Cache war eher langsamer als sein Vorgänger ARM3, der in Spezialversionen auf bis zu 36 MHz getrieben wurde.
  • Das 2 MiB-VRAM-Maximum schien damals schon etwas knapp, denn es limitierte die mögliche TrueColour-Auflösung auf 800×600, was auf 1994 bereits gängigen 17″-Monitoren etwas schmal wirkte.
  • Dazu die Entscheidung, zwar tastaturtechnisch auf PS/2 zu wechseln, aber beim zunehmend merkwürdig anmutenden Busmaus-Anschluss zu bleiben.
  • Die Tatsache, dass die PC-Karte erst rund neun Monate später kommen sollte (tatsächlich wurde es schließlich April 1995, bis die ersten Exemplare in Kundenhand waren).
  • Die Frage, ob das doch relativ lahmelige RAM (16 MHz effektiver Systemtakt, 32bittige Anbindung) zukünftigen CPUs und vor allem dem propagierten Mehrprozessorbetrieb gewachsen sein würde.
  • Die doch recht sparsamen neuen Features in RISC OS 3.50, das insgesamt gegenüber dem fast schon drei Jahre alten RISC OS 3.10 kaum mehr als Anpassungen an die neue Hardware beinhaltete – das weckte durchaus Zweifel bezüglich der Fähigkeit Acorns, die bitter notwendigen Nachrüstungen am OS einigermaßen zeitnah vorzunehmen – verstärkt wurde das noch, als Windows 95 erschien, OS/2 beinahe schon im Massenmarkt etabliert war und Apple mit dem PowerPC auf eine leistungsfähige CPU umschwenkte.
  • Das einkanalige IDE auf dem Motherboard, vor allem nachdem durchgesickert war, dass die Medusa-Prototypen SCSI on board hatten.
  • Nur eine serielle Schnittstelle, obwohl der verbaute Multi-IO-Chip zwei davon intus hatte.
  • Die eher sparsam aufgerüstete Podule-Schnittstelle, die nun bei theoretisch 8 MiB/s (in der Praxis eher 6,5 MiB/s) ihr Maximum weit unter damals verfügbaren ISA-Busmaster-DMA-Karten erreichte, von VLB und PCI ganz zu schweigen.
  • Das schwächliche Netzteil, das der Erweiterbarkeit des Gehäuses nicht angemessen schien.
  • Die praktisch unveränderten Soundfähigkeiten (8-Kanal 8-Bit), obwohl der neue VIDC20 16bit-Sound unterstützte (das wurde später durch recht preisgünstige Upgrades korrigiert).
  • Und wieder kein Floating Point-Coprozessor standardmäßig, ja nicht mal eine CPU mit Coprozessor-Bus zur späteren Aufrüstung (das wäre der ARM600 gewesen).
  • Angesichts der möglichen 256 MiB RAM im Vollausbau wurde auch langsam klar, dass der 26bit-Adressmodus mit seiner Limitierung der Programmgröße auf 28 MiB aufgrund der althergebrachten RISC OS-Memory-Map ein Ding der Vergangenheit war – eventuell wäre es besser gewesen, schon damals den Schnitt hin zu den echten 32bit-Prozessormodi zu machen, aber Manpower war knapp und die Rückwärtskompatibilität aufgrund der Verankerung im Education-Bereich fast schon heilig, und die nicht vorhandene CPU-Mehrleistung machte eine Emulationslösung unattraktiv.

Was in Summe dazu führte, dass für einen A5000-Besitzer, womöglich gar mit FPA, 8 MiB RAM und Colour Card Gold, der Risc PC kaum eine Überlegung wert war.

Und der Preis war natürlich auch immer ein Thema, aber im Angesicht der PC-Karte für 99 UKP – damals etwa 250 DM, der Pfundkurs war deutlich günstiger für uns Deutsche als noch Anfang der 90er – relativierte sich der anspruchsvolle Preis etwas, denn schließlich kaufte man ja quasi zwei Computer in einem, einen mit RISC OS und einem mit DOS und Windows. Und einen Computer mit eingebauter Zukunftsfähigkeit.

Mein eigener Einstieg in die Risc PC-Welt – seit 1990 hatte ich einen A3000, aufgerüstet mit 4 MiB RAM, RISC OS 3.10 und SCSI – begann 1995 mit der zweiten Generation, dem Risc PC 700 mit 40 MHz ARM710, RISC OS 3.60 und der PC-Karte von Anfang an. Ein sehr rundes Gerät, die CPU deutlich schneller vor allem dank 8 KiB Cache, das RISC OS deutlich abgerundet und mit allen entscheidenden Dingen von CDFS über TCP/IP-Stack bis zu den Toolbox-Modulen und dem Draw/Paint/Edit-Triumvirat im ROM. Ein riesiger Fortschritt gegenüber dem A3000.

RISC OS-technisch wurde der Risc PC erst 2002 durch einen Castle IYONIX pc ergänzt und läuft bis heute ganz prima. Ein beständiges und letztlich im wahrsten Sinne des Wortes preiswertes Stück Hardware, aufgerüstet über die Jahre bis an die Zähne mit 287 MHz StrongARM, 128 MiB RAM, RISC OS 4.29 (aka „Select 1“), IDE-Podule, SCSI-Podule, ViewFinder-Grafikkarte, Dual-Serial-Podule und 100 MBit-Ethernet-NIC.

Edit 2019-05-15: peinlichen Schreibfehler korrigiert, den ich erst in gedruckter Form in der neuen GAG-News gesehen habe 🙁

ADFFS 2.72 (auch via PackMan) verfügbar

2019-03-02 16:10

Jon Abbott vom JASPP hat heute (yeah, brandaktuelle News in meinem bescheidenen Blog!) die Verfügbarkeit von ADFFS 2.72 verkündet. Wieder stand die Stabilität im Vordergrund, ebenso Abrundungen bezüglich Kompatibilität. Auch DOS- und Atari-Images können nun gelesen werden. Als neu unter RISC OS 5 unterstützte Spiele kamen Sim City 2000 und Burn’Out dazu. Vor allem das saubere Beenden von Spielen unter ADFFS-Kontrolle per Ctrl+Shift+F12 funktioniert nun in viel mehr Fällen. Ebenso werden nun Abstürze im Spielecode, während der ADFFS-JIT aktiv ist, sauber abgefangen um einen sauberen Systemzustand nach dem kontrollierten Beenden des gecrashten Spiels sicherzustellen.

Auch die Unterstützung für WIMP-basierte Spiele hat Fortschritte gemacht, ist aber noch lange nicht rund, wie Jon nicht müde wird zu betonen. Und eine merkwürdige Unverträglichkeit mit StrongEd wurde behoben.

Wie seit 2.69 üblich ist auch 2.72 über PackMan verfügbar, ebenso die bisher unter JASPP-Flagge re-releasten Spiele-Klassiker.

Aufmerksame Beobachter fragen sich jetzt, wo denn Version 2.71 geblieben ist? Jon sind schlicht die Buchstaben ausgegangen – er „nummeriert“ die Entwicklungsversionen nach dem Muster 2.71a..2.71z durch, und nach 2.71z kam eben 2.72a, und erst mit 2.72k war Jon glücklich, woraus dann die jetzt veröffentlichte 2.72-Release-Version entstand.

Wieder nix in 2018, neuer Versuch in 2019

2018-12-23 19:52

2018 neigt sich dem Ende, und im Jahresendspurt passiert erfahrungsgemäß vor lauter anderen Verpflichtungen eher wenig. Nachfolgend die Liste der Softwareprojekte, die ich „eigentlich“ in 2018 erledigen wollte, die aber weiter ihrer Finalisierung harren. Oft fehlen nur Kleinigkeiten, oder „nur noch das letzte Feature“, oder etwas Feinschliff.

CDVDBurn

Der Klassiker gleich zu Anfang. Das letzte offizielle Release, Version 2.02b (auch wenn als Beta gelabeled), war Feburar 2007. Seither plane ich ein neues Release. Was ist seither passiert? DVD-RAM kann geschrieben werden. Blu-Ray kann als BD-R und BD-RE geschrieben werden. Ein Extraktor ist nun integriert, mit dem man unabhängig von CD(ROM)FS Daten-CDs/DVDs/BDs anschauen kann und Dateien extrahieren kann, inklusive Unterstützung für Joliet und ein Subset der Rockridge-Extensions (soweit unter RISC OS sinnvoll). Dazu wurde die Lauffähigkeit unter ARMv7 und ARMv8 sichergestellt (ein echtes Abenteuer mit dem uralten Ada-Compiler). USB-Unterstützung für RISC OS 5 ist an Bord, ebenfalls S-ATA-Unterstützung fürs neue ADFS (z.B. auf Titanium und IGEPv5).

Ich hatte die Hoffnung, auf zumindest einem gängigen USB- und S-ATA-Laufwerk das DVD-R-Schreiben hinzukriegen, bin aber gescheitert. Einen Versuch habe ich mir noch vorgenommen (Incremental Writing statt DAO/TAO mit reserved track), und dann wird endgültig released, egal ob mit oder ohne DVD-R-Unterstützung. Dual-Layer-Unterstützung für BD-R und BD-RE wäre auch noch schön. Das Update wird kostenpflichtig werden, ich hatte einige Investitionen in Laufwerke und andere Hardware.

TapirMail

David Llewellyn-Jones hat 2018 den Sourcecode für TapirMail auf GitHub freigegeben. Mein Plan war, den Sourcecode etwas aufzuräumen, mit aktueller OSLib und aktuellem GCC und DDE baubar zu machen (so richtig mit Makefile und so…) und dann per Pull-Requests die weitere Entwicklung voranzutreiben. Beispielsweise die Unterstützung für Secure POP3/SMTP, und ggf. auch IMAPS. Da bin ich mittendrin steckengeblieben – bauen tut alles, aber Weiterentwicklung ist nicht geschehen, und ich stecke noch in den Überlegungen, wie so ein RISC OS-Projekt unter GitHub anständig strukturiert sein sollte. Jetzt, mit Jeffreys Git-Client (oh, darüber wollte ich ja auch noch bloggen…), ergeben sich da neue Möglichkeiten.

Isofier

Aus der Reihe „Java-basierte Software für RISC OS, aber nicht unter RISC OS“: ein ISO9660/Joliet-Image-Erzeuger. Die Kommandozeilenvariante funktioniert prächtig, das grafische UI nicht so wirklich. Die Besonderheit ist die volle Unterstützung für die HostFS-Implementierungen von RPCEmu und VirtualRPC, es werden also die Filetype-Extensions automatisch in CDFS-Extensions gewandelt, unter Berücksichtigung der VRPC-extensions-Konfiguration und einer MimeMap-Datei.

ImageTransformer

Aus der Reihe „Java-basierte Software für RISC OS, aber nicht unter RISC OS“: ein Konverter für das CDVDBurn-Fake-Image-größer-als-2-GiB-Format. In beide Richtungen natürlich. Nützlich, um unter RISC OS erzeugte Images dann auf dem PC brennen zu können, oder auf dem PC erzeugte Images (z.B. mit oben genanntem Isofier) unter RISC OS brennen zu können.

SpriteConverter/SpriteViewer

Aus der Reihe „Java-basierte Software für RISC OS, aber nicht unter RISC OS“: SpriteConverter ist ein Kommandozeilentool zur Konvertierung einer Sprite-Datei (also allen oder einzelnen Sprites darin) in PNG, JPEG, GIF oder was auch immer als Java ImageIO-Plugin zur Verfügung steht. SpriteViewer setzt auf demselben Code auf und zeigt in einer grafischen Oberfläche den Inhalt einer Sprite-Datei an, einmal in einer !Paint-artigen Übersicht, dann aber auch per Doppelclick in Originalgröße mit Zoommöglichkeit und Palette. Man kann einzelne Sprites daraus auch direkt als PNG, JPEG oder GIF exportieren. Geplant als kostenlose Software.

ArchiveViewer

Aus der Reihe „Java-basierte Software für RISC OS, aber nicht unter RISC OS“: eine grafische Oberfläche zur Anzeige der Inhalte typischer RISC OS-Archivdateien wie Spark, ArcFS, PackDir, Squash und ZIP, mit voller Filetype-Unterstützung. Basiert hauptsächlich auf der großartigen Vorarbeit namens riscosarc von James Woodcock. Geplant als kostenlose Software.

BBC BASIC Detokenizer

Aus der Reihe „Java-basierte Software für RISC OS, aber nicht unter RISC OS“: ein kleines Tool, um tokenisiertes BBC BASIC V/VI in plain text umzuwandeln. Mit oder ohne Zeilennummern. Geplant als kostenlose Software.

FilecoreImageReader

Software, um Sprites zu lesen, um Archive zu lesen, um BBC BASIC zu lesen…wofür das alles? Auslöser war der vorerst letzte Teil aus der Reihe „Java-basierte Software für RISC OS, aber nicht unter RISC OS“: ein mächtiges Werkzeug, um Filecore-Images (.adf, .hdf) anzuschauen und Dateien und/oder Verzeichnisse daraus zu extrahieren. Unterstützt D, E(+) und F(+)-Format, minimaler Speicherverbrauch auch bei riesigen Images. Anzeige des Verzeichnisbaumes mit den „echten“ RISC OS-Icons. Anzeige der Inhalte von Sprite-Dateien, Archiv-Dateien, Plain-Text-Dateien und BASIC-Dateien (andere Dateitypen werden in einer Hexdump-View angezeigt). Im Moment baue ich gerade echte Acorn Latin 1 Codepage-Unterstützung, um sowohl die Plain-Text-Anzeige als auch die Konvertierung der Dateinamen besser hinzukriegen. Und ich hätte gerne eine Filer-like-Ansicht für einige Inhalte, damit das eleganter aussieht. Und es gibt noch irgendwo einen Bug, der bei einem Disc-Image das mir vorliegt bei, Scannen der Verzeichnisstruktur in eine Endlosschleife gerät. Mindestens das Erkennen der Endlosschleife mit sauberem Abbruch des Lesevorgangs wäre Voraussetzung für ein baldiges Release. Außerdem würde ich gerne automatisch die !Sprites-Dateien von Apps direkt zur Visualisierung verwenden.

Ein Projekt wie FilecoreImageReader ist natürlich in ständiger Gefahr, dem „Feature Creep“ zu erliegen. Man könnte doch bekannte Filetypes aus der PC-Welt auch noch direkt als Inhalt anzeigen (Grafikformate, PDF, PostScript…). Und generell die UI Filer-like machen. Und noch ein RISC OS-artiges Look&Feel für Swing bauen. Und eine Anzeige von Draw-Files ermöglichen. Und Templates. Und Impression…und Artworks…

Auf jeden Fall wird es eine kostenpflichtige Version mit all den coolen Features geben, und eine freie Version wo man nur den nackten Verzeichnisbaum mit Extraktionsmöglichkeit hat, möglicherweise auch limitiert auf Floppy-Images.

PipeDream 4.56 verfügbar

2018-12-22 17:24

Stuart Swales hat die Verfügbarkeit von PipeDream 4.56 verkündet (inzwischen durch 4.56.01 mit minimalem Bugfix ersetzt). Genauere Details kann man der länglichen Release-Historie entnehmen. Interessanterweise sind – neben den unvermeidlichen Bugfixes – einige UI-Änderungen in Richtung Style-Guide-Compliance eingeflossen. PipeDream war da schon mindestens seit Version 3 (die erste, die ich selbst benutzt habe) im Detail doch häufig abweichend von dem, was unter RISC OS so gängig war. Vom Save/Discard/Cancel-Dialog bis zu den Feinheiten des Save-As-Fensters.

Schön auch, dass die genutzten Ressourcen nun sprach-/ländertechnisch sauber separiert wurden, was eine deutsche Version stark vereinfachen würde. Nur die Älteren werden sich erinnern, dass PipeDream 3 zu RISC OS2-Zeiten eine der wenigen Anwendungen war, die komplett auf Deutsch verfügbar war. Aber dann eben nur auf deutsch, der geneigte Benutzer konnte nicht für die englische Originalversion optieren. Aus dieser Zeit stammt auch noch das rudimentäre deutsche Wörterbuch für die Rechtschreibprüfung.

RISC OS 5.26 und NOOBS

2018-12-22 16:54

Um einen sauberen Release-Stand unter der neuen Apache-Lizenz zu haben, ohne gleich das ganz große Release-Rad drehen zu müssen, hat RISC OS Open Ltd. kurzerhand die Version 5.24 als 5.26 neu released. Codetechnisch hat sich nichts verändert, nur die eine oder andere Lizenzdatei wurde angepasst. Konsequenterweise sind damit ab sofort auch alle Development-Versionen bei 5.27 angekommen. Damit entsteht nun die potenziell verwirrende Situation, dass RISC OS 5.25 weiter fortgeschritten war als RISC OS 5.26, aber das wird die überschaubare RISC OS-Community wohl gut verkraften können.

Eine Möglichkeit, auch auch auf dem recht neuen Raspberry Pi 3 A+ (wofür auch immer der im RISC OS-Universum gut sein soll – ein paar Euro weniger auf Kosten von USB-Anschlüssen und Ethernet?) die Version 5.26 einfach mal auszuprobieren ist seit einiger Zeit auch wieder die NOOBS-Distribution. Nach längerer Pause ist hier RISC OS neben zig Linux-Varianten wieder mit von der Partie.

Wer es nicht weiß: NOOBS (ein Akronym für „New Out Of the Box Software“) wird von der Raspberry Pi Foundation als Multi-OS-Installer für den schnellen Wechsel verschiedener Betriebssysteme angeboten, ideal für Pi-Einsteiger zum Ausprobieren verschiedener Varianten. Für dauerhafte RISC OS-Nutzung ist NOOBS aber nicht zu empfehlen, weil RISC OS die Filecore-Parition nicht einfach erweitern kann (und Filecore zudem nur eine Partition unterstützt) und man daher größere SD-Karten platztechnisch nicht ausnutzen kann. Da ist der Weg über SystemDisc und HForm weiterhin der bessere.

ADFFS 2.70 (auch via PackMan) verfügbar

2018-12-22 16:22

Jon Abbott vom JASPP hat (schon vor einiger Zeit) die Verfügbarkeit von ADFFS 2.70 verkündet. Hauptsächlich Bugfixes fanden Einzug, damit funktionieren nun auch einige weniger populäre Spiele neueren Datums wie „DragonBall“, „Sally und Wally“ oder die StrongARM-kompatible Version von „Saloon Cars Deluxe“ aus dem Jahr 2000.

Wie schon 2.69 ist auch 2.70 über PackMan verfügbar, ebenso die bisher unter JASPP-Flagge re-releasten Spiele-Klassiker.

ISO-Images können nun direkt aus ADFFS erzeugt werden – das muss ich dringend mal testen. Leicht verbessert zeigt sich die Integration von USBJoystick, die ich leider immer noch nicht getestet habe. Aber demnächst bestimmt…

Jon arbeitet bereits an 2.71, das verbesserte Unterstützung für Spiele, die zunächst ins WIMP starten, mitbringen soll. Aldebaran, Elite, Karma, Sim City…da sind ein paar interessante Kandidaten dabei. Ist aber aufgrund der Art und Weise, wie ADFFS die Emulation implementiert, eine ziemlich harte Nuss zu knacken, weil man sich um die ganze WIMP-Environment-Handler-Grütze kümmern und mit anderen Anwendungen friedlich koexistieren muss.

RPCEmu 0.9.1 ist da

2018-12-22 16:08

Ich muss noch ein paar aktualisierte Versionen nachliefern, beginnend mit dem Emulator der Herzen, dem RPCEmu.

Vor kurzem wurde die Version 0.9.1 veröffentlicht. Hauptsächlich Feinarbeit und kleinere Bugfixes prägen das Changelog. Der Netzwerk-Pseudo-Podule-Treiber wurde nun besser integriert, ist 26/32bit-neutral und SharedCLib-neutral und kann deshalb problemlos per Podule-Loader ohne explizites Softloading ins System gebracht werden. Etwas später wurden auf der Mailingliste noch Patches gereviewed, um unter MacOSX die Tastaturunterstützung wieder sauber zu ziehen, da gab es bei der Umstellung von Allegro auf Qt ein paar Verwerfungen. Eventuell sind die Patches auch hilfreich für die RISC OS-Portierung von RPCEmu, die mal experimentell von Chris Gransden durchgeführt wurde – dort haperte es auch an der Tastaturunterstützung.

Bei meinen Versuchen unter Linux bin ich letztens gescheitert beim Versuch, das Netzwerk wie hier beschrieben einzurichten – die chown-root-Methode funktioniert mit der von mir verwendeten Qt-Version nicht mehr, Qt lehnt das Starten der Anwendung mit Root als Owner schlicht ab. Es zeichnet sich allerdings ab, dass eine alternative Netzwerk-Lösung seinen Weg in den RPCEmu finden könnte, auf Basis von Slirp, das auch von QEMU und VirtualBox verwendet wird. Das wäre dann die lang ersehnte „zero config“-Variante, mit der sich RPCEmu direkt in das Netzwerk der Hostmaschine integrieren könnte, ganz ohne Tunelling und Bridging und das ganze unhandliche Gedöns. Wir hoffen weiter!