Pointer Tables

[Blade556]

Can anyone tell me what they are and how they work in respect with modifying a game's gameplay, in laymans terms (Or at least, terms a basic computer wizard such as myself can understand)?

This is for the Emulation FAQ on my site, so be as thorough as you want...<img src=smilies/magbiggrin.gif>

[JadussD]

> Can anyone tell me what they are and how they work in
> respect with modifying a game's gameplay, in laymans terms
> (Or at least, terms a basic computer wizard such as myself
> can understand)?

A pointer is data that tells where other data is. The program reads the pointer data, and loads from the address that the pointer "points" to. This means you can put data where you want it in the ROM, as long as you change it's pointer to point to the new location.. Pointers can be either hardcoded (part of the actual game code), or a table (a big section where all the data is pointers).

[Blade556]

How do I implement such a table? Does it matter where it goes? How can I use a hex editor to do so?

I would look on a tutorial, but none of them seem to explain this...They assume you know already....

[Ugly Joe]

From "The Madhacker's Guide to NES Pointers"
<blockquote><font class="small">In reply to:</font><hr>

What are pointers?
Pointers actually have nothing to do with text. A pointer is, quite simply, a reference to
somewhere else. Anyone who's ever used any kind of basic programming has used a simple
pointer. Consider:
10 Print "Pointers are our friends."
20 Goto 10
Line 20 is a pointer. It POINTS to line 10 and says "GO THERE."
Choose-Your-Own-Adventure books (anybody remember these). Go to page XX. That's a
pointer.
Now, these are admittedly very simple pointers, but the fundamental principal behind them are
the same. And the beautiful thing is, NES pointers aren't THAT much more complicated than
these themselves, only finding them.

Uh-huh. So how do I find them?
Whoa, slow down. First you need to understand what they are, or else knowing where they are
won't do you any good. Go ahead and read further down if you want to, but I take no
responsibility for the confusion you WILL cause yourself.

Will pointers let me change how the text appears on the screen?
No. Pointers have nothing to do with how text is DISPLAYED. That's somewhere and
something else completely.

I can see the blank space on the screen where I need to write just 1 or 2 more characters, why
can't I just use that?
Just because you can SEE blank space on the screen doesn't mean that you can USE that blank
space. On a Nintendo, what we see as a blank space at the end of a line the NES sees as just
somewhere that nothing has been written. Consider: (NOTE: This exercise only works on some
programs- like Notepad or Netscape)

A sentence.

Select the sentence. Go ahead, highlight the entire line with your mouse. Notice how even
though you can see blank space all the way to the edge of your screen, when it's highlighted,
there's nothing there? That's how it is on the NES. Once it hits what it knows to be the end of
the line, that's it. Fortunately, with pointers, we can change where the end of the text is, so we
can overcome this barrier.

<hr></blockquote>

I've attached the whole document for further reference.

C:Serverxampphtdocszopharoldwwwthreadsattachmentsp oint11.txt

[JadussD]

> How do I implement such a table? Does it matter where it
> goes? How can I use a hex editor to do so?
>
> I would look on a tutorial, but none of them seem to explain
> this...They assume you know already....
>

Okay, on SNES, let's assume there's a textblock at F6C6 in one of the banks. on a headerless rom. Like let's say at 01F6C6, there's a textblock. You could put that textblock in a blank area of the bank, at 01FE00, let's say, by finding the pointer. Get rid of the first byte of the address (sometimes pointeres are more than 16-bit and inclue the bank though, but a lot don't.) The byte order is stored so that you'd have to switch the two bytes to find the pointer value, so you'd take F6C6 and turn it into C6F6...search for this. Now turn it into the new address...FE00 would turn into 00FE.

[Blade556]

> F6C6

You lost me at approximately this point, the first time you said it...

[UnwrittenEnd]

> > F6C6
>
> You lost me at approximately this point, the first time you
> said it...
>

Maybe it would be a good thing to ask you if you're familiar with hexadecimal numbers? F6C6 refers to a hexadecimal number and it refers to an address in the program code. All a pointer is, is a reference or jump to another address in program code. So if I have:

0000 pointer to 0003
0001
0002
0003 print happy words to screen

All that would occur here, is if the program executed code at 0000, it would jump to 0003 and run my little text message. Do you understand now? A pointer table is simply a series of references to a series of text/etc/whatever have you. The series of pointers "point" to a series of addresses. You can't really make use of this I guess, but you could obviously find a pointer table and alter the addresses. I would guess that would be the most popular use of them in romhacking. Sorry if this is confusing, it can be.

[Blade556]

I know what Hexadecimal is. Allow me to bold what I didn't understand from your post:

> F6C6 refers to a hexadecimal number and it
> refers to an address in the program code.

What program? What code? Are we still talking about Hex here?

> All a pointer is, is a reference or jump to another address in
> program code.

Probably one of the few statements about Pointers I ever understood off hand.

> So if I have:
>
> 0000 pointer to 0003
> 0001
> 0002
> 0003 print happy words to screen

Where the hell are we seeing this? I don't think this is Hex...We've switched away somewhere, a land of magic.

> All that would occur here, is if the program executed code
> at 0000, it would jump to 0003 and run my little text
> message.

This reminds me of Qbasic too much...

> Do you understand now?

Getting there...

> A pointer table is simply a series of references
> to a series of text/etc/whatever have you.

So basically, when we get to a certain point in the code, where we have cleverly placed a pointer, we automatically jump down to the pointer table to find out where we should go from here?

> The series of pointers "point" to a series of addresses.

Got that...

> You can't really make use of this I guess, but
> you could obviously find a pointer table and alter the
> addresses.

Nope. Where do I find it?

Anyways, I have a kind of offtopic question: When I use a hex editor, can I add code/text into a ROM without it being corrupted and unplayable?

[Ugly Joe]

Here's an example. The numbers are hexidecimal. The numbers before the colons are memory addresses. (Every byte of data in memory has an address associated with it. When you want to access that byte, you do so by accessing its address in memory.) The numbers after the colons represent the data (also in hex) at the given address. The text after the colons are the text equivilants of the hex values (such as what you would see in Windhex or Thingy with a table loaded).

<pre>0500:0600 0610 0620 ...
...
0600:different text#
0610:i am some text#
0620:point to me#
...
0700:Oi, 81, please 82.</pre>

At 0500, we have a pointer table. This table consists of a series of entries that point to a memory location containing the text we want to display. At 0600, we have the segments of text that we are going to use pointers to access. In a more relevant example, these segments would be phrases that would be used over and over again ("level up", or "the chest is empty", etc). At 0700, we have some text that the game is going to display.

For this particular fake game, the text routine uses hex values 80-FE to access the pointers. When the game reads the "81", it subtracts 80 from it (since that is the value we're starting from) to get 01. Since we're counting starting from 00, we see that 01 is referencing the second value in the pointer table, 0610. The game would then look up memory address 0610, see "i am some text" (knowing to stop reading when it hits the end-of-segment byte, in this example represented by "#"), and output that to the screen. It would do the same thing when it encounters the "82" (82 - 80 = 02 -> third table entry = 0620 -> 0620 = "point to me").

So, the text at 0700 will be displayed as "Oi, i am some text, plese point to me."

Making sense?

[Isildur]

> I know what Hexadecimal is.


> > So if I have:
> >
> > 0000 pointer to 0003
> > 0001
> > 0002
> > 0003 print happy words to screen
>
> Where the hell are we seeing this? I don't think this is
> Hex...We've switched away somewhere, a land of magic.
>

You clearly don't understand what hexadecimal is. Hexadecimal digits are written as 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, or F. The numbers 0000, 0001, 0002, and 0003 make perfect sense as hexadecimal representations of numerical values. A hexadecimal number doesn't have to have letters in it. That only happens when one or more of the digits has to represent 10 to 15 in that column. (Each digit X in a hexadecimal number written as XXXX represents the portion of the number that is described by X&bull;16ⁿ, where n is the column number, with the rightmost column being the zeroth one.)

eg.:
hexadecimal 0001 = decimal 1
hexadecimal 0003 = decimal 3
hexadecimal 0010 = decimal 16
hexadecimal 0013 = decimal 19

<p id="signature">

<center><img src=http://pages.nyu.edu/~jc73/misc/FieryAshNazg.gif></center></p>

[Blade556]

> You clearly don't understand what hexadecimal is.
> Hexadecimal digits are written as 0, 1, 2, 3, 4, 5, 6, 7, 8,
> 9, A, B, C, D, E, or F. The numbers 0000, 0001, 0002, and
> 0003 make perfect sense as hexadecimal representations of
> numerical values.

I know that part

> A hexadecimal number doesn't have to have
> letters in it. That only happens when one or more of the
> digits has to represent 10 to 15 in that column.

Again, basic Hexadecimal

> (Each digit X in a hexadecimal number written as XXXX
> represents the portion of the number that is described by
> X•16n, where n is the column number, with the rightmost
> column being the zeroth one.)

Arr...Math...

> eg.:
> hexadecimal 0001 = decimal 1
> hexadecimal 0003 = decimal 3
> hexadecimal 0010 = decimal 16
> hexadecimal 0013 = decimal 19

This is about as simple as it gets. Like I said, I know hex, but you're gonna have to show me that equation...It's easier for me to convert using logic, like so:

<ul>
Anything with a zero I automatically know is under 15.
If it starts with a 1 and doesn't go higher than 3 for the second digit, I know it's anywhere from 16-20
[/list]

The rest is pretty self explanatory...

[shawn]

If your feeling daunted by the math don't. The windows calculator has a hexidecimal funtions so you can do your hex math with it. I believe the calculator even has a section on how to use it with the hex. <img src=smilies/cwm11.gif>

[Blade556]

I learned Hex arithmetically, like I explained. There was something on Partial Translations on it, so I learned it from there, but the math was retarded so I just stuck with my system.

[UnwrittenEnd]

Here are examples of valid hex:
00. 01. 0A. A0. A2. B4. CD. CF. 15. etc.
Let's begin.

Ok open your hex editor up, open a rom.
On the left are hex values which represent the very first address to the very first byte of data on that line. Like I have below:
$0000 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
$0010 10 11 12 13 14 15 <u>EE EE DD AF 7A 8A 9A AA</u> etc
$0020 etc....
$0030 etc....
That is exactly what you should see, with obviously differing values than my examples. Now I will explain what a pointer table IS.

Here is what a pointer table will look like (every 2 bytes are a pointer, bold on and bold off to stress that every group of two values are actually just one pointer):
$0040 10 00 11 00 12 00 13 00 14 00 15 00 16 00 etc...
$0050 16 00 18 00 AA 00 FF 00 DD 00 etc...
$0060 etc....
$0070 etc....

Let's take these values. The first one at 0040, is 10 00. This (10 00) is a pointer. Where does it point to? To address 0010. Ok? I just flipped the values, but it depends on the game system as to whether or not they are flipped usually. Moving on. Let's say this pointer jumps to that address and reads the first 6 bytes of data. It would read:
10 11 12 13 14 15 from address 0010 as you see in the first hex table above. I've put it in italiacs to help you see where it is. Make sense?

Let's try one more pointer.
At $0050 you see the value 1600. Flip it, that's 0016. Go to 0016 and grab the first 8 bytes. You'll see EE EA DD AF 7A 8A 9A AA. I've underlined that one. This could be actual text that is printed in a game. For example if:

EE = S
EA = h
DD = a
AF = b
7A = u
8A = t
9A = i
AA = e

Then this text line would print out "Shabutie".

So let's recap. In your hex editor, when you loaded your rom file you saw that at hex address $0050 there was a pointer to data stored at address $0016 which was a text string that printed the word "Shabutie". If you are still confused, let me know.

[Isildur]

Ok, sorry, I guess I misunderstood you when you said "I don't think this is Hex".
So basically, your confusion was not with the numbers themselves, but what UnwrittenEnd wrote after them, and how that related to the numbers. On each line, he was first specifying the address of that line. Then he paraprased in English what the instruction or data actually residing at that address does or contains.

Glancing at it, I see he's now made another post that describes pointers in more detail, so there's no need for me to explain that stuff. (Besides, while I've done assembly programming for PCs, I don't really have any serious ROM hacking experience, so I don't know what different conventions might apply to particular game systems, for example regarding byte order.)

As for that mathematical expression I gave, I just meant that to convert an integer in hexadecimal notation to decimal notation, you take the sum of:
1 times the least significant digit
+ 16 times the next digit
+ 256 times the next digit
+ 4096 times the next digit
etc.

i.e. the significance of digits goes up (reading right-to-left, in the usual notation) by powers of 16.

[Blade556]

Here's the jist of what I understood from you guys. I put it on my website, and gave you guys some credit at the end of it. Thanks a bunch for the help, tell me if there's anything I'm missing. I know I'm missing a bit on what pointers look like and how the game identifies it as a pointer, as well as where to find the pointer tables, but thats about it.

Anyways, enjoy!

-------------------

Pointers and Pointer Tables



Simply put, Pointer Tables are just big blocks of Hex code within a ROM. More specifically, The code represents different addresses all over the ROM that contain valuable information, such as graphics, text, etc.



Pointers are also placed at different parts of the ROM. When you load a ROM, and it reaches a point where it finds a Pointer, the game looks at the pointer table to find out where to go to find the information the pointer requested it to find.



Now, as a rule of thumb, we can't picture Pointer Tables like picturing an HTML table in our heads. Although they are similar, their setup is completely different. For example, lets look at a table in HTML:



<table border=2><tr><td>Item</td><td>Value</td></tr>
<tr><td>New York</td><td>Turn right on I-35 to the Turnpike and you're there</td></tr></table>



And now lets look at a Pointer Table (Yes, I can hear you all saying "Finally!" over here in Barrie):



0023 003F 0024 0040



Yes, as non dramatic as it is, this is indeed a pointer table. Granted, it's not a very BIG pointer table, but thats generally how it looks. Allow me to break it down for you now, since you probably have no idea what it means.



Let's take the first 2 numbers, 0023 and 003F. 0023 is simply an address of this particular Pointer Reference. I'm using the term Pointer Reference like I would use Table Cell to identify a cell in an HTML table. For example, the words "New York" in the above table is in a Table Cell.



Anyways, lets continue. We've identified what 0023 is, now lets figure out what 003F is. Well, it's a Hex Address where the Pointer Reference is telling us to go to find some game data. Then, once the game data is found, it is loaded and the cycle of life goes on. Pretty simple, huh?



So let's recap:

<ul>
The game runs until it sees a pointer in the code.
The game seeks out the Pointer Reference in the Pointer Table
The game goes to the address that the Pointer Reference tells it to go, and loads the game data it finds there
[/list]



Not so scary now, are they? I wanna give a shout out to the boys at ZMD for all their help with this (Especially UnwrittenEnd, you helped out alot), you guys are great.<P ID="edit"><FONT class="small">Edited by Blade556 on 09/29/05 11:38 PM.</FONT></P>

[Ugly Joe]

Not quite right, at least from what I've used. The pointer table isn't a set of index:address pairs. The pointer table is made up of only addresses. The game doesn't say "use pointer #23", it says "use the 23rd pointer". It calculates where this location is in the pointer table by adding the starting address of the table to the number of the pointer they want times the size of the addresses. Something like: $2000 + ( 23 * 2 ). This is assuming the pointer table starts at $2000, you want the 23rd pointer, and that the entries in the pointer table are two bytes each.

[Blade556]

> The game doesn't say "use pointer #23", it says "use the 23rd
> pointer"

...Rhetorical statament?

Anyways, perhaps you could enlighten me further on the subject with some examples, and in language and paragraphing I can understand. <img src=smilies/magbiggrin.gif>

[Ugly Joe]

> > The game doesn't say "use pointer #23", it says "use the
> 23rd
> > pointer"
>
> ...Rhetorical statament?

Not quite. The way your example has it set up is that every entry in the pointer table has an id number. You don't look up the entry by saying, "give me the pointer with the ID #23". This simply isn't the case. The table entries are just in there one after another, and you look it up by saying "I want the 23rd entry". The difference is that there are no id numbers associated with the entries, so you cannot look them up by them.

> Anyways, perhaps you could enlighten me further on the
> subject with some examples, and in language and paragraphing
> I can understand.

I doubt it. I don't think this is the kind of thing that can be put into layman's terms. It's a relatively simple programming idea, but it's still a programming idea.

[UnwrittenEnd]

I think you've almost got it. I'm just not sure about the whole pointer reference / table cell thing, and whether or not your example of 0023 is the address in the rom?

Like:
$FFAE --- 78 FA
Here 78 FA is a pointer. Two bytes of data starting at rom address $FFAE.

Processor flips the data. FA 78. Jumps to address $FA78 in the rom.

$FA78 --- "Hello World" FF (FF marks the end of the string).
$FA90 --- "Hello shabutie" FF

So now that's it. IF you changed the pointer from 78FA to 90FA, you'd make the program print the second message to the screen instead. Sexy.

Anyway, what you NEED to do is get a hex editor, a rom, a tutorial, and hack some good old Final Fantasy NES text or something easy. Learn by doing, I say.

[UnwrittenEnd]

> Not quite right, at least from what I've used. The pointer
> table isn't a set of index:address pairs.

I've never seen a pointer table that was anything more than a bunch of addresses. Though Nigeronpa had some interesting three byte pointers and some other doodads going on, if I remember correctly. Oh, I think it was if you changed a pointer you also changed font colors and things.

[Blade556]

> I don't think this is the kind of thing that
> can be put into layman's terms. It's a relatively
> simple programming idea, but it's still a programming idea.

I basically explained it, of only a small portion of it, in pretty easy to understand terms. Maybe take my example and try?

[Ugly Joe]

> I basically explained it, of only a small portion of it, in
> pretty easy to understand terms. Maybe take my example and
> try?

I think the fact that you are using html tables and table cells as examples only further complicates it. A "table cell" does not make sense to everyone.

[Blade556]

To eliminate further confusion, I used a table there as an example of what NOT to picture when thinking of a Pointer Table. Thats what I wrote, and what people should try not to think about when thinking of a pointer table.

When you think of the words "Pointer Table", the keyword is table, and some people who are familiar with HTML might think "Oh, so it's kinda like an HTML table, right?", which is not the case. I know, because I did too <img src=smilies/magbiggrin.gif>

[Ugly Joe]

A pointer table is still a table. When I said that pointer tables have no index numbers, perhaps I should have said that the index numbers are implied.

Conceptually, a pointer table is a table with two columns and however many rows you want (the more rows, the more pointers). The first column is the index column, and starts from 00 and counts up:

00
01
02

The second column is the list of addresses that point to text.

With this setup, each index points to exactly one address. When the game's text wants to use a pointer, it uses that pointer's index number. (It is, in reality, a bit more complicated than this, but this is conceptually right.)

Because the first column is so simple, and because the adresses of the second column are all of the same length, it is easier to get rid of the first column and just calculate an offset (which is what I was trying to explain in a previous post, but the concept seems to be lost on you). "Pointer index #3" is always the third row and "Pointer index #7" is always the seventh row. Can you see how the index column is used, but doesn't really need to be there in order to be used?

Put simply, if the game needs to look up pointer #3, it is smart enough to figure out which pointer is the third pointer in the table, without the use of the index column (just as a human can see a list of addresses and know what you mean when you ask for "the third address").

This is to say, the game refers to the entries in the pointer table by their index number, but the table itself doesn't have an index column. It is smart enough to figure it out without the column being there.

So, as a recap,
1) a game reads some text and stumbles across a reference to pointer #3
2) the game looks up the third entry in the (single column) pointer table (since "third" and "#3" are the same thing) to get the address
3) the game reads the text from the address<P ID="edit"><FONT class="small">Edited by Ugly Joe on 09/30/05 11:30 AM.</FONT></P>

[Isildur]

Put a little differently, the pointer table isn't really stored in the form

0. Pointer
1. Pointer
2. Pointer
3. Pointer
etc.

It's really stored as
pointerpointerpointerpointerpointer...

By the way, Blade, a consequence of this that may be worth pointing out (no pun intended), is that if you have a pointer table that is a sequence of, say, 32 pointers, and an instruction in the low level code refers to pointer[40], the processor (or emulated processor) will not notice the error. It will obediently go and look at the contents located at "address of the begining of the table + an offset of 40", and it will misinterpret whatever data or instruction is there as a pointer.

When programming in many high level languages (like C++, Pascal, etc.), one can be protected by the fact that many compilers will detect certain array-out-of-bounds errors and warn the programmer with a compile time error. In addition, the compiler may insert bounds-checking code that will throw an understandable error at run time if an invalid index gets used.

When directly tinkering with machine code (like when directly hacking a ROM) however, one can accidentally make a mistake like that and have garbage data returned.

<p id="signature">

<center><img src=http://pages.nyu.edu/~jc73/misc/FieryAshNazg.gif></center></p>

[Gideon Zhi]

No, Joe's got it 100% correct. Pointer tables are lists of addresses, nothing more. Those addresses can be any number of bytes in size, and there can be all sorts of fun miscellaneous data strewn in between the actual pointers, it just means you'll have to have to do slightly more complicated calculations to find the offset of the pointer to a particular string.

Let's say you're dealing with a standard 16-bit pointer table. Any machine. Any funky stuff it has to do to address properly is assumed to happen automatically. Let's also assume we're dealing with an RPG, just to make things a little easier.

You walk up to a townie, and talk to him/her/it. The game loads the particular section of event code that tells it to display text on screen; the psuedocode for this usually looks something like this:

Display String 50

This usually unpacks to something like this:

Relative Pointer Location = String Number * 2 (as we are dealing with 2-byte pointers/16-bit pointers.)

Our text string's location is thus equal to whatever value is in the rom at the address the pointer table starts at plus the previously calculated Relative Pointer Location.

I'd post some 65816 for 24-bit pointer loads if I thought any of you would understand it.

[UnwrittenEnd]

> No, Joe's got it 100% correct.
Yah i was agreeing with Joe more or less, but nigeronpa does have some sexy data between the pointers, or something or other....god I can't remember back to 2000. They are 3byte as well. I didn't know you posted here Zhi, it's Moresco (aka FearGaia etc). Just for the record I despise the name FearGaia. ok carry on.

> I'd post some 65816 for 24-bit pointer loads if I thought
> any of you would understand it.
I just started learning 6502, but I'm pretty sure I would like an explanation of the 24 bit pointer loads ^^

[Gideon Zhi]

> I just started learning 6502, but I'm pretty sure I would
> like an explanation of the 24 bit pointer loads ^^

Your stock 24-bitters behave exactly the same as 16-bitters, except they (usually) have global access to the ROM. In an SNES game at least, a 24-bit pointer is able to access data quite literally anywhere, be it in rom, ram, or sram. I think vram is the only exception. They're also very nearly impossible to do on the NES, due to bankswitch requirements... If you see a 24-bit pointer table on the NES, it usually points to another 16-bit pointer table that operates locally within its bank.

[Blade556]

Here's a revised edition. Hope it seems to be correct...I'm kinda working on this for myself too, so I'm trying to get as much information as I can.

-----------------------------

Pointers and Pointer Tables



Simply put, Pointer Tables are just big blocks of Hex code within a ROM. More specifically, The code represents different addresses all over the ROM that contain valuable information, such as graphics, text, etc.



Pointers are also placed at different parts of the ROM. When you load a ROM, and it reaches a point where it finds a Pointer, the game looks at the pointer table to find out where to go to find the information the pointer requested it to find.



Now, as a rule of thumb, we can't picture Pointer Tables like picturing an HTML table in our heads. Although they are similar, their setup is completely different. For example, lets look at a table in HTML:



<table border=2><tr><td>Item</td><td>Value</td></tr>
<tr><td>New York</td><td>Turn right on I-35 to the Turnpike and you're there</td></tr></table>



