smith%nrl-aic@sri-unix.UUCP (10/25/83)
From: Russ Smith <smith@nrl-aic>
This note is a request for info/help/suggestions about a peculiar problem
I've been having with an I/O-board/external-modem setup on an S-100 system.
Background:
I have a GODBOUT (pre-COMPUPRO) Interfacer II serial I/O board
controlling both the console (H-19 with Super-19 PROM at 19200 baud)
and an external RS-232 port (at 1200 baud). A Hayes Smartmodem is plugged
into the external port. The z80 S-100 computer is running at 4Mhz with no
wait states.
Problem:
The above setup allows both a home-grown modem program and MDM712
to call up another machine and do their respective things. However, if
I hang up (using the Smartmodem "ATH") and try to call again strange things
happen...characters are being sent to the modem (modem lights flash on cue
for example when I type "AT" on my terminal and the Smartmodem answers
back with "OK") but no characters are being echoed to my CRT screen.
This would seemingly point to a software problem, but I can't see where.
Why? Below is an outline of the home-grown modem I/O sequence. The routines
to get and put characters have been used in dozens of other programs without
any trouble (and they work fine the FIRST time the program is run).
read both the CRT and modem ports a couple times (initialization)
LOOP FOREVER {
IF a modem character is present THEN
get the modem character and put it to the CRT
ENDIF
IF a CRT character is present THEN
get the CRT character
IF the CRT character is <CTRL-^> THEN exit
ELSE put the CRT character to the modem
ENDIF
ENDIF
}
The above code implements a very simple full-duplex protocol. The CRT
expects whatever gets its characters to echo them back. Indeed, in local
mode the Smartmodem DOES echo them back (lights flash...) but NOTHING
gets put on the CRT. Again, it only happens after I've done something
and then sent "ATH" to the Smartmodem. I should mention that the
Smartmodem is receiving the correct characters since it will dial a
number, etc. The above problem also applies to the much-tested MDM712
modem program. Exactly, the same trouble. Works first time but can't
hangup and try to dial again and expect characters to echo to the CRT.
One other point...when the CRT is directly plugged into the modem
the modem/CRT combination works beautifully at both 1200 and 300 baud.
Absolutely no irregularities...
Bottomline Questions:
Does someone out there know of a peculiarity with the Interfacer or
Smartmodem which could cause this problem? Is there some initialization
sequence (other than just reading a couple characters from both ports)
which you've found is necessary? Has anybody had a similar problem
with either the Interfacer (not really suspected, it's a rock) or the
Smartmodem? Does the Smartmodem do some RS-232 status line twiddling
which it's expecting to be twiddled back at when it hangs up?
HELP!!
Please send any info/help/suggestions directly to me. If it turns out
that there is some strangeness with the Interfacer/Smartmodem that isn't
documented in the manuals, I'll send a follow-up message to the list.
IF YOU HAVE ANY IDEAS, PLEASE RESPOND!
Thanks in advance,
Russ <Smith@nrl-aic>Little.Fleas%hi-multics@sri-unix.UUCP (10/26/83)
From: Gary Little <Little.Fleas@hi-multics>
The initialization you show is rather "magical". How it could
intitalize anything is amazing. The CRT should not need to be worried
about since your monitor or another power up sequence will bring it up
properly -- in fact it may be memory mapped instead of an asynch
controller and would different initialization. BUT, the modem is
guaranteed to need some fancy (not magical) massageing. The process is
as follows:
output reset code to async controller (hex 03 for a MC6851)
output clock, parity, framing bits, and data size to controller
(clock = 1/1, 1/16, 1/64)
(parity = odd, even, none)
(data size = 7 or 8 data bits)
(framing bits = number of start, stop bits)
output interrupt status (on/off, hi to low, low to hi, etc.)
NOW you can read the port "ah cupple times". Resetting the port should
drop DTR, CTS, RTS, and maybe even DCD. The Hayes will probably respond
to one of these changing state. IF that don't work then try sending a
break:
output break code to port
do for 200 milliseconds
end do
perform standard port initialization
More than likely toggling DTR will do the trick.
Gary Little