Hi Ijor, thanks for you interest in zeST, and thanks again for giving us access to the fantastic fx68k core!
Are you sure this is due to lack of randomization? I don't recall we have seen something like this under emulation, and emulation obviously has the same "issue", with the boot timing being fully deterministic.
Nicolas told me randomization is used on Hatari. The initial angular position of the floppy is chosen at random each time the (emulated) floppy drive's motor turns on.
On "my socks are weapons", the protection uses a few hundreds of bytes in the beginning of RAM (which includes interrupt vectors and the stack space) to decrypt some encrypted code. With some particular bad timing, a VBL interrupt may occur and modify the stack memory, making the demo crash.
On "Flipo", this instruction sequence is used to disable the HBL interrupts:
an HBL interrupt can occur after the HBL interrupt vector is cleared and before HBL is disabled. which results with a jump to address 0, and a crash.
And with some constant initial state, you can get the same bugs each time
You will probably need to implement some kind of randomization sooner or later. Some protections and some titles depend on that. I don't follow why that would be very challenging. You don't need a high quality seudo-random (or true random) implementation. Just some fair timing variation that shouldn't be too difficult to implement.
You're are actually right, there can be simple ways to implement randomness, It can even just be some high bits of the angular position that need to be random, not the full value.
Protections are not supported by zeST though, maybe in the future, but it's really not a priority to me.
...or maybe Falcon
