Hacking the ST rom

There need to be hardware changes
Adding CPS1 sounds with the cps2 sounds would require more memory as the samples roms are already full.

HDR music needs a better sound CPU I doubt that 4mhz z80 would be able to pump it out at a high enough quality.

Or, for HDR you can rearrange the songs to fit the 16 channel monophonic tracker, you can switch instruments quickly, but you’re stuck with the constraint of 16 channels at one time. Monophonic means only one note can play at a time on the channel so chords would require more than 1 channel.

or, we can forget ST and start hacking HSF2 as it has the cps1 character sound effects and the stages just need to fix up the turbo and get rid of the other revisions.

hey jedpossum, any plans on ‘documenting’ your findings at some point?

The Character select edits are just edits in the RAM not on the roms. Before I get back to graphics I still want to figure more about the Turbo on sf2 games before I continue as Music is going to take a bit of time.

I should write down notes more as it has bite me in the ass already. I forgot where the table for the cpu paths 1p mode are stored the only thing I remember about it is that it’s possible to have 16 battles on it.

Is there an irc or something to chat on I’ll answer questions if you want to know.

Nothing specific really, its just that you did some jaw dropping stuff recently and that caught my attention… Also, I plan to give another shot at hacking the st rom soon and this time ill take a look at phoenixed version and try to hack something on the assembly itself, i know i got the minimum skills…

Do you know how to use Mame’s debugger? cause that is going to help you a lot.



CD816: move.l (a1)+,(a0)+


That instruction is responsible for loading background data from the Rom to the Ram.
Now I can find the tables to edit backgrounds.

That’s character select background being loaded up.

Edit: link if you can’t read the numbers on the pic

Another interesting thing the table isn’t encrypted you can edit it on the regular rom.

http://i.imgur.com/na85W8M.png

I wonder if it is possible to use 32x32 tiles for that layer instead of 16x16.

Very impressive! cool music



08DCDA: cmpi.w  #$2, D0 -- Input
08DCDE: bne     $8dce8
08DCE0: addq.b  #2, ($80,A6) -- Adding to the counter.


First input of N.Sagat’s Tiger Upper Cut.

I should note the directions.
1 Back
2 Forward
4 Down
8 Up

With some basic math you get the other directions
4+1 = 0x0005 (Down Back)
8+2 = 0x000A (Jump Forward)

Also, remember were programming here so it’s in hexadecimal.

Edit: If you followed my older notes the old characters have a their own inputs for specials as well.

jedpossum, you rock man. I finally had time to mess with this stuff and its so easy to change the inputs! In less than 5 minutes i changed feilong’s chicken wing motion from :arrow_lower_left:↓:arrow_lower_right::arrow_upper_right: K to :arrow_lower_left:↓:arrow_lower_right:→ K ! It feels sooo right that way!
For anyone interested in trying it, on the phoenixed rom(the others roms have the assembly encrypted, so dont bother), change the value on address 151d6 of rom 4 from 0A to 02.

Weird thing about is the special inputs only in SSF2 and ST time I have seen they have the inputs as constants like that. Well, I only checked the cps1 sf2 and xmvsf still something to note.

And to fully get hold of it you have to make a dis-assembly for it like make O.Chun a non charge character like EX the series.

This got me inspired, at some point ill try to change her kikouken to Yoga flame input, but that will be a lot more complicated, i know. I think that putting a jmp right before the charge checking routines that goes for my new routine (which would basically be a copy paste from yoga flame) would work with maybe only a few adaptations.

EDIT: Here are some fast input hacks i did

fei’s CW is now HCF:
last direction is forward(0x02) instead of Up-forward(0x0a):
rom4 address 151d6 change 0a to 02

cammy’s hooligan HCF as well:
last direction is forward(0x02) instead of Up-forward(0x0a):
rom4 address 11b40 change 0a to 02

cammy’s sbk to QCB (like HDR)
first direction is downward(0x04) instead of backward(0x01):
rom4 address 120ae change 01 to 04
second direction stay the same, that is, down-back(0x05)

last direction is backward(0x01) instead of forward(0x02):
rom4 address 120ea change 02 to 01

I have an idea how about tell the branches to go to a new special completely.

I need to set up a better way to keep a hold of this info instead posts took some time to find this.

branch subroutines for n.gief:

0886ba bsr $88ad4 --> ppp
0886be bsr $88b4c --> kkk
0886c2 bsr $88826 --> fab
0886c6 bsr $88c48 --> spd
0886ca bsr $88ef0 --> rgb/suplex
not 100% sure but 99% sure that these are the respective special moves for each routine, green hand rountines appear to be right after these BSRs, 5 or so debugger lines below.

By debugging inside some of these brunches i started to understand how some certain stuff works:
Memory addresses ff87e0 and ff87e2 are “2 byte words” that hold the current frame and the past frame inputs, respectively.
So, if ff87e4 is different from ff87e0, it means that some button was released or pressed during that frame transition.
The less significant algarism is the direction ( 1 = right, 2 = left, up = 8, sum directiosn to get diagonals etc…). The second less significative algarism is the punch button (1 = jab, 2 = strong, 4 = fierce, sum them for the combination, for example 7 means that PPP is being pressed) and the third is kick (works the same as the punch one) and the most significative is apparently not used.

So, if ff87e0 is holding a value of 0701 and ff87e2 has a value of 0700 it means that the player stopped holding right, while holding kkk the whole time.

Memory references to $392,A6 or $394,A6 are checks to the inputs mentioned above. (A6 usually contains the address FF844E, plus offset 392 = ff87e0 which is the addres mentioned above)

Now, going inside the ppp subroutine:

088ad4 move.w ($394,A6), D0 --reference to past input frame
088ad8 not.w D0
088ada and.w ($392,A6), D0 --reference to current input frame
088ade andi.w #$70, D0
088ae2 cmpi.w #$70, D0 – checks register value D0 with 70, which means that PPP is pressed
088ae6 bne $88b0e

on these instructions the game is checking if the the player just pressed PPP on that frame, and then it doesnt branch on the bne instruction…

This is quite fun to mess with, i will continue tomorrow, going to bed now.

Didn’t see this till now, but HCF motions in Capcom games are 1546.

yeah, you’re right, thats not a true HCF. Too much work to change that tho, plus gameplay wise it doesn’t change much anyway

Insightful!

too bad the worst thing i hate most about HDR is the change of motion.

however, i like fixing the ST input bugs like Fei’s RH CW you have to input up forward, then RH after.
Does your change (CW => HCF) still retain that bug?

No, it would fix the bug. The chicken wing problem is the same problem with that Sagat has Tiger Knee.

master hacker jed, can you shed some light why the motion would cause the bug and it only affect RH chickenwing?

Oh it’s different problem?

I thought it was where would jump since the window to press the button is the prejump window.

yes its a different problem.
LK & MK, you can do it like other special moves.
But for HK, you have to explicitly input :arrow_upper_right: first, then followed by HK otherwise chicken wing won’t come out
:arrow_lower_left:↓:arrow_lower_right::arrow_upper_right: K