Viper (1998) only runs in vanilla dosbox 0.63

[Python-Exoproject]

Are you using the latest Dosbox-Staging Version?

• I have checked releases and am using the latest release.

Different version than latest?

81.1

What Operating System are you using?

Windows 11

If Other OS, please describe

No response

Relevant hardware info

No response

Have you checked that no other similar issue already exists?

• I have searched and not found similar issues.

A clear and concise description of what the bug is.

Similar to #3543 this game will only work on an older version of vanilla dosbox, in this case 0.63. Any other fork or even later vanilla dosbox builds will freeze. Something obviously changed between vanilla 0.63 and later releases which was also inherited by Staging.

Steps to reproduce the behaviour.

Explain how to reproduce

1. Play the game in 0.63 for it to work (I used copy from eXoDOS), any other version or fork freezes during the game loading

Download URL of affected game or software

No response

Your configuration

No response

Provide a Log

No response

Code of Conduct & Contributing Guidelines

• Yes, I agree.

[MasterO2]

@Python-Exoproject, I know this sounds like a stupid question, but have you tried different values for cputype in dosbox-staging.conf, other than auto?

The available values are: 386, 386_slow, 486_slow, pentium_slow, 386_prefetch

[Python-Exoproject]

Thank you for the suggestions but no, none of those settings changed anything. I also tried with sbtype=none, different cycles, and no ems\xms\umb

[jester-xbmc]

switching off the mouse driver (dos_mouse_driver=false) seems to fix the freeze, although the graphics seems a bit messed up
(running main with default config)

[johnnovak]

It was done by demo coders; no wonder it's flaky 😎

Viper was released at the Wired 1998 demoparty in Belgium, where it won 3rd place in the 100KB PC Games compo.

https://www.mobygames.com/game/72308/viper/

[MasterO2]

Now added to Game Issues:

https://github.com/dosbox-staging/dosbox-staging/wiki/Game-issues#viper-1998

[johnnovak]

Now added to Game Issues:

https://github.com/dosbox-staging/dosbox-staging/wiki/Game-issues#viper-1998

Thanks @MasterO2. Just some tips and recommendations on how to keep the wiki succinct because that page is already waaaaaaay too huge.

1. There's no need to explain for every single game how to change config files, what editors to use, etc. Just state the minimum info:

   Disable the built-in DOS mouse driver by setting dos_mouse_driver to off in the [mouse] section.

   That's all we need for this game.

2. If you want, you can include a general section at the top on how to edit config files, etc. But better to link to our Getting Started guide that explains all this stuff.

3. Info like this will become out of date very quickly; we should never use line numbers in these tips:

   Scroll to line 521 and set dos_mouse_driver = false.

So yeah, that page could use a big cleanup, there's tons of redundant info everywhere. I think it could be made 30-50% smaller easily.

[Python-Exoproject]

switching off the mouse driver (dos_mouse_driver=false) seems to fix the freeze, although the graphics seems a bit messed up (running main with default config)

Thanks, that does indeed get past the freeze but like you said the graphics are a bit messed up. Ive gone back and tested against the other forks and vanilla 0.74 and they are all the same, mouse driver off gets past the freeze but they look like the below. So we are still in a situation where only 0.63 runs this game in a playable state

[FeralChild64]

I have tried to start the inside DOSBox Staging using various different mouse drivers The game is very picky - it started with:

• Microsoft mouse driver 7.04 or 8.20
• Mouse Systems mouse driver 8.00
• A4 mouse driver 8.04a
• Genius mouse driver 9.20

It didn’t start with:

• Microsoft mouse driver 9.00, 9.01, or 11.0
• CuteMouse driver 1.9.1, 2.0a4, or 2.1b5
• DR-DOS mouse driver 1.1
• VBMouse driver 0.67

[jester-xbmc]

As mentioned by john, it's demo scene code, and having to stay below 100kb probably means using every trick in the book to do so, my guess is, apart from the mouse stuff, the graphics might be using VESA trickery, it's already switching between VESA 640x480 256-colour graphics mode 101h and VESA 800x600 256-colour graphics mode 103h on start-up

Maybe playing with output and texture_renderer in conf, could yield some results?

[interloper98]

I tried running it when booted into a real MS-DOS image (inside Staging), combined with SciTech display doctor 5.x (UNIVBE.EXE TSR) providing the VESA functionality, and it was still broken in the same way.

[Torinde]

From #1671:

Most builds just crash, though X gives an error "CacheBlock overrun 2 written 8195 size 8192".
DOSBox 0.63 works

My tests: VirtualBox: works, X 2023-10-27 doesn't work

[Python-Exoproject]

As mentioned by john, it's demo scene code, and having to stay below 100kb probably means using every trick in the book to do so, my guess is, apart from the mouse stuff, the graphics might be using VESA trickery, it's already switching between VESA 640x480 256-colour graphics mode 101h and VESA 800x600 256-colour graphics mode 103h on start-up

Maybe playing with output and texture_renderer in conf, could yield some results?

Thanks for the suggestion but no luck. Its interesting that something as old as 0.63 can run the game no issue but everything else since struggles in one way or another. Im glad we got past the crash in Staging at least, but this graphics issue is a bummer. The key will be what changed between 0.63 and later versions.

Ive tested against 0.63, 0.65, 0.70, 0.71, 0.72 and the results are:

0.63 - Only version that runs the game with no graphical glitch
0.65 - Black screen with hard crash and freeze
0.70 - As long as core=normal same as Staging 81.1
0.71 - Black screen with hard crash and freeze
0.72 - Black screen with hard crash and freeze

[johnnovak]

Its interesting that something as old as 0.63 can run the game no issue but everything else since struggles in one way or another.

Well, emulator development is not a straight line 😄 Obscure titles like this one are the most problematic as they get next to no scrutiny.

Plus... democoders... Must contain some dirty tricks and it only worked on the coder's machine at the compo. Quite typical...

[grapeli]

My tests: VirtualBox: works, X 2023-10-27 doesn't work

Works fine under dosbox-x after turning off the mouse. Keyboard operation is completely sufficient.

dosbox-x -set int33=false -set core=normal viper.exe

[interloper98]

Wow, great @grapeli!

DOSBox-X wraps long segment writes, which is apparently hardware-accurate on 286+ CPUs (this is a default-enabled setting in DOSBox-X).

If you turn off segment limits in DOSBox-X, you get the incorrect segment handling and the image isn't written properly:

dosbox-x -set int33=false -set core=normal -set "segment limits=false" viper.exe

I guess these demo coders saved some cycles by writing long segments and got the wrapping for free in hardware!

I thought it could have been fixed by DOSBox-X's vesa map non-lfb modes to 128kb region=true setting, which involves wrapping writes in the bank-switched VESA BIOS. which I think DOSBox Staging also still needs to add, because it has those empty lines in Druid: Dæmons of the Mind (discussion).

[johnnovak]

Wow, great @grapeli!

DOSBox-X wraps long segment writes, which is apparently hardware-accurate on 286+ CPUs (this is a default-enabled setting in DOSBox-X).

If you turn off segment limits in DOSBox-X, you get the incorrect segment handling and the image isn't written properly:

dosbox-x -set int33=false -set core=normal -set "segment limits=false" viper.exe

I guess these demo coders saved some cycles by writing long segments and got the wrapping for free in hardware!

I thought it could have been fixed by DOSBox-X's vesa map non-lfb modes to 128kb region=true setting, which involves wrapping writes in the bank-switched VESA BIOS. which I think DOSBox Staging also still needs to add, because it has those empty lines in Druid: Dæmons of the Mind (discussion).

Good find. Ouch, this feels dirty! 😆 Yeah I would've bet on it it's just democoders being democoders, yet again 😆

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.

We might implement it as an always-enabled tweak if it's not too complex and doesn't cause issues with everything else. We really don't wanna add tons of switches X style 😅

[johnnovak]

Eh, I've just checked out the "segment limit" implementation in DOSBox X. It's just not worth the complication for a single obscure game, a Win3.x S3 driver and maybe a few demos...

[Python-Exoproject]

You guys solved this one so well (shame it wont be Staging compatible), anyone want to look into #3543? Its the only game in exodos left on 0.73 so if I can move it to Staging (hopefully) or even X we can ditch another unneeded dosbox version from eXoDOS

[Torinde]

@Python-Exoproject, is there somewhere a list of games that use something else other than Staging and X?

[Python-Exoproject]

@Torinde Most exodos games are on ECE or 0.74

There is no list per se, but if you have exodos you can open \eXo\util\dosbox.txt to see which fork launches each game. Of course the dosbox.txt file you have access to is most likely from the v6 release and I have made many tickets in our github to move games onto Staging for one reason or another since the release.

Outside of 0.74, ECE, X, and Staging there arent many I havent been able to move now. Excluding the ones ive gotten working in X and Staging theres:

• Cosmic Sheriff (1989), Mike Gunner (1988), and Pack Regalo Gun Stick (1989): using a custom fork with a patch that lets the mouse be used as gun device that these games require
• Hound of the Baskervilles (1993): Using Daum currently, will switch to X in effort to get rid of Daum. Ticket Investigate playability issues with Hound of the Baskervilles (1993) #2906
• Viper (1998): Using 0.63 currently, will switch to X in effort to ditch custom builds. Ticket Viper (1998) only runs in vanilla dosbox 0.63 #3585
• Descent to Undermountain: Using Daum currently, only Daum runs it properly. Ticket Descent to Undermountain (1998) stuttering in intro #3635
• Millionaire - The Stock Market Simulation (1982): Using 0.73 currently, only 0.73 runs it. Ticket Millionaire - The Stock Market Simulation (1982) only runs in vanilla dosbox 0.73 #3543

I am also trying to move from X to Staging where I can, but the following games dont work in Staging:

