#535 4D Sports Boxing configured for Tandy bus errors o-start or on-exit

[krcroft]

Game: 4D Sports Boxing 1.0 (1990)
setup.exe:
- Video display "Tandy"
- Sound option "Tandy with DAC" or "Tandy without DAC/Tandy Other"

Dosbox configuration:

[dosbox]
machine = tandy

[speaker]
tandy = on
pcspeaker = on
disney = off

[gus]
gus = off

[sblaster]
sbtype = none
oplmode = none

[midi]
mpu401 = none
mididevice = none
midiconfig = none

[dos]
xms = false
ems = false
umb = false

The game will pause or freeze during screen transitions, but can be "paced forward" by entering keystrokes. Quiting DOSBox with Ctrl-F9 will produce a bus error.

Launching dosbox inside GDB, and then launching the game eventually caused the DOSBox window to go block, followed by freezing my X session (however the Linux kernel an underlying services were unaffected).

[ripsaw8080]

I'm not reproducing the described problem in 0.74-3 or SVN with your conf on Windows. Tried 4D Sports Boxing (European) and 4-D Boxing (US).

[krcroft]

Thanks ripsaw8080; that bodes well and points to something wrong on my
side.

Tomorrow will re-pull sources, re-run various build types, and investigate
graphical settings (composite / dri / etc..) in my local WM (mate, running
Ubuntu 20.04 and latest kernel.

[krcroft]

Thank you for comparing on your side @ripsaw8080.

Alas I can't stop reproducing it :( That said, I've had issues crop up with Ubuntu 20.04's Iris driver on my hardware, so will chalk it up to that.

Here's what I've tried, just for the record before closing this.

• Toggling Intel's X11 driver flags: TripleBuffer, TearFree, and DRI between true and false
• Set and unset MESA_LOADER_DRIVER_OVERRIDE=i965
• Switched between preemptive and non-preemptive Kernels
• Tried the latest X11 driver-stack https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers
• Rebuilt DOSBox SVN with pure debug flags (-g -Og), mild optimization flags (-O2), and full optimizations (-O3 -march=native).
• All of the above result in a freeze during 4-D Boxing's intro, after which I close DOSBox and it generates the stack-trace shown in the attached screenshot.

Feel free to close this as a non-issue!

[Qbix]

the backtrace doesn't look corrupt. So there might going on something.
At least in this stage, lets not assume that gcc or libc is broken on ubuntu 20.04 ;)

Can you in the backtrace see if test is valid (or maybe set a breakpoint before ctrl-f9)
and/or in ~TIMER()
maybe the PIT list is corrupt or so, what might explain some hanging as well

edit:
I assume that the backtrace is of when pressing ctrl-f9. Is that correct ?

[Qbix]

I am able to reproduce the problem.

[krcroft]

Qbix, that's great news.

Yes, the test pointer is not null; attempting to backtrace higher up doesn't reveal any more.

In the Tandy's TandyDACModeChanged() function, if you block the DAC playback request (case 3:), then the game carries on and plays correct audio.

static void TandyDACModeChanged(void) {
        <...>
        case 3:
                // playback
                LOG_MSG("Blocking DAC playback-mode");
                break;

This is true if setup.exe is configured with or without the Tandy DAC.
Maybe the game's driver is incorrectly enabling the Tandy DAC when it shouldn't?

[Qbix]

It seems our investigations are heading in the same direction @krcroft

I found that turning on the soundblaster "fixes" the problems.

I agree that the game might be using DAC even when not configured for it, as DAC playback requires the soundblaster to be there. (as the resulting sound was very similar in both cases, currently trying to figure out if the game somehow does a detection step (for dac) that succeeds in dosbox even when dac playback isn't enabled. (dac playback in dosbox should be disabled if there is no soundblaster ( the SB_Get_Address in the constructor of TANDYSOUND))

Still this doesn't explain the crash on exit (ctrl-f9) when the game soundblaster is disabled.

I tried walking through the PIC_RemoveEvent code, as that is what delete test ends up doing, but of course it didn't crash while single stepping.

It feels that multiple things are going wrong. (dac playing "working" despite no soundblaster, crash on exit, game detecting dac playback ? and maybe even some more things)

[Qbix]

I am not sure about DAC playback needing it. There is a lot of code in bios.cpp as well that deals with tandysound

[Qbix]

I was wrong about the DAC playback needing the soundblaster. I misread the first line of the function. It can work without.

[Qbix]

Found the problem. Now trying to figure out the best way of solving it.
The quick (but incorrect) hack that I tried, fixed both problems. (crash on exit and hanging on transitions)

[Qbix]

Found the core of the problem.
Fix is being tested with a set of games.

[krcroft]

That's great news Qbix! Thanks for keeping us posted.

[krcroft]