Editing Graphics From A Disassembly

[Shawn]

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

[Tom]

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.

[Shawn]

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.

[Tom]

Hm, could you also post the changes you made that break the binary ?

[Shawn]

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

[Tom]

I can't seem to reproduce it.

Edited January 3, 2006 by Tom

[Shawn]

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.

[Tom]

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.

[Nukey Shay]

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).

[supercat]

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.