[Bug] "CMOS shutdown CPU reset method is not compatible with dynamic core" in Terminal Velocity

[EdHerdman]

Describe the bug

Running the game "Terminal Velocity" with three settings changes: Emulate CPU Speed (tested using various speeds of Pentium as well as the 110,000 cycle AMD K6 option), Fit to Aspect Ratio, F11+F for fullscreen mode.

DOSBOX-X locks up in gameplay in Stage 5-2 when I attempting to exit a 3D tunnel gameplay segment (I'm not sure if it's a specific tunnel, but it might be). DOSBOX-X pops up the following message and refuses to respond - I can't click through the message and must hard shutdown DOSBOX-X through the task manager:

"Sorry, CMOS shutdown CPU reset method is not compatible with dynamic core"

I have an ingame save available which allows investigating this further if necessary.

Steps to reproduce the behaviour

1) Drop attached savegame in Terminal Velocity's main folder (same as the game executable TV.EXE) 2) Play through the game from the attached savegame and wait for DOSBOX-X to lock up with the message on reaching the end of the tunnel (which opens up on the open game world).

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

Windows 11 21H2 (build 22000)

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

dosbox-x-vsbuild-win64-20220901232730 (SDL2)

Additional information

AMD Ryzen 7 3700X is the architecture I'm running.

I've used the DOSBOX-X GUI to mount the Terminal Velocity install folder (from GOG Games) as H:, and then run the game using the file TV.EXE.

I have attached the savegame which leads to this problem. It goes in the main Terminal Velocity directory.

SAVE0.zip

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

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

Code of Conduct & Contributing Guidelines

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

[MX9000]

I completed this game last month and had the same issue as you or more often the crash screen shown in this video: https://www.youtube.com/watch?v=68V3FHu6buY I found out on the old 3D Realms website that this is a known game bug: https://legacy.3drealms.com/tech/terminalvelocity.html#52 In the Steam Community you can also find the technical explanation of the bug: https://steamcommunity.com/app/358370/discussions/0/1744480966981503727/ Other than avoiding the tunnel entirely as recommended by 3D Realms tech support, if I remember right, I was able to exit this tunnel without crashing by not taking any powerup.

[EdHerdman]

Thanks for the explanation! Would it be worth opening another issue about the crash handling? I think locking up entirely like DOSBox-X does is less than ideal, but I wouldn't know if this is something that can be easily implemented. The current message also seems to imply that the interpreter would handle this case differently, which may be true (i.e., better crash handling) or false. The dynarec message here is unfortunately very vague.

[MX9000]

I am only a fan of DOSBox-X, not a developer: but I agree with you that a better crash management could be helpful. Thank you.

[ebelyshev]

The solution to your problem is to change DOS version to 6.22

[EdHerdman]

Good to know. I'd still like DOSbox-X to handle this exception in a friendlier manner without crashing entirely, though.

[grapeli]

This bug in Terminal Velocity has the same consequences for dosbox-SVN and dosbox-staging as in dosbox-x. Nothing special here. E_Exit() is called and the programs exit. The author of DOSBox-X in another thread explained it as follows.

Normally E_Exit() is called when an error happens that the emulator cannot recover from.

I'm curious how it affects the system on real hardware.

If you care so much about keeping dosbox-x running after this event then absolutely don't move the cursor pointer until you restore stability (restart the game).

terminal.velocity.bug.dosbox-x.webm

Another way is to replace dos4gw in GAME.EXE with dos32a. Then this Terminal Velocity crash won't destabilize dosbox-x (when moving the pointer cursor).

The only improvement is the cls command in dosbox-x, which does not clear the screen after this unfortunate event.

[EdHerdman]

It causes a crash on real hardware, as MX9000 mentions above. Anyway, I know this is probably a thing for upstream, but I just find it odd that a crash in the virtualized system brings the whole house down. DOSBox-X's easy setup makes the consequences of a hard crash less bitter than in standard DOSBox.

As far as whether I "care so much," I just report problems as I see 'em. Whether or not it's a priority to fix it is up to the developers, who I thank for their hard work.

[EdHerdman]

Sorry, I misunderstood your question. I can't confirm how the 5-2 tunnel crash behaves on real hardware right now. I'll leave this here as a reminder about that.