My German CD version of RoA: Blades of Destiny (Das Schwarze Auge: Die Schicksalsklinge) has EATXMS or similar utility to disable memory above 16 or 32 MB that may cause issues.

^ yeah eatXMS works too but IIRC you need to reboot the computer to get rid of it...

Mau1wurf1977 wrote:

Jorpho wrote:

HimemX might be a slightly more elegant workaround than a ramdisk.

Could you tell us more about this please?

There is not much more to say. It is a replacement for himem.sys that lets you specify an upper limit for the amount of XMS.
http://www.japheth.de/Jemm.html

I guess if a game has its own XMS manager or something then it might not be effective.

Or you could fill up everything above 16MB with disk cache:
http://johnson.tmfc.net/dos/driver.html

From the readme:

1      /R15   Sets the driver's XMS memory at 16- or 64-MB.   /R15 reserves
2      /R63      15-MB of XMS, and /R63 reserves 63-MB of XMS, for DOS game
3                programs that require XMS memory below 16- or 64-MB!

The reason for the most problems is that ISA DMA is limited to a memory area below 16 MB (same as memory mapped ISA devices). The 15-16 MB memory hole option in old BIOSses is related to this. Usually the memory manager as EMM386 or QEMM386 takes care that the DMA buffers are below 16 MB.
Still some games bring their own memory manager and then you have to make sure that the memory allocated is physically below 16 MB. Usually programs allocate from down to top, f.e. if you load Smartdrive with 16 MB cache it allocates the upto 17 MB. Now even if you would have free XMS/EMS in such scenario it would be beyond 16 MB physically. This is why Privateer plays just garbled sound then, because the playback is not from the actual buffer but from some memory below 16 MB.

There are mainly two strategies to arrange the memory for this:
1. Use some memory manager that makes only the lower 16 MB available.
2. add some program that takes all memory above 16 MB and leaves the memory below 16 MB available.

1. is ok as long as you don't use a program that could use more memory
2. needs specific programs that take memory from top. Some XMS disks are capable of this.

So normally it is no problem to plug more memory as 16 MB. But for some games you have to have the right tools available. I have a Pentium 166 MMX system with 384 MB RAM which is nice for NT4, but I usually load in DOS a XMS Ramdisk on top to cover the top memory. So f.e. Wing Commander IV runs flawless.

Mau1wurf1977 wrote:

device=c:\dos\emm386.exe ram 16000

for example resolves the issue on machines with more than 16MB.

The issue is garbled / screeching speech.

Fascinating.
Based on my experience, Gobliiins may also have this problem.

simcity2000 seems to freeze within minutes into the game on rigs with large memory, although i dunno what the limit is. the smallest ram module i have now is 128mb...

Not sure if relevant, but Realms of Arkania 2 - StarTrail works fine with 512MB SDRAM memory.

Via regular DOS-window(no restart) on win98. Cannot recall me doing anything special to get it to work, but I may be mistaken.
(edited the properties of the desktop shortcut perhaps?)

Same goes for BladeOfDestiny.

^ inside windows you can get away with memory problems , it's in pure DOS that the problem appears

Mau1wurf1977 wrote:

Looking at it from another perspective: Do any games MS-DOS "need" more than 16MB RAM. Or run significantly better with it?

Shadow Warrior with 3DFX patch requires 32MB of RAM. Several of late DOS games (like Jetfighter III and Fullburn) recommends 32MB RAM.

Not really relevant to this thread, but as a (sort of related) aside, on the Atari ST, a few games wouldn't work on machines that had more than 2MB (the maximum the ST had was 4MB). It was easily fixable by running a program that made the ST think it had 2MB (or less), and there weren't too many games that suffered from this bug (Civilisation is the only one I can think of, offhand).

