SMPS2ASM and improved S&K Driver

Glad to hear that you've finally released the modified S3&K z80 sound driver, and the ASM'd music! This should make music porting and hacking much easier . Now I'm just waiting for SMPS2ASM.

If I'm reading this correctly, this means no longer do hackers have to use Music Pointer Fixer (MPF) or do manual pointer fixing to fix the pointers for music for z80 sound drivers? All I have to do now is just "include" ASM'd music files to the S3&K driver for my S3&K hack, and I'm ready to go? Awesome, I didn't think such a thing was possible! I'm going to try the new driver, and see if it improves the playback of some of my ports for my S3&K hack. (Some Ristar songs and S2F songs sounded wrong in the previous driver.) Thanks for the release.

 

Oh hey, someone actually did this. Now I don't have to!

Good stuff.

 

So I tried replacing the "Z80 Sound Driver.asm" file in my S3K disassembly with the new one and building outright and I get a number of errors, ranging from "Too many operands" to "Generic error". I tried looking at the .asm file of both the new sound driver and the conversion tool and it doesn't seem to be formatted correctly; as in it seems illegible compared to other .asm files I have used.
I think I might just be missing something obvious, but maybe not...?

 

Marvellous. Looking forward to digging into this once I have some computers that aren't in pieces.

Since the tool isn't out yet, any chance of converting the Sonic 3C 0517 credits medley to add to the selection? I can send you a pre-extracted binary file if it helps.

Also, one thing:

There's an exception to this: S&K provides a different sample from S3 for B2/B3; this is used in the S3 miniboss and Knuckles themes and the S&K Knuckles theme. Is there anything in the driver to deal with this? If not, do you think it would be easy to add? This is the last thing in Sonic 3 Complete that's accomplished by 68K meddling (I fiddle the DAC bank pointers for those samples depending on the track selected) so it'd be nice to cross that one off.

For completeness, it's perhaps also worth mentioning that there are some very, very slight differences in channel setup in a few of S3's sound effects, but I can't imagine offhand why anyone would want the S3 versions - all it does in the existing game is cause some bad music cutout in DEZ3 and a couple of other places (I think SSZ, which may partly explain why that got a similar fiddle before S&K release).

 

The update seems to have fixed a few of the errors, but I am still getting a lot of "operands" based issues...

Code (ASM):

1. > > >Z80 Sound Driver.asm(329) ALIGN(1) CNOP(1) ORG(1): error: wrong number of o
2. perands
3. > > >         if (*-1+(8)-((*-1+(-(0)))#(8))) < *
4. > > >Z80 Sound Driver.asm(329) ALIGN(1) CNOP(1) ORG(1): error: wrong number of o
5. perands
6. > > >         if (*-1+(8)-((*-1+(-(0)))#(8))) < *
7. > > >Z80 Sound Driver.asm(329) ALIGN(1) CNOP(1) ORG(1): error: wrong number of o
8. perands
9. > > >         if (*-1+(8)-((*-1+(-(0)))#(8))) < *
10. > > >Z80 Sound Driver.asm(329) ALIGN(1) CNOP(1) ORG(1): error: invalid operand t
11. ype
12. > > >         if (*-1+(8)-((*-1+(-(0)))#(8))) < *
13. > > >Z80 Sound Driver.asm(329) ALIGN(1) CNOP(1) ORG(2): error: wrong number of o
14. perands
15. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
16. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
17. > > >Z80 Sound Driver.asm(329) ALIGN(1) CNOP(1) ORG(2): error: wrong number of o
18. perands
19. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
20. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
21. > > >Z80 Sound Driver.asm(329) ALIGN(1) CNOP(1) ORG(2): error: wrong number of o
22. perands
23. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
24. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
25. > > >Z80 Sound Driver.asm(329) ALIGN(1) CNOP(1) ORG(2): error: wrong number of o
26. perands
27. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
28. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
29. > > >Z80 Sound Driver.asm(329) ALIGN(1) CNOP(1) ORG(2): error: wrong number of o
30. perands
31. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
32. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
33. > > >Z80 Sound Driver.asm(329) ALIGN(1) CNOP(1) ORG(2): error: wrong number of o
34. perands
35. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
36. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
37. > > >Z80 Sound Driver.asm(329) ALIGN(1) CNOP(1) ORG(2): error: wrong number of o
38. perands
39. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
40. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
41. > > >Z80 Sound Driver.asm(329) ALIGN(1) CNOP(1) ORG(2): error: invalid symbol na
42. me
43. > > > "too much stuff before org $\ ($\ bytes)"
44. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
45. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
46. > > >Z80 Sound Driver.asm(329) ALIGN(1) CNOP(1) ORG(2): error: invalid string
47. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
48. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
49. > > >Z80 Sound Driver.asm(359) ALIGN(1) CNOP(1) ORG(1): error: wrong number of o
50. perands
51. > > >         if (*-1+(8)-((*-1+(-(0)))#(8))) < *
52. > > >Z80 Sound Driver.asm(359) ALIGN(1) CNOP(1) ORG(1): error: wrong number of o
53. perands
54. > > >         if (*-1+(8)-((*-1+(-(0)))#(8))) < *
55. > > >Z80 Sound Driver.asm(359) ALIGN(1) CNOP(1) ORG(1): error: wrong number of o
56. perands
57. > > >         if (*-1+(8)-((*-1+(-(0)))#(8))) < *
58. > > >Z80 Sound Driver.asm(359) ALIGN(1) CNOP(1) ORG(1): error: invalid operand t
59. ype
60. > > >         if (*-1+(8)-((*-1+(-(0)))#(8))) < *
61. > > >Z80 Sound Driver.asm(359) ALIGN(1) CNOP(1) ORG(2): error: wrong number of o
62. perands
63. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
64. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
65. > > >Z80 Sound Driver.asm(359) ALIGN(1) CNOP(1) ORG(2): error: wrong number of o
66. perands
67. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
68. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
69. > > >Z80 Sound Driver.asm(359) ALIGN(1) CNOP(1) ORG(2): error: wrong number of o
70. perands
71. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
72. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
73. > > >Z80 Sound Driver.asm(359) ALIGN(1) CNOP(1) ORG(2): error: wrong number of o
74. perands
75. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
76. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
77. > > >Z80 Sound Driver.asm(359) ALIGN(1) CNOP(1) ORG(2): error: wrong number of o
78. perands
79. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
80. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
81. > > >Z80 Sound Driver.asm(359) ALIGN(1) CNOP(1) ORG(2): error: wrong number of o
82. perands
83. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
84. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
85. > > >Z80 Sound Driver.asm(359) ALIGN(1) CNOP(1) ORG(2): error: wrong number of o
86. perands
87. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
88. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
89. > > >Z80 Sound Driver.asm(359) ALIGN(1) CNOP(1) ORG(2): error: invalid symbol na
90. me
91. > > > "too much stuff before org $\ ($\ bytes)"
92. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
93. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
94. > > >Z80 Sound Driver.asm(359) ALIGN(1) CNOP(1) ORG(2): error: invalid string
95. > > >                 error "too much stuff before org $\{(*-1+(8)-((*-1+(-(0)))
96. #(8)))} ($\{(*-(*-1+(8)-((*-1+(-(0)))#(8))))} bytes)"
97. > > >Z80 Sound Driver.asm(360) RSTTARGET(2): error: Function PointerTableOffset
98. is at 017h, but must be at a multiple of 8 bytes <= 38h to be used with the rst
99. instruction.
100. > > >                 fatal "Function PointerTableOffset is at 0\{$}h, but must
101. be at a multiple of 8 bytes <= 38h to be used with the rst instruction."
102. fatal error, assembly terminated
103. Press any key to continue . . .

I can't figure this one out. I also apologise for the wall.

 

OK then - it's at $C633A in Sonic 3C prototype 0517.

Everything in the setup is identical to the S&K version (pitch $16 and $20 for B2 and B3 respectively) - the only thing that differs is the sample data, which is the same length as the S&K version too ($848). Both B2 and B3 share that sample data, which I've now uploaded. It can be found at $F3465 in S3A. $F015F and $F0164 are the headers.

 

Yeah, that's a problem. I barely know how to use SVN as it is. Plus I've been working on the released disassembly of S3K for quite some time now so I don't know how that would work; updating stuff (and possibly losing work in the progress) just for an updated sound driver. It seems yet again this is something that is way over my head. I appreciate the release though; I'm sure someone can make use of it.

 

Thanks for adding those in!

While I'm here, I may as well lay out the the issues I've had with the original S&K driver in general in case you have any insight on them or feel like making some optional tweaks for them, since I think some of this would be helpful to others too - if nothing else it's worth making everyone aware of this stuff I think. No worries if you don't want to make any changes for it.

1. Sometimes the sound driver "forgets" to apply a music track change that was queued during a 1-up. You can reproduce this in S3K by giving yourself 99 rings, then collecting another one for a 1up, immediately turning Hyper, and then breaking any shield or ring monitor while the 1up music is still playing. The transition to invincibility music is lost and the zone music resumes.
   I think I've figured out why this is happening, too: the game code uses Play_Sound instead of Play_Sound_2 to play the sound effects for the items in those monitors, which is resulting in the sound effect being queued as the music to fire off when the 1up finishes. So really this is something that is probably best fixed in the game code itself, and it turns out it sort of ties in with point 4... unless there is ever a legitimate reason to play SFX through zMusicNumber instead of the zSFXNumbers?
   
2. Tempo changes always apply immediately, even during the 1up music, reverting to the previous tempo after its completion. In terms of Sonic games' actual use of the tempo feature, it would make more sense if tempo changes are queued to be applied after the 1up track finishes, like music changes. This would make reinstating the correct 1up sound during Sonic 3 special stages work sensibly, for instance, or collecting super sneakers while 1up music is playing.
   
3. It would be nice to have an easy way of defining multiple tracks to have 1up lock/fade-in properties - although this is probably pretty niche to S3C. At the moment I deal with this by just adding more conditionals for different track IDs which isn't too bad.
   
4. I've been thinking about whether it would be possible to operate music and control effects on a totally separate set of IDs from sound - so for example, you could have music tracks from $01-$40 when calling Play_Sound but still keep sound on $32-$DB when calling Play_Sound_2. This would give loads of room to add extra music and sound effects. Given that the 68K code uses different functions depending on which it's trying to play (and even calls the right one some of the time!) and puts them into different addresses for the Z80 to pick up, it seems like it might be possible. Having had a quick flip through the code today, I was thinking it might be possible to do this fairly simply by re-engineering zPlaySoundByIndex to look at the zUpdatingSFX flag. I'd be interested in your thoughts on whether this is a viable path and what other obstacles the driver might present if I tried this myself.

Thanks once again for all the work you've done here - I still haven't got around to integrating it but I really can't wait. (Except that I kind of have to wait. But hey, you know what I mean.)

 

I was thinking the same thing about point 1 - and if I'm going around fixing calls for point 4, it should take care of this too. Your description does raise another issue though, of collecting a second 1up while the first is playing, which sounds like it would also wipe a pending music change... I don't know if routing 1up through Play_Sound_2 would be a viable fix, since we want it to get lost in this case, but that would make separating music and sound functions more of a headache again.

The queue idea sounds very good for tempo - it sounds like quite an undertaking, but it really makes a lot more sense in the context of Sonic games, so I'd be very pleased if you did decide add such a thing. Thinking about it, it would also be nice to have a way to request a music track with an initial tempo change (e.g. collecting invincibility with sneakers active, restarting zone music from an event while sneakers are active, etc.) At the moment I do nothing about the former and for the latter, I create a wait object to run Call_Sound_Event a few frames later - and by "a few frames", I mean "some number of frames that seemed to work most of the time", so if I continue with that approach, do you have any ideas on a more scientific frame gap?

I'll stick to the old conditionals for the different 1up tracks for now then - it's good to have the approach validated.
A macro would be nice but I'm not sure who else would ever have a use for it, so I'm happy enough to tweak it myself.

Having had a look through today, with reference to your info here, I think I see a reasonable way to make the music/sound ID split work; I'll have to try it and see. I am concerned regarding its impact on the coordination flag FF/01 to play another music/sound effect by ID, though - without changing the actual flag format, I imagine it would end up being restricted to either music or sound only. Is this flag actually used by anything? Sound effects would seem a more sensible option to leave available, unless something relies on calling fade effects, but I could rig those up to work in both instances if necessary. Regarding the comment on flutters and space - are we running close to a space limit in the current version then?

Thanks again for the help!

 

Thanks for the info once again.

Just did a quick test - the same principle as the test case I described previously, but with a 1up monitor - get a 1up for 100 rings, immediately turn super, break the 1up monitor, all during the 1up jingle. The invincibility music does still seem to get lost, with the zone music resuming after the 1up jingle completes.

The problem I found in practice was that calling Change_Music_Tempo immediately after Play_Sound in 68K code would just cause the tempo change to be lost. I assumed this was because the sound driver wasn't picking up the music change immediately, and it was just cancelling the tempo change when it did (as it does during a transition to any new music). I run a five frame delay before calling Change_Music_Tempo to work around this at the moment. (Change_Music_Tempo is what I meant by Call_Sound_Event, by the way - I still have the old disasm names in my head!)

OK, I'll watch out for that... I'm hoping to do this without adding too much extra code on balance, but unfortunately I need a fair chunk of music table expansion, even without code changes or adding tracks beyond those I use already. Fingers crossed!

 

Do you think that running it through Play_Sound_2 I.e. the SFX slots is a viable workaround, or will that cause other problems? (Other than for splitting the functions of course... I have an unpleasant but workable solution in mind for that if this is the best way to go.)

On the space limits: is there a particular reason that the tables have to be at 1300h, or that I couldn't sneak a bit of code in after the end of them?