Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!bellcore!whuxcc!lcuxlm!akgua!mcnc!rti-sel!sas!toebes
From: toebes@sas.UUCP (John Toebes)
Newsgroups: net.micro.amiga
Subject: Re: CLI on a terminal.
Message-ID: <185@sas.UUCP>
Date: Wed, 1-Oct-86 00:17:14 EDT
Article-I.D.: sas.185
Posted: Wed Oct  1 00:17:14 1986
Date-Received: Sat, 4-Oct-86 09:32:26 EDT
References: <8609260632.AA26339@cory.Berkeley.EDU>
Organization: SAS Institute Inc. Cary, NC
Lines: 45
Summary: There is hope for a serial CLI

In article <8609260632.AA26339@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
> 
> 	On this, does anyone know the criteria for NEWCLI accepting non-windows
> for it's window argument?
> 
> 	On the ser: device... your outa' luck.  The input buffering is a
> 'feature' of ser:... however, if NEWCLI accepts ser: as an argument, I see
> no reason for it to screw up the input processing once it *does* get a
> buffer full... try using LineFeeds (^j) instead of Returns (^m).  This is
> why you usually attach a newcli to a CON: device and not a RAW: device.
It is possible to modify the port-handler - unsupported of course - to run
a newcli over the ser: device.  I have done it several times and have done
some work to allow one to say
    newcli ser:9600,8,n,1,I
But at the current point in time I have only got a copy of a version that does
not compile.  I have not posted this because I have a request in to CBM (now
quite an old request) for a definition of what form of AMIGADOS device handlers
will be supported.  As the frustration factor is getting high on getting this
resolved, I am tempted to break the cobwebs off the code and post it.
> 
> 	Also, the CON: device does input buffering and echo.
> 
> 	The only solution I see to offering a CLI process on the serial
> port or on a separate screen is for some brave soul to write a DOS device
> driver for it.
The problem we have here is twofold:  There is no supported way to write a
device driver that will work with 1.1.  Second, the documented way of making
a driver work under 1.2 has not worked for me yet.  Doing the CLI on a separate
screen is quite simple.  Jack Rouse has already done the major part of the
work for it in MAKE.  It handles all the I/O to a device other than a CON:
window under program control.  It needs some polish but could be readily
adapted to a number of different attacks on the subject, including adding
command line recall to a window.  But where's the time for us to do all this
work....
> 
> Q: What do you get when you hand OpenScreen() a width of 50?
> A: FireWorks
Try a height of 1 and a width of 1.  It is also just as unpleasant.  I wanted
POPCLI to use that size to reduce the amount of memory.  I finally went with
a nice save number like 120 by 12.

      John Toebes
-- 
John A. Toebes, VIII       usenet:..mcnc!rti-sel!sas!toebes
USnail: 235 Trillingham Ln, Cary NC 27511   BBS:(919)471-6436