This might be useful.

Masking to 16 bits violates the standard and can confuse DOS programs.

Again which one uses that? The few known instances query the available memory beforehand.

Based on the screenshots I provided, Windows 3.1 obviously uses it. Or else it would max out at reporting 64MB.

I'm sure newer versions of DOS4GW or DOS32a use it too, since they mention at one point being limited to 64MB, then working around that limit.

And yes they query beforehand, but I still think it would be better to handle all of EDX not mask it off.

orynider where have you got this from??
[gus]
gus=ace

Based on the screenshots I provided, Windows 3.1 obviously uses it. Or else it would max out at reporting 64MB.

Uhm that's NO PROBLEM then with the 63mb max.

but I still think it would be better to handle all of EDX not mask it off.

Why should I change well-tested and working code just because it may look better?

btw why isn't more memory working with your patch in booted dos/win9x?

Uhm that's NO PROBLEM then with the 63mb max.

I just said earlier in this thread I modded DOSBox to run with up to 256MB of RAM and that I ran Windows 3.1 with memsize=256. Windows 3.1 is obviously using the extended API functions because it reports what my mod passes back and sees 256MB. Otherwise, it would be calling the 16-bit version of the API where my mod has to cap the total memory value at 64MB, and show 64MB of RAM.

To further prove my point I then brought up as many programs as I could to suck up the 256MB and force Windows to allocate and use memory. I also toyed with the "Heapwalk" program that comes with Microsoft Visual C++ to eat up the rest of RAM. Despite that, I had no crashes, no errors, no problems whatsoever. I'll upload an AVI of me carrying out this test if you don't believe me.

Why should I change well-tested and working code just because it may look better?

