WHDLoad und die MMU

### WHDLoad und die Memory Managment Unit (MMU)

Eine MMU ist in den folgenden Prozessoren der 68k-Familie enthalten: 68030, 68040, 68060. Es gibt auch so genannte EC-Versionen dieser Prozessoren welche eine fehlerhafte/nicht funktionierende MMU enthalten. Zum Beispiel sind alle A4000/30 nur mit einem 68EC030 ausgestattet. Bei Beschleunigern von Drittanbietern ist das unterschiedlich. In der zugehörigen Dokumentation sollte die Information welche CPU verbaut wurde aber enthalten sein. Soweit bekannt ist, sind alle in Amigas verwendeten 68040/68060 mit einer funktionierenden MMU ausgestattet (weil der Burstmodus und Zorro III das Markieren der IO-Bereiche erfordert). Die Unterscheidung zwischen einer vollständigen CPU und einer EC-Version kann nicht durch Software getroffen werden (zumindest nicht in aktzeptabler Zeit). Deshalb muss der Benutzer dies mittels der richtigen Optionen WHDLoad bekannt machen.
Für den 68020 existiert eine externe MMU mit dem Namen 68851, diese wird gegenwärtig von WHDLoad aber nicht unterstützt.

#### Fähigkeiten einer MMU und deren Verwendung in WHDLoad

Die Hauptaufgabe der MMU ist die Übersetzung von logischen Adressen in physische. Dies wird benötigt zur Realisierung von virtuellem Speicher und zur Separierung von Adressbereichen (z.B. in einem geschützten Multiprozesssystem). Eine weitere Möglichkeit ist es, spezielle Eigenschaften wie Supervisor Only, Schreibschutz und Cache-Modus für jeden Speicherbereich getrennt einzustellen (kachelbasierend, wobei WHDLoad eine Kachelgröße von 4096 Byte verwendet). WHDLoad benutzt keine logische zu physische Adressübersetzung. Aber es nutzt die MMU für Speicherschutz, CPU-Cache Verwaltung und einige spezielle Sachen (Snooping, resload_Protect#?).

#### Speicherschutz in WHDLoad

Beim Starten durchsucht WHDLoad die Speicherliste und baut einen Übersetzungsbaum auf, der den gesamten verfügbaren Speicher einschließt. Es markiert die folgenden Bereiche als gültig und zugreifbar: $0...BaseMem (unter Benutzung der Informationen aus dem Slave), $dff000...$dff200 (Custom Register), $bfd000...$bff000 (Cia Register) und den Speicher der vom Slave und von WHDLoad belegt wird. Wenn ein Freezer im Speicher gefunden wurde, wird sein Speicher ebenfalls gültig gesetzt. Anderer Speicher ist als ungültig markiert, damit resultiert jeder Zugriff darauf (Lese- oder Schreibzugriff) in einer Access Fault Exception, welche WHDLoad in einem entsprechenden Fehlerrequester anzeigt.

#### Einstellungen des Benutzers zur MMU-Verwaltung durch WHDLoad

Es gibt drei verschiedene Modi wie WHDLoad eine vorhandene MMU verwaltet.

1. Ignoriere MMU:
   In diesem Modus benutzt WHDLoad die MMU nicht und verändert keines der MMU-Register. Dies mag sinnvoll sein, wenn bereits Programme laufen, die die MMU verwenden und deren Funktion aktiv bleiben soll (z.B. ein Freezer wie TK).
   Warnung: Da WHDLoad die MMU nicht selber kontrolliert sind viele Probleme möglich. Dies können Abstürze, Fehlfunktionen oder andere unerwartete Verhaltensweisen sein. Nachfolgend eine Auflistung möglicher Probleme:
   - Wenn Enforcer/CyberGuard oder ein ähnliches Programm läuft, wird der Rechner sich aufhängen, da WHDLoad bei der Umschaltung zwischen OS und installiertem Programm eine Vielzahl von Hits erzeugt. Diese Hits sind Teil des normalen Ablaufes, keine Fehler.
   - Neuere Versionen der 68060.library (beginnend mit v41.1) bilden den Speicher $0-$1000 (die erste Kachel) mittels der MMU in den FastMem ab. Im "Ignoriere MMU" Modus bleibt dies intakt. Wenn nun das installierte Programm versucht diesen Speicherbereich für DMA-Aktivitäten zu verwenden (z.B. eine Copperliste) führt das zu einem unvohersehbaren Verhalten, weil die CPU den FastMem-Bereich schreibt/liest, wohingegen die DMA auf den ChipMem-Bereich zugreift, der undefinierte Daten enthält.
   - Wenn der noch aktive MMU-Code seinen Exception-Handler benötigt ("Access Fault") muss auch die Option NoTrapHandler/S aktiviert sein. Ansonsten wird jede auftretende Exception von WHDLoad selbst empfangen, welches das installierte Programm mit einem Fehlerrequester beenden wird.
   - Wenn der noch aktive MMU-Code Speicher innerhalb BaseMem benutzt (Exception-Handler, Übersetzungsbaum, ...), wird das zum Absturz führen, da BaseMem während der Ausführung des installierten Programmes überschrieben wird.
   - Generell mag jedes Programm welches elementare Funktionen des Systems verändert (unter Benutzung der MMU) mit WHDLoad zu Problemen führen...
2. Deaktiviere MMU:
   In diesem Modus, welcher nur auf einem 68030 möglich ist, schaltet WHDLoad die MMU komplett aus. Keinerlei MMU-Funktionen sind verfügbar.
3. Benutze MMU:
   In diesem Modus übernimmt WHDLoad die komplette Kontrolle über die MMU und realisiert Speicherschutz und CPU-Cache Verwaltung wie oben beschrieben.

Auf 68030 ist der Modus Deaktiviere MMU voreingestellt. Auf 68040/68060 ist voreingestellt Benutze MMU. Es gibt zwei Optionen dies zu verändern. MMU/S schaltet die MMU Benutzung ein (Benutze MMU) und muss auf 68030 verwendet werden um in den Genuss der MMU-Funktionen zu kommen. NoMMU/S schaltet die Verwendung der MMU durch WHDLoad ab (Ignoriere MMU).

Ein Enforcer Hit ist ein Enforcer Hit, Punkt. (Michael Sinz)