not fully in hex, but people used to add some hex coding to make programs more efficient.Also somebody needed to have to understand it to be able to make the compiler.

I remember the good old days with computers like the acorn electron, tandy, and dragon 32 where you could actually add binary code into your program to make it more efficient. I remember copying a binary program out of a book to create a 3d shape on the dragon 32. it was about 10,000 lines of 8 bit binary strings! and no, the end product wanst worth it

hahaha Paul Im fortunate enough to have never had to program in Hex or Binary. I grew up in the age of higher level languages (and this is the part where all the veterans come on and say "Back in my day, they hadnt invented Binary! We had sticks and stones to do our processing for us! If you wanted to enter in values, you had to walk 15 miles in 3 foot snow barefoot uphill both ways! You darned whipper snappers!"

actually most of us still do some hex programming, such as when defining pins as digital or analog. my $50 robot code has a little bit of hex in it.

I actually like to use decimal when defining my port status' simply because I can pretty much physically see which port is which just by looking at the code line but yes I have used Hex in programming but ive never needed to program solely in hex

I programmed in BASIC on my Tandy, binary schminary! I think it had 8 bit color if I remember right . . .

(and Im only in my mid-20's)

actually most of us still do some hex programming, such as when defining pins as digital or analog. my $50 robot code has a little bit of hex in it.

Ditto, basic programming was easier to do. I just copied the binary without actually knowing what was going on

People that use mcu's are lucky in a way because they actually learn about the lower level stuff, higher level stuff, and more about the actual controllers themselves which were skills that were needed in the old days. Now people are generally just being taught how to program in higher level languages (and visual systems) and dont actually know what the program is actually doing on the hardware, they just see the results of it on a screen, I think this is a bit of a disadvantage eventually people will just be trained to program in a modular visual approach and not really have to do anything themselves leaving a small handful of people that genuinely understand whats going on.

AVR hex files are actually fairly readable. The first two hex nibbles after the ":" represent the packet size, which is usually "10" (or 16 bytes). The next four characters are the hex value of the starting flash address of the packet. The next two characters are the packet type (00 = normal, 01 = end of file). The next sequence of characters represent the packet data that will be written to flash, each set of two hex nibbles making up a single byte. The final two characters in the line are the checksum and should equal all of the bytes in the line XORed together. With a little research you could probably even decode the packet bytes into assembly instructions

Quote from: Admin

I programmed in BASIC on my Tandy, binary schminary! I think it had 8 bit color if I remember right . . .

(and Im only in my mid-20's)

Ditto, except for me it was an Apple IIGS when I was 7 or 8 (according to wikipedia, apparently the IIGS had "stunning color graphics and state-of-the-art sound capabilities"!). I found out if I hit the right combination of keys at startup I could get to a blue screen that would let me enter code in BASIC, and the computer came with a little 10(?)-page booklet that listed all of the BASIC instructions. I had no idea what I was doing, but I guess it wasn't too hard to figure out by trial and error.

yea I was about that age too when I started . . . back then video game magazines posted all the code to the games for you to copy . . . cause back then video games were only 1-3 pages of code . . . i would just reverse engineer it . . .