[Coco] DEF USR and strings?
Sean Conner
sean at conman.org
Wed Oct 29 23:49:27 EDT 2025
It was thus said that the Great Allen Huffman via Coco once stated:
> > On Oct 29, 2025, at 8:52 PM, Sean Conner via Coco <coco at maltedmedia.com> wrote:
> >
> > It was thus said that the Great Bruce Borer once stated:
> >> I do not know what can and cannot be done (yet) but can you pass the
> >> address (number) of the string and use the pointer in USRn to do what you
> >> want?
> >
> > Is the page I linked to:
> >
> > https://boston.conman.org/2024/11/26.2-3
> >
> > not clear enough? It goes into extensive detail.
> >
> > -spc
>
> This is excellent.
>
> The sad thing is, I’ve seen this page before, but was not working on
> anything so I didn’t dive too deep.
>
> Your research into these ROM routines is interesting. It sure makes things
> easy for you to do stuff like:
>
> 110 X$ = USR0("ABCXYZ")
> 120 PRINT X$
>
> I am surprised at how little code is needed thanks to those ROM routines
> already existing.
Not only that, but the registers upon calling USRn (ECB) are (from my
notes):
USRn Entry point to user-callable machine language subroutine
Entry: A - 0 if paramater in FP0 is a number
- 255 if parameter in FP0 is a string descriptor
B - length if string descriptor
X - FP0EXP if A=0
- string descriptor if A=255
Zf - 1 if A = 0
- 0 if A = 255
Zn - 1 if A = 255
- 0 if A = 0
FP0 + _STRPTR - string descriptor if A=$FF
VALTYP - same as A
Note: ECB/DECB allow returning a string value.
Changing the characters of the string pointer is undefined; changing
the contents of the string descriptor is allowed.
Because the flags reflect the value in A, there's no need to CMPA or TSTA
before jumping if supporting both a string or numeric input. Also, INTCVT
does a type check, so calls to CHKNUM (a name I came up with) isn't required
if calling INTCVT.
USR (from Color BASIC) doesn't set the registers with any meaningful
values, just FYI.
-spc
More information about the Coco
mailing list