Look up the recommended hardware requirements: http://www.mobygames.com/game/dos/call-of-cth … -comet/techinfo

Use this to set: Set cycles to specific xt/at/386/486/586 speed.

Says minimum CPU is 286, aka AT class, so using the batch files from above, type "at" at the command line.

i am using the d-fend reloaded so I set the values there.
Opening the bat file, I understand that AT = 8000 cycles?

Roughly. AT is calculated with 94*cpucycles, where cpucycles is the AT machine's speed in MHz. The original AT ran at 6 MHz, the later 339 model AT at 8 MHz, and PS/2 models 50 & 60, also 286s, ran at 10 MHz. This will put you in the ballpark, if the game still feels too fast or too slow, adjust to taste.

I use D-Fend reloaded too and i have the cycles and core options set to auto. The game works for fe fine that way.

After choosing both 'auto' the animations [i usually check the flying gull after the intro' seem right.

Edit: but later animations are fast again.. argh

Try some very low value for the cycles (like 1000) and switch between the
different core= settings, and report back with the results.

Testing scene in bar

Cycles 1000
Core emulation: auto,normal,simply,dynamic.. the findings are the same
finding: Generally very low transition between scenes.Slow loading of save games. Animation seems ok. Slow responses between dialogue

So, does this leave me the only option of increasing cycles and thus having normal load times AND unfortunately fast animations?

So, does this leave me the only option of increasing cycles and thus having normal load times AND unfortunately fast animations?

Obviously something is wrong, so yes.
Other than that try the more advanced cycles options like "cycles=max 50%"
possibly adding the limit option as well (see the readme).

Nothing comes to mind on how to distinguish between transition, dialogue vs animation, but file access could be solved. Perhaps going to max cycles on entry of int13 and dos file routines, then set to original set cycles on the next device access.

Yeah.

I would think animation might use one of the timers, vs dialogue and transitions not doing so. If that were the culprit, maybe with the pit running off a separate clock from the cpu and added "wait states" to handle the asynchronous timing would solve it.