🚀 go-pugleaf

In article <163@grpthry.UUCP> aw@grpthry.UUCP (Alan Whitton) writes: 
+---------------
|My question is this: is it possible to somehow connect a plain alphanumeric
|terminal to the CoCo II in any way? I would guess that OS-9 would make it
|easier but I would like to hear from anyone who would have even a guess as
|to whether this was possible. It seems another serial port is needed, but
|how would this be done?
+---------------

I won't say its *IMPOSSIBLE* to do with RS-DOS but I wouldn't even consider
it if I weren't the author of RS-DOS.  RS-DOS and the TV/Keyboard are tied
too closely together.

When you are running OS-9 its trivial.  I've been using a VT100-compatible
terminal with my CoCo for almost a year now and its been great.  The builtin
serial port is sufficient (although better performance may be achieved
through the Deluxe RS-232 pack and version 2 of OS-9).  Make a DIN to DB25
connector thus:

	DIN		DB25
	---		----
	xmt data	RD (pin 3)
	rcv data	TD (pin 2)
	signal ground	GND (pin 7)
	carrier detect	DCD (pin 8)

Sorry, I don't remember the signal assignments on the DIN plug.  Depending
on the terminal you might need to use RTS(pin 4) or DSR(pin 6) instead of
DCD(pin 8).

Now, any of the following commands under OS-9 will start a process under the
control of the serial port (which is called /T1 when not being used with
printer):

	shell >/t1 </t1 >>/t1	* to pass control to the terminal
	shell >/t1 </t1 >>/t1 &	* to still have control at the keyboard
	tsmon /t1		* to require users to login

If you know Unix this probably looks familiar -- no?  ">>" redirects stderr
instead of appending stdout.  SHELL is the name of the shell rather than "sh"
or "csh".  TSMON is the equivalent of "getty" I presume.

Unfortunately, the device driver that Radio Shack wrote for /T1 will only
read characters reliably up to 300 or 600 baud.  Above that, input gets
severly garbled.  I believe this is because the driver continuously must
poll the receive data line and it can only do it so fast before trashing the
response time of the whole machine (or the rest of the machine trashing the
response time of the driver).

Fortunately, in the May 1984 (1985?) issue of Rainbow Magazine a user
submitted an interrupt-driven version of the RS232 driver which requires the
user to tie the reeive data pin to the data carrier detect pin and takes
advantage of the the carrier detect pin's ability to generate interrupts (I
won't go into more detail than that, read the article).  This lets you go
all the way up to 19200 baud through that silly bit-banger port and it
works!!!  There is occasional garbage at 19200 so I use 9600.


-- 
Norm Pritchett, The Ohio State University
BITNET: TS1703 at OHSTVMA	Bellnet: (614) 422-0885
UUCP: cbosgd!osu-eddie!pritch	CSNET: pritch@ohio-state
ARPANET: NPRITCHETT%osu-20@ohio-state (or) pritch@ohio-state