Hubersn

ADFFS 2.62 verfügbar

2017-08-26 18:57

Man mag mir meine kurze Blog-Abstinenz verzeihen, ich hatte kurzfristig mit einem entzündeten Schleimbeutel im Ellenbogen zu kämpfen. Zum Wiedereinsteig gibt es natürlich nichts besseres als ein altes Lieblingsthema von mir: ADFFS.

Gar nicht lange nach 2.61 hat Jonathan Abbott heute die Verfügbarkeit von Version 2.62 verkündet.

Es kehrt mehr Benutzerfreundlichkeit ein – ADFFS ist nicht mehr länger auf ein aktives SparkFS angewiesen, um die JFD-Images zu lesen, die technisch ja nichts anderes als ZIP-Archive sind. Das ist in vielerlei Hinsicht positiv – viele Problemmeldungen von Benutzern hatten mit nicht aktivem SparkFS zu tun, d.h. Jon hat jetzt weniger Arbeit beim Support. Zudem ist es speichertechnisch vor allem auf den alten Maschinen ein Segen, obwohl SparkFS jetzt kein ausgewiesener Speicherfresser war. Aber bei einem typischen Maximum von 4 MiB RAM zählt jedes Byte.

Weitere Verbesserungen im Detail beziehen sich vor allem auf die Kompatibilität mit neuesten RISC OS 5.23 Nightly Builds, wo es ja erneut Änderungen am Handling der Zero Page gab (Beitrag folgt noch). Bugfixes für einige Spiele sind auch inklusive, z.B. für Stunt Racer 2000 sowie einem Spiel, das m.W. in Deutschland immer noch nicht genannt werden darf.

Also: 2.62 runterladen und Spaß haben. Nicht vergessen: auf den Pis muss EDID deaktiviert werden, damit die GPU das Scaling übernimmt.

Neues vom ROOL-Repository

2017-07-12 23:26

Immer wieder habe ich ein Auge auf das ROOL-CVS-Repo, weil man dort aus den Commit-Kommentaren und den geänderten oder hinzugefügten Sources recht gut ablesen kann, wo in der RISC OS-Welt (m Sinne von Kern-OS) gerade Hand angelegt wird.

Aktuell wird am Filecore nebst ADFS und HForm rumgeschraubt, um idlen auf 21 Bits zu erhöhen. Damit kann man dann die maximal erlaubte Anzahl von Objekten in einer Filecore-Partition hochschrauben, was es wiederum erlaubt, bei gleicher Partitionsgröße die LFAU etwas kleiner zu wählen, was wiederum die Platznutzung vor allem bei vielen kleineren Dateien (und was würde RISC OS mehr auszeichnen als die Vielzahl kleiner Dateien – nicht nur die !Run- und !Boot-Skripte sind sehr klein, sondern auch !Sprites und !RunImage und leider oft auch !Help – ich spreche aus Erfahrung) deutlich verbessert. Allerdings wird die Map auch wieder entsprechend größer.

Es scheint auch etwas in Richtung USB3-Unterstützung zu geschehen, am XHCI-Treiber wird gearbeitet. Ab und an sind auch Einsprenkel aus den Arbeiten rund um die Multicore-Unterstützung zu sehen. Und sogar der gute alte Maestro hat eine Pflegekraft gefunden. Wohl nur Teilzeit, aber immerhin.

Auch die Access-Einbindung in OmniClient könnte demnächst ein Comeback feiern – wenn ich mich recht erinnere, lagen die Rechte für den Code bei einer anderen Firma, offensichtlich hat man sich da nun geeinigt.

Es gibt nun ein BASICVFP-Modul, quasi ein BASIC64 mit VFP statt FPE.

Zuletzt wurde noch ein interessanter Bug im EDID-Umfeld gefixed – die Bootsequenz kam zum Erliegen mit einem bösen Absturz, wenn man keinen Monitor angestöpselt hatte bzw. dieser keine sinnvollen EDID-Daten zurücklieferte (z.B. EDID-Infos mit Länge 0, was laut Standard wohl valide ist). Es gibt jetzt einen sicheren Fallback in Form des klassischen Mode 27 – quasi wie beim PC-BIOS.

ADFFS 2.61 verfügbar

2017-07-07 23:50

