13 replies to this topic

[MikFire]

Here is a conversion chart for hexadecimal, decimal, and binary http://www.dewassoc....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

[Thomas Jentzsch]

MikFire, on Sun Jun 4, 2006 5:06 PM, said:

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

You don't have to convert binary numbers into hex. Just use the % prefix for binary numbers.

[nmoog]

I don't even see the binary anymore... All i see is frogger... mario... E.T...

[jbanes]

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.

[Thomas Jentzsch]

jbanes, on Mon Jun 5, 2006 6:06 AM, said:

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.

[jbanes]

Thomas Jentzsch, on Mon Jun 5, 2006 2:00 AM, said:

jbanes, on Mon Jun 5, 2006 6:06 AM, said:

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.)

[SpiceWare]

I think you're missing the point

jbanes, on Mon Jun 5, 2006 8:52 AM, said:

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.

Quote

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.)

[batari]

jbanes, on Mon Jun 5, 2006 8:52 AM, said:

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

[jbanes]

batari, on Tue Jun 6, 2006 4:14 PM, said:

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.

Quote

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.

Quote

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.

Quote

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:

Quote

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, Tue Jun 6, 2006 3:42 PM.

[batari]

jbanes, on Tue Jun 6, 2006 4:36 PM, said:

batari, on Tue Jun 6, 2006 4:14 PM, said:

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<< | 112

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

Quote

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, Tue Jun 6, 2006 4:03 PM.

[jbanes]

batari, on Tue Jun 6, 2006 5:03 PM, said:

(184<<16) | (67<< | 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.

Quote

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.

[batari]

jbanes, on Tue Jun 6, 2006 5:16 PM, said:

batari, on Tue Jun 6, 2006 5:03 PM, said:

(184<<16) | (67<< | 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)<<|( 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, Tue Jun 6, 2006 4:26 PM.

[jbanes]

batari, on Tue Jun 6, 2006 5:25 PM, said:

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)<<|( 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.

[Tom]

batari, on Tue Jun 6, 2006 5:25 PM, said:

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)<<|( 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)<<|( c))