VOGONS


Dos 6 conventional memory tricks

Topic actions

Reply 100 of 298, by Jorpho

User metadata
Rank l33t++
Rank
l33t++
valnar wrote:

but for those who don't know, FreeDOS has had compatibility problems its entire existence.

It has had an exceptionally long existence, and I would have thought some of those compatibility problems would be diminished by now. Can you go into more detail?

Reply 101 of 298, by PhaytalError

User metadata
Rank Member
Rank
Member
Jorpho wrote:
valnar wrote:

but for those who don't know, FreeDOS has had compatibility problems its entire existence.

It has had an exceptionally long existence, and I would have thought some of those compatibility problems would be diminished by now. Can you go into more detail?

While it's rare and total random some games simply don't run properly with FreeDOS... sometimes they glitch out, slow down, or have quirks that make them unplayable. Windows 3.1 / Windows 3.11 WFWG absolutely won't run in 386 mode and this has been known for years which the FreeDOS developers have not fixed, etc even though users have requested it for many years to be fixed.

For a DOS that's been around since 1994, you'd think they would have 100% MS-DOS compatability by now (it's been almost 20 years in development).

DOS Gaming System: MS-DOS, AMD K6-III+ 400/ATZ@600Mhz, ASUS P5A v1.04 Motherboard, 32 MB RAM, 17" CRT monitor, Diamond Stealth 64 3000 4mb PCI, SB16 [CT1770], Roland MT-32 & Roland SC-55, 40GB Hard Drive, 3.5" Floppy Drive.

Reply 102 of 298, by Jorpho

User metadata
Rank l33t++
Rank
l33t++
PhaytalError wrote:

While it's rare and total random some games simply don't run properly with FreeDOS... sometimes they glitch out, slow down, or have quirks that make them unplayable.

But which ones, specifically?

Windows 3.1 / Windows 3.11 WFWG absolutely won't run in 386 mode and this has been known for years which the FreeDOS developers have not fixed, etc even though users have requested it for many years to be fixed.

There seems to be a lot of conflicting information about that. Have you tried it yourself?

I can definitely agree that their documentation is a catastrophe, so if there's actually a place that tracks these things unambiguously, that would be very interesting.

Reply 103 of 298, by valnar

User metadata
Rank Oldbie
Rank
Oldbie

Jorpho, I did not keep a log of games that did not work. I guess I'm not that scientific. But after enough problems, I saw no need to continue playing with something so unstable. I do recall it wouldn't even work in VMware (or was it VirtualPC?) without crashing the VM. I think I have a thread on that here in Vogons. Then there is issue with certain aftermarket memory managers...

I guess the better question for you is, why do you want it to work so badly? It's easy to pick up a copy of MSDOS 6.22 from eBay for $10.

Reply 104 of 298, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

I'm curious more than anything. As has been said, it's been almost 20 years now; if it's really that bad, what could the problems be?

Besides, MS-DOS has its own inconvenient limitations, and not everyone is inclined to go buy MS-DOS on eBay. It's not like it will be available there forever anyway.

Reply 105 of 298, by jwt27

User metadata
Rank Oldbie
Rank
Oldbie

I haven't found any games that are completely incompatible with the FreeDOS kernel. Some game are incompatible with certain memory managers, that's why I use a config.sys menu to switch between UMBPCI+XMGR and JemmEx. Just about anything will run with either one or the other. If configured correctly, FreeDOS is a very fast and quite stable OS, requiring very little memory (I have 627k base memory free with everything loaded, see the link in my sig.)

One thing I noticed which I think may be caused by the FreeDOS kernel itself is this bug in adtrack2.

Reply 106 of 298, by Samir

User metadata
Rank Member
Rank
Member

I'm new here, but I ooohhh so remember the days of manually tweaking all my autoexecs and configs for conventional memory.

The best thing I found was to use a program that I don't remember anymore to actually 'look' at all my memory 1mb and below. You could see which regions had a bios in it, which were empty, which were free, which were allocated, but actually had nothing in them.

Then I'd map those regions and figure out how much free space I had in each region. Then I'd take all my drivers and figure out which one should fit where. Then I'd program them in into the autoexec and config and test. If there's a problem, readjust and test again.

It would usually take a whole day to do this, but in the end, I'd have everything I want running, including smartdrive, network drivers, and niceities like doskey. 😀

I know I've still got those carfully configured files still sitting on my old systems. Too bad I haven't booted some of them in a decade now. 🙁

Reply 107 of 298, by schlang

User metadata
Rank Oldbie
Rank
Oldbie
DonutKing wrote:

Even if you don't want to use dosmax, I got instantly positive results from simply adding these switches to emm386:
DEVICEHIGH=C:\DOS\EMM386.EXE AUTO RAM M3 A=64 H=128 D=256 HIGHSCAN X=B800-C7FF I=C800-EFFF I=B000-B7FF NOTR

just a note, I remember that some games crash when you include specific ranges using the I=XXXX parameter

PC#1: K6-III+ 400 | 512MB | Geforce4 | Voodoo1 | SB Live | AWE64 | GUS PNP Pro
PC#2: 486DX2-66 | 64MB | Riva128 | AWE64 | GUS PNP | PAS16
PC#3: 386DX-40 | 32MB | CL-GD5434 | SB Pro | GUS MAX | PAS16

Think you know your games music? Show us: viewtopic.php?f=5&t=37532

Reply 108 of 298, by Samir

User metadata
Rank Member
Rank
Member
schlang wrote:
DonutKing wrote:

Even if you don't want to use dosmax, I got instantly positive results from simply adding these switches to emm386:
DEVICEHIGH=C:\DOS\EMM386.EXE AUTO RAM M3 A=64 H=128 D=256 HIGHSCAN X=B800-C7FF I=C800-EFFF I=B000-B7FF NOTR

just a note, I remember that some games crash when you include specific ranges using the I=XXXX parameter

And this would probably be because they think that those regions aren't used, like on the original PC and XT and try to use them directly. Easy enough fix though by just having a menu setup in DOS to load a different config. Or you can just F8? (F5?) your way through every line item.

Reply 109 of 298, by schlang

User metadata
Rank Oldbie
Rank
Oldbie

problem is that you just have to guess WHY the game crashed - it does not tell you "hey you are stealing blocks B000-CFFF" 😉

PC#1: K6-III+ 400 | 512MB | Geforce4 | Voodoo1 | SB Live | AWE64 | GUS PNP Pro
PC#2: 486DX2-66 | 64MB | Riva128 | AWE64 | GUS PNP | PAS16
PC#3: 386DX-40 | 32MB | CL-GD5434 | SB Pro | GUS MAX | PAS16

Think you know your games music? Show us: viewtopic.php?f=5&t=37532

Reply 110 of 298, by Samir

User metadata
Rank Member
Rank
Member
schlang wrote:

problem is that you just have to guess WHY the game crashed - it does not tell you "hey you are stealing blocks B000-CFFF" 😉

True, but the first thing I always did when I had a consistent crash on something like that was to boot up to a bare DOS with very minimal settings and try it. Usually there was enough conventional. If it crashed there, then it probably wasn't memory related. If it worked, then I'd just build a config for it.

Reply 111 of 298, by DonutKing

User metadata
Rank Oldbie
Rank
Oldbie

It's not so much the I= parameter that is causing the crash - its that you are using it to include memory ranges that are already used.
You can use MSD.EXE or a similar program to view the memory map and identify free upper memory ranges.

I still use a similar EMM386 config and I haven't run into any games that don't work (except Ultima 7 or Zone 66 which will never run with EMM386 anyway).

If you are squeamish, don't prod the beach rubble.

Reply 112 of 298, by Samir

User metadata
Rank Member
Rank
Member
DonutKing wrote:

It's not so much the I= parameter that is causing the crash - its that you are using it to include memory ranges that are already used.
You can use MSD.EXE or a similar program to view the memory map and identify free upper memory ranges.

But even sometimes when these ranges appear free, programs will directly address them, bypassing any memory managers--then you have a mysterious crash.

I forgot about MSD! That's a pretty useful program to examine those ranges, although whatever I was using (which I can't remember), was more detailed and helped me find more ranges than MSD.

Reply 113 of 298, by Jorpho

User metadata
Rank l33t++
Rank
l33t++

Microsoft explicitly recommends the use of E000-EFFF and B000-B7FF (provided you're not using an IBM PS/2 and a monochrome monitor) at http://support.microsoft.com/KB/77083 . Of course, there's probably some game out there whose developer just assumed that those ranges were safe since no one would bother configuring EMM386 to use them.

Reply 114 of 298, by Samir

User metadata
Rank Member
Rank
Member
Jorpho wrote:

Microsoft explicitly recommends the use of E000-EFFF and B000-B7FF (provided you're not using an IBM PS/2 and a monochrome monitor) at http://support.microsoft.com/KB/77083 . Of course, there's probably some game out there whose developer just assumed that those ranges were safe since no one would bother configuring EMM386 to use them.

I remember those recommendations! I remember one of them causing havoc when they were included where a bios was. 🤣

A lot of times, I was able to use parts of Cxxx and even part of the Bxxx range after the recommended block. You basically would tiptoe around any BIOS's that loaded in there and include the rest. I remember where on some systems, I had a ton of high memory, like 200k. 😎

Reply 115 of 298, by DonutKing

User metadata
Rank Oldbie
Rank
Oldbie

But even sometimes when these ranges appear free, programs will directly address them, bypassing any memory managers--then you have a mysterious crash.

Do you have an example of such a program? Ive not come across one. Win 3.11 can be finicky with memory ranges but it will just throw an error when you start it and you can set EMMExclude in system.ini to work around it.

If you are squeamish, don't prod the beach rubble.

Reply 116 of 298, by Samir

User metadata
Rank Member
Rank
Member
DonutKing wrote:

But even sometimes when these ranges appear free, programs will directly address them, bypassing any memory managers--then you have a mysterious crash.

Do you have an example of such a program? Ive not come across one. Win 3.11 can be finicky with memory ranges but it will just throw an error when you start it and you can set EMMExclude in system.ini to work around it.

I don't know of one off the top of my head, but I remember running across this with applications when I was building my autoexec.bat and config.sys back in the day.

It would go like this--everything works fine, awesome, try out all the programs, oops xxxx is crashing, hmm...try previous set of includes that doesn't include xxxx range, everything works fine, oh well.

I never really ran into an issue with Win 3.1 (not sure if 3.11 would have done things too much differently like WFW did). The only time I did in Win 3.1 was when I saw some empty (FF) ranges inside two blocks of a BIOS and included it. Under certain conditions, Win 3.1 would have a problem with that.

Reply 117 of 298, by gnuuser

User metadata
Rank Newbie
Rank
Newbie

im sure its on here somewhere but if I remember correctly there is a specific order in which the commands in the autoexec .bat and config.sys should be that makes a lot of difference in how fast the system will boot up and run.
Ill look through my old files and see if i can find it.

Reply 118 of 298, by schlang

User metadata
Rank Oldbie
Rank
Oldbie

I keep getting new email notifications to this thread, but there isn't any new post?

PC#1: K6-III+ 400 | 512MB | Geforce4 | Voodoo1 | SB Live | AWE64 | GUS PNP Pro
PC#2: 486DX2-66 | 64MB | Riva128 | AWE64 | GUS PNP | PAS16
PC#3: 386DX-40 | 32MB | CL-GD5434 | SB Pro | GUS MAX | PAS16

Think you know your games music? Show us: viewtopic.php?f=5&t=37532