TOS Patchen

[Petari]

...
Ist doch gemacht worden, siehe EmuTOS.

Ich habe gewartet diese    Aber hier wir sprachen über original Atari TOS und wie machen es besser. Nicht über neue, alternative Lösungen.

[goetz @ 3rz]

...
Ist doch gemacht worden, siehe EmuTOS.

Ich habe gewartet diese    Aber hier wir sprachen über original Atari TOS und wie machen es besser. Nicht über neue, alternative Lösungen.

Nun die Grenzen dazwischen sind fließend. Denn Original-TOS kann es per Definition nur eins geben: das von Atari herausgegebene, im ROM. Alles andere ist eh verändert und nur noch API-kompatibel, aber eben nicht mehr 1:1 Original.

Ob man dann etwas patcht, viel patcht, massiv patcht oder mit gleicher API neu schreibt, sind dann nur noch graduelle Unterschiede, wenn man als Anker vorher gesetzt hat „Original ATARI TOS“.

[MJaap]

Milan Computer hat zumindest behauptet, damals TOS auf einen moderneren Compiler umgesetzt zu haben.

Das ursprüngliche TOS ist komplett umgestrickt und auf einem modernen Compiler neu kompiliert worden. Allein dadurch konnte es in seiner Größe verringert und beschleunigt werden.

(ST-Computer 02/98)

Ist mit etwas Skepsis zu sehen, die ST-Computer und die Atari Inside haben gerne einmal ein bisschen übertrieben...

[1ST1]

Ich habe gewartet diese    Aber hier wir sprachen über original Atari TOS und wie machen es besser. Nicht über neue, alternative Lösungen.

Wenn du original TOS verbesserst, was ist daran dann viel anders als EmuTOS. Es ist auch nicht mehr original. Original TOS 1.04 wurde schonmal verbessert, von Andreas Krohmke, das war KAOS TOS.

[1ST1]

Milan Computer hat zumindest behauptet, damals TOS auf einen moderneren Compiler umgesetzt zu haben.

Das ursprüngliche TOS ist komplett umgestrickt und auf einem modernen Compiler neu kompiliert worden. Allein dadurch konnte es in seiner Größe verringert und beschleunigt werden.

(ST-Computer 02/98)

Die wichtigste Frage dabei ist, welches TOS haben sie neu kompliert? Hat Milan den Quellcode von TOS 1.0x, 2.0x/3.0x oder was benutzt? Letzterer ist bekannt, hat sich wahrscheinlich inzwischen jeder gesichert. Mit welchem TOS läuft der Milan?

[MJaap]

Milan Computer hat zumindest behauptet, damals TOS auf einen moderneren Compiler umgesetzt zu haben.

Das ursprüngliche TOS ist komplett umgestrickt und auf einem modernen Compiler neu kompiliert worden. Allein dadurch konnte es in seiner Größe verringert und beschleunigt werden.

(ST-Computer 02/98)

Die wichtigste Frage dabei ist, welches TOS haben sie neu kompliert? Hat Milan den Quellcode von TOS 1.0x, 2.0x/3.0x oder was benutzt? Letzterer ist bekannt, hat sich wahrscheinlich inzwischen jeder gesichert. Mit welchem TOS läuft der Milan?

Ursprünglich hatte Milan mit dem TOS 3.0x geplant, dann aber das TOS 4.0x eingesetzt. Das sollte die Basis für "TOS 6" sein, wobei dies m.W. nur heiße Luft war. Das Milan-TOS erhielt einige Updates, u.a. mit dem Euro-Zeichen im Zeichensatz, wenn ich mich richtig erinnere wurden in einer der späteren Versionen auch einige der MagiC-Objekte unterstützt, aber zu dem Zeitpunkt hatte ich meinen Milan längst verkauft.

[Thorsten Otto]

Wenn Milan einen anderen Compiler benutzt hat, dann war es vermutlich Lattice C, so wie es Atari  (zumindest in Teilen) dann auch bei TOS 4.04 getan hat. Lattice hatte den Vorteil daß es die  gleichen Register-Konventionen benutzt, da brauchte man also nicht gross mit Assembler-Schnittstellen aufpassen. Ich weiss allerdings nicht wie gut der erzeugte Code war, aber schlechter als der von Alcyon kann er kaum gewesen sein.

Und soviel ich weiss basiert das TOS vom Milan auf TOS 4.x, während das vom Hades mehr oder weniger ein gepatchtes TOS 3.06 ist.

[1ST1]

Da kommt mir der Gedanke, wäre es nicht möglich, GCC die ganzen schmutzigen Tricks beizubringen, dass es TOS 2.06/3.06 "ordentlich" kompilieren kann?

[Thorsten Otto]

Wäre vlt. möglich, ja. Aber davon sind dann die ganzen anderen Probleme noch nicht beseitigt. Wenn man das alles verbessern will, ist das hinterher genauso wenig original Atari-TOS wie EmuTOS. Ich sehe da nicht so den grossen Sinn drin.

[Petari]

