[MarkeyJester]

The original crash of Sonic Crackers on hardware was caused on the Z80 side (in this situation, the sound driver). The fact that the game has crashed, but the music resumes playing means that it's something else this time around. Just to be sure, I triple checked my fix on a clean ROM, and tried it on hardware:




My machine is also european, and I also tried with the addons removed for clarity (not that that should matter at all). There are selections in the level select that have been known to do what you describe, but never directly from the title screen. Are you sure you followed the instructions to the letter? And are you sure the ROM was written to your cart correctly? Crackers has no checksum comparison routine, so if a part of the ROM was not written correctly to the cartridge, then Sonic Crackers won't pick up on that.

[Endri]

MarkeyJester, what an absolutely wonderful setup!

ICEknight, on 17 March 2014 - 11:37 AM, said:

Phoebius, on 17 March 2014 - 03:41 AM, said:

Plus, I'd be curious to know how the map screen could be used/modified.

Speaking of, has anybody looked for any unused functionality in there, such as jumping or collision detection?

I remember finding an unused flashing palette in the "electric" field back in the Genecyst days, but I haven't seen it documented anywhere yet, so there might be more stuff in there still waiting to be discovered.

ICEknight, in fact, there are! IIRC, when I was porting Knuckles' Chaotix/creating a reassemblabe disassembly and looking at Sonic Studium for comparisson(s) a long while ago, off the top of my head, the subroutines equivalent to Obj1_SlopeResist and Obj1_SlopeRepel are dummied out.

[Phoebius]

MarkeyJester, on 17 May 2014 - 10:19 AM, said:

The original crash of Sonic Crackers on hardware was caused on the Z80 side (in this situation, the sound driver). The fact that the game has crashed, but the music resumes playing means that it's something else this time around. Just to be sure, I triple checked my fix on a clean ROM, and tried it on hardware

My machine is also european, and I also tried with the addons removed for clarity (not that that should matter at all). There are selections in the level select that have been known to do what you describe, but never directly from the title screen. Are you sure you followed the instructions to the letter? And are you sure the ROM was written to your cart correctly? Crackers has no checksum comparison routine, so if a part of the ROM was not written correctly to the cartridge, then Sonic Crackers won't pick up on that.

Oh! Then I guess I made some mistake? That's weird. Talking about the checksum, I did fix it with a software after editing the rom and before swapping the bytes. Maybe I shouldn't have?

[MarkeyJester]

Well... changing the checksum value in the header will have no effect, but it's what else it might attempt to change without your acknowledgement. But since there's no software in the ROM that checks the sum of the ROM, running a fix is pointless, so I wouldn't really bother with it.

[ICEknight]

Endri, on 17 May 2014 - 11:40 AM, said:

ICEknight, on 17 March 2014 - 11:37 AM, said:

Phoebius, on 17 March 2014 - 03:41 AM, said:

Plus, I'd be curious to know how the map screen could be used/modified.

Speaking of, has anybody looked for any unused functionality in there, such as jumping or collision detection?

ICEknight, in fact, there are! IIRC, when I was porting Knuckles' Chaotix/creating a reassemblabe disassembly and looking at Sonic Studium for comparisson(s) a long while ago, off the top of my head, the subroutines equivalent to Obj1_SlopeResist and Obj1_SlopeRepel are dummied out.

Hmm, interesting.

If only those routines were the same ones that made it to 3D Blast, perhaps there could be a way of porting them back or something... But yeah, I don't think so. =|

This post has been edited by ICEknight: 17 May 2014 - 03:08 PM

[Caverns 4]

MarkeyJester, on 13 March 2014 - 01:40 PM, said:

If you have a hexadecimal editor available, open the ROM. Go to offset 000412, replace 50 00 with 4F D6. Then go to offset 004FD6, replace 10 00 67 33 8B 00 00 31 8B C9 70 23 40 00 00 00 23 00 00 72 32 D8 E5 E4 00 40 48 02 00 23 00 00 23 00 00 13 00 00 4E 10 00 67 with 4E B9 00 00 51 8A 70 02 72 FF 51 C9 FF FE 51 C8 FF FA 10 3C 00 82 4E B8 64 02 32 3C 40 00 51 C9 FF FE 10 3C 00 E1 4E B8 64 02. Finally, go to offset 006432, and replace 4E B9 00 00 51 8A with 4E 71 4E 71 4E 71. That will prevent the ROM from crashing on hardware.

What would all of this mean in the context of putting this fix into the disassembly of Crackers? I've messed with the game a bit on Regen, but the crashing has been bugging me.

[MarkeyJester]

Well, that doesn't actually "fix" the problem, it more avoids it. Lemmy explain why I gave the instructions to avoid rather than to 100% fix.

The Z80 sound driver reads DAC samples through a window into 68k memory (I.e. directly from the ROM) in $8000 byte sections (mapped at offset $8000 - $FFFF). Upon start up, the sound driver sets up the YM2612, PSG, etc, and the bank window address. It does this by sending a bank slot address (that is a byte long) into a port at offset $6000 one bit at a time. It uses the "h" and "l" registers (paired together as "hl") to access the port, meaning "hl" is now set to $6000.

After the setup is run, it goes into a DAC (DPCM) playback loop where it'll read the registers "d" and "e" (paired together as "de") as a DAC size counter, if "de" is set to $0000, then there are no bytes to decompress and flush out (I.e. no sample). What the setup doesn't do, is clear the registers "d" and "e", so "de" contains an unknown value (that unfortunately for us, isn't $0000). So it continues thinking it's playing a sample, the "hl" register pair is used as the bank window offset, but that isn't setup either, it's still set to 6000 when it set the bank address. So it tries loading byte after byte from 6000 onwards, decompressing in a loop. The problem is, around the 6001 - 7FFF region, is a space the Z80 is not allowed to access on the Mega Drive. However, the Z80 seems to have success reading the data from 6001 all the way up to somewhere around 7E00 without crashing, but of course, crashes eventually somewhere around 7E00 - 7FFF (I cannot pin point exactly which offset, but that's irrelevant, it shouldn't be accessing data around the 6001 - 7FFF region anyway). Which is why it takes a while and manages to show a bit of the SEGA logo before crashing.

tl;dr, ensuring the "de" register pair is cleared on startup, will fix the issue (offset E5 the instruction 11 00 00 (ld de,00000h) should be placed).

But performing that fix on a binary ROM is rather difficult, inserting instructions can be difficult without unaligning data/pointers/etc. For the 68k, you can get away with at least jumping to an unused padded section containing the inserted instructions there, and then jump back. But for the Z80 data on the 68k ROM, it's not as easy. On a disassembly, it should be pretty much a one instruction insert (provided the disassembly is fully complete, and all pointers/instructions/referrences are linked up for assembly). The fix I posted before is simply a set of instructions for the 68k, telling it to play a music track, wait a while, and then stop the track before it makes a sound, thus causing the Z80 to clear it's "de" register by itself, thus avoiding it.

If you want to fix it in the context of a disassembly, then use the clearing "de" method, not the previous method.

[ValleyBell]

I'm a bit late, but here is the fix for the Z80 driver:
At offset 0052B7, replace 21 05 1C 7E with 11 00 00 00.

Disassembly:

00C6	3E 04		LD	A, 04h		; start with DAC bank 04 (ROM offset 020000)
00C8	32 05 1C	LD	(1C05h), A	; save to DAC Bank slot
00CB	21 05 1C	LD	HL, 1C05h
00CE	7E		LD	A, (HL)		; load again
00CF	21 00 60	LD	HL, 6000h	; load Bank Switch address

becomes

00C6	3E 04		LD	A, 04h
00C8	32 05 1C	LD	(1C05h), A	; save to DAC Bank slot
00CB	11 00 00	LD	DE, 0000h	; initialize DE (remaining DAC bytes to play)
00CE	00		NOP
00CF	21 00 60	LD	HL, 6000h

It was a bit of luck that they had some redundancies in the code. But else I would've placed the code in the unused slots of the sound priority table, I guess.

[Phoebius]

Thanks a lot, guys! I'll try to flash my Eprom again and make some tests.