Indeed, I might dust off the Mac Mini and look at supporting Metal in some rudimentary fashion.

Likewise if Centos 7 supports Vulkan.

I don't have the faintest idea why, but I'm having trouble connecting to the internet through the Guest OS using the emulated NE2000 (NPCap with WinCap Compatibility Mode on has been installed and everything has been recognized). It's just that I feel like if I can't get *anything* from Win98SE's IE6, then I'm not going to get the kind of network connections I want for games.

Attached is the dosbox.conf of my configuration (yes, my realnic is 9. My network configuration is kind of ridiculous and might be at fault. I made sure the nic matched my real ethernet device though, so...)

I'm running the 32 bit SDL1.2 version of "DOSBox-X beta 0.82.8 2018-07-15 16:00"

Danfun64 wrote:

I don't have the faintest idea why, but I'm having trouble connecting to the internet through the Guest OS using the emulated NE2000 (NPCap with WinCap Compatibility Mode on has been installed and everything has been recognized). It's just that I feel like if I can't get *anything* from Win98SE's IE6, then I'm not going to get the kind of network connections I want for games.

Attached is the dosbox.conf of my configuration (yes, my realnic is 9. My network configuration is kind of ridiculous and might be at fault. I made sure the nic matched my real ethernet device though, so...)

I'm running the 32 bit SDL1.2 version of "DOSBox-X beta 0.82.8 2018-07-15 16:00"

Change the NE2000 IRQ to 10, then in Windows 95 go into the control panel, system, and edit the NE2000 card settings to match.

I don't know why the original code that DOSBox-X inherited set the NIC default to IRQ 3.

Note that IRQ 3 conflicts with the serial port.

No wonder PCem has it set to 10. Thanks for the quick response!

Edit: Still doesn't work. Odd.

Edit 2: Gave up and went back to PCem. It was more accurate (and ironically faster) anyways. Main reason I tried going with Dosbox-X in the first place was because it might have been faster than PCem.

So i downloaded the windows version and I get within the folders a total of 4 different versions of this program. 2 different 32bit versions and 2 different 64bit versions. Which binary should I be using?

Danfun64 wrote:

No wonder PCem has it set to 10. Thanks for the quick response!

Edit: Still doesn't work. Odd.

Edit 2: Gave up and went back to PCem. It was more accurate (and ironically faster) anyways. Main reason I tried going with Dosbox-X in the first place was because it might have been faster than PCem.

In making DOSBox-X faster I have occasionally sacrificed some performance, yes.

EDIT: Stupid typo... I meant "In making DOSBox-X more accurate I have occasionally sacrificed some performance, yes."

Try running with the --debug option and set up dosbox.conf to log all output to a file.

There's usually some pretty good hints at what is going on with NE2000 emulation.

retrogamerguy1997 wrote:

So i downloaded the windows version and I get within the folders a total of 4 different versions of this program. 2 different 32bit versions and 2 different 64bit versions. Which binary should I be using?

The best supported version is the SDL1 main version. I provide SDL2 versions for those who want it at the time.

Use the version that best suits your needs. However, 32-bit may provide better performance due to the dynamic core as long as the program or guest OS does not use 32-bit protected mode with paging.

Danfun64 wrote:

It was more accurate (and ironically faster) anyways.

More accurate in what? Faster in what? My experience has been the opposite.

TheGreatCodeholio wrote:

retrogamerguy1997 wrote:

So i downloaded the windows version and I get within the folders a total of 4 different versions of this program. 2 different 32bit versions and 2 different 64bit versions. Which binary should I be using?

The best supported version is the SDL1 main version. I provide SDL2 versions for those who want it at the time.

Use the version that best suits your needs. However, 32-bit may provide better performance due to the dynamic core as long as the program or guest OS does not use 32-bit protected mode with paging.

Thank you for the reply. I'm just wondering, Do I need a Glidewrapper to use the voodoo emulation in this dosbox fork?

retrogamerguy1997 wrote:

TheGreatCodeholio wrote:

