Not a surprise. Old DOS had the worst ports due to hardware limitations, while Amiga did the best.

I dont'' think so. Ill try again.

In the case of Ultima 3, the Amiga port had one issue that I noticed; the RNG isn't as random as it should be. Basically, I would get streaks of high or low values far more often than there should be. It got to the point where my chest strategy would be to G)et chests until I get a trap, then switch to magic for chest traps until it fails once and then repeat; this would be faster and safer than other methods (if the spell fails, it would keep failing for a long time before succeeding). Also, instant death spells would hit all enemies or no enemies more often than chance would suggest.

It's as thouth the RNG isn't really random, but is rather just something like a counter.

(Also, the Amiga ports of the Bard's Tale games are apparently quite buggy, so this isn't the best computer for those RPGs either.)

Note that the correct setting is cycles, not cycle. Ultima III with Voyager Dragon's patch works fine for me with all the DOSBox cpu related settings set to auto, so you might try that as a starting point.

[cpu]
core=auto
cputype=auto
cycles=auto

And, again, to recapitulate: it's cycles, not cycle. ;)

Interesting. Could have been a counter, although what kind not sure.

I'm pretty sure this wouldn't have been a problem in the U3 source code as usually rand (random) is a function provided by the standard library used, so the Amiga one might have had a very bad one. If the game was literally just... incrementing a value to use as RNG (as say a filler for the function or a Debug setting never taken out) that... would probably explain it.

It's possible it could also be based on a ticker counter, where it keeps track of how many cycles the computer has been on. Though other than say the cpu instruction (RDTSC) i'm not sure many places where it would keep track of such timers... IBM machines had a timer that you could adjust and a 16bit value would max out very quickly.

Normally PRNG is calculated by taking the number, adding a large prime, and multiplying against another prime. This gives overall a decent spread of random-ish numbers. I would prefer to use crypto functions in a large blocksize, but that's a bit extreme for games (and far slower). PRNG calculations can also probably be similarly in hash functions.

Curiously that ATARI800 had a RNG data location that generated noise from the audio device... That was interesting to explore.

thanks. Ill retry. I did have cycle instead of cycles.

This algorithm can lead to problems, such as fixed points (where, if the RNG is given a particular seed, it spits out the same value over and over again).

(For purposes of this post, I am using the = sign to denote congruence; normally you'd use a symbol of 3 lines, but my keyboard doesn't have such a key.)

Here's how I can show that there are often fixed point. In any case, the random number sequence is done by iterating a function like
f(x) = ax + b (mod m)

We can solve this for a fixed point:
x = ax + b (mod m)
0 = (a - 1)x + b (mod m)
-b = (a - 1)x (mod m)

Unless (a - 1) = 0 (mod m), if (a - 1) and m are relatively prime, we can solve this function and find a fixed point.of the RNG. (Incidentally, Dragon Warrior 2 on the NES has a flaw in the RNG that can cause this to happen. If this happens, it's obvious; townspeople will always "randomly" move in the same direction, and encounters will either occur every step (at least in certain terrain) or not at all. Note that, if encounters do occur, the game will softlock after the first round of commands is entered.)

Turning the RNG into a simple counting function probably involves something similar, and it is possible for this to happen in Dragon Warrior 3 on the NES.