Any "zero page aware" assemblers for the 65c02?

[scotws]

As discussed in the Forth form, Tali Forth needs to switch to a different assembler because we've moved beyond what Ophis (which has served us very well) was built to do. Now what would really be cool is an assembler that is at least aware of the zero page, or, even better, helps populate it. Another problem is that Tali is being installed together with other software which already uses the ZP, so it's getting complicated to figure out what can be used.

Ideally, you could tell the assembler not to use certain parts of the ZP, maybe with something like

Code: Select all

.reserve $00

or

Code: Select all

.reserve $00 to $10

In your own code, you request zero page bytes when you need them -

Code: Select all

.savezero counter 2

for example. The assembler manages the zero page space by allocating storage, here maybe by automatically putting counter at $0A and $0B. It produces a warning if too much is requested. The programmer doesn't have to remember if the counter was in $0A or $OC, it's all just variables in the code.

(Actually, because I'm lazy and error prone, I'd prefer to mark zero page variables themselves somehow, maybe with a &. Then I could just say

Code: Select all

.save &counter 2

sta &counter
inc &counter

and whatnot.)

I'm having trouble believing this would be too hard to implement, given that the zero page can be seen as a collection of registers and there is a ton of research on register allocation for compilers. It's a little trickier of course because in some cases we'll need to allocate blocks of zero page (like the data stock for Tali Forth). Though on the other hand, it's going to be rare that something needs to be "evicted".

Sorry if I've missed it as some obvious feature, but does any assembler for the 6502 have this functionality?

[drogon]

scotws wrote:

As discussed in the Forth form, Tali Forth needs to switch to a different assembler because we've moved beyond what Ophis (which has served us very well) was built to do. Now what would really be cool is an assembler that is at least aware of the zero page, or, even better, helps populate it. Another problem is that Tali is being installed together with other software which already uses the ZP, so it's getting complicated to figure out what can be used.

When I looked at Tali, I used ca65 to assemble it. I don't recall having any significant issues. (Might have had to tell it to use labels without colons, but I don't recall)

So I think ca65 will do everything you want. One way is to use segments for ZP stuff, so:

Code: Select all

.zeropage
foobar: .res 1
.code
    lda foobar

and so on.

I'm fairly sure it can do the rest you want, but a good look at the manual might be wise.

Cheers,

-Gordon

[BitWise]

What platform do you want the assembler to run on?

[cjs]

Have you looked at writing macros to do what you need? For example, I use the following in the Macroassembler AS, allowing me to use foo zds 2 anywhere to reserve two bytes labeled foo at the next two free locations in the zero page.

Code: Select all

;   By default we reserve the first 16 bytes of the zero page for use
;   by "system" things external to the program, such as the BIOS, 6510
;   PIO registers, etc. However, this can be changed later by the
;   including program.
__ZDS_loc   set $10

zds         macro len,{INTLABEL},{NOEXPAND}
__ZDS_save  set *
            org __ZDS_loc
__LABEL__   label *
            rmb len
            org __ZDS_save
__ZDS_loc   set __ZDS_loc+len
            endm

I've not bothered to implement a check for overflow, yet, but it's on my list of things to do.

[GARTHWILSON]

