Date: Mon, 10 Aug 92 09:10:46 EST From: Dwight D. McKay (The Moderator) Reply-To: Suns-at-Home@orchestra.ecn.purdue.edu Subject: Suns-at-Home Digest V5 #31 To: Suns-at-Home-List Suns-at-Home Digest Mon, 10 Aug 92 Volume 5 : Issue 31 Today's Topics: 3/60 Expansion Connector? SUN 3/50 +--------------------------------------------------------------------+ | Submissions: suns-at-home \ @orchestra.ecn.purdue.edu | | Requests: suns-at-home-request > -- or -- | | Archives: suns-at-home-archives / ...rutgers!pur-ee!... | +--------------------------------------------------------------------+ ---------------------------------------------------------------------- Date: Mon, 10 Aug 92 09:51:29 +0200 From: P.H.A.Venemans@research.ptt.nl (Venemans P.H.A.) Subject: 3/60 Expansion Connector? To: Suns-at-Home@orchestra.ecn.purdue.edu Has anyone ever tried to discover what signals are on the expansion connector of a 3/60 main board? (the connector for the optional colour frame buffer). I would guess it contains some sort of native 68020 signals (address/data lines, AS, UDS, LDS, DTACK etc), maybe it is even a VME-like bus such as on the 2/50. I might be able to find out by running the CPU in tiny loops and probing the connector pins with an oscilloscope, but that will take hours or even days. So, any information on this matter is appreciated. If it contains 68020-like signals, it should not be too hard to design some interface logic to connect a standard PC card, a Tseng SVGA video board for example. That interface logic would only need to do some basic address decoding and DTACK generation (as long as no interrupts are used). Can anyone more knowledgeable comment on this idea? Thanks ! --- Pieter H.A. Venemans - Royal PTT Netherlands N.V. - PTT Research P.O.Box 421 - 2260 AK Leidschendam - the Netherlands Email: P.H.A.Venemans@research.ptt.nl phone: +31 70 3325556 ------------------------------ Date: Mon, 3 Aug 92 21:30:51 CDT From: matt@severian.chi.il.us (Matt Crawford) Subject: SUN 3/50 To: malcolm@NUTMEG.NTU.EDU.AU Malcolm, You are correct in your assumptions. ms=crtscts causes the CPU (actually the Zilog 8530 serial chip) to obey CTS as a signal to resume or stop output. You can set ixoff (see man termio) to use XON/XOFF on input -- but if it's the 8530's 2 character FIFO that's overflowing due to tardy interrupt servicing, this won't help. Plus, I doubt that your modem can do CTS flow control in one direction and XOFF/XON in the other. SLIP has less overhead in the interrupt service routine per character received. This may prevent the lost characters. If it doesn't, then the retransmission algorithm of TCP will come into play and things will probably go from bad to worse, since if a given packet of bytes couldn't be handled the first time, it will probably choke the second time too. It's definitely worth getting compressed-slip ("cslip") instead, to cut the TCP+IP header sizes down. Try this with compression disabled as well as enabled in your modem and see if the compression causes delays that wipe out your gains. Matt Crawford ------------------------------ End of Suns-at-Home Digest ******************************