And now lets look at a Pointer Table (Yes, I can hear you all saying "Finally!" over here in Barrie):



0023 003F 0024 0040



Yes, as non dramatic as it is, this is indeed a pointer table. Granted, it's not a very BIG pointer table, but thats generally how it looks. Allow me to break it down for you now, since you probably have no idea what it means.



Let's take the first numbers, 0023. 0023 is simply the address where the game has to go to find some game data. But here's where it gets tricky. As we explained above, in a previous section, we can identify 2 bytes in 0023. The first one is 00, and the second is 23. For reasons unknown to me, the game stores this address BACKWARDS. To find out what the new address actually is, we must "Flip" the bytes, or rather, simply re-arrange them to look like so:



0023 <-> 2300



See how we switched them around to find our new Address? This is done with every Address in the Pointer Table, including the other 3 numbers(003F 0024 0040) I used as an example above.



For the record, these Hex Addresses, AKA Memory Addresses, always have a $ sign before them. So, if we were to write down our new Hex Address, it would look like this:



$2300



You won't find the $ symbol in the actual Hex code within a Hex Editor. You will see it whenever you click on any random byte of code.



So let's recap:

<ul>
The game runs until it sees a pointer in the code.
The game seeks out the Pointer Address in the Pointer Table, and switches around the 2 bytes to find the correct Address
The game goes to the address that the Pointer Reference tells it to go, and loads the game data it finds there
Hex/Memory Addresses have a $ before them to identify themselves as addresses (Not shown in the code)
[/list]



Not so scary now, are they? I wanna give a shout out to the boys at ZMD for all their help with this (Especially UnwrittenEnd, you helped out alot), you guys are great.

[UnwrittenEnd]

I only have a couple things to help you with. First off, the $ symbol is used to point out that the number is hexadecimal and not a decimal number. Addresses in hex are hex, so sometimes i write them as $xxxx whatever. In hexworkshop for instance, the addresses in the editor are on the left as a guide to help you find a specific address faster. That's all.

Like (taken from ys3 rom in hexworkshop):
00000000 4E45 531A 1010 4800 0000 0000 0000 0000 2080
00000012 4283 7584 EE87 D28B DB8F EF91 F992 0C95 5E95

The only reason the next line starts at 00000012 is because of how i've widened or shortened my window.

Another way to print the addresses would be:
0x00000034 which indicates a hex address.
If you notice in hexworkshop it says:
offset: 54 0x00000034
offset: 54 is the decimal offset from the first byte in the rom, which is offset: 0. since this is counting from 0, that makes it the 55th byte.

anyway yeah.

let's see, why does it swap bytes? it depends on endian, i believe. maybe progamming as well? i'm not too sure, but i know typically on a nes, which is little endian, the lowest part of the address becomes the first byte stored in memory. it's like this:

say you have EFAA as an address. AA is the least significant byte of this address. so AA becomes the base address, or 0. EF is next, so it is base address + 1. that's how the processor stores the address in memory and it becomes AAEF. so obviously if you thought the pointer went to address AAEF, you'd be wrong. that's why you flip it, because it was flipped to begin with and you're just flippin it back. :)<P ID="edit"><FONT class="small">Edited by UnwrittenEnd on 10/01/05 12:13 AM.</FONT></P>