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 marcov, 08.01.2024, 23:22

> OK, I just uploaded the first version of memory.htm with a lot of links and
> comments from Rugxulo and bretjohn. If it is not ok, please tell me.
> https://www.bootablecd.de/FreeDOS-Internet-version/help110/en/hhstndrd/help/memory.htm
I'll also try to phrase something, since the above writeup is as confusing as wikipedia. I quite often see confusion between extended/expanded memory on one side, and XMS and EMS on the other.

I sometimes use the term AT, which is a more standardise motherboard architecture for a 286. There are really _weird_ ones that aren't, but those are rare.
----------

Basically "extended memory" is what we now consider memory. So simms or dimms plugged into the motherboard, directly accessible/addressable memory to the CPU. It is the same memory as the first 1 MB, but simply the part that is isn't accessible directly in 16-bit CPU modes. (*)

Expanded memory is basically _any_ memory, anywhere (typically a plugin card in some slot), , made available over a driver. In XT times this was a way to expand memory beyond 1MB while the CPU and mobo couldn't handle it.

But even while the 286+ (or better AT, so 286 on a suitable AT mobo, some very early 286's excluded) could address more (than 1MB+64kb), it couldn't in 16-bit mode.

To make these kinds of physical memory (extended mobo, or off it) accessible to then still dominant 16-bit apps, APIs were defined.

The oldest API (which is "EMS") for access to expanded memory, basically instruments the driver to move the data from the external memory to the 16-bit page frame and vice versa. (the page frame is typically an area of 64KB in the 640-1MB area that is accessible to the processor in 16-bit modes, QEMM defaults to C000-CFFF IIRC). The API doesn't expose too many details.

XMS is a similar API that allows Extended memory to be copied between the Dos 1MB(optionally +64KB, A20) and the memory above that area. It is a bit more transparent and 1:1, since extended memory as directly CPU wired memory has to be transparent anyway.

Now the confusion starts, since Expanded memory can be anywhere, it can also be in Extended Memory.

So extended memory can be used for EMS too, and usually except for XTs and some weird systems, this has been the norm since the AT/286 era. Stronger even, since the 386 features a MMU, for 16-bit applications EMS can be very efficient, since the copying to and from the page frame can be done by zero copy memory mapping rather than copying.

Finally, the API DPMI is usually used with dos-extenders that puts the processor in protected mode (only briefly returning for real mode interrupts), so the application can access extended memory (286: 16MB 386:4GB) directly. For 386 systems, the startup code allocates all available memory via XMS, and then the application accesses it as "direct" memory till it terminates.

The only 286 PM programs that I made (Borland/Turbo Pascal 7) afaik got heap memory on the fly by doing heap calls when allocated. I.e. it didn't allocate anything up front, but 286 PM program.

The reason for this difference is that the 386 with its MMU can map all available memory, but only really allocate it (from the free XMS memory pool) when the CPU accesses it, and simulate it by swapping to disk if the XMS pool is empty.

(*) Something similar happened again when 32-bit got too tight, and they expanded the memory bus to 36-bit and defined an API (PAE) to allow special 32-bit apps like Exchange and SQL Server to handle more than 4GB. The OS usually was fully 36-bit (using a segmentation model), but the apps were accessing an API to escape the 32-bit constraints.

Post reply
 

Complete thread:

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