On 2010-12-20, Lloyd E. Sponenburgh lloydspinsidemindspring.com wrote:
"DoN. Nichols" fired this volley in
:
Does the control support hardware flow control? The CTS/RTS
lines to tell when to stop and start? Sometimes that will work when
the
software DC1/DC3 (also known as Xon/Xoff) won't.
According to the maintenance documentation, the R2E4 BOSS9 control
doesn't support hardware flow-control.
And the BOSS9 _may_ have some underlying OS that we'd have been familiar
with in the mid-80s, but the OS isn't exposed to the user. There are no
command-line inputs, merely prompts (and darned few of them).
Certainly the BOSS-3 through BOSS-6 did not. The CPU was the
DEC LSI-11, and the OS *was* the control program -- all in ROM.
Ordinarily, one "expects" to load a program that will fit in 12K on the
BOSS9. In that case, no flow-control of any kind is used -- the program
is just buffered. In the direct numeric control mode, it would appear
that DC1/DC3 flow control is the only one available.
However, as Dave's documentation shows, this isn't a "dumb" text-only
protocol with flow control -- there are VRC checks by the control, and
LRC at the end of each block, and STX/ETB headers/footers on each block,
along with the conventional ETX or EOT at the end of the data.
Hmm ... just out of curiosity -- does his documentation show what
kind of serial port chip is used to implement the RS-232 interface? I
know that the BOSS-3 through BOSS-6 used old UART chips (40-pin chips so
fairly easy to identify) and the only thing necessary with those to use
hardware flow control would be to connect the proper pin through a
RS-232 level translator chip (e.g. the MC1488/MC1489 pair (I forget
which is the transmitter and which is the receiver, though I could
always look it up) to the CTS pin of the RS-232 connector. IIRC, when
there was data in the chip which had not yet been read, it would turn
off the CTS pin to stop the flow without CPU involvement.
However, since form an earlier comment about it being run by a
Motroloa 68000 family CPU chip, it is likely that it is using the MC6850
serial port chip (ACIA -- Asynchronous Communications Interface Adaptor)
which required software configuration to honor/manipulate the CTS/RTS
pins.
Does the system have a punched tape reader? If so, it should be
able to stop and start *that* for drip feed, so what you need is an
interface box to make that look like a serial port to the PC.
What Dave mentioned was that by entering a filename of "-1" on the
controller, that it would revert to a dumb XON/XOFF protocol without out
all the other overhead -- useful, I guess, if you're dead-sure your link
is solid, and which would save space and communications time when the
programs consisted of lots of very short lines of code.
That sounds reasonable -- if the system sends a XOFF when it
reaches the end of a line, and an XON when that line has been digested,
that could work.
Hmm ... with a 68000 family CPU -- it theoretically *could*
handle a *lot* of memory (for the time and the task -- up to 16 MB.
(unless is a MC68008, which is limited to an 8-bit wide bus and to a 1
MB address space, IIRC.)
However, I could not make that work; at least it didn't appear to. Until
I build up a protocol analyser to watch what's being exchanged, I'm not
sure what protocol EZLink is actually using when I enter the bare "-" for
a filename, followed by the two "execute" depressions.
Yes -- analyzing it will give you more tools, at least.
Good Luck,
DoN.
--
Remove oil spill source from e-mail
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. |
http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---