[Coco] Looking for rma or r63 source.

[Gene Heskett]

On Friday 06 December 2019 18:00:13 Stephen Fischer 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.
>
Sad to hear.

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

140GB? There was a lot more than os9 in that pile then.

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

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

I am in the process of assembling a new box, which will have 6TB in 4 
drives moved from the one that burned up to the new build. But I ordered 
too big a cpu cooler, and it sticks out past the side cover of the tower 
about 1/2".  OTOH, that cover hasn't been on it for 12 years now. :)


> But not on a CoCo for sure.

I find the pair of 1GB seagate scsi-ii's are way more than enough on my 
coco3. Well over 200,000 spinning hours on them, only problem is startup 
stiction if turned off for a month or 3.  No bad sectors that I know of 
on either.

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

Provenance is great, if it can be produced. If you have it, produce it.

I don't think so either. Haveing kicked the tires in c-prep rather 
extensively many years ago now, I did not find any telltale canned 
operations of a compilers footprint in it that I recognized, so I think 
it was  originally done in assembler.  But it was organized better than 
most assemblers do when assembling the output of human fingers.  Does 
that certify it was originally done in asm code?  No, only that I didn't 
recognize the trademarks of _our_ C compiler and it has a plethora of 
them, so if written in C, it wasn't our compiler that made the original 
executable.  No trace of Prof Bud Passes fingerprints in it either. 

Beyond that guess, anybody else's is as good as mine.

> 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


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>