Actually, even more of an aside (since this is a console, not a computer) on the Nintendo 64, there was one game that wouldn't work if you had the 4MB expansion pak attached (which doubled the N64's memory to 8MB); Space Station: Silicon Valley, a rather good 3D platform game* by the people who went on to make the Grand Theft auto Games. Since this was a (cartridge based) console, no easy fix was possible, but the bug was only in the NTSC version, and only then in early batches of the cartridge.

There's this also:

http://www.uwe-sieber.de/files/getxms.zip

working wonders teamed with this:

http://ftp.sunet.se/pub/simtelnet/msdos/bootutil/wrap10.zip

The main idea is to reserve a block of XMS after the XMS manager loads, load everything you need (cache/RAMdisk/whatever), and free the first block. That way free mem comes first and is available for DMA transfers.

Example config.sys would look something like this (taken from mine, your mileage and options may vary):

DEVICE=C:\DOS\UMBPCI.SYS /I=CC00-DFFF <-- UMBs in real mode, reserves E000-EFFF for JEMM386's EMS pageframe)
DEVICE=C:\DOS\XMGR.SYS <-- XMS manager
DEVICE=C:\DOS\WRAPPER.SYS C:\DOS\GETXMS.EXE 65535 <-- reserves first 64MB RAM
DOS=HIGH,UMB <-- Old classic
DEVICEHIGH=C:\DOS\UIDE.SYS /F /H /S128 <-- Loads 128 MB hard disk/CD cache
DEVICEHIGH=C:\DOS\XMSDSK.EXE 65535 <-- Loads 64 MB RAM disk

(WRAPPER.SYS is needed to run programs from config.sys)

autoexec.bat:

@ECHO OFF
C:\DOS\SHCDX33F.COM /D:DVD1 <-- CD-ROM redirector
C:\DOS\FREEXMS.EXE <-- Frees the 64 MB reserved with GETXMS.EXE

no more problems with games like Goblins 3 that require first 16MB for DMA ^^

A very useful tool for checking XMS stuff is XMSSTAT.EXE included with JEMM386 here: http://www.japheth.de/Jemm.html

P.S.: Almost forgot, this is for MS-DOS 5-6/PC DOS. Users of MS-DOS 7-8 who want to use WRAPPER.SYS will need this:http://www.mdgx.com/files/FIXWRAP.ZIP

^ PoulpSquad , excellent info, I had no idea about getxms/freexms! 😮

also about the first 16MB and their DMA buffering stuff, the XMSDSK/EMSDSK ramdisk that I posted in a previous post, have the /t switch that automatically allocates their ram above 16MB (from upper addresses to lower ones) so you can be sure that whatever free ram you have will be on the 16MB region 😊

What can a 386/486 with more than 16 mb RAM profit from this? I mean, most freedos components require a Pentium (uide for one). Does the rest work flawlessly on a 386/486 with DOS7 ?

Also, as far as I can remember, XMGR is not a 100% substitute for Microsoft himem.sys. Sadly I scarcely document the results of my fiddling around but I found one or two games that would chew and spit out XMGR and work happily with MS himem.sys on a P1 166, 64 MB RAM.

This is not to discard freedos - I am just saying I did not find it 100% compatible a few yrs back.

@ Jolaes76
IMHO nothing really needs more than 8MB on a 386 and maybe the limit for a 486 is 32MB assuming you can play with decent framerates the latest games like Shadow Warrior or Dune Nukem 3D...

Still in some almost all cases we do put more ram than needed in builds so we can have smartdrv (really helps at least on my 386/486 systems) or just have a worry less about free memory...

Regarding freedos components, I found that SHSUCDX is not 100% compatible too, had a couple of games not running and I remember that Fade2Black did not play the videos from the CD with SHSUCDX , with MSCDEX it worked fine
I don't believe that freedos is made to replace DOS in older machines, AFAIK it is made to have a DOS environment on recent ones.
TBH I am not even sure that DOS7 is made for older 386/486 machines 😜

Of course, the only reason to put more RAM in a 486 is to have a smoother Windows "experience".

The only use of Win95 in my 486 systems is the comfort for file transfers with Total Commander... 😀

Crazy as sounds, it would be nice to have DOS7 and FAT32 support on my 286 as well... 😁

Jolaes76 wrote:

What can a 386/486 with more than 16 mb RAM profit from this? I mean, most freedos components require a Pentium (uide for one). Does the rest work flawlessly on a 386/486 with DOS7 ?

Also, as far as I can remember, XMGR is not a 100% substitute for Microsoft himem.sys. Sadly I scarcely document the results of my fiddling around but I found one or two games that would chew and spit out XMGR and work happily with MS himem.sys on a P1 166, 64 MB RAM.

This is not to discard freedos - I am just saying I did not find it 100% compatible a few yrs back.

I don't like FreeDOS a lot myself, but *some* components are pretty good.

XMGR just happens to be the XMS manager I'm using so I used it in my little example. You can replace it with whatever XMS manager you like. It would be really nice to know what games gave you problems with XMGR. If you ever remember them, please post their names! I had loads of problems with FreeDOS' HimemX (Ultima 7 for instance), and ended up with a 35 KB Himem.sys sitting in conventional memory on my PII/256 MB RAM...

UMBPCI requires a full PCI BIOS, so 386/486 and early Pentiums can't benefit from it, but there's HIRAM and DOSMAX for older machines (http://www.uwe-sieber.de/files/hiram.zip and http://www.uwe-sieber.de/files/dosmax21.zip).

As for UIDE (http://johnson.tmfc.net/dos/file/drivers.zip), I think it works on a 386. I can't be sure 100% because I don't have a 386, but it states in its doc it works. It's the best caching software in my opinion, fast with a ridiculously small memory footprint compared to SMARTDRV, with the added benefit of an integrated CD/DVD driver and support for BIOS drives (SCSI/USB/you name it).

SHCDX33F puts MSCDEX to shame in every possible way, and works on a 386 as far as I know.

I think a 386 could mostly benefit from a lower memory footprint and "modern" 32 bit tools. Himem+MOUSE.COM+SMARTDRV+MSCDEX vs. HIRAM+CTMOUSE+UIDE+SHCDX33F... we're talking about maybe 50+ KB

To be a little more on topic, some games following XMS 1.0 and 2.0 standards can have problems if they detect more than 32767 KB of RAM (again, Goblins 3 seems to be a good study case). A tool like GETXMS/FREEXMS proves useful to gobble memory until there's 32767 KB or less memory. That way you can use your RAM drive for something useful instead of just filling memory chunks with it ^^.

^ SHSUCDX does run on a 386sx , 486slc2 and 386DX - I have tested it before I went back to MSCDEX.

I have also found that "The Last Byte Memory Manager" has better succes rate than HIRAM/DOSMAX... I couldn't get those working on my 386DX and 486 build whereas TLB just worked . If you can get UMB enabled then MSCDEX or other older programs are not a problem anymore since you load them high. I prefer them due to compatibility reasons.

Also DOS7.1/FAT32 works fine on the above 386sx+ machines. It's when you start using WIN3.x things might get weird (even after patching win3x to not mind dos7.1 and fat32) and then you need a PCI 486 and above to be sure it just works with little effort. Sounds strange I know but that's what I got from my tests. I really think it's a BIOS/chipset thing. Ofcourse your mileage may vary...

.... don't forget that with mTCP's ftpserver app you really don't need any windows environment just to make file transfers 😉

I was trying very hard to set up an ftp server on my Amptron clone VLB 486 board but it always gave me a warm boot. And when I set up the server on my everyday computer (Win7) and the client on the 486 the connection was not established. I might try it again with a better board and PCI LAN instead of ISA.

strange, I am using both ISA and PCI nics... maybe the dos driver is not good?
I actually setup the ftpserver on the retroPC side and use flashfxp/filezilla on win7/x64 ...