There are other types of delays Donkey Kong can do when rolling barrels besides what is described here, but to my understanding those occur under conditions which are not possible on the Kill Screen (such has having many barrels on screen).

So, here's an explanation of the possible delays he can do on the kill screen.

--

Donkey Kong can do two types of delays before rolling the 4th barrel on the kill screen. He will never delay on the first 3 barrels of a board. The first delay is based off of a global framecounter, which is constantly counting down from 255 to 0 and looping back to 255. At the moment DK is done rolling the 3rd barrel, he'll begin the process of rolling the 4th one. A flag is set to keep track of when DK is in the middle of deploying a barrel. At the moment this flag is set, the game will do a calculation based on the global framecounter. It takes whatever value the framecounter is at, and does and AND operation on it, with the number 1F in hex, or 31. Essentially, this 0's out the upper 3 bits of the number, and the remainder is anything from 0 to 31. At this point, it subtracts the current difficulty setting value from the remainder. Every level from 5 and up has a difficulty setting of 5, so on the kill screen it will subtract 5 from the remainder. Finally, at this point the value determines how many frames DK will delay for. The game checks if the value is equal to 5, 4, 3, 2, or 1. If it's not, it returns out of the function, and then the whole process starts over on the next frame.

Here's an example. If the frame counter was at 127 when the check was run, the calculation would go like this. Perform the AND operation to zero out the upper 3 bits (originally 127 is 11111110, and it becomes 00011110, or 30).

We then subtract the difficulty setting from 30, so 30 - 5, and we're left with 26.

The game will check if that number, 26, is equal to 5, 4, 3, 2, or 1. It's not, so the function returns, and this code isn't run again until the next frame. When we arrive here again, the frame counter has ticked down once, so the calculation is done with 126 instead. The result ends up being 25, then 24 the next frame, and so on until 26 frames pass and the result equals 5.

This scenario is the maximum initial delay that Donkey Kong can do- a delay of 26 frames. A framecounter value of 255, 127, or 63 will all yield a 26 frame initial delay.

At this point, IF the Bonus Timer is at less than half of its initial starting value (It starts at 400 on the Kill Screen, and it's now at 100, so this condition is TRUE), then the game looks at the value that's in address $6019. This address is essentially *one of* the game's "RNG" functions- though, it doesn't do a literal random number generation algorithm. Rather this number is constantly influenced by how much CPU time is remaining at the end of each frame. Any minute change in gameplay- different inputs, things happening on screen, even inserting coins into the machine- these all change the amount of time a frame takes to process, and therefore affect the "random" number occupying address $6019.

If the value in $6019 is even (the least significant bit is set to 0), then the function will return and run through everything again the next frame. This essentially means there's a 50% chance for Donkey Kong to delay 1 more frame.

This time through, the Frame Counter calculation results in 4 instead of 5. 4 is still one of the values it checks for to branch down to the RNG check, so it does that again. If it finds another even number, it will delay another frame. And so on. If you roll even numbers every time the frame counter is equal to 5, 4, 3, 2, and 1 (a 1/32 chance) then, finally, the calculation will be 0. This is not 5, 4, 3, 2, or 1, so the logic doesn't fall through to the RNG roll for an even number this time. It instead results in another 26 (+1 for 0, so 27) frame delay, as the calculation results in 0, then 26, then 25, and so on until arriving at 5 again. At this point, it starts rolling for even numbers again, and, it finds 5 even numbers in a row again, it would do yet another 27 frame delay.

Each pass through is a 1/32 chance. The odds increase exponentially.

1 extra delay -  1/32
2 extra delays - 1/1,024
3 extra delays - 1/32,768
4 extra delays - 1/1,048,576

...

19 extra delays - 1 / 32^19, or 39.6 Octillion


Which is more realistic, 1 in 39.6 Octillion luck, or executing 450+ frames straight of impossibly fast and precise inputs? :)

I'd say the latter, but I don't think that one is happening either. Thanks for reading! Feel free to dm me with questions or correct me on anything I may have gotten wrong.

The code for this is on line ~8805 in the disassembly.