atari-home.de - Foren

Software => Alternative Betriebssysteme => Thema gestartet von: czietz am Fr 09.07.2021, 08:29:03

Titel: EmuTOS 1.1 erschienen
Beitrag von: czietz am Fr 09.07.2021, 08:29:03
Gerade ist EmuTOS 1.1 erschienen. Eine große Änderung betrifft den Falcon, dessen DSP nun auch unterstützt wird. Eine Zusammenfassung der weiteren Änderungen gegenüber Version 1.0 findet sich hier: https://github.com/emutos/emutos/blob/VERSION_1_1/doc/changelog.txt

Downloads: https://sourceforge.net/projects/emutos/files/emutos/1.1/

Außerdem gibt es ein (im Aufbau befindliches) Benutzerhandbuch: https://emutos.github.io/manual/
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Lukas Frank am Fr 09.07.2021, 20:40:45
Farbicons nur in der 512kB Falcon Version? Bei der Programm Version über Grafikkarte mit 256 Farben sind die Icons einfarbig.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: czietz am Fr 09.07.2021, 21:04:13
Farbicons nur in der 512kB Falcon Version? Bei der Programm Version über Grafikkarte mit 256 Farben sind die Icons einfarbig.

Ab der 256k-Version - wenn Du ein Programm nutzt, das überhaupt Farbicons verwendet. (Das dürften allerdings in der Tat hauptsächlich Falcon-Programme sein, denn die Funktionen, die nun in EmuTOS dafür eingebaut wurden, sind auch erst in Atari TOS 4 hinzugefügt worden.)
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Lukas Frank am Fr 09.07.2021, 22:24:18
Hatte halt erwartet ab einem 16 Farben EmuTOS Desktop Farbicons zu haben auch auf einem ST ...
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: MJaap am Sa 10.07.2021, 08:10:51
Hier werden zwei Programme genannt, die Farbicons nutzen (aber keine speziellen Falcon-Programme sind):
https://www.st-computer.org/de/news/emutos-11-veroeffentlicht

Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Lukas Frank am Sa 10.07.2021, 11:24:15
Das interessiert mich nicht. Auf dem Falcon sind die Icons auf dem Desktop in Farbe. Ich dachte/wünschte das wäre auf dem ST genau so ...
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: MJaap am Sa 10.07.2021, 23:11:19
Das interessiert mich nicht. Auf dem Falcon sind die Icons auf dem Desktop in Farbe. Ich dachte/wünschte das wäre auf dem ST genau so ...

Schön, dass dich das nicht interessiert.
EmuDesk unterstützt noch keine Farbicons, weder auf dem ST noch auf dem TT oder Falcon.

Ist aber geplant:
Zitat
FWIW, colour icon support is available for 256K ROMs.  Also, I hope to add AES 3D effects and then colour icons for the desktop, so even an STe user will see a difference :-).
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Lukas Frank am Di 13.07.2021, 12:36:22
Ist aber geplant:
Zitat
FWIW, colour icon support is available for 256K ROMs.  Also, I hope to add AES 3D effects and then colour icons for the desktop, so even an STe user will see a difference :-).

Das freut mich und ich kann es kaum erwarten ...

Ist halt schön ab 16 Farben z.B. mit/über einer Grafikkarte einen Desktop mit Farbicons zu haben. Zur Zeit behelfe ich mich indem ich EASE nutze unter EmuTOS.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Chocco am Di 13.07.2021, 22:59:02
Gratulation zur Version 1.1 !! Die Hardware-Unterstützung wird immer besser und ich verwende EMUTOS sehr häufig und besonders EMUCon finde ich spitze.

Ein wenig umständlich finde ich das Handling mit den Sprachen und Zeichensätzen, vor allem, weil viel Speicher dafür aufgewendet wird und es selbst in den dicken ROMs eng wird. Grundsätzlich ist es natürlich super, wenn EMUTOS wesentlich mehr Sprachen unterstützt als das ursprüngliche TOS. Andererseits ist der aktuelle Ansatz nicht besonders nachhaltig.

TOS war ja irgendwie immer auch ein bisschen (MS-)DOS und ROM-/RAM-Platzprobleme gab es früher ja auch. DOS hatte diese Problematik über nachladbare Codepages gelöst, mit der man z.B. die deutschsprachige Version von DOS aktivieren konnte.

Wie wäre es, wenn man in EMUTOS nur die von Atari vorgesehenen Sprachen "fest" verdrahtet in der Compiler Config beachten würde und stattdessen die Möglichkeit schaffen würde, die Tastaturbelegung, Zeichencodes und die Ressourcen für AES und DESKTOP in einer "config.sys" angeben zu können?

Dem Benutzer bliebe es dann überlassen, die Atari Standard-Sprache(n) zu wählen oder über eine Konfiguration, so wie es bei DOS üblich war, selbst zu defineren.

Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: MJaap am Mi 14.07.2021, 07:36:26
Ein wenig umständlich finde ich das Handling mit den Sprachen und Zeichensätzen, vor allem, weil viel Speicher dafür aufgewendet wird und es selbst in den dicken ROMs eng wird. Grundsätzlich ist es natürlich super, wenn EMUTOS wesentlich mehr Sprachen unterstützt als das ursprüngliche TOS. Andererseits ist der aktuelle Ansatz nicht besonders nachhaltig.

TOS war ja irgendwie immer auch ein bisschen (MS-)DOS und ROM-/RAM-Platzprobleme gab es früher ja auch. DOS hatte diese Problematik über nachladbare Codepages gelöst, mit der man z.B. die deutschsprachige Version von DOS aktivieren konnte.

Wie wäre es, wenn man in EMUTOS nur die von Atari vorgesehenen Sprachen "fest" verdrahtet in der Compiler Config beachten würde und stattdessen die Möglichkeit schaffen würde, die Tastaturbelegung, Zeichencodes und die Ressourcen für AES und DESKTOP in einer "config.sys" angeben zu können?

In EmuTOS werden doch die Sprachen getrennt? Seit 1.1 ist auch das 512er ROM nicht mehr multilingual, aus genau diesen Platzgründen, aber auch, weil die wenigsten zwischen Sprachen wechseln. Das steht sogar ganz dick unter den wesentlichen Änderungen! Im übrigen gab es je nach TOS-Version durchaus mehr oder weniger TOS-Sprachversionen.

Eine Ausnahme ist das 1MB-ROM, aber das funktioniert derzeit nur mit Emulatoren.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: simonsunnyboy am Mi 14.07.2021, 17:25:38
Gratulation zur Version 1.1 !! Die Hardware-Unterstützung wird immer besser und ich verwende EMUTOS sehr häufig und besonders EMUCon finde ich spitze.

Ein wenig umständlich finde ich das Handling mit den Sprachen und Zeichensätzen, vor allem, weil viel Speicher dafür aufgewendet wird und es selbst in den dicken ROMs eng wird. Grundsätzlich ist es natürlich super, wenn EMUTOS wesentlich mehr Sprachen unterstützt als das ursprüngliche TOS. Andererseits ist der aktuelle Ansatz nicht besonders nachhaltig.

TOS war ja irgendwie immer auch ein bisschen (MS-)DOS und ROM-/RAM-Platzprobleme gab es früher ja auch. DOS hatte diese Problematik über nachladbare Codepages gelöst, mit der man z.B. die deutschsprachige Version von DOS aktivieren konnte.

Wie wäre es, wenn man in EMUTOS nur die von Atari vorgesehenen Sprachen "fest" verdrahtet in der Compiler Config beachten würde und stattdessen die Möglichkeit schaffen würde, die Tastaturbelegung, Zeichencodes und die Ressourcen für AES und DESKTOP in einer "config.sys" angeben zu können?

Dem Benutzer bliebe es dann überlassen, die Atari Standard-Sprache(n) zu wählen oder über eine Konfiguration, so wie es bei DOS üblich war, selbst zu defineren.

Bitte nicht, das schöne an TOS war immer daß es ohne Konfigurationsfiles einfach funktionierte.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: guest4334 am Do 15.07.2021, 15:34:57
Schade das Emutos 1.1 nicht mehr mit den StonXDos Atari Emulator
funktioniert Emutos 1.0 und Emutos 1.01 gingen noch.

Liebe Grüße von Siegfried
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: czietz am Do 15.07.2021, 17:00:10
Wie ich Dir auf Facebook schon schrieb: Das ist bedauernswert. Aber der Bug befindet sich im StonXDos-Emulator, der übrigens seit ca. einem Vierteljahrhundert keine Updates mehr bekommen hat. Bitte verwende einen anderen Emulator.

PS: In der Schriftgrößenauswahl verklickt?  ;)
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: guest4334 am Do 15.07.2021, 17:28:56
Ja nur kenne ich keinen anderen Emulator
der mit Emutos 1.1
auf MSDOS oder FREEDOS  Computern läuft.

Liebe Grüße von Siegfried
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: simonsunnyboy am Do 15.07.2021, 17:34:35
Ja nur kenne ich keinen anderen Emulator
der mit Emutos 1.1
auf MSDOS oder FREEDOS  Computern läuft.

Liebe Grüße von Siegfried

Bei Pollin gibts aktuell Wyse Thinclients für ~35EUR, auf denen Linux und Hatari super laufen sollte.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: guest4334 am Do 15.07.2021, 17:50:52

simonsunnyboy

Ich suche keinen neuen Computer
habe selbst einen Linux PC
auf dem ich HATARI einsetze.
wollte nur wissen ob es einen Atari Emulator für DOS PCś gibt der mit Emutos 1.1 läuft.

Liebe Grüße von SIegfried
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Thorsten Otto am Do 15.07.2021, 20:04:13
Ja nur kenne ich keinen anderen Emulator
der mit Emutos 1.1
auf MSDOS oder FREEDOS  Computern läuft.

Ja, das stimmt wohl. Dummerweise gibt es zwar noch die Sourcen von stonx-0.6.7 (worauf stonxdos basiert), allerdings finde ich nirgends die Sourcen von dem DOS-Port, lediglich (wenn überhaupt) binaries. Und selbst wenn man die Sourcen hätte, dürfte es einigermassen aufwendig sein auf heutigen Maschinen eine Entwicklungs-Umgebung für DOS aufzusetzen.

@czietz: wo genau liegt denn das Problem? Vermute mal an den geänderten Routinen zur Initialisierung des MFP? Kann ja eigentlich nicht so gravierend sein, wenn es mit 1.0.1 noch funktionierte. Vlt. kann man ihm eine "spezial"-Version von EmuTOS bauen, die mit STonXDOS wieder funktioniert.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: czietz am Do 15.07.2021, 20:29:00
Ja, das stimmt wohl. Dummerweise gibt es zwar noch die Sourcen von stonx-0.6.7 (worauf stonxdos basiert), allerdings finde ich nirgends die Sourcen von dem DOS-Port, lediglich (wenn überhaupt) binaries.

Selbst wenn man auf der Webseite des Autors von StonxDOS nachsieht (die dank der hervorragenden Arbeit des Internet Archives erhalten geblieben ist), findet man nur Binaries. Ich vermute, die Sources wurden (im Widerspruch zur GPL) nie veröffentlicht.

@czietz: wo genau liegt denn das Problem? Vermute mal an den geänderten Routinen zur Initialisierung des MFP? Kann ja eigentlich nicht so gravierend sein, wenn es mit 1.0.1 noch funktionierte. Vlt. kann man ihm eine "spezial"-Version von EmuTOS bauen, die mit STonXDOS wieder funktioniert.

Siehe https://sourceforge.net/p/emutos/mailman/message/37318354/
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: guest4334 am Do 15.07.2021, 20:46:50
StonxDOS

http://stonx.sourceforge.net/download.html

Die Binär und die Sourche Dateien von StonXDos

LIebe Grüße von SIegfried
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: gh-baden am Do 15.07.2021, 21:39:48
Ja, das stimmt wohl. Dummerweise gibt es zwar noch die Sourcen von stonx-0.6.7 (worauf stonxdos basiert), allerdings finde ich nirgends die Sourcen von dem DOS-Port, lediglich (wenn überhaupt) binaries.

Selbst wenn man auf der Webseite des Autors von StonxDOS nachsieht (die dank der hervorragenden Arbeit des Internet Archives erhalten geblieben ist), findet man nur Binaries. Ich vermute, die Sources wurden (im Widerspruch zur GPL) nie veröffentlicht.


