5

I'm trying to define a section of data in a program. The Apple 6502 Assembler/Editor mentions an assembler directive called "DSECT" but I can't tell if I'm using it correctly or not. Here is an example program I created to test if it would work:

1 * Test of DSECT *
2     ORG $800
3     DSECT
4     ORG $1000
5     DFB $C1 ;HEXCODE OF "A"
6     DEND
7     LDA $1000
8     JSR $FDED ;CALL COUT

I thought that I would get an out of "A", but I just get a random letter instead. I haven't seen much online or in the books I have about the DSECT command, so my question is: How do I properly use DSECT?

Improve this question

1 Answer 1

Reset to default
11

To quote the description of your link (emphasis mine):

The DSECT directive is used to define an area of memory [...] without actually generating any output object code. [...] The most common use [...] is to define the labels [...] that occur in the [...] page zero.

So the reason why you do not get an "A" is that your DSECT doesn't produce any assembly output at $1000. However, you could use it to define labels for (uninitialized) variables at $1000 and following addresses (untested):

        DSECT
        ORG $1000 
VAR1    DS 1        ; byte at $1000
VAR2    DS 2        ; word at $1001
VAR3    DS 1        ; byte at $1003
        DEND

        ORG $800
        LDA #$00
        STA VAR1
        ...
        LDA VAR1
        ...

The advantage is that you don't have to care about absolute addresses. You just list your variables and let the assembler figure it out, and you can insert variables anywhere without having to edit your whole assembly program every time.

And if you are taking over the zero-page, you want to place quite a few of your variables there, so then you use a DSECT without ORG.

(This approach doesn't work if you want to use ROM routines, because ROM zero page on the Apple II is all over the place, so you need to pick them carefully).

Improve this answer
8
  • I would add: the alternative is to do it explicitly with a bunch of EQU statements, but that's less clear and harder to maintain. For an example of the same feature in another Apple II assembler, see DUM in Merlin.
    – fadden
    Oct 2, 2021 at 14:55
  • 1
    Not so sure what to make of the comment about ROM routines and what a ROM ZP is supposed to be. In either case, DSECTs are the way to go, even with rather simple assemblers like that one - and it's quite enjoyable with more capable ones.
    – Raffzahn
    Oct 2, 2021 at 18:52
  • 1
    @Raffzahn, dirkt is saying the ROM uses many ZP locations, complicating the definition of the DSECT, and decreasing its usefulness.
    – Nick Westgate
    Oct 3, 2021 at 2:25
  • 1
    @NickWestgate That doesn't make any sense. Maybe he can shed some light.
    – Raffzahn
    Oct 3, 2021 at 2:32
  • @Raffzahn Apple ROM routines use lot of non-continuous zero page locations. So you cannot do a DSECT declaration like in my example and expect the automatic address assignment not to overlap with zero page locations that the ROM uses. Instead, you'd pick particular zero page locations that are known to be "good for use" (and that are scattered all over the place) and assign labels with EQU to those locations. You can do that inside a DSECT as well, of course.
    – dirkt
    Oct 3, 2021 at 4:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .