[Coco] CoCo 2 16k.. Upgrade or no?

[William Astle]

On 12-03-14 03:01 PM, Arthur Flexser wrote:
> Thanks for the additional details.
>
> Actually, those 1 or 2 extra bytes at the top of memory (in a CoCo 3
> and a CoCo 1/2, respectively) aren't wasted, but are necessary for the
> "&H" function to work properly.  (The fact that the CoCo 3 typically
> runs in all-RAM mode allowed one extra byte to be reclaimed.)  If I'm
> recalling correctly:  if you go to ROM mode from a cold start in a
> CoCo 3 (POKE&HFFDE,0) and then try, say, PRINT&H5, you'll get a
> result of 94!  (The same should occur if, on a 32/64K
> CoCo 1/2, you type CLEAR 200,&H7FFF (moving the top of string space
> up one byte) and then try PRINT&H5.)
>
> 94 is the value of&H5E, because the ascii "E" at $8000 (part of the
> 'EX' that begins the Extended Basic ROM) gets erroneously included
> with the 5 when&H5 is evaluated.  That's due to the fact that the
> function attempts to use an extra byte at the top of the string area
> as scratch storage but the byte at $8000 can't be changed because it
> is ROM.

A review of the &H (and &O) parsing code in the Extended Basic ROM shows 
absolutely no access to high memory. If uses one of the floating point 
accumulators in the direct page to do all its scratch work. The usual 
"fetch next character" routine at $9F is used to fetch input characters. 
Thus there is no possible way the "E" at $8000 can possibly be included 
in the conversion result when parsing a line.

That said, the VAL() function does monkey with the byte following the 
last byte of a string so if the string happens to be at the top of 
string space and does not contain a NUL byte, and the top of string 
space just happens to be $7FFF, it means you end up running into the "E" 
at $8000 in ROM mode. This is only an issue because VAL() uses the usual 
numeric conversion routine in the ROM and that expects to see a NUL byte 
at the end of the string. I can duplicate the &H5 thing above only when 
using VAL("&H5"). That makes it clear that the "wasted" byte at the top 
of memory (string space) is intentional. (What VAL does is set the byte 
just past the end of the string to NUL, call the conversion routine, and 
then restore the contents of that byte.)

There's still a wasted byte related to setting the top of the stack 
pointer. When it sets S, it should set it to the address of the last 
free byte of RAM plus one rather than to the last free byte of RAM since 
pushing onto the stack is a pre-decrement operation. (In other words, 
the stack pointer should start out pointing to the lowest address byte 
of string space.)