Ein gutes halbes Jahr ist vergangen seit dem Release von Version 2.60, und so hat Jonathan Abbott nach zahllosen Verbesserungen und Bugfixes heute die Verfügbarkeit von Version 2.61 verkündet.

Hauptänderung ist die Verwendung eines 26bit-BASIC-Moduls unter JIT-Kontrolle anstatt des bisherigen Ansatzes, das Original Maschinen-BASIC zu patchen. Außerdem wurden viele der Patch-Skripte verbessert, so dass nun eine ganze Reihe Spiele problemlos auf dem Pi laufen – Highlights sind hier sicherlich die StrongARM-Versionen von Chocks Away Compendium und Stunt Racer 2000, sowie Syndicate+ und X-Run.

Also, runterladen und ausprobieren. Läuft inzwischen auf jedem Pi inklusive des ARMv8-RPi 3. Man muss eigentlich nur beachten, dass bei zu neuen RISC OS-Versionen die Umschaltung der Auflösung weiterhin von der Pi-GPU übernommen wird, damit AnyMode sein Werk tun kann. Dazu braucht es die Zeile disable_mode_changes in der CMDLINE.TXT im Pi-Bootloader. Besitzer eines klassischen Archimedes müssen sich um solche Feinheiten natürlich nicht kümmern, dürfen zum Ausgleich aber lange Ausschau nach einem funktionierenden Monitor halten.

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

2017-05-21 17:34

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

Arcade BBS – A Blast From The Past

2017-05-17 23:56

Wer schon etwas länger in der RISC OS-Szene dabei ist, und Anfang der 1990er schon im Besitz eines Modems war, dem ist vermutlich die Arcade BBS noch ein Begriff. In den unendlichen Weiten des Fidonets gab es für Acorn-Benutzer im Prinzip drei Hauptanlaufstellen: “The World of Cryton” von Hugo Fiennes (früher bekannt für ARCterm und ARCbbs sowie Inhaber der Firma “The Serial Port”, später dann für den ersten MP3-Player für den Standard-DIN-Schacht eines Autos namens Empeg, noch später bei Apple mit dem iPod zugange, dann bei Google, inzwischen im IoT-Bereich aktiv), “Arcade BBS” von den beiden Daves (David Dade und David Coleman), und ARCpool von Stefan Brück, beheimatet in Wolfsburg. “Mailbox” war der deutsche Begriff für diesen entfernten Vorläufer von Servern im Internet, “BBS” der englische – “Bulletin Board System”.

Die Arcade BBS ist immer noch ein reicher Fundus an Software aus der großen RISC OS-Zeit Anfang/Mitte der 90er und damit ein Eldorado für Classic-Computing-Fans. Im Gegensatz zu anderen Mailboxen hat die Arcade BBS über all die Jahre den Aufstieg des Internets überlebt und sich in die Infrastruktur des Internets integriert – FTP- und Telnet-Zugang standen zur Verfügung.

Der Internetanschluss der Arcade BBS war über Demon Internet realisiert – Demon war früher in England einer der typischen Dienstleister mit starkem technischem Hintergrund, kein Massenhoster mit dicken Leitungen und großen Rechenzentren, sondern echte Experten mit liebevoll gepflegter Infrastruktur und einem offenen Ohr für Randgruppen aller Art. Das ist nun seit einigen Jahren und der Übernahme durch Vodafone Geschichte, die meisten RISC OSler sind längst woanders gelandet, und nun auch die Arcade BBS. Die alte URL ist nicht mehr erreichbar.

Aber: alles neu macht der Mai. Die Arcade BBS ist ab sofort unter http://www.arcade-bbs.net/ erreichbar. Oder per Telnet: telnet.arcade-bbs.net. Oder per FTP ftp://ftp.arcade-bbs.net/.

Viel Spaß bei einem Trip in die gute alte Zeit.

2 TiB auf einer FileCore-Partition

2017-04-21 21:00

Limits von Hardware und Betriebs- sowie Dateisystemen haben in der IT eine lange Tradition. Die 32MiB-pro-Partition-Grenze von alten DOS-Versionen (ich glaube bis Version 3.2). Die 504MiB-Grenze der alten PC-BIOSe. Die 512MiB-Grenze von FileCore bis einschließlich RISC OS 3.5. Die 256GiB-Grenze von RISC OS ab 3.6. Die “DMA nur bis 128GiB”-Grenze des IYONIX pc wegen der ALi-Southbridge. Dazu die LBA28/40/48-Problematik.

ROOL hat angekündigt, dass ab demnächst die neue Grenze 2 TiB pro FileCore-Partition sein wird. Das geht ohne Änderung der internen FileCore-Adressierung, weil FileCore nun mit 4 KiB-Blöcken umgehen kann und ADFS nun auch die (S-ATA-)Hardware entsprechend ansteuern kann. Zuvor wurden 512 Byte-Blöcke verwendet, wie sie lange Zeit bei IDE- und S-ATA-Festplatten auch nativ verwendet wurden.

Bisher konnten derartige Plattengrößen nur bei Dateisystemen über SCSI (also aktuell vor allem USB-Massenspeicher) unter Benutzung von Fat32FS verwendet werden, und das war auch eher getrickst über eine clevere Verwendung von Partitionsoffsets in SCSIFS.

Jetzt noch Partitionsunterstützung unter Ausnutzung der neuen FileCore-Freiheiten seit RISC OS 5 (256 statt 8 “Laufwerke” aka dann hoffentlich Partitionen), dann könnte man ohne größere Verrenkungen Platten (ok, 256 Laufwerksicons…) bis 512 TiB verwenden. Im Moment sind gängige Retail-Größen mit gutem Preis-/Größenverhältnis 2 TiB und 4 TiB, d.h. man hätte sich wieder etwas Luft verschafft im RISC OS-Universum bevor man an den nächsten größeren FileCore-Umbau gehen muss.

RISC OS für Raspberry Pi RC15 verfügbar

2017-04-21 20:56

Lange hat es gedauert. RC14 erschien im Februar 2015 noch basierend auf RISC OS 5.21 und war “out of the box” so richtig gut nur auf dem ersten RPi lauffähig – der RPi 2 war nominell unterstützt, aber es hakte an der ein oder anderen Stelle. Seither war die RPi Foundation nicht untätig und hat quasi im Jahresrhythmus neue Gerätschaften auf den Markt gebracht: RPi Zero, RPi 3, die aktualisierte Variante des RPi 2 auf Basis desselben SoCs wie RPi 3, und zuletzt den RPi Zero W.

Nun konnte natürlich jeder gefuchste Anwender mit Heimwerkerhintergrund “problemlos” (zumindest wenn man SystemDisc von Piccolo Systems hat) eine neuere RISC OS-Version für RPi 3 und Co zusammendengeln. Aber bekanntlich ist der RPi ja auch in den Händen von RISC OS-Noobs, die nur mal kurz unser schönes alternatives Betriebssystem ausprobieren wollen. Für die war die NOOBS-Distribution bisher große Klasse, aber leider basiert diese auch auf RC14. Der zweitbeste Weg um RISC OS auszuprobieren war das RC14-Disc-Image von ROOL selbst, aber wie gesagt – nicht wirklich tauglich für die neuen Modelle, und relativ kompliziert auf einen neueren Stand zu bringen.

Jetzt ist die Warterei vorbei, RC15 wurde veröffentlicht (hier die offizielle Ankündigung). Endlich ist also wieder eine Distribution verfügbar, die man “einfach so” auf alle aktuellen RPi-Modelle bringen kann. Super!

Jetzt muss man nur noch erklären, warum RISC OS nur 2 GiB der üblicherweise viel größeren (micro)SD-Karte nutzen kann – hoffentlich kann man diese Frage auch bald beantworten mit “geht doch”, sobald FileCore und die diversen Dateisysteme anständig mit Partitionen umgehen können.

iMX6-HAL erreicht das ROOL-Repository

2017-03-10 19:50

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.

Ada, RISC OS und ARMv8

2017-03-10 19:17

CDVDBurn ist in Ada geschrieben. Und wird mit dem einzigen Ada-Compiler compiliert, der je unter RISC OS existiert hat: GNAT 3.03, basierend auf GCC 2.7.2.1. Also Technik von 1996. Natürlich nicht 32bit-kompatibel, ich compiliere also entweder auf dem dicken PC im Emulator, oder per Aemulor auf dem ARMX6. Durch glückliche Fügung erzeugt der Compiler 32bit-kompatiblen Code (zumindest meistens – es gibt einige Ada-Features die man besser nicht nutzen sollte wie z.B. Representation Clauses) – das ARM-Backend des GCC konnte das eh schon länger, die GCC-Runtime habe ich damals 2002 als der IYONIX pc erschien aus einem GCC 2.95 extrahiert, und die GNAT-Runtime hat mir Martin Würthner persönlich auf Binärebene angepasst.

