It is currently Tue Sep 18, 2018 4:11 pm

 All times are UTC - 7 hours

 Page 1 of 1 [ 11 posts ]
 Print view Previous topic | Next topic
Author Message
 Post subject: NES Blaster Master Boss SkipPosted: Tue Sep 19, 2017 4:11 pm

Joined: Wed Jul 19, 2017 10:23 am
Posts: 78
The Boss Skip that had been observed during a live run during AGDQ 2017 can be seen here: https://www.youtube.com/watch?v=g5Hq2eA ... e&t=28m55s

I have observed that \$03FB will increment after you defeat a boss. From the beginning of the game this is set at value 0, then value 1 after the first boss, and then at value 3 after the second boss. In other words, if you overwrite the value of 3 into \$03FB just before entering the second boss fight then you will observe what we see in the video. The game thinks the boss was already defeated. I have observed that \$03FB increments the same frame that \$03FD reaches a value of 128. \$03FD starts at 0 from the beginning of the game and only does a 255 to 0 count down at the beginning of each boss fight, and then counts up from 0 to 128 upon the death of the boss. When this value reaches 128 then \$03FB, the address that tracks what bosses have been defeated, will increment.

Observation #1 The first boss loads normally which means that \$03FB is at value 0 when entering the first boss fight. If this value was 1 or higher then the boss would not spawn. The first moment that \$03FB normally increments is upon the death of the first boss, in which case it increments to 1.

Observation #2 Upon entering the second boss fight the boss did not load which means that \$03FB was already at a value of 3.

Conclusion: At some point this address is incremented again. My first suspicion is that it occurs after the first boss fight, that some how it is incremented twice. The later portion of this message shows "conditions" upon an overflow may occur that could possibly corrupt this address but it is still unclear exactly how these conditions could be met.

This is the most pertinent information that I have been able to find at this time.

I played around a little with the Chou-Wakusei Senki - MetaFight (J).nes ROM (GoodNES 3.14) after seeing that happen and will summarize some info here. Hopefully this will serve as a starting point for figuring out the glitch. I used FCEUX 2.2.3 and only played as far as the second boss fight.

After the scrolling ends when you enter a boss room, the following code is executed:

Code:
\$971A:A5 14     LDA \$0014
\$971C:29 07     AND #\$07
\$971E:AA        TAX
\$971F:BD 2B B6  LDA \$B62B,X
\$9722:60        RTS
\$9627:2D FB 03  AND \$03FB    <-- This is the important check
\$962A:D0 0F     BNE \$963B    <-- Branch taken if boss defeated
\$962C:A9 C0     LDA #\$C0
\$962E:85 51     STA \$0051
\$9630:A9 08     LDA #\$08
\$9632:20 8C C1  JSR \$C18C
\$9635:20 CD 97  JSR \$97CD
\$9638:E6 46     INC \$0046
\$963A:60        RTS
\$963B:20 1A 97  JSR \$971A

\$0014 is the value (current area - 1) at this point. At \$B62B, you find a sequence of increasing powers of two, starting with 0x01. Per Data Crystal's RAM map, \$03FB indicates which bosses have been defeated. So this checks if the boss of the current area has been defeated. If it has but the item has not been obtained, then the item is displayed. That seems to be what happened during the race.

If the boss has not been defeated, then the room flashes, the boss loads (including its health), and you proceed with the fight. It appears that the health of the first two bosses is hard-coded into the ROM. For area 1, the pertinent code is:

Code:
\$9C15:A9 80     LDA #\$80
\$9C17:85 53     STA \$0053

For area 2, the pertinent code is:

Code:
\$91FD:A9 40     LDA #\$40
\$91FF:85 53     STA \$0053

The value from \$0053 eventually ends up somewhere around \$0470, but the exact RAM address varies. If you change the health to 0x00 before starting the fight (e.g., set execution breakpoint on \$9C17, change A from 0x80 to 0x00, then continue emulation), the boss graphics load but immediately go into the death animation. This leads me to believe that whatever Skavenger did may have corrupted \$03FB. There are likely other possibilities, but I will let someone with more time and experience take over.

Actually, one other thing. This is the code that is executed when a boss is defeated:

