So I have this little routine:



"R0" is a 16bit pseudo-register in ZP. Somewhere in ROM there's an asciiz message constant.



I call the routine like this:



This is works perfectly well. However, for unrelated reasons, my firmware code is starting to get unwieldy, and I thought now would be a good time to implement a ZP data stack like Garth describes and rewrite some of my routines. The ones like _LCD_chrout that just take a byte in .A I will leave alone. But _LCD_strout seemed like a good candidate for reworking, since it takes an address, and is called randomly from all over the place (in addition to using it for output, I also stick it in various places for debugging) which means nothing else can ever use R0, in case a string output call steps on it.

So I'd like to do something like this:



My question is, is there some way to leave the address on the stack while indexing into the string? It seems like I need the equivalent of (STACK,x),y in order to index into the string, and it is not obvious to me how to express that. If I have to pull the address off the stack and into a scratchpad variable it seems like I might as well just keep on using the "pseudo register."



(I have read Garth's page about the magic of inlining parameters, but I'd like to do it this way first, if there is a way.)

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

An "LDA (STACK,x),y" would be an awesome instruction for just the reason you site. When I am using a page zero data stack I tackle this in one of two ways:

I have a page zero location called TMPPTR and pop TOS into it, and then use "LDA (TMPPTR),y" but as you point out, you could just use a known page zero location to pass the argument. But using a data stack avoids slamming that address accidentally elsewhere. This avoids a reentrancy issue which can make for hard to find bugs.

Since string I/O isn't time critical, incrementing the pointer directly on the stack avoids needing to use the Y register or another page zero location. I increment the pointer on the stack directly using a macro called inctos which looks like this:

; increments the TOS value
.macro incTos
inc TOS_LSB,x
bne _over
inc TOS_MSB,x
_over:
.macend

Performance wise this isn't great because indirect Y addressing is much faster, but in some cases I don't think it is a problem.

AH! I'm equally split between "of course, why didn't I think of that, what a dope" and "that's super clever, you are a genius!"

I think that will be fine; this just needs to print out short strings on the LCD, which is already super slow. The added overhead of incrementing a 16-bit pointer will probably be unnoticeable. Thanks!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Second BDD’s response. Although my enhanced soft-core is not in a working state at the moment, I too included a full set of these type of stack-relative instructions in its instruction set. I also included a base-pointer relative mode, where I use X loaded with the value of S at the start of the subroutine, and use sign extension of the 8-bit offset to access local variables (negative offsets from the base pointer) and subroutine parameters (positive offsets from base pointer). Works well with the Pascal compiler that I ported to work with my extended 65C02 processor.

These accesses can be synthesized with the 6502 instruction set, but the stack-pointer relative addressing mode makes complex equation evaluations much easier. My base pointer relative addressing mode also can be synthesized, but it really make passing and using parameters in the stack much easier. Dereferencing pointers and data on the stack is so much faster with these addressing modes that including them in my processor model was well worth the additional hw complexity.

_________________
Michael A.