|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Author | Message |
---|---|
|
Sega 8-bit summer of dumps: 4 Master System prototypes + Smurfs Travel the World (GG)
Posted: Sun Aug 15, 2010 11:09 am Last edited by Bock on Sun Aug 15, 2010 11:14 am; edited 1 time in total |
It's sunday, it's ROM release day! And from our cave of wonders we've got no less than four Master System prototypes today. How can we find so many prototypes is a secret beyond my own understanding :-)
First on with the demos: Ghouls'n Ghosts [Demo] for the Master System, a non-interactive, 32KB marquee rolling demo (in the same as the Castle of Illusion or Super Basketball demos). Probably used on CES '90 show floor. What is noticeable here is that the title screen logo is bigger and or better quality than the final release. Why is that ? Probably because when it comes to finalizing the game and fitting it entirely in a 2 megabit cartridge, shaving up data out of the title screen it's one of the easiest optimization to do. World Cup Italia '90 [Demo] for the Master System, a non-interactive, auto-playing demo version of the game. Also probably used on CES '90 show-floor. And then more "regular" prototypes: Monopoly [Proto] for the Master System, one of the early US developped Sega title, up to 8 players, in all its splendor and youth programming roughness. Also read the interesting Kevin Seghetti's thread about the development of games like Monopoly or Alf at Nexa, if you haven't already. R.C. Grand Prix [Proto] for the Master System, the classic top down racer by Absolute Entertainment, also based in the US. A little rough on the collision side, it is a very solid and entertaining game for those willing to complete it. Will our reverse engineers experts find out the differences with the final build? And then finally we have the elusive The Smurfs Travel the World (Les Schtroumpfs Autour du Monde) for the Game Gear. This game is famous for being one of the latest developed and rarest titles on the Master System, and the Game Gear version, although not as rare is also a quite difficult find. The Game Gear version was previously undumped - that's one thing corrected now. The plot smurfs with the sad discovery that "the whole world suffers from pollution", to which the curious answer is to violently smurf living animals out of their habitats. Thanks all for your continued support! |
|
|
Temporary Transitional Attachment Fairy
Posted: Sun Aug 15, 2010 11:11 am
|
This message will auto destruct itself someday.
|
|
|
Posted: Sun Aug 15, 2010 5:14 pm |
Very pleased to see the GG version of Smurfs Travel The World! I really like this platformer, and the music is alarmingly catchy.
When I fired it up in an emulator, I noticed that music and gameplay are noticeably slower in this version vs. what I'm accustomed to hearing when playing the SMS version at 60Hz. I always assumed that I was playing it faster than intended (though I think the game is pleasantly brisk at 60Hz); if what I'm seeing isn't some emulator glitch, then I guess this confirms it. Assuming that 50Hz was the intended gameplay speed of the SMS version, am I correct in thinking that -- since all Game Gears run at 60Hz, yes? -- the developers would've had to rewrite the codebase to "slow down" the GG version? Sorry that this question isn't more artfully phrased! I'm basically just asking "Did the developers have to slow down the GG version to match the speed of the SMS version playing back on a 50Hz PAL system"? |
|
|
Posted: Sun Aug 15, 2010 7:26 pm |
Yes, developers might have adjusted the music engine to compensate for the slower frame rate of a PAL SMS compared to a GG. Music engines often do this even if the game doesn't... | |
|
Posted: Sun Aug 15, 2010 8:09 pm |
Maybe I'm wrong, but I think it's both the music and the gameplay that are quicker. Compare this video of the SMS version, running in an emulator which I assume is set for 60 Hz:
The music is faster, but the character movements are also crisper and quicker -- notice the jumps, for instance. (Is there any way to look at the codebase of the SMS version, or any SMS game, and know for sure whether it was intended for 50 or 60 Hz? Are there any definitive "tells"?) It's interesting that the developers would specifically take the time to adjust for the Game Gear's 60 Hz-itude, rather than just leaving it as is with faster gameplay/music -- especially because the SMS version was only barely released. Personally, I think the game plays and sounds better at the faster speed. |
|
|
Posted: Mon Aug 16, 2010 12:07 am |
Challenge accepted! Unfortunately, the differences aren't particularly interesting: A few instructions change between the prototype and the final build: the prototype sometimes uses the I register to hold a temporary. The final build uses a RAM location instead ($c200). Since the memory access instructions used are 3 bytes long while the instructions to access the I register are only 2, these few instruction differences cause a large number of address to differ. The vast majority of these differences are by 2 or 3 bytes - this is because the offsets of the instructions dealing with the I register in the prototype are: In 16KB bank 0: $01cd4, $01d98, $03bab, $03bce, $03bd3 (Note that after $03c0a, bank 0 is empty)
In 16KB bank 10: $2805f, $28076 and $2809c The only other difference between the builds is that the prototype does not contain a product code in its header. |
|
|
Posted: Mon Aug 16, 2010 12:29 am |
While I'm looking at R.C. Grand Prix - there are two versions of "R.C. Grand Prix [SMS-GG]" around.
MEKA doesn't distinguish between them (they have the same MekaCRC), but SMS Checker does: 56201996 R.C. Grand Prix [SMS-GG] [A]
4902B7A2 R.C. Grand Prix [SMS-GG] [B] These two ROMs differ by a single byte: at offset $00c0e, [A] has $04 and [B] has $0c. The bytes are part of a lookup table - it contains information on which palette entry to flash on the map screen for each level. [B] flashes the wrong entry for the fifth race. So, if both of these dumps are genuine, [B] contains a bug and [A] fixes it. However, given that this is a single bit error and that it would be very unlikely for someone to introduce a bug in such a simple table (the complete, correct table is: 0 1 2 3 4 0 5 6 7 8 9), my feeling is that [B] is probably a bad dump. Unfortunately, the ROM does not contain a checksum... |
|
|
Posted: Mon Aug 16, 2010 4:04 am |
Thanks for the infos on GG R.C. Grand Prix, it's very useful. I don't own the GG version so I could never dump it to confirm (note it's the only supposedly good SMS mode dump left in the "old" section of Meka database). I'd be tempted to say that [B] is indeed a bad dump but I will need to buy a few copies of the games before confirming anything.
(MekaCRC has some serious flaw with some bit combinations and byte orders, yes. It's being phased out anyway) |
|
|
Posted: Mon Aug 16, 2010 9:49 am |
I just purchased a loose copy of RC Grand Prix from eBay so maybe it'll help. | |
|
Posted: Mon Aug 16, 2010 9:54 am |
(MekaCRC accidentally masks out bit 3.)
There's no way to look at a game and tell what speed it was designed for. Some games have timing issues at the "wrong" speed that cause glitches, but it's unusual. More conscientious developers would have coded to support both speeds, but we can also assume games were designed for the speed of the developer's country. |
|
|
Posted: Mon Aug 16, 2010 9:58 am |
Dumping a few copies would certainly be helpful, but there is another argument for [B] being a bad dump: Let's assume that [B] is a good dump and that it contains a bug which is fixed in [A]. Now, [B] is almost certainly newer than the final SMS build of R.C. Grand Prix - the former contains "COPYRIGHT 1989,1992" while the latter is "COPYRIGHT 1989". So, the order of builds would have to be: SMS (Proto), SMS (Final), GG [B], GG [A]
So in this case, we'd expect the bug in GG [B] to also be in the SMS ROMs. However, the SMS dumps do not have the bug. Both the final build and the recently released prototype have the correct $04. |
|
|
Posted: Mon Aug 16, 2010 10:05 am |
Seems correct. I still need to dump it once to move [A] to the upper/confirmed part of meka.nam as the purpose of this transition is to redump all games.
What's the time stamp of your RC Grand Prix files btw? I have [A] 1994/05/15 and [B] 1999/05/15 Sometimes the file date can tell something (they can sometimes be used to cross the information with the trackrecord of the dumper or the era etc.). In an old GoodGG compilation (date unknown) [B] is labelled as "correct" and [A] is "[b1]". I don't know if they labelled it this way based on the timestamp or some other information. I think that some people have been redumping GG stuff as well in the past decade but no trace to be found of their records and information (apart from some I received privately, from eg: aRPI). |
|
|
Posted: Mon Aug 16, 2010 10:30 am |
[A] 28/02/1997 [B] 27/09/2001
Interesting. I just downloaded what seems to be the latest GoodGG (3.13, released April 29, 2007) - this has [A] as "[!]" and [B] as "[b1]". |
|
|
Posted: Mon Aug 23, 2010 2:30 pm Last edited by Bock on Sun Sep 26, 2010 4:28 pm; edited 2 times in total |
I received and dumped the game and confirmed the dump:
56201996 R.C. Grand Prix [SMS-GG] [A]
I will label the other as bad based on your analysis above. Thanks! It was the last good SMS entry in old meka.nam format, i'm quite happy to be done with that (I still have some new dumps to sort out etc. but its a symbolic milestone by itself). |
|
|
Posted: Fri Aug 27, 2010 3:14 pm |
Ooooooh, I love these auto demos!!! Thank you so much for this release! :-) | |