Try just using normal core with 0.70 on OSX and see what that does.

With CPU normal, random freezing still happens in Albion and Dune 2.

I can verify this issue on OSX. I have a C2D Macbook Pro and the same thing happens. Except in my instance, the game music is still playing, the mouse in the game still moves, it's just the action in the game itself is frozen and nothing responds to my clicks inside the game. I don't think it's a Dune II issue as I've logged many hours on this game over the years and never noticed this. However I'd be hard pressed to say it's a core issue specifically since some stuff appears to be working still.....

Any ideas Dos Freak?

EDIT: Once I take focus away from DOSBox, trying to get the mouse pointer in-game to move again is impossible. And it appears that once the current music track runs out - the sounds goes as well.

Hi,

The firstposter said it exactly. It happens with X-Com - Enemy Unknown too. After 20 minutes or so the game freezes. Tried nearly all core and gfx settings. 😖

0.65 runs great.
Emac 1.25Ghz PPC, Ati 9200.

greets
GM

See if it happens as well if you compile the sources,
if so enable the debugger and try to figure where it hangs.

I got a fresh checkout and compiled with heavy debug. Problem still happens. Console output shows nothing obviously bad. Guess I'll have to use the debugger...?
How do I Alt-Pause on a MBP which does not have a pause key?

You can use the mapper to change the keys.

OK, I'll look for this mapper thing...

So far, it's stopping at the same place...

946339645: SBLASTER:DMA unmasked,starting output, auto 0 block 12098
946339645: SBLASTER:DMA Transfer:8-bits PCM Mono Single-Cycle freq 11764 rate 11764 size 12099
951855529: SBLASTER:Single cycle transfer ended
951855529: SBLASTER:Raising IRQ
951855959: PIC:1 mask EC
951855963: PIC:0 mask F8

That output isn't too helpful as it's presumably far away from
where the hanging happens.

Any updates on this? I tried modifying all kinds of settings myself but the issues eventually happens no matter what. I tried replicating this in the 0.66rc1 Universal Binary that was being distributed and it happens there as well. I am unable to compile my own version as I get the following error:

1if g++ -DHAVE_CONFIG_H -I. -I. -I../../..  -I../../../include -I/usr/local/include/SDL -D_GNU_SOURCE=1 -D_THREAD_SAFE  -g -O2 -MT nullmodem.o -MD -MP -MF ".deps/nullmodem.Tpo" \
2  -c -o nullmodem.o `test -f 'nullmodem.cpp' || echo './'`nullmodem.cpp; \
3then mv -f ".deps/nullmodem.Tpo" ".deps/nullmodem.Po"; \
4else rm -f ".deps/nullmodem.Tpo"; exit 1; \
5fi
6nullmodem.cpp: In constructor 'CNullModem::CNullModem(Bitu, CommandLine*)':
7nullmodem.cpp:102: error: invalid conversion from 'int' to '_TCPsocket*'
8nullmodem.cpp:102: error:   initializing argument 1 of 'TCPClientSocket::TCPClientSocket(_TCPsocket*)'
9make[4]: *** [nullmodem.o] Error 1
10make[3]: *** [all-recursive] Error 1
11make[2]: *** [all-recursive] Error 1
12make[1]: *** [all-recursive] Error 1
13make: *** [all] Error 2

I followed the build instructions on the DOSBox wiki. I compiled SDL and SDL_net using the source downloads from the SDL site. I get the same error with the current CVS version as well. This is obviously something I'm missing since the 0.70 source code archive ought to compile fine. Any ideas?

Disable modem stuff when ./configuring or force that conversion
(though i don't know if it'd work then).

Compiled out of the box for me, but I grabbed libsdl via macports.
I've no idea what I'm looking for in the debugger... 😢

Basically nothing. Play until the game hangs, then enter the debugger
and trace a bit (F11) to see if it's some short loop (ports reading maybe)
where it got stuck.

I am seeing a short loop. Here's some image capture when it first happens and after a couple of F11s. After that, it repeats.

Ok thanks, that's very precise information (vret waiting, nothing
dangerous normally).
Place a breakpoint right after the conditional jump (move the cursor
bar over the line with cs:0x87 and hit f9), then let it run (f5) and see
if that breakpoint hits.

Nope. The jne goes back 0x80.

I'm not sure if i can guide you further what to look for, but try adding some
logging to vga_misc.cpp, function vga_read_p3da (this cares about the
hret/vret bits that are read in this loop), that is put in there something like

1LOG_MSG("timeInFrame: %.3f, vrstart: %.3f, vrend: %.3f",timeInFrame,vga.draw.delay.vrstart,vga.draw.delay.vrend);

and see if the game is still playable, and what happens to the values
when the hanging occurs (if...).

I finally got the code to compile. I simply removed SDL_net from my system. Even using the macports version didn't work. Anyway, I added the code wd and starting the game has become an act of congress now. The debugger screen is just spitting out that output continiously after I attempt to execute dune2.exe. It's been spitting out output to the debug window for 10 minutes with no end in sight...

Well i feared that, maybe try adding a condition to the output like
if (retval>=8 ) LOG_MSG...
Maybe you can start dosbox through gdb or some other debugger
and break in when it's looping. Then trace to/place a breakpoint
at vga_read_p3da() and examine the data.