I hear How do you change ET HF 77 EF UK J9<----  Im sure this doesen't make sense it was just a example...
to do such and such.....

Is it like a secret code??

Does each letter or number represent another letter or number??

Whats the big secret?

Edit: Next gen Cowboy - This is not a double post, I merged the threads.

*sigh* Hexadecimal is just a different way of counting.

You know decimal, or base 10, right? It's the ordinary numbers you use every day, written with the numbers 0-9. Hexadecimal is hexadecimal, or base 16: it uses the numbers 0-9, but it also uses the letters A-F, effectively giving it 16 "numbers".

So here's how it works. We count 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, and then we're out of digits and we go 10, 11, 12, 13, 14, 15, 16. See? But in hex, it goes 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 and then A, B, C, D, E, F, and then we're out of digits and hit 10 (16 in decimal).

By this point, you're probably wondering what the point of all this rigamarole is. We've been using base 10 for centuries; why stop now? Ah, but computers aren't humans: they don't look at the number of fingers they have and arbitrarily decide to count based on groups of that number. Computers operate in terms of on and off states, or as you might hear it said, ones and zeroes...in other words, base 2, or binary. And binary is really a pain in the ass to work with if you happen to be a human. Fortunately, some clever soul figured out a compromise. Base 2 and base 10 aren't close friends because the powers of 2 and 10 are mutually exclusive; however, if you extend the decimal system to a power of two, i.e. 16, then you have a powerful shorthand for expressing numbers that convert easily back and forth from binary (and a two-digit hex number can express precisely the same range of values as an eight-digit binary one).

In short: 0 is 0. 16 is 10. 255 is FF. For your next trick, you can work out the rest.

Correct me if im wrong..

This:

A Table File:

00=A
01=B
02=C
03=D
04=E
05=F
06=G
07=H
08=I
09=J
0A=K
0B=L
0C=M
0D=N
0E=O
0F=P
10=Q
11=R
12=S
13=T
14=U
15=V
16=W
17=X
18=Y
19=Z
30=a
31=b
32=c
33=d
34=e
35=f
36=g
37=h
38=i
39=j
3A=k
3B=l
3C=m
3D=n
3E=o
3F=p
40=q
41=r
42=s
43=t
44=u
45=v
46=w
47=x
48=y
49=z
60=0
61=1
62=2
63=3
64=4
65=5
66=6
67=7
68=8
69=9

Would be used to Decipher or write if you know how,
A hex table..

Am I right or wrong...

A table file is simply a conversion table from the letters/characters used to their equivalent hex codes in the game. It's used to hack the text in the game. The word 'at' in the game based on your table would be stored as 0x30 0x43 in the ROM.

You can't create an editor for a game without:

1)  knowing how to program in whatever language (VB, C++, C#, Java, etc).  I don't know what "devkitpp" is, it might be a lib or something to make editor creation easier -- but it will still require programming knowledge of some kind regardless.

2)  knowing how the data in the game is arranged.  IE:  you have to know how to hack the game first, before you can make an editor that does it.


If you want to edit the levels in Castlevania... then the way to go is definately to use an editor (such as Stake).

It starts with a hex editor.


Usually.


Learning how things work is the most important thing.


It means nothing if you don't understand. Telling you stuff doesn't magically make you understand how a level is built or how the game interprets the data. If you don't understand the basics, it's irrelevant how and where you learn.


Unfortunately, a lot of this requires you to learn what romhacking is by yourself... asking others for help is only useful if you have some idea what to do with the information given.

I'm bad at giving advice to romhacking newbies because I never was one.  I know that seems impossible, but it's true:

<irrelevent backstory>

My first introduction to romhacking was playing the "FFEpica" hack, and after searching about it brought me to a series of documents called "FFBytes" which outlined which bytes of which file I represented which stats (basically a hex editing guide for Final Fantasy).  Since I already had previous programming experience, I had no trouble understanding hex editing and the concepts that go with it, and soon (almost immediately) after finding FFBytes I made a quick editor to automate the process so that I didn't have to go in and out of a hex editor to change stats.

After using FFBytes to see how data in the game was arranged (and also due to my previous programming experience), I got enough of the general idea behind rom hacking to find some of my own information that FFBytes lacked and add that to the editor, along with contributions from various other people.

Since I had this understanding from the get-go, most of the knowledge I'd gained since then came from reading technical docs, writing emulators, and disassembling games.  None of which I'd recommend to someone just starting out.

So really, I was never in the position where I had to ask how to do something, because I sort of already knew how as soon as I was introduced to it.  This is why I suck at recommending a starting point for noobs, I just can't relate with them at all... I simply don't know what would help.

</irrelevent backstory>


I'd say -- start with editors until you get a feel for what you generally can and can't do with them.  Then (if this is NES) maybe just start looking at the game in the PPU viewer of a debugger to get a general idea of how things work.

Maybe use an editor to do a very small change in a game (like change a single palette color), then compare that changed ROM to the original ROM in a hex editor to see what change the editor made, and then try to figure out why it works that way.

But like I say I don't really know if this is good advice.  Sorry.