IANAL, aber die GPL 2.0 sagt nicht, dass man die Sourcen jederzeit neben das Binary legen muss. Nur, dass man sie auf Anfrage veröffentlicht (https://www.gnu.org/licenses/old-licenses/gpl-2.0.html):

Zitat
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
[…]
Zitat
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

Erst in der GPL 3.0 wurde das verschärft (https://www.gnu.org/licenses/gpl-faq.html#AnonFTPAndSendSources), und man muss den Source quasi „neben“ das Binary/Objektfile legen.

Bin ich blind, oder liegt der STonX-DOS-Source nicht da (http://stonx.sourceforge.net/stonxdos-src.zip)?

{edit}: Siegfried war schneller und ich hab’s überlesen.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Chocco am Do 15.07.2021, 22:11:03
Bitte nicht, das schöne an TOS war immer daß es ohne Konfigurationsfiles einfach funktionierte.

TOS funktioniert nicht einfach so. Ich halte dieses Gehampel mit der Reihenfolge von Startdateien im Auto-Ordner für den größten Murks aller Zeiten. Eine autoexec.bat und config.sys sind dazu im Vergleich eine Segen. Wer NVDI, MINT usw. verwendet hat es gleich doppelt schwer. Da wollen dann Config-Dateien PLUS Reihenfolge von Startprogrammen im Auto-Ordner verwaltet werden!
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Thorsten Otto am Do 15.07.2021, 22:42:43
Jo, stimmt, sourcen findet man da. Aber ich denke es ist trotzdem einfacher EmuTOS anzupassen, als zu versuchen eine passende Version von djgpp  zu finden, und das ganze dann in einer DOS Umgebung zu  übersetzen (wobei das vlt. mit dosbox sogar machbar wäre).

Zitat
Siehe https://sourceforge.net/p/emutos/mailman/message/37318354/

Ah, ok, danke. Liegt dann vermutlich daran, daß STonX (auch die unix-version) lediglich die für den MFP benötigten Addressen emuliert, und bei den dazwischen liegenden dann (fälschlicherweise) einen Bus-Fehler erzeugt (wobei das verhalten der MMU dort schon ein bisschen eigenartig ist, word-Zugriffe zuzulassen, aber bei Byte-Zugriffen auszusteigen).

Hab mal eine gepatchte Version der 192k und 256k ROMs angehängt. Falls die funktionieren, müsste man evtl. mal Roger versuchen zu überreden, den Patch wieder in EmuTOS einzubauen ;)
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Thorsten Otto am Do 15.07.2021, 22:46:03
Ich halte dieses Gehampel mit der Reihenfolge von Startdateien im Auto-Ordner für den größten Murks aller Zeiten.

Das stimmt schon. Allerdings liegt das in den meisten Fällen nicht an TOS, sondern daran daß die Programme manchmal einfach schlecht programmiert sind, und nicht damit zurecht kommen wenn sie an der "falschen" Stelle stehen.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: czietz am Do 15.07.2021, 22:58:28
wobei das verhalten der MMU dort schon ein bisschen eigenartig ist, word-Zugriffe zuzulassen, aber bei Byte-Zugriffen auszusteigen

Nö, überhaupt nicht eigenartig. Bedenke, dass ein Bus-Error (vom GLUE) erzeugt wird, wenn bei einem Bus-Zugriff keine Komponente /DTACK setzt. Bei Zugriffen im MFP-Adressbereich wird /DTACK dann und genau dann generiert, wenn sie zusammen mit /LDS auftreten. Ob dabei zusätzlich noch /UDS gesetzt ist (Word-Zugriff) ist vollkommen unerheblich.

Sorry, aber der Emulator (und nicht EmuTOS) ist kaputt und sollte repariert werden!
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Chocco am Fr 16.07.2021, 00:16:30
Das stimmt schon. Allerdings liegt das in den meisten Fällen nicht an TOS, sondern daran daß die Programme manchmal einfach schlecht programmiert sind, und nicht damit zurecht kommen wenn sie an der "falschen" Stelle stehen.
Entweder das oder ein Programm "überschreibt/ignoriert" die von einem vorher gestarteten Programm gesetzten Veränderungen einfach.

Wenn meine Erinnerung stimmt: Programme im Auto-Ordner haben zudem mit weiteren Einschränkungen zu kämpfen, denn eigentlich werden sie gestartet bevor das System einen stabilen Zustand besitzt. Die Zeichenausgabe funktioniert zwar bereits über TOS (low level Line-A), aber VDI/AES sind noch nicht initialisiert.

Ganz schlimm sind Programme, denen anhand ihres eigenen Dateinamen Parameter übergeben werden. Bestes Beispiel ist FOLDERXX.PRG. Da wird die Anzahl der zusätzlichen Ordner im Dateinamen numerisch eingetragen, die dann vom Programm selbst extrahiert und ausgewertet werden müssen! Man fragt sich, was die Entwickler geraucht haben, um sich sowas auszudenken.

Hinzu kommt noch, das der Pfad auf die eigene Programmdatei nicht als argv[0] übergeben wird, sondern das Programm seinen eigenen Namen erst über die Basepage(?) selbst herausfinden muss.

Jeder dusselige PC hatte zumindest immer ein BIOS Setup, in dem Datum/Uhrzeit, Bootlaufwerk und andere grundsätzliche Dinge eingestellt werden konnten. In TOS und auch EMUTOS gibt es nichts dergleichen.

Bitte nicht falsch verstehen, ich bastle gerne an meinen Rechnern, aber TOS als benutzerfreundliches und einfaches System zu bezeichnen ist realitätsfern. TOS wurde damals mit glühender Nadel fehlerbehaftet gestrickt und auf 192K eingedampft und das merkt man einfach an jeder Ecke.

Für EMUTOS wird die Situation dadurch nicht einfacher, weil Kompatibilität zu TOS ganz oben steht.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: guest4334 am Fr 16.07.2021, 05:02:07
Thorsten Otto

Danke
mit deinen Emutos Patch läuft der StonxDOS Emulator wieder

Liebe Grüße von Siegfried
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Thorsten Otto am Fr 16.07.2021, 12:51:32
Sorry, aber der Emulator (und nicht EmuTOS) ist kaputt und sollte repariert werden!

Hast ja recht eigentlich, aber in dem Fall ist es mir zu viel Aufwand, eine passende Entwicklungsumgebung zu schaffen (djgpp findet man vermutlich noch irgendwo, aber kA. ob der unter dosbox funktioniert, was StonxDOS für libraries braucht und ob die noch irgendwo zu finden sind, etc.).
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Thorsten Otto am Fr 16.07.2021, 13:01:31
Man fragt sich, was die Entwickler geraucht haben, um sich sowas auszudenken.

Das Problem ist halt, das an AUTO-Ordner Programme keine Parameter übergeben werden (wo sollen die auch her kommen). Selbst MiNT macht noch sowas ähnlich, um nur die Programme im AUTO-Ordner zu starten, die *nach* MiNT liegen.

Zitat
das Programm seinen eigenen Namen erst über die Basepage(?) selbst herausfinden muss.

Das geht nicht. In der Basepage werden nur zusätzliche Parameter eingetragen, nicht aber der Dateiname der Programm-Datei. argv[0] kannst du nur herausfinden, wenn das ARGV-Protokoll (oder equivalentes) zum starten benutzt wurde.

Zitat
Jeder dusselige PC hatte zumindest immer ein BIOS Setup, in dem Datum/Uhrzeit, Bootlaufwerk und andere grundsätzliche Dinge eingestellt werden konnten. In TOS und auch EMUTOS gibt es nichts dergleichen.

Diese Informationen sind aber doch auch alle in TOS/EmuTOS verfügbar?

PS.: ich glaube wir schweifen hier ein bisschen vom Thema ab ;)
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Nervengift am Fr 16.07.2021, 20:13:08
Ich find's erstmal cool, dass EmuTOS immer weiter in Richtung von TOS 4.x geht. Da muss man echt den Hut vor den Entwicklern ziehen, finde ich!

Ich gebe @Chocco recht, dass mit den Programmen im Auto-Ordner ist für den Otto Normal Anwender wie mich schon echt frickelig. Selbst bei der Reihenfolge der Treiber bzw. Erweiterungen im MiNT-Ordner muss man ein wenig aufpassen. Das ist echt ein Ding, was ich auch sehr unglücklich finde. Betrachtet man GDOS dann wird's nicht besser. Im Grunde müsste man dort alt hergebrachte Konzepte über den Haufen werfen. Dazu bedürfte es wohl eines TOS 5 und MiNT 2. Beides ist in Anbetracht dessen, dass es wohl nie Software für solche Systeme geben würde, mehr als utopisch. Letzten Endes steht die maximale Kompatiblität zu der alten Software im Vordergrund, denke ich. Wir müssen mit dieser Frickelei leben. :D
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: MJaap am Sa 17.07.2021, 00:02:27
Das coole ist ja, dass der Quelltext vorliegt. Ich hatte mir mal mit TOSPATCH mein Wunsch-TOS2.0x zusammengestellt (mit Pinguin-Icon). Bei EmuTOS gibt es da ganz andere Möglichkeiten. Müsste eben nur jemand entwickeln und entweder einschicken oder einen Fork erstellen. Dinge wie eine Menüzeilen-Uhr oder RAM-Disk wurden schon diskutiert, aber da gibt es eben schon Dutzende Lösungen im PD-Bereich.

Größeren Visionen setzt eben die Kapazität der ROMs (256/512 KB) Grenzen. Ich persönlich würde es super finden, wenn EmuTOS noch Parität mit TOS 4.92 schafft (TOS 5).

Jedes neue Feature, dass durch Programmierer erst erschlossen werden muss, ist allerdings sinnlos. Ein Blick auf die Startseite von Atariuptodate.de zeigt ja, dass es kaum Aktivität abseits von Demos und gelegentlich einem Spiel gibt :(
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Count am Sa 17.07.2021, 15:25:37
Ganz schlimm sind Programme, denen anhand ihres eigenen Dateinamen Parameter übergeben werden. Bestes Beispiel ist FOLDERXX.PRG. Da wird die Anzahl der zusätzlichen Ordner im Dateinamen numerisch eingetragen, die dann vom Programm selbst extrahiert und ausgewertet werden müssen! Man fragt sich, was die Entwickler geraucht haben, um sich sowas auszudenken.

Hinzu kommt noch, das der Pfad auf die eigene Programmdatei nicht als argv[0] übergeben wird, sondern das Programm seinen eigenen Namen erst über die Basepage(?) selbst herausfinden muss.

FOLDRXXX.PRG ermittelt den "Parameter" übrigens ganz simpel. Es holt sich mit Fsfirst("\AUTO\FOLDR*.PRG") den ersten Directory-Eintrag und extrahiert daraus die Zahl. Theoretisch kannst du das Programm also zweimal mit unterschiedlichen Werten im AUTO-Ordner stehen haben, aber beide Aufrufe tun das selbe. Auf jeden Fall musst du das Muster FOLDRxxx.PRG beibehalten und kannst es nicht in z.B. ORDNR100.PRG umbenennen, das würde zu einer mit Tastendruck zu bestätigenden Fehlermeldung führen.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: gh-baden am Sa 17.07.2021, 17:04:53
Das coole ist ja, dass der Quelltext vorliegt. Ich hatte mir mal mit TOSPATCH mein Wunsch-TOS2.0x zusammengestellt (mit Pinguin-Icon). Bei EmuTOS gibt es da ganz andere Möglichkeiten. Müsste eben nur jemand entwickeln und entweder einschicken oder einen Fork erstellen. Dinge wie eine Menüzeilen-Uhr oder RAM-Disk wurden schon diskutiert, aber da gibt es eben schon Dutzende Lösungen im PD-Bereich.

Größeren Visionen setzt eben die Kapazität der ROMs (256/512 KB) Grenzen. Ich persönlich würde es super finden, wenn EmuTOS noch Parität mit TOS 4.92 schafft (TOS 5).

Jedes neue Feature, dass durch Programmierer erst erschlossen werden muss, ist allerdings sinnlos. Ein Blick auf die Startseite von Atariuptodate.de zeigt ja, dass es kaum Aktivität abseits von Demos und gelegentlich einem Spiel gibt :(

Menüzeilen-Uhr, RAM-Disk und Co: klar, kann man machen, aber gibt es doch schon x gute, wozu also nochmals erfinden.

Neue Software: das ist auf anderen Plattformen nicht so viel anders (Acorn RiscOS, Mac 68k mit System 6, 7, A/UX): was soll denn noch erscheinen? Die klassische Produktivsoftware (Textverarbeitung etc.pp.) ist ja noch vorhanden und ist gut. Die könnte man natürlich noch ein bißchen besser machen, aber der Aufwand dafür ist, selbst wenn ein Sourcecode von einer alten Software vorliegt, sehr hoch.

Kleine Tools: sicher, sowas gibt es öfters noch neu.

Spannend wäre heute wohl noch am ehesten Kommunikations- und Netzwerksoftware: da ist meist der Teufel TLS/SSL im Weg, dessen Krypto viel zu dick für 680x0 ist (und selbst auf den StrongARM des RiscPCs brettert das nicht gerade, und die spielen in einer ganz anderen Liga als 68k). Da bräuchte es ein generisches Interface für, auf dem man aufbaut, also quasi „ich döngle mir einen Raspberry Pi (zero) extern an meinen 68k Rechner, und der macht über ein definiertes Interface Krypto für mich“, so wie halt NVDI Vektorfonts bereitstellt, und der Raspberry ist nur ein weiterer der vielen Atari-Coprozessoren (Blitter, FPU, DSP …) für einen speziellen Einsatzzweck.

Es gibt ja kleine Ansätze in die Richtung (@czietz hat ja bspw. die Firmware für ein ESP8266 veröffentlicht, womit ein wget am ST geht), aber bevor nicht eine* heldenhafte Programmierer*in die Ärmel hochkrempelt und Fakten schafft, ist der Weg für viele, die sich einen kleinen Mastodon/Twitter/Instafeed-Client oder Keybase-Messenger oder … bauen wollen, qua Krypto versperrt.

Ich würd’ ja als Interface zum Raspi seriell/RS232 vorschlagen, weil’s das bei jeder Plattform gibt, und man die typischen Datenmengen ganz gut durchkriegt, aber mit dem RaSCSI-Board hätte man noch ganz andere Möglichkeiten: Das Krypto-Layer via SCSI-Protokoll-Erweiterung verpacken, der Raspi ist dann noch gleich Ethernet-Adapter.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: gh-baden am Sa 17.07.2021, 17:12:15
Wenn meine Erinnerung stimmt: Programme im Auto-Ordner haben zudem mit weiteren Einschränkungen zu kämpfen, denn eigentlich werden sie gestartet bevor das System einen stabilen Zustand besitzt. Die Zeichenausgabe funktioniert zwar bereits über TOS (low level Line-A), aber VDI/AES sind noch nicht initialisiert.

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 :)

Ganz schlimm sind Programme, denen anhand ihres eigenen Dateinamen Parameter übergeben werden. Bestes Beispiel ist FOLDERXX.PRG. Da wird die Anzahl der zusätzlichen Ordner im Dateinamen numerisch eingetragen, die dann vom Programm selbst extrahiert und ausgewertet werden müssen! Man fragt sich, was die Entwickler geraucht haben, um sich sowas auszudenken.

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).
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: mfro am Mo 19.07.2021, 07:32:36
...
Jeder dusselige PC hatte zumindest immer ein BIOS Setup, in dem Datum/Uhrzeit, Bootlaufwerk und andere grundsätzliche Dinge eingestellt werden konnten. In TOS und auch EMUTOS gibt es nichts dergleichen.
...

Tatsächlich ist das "BIOS Setup" vom "dusseligen PC" nichts anderes als das NVRAM bzw. die batteriegepufferte Uhr von TT und Falcon.

Atari hat das am Ende eingebaut, wusste aber anscheinend irgendwie selbst nicht so recht, was man denn da reinschreiben sollte.

Im TT ist die einzige mir bekannte, "offizielle" Nutzung die Einstellung der Bootpräferenz, wenn Atari SYSV4 installiert ist.

Im Falcon kamen dann noch Boot-Videoauflösung und die Sprache dazu (wobei erstere - meine ich - nicht wirklich "offiziell" dokumentiert ist und letztere ja nicht dem Anwender, sondern nur Atari selbst nutzte).

Unterm Strich erzeugt das "Atari-NVRAM" mehr Ärger als Nutzen. Hätten die meinetwegen auch weglassen können.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: kernal am Mo 19.07.2021, 08:23:46
Zitat
...
Jeder dusselige PC hatte zumindest immer ein BIOS Setup, in dem Datum/Uhrzeit, Bootlaufwerk und andere grundsätzliche Dinge eingestellt werden konnten.
...

Die Aussage stimmt nicht ganz. Die Echtzeituhr mit dem NVRAM für das BIOS (RTC/Dallas Chip) wurde auch "erst" 1984 mit dem PC/AT eingeführt.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Thorsten Otto am Mo 19.07.2021, 12:29:12
Atari hat das am Ende eingebaut, wusste aber anscheinend irgendwie selbst nicht so recht, was man denn da reinschreiben sollte.

Beim TT hat es ja auch nur 50 byte, das ist nicht gerade viel.

Zitat
Im TT ist die einzige mir bekannte, "offizielle" Nutzung die Einstellung der Bootpräferenz, wenn Atari SYSV4 installiert ist.

Da gibs schon ein bisschen mehr, siehe https://freemint.github.io/tos.hyp/de/xbios_datetime.html#Die_20Belegung_20des_20NVM_20der_20Echtzeit-Uhr

Zitat
letztere ja nicht dem Anwender, sondern nur Atari selbst nutzte).

Wieso nutzte die Spracheinstellung dem Anwender nichts?


Zitat
Unterm Strich erzeugt das "Atari-NVRAM" mehr Ärger als Nutzen.

Ja, hauptsächlich wegen ausgelaufenen/leeren Batterien. Das ist aber bei ollen PCs auch nicht anders. Unterschied ist nur daß die Leute dann nicht die Batterie austauschen, sondern sich einen neuen PC kaufen...

Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: mfro am Mo 19.07.2021, 14:34:01
Atari hat das am Ende eingebaut, wusste aber anscheinend irgendwie selbst nicht so recht, was man denn da reinschreiben sollte.

Beim TT hat es ja auch nur 50 byte, das ist nicht gerade viel.

Zitat
Im TT ist die einzige mir bekannte, "offizielle" Nutzung die Einstellung der Bootpräferenz, wenn Atari SYSV4 installiert ist.

Da gibs schon ein bisschen mehr, siehe https://freemint.github.io/tos.hyp/de/xbios_datetime.html#Die_20Belegung_20des_20NVM_20der_20Echtzeit-Uhr

Im TT? Glaub' ich nicht. In meinem jedenfalls nicht.

Zitat
letztere ja nicht dem Anwender, sondern nur Atari selbst nutzte).

Wieso nutzte die Spracheinstellung dem Anwender nichts?
(Zumindest) in den 80ern dürfte es den meisten Anwendern schnurz gewesen sein, ob sie einen Rechner in ihrer Landessprache oder einen, den sie erst auf ihre Landessprache einstellen müssen bekommen hätten (wahrscheinlich hätten die meisten ersteres bevorzugt). Das Multilanguage-ROM hat m.E. i.W. der Logistik bei Atari genutzt. Und bei leerer Batterie ist es hauptsächlich ein Ärgernis.

Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Thorsten Otto am Mo 19.07.2021, 15:11:01
Im TT? Glaub' ich nicht. In meinem jedenfalls nicht.

Einstellen kann man es da auch. Allerdings interessiert sich nicht mal der Desktop für z.B. das Datumsformat (jedenfalls nicht direkt aus den Werten im NVRAM, dazu müsste man ein Programm starten das den _IDT cookie entsprechend setzt, was das TT-TOS aber nicht tut). Gibt aber durchaus Programme die das auswerten.


Zitat
Das Multilanguage-ROM hat m.E. i.W. der Logistik bei Atari genutzt.

Kann schon sein. Wenn es Atari noch länger gegeben hätte, wären sie vermutlich auch irgendwann auf den Trichter gekommen, daß auch in 512k ROM keine 20 Sprachen passen ;)
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Thorsten Otto am Di 20.07.2021, 07:13:16
mit deinen Emutos Patch läuft der StonxDOS Emulator wieder

Eine abgeänderte Version des patches ist nun auch in EmuTOS. War noch nicht Teil des gerade erschienenen 1.1.1 Bugfix-Release, ist aber dann ab jetzt in den snapshot-Versionen enthalten.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: KarlMüller am Di 20.07.2021, 09:46:02
Wenn es Atari noch länger gegeben hätte, wären sie vermutlich auch irgendwann auf den Trichter gekommen, daß auch in 512k ROM keine 20 Sprachen passen
Dann hätten Sie es wie beim MilanTOS machen können. Dort sind die Resourcedaten und NEWDESK.INF gepackt. Auch beim Logo ist es so. Vielleicht ne Möglichkeit für EmuTOS.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Thorsten Otto am Di 20.07.2021, 13:29:04
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.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Ektus am Di 20.07.2021, 19:35:41
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.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Thorsten Otto am Mi 21.07.2021, 06:59:35
Hatte ich auch schon mal vorgeschlagen, wurde aber bisher abgelehnt. Hauptgrund ist wohl, daß nur die wenigsten überhaupt mehrere Sprachen benötigen.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: czietz am Mi 21.07.2021, 15:59:48
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.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: guest4334 am Fr 23.07.2021, 17:57:05
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
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: tuxie am Sa 24.07.2021, 07:57:15
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.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Thorsten Otto am Sa 24.07.2021, 13:26:11
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 :D

