[SM] Sprite tilemap byte 2 question

[Munchy]

Just to make sure I'm leaving no stone unturned, i thought I'd ask a question about a nuance in the tilemaps for Samus.

@Kejardon, perhaps please you would know?

here's the first tile of Samus facing the screen when you load the game:

Code Select Expand


(samus) fc c3 f0 00 28


C3 is >= $80 and should therefore load 4 tiles (2 x 2) from VRAM. it's also an odd number (which it would have to be, because the previous byte has told the game to load Samus at a negative x coordinate.

but subtract $80 and $1 from $C3 and we're left with $42.  It isn't clear from faffing around in JSM or the SadFish document exactly what the value $42 does.   I mean, obviously, it's the answer to life the universe and everything (which is definitely true if you're a Metroid nerd), but I'm still at a loss as to whether it has any functional significance... If it doesn't, I'd be thrilled to suggest it's an easter egg  :lol:

[Crashtour99]

To my knowledge, Samus' sprite tilemaps are the only ones in the game that are like this, and no one really knows why.  There doesn't appear to be any actual use for those bits being set in that byte.  It may in fact just be a leftover from the development process, something to differentiate Samus tilemaps from the rest. 

Kind of like how in the Animation Disassembly there's this part near the end:
;OAM x/y positioning of arm cannon opening gfx relative to Samus
;first byte - if high nybble is negative ($80+), use 2nd argument
;             if positive use as arm cannon firing direction index (00-09)
;second byte - unknown purpose
;second argument - first byte - high nybble is ignored, low nybble used as arm cannon firing direction index
;                  second byte unknown purpose
;string of bytes after opening argument/s are x/y offset pairs
If the first byte says to use the second argument, then why even have the first argument???  Weird things that we may never know.  :lol: