Jump to content
IGNORED

Hexadecimal, decimal and binary conversion chart.


Recommended Posts

Here is a conversion chart for hexadecimal, decimal, and binary http://www.dewassoc.com/support/msdos/deci...hexadecimal.htm

 

This is a must have if you want to program the Atari in assembly language, expecially on converting character graphics from binary into hexadecimal.

 

 

Example=

Player (space-fighter) graphic:

 

In Binary = hexadecimal (conversion)

 

10000001 = 81

10011001 = 99

10100101 = a5

11111111 = ff

10111101 = bd

00000000 = 0

Link to comment
Share on other sites

It's much simpler to use a Calculator. Under Windows, you can set the Calculator to "Scientific" mode to access Hex and Binary numbering systems. To convert, just enter the number in one system and click the radio button for the other system. The Mac calculator (as of OS X 10.4) works very similar, but is listed under the "Programmer" menu option. As a bonus, you'll be able to do math in the other number bases without fear that you're accidently introducing base-10 errors. (Just the other day I kept trying to figure out why 0x100000 * 32 wasn't equal to 0x32000000. Thank goodness I had a calculator to catch that one.)

 

Under Linux you can use 'dc', but it's not graphical.

 

Generally, you'll want to stick with hex numbering. The one exception is when you're looking to set individual bits rather than obtaining a number. In those cases you can write the binary into the calculator, then convert it to Hex for addition to your files. This should be a lot more concise, and prevent your code from ballooning with useless code. The Mac calculator makes this even easier by allowing you to flip individual bits while you're in Hex mode.

Link to comment
Share on other sites

It's much simpler to use a Calculator.

Why should we use a calculator when the assembler (DASM) already knows how to handle e.g. binary numbers? :?

 

37, $25, %100101... they are all the same, use whichever fits best. E.g. for graphics, you will want to use binary (%), for color values hex ($) and for your scanline count simple decimal numbers.

Link to comment
Share on other sites

It's much simpler to use a Calculator.
Why should we use a calculator when the assembler (DASM) already knows how to handle e.g. binary numbers? :?

 

As I said, it's much simpler to use a calcualtor to do a conversion rather than use a lookup table. The ability to correctly handle Hex math alone is very useful. And for large amounts of ROM data, hex can be a lot more compact than writing out tons of binary.

 

Depending on how you program, though, you probably won't need it as much as you would during C or Java development. (Given that they don't have the ability to use binary directly without a runtime conversion.) :)

Link to comment
Share on other sites

I think you're missing the point

As I said, it's much simpler to use a calcualtor to do a conversion rather than use a lookup table.

 

It's even simplier to not use the calculator, or the lookup table, and let the assembler do the work for you.

 

And for large amounts of ROM data, hex can be a lot more compact than writing out tons of binary.

While it's more compact in the source code, it may not be as useful.

 

What am I drawing here:

.byte $24, $00, $81, $42, $3c

 

versus what am I drawing here:

.byte %00100100

.byte %00000000

.byte %10000001

.byte %01000010

.byte %00111100

 

sure the hex took less space, but it's a lot more useful to the programmer to be able to see the smily face in the binary version. And in the end, they both compile to exactly the same binary.

 

In Medieval Mayhem I actually take it a step further and a file called graphics.h that let's me do the following:

 

.byte zz__X__X__

.byte zz________

.byte zzX______X

.byte zz_X____X_

.byte zz__XXXX__

 

It takes a lot more space than hex, but i tmakes it even more clear what the images are. (I preceeded everything with zz so they wouldn't replace other labels in Stella's debugger.)

Link to comment
Share on other sites

Depending on how you program, though, you probably won't need it as much as you would during C or Java development. (Given that they don't have the ability to use binary directly without a runtime conversion.) :)

It also depends on what you program...

 

Even in C, there's little need for a calculator and basically none for a table. If you are writing a driver (or a compiler :) ), chances are you'll use lots of binary and bitwise operations. C doesn't allow you to specify binary, but you can specify hexadecimal, which can be converted to/from binary in your head without much thought since you only have to look at 4 bits at a time. Or if you can't remember conversions for just 16 binary numbers, you can specify octal in C and you just need to remember 8... Not too many people need to keep a table around for that :P

Link to comment
Share on other sites

It also depends on what you program...

 

True enough. I tend to hit a lot more edge cases and do a lot more hexdumps than most programmers. You know you're out there when your physical calculator regularly overflows from the computations you're putting into it. :)

 

Even in C, there's little need for a calculator and basically none for a table.
Eh? What about RGB? The range for each number is between 0-256, which is 8 bits/2 nibbles. It's incredibly difficult to do those conversions in your head. Well, at least it is for me. Others might be much better at decimal -> hex conversion than I.

 

If you are writing a driver (or a compiler :) )

 

...or a file system, an emulator, an operating system, a compression/packing algo, an FPGA design...

 

Um. Definite edge cases. :D

 

chances are you'll use lots of binary and bitwise operations. C doesn't allow you to specify binary, but you can specify hexadecimal, which can be converted to/from binary in your head without much thought since you only have to look at 4 bits at a time.
Indeed. However, I find it much faster to convert long strings using a calculator. Since I usually keep one handy, it takes me a lot less time to punch in 1100101011010001 and get a decimal or hexidecimal conversion than it does to do it by hand. The really time consuming conversions are in addressing. 0x2000000 just doesn't stand out as 32 megs to me, no matter how long I work with hex. I sleep, eat, and breath hex, but I never really relate hex and decimal in my head.

 

Speaking of which, I've always gotten a kick out of this Blue Sky Ranger tale:

 

FUN FACT: While testing the game, Keith's boss Mike Minkoff kept getting access codes that ended in "69." Mike accused Keith several times of skewing the random numbers for an adolescent joke. Tired of being unfairly accused, Keith put the data stream 01000101 (the binary representation of 69) in the game's opening demo screen. He then told Mike, "Look, if I was going to put a '69' in the game, I'd put it right on the title screen!" and waited to see how long it would take Mike to notice. He never did; the game went out that way. 01000101 appeared on the demo screen, in the advertising, on the back of the box and in the instructions. When Keith finally pointed it out, Mike said, "But that's 45!" Mike is such a dedicated programmer, he saw the number in hexadecimal (base 16); he never made the final calculation that 45 (base 16) is 69 (base 10).
Edited by jbanes
Link to comment
Share on other sites

Even in C, there's little need for a calculator and basically none for a table.
Eh? What about RGB? The range for each number is between 0-256, which is 8 bits/2 nibbles. It's incredibly difficult to do those conversions in your head. Well, at least it is for me. Others might be much better at decimal -> hex conversion than I.

(184<<16) | (67<<8) | 112

 

Any modern C compiler will preprocess the above into a constant for you.

 

I find it much faster to convert long strings using a calculator. Since I usually keep one handy, it takes me a lot less time to punch in 1100101011010001 and get a decimal or hexidecimal conversion than it does to do it by hand.

0145321 or 0xcad1 - just as fast as whipping out a calculator and typing it in, once you're used to it.

 

Though if you prefer coding in decimal, go ahead with the calculator, as that's a lot harder to convert by hand.

Edited by batari
Link to comment
Share on other sites

(184<<16) | (67<<8) | 112

 

Any modern C compiler will preprocess the above into a constant for you.

 

A good point. As a matter of personal preference, though, I'd much rather punch in 0xB84370, as I find it much more easy to visually "read" when I'm scanning the source. To me, that stands out as a color packed into an integer.

 

Though if you prefer coding in decimal, go ahead with the calculator, as that's a lot harder to convert by hand.

 

Not so much as coding in decimal, as plugging in decimal values. I "think" the value "32 megs" which I can then convert to "32 * 1024 * 1024 = 34044240" fairly quickly. But when I put it into a program, I start thinking about the byte boundaries, so I convert it to 0x02000000. Again, it's just a personal preference. I find I have a lot fewer bugs if I stick with decimal for manual computations.

Link to comment
Share on other sites

(184<<16) | (67<<8) | 112

 

Any modern C compiler will preprocess the above into a constant for you.

 

A good point. As a matter of personal preference, though, I'd much rather punch in 0xB84370, as I find it much more easy to visually "read" when I'm scanning the source. To me, that stands out as a color packed into an integer.

Actually, I'm being a bad programmer in the example above, as it's kind of messy... This is better than my other example:

 

#define RGB(a, b, c) ((a)<<16)|((b)<<8)|( c)

 

Then you can do RGB(184,67,112) and it will be translated into a constant, making it both efficient and easy to read in the source.

Edited by batari
Link to comment
Share on other sites

Actually, I'm being a bad programmer in the example above, as it's kind of messy... This is better than my other example:

 

#define RGB(a, b, c) ((a)<<16)|((b)<<8)|( c)

 

That is generally better, but that doesn't work in Java unless you use a non-standard pre-processor. Which would mean a runtime conversion and a utlity class of some sort.

Link to comment
Share on other sites

Actually, I'm being a bad programmer in the example above, as it's kind of messy... This is better than my other example:

 

#define RGB(a, b, c) ((a)<<16)|((b)<<8)|( c)

 

Then you can do RGB(184,67,112) and it will be translated into a constant, making it both efficient and easy to read in the source.

 

You're still a bad programmer with your version of that macro :)

You should always put parentheses around such a macro, in case it is used in a larger expression (which is, admittedly, unlikely with that particular RGB macro. Then again, as a rule of thumb, in software development if you thought something is unlikely to happen it will happen).

 

#define RGB(a, b, c) (((a)<<16)|((b)<<8)|( c))

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...