Electronics > Projects, Designs, and Technical Stuff

Memory management in IBM PC BIOS and DOS

(1/1)

JustClaire:
I am curious about how does DOS(and ibm pc basic) manage memory.

For instance, how does it determine how much memory is available to it and how does it reserve memory for applications, drivers, itself, etc. ?

Also, do DOS programs start execution at a fixed memory address or just at the lowest possible unoccupied location? What does it do if, for example a .exe application on a floppy requires more memory than it has acess to?

I know that my questions are not exactly about electronics but i dont know where else to ask them.

bjbb:
Search engines are our friends. All hail the emperors of thine (search) kingdom.

https://duckduckgo.com/?q=+ibm+pc+basic+memory+management&t=h_&ia=web

https://duckduckgo.com/?q=msdos+memory+management&t=h_&ia=web

Also look for 'segmented memory' and 'A20 handler'

T3sl4co1l:
General or vintage computing would be closer.  Stay tuned, a moderator will transfer your call. :P

I don't remember all of it, but offhand:
- EXEs are relocatable.  They contain a list of file offsets, which are rewritten by MSDOS.SYS on loading, to the next available segments (16 byte aligned).  A very simple sort of linking operation.  So, everywhere in the program there's a

--- Code: ---MOV AX, <seg>
MOV DS, AX

--- End code ---
and such, the <seg> is rewritten to the allocated value plus the program's offsets.

I don't know offhand where this list is stored (look up MS-DOS EXE file format, if you're curious), or exactly how the values are specified.  I assume it's something like, the base file assumes it's loaded at 0:0, and the loader adds the allocated offset to the initial values.

There are differen memory models used for DOS executables, or the assembly or linking of them, anyway.  In tiny and small model executables, code and data are in one segment (much like old fashioned COM files, but aware of segments).  In medium and large models, segments are whatever.  There's also huge, which is used with lots of segments and I think makes or allows some assumptions about >64k structures, I forget.  Also, I've probably forgotten exactly which of these models are which, so again, consult a DOS ASM manual please. :D

- When an EXE is loaded normally, it's loaded at the bottom, at the next available segment.

- DOS assumes worst case and allocates all free memory.  This value is available on an API call.  (Or, is it in CX or whatever on startup?  I forget.)  A program should free unused memory on startup.

- When loading an overlay, you can specify the offset.  (An overlay is another executable loaded on top of an existing one; this is used to "shell" out to other programs for example, or allows more complicated functions to be built from simple programs.  I forget if this is done automatically when piping stdout..?)

- More specifically, when COMMAND.COM runs a command, it finds the executable, loads it as an overlay, sets up initial values, then jumps into it.  If there isn't enough space, COMMAND.COM will unload itself (loading the overlay at its base offset I suppose), and I don't know if a chunk of COMMAND.COM is left at the bottom, or copied to high memory, or it's handled by MSDOS.SYS, but anyway, just a patch is needed to handle initializing and jumping into the new program, and reloading COMMAND.COM when it eventually exits (note that exit is done via INT 21h, AL=4Ch, not by RETing).  This triggers the "Please insert disk with COMMAND.COM into A:..." text on single floppy systems, for example.

- When loaded with a LOADHIGH command in CONFIG.SYS, or some other methods, the program will load from top of memory rather than bottom.  This is common for TSRs and such.  I guess I don't know what the difference really is, how important it is to do that, but it's something that can be done.  There are also upper memory blocks, on later systems, when there aren't devices mapped to the C0000-DFFFF range (display adapter already resides at A0000-BFFFF), and on 286+ systems when A20 is active (accessing addresses FFFF:0010 to FFFF:FFFF because the effective address doesn't wrap around as it does on 8086).  And 386+ systems with HIMEM.SYS, EMM386.EXE and such loaded (the CPU normally runs in real mode, but ISRs for these services jump into protected mode to perform their memory mapping magic; or, they jump into protected mode then jump back into virtual-86 mode as if being an impotent supervisor/OS?).

- If memory cannot be freed automatically, you'll have to figure out what to unload, or change boot settings to not load things that you can't unload anyway.  Hence the old shuffle trying to get some games to load...

Which... they could've been less lazy, and used overlays.  It's unlikely that most games need all the code and data in the EXE at the same time.  Load the core functionality, then load overlays according to game mode, graphics/sound, etc., whatever's in use at the time.  Code is just more data. ;D

As for DOS memory management and model, think there's a heap somewhere (upper memory, or OS area?) and that divvys up working RAM, tracking object name and stuff; this is what MEM interrogates.

Tim

Navigation

[0] Message Index

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod