Mist

You are browsing the search results for MIST

Zero Page und RISC OS 5 – Update

2017-08-29 00:27

Wer sich nicht mehr erinnert – seit Juli 2015 haben alle RISC OS 5-Development-Builds die Zero-Page verschoben und laufen in der sogenannten “high processor vectors”-Konfiguration. Das ermöglicht einen deutlich stabileren OS-Betrieb, führt aber dazu, dass so manche Software, die bisher einwandfrei lief, aufgrund von (vermutlich) unkritischen NullPointer-Zugriffen den Abgang macht. Auch zu Diagnosezwecken, aber auch zur Wahrung der Rückwärtskompatibilität wurde deshalb das ZeroPain-Modul erfunden, das Zugriffe auf die Zero Page loggt. So mancher Uralt-Bug wurde dadurch erfolgreich ausgemerzt.

Ursprünglich war angedacht, ab 1.1.2016 ZeroPain wieder abzuschaffen. Das war wohl viel zu optimistisch, und es gab meines Wissens erheblichen Widerstand von R-Comp und CJE, die bekanntlich fertige RISC OS-Rechner inklusive eigens getesteter RISC OS 5-Versionen für die weniger bastelfreudigen User verkaufen. Letztlich das alte RISC OS-Problem: zuwenige Entwickler, die sich um die Pflege der Software kümmern können, dazu einige Software ohne verfügbaren Quellcode.

Jetzt gibt es eine neue Marschrichtung: einen Kompatibilitätsmodus, “compatibility page” genannt. Per OS_Memory 20 auch softwaremäßig kontrollierbar. Ich denke, das ist ein guter Kompromiss – es ermöglicht allen Parteien, zu einem gemeinsamen ROM-Build zurückzukehren und je nach Zielgruppe zwischen maximaler Rückwärtskompatibilität oder gescheiter Entwicklerunterstützung einfach umschalten zu können. Software, die zu Emulationszwecken die Zero Page selbst simulieren will (ADFFS ist da ein Kandidat, siehe Post zur Verfügbarkeit von Version 2.62), kann ebenfalls entsprechend agieren. ZeroPain ist für Entwickler und Benutzer, die Entwickler unterstützen wollen, weiterhin verfügbar.

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.

Der fast perfekte Retro-Monitor

2016-10-19 22:32

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.

Classic Computing 2016 (1) – Der Plan

2016-07-23 23:56

Am 17. und 18. September 2016 findet die Classic Computing 2016 in Nordhorn statt. Unser loser Zusammenschluss von Acorn- bzw. RISC OS-Enthusiasten, der seit ewigen Zeiten als GAG (German Archimedes Group) firmiert, wird dort auch einen kleinen Stand bemannen, um dem geneigten Retro-Publikum die wunderbare Welt von RISC OS näher zu bringen.

Grob habe ich folgenden Plan gefasst, was die zu präsentierende Hardware angeht:

  • Acorn A3000 als Vertreter der originalen Archimedes-Hardware – ARM2, IOC, MEMC1a, VIDC, 4 MB RAM, “single floppy” – also keine Harddisc oder so neumodischer Schnickschnack. Dafür mit dem LogikJoy-Interface (RTFM-kompatibel, falls das noch jemand was sagt) ausgestattet, damit man zwei anständige Joysticks (aka Competition Pro) anschließen kann um zünftig Sensible Soccer spielen zu können. Die klassische eckige Logitech-Maus ist natürlich auch dabei, weil man will ja Zarch, Aldebaran und Spheres Of Chaos angemessen steuern können.
  • MiST als Vertreter der heutigen Retro-Hardware-Generation Marke FPGA. Der Archimedes-Core ist zwar noch nicht sonderlich weit entwickelt, aber für eine Runde Zarch sollte es reichen.
  • Raspberry Pi als Vertreter der modernen RISC OS-fähigen Hardware, aber dank Software wie ADFFS, ArcEm und ArchiEmu auch für Retro-RISC OS-Zwecke sehr brauchbar. Wegen ADFFS wird es wohl ein Raspberry Pi B+ werden.

Interessant wird, geeignete Monitore aufzutreiben – der A3000 bräuchte schon einen 15kHz-Multiscan-Monitor für den echten Retro-Genuss. Vielleicht funktioniert es ja über den Scart-Eingang meines 22″-TFT, denn auf Röhrenmonitore herumtragen habe ich nicht wirklich Lust.

Raspberry Pi 3 verfügbar

2016-02-29 21:21

Heute hat die Raspberry Pi Foundation den Raspberry Pi 3 offiziell vorgestellt. Er ist bereits (im Gegensatz zum RPi Zero, der immer noch bei der Verfügbarkeit schwächelt) in kleinen Stückzahlen bei den üblichen Verdächtigen lieferbar. Preise liegen bei rund 40€.

Jetzt gibt es also harte Fakten. Die weichen gar nicht so sehr von den Gerüchten ab, die ich vorgestern eingesammelt habe:

  • SoC 1,2 GHz BCM2837 Quad-Core Cortex-A53 – also ARMv8 64bit, aber mit AArch32-Unterstützung (wichtig für RISC OS)
  • WiFi (802.11n) und Bluetooth (4.1) über BCM43438 on board

Rest ist unverändert zum RPi 2 – 1GB RAM, 4x USB2.0, 100MBit Ethernet über USB angebunden, analog Video/Audio out über Klinke, HDMI für digital Video/Audio, microSD-Slot. Es wird ein 2,5A-Netzteil empfohlen, wenn man die 4 USB-Ports voll belasten will. Alle Ports sind an der gleichen Stelle wie beim RPi B+ und RPi 2 B, die Gehäuse sind also kompatibel.

Performancetechnisch wird die Steigerung vermutlich bei 50% gegenüber dem RPi 2 liegen – etwas höherer Takt, und höhere Effizienz des Cortex-A53 gegenüber dem Cortex-A7. NEON soll deutlich schneller geworden sein.

Ben Avison hat ein paar interessante Details zur Rückwärtskompatibilität im ROOL-Forum gepostet. Es scheint diesmal kein übles Ei wie die Änderung der non-word-aligned-memory-access-Geschichte bei ARMv7 vs. ARMv6 zu geben, nur Kleinigkeiten die vermutlich nur das OS betreffen.

In Summe ist der RPi 3 eine super Sache – gleicher Preis wie bisher, und man hat die Chance preiswert einen realen 64bit-ARM zu betreiben. Mal sehen, ob oder optimistischer forumliert wann RISC OS den Sprung in die schöne neue 64bit-Welt schafft. Ohne einen maschinellen Weg, den Assembler-Code in seni 64bit-Pendant zu überführen, sehe ich da wenig Chancen.

Enger wird es nun für die teureren Angebote vom ARMX6 bis zum IGEPv5 oder Titanium. Diese haben natürlich immer noch Alleinstellungsmerkmale wie S-ATA oder Gigabit Ethernet, aber CPU-technisch dürfte der 1,2 GHz Cortex-A53 dem 1,2 GHz Cortex-A9 des ARMX6 ebenbürtig sein, und dem 1,5 GHz Cortex-A15 des IGEPv5 und Titanium zumindest auf den Pelz rücken. RISC OS-technisch hoffen wir also auf einen Raspberry Pi 4 nächstes Jahr mit einem Cortex-A72, der legt bei der Single-Core-Performance nochmal eine ordentliche Schippe drauf. Dann wird es allerdings Zeit, RISC OS die Nutzung mehrerer Cores beizubringen.

Mal sehen, ob man aus dem “hardware virtualization feature” des Cortex-A53 was machen kann (beherrscht auch schon der Cortex-A15). Jon Abbott (Schöpfer von ADFFS) hatte dazu interessante Ideen.