retrogamerguy1997 wrote:

So i downloaded the windows version and I get within the folders a total of 4 different versions of this program. 2 different 32bit versions and 2 different 64bit versions. Which binary should I be using?

The best supported version is the SDL1 main version. I provide SDL2 versions for those who want it at the time.

Use the version that best suits your needs. However, 32-bit may provide better performance due to the dynamic core as long as the program or guest OS does not use 32-bit protected mode with paging.

Thank you for the reply. I'm just wondering, Do I need a Glidewrapper to use the voodoo emulation in this dosbox fork?

You'll need something to provide a GLIDE.OVL for the DOS game to talk to. I generally use the actual 3DFx drivers for testing that feature.

TheGreatCodeholio wrote:

retrogamerguy1997 wrote:

TheGreatCodeholio wrote:

The best supported version is the SDL1 main version. I provide SDL2 versions for those who want it at the time.

Use the version that best suits your needs. However, 32-bit may provide better performance due to the dynamic core as long as the program or guest OS does not use 32-bit protected mode with paging.

Thank you for the reply. I'm just wondering, Do I need a Glidewrapper to use the voodoo emulation in this dosbox fork?

You'll need something to provide a GLIDE.OVL for the DOS game to talk to. I generally use the actual 3DFx drivers for testing that feature.

Thanks, I'll keep that in mind.

In keyboard.cpp, the AT and XT keyboard scancode sets handle repeat key presses differently (AddKey1 - 3).

1		if (keyb.repeat.key == keytype) {
2			/* repeated key being released */
3			keyb.repeat.key=KBD_NONE;

Verified that Windows 95 OSR2 guest uses the AddKey1 code path in my testing, so that code path is correct. In this case, pressing 2 keys at the same time in a dos box shows expected behavior where unpressing one of the keys does not deactivate the other key from repeating. I do not have a configuration that uses the AddKey2 or AddKey3 code path, so I am unable to test whether they require a similar change to their repeat key handling. However, my guess is that they do.

hail-to-the-ryzen wrote:

Verified that Windows 95 OSR2 guest uses the AddKey1 code path in my testing, so that code path is correct. In this case, pressing 2 keys at the same time in a dos box shows expected behavior where unpressing one of the keys does not deactivate the other key from repeating. I do not have a configuration that uses the AddKey2 or AddKey3 code path, so I am unable to test whether they require a similar change to their repeat key handling. However, my guess is that they do.

The only way to test AddKey2 and AddKey3 is to run a guest OS that tells the keyboard to change the scan code set.

https://en.wikipedia.org/wiki/Scancode#PC_compatibles

EDIT: You can also test scan code sets 2 and 3 using the 8042 test program in DOSLIB.

It seems that the code paths for 2 and 3 are not reachable in common situations, so maybe it is just worth noting about. Supposedly Linux 2.5 may access scancode set 3, but 8042 translates set 2 back to the set 1 XT set, at least that is my interpretation.

hail-to-the-ryzen wrote:

It seems that the code paths for 2 and 3 are not reachable in common situations, so maybe it is just worth noting about. Supposedly Linux 2.5 may access scancode set 3, but 8042 translates set 2 back to the set 1 XT set, at least that is my interpretation.

Software written for AT and later systems can easily turn the XT translation on and off if the raw scan codes are desired.

The 8042 test program in DOSLIB allows you to play with these commands and test the keyboard scan code sets.

I'll search the Win95 API for that.

hail-to-the-ryzen wrote:

I'll search the Win95 API for that.

What makes you think Microsoft has an API to do that??

Thank you for sharing the information and for the doslib software to test with. I may test it on real hardware if I can find a ps/2 system.

hail-to-the-ryzen wrote:

Thank you for sharing the information and for the doslib software to test with. I may test it on real hardware if I can find a ps/2 system.

It should work with any AT or PS/2 compatible system and keyboard. For best results use an actual PS/2 keyboard. Try to avoid testing with "USB legacy mode" (BIOS uses a USB keyboard to emulate a PS/2 keyboard).