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

[jdaggett at gate.net]

On 2 Sep 2005 at 21:36, James Diffendaffer wrote:

To:             	ColorComputer at yahoogroups.com
From:           	"James Diffendaffer" 
<jdiffendaffer at yahoo.com>
Date sent:      	Fri, 02 Sep 2005 21:36:57 -0000
Copies to:      	Subject:        	[Coco] [Color Computer] Re: 
OS-9 as Replacement for DECB.
Send reply to:  	CoCoList for Color Computer Enthusiasts 
<coco at maltedmedia.com>
	<mailto:coco-
request at maltedmedia.com?subject=unsubscribe>
	<mailto:coco-
request at maltedmedia.com?subject=subscribe>

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

Correct 
> 
> > 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 largest gate equivalent in QFP is 300K. After that everything is 
BGA. BGA is not so much a problem is that the Spartan2e line goes  
only to 600K gates. The Spartan 3 line goes to 4 million gates but 
the free software only su pports to 600K gates. The lowest cost 
XLINX Fou ndation software is $695. The full blown software is 
$2500 and another chunk for the EDK software. 

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

The RSBASIC FP routines unpacks a 5 byte FP #  and uses 4 bytes 
for the mantissa, one for the exponent and one byte for the sign. 

> 
> > 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.
> 
******

I have to agree with you. I have three that I have the most interest 
inseeing through. WIth these three I have learned a bit about the 
Coco and it has been an exercise in futility art times but a great 
learning tool.


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

Right now ther e is a 6809 core that fits into a Spartan 2e 200K gate 
part that will run at 12.5 MHz. I have a copy and one day would like 
to expand it to incorparate the 6309 instruction set. Also I think I can 
do a few th ings to speed it up to amy be 25 MHz or more. Dangit,if 
t here is a free 8080 core out there that can run at 30 MHz then by 
gosh I can't see why a 6809 core can't!

My dream would be to win a lottery and be able to go to ASIC with a 
6309 compatible processor with improvements. At .13 micron  
technology, it would not be to difficult to get the part to run at 
around 250MHz. But I need upward to a half a million dollars to pull 
it off.

james