VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 2240 of 2248, by shortlyfelongrope

User metadata
Rank Newbie
Rank
Newbie

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.

Last edited by Stiletto on 2021-10-17, 20:43. Edited 1 time in total.

Reply 2241 of 2248, by Stiletto

User metadata
Rank l33t++
Rank
l33t++
shortlyfelongrope wrote on 2021-10-16, 18:47:

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

Moved post to correct thread.

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto

Reply 2242 of 2248, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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."

Reply 2243 of 2248, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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?

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 2244 of 2248, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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.

Reply 2245 of 2248, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 2246 of 2248, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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."

Reply 2247 of 2248, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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

# x86_64
gcc -o idiv idiv.c

# i686
gcc -m32 -o idiv idiv.c
#include <stdio.h>
#include <stdint.h>

int main() {
volatile int32_t r;

__asm__ __volatile__ (
"mov $-2,%%edx\n"
"mov $0,%%eax\n"
"mov $4,%%ecx\n"
"idiv %%ecx\n"
: "=a" (r)
:
: "rdx", "rcx");

printf("%d %x\n",(int)r,r);

return 0;
}
bash-5.0# /idiv 
-2147483648 80000000

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

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 2248 of 2248, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.