PHO - Pokémon Hackers Online
Go Back   PHO - Pokémon Hackers Online > Other Generations Hacking > Guides & Documentation

Guides & Documentation Learn how to make your own Pokémon game through the process of ROM Hacking, or help out the community by sharing your information.

Reply
 
Thread Tools Display Modes
Old 30th August 2013, 06:36 AM   #1
Miksy91
Gotta fill something here.
 
Miksy91's Avatar
 
Join Date: Jul 2013
Location: Northern Europe
Age: 26
Posts: 127
Miksy91
Default Simple Hex <--> Binary conversions

I happened to reply to a certain person in PC how conversions between hexadecimal and binary number systems work, so I thought I might as well copy the information here. It's pretty simple really.


Every hexadecimal digit (0, 1, 2, ..., D, E, F) is described in binary with 4 bits.

Code:
binary = hex (dec)
---------------------
0000 = 0
0001 = 1
0010 = 2
0011 = 3
0100 = 4
0101 = 5
0110 = 6
0111 = 7
1000 = 8
1001 = 9
1010 = A (10)
1011 = B (11)
1100 = C (12)
1101 = D (13)
1110 = E (14)
1111 = F (15)
Now if we for example wanted to describe the hexadecimal number 6B in binary, that would be:

Code:
binary = hex (dec)
---------------------
0000 = 0
0001 = 1
0010 = 2
0011 = 3
0100 = 4
0101 = 5
0110 = 6
0111 = 7
1000 = 8
1001 = 9
1010 = A (10)
1011 = B (11)
1100 = C (12)
1101 = D (13)
1110 = E (14)
1111 = F (15)
0110 1011
__________________
Miksy91 is offline   Reply With Quote
Likes mewthree9000, Elsa, karatekid552 liked this post
Sponsored Links
Old 31st August 2013, 01:33 PM   #2
Gal
Getting there...
 
Join Date: Jul 2013
Location: Israel
Posts: 41
Gal
Default

Or just use the windows caculator :P
__________________
Odd Jokes:

Spoiler:
#1 - I saw Saw
#2 - Mateo's name is NOT Matt!
#3 - Karatekid is a n00b ROM hacker (;
#4 - LaZ doesn't like deadly metal music (;
#5 - Mateo doesn't like Flannery
#6 - Mateo is a bad guy ;(
#7 - Enough jokes about Mateo (;
#8 - I EM 7 YIRZ OLD
#9 - Ann Oldman
#10 - Stunfisk
#11 - Smexy Lotads
Gal is offline   Reply With Quote
Likes Mateo liked this post
Old 31st August 2013, 03:48 PM   #3
karatekid552
What does this button do?.....
Ex-Staff
 
karatekid552's Avatar
 
Join Date: Feb 2013
Location: Stalker.......
Posts: 242
karatekid552 karatekid552
Default

@Miksy91: could you explain bits and how they are stored in relation to the reverse hex numbers in the rom/ram? A lot of times, GBATEK explains things in terms of 'bit 15 controls this' and 'bit 7 does this', and I never know which bit I should look at as the first one. Would you mind explaining this? Thanks!
karatekid552 is offline   Reply With Quote
Old 31st August 2013, 04:15 PM   #4
Miksy91
Gotta fill something here.
 
Miksy91's Avatar
 
Join Date: Jul 2013
Location: Northern Europe
Age: 26
Posts: 127
Miksy91
Default

Quote:
Originally Posted by Gal View Post
Or just use the windows caculator :P
Yeah... but it does make a difference in knowing how to convert between hex and binary in your head. At least I have made lots of use of that knowledge when working with bittables that are stored in ram (and beside that, in general university CPU programming courses as well!).

Quote:
Originally Posted by karatekid552 View Post
@Miksy91: could you explain bits and how they are stored in relation to the reverse hex numbers in the rom/ram? A lot of times, GBATEK explains things in terms of 'bit 15 controls this' and 'bit 7 does this', and I never know which bit I should look at as the first one. Would you mind explaining this? Thanks!
Well let's take a look at big endian 16-bit data value - for example D9E2
That translates into:
1101|1001 1110|0010

Here, the first bit from the left (that has the value of 1) is the sixteenth bit, and has the biggest magnitude in 16-bit value D9E2. (Because if it was 0, instead of D9E2, we would have D9E2 - 8000 = 59E2).

That 8000 there comes from 1000|0000 0000|0000 (in other words, a 16-bit value of which sixteenth bit is 1 and remaining fifteen bits are 0).

Though D9E2 would be E2D9 in little-endian presentation instead. That would mean that the last eight bits in 1101|1001 1110|0010 go first, and are followed by 1101|1001.

So in this case, if GBATEK tells you that bit 15 (in case the bit numbers go from 1 to 16, instead of 0 to 15) controls a specific thing in a big endian presentation, and E2 D9 would be the little-endian presentation of a value, bit 15 would be the following bit (in bold);

1110|0010 1101|1001

It's kinda confusing - even for me trying to explain this right now, but I think I did it right (and understood your question correctly as well). But if that example (with bolded bit) indeed was what you were looking for, you can find the location of that bit easily by subtracting 8 from the bit number if bit > 8, and adding 8 to it if bit number <= 8.
And that of course applies to the situation if bits are indeed numbered between 1 and 16 instead of 0 - 15.
__________________
Miksy91 is offline   Reply With Quote
Likes mewthree9000 liked this post
Old 31st August 2013, 04:46 PM   #5
karatekid552
What does this button do?.....
Ex-Staff
 
karatekid552's Avatar
 
Join Date: Feb 2013
Location: Stalker.......
Posts: 242
karatekid552 karatekid552
Default

Most things on GBATEK start at 0, so 0 - 15 is good.:P

Now, let's make sure that I get this:

Little-endian presentation is what I get before I copy it into the rom/ram and after it is loaded. So an offset would be 08 XA YB ZC.

Big-endian presentation is what is in the rom and is often called "reversed". So, that same offset is ZC YB XA 08.

Good so far?


Now, to find the correct bits, I would take the number in big-endian presentation and split it into bits. So, let's go big and use an I/O register:

Quote:
Originally Posted by GBATEK
4000004h - DISPSTAT - General LCD Status (Read/Write)
Display status and Interrupt control. The H-Blank conditions are generated once per scanline, including for the 'hidden' scanlines during V-Blank.
Bit Expl.
0 V-Blank flag (Read only) (1=VBlank) (set in line 160..226; not 227)
1 H-Blank flag (Read only) (1=HBlank) (toggled in all lines, 0..227)
2 V-Counter flag (Read only) (1=Match) (set in selected line)
3 V-Blank IRQ Enable (1=Enable)
4 H-Blank IRQ Enable (1=Enable)
5 V-Counter IRQ Enable (1=Enable)
6-7 Not used
8-15 V-Count Setting (LYC) (0..227)
The V-Count-Setting value is much the same as LYC of older gameboys, when its value is identical to the content of the VCOUNT register then the V-Counter flag is set (Bit 2), and (if enabled in Bit 5) an interrupt is requested.
Although the drawing time is only 960 cycles (240*4), the H-Blank flag is "0" for a total of 1006 cycles.
I have pulled this random number from my hack at that register:

29 96 (Exactly how it was presented in the RAM, so big-endian?)

Now, I split this into bits:

0010|1001 1001|0110

0 0 1 0 | 1 0 0 1 1 0 0 1 | 0 1 1 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
/-V-count setting--/ /nop//-- flags --/


Cool? I hope?:P

Last edited by karatekid552; 31st August 2013 at 04:49 PM.
karatekid552 is offline   Reply With Quote
Old 31st August 2013, 05:27 PM   #6
Miksy91
Gotta fill something here.
 
Miksy91's Avatar
 
Join Date: Jul 2013
Location: Northern Europe
Age: 26
Posts: 127
Miksy91
Default

