Jump to content
IGNORED

Why doesn't this assembly program work?


Recommended Posts

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?

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

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...

Link to comment
Share on other sites

...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:

 

1861826755_ASMCols.thumb.png.cb111d2bb76e71505cc6c933df2a9b9d.png

...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...

 

ASM01.thumb.png.3caee6cded2312121a0d5667bb9617b9.png

 

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:

 

Endings.thumb.png.27fbced0b6514ef242f0cab45b1dc837.png

 

It also ends without error with a "BRK" command, either as a label or as an opcode:

 

Brk.png.edaab42f5fae757af39ea1be761b22d0.png

 

ASM05.thumb.png.a452ecdea15b2142dc63c843a554ce81.png

 

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!

 

 

Link to comment
Share on other sites

.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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...