Hispanopedia Wiki
En la gestión de memoria de DOS , el área de memoria superior ( UMA ) es la memoria entre las direcciones de 640 KB y 1024 KB ( 0xA0000–0xFFFFF ) en un IBM PC o compatible . IBM reservó los 384 KB superiores del espacio de direcciones de 1024 KB de la CPU 8088 para la ROM del BIOS , el BIOS de vídeo , las ROM de opciones , la RAM de vídeo, la RAM en los periféricos , la E/S mapeada en memoria y el BASIC ROM obsoleto . [ 1 ]
Sin embargo, incluso con la memoria RAM de vídeo, la BIOS ROM , las ROM de opciones y los puertos de E/S para periféricos, gran parte de este espacio de direcciones de 384 KB permanecía sin usar. A medida que la restricción de memoria de 640 KB se convertía en un obstáculo cada vez mayor, se encontraron técnicas para llenar las áreas vacías con RAM. Estas áreas se denominaron bloques de memoria superiores ( UMB ).
Uso
La siguiente etapa en la evolución de DOS fue que el sistema operativo utilizara bloques de memoria superiores (UMB) y el área de memoria alta (HMA). Esto ocurrió con el lanzamiento de DR DOS 5.0 en 1990. [ 2 ] El administrador de memoria integrado de DR DOS, EMM386.EXE , podía realizar la mayor parte de la funcionalidad básica de QEMM y programas similares.
La ventaja de DR DOS 5.0 sobre la combinación de un DOS anterior con QEMM radicaba en que el núcleo de DR DOS y casi todas sus estructuras de datos podían cargarse en la memoria alta. Esto dejaba prácticamente toda la memoria base libre, permitiendo configuraciones con hasta 620 KB de un total de 640 KB disponibles.
La configuración no era automática: las UMB libres debían identificarse manualmente, incluirse en la línea que cargaba EMM386 desde CONFIG.SYS , y luego cargar manualmente los controladores y demás en las UMB desde CONFIG.SYS y AUTOEXEC.BAT . Esta configuración no era un proceso sencillo. Dado que el programa de instalación de QEMM la automatizaba en gran medida, este programa se mantuvo en el mercado; de hecho, funcionaba bien con la compatibilidad con HMA y UMB de DR DOS y se convirtió en una de las utilidades más vendidas para PC.
Esta funcionalidad fue copiada por Microsoft con el lanzamiento de MS-DOS 5.0 en junio de 1991. [ 2 ] Posteriormente, se movieron aún más estructuras de datos de DOS fuera de la memoria convencional, lo que permitió dejar libres hasta 631 KB de 640 KB. A partir de la versión 6.0 de MS-DOS, Microsoft incluso incluyó un programa llamado MEMMAKER que se utilizaba para optimizar automáticamente la memoria convencional moviendo los programas de terminación y permanencia (TSR) a la memoria superior.
Durante un período a principios de la década de 1990, la optimización manual del mapa de memoria de DOS se convirtió en una habilidad muy valorada, lo que permitía que las aplicaciones más grandes se ejecutaran incluso en las configuraciones de PC más complejas. La técnica consistía en crear primero tantas UMB como fuera posible, incluyendo la reasignación de bloques de memoria asignados pero no utilizados, como el área de visualización monocromática en máquinas a color. Luego, los numerosos subcomponentes de DOS debían cargarse en estas UMB en la secuencia correcta para utilizar los bloques de memoria de la manera más eficiente posible. Algunos programas TSR requerían memoria adicional durante la carga, que se liberaba una vez completada la carga. Afortunadamente, había pocas dependencias entre estos módulos, por lo que era posible cargarlos en casi cualquier secuencia. Las excepciones eran que, para almacenar en caché correctamente los CD-ROM, la mayoría de las cachés de disco debían cargarse después de cualquier controlador de CD-ROM, y que los módulos de la mayoría de las pilas de red debían cargarse en una secuencia determinada, esencialmente trabajando progresivamente a través de las capas del modelo OSI .
Un método básico pero eficaz para optimizar la memoria convencional consistía en cargar HIMEM.SYS como dispositivo y, posteriormente, EMM386.EXE como dispositivo con la opción "RAM AUTO", que permite el acceso a la UMA mediante la carga de controladores de dispositivo como devicehigh. Este método carga eficazmente los gestores de memoria fundamentales en la memoria convencional y, posteriormente, todo lo demás en la UMA. Los programas que consumen mucha memoria convencional, como MSCDEX, también podían cargarse en la UMA de forma similar, liberando así una gran cantidad de memoria convencional.
Windows
La creciente popularidad de Windows 3.0 hizo que la necesidad del área de memoria superior fuera menos relevante, ya que las aplicaciones de Windows no se veían afectadas directamente por los límites de memoria base de DOS, pero los programas de DOS que se ejecutaban en Windows (con Windows actuando como gestor de multitarea) seguían estando restringidos. Con el lanzamiento de Windows 95 , esta restricción se volvió aún menos relevante, ya que esta versión de Windows proporciona gran parte de la funcionalidad de los controladores de dispositivos de DOS a las aplicaciones de DOS que se ejecutan en Windows, como la compatibilidad con CD, redes y sonido; el mapa de memoria de las ventanas de DOS de Windows 95 se optimizó automáticamente. Sin embargo, no todos los programas de DOS podían ejecutarse en este entorno. En concreto, los programas que intentaban cambiar directamente del modo real al modo protegido no funcionaban, ya que esto no estaba permitido en el modo virtual 8086 en el que se ejecutaban. Asimismo, los programas que intentaban realizar el cambio mediante la API de la Interfaz de Programación de Control Virtual (VCPI), introducida para permitir que los programas de DOS que necesitaban el modo protegido accedieran a él desde el modo virtual 8086 configurado por un administrador de memoria, como se describió anteriormente, no funcionaban en Windows 95. Solo se admitía la API de la Interfaz de Modo Protegido de DOS (DPMI) para cambiar al modo protegido.
Implementación
Modo virtual 8086
Los bloques de memoria superior se pueden crear asignando memoria extendida al área de memoria superior cuando se ejecuta en modo virtual 8086. Esto es similar a cómo se puede emular la memoria expandida usando memoria extendida , por lo que este método para proporcionar bloques de memoria superior generalmente lo proporciona el administrador de memoria expandida (por ejemplo, EMM386 ). La interfaz de programación de aplicaciones para administrar los bloques de memoria superior se especifica en la Especificación de Memoria Extendida .
Memoria RAM en sombra
En muchos sistemas, incluidos los modernos, es posible usar la memoria reservada para la ROM de la tarjeta de expansión como memoria superior. Muchos chipsets reservan hasta 384 KB de RAM para este propósito y, dado que esta RAM generalmente no se usa, puede utilizarse como memoria superior en modo real con un controlador de dispositivo personalizado , como UMBPCI. [ 3 ]
IBM XT
En las computadoras IBM XT , era posible agregar más memoria a la placa base y usar una PROM decodificadora de direcciones personalizada para hacerla aparecer en el área de memoria superior. [ 4 ] Al igual que con la memoria superior basada en 386 descrita anteriormente, la RAM adicional podía usarse para cargar archivos TSR o como un disco RAM .
La AllCard , una unidad de gestión de memoria adicional para ordenadores de la clase XT, permitía asignar la memoria normal al rango de direcciones 0xA0000-EFFFF, lo que proporcionaba hasta 952 KB para programas de DOS. Programas como Lotus 1-2-3 , que accedían directamente a la memoria de vídeo, necesitaban ser modificados para gestionar esta distribución de memoria. Por lo tanto, se eliminó la limitación de 640 KB a costa de la compatibilidad del software. Este uso de la zona superior de memoria es diferente del uso de bloques de memoria superiores, que se utilizaba para liberar memoria convencional moviendo los controladores de dispositivos y los TSR a los 384 KB superiores del espacio de direcciones de 1 MB , pero dejando intacta la cantidad de memoria direccionable (640 KB).
Véase también
Referencias
- ↑ "Mapa de memoria (x86) - Wiki de OSDev" . wiki.osdev.org . Consultado el 20 de diciembre de 2020 .
- 1 2 Dryfoos, Mike, ed. (1991-09-18) [1991-07-19]. "Informe post mortem del desarrollo de MS-DOS 5.0" (PDF) (enviado por correo como documento judicial). Microsoft . pág. 10. MS-PCA1179169 (MS-PCA1179159-MS-PCA1179191). MS7020988 (MS7020978-MS7021010). Depo. Ex. 1109. Comes v Microsoft Prueba del demandante 3473. CA.No.2:96CV645B Prueba del demandante 477. Archivado (PDF) del original el 2019-04-02 . Recuperado el 2019-07-22 .
[…] Uno de los estímulos más importantes para añadir funcionalidades fue la presión competitiva de
DRDOS 5.0
, del que supimos por primera vez en la primavera de 1990. El conjunto de funcionalidades de DRDOS nos llevó a añadir compatibilidad con
UMB
, intercambio de tareas y recuperación de archivos. […] Gran parte de la atención de la dirección del equipo se desvió a nuevas funcionalidades como el software de transferencia de archivos, la recuperación de archivos y la instalación en red. […] Finalmente, esta situación llegó a un punto crítico a finales de julio de 1990 y, bajo el liderazgo de
BradS
, la dirección del equipo dedicó una ardua serie de reuniones a definir un calendario y un proceso para finalizar el proyecto. […]
(1+32 páginas)
- ↑ "UMBPCI V3.89 - Controlador UMB de hardware de la revista c't para DOS y Win95/98" . Archivado del original el 30/12/2019 . Consultado el 07/02/2020 .
- ↑ Atkinson, Cy (2001). "¿Qué es la memoria de alto rendimiento, por qué me importa y cómo puedo usarla?" . San José, CA, EE. UU. Archivado del original el 5 de octubre de 2018. Consultado el 7 de febrero de 2020 .
- Gestión de memoria de DOS
- BIOS
