Local Variables
![t2-203d-start](images/t2-203d-start.png)
Let's move on to the code at $203D. It starts by storing a couple of values into direct page address $02/03. This appears to be setting up a pointer to $2063, which is a data area inside the file. So let's make it official.
![t2-203d-edit1](images/t2-203d-edit1.png)
Select the line at address $2063, and use Actions > Edit Label to give it the label "XDATA?". The question mark on the end is there to remind us that we're not entirely sure what this is. Now edit the operand on line $203D, and set it to the symbol "XDATA", with the part "low". The question mark isn't really part of the label, so you don't need to type it here.
![t2-203d-after-edit2](images/t2-203d-after-edit2.png)
Edit the operand on line $2041,
and set it to "XDATA" with the part "high". (The symbol text box
gets focus immediately, so you can start typing the symbol name as soon
as the dialog opens; you don't need to click around first.) If all
went well, the operands should now read LDA #<XDATA?
and LDA #>XDATA?
.
![t2-create-ptr-entry](images/t2-create-ptr-entry.png)
Let's give the pointer a name. Select line $203D, and use Actions > Create Local Variable Table to create an empty table. Click New Symbol on the right side. Leave the Address button selected. Set the Label field to "PTR1", the Value field to "$02", and the width to "2" (it's a 2-byte pointer). Click "OK" to create the entry, and then "OK" to update the table.
![t2-after-ptr-entry](images/t2-after-ptr-entry.png)
There's now a .VAR
statement
(similar to a .EQU
) above line $203D,
and the stores to $02/$03 have changed to
"PTR1" and "PTR1+1".
![t2-20a7](images/t2-20a7.png)
Double-click on the JSR
opcode on line $2045 to jump to
L20A7.
The code here just loads a value from $3000 into the accumulator
and returns, so not much to see here. Hit the back-arrow in the
toolbar to jump back to the JSR
.
![t2-2048](images/t2-2048.png)
The next bit of code masks the accumulator so it holds a value between
0 and 3, then doubles it and uses it as an index into PTR1
.
We know PTR1
points to XDATA
,
which looks like it has some 16-bit addresses. The
values loaded are stored in two more zero-page locations, $04-05.
Let's make these a pointer as well.
![t2-204e-lv](images/t2-204e-lv.png)
Double-click the operand on line $204E ("$04"),
and click Create Local Variable. Set the Label
to "PTR2" and the width to 2. Click OK
to create the symbol, then OK
to close the operand editor, which should still be set to Default format --
we didn't actually edit the operand, we just used the operand edit
dialog as a convenient way to create a local variable table entry. All
accesses to $04/$05 now use PTR2
, and there's a new entry in the local
variable table we created earlier.
![t2-2055](images/t2-2055.png)
The next section of code, at $2055, copies bytes from PTR2
to $0400, stopping when it hits a zero byte.
It looks like this is copying null-terminated strings.
![t2-fmt-xdata](images/t2-fmt-xdata.png)
This confirms our idea that XDATA
holds 16-bit addresses,
so let's format it. Select lines $2063 to $2066, and
Actions > Edit Operand.
The editor window should say "8 bytes selected" at the top.
Click the 16-bit words, little-endian radio button,
and then in the Display As box, click Address.
Click OK.
![t2-fmt-xdata-done](images/t2-fmt-xdata-done.png)
The values at XDATA
should now be four
.DD2
16-bit addresses.
If you scroll up, you'll see that the .ZSTR
strings
near the top now have labels that match the operands in XDATA
.
Now that we know what XDATA
holds, let's rename it.
Change the label to STRADDR. The symbol parts in the
operands at $203D and $2041 update automatically.
![t2-enable-counts](images/t2-enable-counts.png)
Let's take a quick look at the cycle-count feature. Use Edit > Settings to open the app settings panel. In the Miscellaneous group on the right side, click the Show cycle counts for instructions checkbox, then click OK. (There's also a toolbar button for this.)
![t2-show-cycle-counts](images/t2-show-cycle-counts.png)
Every line with an instruction now has a cycle count on it. The cycle
counts are adjusted for everything SourceGen can figure out. For example,
the BEQ
on line $205A shows "2+" cycles, meaning that
it takes at least two cycles but might take more. That's because
conditional branches take an
extra cycle if the branch is taken. The BNE
on line
$2061 shows 3 cycles, because we know that the branch is always
taken and doesn't cross a page boundary.
(If you want to see why it's always taken,
look at the value of the 'Z' flag in the "flags" column, which indicates
the state of the flags before the instruction on that line is executed.
Lower-case 'z' means the zero-flag is clear (0), upper-case 'Z' means it's
set (1). The analyzer determined that the flag was clear for instructions
following the BEQ
because we're on the branch-not-taken path.
The following instruction, ORA #$80
, cleared the 'Z' flag and
set the 'N' flag, so a BMI
would also be an always-taken branch.)
The cycle-count comments can be added to generated source code as well.
If you add an end-of-line comment, it appears after the cycle count. (Try it.)