DOS ain't dead

> I realize the whole 4 GB address space cannot be directly used in DOS in
> 32-bit systems because of virtual mapping, etc. The most I've been able to
> get HIMEM.SYS ver. 3.0 to see is 3328 MB. This is with an old 128-MB ATI
> Radeon 9200 card. Am I correct in assuming that reducing the total video
> memory will augment the total available DOS RAM? So using an old 4 MB or 8
> MB card would give me more addressable memory?

Not per se. A card can map more than it has memory.

The main culprit seem to be modern chipsets that require a full 256MB mapping.

PAE and memory remapping could be a solution, since under Dos, mostly only BIOS accesses the roms? Note that I haven't researched this, it is just intuitive.

Btw, what's the matter with all these new chipsets that come with big warning stickers "can't run win9x" ? Is this something only matters for support, or is it something major?

> I'm surprised the HIMEM.SYS even sees above 2 GB, and I was able to use HX
> DOS-extender to run Win32 apps like PIFAST 4.3, and utilize above & beyond
> 3 GB of memory.

Note that many programs, specially C ones doing pointer arithmetic might have problems when using address over 2GB.

> What about PAE -extensions in DOS to utilize > 4 GB memory on a 64-bit
> CPU?

A lot of older Xeons also support PAE. Not just 64-bit ones.

> I realize the whole 4 GB address space cannot be directly used in DOS in
> 32-bit systems because of virtual mapping, etc. The most I've been able to
> get HIMEM.SYS ver. 3.0 to see is 3328 MB. This is with an old 128-MB ATI
> Radeon 9200 card. Am I correct in assuming that reducing the total video
> memory will augment the total available DOS RAM?

Precisely because the video card has its own RAM, you can tell DOS memory managers to free up the system RAM that DOS normally reserves for video. But you still won't get the whole 4GB, or whatever the amount of system RAM is, because some will still be reserved for system or DOS use.

> So using an old 4 MB or 8 MB card would give me more addressable memory?

If your system recognizes it, and if you have the drivers for it.

> Can 16-bit apps be tweaked to see > 2 GB. Specifically, I'm wanting to
> create a RAMDISK over 2 GB in FAT16, utilizing 64-kb clustersize.

DOS and apps see a RAM disk as a disk, not RAM. Apps don't care about disk size (unless they run out of it when writing new files).

> I'm surprised the HIMEM.SYS even sees above 2 GB, and I was able to use HX
> DOS-extender to run Win32 apps like PIFAST 4.3, and utilize above & beyond
> 3 GB of memory.
>
> What is the closes anyone on this board has gotten to utilizing the full 4
> GB on their DOS systems?

Not nearly that much because I only have 1 GB RAM on this laptop.
Yesterday I did use about 850 MB in testing paq8o8z (although it didn't barely help more than 133 MB did).

> Can 16-bit apps be tweaked to see > 2 GB. Specifically, I'm wanting to
> create a RAMDISK over 2 GB in FAT16, utilizing 64-kb clustersize.

XMSv3 supports really large amounts of RAM, so you can use SHSURDRV (386 version) to make a really big RAM disk. It comes w/ NASM src.

XMSv2 is the 16-bit variant, and I think that usually maxes out at 64 MB (even though a 286 can only max. handle 16 MB). So not sure what you mean by "16-bit apps", but in general, you probably want 386+.

> What about PAE -extensions in DOS to utilize > 4 GB memory on a 64-bit
> CPU?

Untested by me, but there is a DOS/32A PAE hack (usable by OpenWatcom/DOS/32-bit, e.g. LE/LX format only):


[2007-01-14]: dos32a_PAE_update.zip - by Charles Hyde - updated PAE patch

> All thoughts & comments on this much appreciated!

CWSDPMI r5 limits you to 512 MB. As you've noticed, HDPMI32 doesn't have such limitations. I think CWSDPMI r6 (beta) is better for large RAM. It can use 4 MB pages, which is faster, and it won't swap out on you as soon either (once 512k page tables are used low). And as far as DJGPP's libc goes, I think it has 2 GB signed pointer issues, so you may have to use sbrk() directly instead of indirectly via malloc(). In other words, CWS has suggested call sbrk() twice in succession for 1.5 GB each time if you want to alloc 3 GB. (PMODE/DJ can alloc 2 GB okay too, supposedly, but it's considered not as good.)