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.