Sorry to be a pain, but I don't think your latest iteration of the 'Through the Wall' entry in your Manic Miner disassembly is quite accurate yet:
"This happens because the section of code at 35600 - which is executed during jumping animation step 16, after Willy's y-coordinate has been updated so that he's exactly one cell height above the place he jumped from, but before his x-coordinate has been updated - checks whether there are any nasty tiles in the cells below Willy's sprite. If there are (as is the case here), the code jumps forward to 35665, which makes Willy proceed to the next jumping animation step (as if the bricks were not there), instead of landing on the bricks."
Regarding the text highlighted in bold, if you look at the illustration for Jumping Animation Step 16, you will see that there aren't any Fire cells under Willy's sprite (there are actually two 'brick' Earth cells).
Part of the confusion relates to the text highlighted in the quote above in italics. In fact, if you consider a jump from start to finish, it's actually the other way round - Willy's x-coordinate is updated before his sprite is drawn to the screen, but his y-coordinate is updated after his sprite is drawn. (More comments on that later*.)
Now, during a jump the check for Fire cells (to determine whether to jump forward to 35665) can only be determined when the Jumping Animation Counter has reached a value of 16 (or 13). However, this takes place after the Jumping Animation Counter has been incremented by the command at 36355. But the Jumping Animation Counter is used to calculate Willy's current y-coordinate at 36330 i.e. before the Jumping Animation Counter is incremented.
As a result, as far as your illustrations are concerned, the pertinent check for Fire cells is taking place at Step 15. At that point, Willy's 'physical presence' is cell-row-aligned, with his back foot directly above the left-most Fire cell (and his front foot above the adjacent 'brick' Earth cell). However, because the y-coordinate of his sprite hasn't been updated yet, there appears to be a vertical gap (of three pixels) between Willy's back foot and the Fire cell.
In contrast, at the point in time represented by the illustration for Step 16, Willy's 'physical presence' is four pixels lower than where his sprite is drawn, so he is not cell-row-aligned. By now, the Jumping Animation Counter has reached a value of 17, so the checks for Fire cells beneath him are not reached (but in any case he has moved past the cell-column boundary, so he is no longer straddling a Fire cell).
* As for the order in which Willy's x- and y- coordinates are updated, this is counter-intuitive because the code that progresses Willy's y-coordinate in a jump is at Move Willy (1) i.e. before the code at Move Willy (3), which moves him sideways and causes him to pass from one cell-column to the next.
[The 'Draw Willy' routine of course comes after the 'Move Willy' routine in the Main Loop.]
However, because the check for Jump keys (which initiates the jumping sequence) is in Move Willy (2), each incrementation of the jump is drawn with the adjustment of the y-coordinate lagging behind that of the x-coordinate. i.e. What you see on the screen is a 'snapshot' taken after Willy's x-coordinate has been moved on, but before his y-coordinate is updated.
You can see evidence of this at the end of the jump. It's the reason why he appears to drop from 4 pixels up, to his final landing position, without his frame of animation being updated (it's 'left-facing frame 2' in both cases; see your illustrations for Jumping Animation Step 17 and 18 - both of which actually represent Jumping Animation Counter values of 18, for the reason discussed earlier). In the last time-frame of his jump, his sprite is drawn before his y-coordinate is updated. Then the next time the program passes through the Main Loop, his sprite's position is updated to reflect his true y-coordinate.
(I haven't checked this yet, but if either a 'Left' or 'Right' movement key were kept depressed throughout the jump, then the illustration for 'Step 18' may not be as shown - he would either have moved on to 'left-facing frame 1', or else turned around to be in 'right-facing frame 2'.)
You can also witness the 'lag' of the y-coordinate behind the x-coordinate if you study the very beginning of the jump, when Willy appears to walk forward by one frame of animation before starting to ascend. Which doesn't make sense if he's jumping from a position at the edge of a precipice - his sprite appears to walk off the edge (with no supporting structure beneath him) before the jump commences. But again, it's because in the first time-frame of his jump, his x-coordinate is updated before his sprite is drawn, but his y-coordinate isn't.
Apologies if all that was a bit long-winded, but if I were to try and summarise it:
The current illustrations in the MM disassembly represent 'snapshots' taken before Willy's vertical pixel coordinate has been updated, and before the Jumping Animation Counter has been incremented. Unlike your previous set of illustrations, the latest ones reflect exactly what is seen on the screen. However, the previous snapshots showed where Willy is located immediately prior to the check for Fire cells underneath him (and the current value of the Jumping Animation Counter at that point), and so they did actually provide a better representation of what is occurring with this quirky aspect of the game engine!
Edited by IRF, 27 May 2016 - 03:10 PM.