2600 Cookbook: Smarter Variable Labels

Problem:
You'd like to label a bunch of RAM variables without worrying about what memory location they're at.

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

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

	SEG.U VARS
	ORG $80
SomeVariableName	ds 1
TwoByteVariableName	ds 2
YetAnotherVariable	ds 1
	SEG CODE

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

References:

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.

Example:
See pretty much any of the longer code examples in the 2600 Cookbook.

Back to 2600 Cookbook