I think this would better meet the implementation recommended by jmarsh and krcroft. Tested the values for unsigned 8-bit mono sound only. This saves the xor operation, but one report suggests that the xor may use less than a cpu cycle. I think that the data value should have a casting operator, but the data type is also somewhat constricted by the condition "sizeof(Type)==1" and "signeddata".

It is best to use the previous version for any testing because this version would likely require additional code to verify the variable casting, otherwise one of the many compilers will probably report a warning. This is posted for reference for a slightly different way to run the conversion from 8-bit to 16-bit values and avoid a conversion bias.

The bias occurs with the 8-bit sample shifted by 8 bits to the left. For an signed 8-bit sample, it would range from -128 to 127. Where using the bit shift method to convert it to signed 16-bit, it becomes an unscaled range from -32768 to 32512. This is shown here:
https://github.com/dosbox-staging/dosbox-staging/pull/1005

The methods of scaling correct for that unscaled range so that the values will range from -32768 to 32767. This allows for a symmetric set of values and avoid some bias toward the negative values, as jmarsh discovered. Otherwise, there are 32768 negative values and 32512 positive values. I believe this can also lead to loss of color values where the conversion is for a color image with the same bit widths.

1diff -rupN dosbox-original/src/hardware/mixer.cpp dosbox/src/hardware/mixer.cpp
2--- dosbox-original/src/hardware/mixer.cpp
3+++ dosbox/src/hardware/mixer.cpp
4@@ -54,6 +54,8 @@
5 #define MIXER_SSIZE 4
6 #define MIXER_VOLSHIFT 13
7 
8+static Bit16s Sample_16_Table[256];
9+
10 static INLINE Bit16s MIXER_CLIP(Bits SAMP) {
11 	if (SAMP < MAX_AUDIO) {
12 		if (SAMP > MIN_AUDIO)
13@@ -379,12 +381,12 @@ inline void MixerChannel::loadCurrentSam
14 	last[1] = current[1];
15 
16 	if (sizeof(Type) == 1) {
17-		const Bit8u xr = signeddata ? 0x00 : 0x80;
18+		Bit16s *tablePtr = signeddata ? (Sample_16_Table + 128) : Sample_16_Table;
19 
20 		len--;
21-		current[0] = ((Bit8s)((*data++) ^ xr)) << 8;
22+		current[0] = *(tablePtr + (*data++));
23 		if (stereo)
24-			current[1] = ((Bit8s)((*data++) ^ xr)) << 8;
25+			current[1] = *(tablePtr + (*data++));
26 		else
27 			current[1] = current[0];
28 	}
29@@ -888,6 +890,15 @@ void MIXER_Controls_Init() {
30 	MAPPER_AddHandler(MAPPER_RecVolumeDown,MK_kpminus,MMOD1|MMOD2,"recvoldown","RecVolDn");
31 }
32 
33+void Mixer_SetSample16Table(void) {
34+    for (Bitu i=0;i<256;i++) {
35+        if (i > 128)
36+            Sample_16_Table[i]=((i-128) << 8) | (2 * (i-128) + 1);
37+        else
38+            Sample_16_Table[i]=(i-128) << 8;
39+    }
40+}
41+
42 void MIXER_Init(Section* sec) {
43 	sec->AddDestroyFunction(&MIXER_Stop);
44 
45@@ -913,6 +924,8 @@ void MIXER_Init(Section* sec) {
46 	mixer.recordvol[0]=1.0f;
47 	mixer.recordvol[1]=1.0f;
48 
49+	Mixer_SetSample16Table();
50+
51 	/* Start the Mixer using SDL Sound at 22 khz */
52 	SDL_AudioSpec spec;
53 	SDL_AudioSpec obtained;

It's already handled in the color upconversions by copying the X highest bits to the X lowest bits (where X is the amount of bits being upscaled by).

how can i fix(selecting some options) the sound effects noises\issues?

Is compatibility with CuteMouse currently broken? I have a particular game that does not like the built-in mouse driver, and in the past I've used CuteMouse to get around this problem, but it seems to not be working in the current build. Is anyone else experiencing this problem?

BTW, I've already tried setting int33=false and setting serial1=serialmouse and setting up CuteMouse as a serial mouse, using the /S1 switch, and that's not working either. The mouse buttons work, but I can't move the mouse cursor at all.

I read on the following page that this was a problem in the past, but that it was fixed. Has this fix been reverted or is this a new bug? DOSBox-X branch

DragonSlayer wrote on 2021-08-21, 05:59:

Is compatibility with CuteMouse currently broken? I have a particular game that does not like the built-in mouse driver, and in the past I've used CuteMouse to get around this problem, but it seems to not be working in the current build. Is anyone else experiencing this problem?

BTW, I've already tried setting int33=false and setting serial1=serialmouse and setting up CuteMouse as a serial mouse, using the /S1 switch, and that's not working either. The mouse buttons work, but I can't move the mouse cursor at all.

I read on the following page that this was a problem in the past, but that it was fixed. Has this fix been reverted or is this a new bug? DOSBox-X branch

You need to use the keyboard shortcut to capture the mouse, then relative mouse motion will be sent to the guest mouse driver. If the mouse is not captured, then relative motion is not sent or counted, but it is possible through INT 33h emulation built in to read absolute mouse position, and the DOSBox-X Windows 3.1 driver can also read absolute mouse position to match to the guest.

This same limitation exists with PC-98 games that talk directly to the bus mouse interface, or HDI images that load their own mouse drivers. The mouse protocols involved can only represent relative motion.

Using Ctrl+F10 to capture the mouse did the trick! Thanks!

I can't believe I forgot that simple trick. I knew there must be some simple something I was missing. I'm kind of glad it happened though because this post might help someone else that is trying to figure this out and save them some trouble in the future.

By the way, do I still need to set int33=false for CuteMouse to override the internal mouse driver, or will it do it automatically once the mouse is captured using Ctrl+F10?

DragonSlayer wrote on 2021-08-21, 18:46:

Using Ctrl+F10 to capture the mouse did the trick! Thanks!

I can't believe I forgot that simple trick. I knew there must be some simple something I was missing. I'm kind of glad it happened though because this post might help someone else that is trying to figure this out and save them some trouble in the future.

By the way, do I still need to set int33=false for CuteMouse to override the internal mouse driver, or will it do it automatically once the mouse is captured using Ctrl+F10?

I think CuteMouse checks for the existing driver first, so int33=false is recommended.

Thanks for the info. I will try to remember to leave int33=false when using CuteMouse.

I have one other quick question, if you don't mind. When using the /O switch with CuteMouse to enable scroll wheel support, the cursor will only move up and down and not left and right. Does DOSBox-X not have any support for a scroll wheel mouse?

I noticed the option in DOSBox-X to send up and down keyboard presses to simulate the scroll wheel, so does this mean there is no actual scroll wheel capability built in to DOSBox-X, even when using a scroll wheel supporting mouse driver?

DragonSlayer wrote on 2021-08-21, 20:25:

Thanks for the info. I will try to remember to leave int33=false when using CuteMouse.

I have one other quick question, if you don't mind. When using the /O switch with CuteMouse to enable scroll wheel support, the cursor will only move up and down and not left and right. Does DOSBox-X not have any support for a scroll wheel mouse?

I noticed the option in DOSBox-X to send up and down keyboard presses to simulate the scroll wheel, so does this mean there is no actual scroll wheel capability built in to DOSBox-X, even when using a scroll wheel supporting mouse driver?

There is supposed to be support for Intellimouse emulation, though recent patches set the default to send up/down arrow keys on scroll wheel instead for legacy software like DOS games or Windows 3.1.

DOSBox-X should recognize the initialization sequence for Intellimouse and send scroll wheel data, though that has not been well tested because Windows 95/98 do not support it without additional drivers and software. It sounds like CuteMouse might be a good test case. If Intellimouse emulation is failing to send left/right movement, then that is also something to fix.

See also: http://hackipedia.org/browse.cgi/Comput ... 1%29%2ehtm which describes Intellimouse mode and the scroll wheel.

Actually, looking at that document, I think I see the problem. Intellimouse compatible mice are supposed to report device ID 0x03, then change to device ID 0x04 when put into Intellimouse mode. DOSBox-X has it a bit wrong returning 0x00 until put into Intellimouse mode, looking into it.

EDIT: Erm, no, the documentation got it wrong. See the raw dump of communication?

EDIT: In fact, Windows 98 will actually hang/crash if a device ID of 0x03 is returned first. Even in Safe Mode. Hah.

According to the link, an Intellimouse should operate as a standard PS/2 mouse at power-on or when reset, with a device ID of 00h until the host sends the following command sequence:

Set sample rate 200
Set sample rate 100
Set sample rate 80

At this point the host then issues the "Get device ID" command and waits for a response. If a non-Intellimouse is attached, it will respond with a device ID of 00h, but if an Intellimouse is attached, it will respond with an ID of 03h. Then the host will expect the mouse to use a 4-byte movement data packet instead of the normal 3 byte packet.

So according to the article, an Intellimouse should not return an ID of 03h until -after- it is sent the above command sequence. If it returns an ID of 03h too soon, it won't detect properly, assuming the article is correct.

The article also tells of another command sequence that is sent after this to determine whether it is a 5 button scrolling mouse or not, and this is when an ID of 04h is to be returned, to indicate that it is a 5 button scrolling mouse. I don't see any reason why this can not be supported by DOSBox-X as well. This feature might be handy when running Windows 9x.

The second command sequence to determine whether it is a 5 button scrolling Intellimouse is as follows:

Set sample rate 200
Set sample rate 200
Set sample rate 80

TheGreatCodeholio wrote on 2012-03-27, 00:42:

I figured my port was out of place on another thread about GUS emulation patching, so I thought I'd start this here. […]
Show full quote

I figured my port was out of place on another thread about GUS emulation patching, so I thought I'd start this here.

This is a branch of DOSBox 0.74 that I have been working on and off for the past 8 months. I've been modifying a lot in the source to make the emulation more accurate, to fix other parts of the emulation, and to widen the kind of hardware DOSBox emulates. I call it "DOSBox-x" for lack of a better name.

I've been developing it alongside a source code library I've been writing that is both a learning tool and a functional library to talk directly to various hardware on a DOS PC. DOSBox is one of my testing grounds for this code, alongside VirtualBox and some ancient Pentium-100 hardware sitting around my house.

Source: http://jon.nerdgrounds.com/dosbox-x-20120326.tar.gz
Windows binary: http://jon.nerdgrounds.com/dosbox-x-win32-bin … ry-20120326.zip

dead link perhaps not updated?

i'm getting troubles on MS-DOS 🙁
1 - the mouse move, but i must move on a different position for select the menu item... and for the button(dialog box), i use use the keys... i don't have control... i'm testing on DSOBox-X and not on game... is there any way for fix these?
2 - how can i clear the audio? i get audio, but i get some noise.. isn't a clean audio.. how can i fix it?

@TheGreatCodeholio: From the article, it seems to be a very simple challenge/response system in detecting what type of Intellimouse you have.

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.

I don't see why this should be all that difficult to implement inside of DOSBox-X. Just remember that once it is detected as a scrolling mouse that it must then use a 4 byte packet instead of a 3 byte packet.

Now that it is getting so common to run Windows 9x inside of DOSBox-X, it would be nice to have access to a 5 button scrolling Intellimouse within Windows 9x.

I believe I've found something in DosBox-X; I don't know what exactly is broken but for the old DOS game "WILDERNESS: A SURVIVAL ADVENTURE"...

if you run it with DOSBOX 0.74; you're able to generate new topographic maps to play on, as well as save topo maps and games.

But if you try running it in DOSBox-X, you get a bad topographic map generation routine; and I think you can't save topo maps or games in progress.

Does LOADFIX help?

Wonder if it uses timer jitter for randomness or some other trick.

BitWrangler wrote on 2021-09-10, 01:27:

Wonder if it uses timer jitter for randomness or some other trick.

It's possible. Some games use the PC speaker timer. Some games when they do that correctly turn that PIT timer on (clock gate) while keeping the PC speaker muted to read that. However I've also seen games that ASSUME the PIT timer clock gate is on, and will fail in that way if it is not.

Try using a DOS program or DEBUG.EXE to write 03h to port 61h. This will make a BEEEEEEEP but will turn on the PIT timer as well.

TheGreatCodeholio wrote on 2021-09-10, 01:22:

Does LOADFIX help?

I tried LOADFIX WILD.EXE and that didn't work

TheGreatCodeholio wrote on 2021-09-10, 01:30:

Try using a DOS program or DEBUG.EXE to write 03h to port 61h. This will make a BEEEEEEEP but will turn on the PIT timer as well.

I got DEBUG.EXE, but I'm trying to figure out how to write 03h to port 61h.

I'm trying this in debug:

-o 61h 03h

but I get an ^ error pointing at the H

EDIT:

I tried

debug.exe
-o 97 3

https://beausanders.org/ascii.htm

03h = 3
61h = 97

and WILD.EXE is still giving the malformed topo map generation