atari-home.de - Foren
Software => Software (16-/32-Bit) => Thema gestartet von: Atariosimus am Do 10.01.2019, 17:53:51
-
Da gibt es ja diesen schönen TOS Patch Pakete im Netz. Eins heisst TP206V38
ein anderes TP206V40.
Ich verstehe nur nicht wie die Patche in die TOS.IMG reinkommen.
Die Image Datei von TOS erstellen geht gut mit Drag and Drop von Reloc206.fil auf Tospatch.ttp
Jetzt ist ein TOS.IMG da und was nun? Das soll ja an verschiedenen Stellen geändert werden.
Die Patche stehen in der 206_Rel.fil drin, die beliebig mit einem Texteditor geändert werden kann.
Aber wie bringt man die beiden Dateien nun zusammen?
Es gibt noch zwei Programme wie Autoconf.prg und Auto_206.prg.
Reicht reicht das einfach Autoconf.prg aufzurufen und dann Auto_206.prg zu laden
und dann wird so ein Patch "gebacken"?
Wer hat das schon mal gemacht?
-
Meinst du das hier? https://www.markusheiden.de/atari/tospatch.html
-
ja, genau diese.
-
Da gehört ein Programm dazu, was diese Patchdateien interpretiert. TosPatch.TTP V2.98 (aktuelle Version vom 11.07.1999)
Ist auf der Seite, das unterste. Wie das funktioniert, kann ich erfragen. Vielleicht weiß ER es noch. Bestimmt...
šbersicht zu TOSPATCH V2.9.8:
===============================
Bei dem TTP ist ein Readme dabei.
-
Anleitungstexte sind doch dabei und der Rest erklärt sich aus dem *.FIL File doch von selber.
-
Aus dem Patch Paket geht das leider nicht eindeutig hervor. Aber der Hinweis von 1St1
könnte die Lösung sein. Muss da mal reinsehen.
-
Bei tp298.lzh handelt es sich um eine neuere Version. Leider werd ich aus der Beschreibung
auch nicht richtig schlau. Schade das kein Beispiel beigefügt ist, das würde helfen.
-
Steht doch alles da ...
;*******************************************************************************
;* MRF:
;* Ausgabeformat des Patchprogramms
>1 3C0000 ;eine Datei (TOS.IMG) fr Adresse $3C0000 erzeugen
; bitte daran denken: Obere Ramgrenze - TOS-Lnge (normalerweise = $40000)
; 4MB-Rechner: $3C0000
; 3MB-Rechner: $2C0000
;2.5MB-Rechner: $240000
; 2MB-Rechner: $1C0000 ;Mit weniger als 2MB Speicher macht es eigenlicht
; 1MB-Rechner: $0C0000 ;keinen Sinn mehr, TOS 2.06 im Ram zu halten -
;0.5MB-Rechner: $040000 ;auer vielleicht zum Testen der Patches!
;>1 ;eine nicht relozierte Datei (TOS.IMG) erzeugen
;* auch mglich: 2, 6 oder 8 Dateien, um neue EPROMs zu brennen
;* dazu mu ">2", ">6" bzw. ">8" angegeben werden
;*******************************************************************************
... einfach ausprobieren.
-
Schiebe ich die Datei nun einfach so drauf auf Tospatch.ttp oder muss
man da noch eine bestimmte Anweisung beifügen?
Mal die 206_rel.fil auf das Patchprogramm geschoben.
Kommt eine Fehlermeldung ...STE_TOS.IMG...Fehler
Scheint so als ob man nur in der Datei .FIL was ändern muss mit einem Textprogramm.
Ein Image vom Original TOs muss im gleichen Ordner liegen und dann diese Datei
auf das Patchprogramm schieben.
Die Fehlermeldung muss jetzt noch weg.
-
Unter TOS 2.06 einfach 206_REL.FIL auf das TOSPATCH.TTP ziehen und loslassen. Beim TOS 1.04 TOSPATCH.TTP starten und in der Befehlszeile den Pfad zu 206_REL.FIL angeben.
Vorher das STE_TOS.IMG in den Ordner kopieren und das 206_REL.FIL so anpassen wie man es haben möchte.
-
Mit AUTO_206.PRG im AUTO Ordner ausprobieren bevor man es in Eproms brennt.
-
Unter TOS 2.06 einfach 206_REL.FIL auf das TOSPATCH.TTP ziehen und loslassen.
Da kommt leider immer eine Fehlermeldung. Vom Grundsatz muss es jedoch so gehen.
Das Programm verknüpft dann das Original TOS mit dem .FIL
-
Alles so in dem Ordner lassen wie es ist. Lies mal 206_REL.FIL durch. Es erwartet ein original TOS 2.06 in Deutsch mit dem Namen STE_TOS.IMG ...
-
Das war ein sehr guter Tip. Jetzt gehts. Vielen Dank Frank ;D
-
Mit dem TP298 traten drei Fehler auf: Bei FASTPR3, Bios1 und noch bei Zeile 618 eine Pfadangabe.
TP206V38/V40 laufen beide anstandslos durch. TOS.IMG wird im selben Ordner gespeichert.
So läuft es zumindest mal schön durch. Eine TOS.IMG (der Patch) wird im Wurzellaufwerk also oberste Ebene automatisch gespeichert nur TP298 mit .FIL aus TP206V38.
Die Frage ist jetzt wo findet man weitere Patche ausser denen die in der FIL Datei schon
enthalten sind?
Supertos UK in deutsch wäre was interessantes. Oder Magic...
-
Wenn du TOS 2.06 patchen möchtest, wäre es doch eigentlich besser, direkt an die C-Quellen zu gehen und da zu patchen, und das neu zu kompilieren. Es existiert und es schwirrt herum, und es wurde darüber diskutiert...
-
Tja, ich bin da eher Anwender und halte das auch in C als nicht so einfach. Ein bisschen
rumprogrammieren ist ganz nett, nur wenn man es verschlimmbessert ist mir der Weg
im Augenblick lieber. Quasi Modulbauweise von funktionierenden Teilen.
-
Wenn du TOS 2.06 patchen möchtest, wäre es doch eigentlich besser, direkt an die C-Quellen zu gehen und da zu patchen, und das neu zu kompilieren. Es existiert und es schwirrt herum, und es wurde darüber diskutiert...
Könnte man theoretisch machen, aber dann müsste man die Patches die dort gemacht werden erstmal verstehen, und wieder in C-Code (oder möglicherweise sogar Assembler) umsetzen. Da die Patches bereits fertig sind, ist es vermutlich einfacher das Programm zu verwenden.
-
...Patches die dort gemacht werden erstmal verstehen,...
Das ist der Punkt. wäre ich Starhacker würde ich das glatt machen. :D
-
Na dann werde einer.
Wenn du das TOSPATCH Tool verstehen willst, musst du dich eh mit dem Thema befassen.
-
TOSPATCH hatte ich vor Ewigkeiten mal verwendet, um ein "TOS 2.08" zu patchen - mit Winx-Patch, neuer Versionsnummer und Pinguin-Icons.
-
TOSPATCH hatte ich vor Ewigkeiten mal verwendet, um ein "TOS 2.08" zu patchen - mit Winx-Patch, neuer Versionsnummer und Pinguin-Icons.
Ich hatte in einem Parallelthread mal nach genau dem (ohne die Pinguine :) gefragt. Hast du die Rezeptur noch? Denn die TP-Archive beinhalten ja nur ein uraltes WINX, spannend wäre da etwas aktuelles.
-
Das ganze Trick mit Patchen ist ahnlich mit Kleidungen - herausschneiden was wie möchten zu wechseln.
Naehen dort neu Teilen. Und kann nicht nur dort, kann auf andere, frei Platzen. Kann machen alles mit hex-Editor. Aber es ist schwer. Wegen das sind Patch Programmen. Normal das brauchen exact TOS Version.
Heute ist möglich zum testen sehr gut, ohne EPROM brennung - Emulator :)
-
Wenn du TOS 2.06 patchen möchtest, wäre es doch eigentlich besser, direkt an die C-Quellen zu gehen und da zu patchen, und das neu zu kompilieren. Es existiert und es schwirrt herum, und es wurde darüber diskutiert...
Ich verainbare absolut. Das ist was Ich vorschlagte auf exxos forum, atariage forum. Und nichts über 7 Monaten. Warum ? Ich glaube diskutieren ist einfacher :) Wie motivieren Leute für einige schwer Arbeit ?
-
TOSPATCH erlaubt dem User aber für jeden einzelnen Patch auszuwählen, ob du ihn im ROM haben möchtest oder nicht. Durch ändern der Sourcen ist das nur sehr viel schwieriger zu erreichen, dazu müsste man defines verwenden, und der User müsste dann die Quellen selber übersetzen. Nicht alle haben die notwendigen Werkzeuge dafür.
-
Nicht alle haben die notwendigen Werkzeuge dafür.
...und die Kenntnisse diese auch anzuwenden.
Die Idee ist jedoch sehr gut, weil man damit auch diese ganzen Copyright Probleme umgeht.
Ich muss zugeben, mehr als in den Anweisungen wie vorgegeben
zu ändern ist mir nicht möglich.
Wie man da jetzt zusätzlich weitere Patches kreiert ist mir völlig fremd.
Ein kleiner Verweis auf eine interessante Seite. Den Patch probiere ich gerade in Steem und
nach anfänglichen Schwierigkeiten im Einrichten läuft der vorzüglich.
Der Patch in dem Thread ist von einem TOS 306 für den STE entwickelt worden und in englisch.
https://www.exxoshost.co.uk/forum/viewtopic.php?f=19&t=1174&start=10 (https://www.exxoshost.co.uk/forum/viewtopic.php?f=19&t=1174&start=10)
-
Die Idee ist jedoch sehr gut
weil man damit auch diese ganzen Copyright Probleme umgeht.
Und was bringt dich auf die Idee daß Binaries einem Copyright unterliegen, Sourcen aber nicht ? ;)
Das würde die Sache eher noch viel problematischer machen.
Ich muss zugeben, mehr als in den Anweisungen wie vorgegeben
zu ändern ist mir nicht möglich.
Mehr sollte ja auch nicht nötig sein. Man könnte da theoretisch auch ein Gem-Programm vorschalten, wo man die nötigen Einstellungen vornimmt und das dann eine Konfigurations-Datei oder sowas erzeugt. Wäre natürlich nochmal extra Arbeit.
Es gibt aber auch noch ein anderes Problem: Das übersetzen der Sourcen dauert auf einem "nackten" STE laut Angabe von Troed aus dem englischen Forum ca. 2 1/2 Stunden. Da kommt nicht viel Spass auf, wenn mittendrin ein Fehler auftritt und man wieder von vorne anfangen muss.
-
TOS 4.04 patchen für ST(E) ist sehr schlimm Idee .
Nutürlich, es ist nicht unmöglich, aber zuviel Modifikazion ist benötigt.
Patchen 3.06 ist nicht gut Idee auch - 2.06 ist equ. mit es, und bereit für ST, STE, Mega STE.
Und 4.04 ist 512 KB statt 256 KB , was meinst das HW mod. ist benötigt auch.
Aber, das ist nicht 4.04 mod - sage Ich nach sehen es besser ... Es ist 2.06 mod.
Complete mess - was zu sagen ? Exxos und troed sind idioten :)
Und etwas mehr: Ich bin wo programmiert nach exxos Frage fast boot TOS 2.06 patch, viele Jahren früher. Überspringen langsam RAM Test, ROM CRC Test ... Es ist nicht normal wie einige Leute missachten ... Oder besser sagen: die strietzen >:(
-
Die Patches kann man ja weitergeben nur das gesamte TOS nicht.
Ich werde jetzt mal von https://www.exxoshost.co.uk/forum/viewtopic.php?f=19&t=1174&start=10 (https://www.exxoshost.co.uk/forum/viewtopic.php?f=19&t=1174&start=10)
das ste pal Ding brennen und in den Rechner einsetzen.. Wenn es gut funktioniert vielleicht
die Übersetzung versuchen.
-
Der Patch in dem Thread ist von einem TOS 306 für den STE entwickelt worden und in englisch.
Ich lese da nur was von einem TOS 4.04 für STE, und das scheint zudem noch ziemlich buggy zu sein.
-
Ich meine diesen Link http://d-bug.mooo.com/various/tos_ste_fastboot_pal.rom (http://d-bug.mooo.com/various/tos_ste_fastboot_pal.rom)
Dieses TOS lässt sich in Steem betreiben.
-
Ja stimmt, ich hab das mit diesem Link verwechselt. http://www.atari-forum.com/viewtopic.php?f=16&t=31243&hilit=tos+patch&start=50 (http://www.atari-forum.com/viewtopic.php?f=16&t=31243&hilit=tos+patch&start=50)
-
Ich meine diesen Link http://d-bug.mooo.com/various/tos_ste_fastboot_pal.rom (http://d-bug.mooo.com/various/tos_ste_fastboot_pal.rom)
Dieses TOS lässt sich in Steem betreiben.
Natürlich - wegen es ist modifiziert TOS 2.06 - nur Desktop von 4.04 ist was ist von 4.04 ;D
-
...und ist das gut oder Crap?
Sieht in Steem jedenfalls gut aus.
-
Im Rechner funktioniert es nicht. Bekomme nichtmal einen Startbildschirm. :-[
Jetzt hab ich doch glatt ein falsches ROM gebrannt alles nochmal von vorne >:(
-
Unter Hatari MSTE/8Mhz/68000/4MB geht es. TOS Info ist TOS 2.16 aber unter 16 Farben sehe ich keine Farbicons ...
STE geht auch aber ST usw. nicht.
-
...stimmt unter 16 Farben geht nicht. Auch der Kompatibilitätsmodus holft da nicht weiter.
Bei Campus findet er keine RSC Dateien. Mit TOS 2.06 geht alles einwandfrei.
Papillon 304 geht auch nicht.
Bei Stad 1.2 sucht er auch die RSC Dateien.
Auch Gemini 1.a geht nicht. wieder die RSC Dateien.
Jedenfalls scheint es damit Probleme zu geben RSC Dateien aufzurufen.
-
Für Farbicons sind die 256k wahrscheinlich zu klein ...
-
...die 4 sollte das Ding allerdings schon können.
Hm, sieht nach "Verschlimmbesserung" aus.
-
4 Farben gehen auch. Konnte endlich das EPROM brennen. :D
Festplatten werden leider nicht erkannt.
Geht auch interlaced. Zittert alles nur ein wenig
-
ST High geht nicht. Egal ob man die Monitorbuchse von Color auf schwarz/weiss umstellt.
IDCheck geht auch nicht. Steem kann da irgendwie mehr.
Alles in allem recht bescheidene Angelegenheit. Interessant ist die Bildauflösung bei 80 Columns
und 4 Farben. Ist einfach vielmehr Platz auf dem Bildschirm. Die Graphiken sind auch schön
anzusehen. Wenn man das auf ein TOS 2.06 richtig übertragen könnte wäre das schon klasse.
-
ST high kann nur an einem SM124 gehen. Oder einem TFT mit Monochromadapter.
-
Bei mir ist ein Umschalter von Olivier Gossuin dran mit dem man von Color auf S/W wechseln kann.
Da geht nichts muss Dich da leider enttäuschen.
True Color und 256 Colors sind ebenfalls nicht machbar. Dazu braucht man vielleicht eine Videokarte.
-
Irgendwie kommen da mehr Auflösungen zustande wie man hier sieht.
-
TOSPATCH hatte ich vor Ewigkeiten mal verwendet, um ein "TOS 2.08" zu patchen - mit Winx-Patch, neuer Versionsnummer und Pinguin-Icons.
Ich hatte in einem Parallelthread mal nach genau dem (ohne die Pinguine :) gefragt. Hast du die Rezeptur noch? Denn die TP-Archive beinhalten ja nur ein uraltes WINX, spannend wäre da etwas aktuelles.
Wenn ich mich richtig erinnere, hatte ich damals nur die Rezeptur für die Versionsnummer hinzugefügt, der Rest waren die Patches, die ohnehin in TOSPATCH definiert waren.
Ja stimmt, ich hab das mit diesem Link verwechselt. http://www.atari-forum.com/viewtopic.php?f=16&t=31243&hilit=tos+patch&start=50 (http://www.atari-forum.com/viewtopic.php?f=16&t=31243&hilit=tos+patch&start=50)
2015 noch kein ST-Computer-Abo gehabt? In der 08/15 wird TOS 2.16 kurz vorgestellt. Leider gab es keine weiteren Updates.
-
In der 08/15 wird TOS 2.16 kurz vorgestellt. Leider gab es keine weiteren Updates.
Nachdem ich das tos_ste_fastboot_pal.rom jetzt im Rechner gestern testen konnte ist mein Fazit:
Ganz nett aber so nicht wirklich brauchbar für real Maschinen, da es weder Festplatten erkennt
noch die Bildschirmdarstellung in High darstellen kann. Abgesehen von den RSC Problemen.
Kann man nur was auf einem Emulator anfangen.
-
Da sind zu viel Problemen mit. Kann nicht starten mein Eprom Brenner SW - es sagt das kein RSC Datei, wann es ist da ...
So, after kurz Test - vergessen ...
-
Hallo Petari,
ich würde das tos_ste_fastboot_pal.rom als Crap bezeichnen.
Das sind wirklich zu viel Probleme. Hat sich jemand ausgedacht
ohne jemals auf Rechner getestet zu haben.
-
[Ganz nett aber so nicht wirklich brauchbar für real Maschinen, da es weder Festplatten erlennt
Wenn sie nicht gerade einen Festplatten-Treiber eingepatcht haben, kann man das auch kaum erwarten. Ausser zum booten hat TOS noch nie einen eingebauten Treiber gehabt. Aber die anderen Fehler hören sich natürlich nicht so vielversprechend an.
-
Getauscht wurde ja nur das ROM. Deshalb bin ich davon ausgegangen, das zumindest
der vorhandene Treiber auf der Festplatte genutzt wird. Ist der neueste von Seimet.
Nur tut das ROM das nicht.
-
In der 08/15 wird TOS 2.16 kurz vorgestellt. Leider gab es keine weiteren Updates.
Nachdem ich das tos_ste_fastboot_pal.rom jetzt im Rechner gestern testen konnte ist mein Fazit:
Ganz nett aber so nicht wirklich brauchbar für real Maschinen, da es weder Festplatten erkennt
noch die Bildschirmdarstellung in High darstellen kann. Abgesehen von den RSC Problemen.
Kann man nur was auf einem Emulator anfangen.
Manche Cracks stürzen ja auch bei Level 14 ab, weil die Cracker nie soweit gespielt haben ;)
Es ist meiner Einschätzung nach eher ein "proof of concept" und irgendwann wird vielleicht auch EmuTOS 3D-Look und Farbicons haben. Die neuen AES-Objekte von TOS 4.x werden von Programmen ohnehin kaum (nicht?) genutzt.
-
[Die neuen AES-Objekte von TOS 4.x werden von Programmen ohnehin kaum (nicht?) genutzt.
Ja, weil es so, wie es implementiert ist, auch nicht grossen Sinn macht. Wenn sie nicht vorhanden sind, braucht man Fallbacks, oder das Programm läuft dann *nur* noch auf TOS >= 4. Da kann man sich die Abfragerei sparen und gleich die eigenen Routinen nehmen. Man h#tte damals ein Programm gebraucht, das die neuen Möglichkeiten auch für ältere TOS-Versionen nachrüstet, ähnlich WDIALOG, dann hätten das vlt. mehr Leute benutzt.
-
Pack doch mal den Plattentreiber auf eine Diskette in den Autoordner und starte ihn so. Dahinter kannst du ja cauro.prg legen, dann bootet das System den Rest von der Platte.
Vielleicht braucht die ganze Patcherei so viel Platz, dass man den Bootcode rausgeschmissen hat?
Worum geht es denn eigentlich letztendlich? Den Desktop vom Falcon auf dem MegaSTE zu haben?
-
TOS 2.06 ist doch gut genug. Ein TOS 3.06 mit den Farbicons vom TOS 4.04 macht doch mehr Sinn da so ein Atari TT von Haus aus schon Farbe kann.
-
Worum geht es denn eigentlich letztendlich? Den Desktop vom Falcon auf dem MegaSTE zu haben?
Um zu zeigen, dass es geht. Darum geht's auch letztlich Demo-Codern und Crackern. "Sinnvoll" ist der 3D-Look ohnehin erst ab dem TT, wenn nicht gerade eine Grafikkarte im MegaSTE steckt. Wer Farbicons auf dem MegaSTE sehen möchte, ist mit ColorTOS besser bedient.
Ja, weil es so, wie es implementiert ist, auch nicht grossen Sinn macht. Wenn sie nicht vorhanden sind, braucht man Fallbacks, oder das Programm läuft dann *nur* noch auf TOS >= 4. Da kann man sich die Abfragerei sparen und gleich die eigenen Routinen nehmen. Man h#tte damals ein Programm gebraucht, das die neuen Möglichkeiten auch für ältere TOS-Versionen nachrüstet, ähnlich WDIALOG, dann hätten das vlt. mehr Leute benutzt.
MultiTOS ;) Aber zu der Zeit hatten Entwickler ohnehin angefangen, eigene Routinen zu verwenden, runde Radiobuttons und Tastaturbedienung für Dialoge hat auch das Falcon-TOS nicht.
-
Mal 'ne andere Frage bzgl. TOSPATCH:
;* Stackpointer bei Autoexec korrigieren (siehe ST-Computer 1/90)
;* Fast-Load-Bit für schnelleres Laden (siehe ST-Computer 1/90)
Weiss jemand was damit genau gemeint ist? In der Online-Version finde ich da keinen Artikel zu.
-
;* Stackpointer bei Autoexec korrigieren (siehe ST-Computer 1/90)
Zitat aus dem Artikel:
Eine falsche Stackkorrektur in der Routine, die Auto-Ordner-Programme ausführt, konnte unter ungünstigen Umständen zu Abstürzen führen.
Die gepatche Routine wird mit autoexec bezeichnet. Eine weitere Erklärung gibt es nicht. Eine Quelle wird nicht angegeben.
;* Fast-Load-Bit für schnelleres Laden (siehe ST-Computer 1/90)
[/code]
FDC-Befehl Seek Track. Also der FDC sucht den Sektor konntrolliert ihn aber nicht. Normalerweise steht dort "moveq 0x14,d6" Seek mit Verify. Ist mit vorsicht zu nutzen, denn es kann zu vermehrten Fehler kommen das ein Sektor nicht korrekt gefunden werden kann.
Steht so auch im Buch "Scheibenkleister II" (Seite 248).
-
Weiss jemand was damit genau gemeint ist? In der Online-Version finde ich da keinen Artikel zu.
In dieser STC ist ein ganzer Artikel zu TOS-Patches. Anbei ein Auszug.
-
Danke euch! (bin ich eigentlch blind oder ist dieser Artikel online nicht verfügbar?)
-
Danke euch! (bin ich eigentlch blind oder ist dieser Artikel online nicht verfügbar?)
Das ist anscheinend leider bei vielen (den Meisten?) Artikeln der Fall, die irgendwas mit Coding zu tun haben.
-
In dieser STC ist ein ganzer Artikel zu TOS-Patches. Anbei ein Auszug.
Welche Ausgabe ist denn das?
-
Stand in meiner Frage weiter oben, 1/90
-
Ah, danke sehe das es auf Seite 134 steht. Zum Glück hab ich das Heft noch nicht im Karton
verpackt.
-
Danke euch! (bin ich eigentlch blind oder ist dieser Artikel online nicht verfügbar?)
Das ist anscheinend leider bei vielen (den Meisten?) Artikeln der Fall, die irgendwas mit Coding zu tun haben.
Die Coding-Artikel sind in der Korrektur am aufwendigsten, in den letzten Wochen sind aber viele Artikel aus den Bereichen Grundlagen und Programmierpraxis hinzugekommen.
-
Danke euch! (bin ich eigentlch blind oder ist dieser Artikel online nicht verfügbar?)
Das ist anscheinend leider bei vielen (den Meisten?) Artikeln der Fall, die irgendwas mit Coding zu tun haben.
Die Coding-Artikel sind in der Korrektur am aufwendigsten, in den letzten Wochen sind aber viele Artikel aus den Bereichen Grundlagen und Programmierpraxis hinzugekommen.
Das war nicht als Gequengel gedacht, sorry - ich weiß, daß da Etliches an Arbeit drinsteckt. Danke dafür!
-
Das waren jetzt alles Patche für TOS 1.04.
Gibt es auch noch welche für 2.06 in STComputer?
-
Das waren jetzt alles Patche für TOS 1.04.
Gibt es auch noch welche für 2.06 in STComputer?
Ich finde keine. Liegt vielleicht auch daran, dass 1.04 weiter verbreitet war und der Anteil an Coding-Artikeln später zurückgefahren wurde.
Das war nicht als Gequengel gedacht, sorry - ich weiß, daß da Etliches an Arbeit drinsteckt. Danke dafür!
Habe ich auch nicht so verstanden. Ich seh's ja (dank Gerhard Stolls Liste) selbst, dass ca. 360 Artikel aus den Bereichen Grundlage, Programmierpraxis und Projekten fehlen. Über die Entscheidung der STC-Layouter, Listings grundsätzlich in einem Font zu layouten, bei dem sich 0 und O und 1, I und l kaum unterscheiden lassen, könnte man aber quengeln. Von fehlenden Artikeln vor 09/1991 nehme ich auch gerne (gute) Scans entgegen.
-
Das waren jetzt alles Patche für TOS 1.04.
Gibt es auch noch welche für 2.06 in STComputer?
Der autoexec-Bug ist auch noch in 2.06/3.06 vorhanden, deswegen ja auch der Patch im Tospatch-Script.
-
Kennt jemand die Patches für das Supertos UK, gibt es da Quellen was genau gepatcht wurde?
-
Ganz genau kann ich es (noch) nicht sagen, aber BIOS, VDI und GEMDOS sind auf jeden Fall unverändert. Hat also mit den Patches aus dem TOSPATCH Archiv nichts zu tun.
-
Wenn man diese Patchliste so durchgeht sind die meisten Dinge doch eher kosmetischer Art.
Ob ich nun ein anderes Logo habe oder der Rechner schneller startet ist Geschmacksache.
Die wirklich gravierenden Sachen, also da wo schlicht Fehlfunktionen vermieden werden
sind an einer Hand abzuzählen.
-
Also ich zähle da mindestens 10-12 Bugfixes, das ist schon nicht wenig. Dazu noch einige Einstellungs-Sachen, für die man sonst separate Programme benötigen würde. Und einige echte Verbesserungen, wie schnellere Druckroutine und natürlich WinX.
-
Auch bei TOS 2.06?
Ich versuche gerade eine Zusammenstellung von Patches die wirklich Fehler
korrigieren.
Die anderen sehe ich mehr als Geschmackssache, die man haben kann aber nicht muss.
-
Es ist normal das TOS 1.04 hat mehr zum Patchen als 2.06 (was ist Patch von 2.05 :) ) .
Was ist mehr important zum Patchen ist Subjektiv . Und natürlich anfangt von was SW benutzer lauft.
Problem mit TOS sind nicht nur bugs - und 1.04 ist sehr gut mit das im normal benutzung. Ich sehe als groser problem wie es ist compiled. Da sind seriös Fehlern wegen limitiert compiler (Alcyon) gebraucht.
Zum Beispiel: warum Line-F Emulation war benötigt ? Wegen das ohne es, TOS 1.xx würde nicht passen im 192 KB ROM Bereich. Mit Line-F es ist um 6-7 KB Platz gespart, und Preise ist bissele langsamer Arbeit. + kann nicht laufen mit 68010-30 CPU. Nur wann STE war konzipiert die könnte machen es ohne Line-F - 256 KB Platz. Warum nicht gleich am Anfang ? ROM Preisen im 1985, natürlich.
Aber, mit bessere compiler TOS 1.xx code könnte kurzer sein für 6-7 KB. plus mit einfach Datei paken von RSC könnte sparen andere 6 KB .
Ander gross problem war compiler limitation: not able to work (properly) with unsigned 16 and 32 bit variables.
Und Problem existiert im 1989 auch - was ist schwer zum verstehen.
Und ich glaube auch im 1991 - TOS 2.xx ist noch immer mit 15-bit FAT . Warum Ich sage 15-bit FAT ?
Bit 16 ist sign :)
Alles im Alles, patchen ist nicht so schwer, und ist sinnvoll. Aber echte Problemen mit TOS sind tiefer, und kann nicht korrigieren mit Patchen.
-
Auch bei TOS 2.06?
Du meinst WinX? Ja. Wenn ich nichts übersehen habe, werden in 2.06 im wesentlichen die gleichen Patches gemacht wie in 3.06, ausser ein paar die nur in 3.06 Sinn machen.
-
Ich meinte ob bei TOS 2.06 auch so viele Patches vorhanden sind.
@Petari, wenn Patchen nicht soviel bringt und der Compiler damals nicht so optimal war.
Geht das denn nicht mit einem modernen Compiler?
Kenn mich da leider zu wenig aus.
Aber nochmal zurück. Interessant sind die Patches für mich, die echte Fehler beheben.
Wie z.B. die Stackkorrektur (Patch 3).
-
Ich meinte ob bei TOS 2.06 auch so viele Patches vorhanden sind.
Ja, wie gesagt, sind die gleichen wie in 3.06.
Geht das denn nicht mit einem modernen Compiler?
Nein, das geht nicht so ohne weiteres. Pure-C fällt sowieso schon mal aus wegen der komplett anderen Parameter-Übergabe, und auch für gcc wird bei den Assembler-Teilen an zu vielen Stellen von der Annahme ausgegangen daß d2/a2 nicht gesichert werden müssen. Die Stellen alle zu finden wäre ne Mörder-Arbeit. Abgesehen davon daß die Quellen von denen wir hier sprechen nicht frei sind. Ausserdem hat man fast das gleiche Ergebnis auch mit EmuTOS.
Interessant sind die Patches für mich, die echte Fehler beheben.
Wie z.B. die Stackkorrektur (Patch 3).
Eigentlich behebt das überhaupt keinen Fehler. Zwar wird der Stackpointer dort nach einem Trap-Aufruf nicht richtig korrigiert, aber die Routine endet sowieso damit daß der auf das Ende des Supervisor-Stacks gesetzt wird.
-
...
@Petari, wenn Patchen nicht soviel bringt und der Compiler damals nicht so optimal war.
Geht das denn nicht mit einem modernen Compiler?
Kenn mich da leider zu wenig aus.
...
Natürlich das es wurde sein viel besser mit moderner Compiler. Und warum niemand hat es gemacht ?
1. Kein C source für TOS 1.04, 1.62 .
2. Viele syntax Korrekzionen sind gebraucht dass kann compile es mit neuer Compiler.
3. Und viele Korrekzionen im Source code wann möchtet besser FAT16 Code - überschreiben es für unsigned variables instead/statt signed variables.
Mögliche Verbesserungen ohne source Code verandern (syntax muss verandern sicherlich) :
Kurzer Code. Zum Beispiel neu Compiler kann machen absolute address short form if address is under $8000 . Besser übersetzung auf ASM.
Schneller Code.
-
Und warum niemand hat es gemacht ?
Ist doch gemacht worden, siehe EmuTOS.
-
Nein, das geht nicht so ohne weiteres. Pure-C fällt sowieso schon mal aus wegen der komplett anderen Parameter-Übergabe,
Pure C kann man mit der Option -H beibringen alle Parameter über den Stack zu geben und Rückgabe in d0.
-
...
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.
-
...
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“.
-
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...
-
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.
-
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?
-
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.
-
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.
-
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?
-
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.
-
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 .
-
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. :D
-
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.
-
Ist KAOS-TOS frei verfügbar? Woo bekooom?
-
Wer hat, der hat. Und jetzt ist es wieder Zeit für mich, abzutauchen! Viel Spaß noch!
-
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?
-
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.
-
Vermutung: TOS 2.06 werden 68030-spezifische Dinge fehlen: MMU, Cache-Invalidierung, Fast-RAM-Unterstützung im Adressraum oberhalb 16 MB...
-
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.
-
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....
-
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
-
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....
Die PAK TOS 3.06 Roms sind genau wie im Atari TT vier Stück 27C010 insgesamt 512kB. Die PAK braucht zum booten vom TOS 3.06 (oder auch ein TOS 2.06) ein TOS 1.04 auf dem Atari ST Mainboard. Man kann auf die PAK oben auf eine 68000 CPU setzen und mit Hilfe eines GALs zwischen PAK und 68000 umschalten. Wenn die 68000 CPU aktiv ist wird natürlich das Mainboard TOS 1.04 genutzt.
Auf der WRS Webseite gibt es mehr Infos -> wrsonline.de
-
Danke für die Antworten. Scheint wirklich so zu sein, daß es einfacher war die TT-Specifica aus 3.06 raus-zupatchen, als die 030-specifica in 2.06 rein (auch wenn dadurch ziemlich viel gepatcht werden muss, NVRAM z.B, und sämtliche TT-Spezifischen XBIOS Befehle).
Was ich aber noch nicht ganz verstehe ist:
;* Für PAK-Trick um mit FC-TOS auf Mainboard in die PAK-ROMs hochzukommen
40030 $4E,F9,00,E0,00,00 ;JMP OS_Main
$40030 ist der Offset vom ROM, landet damit also auf E40030. Wieso hilft das in irgendeiner Weise das PAK Rom zu booten? Kann das ROM bei $fc0000 gemirrored werden?
-
Zitat aus den GAL-Gleichungen des Adressdekoders (Version, die damals in der c't veröffentlicht wurde; nicht unbedingt die aktuellste Version):
0 PAK 68/3, GAL U6: Adressdekoder, Atari ST
1 16-09-93 V6_STc1 Holger Zimmermann @ PE
2 %ID
3 P6_ST
4 %TYP
5 GAL20V8A
6 %PINS
7 !vpa fc0 fc1 !as_20 a21 a20 a17 a18 a16 a19 a22
8 !berr_00 a23 !avec !dram !ciin !word !fpucs !rom !csp19
9 !berr_20 !jp3
10 %LOGIC
[...]
26 rom = a23 * a22 * a21 * a20 * a19 * a18 * !a17 ´TOS 1.04
27 + a23 * a22 * a21 * a20 * a19 * a18 * !a16 ´TOS 1.04
28 + a23 * a22 * a21 * !a20 * !a19; ´TOS x.06
Das dürfte Deine Frage beantworten
-
Mit GALs kenn ich mich zwar nicht aus, aber ich denke mal, das heisst ja ;)
Preisfrage: wenn das PAK-ROM dort gemirrored wird, und auf den Adressen 0-7 die ersten 8 Bytes des ROMs gemirrored werden, wieso braucht man dann den Patch überhaupt?
-
Preisfrage: wenn das PAK-ROM dort gemirrored wird, und auf den Adressen 0-7 die ersten 8 Bytes des ROMs gemirrored werden, wieso braucht man dann den Patch überhaupt?
Weil die ROMs auf der PAK zwar an der Adresse $FCxxxx eingeblendet werden, aber nicht an der Adresse $000000 und die CPU somit den Resetvektor aus dem ROMs auf dem Mainboard liest.
-
Danke für die Antworten. Scheint wirklich so zu sein, daß es einfacher war die TT-Specifica aus 3.06 raus-zupatchen, als die 030-specifica in 2.06 rein (auch wenn dadurch ziemlich viel gepatcht werden muss, NVRAM z.B, und sämtliche TT-Spezifischen XBIOS Befehle).
Was ich aber noch nicht ganz verstehe ist:
;* Für PAK-Trick um mit FC-TOS auf Mainboard in die PAK-ROMs hochzukommen
40030 $4E,F9,00,E0,00,00 ;JMP OS_Main
$40030 ist der Offset vom ROM, landet damit also auf E40030. Wieso hilft das in irgendeiner Weise das PAK Rom zu booten? Kann das ROM bei $fc0000 gemirrored werden?
-
Was ich aber noch nicht ganz verstehe ist:
;* Für PAK-Trick um mit FC-TOS auf Mainboard in die PAK-ROMs hochzukommen
40030 $4E,F9,00,E0,00,00 ;JMP OS_Main
$40030 ist der Offset vom ROM, landet damit also auf E40030. Wieso hilft das in irgendeiner Weise das PAK Rom zu booten? Kann das ROM bei $fc0000 gemirrored werden?
Zitat aus dem aktuellen Patchfile:
; Trick, damit die PAK auch mit TOS 1.xx auf dem Mainboard startet
; Kein Konflikt mehr, da der RSC-Bereich nach hinten verschoben wird
; Zim 20.12.2011
;
; - CPU l„dt nach Reset $00FC0030 als StartAdr (aus TOS 1.xx auf dem Mainboard)
; - Bei Zugriff auf $00FC0030 wird das PAK-TOS angesprochen, falls enabled
; - Adresse, die die PAK-ROMs sehen:
; F C 0 0 3 0 ; diese Adresse liegt am AdrBus an (hex)
; 1111 1100 0000 0000 0011 0000 ; (bin)
; xxxx x100 0000 0000 0011 0000 ; diese Adr sieht das ROM (512 kBytes, bin)
; x 4 0 0 3 0 ; (hex)
-
Danke für die Tips. Ich kann es natürlich nicht testen, aber wollte verstehen was da passiert.
Zitat aus dem aktuellen Patchfile:
Gibt es da noch eine aktualisierte Version? Ich habe hier die aus dem tp306v20 Paket, von Markus' Seite.
Mir ist auch aufgefallen, das in dem tp206v38 Archiv zumindest einige Sourcen sind, in den neueren Archiven aber nicht mehr.
-
Es gibt noch eine tp206v40 als Beta Version
-
Ja, die hab ich auch, aber für 2.x gibt es keine PAK Patches. Auch sehe ich da nirgendwo einen Kommentar von "Zim".
-
Ob da was mit Pak dabei ist habe ich nicht berücksichtigt. Ging mir nur um die allgemeine Ergänzung.
-
Lief 2.06 nicht out of the box auf der PAK?
-
Ja zum Beispiel gut für eine PAK68/2 mit 020 CPU
-
Ja zum Beispiel gut für eine PAK68/2 mit 020 CPU
Genau, ich finde mit dem 2.06 hat Atari eine der besten Versionen heraus gebracht.
-
Hat aber vermutlich das Problem daß dann im Desktop der Eintrag für den Blitter erscheint, aber nicht der für den Cache. Auch an einige Stellen im VDI wird dann der Cache nicht geflusht. Und 2.06 erkennt wohl auch das TT-RAM auf der Frak nicht.
-
Man muss unterscheiden zwischen PAK, PAK68/2 mit 020 CPU ohne L2 Cache und der PAK68/3 mit 030 CPU und 32kB L2 Cache mit Fastram (FRAK) Option, PuPla Buffer Platine etc. ...
-
Hat aber vermutlich das Problem daß dann im Desktop der Eintrag für den Blitter erscheint, aber nicht der für den Cache. Auch an einige Stellen im VDI wird dann der Cache nicht geflusht. Und 2.06 erkennt wohl auch das TT-RAM auf der Frak nicht.
Da wirst du evtl. recht haben. Na ja, ob die Programmierer das TT-RAM auf der PAK kannten oder das TOS überhaupt für den TT vorgesehen war darf bezweifelt werden.
-
Ich habe jetzt mal einen Patch von TP206V38 gebrannt und in Hi und LO splitten lassen.
Passiert leider nichts Rechner ist tot. :-[
Eventuell versuch ich das mit dem Split Tool von Petari da ist
eine Checksum Korrektur drin.
-
Wenn du es nicht gerade abgeschaltet hast, erzeugt tospatch auch eine CRC. Am splitten sollte es also nicht liegen, vlt. ist beim brennen was schief gelaufen.
-
;*******************************************************************************
;* MRF:
;* Ausgabeformat des Patchprogramms
>1 3C0000 ;eine Datei (TOS.IMG) fr Adresse $3C0000 erzeugen
; bitte daran denken: Obere Ramgrenze - TOS-Lnge (normalerweise = $40000)
; 4MB-Rechner: $3C0000
; 3MB-Rechner: $2C0000
;2.5MB-Rechner: $240000
; 2MB-Rechner: $1C0000 ;Mit weniger als 2MB Speicher macht es eigenlicht
; 1MB-Rechner: $0C0000 ;keinen Sinn mehr, TOS 2.06 im Ram zu halten -
;0.5MB-Rechner: $040000 ;auer vielleicht zum Testen der Patches!
;>1 ;eine nicht relozierte Datei (TOS.IMG) erzeugen
;* auch mglich: 2, 6 oder 8 Dateien, um neue EPROMs zu brennen
;* dazu mu ">2", ">6" bzw. ">8" angegeben werden
;*******************************************************************************
Das sollte gehen ...
;*******************************************************************************
;* MRF:
;* Ausgabeformat des Patchprogramms
;>1 3C0000 ;eine Datei (TOS.IMG) fr Adresse $3C0000 erzeugen
; bitte daran denken: Obere Ramgrenze - TOS-Lnge (normalerweise = $40000)
; 4MB-Rechner: $3C0000
; 3MB-Rechner: $2C0000
;2.5MB-Rechner: $240000
; 2MB-Rechner: $1C0000 ;Mit weniger als 2MB Speicher macht es eigenlicht
; 1MB-Rechner: $0C0000 ;keinen Sinn mehr, TOS 2.06 im Ram zu halten -
;0.5MB-Rechner: $040000 ;auer vielleicht zum Testen der Patches!
>1 ;eine nicht relozierte Datei (TOS.IMG) erzeugen
;* auch mglich: 2, 6 oder 8 Dateien, um neue EPROMs zu brennen
;* dazu mu ">2", ">6" bzw. ">8" angegeben werden
;*******************************************************************************
Gleich EE und E0 Epromdateien machen lassen ...
;*******************************************************************************
;* MRF:
;* Ausgabeformat des Patchprogramms
;>1 3C0000 ;eine Datei (TOS.IMG) fr Adresse $3C0000 erzeugen
; bitte daran denken: Obere Ramgrenze - TOS-Lnge (normalerweise = $40000)
; 4MB-Rechner: $3C0000
; 3MB-Rechner: $2C0000
;2.5MB-Rechner: $240000
; 2MB-Rechner: $1C0000 ;Mit weniger als 2MB Speicher macht es eigenlicht
; 1MB-Rechner: $0C0000 ;keinen Sinn mehr, TOS 2.06 im Ram zu halten -
;0.5MB-Rechner: $040000 ;auer vielleicht zum Testen der Patches!
;>1 ;eine nicht relozierte Datei (TOS.IMG) erzeugen
>2 ;* auch mglich: 2, 6 oder 8 Dateien, um neue EPROMs zu brennen
;* dazu mu ">2", ">6" bzw. ">8" angegeben werden
;*******************************************************************************
-
Danke, wer lesen kann ist im Vorteil :D
Muss ich nachher mal probieren.
-
Danke, wer lesen kann ist im Vorteil :D
Muss ich nachher mal probieren.
Weswegen?
-
Ich meinte damit dass ich das nicht gelesen habe.
-
Beim Brennen der BIN Datei zwischen dem TL866 und Pinatu
stellt man unterschiedliche ASCII Darstellungen fest für Hi und Lo.
Zudem ist die Zeile von Pinatu um ein Zeichen länger.
Die Hex Zahl stimmt jedoch wie man erkennen kann.
-
Nicht wirklich, Pinatubo stellt halt auch nicht-ASCII Zeichen dar.
-
Stimmt doch ...
-
Geht aber ohne Probleme wie man sieht :D
-
Einmal am Atari 000000 - 000011 - 000022 usw. und der PC 000000 - 000010 - 000020 usw.
-
Noch 'ne Sache die mir bei TOSPATCH aufgefallen ist: in der Version für TOS 3.06 wird in der Routine, die auf FPU testet, ein fmove fp0,d0 durch ein fmove d0,fp0 ersetzt. D0 wird an der Stelle nicht benutzt, also macht es nichts aus wenn es zerstört wird. Kann mir jemand erklären, was da der Bugfix ist?
-
Ich bin mir gerade nicht sicher, aber kann ein FMOVE.L FPx, Dy nicht eine Exception auslösen, wenn in FPx ein Wert enthalten ist, der in einem CPU-Register nicht darstellbar ist? Z.B. NaN, zu große/kleine Zahl, ...
-
Ja, könnte es (und würde es wohl auch, weil die FPU-Register mit NaN initialisiert sind). Allerdings wird der Test beim booten ausgeführt, und zu dem Zeitpunkt sind die FPU-Exceptions ausmaskiert. Wäre aber durchaus möglich daß das der Grund für den Patch ist, obwohl ich eigentlich kein Programm kenne daß die Exceptions einschalten würde. Wird auch von der mintlib z.B. gar nicht unterstützt.
-
TOS 3.06 wird in der Routine, die auf FPU testet, ein fmove fp0,d0 durch ein fmove d0,fp0 ersetzt. D0 wird an der Stelle nicht benutzt, also macht es nichts aus wenn es zerstört wird.
Um herauszufinden, ob eine FPU eingebaut ist, versucht TOS die eventuell im Register FP0 enthaltene Zahl in eine Integer-Zahl zu wandeln. Gelingt dieses bei vorhandener FPU jedoch nicht, meist nach einem Tastatur-Reset, so löst die FPU ein Exception aus, was zu einer endlosen Reset-Schleife führt.
-
Der Line-F-Trap (also ob überhaupt eine FPU vorhanden ist) wird natürlich abgefangen. Alle anderen Exceptions sind wie gesagt normalerweise maskiert, dh. sie werden zwar im FPU Status Register angezeigt, führen aber nicht zu einer Exception. Ausser halt es schaltet sie jemand frei.
Wäre aber durchaus möglich daß tatsächlich solche Programme existieren. Insbesondere solche die mit Pascal, Modula und Konsorten übersetzt wurden. Solche Programme steigen gerne mal mit absonderlichen Runtime-Fehlern aus.