Upper Memory Area
Die Upper Memory Area (UMA) ist ein Speichertyp von MS-DOS und dazu kompatiblem DOS, die im ursprünglichen Design des IBM Personal Computer mit 384 KB (= 393.216 Bytes) von IBM definiert wurde. Dabei wurde der maximal mögliche Arbeitsspeicher des IBM PC, der mit dem 16-Bit-Prozessor Intel 8088 maximal 1 MiB adressieren kann, in zwei Bereiche unterteilt: den konventionellen Speicher bis 640 KB (= 655.360 Bytes) und den Rest, der sich bis zur 1-MB-Grenze (= 1.048.576 Bytes) ausgeht, für diverse ROMs und den Grafikspeicher. Weil die UMA in den meisten Fällen nicht vollständig genutzt wird, werden freie Bereiche daraus in zusammenhängenden Böcken, den UMBs (englisch „Upper Memory Blocks“), für das Betriebssystem und Programme nutzbar. Der deutsche Begriff „oberer Speicherblock“ für UMB findet sich jedoch selbst in der Speicherverwaltung von DOS kaum, wie auch „oberer Speicherbereich“ für die UMA, weil diese oft mit dem „hohen Speicherbereich“ (High Memory Area, HMA) verwechselt wurden.
Die Nutzung UMBs in DOS wurde von Digital Research im Mai 1990 mit DR DOS 5.0 eingeführt, Microsoft zog im Juni 1991 mit MS-DOS 5.0 nach.
Details
[Bearbeiten | Quelltext bearbeiten]Der Adressraum oberhalb der Speicheradresse A0000hex (entspricht 640 KB) ist für Zusatzhardware (Grafikkarten, SCSI-Controller und Ähnliches) und für das BIOS reserviert. Bei den ersten IBM PCs (wie dem IBM 5150), die gerade einmal 64 KB RAM als Arbeitsspeicher hatten, bedeutete dies keine nennenswerte Einschränkung. Später wurden die Programme jedoch immer speicherhungriger, viele verlangten, dass ein sehr großer Teil des konventionellen Speichers (unterhalb von A0000hex) für sie selbst verfügbar war. Dies stellte dann ein Problem dar, wenn auch noch diverse Treiber und TSR-Programme in den konventionellen Speicher geladen werden sollten – der verbleibende Speicher war dann letztlich für viele Programme zu klein. Zugleich wurde der Adressraum oberhalb von A0000hex aber nur in den seltensten Fällen von Zusatzhardware und dem BIOS komplett belegt; meist blieben hier zwischen 128 und 256 KB ungenutzt, und zwar nicht direkt nach dem Ende des konventionellen Speichers bei A0000hex (hier sitzt die Grafikkarte), sondern in der Mitte des reservierten Bereiches, maximal von C8000hex bis F8000hex.
Konventionelle DOS-Programme können diesen speziellen Adressraum zwar adressieren und problemlos nutzen, allerdings befindet sich hier eben kein Arbeitsspeicher, da der Bereich ja für Zusatzhardware freigehalten wird. Möchte man Programme, Treiber oder TSR-Programme nicht in den konventionellen Speicher laden, sondern dafür UMBs nutzen, muss der jeweilige Adressraum als RAM angesprochen werden können. Dies ist auf 8088/8086- bis 80286-basierten PCs nur eingeschränkt möglich, da x86-Prozessoren erst mit dem 80386 eine Speicherverwaltungseinheit (MMU) besitzen. Der obere Speicherbereich (UMA) ist daher nicht automatisch nutzbar, da ungenutzte Bereiche meist entweder nicht zugeordnet oder schreibgeschützt sind. Auf PCs mit diesen Prozessoren sind UMBs daher nur auf gewisser Hardware, beispielsweise auf Mainboards mit speziellen 286-Chipsätzen oder wenn eine EMS-Erweiterungskarte mit UMA-Unterstützung vorhanden ist, und dann nur mit erhöhtem Aufwand einzurichten, sofern spezielle Treiber vorhanden sind.[1] Teils können auch Bereiche der UMA, die eigentlich für andere Zwecke gedacht sind, mit Treibern in UMBs umgewandelt werden, stehen dann aber nicht mehr für die ursprüngliche Funktion zur Verfügung: beispielsweise kann bei manchen Grafikkarten der Adressraum für den Grafikspeicher mit einem spezifischen Treiber in UMBs umgewandelt werden,[2] allerdings kann dann nur mehr der Textmodus genutzt werden – bei Verwendung des Grafikmodus würde derselbe Speicherbereich für UMBs und den Grafikspeicher verwendet, was zu Instabilitäten und Abstürzen führt. Mit einer für die Retrocomputing-Szene entwickelten 8-Bit-ISA-Speicherkarte[3] und einem generischen, aber manuell zu konfigurierenden DOS-UMB-Treiber[4] können sogar auf einem originalen IBM PC (oder einem kompatiblen Nachbau bis zum PC/AT) UMBs konfiguriert und diese von einem kompatiblen DOS, wenn dieses UMBs verwalten kann, für Treiber und TSRs genutzt werden.[5]
Ab dem i386 kann gewöhnlicher RAM von höheren Adressen jenseits der 1-MB-Grenze (Extended Memory) in den Adressraum der UMA „verlegt“ werden. Dafür gibt es generische Treiber wie beispielsweise EMM386.EXE
oder UMBPCI.SYS
. Diese sorgen dann dafür, dass RAM in den UMBs sichtbar wird.
Der konventionelle Speicher muss unter DOS ein einziger zusammenhängender Adressraum sein, daher sind die UMBs nicht direkt als Teil des konventionellen Speichers verwendbar. Damit nun trotzdem Treiber und TSR-Programme in dieses RAM geladen werden können, muss auch das Betriebssystem die Verwaltung übernehmen; die in MS-DOS und PC DOS dafür verwendeten Befehle sind DEVICEHIGH
in der CONFIG.SYS für Treiber und LOADHIGH
(kurz LH
; z. B. in der AUTOEXEC.BAT) für TSR-Programme, die ihr Ziel jeweils in UMBs laden. Unter DR DOS 5.0 heißen die Befehle mit HIDEVICE
und HILOAD
ähnlich, DR DOS 6.0 unterstützt beide Varianten. Außerdem wurde in MS-DOS 5.0 ein neuer Systemaufruf (via Interrupt 21hex, Funktion 5803hex) eingeführt, mit dem ein Programm dem Betriebssystem signalisiert, dass es für Speicheranforderungen auch Speicher aus der UMA akzeptiert. Alternativ kann der XMS-Treiber (z. B. HIMEM.SYS) explizit angesprochen werden, um über die API-Funktion 10hex Speicherbereiche in der UMA zu reservieren[6]. Auf diese Weise kann die Menge an frei bleibendem konventionellen Speicher erhöht werden, so dass für gewöhnliche Anwendungsprogramme und Spiele mehr Speicher übrig bleibt.
Begriffsverwirrung
[Bearbeiten | Quelltext bearbeiten]In den deutschsprachigen MS-DOS-Versionen, die die High Memory Area (HMA) unterstützten, wurde diese als „oberer Speicherbereich“ bezeichnet. Als die Unterstützung für UMBs hinzukam, verwendete man dann für diese den Namen „hoher Speicherbereich“. Die Benennung war also im Deutschen gerade umgekehrt gehandhabt wie im Englischen, was zusammen mit der insgesamt schweren Verständlichkeit der MS-DOS-Speicherverwaltung zu viel Verwirrung bei den Anwendern führte. Erst unter Windows 95 wurden die deutschen Begriffe vertauscht, so dass sie nun den Englischen direkter entsprachen.
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ Eric Auer: freedos/news/technote/202.txt. freedos.org, 2002, archiviert vom (nicht mehr online verfügbar) am 2. September 2005 (englisch): „This document combines several mails that wandered around in fd-dev … during October 2002. … Matthias Paul and yet another technical mail … Sat, 26 Oct 2002 … Subject: Re: [fd-dev] Memory management FAQ … Matthias also points out that DR-DOS HIMEM.SYS has RDOSUMB/URAM like features for several 286/386 chipsets. This will give you XMSUMB or UMB. It can even use EMS to create UMB. Not practical if you ask me: Normally, you load the XMS driver FIRST, and normally, EMS drivers provide UMB already. Matthias mentions EMMXMA of DR-DOS: This one uses PS/2 XMA memory extension cards to offer EMS. DR-DOS HIMEM.SYS can also – like RDOSUMB/URAM – detect existing RAM in the UMB area and turn it into UMB/XMSUMB. Useful if you can enable some RAM though your CMOS setup. I remember I could do this with a NeAT 386SX chipset…“
- ↑ Beispiel für einen UMB-Treiber, der Grafikspeicher der UMA „umwidmet“: UMBHERC.SYS kann 60 kB des 64 kB großen Videospeichers einer Hercules-Grafikkarte als UMBs zur Verfügung stellen.
- ↑ Adrian Black: 8-bit ISA RAM expansion board with UMB support. In: GitHub. Abgerufen am 8. Juli 2025 (englisch): „This card only supports conventional memory, no EMS. Extra RAM can be mapped into the high memory space (above 640k) allowing for UMB on XT machines.“
- ↑ Der Treiber
USE!UMBS.SYS
wurde von Marco van Zwetsalaar um 1991 geschrieben und ist Public Domain. Der Treiber stellt auf 8088/8086- bis 80286-PCs verfügbare und beschreibbare Speicherbereiche („RAM“) der 384 KB großen UMA in Form von MS-DOS-kompatiblen UMBs (ab MS-DOS 5.0) bereit. - ↑ Detlef Grell: Retro-Plattform Monotech NuXT: IBM-XT-Nachbau mit 8088-CPU im Test. In: Heise online. 10. November 2020. Abgerufen am 8. Juli 2025.
- ↑ http://www.phatcode.net/res/219/files/xms30.txt