Druid: Dæmons of the Mind graphical glitch (segment limit related?)

[emxd]

Describe the bug

Hello,

I was wondering if anything could be done about graphical glitches in Druid: Dæmons of the Mind. According to the thread on vogons (https://www.vogons.org/viewtopic.php?t=32153), these are due to some cpu emulation simplifications vis-a-vis segment limits. I suppose the first thing to determine would be if this is actually the case :).

I tried it on dosbox-svn, dosbox-staging and dosbox-x and all 3 have this problem. Additionally, in dosbox-x I had segment limits config turned on and tried different cpus (386 and higher), but I still got the black horizontal stripes. On Win98 (pcem), the game had no graphical glitches, so this does seem to be related to dosbox in general. I opted to post here, since dosbox-x is the most feature rich dosbox fork.

Steps to reproduce the behaviour

nothing specific required, just start the game.

Expected behavior

No response

What operating system(s) this bug have occurred on?

Windows 11 22H2

What version(s) of DOSBox-X have this bug?

dosbox-x-vsbuild-win64-20230501152329.zip SDL2

Used configuration

No response

Output log

No response

Additional information

No response

Have you checked that no similar bug report(s) exist?

• I have searched and didn't find any similar bug report.

Code of Conduct & Contributing Guidelines

• I agree to follow the code of conduct and the contributing guidelines.

[joncampbell123]

DOSBox-X does emulate segment limits but only for specific MOV instructions used by Windows and a known Demoscene entry that uses the same trick. Perhaps this game is using a different instruction and expecting segment limit exceptions.

[joncampbell123]

I'm looking at this game and it's routine to draw on the screen now... as far as I can tell it's using the same exact values for DS and ES and the segment limit is 0xFFFFFFFF (the full 4GB) so it's not a segment limit issue.

The black lines appear to be an artifact of the row by row copy routine, which copies row by row until the copy writes at or beyond 0xB0000. Note that because of this logic, the last scanline copy might well write to something like 0xAFFF0 to 0xB0170, or to put it another way, up to 639 bytes past the end of the 64KB A0000-AFFFFh region.

I think this game is like another test case from the demoscene which assumes that if you bank switch a 64KB region into A0000-AFFFFh that you can write past AFFFFh into the next 64KB bank without having to stop and break up the scanline.

Apparently this was a common enough "bug" in SVGA cards that it happens to work. Since I still have old DOS machines lying around it would not hurt to update DOSLIB's VESA test code to see on which SVGA chipsets this works on. Perhaps it happens to work because SVGA cards just take the memory I/O to 0xA0000-0xBFFFF, mask off the low 17 bits and then add the base video memory address you set by bank switching.

Having come across this kind of code before, the black lines can be fixed by adding to your dosbox.conf:

[dosbox]
vesa map non-lfb modes to 128kb region=true

I think this bank-switched VESA BIOS fix might be general enough that DOSBox Staging and DOSBox SVN could probably incorporate it easily enough. But no, it doesn't involve segment limits or page fault tricks.

[joncampbell123]

Regarding the above, I have an old Pentium laptop with a Cirrus chipset where the bank switching granularity is 4KB rather than 64KB (yes, not every SVGA chipset uses 64KB granularity!), and the only way that could work is if the chipset indeed just mapped the address to (physaddr & 0x1FFFF) + bank_switch_base.

[emxd]

Great, it works correctly. I knew that this is the place to ask for help. Thanks!