Aces123 Posted May 8, 2020 Share Posted May 8, 2020 10 *=0600 20 LDA #02 30 STA $C2 40 ; 50 ; 60 ; 70 .END The above is what I have written. When I run the debugger (in the assembler editor cartridge) after I have assembled the program I type G0600 and I have also typed G600. When I write DC2 I expect to get something like 00C2 02 00 00 00 00 00, but instead I get 00C2 00 00 00 00 00. What am I doing wrong? 1 Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 8, 2020 Share Posted May 8, 2020 Which assembler is it? Some by default don't generate object code in RAM, Mac-65 is one such example. To assemble to resident memory you need .OPT OBJ If it's the Atari AsmEd cartridge you want a BRK instruction at the end - a big annoyance of that is it doesn't configure to handle RTS (which is a ridiculous oversight that we've had to endure forever) An easier way to get quick feedback whether it's working could be to change border colour instead. Replace $C2 with $2C8 Quote Link to comment Share on other sites More sharing options...
thorfdbg Posted May 8, 2020 Share Posted May 8, 2020 I suggest also to assemble a BRK behind the end of the program, and probably move the value of $C2 to some other location before the program terminates as this zero-page location may be used by the assembler itself. 10 *=$600 20 LDA #$00 30 STA $C2 40 LDA $C2 50 STA $6F0 60 BRK Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 8, 2020 Share Posted May 8, 2020 AsmEd seems to leave that address alone. I'm sure I've seen docs stating what locations it leaves free but couldn't find it in the Atari manual. Quote Link to comment Share on other sites More sharing options...
Aces123 Posted May 8, 2020 Author Share Posted May 8, 2020 My code loks like this now 10 *=0600 20 LDA #08 30 STA $2C8 40 ; 50 ; 60 ; 70 BRK Nothing hapens with the border and when I enter D2C8 I get 00 00 00 00 00 00 00 00 I use the atari cartridge. Quote Link to comment Share on other sites More sharing options...
Preppie Posted May 8, 2020 Share Posted May 8, 2020 line 10 is wrong, you have *=0600 instead of *=$0600 3 Quote Link to comment Share on other sites More sharing options...
Aces123 Posted May 8, 2020 Author Share Posted May 8, 2020 Turns out I forgot the space and $ sign on line 10. When I wrote 10 *= $0600 the border changed and I could see the value stored in $2C8 by typing D2C8 in the debug-mode. 1 Quote Link to comment Share on other sites More sharing options...
Aces123 Posted May 8, 2020 Author Share Posted May 8, 2020 You beat me too it Thanks 1 Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 8, 2020 Share Posted May 8, 2020 How'd we miss that? And it's just luck it didn't crash the machine during assembly - that's $258 which is in the middle of a spare area of about 40 bytes. 1 Quote Link to comment Share on other sites More sharing options...
StickJock Posted May 8, 2020 Share Posted May 8, 2020 I remember having a similar bug once in C, where for some reason, I had a leading 0 in my value. I think that I was probably editing a value and just overtyped to change the value (like changing 100 to 050). I didn't realize that a leading 0 was the notation for Octal! So, in your case, 0600 would be $180 or 384 decimal. In my case, I always checked the assembly diff when I made changes (I'm an assembly programmer at heart) so I saw the bug right away, but it took a while to figure out what was going on. BTW: I think that it is a stupid convention. 2 Quote Link to comment Share on other sites More sharing options...
almightytodd Posted May 28, 2020 Share Posted May 28, 2020 It's funny, because just the other day I made the same mistake while following along with the video here: He uses a starting address of $1000 (4096, I believe...) ...I kept wondering why my code assembled to starting address x03E8. I found that I could run it using G03E8 or T03E8, but I couldn't figure out why... Quote Link to comment Share on other sites More sharing options...
almightytodd Posted May 28, 2020 Share Posted May 28, 2020 ...And while I'm on the topic of this YouTube video (...or perhaps I've hijacked the topic here... ...sorry), I think I've spotted some errors. I'm very new to Assembly Language (on any CPU) so I'm looking for some confirmation. He explains that spaces matter in the Assembly cartridge, and shows the columns and what should go there: ...then he makes a point of "accidentally" forgetting to add an extra space when he types in the Load Accumulator command (LDA #0) so he can show how the assembler flags it as an error. BUT, he completely ignores the fact that he's left the Clear Carry Flag (CLC) command in the "Label" column (...and he refers to it as the "comments" field several times...). I'm guessing that clearing the carry flag isn't particularly important in this case (...maybe because he starts counting up at zero?) so it doesn't matter... The other thing that seems wrong; he indicates how important it is to end the ASM routine with an "END" statement, which he again puts in the LABEL column, so the word "END" is treated as a label. Is "END" even the right command in this case? I run it through the debugger as a trace as entered, and I see that the final command executed is "BRK'. So just for fun, I tried different values in the label field of the final command. It turns out, the program ends exactly the same way with whatever label I stick in there: It also ends without error with a "BRK" command, either as a label or as an opcode: Am I getting all of this right? I really don't want to trash this guy because he has several videos and I have found them very helpful. And it's pretty cool that he's demonstrating everything using an actual 130XE and the actual Assembler/Editor cartridge. I would just like some confirmation as I learn about new things that I'm understanding these things correctly. Thanks! Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 29, 2020 Share Posted May 29, 2020 .END isn't really needed, I never used it in the day. But it can be handy to do a partial assembly. One space then opcode is bad and can go unnoticed to produce a buggy program but if you do it twice on a given operation you'd get a duplicate label error. BRK required, yes, and it's possible to get a program that crashes if you assemble into populated Ram. Easy to do if your program shrinks from doing code optimization. Not allowing RTS is an annoying bug. Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 29, 2020 Share Posted May 29, 2020 He's wrong. CLC is generally required, -unless- you already know the state of the flag when doing some shortcut. In general use, and certainly for instructional purposes, you would always start the addition process with CLC. He's wrong about the END label. Generally, Atari assemblers don't require an END directive, and if one did it would be something like 50 .END where END is not a label but a directive and usually preceded with a period, but that is entirely assembler dependent. You'd have to read the particular assembler's manual to see if a .END directive is required. EASMD and ASM/ED don't, nor does MAC/65. Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 29, 2020 Share Posted May 29, 2020 Just now, Rybags said: One space then opcode is bad and can go unnoticed to produce a buggy program In order to save space, Hume wrote all of the Six Forks stuff with only one space in front of the mnemonic if there was no label on that line. With all the dense commentary and semicolons everywhere it was often frustrating to find a typo because I got so used to not "seeing" that first space. So now whenever I make changes to his stuff, I pad the damn thing over to column 10 like IBM intended, lol. Quote Link to comment Share on other sites More sharing options...
almightytodd Posted May 29, 2020 Share Posted May 29, 2020 Isn't it a better practice to have labels on a line by themselves? It looks odd to me to have a label followed by commands and operands... ...just sayin' Quote Link to comment Share on other sites More sharing options...
Alfred Posted May 29, 2020 Share Posted May 29, 2020 2 minutes ago, almightytodd said: Isn't it a better practice to have labels on a line by themselves? It looks odd to me to have a label followed by commands and operands... ...just sayin' It's mostly a matter of personal taste. I don't isolate labels so as to save space. In the Six Forks code the author does this MYLABEL = * to make it stand out. Me, I want to pack everything in to a small space to cut down on the typing. In the line assemblers like Mac/65 it costs you what, 5 bytes for a line (the line # plus offset etc) which doesn't sound like much but in a big program like say Basic XE, all of those empty label lines would add up to something significant. Quote Link to comment Share on other sites More sharing options...
Preppie Posted May 29, 2020 Share Posted May 29, 2020 I guess it depends which assembler your using. I usualy just type in notepad++ and copy/paste into https://www.masswerk.at/6502/assembler.html This doesn't use line numbers, and spacing isn't an issue as it figures out what's a label and what's an opcode etc. Off course, this isn't an option if you're on an actual atari but if your on an atari then try and get something better than the atari cart. Quote Link to comment Share on other sites More sharing options...
Rybags Posted May 29, 2020 Share Posted May 29, 2020 Label on it's own is preferable especially when having to insert new bits of code. But... the Atari AsmEd's other fatal weakness is that there's no tokenization so if memory gets tight, we'd often resort to stacked label + instruction and minimal commentary. Quote Link to comment Share on other sites More sharing options...
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.