[Coco] [Color Computer] Re: OS-9 as Replacement for DECB.

[James Diffendaffer]

> James
> 
> What I was trying to say and the point seems to be missed is this:

Yeah probably missed... wouldn't be the first time.


> When the interpreter sees and expression like the following as a 
> strting: 
>
> 10 A=5+53
> 
> the line number 10 is converted to binary then the numeric 
> expression is converted 
> to floating point. Thus the ascii character $35 and character string 
> $35, $33 are 
> converted to floating point numbers and then added and then 
> converted to an ascii 
> string. Yes this does take time. 

Understood, that's the part that could take advantage of a P Code type
interpreter speedup.  
Line numbers, stings anything that can be preconverted should be by
the tokenizer.

I did work on a custom version of Basic that also converted the line
numbers in GOTO's and GOSUBs to pointers directly to the destination
line but then Basic couldn't be interactive like ECB.  You can't know
what the pointer will be till you actually type in the line.
Perhaps a 2nd runtime only version of the Basic used once a program is
complete?


> All trig functions are converted to radians, then to floating point 
> numbers and 
> evaluated. Trig functions are evaluated with a modified Taylor 
> series using five 
> cofficients. Just looking at what it takes to just calculate the sin 
> of a30 degress may 
> take several hundreds of microseconds. Most of the time is 
> normalizing the 
> numbers and result. 

I'm with you so far.  I was thinking pure floating point and didn't
think about radians and such.
Normalizing... didn't think of that.  I've been in the C world too much.


> Now variables and array pointers are treated differently. Those are 
> interger binary 
> numbers. Yes loop counters are binary integers. Line numbers are 
> also binary 
> integer. Yes the Coco 3 interpreter does both interger math and 
> floating point math. 

Ok... in the following case 10 does go to float... correct?
X = FLOAT + 10 : PSET(X,100) 

And how about here?
PSET(FLOAT + 10, 100)
Is the interpreter smart enough to convert FLOAT to integer then add?

Just curious.


> A VHDL 6809 with a FPU incorparated within would not fit in a 300K
gate part.

Which would mean going to a larder BGA part instead and not a hobby thing?


> The CPU would but a decent FPU will take up to 300K gates on its 
> own. Especially if you 
> want extended precision, which is 80 bit FP #. While you can split 
> the two it is 
> always more preferable to integrate the CPU and FPU together. 

Agreed, the chip is the limiting factor here.
How many bits is normal CoCo floating point?


> For a Coco FPU, there are FP routines for a PIC contrroller that
> already exist. 

Making that job a snap.  Gotcha.
But I'm assuming a different format than CoCo????
Data file conversion would be and issue.

> Since 
> the PIC or even an AVR can run at five to ten times the buss speeds
> of the current 
> Coco 3 CPU,  the time to do one FP calculation is cut from 1 mSec to 
> as short as 
> 25 microseconds. I would take that any day. Interfacing may prove to 
> be a small 
> challenge but nothing to difficult. 

Ok.  The overhead would be time to load #, send a command, the delay
from when the result flag is set to when the 6809 sees it and
store????  And it depends on the number of bytes in the floating point
number as well.

So... 80 bits = 10 bytes.

Load a byte from RAM, put in FPU ten times.  This still must happen
even if the PIC does it so you have 20 clock cycles in load and store.
 That would still be required by a CPU instruction using that
precision.  Loading the cpu instructions for such a task is extra.
Send command to FPU coprocessor.  
Test done flag (unless all operations take less than the clock cycles
required before you start storing the result or halt the 6809)

That will boost the calculation time and I'm not about the figure out
the milli/micro seconds.  But I'm sure it's still faster than CPU only.

And if you use the 4Mhz hack or 6309?
Just asking if there is an easier way to get the speed gain without
the effort.

Yes I'm being a devils advocate but that's because I've spent time on
projects that sounded wonderful in concept... only to find out the
reality wasn't worth the effort.

If it's faster than a 4MHz 6309 can do it I'd say go for it.  If
not... is it worth the effort?  If you want to do it just because you
can... hey, go for it!

James





------------------------ Yahoo! Groups Sponsor --------------------~--> 
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/CFFolB/TM
--------------------------------------------------------------------~-> 

Brought to you by the 6809, the 6803 and their cousins! 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/ColorComputer/

<*> To unsubscribe from this group, send an email to:
    ColorComputer-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/