Shawn Posted January 3, 2006 Share Posted January 3, 2006 (edited) Hey, I got a diassembly of a game and I have been working with it in notepad for the color tables and registers and other various things but it seems when I try to edit the actual graphics it makes the BIN corrupt?? Yet when I recompile the ASM and then use BitHacker instead to do the graphical changes all is fine!??! Is there something simple I'm missing a la N00b agian? Im using the new version of stella as my EMU of choice for testing the BIN if that matters. Thanks For Any Help, Shawn Sr. Edited January 3, 2006 by silver_surfer Quote Link to comment Share on other sites More sharing options...
Tom Posted January 3, 2006 Share Posted January 3, 2006 Could be a problem with the cartridge type of the particular game you're trying to hack. Maybe you cuold post the original rom image and an (unmodified) disassembly of the game you're trying to hack. Quote Link to comment Share on other sites More sharing options...
Shawn Posted January 3, 2006 Author Share Posted January 3, 2006 Could be a problem with the cartridge type of the particular game you're trying to hack. Maybe you cuold post the original rom image and an (unmodified) disassembly of the game you're trying to hack. 993115[/snapback] Check your PM box good sir. Quote Link to comment Share on other sites More sharing options...
Tom Posted January 3, 2006 Share Posted January 3, 2006 Hm, could you also post the changes you made that break the binary ? Quote Link to comment Share on other sites More sharing options...
Shawn Posted January 3, 2006 Author Share Posted January 3, 2006 Hm, could you also post the changes you made that break the binary ? 993148[/snapback] Just go in the TXT I sent you and alter any of the sprites made up of "X" 's XXXXXXXXXXX XX XXX XX XXXXXXXXXXX XX XX XXXXXXXXXXX and if I was to change that to: XXXXXXXXXXX XX XXX XX XXXXXXXXXXX XXXXXXXXXXX XXXXXXXXXXX and then reassemble it back into a BIN it just crashes?? weird eh? Shawn Quote Link to comment Share on other sites More sharing options...
Tom Posted January 3, 2006 Share Posted January 3, 2006 (edited) I can't seem to reproduce it. Edited January 3, 2006 by Tom Quote Link to comment Share on other sites More sharing options...
Shawn Posted January 4, 2006 Author Share Posted January 4, 2006 I can't seem to reproduce it. 993389[/snapback] So your not getting an Error or a corrupt BIN? weird, I better have another look. Thanks for your help none the less. Always good to get someone else to try it out to see if its a simple problem and obviously it something I'm doing as your not getting the same results. Quote Link to comment Share on other sites More sharing options...
Tom Posted January 4, 2006 Share Posted January 4, 2006 Well, I managed to change the graphics for the walking smurf animation in the disassembly, reassembling worked fine. If you posted an actual modified source code snippet that actually breaks the binary (for you), people might be able to help you. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted January 4, 2006 Share Posted January 4, 2006 Yup, that's the only way to pinpoint the cause. Since hacking an assembly could create a non-working game in a variety of ways...here's a few easy suspects: Indirect jump vectors no longer pointing to the correct "landing" spots. Gfx data being shared with regular data (or even program instructions). "Broken" or missing delimiters used in gfx tables. After assembly...an easy way to double-check your work is to use Dos' file compare to check the new hack angainst the verified-running original you began with...like this: fc /b original.bin hack.bin > changes.txt A text file named "changes" will be created and list all of the altered rom locations. A quick look though it should be enough to see if any of the altered rom locations are not part of the area you thought you were working in. If the hack is missing a byte someplace, for example, the file will report massive changes (as all of the rom memory has been shifted up following the missing byte). Quote Link to comment Share on other sites More sharing options...
supercat Posted January 4, 2006 Share Posted January 4, 2006 Yup, that's the only way to pinpoint the cause. Since hacking an assembly could create a non-working game in a variety of ways...here's a few easy suspects:Indirect jump vectors no longer pointing to the correct "landing" spots. Gfx data being shared with regular data (or even program instructions). "Broken" or missing delimiters used in gfx tables. 994086[/snapback] Any hack that shifts anything in code is apt to break things severely unless all address dependencies have been taken into account in the disassembly, and even then there are no guarantees. Also, some programs may have certain data dependencies with colors or even sprite data. In Adventure, for example, a bit of each color value is used to determine whether it should be interpreted as a "normal" value or a "flash" value (e.g. as used for chalice colors). Additionally, Adventure uses a zero byte to mark the bottom of each sprite's shape. This allows sprites of many different sizes to be stored efficiently, and also allows display to be started mid-sprite (which is how the porticus animation works). It does, however, mean that it's essential to avoid any blank rows within a sprite (that's why one of the bat frames has the funny dots above it, and why there are some extra dots in the Easter Egg message object). Further, a few games may make 'interesting' assumptions about colors or shapes. For example, in my Archon kernel demo, I use X and Y to hold the two color values (blue and yellow). In my kernel, I do stx VBLANK ... draw the nice part of the frame sty VBLANK This provides a very nice way to avoid having anything show outside the proper area of the screen. But it only works if bit 2 of x is clear and bit 2 of y is set. Changing the values in X and Y to use different colors may cause that code to stop working if the wrong colors are chosen. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.