[Coco] 3rdPart Editor

[Gene Heskett]

On Sunday 16 December 2018 11:42:50 Bill Gunshannon wrote:

> Just out of curiosity, has anyone ever built the version of the
>
> Unix editor "ed" that is in the 3rdparty/packages directory?
>
>
> Additionally, is there any documentation on the "make"
>
> command packaged with the C Compiler?  It does not seem to
>
> take any syntax used by other versions of make.
>
>
> bill

That to me is an odd comment Bill, its the first make I ever used, and it 
always did what I asked. But it doesn't have all the bells and whistles 
the current *nix make has. But then I didn't use it very often either, 
preferring the various versions of cc to drive the compiler, primarily 
because they were an editable text script making it easier to stage the 
compiler to stop at the assemble language point where I could do the 
various hand optimizations I had developed back in the day, and then 
finish by assemble and link. Some of those  paid off quite well, with 
rzsz gaining noticeable speed increases approaching 40% on a 6309 when 
compared to Chuck Foresburgs versions built for 6909's. 

Designed to cope with noisy voice grade copper phone lines when it was 
originally released, unforch today its a nearly broken protocol because 
the two ends can't automatically agree on the max size of the block, so 
when I used it to move stuff to the coco from here, I was  forced to set 
the "window" size to a max of 256 bytes from this end. The current *nix 
version can move up to 32kbytes before asking for a crc check, so 
without the window size control, it will at 9600 baud, overrun the coco 
as its max average rx speed is about 7000 baud, so the only way to make 
it work w/o frameing errors is to make the nix version stop and wait for 
a good crc report from the coco every 256 bytes.

That works well, but of coarse is not as fast as drivewire by a quite 
noticeably huge difference. One of the speed killers in rzsz is that it 
does an incremental call to the crc calculator on a per byte received. 
Thats a huge call and return overhead and a time sink.

If it called the table mode crc thing on a whole block of coco memory 
allocated 8192 byte buffer at a time, it could probably keep up with a 
9600 baud circuit on a coco3, but that would not be a tweak, it would be 
a major re-write. But probably not doable on non coco-3's, likely not 
enough available ram. The table occupy's 256 bytes too, making an extra 
8500 bytes the coco1's and 2's don't generally have to spare, but its 
faster than os-9's default method.

-- 
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)
Genes Web page <http://geneslinuxbox.net:6309/gene>