• Cyber Riders (1992): Using X currently, only X will play the game music. Ticket Cyber Riders (1992) #3511
• Best of the Best Championship Karate (1992): Using X currently, only X will detect the MT32 when selected. Ticket Best of the Best Championship Karate (1992) #3208
• Eddy and Co: Using X currently, only X will play the game music. Ticket Eddy and Co (1995): Sound in X, not Staging #3640
• Frank Bruno's Boxing: Using X currently, game is best with machine=amstrad which isnt in Staging
• Design Your Own Railroad, Design Your Own Train, EGA Mouse Paint, FaceMaker - Golden Edition, FBCOACH, Funny Face, The New Print Shop, The New Print Shop Companion, Stare-EO Workshop, and Alf's Party Kit: Using X currently, needs printer support printing to pdf which Staging doesnt have
• Hound of the Baskervilles (1993), and Viper (1998): As mentioned above im moving these games to X as Staging has issues with them
• Transantartica (1993), Ishar 2 (1993), Ishar 1 (1992), Bunny Bricks (1993), Storm Master (1992), Boston Bomb Club (1991), Metal Mutant (1991), Crystals of Arborea (1990): Using X currently due to missing tone issue described in ticket Silmarils games with missing intro tone #3504

And here are a couple other games I know have issues in Staging that we have tickets for:

• Deus (1996), and Time Warriors (1997): A rendering issue was fixed but the games still crash when the required cycles are used. Ticket Cycles and VGA rendering accuracy dependent crash in later Silmarils games #3512

And here are some we have on Staging (or probably will do soon) which still have a tweak or two needed:

• Wizardry VI: popping after every effect. Ticket Investigate playability issues with Wizardry: Bane of the Cosmic Forge (1990) #3642
• Command HQ (1990): MT32 device choice makes the game run at a crawl. Ticket Command HQ (1990) #3385

This list might be a useful resource if saved somewhere outside of this ticket for Viper @johnnovak ?

[Torinde]

@Python-Exoproject, thanks!

If you ask me - higher priority should be moving from 0.74 and ECE (officially announced as end-of-life) to Staging and X - rather than dealing with moving games from X to Staging.

At #1671 are mentioned also others:

• Casino Tournament of Champions (1995), SimTown (1995), Boppie's Great Word Chase (1985) - where do you run those?
• Microsoft Flight Simulator v1.05 - I assume you run it in X?
• Carmageddon Glide - I assume you run it in Staging or X?

[johnnovak]

Super informative post @Python-Exoproject, I will turn it into a new megaticket 👍🏻

[Python-Exoproject]

@Python-Exoproject, thanks!

If you ask me - higher priority should be moving from 0.74 and ECE (officially announced as end-of-life) to Staging and X - rather than dealing with moving games from X to Staging.

At #1671 are mentioned also others:

• Casino Tournament of Champions (1995), SimTown (1995), Boppie's Great Word Chase (1985) - where do you run those?
• Microsoft Flight Simulator v1.05 - I assume you run it in X?
• Carmageddon Glide - I assume you run it in Staging or X?

Casino Tournament of Champions (1995), Boppie's Great Word Chase (1985), Microsoft Flight Simulator v1.05 are all on Staging once ive finished creating tickets and exo implements the changes. In regards to MS Flight Sim I thought this issue was resolved in Staging? Is that not true?

Carmageddon is on ECE currently as I havent gone through the 3dfx games yet.

SimTown is a win3x game currently running on a custom build. I have been focused on eXoDOS, not eXoWin3x. eXoWin3x is a whole new kettle of fish with 30 games currently running via Daum alone, but one thing at a time.

Wizardry VI ive decided to move over to Staging if eXo agrees, though ill add that new ticket Grounded0 created to my above list to keep track of any improvements you guys make

As for moving from ECE or 0.74 as a priority, there is just so many. Something like 5k games are on 0.74 and 2k on ECE each tested to be working at time of setup, we just dont have the time to confirm that many games work just as well on Staging. Thats why we have the alternate launcher on Staging, this way there is a tested working launch option using ECE or 0.74 and Staging can be used for any game that a user wants to try it on

[Python-Exoproject]

Eh, I've just checked out the "segment limit" implementation in DOSBox X. It's just not worth the complication for a single obscure game, a Win3.x S3 driver and maybe a few demos...

Just highlighting the last relevant part of the above discussion, we got off topic a bit

[johnnovak]

Eh, I've just checked out the "segment limit" implementation in DOSBox X. It's just not worth the complication for a single obscure game, a Win3.x S3 driver and maybe a few demos...

Just highlighting the last relevant part of the above discussion, we got off topic a bit

Sorry, I don't understand why you quoted my above statement.

I created a new megaticket based on the info in this ticket. Did I miss something, is there anything else to do in relation to the lengthy discussion?

[Torinde]

In regards to MS Flight Sim I thought this issue was resolved in Staging? Is that not true?

I think it depends on the exact game version and if it has unofficial patches or not.