Using a "word" data type

[Mike]

Brian,

just to get some facts across:

Isn't that how you declare a constant, not a variable?

When you are working with a symbolic (cross-)assembler, those symbols being assigned to a value are only relevant at assemble time (i.e., when the assembler builds your program), not at run time (i.e. when your assembled program actually runs on the computer).

During assembly, the symbols get replaced by their actual values they have at that exact point and instruction they are referenced. The instruction then derives its operand from that value. If you change the value of a symbol by a re-assignment, all assembled instructions above will reference the value before that change, and all instructions below will reference the updated value. The re-assignment itself does not result in any code - as said above, this is an assemble time only thing.

Finally, the CPU itself knows nothing about symbols. It only sees a stream of instruction operation codes either:

• with implicit addressing - i.e. the operand is implicit from the opcode already -, or
• with 1 following byte - either a 1 byte immediate value, a zero page (base) address, or the offset of a branch instruction -, or
• with 2 following bytes - a 16 bit (base) address.

Machine code does not provide any of the niceties of any higher level (structured) programming language. You will have to tell the machine exactly what it has to do, down to the metal - a mere statement of intent is not sufficient. The 6502 has 151 different instructions, each of them with an exactly defined meaning how it acts on the CPU registers, CPU flags and memory. If you don't know how to express your algorithm in terms of these instructions, you're out of luck. Regardless what programming tools you use.

Greetings,

Michael

[chysn]

Isn't that how you declare a constant, not a variable?

Semantics. A “variable” is a data structure for whose attributes you are fully responsible.

[bkumanchik]

Got it, thanks. That makes sense.

Brian,

just to get some facts across:

Isn't that how you declare a constant, not a variable?

When you are working with a symbolic (cross-)assembler, those symbols being assigned to a value are only relevant at assemble time (i.e., when the assembler builds your program), not at run time (i.e. when your assembled program actually runs on the computer).

During assembly, the symbols get replaced by their actual values they have at that exact point and instruction they are referenced. The instruction then derives its operand from that value. If you change the value of a symbol by a re-assignment, all assembled instructions above will reference the value before that change, and all instructions below will reference the updated value. The re-assignment itself does not result in any code - as said above, this is an assemble time only thing.

Finally, the CPU itself knows nothing about symbols. It only sees a stream of instruction operation codes either:

• with implicit addressing - i.e. the operand is implicit from the opcode already -, or
• with 1 following byte - either a 1 byte immediate value, a zero page (base) address, or the offset of a branch instruction -, or
• with 2 following bytes - a 16 bit (base) address.

Machine code does not provide any of the niceties of any higher level (structured) programming language. You will have to tell the machine exactly what it has to do, down to the metal - a mere statement of intent is not sufficient. The 6502 has 151 different instructions, each of them with an exactly defined meaning how it acts on the CPU registers, CPU flags and memory. If you don't know how to express your algorithm in terms of these instructions, you're out of luck. Regardless what programming tools you use.

Greetings,

Michael

[bkumanchik]

OMG, that made things so much easier, thanks!

Thanks, I'll try that out

clc
ldx #11 ;column (0-21)
ldy #10 ;row (0-22)
jsr $FFF0 ;plot - set cursor position

I've come to appreciate PLOT for various things that don't need optimum speed. It's wonderful simplicity when the alternative is 16-bit math.

But... keep in mind that X and Y registers are reversed from Cartesian (x,y) coordinates. X is the y coordinate (row) and Y is the x coordinate (column). For some reason. And yes, the Programmer's Reference Guide gets this wrong.

[bkumanchik]

I'm going to try this as well as I'm still trying to wrap my head around 6502 assembly and need to understand zeropage indirect addressing, thanks

Mike's point about zeropage indirect addressing is important here, because you're writing things to the screen. You probably plan on moving these things around. If so, you're likely to abandon your original code in favor of using a couple zeropage locations to store a pointer to the location to which you're writing. Such a thing might look like this:

Code: Select all

ptr = $fd    ; The location of the thing (2 bytes)
lda #$00     ; Initialize the low byte of the pointer
sta ptr      ; ,,
lda #$1e     ; Initialize the high byte of the pointer; also consider lda $0288, which adjusts for memory expansion
sta ptr+1    ; ,,
lda #1       ; The character code for A
ldy #0       ; Index (the value added to the address in the next line)
sta (ptr),y  ; Basically, the pointed-at location + Y

It's more code, but you get to manipulate the $fd/$fe pointer to change the position of something. If you use absolute addressing here, you lack flexibility, and you'll get frustrated when it comes to putting things where you want.