Articulo de referencia

Memoria convencional

Áreas de memoria de la familia IBM PC En la gestión de memoria de DOS , la memoria convencional , también llamada memoria base , corresponde a los primeros 640 kilobytes de memo...

Áreas de memoria de la familia IBM PC

En la gestión de memoria de DOS , la memoria convencional , también llamada memoria base , corresponde a los primeros 640 kilobytes de memoria en los sistemas IBM PC o compatibles . Se trata de la memoria de lectura y escritura directamente direccionable por el procesador para su uso por el sistema operativo y los programas de aplicación . A medida que los precios de la memoria disminuyeron rápidamente, esta decisión de diseño se convirtió en una limitación para el uso de grandes capacidades de memoria hasta la introducción de sistemas operativos y procesadores que la hicieron irrelevante.

barrera de 640 KB

La limitación de 640 KB es una restricción arquitectónica de los ordenadores compatibles con IBM PC . La CPU Intel 8088 , utilizada en el IBM PC original , podía direccionar 1  MB ( 2²⁰  bytes), ya que el chip ofrecía 20 líneas de dirección . En el diseño del PC, la memoria inferior a 640  KB se destinaba a la memoria de acceso aleatorio en la placa base o en tarjetas de expansión, y se denominaba área de memoria convencional.El primer segmento de memoria (64  KB ) del área de memoria convencional se denomina memoria inferior o área de memoria baja . Los 384  KB restantes, más allá del área de memoria convencional, denominados área de memoria superior (UMA), estaban reservados para el sistema y dispositivos opcionales. UMA se utilizaba para la BIOS ROM , memoria adicional de solo lectura , extensiones de BIOS para unidades de disco fijo y adaptadores de vídeo, memoria del adaptador de vídeo y otros dispositivos de entrada y salida mapeados en memoria . El diseño del IBM PC original ubicaba el mapa de memoria del adaptador de gráficos en color (CGA) en UMA.

La necesidad de más RAM creció más rápido que la capacidad del hardware para utilizar las direcciones reservadas, lo que provocó que la RAM terminara asignándose a estas áreas superiores no utilizadas para aprovechar todo el espacio direccionable disponible. Esto introdujo un "hueco" reservado (o varios) en el conjunto de direcciones ocupadas por el hardware, que podía utilizarse para datos arbitrarios. Evitar dicho hueco era difícil y poco elegante, y no era compatible con DOS ni con la mayoría de los programas que podían ejecutarse en él. Posteriormente, el espacio entre los huecos se utilizaría como bloques de memoria superiores (UMB).

Para mantener la compatibilidad con sistemas operativos y aplicaciones más antiguos, la  barrera de 640 KB permaneció como parte del diseño de la PC incluso después de que el 8086/8088 fue reemplazado por el procesador Intel 80286 , que podía direccionar hasta 16  MB de memoria en modo protegido . La  barrera de 1 MB también se mantuvo mientras el 286 se ejecutaba en modo real , ya que DOS requería el modo real que utiliza los registros de segmento y desplazamiento de manera superpuesta, de modo que no son posibles direcciones con más de 20 bits. Todavía está presente en las PC compatibles con IBM hoy en día si se ejecutan en modo real como el utilizado por DOS. Incluso las PC Intel más modernas todavía tienen el área entre 640 y 1024 KB reservada. [ 3 ] [ 4 ] Sin embargo, esto es invisible para los programas (o incluso para la mayor parte del sistema operativo) en sistemas operativos más nuevos (como Windows , Linux o Mac OS X ) que utilizan memoria virtual , porque no tienen conocimiento de las direcciones de memoria física. En cambio, operan dentro de un espacio de direcciones virtuales , que se define independientemente de las direcciones de RAM disponibles. [ 5 ] 

Algunas placas base incluyen una opción de "Agujero de memoria de 15 megabytes" necesaria para ciertas tarjetas de video VGA que requieren acceso exclusivo a un megabyte específico para la memoria de video. Las tarjetas de video más recientes que utilizan el bus AGP (espacio de memoria PCI) pueden tener 256 MB de memoria con un tamaño de apertura de 1 GB .  

