Hey there, Tweaker here. This is a rewrite of a tutorial I wrote at Acmlm's board, fit to work here. Anyway, first off, you must realize that Hex stands for Hexadecimal, which is a base 16 number system. This is similar to decimal, which is a base 10 number system. So let's learn the numbers, shall we? Decimal: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Hex: 0 1 2 3 4 5 6 7 8 9 A B C D E F 10 As you can see, counting to 16 in decimal is equvelant to counting to 10 in hex. Hex is pretty much decimal with six extra values tacked on to it. Now, how do we hack Sonic with hex? Well, as you may or may not know (hopefully may), everything on a computer is represented by binary code (AKA 001010101110, etc). Of course, editing and viewing ROMs -- or ANYTHING -- in binary alone is extremely impractical (unless you're dealing with bit-based compression algorthms and opcodes...). So as us humans oh-so-hate things being complicated when they don't have to be, we found a way to simplify binary; Using hexadecimal. Hex is dealt with by the byte in most operations. In case you don't know your terminoligy, let's fix that right now: Nybble - Half a byte, or a single digit. "A" would be a good example. Byte - Full hexadecimal value, equal to 8 bits, and two digits. Something like "01" or "1C". Word - Two bytes, or 16 bits. Need I really explain this more? "010A" or "1550" would be good examples. Long(word) - Two words, or 4 bytes, or 32 bits. "00012345' would be a good example. FYI, byte types are advanced in powers of 1,024. 1,024 bytes makes a kilobyte, 1,024 kilobytes makes a megabyte... etc etc down the whole damn chain. Now that you know your basics, we can start editing and move on to pointers and such. So first off, what is a pointer? Well, a pointer is pretty much what it's called -- a pointer. It's a hexadecimal string that lists an offset in ROM in which to locate data. (BTW, an offset is just the current byte in ROM that you're at. $012345 [out of $200000, though that bt's redundant] would be an offset.) There are little endian and big endian processors, and the Megadrive happens to use a big endian processor. This means addresses are read as is, so things are a bit easier to deal with. For example, if my pointer read 00123456, first I'd split that into bytes. This becomes 00 12 34 56, which is the address at which the pointer wants to locate data. Let's make a practical example. Let's say you wanted to edit Sonic's art to add more frames to some animations (which you should edt mappings for later, but :P). You can't add them to the current location because there is vital data after Sonic's art. So what we should do is expand our ROM and add Sonic's art to the end so we can add as many frames as we want. We'll say (it isn't really) that the location for Sonic's art is at offset $55439. However, we don't know where the pointer to his art is! So guess what? We're gonna find it. Remember how I said pointers are byte seperated offsets in ROM? Well, take the offset of Sonic's art and extend it to a longword. Originally, $55439, it becomes 00 05 54 39. Run a search for this in the ROM and you should get at least one result. We found our pointer! Now, let's say the end of the ROM is at offset $100000. First we take Sonic's art and stick it at the end of the ROM. Now all we have left to do is to change our pointer to locate our new art set, rather than the old one. So we take our pointer -- currently 00 05 54 39 -- and change it to the correct offset, $100000. So take our offset and extend to a longword and seperate into bytes. This gives us 00 10 00 00. We then replace our pointer with this new value, and viola! Our new art is fully working and intact. You can even delete the old art and it'll still work! Hope this helps some people understand how to use a hex editor better. I may add more examples if requested, but this should be enough to get you going on your own as a better hacker overall.
Everybody's got to write at least one hex tutorial in their life. Looks like you finally did yours. =P
Obviously there's a difference between "knowing hex" and knowing how to use it in a practical sense. That's what I was trying to clarify with this.
Hex for Beginners: Start->Programs->Accessories->Calculator Switch to Scientific mode, then to hex mode, and fire away.
Well, either way, this is nice Tweaker. I have been educating myself on the finer points of Hex whenever I have the time or find the resources, and every little bit helps. Very nice little guide Tweaker
Come on, you know how defensive Frenchmen get about their language. I agree with Hivebrain - it should only need to be taught as a different number base. Most of what you have there is about programming, not hexadecimal, and adding it in a hex guide could confuse people. (I realize that the preceeding paragraph was completely disjointed. I don't care to fix it right now.)
Well, considering this is a forum mostly about modifying binary programming, data or otherwise, I think teaching Hexadecimal in the context of programming is appropriate enough. Though perhaps Tweaker should disjoin the actual discussion of hexadecimal numbering from the rest of his post.
Also, from the programming perspective, it'll be good to cover the simple fact that binary directly translates to hex, 4 bits to a hex digit. I don't think there should be a huge amount of detail on this point, as it will eventually come naturally when working with lots of hex, but it should be mentioned to bring it to the attention of people who aren't as binary-inclined. In other words, the way Tweaker mentioned it in his discussion of the relationship between bits, nybbles, bytes, and words, is quite good as it is.
I was just thinking today that if Greek philosopher Democritus wanted to discuss programming, he'd probably say something like this: "Nothing exists except offs and ons [zeroes and ones]. The rest is just commentary." Meh.
Thanks for the info Tweaker. Every little bit helps. I'm using an hex editor, and I still find it to be confusing and quite difficult to use sometimes. I'm trying to figure out how to use a compress file back into a bin rom file. I tend to try and not ask for help, and somehow try to do this on my own. If so, the replies will be hostile and the usual replay, "do it yourself you lazy ass".
You talking about Rika's reply? He's irritable like that. Ignore him. :P Compressing? Pretty much all you need to do is insert an offset into the decompressor program (TSDC preferred, but Esrael has a set of decompressors as well) and click decompress to an output file of your choice. Then you simply edit the data, and grab the compressor. Compress the file you decompressed and edited before to a new file (try your old filename, with an _c after it. Like, if your old file was HUD.bin, try HUD_c.bin). Take the data in this new file and tack it at the end of the ROM, then change the pointer to the data. If you don't know where the pointer is, look up the offset of the data in the form of an extended longword -- 00 00 00 00. Like I mentioned in this tutorial, if your offset of $12345, then run a search on 00 01 23 45 and modify that to point to the new offset of your data. Hope that helped.
An infinitely useful topic if you're trying to work out how to edit compressed art. http://forums.sonicretro.org/index.php?showtopic=3446
I know I'm gravedigging, but I thought it would save making a new topic for a quick problem. I'm only just learning hex and I'm using the compressed art tutorial above. I think I understand about Pointers, and I've edited the Signpost art to what I wanted, now putting it back into the game via hex workshop, I know how to add the new art at the end of the rom using the compressed bin file, but when I search for the signpost pointer to change I find it, but... http://img20.imageshack.us/img20/1979/helpig0.png I don't know how to change the pointer 0001D978 to the pointer for the new signpost 00080000. I'm making myself sound like a turd but I would appreciate the help.