Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

Is there a DOS memory documentation available? (Users)

posted by mceric, Germany, 08.01.2024, 00:58

Hi and happy new year and thanks for all the htmlhelp updates :-)

Not sure if I understand your question correctly, but...

- normal low DOS memory is at most 640 kB. Sometimes minus EBDA which is an extra BIOS data area, see SWITCHES /E Option to manipulate if you know what you are doing.

- UMB upper memory blocks, which are the area between 640 kB and 1 MB accessible by all 8086 or newer CPU in theory, but reserved for VGA RAM, BIOS and similar in practice. Drivers like RDOSUMB, HIRAM or URAM can activate normal RAM in unused areas between those in chipset-dependent ways on various mainboards and all sorts of EMM386 style drivers can make RAM visible in those areas if you have 386 or newer CPU. Sometimes, UMB have limitations such as not working with DMA for floppy or harddisk. Extra drivers bundled with the UMB drivers, or extra options for EMM386 can be used to work around or try to work around the limitations. Sometimes you just want to avoid to load certain disk, network or USB drivers to UMB instead. You can tell the FreeDOS kernel to move some data structures to UMB with DOSDATA=... and you can use DOS=... to move some other kernel things to UMB. See also FILESHIGH, I guess.

- HMA high memory area is 64 kB big and starts where the first 1 MB ends. You can use it on 286 or newer CPU, usually by loading HIMEM or similar drivers. You can use DOS=... to move large parts of the kernel to HMA. Other drivers can use remaining HMA space, but this is not done as easily in FreeDOS as in other DOS. See also FILESHIGH, I guess. Because the accessbility of HMA depends on the infamous A20 address line gate, you may have to help HIMEM or EMM386 to treat that properly if autodetection has resulted in wrong A20 handling.

- XMS extended memory is what HIMEM and similar drivers give you. Note that JEMMEX is a driver containing both EMM386 and HIMEM in a single driver. XMS are memory areas which you can ask the driver to copy to or from DOS memory (or UMB, maybe even HMA) as needed. Protected mode apps can also access XMS directly at the original location beyond 1 MB after telling HIMEM to lock areas so they keep a constant absolute location. You need 286, with common drivers even 386 or newer CPU to use XMS.

- EMS expanded memory is what EMM386 usually gives you, but there also are chipset-dependent hardware drivers for certain old mainboards with hardware EMS support and there were hardware expansion cards for EMS for really old computers. Either way, EMS consists of originally 16 kB, later 4 kB sized pieces of memory which you can make visible (map) at locations below 1 MB. For the 4 kB style, you need EMS 4, the 16 kB style is EMS 3.2 and the latter also is limited to make the 16 kB chunks visible in any quarter of a 64 kB page frame at a location which has to be a multiple of 64 kB. That page frame takes away space which you could otherwise use for UMB, so there is a misleadingly named NOEMS option for EMM386 style drivers which actually means that you need no page frame. You can still map 4 kB to various multiples of 4 kB within the first megabyte if you use EMS 4 even when your EMM386 is in NOEMS mode and has no fixed page frame. Because you make memory appear at other places instead of actually copying it, EMS can fast when you want to swap around memory areas, maybe for handling libraries or background music data in a game, in situations where you do not want to copy a specific part of your data, but want a whole subset of your data to be available in case you want to use it. XMS, on the other hand, is good when you already know which specific data area you want to be copied where, because you do not have to take the extra step of mapping there.

- VCPI is a low-level interface for EMM386 which lets it co-exist with other protected mode software, so it also involves memory mapping and allocation. It is not very popular outside DOS extenders, I would say. Note that Windows can be called a DOS extender in this context.

- DPMI is a more high-level interface to manage memory in a protected mode context. It is so comfortable that the CWSDPMI DOS extender basically just makes sure that you get DPMI, if necessary distilled from a number of other (!) types of memory access available in pure DOS, because apps compiled with DJGPP and similar compilers already feel fine with DPMI as a DOS extender, roughly speaking. Windows also provides DPMI to apps, but not for example VCPI, because the latter would be too low-level for smooth coexistance with apps directly using that.

- DOS Extenders make sure that apps can use more than 1 MB of memory taken from any suitable source of memory, using protected mode. So they may differ a lot in which types of memory they support or not.

- This also involves INT15 memory, which is a BIOS based way to access memory above 1 MB which is not otherwise relevant to most DOS apps, because they prefer to use the more DOS specific types of memory instead. So INT15 is more something relevant for HIMEM and EMM386 to either use or coexist with. In general, the BIOS has provided a number of different methods to get to know which memory and where is available for which purposes, often INT15 related, so DOS memory drivers like HIMEM have to take care to query the newest available sub-method and they may have to resolve ambiguities and contradictions if the BIOS is not properly designed.

Note that very specific DOS extenders can also make it possible for apps to use more than 4 GB of RAM or more than 1 CPU core. Neither are widespread yet, so most implementations of HIMEM or EMM386 will be limited to between 2 GB and 4 GB of usable RAM even if you have more installed, because things like graphics memory or MMIO areas and extra BIOS stuff etc. will block some amount of memory within the first 4 GB. In particular graphics RAM windows can be quite large with modern graphics hardware and few apps or drivers for DOS take the effort to use 36- or 64-bit addressing to reach beyond the first 4 GB. You can assume that the system RAM which you cannot access below 4 GB because graphics RAM uses the address space will be made available at some place above 4 GB, so 64-bit aware drivers can use all your RAM. This is similar to the UMB problem mentioned above, RAM covered by BIOS or by VGA RAM and therefore not available for UMB can sometimes still be made available at another address for other purposes such as EMS depending on your hardware and drivers.

---
FreeDOS / DOSEMU2 / ...

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 177 users online (0 registered, 177 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum