[Coco] Tutorial on Telnet/inetd on Coco3 DW4 (is there one?)

[Bob Devries]

Hehe, yeah, I wasn't thinking...

I guess what we need is a realiable way to add a file to an existing .DSK or 
.VHD file. Not sure if wimgtool.exe will fill the bill, or what you'd use on 
Linux.

I'll do some playing....

Regards, Bob Devries
Dalby, QLD, Australia

----- Original Message ----- 
From: "Gene Heskett" <gheskett at wdtv.com>
To: <coco at maltedmedia.com>
Sent: Friday, October 12, 2012 11:23 AM
Subject: Re: [Coco] Tutorial on Telnet/inetd on Coco3 DW4 (is there one?)


> On Thursday 11 October 2012 20:42:11 Bob Devries did opine:
>
>> Good for you, Gene. happy to listen to your educated ramblings any day
>> :)
>>
>> Tell me, I think I should be able to run RZ over the telnet session?
>> When I start rz (with no command line options) it sits there for a
>> while, and errors out with ERROR #216.
>>
> On which end of the circuit?
>
> For transfers coming up to this machine I generally get a dir listing on
> screen so that I can then tell the coco shell to launch "sz -b filename".
>
> Minicom responds to the trigger string and handles the rz stuff on this
> end.
>
> To go the other way, to the coco, you first need to figure out how to
> restrict the window/block size of the sz util on you machine to perhaps 
> 512
> bytes in order not to over-run the coco and cause endless errors that will
> take the transfer speeds down to about 40/second because of all the over
> flows.  In minicom that is relatively easy, and for a 6809 machine you can
> get 400+ cps transfers, 600+ on a 6309 machine.  This is on a 9600 baud
> path.
>
> On the coco, I normally start rz from its shell, (rz </t2) then before it
> errors out, go thru the procedure to have minicom send the file. rz gets
> synched and if the pc doesnt drown the coco in data, the file will
> eventually get there, verbatim.
>
> Now, using telnet, because sz is a hardware oriented protocol, I've no 
> clue
> how you coerce it into using a socket at an ip address.  It's conceivable
> that it has grown this ability while I wasn't looking.  The slowdown is
> still going to be required as the rzsz on the coco is a character by
> character protocol and simply cannot execute that very lengthy loop from a
> bufferless ACIA chip any faster that that.
>
> We really do need a faster way to move data than rzsz will ever be, and I
> think that by using the Toolshed tool kit to "os9 copy filename genes-
> common.dsk" to copy a file into one of dw's virtual disks on the pc,
> followed by a copy of that file from say /x1/filename to media local to 
> the
> coco will be much faster for 25k plus files than rzsz can ever be.
>
> Which works the best is I think, up to us to discover.  But with the
> relatively error free drivewire, I do not believe we need the block by
> block crc checking that rzsz does, and which costs us 9/10nths of the
> transfer speed otherwise attainable by the simpler protocols.
>
>> Should I use some options for this instance?
>
> You should use the "sz -b -w 256" option to force pure binary and restrict
> the block size to what the coco can handle, but personally I think we need
> to find a newer protocol to bark at.  Something that CAN handle the 10k a
> second that drivewire can do.  rzsz isn't it, by quite a lengthy row of
> apple trees.
>
> Aaron?  What is your take on this?
>
>> Regards, Bob Devries
>> Dalby, QLD, Australia
>
> 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)
> My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
> "Is it really you, Fuzz, or is it Memorex, or is it radiation sickness?"
> -- Sonic Disruptors comics
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco