Close encounters of the CADR kind

Alfred M. Szmidt ams at
Tue Jan 17 03:04:35 CST 2017

   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
	   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
			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.2	1 => next DATAO is last word
			2.3	0 => 16 mode, 1 => 8 mode
			2.4	CW
			2.5	CRCERR
			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

More information about the cctalk mailing list