Natürlich ist das wann TOS ist gepatcht, es ist nicht mehr 100% original TOS. Trotzdem es ist schon TOS, und gross Teil - kann sein 99.99% is Gleich. Oder mit viel Patch 99% .
Wann TOS ist recompiliert nach anderungen es kann sein zum Beispiel 80%. Binary es kann sein 100% verschieden wegen alles ist auf diff. Adresse.
Ich weiss es nicht über Milan und andere 'high-end' Atari clone TOS-es - aber glaublich sie brauchte TOS C Quellen.  Aber das war nicht echt TOS verbesserung (Topic hier) - most wurde neu HW unterstützen als erste.

Andere Weg - disassemblieren, machen Anderungen im Asm, dann reassemblieren mit Optimizations ist was Ich habe gemacht.  Und Ich geseht Heute um Kaos TOS - was ist verbessert TOS 1.04 . Ich bin sicher das sie haben gemacht es gleich Weg. Zum beispiel FAT16 code ist gleich als im original TOS, mit 2 diff:  Short address optimization - wie  $3CD2.w statt $3CD2 - 2 bytes gespart. Addressen sind verschiedene, natürlich. Kein andere Erklarung - kein C Quellen für 1.04 . Oder, wenn es gewesen ware - welche Compiler könnte Sie brauchen im 1990 ? Was produziert gleich obj. code. , nur mit einige optimizations. Kein derartig.

KAOS TOS ist gut Beispiel hier: Ich glaube es ist um 95% original TOS 1.04 .

[Arthur]

Das modifizieren ist ein zweischneidiges Schwert. Man schließt dabei immer einen Kompromiss zwischen Funktionalität und Kompatibilität. Zum Glück funktioniert ein großer Teil der Programme unter verschiedenen TOS-Versionen aber einige negative Beispiele funktionieren ja nicht mal unter den original Atari TOS-Versionen wie z.B. TOS 1.0, 1.2 und 1.04. Wenn man es unter diesem Aspekt betrachtet ist das Flashtos 4x eine Super Idee gewesen.

[goetz @ 3rz]

KAOS TOS ist gut Beispiel hier: Ich glaube es ist um 95% original TOS 1.04 .

Dann wurden die richtigen 5% beschleunigt, denn das ist ja nur nicht nur ein Bugfix, das ist auch deutlich schneller als ein Original-TOS 1.04.

[ari.tao]

Ist KAOS-TOS frei verfügbar? Woo bekooom?

[1ST1]

Wer hat, der hat. Und jetzt ist es wieder Zeit für mich, abzutauchen! Viel Spaß noch!

[Thorsten Otto]

Hat hier jemand eine PAK? Ich frage, weil ich mir gerade die Kommentare zu den PAK spezifischen Änderungen in tospatch durchlese. Was mich irritiert ist, daß diese Patches nur in dem Archiv für TOS 3.06 vorhanden sind. Auch werden dort Zugriffe auf Hardware die nur beim TT vorhanden ist rausgepatcht (wie z.B. SCU), und die Blidschirmgrösse auf 32K gesetzt. Warum hat man denn dafür das TT-TOS genommen, und nicht 2.06?

[Lukas Frank]

Ich vermute wegen der PMMU bei der 030 CPU aber frage mal @pakman  ...

Das Atari TT konforme Fastram auf einer FRAK und auch FRAK/2 ist vielleicht ein zweiter Grund.

[czietz]

Vermutung: TOS 2.06 werden 68030-spezifische Dinge fehlen: MMU, Cache-Invalidierung, Fast-RAM-Unterstützung im Adressraum oberhalb 16 MB...

[tuxie]

Hat hier jemand eine PAK? Ich frage, weil ich mir gerade die Kommentare zu den PAK spezifischen Änderungen in tospatch durchlese. Was mich irritiert ist, daß diese Patches nur in dem Archiv für TOS 3.06 vorhanden sind. Auch werden dort Zugriffe auf Hardware die nur beim TT vorhanden ist rausgepatcht (wie z.B. SCU), und die Blidschirmgrösse auf 32K gesetzt. Warum hat man denn dafür das TT-TOS genommen, und nicht 2.06?

Weil die Pak eher einem TT entspricht als einem ST, auch wenn darunter ein ST sitzt. Aber das TOS3.06 läuft wesentlich effektiver auf der Pak, ganz besonders wegen den ganzen Erweiterungen wie TT-RAM, 68030 spezifische dinge usw.

[Thorsten Otto]

Ja, aber wegen den ganzen Erweiterungen (von denen z.B. die 8-plane VDI Routinen gar nicht gebraucht werden), passt das nicht mehr in 256k ROM. Sitzen denn da 512k EPROMs drauf? Und war da nicht auch ein umschaltbares 2.06 drauf, das nur die original 68000 CPU nutzt? Etwas irritiert....

[czietz]

Wegen der 32-bittigen Anbindung der ROMs an die CPU müssen auf die PAK/3 sowieso 4 EPROMs, die ROMs im ST können nicht dafür genutzt werden. Wo ist also das Problem, dass nun 512k nötig sind?
http://www.wrsonline.de/pak3.html