Aranym auf Raspberry Pi OS (32bit) ohne X11

[Mado]

So, ich habe es jetzt auch geschafft, den Aranym auf dem Raspberry Pi ohne X11 zu kompilieren. Wichtig ist, ie Nicht-64Bit-Lite-Distribution zu nehmen. Aranym läuft dort nicht mit Jit, ist aber auch so recht flott. Mit Jit (nicht mit Jit-FPU) kompiliert er, aber die Grafik zeigt Datenmüll an. Ich werde das auch noch mal in eine ganze Anleitung gießen. Hier zur Vorfreude schon mal ein Ergebnis vom Gembench im Anhang.

Vorbereitung inkl. SDL bauen, wie hier:
https://datenbrei.de/atari/2022-06-06-hatari-auf-raspberry-pi-ohne-x11/

Dann Hatari-Bauen auslassen, stattdessen:

Code: [Auswählen]

export LD_LIBRARY_PATH=/usr/local/lib
export PATH=$PATH:/usr/local/bin

git clone https://github.com/aranym/aranym.git
cd aranym
mkdir build
cd build

apt install autoconf
../autogen.sh --disable-jit-compiler --disable-jit-fpu --enable-hostfs --disable-opengl --disable-nfclipbrd
make
sudo make install

sudo usermod -aG video,audio,input $USER
exit     # und neu anmelden

export LD_LIBRARY_PATH=/usr/local/lib
export PATH=$PATH:/usr/local/bin

aranym
Ansonsten muss es natürlich ein emutos-aranym.img geben und sinnvollerweise mindestens irgendein Floppy-Image.

Ansonsten kann das Menü-Skript von dem Hatari-Artikel oben verwenden, nur eben nicht mit Hatari sondern mit Aranym.

Rufe ich im Aranym ganz normal SYSINFO.PRG auf, crasht es mit einer illegal Instruction. Daher ist mein Bauchgefühl, dass es auf dieser Plattform noch mehr Bugs gibt, als auf x86-64.

[Lukas Frank]

Solche Gembench Werte über die 10.000 bringt auch AtariX auf einem schnellen Intel Macintosh ...

Ich weiss nicht ob es Quellen vom MagicPC irgendwo gibt?

[czietz]

Danke. Da muss ich wohl meine Hatari-Test-Installation (bislang mit 64-bit RPi OS) platt machen, wenn ich testen möchte. Daher nochmal zum besseren Verständnis, dass ich es richtig verstanden habe. Du sagst also: Auf 32-Bit armhf läuft Aranym also - aber nur ohne JIT? Auf 64-Bit aarch64 compiliert es nicht einmal?

[Mado]

Ja. Auf der 64-Bit-Arm-Plattform gibt es offenbar kein Compilationsziel. Ich habe beim autogen.sh einfach nix bekommen. Kann man sicher recht einfach fixen, wenn man sich damit auskennt.

Die Plattform bei mir war übrigens ein Raspberry Pi 3B. Der 4er wird so heiß, der 3er kann noch gut passiv gekühlt werden.

GIbt es eigentlich sowas, wie eine Emulator-Test-Suite? Also ein Assembler-Programm, dass der Reihe nach die Opcodes durch geht und die Ergebnisse mit den erwarteten Ergebnissen vergleicht? Letztere ggf. von einer echten Maschine holen? Als weiteren Test dann noch Reaktionen im IO-Bereich der Memory Map? Hat sich schonmal ein Emulator-Entwickler sowas gebaut? Dann könnte man ggf. gezielt dahinter kommen, wo noch Bugs in einem Emulator sind.

[Thorsten Otto]

Ich weiss nicht ob es Quellen vom MagicPC irgendwo gibt?

Nein, leider nicht. Es ist auch eine komplett eigene Version, und hat weder was mit AtariX noch mit MagicMac gemeinsam.

[Thorsten Otto]

GIbt es eigentlich sowas, wie eine Emulator-Test-Suite? Also ein Assembler-Programm, dass der Reihe nach die Opcodes durch geht und die Ergebnisse mit den erwarteten Ergebnissen vergleicht?

