[Coco] dbg.l

[gene heskett]

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!