Teaching young dogs new tricks

[rimsky82]

"Probably" as in I never loaded up the game to debug it myself so I'm taking your word for it.

[nolberto82]

Is obvious when you look at the pictures of the debugger which is the best option. You don't even need to debug it.

[rimsky82]

It might be obvious to you nol, but this is a learning thread. For instance, I didn't know that you were invincible when you spawned, so I didn't realize the timer would be initiated when you started a level. Now it is obvious to me that negating the branch was the best option. If the timer started at 0 at the beginning of the game, then the bne would allow the timer to decrease anyway and could possibly crash the game. It doesn't in jackal's case, but it might elsewhere.

But, what I explained still works in other situations.

[nolberto82]

It doesn't matter if the timer is initiated or not. Address 0x52 is always being read so when you change BEQ to BNE it will not skip this the first time after the change:

07:E9E6:D6 52     DEC $52,X @ $0052 = #$00
07:E9E8:D0 09     BNE $E9F3
07:E9EA:BD 85 E9  LDA $E985,X @ $E985 = #$00
07:E9ED:9D 50 05  STA $0550,X @ $0550 = #$00
07:E9F0:4C 02 EA  JMP $EA02
07:E9F3:FE 50 05  INC $0550,X @ $0550 = #$00
07:E9F6:BD 50 05  LDA $0550,X @ $0550 = #$00
07:E9F9:C9 04     CMP #$04
07:E9FB:D0 05     BNE $EA02
07:E9FD:A9 00     LDA #$00
07:E9FF:9D 50 05  STA $0550,X @ $0550 = #$00

The next time it reads from 0x52 the value will be 0xFF and it will stay that way since it will be skipped by BNE. This will work in a lot of games that use this kind of code. The only way it will crash the game if the game doesn't like negative values.

[rimsky82]

The only way it will crash the game if the game doesn't like negative values.

Exactly what I was saying. Setting the N flag might screw with something that happens next. Plus, without debugging I couldn't know that 52 was always being read, since that code could be in a subroutine that's called when invincibility is obtained in the game.

It's good to have many possibilities at hand and consider the code than to just get in the habit of negating branches all the time. That's my only point.

[Pyriel]

Well, I expect bungholio was thinking BEQ was the disassembler's shorthand for something like "BEQ $0, $0, offset" in the MIPS instruction set. There's any number of ways you can approximate an unconditional branch if one isn't present. If there are operations that explicitly clear the condition code register or individual flags, those will work, or you could always xor a register with itself to ensure the zero flag is set, if nothing else is there. It's all down to what works best and fits in with the rest of the operations.

I mainly commented because I know bungholio was raised on a pretty steady diet of MIPS, so I thought I might have a good idea what he was thinking. I only know NES assembly to the extent that I looked up BEQ and BNE in the instruction set to confirm, and glanced at a few other operations.

[nolberto82]

Well that's what the debugger is for so you can check for that possibility. The probability of a game screwing up because a flag was changed are very rare unless there is an opcode storing or comparing. In this scenario the game is loading values regardless if the game is branching or not so the flags should change accordingly. I agree that there is many possibilities but you always have to try the ones that will make your life easier.