After putting the condition on, the game runs. When the crash begins, There is nothing different about the output of those lines that I can tell than what was displaying before. Of course once the video freezes, that line of output is no longer being dumped to the display either.

Where did you put the logging line? Should be right before the return
statement (in the lines before that return value is changed).

That is exactly where I put it. Afterall as a programmer I know it wouldn't make sense to conditionally display a line based upon a value within a variable that hasn't been set yet (i.e. retval). Though there is a lot of output, and perhaps I missed something. Is there a way to log the debugging output to a file?

EDIT: Wait... do you mean before or after the switch statement? It sounds like you before whereas my conditional logging is placed after it.

No you placed it right, after the switch and before the return.
If it doesn't produce any logmsg then it shouldn't really hang...

In the switch the retval should be ORd with 8 thus the >=8 would
kick in when it hangs. Maybe try running it with gdb and break at
the loop.

Don't know assembler to be useful in gdb, so I've just been logging.

Who calls vga_misc::vga_read_p3da? Once it hangs, the log does not happen...

Uncommented in VGA_VerticalTimer

1if (abs(error) > 0.001 )
2  LOG_MSG("vgaerror: %f",error);

And when hung, getting lines like
vgaerror: -0.018123

But VGA_DrawPart is still executing. But when I enter the dosbox debugger and F11, it doesn't execute anymore until I F5. Threads, I guess?

Who calls vga_misc::vga_read_p3da?

Well the dos program, that's the in al,dx in the looping code (dx==0x3da).

And when hung, getting lines like
vgaerror: -0.018123

So this is negative only when it hangs? Not sure if it's just an effect of it
or could cause the hanging.

Not so much negative as it is too big...

1static void VGA_VerticalTimer(Bitu val) {
2	double error = vga.draw.delay.framestart;
3	vga.draw.delay.framestart = PIC_FullIndex();
4	error = vga.draw.delay.framestart - error - vga.draw.delay.vtotal;
5	 if (std::fabs(error) > 0.001 ) // Used to be abs(), but compile failed with apple gcc? Added #include <cmath> above
6		 LOG_MSG("vgaerror: %f",error);
7...
8}

Comparing with vga_read_p3da, something to do with vga.draw.delay ?

Is VGA_VerticalTimer() called when it's hanging (that is called until you
hard-exit dosbox)? If so try logging those event delays,
vga.draw.delay.vtotal and vga.draw.delay.vrstart.

VerticalTimer is happening. The event delays stay the same from start up to hang. And that vgaerror is always happening hang or not, so that was a red herring. I got the hang to happen on save game name entry, which is rare and the debug showed completely different assembler code. It's looping but the loop is far larger than the other loop hang. Still poking around...

OK, I'm in gdb and looking at the process while the game is hung.

dosbox.cpp:Normal_Loop() is spinning as normal.

1ret=(*cpudecoder)();

is returning 0. I guess that's ok since the if end the loop.

According to gdb, vga_read_p3da is doing

1		else if(timeInLine >= vga.draw.delay.hblkstart &&
2			timeInLine <= vga.draw.delay.hblkend)
3			retval |= 1;

Not |= 8.

Not sure where else to go... it looks like it is running normally but with no VGA updates.

The jump is JumpCond16_b(TFLG_NZ)

Hm it never gets the |8 then, right?
What are the values of timeInFrame, vga.draw.delay.vrstart and
vga.draw.delay.vrend when it hangs?

Right..

(gdb) print vga.draw.delay.vrstart
$3 = 13.092353525322741
(gdb) print vga.draw.delay.vrend
$4 = 13.155908639523336
(gdb) print timeInFrame
$5 = 0

This is strange... 0?

41 double timeInLine=fmod(timeInFrame,vga.draw.delay.htotal);
(gdb) n
43 switch (machine) {
(gdb) print timeInLine
$9 = 0.0067030784508442312
(gdb) print timeInFrame
$10 = 0
(gdb) print vga.draw.delay.htotal
$11 = 0.031777557100297914
(gdb) print (double) fmod(timeInFrame,vga.draw.delay.htotal)
$12 = 0

Ok intermediate question: does it behave any different when you
set core=normal and cycles=xxx (fixed value)?

If it's hanging please try to fetch the values of
CPU_CycleMax, CPU_Cycles and CPU_CycleLeft

The first entry into pic.h:40 at a fresh hang via gdb:

Breakpoint 14, vga_read_p3da (port=986, iolen=1) at ../../include/pic.h:40
40 return (CPU_CycleMax-CPU_CycleLeft-CPU_Cycles)/(float)CPU_CycleMax;
(gdb) print CPU_CycleMax
$1 = 10000
Current language: auto; currently c++
(gdb) print CPU_CycleLeft
$2 = 6622
(gdb) print CPU_Cycles
$3 = 3367
(gdb) print (CPU_CycleMax-CPU_CycleLeft-CPU_Cycles)/(float)CPU_CycleMax
$4 = 0.0011000000000000001

I've been running at core=normal and cycles=10000 all this time.

yerejm,

Thanks for taking up the slack on this one. I really want to see the issue fixed, but my attention has been focused on a very promising job interview earlier this week.

My apologies for not contributing more, however it appears that the fact you are even using gdb shows you've already moved beyond where I would be anyway. Most of my dev experience is web/windows based.

I can only agreed on that running ufo 1.14 here and it freezes aswell in dosbox 0.70 but works nic eon 0.65
I have a g4 1.5ghz and running mac os 10.4.9

(gdb) print CPU_CycleMax $1 = 10000 Current language: auto; currently c++ (gdb) print CPU_CycleLeft $2 = 6622 (gdb) print C […]
Show full quote

(gdb) print CPU_CycleMax
$1 = 10000
Current language: auto; currently c++
(gdb) print CPU_CycleLeft
$2 = 6622
(gdb) print CPU_Cycles
$3 = 3367

That looks a bit suspicious, but might just be incidental.

Anyways maybe you can test two things: replacing the PIC_FullIndex
function call in

1double timeInFrame = PIC_FullIndex()-vga.draw.delay.framestart;

with a call to a (new) function like

1INLINE float PIC_TickIndex_test(void) {
2	return (CPU_CycleMax-CPU_Cycles)/(float)CPU_CycleMax;
3}

(that is the CyclesLeft omitted).

And (independently of the above) look at iohandler.cpp and remove all
calls to IO_USEC_read_delay() and IO_USEC_write_delay().

Replacing PIC_FullIndex causes an endless loop on Dune 2 startup.

144AA:0C06  EC                  in   al,dx     
244AA:0C07  A808                test al,08                                       
344AA:0C09  74FB                je   00000C06 ($-5)         (up)                 

...

Instead of removing IO_USEC_xxx, I made them return immediately on entry. Hang occurs as before, but the loop is different.

12ADE:0079  EC                  in   al,dx                                       
22ADE:007A  2408                and  al,08                                       
32ADE:007C  32C3                xor  al,bl                                       
42ADE:007E  74F9                je   00000079 ($-7)         (up)               

The retval here is set at:

168                      else if(timeInLine >= vga.draw.delay.hblkstart &&
269                              timeInLine <= vga.draw.delay.hblkend)
370                              retval |= 1;

Is that timeInFrame always zero or close to zero when it hangs?

Every time I've looked at it in gdb, it's been 0.
I put in a LOG_MSG to spit out the value in vga_read_p3da and it stays above 1 whether it is hung or not.