z.T.
Hatari führt einige Tests durch, und für FPU hatte ich mal was geschrieben, aber das ist alles erheblicher  Aufwand, weil dort Abweichungen in den letzten Bits nicht unbedingt Fehler bedeuten (selbst unterschiedliche FPUs wie 68881/68882/040/060 liefern oft unterschiedliche Ergebnisse)

Problem bei den Opcodes ist hauptsächlich die ganzen Corner-Cases zu testen. Bei "normalen" Operation ist wohl davon auszugehen, daß sie i.d.R. korrekt sind, weil sonst wohl kaum ein Programm korrekt emuliert werden könnte.

[czietz]

Ja. Auf der 64-Bit-Arm-Plattform gibt es offenbar kein Compilationsziel. Ich habe beim autogen.sh einfach nix bekommen.

Interessanterweise lässt sich Aranym bei mir auf 64(!)-Bit-Raspberry-Pi-OS nach Deiner Anleitung problemlos bauen und es läuft auch.

Was mir auffällt: Die GUI (mit [Pause] aufrufbar) flackert heftig. D.h. es scheint regelmäßig für Sekundenbruchteile der Atari-Bildschirm darunter durch. Das kenne ich von Aranym unter Windows auch; hielt es aber immer für ein Windows-Problem. @Thorsten Otto : Ist der Effekt bekannt?

[Mado]

Interessanterweise lässt sich Aranym bei mir auf 64(!)-Bit-Raspberry-Pi-OS nach Deiner Anleitung problemlos bauen und es läuft auch.

Hmm, was hab ich da denn gemacht?!? Das ist ja blöd, hatte gestern das ganze Raspberry Pi OS neu geflash, dann hätte es die gleiche Plattform getan, wie beim Hatari. Vielleicht sind die Probleme, die ich mit dem crashenden Systinfo hatte dann auch weg, heißt, vielleicht ist Aranym auf einer 64bit-Plattform besser getestet.

Was mir auffällt: Die GUI (mit [Pause] aufrufbar) flackert heftig. D.h. es scheint regelmäßig für Sekundenbruchteile der Atari-Bildschirm darunter durch. Das kenne ich von Aranym unter Windows auch; hielt es aber immer für ein Windows-Problem. @Thorsten Otto : Ist der Effekt bekannt?

Das ist bei mir auf allen Plattformen so. Auch im Manjaro-Linux. Ist bei mir aber erst seit ca. 3-4 Wochen. Da hatte ich ein Majaro-Update eingespielt und danach trat das Problem auf.

[Thorsten Otto]

[Das ist bei mir auf allen Plattformen so. Auch im Manjaro-Linux. Ist bei mir aber erst seit ca. 3-4 Wochen. Da hatte ich ein Majaro-Update eingespielt und danach trat das Problem auf.

Ja, wenn ich mich richtig erinnere, war/ist das auch unter WIndows ein SDL Problem.

vielleicht ist Aranym auf einer 64bit-Plattform besser getestet.

Nein, definitiv nicht (jedenfalls nicht auf ARM). Ich selbst habe eigentlich überhaupt keine Möglichkeit, das auf ARM zu testen.

[czietz]

Im Anhang ein paar Ergebnisse von Aranym auf dem Raspberry Pi Zero 2W unter Aarch64. Man sieht, der RPi Zero 2W ist keine Rennmaschine, die Emulation ohne JIT läuft etwa auf der Performance eines Milan040 @ 25 MHz. Andererseits muss man auch bedenken: Der RPi Zero 2W ist ein 15-€-Computer.

PS: Der Gembench-Vergleich mit einem ST ist natürlich fragwürdig, aber zum Vergleich mit @Mado 's Resultat.

[Arthur]

Sehr beeindruckende Ergebnisse Christian, danke.

[Thorsten Otto]

der RPi Zero 2W ist keine Rennmaschine, die Emulation ohne JIT läuft etwa auf der Performance eines Milan040 @ 25 MHz.

Ja, man müsste wohl JIT mal lauffähig bekommen für Aarch64, dann sähe das schon ganz anders aus. Auf x86 macht das ca. den Faktor 10.

Man sieht daran aber auch, daß Hatari (das deutlich mehr CPU-Power benötigt) vermutlich ziemlich zäh laufen wird.

[Mado]

Also ich finde, dass die Rapsberry Pis sehr günstig sind und schön klein und, solange es die normalen sind, sehr schön viele USB-Anschlüsse haben und schön HDMI - und nur ein normales Micro-USB bzw. USB-C als Power brauchen. Das ist doch klasse. Zusätzlich wird es die eine ganze Zeit lang geben, als Ersatzteil... Man kann sich bei den geringen Kosten ja auch ienen auf Halde legen.

Hatari zumindest bzw. die SDL-Library soll ja sogar beschleunigt laufen. Das geht auch nicht überall. Ich habe leider keine Vergleichsdaten auf Pi ohne den beschleunigten Treiber.

Vergleichbar mit neuen Notebooks oder so ist es sicher nicht. Aber meines hat auch knappe 1400 Ditscher gekostet. Das wird ja, insbesonmdere, was RAM angeht, vom TOS/Mint eh nicht genutzt.

Code: [Auswählen]

CPU: 8-core AMD Ryzen 7 5800U with Radeon Graphics (-MT MCP-)
speed/min/max: 1895/1600/4505 MHz Kernel: 5.18.5-1-MANJARO x86_64 Up: 2h 27m
Mem: 3079.9/31410.2 MiB (9.8%) Storage: 953.87 GiB (26.7% used) Procs: 371
Shell: Bash inxi: 3.3.19
Stonx-Ergebnisse im Anhang. Haha, der ist so schnell, dass beim Gembench das Geblinke der jeweiligen Test-Beschreibung ein Vielfaches vom Test selber dauert.

Aber man muss ja bedenken: Was bringt einem das in der Realität? Nichts! Ein Rechner muss so flott sein, dass die genutzten Programme angenehm und ohne Warten bedienbar sind und gute Ergebnisse liefern. PGP auf dem ST geht dann irgendwann gut, aber ich tippe, dass Videobearbeitung z.B. nicht die erste Domäne von TOS-Betriebsystemen ist.

[czietz]

Wenn man nicht gerade den langsamsten derzeit erhältlichen RPi nimmt, kommt man natürlich auch auf höhere Werte. Mit einem RPi 400 ist die Performance gut vier Mal so schnell etwa auf dem Level eines Milan 060:

[Arthur]

Wenn du als Vergleichsreferenz einen TT nimmst sollte der CPU-Error in der Statistik verschwinden.

[Mado]

Leider nein. Einfach zu schnell. Gibt es die Sourcen von Gembench? Das ist ja in GFA Basic geschrieben, soweit ich weiß... Könnte man ja um 1-2 Stellen erweitern...

[czietz]

Gibt es die Sourcen von Gembench?

Nein. Zwischenzeitlich sah es sogar mal so aus, als ob der jetzige Maintainer es komplett einstellen würde: https://web.archive.org/web/20211011055201/https://exxoshost.co.uk/atari/last/GB6/index.htm. Mittlerweile hat er seine Meinung wieder revidiert.

Andererseits: Vielleicht sind Benchmarks wie QINDEX oder GEMBench auch etwas "aus der Zeit" gefallen. Es gibt modernere Benchmarks mittlerweile.

[Mado]

Ich finde spezifische Benchmarks hilfreich beim Optimieren verschiedener Routinen, wie beim VDI zum Beispiel. Aber dort wäre es dann besser wirklich noch spezifischere Tests zu haben, die genau bestimmte OS-Routinen testen.

[czietz]

Aber dort wäre es dann besser wirklich noch spezifischere Tests zu haben, die genau bestimmte OS-Routinen testen.

Du meinst also sowas wie Kronos.