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

[Arthur Flexser]

Ah, yes, my hazy memory forgot that the problem occurs with
VAL(&H....) rather than simply &H.  Thanks!

Art

On Wed, Mar 14, 2012 at 5:44 PM, William Astle <lost at l-w.ca> wrote:
> 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.)
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco