[Coco] CoCo 2 16k.. Upgrade or no?
lost at l-w.ca
Wed Mar 14 17:44:02 EDT 2012
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.)
More information about the Coco