Sonic 1 Sound Driver in Sonic 3 and Knuckles

[Bobesh8 14]

We know that the Sonic 1 Sound Driver (SMPS 68k) works in Sonic 2 (Final tested, S.W. Beta tested).

The Sonic 1 Sound Driver (SMPS 68k) can be used out of the 4MB ROM limit.

The SMPS Z80 Driver used in Sonic 2-3&K cannot be used out of the 4MB ROM limit,

or else, all music and sounds are muted, and the SEGA PCM plays screeching sound.

 

I attempted to port the Sonic 1 Sound Driver with Mega PCM to Sonic 3 and Knuckles, and it worked!

 

The other thing I need to fix it the sfx, or else the game crashes and restarts.

Could someone please give me instructions to fix the sound driver to work with S3K,

and the game's music and sfx?

I'm using the HG disassembly.

 

Musics: $01-32

Sounds: $33-DF

 

Thanks!

 

EDIT: I am currently doing Addressed Music just like MarkeyJester did with Sonic 1.

Edited 26 Jul 2013 by Bobesh8

[ThomasSpeedrunner 92]

Wait, you ported WHAT to Sonic 3 & Knuckles? I had looked into the Sonic 1 sound driver in S3K but it didn't seem possible due to major RAM rearrangements. Nevertheless, I congratulate you, and to celebrate your accomplishment, I have converted and fully fixed three S3K songs for the S1 sound driver. Here they are.

The songs are:

Endless Mine

Death Egg Zone, Act 2

Flying Battery Zone, Act 1

 

I'd give you Ice Cap Zone, Act 1 and Death Egg Zone, Act 1, but sadly, I already remixed Ice Cap Zone Act 1, and Death Egg Zone Act 1 isn't fully fixed yet. Nevertheless, I hope these help you.

[InfiniteWave 3]

Sonic 1's sound driver is soo inferior why replace 3K's with it?

[Electroball 68]

I have to agree with InfiniteWave, S1 Snd Driver is way too inferior than the S3K one... But I can recommend you this. It features SFX, DAC's and Songs from Sonic1, Sonic2, Sonic3, Sonic & Knuckles and Sonic 3D Blast.

[ThomasSpeedrunner 92]

Actually, the Sonic & Knuckles sound driver is no better than the Sonic 1 sound driver. IIRC, one major issue with the S&K sound driver (the reason why I can't use it) is that it constantly switches between DAC and PSG, causing additional chopping in samples. Soft samples and character voices especially suffer from this.

 

Electroball, that post you linked? That's still the S&K sound driver. So that won't work.

 

Now, as far as I'm concerned, some sound effects, like collecting and losing rings and jumping, are the exact same as Sonic 1, so I could give those, but I can't convert any S3K-specific sound effects due to my lack of experience, so you'll have to call on someone else for that part of it.

[Bobesh8 14]

Sonic 1's sound driver is soo inferior why replace 3K's with it?

Like I said:

 

 

The Sonic 1 Sound Driver (SMPS 68k) can be used out of the 4MB ROM limit.

The SMPS Z80 Driver used in Sonic 2-3&K cannot be used out of the 4MB ROM limit,

or else, all music and sounds are muted, and the SEGA PCM plays screeching sound.

 

Sonic 1 Sound Driver is much easier to work with.

Edited 4 Jun 2013 by Bobesh8

[Bobesh8 14]

I followed this guide: http://info.sonicretro.org/SCHG_How-to:Expand_the_music_index_to_start_at_$00_instead_of_$80_%28Sonic_2_Clone_Driver_version%29

 

I wan't to know to play Sound Effects on $33-$DF.

Edited 4 Jun 2013 by Bobesh8

[Varion Icaria 184]

Okay, While the S1 driver may seem better than S3K's driver, It really isn't capable of working in S3K Stock. Not to be a downer but it is a severe ram issue. Excerpt from my Disassembly showing the ram values used in S3K.


FFFFFFFF Water_Pal_FadeTo: equ $FFFFF000
FFFFFFFF Water_Pal_FadeTo_Line2: equ $FFFFF020
FFFFFFFF Water_Pal_FadeTo_Line3: equ $FFFFF040
FFFFFFFF Water_Pal_FadeTo_Line4: equ $FFFFF060
FFFFFFFF Water_Pal:       equ $FFFFF080
FFFFFFFF Water_Pal_Line2: equ $FFFFF0A0
FFFFFFFF Water_Pal_Line3: equ $FFFFF0C0
FFFFFFFF Water_Pal_Line4: equ $FFFFF0E0
FFFFFFFF VRAM_Buffer:     equ $FFFFF580

So as seen here. $FFFFF100 to $FFFFF57F is Unused [that I know of thus far] Sonic 1 requires $5FF bytes. Now there is a way to make it work, but it involves Re-arranging the ram so all of the free ram is in one spot. Effectively it could be done in a few simple ways if you were smart about it. The Underwater Palette could be moved to $FFFFFD00 cause there's $100 bytes of free ram. As for the VRAM_Buffer. I am not sure where there is another free $80 bytes in the RAM. One of the only other methods to get it to work, would be to make the S1 driver use less Variables. I hope this helps those who were attempting or lost in how to do this.

[Bobesh8 14]

I am currently doing Addressed Music just like MarkeyJester did with Sonic 1.

[Varion Icaria 184]

Addressed music isn't going to make a difference if there is no RAM for the Variables for the Sound Driver core itself. It's going to mess up on levels with water and not to mention anything that uses the VRAM buffer will either be messed up or the Driver itself will shit itself. If you don't free enough RAM or don't lower the amount of Variables the driver uses [Not sure how S1's driver works nor do I really care as I use Z80 drivers primarilly] The driver will never fully work in a stock S3K. Not to mention that the Driver could potentially slow down S3K due to it being run on the 68K rather than Z80. I would just use Flamewings SK driver or my customized binary insertion driver [For ASM68K and my Specific S3K Disassembly. since Flamewings is AS only.]

[ValleyBell 46]

Lets me post the RAM layout of the S1 driver:

F000    Global Variables
F040    DAC Track [Music]
F070    FM1 Track [Music]
F0A0    FM2 Track [Music]
F0D0    FM3 Track [Music]
F100    FM4 Track [Music]
F130    FM5 Track [Music]
F160    FM6 Track [Music]
F190    PSG1 Track [Music]
F1C0    PSG2 Track [Music]
F1F0    PSG3 Track [Music]
F220    FM3 Track [SFX]
F250    FM4 Track [SFX]
F280    FM5 Track [SFX]
F2B0    PSG1 Track [SFX]
F2E0    PSG2 Track [SFX]
F310    PSG3 Track [SFX]
F340    FM4 Track [Extra SFX]
F370    PSG3 Track [Extra SFX]
F3A0    Music RAM copy for 1-up [$220 bytes]
F5C0    End of RAM used by the sound driver

For S3K, you could remove the "Extra SFX" channels, because S3K doesn't use these. (In Sonic 1, the D0 sound uses them.)

If you do so and move the 1-up to F340, you free $60 bytes and the driver's RAM would end at F560.

 

This can be pushed even further, btw. The S2 Clone Driver in S2 Recreation uses $520 bytes right now. (Well, plus another $1F0 bytes somewhere else to store a second copy of the music track RAM.)

[Varion Icaria 184]

Well said ValleyBell. I'm sure our combined info will probably help them fix it up.

[MarkeyJester 1091]

Right then chaps, here's the strategy for getting the music men onto mars:

This...

...is the universe as we know it, the small round like object is planet earth, that of which we have too many people on, and this bigger round object is mars.

Now, mars is quite cramped at the moment, not enough for people to complain, but it's still pretty squashed, now, we could move all of the chunk people from chunky island to earth, but earth doesn't have enough space for them, so we better leave them on mars.

The layout mounts, the people there are ALWAYS moving in and out like a fucking battery ram, moving more people in and out there would only cause confusion and we'll probably end up causing the universe to suck itself in (we've already had that once, I don't think we want it again).

Other crap pole? Bleh!! No thanks, we'll pass.

Block land however is where it's at! Now, we all know that the block people are compact on earth, because we kept them locked inside the factory, we only really let them out to stretch their legs on block land, every level or so, however, there is enough space on earth so much so, that we can let them out the factory there! So they don't need to go to block land!

For those of you who know best, the music men have paid in full for a spot on mars, so we can't keep them on earth, lord knows we don't wanna get sued... again...

SO! We put the music men on block land perminantly, and let all of the block people out of the factory, uncompressed and stretch free on earth! We all know they don't take much space, unlick SOME people we know... Riiiiggghhht chunky people?

Now the music men are quite small and are well organised, so I'm sure they won't mind letting out the 70% of their free space for other people later in time, you never know when more interesting people will arrive in our universe!!

And that concludes our strategy for this evening, hop to it men!

1

2

1

2

1

2

...

[redhotsonic 376]

Are you pissed?

[Spanner 286]

He just wanted to do something different instead of the usual posts from people that consist of plugging their own hack to oblivion.

[redhotsonic 376]

Yes, it's certainly different.  Made me laugh =P

[MarkeyJester 1091]

Alright, I've had my fun.

BASICALLY!!

What I am suggesting is that you decompress all of the 10x10 (i.e. 16x16) block data for each and every level, and change the engine to read them directly from the ROM, and use the block RAM space for the sound driver, now, those astute idividuals in the thread will automatically state the obvious notion of ROM space usage, i.e. using too much of it for uncompressed block data, now this is indeed a con to the method, but that's why I chose blocks as opposed to chunks, it isn't so much that it's going to be a bother, especially if this individual has already surpassed 4MB and is heading upto the 10MB mark.

The pros behind this though, I feel majorly outbalance the con, for a start, you don't need to decompress and transfer the block data, this will increase the level loading speed (not that it's much speed, but fuck it, it's a pro), the second is that you now have not only enough space for the whole sound driver, but you have an approximate remaining space of about 60-70% to use for something else, should you want to add an interesting and unique feature later on (that of which, I wish most of you would do).

I still feel that taking ValleyBell's advice on organising RAM sections, is still a good idea, if not for the sound driver, then certainly for something else, so keep that also in mind.

[Bobesh8 14]

Alright, I've had my fun.

BASICALLY!!

What I am suggesting is that you decompress all of the 10x10 (i.e. 16x16) block data for each and every level, and change the engine to read them directly from the ROM, and use the block RAM space for the sound driver, now, those astute idividuals in the thread will automatically state the obvious notion of ROM space usage, i.e. using too much of it for uncompressed block data, now this is indeed a con to the method, but that's why I chose blocks as opposed to chunks, it isn't so much that it's going to be a bother, especially if this individual has already surpassed 4MB and is heading upto the 10MB mark.

The pros behind this though, I feel majorly outbalance the con, for a start, you don't need to decompress and transfer the block data, this will increase the level loading speed (not that it's much speed, but fuck it, it's a pro), the second is that you now have not only enough space for the whole sound driver, but you have an approximate remaining space of about 60-70% to use for something else, should you want to add an interesting and unique feature later on (that of which, I wish most of you would do).

I still feel that taking ValleyBell's advice on organising RAM sections, is still a good idea, if not for the sound driver, then certainly for something else, so keep that also in mind.

 

How exactly do I do that?

I'm not too smart at hacking sonic.

 

EDIT: When playing the rolling sfx, tiles start to look incorrect.

Let me guess, it is a RAM problem.

Edited 4 Jun 2013 by Bobesh8

[ThomasSpeedrunner 92]

I don't think the sounds are part of RAM, so that's most likely not the issue. But what do I know on the subject? Not much, that's what =P

 

Also, I personally see no difference in the screenshot you took.

[Bobesh8 14]

I don't think the sounds are part of RAM, so that's most likely not the issue. But what do I know on the subject? Not much, that's what =P

 

Also, I personally see no difference in the screenshot you took.

 

Look close at the waterfall. You will see Horizantal lines.

 

Also, I need help using Non-Module Kos art as level art,

so I can get rid of these to free RAM:

Kos_decomp_queue_count =    ramaddr( $FFFFFF0E ) ; word ; the number of pieces of data on the queue. Sign bit set indicates a decompression is in progress

Kos_decomp_stored_registers =    ramaddr( $FFFFFF10 ) ; $28 bytes ; allows decompression to be spread over multiple frames

Kos_decomp_stored_SR =        ramaddr( $FFFFFF38 ) ; word

Kos_decomp_bookmark =        ramaddr( $FFFFFF3A ) ; long ; the address within the Kosinski queue processor at which processing is to be resumed

Kos_description_field =        ramaddr( $FFFFFF3E ) ; word ; used by the Kosinski queue processor the same way the stack is used by the normal Kosinski decompression routine

Kos_decomp_queue =        ramaddr( $FFFFFF40 ) ; $20 bytes ; 2 longwords per entry, first is source location and second is decompression location

Kos_decomp_source =        ramaddr( $FFFFFF40 ) ; long ; the compressed data location for the first entry in the queue

Kos_decomp_destination =    ramaddr( $FFFFFF44 ) ; long ; the decompression location for the first entry in the queue

Kos_modules_left =        ramaddr( $FFFFFF60 ) ; byte ; the number of modules left to decompresses. Sign bit set indicates a module is being decompressed/has been decompressed

Kos_last_module_size =        ramaddr( $FFFFFF62 ) ; word ; the uncompressed size of the last module in words. All other modules are $800 words

Kos_module_queue =        ramaddr( $FFFFFF64 ) ; $18 bytes ; 6 bytes per entry, first longword is source location and next word is VRAM destination

Kos_module_source =        ramaddr( $FFFFFF64 ) ; long ; the compressed data location for the first module in the queue

Kos_module_destination =    ramaddr( $FFFFFF68 ) ; word ; the VRAM destination for the first module in the queue

Edited 5 Jun 2013 by Bobesh8