[Coco] Looking for rma or r63 source.

[David Lord]

 Just checked.      I have 129 TB in NAS storage on my network.  Didn't realize it had grown so much over the years.
    On Friday, December 6, 2019, 05:00:35 PM CST, Stephen Fischer <sfischer1 at mindspring.com> wrote:  
 
 I can make no judgement on your words except that other things may have 
been on that hard drive that we sorely are missing and wish we have.

But it's all in some landfill as Br. Jermony (sp) has gone over the pond 
to stay.

I was too late asking for a copy of the 140 GB that was offered by 
Little John in an issue of the Glenside Newsletter, and he passed on too 
soon quickly.

We keep shooting ourselves in the foot and else where for the wrong reasons.

You want drives larger than 131 megabytes? Well as a person who has a 
1TB N.A.S. (Raid 1) on my network and and five 1 TB USB drives and one 2 
TB USB drive I can see the need for even larger drives.

But not on a CoCo for sure.

And the reference was just for one person who I know worked at Microware 
and might have come into contact with the "C" Compiler source.

Should a Provenance for the "C" Compiler source be identified we are in 
contact with one of the current owners of said source who could verify
said provenance.

I just don't think we have the "C" Compiler source.

SHF

On 12/6/2019 2:34 PM, Gene Heskett wrote:
> On Friday 06 December 2019 15:25:03 Stephen Fischer wrote:
> 
>> I think that we need to get as suspicious of people that declare they
>> have the original copy of "The Bible" written by "GOD".
>>
>> Provenance is a pivotal vernacular in the art world.
>>
>>  From the French word, provenir, meaning “to come from,” it proves the
>> history of ownership of a specific piece of art. Provenance is the
>> documentation that authenticates a particular art piece.
>>
>> It's all in the "Provenance" which we don't have.
>>
>> There has been so very much disassembly of CoCo programs and comments
>> added over the years going way back past the memory of some people
>> that they think they have the original and not a comments added
>> disassembly of the original program.
>>
>> I am not declaring that I can tell the difference, it would take the
>> word of someone who at least worked at Microware. That is, word of
>> someone who left the very restricted 6809 world to earn a living on
>> 68000 systems like K____ D______ who worked on the unreleased version
>> of OS-9.
>>
>> SHF
> 
> Stephen: (and anybody else that gives a fat rats ass)  Based on what I
> found in K-D's newest "Christmas Present" rbf.mn when I first converted
> rbf.mn to run on the 6309, the most educated opinion I can come to was
> that the Christmas Present rbf.mn was intentionally poisoned to prevent
> us from ever using a hard drive of more than 131 megabytes.
> 
> I'm the one who put the multiple cluster code BACK into rbf.mn at that
> time, so now we can use drives up to 4GB. I got the majority of that
> code from the original level 1.000000 rbf.mn, so it was there originally
> from MicroWare, made a few minor tweaks as I was testing it before
> anyone but me ever saw it, then someone else with a bigger machine, an
> Apple I suspect, so bigger buffers, ( as I was often working in the last
> 10 bytes of tsedits 56k buffer while doing that on my coco3 ) did it so
> it was a conditional, either r68 or r63 assembly, and thats how rbf.mn
> is to this day except the header comments have been edited to hide all
> those now very old details.
> 
> \Somewhat off topic.
> 
> I tried to add an "archive this" bit in rbf.mn ed 34, and mentioned at
> the time that a larger default file allocation, like changing the 8 to a
> $20 was good insurance against useing up the FD sectors list of
> segments, but no one paid any attention until it bit the then head
> developer and all hell broke loose.
> 
> I still think that bit was a good idea, but should also have coded a one
> less segment maximum segment count into rbf.mn thus protecting the last
> 5 byte block.  That 5 bytes would have opened up several other
> possibilities I've still not thought of. Ownership controls for up to
> 255 users comes to mind.  And would only use 1 byte of the 5.
> 
> By that bit you could have backed up only that which had been changed
> since the last backup. But going to a $20 segment allocation size would
> have made zero diff in the actual size of a file since os9 gives back
> all sectors not used at file closing time. But it would have divided the
> used segment count by 4, and insured that the bug the bit I borrowed for
> the "archive me" flag would probably never occur in practice. But I've
> lost my commit perms, so that will never happen now.
> 
> \end off topic
> 
> My estimation of K-D's intentions toward the community as a whole went
> several rungs down the ladder with that discovery.  If you have his
> book, take carefull note that rbf.mn's capability in that realm was
> moderately well scrubbed.
> 
> You will never convince me that was a mistake. That was intentional. To
> me the puzzle wasn't that fact, but the motivation for it is still the
> unsolved puzzle in my mind.
> 
> The singular insult to me is that there is no mention of any of that in
> the rbf.mn headers, giving no credit to me for having done that FIRST.
> 
> I'd like to see that fixed, giving credit to me for that, but at 85, I'm
> not convinced it will happen in my remaining time here. And it has left
> a bad taste in my mouth for 3 decades now.
> 
> Like Paul Harvey was fond of saying, "and now you know the rest of the
> story."  Make of it what you want.
> 
> Cheers, Gene Heskett
> 

-- 
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco