Noel Chiappa wrote: 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