Super Street Fighter 2 - new Z80 driver

[Stef]

No update lately... the driver is ok for SF2, for SSF2 strangely sometime it seems to impact music (modifying a instrument sound) but it happens very rarely (i was not able to reproduce it on my system) so it will be difficult to fix. And by reading the code i don't understand what can happen... I have to admit i'm too lazy to investigate more about it

[Bottino]

Hey Stef, I promised some feedback to you, but only now i had the time to play this version properly.

I've tested it with an Everdrive v3 on my Model 1 non-TMSS Sega Genesis and i applied your patch to the Super Street Fighter II - The New Challengers (USA) ROM from the latest NoIntro ROM set.

I've played the game extensively and only during one of my bouts against M.Bison some error with music occurred, like it was out of tune or something, just before the fight started; it was only during a couple of seconds and then the music resumed normally. The announcer sample played normally during that period.

Also, I've faced every single fighter multiple times and I didn't noticed any problems with the samples. They played flawlessly.

[Chilly Willy]

I ran into something similar for my VGM player in the NeoFlash Myth menu. Depending on how you turn the channel off, when you later turn it on to play something, it may not play correctly. This is particularly true for FM drums, but can affect almost any sound. So if you want to look for where the problem is, try looking at how the sound is turned off and compare that to how you do so in your new driver. That would be the first place I'd look given my experiences.

[Stef]

Bottino> Thanks for the feedback, it indeed happen really rarely and only on SSF2... well hopefully the bug is not really hurting, still it would be nice to fix it.

Chilly Willy>
The Z80 driver is only handling PCM playback, it does not change key off/on register, the only thing it does is that for each sample played it write $2A to YM port 0 then write the sample value to YM port 1.
The only thing i can think of is a timing issue, in the original SF2 driver, we have this :

ld de,FM_ACCESS
ld a,$2a
ld (de),a ; indicate Z80 is accessing YM DAC register
ld ($4000),a ; prepare DAC write =37

and in my driver the code has changed to this :

LD A, $2A ; ' 7 |
LD (HL), A ; Z80 is accessing YM ' 7 | 14 (18)
LD (DE), A ; prepare DAC write ' 7 |

In my driver HL = FM_ACCESS so the driver does the exact same thing :
FM_ACCESS takes value $2A to indicate that Z80 is accessing YM chip.
The 68000 is always checking for the value of this variable before accessing YM, if the value is not 0 then it wait until Z80 release access. The problem is that original code use the "LD ($4000),A" instruction to set the register number on port 0 while i'm using the instruction "LD (DE),A" to do the same thing. The first instruction takes 13 cycles while mine only use 7 cycles, a difference of 6 cycles but which can make a difference !
Imagine the 68000 takes the Z80 bus right before FM_ACCESS is set to $2A by the Z80, then the 68000 setup the YM registers and release the Z80 bus. Z80 resume execution and on the original driver, 20 cycles are spent to send the new command to YM while only 14 cycles are spent on my driver. So maybe the YM2612 chip is still busy while receiving the new write in my driver so it ignores it and the sample write will screw up another register while the extra 6 cycles on the original driver allow the YM2612 to be ready just in time.... just a hypothesis.

[Chilly Willy]

It doesn't matter which processor is handling the FM, the problem exists either way. Note, this problem is only at the START of a song, not elsewhere.

Here's how I turn off the FM in my VGM player:

ExitVGM:
| reset YM2612
        lea     FMReset(pc),a5
        lea     0xA00000,a0
        moveq   #6,d3
0:
        move.b  (a5)+,d0                /* FM reg */
        move.b  (a5)+,d1                /* FM data */
        moveq   #15,d2
1:
        move.b  d0,0x4000(a0)           /* FM reg */
        nop
        nop
        nop
        move.b  d1,0x4001(a0)           /* FM data */
        nop
        nop
        nop
        move.b  d0,0x4002(a0)           /* FM reg */
        nop
        nop
        nop
        move.b  d1,0x4003(a0)           /* FM data */
        addq.b  #1,d0
        dbra    d2,1b
        dbra    d3,0b

        move.w  #0x4000,d1
        moveq   #28,d2
2:
        move.b  (a5)+,d1                /* YM reg */
        move.b  (a5)+,0(a0,d1.w)        /* YM data */
        dbra    d2,2b

| reset PSG
        move.b  #0x9F,0xC00011
        move.b  #0xBF,0xC00011
        move.b  #0xDF,0xC00011
        move.b  #0xFF,0xC00011
9:

where the data is

FMReset:
        /* block settings */
        .byte   0x30,0x00
        .byte   0x40,0x7F
        .byte   0x50,0x1F
        .byte   0x60,0x1F
        .byte   0x70,0x1F
        .byte   0x80,0xFF
        .byte   0x90,0x00

        /* disable LFO */
        .byte   0,0x22
        .byte   1,0x00
        /* disable timer & set channel 6 to normal mode */
        .byte   0,0x27
        .byte   1,0x00
        /* all KEY_OFF */
        .byte   0,0x28
        .byte   1,0x00
        .byte   1,0x04
        .byte   1,0x01
        .byte   1,0x05
        .byte   1,0x02
        .byte   1,0x06
        /* disable DAC */
        .byte   0,0x2B
        .byte   1,0x80
        .byte   0,0x2A
        .byte   1,0x80
        .byte   0,0x2B
        .byte   1,0x00
        /* turn off channels */
        .byte   0,0xB4
        .byte   1,0x00
        .byte   0,0xB5
        .byte   1,0x00
        .byte   0,0xB6
        .byte   1,0x00
        .byte   2,0xB4
        .byte   3,0x00
        .byte   2,0xB5
        .byte   3,0x00
        .byte   2,0xB6
        .byte   3,0x00

That's the best I've been able to do so far and it STILL has trouble on certain instruments on certain songs on the startup.

[Stef]

Yeah i know the problem while starting a music, i experienced this issue in my new XGM driver
I believe i finally fixed it but it needs more testing: my reset sequence is similar to your except that i also set RR to max before keying off. This way i am sure the envelop phase is correctly reseted.
The panning has weird behavior on real hardware, even by turning off all channels you can still heard sound (at a lower volume though)... i was using it before to allow "pause" music command and it was not working because of that behavior.

Anyway the problem in SSF2 is not about music starting sequence, a video posted sooner in the topic saw the bug happening in the middle of a music..
so i believe it can be due to the problem i pointed out just above.

[dr apocalipsis]

Not sure if related, cause I haven't heard your patch on real HW, but I have the original PAL cartridge and it used to fart and peep from time to time for no reasons.

[Stef]

Oh really, do you mean the original game suffers from this problem as well O_o ??

[retrospiel]

Back in 1994 I played the original for days on end and I haven't noticed anything.

Just to reiterate my previous statements on this matter: There definitely is something wrong with the latest patched versions.

It seems to keep the PCM/FM channel from switching back to FM once a PCM sample played. This happens quite frequently.

My first suggestion would be to check the WAV files I've sent you whether they are all of the same size. Not that I am the one to blame as I sent you a PCM file larger than what could be inserted into the ROM....!?


Maybe start with a fresh ROM and re-insert the sound driver to see if the problem remains?


All I know for sure is that it happened with the versions I played, but I haven't played the initial first version.

[Chilly Willy]

Yeah i know the problem while starting a music, i experienced this issue in my new XGM driver
I believe i finally fixed it but it needs more testing: my reset sequence is similar to your except that i also set RR to max before keying off. This way i am sure the envelop phase is correctly reseted.

Yeah, that sounds like a good idea. Those RR can be REALLY long.

Anyway the problem in SSF2 is not about music starting sequence, a video posted sooner in the topic saw the bug happening in the middle of a music..
so i believe it can be due to the problem i pointed out just above.

Okay. Just checking.

[Stef]

Back in 1994 I played the original for days on end and I haven't noticed anything.
Just to reiterate my previous statements on this matter: There definitely is something wrong with the latest patched versions.
It seems to keep the PCM/FM channel from switching back to FM once a PCM sample played. This happens quite frequently.
My first suggestion would be to check the WAV files I've sent you whether they are all of the same size. Not that I am the one to blame as I sent you a PCM file larger than what could be inserted into the ROM....!?

Maybe start with a fresh ROM and re-insert the sound driver to see if the problem remains?
All I know for sure is that it happened with the versions I played, but I haven't played the initial first version.

Actually the way the driver is designed it should not have any impact on it.
The Z80 driver is only playing samples while 68k is handling FM+PSG stuff, the 68000 just give orders to Z80 and only check about YM chip access conflict, but it don't check if Z80 is still playing samples... at the moment it needs to switch FM5 back to FM it will do it whatever the Z80 is doing. So it should not miss any FM notes. Honestly i think the FM5 is not much used in music because all voices interrupt it anyway.
I will try to patch with a modified version of the driver (including original timing just to be safe).

[retrospiel]

While you're at it I'd like to request to have this most recent version of my modified PCM inserted into the ROM:

http://www.mediafire.com/listen/qn4b...cs6/test16.wav

[Bibin]

https://www.youtube.com/watch?v=auNA...etailpage#t=20

Where do these rude responses come from? There is nothing ridiculous about suggesting a few tweaks to a game's moveset to match a later, updated version of the game - especially when it is the Street Fighter 2 game anyone plays competitively these days. An improved PCM driver, better palettes... is a gameplay tweak a childish suggestion following these other modifications?

[Tor Landeel]

Rude responses come from unrealistic requests..
One thing is modding, another is completely reprogramming the game.

[Bottino]

Where do these rude responses come from? There is nothing ridiculous about suggesting a few tweaks to a game's moveset to match a later, updated version of the game - especially when it is the Street Fighter 2 game anyone plays competitively these days. An improved PCM driver, better palettes... is a gameplay tweak a childish suggestion following these other modifications?

It was a joke of mine and NeoVamp's, due to a suggestion that another member made here, that was blown a little out of proportion for other members - including myself.

Don't take it seriously, no one was mocking your suggestions.