I'm so glad the original (and fixed) Z80 code was shown, rather than some pseudocode or a C equivalent version. Now I actually get what the problem is -- all I've ever seen are descriptions of the problem.
I'm glad they're showing the actual assembly and walking through an example, but I think their explanation is incorrect. In particular, I follow how doubling #00FF gets you #01FE and doubling that gets you #03FC---and how this is effectively using the X value as overflow bits for 2s-complement arithmetic, thus causing this bug.
But, surely #00FF is still (0,-1) as it should be, with #01FE being (1,-2) (not (2,-2)) and #03FC being (3,-4) (not (4,-4))?
I'm also not 100% sure that the original authors would have chosen to fix it. I don't know how memory-constrained they were or how compute-constrained, but given that the "buggy" program still generates a target, still moves the ghost into the right general direction mostly, and is undetectable to users (except by extreme power-players), it's entirely possible that they would have decided to leave it. Also possible that they didn't know about it, of course, but I wouldn't be so quick to assume they'd definitely fix it, either.
