What type of application?

Usually you're better off logging things like interrupts (CPU_Interrupt() in
cpu.cpp) and dos calls (DOS_21Handler() in dos.cpp) which don't depend
on timing. That way you might be able to pinpoint some area of interest,
like "after file open but before file read" or "somewhen after an int33".

Also having the interrupts (additionally the PIC_startIRQ() logging from pic.cpp
maybe) is a good idea as it makes it easier possible to determine when the
(non-deterministic) hardware interrupts happen, and where execution of
their handlers can be found (and probably removed) from the logs.

thanks. will try these...

How much memory do you have available on these devices?
At lot the instability on the gp2x was resolved by reducing the memory consumption. The big saver is to shrink the TLB? array. See under DOCS the porting file if you haven't already.

There's a pretty nice implementation in the cvs (by crazyc, psp port) that reduces
the size of the TLB. I wasn't aware that memory size was a stability issue though.

the gp2x version is still at 0.72, I think I complied a cvs version at one point recently but it crashed right at the beginning.
Maybe when I have some time I should into it.

i'm not sure its a memory issue, but i can't rule it out yet... dosbox is set to emulate 2MB, (16MB didn't work so i fugured i'd go with something more minimal...) otherwise stability's looking good. its just this app (x-com).
i can run the intro but the main app crashes with a panic (and i don't have call stack to work with...) i know it crashes before setting its video mode, but i need to narrow it some more... to complicate thing its running over dos4gw (but so is the intro - seperate executable-, which runs fine)

Maybe check the sound config (disable it).

i thought about this a lot (winnie the pooh style: scratching my head and eating - waiting for way more recompiles than made sense)...

here's what i want to do. i want to make dosbox run deterministicly.

i'm not concerned about input handling (in this case anyway), and i don't care about "real"-timy-ness.

question:

1) am i correct to assume that syncing timer by fixing it to say the number of emulated cycles instead of having it hooked to system timer events would get me there?

2) any better ideas? recommendations on how to do this minimum effort

like definig GetTicks() to return a constantly incremented static?

dosbox surely isn't suited for that, anyways if you care you should maybe
start off with Normal_Loop() in dosbox.cpp where part of the ticks handling
(that triggers the "external" events like timer irq) is located.

Setting up some auto-loading ([autoexec] section of dosbox.conf) along with
disabling all hardware irqs might already get you some useful logs, at least
if the game still runs.

did this in timer.h, what would be a "pseudo-quazi-sensible" (educated guess) value for MYTICKS_SCALE ???

#define MYTICKS_SCALE 10;

Bit32u MyTicks()
{
static Bit32u ticks = 0;
ticks += MYTICKS_SCALE;
if (ticks == 0xffffffff ) ticks = 0;
return ticks;
}

//#define GetTicks() SDL_GetTicks()

#define GetTicks() MyTicks()

Well anything should do as long as you just want a deterministic log, i'd say.
But remove that

1if (ticks == 0xffffffff ) ticks = 0; 

as it won't be hit by the +=10 thing anyways. Also the scale might be best
at 1, not?

yep... just experimented a little and setting it 2-3 gives "comparable" performance with calling SDL (in my win32 build), so i'll use that.

I think I complied a cvs version at one point recently but it crashed right at the beginning.
Maybe when I have some time I should into it.

That would be nice, if there's some regression i'd like to fix that sooner than later.
Just post somewhere if you need help at some point.

almost nailed the comperative debugging. backported my s60 code to win32, and i am comparing it against the vanilla... (a lot faster than straining myself on the symbian emulator :-)
expect results (hopefully x-com running) soon...
then, i will move to the cvs codebase

Off topic, but if your really aiming for Xcom, M-HT the same guy who did the ARM dynarec has statically recompiled xcom for ARM.

Pickle wrote:

Off topic, but if your really aiming for Xcom, M-HT the same guy who did the ARM dynarec has statically recompiled xcom for ARM.

Wow, that's really cool 😮

I looked it up and saw these threads; X-COM 1, X-COM 2 and even Albion.

I don't see any available source for them, though? But if these 3 were somehow ported to S60, I would be in heaven.

Would absolutely love to see Master of Magic too, but I'm not sure it use DOS4GW so it can be recompiled?

Source comes from M-HT, I do have the xcom source since I complied it for the Gp2X wiz. But id rather have M-HT give out the source if he wants to.

getting back to topic...
i'm narrowing this down (getting a deterministic run in dosbox), but stumbled again.

i fixed the timer... that helped a lot, but my dos-cpu instruction logs still diverge in parts even when exectued on the same platform over and over, - time variance.

one thing i thought of is that maybe the dos app is requesting system time to init its random seed, or something like that. what would i need to do to fix that.

also maybe the app is reading mouse input, even though there is no pointer shown. (i'll try to rule that one out)

any other ideas as to what could break my determinism?

thanks for any advice in advance

ps: one things probably to fix the system time to some constant in dos.cpp, right? what else?

worked... done... :-) x-com runs!