[Coco] Surprising find when calling USRn(X)

[Johann Klasek]

On Tue, Nov 05, 2024 at 09:22:13PM -0500, Sean Conner via Coco wrote:

> The assembly subroutine:
> 
> 	GIVBF	equ	$B4F3
> 

Here you should check in A if the expected type is given otherwise
X won't contain a descriptor address at all ...

> 		org	$7F00
> 		lda	,x	; length
> 		ldx	2,x	; actual string
> 		clrb
> 	chksum	addb	,x+
> 		deca
> 		bne	chksum
> 		comb
> 		jmp	GIVBF
> 		end
> 
>   I checked _Getting Started With Extended Color BASIC_ and this is not
> mentioned at all.  In fact, I seem to have found an error in the book.  It
> states:
[..]
> And the following BASIC program:
> 
> 	10 DATA189,179,237,31,1,166,132,174,2,230,132,193,65,37,6,193,90,34,2,202,32,231,128,74,38,239,57
> 	20 CLEAR200,32511:FORA=32512TO32538:READB:POKEA,B:NEXT:DEFUSR0=32512:DEFUSR1=32517
> 	100 X$="HELLO, WORLD!"
> 	110 X=USR0(VARPTR(X$)):PRINT X$
> 	120 X$="NICE TO MEET YOU"
> 	130 Y$=USR1(X$):PRINT Y$
> 
>   If I change line 110 to basically match the documentation:
> 
> 	110 Y$=USR0(VARPTR(X$)):PRINT Y$
> 
> I get
> 
> 	?TM ERROR in 110
> 
>   Line 130 works as is.  Go figure.

The current type is derived from the last expression evaluated. The
expression of the argument is this last expression and determines the
type of the whole expression USRx() which has to match the variable type
of the assignement. The reported "Type Mismatch" is telling this.

For 

> 	110 Y$=USR0(VARPTR(X$)):PRINT Y$

to work the code above has to put a discriptor pointer (maybe a temporary
descriptor on the string descriptor stack) with a string allocated on the
string heap (containing the result) into the ACC0 and set the type to
"string".
Otherwise, the rule applies that the assignment type and argument type are
identical.


Johann K.