Big endian number format is the way you would like to read the bytes as. The GBA pointer to rom address $72A569 is 08 72 A5 69 in big endian data format. In little-endian, the bytes are in reversed order.

I can't say about ARM/Thumb assembly, but in GB/C assembly, most data inside rom is presented in little-endian data format (a.k.a reversed order) because coding the routines that use little-endian data tables is "easier" than coding routines that use big endian data tables.
However, nothing prevents you from coding tables that are stored inside ROM/RAM so that the data is presented in big endian format instead of little-endian. In fact, I have coded some new routines in my own hack so that they actually use big endian data tables instead!

So let's say that even though in pokemon FireRed, GBA pointers tend to be in little-endian format, that doesn't mean you couldn't find some of the routines using straight big endian addresses used as pointers as well.

Anyway, what comes to your question;

Data tends to be stored in ram in little-endian format, but it's not always there that way. For example in this case with the general 16-bit LCD Status "register", I'd assume it to work so that the value (according to that documentation) is in big endian format and the first 8 bits of it work as the V-Count Setting.

Quote:
Originally Posted by karatekid552
0010|1001 1001|0110

0 0 1 0 | 1 0 0 1 1 0 0 1 | 0 1 1 0
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
/-V-count setting--/ /nop//-- flags --/
Yeah, that's how I would assume it to be (though I don't have much knowledge about GBA hardware, or playing with 16-bit data for that matter either).

Endianness in Wikipedia

Edit:
The solution I made with LCD Status register being in big endian format instead comes from the fact that it would be stupid to give documentation about something that wouldn't be "accurate" just yet. In this case, it's easy to perceive V-Blank flag (bit 0) being the rightmost bit since that way, you don't have to "look for it".
If that data was in little-endian format instead, V-Blank flag would be in the middle of the 16-bit value, as the eight bit from the left.

The location of V-Blank flag (Bit 0)

Possibility #1 (Big Endian):
0010|1001 1001|0110

Possibility #2 (Little-endian):
1001|0110 0010|1001
__________________

Last edited by Miksy91; 31st August 2013 at 05:39 PM.
Miksy91 is offline   Reply With Quote
Old 31st August 2013, 08:47 PM   #7
karatekid552
What does this button do?.....
Ex-Staff
 
karatekid552's Avatar
 
Join Date: Feb 2013
Location: Stalker.......
Posts: 242
karatekid552 karatekid552
Default

Quote:
Originally Posted by Miksy91 View Post
Big endian number format is the way you would like to read the bytes as. The GBA pointer to rom address $72A569 is 08 72 A5 69 in big endian data format. In little-endian, the bytes are in reversed order.

I can't say about ARM/Thumb assembly, but in GB/C assembly, most data inside rom is presented in little-endian data format (a.k.a reversed order) because coding the routines that use little-endian data tables is "easier" than coding routines that use big endian data tables.
However, nothing prevents you from coding tables that are stored inside ROM/RAM so that the data is presented in big endian format instead of little-endian. In fact, I have coded some new routines in my own hack so that they actually use big endian data tables instead!

So let's say that even though in pokemon FireRed, GBA pointers tend to be in little-endian format, that doesn't mean you couldn't find some of the routines using straight big endian addresses used as pointers as well.

Anyway, what comes to your question;

Data tends to be stored in ram in little-endian format, but it's not always there that way. For example in this case with the general 16-bit LCD Status "register", I'd assume it to work so that the value (according to that documentation) is in big endian format and the first 8 bits of it work as the V-Count Setting.


Yeah, that's how I would assume it to be (though I don't have much knowledge about GBA hardware, or playing with 16-bit data for that matter either).

Endianness in Wikipedia

Edit:
The solution I made with LCD Status register being in big endian format instead comes from the fact that it would be stupid to give documentation about something that wouldn't be "accurate" just yet. In this case, it's easy to perceive V-Blank flag (bit 0) being the rightmost bit since that way, you don't have to "look for it".
If that data was in little-endian format instead, V-Blank flag would be in the middle of the 16-bit value, as the eight bit from the left.

