PHO - Pokémon Hackers Online

PHO - Pokémon Hackers Online (http://pokemonhackersonline.com/index.php)
-   Archive (http://pokemonhackersonline.com/forumdisplay.php?f=180)
-   -   Simple Hex <--> Binary conversions (http://pokemonhackersonline.com/showthread.php?t=14312)

Miksy91 30th August 2013 06:36 AM

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

Gal 31st August 2013 01:33 PM

Or just use the windows caculator :P

karatekid552 31st August 2013 03:48 PM

@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!

Miksy91 31st August 2013 04:15 PM

Quote:

Originally Posted by Gal (Post 125112)
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 (Post 125113)
@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.

karatekid552 31st August 2013 04:46 PM

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

Miksy91 31st August 2013 05:27 PM

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

karatekid552 31st August 2013 08:47 PM

Quote:

Originally Posted by Miksy91 (Post 125118)
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:p.

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!

Jisuke 31st August 2013 11:19 PM

I feel so stupid right now T-T

droomph 31st August 2013 11:37 PM

Quote:

Originally Posted by Reb0rn (Post 125122)
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

Miksy91 1st September 2013 06:43 AM

Quote:

Originally Posted by karatekid552 (Post 125121)
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:p.

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.


All times are GMT. The time now is 11:18 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
User Alert System provided by Advanced User Tagging (Lite) - vBulletin Mods & Addons Copyright © 2018 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