[Coco] A question about the BASIC statement CLEAR

[William Astle]

I just verified my understanding of what's going on against Unravelled.

There needs to be one byte of RAM above string space in order for VAL() 
to work properly if it happens to be called on the string that occupies 
the very top of string space. That's actually why MEM returns 1 byte 
more on a Coco 3 than it does on an equivalent configuration for a Coco 
1 or 2 - because the Coco 3 is running RAM mode so it can align string 
space all the way at the top of free memory.

The Color Basic ROM sets the "top of RAM" to 7FFE (for 32K) as a result 
of its startup memory test. (It looks like an off by one error in the 
testing but it turns out to be intentional.) The Coco 3 patch to the 
startup sequences sets it to 7FFF.

The CLEAR command subtracts 1 from the argument given so CLEAR200,&H8000 
is the same as having the top of memory set to 7FFF.

When VAL runs, it temporarily saves the byte that follows the string 
data, sets that byte to zero, calls the regular number parser, then 
restores the original byte. This can fail if the number parser throws an 
error (Overflow and Syntax Error are both known to be possible). If that 
happens, the byte doesn't get restored and you end up corrupted the byte 
of memory following the string. Note that that could even by the Basic 
program itself if the string was a constant in the program.

Note that the VAL thing could also be a problem if your program is 
running an interrupt handler that might fire while VAL is running. An 
admittedly unlikely scenario, but possible.

So, it is safest to leave the extra byte just in case. However, 
technically speaking, if you need to put your machine code at &H7000, 
then you can actually pass &H7000 to CLEAR. However, if you want to 
restore the original state of the machine, you need to do 
CLEAR200,&H7FFF on a Coco1/2 and CLEAR200,&H8000 on a Coco 3.

Anyway, I suspect there's an element of cargo cult copying going on, but 
it turns out what most of us have been doing is actually the safest 
practice.

On 2024-11-03 20:18, Arthur Flexser via Coco wrote:
> Actually, Ciaran, your message caused me to think more about this, and now I'm not completely certain about the extra byte.  It's been almost 40 years since I've done any CoCo programming.  Somebody should check the ROM code to find the definitive answer.
> 
> Art
> ________________________________
> From: Coco <coco-bounces at maltedmedia.com> on behalf of Ciaran Anscomb via Coco <coco at maltedmedia.com>
> Sent: Sunday, November 3, 2024 2:40 AM
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Cc: Ciaran Anscomb <cocomalt at 6809.org.uk>
> Subject: Re: [Coco] A question about the BASIC statement CLEAR
> 
> Note: This message originated from outside the FIU Faculty/Staff email system.
> 
> 
> Arthur Flexser via Coco wrote:
>> You don't need to allow an extra byte.  CLEAR 200, &H7000 means your ML
>> routine can safely start at $7000.  Below that will be 200 bytes allotted to
>> string space and below that is the stack.
> 
> Wow.  That's a _lot_ of years I've gone assuming you did have to set it
> one byte lower, and never really questioning it.
> 
> ..ciaran
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://urldefense.com/v3/__https://pairlist5.pair.net/mailman/listinfo/coco__;!!FjuHKAHQs5udqho!Kb_6XtXh23w7NSohax4Rz13sgFsq22VYrsIzsNnk1dVCF8Ow07HgPn9hJJ87H7_VsgwzlAkY79swJaI$
> 


-- 
William Astle