Date: Sat, 22 Nov 1997 10:06:51 +0100 (CET) From: hm@kts.org (Hellmuth Michaelis) To: walter@fortean.com (Bruce M. Walter) Cc: garyj@muc.de, freebsd-hackers@freefall.FreeBSD.org, isdn-dev@hcs.de Subject: Re: Ascend NetWarp 128 ISDN TA Message-ID: <m0xZBWd-00024IC@bert.kts.org> In-Reply-To: <Pine.BSF.3.95q.971121172702.14316A-100000@callisto.fortean.com> from "Bruce M. Walter" at "Nov 21, 97 05:38:30 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce M. Walter wrote: > > >Is anyone working on a driver for the Ascend NetWarp 128 ISDN Terminal > > >Adapter? [i'm rearranging the order of your mail a bit] > 2) The card is PnP and based on the Siemens 2086/2091/82525 chipset. In > fact, these are about the only chips on the card at all. The 2086 is the ISAC, it is used to interface the ISDN line with the rest of the system, the 2091 is an Echo Cancellation Circuit, no idea what it is used for here and the 82525 is the HSCX used to interface to the B channel. Databooks for these chips are available from: http://www.siemens.de/Semiconductor/products/ICs/33/33036.htm All passive cards currently supported by bisdn and the upcoming isdn4bsd are based on the Siemens HSCX/ISAC combination, so once you know how the interfacing of the chips to the ISA/EISA/PCI bus is done, you are done. Bisdn and isdn4bsd do _not_ support any protocols other than DSS1 (EuroISDN) (and the old 1TR6 in case of bisdn) yet, and this will be most of the work to make the card usable outside Europe. > 3) It claims to support National ISDN NI-1, AT&T 5ESS, NORTEL DMS-100, > EDSI and INS-64 signaling protocols. Yes, this is the same as if a manufacturer of cars would write in it's specs: "This car supports driving on every road in the world" :-) The chipset in question does support the hardware access to the line in order to support the above mentioned protocols, but the protocol support itself will have to be written by someone. I guess, that this card comes with some sort of support software for DOS or Windows or so, and the whole (which is _much_!) protocol handling then is done in this software. You have to write this support from scratch when you want to use this card under another than the supported OS'ses. Since the D channel is 3-layerd, it might be possible to reuse some of the existing protocol support from DSS1 for the US protocols (it basically has 3 layers, in Europe is it I.430, Q.921 and Q.931 - Layer 1 seems to have some differences for the US being "not quite" I.430, Layer 2 seems to be the same but layer 3 has to be written; the difficulty seems that there is not a single protocol but different phone companies with different switches seem to have different protocols in the US). The B channel stays the same everywhere. > 1) It is a passive TA based on the Network Interface model rather than the > Comm Interface model. This makes it an excellent choice to avoid the > latency hit involved in Sync<->Async translation as well as the UART speed > ceiling. It looks like this "interface model" is entirely implemented in the accom- panied software. It is - once the whole protocol support is written for the M$DOS world - very easy to interface the result to a TTY or a network interface inside the hosting OS, but for passive cards this is done in soft- ware. In case you have an active card, the host OS can be presented a _hardware_ interface which look like an UART or a network chip like the ones found on NE2000 or WD/SMC cards, then this interface model is transportable across OS platforms, but this does not seem to be true in your case, since this would require not only the chips you have found on your card, but at least a microprocessor, RAM, ROM and support chips. Hope this helps, hellmuth -- Hellmuth Michaelis hm@kts.org Hamburg, Europe "Those who can, do. Those who can't, talk. And those who can't talk, talk about talking." (B. Shaw)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0xZBWd-00024IC>