hail-to-the-ryzen wrote on 2023-01-25, 08:29:

There is a pull request "Sync dh fpu state with normal fpu": https://github.com/joncampbell123/dosbox-x/pull/3965 […]
Show full quote

There is a pull request "Sync dh fpu state with normal fpu":
https://github.com/joncampbell123/dosbox-x/pull/3965

"...fixes the fpu state out of sync problem when dynamic core calls normal core to handle self modification code."

On testing the latest commits in the above patch with core=dynamic, there is a significant performance penalty, such as for win32 games as available to a Win95 guest OS. It may be worth verifying in other environments. Otherwise, a better option is to test performance (and the above fpu state issue) while running core=dynamic with a build based on the non-x86 fpu (instead of the x86 fpu emulation).

I'm the author of this patch. There is more discussion on this issue in dosbox-staging repo https://github.com/dosbox-staging/dosbox-staging/pull/2248

Can anyone please help me? None of my games will launch anymore, I just get this error message:

Azarien wrote on 2022-02-19, 22:18:

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 have finally found a working solution - running DosBox-X with "-set memsize=63 -set output=opengl" did the trick.

finalpatch wrote on 2023-01-26, 04:56:

hail-to-the-ryzen wrote on 2023-01-25, 08:29:

There is a pull request "Sync dh fpu state with normal fpu":
https://github.com/joncampbell123/dosbox-x/pull/3965
...

I'm the author of this patch. There is more discussion on this issue in dosbox-staging repo https://github.com/dosbox-staging/dosbox-staging/pull/2248

With the recently submitted commits to dosbox-x the major performance penalty in Win95 is no longer present. However, my tests are in a small sample. With the improvements to the patch I will continue to test since it improves the accuracy in a crucial area of the x86-specific emulation. One example where a major slowdown still occurs is in the win32 program BGB, such as version 1.03:
Re: Emulation on Windows NT 4.0

This case was not tested against core=dynamic where the non-x86 fpu emulation is used.

I have a question about swapping big, 8gig VHDs between DOSBOX-X and PCEM. Unless I'm missing something, I see that PCEM has a max limit of 16 heads, so an 8gig hd has 16302 cylinders - whereas in DOSBOX-X the standard VHD will have 255 heads and 1023 cylinders which will get it rejected outright by PCEM.

I have tried using the VHD from PCEM, first by putting -size 512,63,16,16302 into the conf (which made the contents of the disk seem garbled) and then by putting the standard DOSBOX-X -size 512,63,255,1023. This seems to work just fine, but, as I know computer code is incompatible with common sense, I kinda suspect it might cause file/directory/vhd corruption in some way.

Are there any experiences with this? Of course, a workaround would be to take the two VHDs, attach them in Disk Management and just copy the stuff from one to the other.

@Sallow

If you want larger VHDs switch from PCEM to 86BOX.
I'm not sure what the limit is for 86BOX but I've used 100GB VHDs without issue.

Ok, I think I have given 86BOX a fair try... apologies to the devs, but it just isn't for me. It is absolutely DROWNING in roms that a lay person wouldn't know to pick from. I kept trying to find a BIOS that would let me install DOS 7.1 CDU on an 8GB drive, but they ALL kept giving me the "not bootable disk" error. Some even when I tried to boot with the DOS 6.22 floppies (yes, I did a hard reboot.) There are no help files, it got so frustrating I went to YouTube to hopefully watch some tutorials. I found the devs' official channel (I think) which was all just videos about running pre-3.1 versions of Windows and I watched a video by some guy who was playing a bunch of games and just stating matter-of-factly "this one had buggy sounds" "this one had problems with the keyboard" for practically every game he played. And the UI... When I wish to change/eject a floppy I have to click on Media and then move my mouse all the way to the edge of the screen, to access the side-menu (because it has to print out the entire directory path... in the drop-down menu)

The plus side is that, even though by default it uses the PCem format for virtual HD files, with 16 heads and 16302 cylinders, it does accept the 255,1023 DOSBox-X format.

But still... no. My question about whether it's fully safe to use the PCem-created VHD files in DOSBox-X still stands. Anyone?

I created today a Pentium MMX class machine in 86Box 3.11, and gave it a 2GB RAW HDD image with Win98SE pre-installed that had been created with DOSBox-X.

On first launch, it obviously found tons of new hardware, but it worked just fine. In fact, on my system, the guest OS felt a lot smoother in 86Box then in DOSBox-X.

The machine I chose in 86Box was a:

• Machine Type: Socket 7 (Dual Voltage)
• Machine [i430TX] Intel YM430TX
• CPU type: Intel Pentium MMX 233
• Video: [PCI] ATI Mach64GX

That's nice but this thread is for dosbox-x not 86box or pcem so no one cares.

I have a question that may be a bit difficult to answer.

I'm running Windows 98 SE and using it to listen to MIDIs using the Yamaha S-YXG100 Plus synthesizer, because running it under Windows 98 is the only way to activate the Sondius drivers, which sound spectacular, if configured correctly. You can run this Yamaha player under Windows 10, but so far as I can tell, nobody has found a way to activate the Sondius drivers under a modern OS so it must be run under Windows 98 to get the best sound quality.

What I'm trying to do is to run Windows 98 under DOSBox-X, set up a MIDI playlist to play in the background, while I surf the Internet, and run DOSBox-X minimized in the background.

The problem that I'm having is that if I use the SDL1 version of DOSBox-X, when I alt-tab out of it, it automatically goes from fullscreen to windowed, and if I minimize it, all programs running in DOSBox-X become muted. Also, if I leave it unminimized, and switch to any web browser, it also becomes muted. Strangely enough, I can switch to other windows, but as soon as I switch to my web browser, DOSBox-X always mutes itself.

If I use the SDL2 version of DOSBox-X, and alt-tab out of it, it will stay fullscreen, but for some odd reason, any audio player used starts stuttering and skipping after a short while, and I have a very fast, modern computer. If I switch back to DOSBox-X, the player plays perfectly, without stuttering, but when I alt-tab out, it will start stuttering again in a short amount of time.

I have already changed the priority setting to highest,highest so that isn't the problem.

Is this a known bug in DOSBox-X or is there some obscure setting that I'm missing that will fix this situation?

BTW, I know that I can do what I want to do under 86Box, but the sound quality under 86Box is very poor compared to DOSBox-X, and that defeats the point of what I'm trying to accomplish.

Sorry for the long post, but this is as succinct as I could think to explain the situation without leaving out any important details. Thanks in advance for any help with this problem.

The RISC-V CPU based Linux system would be an interesting target to support:
https://wiki.pine64.org/wiki/STAR64

Does anybody know if any progress has been made in getting scroll wheel support working under Windows 98? We discussed the matter here in this thread a couple of years ago and nothing much seemed to come of it at the time. I tried once again a few days ago with the newest DOSBox-X release, and so far, I've still not found any combination of options that would yield scroll wheel support in Windows 98. Am I missing something?

DragonSlayer wrote on 2023-04-10, 05:43:

Does anybody know if any progress has been made in getting scroll wheel support working under Windows 98? We discussed the matter here in this thread a couple of years ago and nothing much seemed to come of it at the time. I tried once again a few days ago with the newest DOSBox-X release, and so far, I've still not found any combination of options that would yield scroll wheel support in Windows 98. Am I missing something?

I posted a question about this recently on github. Nobody seemed to know the answer and I found no other issues regarding mouse wheel scrolling in W98.

@feda: Thank you for the reply. I posted what I believe is the key to getting scroll wheel support working in Windows 98 on page 111 of this thread a couple of years ago, but I guess nobody has taken the time to implement it yet. I'm not a programmer or else I would have done so myself.

On the bright side, the original MouseImp Pro works on Windows 98, so that makes navigating Windows 98 much much easier, but it would still be nice to have proper scroll wheel support implemented into DOSBox-X for Windows 98.

I did some testing with the Intellimouse emulation.

It doesn't seem to work with Windows 98/ME because despite the fact that they do set the mouse up in Intellimouse mode, they still depend heavily on the BIOS PS/2 INT 15h functions and the BIOS callback function, which in DOSBox-X at this time does not provide any scrollwheel support in 4-byte packet mode. Except Windows 98 sticks with the 3-byte packet mode through INT 15h even after sending the sequence to the mouse to enable Intellimouse mode.

However if I boot into Windows 2000, which talks directly to the AUX emulation, Windows 2000 goes through the process at startup to set up the 5-button wheel mouse (device ID 0x04) and the scrollwheel from the host works perfectly fine in Windows 2000.

It looks like WinWorld found old Intellimouse drivers for Windows 95/98 so perhaps scroll wheel works for those OSes only if you install the driver.

https://winworldpc.com/product/intellipoint/1x

@TheGreatCodeholio: Thank you for responding. I'm not sure if you missed my post from a couple of years ago, but it seems like the Intellimouse works with a challenge/response type of system.

When first queried, the mouse should respond as a standard Intellimouse, then when challenged, it should give the proper response to be detected as a scrolling Intellimouse, then when challenged once again, it should then give the proper response to be detected as a 5 button scrolling Intellimouse.

If you have the time, check out my comments on page 111 of this thread. Maybe that will help in figuring out this mystery, and thank you for taking your valuable time to try to help resolve this tough problem. It has been bugging me for the last few years not not having proper scroll wheel support in Windows 98. If you can fix this problem, it would be a great relief for anyone running Windows 98 under DOSBox.

Nope. As far as I can tell, the Standard PS/2 mouse driver just uses INT 15h PS/2 functions for a callback even with IntelliPoint/IntelliMouse installed.

I'm not certain whether Windows 95/98 at that point merely just buffer 3 or 4 bytes from the 3 bytes of the BIOS and read it that way, or if BIOSes somehow recognize the knock sequence through INT 15h and change the callback to 4 bytes, or what. It will need more study to get Intellimouse working in Windows 9x/ME. But as I said, OSes like Windows NT and 2000 talk directly to the AUX port and the code as implemented in DOSBox-X does work with regard to Intellimouse emulation and the scroll wheel.

DragonSlayer wrote on 2023-04-12, 20:27:

@TheGreatCodeholio: Thank you for responding. I'm not sure if you missed my post from a couple of years ago, but it seems like the Intellimouse works with a challenge/response type of system.

When first queried, the mouse should respond as a standard Intellimouse, then when challenged, it should give the proper response to be detected as a scrolling Intellimouse, then when challenged once again, it should then give the proper response to be detected as a 5 button scrolling Intellimouse.

If you have the time, check out my comments on page 111 of this thread. Maybe that will help in figuring out this mystery, and thank you for taking your valuable time to try to help resolve this tough problem. It has been bugging me for the last few years not not having proper scroll wheel support in Windows 98. If you can fix this problem, it would be a great relief for anyone running Windows 98 under DOSBox.

That part I fully understand, and emulation is implemented as described regarding 200, 100, 80 and 200, 200, 80 sequences. The problem is that Windows 9x/ME use the INT 15 PS/2 BIOS functions to talk to the PS/2 mouse which doesn't implement the scroll wheel, and even if it did, it's not certain how, in the way Windows 9x/ME talks to it, how the 4 byte packet would work 3 bytes at a time. As far as I can tell, Windows 9x asks for the 3-byte format, then sends the knock sequence, then verifies with the device ID, but at no point does it go back to the BIOS and change the callback setup for 4 bytes per packet. That's what's confusing about all this.

The only way I can think to answer this question is to pull out DOSLIB, an old Pentium II system and find a PS/2 Intellimouse to test this with. Or perhaps a USB Intellimouse made around 2001-2004 when they often shipped with a USB-PS/2 adapter back when that was more common.

Concerning my earlier post about DOSBox-X muting itself when minimized or running in the background, DOSBox Staging has recently fixed this problem with their fork. I can now listen to MIDIs playing in the background when running Windows 98 on DOSBox Staging without it muting or stuttering! Now if only the DOSBox-X team could implement their recent fix, that would be awesome! 😀