I want to really learn low-level programming, but the problem with that is I don't know how to use hex numbers, and I know its almost essential to know those in order to use (You guessed it) Good O'l Assembly.
ummm..... no, i don't think hex is essential. i dont know assembly but i tried learning it and it didnt require hex. how long have you been programming? since ur twelve im guessing not that long. you probably want to stick with c++ for a while and anyways its pretty low level also:
What are you having trouble with understanding when it comes to hexadecimal numbers?
It uses 16 symbols (1-9 and A-F) the order being 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F. So for example "13" in hex would be "d" (The 13th symbol) or "127" would be "7f".
I admit it is quite hard to understand in the beginning but just start looking at some multiplication tables for hex and other tables and you will get the hang of it. Print a few out and put them by your computer for reference, and most operating systems come with scientific calculators that can deal with hex numbers so use that also or download a good calculator application.
FredBill: I have been programming for about three years. ive made like five games, two encryption algorithims, and i can memorize about 300 lines of code and rewrite on paper by just reading it line by line once. ive learned ruby. it is nothing like assembly
There is absolutely nothing in assembly that would require learning hex. You should have some understanding of binary though, but only about as mush as to understand that shift left is multiplication by 2 and etc. Decimal is a bit awkward though. For example, (from os development) pages start at multiples of 212 = 0x1000, so if an error happens and I see that my instruction pointer was at 0x60C2, I know it's on page 6. If instead it was printed as 24770, I'd have to divide it by 4096 first. In other words, it's just a thing of comfort.
@guestgulkan, no <...> is going to write what in decimal? Also, I don't think he (it's a he) is completely baffled by 0xABC, it's just that he needs a converter to get the decimal value (the big revelation to be had here is that you don't need the decimal value, usually all you need it to subtract 4, or drop some digits or something trivial like that). And there is nothing wrong with that. I feel that you're just propagating the stereotype of ASM being some kind of complex-math-hacker thing, while in reality it is just totally uncomfortable and somewhat boring.
If you're interested, the instruction set for the 68000 chip is reasonably simple once you get going. I'd advise using the Easy68k editor/assembler. http://www.easy68k.com/
I've been doing this all week and I'm sick of it now. The plus side is that it's all fresh in my mind if you need a hand.
As for hex, you'd best understand how it works and have a dec to hex calculator handy. Mastery isn't really required, but it is definitely handy to know. There are situations in 68k that rely on it, such as giving cursor coordinates in hex as it allows 256 values in just one byte.
Also, all of your memory addresses are in hex, so it's a good idea to have a grounding on it.
As for binary, I haven't had much interaction with it on this endeavour, but it'd be handy to know. As chrisname pointed out, neither of them of particularly difficult.
All AMD and Intel x86 processors are backwards-compatible all the way back to the original 8086. They start in a processing mode called "real-mode" which is identical to the original 8086. The software can then explicitly enable "protected mode" which is the 32-bit operating mode introduced with the 80386. On 64-bit processors, software can then enable 64-bit "long mode". These are all layers built on top of each other. In short, you don't need an emulator specifically for the 80386 (the first 32-bit Intel CPU), you just need any Intel emulator (or real CPU), they're all compatible.