[Coco] Assembler Source file for the CoCo ROMs

[Arthur Flexser]

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
>