Noel Chiappa wrote:
> My memory of the CONS machine is that, like the Chess Machine, it was
> a special purpose CPU hung off the AI PDP-10. (Or maybe the Chess
> Machine was attached to MC? I forget.)
Would that Chess Machine be the one called CHEOPS?
And oh, since I may have the attention of LispM hackers, I'll take this
opportutity to ask what CAIOS was? It seems intimately related to
Chaosnet. Maybe an earlier name for Chaos, or a Chaosnet hardware device?
CHAOS;ARC 1 contains some interesting bits, not that they make it
clearer. Early name for Chaos?
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
