[Coco] [Color Computer] Multiple C compiler projects

[Gene Heskett]

On Monday 18 July 2005 06:50, James Jones wrote:
>Gene Heskett wrote:
>> Is that not pretty well handled by the pd trig library, donated by
>> the South American who died shortly after pd-ing his code in the
>> rainbow? I've used that library extensively and its at least as
>> good as my TI-51 in terms of accuracy of the stuff I actually
>> checked.  It gives a 1 byte exponent, and enough of a mantissa
>> that answers to the 16th digit, sometimes the 17th, can be
>> obtained via a suitable printf statement.
>>
>> This also has the advantage of not being radisys's code.
>
>Hmmm. I either didn't read RAINBOW as closely as I should, or I've
>totally forgotten about that library. What issue was that in?

Now you've asked the 64 million dollar question, James.  I don't 
recall ATM.  I'll have to go dig around in the boxes in the basement 
I expect.  What I do recall was the difficulty I had in making it 
work because Lonnies daisy wheel printer he used for making the press 
plates scans used an el character that was identical to a one 
character.  And one of my earlier daisy wheel printers did too, so I 
wound up grinding a piece off the bottom of the el so I could tell 
the difference.  My zerox 1650-ro has an easily discernable 
difference.  I'll see if I can find it, but its earlier, say 1986ish 
as I think as I was living in a trailer by myself in a small town NE 
of Clarksburg called Hepzibah at the time.  Back in about half an 
hour if I'm lucky... 

Found it, April 1986, starting on page 240.  (Gee, the Rainbow really 
was a big magazine back then) The code has some semi-circular 
references, so that when merging to make the library, there are a 
couple of routines that need to be included twice as the linker, 
c.link, only scans the library once.  So I think the version I have 
on my hard drive probably has 2 copies of several of the routines in 
it.

One could probably re-arrange the merge order even more and alleviate 
the need for the dups if enough effort were expended.  Working on a 
floppy only system at the time, I remember putting about 2 weeks 
worth of spare time into it.  At the time I didn't mind an extra 
kilobyte in the library if it worked, and it did as near as I could 
tell.

And watch the one's and the el's :-(

>It, or any floating-point library, presumes a particular format for
> the numbers. Googling "6809 trig library" shows an earlier message
> in which you mention using the library in C--that implies that
> either it worked on floating point in the format that the Microware
> 6809 C compiler used, or it used a different format and either you
> or the library's author wrote functions to convert to and from that
> format. In any case, one can independently write code to use the
> same floating point format that the Microware C compiler uses.
> Doing so would have the advantage that existing binary data that
> people have generated using that format would still be usable
> without conversion. IEEE format has some advantages (an additional
> significant bit for normalized numbers), and some disadvantages (it
> would take additional code to deal with the NaN and Infinity
> values).

> James Jones

The data format was compatible with the microware printf, that much I 
do recall.  Where does that extra significant bit show up in the 
printf output?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.