Lunar_Legend.txt

Hmm mmm hmm... Black Screen of Despair... Kill it...

It seems to get stuck in a loop. It's still executing opcodes, but it's just stuck. The relevant PCs are:

===============================
0x8017054
0x8017056
0x8017058
0x801705a
0x801705c
0x801705e
0x8017060
0x8017062
===============================

*Do working emulators even touch this code?
*If so, what values does the code expect, and what do the emulators give that I don't?
*If not, where do things break down? Where does it jump to invalid code?

-Can confirm, this is invalid code!

-0x08010e00 is a known good point. From there, it only goes south.

-Okay, the issue is that GBE+ jumps @ 0x8010E06 0xE1AD, Branch 0x8011164. It should never hit this code during boot.
-The game runs LSL R0, R0, 0x10, then CMP R0, 0x0 and expect them to be equal.
-It works alright in GBE+ until some stupid, crazy value is set for R0

*What is the crazy, stupid value?
-It appears to be 0x80ff0000 after the shift, so the value is originally 0x80FF

*When does GBE+ set R0 to 0x80FF?
- @ 0x8056804 0x4801, LDR R0 0x80FF. GBE+ misses the BCC right above it
-Prior to this, it read the value at [0x3005C00], which should be 0x87F811C, then it reads [0x87F811C + 4] which should give a result of 0x400.
-GBE+ read from [0x087f8110 + 4] and gives a value of 0x40. R3 counts up

*When is [0x3005C00] set to 0x87F811C?
- @ 0x8056628 0x6008 STR R0, R1. GBE runs this code, however, it seems it later sets [0x3005C00] to 0x087F8110 (because R0 not equal to 0x40, BNE @ 0x8056622)


	1st iteration of 0x8056628, GBE+ sets R3 to 0x7FFF.
	This should be rest by VBlank interrupt.
	MAJOR problem, after VBlankIntrWait SWI @ 0x8056600, GBE+ seemingly passes up the BX R14 opcode!!
	The LR register should be 1 instruction size shorter!
	This prevented the game from booting, wow


==================================================

I killed the black screen of despair, but enemies abound... the game won't get past the New Game state (not often anyway).
Before that, let's checkout an out-of-bounds write near the intro


==================
Out of bounds write : 0x430055d7
Out of bounds write : 0x430055d6
Out of bounds write : 0x430055d5
Out of bounds write : 0x430055d4
==================

*Why does this happen in GBE+?
*Does it happen in other emulators?
*If not, how to fix it?

-Set at 0x300184C, ADDS, R5, R5, 0x40000000


=========================================================
-So, I somewhat fixed the out-of-bounds write, at least I changed it. It now writes

==================
Out of bounds write : 0x830055af
Out of bounds write : 0x830055ae
Out of bounds write : 0x830055ad
Out of bounds write : 0x830055ac
==================

-Here's the theory. These are all supposed to be writes to Fast WRAM. If you drop the first 4 MSBs, you get an address that pretty much lines up with that address space.
-Some instruction is probably messing with the top 4 MSBs, causing shit to happen.
-No other emulators report out-of-bounds writes here at this time, so the fault is on GBE+
-It seems I may be onto something. Observe that at 0x3001850 it executes the following:
	-ARM_9 : 0xe4856004
-R5 seems to be the dest. addr. and it equals 0x830055b0 after a certain time. However, it correctly write to WRAM before a certain point.
-After some event, it looks like it adds 0x40000000 to R5 twice.

-@ 0x3001848, the game executes ARM 5 -> 0xe2955101. Perhaps this is a decoding error? What do other emus do at this point?

-That's right before shit hits the fan. Crap. Closer analysis shows my thoughts yesterday were spot on! LR is incorrectly set, so it skips one instruction (in this case, an ADDS R5, R5, 0x40000000 instruction), and goes straight to the BCC! Here's the thing. The way GBE+ is set up, only ARM code seems to suffer from this error! Yikes...