Street Fighter 2 button reading code

[earok]

I'm a total noob here so sincere apologies for my ignorance

Street Fighter 2 is known to be a game that doesn't read the fire button a CD32 pad, I started poking around in the WinUAE debugger and this appears to be an example of the code used for reading the joystick button (button 1 on joystick 2).

MOVE.B $00bfe001,D1
EOR.W #$0080,D1
AND.W #$0080,D1
OR.B D1,D2

The way I'm reading this is, "If the eight bit of $bfe001 is set to 0, set the eight bit of D2 to 1". It's quite different to the examples I've seen for reading the fire button, I take it this may be why it struggles with the CD32 pad?

I thought I might try swapping it out with this code, does it look sound?

TST.B $00bfe001     ;Test for fire button
BMI.W #$0008     ;Branch ahead if it wasn't hit
OR.W #$0080,D2     ;Set the 8th bit on D2 to 1
NOP.L     ;Fills in the empty space freed by the shorter code

Thanks in advance

[Toni Wilen]

Code seems fine.

"Normal" case for non-working CD32 pad is program setting button 3 line in output mode and data in high state. (Which configures pad in CD32 pad mode, all buttons supported but they must be read from pad's shift register)

Check all POTGO register writes. "dj 16" debugger command can be useful (16 = log POTGO accesses. 1 = events, 2 = joystick port, 4 = $bfe001)

[Retro1234]

Nice one ill be interested in your end results.

[earok]

@Toni thank you very much! I've done as you've suggested and it's logging this

POTGO_W: CC01 000188D4

And 000188D4 is:
MOVE.W #$cc01, $00dff034

So the value of $cc01 is being written to the POTGO?

Toni, do you have any suggestions for the proper way to patch this? I've NOP'ed out the line entirely and at least in WinUAE it doesn't seem to have broken it (players 1 and 2 work with buttons 1 and 2). (edit: Just tested on a real CD32 with that line NOP'ed out, seems just fine)


@BooBoo cheers

[matthey]

Originally Posted by earok

NOP.L     ;Fills in the empty space freed by the shorter code

Thanks in advance

There is no such thing as a NOP.L. NOP is a 16 bit encoding which is documented as "unsized" although a NOP.W would probably be acceptable. Different assemblers could generate 2xNOP or ignore the ".L" and generate a single NOP. I recommend not using NOP at all as this synchronizes the pipeline and takes up to 9 pOEP only cycles on the 68060. It would be better to fill with TST/CMP/CMPI if the CCR flags are unneeded as appears to be the case here.

[Toni Wilen]

Originally Posted by earok

@Toni thank you very much! I've done as you've suggested and it's logging this

POTGO_W: CC01 000188D4

And 000188D4 is:
MOVE.W #$cc01, $00dff034

So the value of $cc01 is being written to the POTGO?

Replacing it with CC00 should fix it. Removing the write is not safe because default value may not be correct depending on how you boot the game.

I have seen this kind of reading method previously (don't remember in which game) and I am not sure why it enables POT counters.

Originally Posted by matthey

I recommend not using NOP at all as this synchronizes the pipeline and takes up to 9 pOEP only cycles on the 68060. It would be better to fill with TST/CMP/CMPI if the CCR flags are unneeded as appears to be the case here.

Which is pointless micro-optimization in this case.

[earok]

Originally Posted by Toni Wilen

Replacing it with CC00 should fix it. Removing the write is not safe because default value may not be correct depending on how you boot the game.

I have seen this kind of reading method previously (don't remember in which game) and I am not sure why it enables POT counters.

thanks mate, I appreciate it.

If I recall correctly, Shaq Fu and Street Rod 1/2 have similar issues, but I can't recall any other game that needs a regular joystick rather than a CD32 pad. I think the only thing all of the games have in common is an option to use a second button (Shaq Fu is a two button fighter, and Street Rod can apparently use both buttons in Mouse mode).

[matthey]

Originally Posted by Toni Wilen

Which is pointless micro-optimization in this case.

The speed difference will probably not be noticeable on a 68040-68060 for one NOP but it is good to know that NOP does more than NOP on these processors and is very slow. NOP.L should never be used IMO. It is a matter of style and understanding which is more important than optimization in this case.

[meynaf]

Originally Posted by matthey

The speed difference will probably not be noticeable on a 68040-68060 for one NOP but it is good to know that NOP does more than NOP on these processors and is very slow.

You can extend this to 68020-68060, because 020-030 do a pipe sync too for NOPs. Now if the NOP just wanted to waste time then it reached its goal
However using NOPs for time waste is NOT recommended at all, btw - as the timing isn't guaranteed at all.

[Leffmann]

If you want a true no-op, there's always

movea.l An, An

.