SDL version shouldn't really matter, but the odd part is that it
(seems to?) happen on macs only. Was playing dune2 for quite
a while with different settings, no crashes.
Is it reproducable with the above steps on windows/linux, too?

No it doesn't happen on Windows. I dual boot XP on my MacBook Pro and DosBox runs flawlessly there using the same games.

I changed games to Dragon Strike. It's more convenient to test using it than Dune 2. Dragon Strike takes a little longer to cause a lock. I guess the graphics requirements aren't as heavy as Dune 2?

Checked out 2007-01-25: No lock after an hour.
Checked out 2007-01-26: Locks in under an hour.

Taking a glance at the commits in the diff, it looks wholly video-related: render, vga, int10.

I can confirm I also have no issues with Windows. I also tried Linux and it works fine. For both, I consider "fine" and "no issue" if there is no lock in an hour or more of runtime.

could you try the mac os x variant like this:

1CXXFLAGS="-O0" ./configure --disable-fpu-x86 --disable-dynamic-x86

(the configure switches should disable the dynamic core and the asm fpu core. Maybe there is some mixing of fpu calls with internal calls.)

Using HEAD: still locks.

As far as Dragon Strike is concerned, it seems that only graphics locks. Game logic, sound and input still seem to be operating normally.

So are there any updates on this issue? It seems that we at least generally know what commits are the source of the problem.... is there a gameplan on what the next step here is?

Quite simple: get consistency of log output and gdb display and go through
the questions above. That is figuring if the cycles advance "normally"
(don't get stuck, don't advance in very large steps), if the vga callbacks
are still called (think they are as yerejm said) and what happens inside
vga_read_p3da when it hangs.

I have the same problem on windows xp using ykhwong's CVS when playing Ultima 7 (both episodes).
The games freeze randomly without any apparent reason, you can still hear the music and move the mouse cursor around the screen but if you click anything happens. 😒

Does it happen with the official 0.70 release?

This patch produces debug output with values of the VGA timing every two seconds. Could somebody who has the problem try it and see if any values change when the error occurs?

I just tried it with the patch and Dune 2. There is no difference in the output after the lockup. This was after 30 minutes using your patch applied against dosbox 0.70. Attached is a gzipped version of the debugger log.

Thanks for testing. Now have another one. It displays some more data.
If that doesn't show changes I doubt the read_p3da is at fault.

Okay now this one showed a difference. The calls count shot through the roof once the lockup occurred:

15 minutes into gameplay:

1h(us) total 31.78 end 0.00 blank (25.42/31.14) retrace (0.00/0.00)
2v(ms) total 14.27 end 12.71 blank (12.90/14.01) retrace (13.09/13.16)
3time: 947051.00, time in line: 31.09, time in frame: 5.69, total calls: 400119, vr:129, bl:79894

Right after lockup:

1h(us) total 31.78 end 0.00 blank (25.42/31.14) retrace (0.00/0.00)
2v(ms) total 14.27 end 12.71 blank (12.90/14.01) retrace (13.09/13.16)
3time: 2117051.00, time in line: 15.14, time in frame: 4.75, total calls: 1813105, vr:0, bl:476914
4
5h(us) total 31.78 end 0.00 blank (25.42/31.14) retrace (0.00/0.00)
6v(ms) total 14.27 end 12.71 blank (12.90/14.01) retrace (13.09/13.16)
7time: 2119051.00, time in line: 4.72, time in frame: 7.25, total calls: 1813458, vr:0, bl:478553

Attached is the full debug output of course. So is that revealing in any way?

For some unknown reason it (the "time in frame") is unable to hit the vr timing period (13.09/13.16).

The calls is so high because the game is polling the register for the vr bit but never gets one.

A hopefully temporary hack:

1if(timeInFrame >= vga.draw.delay.vblkstart &&
2			timeInFrame <= vga.draw.delay.vblkend)
3				retval |= (0x1|0x8);

It should allow you to play Dune and others but breaks Horde and Archon Ultra.

Does anybody have any idea which specific change caused this breakage? I know we had it narrowed down to a specific day, but has anybody figured out the specific change that is at fault?

Um that's very easy, when the retrace handling was changed.

You could try some additional logging like

1		if(timeInFrame >= vga.draw.delay.vrstart-0.05 &&
2			timeInFrame <= vga.draw.delay.vrend+0.05)
3			LOG_MSG("%.3f  %.3f  %.3f",timeInFrame,vga.draw.delay.vrstart,vga.draw.delay.vrend);

where the +-0.05 is to be adapted until it is playable and produces log output
when hanging.
In that case maybe add logging about the cpu cycles/max cycles and
PIC_FullIndex and stuff.

Tried as suggested.

+- 0.05, froze. Logging stopped after vga hang. Incremented to 0.1.
Tangent: A massive cycles left count shows up frequently (10^154), but this seems unrelated to a freezing vga. Unsure if this normal or my fault.
+-0.1, vga did not hang while playing Dragon Strike or Dune 2. Log doesn't show anything special different from previous log. VGA hang apparently resolved.

Code was...

1		if(timeInFrame >= vga.draw.delay.vrstart-0.1 &&
2			timeInFrame <= vga.draw.delay.vrend+0.1) {
3            LOG_MSG("timeInFrame: %.3f,  vrstart: %.3f,  vrend: %.3f",timeInFrame,vga.draw.delay.vrstart,vga.draw.delay.vrend);
4            MY_CPU_LOG(); // prints cpu cycle info
5            retval |= 8;
6        }

This outcome is nuts.

Thanks for reporting back.

Please split up the block you posted, that is having one with the
+-0.05 for the logging, and one WITHOUT the +-0.05 for the
retval |= 8 (so no functionality is changed).

+-0.1, vga did not hang while playing Dragon Strike or Dune 2. Log doesn't show anything special different from previous log.

Are you sure? The vr field is zero but it doesn't hang???