TheGreatCodeholio wrote:

According to the PS/2 and VGA graphics book I have (the only one I have that even documents some of the MCGA registers!) the register set is more CGA-like than VGA. It has the VGA-like DAC registers (if fractint source code is correct), but also has CGA compatible CRTC registers with additional registers specific to the MCGA, and it has a "mode" register that is like CGA.

That is interesting. I wonder what it would make of 8088 MPH then, since it does a lot of CGA-specific CRTC/mode programming. It doesn't work on EGA/VGA at all of course.

TheGreatCodeholio wrote:

The description implies that it only has 64KB of video RAM, and that video memory is mapped to B8000-BFFFF like CGA with B0000-B7FFF holding the character generator RAM in text modes (though in a very strange format).

I'm pretty sure it indeed has only 64k (enough for mode 13h), but also I'm pretty sure that it maps the video memory to A0000 in mode 13h, so that it is fully compatible there (as long as you stick to vanilla mode 13h of course, you can't do mode X hacks, scrolling etc).

For some cpu testing that looks to be a little less involved to get going: test386.asm CPU tester

Danfun64 wrote:

My first question wasn't answered.

Danfun64 wrote:

Is it possible to get either the timidity or mt32 mididevice to work with the windows builds from the Dosbox-X Releases github page?

Current Windows builds do not compile MT32 emulation, but I see no reason not to try.

What about timidity (and what does it mean, anyways? Does it mean like connecting to a timidity server, or does it mean the GUS patch only timidity bundled with SDL(2)_Mixer)?

Danfun64 wrote:

What about timidity (and what does it mean, anyways? Does it mean like connecting to a timidity server, or does it mean the GUS patch only timidity bundled with SDL(2)_Mixer)?

Not sure, I'm not familiar with Timidity.

Apparently Timidity is a MIDI synthesizer.

http://timidity.sourceforge.net/

The problem with CTMOUSE and serial mouse emulation has been fixed.

When int33=false, the mouse mickey count is not initialized and not large enough to permit any motion to be sent to serial mouse emulation (though buttons worked).

https://github.com/joncampbell123/dosbox-x/issues/865

Thanks!

In contrast to the ps2 mouse, the serial mouse inherits a large degree of mouse acceleration, presumed from the host OS. Is there a workaround for this effect?

hail-to-the-ryzen wrote:

Thanks!

In contrast to the ps2 mouse, the serial mouse inherits a large degree of mouse acceleration, presumed from the host OS. Is there a workaround for this effect?

No, not without a million hacks. Are you sure the host OS is doing it?

It just seemed like the first possible cause to test. Does this happen in linux?

I didn't find a mouse movement scaling factor in the serial mouse code. I also didn't measure the sampling rate of mouse input.

The serial mouse emulation has high mouse acceleration by default and also does not register small movements of the mouse. This fixes the latter:

1--- serialmouse-Orig.cpp
2+++ serialmouse.cpp
3@@ -45,8 +45,8 @@ void CSerialMouse::start_packet() {
4 
5 	/* FIX: Default mapping deltas as-is in previous versions of this code
6 	 *      resulted in serial mouse input that was way too sensitive */
7-	mouse_delta_x /= 4;
8-	mouse_delta_y /= 4;
9+	mouse_delta_x /= 1;
10+	mouse_delta_y /= 1;
11 
12 	if (mouse_delta_x < -128) mouse_delta_x = -128;
13 	else if (mouse_delta_x > 127) mouse_delta_x = 127;

Also, reduced the high mouse acceleration in my configuration by running ctmouse at a non-default value:
ctmouse /s1 /r11

I didn't test in the Windows 95 guest OS yet, but presumably that same setting is adjustable in the mouse settings applet. It is also possible to modify the mouse.cpp code with a lower sensitivity value and test whether the mouse response is flatter.

Would it help if the delta scaling were configurable?

If there are other known scaling values that allow detection of small mouse movements and improve upon the above suggested value.

Also, the ctmouse driver does not seem to have a setting to remove mouse acceleration while there is at least one commercial dos mouse driver that does. Perhaps a note of this could be added to the dosbox-x configuration file. Another alternative is to edit the assembly code of ctmouse to create a version without mouse acceleration.

The asm code is here:
https://github.com/joyent/sdcboot/blob/master … use/ctmouse.asm

And a region of code that applies the sensitivity value for mouse movement:
shr ax,2 ; =sensitivity*min(12,abs(mickeys))/4

Built an updated ctmouse in dosbox-x with a correction so that the mouse response is flatter and compatible with the new delta scaling value in serialmouse.cpp.

Source code based on Japheth's adaptation of ctmouse v21b4 for building with jwasmd and includes com2exe program:
https://www.ibiblio.org/pub/micro/pc-stuff/fr … new-ctm21b4.zip

Version of jwasmd that is compatible with ctmouse source code:
https://www.ibiblio.org/pub/micro/pc-stuff/fr … jwasm.2_11.html

Here are lines to build english language version of ctmouse.exe:

1jwasmd -nologo -c -bin -D?LANG=ctm-en ctmouse.asm
2com2exe -s512 ctmouse.bin ctmouse.exe

To flatten the mouse response, modify ctmouse.asm:

1diff -rupN ctmouse-Orig//CTMOUSE.ASM ctmouse/CTMOUSE.ASM
2--- ctmouse-Orig//CTMOUSE.ASM
3+++ ctmouse/CTMOUSE.ASM
4@@ -1020,7 +1020,7 @@ else
5 ;	 end_
6 @@up2ae:
7 		mul	dx
8-		shr	ax,2		; =sensitivity*min(12,abs(mickeys))/4
9+		shr	ax,3		; =sensitivity*min(12,abs(mickeys))/8
10 endif
11 		imul	si		; DX:AX=mickeys*newsensitivity
12 ;	end_

MCGA emulation is basically done.

The way it's implemented is based on poking at actual PS/2 MCGA hardware, though there's probably still some inaccurate parts of the emulation.

But the emulator does resemble the video seen on an actual MCGA display, including the extra-thick cursor in text modes due to the hardware "upscaling" from 200-line CGA to 400-line VGA from the base CGA hardware.

You should be able to try it from the latest commit using machine=mcga.

When starting Windows 95 (ems=false), the EMS region appears mapped as ROM since there are logged messages like this:
CPU:Write 0 to rom at e10a0
CPU:Write ffff to rom at e10a2

The code does map the EMS region as ROM in this example. Is this region actually EMS? Is it expected that this region is ROM?

By default, DOSBox-X should unmap the EMS page frame, UMB blocks, and "private area" from the upper memory area when booting a guest OS.

There are options to keep them there, of course, which are off.

EDIT: Think about it, what would Windows 95 do with DOSBox's EMS page frame?

Is it possible for Windows 95 to allocate memory in that region?

hail-to-the-ryzen wrote:

Is it possible for Windows 95 to allocate memory in that region?

No, not without special drivers.

Remember that on real hardware, A0000-EFFFF is usually adapter ROM/RAM and the BIOS.

The Windows 95 version of EMM386.EXE however can use virtual 8086 mode to provide it's own EMS page frame independent of DOSBox/DOSBox-X.

Thank you. I wondered why the log shows writes to that region then? If in fact that is reported correctly as EMS area.