why cane glitches crashes

Pinkus - 10/26/2017
I think the problem is $B7[0x2]
which is uninitialized in this case
yeah, I memory edited it to 0x8800 (which seems like a safe value) and swamp doesnt crash

nacitar sevaht - 10/26/2017
what's B7?

Pinkus - 10/26/2017
points to a table
one table per overlay
its uninitialized so we're loading w/e overlay was loaded last I think
possibly with a pointer that points to outside of the table or something
yeah, if we can clear/modify $BA or $B7 somehow, we'd be golden
no canes would crash

Pinkus - 10/26/2017
its about dynamic stuff inside dungeons. like stepping on a star tile, making a chest appear, probably hammering a peg
stuff like that matters for those variables
stuff that makes jingle noise generally
but it looks like they are set as you enter rooms too

Pinkus - 10/26/2017
anyways I think data is just written everywhere in ram
which is a good thing maybe
its like using map in FD dungeon
game tries to decompress invalid data and ends up putting jarbled values everywhere, including some graphics-related memory addresses
perhaps some hardware register is read from, which would act differently on console and (at least bad) emulators

Pinkus - 10/26/2017
oh lol
ye so I can see its writing all over hardware registers and stuff
so everything makes sense
now to figure out how to manipulate $ba and $b7..

Pinkus - 10/26/2017
Ok, generally every screen will have different values here, all of them unintended for our functionality. It's used for multiple things when loading a new room (so intra-transitions does not touch it). The last thing is generally loading a pointer to objects that should be drawn in the newly loaded room, so no way to manipulate that. In rooms that fade in/out (like GWG eastern) some code will run after the room is loaded, and it should be set to the same value every time I think.
I've yet to find anything we can do to manipulate but I'll read on more.
Applying overlay, whatever that entails, also changes it after the room is loaded. I tested walking on a star tile in room before mummy hellway and it changed. I'm not sure what other examples there are but seems to be 19 overlays(edited)

Pinkus - 10/26/2017
its the darkness
or, fade in/out
as noted above
so if there are more than one way to get to a supertile, and one of them includes a fade out/in effect (like staircases), those can be used to save it
also considering we're writing random data to random addresses, random things can save it too lol
basically the loop is waiting for the sequence $FF, $FF to stop. that can happen on the first try or .. never
in which case we'd write over a lot of shit
and concidering the values generally are random, unless there is a fadeout/in effect, or you happen to interact with some overlay, we get different glitches in different rooms, though they do look the same I guess..

Blank - 10/26/2017
so could be different results if you enter using staicases or not basically?

Pinkus - 10/26/2017
I think we can say that entering staircase will always be safe
you'll get the same value I think

Blank - 10/26/2017
In desert it's safe, but entering normally (by advancing in desert and going back) gives more beneficial gfx(edited)

Pinkus - 10/26/2017
yep makes sense
it has fade in/out upon entering the supertile coming from desert 2
then you change supertile and go back, and you get the real room value instead
so it's the reverse :>

Pinkus - 10/26/2017
so

1) red yba/prayer cutscene
2) doing transitions in different order
  - staircases
  - dark rooms
  - possibly others?
3) interact with overlay (only confirmed one is stepping on star tiles)

those are our options afaik

Pinkus - 10/26/2017
studying the ram addresses we overwrite, theres not much of interest. but doing the swamp one does 224 writes to hardware, most of which is undefined behaviour if you do it outside of vblank.
so the fact that emulators and consoles are different is not strange