Atari 2600 Programming for Newbies

.byte

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 optimizations). 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.

ds (Define Space)

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

    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 uninitialized 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 initialized and uninitialized.

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 uninitialized 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 cartridge 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 uninitialized 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 uninitialized segment - start of ROM binary

    ORG $F000
; code....

    ; This overlay variable is used for the overlay variables. That's OK.

    ; However, it is positioned at the END of the variables so, if on the

    ; off chance we're overlapping stack space and variable, it is LIKELY
    
    ; that won't be a problem, as the temp variables (especially the
    
    ; latter ones) are only used in rare occasions.



    ; FOR SAFETY, DO NOT USE THIS AREA DIRECTLY (ie: NEVER reference
    
    ; 'Overlay' in the code). ADD AN OVERLAY FOR EACH
    
    ; ROUTINE'S USE, SO CLASHES CAN BE EASILY CHECKED.


Overlay    ds 0;   ; --> overlay (share) variables
                   ; (make sure this is as big as the biggest overlay
                   ; subsection)




;----------------------------------------------------------------------------
;
; OVERLAYS!

; These variables are overlays, and should be managed with care. That is,
; variables are ALREADY DEFINED, and we're reusing RAM for other purposes.


; EACH OF THESE ARE VARIABLES (TEMPORARY) USED BY ONE ROUTINE (AND IT'S
; SUBROUTINES) THAT IS, LOCAL VARIABLES. USE 'EM FREELY, THEY COST NOTHING.


; TOTAL SPACE USED BY ANY OVERLAY GROUP SHOULD BE <= SIZE OF 'Overlay'


;----------------------------------------------------------------------------



                org Overlay



   ; ANIMATION/LOGIC SYSTEM

   ; place variables here


;----------------------------------------------------------------------------



                org Overlay



   ; DRAWING SYSTEM

   ; place variables here



   ; etc