I used the 2500AD assembler in the 1980's which had the .PAGE0 directive, but I don't know how that's any different from just saying ORG 0 (or start with ORG $0A or whatever you want), except maybe it would tell you if you overflowed the ZP area. (ORG is of course short for "origin.") I don't have a full manual on it here, only the quick-reference guide. I've been using the C32 assembler since then, where I would either to the ORG thing, or, if I didn't want to declare all the variables up front, do it with a macro like cjs says, and even give a warning if you run out of ZP space. You can use ORG as many times as you want in the code, to move around, skip portions of the memory map, even move backwards (which I do a lot in my program flow-control structure macros to go back and fill in branch operands when the target addresses are found, then go forward again to resume normal assembly. Links to C32 and and lots of other assemblers are in the assemblers section of my links page, at http://wilsonminesco.com/links.html#assem . After we were using the 2500AD assembler at work, it was taken over by Avocet (who was initially a competitor) and then they eventually dropped support for it.

[cjs]

Oh, I should mention the ASxxxx set of assemblers (for which I have personal notes here), which has the concept of a "direct page" built in. You declare an "area" (which might be more usually called a "section" in other systems) with whatever name you like, marking it as direct and absolute, and any data or code you put in that area will be linked into a single page, with a warning from the linker if the sum of all data/code in that section is longer than 256 bytes. Here's some example code taken from my test code for AS6502:

Code: Select all

            ;   Zero page area, allowing us to interleave zero-page and
            ;   code segment allocations.
            .area   ZP  (abs,pag)
            .org    80               ; allocated area starts 80 bytes in
...
;--------------------------------------------------------------------------
;   bsread: A source stream of bytes
;   Preserves X and Y. Each call returns in A the next byte from [bytesource],
;   incrementing bytesource after.  This is a bit awkward; if we were worried
;   about efficiency we'd read from [bytesource+1], among other things.

bsread:     sty     *bs_ysave
            ldy     #0
            lda     [*bytesource],y
            pha
            ldy     *bs_ysave
            inc     *bytesource
            bne     1$
            inc     *bytesource+1
1$:         pla
            rts

            .area   ZP
bytesource: .ds     2       ; pointer to bytes to read
bs_ysave:   .ds     1       ; temp storage for Y register
            .area   CODE

This doesn't actually do anything that can't be done with macros in a good macro assembler, with the exception that this system supports linking and so lets you separately assemble files and later let the linker determine exactly where zero page addresses will be assigned and whether or not the zero page overflowed.

I started out using this system, but at the moment I'm feeling that it's better just to do full-program assembly instead, so I now use Macroassembler AS, as described in my post earlier in this thread.

[scotws]

Thanks for all the help! The idea is to make it easy enough for people to port Tali to their hardware, something I hadn't given that much thought to when I started out (actually, I didn't think a lot of things through. There is a lesson here), so something that runs at least on Linux and Windows is the target.

While I've been fooling around in this forum, Sam has actually sat down and created two versions of Tali Forth with cc65 (https://github.com/SamCoVT/TaliForth2/t ... grify/cc65) and 64tass (https://github.com/SamCoVT/TaliForth2/t ... ify/64tass) for comparison. Their not optimized yet - for instance, they use the .text directive for strings and not the specialized versions .ptext and .null for counted strings and zero-terminated strings with tass. Note that cc65 needs a configuration file, which defines the zero page. This might be what we're looking for.

(I wonder if it would be worth it to create an actual IDE for programming with the 6502, something like the big kids have for languages like Python or Jave. It doesn't have to be eclipse, but it would be nice to have something that interactively checks for branch distances, typos and whatnot. It's not like the resource use would break a machine ...)

[Martin_H]

@Scotws, have you read how Ophis data and code segments work? It can be really handy to modularize code, while allowing each module to allocate space in zero page, a separate data segment, and code segments. In one module you define the data segments like this:

Code: Select all

; -----------------------------------------------------------------------------
; Declaration of data segments and their origins used by the interpreter.
; For example zero page definitions require defining the program section
; origins before any use. So placing them here ensures no conflict
; Martin Heermance <mheermance@gmail.com>
; -----------------------------------------------------------------------------

.data ZPSTACK
.org $0000		; make stack at bottom of ZP.

.data ZPDATA
.org $008A		; start a few bytes after ZPSTACK as a guard.

.data BSS
.org $0300		; page 3 is used for uninitialized data.

.text

Then in another module you refer to specific data segments to allocate space like this.

Code: Select all

;
; Data segments
;
.data ZPDATA
.space _STDOUT	2	; pointer to console output routine.
.space _STDIN	2	; pointer to console input routine.
.space _TMPPTR1	2	; working pointer

.data BSS
.space _tib	$50	; a line buffer for buffered reads.
.space _tibEnd	$00	; end marker to compute buffer size.
.space _writeIdx $01	; current write position in the buffer.
.space _readIdx	$01	; current read position in the buffer.
.space _echo	$01	; control echo during line edit mode.

.text

Each data and code segment maintains a separate PC, so you can switch between them in another module to allocate more space.

The nice thing about Ophis is there's no linker to deal with. Instead you have a main file that includes all the modules. I use this technique extensively in my Lisp65 project I'm working on:
https://github.com/Martin-H1/Lisp65