Jump to content

Photo

Editing Graphics From A Disassembly


9 replies to this topic

#1 Shawn OFFLINE  

Shawn

    As Above

  • 18,852 posts
  • So Below

Posted Tue Jan 3, 2006 1:51 AM

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 by silver_surfer, Tue Jan 3, 2006 2:01 AM.


#2 Tom OFFLINE  

Tom

    Moonsweeper

  • 455 posts
  • Location:Switzerland

Posted Tue Jan 3, 2006 2:34 AM

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.

#3 Shawn OFFLINE  

Shawn

    As Above

  • Topic Starter
  • 18,852 posts
  • So Below

Posted Tue Jan 3, 2006 5:12 AM

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.

View Post



Check your PM box good sir.

#4 Tom OFFLINE  

Tom

    Moonsweeper

  • 455 posts
  • Location:Switzerland

Posted Tue Jan 3, 2006 5:42 AM

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

#5 Shawn OFFLINE  

Shawn

    As Above

  • Topic Starter
  • 18,852 posts
  • So Below

Posted Tue Jan 3, 2006 2:57 PM

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

View Post



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

#6 Tom OFFLINE  

Tom

    Moonsweeper

  • 455 posts
  • Location:Switzerland

Posted Tue Jan 3, 2006 3:36 PM

I can't seem to reproduce it.

Edited by Tom, Tue Jan 3, 2006 3:38 PM.


#7 Shawn OFFLINE  

Shawn

    As Above

  • Topic Starter
  • 18,852 posts
  • So Below

Posted Tue Jan 3, 2006 6:37 PM

I can't seem to reproduce it.

View Post



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.

#8 Tom OFFLINE  

Tom

    Moonsweeper

  • 455 posts
  • Location:Switzerland

Posted Wed Jan 4, 2006 3:11 AM

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.

#9 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,885 posts
  • Location:The land of Gorch

Posted Wed Jan 4, 2006 4:16 PM

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

#10 supercat OFFLINE  

supercat

    Quadrunner

  • 6,401 posts

Posted Wed Jan 4, 2006 5:46 PM

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.

View Post


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.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users