9.16 TOS 3.06 auf PAK

TOS 3.06 auf PAK

  +---------+---------------+----------------+---------+-------------------+
  | Pak-TOS | Speicher 4..7 | E00004..E00007 | läufts? |Pak-TOS bei FCxxxx |
  +---------+---------------+----------------+---------+-------------------+
  |  2.06   | 00 FC 00 20   | 00 E0 00 30    |   Ja    |  Ja               |
  |  2.06   | 00 FC 00 30   | 00 E0 00 30    |   Ja    |  Ja               |
  |  3.06   | 00 FC 00 20   | 00 E0 00 30    |   Nein  |                   |
  |  3.06   | 00 FC 00 30   | 00 E0 00 30    |   Ja    | Nein (nach booten)|
  +---------+---------------+----------------+---------+-------------------+

!d e00020 e0005e

!,00E00020 ORI.B    #$66,D0
!,         ORI.B    #$BB,D0
!,         ORI.B    #$1E,D0
!,         ORI.B    #$00,D0
!,00E00030 MOVE.W   #$2700,SR
!,         RESET
!,         MOVE.B   #$0A,$FFFF8001.W
!,         LEA      $000007FC.L,A7
!,         CMPI.L   #$FA52235F,$00FA0000.L        D0 wurde
!,         BNE.B    $00E00058                        nirgendwo
!,         LEA      $00E00058(PC),A6                 benutzt
!,         JMP      $00FA0004.L
!,00E00058 MOVE.L   #$00000808,D0                 D0 wird beschrieben

Die Frage ist nun, warum funktioniert TOS-3.06 nicht wenn man es an FC0020 loslaufen lässt. Das (FCxxxx) != (E0xxxx) nach dem booten kann ja nur durch die PMMU bewirkt werden ... also wenn das System schon läuft. Das TOS-3.06 ab FC0030 läuft beweist, daß diese PMMU Initialisierung erst nach dem Sprung nach Ewxyz stattfindet. Da die (einfache) Umschaltung zum 68000 davon abhängt nun folgender Anreiz: der erste, der's versteht (und mir erklärt) hat ein Freibier im Karlsruher Stammtisch bei mir gut.

Um das Pak-TOS bei FC0030 anstatt bei FC0020 loslaufen zu lassen ist übrigens nicht unbedingt ein neues Eprom auf der Hauptplatine nötig. Das Aushebeln von Pin 16-U7 genügt um aus 20 ein 30 zu machen (HeavyPatch :-) ).

Ich habe z.Z nur als Notlösung wieder die alten TOS 1.0 ROMS drin, falls die TOS-1.4 ROMs auch schon den Einsprung bei FC0030 haben ist mein Problem auch gelöst.

In GAL U6 wird das Signal "rom" erzeugt. Dieses ist aktiv bei Adressen im Bereich $FC0000..$FEFFFF und außerdem im Bereich $E00000..$E7FFFF und wird indirekt (über U1) als Chipselect für die EPROMs verwendet. Wird ein 512K großes Betriebssystem (TOS3.06) eingesetzt, so findet sich dieses im Adressbereich $E00000..$E7FFFF; außerdem wird die _zweite_ Hälfte des Betriebssystems, also der Teil, der ab $E40000.. zu finden ist, bei $FC0000.. eingeblendet, da die Adreßleitung A18 beim Zugriff auf $FC0000.. High ist.

Beim Reset wird der Resetvector aus den ROMs auf der Hauptplatine gelesen, dann wird zur Adresse $FC0020 bzw. $FC0030 verzweigt. Im TOS 3.06 befindet sich clevererweise bei der Adresse $E40030 ein Sprungbefehl zur Adresse $E00030. Dies ist möglich, da sich dort zufällig ein nicht benötigter Teil der Desktop-Resource befindet, welcher (soweit ich dies verstanden habe) sowieso ins RAM kopiert und neu initialisiert wird (??). Dieser Sprungbefehl verzweigt dann zum richtigen Eintrittspunkt. Befindet sich im ROM auf der Hauptplatine ein Reset-Vector $FC0020, so wird das auszuführende Programm von Adresse $E40020 genommen, und dort steht kein Sprungbefehl.

Der Reset bei der PAK läuft also mit TOS 1.02/1.04 auf der Hauptplatine folgendermaßen ab:

Zugriff auf   ROM              Adresse im Rom (rel.)     Inhalt
$000004       Hauptplatine     $000004                   $FC0030
$FC0030       PAK              $040030                   JMP $E00030
$E00030       PAK              $000030                   TOS-Start