Hudson Hawk’s One Byte Bug by Warren Pilkington

Commodore Format’s Warren ‘Waz’ Pilkington is back, and he’s noticed something amiss in Ocean’s cracking puzzle platformer Hudson Hawk…

Back in issue 14 (December 1991) Commodore Format gave a very favourable review to Ocean’s film licence conversion of Hudson Hawk. Its mix of not just platform action but also puzzles to solve along the way definitely made for a different licence, and the cartoon style graphics were very different from the other licences at the time. It scored 88% in CF, and the relaunched Zzap! 64 also gave it 82%, indicating a solid release, and as both reviews stated at the time, it was much better than the movie. There are various instances where Gary Bracey of Ocean despaired at the way the original script was being messed around with by Bruce Willis and turned a potentially promising film into a box office turkey – all because of Willis’ ego.

Naturally, a solid conversion on the 8-bit games meant a solid all round experience, with Special FX’s team handling the C64 version, and handling it well. I remember purchasing the disk version through some software vouchers from either Zzap! or CF at the time, and this was the large box version complete with baseball cap. I still have the disk in its original box, although the baseball cap didn’t survive a couple of house moves over the years. But one thing throughout had bugged me.

If you let the title tune play, when the tune looped you could hear that one of the background voices was out of sync, and seemed to be a little ahead of where the rest were at the time. Thinking it might have been a mastering error with the disk, I sourced an original cassette version at the time, and this still had exactly the same problem, so sounded much like either a full mastering error or a small bug in the code somewhere, as when the tune initialises on the title screen it does play properly first time round, just when it looped later.

So in Autumn 2018, fresh from fixing the Martin Walker title tune from Indiana Jones and the Fate of Atlantis, which I wrote about for CF at the time, I thought it was time to finally get to the bottom of what the bug was, and how it could potentially be fixed. I had already checked Gamebase64 for any versions there, including any original tape or disk images, and the bug existed in all the versions there too. Further listening with DeepSID online, where you can mute the SID voices, showed that it was voice one where the error occurred on loop. It sounded like it restarted at the wrong sequence but it was a case of tracing how the tune would restart and what happens during that point.

Armed with trusty Action Replay cartridge in hand, I used my original C64 disk version as a source reference, primarily as I knew that would be a clean copy to start with (or similar in VICE would have also worked). I loaded up to the title tune, and froze the code. I knew that the music routine was called at $0803, so disassembled the code and found that it referenced the following memory locations from $071A quite a bit. So I took a look under there:

Using the hi/lo byte representation, as these were loaded into zero page locations $04 and $05 for processing the tune, we can see that this relates to $1A61, $1A8D and $1AAA. The next step was therefore to look at $1A61:

This looked like it was the sequence data which was needed for each of the voices. So checking the ends of each voice’s memory locations I noted the following:

$1A8B – F0 03
$1AA8 – F0 00
$1ABF – F0 00

I suspected, like Ubik’s Musik, a particular value means to loop or restart, so in this case the F0 byte is used. Then I thought, okay, so what if the second value is the sequence number that the tune restarts at, which allows the player to be flexible – say for example if you didn’t want an intro part of a tune to play. Keith Tinman had used that in Midnight Resistance in some cases, so made sense.

So I thought, go for it, and amended the single byte at $1A8B to 00 instead of 03, and went back to the Action Replay menu to restart the game. Then I let the title tune loop. Sounded good and then let it loop for a second time. Still sounded good. I had cracked it! So, unbelievably, it was one single byte of data in the music player code that was incorrect (and could have happened by accident when saving the music from any editor). Here’s the same memory code showing the one incorrect byte before it was amended to 00:

From then on it was very straightforward. I could load the existing SID file in SIDEdit, which has a handy function to check the memory locations in its own internal monitor, and could do the same replication there. I got the SID file playing, and looping, and it worked just as well. This then was submitted to the HVSC team, and it was included in their Christmas 2018 update (to HVSC version 70). Any HVSC version since then will include that correct file, so if you have an old HVSC, time to get an updated one. I also concocted two listings, one for the tape version and one for the disk version. Type them in, save them and then run, and when the game loads, the music is fixed! CF