11 March 2016 - Forum Rules

Main Menu

Cannon Fodder GBC bugfix

Started by FernandoLemon, January 04, 2023, 01:20:47 PM

Previous topic - Next topic


From The Cutting Room Floor:

QuoteDuring the FMV intro, the wave channel is set to the wrong frequency, causing the streamed music to be glitched. The wave channel is set to the correct frequency everywhere else in the game.

This is a shame, because although the intro's high quality animation was one of its biggest selling points, the glitched audio is very much noticeable, and there doesn't seem to be a patch for it yet.

I wanted to ask people with more experience at this what tools could help me out here. It certainly sounds like an easy fix, but I'll remain cautious because I've learned from experience not to underestimate things like these.


Wow! When I've seen for the first time a video of the Cannon Fodder GBC version, I heard musics and SFX are alsmost more than 8 bits. Now, I already know two games:

- Tarzan
- Cannon Fodder


I got someone else to look at the code, but it looks like this is way more complex than initially thought.

Quote0xC000-0xCFFF is RAM
No wonder we saw different results. The RAM is getting dynamically updated with new code.

QuoteI did a bit of digging and found this
12CA:  FAFCCE    ld a, [$CEFC]
12CD:  E01D    ld [$FF1D], a
12CF:  FAFDCE    ld a, [$CEFD]
12D2:  E01E    ld [$FF1E], a
12D4:  3E20    ld a, $20
12D6:  E01C    ld [$FF1C], a
This is some driver code, where the game is using 0xCEFC and 0xCEFD to hold the wavelength values that need to be sent to the wave channel
The code around it, on the other hand, is entirely graphics code
Between the structure of the code and the way TCRF says that it's an intro FMV, it looks like it's unpacking audio and graphics data out of the ROM into memory and then copying it into the video and audio registers
Which means that this isn't a code bug -- it's a data bug.
The FMV was written into the ROM with the wrong wavelength values.
And it would require a fair amount of reverse-engineering to figure out how to re-encode the data correctly
It's reverse-engineering that it appears someone has done before because there's the TCRF clip and a YouTube video showing the corrected intro

By YouTube video, I assume they mean this one:

After I commented the audio was actually superimposed and not an actual in-game fix, they had this to say:

QuoteIt is, no doubt about that
But the point is, the reverse-engineering had to be done to understand how the data was stored in the ROM
If you had that knowledge, you could figure out how to make a version of the data that didn't have the problem


The raw audio stream is from 30:41b0 - 3a:43e0  (0xc01b0 - 0xe83e0). You can use MM_X's GameBoy Wave Convertor tool on it.

Opened it as 8-bit unsigned mono @ 8192

Then realized intro uses 0x72d frequency so bumped to 9939

Which seems a bit fast for me. My math is likely off somewhere.
Frequency = 4194304/(64*(2048-x)) Hz = 65536/(2048-x) Hz.

The intro engine does not use a timer so it can keep pushing new colors mid-frame and also uses hdma to upload more fmv tiles.

Audio uploads 5 times per frame but at pretty uneven intervals, so tempo mini-jumps all over the place. Rest of the game uses a timer to consistently deliver its audio so it has much lower distortion with pcm.

A small experiment which sounds a few bits better but nowhere clean like the raw audio (tries to smooth out the audio uploads)

If we don't care for the fmv, it improves but no timer used and crackle distorty

I have no idea if the external audio pin can be used as a waveram sampling replacement with new hardware extension.

This is a really hard problem, and requires some great optimization mastermind. And now I greatly wonder what other games were affected by this timing distortion.
(I was pretty surprised at the quality level of the clean 4-bit stream)