[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