I was testing this yesterday, it's because camera speed gets confused: it's 2 byte for whatever purpose. And these 2 bytes must be set accordingly, like whenever one is negative, the other must also be negative. But when you warp around the screen, one of them gets positive, another gets negative, resulting in value of -250 and such, and when the cam needs to actually scroll (when you arrive to the middle of the screen from the other side), it uses that speed value and goes way to the left, so that camera position is also around -250. Jump to contents of $22 happens when a new object is about to be spawned by scrolling (I guess?), but it gets written with values of $24, and that is what breaks I think. I was about to trace this for a few frames, but got tired. Hold on. Download GnG.lua

Language: lua
function stuff()
	Xcam  = memory.readwordsigned(0x64)
	DXcam = memory.readwordsigned(0x5d)
	Objects()
	--Sprites()
	gui.text(30,  0, DXcam) -- don't crop 8 scanlines to see
	gui.text(30, 10, Xcam)
end

function Objects()
	for i = 0, 0x15 do
		local color = "#ffaa00ff"
		local id  = memory.readbyte(0x4f0+i)
		local y   = memory.readbyte(0x509+i)
		local spr = memory.readbyte(0x522+i)
		local pal = memory.readbyte(0x53b+i)
		local x   = memory.readbyte(0x554+i)
		
		if id<80 then color = "#22ccccff" end -- offscreen
		if id> 0 then
			gui.text(x,y,string.format("\n%X",id),color,"#000000ff")
		end
	end
end

function Sprites()
	local base0 = 0x480
	for i = 0, 16 do
		local base = base0 + i*4
		local y   = memory.readbyte(base+0)
		if y==0xff then break end
		local spr = memory.readbyte(base+1)
		local pal = memory.readbyte(base+2)
		local x   = memory.readbyte(base+3)
		gui.text(x,y,i,"#ffaa00ff")
	end

end
gui.register(stuff)

And I doubt we can get any use of it. There's 3 ways to change the result: duck while you go to illegal area, jump, or be at the bottom of the screen. Can't go there while on top because there's no room for scrolling up there. Jump by $22 contents is related to object spawn and is determined by scrolling. $C1 contains object config offset ( I think), it looks like 2-byte. It is used to formulate the resulting jump pointer that is then stored in $22. So if you're at the bottom, scrolling goes downwards as well. It results in $C1 value that lets it formulate a somewhat legit pointer, so nothing special occures, even though $C1 value is still out of global bounds, the game only uses values up to $D02, and $C1 is $F01. We end up in random garbage that gets loaded as a map, and from my tests, there's nowhere to go there, you can't get back in bounds since there's some block on the very right, you can't go left since there's a pit with a wall on the left as well. If we're in the middle, the jump happens using $C1 value $F00, and it leads execution to RAM, however it's only the same address all the time, since it's what we get with $C1=$F00. It is sprite ram, that would work perfectly if not the fact that all old sprites get erased and some random garbage is loaded as well. Now, depending on your movement, garbage sprites start from 3 possible places, all the above (up to our broken jump address) is filled with $FF. $FF is an undefined opcode INS that takes 3 bytes, so PC goes in steps of 3, every time eventually getting to sequence $D0550280 in sprite RAM, but at different offsets. If we're standing still on a platform that moves us to the left, or running there, PC gets to $02 which is halt. If we're ducking, PC gets to $5502 which is EOR $02,X, and it eventually goes to reset vector (?). If we're jumping, PC gets to $D055 which is BNE $03F3, and it also leads to reset in the end.