Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!ames!haven!decuac!e2big.mko.dec.com!bacchus.pa.dec.com!decwrl!apple!motcsd!mcdcup!mcdchg!chinet!les From: les@chinet.chi.il.us (Leslie Mikesell) Newsgroups: u3b.tech,comp.sys.att Subject: Re: EPORTS & TB+ Message-ID: <1990Aug10.170043.8799@chinet.chi.il.us> Date: 10 Aug 90 17:00:43 GMT References: <1990Aug01.164029.3251@chinet.chi.il.us> <1990Aug3.040126.17331@robohack.UUCP> <1990Aug9.113122.8696@nebulus.UUCP> Organization: Chinet - Public Access UNIX Lines: 29 In article <1990Aug9.113122.8696@nebulus.UUCP> dennis@nebulus.UUCP (Dennis S. Breckenridge) writes: >Well the problem is obvious. The 3B2 driver is not as generic as one >would like. Some of the driver code lives on the 3B2 side of the world >and most of the "low level" code lives on the ports card itself. It is >easy to say, if I had the source I could fix it. There are many more >constraints than just broken software. The ports card is driven by it's >own heartbeat and interrupts are serviced on a hardware priority. What >really has to happen is the hardware has to be modified, and then a driver >must be DESIGNED post facto. Why would any hardware have to be modified to make software flow control work? Are you saying that the on-board 80186 can't see the characters that are transfered into the 3B2 memory, or that the 3B2's ioctl's can't pass information to the 80186 when the modes are changed? The obvious thing to do is to let the on-board CPU deal with both types of flow control and unless something is really wierd it should be possible in software. >[...] If it was economical to repair or >resdesign do you not think that other companies would have cloned the card >and fixed the driver? No. Why should they? But you might note that the 80386 ports expansion almost works right. Is this due to having to compete with equivalent reasonable products or did the whole thing come from an outside source? Les Mikesell les@chinet.chi.il.us