(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album
05-14-24 01:20 AM
0 users currently in ROM Hacking.
Acmlm's Board - I3 Archive - ROM Hacking - What do I need?
  
User name:
Password:
Reply:
 
Options: - -
Quik-Attach:
Preview for more options

Max size 1.00 MB, types: png, gif, jpg, txt, zip, rar, tar, gz, 7z, ace, mp3, ogg, mid, ips, bz2, lzh, psd

UserPost
the_icepenguin
Posts: 33/257
Alright this is what Ive got.

I got a clean Zelda 2.

I leveled up my sword from lvl1 to lvl2......and the offset E66D didnt change.

Then i tried this.

I started over again. I changed offset E66D from 02 to 01.

This made my ATK Power at level 1 decrease making all monsters harder to kill.

i then leveled up my sword to level 2 and everything went back to normal.

so this is my theory.

offset E66D is the ATK Power for Link's level 1 Sword.

and every sword level has a different offset.
Ryusui
Posts: 17/58
By any chance, when you tweak memory values like that in FCEUXD, does the memory value merely change to what you specify, or is it permanently set to that value?

If it sets it permanently to that value, that might have the side effects you're talking about if other parts of the game code use that value for different purposes.

If it only changes it temporarily, then we may very well have a larger problem on our hands: the value isn't merely an ATK value; it handles other stuff that the game can't run properly without. Do what you did the first time and see if it has a consistent effect in a fight: higher values mean monsters die quicker, lower values mean monsters die slower. And double-check to see if our "ATK value" hypothesis is right to begin with by seeing if it changes on its own when you increase ATK on level-up. Heck, make sure you didn't change the wrong value by mistake by double-checking to see if the castle errors crop up again.

Romhacking is mostly experimentation: try something, see if it works, and if it doesn't, try something else. Even experts have to take the rinse, lather, repeat approach more often than not. The scientific method applies readily to this line of work: if you think you've found your miracle, the first thing you do is not trumpet it to the world, but see if you can get it to happen again, and consistently. Same thing goes for glitches. Nothing bugs (no pun intended) a programmer of any description more than a glitch that only happens sometimes.

As for your question, I looked on Romhacking.net, but no dice. Google is your friend...learn how to shake him down for every cent he's worth.
the_icepenguin
Posts: 32/257
wow, this stuff is harder than i thought!

im getting it though. and what you said about the"Zero ATK"

that makes sense. i didnt think of that.

anyway, i messed around with the game some more and this is what happened.

when i changed the "Zero ATK" code, it messed up the game. like the first cave to the first palace didnt have that crawley monster. it has a worm thing from the deserts. and in the first castle, it loaded a boss fight that i couldnt fight so i was stuck.

all i did was change the offset E66D from 02 to 01.

anyways, here is my main question.

seeing that Zelda 2 has been hacked before, is there a list of some kind that someone made giving RAM/ROM addresses for stuff in the game? if so, can i have the link? im not good at google.......ing...
Ryusui
Posts: 16/58
Sounds like you didn't find an "Infinite Health" code for monsters as much as a "Zero ATK" code.

If a higher number means a weaker monster, then the obvious conclusion is that it's not how much HP the monster has, but how much damage is being done to it. If a monster has 3 HP, then 2 ATK will kill it in two hits. 8 ATK is enough to kill it nearly three times over, and 1 ATK makes it take three hits. And 0 ATK means your attacks do nothing and never will.

Check the value again after a level-up (make sure you increase Attack power!) and see if it increases.

Anyways, about your first question. Once the value's been written to, backtrack in the code as directed until you come upon the LDA instruction that loads the value from the ROM. I know little about the details of NES ASM, though I've worked with SNES and GBA and much of the concepts are similar. The offset that's being loaded from might be given as part of the instruction; if not, set a code breakpoint there and when it breaks, note the values of the registers. Check them for a ROM address; if there's one in there, that's what you're looking for.
the_icepenguin
Posts: 31/257
is there a way of knowing which one it loads from?

i mean when i back track in the debugger. or do i just guess. or something.

...
...
...

i did do something, when i just tried. i made every monster in the game have infinite health.

i dont know exactly how i got there, but i can remember.(Zelda 2 by the way)

the RAM offset is: E66D

basically i figured out how to make every monster stronger. the offset was originally
at 02. i changed it to 08 to see if it would take 8 hits to kill the bot instaed of 2.

it actually made it weaker. so i changed it to 01 and it took 3 hits to kill, making it stronger.

i then changed it to 00 and every monster had infinite health.

...
never-obsolete
Posts: 48/79
the debugger will snap where an instruction writes to the ram address. you will need to back track from there a line (or possibly more) to see where the value written is read from in rom.
the_icepenguin
Posts: 30/257
Alright. Im gonna go try to figure this out.

Since i dont know what the outcome will be, ill ask my question now.

when i put the write break point (?)on the enemy HP in the RAM, will i be able to see(somehow) where it is in the ROM? so i can change it.

like will it give me an offset of some kind?
HyperHacker
Posts: 2279/5072
Yes, you would use a breakpoint on writes to whatever RAM address the health is stored at.
the_icepenguin
Posts: 29/257
That actually kind of made sense.(I think)

Now i have more questions, but i dont know which ones to ask or how to ask them.

When trying to locate where the enemy HP (or anything) is coming from in the ROM, i use breakpoints in the RAM, correct? or almost correct?

I noticed that there were a few different kinds of breakpoints.

writeable

executable

....and one more, i forgot.

arg! so much info! ....................

never-obsolete
Posts: 46/79

nes prg-rom space is:

bank0 - $8000 to $BFFF
bank1 - $C000 to $FFFF

smaller switchable banks are possible, just depends on the mapper. ram is
located at $0000 to $07FF and is thus mirrored after that up to $2000. all
code/data is loaded into those 2 banks of prg-rom, though thats not there actual
offset in the rom. the value will be stored in ram when needed but will first need
to be loaded from rom. you need to find where in rom it is loaded from by using a
breakpoint set to when that location in ram is written to. and ram will be written to
like so:

lda #n
sta $g

where n = the value of health and g = offset in ram. though it might be tricky
because indirect or indexed addressing might be used or they will use the X or Y
register instead of the accumulator (A register). so you might get something like:

lda ($nn), Y
or
lda ($nn, X)

which are the two forms of indirect addressing (X and Y are 6502 registers, nn =
zero page address). or you might also get one of these:

lda $nn, X
lda $nnnn, X
lda $nnnn, Y

which are forms of indexed addressing. ($nn = zero page address and $nnnn =
non-zero page address) when the game stores the value into ram it may also use
indirect/indexed addressing rather than absolute.
Ryusui
Posts: 11/58
Think of memory as being one great big collection of address numbers on a particular street. Say we know Rom Street has houses on it numbered from, say, 8000 to 9000 (yes, it's a very long street). If there's a number between 8000 and 9000 in memory, then we know that it has to be an address on this Rom Street. Otherwise, we know it's not on Rom Street and we don't bother looking there.

I know jack about NES programming, so I don't know what values the hardware treats the ROM as, but apply what you know to my example and you'll get it.

In brief: you're not getting the "go to this place in the ROM" menu option because it's not a valid ROM address.
the_icepenguin
Posts: 28/257
So basically, when i changed the enemy HP in Ninja Gaiden, the offset was automatically pointing to the ROM

and

When i tried to change the enemy HP in Zelda 2, it wasnt?

The thing i dont understand is that when i right click the offset, sometimes it will give me the

"go here in ROM file" option, and sometimes it wont.

for the times it doesnt, does that mean i went to the wrong offset?
Ryusui
Posts: 10/58
Because it's not pointing to a place in the ROM.

As far as the hardware is concerned, RAM and ROM are the same thing: a great big sequential collection of numbers. The difference is that the RAM is 1. both readable and writable and 2. the system's internal workspace for all its number-crunching, while the ROM is 1. Read-Only Memory and 2. the numbers that comprise the game itself.

If the offset is pointing to a place in RAM, then find the place in RAM and use breakpoints to figure out when it's written with the proper value and where in the ROM it's coming from. This will require the willingness to understand a bit of how ASM works (although not any actual hacking).
the_icepenguin
Posts: 27/257
I dont get it.

This is what i did.

I learned how to change HP on Ninja Gaiden 1. It worked fine.

I went to go try it on Zelda 2 and it wouldnt give me that "go here in file" option.

here is a picture..

http://www.geocities.com/the_icepenguin/Helppic2.JPG
Ryusui
Posts: 8/58
You've probably got the memory (RAM) offset, not the ROM offset.
the_icepenguin
Posts: 26/257
I did it. I changed the first level boss's HP on Ninja Gaiden 1!!!!!

but there is a problem.

I went to change the first boss's HP in Zelda 2, I did everything the same way, it was working, but then


when i right clicked the offset, it didnt give me the option

"go here in the ROM"

so i couldnt change his HP.

how do i get the option:"go here in the ROM"?
never-obsolete
Posts: 45/79
if you are looking for offset $B547 then go to row 00B540 and count each column over until you get to 7, but start with 0.
the_icepenguin
Posts: 25/257
Alrighty, Im stuck...

I think ive been doing it right so far...(not really sure)



well anyway, here is where im stuck and i dont know what to do....i took a picture of the screen.

http://www.geocities.com/the_icepenguin/HelpImage.JPG


Let me know if Im doing it right so far, if its possible to tell...
Chickenlump
Posts: 134/154
Binaries for now. It is the program, you can use it right away.
You would only download the source code if you wished to add on to, or change the program, since the source code is like the blueprints for the program.
the_icepenguin
Posts: 24/257
Yeah, I am new to hacking. basically, I just need help finding whats what. i would have never guessed FCEUXD was what i was looking for...

Once i have the program, i can pretty much figure it out...

i had to figure out text editing on my own. i dont know if that is a good thing or not....i dont know.

I have a question by the way...

Here are the files:
Download the FCEUXD SP 1.06 binaries
Download the FCEUXD SP 1.06 source code

which one do i download?
This is a long thread. Click here to view it.
Acmlm's Board - I3 Archive - ROM Hacking - What do I need?


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.005 seconds; used 373.57 kB (max 438.44 kB)