TOS206 mit 68030 CPU

[udo]

Hallo,

ich frage mich, ob ein ungepatchtes TOS206 in einem STE mit 68030 CPU
ohne Einschränungen läuft. Ich habe nämlich hier so ein System, dabei fällt
mir auf, daß manche Programme (z.B. die Pure-C IDE) sehr zäh auf
Tastatureingaben reagieren. Bei Emucon2.tos hingegen ist alles wie gewohnt.
Wenn ich den Cache der CPU abschalte, funktioniert auch Pure-C.
Hat jemand ein STE mit PAK und hat den schnon mal mit einem 206er Tos probiert?
Mein System ist eine Suska-Spezial-Version, wäre interessant, wie sich ein
echter STE an der Stelle verhält.

ciao ciao
Udo

[Thorsten Otto]

Kann ich mir nicht vorstellen, für die PAK gibt es nicht ohne Grund ein gepatchtes TOS. U.a. fehlen da gleich beim bios-start die notwendingen Instruktionen um den Cache abzuschalten und die MMU zukonfigurieren.

[KarlMüller]

Kann ich mir nicht vorstellen, für die PAK gibt es nicht ohne Grund ein gepatchtes TOS. U.a. fehlen da gleich beim bios-start die notwendingen Instruktionen um den Cache abzuschalten und die MMU zukonfigurieren.

Wenn ich den Ausgangs post richtig verstehe ist nur ein 68030 vorhanden und keinen MMU. Was die CPU angeht erkennt TOS 2.06 einen 030.

https://github.com/sarnau/AtariSTRomListings/blob/622ccfdd120cdbb9a005b7de84a4562bf9dc28da/TOS206%2C206STBook%2C206.asm#L593-L617

[udo]

Es ist eine mehr oder weniger komplette 68030 CPU, d.h. es ist auch eine MMU drin.
Scheinbar initialisiert das TOS die CPU schon gar nicht so schlecht, denn der Desktop
inkl. HDDRV kommt problemlos hoch. Drum hab' ich mich auch gefragt, wozu es
eine gepatchte Version braucht. Auch Sysinfo.prg zeigt alles korrekt an.

Ein gepatchtes TOS206 hab' ich auch nicht gefunden, nur eine 3er TOS mit
Patches für die PAK. Ein für die PAK gepatches TOS306 arbeitet leider auch nicht
besser. D.h. solange die Caches der CPU aktiv sind funktioniert bei vielen Programmen
die Tastatur nicht richtig.
Besser funktioniert das EMUTOS. Da kann ich z.B den Pure-C Editor bedienen.
Um einen Fehler der CPU auszuschließen hätte mich wirklich das Verhalten eines TOS206
interessieren. Hätte gehofft, jemand hat das schonmal probiert und könnte mir einfach sagen,
geht oder geht nicht.

[KarlMüller]

Es ist eine mehr oder weniger komplette 68030 CPU, d.h. es ist auch eine MMU drin.
Scheinbar initialisiert das TOS die CPU schon gar nicht so schlecht, d

Da habe ich mich vertan und dachte ein 030 hätte keine MMU intern. Wobei das TOS 2.06 diese dann nicht initallisiert.

Drum hab' ich mich auch gefragt, wozu es
eine gepatchte Version braucht.

Aus der c't 2/1992

Speziell dieser Patch ist lebensnotwendig: Wenn aufgrund einer fehlerhaften Zeitmessung die Zugriffe auf Hardware-Register in zu schneller Folge auftreten, kann das zu Problemen führen, etwa zum Absturz des Tastaturprozessors, weil das Delay zwischen den ACIA-Zugriffen zu kurz ist. Wünschenswert war ferner eine Anpassung an die Echtzeituhr des Mega ST, damit der Rechner nicht `zeitlos´ ist, auch wenn viele den Atari so empfinden.

[udo]

Oh - besten Dank. Das Verhalten meines Systems ist schon recht nah an dem Zitat aus der ct.
Werd mir gleich mal den Artikel anschauen.

[mfro]

Oh - besten Dank. Das Verhalten meines Systems ist schon recht nah an dem Zitat aus der ct.
Werd mir gleich mal den Artikel anschauen.

Ich glaube nicht, dass dir das weiterhilft. TOS2.06 gilt eigentlich (im Gegensatz zu den älteren Versionen als  weitgehend "warteschleifenbereinigt" - also von der CPU-Geschwindigkeit unabhängig gemacht). Dafür spricht auch, dass anscheinend (?) alles funktioniert, wenn Du die Caches ausschaltest (wie machst Du das eigentlich - TOS2.06 kann das m.E. bei einer '030 CPU nicht?).

Dein Problem ist m.E. die nicht initialisierte MMU - bei eingeschalteten Caches wird dann der gesamte Adressraum gecached. Zugriffe auf Hardware- (also z.B. die ACIA-) Register lesen so lange "alte" Werte aus dem Cache (anstatt direkt von der Hardware), bis die aus Platzmangel rausfliegen und der Cache neu befüllt wird. Anscheinend liegen die "entscheidenden" Zugriffe bei Pure C eben so dicht beieinander, dass das nicht passiert (verwunderlich, dass Du das anscheinend nur dort bemerkst).

Du brauchst (mindestens) eine rudimentäre MMU-Initialisierung, die der CPU sagt, wo im Adressraum Hardware-Register liegen (was also nicht gecached werden darf).
Zusätzlich ein Remapping, das die Hardware ab $FFF00000 auch im 24-bittigen ($F00000) Adressraum zugänglich macht (oder andersrum, je nachdem wo bei dir die Hardware sitzt).

Der Code dafür findet sich im EmuTOS - sollte nicht allzu schwierig sein, daraus ein Auto-Ordner Programm zusammenzuschustern.


Was ich nicht verstehe ist, warum das gepatchte PAK-TOS dasselbe Verhalten zeigt (aber ansonsten anscheinend läuft?). Das sollte eigentlich genau das machen?

[udo]

Danke für die ausführliche Antwort.
Ausschalten kann ich den Cache am Suska-Board per Schalter :-).
Kann natürlich auch sein, daß noch ein Bug in der MMU ist, Ich werde mir
mal den PAK-306 Patch und die EMUTOS Initialisierung anschauen.

[mfro]

Danke für die ausführliche Antwort.
Ausschalten kann ich den Cache am Suska-Board per Schalter :-).
Kann natürlich auch sein, daß noch ein Bug in der MMU ist, Ich werde mir
mal den PAK-306 Patch und die EMUTOS Initialisierung anschauen.

Ich meine auch, irgendwo aufgeschnappt zu haben (weiss nicht mehr wann und wo, kann also auch falsch sein), dass Wolfgang seiner '030 CPU wesentlich grössere Caches verpasst hätte als Motorola?

Wenn das tatsächlich der Fall sein sollte, kann es natürlich sehr gut sein, dass Code darauf angepasst werden muss.

[Thorsten Otto]

Da habe ich mich vertan und dachte ein 030 hätte keine MMU intern. Wobei das TOS 2.06 diese dann nicht initallisiert.

Es gibt auch 68030 ohne MMU (68EC030), die sind aber wohl eher die Ausnahme. Ausserdem müssen, wenn ich mich richtig erinnere, selbst ohne MMU mind. die TransparentTranslation-register initialisiert werden weil sonst der Zugriff auf die Shadow-IO-Register im Bereich $FF0000-$FFFFFF nicht funktioniert, oder (wie mfro schrieb) gecachet wird.

Du kanst ja mal versuchen, ein Programm in den Auto-Ordner zu packen, das folgende Befehle (im Super-Visor-modus) ausführt:

Code: [Auswählen]

    pmove mmu_tt0,ttr0
    pmove mmu_tt1,ttr1
    rts
mmu_tt0:
    dc.l                      $017e8107
mmu_tt1:
    dc.l                      $807e8507

Vlt. hilft es.

Anscheinend liegen die "entscheidenden" Zugriffe bei Pure C eben so dicht beieinander, dass das nicht passiert (verwunderlich, dass Du das anscheinend nur dort bemerkst).

Er schreibt ja daß das bei anderen Programmen wohl auch auftritt. Pure-C verwendet jedenfalls keine direkten Hardware-Zugriffe (vlt. der Debugger, aber nicht die IDE). Die Sache mit dem Cache würde jedenfalls auch erklären warum EmuTOS "normal" läuft, zum einen müsste die MMU dort initialisiert werden wenn ein 030 erkannt wird, zum anderen sind die BIOS-Routinen ja ganz anders organisiert, was die Wahrscheinlichkeit grösser macht, daß die Hardware-Zugriffe nicht gecachet werden.

[udo]

Ja bei Wolfgangs CPU sind die Caches größer. Die aktuelle Emutos Version funktioniert bei mir 2048 Byte. Aber für meine TOS206 Tests habe ich ein Image mit 256 Byte Caches gebaut,

[czietz]

Ja bei Wolfgangs CPU sind die Caches größer. Die aktuelle Emutos Version funktioniert bei mir 2048 Byte.

Wimre habe ich deshalb eine Stelle in EmuTOS angepasst, um mit dem Caches in Wolfgangs 68030-Klon klarzukommen.

[udo]

Ich hab' inzwischen gesehen, der Wolfgang hat für den Bereich xxFFxxxx
den Cache fest abgeschaltet. Das erklärt wohl wieso das TOS206 überhaupt
gelaufen ist. Ich hab' mir nun einen Core gebaut, bei dem nur die MMU entscheidet
wann gecacht wird, damit läuft das TOS206 nicht mehr. Nur das aktuelle EMUTOS
kommt damit zurecht.
Jetzt werd ich mal sehen ob ich die EMUTOS MMU Initialisierung ins 206er TOS
reinbekomme.

[Thorsten Otto]

Gibt es denn einen besonderen Grund warum du da unbedingt TOS 2.06 drin haben willst? Wenn EmuTOS funzt, sollte das doch reichen denke ich. Die meisten (hardware-nah programmierten) Spiele werden aufgrund des geänderten timings sowieso nicht funktionieren.

[udo]

nein - kein besonderer Grund - mich hat viel mehr gewundert, daß es fast fehlerfrei lief :-).
Am Ende sollte da natürlich ein 3er oder 4er TOS und EMUTOS drauf laufen.