Memoria adicional

Una técnica empleada en los primeros ordenadores IBM XT consistía en instalar RAM adicional en el rango de direcciones de la memoria de vídeo y aumentar el límite hasta el inicio del adaptador de pantalla monocromática (MDA). En ocasiones, se requería software o un decodificador de direcciones personalizado para que esto funcionara. Esto desplazaba la barrera a 704  KB (con MDA/HGC) o 736  KB (con CGA). [ 6 ] [ 7 ]

Los administradores de memoria en sistemas basados ​​en 386 (como QEMM o MEMMAX (+V) en DR-DOS ) podían lograr el mismo efecto, agregando memoria convencional a 640  KB y moviendo la barrera a 704  KB (hasta el segmento B000, el inicio de MDA/HGC) o 736  KB (hasta el segmento B800, el inicio de CGA). [ 7 ] Solo se podía usar CGA en esta situación, porque la memoria de video del Adaptador de Gráficos Mejorado (EGA) estaba inmediatamente adyacente al área de memoria convencional debajo de la  línea de 640 KB; la misma área de memoria no podía usarse tanto para el búfer de fotogramas de la tarjeta de video como para programas transitorios.

Las unidades de gestión de memoria adicionales AllCard para XT- [ 8 ] [ 9 ] y Chargecard [ 10 ] de All Computers para computadoras de clase 286/386SX, así como la tarjeta adicional ECM (Extended Conventional Memory) de MicroWay [ 11 ] permitieron mapear la memoria normal en el rango de direcciones A0000–EFFFF ( hexadecimal ), lo que proporcionó hasta 952  KB para programas DOS. Programas como Lotus 1-2-3 , que accedían directamente a la memoria de vídeo, necesitaban ser parcheados para manejar esta distribución de memoria. Por lo tanto, se eliminó la  barrera de 640 KB a costa de la compatibilidad del hardware. [ 10 ]

También era posible utilizar la redirección de consola [ 12 ] (ya sea especificando un dispositivo de consola alternativo como AUX: al invocar inicialmente COMMAND.COM o utilizando CTTY más adelante) para dirigir la salida y recibir la entrada de un terminal tonto u otro ordenador que ejecutara un emulador de terminal . Suponiendo que el BIOS del sistema aún permitiera que la máquina arrancara (lo cual suele ser el caso, al menos con los BIOS para PC integrados), la tarjeta de vídeo en un ordenador sin monitor podía eliminarse por completo, y el sistema podía proporcionar un total de 960  KB de memoria DOS continua para cargar programas.

Un uso similar era posible en muchos ordenadores compatibles con DOS pero no con IBM con una disposición de memoria no fragmentada, por ejemplo, los sistemas de bus SCP S-100 equipados con su tarjeta de CPU 8086 CP-200B y hasta dieciséis  tarjetas de memoria SCP 110A (con 64  KB de RAM en cada una de ellas) para un total de hasta 1024 KB (sin tarjeta de vídeo, pero utilizando la redirección de la consola y después de mapear la ROM de arranque/BIOS), [ 13 ] el Victor 9000 / Sirius 1 que admitía hasta 896  KB, o el Apricot PC con una memoria DOS más continua para ser utilizada bajo su versión personalizada de MS-DOS.

Software de controladores DOS y TSR

La mayoría de los programas estándar escritos para DOS no requerían necesariamente 640  KB o más de memoria. En su lugar, se podían usar controladores y utilidades, conocidos como programas residentes permanentes (TSR, por sus siglas en inglés), además del software estándar de DOS. Estos controladores y utilidades solían utilizar parte de la memoria convencional de forma permanente, reduciendo así la memoria total disponible para los programas estándar de DOS.

