I don't know how SNES headers work, but I'm wondering if the DKC3 prototype header is similar to the final DKC3 header (minus the checksum, assuming the SNES uses one like the GB does, since the data will likely be different). Reading this prompted me to compare DKL3's prototype header with the final v1.0 header (from 0x100-0x14F). (For more information on a Game Boy cartridge header, read
this.) It's almost the same between the two versions, except with a few differences:
0x144-145, which determines the licensee code, is different.
In the prototype version, this is 0xAD3E -- this isn't easy to translate into ASCII, but it's worth noting that the English cartridge (at least the final one) has the text DMG-
AD3E-USA. I guess that prior to release, someone mistakenly thought this part of the header was intended for some internal game code or something.
In the final version, this is 0x3031, which in ASCII is 01. According to
this list, 01 = Nintendo.
0x14D, which determines the header checksum, is different.
(This is determined starting with the integer 0xE7, and then taking the values from offsets 0x134-14C, subtracting them all, and taking the last 8 bits.) This checksum needs to be valid in order to run on real hardware. The checksum change makes sense, as the data above has changed. In the prototype, it is 0x51, and in the final, it is 0xDB.
0x14E-14F, which determines the global checksum (this adds all the bytes in the ROM, excluding itself, where the result is a big endian 16-bit number), is different. (The global checksum doesn't need to be valid to work on a real Game Boy, but the emulator BGB raises warnings about it -- an invalid global checksum implies that the game is hacked.) This difference also makes sense, as there are many changes from the prototype and final (which includes the changes mentioned above, and all the changes mentioned in the past). In the prototype, this is 0xC95A, and in the final, this is 0xF1BA.
Point is, how different is the prototype DKC3 ROM header from the final DKC3 ROM header? And does changing it to resemble the final header seem to do anything?
As for Barrel Boulevard, there seems to be a way to fix this glitch. Use a hex editor and go to offsets 0x40419-4041A. In the final, this hex string is 0xFFFF, but in the prototype, it is 0x0A00. Changing this to 0xFFFF, like in the final version, fixes the glitch for whatever reason.
(If you want to see more information on this, go here -- the bytes that you're changing here are the ones that I labeled xx and yy. Unfortunately, I don't know what these bytes do besides determining whether this death glitch occurs or not. If you want to see the offsets for other levels, go here (English version) or here (Japanese version). It's weird that in the final version, Barrel Boulevard is the only level to have 0xFFFF as this byte value, whereas other levels seems to have different values -- Raccoon Sam and I tried figuring this out years ago, but were unsuccessful. I should probably get back to figuring out the purpose of the two bytes now that I know how to use BGB's disassembler.)As for what's down there, it seems to be the same thing as in the final version (although I only took a quick look) -- two Sneeks followed by the flagpole.
EDIT: Fixed a typo.