Nun hat sich allerdings in den letzten Tagen herausgestellt, dass der erzeugte Code doch nicht so ganz hasenrein war, was die 32bit-Kompatibilität angeht. Ein Sack voll deprecated LDM-Instruktionen haben sich in der GCC-Runtime gefunden, die zwar auf bisherigen 32bit-Maschinen – vom IYONIX über den Pi 1 bis zum ARMX6 – trotzdem funktioniert haben, aber beim Pi 3 mit einem gnadenlosen “Undefined Instruction” abgebügelt werden. Konsultation mit Experten und nähere Analyse mit ARMalyser zeigten den Schuldigen: die GCC-Runtime enthält im main-Entrycode non-32bit-Code. Die Suche nach Sourcecode, auf dem die Runtime basiert, war leider nicht erfolgreich, und so versuchte ich mein Glück mit händischem Binär-Patch.

Scheint mein Glückstag gewesen zu sein: CDVDBurn läuft nun einwandfrei auf dem Raspberry Pi 3. Ich hoffe inständig, dass das auch so bleibt falls RISC OS auf weiteren ARMv8-Plattformen stattfinden wird. Ich bin zu alt für diesen Scheiß.

RISC OS auf Linux portiert

2017-02-13 23:09

Zugegeben, die Überschrift klingt irgendwas zwischen merkwürdig und erklärungsbedürftig.

Timothy Baldwin hat im ROOL-Forum genau das angekündigt: ein RISC OS, das unter Linux läuft. Und zwar nicht in einem Emulator, sondern nativ (falls es sich um ARM Linux handelt, sonst wird QEMU genutzt).

Ich habe es noch nicht selbst ausprobiert, aber was dort zu lesen ist, klingt schon sehr interessant (wenn auch noch nicht ganz produktionsreif). Im Prinzip wird das RISC OS-ROM-Image quasi als Linux-Anwendung ausgeführt. Im User-Space wohlgemerkt. Als Standard-Linux-Prozess. Ein spezielles Dateisystem, genannt IXFS, sorgt für die Verbindung zum Linux-Dateisystem und kümmert sich auch um die Speicherung der RISC OS-Spezialitäten (Load/Exec bzw. Filetype) in den Metadaten. Video-, Maus- und Tastaturtreiber verbinden sich via Unix Domain Socket (Interprozesskommunikation nach POSIX-Art – auch IPC genannt) mit einem Prozess, der dann z.B. für die Darstellung des “Bildschirms” SDL2 verwendet.

Das Posting nennt auch ein paar Bereiche, wo es noch Schwächen gibt. Aber immerhin ein erster Schritt, und einige Anwendungen laufen bereits.

Hier ist das GitHub-Projekt zu finden.

Wie immer bei neuen Entwicklungen gibt es jede Menge Unwägbarkeiten, und es ist sicher ein typisches 80-20-Softwareprojekt – obwohl schon zu 80% fertig, wird die Perfektionierung noch sehr lange dauern. Aber sollte die Perfektionierung gelingen, ist das Projekt fast schon eine Revolution im RISC OS-Bereich. Es vereinigt die Vorzüge einer Emulationslösung mit den Vorzügen einer nativen Lösung. Gerade im Bereich der ARM-Boards gibt es ja eine Vielzahl von Geräten, auf denen Linux läuft, aber auf denen RISC OS niemals laufen wird, weil die Manpower für die Portierung fehlt und/oder gar nicht ausreichend Informationen über das verwendete SoC zur Verfügung stehen, um überhaupt eine Portierung zu ermöglichen (typische Beispiele sind SoCs von Rockchip, MediaTek und Allwinner, aber auch die Tegras von NVIDIA oder das Qualcomm-Zeugs oder die Samsung Exynos).

Optimistisch gesprochen ist ab sofort Linux der Hardware Abstraction Layer für RISC OS. Eine Revolution.