Algunos controladores DOS y programas residentes en memoria (TSR) muy comunes que utilizan memoria convencional incluyen:

  • ANSI.SYS : compatibilidad con texto en color y diferentes resoluciones de texto.
  • ASPIxDOS.SYS, ASPIDISK.SYS, ASPICD.SYS: todos deben estar cargados para que las unidades SCSI y las unidades de CD-ROM de Adaptec funcionen.
  • DOSKEY.EXE : permite recuperar comandos de DOS escritos previamente usando la flecha hacia arriba.
  • LSL.EXE, E100BODI.EXE (u otro controlador de red), IPXODI.EXE, NETX.EXE: todos deben cargarse para acceder a la letra de unidad del servidor de archivos NetWare.
  • MOUSE.EXE: compatibilidad con dispositivos de ratón en programas de DOS.
  • MSCDEX.EXE : admite el acceso a la unidad de CD-ROM y la asignación de letra de unidad. Se utiliza junto con un controlador específico del fabricante. Es necesario, además de los controladores SCSI mencionados anteriormente, para acceder a un dispositivo de CD-ROM SCSI.
  • SBCONFIG.EXE: compatibilidad con el dispositivo de audio Sound Blaster 16 ; para otras tarjetas de sonido se utilizaba un controlador con un nombre diferente, que también ocupaba memoria convencional.
  • SMARTDRV.EXE : instala la caché de la unidad para acelerar las lecturas y escrituras del disco; aunque podía asignar varios megabytes de memoria más allá de 640  KB para el almacenamiento en caché de la unidad, aún necesitaba una pequeña porción de memoria convencional para funcionar.

Como se puede observar, muchos de estos controladores y programas residentes en servicio (TSR) son prácticamente esenciales para el correcto funcionamiento del sistema. Sin embargo, en muchos casos, el usuario debía elegir entre ejecutar ciertos programas estándar de DOS o tener cargados todos sus controladores y TSR favoritos. Cargar la lista completa resulta poco práctico o incluso imposible si el usuario también desea ejecutar un programa estándar de DOS.

En algunos casos, era necesario descargar los controladores o los programas residentes en memoria (TSR) para ejecutar ciertos programas y volver a cargarlos tras su ejecución. Para los controladores que no podían descargarse, las versiones posteriores de DOS incluían un menú de inicio que permitía al usuario seleccionar distintos grupos de controladores y TSR para cargar antes de ejecutar ciertos programas estándar de DOS que consumían mucha memoria.

Bloques de memoria superiores y carga alta

A medida que las aplicaciones de DOS se volvieron más grandes y complejas a finales de la década de 1980 y principios de la de 1990, se generalizó la práctica de liberar memoria convencional moviendo los controladores de dispositivos y los programas TSR a bloques de memoria superiores (UMB) en el área de memoria superior (UMA) durante el arranque, con el fin de maximizar la memoria convencional disponible para las aplicaciones. Esto tenía la ventaja de no requerir cambios de hardware y preservaba la compatibilidad de las aplicaciones.

Esta función fue ofrecida inicialmente por productos de terceros como QEMM , antes de ser integrada en DR DOS 5.0 en 1990 y posteriormente en MS-DOS 5.0 en 1991. La mayoría de los usuarios utilizaban el controlador EMM386 incluido en MS-DOS 5, pero los productos de terceros de empresas como QEMM también resultaron populares.

Al iniciar el sistema, los controladores se podían cargar en la memoria principal mediante la directiva " DEVICEHIGH ", mientras que los programas residentes en memoria (TSR) se podían cargar en la memoria principal mediante las directivas " LOADHIGH ", " LH " o " HILOAD ". Si la operación fallaba, el controlador o el TSR se cargaban automáticamente en la memoria convencional.

CONFIG.SYS , cargando ANSI.SYS en UMBs, sin soporte EMS habilitado:

DISPOSITIVO=C:\DOS\HIMEM.SYS DISPOSITIVO=C:\DOS\EMM386.EXE NOEMAS DISPOSITIVOALTO=C:\DOS\ANSI.SYS

AUTOEXEC.BAT , cargando MOUSE, DOSKEY y SMARTDRV en UMBs si es posible:

LH C:\DOS\MOUSE.EXE LH C:\DOS\DOSKEY.EXE LH C:\DOS\SMARTDRV.EXE

