atari-home.de - Foren
Hardware => Hardware (Classic 16-/32-Bit) => Thema gestartet von: Lukas Frank am Mo 01.06.2015, 12:45:14
-
Habe mir für meinen Atari Mega ST einen MC68010 bestellt. Hatte ich damals auch schon und meine das der Rechner unter TOS 2.06 beim laden einer newdesk.inf Datei immer wieder einen Reset ausführt.
Welcher Wert in der newdesk.inf ist dafür verantwortlich ?
Gibt oder gab es ein Patchprogramm für die newdesk.inf ?
-
Hallo Lukas,
ich habe zwar nie ein MC68010 mit TOS 2.06 benutz, ich habe dazu KaosTos benutz.
Kannst du newdesk.inf nicht so weit abspecken und die datei immer wieder erweitern bis der absturz abtritt ?
Ich bin leider zu lange raus :(
War nur als anregung um das Problem einzugrenzen.
LG
Khristiane
-
Mein MC68010 kommt aus China, muss warten bis ich ihn habe, dann schaue ich mal ...
-
So der 68010 ist da, sogar von Motorola ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=11993.0;attach=8280;image)
Es ist jetzt so das nach abarbeitung des Autoordners das TOS die newdesk.inf einlädt und der Rechner bombt dann mit 4 Bomben ab.
Wenn ich nun die newdesk.inf zum Beispiel in newdesk.inx umbenenne und diese dann nachdem der Desktop da ist über das Menü ".INF Datei lesen" lade ist alles fein ...
-
Wenn es einen Patch für das TOS 2.06 geben würde, wäre das fein ...
Wobei man ja auf die Idee kommen kann das der Fehler im Desktop des TOS 2.06 liegt, keine Ahnung ...
Oder ein kleines Programm welches eine newdesk.inx nach dem Start des Desktops automatisch lädt.
-
Ganz einfach:
- Auslesen
- nach dem Eintrag "NEWDESK.INF" suchen (es gibt 3 Einträge - wobei ich nicht ganz sicher bin, ob alle 3 zu ändern richtig wäre
- patchen
- teilen
- neu brennen
- testen
-
Ließt sich so einfach... Burkhard, mach doch mal vor, insbesondere den Punkt "patchen".
-
Ich habe gerade - bevor ich den Text schrieb, habe ich meine schon mal zu Testzwecken ausgelesene TOS Datei untersucht und tatsächlich dreimal diesen Eintrag gefunden - ich könte jetzt einen Test mit Emu machen, aber das (ein Patch) würde vermutlich für Lukas nicht viel bringen, da ich meine, irgendwo dokumentiert gesehen zu haben, daß einzig der CPU-Tausch für eine Erhöhung der Geschwindigkeit nicht reicht! Es gab mal eine Bauanleitung in einer ST Computer - da wurde so viel verändert ...
Ich glaube daß sich das TOS durch die höhere Prozessorgeschwindigkeit irgendwie verhalpelt und dadurch zum Bombenleger wird! Daran würde auch eine Veränderung eines Dateinamen nichts ändern!
-
Kann sein das da mal etwas in einer Atari Zeitschrift wegen MC68010 drin war, könnte sein ...
Jetzt wäre natürlich die Frage wer hat den Artikel ?
Der Fehler liegt wohl an einem Wert in der Zeile #c der newdesk.inf oder/und einem bug im Desktop des TOS 2.06 !?!
Wenn ich nachdem der Dektop da ist über die Menüleiste die newdesk.inx lade ist ja alles in Ordnung. Heisst die Einstellungen und alles andere werden geladen ohne Bomben, alles fein ...
-
Burkhard, was willst du denn da patchen? Willst du den Dateinamen ändern? Willst du, ohne M68K Assembler zu verstehen, den Maschinencode ändern? Ohne das TOS mal dissasembliert zu haben? Weißt du, dass bei einem Maschinenprogramm die Strings nicht unbedingt in dem Adressbereich liegen, wo auch der zugehörige Maschinencode liegt? (Das ist nicht unbedingt wie bei BASIC!)
@Frank: Ich weiß nicht mehr genau, was damals die Begründung war, aber der 68010 wurde damals in der Atari-Gemeinde als nicht tauglich für den Einsatz im ST erklärt. Der 68010 soll bei divereser Software Probleme machen. Ich meine ein Teil der Begründung war, dass der Aufwand am Software für den 68010 patchen höher wäre, als der Vorteil. Besser gleich einen 68020 oder einen 68000 mit 16 Mhz.
-
TOS 2.06 kann prima mit dem 68010 umgehen (mit Ausnahme des gefundenen "NEWDESK.INF"-Problems).
Wenn ich mich recht erinnere, gibt's in der Desktop-Initialisierung eine Stelle, die alles als 68030 identifiziert, was nicht 68000 ist.
Das bewirkt den Versuch, den Inhalt des Cache-Control Registers auszulesen, was zu einem Illegal Instruction Error führt.
-
68030? Wahrscheinlich eher als 68020 oder besser, denn der 68020 läuft einwandfrei mit TOS 2.06.
-
# 1ST1!
Lukas schrieb doch Eingangs:
... newdesk.inx ...
muß geladen werden - also warum nicht den String NEWDESK.INF nach NEWDESK.INX ändern - das geht auch über einen Diskmonitor ohne sich lange über ASSEMBLER Assoziationen Gedanken zu machen !!!
# Lukas Frank!
Schau mal in den Archiven von Matthias Jaap (jaapan.de) nach - leider habe ich jetzt keine Zeit, das für Dich rauszusuchen! Der Artikel hieß (glaube ich): "Und es geht doch - Atari ST mit mehr als 8MHz" oder so ähnlich! Am Ende wurde er mit mW mit 12MHz betrieben!
Die Zeile "#c..." beinhaltet 16x3 Ziffern zur Farbinfo und dann noch einige Bytes Systeminfos!
edit: habe den Artikel doch noch auf die Schnelle finden können! (http://www.stcarchiv.de/stc1992/09_gehtdoch.php)
-
Was nützt die Änderung des Dateinamens? Dann liest er eben eine newdesk.inx ein und schmiert wieder ab. Was wäre dann der Vorteil, außer dass diverse andere Tools mit denen sich die Newdesk.inf (mit fest verdrahtetem Dateinamen, z.B. XBoot) nicht mehr bearbeiten lässt?
Wenns um Performance geht: Die c't hatte seinerzeit eine recht einfache Schaltung, mit der man einen 68000-16 im ST betreiben konnte, ganz simpel ohne Cache. Die Schaltung bestand nur aus wenigen Gattern und taktete den 68000 von 8 auf 16 MHz hoch, wenn er intern mit sich selbst beschäftigt ist, sprich gerade keine Buszugriffe macht. Letztens beim Aufräumen habe ich den Artikel oder die Schaltung draus gesehen und ich dürfte auch noch ein altes ST-Umbau-Projekt von vor 15..20 Jahren im Keller haben, wo diese Schaltung drin ist. Den Rechner müsste ich irgendwann mal fertig machen.
-
68030? Wahrscheinlich eher als 68020 oder besser, denn der 68020 läuft einwandfrei mit TOS 2.06.
den betreffenden Befehl, der da ausgeführt wird
movel.l cacr,d0
gibt's tatsächlich ab 68020, bloß gibt's - zumindest offiziell - keinen Atari-Rechner mit 68020.
Der Verdacht liegt daher nahe, daß die entsprechende Codesequenz aus den TT-ROMs übernommen wurde (sieht auch genauso aus). Bei allem, was die neueren "langen" Stackframes benutzt und enstprechend die _longframe Systemvariable setzt (deswegen läuft der 68010 überhaupt), hat gefälligst ein CACR-Register zu haben. Beim 68010 trifft zwar ersteres zu, aber zweiteres nicht, deswegen fällt er auf die Nase.
-
Ein 68010 im ST ist schon ganz in Ordnung. Programme laufen alle ohne Fehler, was ich so bisher festgestellt habe ...
Nur z.B. in GEMBENCH beim FPU Test bombt die Maschine ab, hängt sich aber nicht auf und läuft auch weiter.
Der 68010 im ST ist auch nur ein Spaß, habe ja noch diese Maxon MACH16 Beschleunigerkarte die ja mit 16Mhz läuft.
MiNT läuft auch einwandfrei, null Probleme bisher ...
(http://forum.atari-home.de/index.php?action=dlattach;topic=11993.0;attach=8284;image)
-
Habe mal Matthias gefragt und es gab eine ST-Computer Ausgabe 3/91, Seite 88. Thema war die Erkennung des 68010 per Software.
Wer hat den Artikel und könne mir sagen ob darin auch das Thema NEWDESK.INF und TOS 2.06 angesprochen wird und mir den Artikel vielleicht sogar einscannen ...
-
Habe mal Matthias gefragt und es gab eine ST-Computer Ausgabe 3/91, Seite 88. Thema war die Erkennung des 68010 per Software.
Wer hat den Artikel und könne mir sagen ob darin auch das Thema NEWDESK.INF und TOS 2.06 angesprochen wird und mir den Artikel vielleicht sogar einscannen ...
Ich kann dir den Artikel gerne scannen, Newdesk.inf und TOS 2.06 sind allerdings kein Thema. Es geht wirklich nur um das Erkennen des 68010, da manche Programme ihn offenbar fälschlich als 020 identifizieren.
-
Danke für das Angebot, nein Danke muss nicht sein !
-
Gab es TOS 2.06 überhaupt im März 1991 schon, als der Artikel erschien? Ich meine das kam erst im November, konnte also in dem Artikel noch garnicht berücksichtigt worden sein.
-
Gab es TOS 2.06 überhaupt im März 1991 schon, als der Artikel erschien? Ich meine das kam erst im November, konnte also in dem Artikel noch garnicht berücksichtigt worden sein.
Die TOS-Extension-Cards tauchten jedenfalls erst in den November- oder Dezember-Ausgaben der ST-Magazine auf. Uwe Seimets Artikel dürfte noch älter sein - bei einem Mindestvorlauf von einem Monat dürfte er den spätestens im Februar abgegeben haben, eher noch früher. Also möglicherweise noch vor der Vorstellung des MegaSTE mit TOS 2.05.
Angeblich unterstützte auch Kaos den 68010.
-
Ja das mit KaosTOS weiss ich wohl aber es nutzt mir nichts da ich IDE brauche und auch davon boote ...
KaosTOS läuft soweit ich weiss mit allen Motorola 68K CPUs.
Könnte natürlich über meine Megafile vom ACSI Port booten aber das möchte ich eigentlich nicht ...
-
Es gibt ja das TOS Patch Paket von Markus Heiden, damit wäre ein Patchen vom TOS 2.06 mit Sicherheit kein Problem aber ich bekomme so was nicht alleine hin, zu blöd dafür ...
-
Es gibt ja das TOS Patch Paket von Markus Heiden, damit wäre ein Patchen vom TOS 2.06 mit Sicherheit kein Problem aber ich bekomme so was nicht alleine hin, zu blöd dafür ...
Da gibt's scheinbar ne ganze Gemeinde ... ;D
Ich gehöre auch dazu!
-
Kann mir jemand dieses Paket mal geben? Ich würde es mir mal anschauen, und wenn ich es nicht hinbekomme, weiß ich noch 2 andere Leute, die ich mal fragen kann, einer von denen packt es bestimmt.
-
Einfach Google "tospatch markus heiden" da kommt dann das -> http://www.markusheiden.de/atari/tospatch.html
-
Danke. Da fällt mir doch galtt die 2-Tages-Homecon von vor 2 Jahren ein... Warum, verrate ich aber nicht.
-
Nur mal so aus Interesse:
Ist das Sicher, das der 68010 problemlos im ST funktioniert?
Der 68010 hat neue Register, getrennte User- und Supervisormodi und ist fehlerbereinigt.
Könnte also gut sein, das der ST da mit irgendwas ein Problem hat.
-
Klar kanns Probleme geben.
Gibts mit einem 68020 im ST auch.
Ich habe mit dem 68010 damals auch Experimentiert. Alle Anwendungsproggis die ich damals benutzt haben liefen damit. Spiele haben Probleme gemacht.
Da meine 68010-CPU mit der c´t billig-16MHz-Lösung nicht funktioniert hat und der Geschwindigkeitsgewinn mit dem 68010 bei 8MHz auch eher bescheiden war, habe ich das Teil irgendwann mal zum testen in mein Mega Drive eingebaut.
Aber auch da gab es Ärger. Während alle Sega-Spiele die ich hatte Problemlos liefen (Sonic hat tatsächlich ein klein wenig weniger geruckelt!) gab es mit den 3rd Party Games immer irgendwelche Probleme, meistens war die Grafik zerstört.
Sega hat auch den 68010 in ein paar Automaten gehabt, ich nehme an das sie daher auch Tools verwendet haben der den Code für beide CPUs lauffähig erstellt hat. Die haben ja sicher nicht neue Tools gekauft oder entwickelt nur um fürs Mega Drive zu Coden.
OK, genug abgeschweift...
-
Ist das Sicher, das der 68010 problemlos im ST funktioniert?
Wie schon geschrieben, bisher null Probleme auch mit MiNT und MagiC nicht. Da beim Gembench Test der FPU Teil abbombt könnte ich mir vorstellen das Probleme da sind bei Programmen die FPU Code aufrufen oder es bombt nur die abfrage in Gembench ob eine FPU überhaupt vorhanden ist ...
Von der Geschwindigkeit bringen die 16-17% mehr nichts ...
-
Der 68010 hat neue Register, getrennte User- und Supervisormodi und ist fehlerbereinigt.
Das steht zwar so in Wikipedia, ist aber genau genommen falsch. Der 68010 hat keine neuen Register, sondern lediglich eins: das VBR (vector base register). Wenn man das nicht anfaßt, ist es mit 0 initialisiert und der 68010 verhält sich (fast) wie ein 68000.
Getrennte User- und Supervisormodi hatte der 68000 auch, der wesentliche Unterschied ist, daß der Befehl move.w sr, xxx im 68010 ein privilegierter (nur im Supervisor-Mode ausführbarer) Befehl wurde. Will man nur die Flags (im User-Mode) abfragen, muß man stattdessen den (neuen) Befehl move.w ccr,xxx benutzen, den es beim 68000 nicht gibt. TOS 2.06 hat einen Exception-Handler, der diesen Unterschied für die meisten "normalen" Programme eliminiert.
Darüber hinaus hat der 68010 ein anderes (längeres) Exception-Stackframe-Format (identisch zu 68020+), das ihm erlaubt, im Bus-Error-Handler die referenzierte, aber nicht vorhandene Speicheradresse rauszufinden. Das ist eine Grundvoraussetzung, um virtual memory zu implementieren. TOS2.06 ist hier wieder das einzige TOS, daß diesen Unterschied mit der _longframe Systemvariable (die brauchen Falcon und TT auch) teilweise ausbügelt.
Ansonsten scheint mir die in Wikipedia erwähnte "weniger als 10% höhere" Geschwindigkeit etwas stark übertrieben. Die werden nur erreicht, wenn man es schafft, den 68010 in den Loop-Mode (auch eine Neuerung) zu versetzen. Dabei nutzt er einen interne Cache und muß nicht auf den Bus zugreifen.
Dummerweise funktioniert das nur bei Schleifen, die aus maximal zwei Maschinenbefehlen bestehen (und damit läßt sich nicht wirklich viel Sinnvolles anstellen), so daß der Geschwindigkeitszuwachs in realen Programmen wahrscheinlich eher unter 1% liegt.
-
(...) so daß der Geschwindigkeitszuwachs in realen Programmen wahrscheinlich eher unter 1% liegt.
mfro ist der einzige hier, der verstanden hat, dass ein 010 nur Ärger im ST macht und konnte es noch fundiert erklären. Einen Standing-Ovation Smiley gibt's hier leider nicht.
-
Ganz so hart würde ich das nicht sagen ...
Bei mir läuft alles Wunderbar bis auf das laden beim booten der newdesk.inf, was man aber durch das manuelle nachladen umgehen kann. Und unter MiNT und MagiC stellt dich das Problem gar nicht.
Spiele laufen bei mir nie und da machen 020er und aufwärts Karten wahrscheinlich die gleichen oder mehr Probleme, ganz zu schweigen von einem Coldfire wie in der Firebee ...
-
Ja, die 10% oder gar 16/17 kann man total vergessen!
Irgendwo habe ich von 3% (oder 5?) gelesen wenn man entsprechenden Code hat, was wahrscheinlich an kleineren Optimierungungen in der Befehlsabarbeitung liegt.
Der 68010 ist ja "nur" ein modifizierter 68000, wo sollen da zweistellige Prozente herkommen?
Das ist wahrscheinlich auch der Grund warum sich der 68010 nicht so toll verkauft hat.
Ich bin mir sicher das schon 1985 der 68010 in Stückzahlen nicht so viel teurer war, aber für nur 1% macht ein Tramiel den Geldbeutel eben nicht auf. ;D
-
Ja habe schon geschrieben das es ein sinnfreier Spaß ist einen MC68010 zu nutzen ...
Da er in meinem Mega ST recht gut läuft, bleibt er erstmal drin.
-
Der 68010 war vom Design her ein deutlich geeigneterer Unix-Prozessor als der 68000. Das VBR und die langen Stackframes erleichterten (bzw. ermöglichten erst) die Portierung und die Implementierung von virtuellem Speicher. Zudem gab es eine passende MMU (die Motorola allerdings vermurkst hat, deswegen verwendete Sun eine Eigenentwicklung). Der Verfügbarkeit des 68010 (und natürlich Andreas von Bechtolsheim) verdankt(e) Sun überhaupt seine Existenz. Die Sun 1 und 2 basierten auf dem Prozessor.
Diese Features brauchte das für den ST zur Verfügung stehende TOS nicht (bzw. konnte damit nichts anfangen). Der 68010 wäre für den ST tatsächlich rausgeschmissenes Geld gewesen. Heutzutage kann man ja für ein paar € damit rumspielen, wenn man denn unbedingt will.
-
Es gab wohl mal einen Patch für den MC68010 und TOS 1.6 im Atari STE -> http://www.atari-forum.com/viewtopic.php?f=33&t=27963&sid=65aaa9f5c2e8646b6fc99c6a3b458fa4&start=25#p275490
Update TOS 1.6 fuer ST/STE/68010:
Folgende Aenderungen wurden durchgefuehrt:
1. Alle Patches aus TOSFIX.PRG (von Atari) wurden durchgefuehrt
2. _shell_p ($4F6) wird bei reset auf null gesetzt
3. befindet sich auf Diskette kein DESKTOP.INF, so wird alternativ
nach DESKTOP.INC fuer Farbe, sowie nach DESKTOP.INM fuer monochrom
gesucht. Fehlen diese, wird eine Version aus dem ROM verwendet,
welche standartmaessig die Textdarstellung verwendet.
Achtung - bei 'Arbeit sichern' wird immer DESKTOP.INF verwendet.
4. Wird ein ausfuehrbarer Bootsektor geladen, so wird gefragt, ob
dieser ausgefuehrt werden soll. Bei einigen Programmen muss man
sich allerdings beeilen, da diese davon ausgehen, dass das Laufwerk
noch selektiert ist.
5. Zusaetzlich wurden noch folgende Tastaturbefehle implimentiert:
CTRL ALT 1: Mouse Speeder aus
" " 2: " " geringe Wirkung
" " 3: " " grosse Wirkung
" " 5: 50 Hz
" " 6: 60 Hz
" " P: parkt alle Atari-Harddisks (Target 0-7, Unit 0&1)
" " K: Tastaturklick aus/an
6. Bei gedrueckter ALTERNATE-Taste, koennen ASCII-Codes in dezimal
eingegeben werden. (Nur mit dem numerischen Tastenfeld)
7. Werden waehrend eines Reset Pin 20 und Pin 22 der RS232 kurz-
geschlossen, so wird ein echter RESET durchgefuehrt (unabhaengig
von $426)...
Folgende Dateien gehoeren dazu:
FC0000.IMG ROM-Version ST
E00000.IMG ROM-Version STE
3D0000.IMG RAM-Version 4MB fuer ST/STE
1D0000.IMG RAM-Version 2MB fuer ST/STE
0D0000.IMG RAM-Version 1MB fuer ST/STE
... leider ist nichts genauer beschrieben !
Weiss jemand wer das mal gemacht hat ?
-
Diese Patches sind allgemein sehr interessant, z.B. die Sache mit der 50/60 Hz Unschaltung oder ASCII-Codes über ALT eingeben, usw. Ein damit vollständig durchgepatchtes TOS müsste man mal ausprobieren.
Interessant finde ich auch, dass das auf TOS 1.6 (1.06, 1.62 ???) basiert und da auch ST/STE steht. TOS 1.06/162 läuft eigentlich nicht auf normalen STs.
-
Gibt es denn kein gepatchtes Tos mit allen Schikanen in einem Romfile? Würde das dann auch ganz gerne mal probieren :)