highscan checks which parts of memory map to allocate - it might just find another kb free here or there;
if you can resign of the 8192 argument, also try auto instead of ram or just highscan alone;
sorry but ima too lazy to pull out my 386 for this one 😁
there was a program that did both himem and emm386 in one program and was more compact thanx to this - maybe that is an option for you too - i just cant recall, sorry about that; its from freedos i believe or some gnu project
Having trouble running 3dMark99Max, so I'll probably have to re-download it and re-install it. According to Quake1, dropping to the Voodoo1 from a Voodoo2 resulted in a 26%-30% loss in framerate. Considering the Voodoo2 is 44% faster (50MHz vs 90MHz), it looks like the system is able to use "more" of the Voodoo1 than it can the Voodoo2.
I'm just really glad that 3dfx Tomb Raider 1 works, and it's beautiful.
Ok, so I just now figured it out... at least a working solution for EMM386.exe.
I found a website that suggested using a german program called UMBINFO and I was able to find two different sections of Upper Memory, the 360K of unused 1MB memory in DOS as a hold-over from the 8088 days. As it turns out, my memory map WITHOUT emm386.exe looks something like this:
0000-9FFF [Primary DOS MEMORY, ~640KB]
A000-AFFF [SYSTEM BIOS SHADOW]
B000-B7FF (monochrome video memory - useable)
B800-C7FF [DO NOT USE]
C800-CFFF [EMS FRAME]
D000-EFFF (unused memory space)
F000-FFFF [VIDEO BIOS SHADOW]
Now, UMBINFO shows that the Video BIOS is only from F800-FFFF, but every time I attempt to increase my useable space up to F7FF, EMM386 locks up the computer during boot. When I change the ending value to EFFF, it works perfectly fine. I may play around with this value later.
As it stands now, my CONFIG.SYS file reads like this:
And with DOSSTART.BAT reading as usual to load the Mouse and CDROM drivers, here's what I end up with.
1C:\>mem /c 2 3Modules using memory below 1 MB: 4 5 Name Total Conventional Upper Memory 6 -------- ---------------- ---------------- ---------------- 7 SYSTEM 33,888 (33K) 9,552 (9K) 24,336 (24K) 8 HIMEM 1,168 (1K) 1,168 (1K) 0 (0K) 9 EMM386 4,320 (4K) 4,320 (4K) 0 (0K) 10 COMMAND 7,168 (7K) 0 (0K) 7,168 (1K) 11 MOUSE 3,320 (3K) 0 (0K) 3,328 (3K) 12 OAKCDROM 36,064 (35K) 0 (0K) 36,064 (35K) 13 IFSHLP 2,864 (3K) 0 (0K) 2,864 (3K) 14 SETVER 832 (1K) 0 (0K) 832 (1K) 15 MSCDEX 28,832 (27K) 0 (0K) 28,032 (27K) 16 Free 647,584 (632K) 624,704 (610K) 22,880 (22K) 17 18Memory Summary: 19 20 Type of Memory Total Used Free 21 ---------------- ----------- ----------- ----------- 22 Conventional 640,000 15,296 624,704 23 Upper 125,504 102,624 22,880 24 Reserved 0 0 0 25 Extended (XMS)* 65,934,784 579,008 65,355,776 26 ---------------- ----------- ----------- ----------- 27 Total memory 66,700,288 696,928 66,003,360 28 29 Total under 1 MB 765,504 117,920 647,584 30 31 Total Expanded (EMS)* 3,522,560 (3,440K) 32 Free Expanded (EMS)* 3,145,728 (3,072K) 33 34 * EMM386 is using XMS memory to simulate EMS memory as needed. 35 Free EMS memory may change as free XMS memory changes. 36 37 Largest executable program size 624,688 (610K) 38 Largest free upper memory block 16,368 (16K) 39 MS-DOS is resident in the high memory area. 40 41C:\>_
So I increased the useable upper memory block space I can use, freeing up to 610K of Conventional Memory, setting up 3MB of EMS out of my full 64MB of XMS for Master of Magic, and whatever else may want to run.
So that solves that problem. Now, if I could only figure out why Windows refuses to shut down after I install the NIC driver and set up Windows for TCP/IP. Windows works perfectly fine while it's up, but every time I go to shut it down the system locks on a black screen (quit to DOS mode) or locks up on "Please wait while Windows shuts down." Got me scratching my head. But it's almost 11PM now and I'm done for the day.
EDIT: Ok, well shit. Windows just made a liar out of me. I performed a regular shut-down just now and it took about 25 seconds at the "Please wait will Windows shuts down." but then it finished shutting down and the system powered off on its own like it's supposed to. So maybe I only have half a problem on my hands. We'll see.
Thank you, that's what I was going for. I'm still tempted to tweak that final hex value to see where it works and where it stops working. It just takes time waiting for restarts, mainly because it takes 10-15 seconds to wait for the drive overlay software.
1C:\>mem /c 2 3Modules using memory below 1 MB: 4 5 Name Total Conventional Upper Memory 6 -------- ---------------- ---------------- ---------------- 7 SYSTEM 33,888 (33K) 9,552 (9K) 24,336 (24K) 8 HIMEM 1,168 (1K) 1,168 (1K) 0 (0K) 9 EMM386 4,320 (4K) 4,320 (4K) 0 (0K) 10 COMMAND 7,168 (7K) 0 (0K) 7,168 (1K) 11 MOUSE 3,320 (3K) 0 (0K) 3,328 (3K) 12 OAKCDROM 36,064 (35K) 0 (0K) 36,064 (35K) 13 IFSHLP 2,864 (3K) 0 (0K) 2,864 (3K) 14 SETVER 832 (1K) 0 (0K) 832 (1K) 15 MSCDEX 28,832 (27K) 0 (0K) 28,032 (27K) 16 Free 672,144 (656K) 624,704 (610K) 47,456 (46K) 17 18Memory Summary: 19 20 Type of Memory Total Used Free 21 ---------------- ----------- ----------- ----------- 22 Conventional 640,000 15,312 624,688 23 Upper 150,080 102,624 47,456 24 Reserved 0 0 0 25 Extended (XMS)* 65,910,208 570,816 65,339,392 26 ---------------- ----------- ----------- ----------- 27 Total memory 66,700,288 688,752 66,011,536 28 29 Total under 1 MB 790,080 117,936 672,144 30 31 Total Expanded (EMS)* 3,522,560 (3,440K) 32 Free Expanded (EMS)* 3,145,728 (3,072K) 33 34 * EMM386 is using XMS memory to simulate EMS memory as needed. 35 Free EMS memory may change as free XMS memory changes. 36 37 Largest executable program size 624,672 (610K) 38 Largest free upper memory block 30,784 (16K) 39 MS-DOS is resident in the high memory area. 40 41C:\>_
Did some testing and setting the final value at F600 locks the system up, but a value of F5FF allows the whole thing to boot fully into DOS and Windows. This increases, yet again, my free upper memory to a WHOPPING 146KB! I may want to tweak my Windows 98 computers like this. This is almost fun.
EDIT: Crap-baskets. I spoke too soon. Windows refused to boot. EMM386 kept finding issues at memory location F2?? or some other value. Changing it again to F1FF and Windows actually booted in fine. Scared me for a minute there... That limits me to only 130KB of upper memory, but that's pretty good.
You should save a lot of memory (more than 20-25kb) by using this driver rather than the oak cd-rom driver.
Edit: Reading a bit more on what you are doing, you can't use memory from F0000-FFFFF with emm386, that is where the BIOS lives and DOS/Windows won't work at all without it. There is also Video BIOS from C0000, usually 32-64kb, which you also can't use with emm386. A0000-AFFFF and B8000-BFFFF are Video RAM locations for VGA. You can probably get away with using the 32kb block at B0000-B7FFF as that is normally where the Monochrome graphics memory is, and generally unused on VGA systems.
Typically, the prime real estate for EMM386 is from C8000 or so, to EFFFF, before the start of the ROM BIOS.
Well, hate to burst your bubble, but I specifically mentioned that I was using a program that told me explicitly what memory was being used and for what. It's a German program called UMBINFO. And no, I cannot read German. Thank you Google Translate.
F800-FFFF : System BIOS
C800-F800 : unused space
C000-C7FF : ROM extension
B800-BFFF : Video RAM
B000-B7FF : unused space
A000-AFFF : Video RAM
9C00-9FFF : unused space
And this is reported running from "Command Prompt Safe Mode" which bypasses my Config and Autoexec files. Using this map, I am attempting to figure out how to best configure the system for maximum space usage for DOS, but also allow Windows to run. As it turns out, I can tell EMM386 to use all of the space up to F5FF without DOS having an issue, but then Windows has a problem running like that. When I change the value to F1FF, Windows no longer has an issue running, but it also leaves F200-F7FF as effectively unused space in DOS.
I've been wondering what that FRAME value is for. The page I was looking at during all this setup (and got UMBINFO from) mentioned it was needed for Expanded memory, but most other places don't bother with the value at all. If it is necessary, I was wondering if it would be better sticking it a lot earlier in the memory map in order to increase the contiguous size of the UMB section instead of having two larger sections. I was wondering if I could even stick it in B000-B7FF, freeing up the C800+ area.
Ok, I just checked UMBINFO and the EMS side frame once running is from c800-D7FF, is apparently 64KB. There's no way that will fit in B000-B7FF, so I'll just leave it as is.
Diagnostic software can easily be wrong. F0000-FFFFF is pretty much ALWAYS system rom, unless your computer is really strange.
To tell for sure, you can look at what is in the memory. Make sure all rom shadowing is disabled, then run the following command from a command prompt safe:
If the memory dump is full of FF memory cells, that means there is no ROM there and you can actually use EMM386.EXE and put UMBs or the EMS frame there. If you see anything else in that space, then you are seeing a portion of the system ROM there and letting EMM386.EXE overlap it is really a crash waiting to happen. I really strongly recommend you check the F000 segment yourself, it is really strange NOT to have system rom there.
Did you end up trying the other CD-ROM driver VIDE-CCD.SYS, you can save a lot of memory as long as it works for you. 35KB for OAKCDROM.SYS vs 5KB for VIDE-CCD.SYS
I have exactly the same motherboard and processor. Pentium 200 MMX and M55HIPLUS Rev B, firmware version 4.05.10b. I used a Seagate 120GB hard drive and had exactly the same problem. The BIOS detected the hard drive as 8455 MB size with C=16383, H=16, S=63. LBA Mode Control is Enabled (It also says that LBA is needed for hard drive sizes more than 528 MB). I could boot from DOS or Windows 95 boot floppy disk and do an FDISK. Then it asked me to reboot. After rebooting the system hang before I took out the hard drive and deleted the partitions. It hangs each time I do an FDISK and reboot operation.
The simplest solution is manually setting the hard drive parameters in BIOS. 4.05.10b only supports 4 GB hard drive size. So I just changed the hard drive type to USER with C=8191, H=16, S=63 (total 4227 MB) then everything worked perfectly.
There is a newer firmware version 4.06 for this board that claims to support 8GB hard drives. http://www.elhvb.com/mobokive/Archive/Microni … m/m55/files.htm I'll try it and see if I can set the hard drive size to 8 GB. During my trials with 4.05.10b firmware, I found I could actually set C=65535, H=16, S=63 and successfully create a 32 GB partition. The only issue was that after rebooting the system hung and I could not do anything about it. I could format it in another computer but I just could not use it on this motherboard unless I shrunk it to 4 GB.
My solution to using a 20.4 GB hard drive is to use a drive overlay software. They were frequently used back in the late 90s to bypass older MB size limits due to drastically increasing hard drive sizes and could be commonly found on systems that had those large drives. I found one created by the same hard drive manufacturer - in this case, Maxtor. It installs the overlay in the boot-sector of the hard drive and loads first. Once it's running, it points to a "new" boot sector that then loads DOS/Win95. It works, but it also makes the computer wait 10 seconds for the user to be able to choose to boot to a floppy (that way, even booting from a floppy OS will be able to see the entire hard drive). Maybe you could look into something like that.
OR.... you can put a first primary partition that's the right size for DOS and works with the BIOS, but then once Windows takes over, you should be able to have the rest of the hard drive in a 2nd partition. Just don't expect DOS to be able to see that 2nd partition or use it.