The location of V-Blank flag (Bit 0)

Possibility #1 (Big Endian):
0010|1001 1001|0110

Possibility #2 (Little-endian):
1001|0110 0010|1001
Hmmm, it seems I had it backwards. So big endian is normal, and little endian is reversed. Either way, in the reversed format, the bits go from 15 to 0. That should make things easier.

In ARM, as far as I have seen, everything is stored in little endian. I haven't seen any numbers stored in big endian.

Thanks for you help!
karatekid552 is offline   Reply With Quote
Old 31st August 2013, 11:19 PM   #8
Jisuke
私の陰茎は非常に大きい
Ex-StaffPHO VIP
 
Jisuke's Avatar
 
Join Date: Mar 2013
Location: Brooooo...
Age: 21
Posts: 200
Jisuke Jisuke
Default

I feel so stupid right now T-T
Jisuke is offline   Reply With Quote
Old 31st August 2013, 11:37 PM   #9
droomph
握りモンスター
Ex-StaffPHO VIP
 
droomph's Avatar
 
Join Date: Apr 2012
Location: maybe.
Age: 20
Posts: 439
droomph
Default

Quote:
Originally Posted by Reb0rn View Post
I feel so stupid right now T-T
summary:
  • each hex digit is four of binary
  • some computers store their numbers forwards
  • some reverse the digits
  • numbers suck
__________________
droomph is offline   Reply With Quote
Likes Miksy91 liked this post
Old 1st September 2013, 06:43 AM   #10
Miksy91
Gotta fill something here.
 
Miksy91's Avatar
 
Join Date: Jul 2013
Location: Northern Europe
Age: 26
Posts: 127
Miksy91
Default

Quote:
Originally Posted by karatekid552 View Post
Hmmm, it seems I had it backwards. So big endian is normal, and little endian is reversed. Either way, in the reversed format, the bits go from 15 to 0. That should make things easier.

In ARM, as far as I have seen, everything is stored in little endian. I haven't seen any numbers stored in big endian.

Thanks for you help!
You're welcome!
Though I won't let you go so easily with it just yet :P (since according to this comment, you possibly haven't caught the little-endian format just yet).

In big endian, bytes are in normal order. In little-endian bytes are in reversed order.
Bytes consists of 8 bits. In other words, bytes are 8-bit queues/sequences (don't know the right word in english so I picked up two that an internet wordbook gave me).

Now if we again think about a hexadecimal value xA7DF.

In big endian, it is represented as A7 DF.
A7|DF
-----
1010 0111|1101 1111

In little-endian, it is represented as DF A7.
DF|A7
------
1101 1111|1010 0111

As you can see, bit 0 won't go to the place of bit 15 - it goes to the place of bit 8. That's because the order of the bytes (or 8-bit queues!) change - not the order of bits.
__________________
Miksy91 is offline   Reply With Quote
Reply

Tags
<>, binary, conversions, hex, simple, [Guide]

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 08:57 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2017, vBulletin Solutions, Inc. User Alert System provided by Advanced User Tagging (Lite) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.
Feedback Buttons provided by Advanced Post Thanks / Like (Lite) - vBulletin Mods & Addons Copyright © 2017 DragonByte Technologies Ltd.
Pokémon characters and images belong to Pokémon USA, Inc. and Nintendo.
Pokémon Hackers Online (PHO) is in no way affiliated with or endorsed by Nintendo LLC, Creatures, GAMEFREAK inc,
The Pokémon Company, Pokémon USA, Inc., The Pokémon Company International, or Wizards of the Coast.
All forum/site content (unless noted otherwise) and site designs are © 2006-2013 Pokémon Hackers Online (PHO).
Green Charizard Christos TreeckoLv100

"Black 2" by ARTPOP. Kyurem artwork by XOUS.

no new posts