Code:
\$971A:A5 14     LDA \$0014
\$971C:29 07     AND #\$07
\$971E:AA        TAX
\$971F:BD 2B B6  LDA \$B62B,X
\$9722:60        RTS
\$97A7:0D FB 03  ORA \$03FB
\$97AA:8D FB 03  STA \$03FB

Most if it should be familiar from that first block, but the last two lines update the value at \$03FB rather than testing it.

And another analysis:

I haven't looked at Blaster Master before, but this glitch got me curious, so a few observations from looking at the code in case they give anyone any ideas. Note that these are all from the English ROM (the only version I have handy), so if the glitch turns out to be JP-only then none of this may be of much use...

- The only stores to \$03FB are the one Dacicus quoted which is done on boss kill, and a few that store literal 0 or 255 (and the 255 clearly can't be the case because the rest of the bosses showed up properly). The store after the area 1 boss kill in that run can't have set the wrong bit, because then the boss would immediately respawn when the room was reloaded after the boss death.

- 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.) On the other hand, Personman's example of a case when both a boss and its item were missing could indicate a buffer overflow that wrongly set bits in both \$03FB and \$03FC, so I dunno.

- The boss-defeated store to \$03FB has this stack trace (again, addresses are from the English ROM - bank 4 is mapped to \$8000 here):

Code:
(0) A109: sta \$03FB
(1) A58C: jsr \$A07B
(2) C9D3: jmp (\$007A) = \$A58C
(3) C987: jsr \$C9A4
(4) C3D8: jsr \$C971

For \$A07B to reach the store to \$03FB, the following have to be true:
- \$0053 = 0
- The low bit of \$0010 is clear
- \$03FD >= 127
It does look like this routine is called for other purposes as well, so conceivably there could be a case where all those preconditions are (incorrectly) met, which would trigger the glitch.

Here's the relevant part of that routine:

Code:
A07B: A5 53     lda \$53
A07D: F0 10     beq \$A08F
A07F: AD FD 03  lda \$03FD
A082: F0 7B     beq \$A0FF
A084: CE FD 03  dec \$03FD
A087: D0 76     bne \$A0FF
A089: 20 18 A1  jsr \$A118
A08C: 4C FC A0  jmp \$A0FC
A08F: A5 10     lda \$10
A091: 4A        lsr a
A094: AD FD 03  lda \$03FD
A097: D0 0A     bne \$A0A3
A099: A9 0A     lda #\$0A
A09B: 20 16 C2  jsr \$C216
A09E: A9 0B     lda #\$0B
A0A0: 20 16 C2  jsr \$C216
A0A3: EE FD 03  inc \$03FD
A0A6: AD FD 03  lda \$03FD
A0A9: C9 80     cmp #\$80
A0AB: B0 53     bcs \$A100
(...)
A100: 20 0E C1  jsr \$C10E  // Only reachable from branch at \$A0AB
A103: 20 72 A0  jsr \$A072  // Get bit for current area (encapsulates "lda \$14" etc.)
A106: 0D FB 03  ora \$03FB  // Set boss-killed flag for current area
A109: 8D FB 03  sta \$03FB  // Store updated flag byte
A10C: A9 5A     lda #\$5A
A10E: 85 46     sta \$46
A110: A9 00     lda #\$00
A112: 20 1A C1  jsr \$C11A
A115: 68        pla
A116: 68        pla
A117: 60        rts

Top

 Post subject: Re: NES Blaster Master Boss SkipPosted: Wed Sep 20, 2017 6:51 pm

Joined: Wed Jul 19, 2017 10:23 am
Posts: 78
This is my first crack at this issue today. Thoughts are always appreciated.

At the beginning of the game when the memory is initialized, address \$03FB is set to #\$00. Perhpas a simple hack of the rom could have this value set to 2 and this would still allow the first boss to spawn and cause the second boss not to be present since \$03FB would be at value 3. Since the starting value is 2, then the amount it will increment is based upon the value 2 to the power of \$0014 value. Since area 1 boss is in \$0014 value zero, then 2 to the power of zero is 1, and therefore the resulting value of \$03FB after Boss one is 3. This of course is assuming that the rom was hacked.

Code:
STA \$0300,X @ \$03FB = #\$00 ;Initializing memory, setting address to zero

Upon entering the Boss 1 room the following executes. Notable is that it loads the value of address \$0014 to the A Register. When I used a Lua Script to change \$0014 to a value of 1, the value of Boss 2 location, I was able to get the Boss 2 to spawn in the Boss 1 area. The value of \$03FB is checked at this time. If the value is a 0, as it is supposed to be, then the Boss will spawn. If the value is 1, which it should be after the Boss fight, then the boss will not spawn. I also checked and even if this value was a 2 then the boss will still spawn. Basically here after the AND \$03FB instruction it will Branch on Not Equal as seen BNE \$963B.

Code:
\$961F:F0 03     BEQ \$9624                                    A:00 X:0A Y:00 S:FB P:nvUbdIZC
\$9624:20 1A 97  JSR \$971A                                    A:00 X:0A Y:00 S:FB P:nvUbdIZC
\$971A:A5 14     LDA \$0014 = #\$00                             A:00 X:0A Y:00 S:F9 P:nvUbdIZC
\$971C:29 07     AND #\$07                                     A:00 X:0A Y:00 S:F9 P:nvUbdIZC
\$971E:AA        TAX                                          A:00 X:0A Y:00 S:F9 P:nvUbdIZC
\$971F:BD 2B B6  LDA \$B62B,X @ \$B62B = #\$01                   A:00 X:00 Y:00 S:F9 P:nvUbdIZC
\$9722:60        RTS (from \$971A) --------------------------- A:01 X:00 Y:00 S:F9 P:nvUbdIzC
\$9627:2D FB 03  AND \$03FB = #\$00                             A:01 X:00 Y:00 S:FB P:nvUbdIzC
\$962A:D0 0F     BNE \$963B                                    A:00 X:00 Y:00 S:FB P:nvUbdIZC
\$962C:A9 C0     LDA #\$C0                                     A:00 X:00 Y:00 S:FB P:nvUbdIZC
\$962E:85 51     STA \$0051 = #\$00                             A:C0 X:00 Y:00 S:FB P:NvUbdIzC
\$9630:A9 08     LDA #\$08                                     A:C0 X:00 Y:00 S:FB P:NvUbdIzC
\$9632:20 8C C1  JSR \$C18C                                    A:08 X:00 Y:00 S:FB P:nvUbdIzC

At the beginning of the Boss 1 fight when the boss begins to load, address 03FD is set to the value 255 and then decrements to 0, at which time the boss begins to move. Upon the death of the boss address 03FD increments up to 128 from zero. Once 03FD reaches 128 (#\$80)then we see the following execute when the Comparision is made. It is at this time that the addition to \$03FB will be 2 to the power of the value of \$0014, the area locator. If at any time that \$0014 is changed via Lua Script then the game starts to glitch between where you are and where you are telling the game where you are. I have observed some funny things as a result of this. What this means is that I think that it is unlikely that the game was confused as to your location and therefore gave a different value in \$03FB, because it thought that you were in a different \$0014 location. If \$0014 was anything but 0 during the boss 1 fight then you would see graphical distortions. Since the addition to \$03FB only occurs after a boss is defeated it would be curious how it might occur at any other time, and if so, then how?

Code:
\$9C2D:20 23 97  JSR \$9723                                    A:2D X:2A Y:00 S:FB P:nvUbdIzc
\$9723:A5 53     LDA \$0053 = #\$00                             A:2D X:2A Y:00 S:F9 P:nvUbdIzc
\$9725:F0 10     BEQ \$9737                                    A:00 X:2A Y:00 S:F9 P:nvUbdIZc
\$9737:A5 10     LDA \$0010 = #\$14                             A:00 X:2A Y:00 S:F9 P:nvUbdIZc
\$9739:4A        LSR                                          A:14 X:2A Y:00 S:F9 P:nvUbdIzc
\$973A:B0 19     BCS \$9755                                    A:0A X:2A Y:00 S:F9 P:nvUbdIzc
\$973C:AD FD 03  LDA \$03FD = #\$7F                             A:0A X:2A Y:00 S:F9 P:nvUbdIzc
\$973F:D0 0A     BNE \$974B                                    A:7F X:2A Y:00 S:F9 P:nvUbdIzc
\$974B:EE FD 03  INC \$03FD = #\$7F                             A:7F X:2A Y:00 S:F9 P:nvUbdIzc
\$974E:AD FD 03  LDA \$03FD = #\$80                             A:7F X:2A Y:00 S:F9 P:NvUbdIzc
\$9751:C9 80     CMP #\$80                                     A:80 X:2A Y:00 S:F9 P:NvUbdIzc
\$9753:B0 4C     BCS \$97A1                                    A:80 X:2A Y:00 S:F9 P:nvUbdIZC
\$97A1:20 C9 C0  JSR \$C0C9                                    A:80 X:2A Y:00 S:F9 P:nvUbdIZC
\$C0C9:4C 5B D0  JMP \$D05B                                    A:80 X:2A Y:00 S:F7 P:nvUbdIZC
(...)
\$D066:60        RTS (from \$C0C9) --------------------------- A:0F X:FF Y:00 S:F7 P:NvUbdIzC
\$97A4:20 1A 97  JSR \$971A                                    A:0F X:FF Y:00 S:F9 P:NvUbdIzC
\$971A:A5 14     LDA \$0014 = #\$00                             A:0F X:FF Y:00 S:F7 P:NvUbdIzC
\$971C:29 07     AND #\$07                                     A:00 X:FF Y:00 S:F7 P:nvUbdIZC
\$971E:AA        TAX                                          A:00 X:FF Y:00 S:F7 P:nvUbdIZC
\$971F:BD 2B B6  LDA \$B62B,X @ \$B62B = #\$01                   A:00 X:00 Y:00 S:F7 P:nvUbdIZC
\$9722:60        RTS (from \$971A) --------------------------- A:01 X:00 Y:00 S:F7 P:nvUbdIzC
\$97A7:0D FB 03  ORA \$03FB = #\$00                             A:01 X:00 Y:00 S:F9 P:nvUbdIzC
\$97AA:8D FB 03  STA \$03FB = #\$00                             A:01 X:00 Y:00 S:F9 P:nvUbdIzC
\$97AD:A9 5A     LDA #\$5A                                     A:01 X:00 Y:00 S:F9 P:nvUbdIzC
\$97AF:85 46     STA \$0046 = #\$63                             A:5A X:00 Y:00 S:F9 P:nvUbdIzC
\$97B1:A9 00     LDA #\$00                                     A:5A X:00 Y:00 S:F9 P:nvUbdIzC
\$97B3:20 D5 C0  JSR \$C0D5                                   A:00 X:00 Y:00 S:F9 P:nvUbdIZC

Twenty nine frames after this addition to \$03FB occurs the \$971A sub routine runs again (twice). After the first sub routine it checks the \$03FB address, and then it will branch if not equal BNE \$963B, the same as when we entered the room. And the second routine is followed by a check to \$03FC, seeing if you have already collected the item, and then a branch if not equal BNE \$965C.

Code:
\$961F:F0 03     BEQ \$9624                                    A:00 X:0A Y:00 S:FB P:nvUbdIZC
\$9624:20 1A 97  JSR \$971A                                    A:00 X:0A Y:00 S:FB P:nvUbdIZC
\$971A:A5 14     LDA \$0014 = #\$00                             A:00 X:0A Y:00 S:F9 P:nvUbdIZC
\$971C:29 07     AND #\$07                                     A:00 X:0A Y:00 S:F9 P:nvUbdIZC
\$971E:AA        TAX                                          A:00 X:0A Y:00 S:F9 P:nvUbdIZC
\$971F:BD 2B B6  LDA \$B62B,X @ \$B62B = #\$01                   A:00 X:00 Y:00 S:F9 P:nvUbdIZC
\$9722:60        RTS (from \$971A) --------------------------- A:01 X:00 Y:00 S:F9 P:nvUbdIzC
\$9627:2D FB 03  AND \$03FB = #\$01                             A:01 X:00 Y:00 S:FB P:nvUbdIzC
\$962A:D0 0F     BNE \$963B                                    A:01 X:00 Y:00 S:FB P:nvUbdIzC
\$963B:20 1A 97  JSR \$971A                                    A:01 X:00 Y:00 S:FB P:nvUbdIzC
\$971A:A5 14     LDA \$0014 = #\$00                             A:01 X:00 Y:00 S:F9 P:nvUbdIzC
\$971C:29 07     AND #\$07                                     A:00 X:00 Y:00 S:F9 P:nvUbdIZC
\$971E:AA        TAX                                          A:00 X:00 Y:00 S:F9 P:nvUbdIZC
\$971F:BD 2B B6  LDA \$B62B,X @ \$B62B = #\$01                   A:00 X:00 Y:00 S:F9 P:nvUbdIZC
\$9722:60        RTS (from \$971A) --------------------------- A:01 X:00 Y:00 S:F9 P:nvUbdIzC
\$963E:2D FC 03  AND \$03FC = #\$00                             A:01 X:00 Y:00 S:FB P:nvUbdIzC
\$9641:D0 19     BNE \$965C                                    A:00 X:00 Y:00 S:FB P:nvUbdIZC
\$9643:A5 14     LDA \$0014 = #\$00                             A:00 X:00 Y:00 S:FB P:nvUbdIZC
\$9645:C9 07     CMP #\$07                                     A:00 X:00 Y:00 S:FB P:nvUbdIZC
\$9647:D0 0E     BNE \$9657                                    A:00 X:00 Y:00 S:FB P:NvUbdIzc
\$9657:A9 6A     LDA #\$6A                                     A:00 X:00 Y:00 S:FB P:NvUbdIzc
\$9659:85 46     STA \$0046 = #\$5A                             A:6A X:00 Y:00 S:FB P:nvUbdIzc
\$965B:60        RTS (from \$C8EC) --------------------------- A:6A X:00 Y:00 S:FB P:nvUbdIzc

While there may not be anything revelatoty here beyond the previous posts concerning the matter, but it is where I am at with it at the moment.

Top

 Post subject: Re: NES Blaster Master Boss SkipPosted: Thu Sep 21, 2017 2:27 pm

Joined: Wed Jul 19, 2017 10:23 am
Posts: 78
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

- \$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.

Code:
\$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...

Code:
STA \$0300,X @ \$03FB = #\$00 ;Initializing memory, setting address to zero

And then shortly after you defeat the Boss.

Code:
\$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...

Top

 Post subject: Re: NES Blaster Master Boss SkipPosted: Thu Sep 21, 2017 9:53 pm

Joined: Thu Jan 03, 2008 1:48 pm
Posts: 568
I want to provide you with key information that may help you with this... Values from \$8000+ cannot change in value unless they have been bankswapped through bankswitching. Find out which "mapper" MetaFight or Blaster Master is... Research the bankswitching portion for PRG ROM to figure out if you're seeing values change because of bankswitching.

\$8000-\$FFFF is ROM. These values CANNOT be written to... They can be addressed for external functions, such as mappers that perform bankswitching.

The address values for subroutines that you describe between \$8000-\$FFFF can change if they have been bankswapped.

Bankswitching is a way for the NES/Famicom to address more than 32K of PRG ROM in a quick fashion.

Please attach savestates and movie files for those of us who are not as good at videogames as you are.

Top

 Post subject: Re: NES Blaster Master Boss SkipPosted: Fri Sep 22, 2017 6:35 am

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20554
Location: NE Indiana, USA (NTSC)
Blaster Master is SLROM: 128 KiB PRG ROM, 128 KiB CHR ROM, no WRAM, MMC1.

Top

 Post subject: Re: NES Blaster Master Boss SkipPosted: Fri Sep 22, 2017 10:30 am

Joined: Wed Jul 19, 2017 10:23 am
Posts: 78
Thank you B00daW for that explanation, that \$8000+ is used for Rom explains why I could not add \$B62C to the Ram watch, and why I was not able to write a value to it via Lua Script. As for bankswitching/bankswapping I am not sure I quite understand except that I did observe that addresses like \$B62C were temporarily used when it loads the screen after death and loading the screen when unpausing it. Is this an example of bankswitching/bankswapping?

Thank you for the link Tepples.

Attached you will find the disassembly for Chou-Wakusei Senki - MetaFight (J).nes. This is the Rom on which this issue occurred so I am sticking with it. I did notice that the J version has only 6 references to \$03FB while the US version has 7 references. I did not check to see what was added to the US version. The J version was released first so I wonder why the developers thought to modify the US version to involve one more reference to \$03FB. Were they trying to fix something and if so is it relevant. See Zeronoid's analysis of some key differences between these versions, if interested, either way I am focusing on the J version. http://zeronoin.com/bm/0002.html

Attached you will also find three text files compiled by Trace Logger taking a one frame snapshot of when \$03FB is referenced. First when it is checked to see if you have beaten the boss, second after you beat the boss and if so it writes an updated value to it, and third, immediately after to see if this is still true before checking to spawn the item or not.

Shortly I will post the FM2 file for FCEUX which can be played in the TAS Editor up to and defeating the second boss.

Top

 Post subject: Re: NES Blaster Master Boss SkipPosted: Fri Sep 22, 2017 10:50 am

Joined: Wed Jul 19, 2017 10:23 am
Posts: 78
Attached is the FM2 file of a poor attempt at good game play It plays up to and defeats Boss 2. This Boss 2 is the one that did not spawn but the item did on one live occasion. I have not been able to duplicate this without a Lua Script to \$03FB. I used controller input recording in the TAS Editor and I have to say that FCUEX lags horridly when doing this. It is like playing the game at 1/8 the normal speed. I think that BizHawk does not lag in this same way and I wonder why that is.

Top

 Post subject: Re: NES Blaster Master Boss SkipPosted: Fri Sep 22, 2017 11:13 am

Joined: Wed Jul 19, 2017 10:23 am
Posts: 78
The following are 5 save states. I did not know how many would be appropriate so I created a save state just before entering a new \$0014 value location, and just before entering the Boss.

FC1 = Just before entering into \$0014 value 0 location from the starting 8 value at beginning of the game. This is when you are playing with the large walking character.
FC2 = Just before entering the Boss 1 fight in \$0014 value 0 location.
FC3 = Just before entering the \$0014 value 9 location. After the Boss one fight in \$0014 value 0 location we back track to value 8 and that is where we are before entering 9.
FC4 = Just before entering the \$0014 value 1 location. This is when you are playing with the large walking character again.
FC5 = Just before entering the Boss 2 fight in \$0014 value 1 locaiton.

Top

 Post subject: Re: NES Blaster Master Boss SkipPosted: Fri Sep 22, 2017 3:46 pm

Joined: Thu Jan 03, 2008 1:48 pm
Posts: 568
One of these days we should just tackle some things on Discord/Twitch or something and document the concrete things on DataCrystal. Those are some pretty valuable resources that I was not previously aware of...

I'll be frank with you, you seem to be spending a lot of time debugging, and you are learning, but you don't want to build upon logical fallacies too often... (Some of your code comments are fallacy.) Myself, I'm learning in many ways as well. I think given your commitment and interest you will easily surpass the skill level I have; but I am good at and like to teach.

I'll PM you my general schedule of availability for Discord/Twitch. Should be fun.

Top

 Post subject: Re: NES Blaster Master Boss SkipPosted: Wed Sep 27, 2017 9:04 pm

Joined: Wed Jul 19, 2017 10:23 am
Posts: 78
I have learned that this glitch occurred while using the Japanese Cart and converter that allows you to play it with an NES, and a Front-Loader. Skavenger, the one this happened to said that he had used that Japanese Cart 1000's of times with the converter and his front loader and has never had any issues with it.

Here is the information on the Japanese Cart: http://bootgod.dyndns.org:7777/profile.php?id=3923

And some information about regional differences: https://tcrf.net/Blaster_Master

I see it also has a hidden stage select and I am wondering if that too modifies the addresses pertinent to this project and if any of that code can be accessed in part during normal game play.

Top

 Post subject: Re: NES Blaster Master Boss SkipPosted: Wed Sep 27, 2017 9:24 pm

Joined: Thu Jan 03, 2008 1:48 pm
Posts: 568
A straight converter that's simply routing pins will not provide any additional logic that may affect address mapping or program changes. There is likely something that happened in that instance. We'll still have to do the research.

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 1 of 1 [ 11 posts ]

 All times are UTC - 7 hours

#### Who is online

Users browsing this forum: morskoyzmey, na_th_an and 2 guests

 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum

Search for:
 Jump to:  Select a forum ------------------ NES / Famicom    NESdev    NESemdev    NES Graphics    NES Music    Homebrew Projects       2018 NESdev Competition       2017 NESdev Competition       2016 NESdev Competition       2014 NESdev Competition       2011 NESdev Competition    Newbie Help Center    NES Hardware and Flash Equipment       Reproduction    NESdev International       FCdev       NESdev China       NESdev Middle East Other    General Stuff    Membler Industries    Other Retro Dev       SNESdev       GBDev    Test Forum Site Issues    phpBB Issues    Web Issues    nesdevWiki