WHDLoad y la MMU

### WHDLoad y la Unidad de Gestión de Memoria (MMU)

Una MMU esta contenida en los siguientes procesadores de la familia 68k: 68030, 68040, 68060. También existe la llamada versión EC de dichos procesadores los cuales tienen una unidad MMU rota, fuera de acción. Por ejemplo, todas las A4000/030 estándar tienen solamente una CPU 68EC030. En placas aceleradores de terceros esto es diferente, mire la documentación apropiada para aprender sobre el particular. Hasta donde yo se, todos los 68040/68060 utilizados en Amiga son CPU's completas conteniendo una MMU funcional (debido a que el modo burst y Zorro III requieren mapeo del espacio de E/S mediante MMU). La distinción entre una CPU completa y una versión EC no puede hacerse por software (no al menos en un tiempo aceptable). Por lo tanto el usuario debe hacer esto configurando las opciones correctas en WHDLoad.
Para el 68020 existe una MMU externa llamada 68851, pero actualmente no esta soportada por WHDLoad.

#### Funcionalidades de una MMU y su uso en WHDLoad

El propósito principal de la MMU es traducir direcciones lógicas a direcciones físicas. Esto se requiere para la memoria virtual y espacios separados de memoria (por ejemplo en un sistema multiprocesos protegido). Otra funcionalidad es especificar propiedades especiales como Solamente Supervisor, Protección Contra Escritura y modo de Caché para cada dirección física en el espacio de direcciones (basándose en páginas, donde una página usada por WHDLoad consiste en 4096 bytes). WHDLoad no usa la traducción de direcciones lógicas a físicas. Pero si usa la MMU para protección de memoria, gestion de la caché y algunas funcionalidades especiales (Snooping, resload_Protect#?).

#### Protección de memoria en WHDLoad

Durante el arranque, WHDLoad recorre la lista de memoria y construirá un árbol de traducción que incluirá toda la memoria accesible. Marca los siguientes espacios de direcciones como válidos y accesibles: $0...BaseMem (usando la información del Esclavo), $dff000...$dff200 (registros Custom), $bfd000...$bff000 (registros CIA) y la memoria usada por el Esclavo y WHDLoad. Si se encuentra un Congelador en memoria, la memoria usada por el congelador también será marcada como válida. Toda otra memoria será marcada como inválida, y por lo tanto cualquier acceso a dicha área (Lectura o Escritura) ocasionará una Excepción de Falla de Acceso que terminará con el cuadro de diálogo de error apropiado creado por WHDLoad.

#### Control del usuario de la gestión de MMU en WHDLoad

Hay 3 modos diferentes en los cuales WHDLoad afectara una MMU existente.

1. ignorar la MMU:
   En este modo WHDLoad no cambiará ningún registro relacionado con la MMU. Esto puede ser útil si Ud. esta ejecutando programas que modifican la MMU y Ud. quiere que la funcionalidad de dichos programas permanezca intacta (por ejemplo un congelador por software como TK).
   Precaución: Dado que WHDLoad no toma control por si mismo de la MMU un montón de problemas son posibles. Estos problemas pueden causar caídas del sistema, mal funcionamiento u otros comportamientos no esperados. Aquí hay una lista de los riesgos existentes:
   - ejecutar Enforcer/CyberGuard o una herramienta similar congelará/tirará abajo la máquina, dado que WHDLoad creará una gran cantidad de Hits cada vez que conmute el SO desactivado y activado. Estos Hits no son errores de WHDLoad sino parte de una operación normal.
   - las versiones mas nuevas de la 68060.library (comenzando por v41.1) remapearán la memoria $0-$1000 (la primer página) a una ubicación en memoria Fast usando la MMU, en el modo "ignorar la MMU" esta traducción de direcciones permanecerá intacta, si el programa instalado intenta usar este área para cualquier acción DMA (por ej. debido a una copperlist en este área) los resultados no pueden predecirse, dado que la CPU escribirá/leerá la ubicación de memoria Fast mientras que la DMA lo hará sobre la memoria Chip real que contiene información al azar.
   - si el código de MMU en ejecución depende de esta gestión de excepciones ("Access Fault" exception) la opción NoTrapHandler/S debe estar activada, de otra forma cualquier excepción que ocurra sea gestionada por WHDLoad, el cual saldrá del programa instalado si sucede cualquier cosa no esperada
   - si el código de MMU en ejecución usa cualquier memoria (gestión de excepciones, árbol de traducción, ...) dentro de BaseMem del programa instalada, ocasionará una caída del sistema, dado que la BaseMem será sobreescrita durante la ejecución del programa instalado (temporalmente)
   - en general cada programa que cambie funciones básicas del sistema (usando la MMU) entrara en conflicto con WHDLoad ...
2. desactivar la MMU:
   En este modo, que es posible solamente en un 68030, la MMU será desactivada por WHDLoad, no estarán disponibles funcionalidades relacionadas con la MMU.
3. usar la MMU:
   En este modo WHDLoad toma control total sobre la MMU y realiza la protección de memoria y gestión de la caché tal y como se ha explicado arriba

En el 68030 el modo por defecto es desactivar la MMU. En los 68040/68060 el modo por defecto es usar la MMU. Hay dos opciones para controlar este comportamiento. MMU/S fuerza WHDLoad a usar la MMU y se requiere en sistemas 68030 para usar las funciones de la MMU. NoMMU/S desactiva el uso de la MMU por WHDLoad (ignorar la MMU).

Un hit de Enforcer es un hit de Enforcer, punto. (Michael Sinz)