Hmm, could this have anything to do with WinXP SP1, or DirectX9? My laptop (which I do about half my testing on,,,has neither of these installed - wheras my main PC has both of these installed.
So far nothing has run right on my main PC...but I always assumed it was the SBLive! card in it not liking stuff. Now that I think about it though, the 3rd party noname soundcard in my laptop isn't really any MORE likely to run stuff now is it? Hmm, I've heard other people complaining about DX9, so you should check into that. I'm not planning on upgrading my laptop, so for now I shouldn't have to worry. Just a thought since. Regardless though, my laptop won't run MOM right unless I use VDMsound w/o all sound options off. Dosbox just don't cut it.

I've got SP1 and DX 9 on both of the computers here, as well as on three other computers at my brothers' houses. VDMSound runs fine on all five units.

Nicht Sehr Gut wrote:

Actually, if you create a file named GO.BAT and edit it to contain the single command MEM, the run it with VDMSound (right-click […]
Show full quote

Actually, if you create a file named GO.BAT and edit it to contain the single command MEM, the run it with VDMSound (right-click and choose Run with VDMS), it should report something like the following:

Loading 'VDDLoader.dll'...
Successfully loaded & initialized (hVDD = 0x01).

655360 bytes total conventional memory
655360 bytes available to MS-DOS
625120 largest executable program size

4194304 bytes total EMS memory
4194304 bytes free EMS memory

8388608 bytes total contiguous extended memory
0 bytes available contiguous extended memory
4045824 bytes available XMS memory
MS-DOS resident in High Memory Area

It's not VDMSound eating up the memory, trust me.

Hi,
I'm using WinXP and in MOM after the intro, I keep getting the error message " Insufficient Memory .... you need at least 583k free "
I did what you said above "create a file named GO.BAT and edit it to contain the single command MEM, the run it with VDMSound", and here's what I got:
----------------------------------------------------------
Loading 'VDDLoader.dll'...
Successfully loaded & initialized (hVDD = 0x01).
655360 bytes total conventional memory
655360 bytes available to MS-DOS
591264 largest executable program size

4194304 bytes total EMS memory
4194304 bytes free EMS memory

8388608 bytes total contiguous extended memory
0 bytes available contiguous extended memory
4045824 bytes available XMS memory
MS-DOS resident in High Memory Area
-----------------------------------------------------------
591264 is less than the 583k needed.

If I just do a mem in the dos window, I get:
-------------------------------------------------------------
655360 bytes total conventional memory
655360 bytes available to MS-DOS
633264 largest executable program size

1048576 bytes total contiguous extended memory
0 bytes available contiguous extended memory
941056 bytes available XMS memory
MS-DOS resident in High Memory Area
-----------------------------------------------------------------
So I think I'm having a problem with VDMSound using too much conventional memory. What's happening here?

VDMSound doesn't use conventional memory. Do a search for autoexec.nt... You should find a post or two I've made in the past with custom autoexec.nt and config.nt's that free up a lot of memory.

psz wrote:

VDMSound doesn't use conventional memory. Do a search for autoexec.nt... You should find a post or two I've made in the past with custom autoexec.nt and config.nt's that free up a lot of memory.

Like I said, I have more than enough conventional memory when I do the "mem" command in the DOS prompt. I don't understand why I get a lot less conventional memory when I "create a file named GO.BAT and edit it to contain the single command MEM, the run it with VDMSound".
The only difference is one is using VDMSound, one is not.

I can get MoM to work with full audio support using the Soundblaster/MPU-401 emulator that comes with Windows XP. I am not going to recommend it for all titles, but for later age DOS games it seams perfectly adequate.

InOcean: My point is, if you use those .nt's for the shortcut, you should be able to just right-click Run With VDMSound the shortcut (or add the command line for VDMSound to the shortcut itself). No go.bat needed.

Originally posted by InOcean 655360 bytes available to MS-DOS
591264 largest executable program size
Like I said, I have more than enough conventional memory when I do the "mem" command in the DOS prompt. I don't understand why I get a lot less conventional memory when I "create a file named GO.BAT and edit it to contain the single command MEM, the run it with VDMSound".

Well, that certainly makes a whole lot of no sense. Try changing the MEM command to MEM /C and run it again. Look to see if what's using up your conventional memory and make sure that you still have some upper memory available.

This sounds suspiciously like the "NO EMS" problem some of the newer motherboards have (yes, I know it's reporting EMS memory...but it sounds like something may be getting "shifted" from upper to conventional memory).

BTW, you may find it easier to use the GUI launchpad as a replacement for commands placed in "AUTOEXEC.NT / CONFIG.NT". On your VDMSound shortcut (the one created by using the Launchpad with an executable or batch file), right-click, choose 'Properties", click "Advanced" and you should find "empty boxes" in which you can place commands that would normally go into those two files.

This FAQ discusses other options:
http://faqs.ign.com/articles/372/372466p1.html

Changing subjects a little bit here, all EMS really means is that the addressing information for upper memory is placed in RAM. Programs that use EMS read it from there instead of reading it from the hardware on the CPU/chipset/whatever. When EMS was first invented, there was no addressing information available. Within a year of the invention of EMS, Intel put out a new CPU/chipset/whatever that had the addressing information. Most programmers, being lazy, stuck with EMS instead of learning how to program properly. Unfortunately things went on this way until the introduction of CD-ROMs. The reason being is that they hog so much conventional memory (especially if like 99% of people you don't know how to configure autoexec.bat and config.sys properly) that they had to start using XMS and skip out on EMS altogether.

Something similiar happened with the whole vxd/wdm thing. Windows 98 can use either and Microsoft's intention was for people to learn to write wdm drivers for Windows 98 to give them plenty of time to transition to Windows XP.

Nicht Sehr Gut wrote:

Well, that certainly makes a whole lot of no sense. Try changing the MEM command to MEM /C and run it again. Look to see if what's using up your conventional memory and make sure that you still have some upper memory available.

Thanks for all your help. Ok I did the mem /c in the go.bat file and ran it with VDMSound, and here's what I got:
*****************************************
Conventional Memory :
Name Size in Decimal Size in Hex
------------- --------------------- -------------
MSDOS 12464 ( 12.2K) 30B0
KBD 3296 ( 3.2K) CE0
EMM 176 ( 0.2K) B0
HIMEM 1248 ( 1.2K) 4E0
COMMAND 4016 ( 3.9K) FB0
DOSX 34720 ( 33.9K) 87A0
KB16 6096 ( 6.0K) 17D0
FREE 112 ( 0.1K) 70
FREE 720 ( 0.7K) 2D0
FREE 592240 (578.4K) 90970

Total FREE : 593072 (579.2K)

Upper Memory :
Name Size in Decimal Size in Hex
------------- --------------------- -------------
SYSTEM 204784 (200.0K) 31FF0
MOUSE 12528 ( 12.2K) 30F0
FREE 4064 ( 4.0K) FE0
FREE 40672 ( 39.7K) 9EE0

Total FREE : 44736 ( 43.7K)

Total bytes available to programs (Conventional+Upper) : 637808 (622.9K)
Largest executable program size : 591264 (577.4K)
Largest available upper memory block : 40672 ( 39.7K)

4194304 bytes total EMS memory
4194304 bytes free EMS memory

8388608 bytes total contiguous extended memory
0 bytes available contiguous extended memory
4045824 bytes available XMS memory
MS-DOS resident in High Memory Area
*********************************************
I guess the problem is the dosx not being loaded in the Upper Memory (it does load into the Upper Memory when I do the mem /c in the dos prompt window).
Here's what I got with the mem /c in the dos prompt only:
*******************************************
Conventional Memory :
Name Size in Decimal Size in Hex
------------- --------------------- -------------
MSDOS 12464 ( 12.2K) 30B0
KBD 3296 ( 3.2K) CE0
HIMEM 1248 ( 1.2K) 4E0
COMMAND 3792 ( 3.7K) ED0
FREE 112 ( 0.1K) 70
FREE 634272 (619.4K) 9ADA0

Total FREE : 634384 (619.5K)

Upper Memory :
Name Size in Decimal Size in Hex
------------- --------------------- -------------
SYSTEM 204784 (200.0K) 31FF0
MSCDEXNT 464 ( 0.5K) 1D0
DOSX 34848 ( 34.0K) 8820
MOUSE 12528 ( 12.2K) 30F0
REDIR 2672 ( 2.6K) A70
FREE 976 ( 1.0K) 3D0
FREE 2448 ( 2.4K) 990
FREE 68784 ( 67.2K) 10CB0

Total FREE : 72208 ( 70.5K)

Total bytes available to programs (Conventional+Upper) : 706592 (690.0K)
Largest executable program size : 633264 (618.4K)
Largest available upper memory block : 68784 ( 67.2K)

1048576 bytes total contiguous extended memory
0 bytes available contiguous extended memory
941056 bytes available XMS memory
MS-DOS resident in High Memory Area
******************************************
Also, I don't understand why everyone is telling me to change my AUTOEXEC.NT and CONFIG.NT files. If that was the problem, shouldn't it affect the memory when I do the mem /c in the dos window? So why isn't DOSX loading in the Upper Memory when I use VDMSound only?

AUTOEXEC.NT loads DOSX in high-memory, whereas the VDMSound's AUTOEXEC does not.

You can enter this into the "custom autoexec.nt" box in the Launchpad:

lh %SystemRoot%\system32\dosx.exe

and see if that doesn't fix the problem.
Make sure to DESELECT the DOSX option elsewhere in the Launchpad.

Snover wrote:

AUTOEXEC.NT loads DOSX in high-memory, whereas the VDMSound's AUTOEXEC does not. […]
Show full quote

AUTOEXEC.NT loads DOSX in high-memory, whereas the VDMSound's AUTOEXEC does not.

You can enter this into the "custom autoexec.nt" box in the Launchpad:

lh %SystemRoot%\system32\dosx.exe

and see if that doesn't fix the problem.
Make sure to DESELECT the DOSX option elsewhere in the Launchpad.

Thanks again but I did what you said, and DOSX still loads in conventional memory. However, while playing with the Lauchpad settings, I figured out what's causing DOSX to load in conventional memory. It happens only if I enable Expanded Memory. If I don't enable Expanded memory, it always loads in Upper Memory, and that's why I was seeing all that conventional memory if I do a mem /c in a dos prompt window. But if I enable Expanded Memory, DOSX always loads in conventional memory. Hmm but I need Expanded Memory... I'm not too familiar how Expanded memory works... any more suggestions?

Originally posted by Snover ...whereas the VDMSound's AUTOEXEC does not.

It doesn't? Here's my results with low-level CD-ROM access and EMS enabled:

Conventional Memory :

Name Size in Decimal Size in Hex
------------- --------------------- -------------
MSDOS 13184 ( 12.9K) 3380
KBD 3296 ( 3.2K) CE0
EMM 176 ( 0.2K) B0
HIMEM 1248 ( 1.2K) 4E0
COMMAND 3136 ( 3.1K) C40
FREE 112 ( 0.1K) 70
FREE 634000 (619.1K) 9AC90

Total FREE : 634112 (619.3K)

Upper Memory :

Name Size in Decimal Size in Hex
------------- --------------------- -------------
SYSTEM 180208 (176.0K) 2BFF0
MOUSE 12528 ( 12.2K) 30F0
MSCDEXNT 464 ( 0.5K) 1D0
DOSX 34720 ( 33.9K) 87A0
FREE 256 ( 0.3K) 100
FREE 33856 ( 33.1K) 8440

Total FREE : 34112 ( 33.3K)

Total bytes available to programs (Conventional+Upper) : 668224 (652.6K)
Largest executable program size : 633728 (618.9K)
Largest available upper memory block : 33856 ( 33.1K)

Originally posted by InOcean It happens only if I enable Expanded Memory. If I don't enable Expanded memory, it always loads in Upper Memory, and that's why I was seeing all that conventional memory if I do a mem /c in a dos prompt window. But if I enable Expanded Memory, DOSX always loads in conventional memory. Hmm but I need Expanded Memory... I'm not too familiar how Expanded memory works...

I know that EMS likes a nice contiguous block of (upper) memory to work properly. It could be that your upper memory is in broken segments or just a little too "tight" to squeeze in an EMS memory block (which would cause it to load low).

Read this post and try the attached bootdisk maker:
showthread.php?threadid=1233#post12151

Remember to keep the floppy in the drive (ignore messages to remove it). If it can create EMS for you, then you probably have an OS or program problem, if not, your hardware probably can't make EMS.

Does the WinNT version of EMM386 allow forced memory locations? If so this should be a pretty easy fix -- just force it to load into the memory addresses where monochrome video instructions would have been.

Snover wrote:

Does the WinNT version of EMM386 allow forced memory locations? If so this should be a pretty easy fix -- just force it to load into the memory addresses where monochrome video instructions would have been.

I don't think so. I could be wrong.

Juason wrote:

oohhh...perhaps that is it...let me check it out and get back with ya!