ATARI ST im Browser

[Wosch]

https://jamesfriend.com.au/pce-js/atari-st/

Läuft auch auf meinem iPhone 6SPlus. Bedienung ist etwas schwierig 

Gruß
Wolfgang

[ama]

Ein ST direkt im Browser. Spielerei, aber funktioniert nicht einmal so schlecht.

https://jamesfriend.com.au/pce-js/atari-st/

[czietz]

@Thorsten Otto hat den PCE.js-Emulator noch etwas erweitert: http://tho-otto.de/pce-js/.

Und mit seinem Floppy-Disk-Image-Browser verbunden. Wenn Du z.B. die ST-Computer-PD-Diskette 002 ausprobieren möchtest, auf dieser Seite...
http://tho-otto.de/fatfs/fatfs.php?image=http%3A%2F%2Fdownloads.atari-home.de%2FPublic_Domain%2FSerie_ST-Computer%2F0-99%2FPDATS002.msa&codepage=
... auf den Link "Run PDATS002.st in PCE" klicken - und schon startet sie im Browser.

[guest4334]

Fast alle Atari ST PD Disketten
lassen sich mit den Browser starten

https://www.atariuptodate.de/de/atari-pd-serie/

Einfach Atari Public Domain Serie auswählen

zb: 4U PD

4U 001

auf Linkes Disk Symbol klicken
Content
--------------------------
Download 4U 001 (19xx)(ForYou).st as ZIP
Run 4U 001 (19xx)(ForYou).st in PCE

Volume has no label
Directory for A:/

BASE    <DIR>       1989-04-06   00:05    
SCRIPT    <DIR>       1989-04-06   00:05    
README.TXT    598   2005-01-26   09:30       [View]
1 file 598 bytes
2 directories
16 384 bytes free
------------------------

Dann auf
Run 4U 001 (19xx)(ForYou).st in PCE

klicken

und schon läuft die Atari ST Disk im Browser

Liebe Grßé von Siegfried

Danke an Thorsten Otto für den Disketten Browser  der Atari Disketten direkt starten kann.

[jeloneal]

Ziemlich praktisch! Aber irgendwie kann man kein deutsches TOS wählen. Springt immer wieder auf emuTOS US. Soll das so sein?

[Thorsten Otto]

Nein, soll nicht so sein. Funktioniert bei mir aber:

[jeloneal]

Welchen Browser verwendest du? Bei mir springt er sofort wieder auf emuTOS US wenn ich ein anderes auswähle 

Nutze Edge (Chromium), in Safari aber auch das gleiche Verhalten. Irgendwelche Ideen? Einstellungen?

Die anderen Einstellungen im Emulator lassen sich setzen, Takt etc.

[Thorsten Otto]

Ich benutze FireFox (verschiedene Versionen, auch aktuelle).

Wenn zwischen mono/color geswitcht wird, wird lediglich ein "reset" an den Emulator geschickt, ebenso bei ändern der Taktrate. Wenn ein neues TOS ausgewählt wird, wird aber die Seite neu komplett neu geladen, möglcherweise gibt es da Probleme mit dem cache.

PS.: die sourcen sind natürlich auch verfügbar (https://github.com/th-otto/pce), falls du die Möglichkeit hast selber einen Server aufzusetzen (geht auch lokal). Meine Änderungen sind im "emutos" branch zu finden.

[jeloneal]

Danke für den Tipp, werd ich mir am Wochenende mal genauer ansehen. Tolle Sache auf jeden Fall 

[black panther]

Ziemlich praktisch! Aber irgendwie kann man kein deutsches TOS wählen. Springt immer wieder auf emuTOS US. Soll das so sein?

ist bei mir auch so!

[Arthur]

Hut ab, coole Sache so ein Atari ST im Browserfenster. Mit der Sprache das finde ich jetzt nicht so wild denn im Firerfox klappt es ja.

[Thorsten Otto]

Englische Sprache würde mich auch nicht stören, aber die Tastaturbelegung stimmt dann natürlich auch nicht. Kann aber bestätigen daß bei mir mit Chromium das gleiche Verhalten ist. Muss mal suchen...

Edit: sieht so aus als ob die sich unterschiedlich verhalten wenn ich sage er soll die Seite neu laden. FireFox behält dann die Einstellungen des Formulars bei, Chrome nicht. Durch die Art wie der Emulator von Javascript gestartet wird, muss aber die Seite neu geladen werden... hm...

[czietz]

Und hier noch ein Link (via @tin im Atari-Forum): Der Emulator Hatari im Browser: http://absencehq.de/atariaviary.

Hataris Emulation ist noch einmal ein Stück exakter als die von PCE.js, sodass auch anspruchsvolle Demos laufen. Dafür bringt er selbst auf einem performanten Rechner Firefox an seine Grenzen. Mit Chrome läuft es weniger ruckelig.

[guest4334]

Der Hatari im Browser läuft bei mir leider nicht.

Der Link geht bei mir leider nicht
Please wait...

loading database...

Please wait ...

Er läd und läd und läd
geht aus den laden nicht mehr heraus.

Läd auch den Hatari nicht.

Liebe Grüße von Siegfried

[Thorsten Otto]

kA wie die Hatari da eingebunden haben, aber bei PCE wird emscripten benutzt. Das ist ein Compiler der Web-Assembly code erzeugt, wodurch ein Grossteil der Emulation native im Browser ausgeführt wird. Würde man das für Hatari hinbekommen, dürfte das deutlich performanter sein. Allerdings ist es nicht so einfach das einzubinden, ich hatte mir das schon mal angeschaut.

Edit: ah sehe gerade im AF-Forum, daß die wohl auch schon emscripten benutzen.

[tin]

Und hier noch ein Link (via @tin im Atari-Forum): Der Emulator Hatari im Browser: http://absencehq.de/atariaviary.

Hataris Emulation ist noch einmal ein Stück exakter als die von PCE.js, sodass auch anspruchsvolle Demos laufen. Dafür bringt er selbst auf einem performanten Rechner Firefox an seine Grenzen. Mit Chrome läuft es weniger ruckelig.

Daher der sehr wichtige Hinweis im original-Post, dass das Ganze nur mit Chromium-basierten Browsern läuft. Firefox ist mit seiner aktuellen Webasm-Implementation leider viel zu langsam (das war mal andersherum, siehe Original-Thread). Ggfs sollte da wohl eine FF-Sperre rein, da das aktuell wohl verwirrt.

„Weniger ruckelig“ kann ich im Chrome (kleinerer I5 Laptop) und hier auf dem Tablet leider nicht nachvollziehen, beides läuft sauber in 50/60Hz ohne jegliche Framedrops. Auf was für einer Konfiguration lässt Du es laufen? Oder passieren Ruckler nur bei bestimmten Demos?

[Thorsten Otto]

Ggfs sollte da wohl eine FF-Sperre rein, da das aktuell wohl verwirrt.

Haben sie wohl gerade gemacht

Find ich eigentlich unsinnig, die Situation kann sich ja jederzeit wieder ändern. Ausserdem hängt das ja auch von anderen Faktoren, wie dem verwendeten Rechner ab.

[czietz]

„Weniger ruckelig“ kann ich im Chrome (kleinerer I5 Laptop) und hier auf dem Tablet leider nicht nachvollziehen, beides läuft sauber in 50/60Hz ohne jegliche Framedrops. Auf was für einer Konfiguration lässt Du es laufen? Oder passieren Ruckler nur bei bestimmten Demos?

Natürlich habe ich in Chrome "Sea of Colour" getestet; soll ja auch was anspruchsvolles sein.  Da geht der Frameskip nach dem Titelbildschirm auf 3 - 4 hoch. Das auf einem gut zwei Jahre alten Core i7, der lokal genug Leistung hat, um auch die deutlich anspruchsvollere Falcon-Emulation in Hatari zu stemmen.

Aber bevor das jetzt als Kritik aufgefasst wird: Ich find's großartig, dass Hatari überhaupt im Browser lauffähig ist. Und mir bewusst, dass das ein Test / eine Alpha-Version ist.

[tin]

Haben sie wohl gerade gemacht

Ja, habe ich inzwischen eingebaut, da es selbst auf aktuellen grösseren i7+Co. kaum zuckt und ich vermehrt Anfragen idF "Warum ruckelt das" bekomme. Aktuell ist FF für die Zielgruppe (aka mich) nicht benutzbar.

Ich beobachte die Webasm+FF-Entwicklung und sollte sich dies verbessern, werde ich die Sperre wieder entfernen.

Natürlich habe ich in Chrome "Sea of Colour" getestet; soll ja auch was anspruchsvolles sein.  Da geht der Frameskip nach dem Titelbildschirm auf 3 - 4 hoch. Das auf einem gut zwei Jahre alten Core i7, der lokal genug Leistung hat, um auch die deutlich anspruchsvollere Falcon-Emulation in Hatari zu stemmen.

Ah, also ist es definitv Demo-abhängig - sobald intern in Hatari die genauren "Copper" Behandlungen anspringen, wird deutlich mehr Leistung benötigt. Auch bei verstärktem IRQ-Aufkommen kann das passieren.

Aber bevor das jetzt als Kritik aufgefasst wird: Ich find's großartig, dass Hatari überhaupt im Browser lauffähig ist. Und mir bewusst, dass das ein Test / eine Alpha-Version ist.

Oh, keine Angst, das ist auf keinen Fall als Kritik aufgefasst worden - ob ich es allerdings deutlich verbessern kann wird sich zeigen; ich habe schon einen cast "Fehler" in Hatari "behoben" (aka umgehackt), damit die teure Cast-Emulation in EM nicht verwendet werden muss (die bei jedem einzelnen Befehl griff) und ich musste inzwischen auch vom aktuellen HEAD auf 2.31 zurück, da es sonst zuviel Regression gab (z.B. Closure lief nicht mehr). Aber schaunmermal, für einen so schnell zusammengestöpselten Prootypen läuft es erstaunlich gut, vor allem wenn man es mit 2014 (http://absencehq.de/union/) vergleicht.

[Thorsten Otto]

Ich beobachte die Webasm+FF-Entwicklung und sollte sich dies verbessern, werde ich die Sperre wieder entfernen.

Ich fänds gut, wenn man die Sperre durch eine Warnung ersetzen könnte, Hatte es zwar nur kurz probiert, aber zumindest einige Demos liefen eigentlich auch mit FF ganz brauchbar.

vor allem wenn man es mit 2014 (http://absencehq.de/union/) vergleicht.

Da stehts übrigens noch umgekehrt, daß man bitte FF statt Chrome benutzen soll

Auch bei verstärktem IRQ-Aufkommen kann das passieren.

Vlt. bessert sich das mit der geänderten IRQ Behandlung in Hatari (scheint aber noch ein paar Probleme zu machen)

BTW, sind die notwendigen Änderungen eigentlich irgendwo einzusehen? Wie ich oben schon schrieb, hatte ich mir das nach meinen Erfahrungen mit PCE-js auch mal für Hatari angeschaut, war aber irgendwo ins stocken geraten (und hatte wohl auch die Version von 2014 übersehe, wo das ja eigentlich schon gemacht wurde)