Hey there. So... Streets of Rage 2 has this functionality where the default life points (health value) are assigned, and each time a player dies, they receive that same number of life points for their next life. I'd like to break the code up a bit, such that the first life is assigned fewer life points, and then when a player dies, their next lives are full lives (0x68 life points). I've written some VERY rudimentary ASM and am looking to see if someone wouldn't mind reading through the code and letting me know what fatal flaws I've written. There are, for certain, syntax errors, and I'm using certain 65c816 mnemonics, as I don't know the 68K equivalents yet. My beq v. bne is probably also going in the wrong direction. I also plan to inject the code straight into the ROM via the equivalent hex bytes and test the functioning once the code makes sense. Any help you can provide would be much appreciated! (I tend to credit folks in game and/or on the distribution site and within the readme.) Code (Text): ;========================================= ;Streets of Rage 2 ;Initial Health Code Modifications v7 ;========================================= ;----------------------------------------- ;Purpose: Hijack the code before the 1st ;stage starts and send it to another area ;in ROM to add functionality to two more ;RAM bytes. ;----------------------------------------- org $00005CBE ;offset to hijack ; lea ($00005D74),A6 ;4D F9 00 00 5D 74 ;original (hijacked) $5CBE code jsr $00024E00 ;4E B9 00 02 4E 00 ;jump to new code location ;----------------------------------------- ;Purpose: Set two unused RAM bytes to zero ;before a game (stage 1) starts. ;These bytes will be changed so the health ;value increases to 0x68 whenever a player ;dies, but the very first life should have ;a health value much less than the default ;0x68. ;----------------------------------------- org $00024E00 ;offset to hijack move.b #$00,$F0BE ;11 FC 00 00 F0 BE ;create a player 1 parameter (1 byte) move.b #$00,$F0BF ;11 FC 00 00 F0 BF ;create a player 2 parameter (1 byte) lea ($00005D74),A6 ;4D F9 00 00 5D 74 ;original (hijacked) $5CBE code rts ;4E 75 ;return to hijacked location and continue code ;----------------------------------------- ;Purpose: The byte with the initial health ;value is at offset $7EC8. ;Need to modify this code to split the ;commands such that the initial value is ;reduced, but all lives after receive a ;larger health value (the old 0x68). ;----------------------------------------- org $00007EC8 ;offset to hijack ; move.w #$0068,$0080(A2) ;35 7C 00 68 00 80 ;this is the original code at $7EC8 jsr $00024E50 ;4E B9 00 02 4E 50 ;jump to new code location org $00024E50 ;new code to split out 0x68 health per player after death addq.b,#1,$F0BE ;52 38 F0 BE ;increment new player 1 byte addq.b,#1,$F0BF ;52 38 F0 BF ;increment new player 2 byte cmpi.b #$01,$F0BE ;0C 38 00 01 F0 BE ;P1 RAM byte should be #$01 the first stage, first life beq.s splithealth ;67 10 ;if equals #$01, give #$01 in health; else, give health of #$68 cmpi.b #$01,$F0BF ;0C 38 00 01 F0 BF ;P2 RAM byte should be #$01 the first stage, first life beq.s splithealth ;67 08 ;if equals #$01, give #$01 in health; else, give health of #$68 move.w #$0068,$0080(A2) ;35 7C 00 68 00 80 ;this is the original code at $7EC8 rts ;4E 75 ;looking to jump back to $7ECE -- clr.w $00A8(A2) splithealth: ; move.b #$68,$EF80 ;11 FC 00 68 EF 80 ;$EF80 appears to be where the default health value comes from; modifying original $7EC8 code may be better ; move.w #$0068,$0080(A2) ;35 7C 00 68 00 80 ;this is the original code at $7EC8; seems to do the same thing my code above would have move.w #$0001,$0080(A2) ;35 7C 00 01 00 80 ;change #$68 to a lower number, so when $F0BE or $F0BF = #$01, that player starts game with less life rts ;4E 75 ;looking to jump back to $7ECE -- clr.w $00A8(A2) ; ;------------------------------------------ ;As written: ;When the ROM starts, P1 and P2 have RAM ;values of zero. ;When the first stage of the first game ;starts, the RAM values will increment to ;#$01. The comparison will occur. ;The code will branch, and default health ;for both players will be 1 unit. ;Plus, both RAM values will increment. ;P1 and P2 will have RAM values of 2. ;So, whenever either dies, when this code ;runs again, it will not branch, and life ;points assigned will be #$68. ; ;When a game is reset (hard or soft), ;the RAM bytes should be assigned values ;of zero. ; ;Test: ;Seems to work as intended for P1, ;but P2 will start with full life. ;This will be the puzzle... ; ;Will the stronger player take P1? ;Will P2 let P1 take the 1up or make P1 ;take the suicide run for the chicken? ;------------------------------------------
1. What's a jsl? 2. That beq is not valid syntax, you need to specify an address or a label, as well as a size on the instruction itself (.s or .w). 3. cmpi takes two parameters, one immediate value and a register/memory.
Addendum to MainMemory's point 1: based on a quick Google search I'm guessing that jsl is meant to jump to a subroutine, so you'll want to use a jsr there (or maybe a bsr.x where x is s or w, check the 68k docs for the difference between the two opcodes. You're safe with jsr, but bsr can be faster sometimes, IIRC).
In the 65c816 CPU, JSL means "Jump to Subroutine Long", which takes a 24 bit address, so that it can jump to pretty much anywhere in the address space (JSR only does it within a bank). Though, you also have to use "RTL" to return properly. They mentioned "65c816" in the original post, so I think that's what they're referring to. The 68000 doesn't naturally do bankswitching, so in this case, "JSR" would be the equivalent to "JSL". Likewise, "JML"' equivalent would be JMP.
@Ralakimus That was my gut feeling too (not being familiar with 65c816), with the matching org directives backing it up, but I figured I'd be thorough. I use bsr and bra probably more often than is necessary in my own code (and spend more time fixing out-of-range issues as a result).
Thanks, guys! I was indeed using a 65c816 mnemonic, since I'm more used to that code from my 3 summers of NBA Jam TE hacking. I looked into a couple tutorials as well as the responses here and went with jsr. I also added the parameter to the cmpi. Edits made to the code in the original post. For the beq, I assumed you could just tell the 68k to go to the next byte (or go [x] bytes, like an effective address). Is that not the case? I haven't figured out what you guys are using for an assembler, based on a number of Google searches, so my alternative was going to be convert the code by hand to hex and drop that into the rom. I'm admittedly not sure of the org equivalent for 68k assembly, so that's another placeholder and 65c816 mnemonic (e.g., for assembling SNES code via xkas).
I imagine most people are using (or prefer) asm68k, which is totally pirated and hacked but ¯\_(ツ)_/¯ Same goes for snasm68k, I believe. The alternative is AS, which is more legally sound (and I believe why most of the Sonic disasms use it) but comes with its own... eccentricities. (I keep thinking about writing a Python preprocessor for AS to make it behave more like asm68k but I haven't found the energy for it yet) What MainMemory was getting at with the beq syntax is that you need to specify the width of the effective address. So .s if your effective address fits in a byte, or .w otherwise. If you haven't already, do a search for 68k instruction set. There's a PDF there that's a good reference (would link but my phone is being bleh). You could also look for MarkeyJester's 68k reference site (http://mrjester.hapisan.com/04_MC68/), or RHS's intro to 68k assembly right here on the wiki: http://info.sonicretro.org/SCHG_How-to:Work_with_Motorola_68000_assembly
ORG is fine, 68000 assemblers also use that directive. For the beq, it needs to look something like this: Code (Text): beq.s mylabel ;code here mylabel: ;more code
Thanks for all the help! I did indeed start with MarkeyJester's tutorial to get a feel for 68K mnemonics, and it's been pretty helpful. I'm also peeking through the RHS intro docs on the site as well. I've made some changes to the code in the OP based on all the guidance above; I also killed those lea commands I had written because they don't seem to work same as a 658c16 LDA. I replaced them with more direct cmpi.b commands and shortened the code.
This move.w #$0068,$0080(A2) command at $7EC8 has me curious. Both players 1 and 2 use the same subroutine to generate/re-generate the player, with $FFFFEF80 the life counter for P1 and $FFFFF080 the life counter for P2. The code will reduce the life value for P1's first life, but it ignores it for P2 and gives them the default 0x68 value. Not sure why or what I've written that didn't impact P2 as intended.
