The following are ideas that I have examined concerning what could have occurred. This list at least helps to rule out some possibilities and should help to stir further thought. First some basic information. Also all of my investigation concerns the Japan rom
Chou-Wakusei Senki - MetaFight (J).nes
Pertenient Addresses
- $0014 = This is the Area Locator, this tells the code where you are.
- $03FB = This is the Boss Kill Accumulator. Each time you kill a Boss this address updates, adding 2 to the power of $0014 value.
- $B62B = This is a basic value store that is a value of 1 most of the time, but on pause and death transitions is temporarily used but then reverts back to its base value. Likewise, $B62C is a value of 2. This will be important later.
- $03FD = This seems to be a Boss Counter. When the Boss begins to load it jumps from 0 to 255 and then decrements each frame down to 0, at which point the Boss begins to move. Once the Boss is defeated and stops moving this address runs from 0 to 128 incrementing once every two frames. Once this value gets 128 then $03FB updates. The value remains 128 until the next Boss loads.
Pertenient Code
This subroutine runs a total of three times during the boss fight. Once before, once upon death of boss, and then before item appears. It basically checks to see where you are located, first to see if that Boss has been defeated when entering the room, then again to see if the Boss was killed, and if so, it checks again to before spawning the item appropriate for that area.
$9624:20 1A 97 JSR $971A A:00 X:0A Y:00 S:FB P:nvUbdIZC ;Jump to Subroutine $971A
$971A:A5 14 LDA $0014 = #$00 A:00 X:0A Y:00 S:F9 P:nvUbdIZC ;Load value at $0014 into A Register
$971C:29 07 AND #$07 A:00 X:0A Y:00 S:F9 P:nvUbdIZC ;Bitwise AND Immediate Mode
$971E:AA TAX A:00 X:0A Y:00 S:F9 P:nvUbdIZC ;Transfer A value into X Register
$971F:BD 2B B6 LDA $B62B,X @ $B62B = #$01 A:00 X:00 Y:00 S:F9 P:nvUbdIZC ;Load ($B62B + X) into A. If X = 1 then $B62C
$9722:60 RTS (from $971A) -----------A:01 X:00 Y:00 S:F9 P:nvUbdIzC ;Return from Subroutine $971A
There are only two occasions when I observe $03FB gets written to. First, when the game initializes its memory...
STA $0300,X @ $03FB = #$00 ;Initializing memory, setting address to zero
And then shortly after you defeat the Boss.
$97A7:0D FB 03 ORA $03FB = #$00 A:01 X:00 Y:00 S:F9 P:nvUbdIzC ;Bitwise OR Zero Page Mode
$97AA:8D FB 03 STA $03FB = #$00 A:01 X:00 Y:00 S:F9 P:nvUbdIzC ;Store A value into $03FB
Hypothesis #1 Rom Modification/Corruption
Basically any alteration of the code in address $03FB to initialize as a value of 2 instead of 0 at the beginning of the game would cause the boss not to spawn in area 2 but everything else would function the same. The same is true if the Rom was modified
so that $B62C had a base value of 1 instead of 2. Nothing else would be effected it seems.
Hypothesis #2 $0014 Confusion
$0014 tracks where you are located in the game and is part of the code that executes to check if the boss needs to spawn. If this value was different then the comparision results would be different. Subroutine $971A loads the value of $0014 into the
A Register, this is then transfered to X, and this determines whether it will compare $03FB with $B62B or if it will, for example in the case of X having a value of 1, compare $03FB with $03FC, etc. The problem is that when $0014 is altered via Lua Script
it causes graphical problems and your character essentially warps to the other location since the game thinks that you are there. This would be easily seen in the run if this were ever to occur. Therefore, it is reasonable to assume that $0014 is always
functioning correctly.
Hypothesis #3 Wrong Value in $B62C
It would be possible for the second Boss to be skipped if $B62C were a different value than its base value of 2. This is one of the addresses that is involved in the comparison with $03FB. Since in the second Boss area $0014 will be a 1, and since this value is
transfered to the X register, then $B62B,X will always be $B62C, so there is no way it will reference any other address during this check, since we have concluded that $0014 was functioning correctly. If $B62C was a different value, such that it was a 1
value instead of 2, then the second Boss would be skipped because the Equal check with $03FB having a value of 1 would check out. I would need to see how the 2 value is written to this address throughout gameplay to determine it this value could be altered through any other means.
I have observed that $B62C does temporarily change when loading the screen after death and after unpausing the game, but then this value reverts back to the base number 2. I have paused the game one frame before Subroutine $971A occurs and then unpaused the game to manipulate $B62C to change but the $971A Subroutine does not execute until 7 frames after $B62C reverts back to 2. Therefore the only manipulation of this address can not be used to confuse the subroutine.
However, as good as this sounds, the $971A Subroutine also runs just before spawning the item and if $B62C was the cause of the Boss not spawning, this would also cause the item not to spawn. This has been observed, and one simple explanation is that
one of these B6xx addresses were a different value than it is supposed to be upon check. But if this is the case, then we have two different issues that occur. One where an $B6xx address is not what it is supposed to be and something else. I would like
to think that the two observations, no boss with item, and no boss without item, are related to the same issue.
Hypothesis #4 Additional Increments to $03FB
As we have observed by looking at the $971A Subroutine, assuming our conclusion that $0014 will always be correct, and assuming that there is no way to alter the $B62C value, then $03FB will always update with the appropriate value upon defeating the Boss. Could it be possible that this bit of code ran twice upon defeating the Boss or executed some other occasion during the run? If the code ran before the first boss kill in the area before you are the large walking character then $0014 would be an 8
and so the value of $03FB would be 2 to the power of 8, which is a very large number. If it occured while you are the large walking character then this would update $03FB with a 1 and therefore it would also skip the first Boss. If dual execution occurred after
defeating the first Boss then this would be a value of 2 which is sufficient to skip the second Boss. Likewise, if the Boss death update to $03FB occurred while large walking character just before the second Boss fight then it would update to a 3 which is also
sufficient to defeat the Boss.
Is it possible for this code to execute some other time? Could it execute twice upon defeating the first Boss? While I think that the second is more likely to occur because it is actually being executed at that time, it does seem unlikely that it would update
twice, and upon closer examination I suspect that this will be the case, but is still a stone to be turned.
Hypothesis #5 Overflow to Address $03FB
This hypothesis has basically been explained by vaxherd but wanted to document it again in this list. "The only indexed stores that could reach $03FB are the stores to the PPU RAM write buffer at $0300. I played up to area 2 to check, but the buffer
high water mark was $0340, and a cursory review of the code suggests it's pretty good at flushing the buffer before it overflows, so it seems unlikely to me that a buffer overflow is the cause. (Also, in order to have disabled only the second boss, the store value would have to have been $02 or $03, which seems unlikely for an arbitrary PPU data store; and if the buffer overflowed all the way up to $03FB then it would stomp on lots of other stuff in the $03xx range, which would probably cause more problems than just a missing boss.)"
The search continues...
