[Coco] MEMSIZ - PEEK(39)*256+PEEK(40)
Arthur Flexser
flexser at fiu.edu
Fri Jul 15 03:32:47 EDT 2022
You can demonstrate the need for the extra byte on a 32/64K CoCo 1/2 by the following:
Change the top of string space to $7FFF rather than the usual $7FFE by POKE 40, 255:CLEAR, upping the LSB of MEMSIZ by one.
Then try PRINT VAL("&H5") and you get the rather surprising answer of 94! Why 94? Because that's decimal for hex 5E, and the "E" has arisen from the first byte of Extended Basic at $8000.
On a CoCo 3, the top of string space is already at $7FFF, so you just need to put it into ROM/RAM mode with POKE&HFFDE,0 before entering PRINT VAL("&H5") to get the answer of 94.
Art
________________________________
From: Coco <coco-bounces at maltedmedia.com> on behalf of Allen Huffman via Coco <coco at maltedmedia.com>
Sent: Thursday, July 14, 2022 1:25 AM
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Cc: Allen Huffman <alsplace at pobox.com>
Subject: Re: [Coco] MEMSIZ - PEEK(39)*256+PEEK(40)
Note: This message originated from outside the FIU Faculty/Staff email system.
On Jul 13, 2022, at 11:35 PM, Arthur Flexser via Coco <coco at maltedmedia.com> wrote:
>
> Allen, I believe you're wrong about Microsoft having made a one-byte memory
> mistake that Microware corrected for the CoCo 3. My memory is a little
> vague on this, but I have a recollection that the CoCo 1/2 actually needs
> that extra byte, but the CoCo 3 doesn't because Basic is running out of RAM
> on the CoCo 3.
>
> I recollect that some function, maybe VAL or HEX$, uses 2 bytes of RAM at
> the top of memory as scratch storage for its calculations. If you raise
> the top of memory by 1 byte on a CoCo 1/2, this function misbehaves in that
> it thinks that the byte at $8000, containing the Ascii for the letter E at
> the start of Extended Basic (which starts with "EX") is RAM and uses the
> hex value of "E" (decimal 14) in the calculations instead of the value that
> the function has temporarily poked into that byte.
>
> Wish I could be more specific, but that's what I remember. Perhaps someone
> here can fill in the particulars.
Interesting.
I did tests like this, using the default 200 bytes of string space…
A$=STRINGS$(200,42)
I can peek 32766 and get the 42, so there is only one byte after it at 32767. 0-32767 is the 32678 bytes of 32K, with the next byte being the start of ROM.
That gives us one byte… and now off to check the unraveled books…
--
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco
More information about the Coco
mailing list