UNIXcoffee928 Posted January 19, 2009 Share Posted January 19, 2009 That's true, and it is a more elegant solution. I described the first program based on the more academic form shown in Atari Roots, since we were discussing that book. A good thing to remember is that there are always lots of ways to do something, for instance, we could assemble & save a bare-bones file called "BL2" that was very short, & to the point, yet equivalent in function to the above two examples: 01 .OPT OBJ 02 *= $02C6 03 .BYTE $0 Just: ASM then SAVE #D:BL2<02C6,02C6 You can load BL2 from DOS with the "Binary Load" command for a black background in DOS. Fine for a quick solution, but labels & comments will make your code much more readable, especially once your programs get longer. It would be kinda neat if other users posted different ways to achieve this functionality, to show a bunch of examples for people getting started. Quote Link to comment Share on other sites More sharing options...
Urchlay Posted January 19, 2009 Share Posted January 19, 2009 What you suggest is that it turns the screen black during the assembling process. Is it possible to assemble this to a com file? Sure. Actually, what happens is that one byte (a zero) gets loaded at location $02C6, whenever you load this file. Obviously it's not executable code, but that's why I said to assemble it without a run address. Without a run address, DOS just loads the binary file into memory, then returns to the menu. Quote Link to comment Share on other sites More sharing options...
1050 Posted January 20, 2009 Share Posted January 20, 2009 What you suggest is that it turns the screen black during the assembling process. Is it possible to assemble this to a com file? Sure. Actually, what happens is that one byte (a zero) gets loaded at location $02C6, whenever you load this file. Obviously it's not executable code, but that's why I said to assemble it without a run address. Without a run address, DOS just loads the binary file into memory, then returns to the menu. And this one is so simple we really don't need any assemblers at all. Drawing on knowledge of Atari file syntax we can do this in a disk editor: FF, FF, c6, 02, c6, 02, 00 And then point to the sector that holds that code with a directory entry properly filled out - and that simple, it's a com file. There is more that needs doing depending on the exact DOS used, but that goes back to the knowledge of Atari file syntax. Which is another subject that should get some air time, I've never seen it fully covered in one place. I learned on my own with a disk editor and the occasional clue from Mapping the Atari, etc. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted January 20, 2009 Share Posted January 20, 2009 honestly this "memory" and "register changes" by DOS are nonsense for beginners...confuse more than help? Quote Link to comment Share on other sites More sharing options...
roland p Posted January 20, 2009 Share Posted January 20, 2009 Here's another tool you may find useful (for beginners and experienced programmers alike): http://home.pacbell.net/michal_k/6502.html It's a 6502 simulator that includes an integrated macro assembler and debugger. I use it to develop and verify subroutines. I like it because it allows easy source-level debugging. You can certainly do the same thing using the monitor that comes with Atari800 win+ but this application has a nice IDE-like GUI. It's ideal for experimenting with 6502 assembler. tjb Oh, I know that... that is cool one...I played around with it in the past, too... But he should go really quickly to de facto standards nowadays so when posting code etc or getting sources he does not get frustrated by not running or converting source codes... my 2 cents... Are there better simulators? Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 20, 2009 Share Posted January 20, 2009 Just use the AsmEd cart... it's got Step and Trace. Ideal way for someone starting out to see what's going on. The GUI based stuff is all well and good, but at least the old way, you've got a screenful of info so you have a bit of history. Quote Link to comment Share on other sites More sharing options...
Marius Posted January 20, 2009 Share Posted January 20, 2009 Another important thing is: make sure that the documentation you use, is error-free. My first steps on 6502 coding where in 1989 when I bought a book called "Machinetaal voor Atari XL/XE" written by Roelf Sluman (it's a dutch book, called Machinelanguage for Atari XL/XE" This book was really FULL of mistakes, and that made me believe I would never be able to learn it. I was 13 years old and I gave up... years later i was able to understand what was going wrong. This book was -beside of the errors- a good start. It described things very well, and I think such a book/course is a great start, as long as it is error free. Greetz M. Quote Link to comment Share on other sites More sharing options...
Trooper Posted January 23, 2009 Author Share Posted January 23, 2009 Thanks everybody for the great advice, I guess I will start out with Atari Roots and see if I can make heads or tails of any of it Bounty Bob: Yeah I hope to get some playtime in this years HSC, it's always lots of fun competing in the games from your childhood If only there were more hours in the day Quote Link to comment Share on other sites More sharing options...
Ransom Posted January 23, 2009 Share Posted January 23, 2009 Atari Roots is a good book for beginners. http://www.atariarchives.org/ I definitely agree with that! Way back when, that book was the breakthrough for me. I didn't know it was online now, tho! Quote Link to comment Share on other sites More sharing options...
undeadmechanic Posted February 2, 2009 Share Posted February 2, 2009 I program exclusively on a real 130XE and an original 800. The 130 has MyIDE and I run Mac/65. Assembles plenty fast enough for me. As for books, I have all the Atari related books released by Compute!. The best ones to have would be "Machine Language For Beginners", "The Second Book of Machine Language", and "Assembly Language Programming for the Atari Computers". No Atari book collection is complete without "Mapping The Atari", the revised 1985 edition. These 4 books are pretty much essential. All of these books are on atariarchives.org. Quote Link to comment Share on other sites More sharing options...
potatohead Posted February 2, 2009 Share Posted February 2, 2009 One thing I did to learn assembly was write some very simple programs. One such program is to just count up numbers on the text screen. It can be done in pieces! zero = $30 'character value of "0" nine = $39 'character value of "9" screen = $6000 'some address that's on the text screen $a9, $30 ' lda #zero Load the number that represents a "0" digit into the A register $a2, $08 ' ldx #8 Load the X register with the number of digits to write to screen $9d, $c7, $7c 'digits sta numbers, x Write the first digit to the screen (screen memory + X) $ca ' dex Subtract one digit --this also moves the screen index $e0, $00 ' cpx #0 Are we all done with the digits? (0 = no more digits remain) $d0, $f8 ' bne digits Not done? Write next digit. (other code) Done? Move on. This little chunk will write the zeros to the screen. There are some things you can do that really help get started. This program will actually work, but you probably have to adjust the screen address for your Atari, and maybe the character values too. I think this one is in ASCII. The first part are your defines. Try very hard to use these where you can. That's a big part of what "Mapping the Atari" is all about. Memory locations do stuff, and that's what you need for assembly language programs. In this little snippet, the only things we need to know are the character values, and really only zero for this piece, and the location in memory where we plan to write them. So for a simple program, it's good to collect the bits needed and define them so you don't have to focus on those later on. Also, if you make a mistake, it's really easy to change these, where if they are coded into the program itself, it's harder and easier to make more mistakes. Break your program plan down into little tiny tasks! That works kind of like this: So, the goal here is to write some zeros to the screen in preparation for counting them up, sequentially like an odometer for your car. We know the values of things, so the tasks are: 1. Load up a zero 2. Load up the counter for the number of zeros. 3. Calculate where it needs to go to show on your text screen. 4. Store one of the zeros. 5. Change your counter. 6. Done? 7. If so, continue on. 8. If not, go back and do it again and again. Assembly language programs focus on each bit of detail and each bit of detail just isn't all that much. The 6502 just doesn't do all that much at any one time, but it does it fast! Then you go and sort out the kind of instruction. 1. That's a load. What kind of load? The 6502 has a lot of addressing modes. Immediate mode is the right answer here, because that mode basically takes a number, stored right in the program instruction and puts it into a register. You do stuff to and from the registers, for the most part. 2. That's a load too. Same kind. 3. & 4. That's a store, but to where? This is where the detail helps you out. Really, the store is to some screen address, plus something for each digit! Addressing modes help out here again. Be sure you understand those well. It's worth thinking through each one. In this case, the addressing mode is absolute + X. So the calculation happens in the addressing mode, which then directs the store instruction to do it's thing in the right place. 5. This is a decrement. What to decrement? The counter register, which happens to be X. Implied is the addressing mode because the instruction contains all it needs to know. Just subtract one from the X register, and move on. Counters are often associated with simple add one and subtract one operations. That's increment and decrement. For anything else, you need to use an add or sub instruction. Since the 6502 really only handles a byte at a time, increment and decrement operations are just handy. That's why there is one fast instruction for them. 6. Now we have to make a decision. On computers, comparing two numbers boils down to subtracting them and looking at the result. On the 6502, we've got a cmp (compare) instruction that does this and sets the flags. As the CPU crunches through things, the state of it's calculations is always updated in the status flags. Branches work off of these to do stuff. Compare to what? Again, the immediate addressing mode is handy, because we have a known value to compare to. Works a lot like the load instructions above. 7. Branch. Eventually your program is gonna have to execute some code based on some flag, and some other code based on some other flag. There are a number of branches you can use. This one works easily enough with branch if not equal, or bne. Branch where? The target of the branch is really the store instruction again. On the 6502, branches have a limited range of about 127 bytes in either direction. For larger programs, that's an issue to be resolved with a jump or other tricks! For this little program, we need to plug in the offset value that when added to the program counter, will put us at the store instruction again. Your assembler can do this with a label. That's what 'digits' in the source code above is all about. For this little program, I hand assembled it for a test. That's why it's in nice binary value, followed by human readable instruction, followed by a comment form. The assembler will do the math, then plug in the value. The addressing mode is kind of locked in for these, and it's program counter relative, or mostly immediate as the branch target is part of the instruction itself' just like the other load instructions were. (not sure which to call it! somebody here will correct me on that) Now it's basically done. At this point, you will have looked through your references, snagging bits and pieces you need. Looking up the screen location and character values tells you what to do with the load instructions. So write those and comment them like I have above. It's more complicated at first, but it's worth doing. If you write it on paper, just like I have above, you are basically hand assembling. Do this for some simple stuff, just to know what's really going on. As soon as you grok it, then move on as it will slow you down. As a kid, I did this stuff while in school, only to rush to type stuff in during lunch! LOL!! (it was so much nicer to get my own damn computer!) Anyway, looking up the opcode tells you it's $a9 for the first load to accumulator instruction. (lda) So, write that down, then look at your constants for the character value, say $30. Now you have actually written a line of assembly code! Follow that with your instruction, and your comment and move on to the next one, and the next, etc... When you get to the branch, read your books! It's good to understand how that one works. I'm not going to cover it right now however. Eventually you will have looked all the stuff up, and have your program ready to go. Since you have an assembler handy, go ahead and type in the program text and look at the output! It should look like what you did by hand, and if it does, sweet! You are cooking with gas. If not... go do some looking until it does. This is a lot of work, but it's totally worth it. Skip some of this early stuff, and you run into little troubles here and there that just make larger programs harder. YMMV I'll post up the counting bit after this long post, just so you can see it and probably improve on it! I've done this for every CPU I've ever learned on. It's tedious, but it works well. Another great thing to do is go through other programs and just try to comment them, or interpret the comments. All of this helps you see the kinds of detail bits you need to be thinking about to put assembly programs together. For me, this is always the hardest part!! Another nice thing about this is that it's not so tough to debug. Did it appear on the screen? If so, your screen information and store instructions are right. If it didn't, then that's where you look. Did the right number of digits appear? If so, your counter and addressing mode for the screen are right. Did they appear in the wrong place? Look at your counter and addressing modes and such. Were there too many of them? Look at your branch and compare. It's all simple and visual, making it easy. Try to build these kinds of programs at first and you will have a good time of it. As you get better, you will be able to hold more in your head, allowing you to build bigger things and still be able to debug them. Use the tools in your assembler to step through the program, watching the registers and flags to see it all happen. I didn't have that facility for getting started. My group of computer geeks used a substitute! We would have somebody else think through the program and look for problems. You've got the debugger and probably some help here! Don't forget to have fun. Assembly is kind of depressing at times. You will work for an hour, only to get nothing on your screen in such little time your finger doesn't even leave the execute key! That's ok. It will pass. Quote Link to comment Share on other sites More sharing options...
potatohead Posted February 2, 2009 Share Posted February 2, 2009 $a0, $30 ' ldy #zero 'have this handy... $a2, $08 'count1 ldx #8 'back to first digit $fe, $c7, $7c ' inc numbers, x 'increment first one $bd, $c7, $7c ' lda numbers, x 'look it over $44, $3a ' cmp #nine + 1 'are we over nine? $d0, $f4 ' bne count1 'no, keep going... $98 ' tya $9d, $c7, $7c ' sta numbers, x 'reset digit count $ca ' dex 'point to next digit $fe, $c7, $7c ' inc numbers, x 'increment second one $bd, $c7, $7c ' lda numbers, x $44, $3a ' cmp #nine + 1 $d0, $ef ' bne count1 $98 ' tya $9d, $c7, $7c ' sta numbers, x 'reset digit count $ca ' dex 'point to next digit $fe, $c7, $7c ' inc numbers, x 'increment next one $bd, $c7, $7c ' lda numbers, x $44, $3a ' cmp #nine + 1 $d0, $ef ' bne count1 $98 ' tya $9d, $c7, $7c ' sta numbers, x 'reset digit count $ca ' dex 'point to next digit $fe, $c7, $7c ' inc numbers, x 'increment next one $bd, $c7, $7c ' lda numbers, x $44, $3a ' cmp #nine + 1 $d0, $ef ' bne count1 $98 ' tya $9d, $c7, $7c ' sta numbers, x 'reset digit count $ca ' dex 'point to next digit $fe, $c7, $7c ' inc numbers, x 'increment next one $bd, $c7, $7c ' lda numbers, x $44, $3a ' cmp #nine + 1 $d0, $ef ' bne count1 $98 ' tya $9d, $c7, $7c ' sta numbers, x 'reset digit count $ca ' dex 'point to next digit $fe, $c7, $7c ' inc numbers, x 'increment next one $bd, $c7, $7c ' lda numbers, x $44, $3a ' cmp #nine + 1 $d0, $ef ' bne count1 $98 ' tya $9d, $c7, $7c ' sta numbers, x 'reset digit count $ca ' dex 'point to next digit $fe, $c7, $7c ' inc numbers, x 'increment next one $bd, $c7, $7c ' lda numbers, x $44, $3a ' cmp #nine + 1 $d0, $ef ' bne count1 $98 ' tya $9d, $c7, $7c ' sta numbers, x 'reset digit count $ca ' dex 'point to next digit $fe, $c7, $7c ' inc numbers, x 'increment next one $bd, $c7, $7c ' lda numbers, x $44, $3a ' cmp #nine + 1 $d0, $ef ' bne count1 Quote Link to comment Share on other sites More sharing options...
potatohead Posted February 2, 2009 Share Posted February 2, 2009 This one can be done in pieces too. Get it to do the first digit, then two, then all of them. Quote Link to comment Share on other sites More sharing options...
Marius Posted February 3, 2009 Share Posted February 3, 2009 when you post things in a 'absolute beginner' thread, really be sure there are no errors in your code. You have the label "SCREEN" = $6000 but in your code you use "NUMBERS" I guess this must be SCREEN? thanks Marius p.s. or the label "SCREEN" must be changed into "numbers" Quote Link to comment Share on other sites More sharing options...
potatohead Posted February 3, 2009 Share Posted February 3, 2009 Good catch! Well, if I could edit it, I would. Too late now, but for our brief exchange. It is what it is now. I would just change the label to numbers, and call it good, and comment that's the screen location. Really, my intent was to help frame up the process as in "where to go" and "something to do", as much as it was just posting up something that works. That was actually sample run code from a 6502 emulator project. It was hand assembled, and that's where the label confusion came into play, just FYI. Quote Link to comment Share on other sites More sharing options...
UNIXcoffee928 Posted February 12, 2009 Share Posted February 12, 2009 A really well written book that will help you to understand the concepts you need to know is: Apple II Assembley Language by Marvin L. De Jong Howard W. Sams & Co. 1982 ISBN:0-672-21894-1 Available at Amazon here: http://www.amazon.com/Assembly-Language-Bl...603&sr=11-1 Of course it is Apple II focused, but if you use it with Atari Roots, it fills in a lot of info, since both systems are 6502-based. It is written very clearly, and presents all of the concepts in a very well laid-out & straightforward manner. A lot of Assembly Language books are not good reads... this one definitely is! Quote Link to comment Share on other sites More sharing options...
carmel_andrews Posted February 12, 2009 Share Posted February 12, 2009 A really well written book that will help you to understand the concepts you need to know is: Apple II Assembley Language by Marvin L. De Jong Howard W. Sams & Co. 1982 ISBN:0-672-21894-1 Available at Amazon here: http://www.amazon.com/Assembly-Language-Bl...603&sr=11-1 Of course it is Apple II focused, but if you use it with Atari Roots, it fills in a lot of info, since both systems are 6502-based. It is written very clearly, and presents all of the concepts in a very well laid-out & straightforward manner. A lot of Assembly Language books are not good reads... this one definitely is! Is this also available as 'text' on the internet (the apple book that is) Also anyone know whatever happened to 'spalp.org' which also tried to show the basics of 6502 assembler programming, i recall that they only did a few paragraphs and that was it Quote Link to comment Share on other sites More sharing options...
Bryan Posted February 12, 2009 Share Posted February 12, 2009 I tried to learn assembly back in the '80s and had a very difficult time understanding what was really going on. I knew the OS was changing things in memory, but didn't understand how it could run if my program was running. It was much later that I got a full grasp of interrupts and whatnot. Today I would probably teach it in this order: 1. Start with a simplified model of a CPU. Show how it can read and store to an array of addresses and perform basic calculations. Then show things like the status register and conditional branching. Next, introduce the stack and interrupt concepts to show it responding to an external event. Eventually build up to a full 6502 model. If you understand the clear division between the CPU and system it operates on, things will be much easier in the long run. 2. Introduce the Atari memory map. Show how the CPU starts up and fetches the start/reset address. Show (in general terms) how ROM allows the system to initialize and start services. Demonstrate how the VBlank code provides regular updates in addition to whatever else is running. 3. Introduce the DMA concept and Antic. Explain how the CPU is stopped at intervals to allow RAM to be read for video generation and how this is invisible to the code being executed. Show example DLISTs and set up a simple screen in memory. 4. Introduce the other IC's and show how they each have an area of memory for their registers. 5. Build up a simple program that integrates video, sound, and user input. 6. Move on to more complex things like custom interrupts (Timers, DLIs) and SIO and so forth. 7. Only now can you start optimizing by taking control away from the OS and managing things yourself. This is also a good time to start learning some of the more advanced shortcuts on the 6502. Learn to arrange your data to best suit 8-bit indexing and how to order instructions for best register usage. These things are essential if you ever want to try your hand at 2600 coding! I started by trying to understand it all at once and got really confused, but if you build up from the basics then you'll see how the Atari architecture makes sense. Quote Link to comment Share on other sites More sharing options...
BigO Posted February 12, 2009 Share Posted February 12, 2009 (edited) I tried to learn assembly back in the '80s and had a very difficult time understanding what was really going on. I knew the OS was changing things in memory, but didn't understand how it could run if my program was running. It was much later that I got a full grasp of interrupts and whatnot. Today I would probably teach it in this order: 1. Start with a simplified model of a CPU. Show how it can read and store to an array of addresses and perform basic calculations. Then show things like the status register and conditional branching. Next, introduce the stack and interrupt concepts to show it responding to an external event. Eventually build up to a full 6502 model. If you understand the clear division between the CPU and system it operates on, things will be much easier in the long run. 2. Introduce the Atari memory map. Show how the CPU starts up and fetches the start/reset address. Show (in general terms) how ROM allows the system to initialize and start services. Demonstrate how the VBlank code provides regular updates in addition to whatever else is running. 3. Introduce the DMA concept and Antic. Explain how the CPU is stopped at intervals to allow RAM to be read for video generation and how this is invisible to the code being executed. Show example DLISTs and set up a simple screen in memory. 4. Introduce the other IC's and show how they each have an area of memory for their registers. 5. Build up a simple program that integrates video, sound, and user input. 6. Move on to more complex things like custom interrupts (Timers, DLIs) and SIO and so forth. 7. Only now can you start optimizing by taking control away from the OS and managing things yourself. This is also a good time to start learning some of the more advanced shortcuts on the 6502. Learn to arrange your data to best suit 8-bit indexing and how to order instructions for best register usage. These things are essential if you ever want to try your hand at 2600 coding! I started by trying to understand it all at once and got really confused, but if you build up from the basics then you'll see how the Atari architecture makes sense. I can't imagine how difficult it would be to (attempt to) write assembly language code if you didn't realize what you were actually doing with respect to reading/writing CPU registers, directly accessing memory and I/O devices by address, etc. It's hard enough when you do understand things to that depth. Seems like it would be nigh on to impossible without that understanding. Edited February 12, 2009 by BigO Quote Link to comment Share on other sites More sharing options...
Bryan Posted February 12, 2009 Share Posted February 12, 2009 I can't imagine how difficult it would be to (attempt to) write assembly language code if you didn't realize what you were actually doing with respect to reading/writing CPU registers, directly accessing memory and I/O devices by address, etc. It's hard enough when you do understand things to that depth. Seems like it would be nigh on to impossible without that understanding. One of the reasons I wrote Castle Crisis was to make up for how frustrated I was by assembly the first time I tried it. Once I went back and learned everything properly I needed to prove I could write a big program like I'd always dreamed of doing. Quote Link to comment Share on other sites More sharing options...
Urchlay Posted February 12, 2009 Share Posted February 12, 2009 Also anyone know whatever happened to 'spalp.org' which also tried to show the basics of 6502 assembler programming, i recall that they only did a few paragraphs and that was it Wow, I can't believe someone actually remembers spalp.org... that was supposed to be a collaboration between me and 2 other guys. Unfortunately the other guys never got around to actually writing anything. The site died due to lack of interest... Also one of those 2 guys turned out to be a complete psychopath, and he's the one who registered the domain (which eventually expired). Sadly, I don't seem to have any of the content from the site any more. Quote Link to comment Share on other sites More sharing options...
charliecron Posted February 12, 2009 Share Posted February 12, 2009 Some of it seems to have been archived. http://web.archive.org/web/20030724173444/...rials/italpaga/ Quote Link to comment Share on other sites More sharing options...
carmel_andrews Posted February 12, 2009 Share Posted February 12, 2009 Also anyone know whatever happened to 'spalp.org' which also tried to show the basics of 6502 assembler programming, i recall that they only did a few paragraphs and that was it Wow, I can't believe someone actually remembers spalp.org... that was supposed to be a collaboration between me and 2 other guys. Unfortunately the other guys never got around to actually writing anything. The site died due to lack of interest... Also one of those 2 guys turned out to be a complete psychopath, and he's the one who registered the domain (which eventually expired). Sadly, I don't seem to have any of the content from the site any more. Oops, looks like next time, ill keep that trap of mine shut...it would seem that I've opened a nasty old wound that should have healed Quote Link to comment Share on other sites More sharing options...
Urchlay Posted February 13, 2009 Share Posted February 13, 2009 Oops, looks like next time, ill keep that trap of mine shut...it would seem that I've opened a nasty old wound that should have healed Nah, how would you possibly have known? Quote Link to comment Share on other sites More sharing options...
carmel_andrews Posted February 13, 2009 Share Posted February 13, 2009 Oops, looks like next time, ill keep that trap of mine shut...it would seem that I've opened a nasty old wound that should have healed Nah, how would you possibly have known? This is just an idea that is all, perhaps if the coders here (including you) could modify the series of ML tutorials on CSDB's forum (sorry forgot the link) and make them specific to the Atari8, that would be fan bloody tastic Or just come up with a better version of those tutorials but just focusing on the a8 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.