I ran into this issue (Windows 98 - Controller not recognized ? ) recently (began trying to tackle it around 2021-08). I have found a solution, and it possibly points to an error within dosbox-x.

I am running windows 10 (whatever service pack is current as of 2021-10-16), on an i4770k @ stock (3.5GHz) system, 32GB ram, GTX1080ti. I use vjoy to map my xbox elite series 2 controller to old games, so I am routing through vjoy. I use hidguardian to block win10 from seeing the xbox controller, so in control panel -> devices and printers -> controllers only sees vjoy. I am running dosbox-x v.18 build though this is present on the .17 and .16 versions as well.

I load win95 (any version, tested it on RTM, a, b, and c) or win98 (any version, tested RTM and SE). My controller is recognized in the dosbox-x mapper, and works in mechwarrior 2 run through dosbox-x. However, the controller is not recognized within win9x operating as guest os within dosbox-x.

Under my computer -> control panel -> system -> device manager -> sound, video, and game controllers, there is listed: 1) creative labs sound blaster 16 plug and play, 2) gameport joystick, 3) mpu-401 compatible.

Under gameport joystick -> properties -> resources, there is only the option for "basic configuration 0000", which is i/o range 0200-0207. This range will not recognize dosbox-x emulating the gameport joystick. There is no "basic configuration 0" or "basic configuration 1" as others have suggested to use. This makes the joystick not visible in win9x, and will not work.

Now, the fix:

1) Under device manager -> sound, video, and game controllers, select gameport joystick, and hit "remove".

2) In control panel, launch "add new hardware".

3) Click "next".

4) Select "no" -- we are going to manually install the gameport.

5) From the list, near the bottom, select "sound, video and game controllers" and hit "next".

6) In the left hand list select "microsoft", in the right hand list select "gameport joystick" (there may be a few, with driver dates listed, try each of them until one works, though, it may require repeating this entire process for each attempt). Once both sides have been selected, hit "next".

7) It should now list i/o as 0201. Hit "next".

8) Hit "finish".

9) It will ask to restart, hit "no" -- if you restart, it will reset the i/o range, and you need to repeat this process.

I need to repeat this every single time i restart win9x under dosbox-x. It's not that difficult, but it is quite annoying.

It is worth pointing out that PCEM and 86box both emulate the gameport controller and accept vjoy and joysticks on the i/o range of 0200-0207. I believe this means dosbox-x is not feeding windows the correct gameport i/o information. I am not a CE expert, so I have no real idea what's going on here, but it does point to an issue that might have a simple fix in the dosbox-x code.

shortlyfelongrope wrote on 2021-10-16, 18:47:

I ran into this issue (Windows 98 - Controller not recognized ? )

Moved post to correct thread.

There is a recent commit to dosbox-x for "allowing borderline quotient values in IDIV":
https://github.com/joncampbell123/dosbox-x/pull/3014

The above commit is a partial reversion to dosbox svn commit r2175, a change to the idiv instruction and related code. It may be worth testing whether any remaining bugs in MSFS 1.0 are related to that commit. Also, it may be worth verifying that the registers affected by idiv are used in the case of the borderline quotient values in the above pull request. The partial revert is probably not a complete solution. If the below is applicable, then it should be possible to attach a reversion of r2175, whether in part or full, to the 8086/8088 cpu types for testing.

There is more information about the MSFS 1.0 bug at stackexchange:
https://retrocomputing.stackexchange.com/ques … by-zero-command

"Compatibility difficulty included the unusual use of the x86 assembly DIV command, where a "DIVIDE BY ZERO" command would be issued every time a screen refresh was needed. This technique often required hardware changes to assure compatibility with MSFS 1.0 software."

-and-

"I don’t think however that this would cause issues with 8086/8088-based computers attempting to be PC compatible, because this is handled by the CPU. It does cause problems with later CPUs though because the divide-by-zero error became a fault, not a trap, with the address on the stack pointing at the faulting instruction, not the one following it. Thus on World Maker or Flight Simulator 1, the divide-by-zero instructions would result in the interrupt 0 handler being called, but when that returned, the divide-by-zero instruction would run again, causing an infinite loop."

