Autor Thema: EmuTOS 1.1 erschienen  (Gelesen 3801 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline Chocco

  • Benutzer
  • Beiträge: 193
  • May the force be with you
Re: EmuTOS 1.1 erschienen
« Antwort #20 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!
Atari TT030 mit CrazyDots
Milan 060 (ATI Rage Pro)
Apple MBP

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 978
Re: EmuTOS 1.1 erschienen
« Antwort #21 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 ;)

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 978
Re: EmuTOS 1.1 erschienen
« Antwort #22 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.

Offline czietz

  • Benutzer
  • Beiträge: 2.800
Re: EmuTOS 1.1 erschienen
« Antwort #23 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!

Offline Chocco

  • Benutzer
  • Beiträge: 193
  • May the force be with you
Re: EmuTOS 1.1 erschienen
« Antwort #24 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.
Atari TT030 mit CrazyDots
Milan 060 (ATI Rage Pro)
Apple MBP

Offline SH

  • Benutzer
  • Beiträge: 44
Re: EmuTOS 1.1 erschienen
« Antwort #25 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

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 978
Re: EmuTOS 1.1 erschienen
« Antwort #26 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.).

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 978
Re: EmuTOS 1.1 erschienen
« Antwort #27 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 ;)

Offline Nervengift

  • Benutzer
  • Beiträge: 1.489
Re: EmuTOS 1.1 erschienen
« Antwort #28 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
520 ST(M) (TOS 1.02), Falcon030 (16 MHz, 16 MB RAM, CF-Karte, MiNT & MyAES), Milan040 (25 MHz, 48 MB RAM, EasyMiNT 1.90), Firebee (2nd Edition), PowerMac G5 Late 2005 (2 x 2,3 GHz, Mac OS 10.5), iMac 4K Late 2015 (intel Core i7 4 x 3,3 GHz, Mac OS 10.11.6), IBM XT SFD (640 KB RAM, DR DOS 6.0), Compaq LTE 5300 (Pentium/133 MHz, DR-DOS 7.03), AT-PC (Cyrix 6x86L/200 MHz, Windows 98 SE/MS-DOS 6.22 & Windows 3.11)

Offline MJaap

  • Benutzer
  • Beiträge: 1.436
  • ST-Computer
Re: EmuTOS 1.1 erschienen
« Antwort #29 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 :(

Offline Count

  • Benutzer
  • Beiträge: 200
Re: EmuTOS 1.1 erschienen
« Antwort #30 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.

Offline gh-baden

  • Benutzer
  • Beiträge: 1.623
Re: EmuTOS 1.1 erschienen
« Antwort #31 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.
Wider dem Signaturspam!

Offline gh-baden

  • Benutzer
  • Beiträge: 1.623
Re: EmuTOS 1.1 erschienen
« Antwort #32 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).
Wider dem Signaturspam!

Offline mfro

  • Benutzer
  • Beiträge: 1.549
Re: EmuTOS 1.1 erschienen
« Antwort #33 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.
And remember: Beethoven wrote his first symphony in C

Offline kernal

  • Benutzer
  • Beiträge: 42
Re: EmuTOS 1.1 erschienen
« Antwort #34 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.

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 978
Re: EmuTOS 1.1 erschienen
« Antwort #35 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...


Offline mfro

  • Benutzer
  • Beiträge: 1.549
Re: EmuTOS 1.1 erschienen
« Antwort #36 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.

And remember: Beethoven wrote his first symphony in C

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 978
Re: EmuTOS 1.1 erschienen
« Antwort #37 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 ;)

Offline Thorsten Otto

  • Benutzer
  • Beiträge: 978
Re: EmuTOS 1.1 erschienen
« Antwort #38 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.

Offline KarlMüller

  • Benutzer
  • Beiträge: 374
Re: EmuTOS 1.1 erschienen
« Antwort #39 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.