The directory /wattcp/bin/ has wattcp.cfg. Placed this "watt" configuration file in the directory along with q2.exe and modified settings. There is even a setting: pkt.near_ptr = 1 ; optional (djgpp only). It also has settings for logging to a file.

I don't know how to say it without being an ass... but I really don't care about this whole nearptr bullshit trying to run in windows dos boxes. It's a mess and I already discussed this recently with Taniwha who used to be a fairly prolific DJGPP developer back in it's hey-day. He said the biggest issues I'm going to run into is that the conventional_base shifts around even between malloc and friends in Windows so you would have to wrap around all of it and years ago we tried this with QDOS and it was too much to do and we ended up leaving it be.

You're probably never going to get it to work properly in NTVDM or Win9x DOS BOX because of the real2ptr address constantly moving around. A large overhaul of the code and all it's libraries is probably necessary to convert everything to work properly. Another option might be Watcom, but again everything has to be converted over for this. I'm 100% not interested and I'm not interested in seeing snippets of code unless it's something that works and is ready to merge for such a project like this.

I know you're pretty hell-bent on trying to get this to work, but this entire project is intended for people with actual DOS computers with Sound Blasters and Gravis UltraSounds (GUS preferred 😉). Being able to play it properly in DOSBox, QEMU, (insert favourite VM/Emulator here) is just a nice side-effect. If you want to play the game with all it's extra enhacements (and I've personally spent wayyyy too much time on adding them all in and sezero has spent a massive amount of time auditing all of my changes to catch any potential creeper bugs) then compile it in Visual Studio 6. It can probably be upgraded to compile on modern Visual Studio considering the code compiles just fine in GCC 4.84 if this is an issue for you.

Not only will you get to experience it in Windows, properly, but on modern computers it actually runs faster in Windows than it does in DOS. On my older DOS computers it is the other way around.

...That being said. I can give you potential clues if you really must keep playing with it. That endtime change is a good catch and may be why s_mixahead actually works properly in Q2 (in Quake 1 it basically doesn't work at values past 0.4 and this can be a semi-hacky way to play 44100 on a slow computer at the expense of the sounds obviously being delayed by half a second). The crash is happening at the memset after the real2ptr for grabbing the DMA address. You can also try building a null video build and see if it still crashes at the memset. You're going to have to eliminate things one by one until you can actually get sound working in a Windows dos box. This is how I would do it. A good utility in Windows for comparing Q1 to Q2 files is BeyondCompare. There's a freeware alternative out there but I forget it's name.

Other side notes is that I have already tried compiling with DJ 2.03 with GCC 2.95 with OGG removed and all those friends (except WATT32) and still had the problem.

Inlining the vector math functions is probably worth it, but I haven't gotten around to it yet.

If you ever make it work, then I'll be glad to see the entire code project (no DIFFs, please). But please, no more discussion of it. To me it is senseless and everyone working on the project feels the same way.

Thank you for the helpful information. I will read it more carefully today, but I have news. Q2Dos is working in a 95 dos box. Here is the necessary code change:

1--- snd_sb-ORIG.c	2015-07-22 21:21:22 +0000
2+++ snd_sb.c	2015-07-23 00:32:32 +0000
3@@ -452,13 +452,13 @@ qboolean BLASTER_Init(void)
4 	dma_buffer = (short *) real2ptr(realaddr);
5 	dma_size = size;
6 
7-	memset(dma_buffer, 0, dma_size);
8+	//memset(dma_buffer, 0, dma_size);
9 
10 	dma.samples = size/(dma.samplebits/8);
11 	dma.samplepos = 0;
12 	dma.submission_chunk = 1;
13 	dma.buffer = (unsigned char *) dma_buffer;
14-	dma.samples = size/(dma.samplebits/8);
15+	// dma.samples = size/(dma.samplebits/8);
16 
17 	StartDMA();
18 	StartSB();

I also temporarily attached a q2.exe binary until the result is verified.

There was a wattcp.cfg file in the q2dos directory and this parameter was set:
pkt.near_ptr = 1 ; optional (djgpp only)
However, I don't think that was necessary to find the above result.

Edit: removed attached binary for testing, "Q2Dos binary for 95 dos box".

I never noticed dma.samples is being set twice. I have to test with the memset. GUS still crashes but I haven't seen if that's also in there twice, though I'm unsure why that would cause an issue. But thanks for this.

It's my pleasure, especially give your team's efforts in bringing us the port.

Did you change the values of SND_BUFFER_SIZE and friends? Because if I compile the same code it crashes during memset of S_Soundinfo

The only change should be disabling extra functions in makefile (but for cd audio). I will run a difference file between the entire source from your branch and the modified one, although I don't recall other changes.

Edit: just realized I changed settings in the ms dos box in 95 (such as fast paste off).

The full set of changes...

1diff -rupN q2-ORIG//dos/snd_sb.c q2//dos/snd_sb.c
2--- q2-ORIG//dos/snd_sb.c	2015-07-22 21:21:21 -0400
3+++ q2//dos/snd_sb.c	2015-07-23 00:32:31 -0400
4@@ -452,13 +452,13 @@ qboolean BLASTER_Init(void)
5 	dma_buffer = (short *) real2ptr(realaddr);
6 	dma_size = size;
7 
8-	memset(dma_buffer, 0, dma_size);
9+	//memset(dma_buffer, 0, dma_size);
10 
11 	dma.samples = size/(dma.samplebits/8);
12 	dma.samplepos = 0;
13 	dma.submission_chunk = 1;
14 	dma.buffer = (unsigned char *) dma_buffer;
15-	dma.samples = size/(dma.samplebits/8);
16+	// dma.samples = size/(dma.samplebits/8);
17 
18 	StartDMA();
19 	StartSB();
20diff -rupN q2-ORIG//dos/sys_dos.c q2//dos/sys_dos.c
21--- q2-ORIG//dos/sys_dos.c	2015-07-22 21:21:21 -0400
22+++ q2//dos/sys_dos.c	2015-07-22 23:56:47 -0400
23@@ -20,7 +20,7 @@
24 #include <sys/nearptr.h>
25 #include <conio.h>
26 
27-int _crt0_startup_flags = _CRT0_FLAG_UNIX_SBRK; // FS: Fake Mem Fix (QIP)
28+// int _crt0_startup_flags = _CRT0_FLAG_UNIX_SBRK; // FS: Fake Mem Fix (QIP)
29 
30 #include "dosisms.h"
31 #include "../qcommon/qcommon.h"
32diff -rupN q2-ORIG//makedxe3.frank q2//makedxe3.frank
33--- q2-ORIG//makedxe3.frank	2015-07-22 21:21:21 -0400
34+++ q2//makedxe3.frank	2015-07-22 23:21:22 -0400
35@@ -1,24 +1,24 @@
36 # features selection :
37 #
38 # gamespy/server browser:
39-USE_GAMESPY=1
40+USE_GAMESPY=0
41 # dynamically linked gamespy:
42-GAMESPY_DXE=1
43+GAMESPY_DXE=0
44 # libcurl/http downloads:
45-USE_CURL=1
46+USE_CURL=0
47 # ogg/vorbis music:
48-USE_OGG=1
49+USE_OGG=0
50 # use tremor library for ogg/vorbis:
51-USE_TREMOR=1
52+USE_TREMOR=0
53 # pci sound card support:
54-USE_SNDPCI=1
55+USE_SNDPCI=0
56 # cd audio support:
57 USE_CDAUDIO=1
58 # abrash's asm optimizations:
59 USE_ASM=1
60 

61 CC = gcc
62-CFLAGS = -g -Wall -O2 -fno-strict-aliasing -fomit-frame-pointer
63+CFLAGS = -g -O2 -fno-strict-aliasing -fomit-frame-pointer
64 CPPFLAGS = -DREF_HARD_LINKED -DCLIENT_SPLIT_NETFRAME
65 LDFLAGS =

Also, ran strip.exe on q2 binary.

The most interesting is the removal of the CRT0 flag.

DJGPP says this about it:

_CRT0_FLAG_UNIX_SBRK

If set, the sbrk algorithm resizes memory blocks so that the layout of memory is set up to be the most compatible with Unix sbrk expectations. This mode should not be used with hardware interrupts, near pointers, and may cause problems with QDPMI virtual memory.

A long time ago QIP posted this as a fix for incorrect memory sizes being reported to Q1 (which was an issue because of it's weird zone/scache manager). I wonder if that's all the problem was all along.

I spent a lot of time reading about these parameter settings, but there is too much conflicting information. Instead, I experimented with them since the examples are lacking.

The most interesting aspect is all that flag is necessary to get the crashing to stop. However, LFB modes still crash, but banked is OK. I have to test if LFB is OK in real DOS.

I didn't mention earlier, but opencp doesn't work (so far for me) in XP ntvdm. I went over a dozen code samples using auto-init dma and some of the corresponding binaries show the same issue as q2dos, even though the code is short. I think ntvdm dpmi is not made for sound compatibility. 😀

I'll let the experts decide the rest. I wanted to tinker just a bit further because I had some ideas to test.

Also recompiling with this flag instead works just as well and sounds more appropriate to use:

_CRT0_FLAG_NONMOVE_SBRK

If set, the sbrk algorithm uses multiple DPMI memory blocks which makes sure the base of CS/DS/SS does not change. This may cause problems with sbrk(0) values and programs with other assumptions about sbrk behavior. This flag is useful with near pointers, since a constant pointer to DOS/Video memory can be computed without needing to reload it after any routine which might call sbrk.

That's good insight, I did test that command but not in this context. I look forward to testing your results.

Well the CS/DS/SS is shifting around in Windows which is the cause of the crashes from real2ptr with nearptr so that flag sounds like you would still get SBRK (which apparently was needed for the fake memory issue but maybe DJGPP has since resolved this in 2.04+) but not have to chase every nearptr everywhere and wrap it around to verify its value, which was the exact problem we had in QDOS a long time ago and I always wondered how ID was even able to get it all to work since the code was basically all the same.

Also, works perfect in real DOS. I noticed in Windows... memstats shows only using virtual memory (which I guess windows takes over and does what it needs) but in DOS memory usage is still working properly. The one machine has 1GB RAM and reports the proper amount (previously original Q1 would show negative values before using SBRK!). It looks like that oneliner you found was the biggest issues of all!

Maraakate wrote:

Also, works perfect in real DOS. I noticed in Windows... memstats shows only using virtual memory (which I guess windows takes over and does what it needs) but in DOS memory usage is still working properly. The one machine has 1GB RAM and reports the proper amount (previously original Q1 would show negative values before using SBRK!). It looks like that oneliner you found was the biggest issues of all!

Un-freaking real. What a nightmare this has been.

Good job for everyone finding this, it's going to make those additional Quake2 MS-DOS users happy!!!! 😎

Without a doubt the MS-DOS version will be the best Q2, ever!

That one liner also fixed QDOS to work now as well. LFB (or at least I assume it is LFB writes because the one resolution only is reported by VBE) works there so there's a way we are using the writes to LFB address being wrong in windows, but it's stil lquite amazing to see it working now.

Anyways, thanks a lot. That incidental one liner is amazing, haha.