0
As we've discovered, DASM keeps a list of all symbols and as it is assembling our code, it assigns values (= numbers, or addresses) to those symbols. When it is creating the binary ROM image, it replaces opcodes (=instructions) with appropriate values representing the opcode, and it replaces symbols with the value of the symbol from its internal symbol table.
OK, that basic process should be clear by now. When we view our symbol table (which is output when we use the -v5 switch on our command-line when assembling a file), we will see that there are some symbols which are unused (the used ones have (R ) after them, in the symbol table output). We can see, then, that it is not necessary for a symbol to actually be in the ROM binary file for it to have a value. There are several reasons why we'd want to have a symbol with a value, but not have that symbol "do anything" or relate to anything in the binary.
For example, we could use a symbol as a switch to tell the compiler which section of code to compile. A symbol could be used as a value to tell us how many scanlines to draw... eg:
SCANLINES = 312; PAL ;...later iny cpy #SCANLINES ; at the end? bne AnotherLine ; do another line
We can even implement a compile-time PAL/NTSC switch something like this...
PAL = 0 NTSC = 1 SYSTEM = PAL ; change this to PAL or NTSC #if SYSTEM = PAL ; insert PAL-only code here #endif #if SYSTEM = NTSC ; insert NTSC-only code here #endif
This sort of use of symbols to drive the DASM assembly process can be quite useful when you want various sections of code to behave differently - for whatever reason. You might have a test bit of code which you can conditionally compile by defining a symbol as in the above example.
Now that we're comfortable with DASM's use of symbols as part of the compilation process, let's have a look at how we've been managing our RAM so far...
VARIABLE = $80 ; variable using the 1st byte of RAM VAR2 = $81 ; another variable using the 2nd byte of RAM VAR3 = $82 ;etc
That's perfectly fine - and as we already know, lines like this will add the symbols to DASM's internal symbol table, and whenever DASM sees those symbols it will instead use the associated value. Consider the following example...
VARIABLE = $80 ; variable using 1st TWO bytes of RAM VAR2 = $82 ; another variable must start after the 1st var's space
In this case we've created a 2-byte variable starting at the beginning of RAM. So the second variable has to start at $82 instead of $81 - because the first variable requires locations $80 and $81. The above will work fine - but there's no clear correspondence between the variable declaration (which is really just assigning a number/address to a symbol) and the amount of space required for the variable. Furthermore, if we later decided that we really needed 4 bytes (instead of 2) for VARIABLE, then we'd have to "shift down" all following variables - that is, VAR2 would have to be changed to $84, etc.. This is not only extremely annoying and time-consuming, it is a disaster waiting to happen - because you humans are fallible.
What we really want to do is let DASM manage the calculation of the variable/symbol addresses, and simply say "here's a variable, and it's this big". And fortunately, we can do that.
First, let's consider "normal code"
ORG $8000 LABEL1 .byte 1,34,12,3 LABEL2 .byte 0
When assembled, DASM will assign $8000 as the value of the symbol LABEL1, and $8004 as the value of the symbol LABEL2 (that is, it assembles the code, and starting at location $8000 (which is also the value of LABEL1) we will see 4 bytes (1, 34, 12, 3) and then another byte (0) which is at $8004 - the value of the symbol LABEL2.
Note, the ".byte" instruction (actually it's called a pseudo-op, as it's an instruction to the assembler, not an actual 6502 instruction) is just a way of telling DASM to put particular byte values in the ROM at that location.
Remember when we wrote "NOP" to insert a no-operation instruction - which causes the 6502 to execute a 2 cycle delay? When we looked at the listing file, we saw that the NOP was replaced in the ROM image by the value $EA. Well, instead of letting DASM work out what the op-code's value is, we can actually just put that value in ourselves, using a .byte instruction to DASM. Example...
.byte $EA ; a NOP instruction!
Now, this isn't often done - but there are extremely rare cases where you might want to do this (typically with extremely obscure and highly godlike optimisations). We won't worry about that for now. But it's important to understand that just like DASM - which simply replaces a list of instructions with their values, we can just as easily do the same thing and put the values there ourselves.
Now it's easy to see how DASM gets its values for the labels from the address of the data it is currently assembling - in the earlier example, we started assembly (the ORG pseudo-op) at $8000, and then DASM encountered the label LAB1 - which was given the value $8000, etc. We then inserted 4 bytes with the ".byte" pseudo-op. Instead of ".byte" which places specific values into the output binary file, we could have used the "ds" pseudo-op - which stands for "define space". For example, the following would give the same two addresses to LAB1 and LAB2 as the above example, but the data put into the binary would differ...
ORG $8000 LAB1 ds 4 LAB2 ds 1
Typically, the "ds" pseudo-op will place 0's in the ROM - as many bytes as specified in the value after the "ds". In the above example, we'll see 4 0's starting at $8000 followed by another at $8004.
Now let's consider our RAM... which starts at $80. What would we have if we did something like this...?
ORG $80 ; start of RAM VARIABLE ds 3 ; define 3 bytes of space for this variable VAR2 ds 1 ; define 1 byte of space for this one VAR3 ds 2 ; define 2 etc..
Now that's much nicer, isn't it! It won't work, though
The problem is, DASM will quite happily assemble this - and it will correctly assign values $80 to VARIABLE, $83 to VAR2 and $84 to VAR3 - but it will ALSO generate a binary ROM image containing data at locations $80-$85. That's RAM, not ROM - and it most definitely doesn't belong in a ROM binary. In fact, our ROM would now also be HUGE - because DASM would figure that it needs to create an image from location $80 - $FFFF (ie: it will be about 64K, not 4K).What we need to do is tell DASM that we're really just using this code-writing-style to calculate the values of the symbols, and not actually creating binary data for our ROM. And we can do that. Let's plunge right in...
SEG.U variables ORG $80 VARIABLE ds 3 ; define 3 bytes of space for this variable VAR2 ds 1 ; define 1 byte of space for this one VAR3 ds 2 ; define 2 etc..
The addition is the "SEG.U" pseudo-op, followed by a segment name. This is telling DASM that all the following code (until a next "SEG" pseudo-op is encountered) is an uninitialised segment. When it encounters a "segment" defined like this, DASM will not generate actual binary data in the ROM - but it will still correctly calculate the address data for the symbols.
Note: It is important to give the segment a name (though this parameter is optional, you should choose a unique name for each segment). Naming segments assists the assembler in keeping track of exactly which parts of your code are initialised and uninitialised.
If you now go back and have a close look at the vcs.h file, you may begin to understand exactly how the values for all of the TIA registers are actually defined/calculated. Yes, they're defined as an uninitialised segment starting at a specific location. Typically this start-location is 0, and each register is assigned one byte. We keep the register symbols in the correct order and let DASM work out the addresses for us. There's a reason for this - to do with bankswitching cartrige formats - but the general lesson here is that it's nice to let DASM do the work for us - particularly when defining variables - and let it worry about the actual addresses of stuff - we just tell it the size.
One final word on the SEG pseudo-op. Though it is not strictly necessary, all of our code uses it. Without the .U extension, SEG will create binary data for our ROM. With the .U, SEG just allows DASM to populate its symbol table with names/values.
So from now on, let's define variables "the proper way". We'll use an uninitialised segment starting at $80, and give each variable a size using the "ds" pseudo-op. And don't forget after our variable definitions to place another "SEG" which will effectively tell DASM to start generating binary ROM data. Here's an example...
SEG.U vars ; the label "vars" will appear in our symbol table's segment list ORG $80 ; start of RAM Variable ds 1 ; a 1-byte variable SEG ; end of uninitialised segment - start of ROM binary ORG $F000 ; code....
That will do nicely for this session - see you next time!