Zitat
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.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: tuxie am So 25.07.2021, 18:18:00
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 :D

Zitat
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!

Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: czietz am So 25.07.2021, 19:22:29
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.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Thorsten Otto am Mo 26.07.2021, 07:26:43
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?
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: guest4334 am Mo 26.07.2021, 16:22:57
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

Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: czietz am Mo 26.07.2021, 18:57:52
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.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Chocco am Mi 28.07.2021, 21:23:10
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.

Zitat
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.



Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: mfro am Mi 28.07.2021, 22:16:25
...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.
Titel: ROMs, TOS-Patches und Entwicklungsstände (was: EmuTOS 1.1 erschienen)
Beitrag von: gh-baden am Do 29.07.2021, 00:11:14
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.

Titel: Re: ROMs, TOS-Patches und Entwicklungsstände (was: EmuTOS 1.1 erschienen)
Beitrag von: gh-baden am Do 29.07.2021, 00:31:23
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.
Titel: EmuTOS Build-Tool
Beitrag von: Arthur am Fr 30.07.2021, 16:12:59
@Thorsten Otto, sehr schick dein EmuTOS Build-Tool...   
Titel: Re: ROMs, TOS-Patches und Entwicklungsstände (was: EmuTOS 1.1 erschienen)
Beitrag von: MJaap am Fr 30.07.2021, 20:36:30
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.
Titel: Re: ROMs, TOS-Patches und Entwicklungsstände (was: EmuTOS 1.1 erschienen)
Beitrag von: gh-baden am Sa 31.07.2021, 00:20:23
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.
Titel: Re: ROMs, TOS-Patches und Entwicklungsstände (was: EmuTOS 1.1 erschienen)
Beitrag von: mfro am Sa 31.07.2021, 06:06:38
Wer hat denn das UNIX SVR auf den TT portiert? Atari selbst oder eine externe Bude?

Unisoft (http://www.unisoft.com/history.html). Die gibt's noch.
Titel: Re: ROMs, TOS-Patches und Entwicklungsstände (was: EmuTOS 1.1 erschienen)
Beitrag von: MJaap am So 01.08.2021, 17:26:36
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.

Ja, aber Thomas hat das auf eigene Rechnung geschrieben und nicht für einen Arbeitgeber, der vielleicht ganz andere Vorstellungen hat, wo die Entwicklerressourcen besser aufgehoben sind. Ein reines "TOS-Team" hat es so wohl nie gegeben.

64KB mehr ROM waren vielleicht ab 1987 nicht mehr viel teurer, aber vielleicht zu teuer für die Geschäftsleitung. Vorher hätte auch entschieden werden müssen, den Desktop zu verbessern, oder ein paar Funktionen beim Mac abzukupfern. Offenbar keine Priorität.

Übrigens haben die letzten Snapshots von EmuTOS nun auch 3D-Look :)
Titel: Re: ROMs, TOS-Patches und Entwicklungsstände (was: EmuTOS 1.1 erschienen)
Beitrag von: gh-baden am So 01.08.2021, 19:39:15
Übrigens haben die letzten Snapshots von EmuTOS nun auch 3D-Look :)

… hoffentlich optional. Ich mag den original Atari-GEM-2D-Look, und verwende EmuTOS außer zum testen erst, seitdem dort Atari-GEM-gleichende Mauszeiger und Icons Einzug gehalten haben. Der Atari TOS4-3D-Look war mir eigentlich immer zu klobig. MagiC machte es später etwas „feiner“, das ging dann einigermaßen.
Titel: Re: ROMs, TOS-Patches und Entwicklungsstände (was: EmuTOS 1.1 erschienen)
Beitrag von: czietz am So 01.08.2021, 22:01:17
Übrigens haben die letzten Snapshots von EmuTOS nun auch 3D-Look :)

… hoffentlich optional. Ich mag den original Atari-GEM-2D-Look

Probiere es aus. In allen aktuellen Snapshots außer den 192k ROMs ist 3D aktiv: https://sourceforge.net/projects/emutos/files/snapshots/. Jetzt ist der richtige Moment (auch als User) Feedback zu geben, gerne auch direkt auf der Mailingliste: https://sourceforge.net/p/emutos/mailman/emutos-devel/

