mm BA kamaro/romani softlock

mips info: http://wiki.cloudmodding.com/oot/Mips
mips info2 (more indepth):http://math-atlas.sourceforge.net/devel/assembly/mips-iv.pdf
n64 cpu info: https://en.wikibooks.org/wiki/N64_Programming/CPU_overview
n64 register info: http://wiki.cloudmodding.com/oot/Registers
natwa's ram map: https://goo.gl/hm0n0v
BA write info (addresses are mupen and us, relative difference is what matters): https://goo.gl/zjxjIl

rom: Zelda no Densetsu - Mujura no Kamen (Japan).n64 (jp 1.0)
	MD5 hash:  44dbde0232b67654b3a4251d599cc713
all addresses are used in nemu, idk how to convert to real addresses. Should probably talk to mzx about that at somepoint.

kamaro/Romani BA softlock byte: jp 1.0  0x801f372e (I will refer to it as kbas Kamaro BA Softlock)
	-This is row row 2 Kamaro, row 3 Romani, row 4 keeton

This memory addressed is read under 7 circumstances I know of: 1) every frame, 2) a special refernce when spawning textboxes, 3) a special reference loading a new area, 4) being a transformation and having text on B button? (not sure if in certain areas or in general), 5) being in the pause menu, 6) pulling out ocarina, 7)scrolling text? or cs? or textbox background is on screen? (during the you get magic cs). 2) and 3) both softlock but don't execute the same instructions, I will need to look more into why each soft locks.


Here are relevent instructions realted to this address. (Not comprehensive and slowly adding as I begin to understand

1) This address is reference (almost) every frame w/ relevent parts (again not comprehensive slowly adding):
8011AA08: lbu $t9,0x372e($t9) ;$t9=0xFFFFFFFF801F0000
	--load byte unsigned (0x372e + 0x801F0000=)0x801f372e into register t9
8011AA0C: lui $at,0x081c
	-- load upper immediate (sign extended), $at = (0x081c<<16)=0xffffffff801c0000
8011AA14: sll $t1,$t9, 0x2
	-- bit shift and store, $t1 = $t9 << 2
8011AA18: addu $at, $at, $t1
	-- add unsigned, $at = $at + $t1
8011AA1C: lwc1 $f8, 0xa82c($at)
	-- load word to coprocessor 1 register $f8, $f8 = memory[$at + 0xa82c]
	-- coprocessor 1 in this case is the fpu, floating point unit
	-- in the intended case 0x801f372e = 0, $at = 0xffffffff801c0000
		-- somehow, 0xffffffff801c0000 + 0xa82c = 0xffffffff801ba82c
	-- in the BA softlock case case 0x801f372e = 17, $at = 0xffffffff801c005c
		-- somehow, 0xffffffff801c0000 + 0xa82c = 0xffffffff801ba888

Manually changing the value of 801ba888 to the value of 0x801c005c doesn't prevent the soft lock. Thus this call cannot be the cause of either softlock.

Curiosly, the game stops this refernce on the few frames before currernt area is unloaded.


2) This is also read when spawning a textbox and called once for one frame when the textbox spawns, thus the softlock must be here:
80152114: lbu $t9, 0x42ce(v1); $v1=0xffffffff801ef460
	--load byte unsigned (0x42ce + 0x801F0000=)0x801f372e into register t9
80152120: bnez t9, 0x8015215c
	--branch not equal zero, if $t9 (not edited from instruction 80152114) isn't 0

Now, if 0x801f372e == 0, then instructions 80152128-80152154 execute and 80152154 branches to 80152184.
If 0x801f372e != 0, then instructions 80152154-80152180 execute and then proceeds to 80152184
Now undr both cases, execution continues to instruction 8015284, and (it seems) this area of the game isn't executed until the next textbox spawn. Thus the cause of this softlock should be in the difference between these 2 sets of instructions.

3)These are the calls related to loading a new area of the game's code:
80123ad4: lbu $t1, 0x4ce($a3) ; $a3=0xffffffff801ef460
	--load byte unsigned (0x42ce + 0x801F0000=)0x801f372e into register $t1
80123ae0: bnez $t1, 0x80123af0
	--branch not equal 0, if $t1(unchanged than the load @ 80123ad4) != 0 then branch to 0x80123af0
Similar to 2), there are a few instruction differences between the softlock byte being 0 and not 0, but after the few differnces the games continue execution at the same instructin (80123af4). The differnce here is there is like only 3 instruction differnce instead of the dozon or so in 2).
if $t1==0, 80123ae0-80123ae8 are executed and t=80123ae8 branches to 80123af4.
if $t1!=0, 80123af0 is executed then proceds to 80213af4

4)8011a284 //ToDO

5)8011a03c //ToDO

6)80152114 //ToDO
  801521ec
  8011a03c

7)80(lots of addresses, need to look into mostlikely) //ToDO

---------------------------------------------------------------------------------------------------------------------------------------

The actual softlock

The actual softlock for BA with Kamaro happens not at any of the above mentioned instructions. When catching HSW, on or around the frame link holds the bottle up and the camera starts to pan are the instructions that cause the soft lock. 1 additional reads:

80152114: lbu t9,0x42ce($t1); $t1 = FFFFFFFF803FB5F8
	-- load byte unsigned from 0x803FB5F8+0x42ce=0x801f372e (soft lock byte)
instructions 80152118-801521e8 are not responsible for the soft lock. Manually changing the value of kbas to 0 after before 801521ec with some memory editing software will not cause the soft lock

801521ec: beql $t2, $r0 80152264								|--> 801521f0 is the branch delay for 801521ec. If this instruction
	--branch if $t2 == $r0										|	 were add $t6, $r0, 0x0 kbas wouldn't happen. I should see
801521f0: lbu $t6, 0x42ce($v1) ; $v1=0xFFFFFFFF801EF460			|	 make this modification and see what other effects it has on the
	-- load unsigned byte, $t6=*(0x42ce+0x801EF460)=*(kbas)		|    game.

80152268: bnez $t6, 801522e4
	-- branch to 801522e4 if $t6 (unchanged from 801521f0) != 0
	--This is part of the cause of the soft lock. If I change the value of kbas after this instruction executes the soft lock still occurs, so somewhere after this branch is the "meat" softlock.