[Evan]

Martin from NES World sent me several SNES prototypes that he dumped. The first one that I made an article of is for Battle Blaze, a mediocre fighting game. The most interesting thing is that this game has a connection to F-Zero.

http://www.snescentral.com/article.php?id=0994

[Dradsa]

Very cool read! looks as if they were aiming for the next big Mortal Kombat but failed haha. Would Nintendo have given the code away for FREE? Or perhaps royalties were payed? Very strange...

[Evan]

I would agree with the Mortal Kombat thing, but this game predates it. More likely, they were trying to capitalize on the Street Fighter II rage.

[Tongueman]

It's possible Nintendo sent out code examples with their SFC devkits.

Or perhaps this is a possibility:

[Evan]

I like the idea that they stole the code. It might explain why the mode 7 stuff is tricky to emulate.

[GDRI]

Similar situation: Graphics from Putt & Putter (SMS/GG) turn up in Vattle Giuce (GB)

[Vlcice]

I remember that a Sonic 2 beta had graphics from a completely unrelated game. The explanation there was that EPROM writers just skip over blank sections rather than erase them, so empty sections of game contained whatever happened to be on the cartridge before. I don't know how Nintendo prototypes were handled, but is it possible that the cartridge with this Battle Blaze proto used to hold an F-Zero proto before?

[BMF54123]

Actually, it seems much more likely to me that Sammy reused an old development board, one previously used for F-Zero (perhaps Nintendo sold their used development hardware at a discount, or F-Zero was merely used to test the carts). When the Battle Blaze data was burned to the EPROMs, areas that weren't used were simply not written to, leaving "holes" where the original F-Zero data shows through. Some old Genesis prototypes exhibit the same phenomenon; there's data from a TMNT game in the padding at the end of the "Sonic Crackers" ROM, and data from Chiki Chiki Boys scattered around the old Sonic 2 prototype.

Besides, if the F-Zero code really was used as a base, why would it only appear in a prototype between the JP and NA releases?

[edit]
Blah, I'm too slow. Vlcice got it.

[drx]

This is actually a myth.

There is no way to properly erase an EPROM while leaving so much "unused" space. Erasing an EPROM means applying certain UV light to the EPROM window which wipes out all data it touches. EPROM erasing sets all the bytes it can to FF, and EPROM writing can set individual bits from 1 back to 0.

The leftover data would have to be surgically left over in order to leave it there and yet allow to properly burn a working ROM.

The more sensible explanation is that compilers back in the day didn't bother to really clean the memory used for padding, resulting in data being there that just randomly happened to be in that specific part of memory (for example from being used in another program, or being previously compiled).

Now, this applies to every case except that Sonic Crackers cart, which the guy who burned it didn't bother to take the TMNT eproms out (the TMNT data was on separate unerased EPROMs, as Sonic Crackers was twice as small as the TMNT ROM). Which is pretty horrid, considering he did that to tens of prototypes.

[Evan]

I guess the main problem with the idea that they just reused an F-zero board is that the two games are of different sizes (F-zero is 512 kB, while Battle Blaze is 1 MB), and the F-zero stuff doesn't align. Unless of course the ROM was somehow interleaved, or that both ROM chips had F-zero on them.

[Xkeeper]

[Evan]

The probable reason why the data is in the wrong spot is that both of the EPROMs had copies of F-zero on them.

[mrdomino]

[TheRedEye]

Is it really so surprising to learn that maybe -- just maybe -- people with access to development carts and BBS systems might have oh, I don't know, downloaded and burned games to play?

[Evan]

I have a couple more up:


Zoop

TKO Super Championship Boxing

[KingMike]

Both links are to Zoop.

[Evan]

Copy-pasta error

[Evan]

Got another one up!

The Flintstones - The Treasure of Sierra Madrock

[Tongueman]

That's interesting that the proto of the Flinstones runs at what, half-speed? Do you think it could be set that way for debugging purposes? I don't think it has anything to do with poor coding or compression as it's unlikely a decompression routine would be running during actual gameplay.

Also, those tiles in the proto look like they're almost identical to the final; you just need to change the tile offset a bit more in your tile viewer by about 4 steps.

(sorry, in other words, I'm debunking your technical guesses.)

[Evan]

Nah, they aren't exactly the same. The settings are identical in both views, so there is a fundamental difference in the way they are stored. Also, it is possible that those tiles are garbage data, as most of the other graphics are compressed and cannot be seen visually in a tile viewer (and like I said, I never found the place in the game where that area in the memory is accessed, even though I played through the entire game).

You are right though, the slowdown might be a debugging feature. Or even an anti-piracy feature. The decompression idea was suggested to me by an emulator developer.