Blöd finde ich hingegen, wenn in einem erst im Release-Thread (wie zuletzt zu Version 1.1) alles "um die Ohren gehauen" wird, was persönlich an EmuTOS nicht gefällt.
Titel: Re: ROMs, TOS-Patches und Entwicklungsstände (was: EmuTOS 1.1 erschienen)
Beitrag von: Thorsten Otto am Mo 02.08.2021, 12:15:58
… hoffentlich optional.

Bin mir jetzt nicht sicher ob es ein CPX dafür gibt, aber man kann es über objc_sysvar() einstellen (und dementsprechend auch weitgehend abstellen). Was allerdings bleibt ist daß dann Buttons etwas grösser als sonst dargestellt werden.

PS.: eine Vorschau gibt es auf http://tho-otto.de/rscview/de/index.php?aes3d=1
Titel: Re: ROMs, TOS-Patches und Entwicklungsstände (was: EmuTOS 1.1 erschienen)
Beitrag von: MJaap am Di 03.08.2021, 13:18:51
MagiC machte es später etwas „feiner“, das ging dann einigermaßen.

Den von MagiC mochte ich gerne. Ganz schlimm ist der von Geneva, der zum Teil sehr protzig aussieht.

Vielleicht kann man ja den 3D-Support zum Online-Build-Tool hinzufügen.

Ich hatte gestern in "meinem" Build die unterstrichenen Dialogtitel von MagiC hinzugefügt. Die finde ich optisch ansprechender als zentrierte Titel in Großbuchstaben.

Titel: Re: ROMs, TOS-Patches und Entwicklungsstände (was: EmuTOS 1.1 erschienen)
Beitrag von: Thorsten Otto am Di 03.08.2021, 15:18:47
Vielleicht kann man ja den 3D-Support zum Online-Build-Tool hinzufügen.

Ja, kann man ;)

BTW, die  scripts die dafür zuständig sind, sind natürlich auch verfügbar: https://github.com/th-otto/rscview/tree/master/emutos

Wenn sich jemand daran versuchen will: ist im wesentlichen Fleiss-Arbeit, die restlichen config-Optionen dort hinzuzufügen, und dürfte mit copy/paste auch ohne grosse PHP-Kenntnisse machbar sein.


PS.: das script macht keinerlei Überprüfung ob die ausgewählten Optionen zusammen passen. Nicht alle Kombinationen sind möglich, manche Einstellungen setzen andere voraus etc. Das kann dann auch dazu führen daß sich EmuTOS gar nicht übersetzen lässt. Im Zweifelsfall sollte man solche Einstellungen erstmal mit einer Release-Version überprüfen, das geht wesentlich schneller (für eine snapshot-Version muss immer erstmal das EmuTOS-Repository geclont werden).
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: MJaap am Di 03.08.2021, 22:50:02
Mit vier Zeilen Code zu Nicelines in Menüs. Vorher/Nachher-Vergleich.

Inspiriert von diesem Artikel:
https://stcarchiv.de/stc1992/03/menutune

Aber eben direkt im Betriebssystem :)
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: gh-baden am Mi 04.08.2021, 05:42:29
Mit vier Zeilen Code zu Nicelines in Menüs. Vorher/Nachher-Vergleich.

Inspiriert von diesem Artikel:
https://stcarchiv.de/stc1992/03/menutune

Aber eben direkt im Betriebssystem :)

Mui bien! Sehr gut. Viel besser als "Pseudo-Grafik" mit Minuszeichen.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: MJaap am Mi 04.08.2021, 13:07:33
Mui bien! Sehr gut. Viel besser als "Pseudo-Grafik" mit Minuszeichen.

Ich hab's mal vorgeschlagen, vielleicht schaffen es die Nicelines in EmuTOS 1.2. Verglichen mit den Verrenkungen für so einen 3D-Dialog/Button-Look super-simpel  :D
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: tuxie am Mi 04.08.2021, 16:05:58
Wie würde das ganze den aussehen wenn man Unterlinien  nimmt ? die sollten so Breit sein das sie durchgängig sind.   _______________________ wie das.

Die frage ist natürlich ob das geht!
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: MJaap am Mi 04.08.2021, 17:44:41
Wie würde das ganze den aussehen wenn man Unterlinien  nimmt ? die sollten so Breit sein das sie durchgängig sind.   _______________________ wie das.

Die frage ist natürlich ob das geht!

Naja, im Prinzip sind die Menüeinträge ganz normale String-Objekte, die nur eben disabled sind. Du könntest da auch andere Zeichen verwenden (manche Anwendungen tun das auch  ::)) Das Problem beim Unterstrich ist eben, dass du nach oben dann so einen Riesenabstand hast. Eventuell ist der Unterstrich noch nicht mal durchgängig, je nach Font.

Ich hatte am Anfang meine Niceline falsch platziert, also quasi einen Unterstrich erzeugt. Die Menüs sahen durchlöchert und chaotisch aus.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Thorsten Otto am Mi 04.08.2021, 18:02:53
Die frage ist natürlich ob das geht!

Natürlich geht das, dazu musst du nur mal im RSC-Editor die "-" durch "_" ersetzen. Aber das ganze sieht ziemlich besch* aus, siehe unten. Erstens sind die nicht durchgängig, und zweitens ist der Strich dann halt auch nicht mehr in der Mitte.

BTW: die meisten Libraries benutzen keine gepunktete Linie, sonder eine durchgehende graue, wenn 16 Farben oder mehr verfügbar sind. Sieht auch meiner Meinung nach besser aus.

Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: MJaap am Mi 04.08.2021, 19:57:14
BTW: die meisten Libraries benutzen keine gepunktete Linie, sonder eine durchgehende graue, wenn 16 Farben oder mehr verfügbar sind. Sieht auch meiner Meinung nach besser aus.

Das ist tatsächlich keine Absicht - hatte übersehen, dass EmuTOS später nochmal mit einem Muster über den Bereich zeichnet, da der State Disabled bleibt.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Nervengift am Mi 04.08.2021, 21:01:07
Bin ich der einzige, dem der 3D Look des Falcon TOS oder des Milan TOS gefällt? ??? War 3D in TOS 4.x nicht auch abschaltbar?
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: MJaap am Mi 04.08.2021, 21:55:43
Bin ich der einzige, dem der 3D Look des Falcon TOS oder des Milan TOS gefällt? ??? War 3D in TOS 4.x nicht auch abschaltbar?

Ich mochte den 3D-Look erst, aber wenn viele 3D-Buttons in einem Dialog sind und der auch noch in der niedrigen Auflösung auf den Bildschirm passen soll, wirkt er sehr wuchtig - gerade im Vergleich zu MagiC. Zumindest in MagiC ist der 3D-Look leicht abschaltbar.

