ripsaw8080 wrote on 2022-02-25, 16:14:

https://sourceforge.net/p/dosbox/code-0/4446/
Creative Artist has the same "basement" screen that Creative Writer does. A fix was committed for those awhile ago.

Still though, the DOSBox-X implementation (srcdata&readmask)==readmask seems to work just as well and it better follows S3 documentation.

I noticed the latest commit to DOSBox SVN goes by what is effectively (srcdata ? foreground : background). That happens to work with Windows 3.1 and 95/98 because the S3 driver doesn't do anything with readmask other than set it to the bit width of a pixel anyway, and pattern pixels in video memory are always 0 or 0xFF, but just so you know, S3 documentation seems to say that the foreground is only chosen if ALL bits are 1, and background if any bits are zero, while current SVN behavior is to choose foreground if any bits are 1, and background if all are zero.

https://jon.nerdgrounds.com/jmcs/docs/b ... 3%29%2epdf

I have a question for anyone with a S3 ViRGE PCI card and a Windows 3.1/95/98 install: When you go into Display properties and select video mode, does the dropdown say "Truecolor (24-bit)" or "Truecolor (32-bit)"? Or is "Truecolor (32-bit)" never an option anywhere with ViRGE cards?

S3 ViRGE datasheets I have suggest that the misc control bits that traditionally set the mode become just a RAMDAC mode and that you can switch both primary and secondary "streams processors" to make the primary stream (the framebuffer) either 24-bit or 32-bit. The secondary stream when enabled is the YUYV overlay used when playing video that use MPEG-like compression.

The funny thing is that S3 drivers in general including the ViRGE drivers don't have their own modesetting code. They call INT 10h VESA BIOS extensions to set the video mode and then program the rest of the card themselves, so it's the VESA BIOS that programs CR67 and the streams processor. They do make assumptions about video modes though. ViRGE drivers will use the base VESA modes 0x100-0x11F where it can and they seem to assume that the "truecolor" modes in that range are 24bpp, so you can't just make it 32bpp there, the driver will draw 24bpp anyway and you'll get a garbled screen.

I've managed to add S3 ViRGE XGA acceleration enough that 2D BitBlt and rectangle operations work correctly and display correctly in Windows 3.1 and Windows 98 with machine=svga_s3virge. 8-bit and 16-bit modes were straightforward, but I was surprised to see that Windows ViRGE drivers seem to support only 24-bit RGB (not 32-bit XRGB) and they seem to expect the XGA acceleration to do that same. I haven't added line and poly support yet, so lines and that line drawing screensaver in Windows won't work and you won't be able to draw lines or polygons in Windows 3.1 Paintbrush.

The ViRGE chipset is when S3 changed the XGA registers around which is why the existing XGA acceleration for previous S3 cards did not work with Windows and ViRGE drivers prior to this recent work in DOSBox-X.

The s3virge.inf shows this in a S3 Virge Windows driver set, but the other Virge variants are similar (the following may possibly constrain the Windows color depth options):

HKR,"MODES\4\640,480",drv,,vga.drv HKR,"MODES\4\640,480",vdd,,*vdd HKR,"MODES\4\800,600",drv,,vga.drv HKR,"MODES\4\800,600",vdd, […]
Show full quote

HKR,"MODES\4\640,480",drv,,vga.drv
HKR,"MODES\4\640,480",vdd,,*vdd
HKR,"MODES\4\800,600",drv,,vga.drv
HKR,"MODES\4\800,600",vdd,,*vdd
HKR,"MODES\8\640,480" ,,,"60,72,75,85"
HKR,"MODES\8\800,600" ,,,"56,60,72,75,85"
HKR,"MODES\8\1024,768" ,,,"43,60,70,75,85"
HKR,"MODES\8\1152,864",,,"60"
HKR,"MODES\8\1280,1024",,,"43,60,75"
HKR,"MODES\8\1600,1200",,,"48"
HKR,"MODES\16\640,480",,,"60,72,75,85"
HKR,"MODES\16\800,600",,,"56,60,72,75,85"
HKR,"MODES\16\1024,768",,,"43,60,70,75,85"
HKR,"MODES\16\1280,1024",,,"43"
HKR,"MODES\24\640,480" ,,,"60,72,75,85"
HKR,"MODES\24\800,600",,,"56,60,72,75,85"
HKR,"MODES\24\1024,768",,,"43"

songo wrote on 2022-02-19, 21:13:

I cannot run 3dfx-patched version of Blood 1 on DosBox-X.

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

I have the same problem. Other games work but Blood always says that it cannot load DLL.

Set ems=false in the DOSBox command prompt (or in the DOSBox menu).

I have "inherited" a DOS application that uses direct access (using inp/outp) to the parallel port registers for reading and writing to the port.

I am trying to run this application on my Fedora Linux system using DOSBox-X. I have no way to recompile the DOS application, I am supplied with a DOS executable.

My system has a PCI board providing the parallel port. This means that the address of the port register are different from the "standard" 0x3bc, 0x378, etc. The proper address can be obtained via 'lspci -v' on the Linux system. The DOS application has a configuration capability that lets me set the proper address.

I have written and tested a simple C program (non-DOS) that uses inp/outp to assure that the PCI parallel port can be accessed. What I have run into is that the Linux system first requires a call to ioperm in order to access the port, and the application must be running in root for proper authority.

How do I execute this DOS program under DOSBox-X given the Linux constraints I mentioned?

Thanks for the help.

-----------------
DOSBox-X v0.03.20
Fedora 33 Linux
System is Dell desktop
KDE 5.20.5

PCI Parallel board: StarTech PEX1P2

First of all, my apologies if this is the wrong trhead to speak of this... but it is the first one I've found regarding this build of DOSBox using Google.

I'd like to request the "amstrad" machine mode to be updated / revised. I think it's an old patch and it mostly does the work it was designed to, but I've been collecting info on the PC1512 exclusive graphic mode and found that some games have glitches.

For the thread where this info is being posted, check out PC1512 graphics

As for the glitches, two games (by now) are the main offenders, "Manoir de Mortevielle" and "Top Gun".

In the first case, thew tile screen shows parts of the next screen. According to some people, the borders surrounding the logo should be completely black.

"Top Gun" has a similar issue. The Ocean logo, present in the config screen, shows at the bottom of the play screen, and details of the cockpit and / or the crosshairs seem to be missing.

@Neville. It may be better to open an issue on the DOSBox-X github page.

I suspect the box around the mouse cursor in Maupiti Island may also be related to this.

Damn. I've never opened an issue on any GitHub project. Could you show me the ropes?

It's pretty easy. You need to have a github account, and then you go to the https://github.com/joncampbell123/dosbox-x/issues tab and create a new issue. You can drag-and-drop images into the text box to add them to explain things.

Certainly it's easier than I expected. I just posted mentioning the issue.

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

I'm posting this here because while working on S3 and S3 ViRGE emulation I found something about the Trio64 emulation that SVN might be interested in.

In the command word to draw a line, there is a bit that controls whether the line includes or omits the last pixel. The code as it was before my changes did not pay attention to that bit, which meant that the line was always drawn from x1,y1 to x2,y2 inclusive. The thing is, Windows 3.1 S3 drivers rely on that bit to draw continuous segments like polygons and circles as a series of short line segments, and by ignoring the "skip last pixel" bit, the line segments overlap by one pixel. This is especially noticeable in programs like Microsoft Word where when dragging a shape, it's outline is drawn with a XOR against the screen as you move since XORing a pixel twice restores the original value. I think it may also visually affect the "Curves and Colors" screensaver somewhat in Windows 98 as well.

According to Windows 3.1 driver behavior, there is an undocumented feature where the XGA rectangle command also obeys the "skip last pixel" bit, in fact poly lines in Windows 3.1 will look wrong if not handled there as well. S3 documentation says nothing about that.

I came across this while finishing the XGA line draw support for S3 ViRGE emulation. S3 ViRGE changed the accelerated line draw from a Bresenham type algorithm to a simple Y-major X delta fixed point DDA with 1 sign bit, 11 bits for the whole part and 20 bits for the fractional part (run over rise), so I had to puzzle that out to make it work. I think the reason they did that is so that 2D acceleration can have a 3D acceleration variant that uses an additional register for Z, and that kind of math can support 3D graphics as well as ViRGE cards have 3D acceleration. No 3D acceleration is implemented yet in DOSBox-X.

Is DOSBox SVN interested in a patch to fix XGA line drawing?

Speaking of old SVGA emulation, Anyone know how to fix the yellow tinting screen when using SDL2 build of DOSBox-X? I get that whenever I want to use more than 256 colors in Windows.

Good job guys. Dosbox-x keeps becoming better and better!
I'd like to see Ps1 audiocard emulation returning to work someday...

Bruninho wrote on 2022-04-08, 12:36:

Speaking of old SVGA emulation, Anyone know how to fix the yellow tinting screen when using SDL2 build of DOSBox-X? I get that whenever I want to use more than 256 colors in Windows.

Run DOSBox-X with --debug or specify debug level logging. It should tell you what SDL/SDL2 returned when it asked for the R/G/B bitmasks.

16/256-color modes are well designed to match those bitmasks but I'm not sure the 16bpp/24bpp/32bpp modes are designed for anything but ARGB format, and that might be the problem.

On Mac OS X the worst case scenario is SDL1 and the traditional Cocoa API which likes an unusual BGRA format (blue in the upper 8 bits, alpha in the lower 8 bits), which is the opposite of ARGB (alpha in the upper 8 bits, blue in the lower 8 bits) and probably a holdover from the big-Endian era when Mac OS X ran on PowerPC. So the VGA line rendering code needs "byte swap" versions of >256-color modes, which might be easy to add.

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

- PS/2 AUX port emulation. This enables DOS programs and OSes to work that don't use INT 33h and communicate directly with the PS/2 mouse connected to the keyboard controllers "AUX" port. This code is wired in so that INT 33h emulation is enabled by default, but shut down the instant the "reset" command is sent to AUX.

Is the SVN repository with this change from march 2012 still available anywhere? GitHub repository does not seem to reach that far (March 2012).

I’m asking because I’m developing a mouse overhaul patch for the DOSBox Staging (https://github.com/feralchild64/dosbox-stagin … mouse-updates-2 - wheel support using CtMouse API, up to 5 buttons, basic VMware mouse protocol support, Mouse Systems Mouse emulation - I know some of these changes were already integrated into to DOSBox-X) and I got stuck with Windows 3.11 which makes the emulated system to stop reacting on IRQ1 keyboard events once I implemented PS/2 mouse register-level access. I must have missed some important part of the implementation, but I have no idea which one.

FeralChild64 wrote on 2022-04-15, 15:17:

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

- PS/2 AUX port emulation. This enables DOS programs and OSes to work that don't use INT 33h and communicate directly with the PS/2 mouse connected to the keyboard controllers "AUX" port. This code is wired in so that INT 33h emulation is enabled by default, but shut down the instant the "reset" command is sent to AUX.

Is the SVN repository with this change from march 2012 still available anywhere? GitHub repository does not seem to reach that far (March 2012).

I’m asking because I’m developing a mouse overhaul patch for the DOSBox Staging (https://github.com/feralchild64/dosbox-stagin … mouse-updates-2 - wheel support using CtMouse API, up to 5 buttons, basic VMware mouse protocol support, Mouse Systems Mouse emulation - I know some of these changes were already integrated into to DOSBox-X) and I got stuck with Windows 3.11 which makes the emulated system to stop reacting on IRQ1 keyboard events once I implemented PS/2 mouse register-level access. I must have missed some important part of the implementation, but I have no idea which one.

Are you doing I/O access directly or are you doing the I/O out as IN/OUT instructions where Windows 3.1 can see it?

It helps to imagine Windows 3.1 as MS-DOS like code (talking directly to hardware and DOS/BIOS interrupts) running under a 32-bit kernel that traps and virtualizes I/O and interrupts so everyone gets along. That includes DOS and BIOS interrupts and IRQs. Windows 3.1 has a driver to virtualize the PS/2 mouse and keyboard. If you're doing I/O directly, Windows 3.1 can't trap your I/O and virtualize it. 386 Enhanced mode is heavily dependent on virtual 8086 mode.

In case you think I'm making things up, I suggest downloading the Windows 3.1 DDK. Drivers often have two parts: a "286" driver that runs in userspace and generally just talks directly to things like real mode code would, and a "386" driver that traps and virtualizes things and does Win386 work for the "286" driver as well as any DOS VM you start in Windows.

To explain another change made to DOSBox-X, Windows 95 not only uses virtualization, but depends on it in the IDE driver to auto-detect which IDE device your BIOS accesses for the boot drive by trapping I/O ports and making INT 13h reads against the boot drive. If your INT 13h implementation doesn't at least poke at IDE ports and pretend it's doing a PIO transfer, where Windows 95 can trap it, then the IDE driver gives up and your drive C: will always be in "MS-DOS compatibility mode" no matter how good your IDE emulation is.

You can copy or adapt mouse emulation code from DOSBox-X, it's perfectly fine with me. A recent pull request also added VMWare mouse integration. You might also consider the serial mouse emulation so that Windows 1.0 (which was made before PS/2 mice existed) can work with your staging branch.

For wheel mouse support you'll need to recognize a specific sequence of commands that enable or disable the wheel. When enabled, the mouse packet becomes 4 bytes. It's a sequence of Report Rate commands. Microsoft even documented it once: http://hackipedia.org/browse.cgi/Comput ... oft%2ehtml

DOSBox-X PS/2 mouse and keyboard emulation comes from some code I wrote for the DOSLIB project concerning the 8042 controller which was developed against real hardware. This might be a good reference: https://github.com/joncampbell123/doslib/tree/master/hw/8042

The only known problem with DOSBox-X is an unresolved issue where the PS/2 mouse emulation is not always able to keep interrupts working under Windows 3.1 if you start a DOS VM in any way, which apparently includes any compile or build steps in Microsoft Visual C++.

Thanks for the DDK hint, indeed I might find a clue here.

> Are you doing I/O access directly or are you doing the I/O out as IN/OUT instructions where Windows 3.1 can see it?

I don’t understand - I have extended port 0x60 and 0x64 emulation.

I have already stolen your serial mouse emulation, and extended it a lot. Added support for Logitech 3-button protocol, Microsoft wheel protocol, and Mouse Systems 3-button protocol. It can even autodetect whether guest code expects Microsoft-style protocol or Mouse Systems protocol and autoswitch between them. By defaults it also boosts sampling rate for smooth cursor and wheel. Windows 1.0 works.

Windows 95 works correctly. Moreover, if you install IntelliPoint 3.0 software, it will detect IntelliMouse Explorer mouse - all the 5 buttons work, wheel works too.
As for the DOS itself - tested Microsoft mouse driver 8.20, Mouse Systems driver 8.0, CtMouse driver 2.0 (uses PS/2 registers), CtMouse 2.1 (uses BIOS), CtMouse forced to use serial protocol - all work.

The only problem left is broken keyboard with certain 16-bit Windows versions. And I haven’t tested DOS apps from within Windows yet.

FeralChild64 wrote on 2022-04-15, 18:02:

Thanks for the DDK hint, indeed I might find a clue here.

> Are you doing I/O access directly or are you doing the I/O out as IN/OUT instructions where Windows 3.1 can see it?

I don’t understand - I have extended port 0x60 and 0x64 emulation.

I mean does the interrupt handler use the IN/OUT instructions to talk to the keyboard and mouse? There are some functions in cpu.cpp that issue I/O visible to the guest by jumping to a region in the BIOS with an IN or OUT instruction if you're handling the interrupt from native C++ code. This is so that the guest's General Protection Fault handler can see the I/O instruction and act on it as intended. INT 13h emulation will use them if the BIOS drive is attached to the IDE emulation code and it detects the guest is calling INT 13h from virtual 8086 mode.

Do you mind if I incorporate your serial mouse improvements back into DOSBox-X? In DOSBox-X tradition of course you would specify Logitech/Mouseman/Microsoft manually in dosbox.conf instead of an autodetect from guest behavior. Real hardware behaves like one of those mice only and that's how DOSBox-X intends to emulate things.

Of course, feel free to take the modified serialmouse.* back into DOSBox-X, it’s open source 😀 Just keep in mind that the interface to the rest of the mouse subsystem has changed - bitfield for buttons is now different (for sake of uniformity with the rest of the mouse emulation), there is no Mouse_AutoLock call (Staging does not use it), and list of registered handlers is kept externally in mouse_serial.cpp. It can’t autodetect between Microsoft/Logitech/wheel, unfortunately - it can only detect Mouse Systems vs previously mentioned, as Mouse Systems protocol needs different port settings (8N1 for Mouse Systems vs 7N1 for Microsoft/Logitech/wheel). And which protocol it should use, whether it should do autodetection or not - these are already configurable.

I’m not calling port reading/writing from updated INT74 or INT13 handler.