There was a previous patch to dosbox-x concerning gus.cpp (8/24/14). However, the patch doesn't agree with the "GUS panning register" on vanilla dosbox. Consider the following change:

1	void WritePanPot(Bit8u val) {
2 		PanPot = val;
3+		PanLeft = pantable[0x0f-(val & 0xf)];
4+		PanRight = pantable[(val & 0xf)];
5-		PanLeft = pantable[(val & 0xf)];
6-		PanRight = pantable[0x0f-(val & 0xf)];
7 		UpdateVolumes();

truth5678 wrote:

I noted this code in sdl_mapper.cpp from dosbox-x (it is from a joystick patch and it isn't in vanilla dosbox): […]
Show full quote

I noted this code in sdl_mapper.cpp from dosbox-x (it is from a joystick patch and it isn't in vanilla dosbox):

Copy code to clipboard

1for (i=0; i<MAX_VJOY_AXES; i++) {
2   virtual_joysticks[0].axis_pos[i]=0;
3   virtual_joysticks[0].axis_pos[i]=0;
4}

Should this code be changed to this? I'm not sure. 😀

Copy code to clipboard

1for (i=0; i<MAX_VJOY_AXES; i++) {
2   virtual_joysticks[0].axis_pos[i]=0;
3   virtual_joysticks[1].axis_pos[i]=0;
4}

That would make more sense, yes, than assigning zero twice to the same virtual joystick.

Thank you! Also, I posted a suggested changed above (I think we posted at the same time so it may be missed). 😀

truth5678 wrote:

There was a previous patch to dosbox-x concerning gus.cpp (8/24/14). However, the patch doesn't agree with the "GUS panning reg […]
Show full quote

There was a previous patch to dosbox-x concerning gus.cpp (8/24/14). However, the patch doesn't agree with the "GUS panning register" on vanilla dosbox. Consider the following change:

Copy code to clipboard

1	void WritePanPot(Bit8u val) {
2 		PanPot = val;
3+		PanLeft = pantable[0x0f-(val & 0xf)];
4+		PanRight = pantable[(val & 0xf)];
5-		PanLeft = pantable[(val & 0xf)];
6-		PanRight = pantable[0x0f-(val & 0xf)];
7 		UpdateVolumes();

vanilla DOSBox's GUS emulation had (still has?) a problem where mistakes in panning register emulation caused all GUS audio to play in the center, effectively forcing monaural audio.
What I have is based on the UltraSound Software Developer Kit PDF I have that says the Pan Position register uses bits 0-3 to specify pan position, where 0=full left and 15=full right.
The pantable if I understand correctly contains integers used to attenuate (turn DOWN the volume) of the channel NOT increase volume, 0 means no change and 0xFFFF would completely silence audio (it's some power of 2 the GUS emulation uses for it's fixed point math--I forget what exactly). So if the pan position value is 0, it needs to not change the left channel, and attenuate to silence the right channel.

Excellent, thank you for confirming and for fixing the gus emulation!

Noted that the function "CALLBACK_SetDescription" is defined twice in callback.cpp. For mingw, it compiles where the the 1st line below is moved to callback.h:

1void CALLBACK_SetDescription(Bitu nr, const char* descr);
2
3void CALLBACK_SetDescription(Bitu nr, const char* descr) {
4  if (CallBack_Description[nr]) delete[] CallBack_Description[nr];
5  CallBack_Description[nr] = 0;
6
7  if (descr != NULL) {
8    CallBack_Description[nr] = new char[strlen(descr)+1];
9    strcpy(CallBack_Description[nr],descr);
10  }
11}

Also, in sdlmain.cpp, "PROGRAMS_Shutdown" is defined twice:

1void PROGRAMS_Shutdown(void);
2void DOS_UninstallMisc(void);
3void CALLBACK_Shutdown(void);
4void PROGRAMS_Shutdown(void);

Also, verifying that the the 3 bool variables should be set 2x in sdlmain.cpp (I have to check the 2 functions whether they alter their values):

1bool run_machine = false;
2bool reboot_machine = false;
3bool dos_kernel_shutdown = false;
4/* start the shell */
5control->StartUp();
6SHELL_Init();
7/* main execution. run the DOSBox shell. various exceptions will be thrown. some,
8* which have type "int", have special actions. int(2) means to boot a guest OS
9* (thrown as an exception to force stack unwinding), while int(0) and int(1)
10* means someone pressed DOSBox's killswitch (CTRL+F9). */
11run_machine = false;
12reboot_machine = false;
13dos_kernel_shutdown = false;

truth5678 wrote:

Noted that the function "CALLBACK_SetDescription" is defined twice in callback.cpp. For mingw, it compiles where the the 1st li […]
Show full quote

Noted that the function "CALLBACK_SetDescription" is defined twice in callback.cpp. For mingw, it compiles where the the 1st line below is moved to callback.h:

Copy code to clipboard

1void CALLBACK_SetDescription(Bitu nr, const char* descr);
2
3void CALLBACK_SetDescription(Bitu nr, const char* descr) {
4  if (CallBack_Description[nr]) delete[] CallBack_Description[nr];
5  CallBack_Description[nr] = 0;
6
7  if (descr != NULL) {
8    CallBack_Description[nr] = new char[strlen(descr)+1];
9    strcpy(CallBack_Description[nr],descr);
10  }
11}

Also, in sdlmain.cpp, "PROGRAMS_Shutdown" is defined twice:

Copy code to clipboard

1void PROGRAMS_Shutdown(void);
2void DOS_UninstallMisc(void);
3void CALLBACK_Shutdown(void);
4void PROGRAMS_Shutdown(void);

Also, verifying that the the 3 bool variables should be set 2x in sdlmain.cpp (I have to check the 2 functions whether they alter their values):

Copy code to clipboard

1bool run_machine = false;
2bool reboot_machine = false;
3bool dos_kernel_shutdown = false;
4/* start the shell */
5control->StartUp();
6SHELL_Init();
7/* main execution. run the DOSBox shell. various exceptions will be thrown. some,
8* which have type "int", have special actions. int(2) means to boot a guest OS
9* (thrown as an exception to force stack unwinding), while int(0) and int(1)
10* means someone pressed DOSBox's killswitch (CTRL+F9). */
11run_machine = false;
12reboot_machine = false;
13dos_kernel_shutdown = false;

Fixed. Just curious, does the first issue prevent mingw from compiling it?
And for the third issue, no, there's no reason for them to be set to "false" twice.

Thank you! The first issue did prevent the compile (or it may have been the linker step) and the above was a fix for that; I've been testing your code sections against a mingw build and seeing what works. 😀 Mainly I've been studying the startup and shutdown code and how you dynamically allocated the dos system into the emulated RAM. It's so integrated it's difficult to just take a snippet and work with it, a testimony to the complexity and interdependence of a computer system emulator.

I did note that your dynamic allocation code which potentially frees RAM at address 0xD000 and above. Otherwise, I think, almost sure, that dosbox assigns UMB to that region. However, I recall discussion about that code and there are callbacks to that address region. Is it possible that that area is returned to free RAM but there is another function which has a callback to the 0xD000 address area? My bet is that you already accounted for that. 😀

truth5678 wrote:

Thank you! The first issue did prevent the compile (or it may have been the linker step) and the above was a fix for that; I've been testing your code sections against a mingw build and seeing what works. 😀 Mainly I've been studying the startup and shutdown code and how you dynamically allocated the dos system into the emulated RAM. It's so integrated it's difficult to just take a snippet and work with it, a testimony to the complexity and interdependence of a computer system emulator.

I did note that your dynamic allocation code which potentially frees RAM at address 0xD000 and above. Otherwise, I think, almost sure, that dosbox assigns UMB to that region. However, I recall discussion about that code and there are callbacks to that address region. Is it possible that that area is returned to free RAM but there is another function which has a callback to the 0xD000 address area? My bet is that you already accounted for that. 😀

A lot of the complexity there is caused by the gradual changes I've made to add those features. To be honest there's a lot of dynamic allocation I'd like to code that would help clean up a lot (something like the allocator I made for the BIOS area). DOSBox's original memory allocation code takes the total memory you want and just allocates a huge char[] array for system memory, including the area associated with adapter RAM and BIOS. Then it makes the BIOS read-only by changing the memory callback function to one that ignores writes. My changes do not affect that, except to map out entirely (if you want) anything not given to a device and to ensure that unused areas return 0xFF (like real hardware) where vanilla DOSBox left them set to 0x00. It's funny to note many emulators don't seem to understand that undefined areas return 0xFF, even VirtualBox got that wrong, which is why EMM386.EXE in VirtualBox can't autodetect where to put it's EMS page frame and you have to force a specific segment.

Since DOSBox "RAM" is one huge block there's really no way to "hole punch" portions of it out to free memory (unless you want to resort to platform-specific memory-mapping functions).

Some parts of DOSBox are coded around the large char[] array, taking the memory base and adding the physical location to do operations on memory, I've noticed.

I prefer to keep changes gradual so that any breakage is easy to spot and roll back on. Especially for things I can't always readily test like Win32 additions and shader effects.

I appreciate the insightful reply! I understand better now, especially how unused areas are identified. That must make it simple to ensure that memory is unused. I wonder who is programming vbox and how their code originated, too, especially given the size of the project.

I've noted how easily a small code change will cause breakage. I've been spending a lot of time just running a difference file between the 1st dosbox-x and the current dosbox-x, and finding out which section of code in which I caused a break. I thought it was the startup/shutdown functions, but instead it may something as simple as a line somewhere. I almost have isolated it. The sole cause of this is from testing your code sections without another integrated part (proof is that the integrated whole works great!). 😀

truth5678 wrote:

I appreciate the insightful reply! I understand better now, especially how unused areas are identified. That must make it simple to ensure that memory is unused. I wonder who is programming vbox and how their code originated, too, especially given the size of the project.

I've noted how easily a small code change will cause breakage. I've been spending a lot of time just running a difference file between the 1st dosbox-x and the current dosbox-x, and finding out which section of code in which I caused a break. I thought it was the startup/shutdown functions, but instead it may something as simple as a line somewhere. I almost have isolated it. The sole cause of this is from testing your code sections without another integrated part (proof is that the integrated whole works great!). 😀

One mystery I'd like to solve as well, if you can help me out on this, is why Second Reality crashes halfway through in DOSBox-X. Even if I compile from the initial commit. Whatever causes it also causes Second Reality to divide by zero crash in the latest commit of the vanilla DOSBox code. The crash happens when starting the section with the green 3D balls that rotate like a tornado while bouncing off the ground. It used to run just fine in DOSBox 0.72 when I first captured the demo to DVD in 2007 for a friend of mine.

I'll definitely work on it. I'm almost finished with my current task, I believe it is certainly an obscure line of code in this current case!

I'll run a difference between 0.72 and SVN and isolate the issue that way. I'll verify the different cores and whether they have an effect in either or both versions. 😀

Edit: saw this in the compat list for second reality (must be 0.72? (2008)) --
"Runs perfectly, on my setup.
Demo crashing halfway (during the "particle spring" part) is a bug in the demo, which relates to the path being to long (also happens to real DOS machines). Run it from C: or a 1 level deep subdirectory to fix."

It showed a cache block overrun error (core=dynamic), at least the part I could see, running the latest commit of vanilla dosbox with a bunch of code patched in. It was a cube rotating, one with multiple colors, when the error appeared. I also lost mouse movement for a minute, possibly linked to an effect on SDL and its release of the mouse. I'll continue to test.

Edit: I believe 0.74 crashed at same point where the cube was rotating. However, it didn't show the overrun error (probably that log message was added in SVN?). I've been running sbpro/standard for sound.

0.72 crashed with a cpu reset error, I think I caught part of the log showing that it is related to the keyboard (around the same part of the demo as the newer versions).

I was running the Win32 build (official release of 0.72) at the time. Would that make a difference?

I was running win32, too. I just reproduced it again with 0.72 and it showed the error with cpu reset concerning XMS: then something about a keyboard, I think.

I wonder if we could disable xms and try jemmex?

truth5678 wrote:

I'll definitely work on it. I'm almost finished with my current task, I believe it is certainly an obscure line of code in this […]
Show full quote

I'll definitely work on it. I'm almost finished with my current task, I believe it is certainly an obscure line of code in this current case!

I'll run a difference between 0.72 and SVN and isolate the issue that way. I'll verify the different cores and whether they have an effect in either or both versions. 😀

Edit: saw this in the compat list for second reality (must be 0.72? (2008)) --
"Runs perfectly, on my setup.
Demo crashing halfway (during the "particle spring" part) is a bug in the demo, which relates to the path being to long (also happens to real DOS machines). Run it from C: or a 1 level deep subdirectory to fix."

Huh. So the programmers used too short a char buffer for file paths?

I extracted the Second Reality files to a folder and made that drive C, then used symbolic links (in Linux, 'ln -s') that point back to the root directory. To the DOS VM, they become subdirectories that have the same content as the root directory to make doing this test easier.

I would like to note that in my tests it doesn't matter if you use GUS, SB, or silent audio output, the crash is the same. In these tests, I used GUS playback.

Test results:

Starting dosbox-x with dynamic core, running SECOND.EXE and no ULTRASND variable: Invalid opcode exceptions
Starting dosbox-x with normal core, running SECOND.EXE and no ULTRASND variable: It works
Starting dosbox-x with dynamic core, running SECOND.EXE and ULTRASND variable (GUS emulation enabled): It works

weird...

Run from C:\SECOND.EXE - No problems.
Run from C:\X\SECOND.EXE - Particles fall rapidly, hit the floor, crash with runtime divide by zero (same result as vanilla DOSBox). Music for that section kept playing with a blank screen until the next part.
Run from C:\XX\SECOND.EXE - Same as "X"
Run from C:\XXX\SECOND.EXE - No problems.
Run from C:\XXXX\SECOND.EXE - No problems.
Run from C:\XXXXX\SECOND.EXE - Lockup (DOSBox complains about invalid opcodes)
Run from C:\XXXXXX\SECOND.EXE - Lockup (DOSBox complains about invalid opcodes)
Run from C:\XXXXXXX\SECOND.EXE - No problems.
Run from C:\XXXXXXXX\SECOND.EXE - No problems.

Run from C:\XXXXXXXX\X\SECOND.EXE - Particles fall but many of them are not being drawn, then part hangs.
Run from C:\XXXXXXXX\XX\SECOND.EXE - Lockup (DOSBox complains about invalid opcodes)
Run from C:\XXXXXXXX\XXX\SECOND.EXE - Lockup (DOSBox complains about invalid opcodes)
Run from C:\XXXXXXXX\XXXX\SECOND.EXE - Particles fall but many of them are not being drawn, then part hangs.
Run from C:\XXXXXXXX\XXXXX\SECOND.EXE - Particles fall but many of them are not being drawn, then part hangs.
Run from C:\XXXXXXXX\XXXXXX\SECOND.EXE - No problems.
Run from C:\XXXXXXXX\XXXXXXX\SECOND.EXE - No problems.
Run from C:\XXXXXXXX\XXXXXXXX\SECOND.EXE - Lockup (DOSBox complains about invalid opcodes)

I'm sure I could run all the way out to several directories deep, but I think this conveys the apparent pattern well.

The thing is I remember running the demo possibly one, two, or three folders deep from Windows 98 "DOS mode" back in the day with no problems. Are you sure DOSBox isn't doing something to overrun a buffer somewhere? According to descriptions of the source code, part of their "Demo Interrupt Server" involves hooking INT 21h to allow running EXE files and their datafiles directly from within the SECOND.EXE which probably doesn't help diagnosing this problem.

One guess I have is that this might be another one of those memcpy() vs memmove() mistakes, possibly within DOSBox-X itself. The difference between copying one region of memory to another (that doesn't overlap) verses copying memory regions that overlap, in order to shift contents back or forth a few bytes, like when taking a C-string and using memmove() to shift the rest of the string back to overwrite some characters you don't want anymore. I can explain in more detail why memcpy() vs memmove() matters if you like.

^ following up on my post: I'm also prepared for the horrifying possibility that SECOND.EXE itself may have made that mistake. I haven't read their published code too deeply to know if there's anything in there like that.

Please do -- it sounds like an interesting problem. Do you think the error is related to the the demo's loading of datafiles via INT 21h, or that dosbox loads the data to memory incorrectly? It seems like 0.72, 0.74, and SVN all have the same location for the error, but report it differently in terms of its origin.

Does the program run in real mode only?

Just as an aside, I finally found that error that I mentioned above, I accidentally changed two lines from fprintf to LOG_MSG! The compiler should have warned me. 🙁