Área de memoria superior

Véanse también: Memoria convencional y Memoria expandida.

El área de memoria superior o UMA (Upper Memory Area) es una característica de diseño de las computadoras compatibles con la IBM PC, de arquitectura x86. Esta es la característica que crea la barrera de los 640 kilobytes (KB).

El área de memoria superior (UMA) ocupa 384 KiB, que va desde los 640 KiB hasta 1 MiB.

La IBM reservó la región más alta del mapa de memoria de la PC para la memoria ROM del BIOS (8 KiB en una dirección justo abajo del megabyte), además, memoria RAM para los periféricos como las tarjetas de video CGA y MDA, otras ROM del sistema, y entrada/salida (E/S) mapeada en memoria. En el caso de las computadoras fabricados por IBM, también había un interpretador BASIC, escrito por Microsoft que ocupaba 40 KiB por debajo del BIOS.

Esta región se llama UMA, ocupa 384 KiB y descansa sobre la memoria convencional, entre los 640 KiB y 1 MiB, máximo límite direccionable de la CPU 8088 de la PC original. Por ejemplo, el área de memoria de video monocromática va desde las dirección B000 a la B7FF. Sin embargo, incluso con la RAM de video, el ROM BIOS y los puertos de E/S para las tarjetas de expansión, muchos de estos 384 KiB del espacio de dirección no era usado, incluso cuando una ventana de 64 KiB fue reservada para el "marco" de direcciones de la especificación de memoria expandida en la cual el RAM EMS tenía los bancos conmutados. Por ejemplo, en la mayoría de los PC, toda la o la mayor parte del área desde C800 a EFFF está normalmente sin uso.

Uso en sistemas operativos del PC

La siguiente etapa en la evolución del DOS estuvo en el sistema operativo en sí mismo al hacerlo consciente de los bloques de memoria superior (UMB) y del área de memoria alta. Esto ocurrió con el lanzamiento de DR-DOS 5.0 en 1990. El gestor de memoria​ incorporado en el DR-DOS, el EMM386.EXE, podía realizar la mayor parte de la funcionalidad básica del QEMM y programas comparables.

Donde el DR-DOS hizo puntos sobre la combinación de un más viejo DOS junto con el QEMM fue que el núcleo (kernel) en sí mismo del DR-DOS y casi todas sus estructuras de datos se podían cargar en memoria alta, más todos sus componentes asociados en UMBs. Esto dejó virtualmente libre toda la memoria baja, permitiendo configuraciones con hasta 620 KiB libres de los 640 KiB de la memoria convencional.

La configuración no era automática - UMBs libres tenían que ser identificados a mano, incluidos manualmente en la línea que cargaba el EMM386 en el CONFIG.SYS, y entonces los drivers, etc, tenían que ser cargados manualmente en UMBs desde el CONFIG.SYS y el AUTOEXEC.BAT. Esta configuración no era un proceso trivial. Mientras fue automatizada en gran parte por el programa de la instalación del QEMM, este programa sobrevivió en el mercado. de hecho, trabajó bien con el propio soporte del HMA y UMB del DR-DOS y continuó siendo una de las utilidades mejor vendidas para el PC.

Esta funcionalidad fue copiada por Microsoft con el lanzamiento del MS-DOS 5.0 en junio de 1991. Eventualmente, aún más estructuras de datos del DOS fueron sacadas de la memoria convencional, permitiendo hasta 631 KiB libres en ella.

