DOS starting memory address

[Trixter]

Rumor has it that the book DOS Internals by Geoff Chappell dedicates chapter 4 to explaining the DOS memory management system. That's one way to get to the bottom of where the heap ("arena") memory structures are, but another way is to just write a short program that allocates a memory block and trace it. I'll try to remember to do the latter at some point.

[Trixter]

Okay, so I did that, and after wading around inside DOS for a while, I realized that jrconfig.sys probably isn't mucking around inside DOS structures (which isn't documented) but is likely simply altering the last memory control block (MCB) in the chain (which *is* documented). The author told me over the phone that while he didn't remember what he did, he definitely remembered it was "documented, no funny business".

I will look into how DOS handles the MCB chain.

[Trixter]

So, the MCB chain is set up *after* config.sys processing. So that was a dead end. Next step: Learn how to write a device driver, to see how it handles memory allocation.

[Brutman]

I think you are making this too complicated.

The first time jrconfig sees the system the BIOS ROM areas in RAM report that the DOS top of memory is at 112KB. The VGA is also programmed to expose a 16KB window starting at 112KB.

All jrconfig has to do is relocate the video window lower in RAM, tell DOS where the first available page of RAM for the free list is, and adjust the BIOS ROM area to indicate the true size of memory on the system. There is no need to muck with the free memory chain. Jrconfig does all of this fixup, and then soft boots the machine, probably leaving a cookie crumb in RAM so that it knows it was there once already. On the second boot the video RAM is in the correct place, DOS loads above that, and DOS thinks the system is bigger than what the BIOS originally reported. Jrconfig can see the cookie crumb that it left and then do other things, like turn on the keyboard click, setup for two drives, etc.

[Trixter]

With respect, your understanding of how jrconfig works is not correct. It especially doesn't do a second/soft boot, since device drivers that print something onscreen that come before it don't print twice when you boot. And DOS does load in the first 128K, which is why a DIR takes 3x longer on a PCjr (even with jrconfig) than on a PC. Only drivers after jrconfig, and command.com, load after the first 128k. You can verify this by traversing the device chain after boot.

You wrote something that sounds trivial: "tell DOS where the first available page of RAM for the free list is". That is not trivial -- it 's completely undocumented, and is all I've been trying to figure out this entire time (it's alan's post heading). There are blunt ways to do this (fixed buffer sizes in the device driver), and some sneaky ways (modifying the very first MCB somehow after config.sys is done processing), but so far a disassembly of jrconfig doesn't look like it does either of these. It's a shame the source was lost since it would really shed light on this. If you know how to "tell DOS where the first available page of RAM for the free list is", please enlighten me.

Once I learn how to write device drivers, I'm going to start the disassembly of jrconfig.sys again (without ramdisk, to keep it simple) with an eye on trying to understand exactly what part of memory it is modifying and why to make the next memory allocation -- which could be another device driver -- start at 128k.

[Brutman]

Before I go any further, do you care to explain how the BIOS messages for the jrIDE are showing up twice if jrConfig is not doing a warm boot in between as part of it's magic? On what planet would it be safe to run the BIOS ROM extensions twice in the same boot?

[Trixter]

I'll verify on my hardware before replying. My recollection is from non-jrIDE systems. If I never reply back, you can assume that I was horribly mistaken and wrong, and that all jrconfig is doing is massaging the BIOS data area.

[Brutman]

I don't even think that jrConfig has to massage the data area to do what it is doing. It doesn't even need to look at the warm boot/cold boot flag. It just needs to see where the video RAM is currently placed to know if it has been there or not. Maybe it leaves a cookie crumb somewhere just to be safe, but you'll have to disassemble it to find it.

I just ran a test where I did the following:

• Cold boot the machine. Let it boot from a DOS 2.1 floppy with no device drivers. The BIOS areas show that total system memory is 736K (because jrIDE makes it so) but DOS memory is 112K.
• Cold boot again. Boot from the hard drive once just to give jrConfig a chance to mess things up. Then when it tries to boot again, tell it to boot from A instead. This lets you see the state of the system in between the two boots. Now the BIOS areas show 736K and 736K for both values; jrConfig did that.

If I had bothered with a device driver "run the chain" program I would have seen that jrconfig looks like a device driver that just covers a lot of low memory. DOS will naturally load after whatever the device drivers consume, so jrconfig doesn't even have to do anything fancy to tell DOS where to load. It just needs to make it look like it's using the RAM, and DOS will load after it. In this manner it can protect the video buffer.

[Trixter]

Thanks for testing and confirmation. So the working theory is this:

- System boots
- jrconfig sees wrong top-of-ram variable at 40h:13h and adjusts it by detecting real amount of memory somehow
- jrconfig sets the flag for warm start by setting 40h:72h to "1234" (confirmed by looking at the BIOS source) to avoid the POST resetting everything
- jrconfig sets some sort of cookie to know it has done the above (or maybe uses the warm boot flag it just set?)
- jrconfig JMPs to FFFF:0 to start the boot process
- On re-run of jrconfig, cookie status checked, and if found, allocates RAM for itself to cover the remainder of the first 128K

I can get behind that. So I guess the last bit of info for me to know is how it requests/allocates memory. So I'm still going to research how device drivers are written.

[Brutman]

Some details are probably wrong, but that's about what I described earlier .. jrconfig moves the video buffer, fixes up some BIOS values, and then causes a warm boot. After that it does the other functions, like set keyboard clicker or the number of diskette drives.

I don't know if jrconfig keys off of the wrong top-of-RAM value or not. But that's one way to know if a memory manager has been there or not because on a Jr there are two such values; the real one (detected by the POST routine) and the one it tells DOS, and by default the one told to DOS is knee-capped to avoid DOS stepping on the video buffer.

Jrconfig may not have to put the 1234 value in place; that might be there after any boot by default. (It was already in place after I booted up a plain DOS 2.1 diskette.)

Jrconfig doesn't look to be setting the warm/cold boot flag as a cookie; when I interrupted it and had the second boot go to a plain DOS 2.1 diskette the 1234 was still in place. But it could have left a cookie in part of the video buffer, or in any number of places. If it even needs a cookie; that's speculation on my part.


See? My understanding of the boot process is pretty damn good. ;-0 I have some books on writing device drivers that I've gone through in the distant pass. Any of the 'Inside DOS' books will also give you a better understanding of the CONFIG.SYS processing.