EmuTOS 1.1 erschienen

[Thorsten Otto]

War tatsächlich schonmal angedacht, allerdings nicht nur für die Resource-Dateien, sondern für das komplette ROM. Nur die Resourcen zu packen würde auch erhebliche Umstruktierungen notwendig machen (abgesehen davon daß nicht alle sprachabhängigen Sachen in Resource-Files stehen, z.b. die Meldungen von EmuCON).

Würde aber wohl zu viel RAM kosten zur Laufzeit (einige Spiele laufen schon jetzt nicht mit EmuTOS weil sie sich einfach an feste Addressen kopieren, EmuTOS aber etwas mehr Speicher benötigt als original TOS). Ausserdem wäre das nur ein Aufschub. Und irgendwie scheint es mir auch nicht sinnvoll, mehr als 50% des ROMs mit sprachabhängigen Daten zu belegen von denen dann am Ende nur jeweils eine genutzt wird.

[Ektus]

Wäre es da nicht geschickter, einfach nur eine Sprachvariante (z.B. Englisch) ins ROM zu packen und weitere Sprachen bei Bedarf nachzuladen? Für Spiele läßt man die dann weg und hat das RAM frei.

[Thorsten Otto]

Hatte ich auch schon mal vorgeschlagen, wurde aber bisher abgelehnt. Hauptgrund ist wohl, daß nur die wenigsten überhaupt mehrere Sprachen benötigen.

[czietz]

Wäre es da nicht geschickter, einfach nur eine Sprachvariante (z.B. Englisch) ins ROM zu packen und weitere Sprachen bei Bedarf nachzuladen?

Ich sehe den Vorteil gegenüber der aktuellen Lösung, bei der Leute schlicht das ROM in der Sprache ihrer Wahl nehmen, nicht. Dafür aber zwei gravierende Nachteile:

1. Beim Reset vergessen, die Diskette mit der deutschen Sprachdatei einzulegen? => Sprache und Tastaturbelegung ungewollt plötzlich auf Englisch.
2. Der Code, um Sprachen zur Laufzeit nachzuladen, belegt Platz, der für sinnvollere Features imho besser genutzt wäre.

Seien wir mal ehrlich: (So gut wie) Niemand möchte die Sprache zur Laufzeit wechseln. Es ist gut und richtig, dass es EmuTOS in über einem Dutzend Sprachvarianten gibt, aber letztlich wählen Nutzer(innen) daraus einmal ihre Sprache und bleiben dann dabei.

Wer rein zu Testzwecken (z.B. Reproduktion eines Bugs, Screenshots, ...) eine andere Sprache braucht, kann immer noch entweder auf die PRG-Version von EmuTOS (oder den Festplatteninstaller für EmuTOS) zurückgreifen.

[guest4334]

von EmuTOS

Hier habe ich eine EmuTOS Version
für den PaCifiST 0.48 Emulator
die mir EmuTOS gesendet hat.

von EmuTOS     (PaCifiST 0.48 Emulator)  22.07.2021

Ein Vorteil von EmuTOS gegenüber Atari TOS ist, dass man Funktionen beliebig "ausknipsen" kann und dann eine Spezialversion bauen kann. Wie in diesem Fall, wo man Unterstützung für alle Hardware abschalten kann, die PaCifiST schlicht fehlerhaft emuliert. Damit bekommt man ein aktuelles EmuTOS, das - mit limitiertem Funktionsumfang - unter PaCifiST 0.48 funktioniert. Siehe Anhang.

Bitte beachte:
1. Die Eingabeaufforderung (EmuCON) funktioniert auf dem emulierten C:-Laufwerk nicht richtig.
2. Dies ist keine offizielle EmuTOS-Version; wir werden keine Funktionen aus offiziellen EmuTOS-Snapshots oder -Releases entfernen, nur um Kompatibilität zu einem fehlerhaften, uralten Emulator zu ermöglichen.
3. Ich habe das angehängte Image nur oberflächlich getestet. Eventuell enthält PaCifiST noch weitere Fehler.

von EmuTOS

[tuxie]

Du kannst doch ohne Probleme einen neuen Target einpflegen und nur das einbauen lassen womit pacifist gut läuft, dann das ganze als Patch an die Mailingliste senden. Und mit etwas Hoffnung wird es in den offiziellen Build aufgenommen. So habe ich es bei dem EmuTOS für die Vampire V4SA auch gemacht.

[Thorsten Otto]

Du kannst doch ohne Probleme einen neuen Target einpflegen

Du hast dir glaub ich noch nie das Makefile angesehen, sonst würdest du sowas nicht behaupten

mit etwas Hoffnung wird es in den offiziellen Build aufgenommen.

Denke eher nicht. Pacifist läuft ja nicht mehr auf aktuellen Maschinen. Bei dem patch für StonXDOS war es ein bisschen anders, weil man dafür keinerlei #ifdef braucht.

[tuxie]

Du kannst doch ohne Probleme einen neuen Target einpflegen

Du hast dir glaub ich noch nie das Makefile angesehen, sonst würdest du sowas nicht behaupten

mit etwas Hoffnung wird es in den offiziellen Build aufgenommen.

Denke eher nicht. Pacifist läuft ja nicht mehr auf aktuellen Maschinen. Bei dem patch für StonXDOS war es ein bisschen anders, weil man dafür keinerlei #ifdef braucht.

Ich habe wie geschrieben bereits den Target für die V4SA hinzugefügt, daher ja ich weiß was das für Arbeit macht! Aber versuchen kann man es ja!

[czietz]

Sorry, aber ich sehe keine Chance für ein separates Target für einen fehlerhaften, knapp 25 Jahre alten, so gut wie nicht mehr genutzten Emulator. Beachte, dass ein Target nicht nur einmalige Arbeit bedeutet, sondern wiederkehrenden Aufwand für Pflege, Testing, Speicherplatz etc. mit sich bringt.

Aber ein großer Vorteil von Open-Source-Software ist: Jeder, der dennoch unbedingt EmuTOS unter PaCifST unter MS-DOS nutzen möchte, kann es sich problemlos selbst compilieren, indem er vor dem make 256 die angehängte Datei als localconf.h ins Build-Verzeichnis kopiert.

[Thorsten Otto]

Wer (mangels geeigneter Entwicklungs-Umgebung) nicht in der Lage ist, EmuTOS selber zu übersetzen, kann auch gerne meinen (experimentellen) "Build Service" ausprobieren. Nicht alle Sachen die EmuTOS unterstützt lassen sich dort einstellen, aber die von @czietz erwähnten Sachen habe ich hinzugefügt:

http://tho-otto.de/emutos/index.php

In dem speziellen Fall, müsste man die unten angezeigten Sachen einstellen.

Bitte beachtet aber daß die so erzeugten EmuTOS-Versionen nur für spezielle Zwecke verwendet werden sollten, und keine "offiziellen" Versionen sind.

PS: @czietz, wie hast du eigentlich (wieder mal) so schnell heraus gefunden, welche Sachen Pacifist Probleme bereiten?

[guest4334]

Thorsten Otto

super vielen Dank
mit deinen Emutos  Build Service

habe ich mir ein Emutos für den Pacifist gebastelt
super einfach.

Liebe Grüße von Siegfried

[czietz]

PS: @czietz, wie hast du eigentlich (wieder mal) so schnell heraus gefunden, welche Sachen Pacifist Probleme bereiten?

Grenzenloses Können . Nein, dass PaCifiST die STOP-Instruktion des 68000ers falsch emuliert, war dank des eingebauten Monitors/Debuggers schnell klar, denn ein reguläres EmuTOS hängt schlicht an dieser Stelle. Dann gab es Grafikfehler, die für mich nach einer defekten Blitter-Emulation in PaCifiST aussahen ... und ich lag richtig. Schließlich detektierte EmuTOS Alt-RAM, das nicht da ist, und ich habe herausgefunden, dass auch PaCifiSTs Emulation von Bus-Errors fehlerhaft ist und EmuTOS daher eine MonSTer-Karte vermutete.

[Chocco]

Nö, das ist so nicht richtig. VDI hast du im Auto-Ordner schon. Nur AES nicht. Du kannst also sauber eigene GUIs bauen, wenn du das im Auto-Ordner unbedingt tun willst

Ja stimmt, XBOOT macht das so. In den bekannten ST-Auflösungen funktioniert das sogar.

Kann man natürlich so beurteilen. Oder sich denken „das spart dann halt eine Datei #:\FOLDR.INF, in der dann nur die Zahl "60" stünde, sonst nix“. Haben aus dem selben Grund ja auch RAM-Disk-Entwickler*innen ähnlich gemacht. Auf einer SH205 unter TOS 1.0 war ich um jede Datei froh, die von einer Software nicht referenziert wurde (und ja, ich habe das lange genau so genutzt).

Du hast natürlich recht. Für jeden Einstellung eine eigene INF-Datei ist total lahm. Hätte man eine Art CONFIG.SYS, könnte man dort einfach eine FOLDER=60 eintragen oder auch die Anzahl gleichzeitiger File Handles, Puffergrößen, Tastaturlayout oder Codepage, usw. Das sollte natürlich von TOS unterstützt werden. Wenn keine CONFIG.SYS gefunden wird, werden einfach Default-Einstellungen genommen.

[mfro]

...Hätte man eine Art CONFIG.SYS, könnte man dort einfach eine FOLDER=60 eintragen oder auch die Anzahl gleichzeitiger File Handles, Puffergrößen, Tastaturlayout oder Codepage, usw.

Dann hätte man auch einen idiotensicheren Editor mitliefern und den Leuten erklären müssen, wie sie damit umgehen.

FOLDRXXX umbenennen konnte jeder - äh - Laie mit Bordmitteln.

[goetz @ 3rz]

Du hast natürlich recht. Für jeden Einstellung eine eigene INF-Datei ist total lahm. Hätte man eine Art CONFIG.SYS, könnte man dort einfach eine FOLDER=60 eintragen oder auch […]  Das sollte natürlich von TOS unterstützt werden. […]

Ich denke nicht, dass das so einfach funktionieren könnte. Wenn TOS von FOLDRxx wissen kann/müßte -- dann braucht es auch FOLDRxx nicht mehr, dann kann man den Fix den FOLDR bereitstellt, gleich ins ROM gießen. Der Trick von TOS-Fixes im Auto-Ordner ist ja gerade, dass TOS davon nichts weiß.

Wenn man in TOS ein generisches Mittel eingebaut hätte "wenn es im AUTO-Ordner ein Programm ARGLK gibt, dann suche in der CONFIG.SYS nach einem Schlüssel ARGLK und übergib den Wert dann ARGLK“ … geht auch nicht, denn Parameterübergabe ist im AUTO-Ordner nicht.

Und das Parsing einer CONFIG.SYS wären in den 192 KB damals nicht mehr einzuquetschen gewesen ohne größere Umbauten.

Alles nicht so einfach.

[goetz @ 3rz]

Ich stelle mir ja eher die Frage, was Atari von 1985 bis 1989 gemacht hat, um gerade mal einen TOS-Sprung von 1.0 nach 1.04 hinzubekommen. Damit meine ich nicht die Versionsnummer, sondern … den Inhalt. Ein paar Fixes für gröbste Bugs, und Blitterroutinen. Das war’s. In 4 Jahren. Ich rate mal, dass viele der ursprünglichen Entwickler*innen ausgebrannt waren und/oder absprangen nach dem Release des STs.

[Arthur]

@Thorsten Otto, sehr schick dein EmuTOS Build-Tool...   

[MJaap]

Ich stelle mir ja eher die Frage, was Atari von 1985 bis 1989 gemacht hat, um gerade mal einen TOS-Sprung von 1.0 nach 1.04 hinzubekommen. Damit meine ich nicht die Versionsnummer, sondern … den Inhalt. Ein paar Fixes für gröbste Bugs, und Blitterroutinen. Das war’s. In 4 Jahren. Ich rate mal, dass viele der ursprünglichen Entwickler*innen ausgebrannt waren und/oder absprangen nach dem Release des STs.

Das Entwicklerteam scheint ja eher klein gewesen zu sein:
https://dadhacker-125488.ingress-alpha.easywp.com/the-atari-st-part-2/

...und größere Änderungen hätten TOS mit Sicherheit wieder über die 192KB Grenze geschoben, die mit ROM-TOS unterschritten wurde. Mich würde interessieren, was Atari zum Umdenken verleitete. Da kam ja in (relativ) kurzer Abfolge ein Desktop-Update, ein AES-Update, SpeedoGDOS und fast noch TOS 5.

[goetz @ 3rz]

Das Entwicklerteam scheint ja eher klein gewesen zu sein:
https://dadhacker-125488.ingress-alpha.easywp.com/the-atari-st-part-2/

Halte ich für nicht stichhaltig. Thomas hat Texel 1.0 in … 18? Monaten geschrieben. Alleine. Und vor allem: nebenher. Selbst wenn das TOS-Team nur aus 1 Vollzeit-Person bestand, dann sind in 4 Jahren nur Blitter, ein paar Fixes, und fsel_exinput weiter ziemlich mager.

...und größere Änderungen hätten TOS mit Sicherheit wieder über die 192KB Grenze geschoben, die mit ROM-TOS unterschritten wurde. Mich würde interessieren, was Atari zum Umdenken verleitete.

Naja, 1987++ waren 64 KB mehr EPROM nicht mehr wirklich teuer. Sieht man ja auch am 1040STE von 1989, wo dann 256 KB drin waren.

Da kam ja in (relativ) kurzer Abfolge ein Desktop-Update, ein AES-Update, SpeedoGDOS und fast noch TOS 5.

Ja, 1990+ gab es nochmal einen Burst.

Ich spekuliere, dass 1986-1989 man die Entwicklerkapazitäten in Projekte steckte, die im nirgendwo versandeten, wie das Pen-Tablet, Treiber fürs Atari CDAR504 CD-ROM-Laufwerk …

Wer hat denn das UNIX SVR auf den TT portiert? Atari selbst oder eine externe Bude? Bei der ATW (auch so ein Megaprojekt) kam die Software ja definitiv von außen.

[mfro]

Wer hat denn das UNIX SVR auf den TT portiert? Atari selbst oder eine externe Bude?

Unisoft. Die gibt's noch.