Sonic 1 sound driver in PAL systems

Well. I have tested my Sonic The Hedgehog hack in my real PAL consoles and in my Nomad. The songs sounds perfect in the Nomad system (NTSC-60Hz.) but the songs are too slow in the PAL (50Hz.) MegaDrive consoles (yes, I know, it's like this with the original Sonic The Hedgehog). I was wondering if a fix for this could be possible to make the music sound the same in both systems (NTSC and PAL).


I'm using the original Sonic 1 soundriver untouched.


Thanks.

 

It's an ordinary problem for games running sound driver on M68K (e.g. smps68k driver). Games using Z80 for the whole sound driver can get rid of this issue (test later Sonic games with smps/z80 driver on PAL region).


In fact, using Z80 has lots of advantages. You will free up the main processor and this will increase the performance. The best thing is that Z80 runs sound driver only, it don't have to take care of other things. Thus, you can control sound driver timing, which wasn't possible on M68K (there used VBlank for timing). Z80 sound drivers seem to alter timing depending on your region, so music will play at same speed on both PAL and NTSC machines.


Actually, I can be wrong in certain points as I've learned only basic ideas about how sound drivers work. To my mind, fixing the issue with M68K drivers isn't easy job as they weren't designed for this. The only way I see here is using Horizontal Interrupts for sound driver timing, i.e. interrupt game within some number of lines (less lines for PAL, more for NTSC). But this way seems to be hackish and I'm not sure if it's usable, at least nobody did it.

 

vladik, you're somewhat incorrect about Z80 drivers automatically fixing it. It's actually a PAL check in the sound driver, which skips things (Someone more skilled in this area will have to correct me and make things clearer) and then plays the music at the correct speed. There's several Z80 SMPS games without PAL optimisation, and several 68k SMPS games with PAL optimisation, and has even been taken into some hacks like Megamix.


Point I'm saying, is that while I don't know the specifics, it's just some PAL checks and doing some things in the sound driver. That said, there's some other optimisations you'll want to make as well as the sound driver -- physics, deformation, etc: the whole game is running at a lower framerate, not just the sound driver.

 

I didn't know few game actually fix playback speed on M68K driver. Can you name other games that have it besides Megamix? I haven't seen them yet, all smps68k games I know don't have PAL optimization.


I don't find global game optimizations necessary, the only pointless thing you will want to get rid of is this (in VBlank and VBlank_Sub00):



btst #6,($FFFFFFF8).w ; is Sega PAL (European)?
beq.s loc_BBA ; if not, branch


move.w #$700,d0


dbf d0,* ; delay processor



I don't know why they did it, it just wastes processor's time (Sonic 1 hates PAL region =).

 

I don't know all of them, but one I remember is that The Revenge of Shinobi is one that is optimised. There may be some others, but I'm not sure.

 

It's basicallty as vladikcomper pointed out.


All games require some form of timing mechanism to keep the processor(s) processing the game at a steady speed, if a game has four objects on screen taking up some processing time, and then two objects were deleted, the processor(s) would be able to process the last two objects a lot more quicker than the four objects altogether, but you wouldn't want the entire game to suddenly speed up to an extremely fast rate, nor would you want it to slow down when more objects come on screen.


So what the timing mechanism is designed to do is count upwards, and if the processor(s) has/have already finished processing the game data, they wait in a loop, just wasting processing time until the timing mechanism has finished counting, it resets and lets to processor run through the game data once again. This ensures that the processor takes the same time to process the game data each time and that the game doesn't suddenly change speed all the time.


The Mega Drive/Genesis doesn't really have a timing mechanism designed for this, so what the programmers used to do is set the processor to hang in a loop wasting it's processing time, but instead, making it wait for the vertical blanking interrupt occurance (i.e. the end of a TV frame draw), and once the interrupt routines have been returned from, the processor will resume and start processing the game data again.


The downside to this is that the TV frame speed is different between regions, USA uses 60hz, while EURO uses 50hz (JAP had both as far as the emulators are saying), what this means is that the EURO machines have a longer time to wait before the vertical blanking interval occurs. Sonic 1 has it's sound driver written in and run by the MC68, so that would mean the SMPS script data would be processed at the speed of the region's TV frequency, thus runs slower on 50hz systems.


There may be a few ways around the timing issue, I had an idea of using the YM2612's timers and checking them to see if they've elapsed before continuing, but I don't know if they will work too well, if they're too fast or too slow, then it won't work too well. Another idea would be to have multiple game loops, each one processing several bits of data under different times, but again, I wouldn't know if that'd be any good either.

From what I was told, it's used so that the processor only writes data to the VDP when it's finished displaying the background colour boarder and the beam is really moving up, to prevent strange colours/pixels from blipping on the bottom boarder, I checked this on hardware, and can confirm that it is indeed what it does.

 

Thanks for all the replys. So doing this possible won't be easy, as I thought. Is anyone interested in try it? if not, what other ways could I try to make the music sound good in PAL consoles? Sonic 2, Sonic 3 adn Sonic & Knuckles works fine with the music in PAL consoles. This "issue" is only happening in Sonic 1 (talking of Sonic games...).

 

Puto once suggested me a possible way to fix this, even though it will introduce some jitter. Basically, if you're running in 50Hz mode, you count the VBlanks, and every fifth one, you process the sound driver code twice instead of once.

 

Interesting, but it would be great if there was a better solution for this...

 

I went ahead and implemented this, and for the most part there is no noticeable jitter


e: actually you can notice it in rapid bunches of notes, but if you're not listening for it you probably wouldn't pick it up.


e2: here's an example mp3: GHZ in PAL with speed fix

 

Thanks to Puto for the original idea, thanks nineko for telling it here and thanks Crash for implement it! I have tested it in my PAL console and it works very good. It's not a perfect fix but I think it's better than nothing.


If someone think in something better to fix this, please, tell me.

 

There's no harm in posting the code, I guess:




btst #6,(v_megadrive).w ; is Megadrive PAL?


beq.s VBla_Exit ; if not, branch


addq.b #$1,(v_palmuscounter).w ; add 1 to frame count


cmpi.b #$5,(v_palmuscounter).w ; 5th frame?


bne.s VBla_Exit ; if not, branch


jsr (UpdateMusic).l ; run sound driver again


move.b #$0,(v_palmuscounter).w ; reset counter

 

Impressive! It sounds pretty accurate too, well done on giving this a shot =)

 

It really sounds good, nice work!

 

You would have been better off making a video, but it's good that you have got it fixed.

 

Sorry for bumping this old topic but I tested deep this code in my Sega Mega Drive and I have to say that is not a good fix. I have noticed the music going slow again a lot, specially in Labyrinthz Zone or when Sonic is hit and loses the rings. It works fine with no much action and no much objects in the game, but when the game is working with too much data the music goes too slow again.

 

Yeah, I've noticed that, it happens when water is onscreen but Sonic isn't in it yet. The code probably just needs to be duplicated in another vblank routine or something but I haven't really looked at fixing it.


edit: Yep, UpdateMusic is called again in the Hblank routine, duplicate the same code directly after that one as well and it should fix it.


e2:It'd probably be tidier to do the check from within the UpdateMusic subroutine itself, I'll probably do this and post a proper tutorial.

 

Oh, sorry, I saw your tutorial before this reply, so everything is already said. Your second version of the code works fine and now it's perfect (I think).


So, thanks for the fix and thanks for the tutorial. Now I play my custom Sonic 1 happier on my MD and I haven't to use always my Nomad