La capacidad de las versiones 5.0 y posteriores de DOS para mover su propio código central del sistema al área de memoria alta (HMA) mediante el comando DOS =HIGH dio un impulso adicional a la memoria libre.

Optimización del controlador y del TSR

Las tarjetas de expansión de hardware podían usar cualquier área de memoria superior para el direccionamiento de la ROM , por lo que los bloques de memoria superior eran de tamaño variable y se ubicaban en diferentes posiciones para cada computadora, dependiendo del hardware instalado. Algunas ventanas de memoria superior podían ser grandes y otras pequeñas. Al cargar controladores y programas residentes en memoria (TSR) en la parte superior, se seleccionaba un bloque y se intentaba alojar el programa en él, hasta encontrar un bloque donde encajara; de lo contrario, se cargaba en la memoria convencional.

Un aspecto inusual de los controladores y los TSR es que utilizaban distintas cantidades de memoria convencional y/o superior, según el orden de carga. Esto podía resultar ventajoso si los programas se cargaban repetidamente en diferentes órdenes, comprobando cuánta memoria quedaba libre tras cada carga. Por ejemplo, si existía una  UMB de 50 KB y otra de 10 KB, y se cargaban  programas que necesitaban 8  KB y 45 KB, los 8 KB podrían ocupar la UMB de 50 KB, impidiendo la carga de la segunda. Las versiones posteriores de DOS permitieron el uso de una dirección de carga específica para un controlador o TSR, para optimizar su compatibilidad.   

En MS-DOS 6.0, Microsoft introdujo una función que automatizaba el proceso de coincidencia de bloques, igualando la funcionalidad que ofrecían los administradores de memoriaMEMMAKER de terceros . Sin embargo, esta optimización automática a menudo no proporcionaba el mismo resultado que hacerlo manualmente, en el sentido de ofrecer la mayor cantidad de memoria convencional libre.

En algunos casos, empresas externas desarrollaron controladores multifuncionales especiales que combinaban las capacidades de varios controladores DOS estándar y programas residentes en memoria (TSR) en un único programa muy compacto que utilizaba solo unos pocos kilobytes de memoria. Por ejemplo, las funciones de controlador de ratón, controlador de CD-ROM, compatibilidad con ANSI, recuperación de comandos DOSKEY y almacenamiento en caché de disco se combinaban en un solo programa, consumiendo solo 1 o 2 kilobytes de memoria convencional para el acceso normal al controlador o a las interrupciones, y almacenando el resto del código del programa multifuncional en memoria EMS o XMS.

extensores de DOS

La barrera solo se superó con la llegada de los extensores de DOS , que permitieron que las aplicaciones de DOS se ejecutaran en modo protegido de 16 o 32 bits , pero estos no se usaron mucho fuera de los videojuegos . Con un extensor de DOS de 32 bits, un juego podía beneficiarse de un espacio de direcciones plano de 32 bits y el conjunto completo de instrucciones de 32 bits sin los prefijos de anulación de dirección/operando 66h/67h. Los extensores de DOS de 32 bits requerían soporte del compilador (compiladores de 32 bits) mientras que XMS y EMS funcionaban con un compilador antiguo dirigido a aplicaciones de DOS en modo real de 16 bits. Las dos especificaciones más comunes para los extensores de DOS eran compatibles con VCPI y, posteriormente, con DPMI para Windows 3.x.

El extensor de DOS compatible con DPMI más notable es DOS/4GW , incluido en Watcom . Era muy común en juegos para DOS. Un juego de este tipo consistía en un núcleo de DOS/4GW de 32 bits o en un fragmento que cargaba un núcleo de DOS/4GW ubicado en la ruta o en el mismo directorio, junto con un ejecutable lineal de 32 bits. Existen utilidades que permiten extraer DOS/4GW de un programa de este tipo y que el usuario puede experimentar con cualquiera de los diversos clones de DOS/4GW, algunos de los cuales podrían ser mejorados.

Antes de la llegada de los extensores de DOS, si un usuario instalaba memoria adicional y deseaba usarla en DOS, primero tenía que instalar y configurar controladores para que fueran compatibles con la especificación de memoria expandida (EMS) o la especificación de memoria extendida (XMS) y ejecutar programas compatibles con una de estas especificaciones.

EMS era una especificación disponible en todos los PC, incluidos los basados ​​en Intel 8086 e Intel 8088 , que permitía al hardware adicional paginar pequeños bloques de memoria ( conmutación de bancos ) del espacio de direcciones de "modo real" (0x0400–0xFFFF). Esto permitía a los programas DOS de 16 bits en modo real acceder a varios megabytes de RAM a través de un hueco en la memoria real, normalmente (0xE000–0xEFFF). Un programa debía entonces solicitar explícitamente la página a la que quería acceder antes de usarla. Estas ubicaciones de memoria podían utilizarse arbitrariamente hasta que fueran reemplazadas por otra página. Esto es muy similar a la memoria virtual paginada moderna . Sin embargo, en un sistema de memoria virtual, el sistema operativo gestiona todas las operaciones de paginación , mientras que con EMS la paginación era explícita.

XMS proporcionaba un protocolo básico que permitía a los programas DOS de 16 bits cargar bloques de memoria extendida 80286 o 80386 en la memoria baja (dirección 0x0400–0xFFFF). Un controlador XMS típico tenía que cambiar al modo protegido para cargar esta memoria. El problema con este enfoque era que, mientras se estaba en el modo protegido 286, no se podían realizar llamadas directas a DOS. La solución consistía en implementar un mecanismo de devolución de llamada, que requería reiniciar el 286. En el 286, esto suponía un problema grave. El Intel 80386 , que introdujo el " modo virtual 8086 ", permitía al núcleo invitado emular el 8086 y ejecutar el sistema operativo anfitrión sin tener que forzar al procesador a volver al "modo real". HIMEM.SYS 2.03 y versiones posteriores utilizaban el modo irreal en las CPU 80386 y superiores, mientras que HIMEM.SYS 2.06 y versiones posteriores utilizaban LOADALL para modificar registros internos no documentados en la 80286, lo que mejoraba significativamente la latencia de interrupción al evitar cambios repetidos entre el modo real y el modo protegido. [ 14 ]

Windows instala su propia versión de HIMEM.SYS [ 15 ] en DOS  3.3 y versiones posteriores. Windows HIMEM.SYS inicia el proveedor de servicios XMS (n).0 en modo protegido de 32 bits para el Administrador de máquinas virtuales de Windows, que luego proporciona servicios XMS (n-1).0 a las ventanas de DOS y a la máquina Windows de 16 bits (por ejemplo, DOS  7 HIMEM.SYS es XMS  3.0, pero al ejecutar el comando 'MEM' en una ventana de DOS de Windows 95  se muestra información de XMS 2.0).

Véase también

