Anonymous user
Luck manipulation (Generation I): Difference between revisions
Live and learn...
>Bbbbbbbbba (Explained the deviation of V-Blank timings to my best understanding.) |
>Bbbbbbbbba (Live and learn...) |
||
Line 20:
ld [hRandomSub], a
ret
Here, rDIV is the Divider Register, which is initialized to a fixed value during the booting process<!-- Is it 0 before BIOS? -->, and is incremented at a rate of 16384Hz (~16779Hz on SGB), or every 256 cycles.
(Note: In this article, the word "cycles" refers to T-cycles, where the CPU clock frequency is 4.194304 MHz. Since all instruction timings are divisible by 4, some people use M-cycles, which is defined as 4 T-cycles (or 1 nop). For the BGB debugger, the unit of all "CLKS" variables is 2 T-cycles (or 1 doublespeed nop), although their values may be slightly inaccurate when interrupts are involved.)
At the very beginning of the game's startup process (before the copyright screen), hRandomAdd ($FFD3) and hRandomSub ($FFD4) are zeroed with the entire HRAM; apart from that, Random_ is the only place in the code that directly changes them. If the exact timings and circumstances (actually only the carry flag matters) of those calls can be predicted (e.g. in a TAS or shortly after a hard reset), then the results can be predicted too. That's the principle behind luck manipulation.
Line 31 ⟶ 33:
<!-- TODO: Which things do matter? -->
There is one complication to the timing of the V-Blank interrupt. Usually, the game executes a "halt" instruction each frame after the necessary processing, to put the console in "sleep mode", and wait until an interrupt (usually V-Blank) wakes it up. However, when there is too much processing to do, or when the game is busy-waiting for user input, the V-Blank interrupt may happen before the "halt" instruction. In this case, the game
==DSum manipulation==
| |||