Nach der Enttäuschung mit dem STE und dessen TOS 1.06 fand ich den Falcon mit TOS 4.0 aber super.

BTW: die meisten Libraries benutzen keine gepunktete Linie, sonder eine durchgehende graue, wenn 16 Farben oder mehr verfügbar sind. Sieht auch meiner Meinung nach besser aus.

Ist jetzt durchgezogen - für den Preis einer weiteren IF-Abfrage. Der Code würde momentan aber aus jedem disabled String der mit "-" anfängt eine Linie machen.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Thorsten Otto am Do 05.08.2021, 06:00:02
Der Code würde momentan aber aus jedem disabled String der mit "-" anfängt eine Linie machen.

Müsste man sich nochmal anschauen. MIMRE, gab es durchaus Programme, die zwar einen "-" am Anfang, dann aber weiteren Text in den Strings hatten. In ORCS hatte ich jedenfalls extra mal 'ne Abfrage eingebaut daß wirklich der komplette String aus "-" besteht.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: gh-baden am Do 05.08.2021, 11:42:11
Bin ich der einzige, dem der 3D Look des Falcon TOS oder des Milan TOS gefällt? ???

Das wird sicher spätestens mit der zweiten Person, die sich meldet, zu widerlegen sein. :-)

Aber ich mag den Look nicht. Er ist von Atari inkonsistent designed worden an verschiedenen Ecken (nicht alle Elemente sind gleich „erhaben“ bspw.), sehr klobig/dick, und v.a. mit dem üblichen Zeichenraster, das GEM bei aller Grafikaffinität in der Praxis beim Gestalten von AES-Dialogen immer noch hat, schwierig umzusetzen, weil dann Abstände zwischen UI-Elementen nicht mehr passen, da die Elemente zu dick ausfallen.

Ist ähnlich der Farb-Icons die mit dem Falcon kamen. Juhu! Farbe! Booh, ein Farbeimer ausgeschüttet … hauptsache alles wurde bunt, aber ein Konzept war da nicht erkennbar.

Wenn man sich dagegen mal die Icons des frühen BeOS anschaut als Gegenbeispiel: so bekommt man eine Linie rein.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: gh-baden am Do 05.08.2021, 11:43:19
Müsste man sich nochmal anschauen. MIMRE, gab es durchaus Programme, die zwar einen "-" am Anfang, dann aber weiteren Text in den Strings hatten. In ORCS hatte ich jedenfalls extra mal 'ne Abfrage eingebaut daß wirklich der komplette String aus "-" besteht.

Ich muss aus der Erinnerung sagen, dass ich meine, damals RSC-Files in der Hand gehabt zu haben, wo der Menütrenner aus nur drei "-" bestand und dann expandiert wurde. Aber welches Programm das war, da muss ich passen.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: MJaap am Do 05.08.2021, 13:54:43
Hier die überarbeiteten Nicelines und die Groupboxes (MagiC kompatibel). Ich habe keine Ahnung, wie "schwer" die einzelnen Ergänzungen sind, also wie viel Bytes sie im ROM beanspruchen würden. Derzeit kompiliere ich immer die 512KB-Version, da gibt es noch für ganz andere Sachen Platz :-D

Die Groupboxes mochte ich vom Aussehen, allerdings gehörten die zu den MagiC-Ergänzungen, die nur dann gut aussehen, wenn das OS dieses Feature kennt.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Thorsten Otto am Do 05.08.2021, 14:28:24
wo der Menütrenner aus nur drei "-" bestand und dann expandiert wurde. Aber welches Programm das war, da muss ich passen.

Das wäre nicht so sehr das Problem. Die drei "-" sind wahrscheinlich nur dafür gedacht um ein paar bytes zu sparen.

Was ich meine sind Einträge wie "--- hier abschneiden ---" (wobei ich jetzt auch nicht mehr weiss  welches Programm das war). Wenn man die durch Nicelines ersetzt, ist der Text futsch.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: Thorsten Otto am Do 05.08.2021, 14:32:51
Ich habe keine Ahnung, wie "schwer" die einzelnen Ergänzungen sind, also wie viel Bytes sie im ROM beanspruchen würden.

Übersetze es einfach einmal mit, einmal ohne deine Änderungen. Am ende kommt immer eine Meldung:

# etos512de.img done (183660 bytes free)

Die Differenz sagt dir dann wieviel deine Änderungen beanspruchen ;)
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: MJaap am Do 05.08.2021, 16:49:34
Was ich meine sind Einträge wie "--- hier abschneiden ---" (wobei ich jetzt auch nicht mehr weiss  welches Programm das war). Wenn man die durch Nicelines ersetzt, ist der Text futsch.

Mein erster Gedanke war "Tempest" und ja, der Tempest Editor m macht das, ebenso Junior Prommer und Public Painter.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: MJaap am Do 05.08.2021, 17:56:14
Die Differenz sagt dir dann wieviel deine Änderungen beanspruchen ;)

600 Bytes für Nicelines, Dialogtitel und MagiC-Gruppenrahmen. Wird noch genauer aufgedröselt.

Nicelines "Edition Tempest" oder "Der ORCS Weg": Nicelines gibt es nur noch für Linien die komplett aus "-" bestehen. Geht besser, aber ansonsten muss Zeichen für Zeichen geprüft und gezeichnet werden.

Ich muss aus der Erinnerung sagen, dass ich meine, damals RSC-Files in der Hand gehabt zu haben, wo der Menütrenner aus nur drei "-" bestand und dann expandiert wurde. Aber welches Programm das war, da muss ich passen.

Klingt nach einer Komfortfunktion des Resource-Editors, damit nicht die Zahl der "-" abgezählt werden muss.
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: czietz am Mi 11.08.2021, 08:51:28
Hier die überarbeiteten Nicelines

Die Nicelines haben es unterdessen ins offizielle EmuTOS geschafft. Finde ich gut!
(Ab Snapshot (https://sourceforge.net/projects/emutos/files/snapshots/) 20210810-234939-959e03d1, 256k ROMs und aufwärts.)
Titel: Re: EmuTOS 1.1 erschienen
Beitrag von: MJaap am Mi 11.08.2021, 21:06:54
Der nächste Patch ist bereits eingereicht ("Dialog-Titel"). Mal sehen wie viel von meiner Liste ich umsetzen kann (d.h. fähig sein, es umzusetzen).