Referencias

  1. Norton, Peter (1986). Inside the IBM PC, Revised and Enlarged, Brady. ISBN 0-89303-583-1, pág. 108.
  2. Patente estadounidense 4,926,322 - Emulación de software de memoria conmutada por bancos mediante un monitor DOS virtual y gestión de memoria paginada , Fig. 1
  3. Yao, Jiewen; Zimmer, Vincent J. (febrero de 2015). "Libro blanco: Un recorrido más allá del diseño del mapa de memoria del BIOS en el BIOS UEFI" (PDF) . Intel Corporation . Archivado del original (PDF) el 30 de septiembre de 2015. Recuperado el 25 de agosto de 2016 .
  4. Russinovich, Mark Eugene ; Solomon, David A.; Ionescu, Alex (2012). Windows Internals . Vol. Parte 2 (6.ª ed.). Microsoft Press . pág. 322. Nótese la brecha en el rango de direcciones de memoria desde la página 9F000 hasta la página 100000...   
  5. Richter, Jeffrey. Aplicaciones de programación para Microsoft Windows . págs. 435 y siguientes. 
  6. 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 3 de marzo de 2016. Consultado el 13 de marzo de 2017 .
  7. 1 2 Paul, Matthias R. (1997-07-30). NWDOS-TIPs — Tips & Tricks rund um Novell DOS 7, mit Blick auf undokumentierte Details, Bugs und Workarounds [ NWDOSTIPs — Tips & tricks for Novell DOS 7, with special focus on undokumentierte details, bugs and workarounds ] . MPDOSTIP (en alemán) (3.ª ed.). Archivado del original el 6 de junio de 2016. Recuperado el 6 de junio de 2016 . (Nota: NWDOSTIP.TXT es una obra exhaustiva sobre Novell DOS 7 y OpenDOS 7.01 , que incluye la descripción de muchas características y aspectos internos no documentados. Forma parte de la colección MPDOSTIP.ZIP del autor, aún más extensa, que se mantuvo hasta 2001 y se distribuyó en numerosos sitios web en aquella época. El enlace proporcionado dirige a una versión anterior del archivo NWDOSTIP.TXT convertida a HTML).
  8. Petzold, Charles (1986). "Más opciones para ampliar las dimensiones de la memoria". PC Magazine . Vol. 5, n.º 11. ISSN 0888-8507 .   
  9. "Análisis de AllCard". Personal Computer World . Septiembre de 1986. pág. 138. 
  10. ^ Zerbe , Klaus (noviembre de 1987). Burgwitz, Andreas (ed.). "Speicher-Kredit - Todas las tarjetas de crédito para AT". c't-magazin für computertechnik . Prüfstand (en alemán). vol. 1987, núm. 11. Verlag Heinz Heise GmbH & Co. KG . págs.58 , 60. ISSN 0724-8679 .    
  11. Petzold, Charles (16 de septiembre de 1986). "Number Smasher/ECM" . PC Magazine . Accelerator Boards. Vol. 5, n.º 15. págs. 148, 150. ISSN 0888-8507 . Archivado del original el 3 de marzo de 2020. Consultado el 3 de marzo de 2020 .    
  12. Guía del usuario de Kontron - COMe-cBTi6R . Revisión del documento 1.0. Kontron . 2021. págs. 37, 60, 64. Archivado del original el 23/09/2023 . Consultado el 23/09/2023 . (89 páginas)
  13. Paterson, Tim (24-11-2007). "La primera máquina DOS" . DosMan Drivel . Archivado del original el 18-09-2021 . Recuperado el 23-12-2021 . IBM también reintrodujo limitaciones de memoria que yo había evitado específicamente al diseñar la CPU 8086 [tarjeta]. Para las computadoras S-100 , una alternativa de bajo costo al uso de una terminal de computadora regular era usar una tarjeta de video. Sin embargo, la tarjeta de video consumía parte del espacio de direcciones de memoria. La ROM de arranque normalmente también consumiría espacio de direcciones. Los sistemas SCP fueron diseñados para usarse con una terminal, y la ROM de arranque podía deshabilitarse después del arranque. Esto hacía que todo el espacio de direcciones de memoria de 1 MB estuviera disponible para la RAM. IBM, por otro lado, había limitado el espacio de direcciones en su PC a 640 KB de RAM debido al video y la ROM de arranque/BIOS. Esta limitación se denominó la "barrera de DOS 640K", pero no tenía nada que ver con DOS . Microsoft aprovechó al máximo las capacidades del sistema SCP . En 1988, años después del cierre de SCP, seguían utilizando el sistema para una única tarea que solo él podía realizar ("enlazar el enlazador"). Su máquina estaba equipada con 1 MB de RAM, distribuidos en 16 tarjetas de 64 KB. Dicha máquina no pudo ser retirada hasta que se desarrollaron herramientas de software de 32 bits para el microprocesador Intel 386 .    
  14. "HIMEM.SYS, modo irreal y LOADALL" . Museo OS/2 .
  15. "Descripción general de la funcionalidad de administración de memoria en MS-DOS" . Soporte técnico de Microsoft. 12 de mayo de 2003. Archivado del original el 12 de febrero de 2007. Consultado el 13 de agosto de 2012 .

Lecturas adicionales

Obtenido de " https://en.wikipedia.org/w/index.php?title=Conventional_memory&oldid=1328244241#Console_redirection "