I got a MD Copier recently, the Double Pro Fighter. I noticed that Treasure developed games like Gunstar Heroes don't run on it. I was able to compare a region cracked Alien Soldier to the original to apply similar changes to Gunstar Heroes and it works. But the confusion is that this routine that stopped the game from running is a checksum routine. I'm pretty sure it's one of two things. Either my RAM has bad spots in it, or that it might be ROM Mirroring related and maybe the checksum generated expects to read the word at $100000, which would be $00000 but on the Copier there is uninitialized RAM so the result is wrong. That's my speculation atleast. Can anyone help me out by either pointing out some sort of test ROM that would help me identify the issue? Or could someone whip up a quick test ROM that simply checks if ROM mirroring happens or not? I was going to try making a ROM mirroring test but I have not gotten into the Genesis programming or 68000 enough to be able to do that yet. If it wouldn't be too much more trouble, some sort of 32 megabit ROM with junk data to be used to calculate a checksum to be sure my RAM is in good working order would be awesome as well. Ofcourse if anyone knows some secret button combination or something to make the Double Pro Fighter do a RAM check that would be nice too.
So do you have any guesses as to why Gunstar Heroes wouldn't work on my console till the checksum routine was cracked? In the emulator Gens the same thing that appears to happen on my copier will happen if you add to the end of Gunstar Heroes some extra bytes of 00. After the Licensed By Sega screen it just hangs with a black screen.
Ahem, I think all SEGA licenced developers were obligated to add a checksum routine to their code. Most SEGA 1st party games will show a blood RED screen if the CRC is wrong.
what l_oliviera said is correct. I doubt the copier will just let one write into the ROM area for doing some nice RAM testing... I would not know where are the control regs and how they operate...
Actually what I meant was not to write to the ROM area, just make a 32M ROM that actually did a test to verify all of the ROM was loaded correctly. But if all games do this, then that's not the problem with the copier and Treasure games. No idea what it could be then, but they most certainly do not work on the DPF unless that checksum looking routine is cracked. Even the US Gunstar Heroes on my US Genesis won't run unless that routine is cracked.
Well that's good to know. But it's a mystery to me why it's only Gunstar Heroes and presumably other Treasure games.I haven't tried the other US Treasure games yet to see if they suffer from this too. I suppose if Sonic 3D Blast checksums the whole 32mbits of ROM then my RAM is fine. I may end up replacing the DPF with a Flash cartridge of some kind but before I do I think I'll test out some other Treasure games to see if it is indeed common amongst them all, but I'm pretty sure that the Gunstar Heroes ROM I have is good.
if you disable autofix checksums in emulators, you can spot quite a lot of trouble.... Nearly all games use standard checksumming procedure, few that don't will not run when autofixing is enabled (I've forgotten which titles, but they were EA ones).
Well, I use Kega Fusion for emulating, and have AutoFix off normally. My ROMs are good, that's certainly not the problem for Gunstar Heroes not working on the DPF. Too bad someone else here doesn't have a DPF or even a Super Magic Drive to test and see if they got similar results.
MD Copiers mostly keep the SRAM active all the time. And I know of games that refuse to work if they detect standard SRAM (like for example Megaman/Rockman Willy Wars.)
I'll show you exactly what's going on, and just by breaking this routine's possibility for failure, the game runs. Other games I don't have to do this for them to run. Gunstar Heroes: Address Space $000350 move.l #$00000200,A0 move.l #$000001A4,A1 move.l (A1),D0 moveq #$00,D1 add.w (A0)+,D1 cmp A0,D0 bcc #$fa move.l #$0000018E,A1 cmp.w (A1),D1 bne #$00FC By changing that final instruction, bne #$00FC to NOPs, the game will run on the DPF. But without that change, it would always hang at a black screen, not a red one. I haven't checked Sonic 3D Blast yet, but I would assume it does a checksum of the whole ROM and if it failed it wouldn't run. But it did run just fine. Games that I've run on the DPF with no troubles include: Battletoads Strider Crusader of Centy Streets of Rage Snake Rattle 'n' Roll Shadow Dancer Contra Hardcorps Sonic 3D Blast I will try some other Treasure games today to see if they too won't run without that checksum routine cracked. Update: Dynamite Headdy, which the good ROM ( [!] ) has a bad checksum, actually runs fine on the DPF. Retested on the same disk, Gunstar Heroes, it still fails when not hacked. The McDonalds game works without changes. Testing Light Crusader, the last US Treasure game to test. Update: The only game, reguardless of development that doesn't work for me, is Gunstar Heroes. The CRC32 value for my Gunstar Heroes US region ROM is: B813CF0D If anyone can check theirs against that CRC32 value maybe it really is I just have a bad ROM for Gunstar Heroes. As I said currently it's the only game I'm aware of that is not working.
I was just thinking about this and wondered why Gunstar Heroes is the only game having this problem. The only games I'm sure run a checksum are the Treasure games. I've tested a few games in emulators, changing a byte to throw off the checksum to see if the game hangs. The ones I tried didn't, only Treasure games did. So I was thinking, maybe it's just by pure luck that Gunstar Heroes fails and other games don't perhaps due to bad RAM as I've been suggested it might be. Perhaps Gunstar Heroes needs a certain bit or few bits in RAM to be 0 or 1 but they are defective and stuck on the opposite but these bits don't bother or match what other games place there. Hopefully that makes sense. So I suppose a test ROM for testing the RAM could be as simple as two different ROMs, one that puts 00s at every single byte (other than the code doing the checking) and would report success or failure if all the expected area was 00. Then have another ROM where it does the same thing but with FF. Update: Someone was nice enough to code test ROMs for me at SpritesMind.