[Coco] Assembler Source file for the CoCo ROMs

[jdaggett at gate.net]

On 24 Oct 2010 at 20:03, Arthur Flexser wrote:

> 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

>From what I see of the code. I would not call it economical at all. Then that is only an opinion 
from the peaut gallery. Basically what I see is Microware did  not want to rewrite the the 
complete graphics command section so they basically plopped the higher resolution graphics 
in their own code instead of merging with the code Microsoft wrote. 

Not exactly economical. Though far more easier and quicker to market the way it is now. I will 
grant that combining the graphic commands(HLINE and LINE so forth and so forth)  into 
separate routines will not be an easy task. It sure is not impossible. Off loading the graphics 
command to another processor would allow a major reduction in code size. 

just thought of another means of code size reduction. Instead of getting rid of the floating 
point routines, why not off load that to a parallel processor. Do the same for the graphics 
also. Then the Basic interpreter would be leaner and faster.

just my thoughts. 

james 
> 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