Looks better?!? My point all this time has been that the extended API functions 0x80-0x8F uses all 32 bits of the EDX register, therefore masking off the upper 16 bits for them is inaccurate and prone to errors, not to mention the very reason you needed a 64MB max in DOSBox in the first place. You said you don't want DOSBox to have more than 64MB of RAM. Fine. So I said that at least you should compare EDX against 65535 and return an error so that an errant DOS program trying to allocate 64MB gets the correct response instead of the false impression that 64MB was allocated (because ANDing EDX with 0xFFFF causes requests larger than 65536KB to wrap back around to small values). I also said DOSBox's memory limit should be a compile-time option because apparently the few problems involved are fixed and enabling >= 64MB of RAM seems to be extremely trivial (it's a #define in src/hardware/memory.cpp FFS).

robertmo wrote:

btw why isn't more memory working with your patch in booted dos/win9x?

Probably because booted dos/win9x uses the BIOS to determine total memory, and my patch so far only covers non-booted DOS programs using HIMEM.SYS.

I suppose the next step is to make sure INT 15H AX=88H/AX=0xE801H/etc is capping the return value at 64MB, and then add INT 15H Ax=0xE820H emulation to cover it.

http://wiki.osdev.org/Detecting_Memory_%28x86 … C_AX_.3D_0xE881

I just said earlier in this thread I modded DOSBox to run with up to 256MB of RAM and that I ran Windows 3.1 with memsize=256.

I've stated several times that I will NOT raise the memory limit.

To further prove my point

You don't have to prove your point. If you want to raise the memory limit you have to
implement the enhanced functions, but this is of no relevance to me.

So I said that at least you should compare EDX against 65535 and return an error

No because everything works fine as-is.

that an errant DOS program trying to allocate 64MB gets the correct response

Which game are you talking about?

I also said DOSBox's memory limit should be a compile-time option

Don't see any need.

Fine, fine.

For those who do want >= 64MB I'll be working on my branch of it and posting tarballs for testing.

😀

robertmo wrote:

btw why isn't more memory working with your patch in booted dos/win9x?

It is now. I fixed INT 15H AH=88H to cap at 64MB (16-bit return value limits), and added INT 15H AX=E820 and INT 15H AX=E801 emulation. That should cover the popular ways that DOS/Windows detects memory through the BIOS.

http://jon.nerdgrounds.com/dosbox-x-hackipedi … 821-1438.tar.gz

More on INT 15H AX=E820: http://wiki.osdev.org/Detecting_Memory_%28x86 … _EAX_.3D_0xE820

Latest version:

http://jon.nerdgrounds.com/dosbox-x-hackipedi … 822-0032.tar.gz

1New DOSBox fixes:
2   - Corrected typo in INT 15H AX=E820 emulation that caused random type values to appear in the third memory region
3   - Sound Blaster fixes: Some early DOS (1992) demos use the GoldPlay library which uses SoundBlaster DMA playback in a strange way
4                          not properly emulated by the existing SoundBlaster emulation. Full explanation in hardware/sblast.cpp.
5                          The fix changes the code so that if the Sound Blaster is being used in this manner it switches to a
6                          per-sample interval timer that accurately reproduces the intended sound. Without the fix, the sound comes
7                          out as garbled low-frequency unrecognizeable "noise".
8 
9                             This fixes audio in:
10                                  - Crystal Dreams (although there is still the issue with audio stopping because the demo has problems programming
11                                    the interrupt controller properly)
12                                  - Twilight Zone, Buttman (affects the music playback. sound effects up to that point use Direct DAC output)
13                                  - The Jungly (although you should use the demo's Gravis Ultrasound support instead)
14
15   - VGA Chained 256-color mode fix: Rendering output should cover all 256KB of traditional VGA RAM, not just the first 64KB.
16                                     Some demos rely on programming the Graphics Controller to map the first 128KB into range 0xA0000-0xBFFFF
17                                     without Mode X and they expect to scroll those contents on-screen. This fixes screen corruption in
18                                     Abaddon's "Cycling" demo.

BTW nothing wrong with your patch, the game doesn't work on real computer with more than 64mb too (with dos4gw and with dos32a) (unless it is limited of couse):
Battlecruiser 3000AD 2.09 Freeware
Exit to error: Illegal descriptor type 0 for int 31

I found a freeware copy of that game. Same crash here. Setting memsize=31 gives me a game that plays half it's intro video, glitches out, then starts the main game and demands the CD.

It's sad they have a Windows installer for a DOS game, much less a picky MSI-type installer that demands Windows 9x. I had to run winecfg, set emulation to "Windows 98" and then run the installer in WINE to get the DOS files. Then copy them to a folder accessible to DOSBox.

In other news, I got Windows 95 to install in DOSBox. It runs perfectly fine, but it also seems to trigger crashes with SVGA emulation, so I've had to run it with machine=vgaonly to keep it stable.

I looked at the SVGA emulation crashes in GDB and it seems to happen because page fault emulation gets itself stuck into a recursive call until the stack overflows. This happens with both svga_s3 and svga_et4000. It probably has to do with poor handling of the fault routine combined with the VDD "hack" that Windows 95 does to fake a linear framebuffer from SVGA bank switching.

I think you need latest S3 Trio64 drivers.
also cputype=pentium_slow or use ykhwong dosbox build that has some paging patch, so it works with other cputypes.
There are guides on vogons about win9x.

I quickly checked win98 first edition with your patch and it works up to memsize=1094
I wonder why it doesn't work with more.
Why have you limited it to 256?

robertmo wrote:

Why have you limited it to 256?

I wanted to raise the limit but not in any drastic way that caused problems, only in a reasonable bump that I could test against. You probably noticed the argument between me and "wd" here in the forums about XMS emulation and masking edx with 0xFFFF just because the 64MB limit is in place. I figured a modest bump would be enough to shake out any other limits imposed by similar programming practices in DOSBox before raising the limit further.

The other reason is that the max memory limit is a #define constant in src/hardware/memory.cpp and it's used to define the length of some bookkeeping arrays. I wasn't sure at the time how badly it would affect the length of the arrays and by how much it would increase DOSBox's memory footprint just to do the bookkeeping. My patch raised it to 256. Feel free to raise it to 1024 or 2048 if you want, though I don't recommend going past 4095. DOSBox does not emulate a machine that can address >= 4GB of RAM nor does it emulate the PSE/PAE page table extensions needed to do that, the RAM would be unused and wasted. And DOS games don't use PSE/PAE extensions anway 😀

I have an updated tarball as well.

http://jon.nerdgrounds.com/dosbox-x-hackipedi … 822-0606.tar.gz

This primarily fixes problems introduced by the Sound Blaster GoldPlay hack I introduced in the last post.
- Running a program that uses the GoldPlay DMA hack, then running a DOS program that uses DMA normally, causes the SB emulation to stall. For Windows 95, it causes the boot process to hang if Sound Blaster 16 drivers are installed.
- There were several cases where the DMA hack would not feed the DOSBox mixer. Apparently this causes the mixer to go into an infinite loop and hang DOSBox.
- Several stability fixes as well to ensure that going back and forth between the two emulation modes went smoothly, at least with DOS programs that were properly written to initialize the Sound Blaster. Older demos like Unreal do NOT fully init the sound card, and just like real hardware, can fail to detect the Sound Blaster if the previous DOS program didn't fully clean up after itself. Newer demos like EMF Verses are always able to get the SB working.
- DMA sample interval code has been corrected to use the proper sample rate, not the "sample rate" computed for DMA transfer. This fixes Unreal where with the original hack the music would play 2 octaves too high and with a creepy slow-motion sound effect.
- The DMA transfer length limit to trigger the hack has been reduced. Unreal and Panic use a short transfer length (something like 128, 256, 512, etc.) that DOSBox is able to emulate correctly so there is no need for the hack to kick in.

about battlecruiser 3000ad http://www.fileplanet.com/62798/60000/fileinf … -3000AD-v.-2.09

a nice installation installation method is described here:
"Fortunately, all the needed files are actually in the 130+ meg version you've downloaded - just rename it to the extention .cab, and extract all the files in it (with winRar or similar), to the same directory you've places the downloaded BC file (for some reason, only msi-relevant files are available in the archieve). Then, rename the BC file back to the .exe extention, set compatibility mode to Windows 95/98 for *both* the BC exe and the newly created file named 'msiexec.exe'. This file will hopefully be used to perform the install, rather than the one in your system32 dir. Then run the BC setup, and it should work." quote from http://www.capsu.org/bc3k/9.html

for the missing cd you can either run the game with /d1 (debug mode) or
use this small fix
http://www.fileplanet.com/62988/60000/fileinf … -intro-anim-fix

then you will encounter this "problem":
Battlecruiser 3000 a.d. 1x

robertmo wrote:

about battlecruiser 3000ad http://www.fileplanet.com/62798/60000/fileinf … -3000AD-v.-2.09 […]
Show full quote

about battlecruiser 3000ad http://www.fileplanet.com/62798/60000/fileinf … -3000AD-v.-2.09

a nice installation installation method is described here:
"Fortunately, all the needed files are actually in the 130+ meg version you've downloaded - just rename it to the extention .cab, and extract all the files in it (with winRar or similar), to the same directory you've places the downloaded BC file (for some reason, only msi-relevant files are available in the archieve). Then, rename the BC file back to the .exe extention, set compatibility mode to Windows 95/98 for *both* the BC exe and the newly created file named 'msiexec.exe'. This file will hopefully be used to perform the install, rather than the one in your system32 dir. Then run the BC setup, and it should work." quote from http://www.capsu.org/bc3k/9.html

for the missing cd you can either run the game with /d1 (debug mode) or
use this small fix
http://www.fileplanet.com/62988/60000/fileinf … -intro-anim-fix

then you will encounter this "problem":
Battlecruiser 3000 a.d. 1x

We don't link downloads of commercially released games here.

Battlecruiser 3000 is freeware
http://www.3000ad.com/downloads/bc3k.shtml