[Coco] dbg.l

Wed May 4 12:17:28 EDT 2011

Hi,

No Gene, Brother Jeremy concentrated on the new stuff Kevin was working on, 
not the old files downloaded from CIS. I can check my copies also but I see 
no reason that what we want would be included.

The files may have been deleted requiring the FBI methods I use. Thus KD's 
original HDD may be needed. (Or a sector by sector copy made)

In searching John Collyer's Hard Disk I was pleasantly suprised to find some 
of my work which John may have deleted.

I am still waiting for the "rdump" of "dbg.l" to help with my searching and 
to determine the status of "trace_c" which may be the main part needed 
perhaps.

We need to think about searching floppy disks when offered and hard drives 
also.

Do we have an "UNDelete command to automate the recovery of some of these 
deleted NOT! as we all know files.

I think we are in very desperate mode now.

SHF

----- Original Message ----- 
From: "gene heskett" <gheskett at wdtv.com>
To: <coco at maltedmedia.com>
Sent: Wednesday, May 04, 2011 12:46 AM
Subject: Re: [Coco] dbg.l

> On Wednesday, May 04, 2011 03:02:25 AM Stephen H. Fischer did opine:
>
>> Hi,
>>
>> Just fine with me, I am glad that I found something of value.
>>
>> Perhaps you can help one the CoCoers going to Chicago to remark to
>> Brother Jeremy that he has a unique snapshot of our OS-9, perhaps our
>> only chance to find the source to "dbg.l", "ShellPlus 2.1" and many
>> other programs that appear to be lost. I clearly understand his
>> agreement with Kevin Darling and Kevin's NDA with Tandy and the desire
>> to not break them. If there are any other places to look, please
>> suggest them.
>
> Are you saying that it may be on the update disks that Brother Jeremy was
> pushing years ago?  Somewhere, I think I have a set of those!  Hopefully
> still readable.  I'll go look once I've collected a few zzz's.
>
>> I do have some Delphi files to look at still but as I said before, CIS
>> binaries were transferred to Delphi, Source code usually was not. My 300
>> Baud straw did not suck up too much of Delphi.  Someone did offer an
>> archive of files which I downloaded (56K Baud perhaps), I just need to
>> find it. My archive of Delphi messages might provide a "dbg.l"
>> discussion date but by the time I joined Delphi the OS-9 forum had been
>> taken over by the OSK people driving away all the CoCo people which was
>> why I attacked one of them decades ago.
>>
>> I found where Kevin went after the CoCo including some messages from
>> you.
>>
>> SHF
>
> That might be a possibility Stephen.  Way back when, and I was first
> looking at rbf.mn with an eye toward using the extra 6309 features to 
> speed
> it up, I discovered that Kevin's "Christmas Present" new version of rbf.mn
> had also stripped out some functions related to disk cluster sizes >1, and
> put them back in, and may have been doing some public muttering about that
> breakage.  He may not have appreciated me at the time, but I personally
> took that to indicate that he wanted to cripple it for some reason.  OTOH,
> may he have just forgot what it was doing and nuked it as spare code, so
> once I'd put that back in, and spent a couple of weeks really hammering on
> it, IIRC fixing a couple of places in it that my tests with cluster sizes
> up to 8 disclosed told me that the original code hadn't been well
> exercised, so I was happy and grinning like an ID10T that I had managed to
> fix some of the great KD's code.  ;-)
>
> I also installed the backar flag, and that turned out to be my most famous
> mistake ever.  It bit Boisy and it took years for that smoke to settle.  I
> personally knew how to work around that but failed to emphasize that
> setting the descriptors DD.SAS way up from the default 8 would prevent its
> running out of FD.SEG space in the file descriptor for any reasonably 
> sized
> file, which is when that flag would bite you hard by removing the first
> FD.SEG sized allocation from the disks FAT.  That meant the next write
> overwrote LSN0 and likely the FAT & root directory too.  By-by disk and 
> its
> data unless you had what it took to rebuild it with ded.  I had been
> running DD.SAS at $20, on up to $FF because it stopped a lot of disk
> fragmentation even before then and I still do.
>
> Unforch, not everyone follows my line of reasoning on that point.  IMO to
> waste an FD.SEG for every 2k of file written was NOT an excusable design
> decision.  But that is just me being an ornery old fart too.  What most
> didn't understand was that even if 255 sectors was allocated by DD.SAS=FF,
> the closing cleanup at the end of the file write gave back the unused
> sectors in the FAT, so if the file only needed 14 sectors, the rest was
> returned to the FAT pool.  IIRC, that was one of the areas in the original
> rbf.mn that I had to fix as that went to hell when the cluster size was 
>  >1.
>
> To me there wasn't any good reason not to use a much bigger SAS as long as
> there was enough disk space left to grant the allocation in the first
> place.
>
> [...]
>
> -- 
> 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)
> Don't steal... the IRS hates competition!
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco 