hail-to-the-ryzen wrote:

Could that option be removed from the configuration list? Also, is it ever necessary to set "allow dma address decrement" to false?

The floppy option, perhaps.

"allow dma address decrement" doesn't need to be changed, but it's there for retro-development as a "what if" for your code. As in, "what if the hardware omitted the rarely used backwards DMA (decrement) mode?"

Currently the only case I know of where backwards DMA is unsupported are PCI sound cards combined with a TSR that uses it to emulate Sound Blaster. Such as one test system I have set up with a Sound Blaster Live! card and the Creative TSR driver to test DOSLIB against SB16 emulation. I've found the TSR does an excellent job of SB16 emulation, a "meh" job at OPL3 emulation, but it doesn't support Direct DAC commands, nor does it support the decrement mode of DMA.

That is interesting. I also have a question about dsp write busy delay, busy cycle rate, and busy cycle duty. Are those solely for demo playback or are they expected to have an effect in DOS games with use of the older soundblaster emulation types?

hail-to-the-ryzen wrote:

That is interesting. I also have a question about dsp write busy delay, busy cycle rate, and busy cycle duty. Are those solely for demo playback or are they expected to have an effect in DOS games with use of the older soundblaster emulation types?

They're tunable options that you can use to test your retro development, as well as options you can play with if you find an old demo or game that's too picky about the Sound Blaster emulation.

Having these options to play with can help you better understand what the game or demo programmer did wrong.

Thank you for the helpful reply. It seems that the configuration file refers to the SB16 type for those parameters, but there were further updates to dosbox-x that extend the improvements to the other SB types.

Okay, here's a question about the Programmable Interrupt Controller:

Interrupts are marked "in service" until acknowledged, however there's no mention if the cascade interrupt follows exactly the same logic.

I found a PC-98 game, "Blackbird" who's FM interrupt handler acknowledges the FM interrupt directly on the slave PIC (IRQ 12), but then checks the slave to see if any IRQs are pending and does NOT acknowledge the cascade interrupt if the request bits are nonzero.

In DOSBox-X, this causes the music to "hang" though the game continues until it hits a point where it waits for the music to stop, where it hangs indefinitely. It doesn't hang immediately, it hangs once another IRQ is pending at that check point. Moving the mouse will trigger the issue, as well some point in the FM music when the FM interrupt happens again between acknowledging the FM interrupt and checking for pending IRQs.

More details here:

https://github.com/joncampbell123/dosbox-x/is … mment-419350023

Hacking the PIC emulation never to mark the cascade IRQ as in service "fixes" the game but I'm not certain if that's what actual hardware does.

False alarm, it's a bug in the interrupt handler.

It wants to poll in-service interrupts (ISR) from the slave PIC, but it only programs the master PIC to read that. The slave PIC is not in the right mode, so it reads the interrupt request register instead and mis-interprets incoming interrupts (IRR) as in-service.

But you can poke 0x0B into OCW3 manually before the game to fix it.

Are the other mouse emulation types resistant to this issue?

Also, use of GetDeviceCaps() for screen DPI is apparently not a simple solution:

"the values returned by GetDeviceCaps are returned by the
*device driver*, not by Windows itself. Device drivers are written by
hardware manufacturers." (source)

https://stackoverflow.com/questions/7003316/w … ll-shows-96-dpi

https://social.msdn.microsoft.com/Forums/wind … rtdevicesnative

hail-to-the-ryzen wrote:

Are the other mouse emulation types resistant to this issue?

It's not a mouse emulation issue specifically, it's a problem with the interrupt service routines on PC-98 games.

Some follow an understandable convention where they read the ISR register of the slave, and skip acknowledging the cascade interrupt if other interrupts are in service.

Others ack only the slave PIC and not the cascade interrupt on the master.

hail-to-the-ryzen wrote:

Also, use of GetDeviceCaps() for screen DPI is apparently not a simple solution: […]
Show full quote

Also, use of GetDeviceCaps() for screen DPI is apparently not a simple solution:

"the values returned by GetDeviceCaps are returned by the
*device driver*, not by Windows itself. Device drivers are written by
hardware manufacturers." (source)

https://stackoverflow.com/questions/7003316/w … ll-shows-96-dpi

https://social.msdn.microsoft.com/Forums/wind … rtdevicesnative

Well SOMETHING in Windows has to report screen size.
Or else, I need to find what API function returns the user's DPI setting.

I may need a visual logic table for how pc98 games mishandle the interrupts. 😀

On finding the DPI value, where in SDL is the window sized for the fullscreen case?

hail-to-the-ryzen wrote:

I may need a visual logic table for how pc98 games mishandle the interrupts. 😀

On finding the DPI value, where in SDL is the window sized for the fullscreen case?

One common failure mode is that the interrupt handler acknowledges only the slave PIC, not the master, so the master PIC fails to fire any more IRQs from the slave as the cascade interrupt is still "in service".

I have notes here: https://github.com/joncampbell123/dosbox-x/is … mment-419553365

And here: https://github.com/joncampbell123/dosbox-x/is … mment-419333407

Thanks for the references.

For the large DPI issue, it should be possible to rescale the fullscreen window so that it fits the monitor screen. Here are hints:
https://stackoverflow.com/questions/7003316/w … -96-dpi/7003538
https://social.msdn.microsoft.com/Forums/vstu … forum=vbgeneral
http://forums.codeguru.com/showthread.php?521 … ws-7-wrong-size
http://www.rensselaer.org/dept/cis/software/g … nclude/wingdi.h

Referencing their suggestion:

1public static int GetSystemDpi()
2{
3    using (Graphics screen = Graphics.FromHwnd(IntPtr.Zero))
4    {
5        IntPtr hdc = screen.GetHdc();
6
7        int virtualWidth = GetDeviceCaps(hdc, DeviceCaps.HORZRES);
8        int physicalWidth = GetDeviceCaps(hdc, DeviceCaps.DESKTOPHORZRES);
9        screen.ReleaseHdc(hdc);
10
11        return (int)(96f * physicalWidth / virtualWidth);
12    }
13}
14
15private enum DeviceCaps
16{
17    /// Logical pixels inch in X
18    LOGPIXELSX = 88,
19    /// Horizontal width in pixels
20    HORZRES = 8,
21    /// Horizontal width of entire desktop in pixels
22    DESKTOPHORZRES = 118
23}
24[DllImport("gdi32.dll")]
25private static extern int GetDeviceCaps(IntPtr hdc, DeviceCaps nIndex);

These are the parameters:
DeviceCaps.DESKTOPHORZRES (physical width of desktop in pixels)
DeviceCaps.DESKTOPVERTRES
DeviceCaps.HORZRES
DeviceCaps.VERTRES

I didn't verify the source's finding that LOGPIXELSX typically returns 96 DPI even though the DPI is set higher.

There is another check possible in the registry for EDID settings. So it may be possible to run multiple checks for the DPI value in the code and revert to no scaling if the results contradict. For video drivers that do not report correct values, then those could be flagged in the code given the GetDeviceCaps identifies the video driver by version.

My understanding is that Windows might cap the DPI at 96 if your program is not "DPI aware".

DOSBox-X has code to tell Windows otherwise (that it is DPI aware), so hopefully the reported DPI is more accurate.

Is that DPI code compatible with older Windows versions?

hail-to-the-ryzen wrote:

Is that DPI code compatible with older Windows versions?

It uses GetProcAddress() to call the entry point if it exists, ignores it otherwise.

So far, it's able to tell Windows 10 not to DPI upscale it on my system, while still allowing the executable to run on Windows XP without issues.

That's a good method. Here is a table of the myriad of DPI functions per OS version:
https://docs.microsoft.com/en-us/windows/desk … ment-on-windows

It is reasonable to use the LOGPIXELSX method to report the scaling, but perhaps log the other parameters for diagnosing any other issues. And if the user has these logged values as hints, then they could always manually set a fullscreen resolution in the configuration file.

SDL2 must be effective at handling DPI:
https://discourse.libsdl.org/t/wip-windows-hi … i-support/22446

Software that searches for LASTDRIVE beyond the drive letter A may fail. Here is a workaround to increase it:

1diff -rupN dosbox-Orig//src/dos/dos_classes.cpp dosbox/src/dos/dos_classes.cpp
2--- dosbox-Orig//src/dos/dos_classes.cpp
3+++ dosbox/src/dos/dos_classes.cpp
4@@ -65,7 +65,7 @@ void DOS_InfoBlock::SetLocation(Bit16u s
5 	sSave(sDIB,protFCBs,(Bit16u)0);
6 	sSave(sDIB,specialCodeSeg,(Bit16u)0);
7 	sSave(sDIB,joindedDrives,(Bit8u)0);
8-	sSave(sDIB,lastdrive,(Bit8u)0x01);//increase this if you add drives to cds-chain
9+	sSave(sDIB,lastdrive,(Bit8u)0x05);//increase this if you add drives to cds-chain
10 
11 	sSave(sDIB,diskInfoBuffer,RealMake(segment,offsetof(sDIB,diskBufferHeadPt)));
12 	sSave(sDIB,setverPtr,(Bit32u)0);

Let me put things in perspective for the post to follow by saying that I am collaborating with Serge from Serdaco to test some of this cool gadgets which he has been pumping out recently. In particular the parallel port sound devices that he is making: CVX )Covox replica), OPL3LPT (OPL3 on parallel port) and S2P (GM synth on parallel port). What I am contributing with is trying to adapt them to work on modern computers without parallel ports. In particular trying to attach them to USB via a USB/parallel converter. The converter is based on usb2lpt https://www-user.tu-chemnitz.de/~heha/basteln … PT/index.en.htm in particular the high-speed version based on a Cypress development board. Basically the chip on the board is flashed with firmware (open source too, though it's in 8051 assembler https://www-user.tu-chemnitz.de/~heha/viewzip … p/src/firmware/ ) and when connected to a computer it presents itself like a LPT port. The driver is configurable to emulate LPT1 or LPT2.

Where does Dosbox-X come into the picture? I am trying to use it to make these devices work, and become usable as sound output devices from inside the emulated DOS. I chose Dosbox-X because it includes LPT passthrough (parallel1=reallpt) so I'm hoping to achieve the goal of the software (games etc) running inside it to be able to pass data through the virtual LPT to the emulated LPT on USB on the host computer and drive the sound devices.

So far it's not working. I have configured the USB/LPT emulator as LPT1 (see screenshot below), then configured Dosbox-X with the above parallel1=reallpt , enabled logging and I see in the log file "Parallel1: BASE 378h
LoadLibrary Failed" I'm not sure if the "LoadLibrary Failed" refers to the LPT emulation as it's on the next line in the log file. I have attached a Covox to the emulated parallel port, and am trying to run Crystal Dreams demo on LPT1. It doesn't run. See second screenshot. It doesn't generate any entries in the log file.

Can this be done?