mirror of
https://github.com/PDP-10/its.git
synced 2026-02-26 08:53:29 +00:00
Documentation for the ML CH10 Chaosnet interface.
From CHAOS; ARC 1.
This commit is contained in:
2
Makefile
2
Makefile
@@ -32,7 +32,7 @@ DOC = info _info_ sysdoc sysnet syshst kshack _teco_ emacs emacs1 c kcc \
|
||||
xfont maxout ucode moon acount alan channa fonts games graphs humor \
|
||||
kldcp libdoc lisp _mail_ midas quux scheme manual wp chess ms macdoc \
|
||||
aplogo _klfe_ pdp11 chsncp cbf rug bawden llogo eak clib teach pcnet \
|
||||
combat pdl minits mits_s
|
||||
combat pdl minits mits_s chaos
|
||||
BIN = sys2 emacs _teco_ lisp liblsp alan inquir sail comlap c decsys \
|
||||
graphs draw datdrw fonts fonts1 fonts2 games macsym maint imlac \
|
||||
_www_ hqm gt40 llogo bawden
|
||||
|
||||
192
doc/chaos/pdp10.caios
Normal file
192
doc/chaos/pdp10.caios
Normal file
@@ -0,0 +1,192 @@
|
||||
PDP10 CAIOS 2037 EDT Saturday, 10 July 1976 DAM
|
||||
|
||||
It seems more reasonable for ML to have an interface on it directly
|
||||
than to use e.g. a crufty DL10. Maybe other 10s want to go direct, also?
|
||||
|
||||
What needs to be done to attach a caios net interface directly
|
||||
to a pdp10 I/O bus, rather than via an 11.
|
||||
|
||||
Both ML and MC have open-collector type TTL I/O buses. The cable
|
||||
requirements are a little different, but otherwise they appear to
|
||||
be about the same. The ML one terminates in the Morton box. The MC one
|
||||
starts at the impterface and doesn't go anywhere at the moment.
|
||||
Probably two cables could be arranged that presented the same interface
|
||||
at one end, and at the other end one had DEC connectors with the ML
|
||||
pinout, and the other had Augat-board connectors with the MC pinout.
|
||||
As far as I know AI doesn't have a TTL I/O bus (i.e. a set of level
|
||||
converters designed for more than one device.) Should it be given
|
||||
one or should it work through one or more pdp11s? DM has one, but
|
||||
who cares?
|
||||
|
||||
[F once said something about using tristate for the MC TTL I/O
|
||||
bus, but according to the prints it's unibus-style open collector.]
|
||||
|
||||
Putting a caios net interface on a 10 seems pretty easy since it needn't
|
||||
use DMA or even hairy interrupts; as on the 11 the data can be copied
|
||||
in and out of the buffer under program control. The data probably ought
|
||||
to go in and out in 32 bit chunks rather than 16. One problem is there
|
||||
is no SSYN on the I/O bus. The receive and transmit buffers shift one
|
||||
bit each tick of the 8 MHz clock, so it would take 4 micro seconds to
|
||||
do it. On the transmit side, a DATAO AOBJN loop might possibly be too
|
||||
fast, although there is supposed to be only one I/O bus operation every
|
||||
4 micro seconds (is this true on the KL? I seem to recall some "fast
|
||||
I/O bus" option.)
|
||||
|
||||
On the receive side, the way the current interface works is when
|
||||
the 11 reads from CAIRBF, it stalls the 11 while the bits are shifted
|
||||
out of the RAM into the 16-bit shift register, then when the bits
|
||||
are in the shift register gives SSYN. On a pdp10 the processor would
|
||||
expect the bits to be there 1 usec after it gave the DATAI signal,
|
||||
which isn't enough time. One possibility is to change the design
|
||||
so the bits shift after the DATAI instead of before. Then the first
|
||||
DATAI would input garbage, but initiate shifting in of the first data
|
||||
word which the second DATAI would pick up. Again, if the 10 was in
|
||||
a DATAI AOBJN loop it might DATAI faster than the interface could shift
|
||||
the bits over.
|
||||
|
||||
One way to add delay to insure that the 10 doesn't DATAI or DATAO
|
||||
too fast is to require a CONI in that loop. The receive side might
|
||||
want one anyway so it could check whether it had read the whole message
|
||||
yet.
|
||||
|
||||
Another detail is the pdp11 versus pdp10 byte reversal lossage. I
|
||||
suggest there be a CONO'able flag which controls multiplexors to and
|
||||
from the I/O bus so that the 10 can select either to have the bits
|
||||
in correct order for 16-bit bytes or for 8-bit bytes. So it would
|
||||
read or write the header of a packet in 16-bit mode, switch to 8-bit
|
||||
mode for the data, and switch back to 16-bit mode for the trailer (the
|
||||
destination/source/crc words). All this time it would be transferring
|
||||
32 bits on each I/O bus cycle.
|
||||
|
||||
Another problem is that the source my# kludge which works by
|
||||
putting the number on the unibus and reading it back wouldn't work
|
||||
because of the 32 bit words (maybe other reasons, too.) This could
|
||||
be changed. E.g. a "last word" CONO bit which is set before the
|
||||
DATAO. Then the 10 can DATAO a word with the destination # in the
|
||||
high 16 bits and the hardware can fill in the source # in the low
|
||||
16 bits.
|
||||
|
||||
There needn't be any provision for the 10 to send or receive messages
|
||||
not a multiple of 32 bits long. Actually, messages will be a multiple
|
||||
of 32 data bits + 32 bits of source and destination addresses + 16 bits
|
||||
of CRC check word + the 1 "overhead" bit. That extra 1/2 word will
|
||||
cause a little bit of trouble.
|
||||
|
||||
Detailed comments on each drawing:
|
||||
|
||||
11CON - entirely replaced by pdp10 I/O bus control logic. CONI =
|
||||
11RCSR in the right half, 11RRBTCT in the left half. CONO = 11WCSR.
|
||||
DATAI = 11RRBUF. DATAO = 11WTBUF. This does not allow any way
|
||||
to read MY#, does not allow for a programmable clock, and does not
|
||||
allow for the 11SCTRL operation which is not used anyway. I don't
|
||||
think any of these are problems. This drawing would get a good
|
||||
deal simpler.
|
||||
|
||||
CPINS - replace by pdp10 TTL I/O bus pinout, which is pretty much
|
||||
whatever we choose. E.g. the connector pins on an Augat PG21.
|
||||
|
||||
DATAPA - Similar, but 36 bits of I/O bus tranceivers. The input
|
||||
multiplexors need to be for DATAI vs CONI, and for 16-mode vs 8-mode
|
||||
for DATAI. There need to be output multiplexors for 16-mode vs
|
||||
8-mode on DATAO and for substituting MY# in the second 16 bits
|
||||
of DATAO of the last word. Apparently DM8838's are the right
|
||||
thing to use for the bus tranceivers.
|
||||
|
||||
DETECT - unchanged
|
||||
|
||||
ICON - replaced by pdp10-style interrupt control. A 3-bit PIA
|
||||
register, an open-collector 1-of-8 decoder to drive the PI lines,
|
||||
and the PI RQ = (RDONE and RIEN) or (TDONE and TIEN) gate are all
|
||||
that's needed. There's no need to hack channel 1 multiplex (KA)
|
||||
nor vector interrupt (KL).
|
||||
|
||||
MODULA - unchanged
|
||||
|
||||
MY# - unchanged
|
||||
|
||||
MYTURN - unchanged
|
||||
|
||||
PROGCK - delete
|
||||
|
||||
RBUF - change the shift register to 32 bits. Change the ^ROWEND signal
|
||||
to come from 5-bits over in the counter (this may require a modest
|
||||
amount of hair?) Also, when taking out the CRC, ^ROWEND has to come
|
||||
after only 16 bits instead of 32.
|
||||
|
||||
RCTL - no dependency on 11RRBTCT (this is only there to delay SSYN
|
||||
if the 11 reads the bit count while it's changing). Change it so
|
||||
that ^ROCLK doesn't start clocking until after the DATAI has finished.
|
||||
Maybe hair to detect another DATAI too early, while the ^ROCLK is
|
||||
still clocking, and set a CONI error bit?
|
||||
|
||||
TBUF - change the shift register to 32 bits. Change the ^TIWEND signal
|
||||
to be every 32 bits instead of every 16, except when shifting in the CRC
|
||||
it's going to need to go off after only 16.
|
||||
|
||||
TBUFIN - unchanged except get rid of the 11RMY# hair. Add (on some
|
||||
other drawing like 10CON or DATAPA) a last-word-in flip flop which enables
|
||||
the DATAO multiplexor to plug in the MY#.
|
||||
|
||||
TCLK - unchanged
|
||||
|
||||
WRDBTS - changed to the following:
|
||||
|
||||
DATAO (16 mode)
|
||||
4.9-3.3 first 16 bit word
|
||||
3.2-1.5 second 16 bit word
|
||||
1.4-1.1 ignored
|
||||
|
||||
DATAO (8 mode)
|
||||
4.9-4.2 first 8 bit byte (low half of first word)
|
||||
4.1-3.3 second 8 bit byte (high half of first word)
|
||||
3.2-2.4 third 8 bit byte (low half of second word)
|
||||
2.3-1.5 fourth 8 bit byte (high half of second word)
|
||||
1.4-1.1 ignored
|
||||
|
||||
DATAI (16 mode)
|
||||
4.9-3.3 first 16 bit word
|
||||
3.2-1.5 second 16 bit word
|
||||
1.4-1.1 zero
|
||||
|
||||
DATAI (8 mode)
|
||||
4.9-4.2 first 8 bit byte (low half of first word)
|
||||
4.1-3.3 second 8 bit byte (high half of first word)
|
||||
3.2-2.4 third 8 bit byte (low half of second word)
|
||||
2.3-1.5 fourth 8 bit byte (high half of second word)
|
||||
1.4-1.1 zero
|
||||
|
||||
CONO
|
||||
1.1-1.3 jam into PIA
|
||||
1.4 1 => set TDONE
|
||||
1.5 ignored
|
||||
1.6 jam into TIEN
|
||||
1.7 1 => 11 SAYS GO
|
||||
1.8 ignored
|
||||
1.9 jam into RIEN
|
||||
2.1 jam into MATCH ANY DEST
|
||||
2.2 1 => next DATAO is last word, 0 => not.
|
||||
(this is the destination, source address word)
|
||||
2.3 0 => 16 mode, 1 => 8 mode
|
||||
2.4 1 => INIT
|
||||
2.5-2.9 ignored
|
||||
|
||||
CONI 1.1-1.3 PIA
|
||||
1.4 TDONE
|
||||
1.5 TBSY
|
||||
1.6 TIEN
|
||||
1.7 RDONE
|
||||
1.8 RACT
|
||||
1.9 RIEN
|
||||
2.1 MATCH ANY DEST
|
||||
2.2 1 => next DATAO is last word
|
||||
2.3 0 => 16 mode, 1 => 8 mode
|
||||
2.4 CW
|
||||
2.5 CRCERR
|
||||
2.6 TABORT OF LAST MSG
|
||||
2.7-2.8 zero
|
||||
2.9 sign of RRBTCT (1 => next DATAI is last word)
|
||||
3.1-3.4 LOST COUNT
|
||||
3.5-3.6 zero
|
||||
3.7-4.9 RRBTCT
|
||||
|
||||
|
||||
Reference in New Issue
Block a user