[Coco] Assembler Source file for the CoCo ROMs

[Little John]

Key264K by Dynamic Electronics was for 64K CoCo 1 and 2's. It was a pretty 
nifty piece of programming and made use of the "Page" bit in the SAM.
Big BASIC was by DanoSoft for 512K CoCo 3's and allowed BASIC programs to 
span much of the CoCo 3's extra memory, included techniques for passing info 
between program segments too I think. There was also Baby BASIC which was 
for the 128K CoCo 3.
Also 512KBASIC and BASIC512 from others that patched the interpreter to 
allow BASIC programs to run from extended CoCo 3 memory.
It would be neat to find manual scan's for these pieces of software.
----- Original Message ----- 
From: "Arthur Flexser" <flexser at fiu.edu>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Sunday, October 24, 2010 7:03 PM
Subject: Re: [Coco] Assembler Source file for the CoCo ROMs


> Disk Basic is actually written pretty economically with respect to number 
> of
> bytes used.  Though there are some obscure features that might be 
> eliminated
> to save some space.  One could move Disk Basic up higher by a couple of K 
> to
> allow for bigger Basic programs, since there's that much free space above
> it.  Dunno that it would really be worth the bother, though.  For big 
> Basic
> programs, it'd be easier in the CoCo 3 to use some free memory segments.
> Wasn't there at least one commercial program that did that?  And there was
> one for the CoCo 1/2 that worked by swapping the two 32K RAM banks in and
> out, as I recall, to allow for bigger Basic programs.  Key264K, I think it
> was called.  (I seem to also remember the name Big Basic for one of these
> sorts of programs.)
>
> Art
> On Sun, Oct 24, 2010 at 7:29 PM, William Astle <lost at l-w.ca> wrote:
>
>> On 10-10-24 02:24 PM, tim lindner wrote:
>>
>>> 1. Compact BASIC. Try to squeeze it even tighter that it already is.
>>> Shove it as high in memory as you can and set the program RAM size
>>> higher that $7000.
>>>
>>
>> I think you mean $8000.
>>
>> In any event, I'd wager there is probably a few K that can be gained by
>> doing that simply by eliminating the redundant stuff in command
>> interpretation, tokenization, and the various overhead from ramhooks. 
>> That
>> would give a non-trivial speedup, too.
>>
>> 2. Integer BASIC. Strip all of the floating point routines and replace
>>> them with integer versions. Result: BASIC program will have a smaller
>>> RAM footprint and will execute faster.
>>>
>>
>> That would probably make a siginficant difference in the footprint but 
>> not
>> so much in the floating point handling routines. The real difference 
>> would
>> come from the removal of all the trig and similar functions that require
>> floating point. It would, of course, make things run significantly 
>> faster,
>> however.
>>
>> How about some more ideas (and maybe some code)!
>>>
>>
>> A complete HPRINT character set (matching the hires text screen) could be
>> done. (Don't even need to create the extra characters - they're present 
>> in
>> the Coco3 ROM at the end of SECB).
>>
>> Maybe also support for both floating point and integer variables, or even
>> double precision floating point.
>>
>>
>> --
>> William Astle
>> lost at l-w.ca
>>
>> --
>> 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