Smarter Variable Labels
You'd like to label a bunch of RAM variables without worrying about
what memory location they're at.
Put the variables in an unitialized segment and specify the number of bytes
each label refers to using the "ds" ("define space") pseudo-op in DASM.
Historically, it wasn't uncommon to see code like the following
for labeling RAM:
SomeVariableName = $80
TwoByteVariableName = $81
YetAnotherVariable = $83
This gets the job done, but it's clearly not very flexible.
It isn't easy to add or delete variables except at the "end of the list",
and you don't know how many bytes a variable is meant to be (the list could
be out of order, or a previously used label could be deleted, etc etc.)
Andrew Davie would suggest this equivalent code:
SomeVariableName ds 1
TwoByteVariableName ds 2
YetAnotherVariable ds 1
"SEG.U" is an instruction to DASM telling it to create an "unitialized segment",
so it can make labels and what not, but won't try to create the same space when
you build your ROM. ("VARS" and "CODE" are just labels.) The number following "ds"
is how many bytes to reserve.
There's only one possible drawback...you could be running out of RAM and not
realize it! An easy solution to that was explained to me by Dennis Debro. Simply
add this line before the "SEG CODE"
echo "----",($100 - *) , "bytes of RAM left"
This will make DASM print how many bytes of RAM you have left (in hex).
The only drawback is that it will print that once per DASM pass, so you'll
probably see it twice during the assembly, but that's a minor issue.
Section 16 of Andrew Davie's Programming for Newbies forum,
Letting the Assembler do the Work,
covers this in great detail, along with a similar concept called "overlays" for
using different variables names for the same memory location.
See pretty much any of the longer code examples in the 2600 Cookbook.
Back to 2600 Cookbook