Por un período a principios de los años 1990, la optimización manual del mapa de memoria del DOS se convirtió en una habilidad altamente estimada, permitiendo que las aplicaciones más grandes corrieran incluso en las configuraciones más complejas del PC. La técnica era crear primero tantos UMBs como fuera posible, incluyendo el remapeo de bloques de memoria asignados pero no necesarios, como el área de la pantalla monocromática en las máquinas con tarjetas de video en color. Entonces, muchos subcomponentes del DOS tenían que ser cargados en estos UMBs en justo la secuencia correcta para usar los bloques de memoria tan eficientemente como fuera posible, teniendo en cuenta el hecho de que algunos programas TSR requerían memoria adicional mientras se cargaban que era liberada una vez que la carga estaba completa. Afortunadamente había pocas dependencias entre estos módulos, así que era posible cargarlos en casi cualquier secuencia. Las excepciones eran tener con éxito el caché de los CD-ROM, la mayoría de los caché de disco tenían que ser cargados después de cualquier driver de CD-ROMs, y los módulos de la mayoría de los stack de redes tenían que ser cargados en cierta secuencia, esencialmente trabajando progresivamente a través de las capas del modelo OSI.

Con la adición de un manejador de multitarea de DOS como el DESQview de Quarterdeck, múltiples sesiones podían ser arrancadas al mismo tiempo, cada una con 600 KiB de memoria libre y todas compartiendo el acceso al DOS y sus drivers y facilidades asociados.

La creciente popularidad de Windows 3.0 hizo esto menos relevante, dado que las aplicaciones de Windows no eran afectadas por los límites de la memoria base del DOS, pero los programas de DOS corriendo bajo Windows (con Windows en sí mismo actuando como un manejador multitarea) todavía tenían ese inconveniente. Con el lanzamiento de Windows 95, todavía se convirtió en menos relevante, porque esta versión de Windows proporcionaba mucha de la funcionalidad de los drivers de dispositivo del DOS a las aplicaciones de DOS corriendo bajo Windows, como por ejemplo, soporte de CD, red y sonido. El mapa de memoria del DOSBox de Win95 fue automáticamente optimizado. Sin embargo, no todos los programas de DOS podían ejecutarse en este ambiente. Específicamente, los programas que intentaban cambiar directamente de modo real a modo protegido, no trabajarían puesto que esto no era permitido en el modo virtual del 8086 en el que estaban corriendo (de hecho, este punto está siendo ahora tratado por tecnologías de virtualización para los CPU x86 a punto venir (2006), como Vanderpool y Pacífica). Tampoco trabajaban en Windows 95, programas que trataban de hacer el cambio usando el API VCPI (que fue introducido para permitir a los programas DOS que necesitaran modo protegido entrar a este desde el modo virtual 8086 puesto en marcha por un manejador de memoria, según lo descrito arriba). Para cambiar al modo protegido solamente fue soportado el API DPMI.

Memoria superior y la RAM de sombra

En muchos sistemas incluyendo los modernos, es posible usar la memoria reservada para la sombra de la ROM de tarjetas de expansión como memoria superior. Muchos chipsets reservan hasta 384 KiB de RAM para este propósito, y puesto que este RAM generalmente está sin uso, puede ser usado como memoria superior de modo real con un driver de dispositivo específico para ello.

Memoria superior en la IBM XT

En las computadoras IBM XT era posible agregar más memoria a la tarjeta madre y usar un PROM decodificador de direcciones a la medida para hacer que aparezca en el área de memoria superior.​ Como con la memoria superior basada en el 386 descrita arriba, el RAM adicional podía ser usado para cargar archivos de TSR, o como disco RAM.

Sistemas de PC x86 que no tenían el UMA

La existencia del UMA y la barrera de los 640 KiB eran artefactos, características propias, del diseño del IBM PC y por lo tanto de cualquier computadora compatible con este, en otras palabras, todos los sistemas compatibles del IBM PC. Sin embargo, ha habido muchas otras computadoras basadas en Intel u otros procesadores x86 que no eran compatibles con el PC y no tenían así un Upper Memory Area y ninguna barrera de los 640 KiB.

Véase también

• Administración de Memoria
• Especificación de memoria expandida
• Especificación de memoria extendida
• Gestión de memoria
• Memoria convencional
• Modo irreal
• Modo protegido
• Modo real
• Área de memoria alta

• Datos: Q1323962