Taking the first steps to programming...

[Clint Thompson]

Well.... since I have the free time and I'm technically getting paid to read it, I decided that I should start to learn Assembly (Machine Language), even if I can't come to snuff enough to program my own game, at least I'll better understand it all.

 

I guess I did very little research but wanted to learn coding for the 6502

(for obvious reasons) and found on the atariarchives Machine Language

for Beginners and just started reading that and decided I will finish it. I'm on Chapter 5 right now (just started tonight) and it's

actually helped me understand quite a few things that were unclear to me before. (taking break now...lunch is soon)

 

I still don't understand the whole thing yet (as I haven't read the whole book either) but I got that hexadecimals is like a short hand for binary assembly. (Here I was thinking you would actually have to type 00001011 strings just to get anywhere) and it's just as easy to type $A0 instead (I know, it doesn't match up, just example)

 

The other thing that really confused me was the whole line number thing. It was saying a simple assembler addresses each line like you do in basic, although not the same.

 

I guess I pretty much know how to print the letter A (or more easily) Hello World, now... on the screen (on the Atari Computers anyhow)

but haven't assembled anything usable.

 

How I'm going to go from text to the 7800 with it's own memory map may not be a problem.... it's the whole graphics sound and interactoin thing that scares me

*Guess this topic just goes to show how much I don't know about programming *

 

After I get done reading the whole thing, hopefully it won't be too terrible for me to post my quesitons on this subject in this topic hoping for a response.

 

Anyways, I guess everyone starts somewhere..... I've finally taken 1 step

 

Wish me luck

 

Clint

[Clint Thompson]

Oh... and if I screw anything up by what I say or ask please correct me.

 

Thanks.

 

[Mindfield]

Funny thing about 6502 assembler. Once upon a time I'd look at assembler listings in magazines and it would look like pure gibberish to me. It might as well have been written in Sanskrit for all the sense it made. I was fairly familiar with BASIC programming at that time, but assembler was utterly beyond me.

 

Then one day, for seemingly no apparent reason, I looked at it it -- actually looked and tried to make some sense (along with some of the notes in the listing explanation) more than just glanced over it the same way I would complex algebraeic equations. (I sucked at math in high school). For whatever reason, it actually started making sense.

 

"So ... the three letter things on the left are the commands, and the bits on the right are the parameters. And there's this accumulator and a couple of these register thingies that are sort of like staging areas for manipulating little bits of data. And that one, that LDA, that's loading a value into the accumulator, and the one after that, it's adding something to it, and then it's storing it back with the STA command. And JMP, that's like GOTO. And..."

 

Not long after that I started writing modules for Oasis BBS in MAC/65. :-)

 

The secret truth about assembler is that it's actually really easy. If you have a head for technical stuff, it's easier to pick up than BASIC or C. The thing that throws most people off are all the obfuscated mnemonics -- they don't really look like they mean anything to the casual observer, not like BASIC commands that acutally do pretty much what they spell out. Plus, BASIC does in one function what it takes five or six lines of assembler code to accomplish. But what assembler is all about is the minutae -- you're basically building your program one byte at a time. But instead of simply writing "PRINT "Hello world!"" you're writing the loop to iterate through each byte of your text and reading each character in succession from your text data, then outputting it to the screen at each iteration. You even have to include the carriage return. :-)

 

It's fun in its own way.

 

With regards to decimal, binary and hex -- that too is pretty easy to wrap your head around. Generally you'll only need to use binary when working with bitwise operators (using bits as program control flags and whatnot). Hex is pretty easy -- you just have to remember that it's base-16, so numbers go from 1 to F (or 1 to 16 in decimal).

 

I wrote a paper in college once explaining how to convert directly to and from hex and decimal. For whatever reason they'd have you convert from decimal to binary to hex and back again -- they had absolutely no idea how to skip the binary stage, which struck me as absurd. Basically, all you need to do is this:

 

Decimal to Hex (8-bit):

 

Divide your number by 16. Convert the whole product to a single hex number. This is your first hex digit. Take the whole number and multiply by 16, then take the difference between the result of that and your original number and convert that to hex. This is your second hex digit.

 

Example: 182 decimal. Divide by 16 (11, ignoring remainder). 11 in hex is $B. 11 multiplied by 16 is 176. The difference between 176 and 182 is 6. 6 is the same in hex. Therefore, 182 is $B6 in hexidecimal.

 

Hex to Decimal (8-bit):

 

Convert the first hex digit to decimal and multiply by 16. Convert the second hex digit to decimal and add it to the product of the first.

 

Example: $B6 hex. $B is 11 in decimal. 11 multiplied by 16 is 176. 6 is the same in decimal. Added to 176 you get 182.

 

16-bit works almost the same way:

 

Decimal to Hex (16-bit):

 

Take your number and divide by 256. Convert the whole result (ignoring the remainder) to hex as above for 8-bit. This is your high byte. Now take the whole number and multiply by 256. The difference between the result and your original number will be your low byte after converting to hex as above for 8-bit.

 

Example: 5012. Divide by 256 to get 19 (ignoring the remainder). 19 in hex is $13. Multiply 19 by 256 to get 4096 to get 4864. The difference between 4864 and 5012 is 148. 148 in hex is $94. 5012 decimal is therefore $1394 in hex.

 

Hex to Decimal (16-bit):

 

Take the high byte, convert to decimal as above, and multiply by 256. Take the low byte, convert to decimal as above, and add it to the previous result. This is your decimal number.

 

Example: $1394. $13 is your high byte. Converted to decimal you get 4864. $94 is your low byte. Converted to decimal you get 148. 148 added to 4864 is 5012.

 

You may already know all this, but here it is anyway. :-)

[Clint Thompson]

Thanks for the response mindfield.

 

I pretty much knew how to look up the conversoins but how you put it seems to make much more sense. I'm currently on the 6th chapter of that.... looking into the commands...

 

(JSR, JMP, CMP, BNE and all that Jazz)

 

Now... I assume that the 6502C has it's own set of unique commands?

If it does, where can I get this list? If not, what exactly makes it a custom CPU oppose to just any other 6502?

 

Thanks agian!

 

Clint

[Mindfield]

Thanks for the response mindfield.

 

I pretty much knew how to look up the conversoins but how you put it seems to make much more sense. I'm currently on the 6th chapter of that.... looking into the commands...

 

(JSR, JMP, CMP, BNE and all that Jazz)

 

Now... I assume that the 6502C has it's own set of unique commands?

If it does, where can I get this list? If not, what exactly makes it a custom CPU oppose to just any other 6502?

 

Thanks agian!

 

Clint

 

The only difference between a regular 6502 and the 6502C is a HALT function, whereby the 6502 can be instructed to halt in order to allow Maria (or any other components) full bandwidth access to the bus. Other than that it's just a normal 6502.

[Nukey Shay]

Correct...

The 6502C was used in all Atari 8-bit computers (including the 7800 and 5200 game consoles). It doesn't add any extra programming opcodes to the set. But there are undocumented or "illegal" instructions that have known effects in 65xx CPU's. For example, you might know that the hex code for LDY$zeropage is $A4. LDA$zeropage is $A5...and LDX$zeropage is $A6. Computers are logical creatures...but also very simple-minded and have a simple way of doing things. How a hex code's bitpattern is arranged determines what effect the instruction has. The only thing that is changing between those 3 particular opcodes is the arrangement of the last 2 bits...%00 to affect the Y register, %01 to affect the accumulator, and %10 to affect X. That leaves the pair %11 unused by the "official" instruction set...and the side effect it has is that it loads BOTH A and X with the value (i.e. %11 = %01 + %10). That makes some "illegal" instructions pretty useful, considering you'd do that in half of the cycle time that the same job in "legal" instructions would take. All of them have been given mnemonic names (the example above is referred to as LAX)...but some side effects are so exotic that it might be hard to actually find a good use for them.

A list of undocumented instructions can be seen here:

http://members.chello.nl/taf.offenga/illopc31.txt

[eric_ruck]

Don't forget the Lynx...you have to halt it to let the blitter run. Doesn't it also have a few extra nice instructions like test and set?

 

Anyhow, get past the assembler instructions by writing a couple of small programs to use much. You don't have a lot of options in 6502, so there's not much to learn, at least not from the book.

 

The trick is learning how to do things in certain ways that save memory or processing cycles. Also, because you don't have a fast processor, or much memory, or really that much video hardware (compared to, say, a Radion 9000 and DirectX) that you really need to learn how to plan out what you want to do.

 

Good luck,

Eric

[DracIsBack]

For those who are interested, the link is here:

 

http://www.atariarchives.org/mlb/

 

Thanks for the tip, Clint. I've started reading it too!