+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  NES graphic check, if certain tiles are altered, game won't work
Pages: [1]
Author Topic: NES graphic check, if certain tiles are altered, game won't work  (Read 2 times)
Kagemusha
Guest
« on: June 23, 2009, 03:21:13 pm »

So Jarvas has got this graphic check on or around startup for the number tiles and if those tiles are altered in any way, the game will not work. I'm not really sure how this is done aside from it might have something to do with a CMP and the tile values, but that hasn't provided any results for me. Would anyone know how this check of sorts would work? There are multiple tile sets and the check applies to all of them, at least I think so. What I'm looking to do is disable it so I can replace those tiles.
« Last Edit: June 23, 2009, 03:58:35 pm by Pennywise »
Ryusui
Guest
« Reply #1 on: June 23, 2009, 10:37:07 pm »

Might be something as simple as a checksum. Adds up all the bytes and compares 'em to a value. Should be simple enough to break.

Just check for reads from one of the tiles that trips the checksum and follow it from there.
Kagemusha
Guest
« Reply #2 on: June 24, 2009, 01:51:23 pm »

I don't really know how checksum's work, but for this particular game there's a table that game checks and if those bytes don't match up(That's what I'm assuming), the game will skip ahead to some code that leads to a jump to the same location as the jump occurs resulting in an infinite loop of sorts. All I had to do was NOP out that code that told the code to go there and presto.
KingMike
Guest
« Reply #3 on: June 24, 2009, 03:31:39 pm »

That's exactly what a checksum does. It checks the sum of some data. Smiley
Kagemusha
Guest
« Reply #4 on: July 02, 2009, 10:25:14 pm »

I guess I got another checksum issue and this one is a bit different from Jarvas. If you change any byte  in the ROM, after you get the past the start/continue screen, the game will be extremely wacktastic and won't crash right away until you jump. Last time for Jarvas, I got a clean crash and I could tell by the code what was going on, but I'm not sure about this one. Although it might have something to do with this code, which seems to be executed throughout the game.

Code:
$EF5B:4C C3 EE  JMP $EEC3                  A:F0 X:6C Y:01
$EEC3:B1 12     LDA ($12),Y @ $EFAA = #$06 A:F0 X:6C Y:01
$EEC5:0A        ASL                        A:06 X:6C Y:01
$EEC6:0A        ASL                        A:0C X:6C Y:01
$EEC7:A8        TAY                        A:18 X:6C Y:01
$EEC8:B9 B1 06  LDA $06B1,Y @ $06C9 = #$F0 A:18 X:6C Y:18
$EECB:C9 F0     CMP #$F0                   A:F0 X:6C Y:18
$EECD:D0 03     BNE $EED2                  A:F0 X:6C Y:18
$EECF:4C 55 EF  JMP $EF55                  A:F0 X:6C Y:18
$EF55:C6 1A     DEC $001A = #$01           A:F0 X:6C Y:18
$EF57:30 05     BMI $EF5E                  A:F0 X:6C Y:18
$EF59:A4 1A     LDY $001A = #$00           A:F0 X:6C Y:18
$EF5B:4C C3 EE  JMP $EEC3                  A:F0 X:6C Y:00

It appears to be checking FO with a value in RAM and that might be what's causing the problem, but if I mess with, the game will stay about the same or get worse. I don't think it's it.

Oh yeah, different game. Fudou Myouou Den
« Last Edit: July 02, 2009, 10:34:07 pm by Pennywise »
KaioShin
Guest
« Reply #5 on: July 03, 2009, 01:59:46 am »

Hey, you're a romhacker, if you think this is the right value there is a very very simple way to test. Just hardcode the jump so it always or never executes (don't know which one is "right") and see what happens. The art of romhacking: Try around and break stuff and things will come together by themselves.
KingMike
Guest
« Reply #6 on: July 03, 2009, 07:55:19 am »

It's checking if the value in RAM is $F0.
Kagemusha
Guest
« Reply #7 on: July 03, 2009, 05:11:36 pm »

I seem to have the tendency of asking for help when I don't need it. Almost like I can't quite cut the ambilacal cord, but this particular issue is puzzling me. That code I posted probably isn't right, I was trying to repeat the method in which I found the code responsable for crashing Jarvas. It executed itself multiple times before the game completely crashed when the character jumped as in jumped in the air. The game was messed up before that. My only guess is that changing any byte within the ROM will alter values in multiple locations ranging from $100-$800 (I believe that's RAM), which will in turn fuck up the game. That's just based on comparing trace dumps.
Tauwasser
Guest
« Reply #8 on: July 03, 2009, 06:58:09 pm »

So if you have comparison trace dumps... Go to the first difference and figure out why it exists?

cYa,

Tauwasser
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC