How to make invincibility codes?
With FCE Ultra, I just save a state before the effect I want to test for is active, then activate the effect as soon as possible(to keep other values from interfering), then save the state as small an amount of time into having the effect as I can.
I then leave the memory window open to visually test for things that change in the memory window as I load state 1, then state 2 over and over, and then re-test the values I find by re-activating the effect in the original save-state.
If a value seems to be exclusively for the effect I want, I put a breakpoint to it in the debugger for write tests, activate the effect again in the original save state(with the debugger window still open), and it stops on the instruction that caused the change.
I then get into more intimate knowledge of assembly and try to find what piece of code should Always or Never be activate to get the effect I want(for death routines, the value is often just one of many that are affected). In my experience, Never is easier to re-program for than Always.
I still tend to look for the instruction I want in the game's code, and modify it for my use. The idea for Never is to make the code do nothing in the fewest number of address changes as possible. For the rainbow island Infinite Lives code, it involved 1 code to change an address to a 'Load A with 00' instruction right before a 'Load A with 01' instruction'.
For gradius 2, I think of the code as a 'Never run the code past the RTS' code.
For gradius 1, it's 'At the start of the code jumped to, Always return to where you would've at the end of this code segment', which required 3 addresses to be changed to a complete JMP instruction with a full address.
I say it's simple because the code was straight-forward and easy to reprogram, but kind of taxing to try and figure out if there was a way of doing everything needed with 1 byte change.
With FCE Ultra, I just save a state before the effect I want to test for is active, then activate the effect as soon as possible(to keep other values from interfering), then save the state as small an amount of time into having the effect as I can.
I then leave the memory window open to visually test for things that change in the memory window as I load state 1, then state 2 over and over, and then re-test the values I find by re-activating the effect in the original save-state.
If a value seems to be exclusively for the effect I want, I put a breakpoint to it in the debugger for write tests, activate the effect again in the original save state(with the debugger window still open), and it stops on the instruction that caused the change.
I then get into more intimate knowledge of assembly and try to find what piece of code should Always or Never be activate to get the effect I want(for death routines, the value is often just one of many that are affected). In my experience, Never is easier to re-program for than Always.
I still tend to look for the instruction I want in the game's code, and modify it for my use. The idea for Never is to make the code do nothing in the fewest number of address changes as possible. For the rainbow island Infinite Lives code, it involved 1 code to change an address to a 'Load A with 00' instruction right before a 'Load A with 01' instruction'.
For gradius 2, I think of the code as a 'Never run the code past the RTS' code.
For gradius 1, it's 'At the start of the code jumped to, Always return to where you would've at the end of this code segment', which required 3 addresses to be changed to a complete JMP instruction with a full address.
I say it's simple because the code was straight-forward and easy to reprogram, but kind of taxing to try and figure out if there was a way of doing everything needed with 1 byte change.


Comment