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

[Arthur Flexser]

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.

Art

On Wed, Mar 14, 2012 at 11:58 AM, William Astle <lost at l-w.ca> wrote:
> On 12-03-14 01:36 AM, Arthur Flexser wrote:
>>
>> The ?mem command gives the amount of memory between the start of
>> program memory and the top of available memory--the amount of memory
>> Basic programs have to work with.  In a 16K CoCo without Disk Basic,
>> and with the default PCLEAR 4 in effect, program memory starts at
>> $1E01 (or $2601 with Disk Basic).  Basic reserves 200 bytes of string
>> space at startup, at the top of memory.  So in a 16K CoCo without Disk
>> Basic, available memory is $4000 - $1E01 - 200, which comes out to
>> 8503, 16 bytes higher than the observed figure of 8487.  (The 16 bytes
>> are probably reserved for stack space.)  Add 16,384 (16K) to that, and
>> you get what ?MEM should give in a 32K/64K CoCo.
>
>
> For the TL;DR crowd, this explains exactly where the 8487 number above comes
> from.
>
> MEM actually calculates the amount of space between the current stack
> pointer (S) and the top of the variable table. Thus it gives an
> approximation of the number of bytes available to be used by the system
> stack and new variables. The system stack is used for book keeping for
> GOSUB, FOR, and expression evaluation, among other things. The memory map
> looks like this, starting from 0:
>
> Direct page and other color basic variables
> 32 column text screen
> disk basic variables and data (if DECB is present)
> PMODE graphics memory (if ECB is present)
> basic program
> variable table
> <free space>
> the stack
> string space
> <top of "RAM">
>
> Observing the memory detection code in the color basic ROM, I see it wastes
> two bytes at the top of RAM - that is, it detects $3FFE as the top of RAM
> instead of $4000 as the first non-RAM byte. On a 32K or 64K machine, that
> would be $7FFE. On a coco3, it is forced to $7FFF (which explains why MEM
> returns one additional free byte on a coco3 compared to a 32K coco1 or
> coco2).
>
> Continuing on with a 16K machine, 200 bytes are then allocated for string
> space which moves the top of free memory to $3F36. The stack pointer is then
> set to that address and a zero byte is pushed onto the stack. This makes the
> stack pointer $3F35 on a cold start.
>
> The end of the basic program is actually two bytes after the start of the
> basic program, even when there is no program present. That means variables
> and all that starts at $1E03 by default in ECB.
>
> With nothing else involved, that should give 8499 as the MEM value. However,
> because the stack pointer is used to determine the top of free memory, we
> also need to account for the usage of the stack during interpretation. So
> let's trace the call path for ?MEM:
>
> First, the command processing routine is called (2 bytes return address on
> the stack) which transfers control directly to the PRINT command. PRINT uses
> an internal subroutine for handling its arguments (another 2 bytes return
> address on the stack). That internal subroutine then calls the expression
> evaluation routine (another 2 bytes return address on the stack). The
> expression evaluator stores a zero byte on the stack then makes an internal
> routine call for yet another 2 bytes on the stack. This routine eventually
> gets around to calling the MEM routine (another two bytes return address on
> the stack).
>
> I make that 11 bytes stored on the stack by the time MEM gets to do any
> operations on it. That gives the observed value of 8487 when MEM grabs the
> stack pointer and subtracts it from the top of the variable table (which is
> empty so it's really the top of the empty program).
>
> As a consequence of all of the above, if you use MEM in a more complex
> expression, you will get a lower number even without any variables defined.
> For instance, "?3*MEM/3" gives 8475. Also, defining variables will reduce
> the result. For instance, doing "A=0" before "?MEM" gives 8480, accounting
> for the 7 byte table entry for A. Obviously adding program lines will also
> reduce the result.
>
>
>
>>
>> Art
>>
>> On Tue, Mar 13, 2012 at 8:35 PM,<haywire666 at aol.com>  wrote:
>>>
>>> Thats interesting I don't remember the ?mem thing...
>>>
>>>
>>> Can someone provide a list of the #'s and what they mean?
>>>
>>>
>>> 8487 means 16k?
>>>
>>>
>>> I got 24871 on the coco2 I have on at the moment, does that mean it only
>>> has 48k?
>>>
>>>
>>> Steven
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Chad H<chadbh74 at hotmail.com>
>>> To: 'CoCoList for Color Computer Enthusiasts'<coco at maltedmedia.com>
>>> Sent: Tue, Mar 13, 2012 8:31 pm
>>> Subject: [Coco] CoCo 2 16k.. Upgrade or no?
>>>
>>>
>>> Was just given a virgin CoCo2 26-3136.. It's apparently 16k, only shows
>>> 8487
>>> from "?MEM".  I already have a spare 64k CoCo, don't really need this
>>> one.
>>> I will probably put it up for sell.  Question though.would it be better
>>> to
>>> leave it as is or perform a 64K upgrade to it?  I already have enough
>>> spare
>>> RAM IC's and sockets and it already has ECB 1.1.
>>>
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>>
>>>
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco