Sonic 3D general hacking topic

Doesn't ESE and other little programs have a SMD-to-BIN converter? I think it'd be less hassle just to find the .BIN of the ROM from SonAR or sites that carry the GoodGen copy of Sonic 3D Blast (which would be Sonic 3D Blast (UE) [!]).

If you have a .GEN version, it's basically a .BIN file renamed to .GEN so that's easy to correct.

EDIT: Oh, address converter. I'd just limit it to only use .BIN files to avoid such issues.

 

Yeah, it was a .SMD I messed with - just found the file. Damn.

Eh, hopefully we can come up with something. Would be a shame to have all of it go to waste.

 

You could always see how little interweaving there is by taking an address you know the location of in the smd version and bin version, and finding the difference in offsets. Then apply this difference to find a smd address in the bin version. If this doesn't want to work then you're probably going to have to use a more advanced algorithm. As long as there's no compression though, there should be a mathematical approach to finding the differences and their consistencies.

 

I'll whip up a program to convert an address form an SMD ROM to BIN. It shouldn't be too hard.

 

Doesn't ESEII convert from SMD to Bin?

 

Converting SMD to BIN has been done many times before. What they ask is a program to convert an address in a SMD ROM to an address in a BIN ROM. It's nearly finished BTW.

 

Ah, my bad then.

 

It's done now. I've done some minor testing and it works as far as I know. Any suggestions on where to upload it?

EDIT: http://rapidshare.com/files/179365243/smdadrconv.rar
It's a command-line tool. You enter the address in the SMD ROM (hexadecimal), hit enter and it'll spit out where that byte should be in the BIN ROM. The source has been included (yes, it took me this long to write 28 lines of C code, never said I was a good programmer :P).

 

You don't even need the SMD file, actually. You just enter the address and it'll give you the address for the BIN file.

 

That's great Sintendo! That will be really useful for converting those addresses.

In the meantime, I've got a .bin version, so I might start playing with it again and attempt to find some more data as well. Should be far more useful now that I am using the correct version.

 

SMD

Apparently, no.

 

Not according to this document. The header is always 0x200 bytes (0x000 - 0x1FF) and every block is 0x4000 bytes (0x2000 for the odd and 0x2000 for the even bytes). Besides, if the blocks/header had a variable size, we would never be able to decode S.N.N.'s document anyway, since we don't know what size the blocks had in S.N.N.'s ROM when he wrote that document.

I've done some testing with two identical ROMs in the two formats (created using one of the many converters out there), and the addresses that the program returns are correct. It is possible that I've made a mistake somewhere though, so I will be doing so more testing soon. If you notice anything off, please do tell me.

 

I did a couple conversions using your tool (from my document), and they seemed to line up in the .BIN just fine. I'll be messing around with it for a while though, since it seems useful so far.

I was able to make up a small .tbl file and do this, in the meantime, though it's nothing exciting yet.



I'll get the addresses shortly .. want to play around with it a bit more.

EDIT: In the meantime, I've been trying to pick up on the sound format for this game. I've worked with SNES's N-SPC format quite a bit, and I've notice that this is surprisingly similar.

Here is a very minor change to DDA2's theme (mostly just an octave shift). (sorry for the large WAV file .. wasn't thinking when I exported it). I was wondering if there was some kind of documentation on this floating around. If there is, I would be extremely interested in reading it.

Thanks

 

I put together a small test to see if my program is working correctly (basicly let it compare the bytes in both the SMD and BIN ROM to see if they are the same). I've tested it with a Sonic 2 ROM (couldn't find a Sonic 3D one :/) and it returned zero errors, which means my address conversion code is fully working as it should. I'll try it again once I get my hands on a Sonic 3D ROM, but it's unlikely that the tool will choke on that. Just posting this so you don't have to worry about the program messing up and returning wrong addresses. =P

 

SNN...

Sonic 3D Blast and most other MegaDrive Sonic use SMPS, aka the Sample Module Playback System. There's a guide about it on the wiki, which can be found here.

 

Thanks a lot roxy. Tweaker mentioned to me yesterday that he already has it all documented, so looks like I'll move on to something else within the ROM .. heh. Maybe tile data or something.