near-san
commented
3 years ago There's two non-deterministic behaviors to OPHCT.
-
after a soft-reset, sometimes Hclock=186 (OPHCT~=Hclock>>2), and sometimes Hclock=188. On some SNES consoles, it's always H=186. On others, it's one or the other, randomly. I am not sure about after a power-on event, I never had an easy way to check as any means I've ever had to test code (copiers, flash carts, 21fx) required startup code that took me too far from reset to tell what value the system started at.
-
right near the long-dots that exist on nearly every scanline, roughly around Hdot=322 and Hdot=326, the long dot start position tends to fluctuate 2 Hclocks to the left or right each time you latch. If you wrote a test that kept latching OPHCT at the exact same cycle, you would see the Hdot value returned fluctuate around the two long dots. For all other times, the latched value is 100% stable and predictable.
I don't emulate either because aside from the option to randomize memory at startup, bsnes and higan are deterministic, ironically for the sake of TASing. Deterministic TASing on real hardware isn't possible due to the CPU<>APU oscillator fluctuations that exist on real hardware. Also to emulate the first one, I'd have to know why some systems fluctuate on reset and others don't. I didn't test on enough systems to deduce a pattern for that. And I simply don't know what happens at power-on. Someone else would have to test that who could latch OPHCT immediately as the first instruction in the reset vector, and then staggered by a half-dot (to deduce the exact Hclock value) as a second, separate test. For the second behavior ... if someone were to create a probability model of the long dot being 2 Hclocks behind, centered, or 2 Hclocks ahead, we could model that into the emulator.
Neither of these two behaviors seem likely to affect whatever Ultima VII is doing. I don't believe there is another non-determinism in OPxCT. In my experience, other than the two above, the values are extremely stable and predictable. Pretty much all of my test_* ROMs relied on this, and is the core basis for all of my cycle-accurate timings. I would suggest you to more thoroughly evaluate your theory, and provide stronger evidence. I'll never rule out that I missed something, but it's fairly unlikely in this case.
Arya-Iwakura
Looking into speedrunning Ultima VII The Black Gate (SNES), I found that the game has predictable and consistent "RNG" values on both hard and soft resets when using bsnes, however, on hardware, the values are random upon boot. This causes a discrepancy of the emulated version of the game vs the hardware version.
When disassembling the code, I found the random number generator reads in the horizontal and vertical scanline registers (OPVCT and OPHCT), and this seems to be always stable in emulator but on hardware is not exactly stable, causing non-predictable randomization.
I have confirmed with two others who were able to also show this was the case on their systems to ensure it was not simply my hardware causing issues.