If I'm reading this correctly, what DOSBox-X needs to do on divide by zero is return to the following instruction if cputype=8086, and the faulting instruction otherwise?

Does the 80186 also return to the faulting instruction?

I think so. Given the commit is reversed and the cpu=8086, then it seems reasonable to return to the following instruction for now. I would verify that the registers in idiv are handled correctly, too. I think any change should be attached to 8086, until more is known of the other cpu types. This can be tested in the normal core for now.

I do not know about the 80186. I think real hardware would be interesting to test with, even for a 286 if a 80186 is not available.

The RBIL says a few things about divide exception behavior of 8086/8088 in the INT 0 notes: http://www.delorie.com/djgpp/doc/rbinter/id/06/0.html

However, I suspect not all is said about edge cases generating an exception (or not) that differ from later processors, so it would be good to test on a real 8088.

There is an interesting list of differences between the 8086 and 386 cpu:
https://pdos.csail.mit.edu/6.828/2008/reading … i386/s14_07.htm

Examples:
"The 80386 can generate the largest negative number as a quotient for the IDIV instruction. The 8086/8088 causes exception zero instead."

"The setting of the flags stored by PUSHF, by interrupts, and by exceptions is different from that stored by the 8086 in bit positions 12 through 15. On the 8086 these bits are stored as ones, but in 80386 real-address mode bit 15 is always zero, and bits 14 through 12 reflect the last value loaded into them."

I can confirm here on my Linux development system with GCC that modern processors can also handle IDIV without faulting with a result of 0x80000000

1# x86_64
2gcc -o idiv idiv.c
3
4# i686
5gcc -m32 -o idiv idiv.c

1#include <stdio.h>
2#include <stdint.h>
3
4int main() {
5	volatile int32_t r;
6
7	__asm__ __volatile__ (
8		"mov $-2,%%edx\n"
9		"mov $0,%%eax\n"
10		"mov $4,%%ecx\n"
11		"idiv %%ecx\n"
12		: "=a" (r)
13		:
14		: "rdx", "rcx");
15
16	printf("%d %x\n",(int)r,r);
17
18	return 0;
19}

1bash-5.0# /idiv 
2-2147483648 80000000

Processor is a "Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz"

hail-to-the-ryzen wrote on 2021-11-01, 00:40:

There is an interesting list of differences between the 8086 and 386 cpu: https://pdos.csail.mit.edu/6.828/2008/reading … i386/s […]
Show full quote

There is an interesting list of differences between the 8086 and 386 cpu:
https://pdos.csail.mit.edu/6.828/2008/reading … i386/s14_07.htm

Examples:
"The 80386 can generate the largest negative number as a quotient for the IDIV instruction. The 8086/8088 causes exception zero instead."

"The setting of the flags stored by PUSHF, by interrupts, and by exceptions is different from that stored by the 8086 in bit positions 12 through 15. On the 8086 these bits are stored as ones, but in 80386 real-address mode bit 15 is always zero, and bits 14 through 12 reflect the last value loaded into them."

Ah-ha. So emulation needs a few more adjustments for 8086 emulation then:

IDIV exceptions for quotients of 80H or 8000H.

The 80386 can generate the largest negative number as a quotient for the IDIV instruction. The 8086/8088 causes exception zero instead.

hello

i have a small question.
i want to run the game Sideline with dosbox-x

http://sideline.ghegs.com/

the game needs jemmex to run but i cannot get jemmex to work with dosbox-x
when i disable ems and start to run jemms with "jemmex noems load"
i get the message:
"xmm already installed"

seems a memory manager is runing in the background
how can i disable it and play the game ?

thx in advance

edit:
i got it working 😀
had to disable xms and umb as well

K.A.R.R. wrote on 2022-01-12, 15:02:

hello […]
Show full quote

hello

i have a small question.
i want to run the game Sideline with dosbox-x

http://sideline.ghegs.com/

the game needs jemmex to run but i cannot get jemmex to work with dosbox-x
when i disable ems and start to run jemms with "jemmex noems load"
i get the message:
"xmm already installed"

seems a memory manager is runing in the background
how can i disable it and play the game ?

thx in advance

edit:
i got it working 😀
had to disable xms and umb as well

Perhaps it's using an EMM detection method that is unusual. As a possible hangover from when DOSBox-X forked from SVN, there may be EMM-related structures in memory that are always there even if ems=false tells the DOS kernel to pretend that EMM functions are not there (in a way, like INT 33h mouse emulation). So the first question is what is JEMMEX doing to detect EMS?

Or does XMM refer to XMS (extended memory) services?

EDIT: Actually, perhaps it's checking the EMM/VCPI interrupt to see if it's nonzero? I remember there were plenty of examples in the Demoscene where the demo refused to run because it thought EMS was enabled even if ems=false, and it turned out it was testing whether the interrupt vector was 0000:0000 or not.

Is it me or ps1 audiocard emulation is totally broken in latest dosbox-x build(s)?

Myloch wrote on 2022-01-17, 02:31:

Is it me or ps1 audiocard emulation is totally broken in latest dosbox-x build(s)?

I don't have any test cases for PS/1 audio card emulation, so if that code has bitrotted, then it needs to be noted in the issue tracker.

Another question: am I supposed to use latest dosbox-x with internal mt32 emulation or external munt driver? I noticed that using external one emulation is better: all the games I tried seem to play mt32 tunes at lower (wrong) pitch if I use the internal one.

Myloch wrote on 2022-01-17, 17:22:

Another question: am I supposed to use latest dosbox-x with internal mt32 emulation or external munt driver? I noticed that using external one emulation is better: all the games I tried seem to play mt32 tunes at lower (wrong) pitch if I use the internal one.

Either is fine, but if the pitch is wrong for internal MT32, that needs to be noted too. Is the sample rate used by MT32 synthesizers known? Perhaps the DOSBox mixer is being given the wrong sample rate. MT32 emulation was originally ported in from DOSBox Daum's branch about 7-8 years ago.

I think I somewhat fixed the mt32 problem by changing the default mt32.rate value to 48000.

I cannot run 3dfx-patched version of Blood 1 on DosBox-X.

I applied patch with no error, put glide2x.ovl in the game's directory and all I get is 'Fatal Error' - unable to load DLL'.

Can anybody make a short, step by step tutorial how to setup Dosbox-X for this game?

songo wrote on 2022-02-19, 21:13:

I cannot run 3dfx-patched version of Blood 1 on DosBox-X.

I have the same problem. Other games work but Blood always says that it cannot load DLL.

I just made a fix to S3 accelerated XGA emulation that DOSBox SVN might be interested in.

There's a case where a rectangular pattern blit can use display memory as a pattern source to select foreground and background. DOSBox SVN, and that code inherited by DOSBox-X, make an educated guess by comparing the source data from video RAM with the foreground and background colors, but that's wrong according to S3 Trio32/Trio64 documentation I have, and it makes a visual artifact in Creative Writer under Windows 3.1 in the "basement".

Apparently what you are supposed to do, is read the pixel from video memory, mask by the XGA read mask, and then, if all bits are 1, use the foreground color. Else, use the background color.

The S3 Windows 3.1 video drivers like to leave foreground == 0 and background == 0xFF a lot, so the SVN case generally happened to work, but it's wrong.

This commit fixes that visual anomaly in the "basement" of Creative Writer, as described.

Source code commit also links to the PDF in question and where in the PDF the pattern blit behavior is described.

https://github.com/joncampbell123/dosbox-x/co … c02ebab839a1681

https://sourceforge.net/p/dosbox/code-0/4446/
Creative Artist has the same "basement" screen that Creative Writer does. A fix was committed for those awhile ago.