FFFFFFFF FF an ISDN CAPI FOSSIL driver ccc FF ooooo sssss cc FFFF oo oo ss by Martin Winkler & cc FF oo oo ssss Christoph Lueders ccc FF ooooo ss ssssssssssssssssssssssss from Zaphods BBS, Bonn/FRG --- Documentation --- cFos, Version 0.97h, Release date 06-Mar-1994 0. Distribution Files README Einfuehrung REGISTER.DOC Wie erhalte ich eine registrierte Version? REGISTER.ENG How to obtain the registered Version? COPYING.CF Nutzungsbedingungen WHATSNEW Was hat sich geaendert? CFOS.DOC Diese Dokumenation MODEM.DOC Uebersicht ueber die "Modem" Kommandos CFOS.FAQ Frequently asked questions zu 'cFos' CFOS.EXE 'cFos' executable FILE_ID.DIZ Kurzbeschreibung fuer Mailboxen 'cFos' wird ab Version 0.97g als ZIP-Archiv mit AV ausgeliefert. Die PKZIP AV (=Authencity Verification) ist eine Art Siegel, welches sofort zerbricht, wenn man Files in dem Archiv aendert, loescht oder hinzufeugt. D.h. das 'cFos' Archiv ist nur echt, wenn nach dem Auspacken folgendes steht: 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴캠 � This is an original cFos distribution, iff the above lines read: � � � � Authentic files Verified! # MFA364 � � Zaphods BBS � � � � If they do not, try to get an original version, e.g. at � � Zaphods BBS, ISDN +49-228-9111041, fido 2:2453/30. � 突袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴暠 Inhalt: Einfuehrung . . . . . . . . . . . . . . . . . . . . . . . . . 1 Features at a glance . . . . . . . . . . . . . . . . . . . . 2 'cFos' Command Line Parameter . . . . . . . . . . . . . . . . 3 AT Command Emulator . . . . . . . . . . . . . . . . . . . . . 4 Aktiver Verbindungsaufbau . . . . . . . . . . . . . . . . . . 5 Passiver Verbindungsaufbau und Protokollauswahl . . . . . . . 6 Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 7 Safety/Debug features . . . . . . . . . . . . . . . . . . . . 8 Blockgroessen und Speicherbedarf . . . . . . . . . . . . . . 9 Windowsizes, die ultimative Speed . . . . . . . . . . . . . . 10 'cFos' als Multiport Fossil . . . . . . . . . . . . . . . . . 11 'cFos' Channel Bundling (CCB) . . . . . . . . . . . . . . . . 12 Vertraeglichkeit von 'cFos' mit bestehender Software . . . . 13 ISDN Hardware/Software . . . . . . . . . . . . . . . . . . . 14 Verschiedenes . . . . . . . . . . . . . . . . . . . . . . . . 15 Addressen, Autoren, Verfuegbarkeit . . . . . . . . . . . . . 16 Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 End of Documentation; Thanx for using 'cFos'. . . . . . . . . 18 Anhaenge: CAPI Fehlermeldungen . . . . . . . . . . . . . . . . . . . . A Format der V.110 User Rate (ATS27) . . . . . . . . . . . . . B B2-Frames und Windowsizes bei X.75 . . . . . . . . . . . . . C Connect Probleme mit ISDN Blaster (X.75) . . . . . . . . . . D Connect Probleme zu ELINK "Modems" . . . . . . . . . . . . . E CCB mit mehreren S0-Bussen unterschiedlicher Rufnummer . . . F 'cFos' Modem Fehlermeldungen . . . . . . . . . . . . . . . . G Vertraeglichkeitsliste . . . . . . . . . . . . . . . . . . . H 1. Einfuehrung: 'cFos' ist ein FOSSIL Treiber, der mittels eines Modememulator mit AT Command Set und unter Zuhilfenahme eines CAPI Treibers, nach Version 1.1, Profil A eine grosse Anzahl an existierender Software auch fuer ISDN nutzbar macht. Da ISDN mehr ist, als nur ein Netz fuer High-Speed Datenuebertragung, ist es unser Ziel, moeglichst viele Moeglichkeiten des ISDN durch 'cFos' auf einfache Weise zugaenglich zu machen. 'cFos' gibt es auch in einer registrierten Version, die man bei uns lizensieren kann. Zeilen, die mit einem {+} gekennzeichnet sind, beziehen sich auf diese registrierte Version. Weiteres ueber diese "geheimnisvolle" registrierte Version steht in REGISTER.DOC. 'cFos' braucht mindestens einen 286er AT Class Computer. 2. Features at a glance: * Laueft mit jeder Karte, die ein ISDN CAPI, V1.1, Profil A hat. * Unterstuetzt FOSSIL, Revision 5 (nach FSC-0015) mit einigen Erweiterungen. * Unterstuetzt mehrere B-Kanaele gleichzeitig, wahlweise mit automatischem Ringdown. MultiPort Mode. * Laueft alleine oder in Zusammenarbeit mit "standard" RS-232 FOSSILs. * Eingebauter BIOS-Emulator, sodass auch Programme, die nur INT 14 unterstuetzen, betrieben werden koennen. * 'cFos' ist schnell! Man erreicht bei Windowsizes >= 2 Daten- uebertragungsraten bei X.75 von 7900 cps pro Kanal und mehr. * 'cFos' enthaelt einen Modem-Emulator, mit dem nicht nur alle Modem-Meldungen und Kommandos nachgebildet werden koennen, sondern auch alle ISDN-spezifischen Parameter eingestellt, gespeichert und damit ueberhaupt erst genutzt werden koennen. * 'cFos' kann eine Statuszeile anzeigen, in der alle ISDN Verbindungsparameter angezeigt werden und zusaetzlich "Modem LEDs" fuer Carrier Detect, Off Hook, Transmit Data, Receive {+} Data. In der registrierten Version wird die Dauer der der aktuellen Gebuehreneinheit zusaetzlich noch angezeigt (Toll Saver). * Unterstuetzung fuer SPV's (semipermanente Verbindungen). * Unterstuetzung fuer fast alle B2 und B3 Protokolle, z.B. X.75 und V.110. * Unterstuetzt TELES Channel bundling protokoll, 128kbps ueber 2 B-Kanaele. * Safety inactivity und connect timers, um den Gebuehren-"GAU" zu verhindern. 'cFos' enthaelt speziellen Code, um evtl. auf- tretende Fehler im CAPI/ISDN-Netz abzufangen. * Die Time/Date Info des ISDN kann ausgewertet werden und danach {+} die lokale Rechnerzeit. Zusaetzlich kann die Uhrzeit eines NetWare Servers gesetzt werden. * 'cFos' kann UMBs benutzen, um seine Daten abzulegen. {+} * 'cFos' hat nun eigenes CHANNEL BUNDLING ! Das 'cFos' eigene Channel Bundling (CCB) ist herstellerunab- haengig und unterstuetzt bis zu 4 B-Kanaele - auch mit mehreren ISDN Karten gleichzeitig. Darueberhinaus laesst es sich beliebig mit dem MultiPort Mode kombinieren, z.B. 2 Ports buendeln gleichzeitig je zwei Kanaele. 'cFos' schafft mit zwei B-Kanaelen 15800 CPS, mit drei B-Kanaelen 22500 CPS und mit vier B-Kanaelen 30000 CPS !!! Das '{+}' Symbol weist auf Funktionen hin, die nur in der registrierten Version verfuegbar sind. 3. 'cFos' Command Line Parameter: 'cFos' kennt folgende Commands: i Install. Installiert 'cFos' als TSR im PC Speicher; dazu muss natuerlich schon das CAPI geladen sein (wird angewarnt, falls nicht). Alle Switches muessen beim Laden angeben werden. Spaeteres Aufrufen wirkt nur bei speziellen Commands (z.B. 't' oder 'bps'). d Deinstall. Deinstalliert 'cFos' und gibt damit auch allen Speicher von 'cFos' wieder frei. Bitte ERST 'cFos' und DANN das CAPI deinstallieren. Mit dem Deinstallieren werden alle bestehenden Verbindungen, die ueber unser FOSSIL laufen, getrennt. r Reregister. Re-registriert 'cFos' am CAPI. Damit kann das CAPI neu initialisiert werden. Auch hier werden alle Verbindungen getrennt. Mit diesem Aufruf werden einige CAPI-Strukturen wieder neu initialisiert. t Tranx. Synchonisation der Rechner-Uhr mit der Zeit, die im ISDN verfuegbar ist. Fuer eine weitere Erlaeuterung siehe weiter unten. {+} bps Baud (Bit per second). Die Baudrate der z.Z. laufenden Verbindung wird in die Environment Variable BPSRATE geschrieben. Auf diese Weise steht sie zur Auswertung in Batch Files (z.b. beim Aufruf von BBS Software) zur Verfuegung. Hinter dem Kommando kann die Portnummer angegeben werden, z.B. 'cfos bps:2'. reboot Die FOSSIL Definition sieht eine Reboot Funktion vor, die auch auf der Commandline verfuegbar ist. Vor dem Rebooten werden erst die offenen Files aller DOS Applikationen geschlossen, dann werden die Cache Buffers folgender Caches geflushed: QCache, Super PC Kwik, PC Tools PC-Cache 5.x & 6.x, Qualitas Qcache 4.00, Norton Utilities NCACHE, SMARTDRV v4.00+ und HyperDisk 4.50+. Danach wird der Rechner via Keyboard Controller gebootet. und folgende Switches: -b Maximale B2-Framelen Maximale im Modem-Emulator anwaehlbare B2-Framelen, Default = 2048 Bytes -w Maximale Windowsize Maximale im Modem-Emulator anwaehlbare B2-Windowsize, Default = 2 Mit diesen beiden Optionen wird festgelegt, wieviel Speicher beim Installieren fuer das CAPI reserviert wird. Mittels ATS22=xxxx und ATS26=x kann danach natuerlich auch ein kleinerer Wert fuer die naechste Verbindung eingestellt werden, allerdings kein groesserer. -c Portnummer (Default 0) (default 0, ein Port), 0 = COM1, 1 COM2, ... -c kann mehrfach angegeben werden. Diese Einstellung der Ports ermoeglichst das Zusammenspiel von 'cFos' mit einem RS232 FOSSIL auf einem Rechner. 'cFos' ueberprueft bei jedem INT 14h Aufruf, ob es diese Port Nummer unterstuetzen soll. Falls nicht, wird der "darunter liegende" INT 14h aufgerufen. Laedt man vor 'cFos' ein RS 232 Fossil, kann dieses den entsprechenden RS-232 Port betreiben. -e Enable BIOS emulator (Default 1) 0 = Off, 'cFos' arbeitet nur als FOSSIL. 1 = On, 'cFos' arbeitet als FOSSIL und als BIOS INT 14h damit koennen auch Programme, die zwar kein FOSSIL, aber BIOS INT 14h benutzen, ISDN betreiben. 2 = Force on, 'cFos' arbeitet nur als BIOS Emulator. Empfehlung fuer Programme die BIOS INT 14h auf PS/2 Rechnern, oder andere INT 14h Erweiterungen benutzen. Es werden die INT 14h Funktionen 4-1B deaktiviert. Bemerkung: Da 'cFos' zur Zeit die '+++' Sequenz zum Auflegen nicht unterstuetzt, legt die "set baudrate" BIOS Funktion (INT 14h) auf - allerdings nur, wenn der BIOS-emulator auf on geforced wurde (-e2). Das ist ausser der FOSSIL Funktion 6 (raise/lower DTR), die einzige Moeglichkeit aufzulegen. -f fast-event, Einstellung der Datenreceiver-Strategie. 1 = Das Kopieren der Daten in den FOSSIL Receiverbuffer uebernimmt die Applikation Vorteil : Man braucht fast keinen Speicher mehr fuer den FOSSIL Receiver Buffer Nachteil : Bei langsamen Applikationen kann die Uebertragunsgeschwindigkeit etwas sinken. 0 = Das Kopieren der Daten in den FOSSIL Receiverbuffer uebernimmt der CAPI-Eventhandler (default) Vorteil : Leichte Speedvorteile bei langsamen Applika- tionen Nachteil : Man brauch einen entsprechend grossen FOSSIL Receiver Buffer. -r rxbufsize, Groesse des Receiverbuffers Falls 'cFos' mit -f0 geladen wurde, ist die Default-Groesse gleich B2-Framelen * (Windowsize + 1) Bytes. Laedt man 'cFos' mit -f1, ist hier der Default 256 Bytes. -t txbufsize, Groesse des Transmitterbuffers Default ist B2-Framelen * (Windowsize + 1) Bytes. -v CAPI Interrupt Nummer, default 0xF1 = 241. {+} -a Auxiliary Port, samt Controller Nummer (z.B. -a1). Fuer die registrierte Version von 'cFos' kann man so fuer 'cFos' Channel Bundling (CCB), d.h. Datenuebertragung auf mehreren ISDN B-Kanaelen gleichzeitig, sogenannte Auxiliary Ports aktivieren. Wird hinter einer Zahl ein 'k' angegeben, wird der Wert in K (=1024) gerechnet. -r4k bedeutet z.B. 4096 bytes Receiverbuffer. Alle Werte koennen auch in Hex angegeben werden, dazu muss nur ein '0x' vor die Zahl, also z.B. 0x800 fuer 2048. zusaetzliche -j Flags: -j3 Disable 386er Support. -jc Carrier LED. Hierbei wird die sCrollLock LED als Carrier LED missbraucht. Solange eine Verbindung besteht, ist diese LED an und solange ein einkommender Ruf weder angenommen noch abgelehnt ist, blinkt sie. Vorsicht bei Programmen, die ScrollLock fuer andere Zwecke benutzen (z.B. das FrontDoor Terminal); diese springen darauf dann auch an. {+} -jd Data Dump. Wenn dieses Flag angegeben ist, protokolliert 'cFos' alle empfangenen und alle gesendeten Daten in eine Datei namens FOSSDUMP, die dann in dem Verzeichnis zu finden ist, in dem sich auch CFOS.EXE befindet. Das dumpen wird erst mit dem Deinstallieren des FOSSILs wieder gestoppt. Der Data Dump benoetigt zusaetzlich 10kb Hauptspeicher. -je Disable environment deallocation. Sollte beim oder direkt nach dem Laden von 'cFos' ein Absturz oder schwerwiegender DOS Fehler auftreten, koennte dieser Switch Abhilfe schaffen. -ji Laedt 'cFos' mit initialisierten COM Ports. Fuer Software, die vergessen sollte, die COM Ports vor Benutzung zu initialisieren. -jn Disable NetWare support. Wenn dieser Switch angegeben wird, wird kein Versuch gemacht, NetWare zu finden oder zu unterstuetzen. -jp Aktiviert passiven Ebene 3 Verbindungsaufbau, um auch den Eigenheiten des ISDN Blaster FOSSILs PCIF Version 5.78 gerecht zu werden (Empfehlung fuer Stollmann und AVM, nicht aber fuer TELES). Sollte bei gegenseitigem PCIF 5.81 (oder hoeher) nicht mehr noetig sein. -jr Disable CAPI Re-Register (noetig fuer SOLIS Karten). -js Ignore seconds in ISDN date/time. Siehe 'TRANX'. -ju UMB Speicherbloecke nicht benutzen. Ansonsten versucht 'cFos', Datenbloecke erstmal im XMS oder UMB abzulegen. -jv Disable V.110. Damit weiss 'cFos', dass das jeweilige CAPI kein V.110 unterstuetzt und gibt z.B. bei ATB1 und ATB2 einen Fehler aus. Ebenso werden Rufe, die V.110 mittels Additional Service Indicator signalisieren, abgelehnt. (s. auch Kapitel 6) -jx Dieser Switch veranlasst 'cFos', bei der Funktion 0x1b die gleichen Werte in CX und DX wie X00 zurueckzugeben. Erforderlich, um mit XBTX zu arbeiten, ansonsten raten wir aber von der Benutzung dieses Switches ab. -d[df] Debugging Trace Wenn diese Switches beim Laden angegeben werden, schreibt 'cFos' eine debug-trace von allen CAPI-Messages mit. Dafuer belegt es 10kb zusaetzlichen Speicher als Buffer und schreibt diesen bei Bedarf auf Platte. Das File heisst CTRACE und liegt in dem gleichen Verzeichnis wie CFOS.EXE. Das File kann schnell sehr gross werden, daher sollte man diese Funktion nur in seltenen Faellen benutzen. Mit -d schaltet man nur das Mitschreiben der CAPI-Messages ein, mit -dd wird noch mehr mitgeloggt und mit -df oder -ddf werden noch zusaetzlich fast alle FOSSIL Aufrufe mitgeloggt. Sollte sich 'cFos' auf Ihrem Rechner sonderbar verhalten, nicht sauber laufen, keine einkommenden Rufe annehmen oder aehnliches, ist es immer gut, uns von dem Problem ein Trace mitzuschicken. Dazu sollte 'cFos' mit 'cfos i -dd' geladen werden und danach auf jeden Fall mit 'cfos d' wieder deinstalliert werden, bevor das CTRACE verschickt oder eingepackt wird. Tranx Beim aktiven Verbindungsaufbau und bei jedem Verbindungsabbau schickt ISDN dem Teilnehmer die aktuelle Zeit (inklusive Sommer/Winterzeit gestellt nach der TU Braunschweig; allerdings ist dieser Service ab Anfang 1994 kostenpflichtig). 'cFos' vergleicht diese Zeit mit der Rechneruhr und stellt fest, um wieviel sich beide Zeiten unterscheiden, stellt die Rechneruhr allerdings nicht sofort, sondern erst auf Anfrage. Wenn man 'cFos' mit der Option 'T' aufruft, holt sich das aufgerufene 'cFos' diese Zeitabweichung von dem residenten 'cFos' (welches seinen alten Wert danach auf 0 setzt) und setzt die Rechneruhr auf den korrigierten Wert. Die Uhrzeit kann auch aus dem Modem-Emulator gesetzt werden mit dem Kommando AT&T. Diese Art und Weise ist wesentlich einfacher und unbedenklicher zu implementieren als jedesmal eine Verbindung aufzubauen, wenn 'cFos' mit 'T' Option aufgerufen wird. Es hat allerdings den Nachteil, dass es nur die Uhrzeit setzt, wenn seit dem letzten 'cfos t' Aufruf Verbindungen vorhanden waren. Soll die Uhrzeit immer gesetzt werden, einfach ein 'at&t' in den Modem Init-String schreiben. Anmerkung: in manchen Ortsnetzen wird die Zeit ohne Sekunden uebermittelt. 'cFos' ist so geschrieben, dass es sich dann innehalb mehrerer Verbindungen an die "richtige" Uhrzeit annaehert. Dieser Modus kann auch forciert werden, dann wird das Sekundenfeld ignoriert, selbst wenn eines mit uebermittelt wurde. Dies kann bei lokalen Telephonanlagen sinnvoll sein. Wird ein NetWare Server erkannt, so wird dessen Zeit auch gesetzt, solange kein -jn Switch angegeben wurde. Allerdings muss der entsprechende User dafuer File Server Console Operator sein, d.h. im SYSCON unter 'Supervisor Options', 'File Server Console Operators' als ein solcher eingetragen sein. 4. AT Command Emulator: Da dieser Treiber ermoeglichen soll, bestehende Software mit ISDN zu benutzen, emuliert 'cFos' ein Modem, das Kommandos wie 'ATD' zum Waehlen und 'AT&V' zum Anzeigen der Konfiguration benutzt. Die gesamte Steuerung des CAPI's und des Verhaltens von 'cFos' geschieht ueber den Modem Emulator. Der Emulator besitzt eine kleine Hilfe, die mit 'AT?' angezeigt werden kann. Eine komplette Aufstellung aller Kommandos und Register findet sich in der Datei MODEM.DOC. Der Receiver-Buffer muss gross genug sein, um den jeweiligen Output des AT Command Emulators zu fassen; z.B. sollte er ca. 2kb gross sein, um eine ganze 'AT?' Screen fassen zu koennen. Stellt man den rx-Buffer beim Laden von 'cFos' zu klein ein (mit -r oder -f1), dann kann bei einigen Ausgabe des Modem Emulators ein 'rx-buffer too small, output lost' erscheinen. Es ist manchmal etwas schwierig, eine neue und wesentlich komplexere Technik wie ISDN in das teilweise recht simple Bild von einem Modem mit seinen Commands und Result Codes zu quetschen, deshalb hier eine Erklaerung, was die Modem Messages bedeuten: - NO ANSWER Heisst, dass die Gegenstelle nicht abgenommen hat, aber der Ruf quasi "bis zu ihrer Telephondose" gekommen ist. Es faellt nur ein 1.TR.6 Cause darunter: 0x34ba: No user responding - NO DIALTONE Heisst, dass 'cFos' nicht bis zu der Gegenstelle durchkommen konnte, und das der Grund dafuer wahrscheinlich beim Anrufer liegt. Gruende waeren: 0x3301: Fehler beim Aufbau D-Kanal Ebene 1 0x3302: Fehler beim Aufbau D-Kanal Ebene 2 0x3305: Abbruch D-Kanal Ebene 1 0x3306: Abbruch D-Kanal Ebene 2 0x3307: Abbruch D-Kanal Ebene 3 0x348a: No channel available 0x34a0: Outgoing calls barred 0x34d9: Nonexistent CUG 0x34f0: Network congestion 0x34a3: Local procedure error - BUSY Heisst, dass wir schon bis zu der Gegenstelle gekommen sind, diese aber entweder aus Ueberlastung oder aktivem Ablehnens unseren Anruf nicht annehmen will. Das waere: 0x34a1: User access busy 0x34bb: User busy 0x34bd: Incoming calls barred 0x34be: Call rejected - NO CARRIER Alle anderen Causes, die einen Connect-Versuch scheitern lassen. Falls hier jemand der Meinung ist, dass ein Cause noch in eine der o.g. Klassen gehoert, bitte melden. Einen Cause meinen wir noch dingfest gemacht zu haben: 0x3483, der kommt, wenn man eine analoge Nummer anruft, waere also mit einem VOICE zu vergleichen, ist aber bisher nicht eingebaut. Ansonsten gibt es z.B. 0x34b5: Destination not obtainable (z.B. "Kein Anschluss unter dieser Nummer" ;-) oder unzulaessige Dienstmerkmale. 0x34f1: Remote Procedure Error (bei der anrufenden Seite liegt ein Fehler vor, z.B. unzulaessiger AddSi) Der Modem-Emulator kann noch eine ganze Reihe andere Commands, die man bitte dem AT Command-Chart in MODEM.DOC entnehmen moege. Gesondert seien hier noch ausfuehrlich die ATIn Commands erwaehnt: Mit ATI0, ATI1, ATI2 und ATI4 koennen mit dem Modem-Emulator Informationen ueber die letzte Verbindung abgefragt werden: - ATI0 product-info - ATI1 'cFos' Status Zeile (s. Kapitel 7) - ATI2 Link Information : Bei "Last inbound call" wird die CallerId, der Requested Service Indicator und der Requested Additional Service Indicator sowie die requested EAZ des letzten Anrufers angezeigt. Bei "Last outbound call" wird unter "Charge" die Anzahl der Gebuehreneinheiten des letzten Anrufs angezeigt. Bei "Last disconnect" wird zum einen der Grund des letzten disconnect angegeben, zum anderen der Reason, den die CAPI messages beim passiven (!) disconnect an 'cFos' melden. "Last disconnect" kann folgende Werte enthalten : Active: 'cFos' wurde von der Applikation aufgefordert zu disconnecten. Passive: die Gegenseite oder das CAPI hat aufgelegt. Disconnect B3 timeout: Der safety timer (s. oben) wurde aktiviert. Disconnect D timeout: Der safety timer (s. oben) wurde aktiviert. CAPI reset: Der safety timer (s. oben) wurde aktiviert und es wurde als letzte Massnahme ein CAPI Reset durchgefuert, (s. oben). Connect timeout: Die in S7 angegebene Zeit beim Verbindungsaufbau wurde ueberschritten. Inactivity timout: Die in S19 angegebene Zeit wurde nichts uebertragen. - ATI4 Message Dump: zeigt die letzten 10 gespeicherten CAPI Messages an, die W-Elemente nach 1TR6 enthalten, ausser der Date/Time- und der Charging-Information. Auf diese Weise koennen z.B. die letzten CallerIDs derjenigen angezeigt werden, die waehrend einer Verbindung "angeklopft" haben. Profile saving: Bei einem normalen Modem werden die Settings mit AT&W in das NVRAM des Modems geschrieben und dort bei einem ATZ auch wieder ausgelesen. Da 'cFos' kein NVRAM hat, werden die Settings in einer Datei auf der Platte gespeichert. Diese Datei liegt bei DOS 3.1+ in dem Verzeichnis, in dem auch 'cFos' liegt, bei DOS <3.1 im dem Verzeichnis, welches bei Aufruf von 'cFos' aktuell war. Das File heisst PROFILE und enthaelt alle Profiles, die man mit 'AT&Wn' abgespeichert hat (n=0..9). Ein entsprechender 'ATZn' holt das Profile wieder zurueck. Wenn keine Nummer angegeben wird, dann speichert/restauriert 'cFos' unter/von Nummer 0. Da fuer das Lesen und Schreiben dieser Datei DOS benoetigt wird, muss 'cFos' anhand z.B. des "DOS critical flags" pruefen, ob zur Zeit DOS Zugriffe erlaubt sind. Wenn nicht, speichert bzw. laedt es das Profile auch nicht und meldet schlicht "ERROR". Ist das Profile nicht gueltig (z.B. wenn es von einer aelteren 'cFos' Version angelegt wurde) wird ebenfalls "ERROR" gemeldet. Ist kein Profile vorhanden, bewirkt ein ATZ da gleiche wir AT&F und meldet "OK". Achtung! Wenn 'cFos' mit mehreren Ports benutzt wird, kann natuerlich auf diese Art und Weise leicht das gleiche Profile fuer alle Ports benutzt werden (wenn alle mit 'ATZ' initialisiert werden). Um das zu vermeiden, sollte man einfach verschiedene Nummern fuer die 'ATZ's vergeben (ATZ0...ATZ9). Bei mehreren Ports werden die Register S13 Serviced EAZ Mask S14 Serviced SI Mask S41 Info-Mask-low S42 Info-Mask-high "gemirrored". Das heisst, wenn ein Port diese Register aendert, dann sind sie auch automatisch fuer alle anderen Ports veraendert. Das geht nur so, da diese Werte immer fuer alle Ports gelten und nicht fuer einen einzelnen. Das ist durch das CAPI bedingt. 5. Aktiver Verbindungsaufbau: Neben der Telefonnummer koennen bei einem Verbindungsaufbau im ISDN diverse Parameter eingestellt werden, um Service und verschiedene Uebertragungsprotokolle auszuwaehlen. 'cFos' ist defaultmaessig auf Datenuebertragung mit X.75 als Ebene 2 Protokoll und transparentem, d.h. nicht vorhandenem, Ebene 3 Protokoll eingestellt. Alle noetigen Parameter koennen von Hand in den Registern S16-S18, S20-S36, S39 und S40 eingestellt werden. Um die Auswahl der wichtigsten Datenuebertragungsprotokolle moeglichst einfach zu gestalten, kann man mit AT Befehlen die folgenden Protokolle einstellen: ATB0 Datenuebertragung mit X.75 und transparentem B3 Protokoll, wobei abweichend vom CAPI-Default, die X.75 Windowsize und Framelength auf die Werte gesetzt werden, mit denen 'cFos' geladen wurde (Optionen -w und -b). Der Additional Service Indicator wird auf 0 gesetzt. ATB1 Datenuebertragung mit V.110 und transparentem B2/B3 Protokoll, 38400,8,n,1,asynchron. Der Additional Service Indicator wird auf 64 (40 hex) gesetzt. ATB2 Datenuebertragung mit V.110 und transparentem B2/B3 Protokoll, 19200,8,n,1,asynchron. Der Additional Service Indicator wird auf 199 (C7 hex) gesetzt. ATB3 Wie ATB0, aber mit Channel- Bundling ( 128k bps). Unter- stuetzt nur TELES channel bundling, NICHT das 'cFos' channel bundling, welches mit AT&Bn aktiviert wird. Ist nur dann verfuegbar, wenn BUNDLE.EXE in STARTS0 geladen wurde. ATB4 ELINK Mode, Datenuebertragung mit X.75 und transparentem B3 Protokoll, wobei abweichend vom CAPI-Default die X.75 Windowsize auf 7 und die Framelength auf 256 Bytes gesetzt wird, falls 'cFos' mit -w7 und mindestens mit -b256 geladen wurde. Ansonsten liefert ATB4 einen Error. Der Additional Service Indicator wird auf 146 gesetzt. ATB5 BTX Mode. Da fuer BTX eine Variante des X.75 Protokolls mit Window-Size 7 benutzt, muss 'cFos' mit -w7 geladen worden sein, sonst liefert dieses Kommando einen "ERROR". Wir empfehlen, diese AT Befehle fuer den Verbindungsaufbau zu benutzen. Man kann aber auch den Verbindungsaufbau durch Setzen der einzelnen Register fuer spezielle Anwendungen anders einstellen. Bei manchem Equipment muss man z.B. den Additional Service Indicator immer auf 0 stellen, sonst nimmt die Gegenseite ueberhaupt nicht ab (z.B. wenn man CompuServe anrufen will). Hier noch Modem INIT Strings fuer spezielle Anrufe: fuer CompuServe und Datex-P Gateways V110, 9600,ansync,7,E,1 ATB0S20=8S27=237 aber fuer DOSCIM ATB0S20=8S27=197 6. Passiver Verbindungsaufbau und Protokollauswahl: Zunaechst muss man dem CAPI durch Setzen der "Serviced SI Mask" "sagen" auf welche ISDN Services und welche EAZs es ueberhaupt "hoeren" soll. Die Services stellt man mit Register S14 ein. Bit 7 = 1 aktiviert beispielsweise eingehende Rufe mit Dienst- erkennung "Datenuebertragung". Bit 1 = 1 aktiviert Rufe fuer "Telefondienst". Die aktiven EAZs kann man entweder durch die entsprechenden Bits in Register S13 setzen oder mit AT&Lxxxx einstellen. AT&L* aktiviert alle EAZs. AT&L123 die EAZs 1, 2 und 3. 'cFos' kennt z.Z. die Dienste "Datenuebertragung" und "Telefondienst". Aktiviert man Rufe mit anderer Dienstkennung, waehlt 'cFos' bei unbekanntem Dienst (Service) die Protokolle und Parameter gemaess der Register S20-S36. Bei eingehenden Rufen mit Dienstkennung "Telefonie" waehlt 'cFos' als B2 Protokoll "Bittransparent" und als B3 Protokoll "Transparent". Somit bekommt man einen Datenstrom mit konstanten 8000 cps mit digitalisierten Analog-Samples. Defaultmaessig ist aber nur "Datenuebertragung" als Service aktiviert. Bei eingehenden Rufen mit Dienstkennung "Datenuebertragung" hat 'cFos' aufgrund des Design des CAPI nur die Moeglichkeit, anhand des Additional Service Indicators die Uebertragungs-Protokolls auszuwaehlen. Eine nachtragliche automatische Aenderung des Protokolls ist nicht moeglich, da es keine Signalisierungsmoeglichkeit fuer das CAPI gibt, mit der es die Protokolle des Anrufers anzeigen koennte, geschweige denn die dazugehoerigen Parameter. Das B3 Protokoll ist immer das in den Registern S21 und S30-S36 voreingestellte, also am besten "Transparent". Das CAPI default 1 (=T.70 NL) wird von fast keiner Mailbox benutzt. Das B2 Protokoll wird anhand des Additional Service Indicators gemaess 1.TR.6 ausgewaehlt. Fuer V.110, 38400 bps, asynchron ist nach 1TR6 ueberhaupt kein Additional Service Indicator vorgesehen. Dieses Protokoll koennen Anrufer bei 'cFos' mit dem Additional Service Indikator 64 bzw. 128 auswaehlen. Aufschluesselung des Additional Service Indikator : 0000 0000 Anrufer wuenscht X.75, 64000 bps 1000 0000 Anrufer wuenscht V.110, 38400,8,n,1,asynchron 01-- -000 Anrufer wuenscht V.110, 38400, asynchron 1010 ---- Anrufer wuenscht V.110, X.30 (ECMA 102), synchron 1011 ---- Anrufer wuenscht V.120, synchron 11-- ---- Anrufer wuenscht V.110, X.30 (ECMA 102), asynchron die zwei wichtigsten : 1100 0111 Anrufer wuenscht V.110, 19200,8,n,1,asynchron 0100 0000 Anrufer wuenscht V.110, 38400,8,n,1,asynchron Ob diese Protokolle vom jeweiligen CAPI unterstuetzt werden, haengt vom Hersteller des CAPI ab. 'cFos' waehlt "V.110 mit transparentem B2-Protokoll" (8). Anrufer, die sich nicht an diese Spezifikation halten, oder mit Telefonanlagen arbeiten, die den Additional-Service Indikator filtern, bekommen es leider u.U. mit mit einem anderen Protokoll, als dem gewuenschten Protokoll zu tun. Da es mit der Protokoll-Auswahl so viele Probleme gibt, haben wir noch ein paar "Specials" in 'cFos' eingebaut: Ist 'cFos' der Additional Service Indicator gaenzlich unbekannt, entscheidet Register S43, welches Protokoll selektiert wird. Das High-Byte selektiert das Protokoll, das Low-Byte ggf. die V.110 User-Rate. Als Default ist Register S43 auf V.110, 38400,8,n,1, asynchron eingestellt, da es mit diesem Modus am meisten Probleme zu geben scheint. Zusaetzlich kann man einzelne EAZs auf bestimmte Protokolle festlegen, falls der Additional Service Indicator gleich 0 ist. Dies geschieht mit den Registern S50-S59 fuer die EAZ 0 bis EAZ 9. Ist das Low-Byte des entsprechenden Registers ungleich Null, wird die EAZ auf das Protokoll festgelegt, das im High-Byte des Registers angegeben ist. Das Low-Byte bestimmt dann ggf. die V.110 User Rate. Ist der Additional Service Indicator ungleich 0, bestimmt obige Aufschluesselung nach 1.TR.6 das Protokoll. Defaultmaessig ist dieses Feature nicht aktiviert. Beispiel: Seien S51 = 0x0 und S52 = 0x0840 und S53 = 0x08C7 und die Serviced EAZ Mask = 14 (man hoert also auf EAZ 1-3); dann werden die Protokolle wie folgt selektiert : EAZ AddSi = 0 AddSi <> 0 1 X.75 gemaess 1.TR.6 2 V.110,38400 gemaess 1.TR.6 3 V.110,19200 gemaess 1.TR.6 Also: Anrufer, die X.75 wollen, koennen auf EAZ 1 anrufen. Anrufer, deren ISDN Karten 1.TR.6 konform sind und die V.110 wollen, koennen auf allen EAZs anrufen. Anrufer, deren ISDN Karten nicht 1.TR.6 konform sind, koennen fuer 38400 auf EAZ 2 anrufen und fuer 19200 auf EAZ 3. 7. Status Line: 'cFos' kann eine Status-Zeile auf dem Bildschirm darstellen, um etwas "Modem-Feeling" zu geben, bzw. fuer Debug-Zwecke. AT&D0 Status-Zeile aus AT&D1 Status-Zeile ein, wenn Port initialized ist AT&D2 Status-Zeile ein, wenn eine Verbindung aktiv ist ATS11=xx Bildschirmzeile, in der die Status-Zeile dargestellt wird (faengt bei 0 an zu zaehlen). Sie ist folgendermassen aufgebaut: Anzahl der Frames, die noch ausstehen. | | Anzahl Frames die gerade gesendet werden | | {+} | | verbleibende Sec. der aktuellen Einheit | | | cFos> C-B3 ACOD 0R:64 0T:1024 C:12 V110 19200 9111041 39 | | |||| | | | | | | connect/ | |||| | | Charge | | Caller ID/ disconnect | |||| | | (Gebuehren- | | dialed number indicator | |||| | | Einheiten) | | (*) | |||| | | | bps rate bei V110 Ebene |||| | | B2-Protocol (z.b. X75) |||| | last transmitted block length, mit TX-"LED" |||| last received block length, mit RX-"LED" Auto-Ans||| ||DTR-"LED" (bei DTR low werden alle Calls rejected) Carrier Detect| Offhook-"LED", an = reject calls (anders als beim modem) Evtl. kann vor dem "R" noch eine Zahl "auftauchen", die dann angibt, wieviele Datenbloecke 'cFos' dem CAPI noch nicht quittiert hat. Vor dem "T" kann ebenfalls noch eine Zahl stehen, die angibt, wieviele Datenbloecke z.Z. unterwegs zum Empfaenger sind. (*) waehrend einer laufenden Verbindung wird hier die Anzahl der aktiven B-Kanaele angezeigt ("B3-1") {+} Bei 'cFos' Channel Bundling (CCB) kann hier z.B. "B3-2" stehen. 8. Safety/Debug features: Zu Anfang etwas gewoehnungsbeduerftig bei ISDN-Karten ist vielleicht, dass man nie so recht weiss, ob die Verbindung noch steht, oder hoffentlich aufgelegt ist. 'cFos' kann auf mehrere Arten den "Gebuehren-GAU" verhindern: 1. Verfuegt der Modem-Emulator ueber einen Inactivity Timer. Mittels ATS19 kann eingestellt werden, wie lange sowohl nichts mehr empfangen als auch gesendet werden darf, bevor automatisch aufgelegt wird. 2. Beim Abbau der Verbindung laufen Timer, die ueberwachen, ob vom CAPI die entsprechenden DISCONNECT_B3_IND bzw. DISCONNECT_IND Messages signalisiert wurden. Geschieht dies nicht, wird zweimal im 5 sec. Takt erneut zuerst zweimal die Ebene B3 disconnected, danach zweimal die Ebene D. Fuehrt auch dies nicht zum Erfolg, meldet sich 'cFos' vom CAPI ab und danach erneut an. Spaetestens jetzt sollte das CAPI alle bestehenden Verbindungen abgebaut haben. 3. Beim Connect gibt es, wie bei Modems einen "Wait for Carrier" Timer. Kann innerhalb der in S7 einstellbaren Zeit die Verbindung nicht aufgebaut werden, wird disconnected. Damit soll "haengen" beim Aufbau der B3 Verbindung verhindert werden. 4. 'cFos' unterstuetzt in der DEBUG-Version einen alternate Monitor. Man kann dann auf dem alternate Monitor alle CAPI message und einigen Hand-DEBUG Output verfolgen. Das kann im Zweifel sehr hilfreich sein, wenn man beobachten kann, wo genau Probleme auftauchen. 9. Blockgroessen und Speicherbedarf: Es existiert eine verwirrende Vielfalt von Blocks und Buffers in diesem FOSSIL Treiber. Hier ein Versuch einer Erklaerung: B2-Framelength: Daten werden im ISDN auf Ebene 2 in 'Frames', also paketweise, verschickt. Diese Frames (=Pakete) haben eine maximale Laenge. Das bezeichnen wir als B2-Framelength. Die Spezifikation des CAPI erlaubt eine maximale B2-Framelength von 2048 Bytes. Werden groessere Frames empfangen kann es zu Datenverlusten und Abbruch der Verbindung kommen ! Damit sind ISDN-Karten, die mit groesserer B2-Framelength senden zu CAPI Anwendungen inkompatibel !!! B3-Framelength: Auch auf Ebene 3 werden Daten in Frames verschickt. Wenn Ebene 3 transparent ist (also kein Protokoll hat), dann sind die B3-Frames genauso gross wie die B2-Frames. Wenn allerdings auf Ebene 3 ein Protokoll gefahren wird, z.B. T70.NL (CAPI default, aber nicht 'cFos' default), dann benoetigt dieses Protokoll noch ein paar Bytes Overhead. Diese Bytes sind allerdings aus der Sicht des B2-Protokolls normale Nutzdaten und somit in einem entsprechenden Buffer zu speichern. Die B3-Framelength ist uebrigens die maximale Anzahl von Bytes, deren Empfang durch eine DATA_B3_IND signalisiert werden kann. B2-Windowsize: Die B2-Windowsize ist die maximale Anzahl von B2-Datenbloecken, die das CAPI losschicken darf, ohne dass ein Empfang von Daten von der Gegenseite bestaetigt werden muss. Um "full-streamed" Datenuebertragung (d.h. die Datenbloecke werden ohne Verzoegerung durch Warten auf die Empfangsbestaetigung kontinuierlich verschickt) zu ermoeglichen, sollte die B2-Windowsize auf mindestens zwei stehen, sofern sich dies bei der Gegenseite auch einstellen laesst (Ist dies nicht moeglich, kann u.U. die Gegenseite "ueberrannt" werden. Buffer fuer API_REGISTER: Das CAPI benoetigt mindestens einen Puffer fuer einkommende B3-Datenbloecke. Dieser Puffer muss mindestens einen B2-Datenblock samt B3 Overhead Aufnehmen koennen. Wenn also B2=X.75 und B3=T70.NL eingestellt ist, dann benoetigt das CAPI bei einer gewuenschten max. B3-Framelength von 128 Bytes eine B2-Framelength von 130 Bytes und damit 130 Bytes fuer diesen Puffer. Das CAPI muss allerdings die bei API_REGISTER angegebene maximale Anzahl B2-Frames puffern koennen, die wiederum abhaengig ist von der B2-Windowsize und der Anzahl der B3-Verbindungen. Ausserdem braucht das CAPI fuer seine Message-Queues ebenfalls Speicher. Somit ergibt sich in unserem Beispiel bei API_REGISTER folgender Speicherbedarf (Anzahl der Messages, die die Queues aufnehmen koennen sei hier 10) : (10 * 180) + (Anz. B3-Verbingungen * B2-Windowsize * 130) Buffer fuer FOSSIL Funktionen: Das FOSSIL braucht auch noch Speicher fuer seine Ringbuffer. Der Receiver-Buffer sollte mindestens so gross sein, wie die B3-Framelength. Andernfalls kann 'cFos' dem CAPI den empfangenen Datenblock nicht vollstaendig abnehmen. Der empfangene Datenblock wird statt dessen gesplittet und in mehreren Teilen in den FOSSIL Receiver Buffer geschrieben. Dies kann zu geringfuegigen Verzoegerungen bei der Bearbeitung der empfangenen Daten fuehren. Weiterhin kann 'cFos' bis zu acht Messages vom CAPI "auf hold" legen und in den Receiverbuffer kopieren, wenn dieser wieder genuegend Platz hat. Das ist eine mehr als die maximale B2-Windowsize nach CAPI. Voraussetzung dafuer ist allerdings, dass das CAPI genuegend Empfangsspeicher hat. Bei Senden versucht 'cFos' die Daten moeglichst sofort, aber auch in moeglichst grossen Bloecken (und dabei moeglichst viele auf einmal :-), also maximal B2-Windowsize viele) zu verschicken. Durch die Art, wie mit dem CAPI durch DATA_B3_REQ-Messages Daten verschickt werden, ergibt sich, dass, um die Transmitterbuffer-Grenzen nicht zu ueberschreiten, Daten, die nahe der Puffergrenzen liegen, nicht immer in Bloecken der maximalen B3-Framelength verschickt werden koennen. Um diesen Effekt zu minimieren sollte die Groesse des Transmitterbuffers etwa B2-Framelength * (Windowsize + 1) betragen. {+} Beim Channel Bundling sollte diese Groesse noch mit der Anzahl der B-Kanaele multipliziert werden. 10. Windowsizes, die ultimative Speed ! Man kann versuchen, durch moeglichst grosse B3 Datenbloecke, die Geschwindigkeit zu erhoehen. Allerdings ist das nicht unbedingt von Erfolgt gekroent. Das liegt an der Art und Weise, wie bei X.75 Daten verschickt werden. Die B2-Windowsize ist, wie oben erwaehnt, die Anzahl der Frames, die sich gerade in Transmission befinden duerfen, ohne das eine Confirmation fuer diese empfangen wurde. Das heisst, bei einer Windowsize von drei kann man drei Blocks hintereinander (ohne Pause!) verschicken ohne auf eine Bestaetigung warten zu muessen. Somit muss 'cFos' bei einer Windowsize von 1 immer auf die Confirmation fuer den Block warten, bevor es einen neuen verschicken darf. Nun werden aber wiederum die Confirmations erst dann gemeldet, wenn die Applikation auf der Gegenseite der dortigen ISDN-Karte den Datenblock abgenommen hat. (Das ist sehr sinnvoll, da man so eine Art Flow-Control zwischen den beiden Teilnehmern hat. Im ISDN gibt es kein RTS/CTS handshake :-) ). Dadurch, dass bei einer Windowsize von 1 immer nur ein Block unterwegs sein kann, bekommt ein ISDN-Transfer exakt das gleiche Zeitverhalten, wie X-Modem. Das ist Steinzeit-DFUE !!! Bei einer Windowsize von 2 hingegen kann 'cFos', waehrend gerade ein Block verschickt wird, schon den zweiten losschicken und die Gegenseite, waehrend der zweite noch empfangen wird, schon den ersten bestaetigen. Auf diese Weise koennen die Datenbloecke nahezu ununterbrochen verschickt werden. Damit kann man *wirklich* Speed erreichen. Wir haben bei unseren Tests bei einer durchschnittlichen Blockgroesse von 2048 Bytes mehr als 7900 cps (bei theoretischen 8000 cps) erreicht. Als Mailerprotokoll wurde Z-Modem verwendet. Eine Erhoehung der Windowsize auf 3 war wirkungslos. Unsere Empfehlung: Obwohl die Transfer Routinen in 'cFos' auf High-Speed optimiert sind, halten wir eigentlich nichts von dem CPS-Krieg, da es genau genommen auf die tatsaechliche Uebertragungsdauer ankommt, denn die kostet Geld. Uebertraegt man eine 2 MB grossen Datei mit 7500 cps statt mit 7900 cps, macht das einen Unterschied von 15 sec. aus, kostet also im Inland im schlimmsten Fall eine Einheit mehr. Ein weiterer Faktor bei den Uebertragungsraten ist der Protokoll-Overhead (den man aber bitte auch nicht ueberbewerten sollte - viel kritischer ist das oben beschriebene Zeitverhalten). Um diesen zu minimieren, empfehlen wir B3-Protokoll=4, also transparent. D.h. der Overhead ist hier Null. Um ebenfalls den B2-Protokoll Overhead zu minimieren, empfehlen wir eine B2-Framelength von 2048 Bytes. Mit dieser Framelength sollten alle ISDN Karten beim Empfang klarkommen, allein schon um zu potentiellen CAPI-Karten kompatibel zu sein. Wer seine ISDN-Karte auf eine groessere Framelength einstellt, macht sich damit inkompatibel zu anderen !!! Leider verschickt z.B. die ISDN-Blaster defaultmaessig 16k Frames, weshalb mit diesen Karten ohne Umstellung kein Transfer moeglich ist. Aber es gibt einfache Abhilfe: einfach ein ATS75=0x0800 in den Init-String und die Blaster schickt nur noch max. 2k Frames. Wer keinen CONNECT zu einer ISDN-Blaster hinbekommt, versuche V.110 und schreibe dem entsprechenden Betreiber, dass er seine B2-Framelength mittels ATS75=0x0800 auf vernuenftige Werte einstellen soll, da er sonst NUR kompatibel zu anderen ISDN Blaster Karten ist. Er kann dann immer noch 16k Byte Frames empfangen. Wenn es beim Senden von Daten oft zu CRC Fehlern kommnt, kann das daran liegen, dass die Gegenseite nur mit Windowsize 1 empfaengt. In diesem Fall kann man bei 'cFos' mit ATS26=1 zur Not auch auf eine Windowsize 1 "herunter-schalten". Die meisten Karten koennen aber eine Windowsize von 2. Wir empfehlen deshalb eine Windowsize von 2 ! Oder sollte sich im FidoNet die Steinzeit-DFUE durchsetzen ? Zum gegenwaertigen Zeitpunkt laeuft ISDN im FidoNet alles andere als toll. Das liegt unter anderem daran, dass man sich bisher nicht auf einen ISDN B2- und B3-Protokoll Standard geeinigt hat. Denn wenn zwei Karten mit unterschiedlichen Protokoll-Parametern miteinander connecten, kommt es frueher oder spaeter zu Uebertragungsproblemen und Verbindungsabbruechen. Man muss sich also frueher oder spaeter darauf einigen was genau denn das ISDNC Flag in der Nodelist bedeuten soll. Hierzu unser Vorschlag (und cFos' default Einstellung) : B2-Protokoll : X.75 (logisch :-) ) B2-Framelength : 2048 (s. obige Erlaeuterung) Link-Address A : 3 (CAPI default) Link-Address B : 1 (CAPI default) Modulo Mode : 8 (CAPI default) Windowsize : 2 (s. obige Erlaeuterung) mehr braucht bei 2048 auch zuviel Speicher B3-Protokoll : transparent, also keines. Wir meinen, dass die Chancen fuer einen guten Transfer so am hoechsten sind. 11. 'cFos' als Multiport Fossil: Theoretisch kann 'cFos' bis zu 255 verschiedene Ports unterstuetzen. Einen Rechner mit der dazugehoerigen Leistung und dem entsprechenden ISDN Equipment (8 Primaermultiplex-Anschluesse :-) ) moechten wir aber erstmal sehen. Diese 'cFos' Version ist so kompiliert, dass man bis zu vier COM Ports aktivieren kann. Fuer jeden COM Port wird dann beim Installieren Buffer- und Datenspeicher reserviert. Man kann z.B. beim Aufruf -c0 und -c1 verwenden, um COM1 und COM2 zu unterstuetzen. Entsprechend gibt es dann zwei Modem-Emulatoren und man kann gleichzeitig bei zwei verschieden Systemen anrufen oder von einem angerufen werden und auf dem anderen Port einen RING beantworten. Das setzt allerdings MultiPort-faehige Software oder einen Multitasker voraus. Im MultiPort-Betrieb hoeren z.Z. alle "Modems"/Ports auf RINGs mit automatischen Ringdown vom ersten mit -c spezifizierten Port zum naechsten. In einer spaeteren Version wird man aber fuer alle Ports seperat EAZs einstellen koennen, die sich auch ueberschneiden duerfen. 12. 'cFos' Channel Bundling (CCB): Das Channel Bundling von 'cFos' wurde so designed, dass es unabhaengig von den Herstellern des jeweiligen CAPIs ist. D.h. jeder 'cFos' User kann mit jedem anderen 'cFos' User buendeln, auch dann, wenn die Teilnehmer verschiedene ISDN Hardware haben. 'cFos' Channel Bundling (CCB) ist kein Protokoll, sondern eine Betriebsart. Man kann also sowohl mit X.75 als auch mit V110 (theoretisch, aber nicht zu empfehlen!) buendeln. Voraussetzung fuer CCB ist, dass das vorhandene ISDN Equipment mehrere B Kanaele gleichzeitig mit Dienst "Datenuebertragung" betreiben kann. Dies ist z.B. bei TELES und AVM Karten (nicht alte A1 Karten) der Fall, ebenso bei ELSA ab CAPI 1.43. Mit der Stollmann Tina DS und Tina D (wohl aber mit Tina DD) ist dies nicht moeglich, da einer der beiden B Kanaele hardwaremaessig nur fuer den A/B Adapter zur Verfuegung steht. Weitere Voraussetzung ist, dass cFos fuer mehrere Ports geladen ist. Dies ist z.B. der Fall, wenn es im MultiPort Betrieb geladen wurde, d.h. wenn mehrere Ports durch Verwendung von -c Parametern aktiviert sind. Soll 'cFos' aber nur einen Port unterstuetzen, kann man mit dem Parameter -aX sogenannte Auxiliary Ports aktivieren. Diese werden dann intern von 'cFos' benutzt, koennen aber von aussen, d.h. durch INT 14 calls nicht angesprochen werden. Der Parameter X gibt an, auf welchem Controller (ISDN Karte) der entsprechende B Kanal betrieben werden soll. 'cFos' kann naemlich Channel Bundling mit mehreren ISDN Karten gleichzeitig, sofern das CAPI dies unterstuetzt. Beispiele: cfos i -c0 -c1 'cFos' ist im Multiport Mode geladen und unterstuetzt die Ports COM1 und COM2. CCB ist mit 2 Kanaelen moeglich cfos i -c2 -a0 'cFos' unterstuetzt nur COM3. CCB ist aber mit 2 Kanaelen moeglich, wobei sich der 2. Kanal auf ISDN Karte 0 befindet. Dies wird wohl der haeufigste Anwendungsfall sein. cfos i -c0 -c2 -a1 'cFos' unterstuetzt COM1 und COM3. CCB ist mit 2 oder 3 Kanaelen moeglich. Falls man nur 2 Kanaelen zum Buendeln benutzt, wird der "Hauptport" (COM1 oder COM3) und der Auxiliary Port benutzt. Erst wenn 3 Kanaele gebuendelt werden sollen, wird auch der zweite Hauptport verwendet, sofern er zum Zeitpunkt des Verbindungsaufbaus frei ist. Dies ist leider etwas kompliziert geworden, aber ermoeglicht, dass sich Channel Bundling und MultiPort Mode nicht gegenseitig ausschliessen, sondern beliebig miteinander kombiniert werden koennen Grundsaetzlich waehlt 'cFos' neben dem Hauptport, von dem aus das CCB gestartet wurde, bevorzugt Auxiliary Ports und erst wenn keine mehr frei sind, weitere Hauptports. Wird auf einen Hauptport zugegriffen, der aber gerade fuer einen anderen Port gebuendelt ist, gibt der Modem Emulator auf alle Modem Kommandos immer OK zurueck. Dies koennte z.B. der Fall sein, wenn unter DesqView zwei Mailer Tasks laufen. Hat die eine gerade beide Kanaele, gibt der Modem Emulator der anderen immer OK zurueck, aber es wird kein Kommando ausgefuehrt. Auf diese Weise "weiss" der Mailer aber, dass der Port "noch da ist". Der aktive und passive Verbindungsaufbau beim CCB, insbesondere die Wahl der Uebertragungsprotokolle unterscheiden sich nicht vom Verbindungsaufbau mit einem Kanal. Auxiliary Ports haben das gleiche PROFILE, wie der zughoerige Hauptport, mit Ausnahme des Controller Bytes (S Register 40). Dieses wird durch den Wert des -a Parameters bestimmt. Das Modem Kommando AT&Bn bestimmt, wieviele Kanaele zum CCB benutzt werden sollen. Mit ATD werden die Kanaele aufgebaut. Gibt man mit AT&Bn mehr Kanaele an, als 'cFos' beim Aufruf eingerichtet hat, wird ERROR zurueckgegeben. Gibt es hingegen genuegend Kanaele, die aber u.U anderweitig verwendet wurden, wird CCB nur mit den verfuegbaren Kanaelen durchgefuehrt. Gleiches gilt auch fuer eingehende Rufe. 'cFos' prueft bei eingehenden Rufen, ob fuer eine Caller ID, samt EAZ/SI/AddSI, schon eine Verbindung besteht und schaltet ggf. in den Bundle Mode. Ruft man also ein 'cFos' zweimal gleichzeitig mit gleicher Caller ID/EAZ an, wird CCB angenommen. Voraussetzung fuer CCB ist deshalb, dass der Anrufer seine Caller ID uebermittelt ! Hier ein Quicky zum testen: CFOS i -a0 ; cfos mit defaults fuer COM1 + 1 Aux.Port laden Terminal Software fuer COM1 starten AT &F &B2 DS0 ; bei Zaphods BBS anrufen Es sei noch bemerkt, dass es keine speziellen CONNECT Strings fuer CCB gibt, da 'cFos' zum dem Zeitpunkt, zu dem es die CONNECT Meldung ausgibt, noch keine Informationen ueber die Anzahl der gebuendelten Kanaele hat. Dies wird insbesondere dann schon gar nicht mehr der Fall sein, wenn, wie in Kapitel 17 angedeutet, lastabhaengiges Zu- und Abschalten einzelner Kanaele implementiert sein wird. CCB ist fuer mit max. 4 Kanaelen moeglich. Auf Wunsch fertigen wir fuer Sie aber auch Spezial-Versionen fuer mehr Kanaele an. CCB ist auch mit mehreren S0-Bussen unterschiedlicher Rufnummer moeglich. Da dies nur fuer wenige interessant ist, haben wir die Beschreibung dazu in den Anhang F verlegt. 13. Vertraeglichkeit von 'cFos' mit bestehender Software: Wir haben 'cFos' mit verschiedenen Applikationen und mit verschiedener ISDN Hardware/Software getestet, wobei manche Software Schwierigkeiten z.B. mit den hohen Baudraten hat (die meisten Programm benutzen hierfuer einen signed int, dessen Wertebereich allerdings bei 32767 sein oberes Ende erreicht.) Laut der FOSSIL Spec. soll man die Lauffaehigkeit seines FOSSIL's am besten dadurch testen, indem man existente Software mit ihm testet. Die "FOSSIL Unterstuetzung" mancher Terminalprogramme ist leider nicht so berauschend, insbesondere wird teilweise PRO BYTE einmal der Status abgefragt und dann (falls Daten vorhanden sind) ein receive_char () Call benutzt, um das Character vom FOSSIL abzuholen. Diese Art, mit dem FOSSIL umzugehen, erzeugt pro Character mindestens 2 INT's und 2 IRET's (zusammen etwa schon 2000 Takte bei einem 386'er mit QEMM oder EMM386), ganz abgesehen von sonstigem Call-Overhead. Wir haben uns zwar Muehe gegeben, selbst mit diesen Applikationen noch moeglichst schnell Daten senden/empfangen zu koennen, jedoch ist es bei solcher Behandlung des FOSSIL's auf langsamen Rechnern (speziell 386'ern mit Memory-Manager) nicht moeglich, Daten mit gutem Durchsatz zu uebertragen. Hier sind ganz klar die Autoren der Terminalsoftware gefragt, geeignetere Wege zu nutzen, das FOSSIL anzusteuern; das heisst bei den meisten Programmen, Daten mit receive_block() und transmit_block() in groesseren Blocken zu uebertragen, anstatt jedes Byte einzeln. Viele FOSSIL unterstuetzende Software muss eine Baudrate wissen, mit der sie ueber den Seriellen Port (RS232) mit dem Modem reden und auf den sie diesen Port 'locken'. Diese Baudrate ist fuer die Kommunikation mit dem Modem sehr wichtig, bei unserer Loesung (da ohne RS232 und ohne externes Modem) voellig egal. Um auf der sicheren Seite zu sein, sollte man in solchen Feldern eine Baudrate von 38400 oder 19200 eintragen. FrontDoor FidoNet-Mailer von Absolute Solutions (JoHo). Sowohl Mailer wie auch Terminal-Programm gehen recht gut mit dem FOSSIL um, weshalb man mit diesem Programm selbst bei langsamen Rechnern (386DX mit 6MHz) und passiven Karten Uebertragungsraten von > 7300 cps erreichen kann. Auf schnelleren Rechnern ist FD eines der besten Terminalprogramme, was wir finden konnten (zumindest in Bezug auf Transferspeed). Problem 1: FrontDoor besitzt ja die Eigenheit, nur "canned" CONNECT strings erkennen zu koennen. In den Versionen < 2.11 gibt es da keinen fuer 64000 (wohl aber fuer 38400). Also muss man einen anderen String dafuer verwenden, was zwar dazu fuehrt, dass FD alle moeglichen Zeit-Dauern falsch berechnet, aber immerhin laeuft. Loesung 1: a) Du hast FD 2.20/c oder FD 2.11/nc, dann hast Du dieses Problem nicht, b) Du benutzt andere CONNECT messages fuer die "neuen" bps-Raten, oder c) Du hast kein FD >= 2.11, dann sorgt ein 'ATS9.1=0' dafuer, dass immer "CONNECT 9600" gemeldet wird, und deshalb kein Mailer sich beschwert. Damit man aber immer schoen was in den Logfiles stehen hat, steht dann noch das B2 Protokoll dahinter, also "CONNECT 9600/X75". Das mag FD. Problem 2: Die CallerID, die bei ISDN mitgeliefert wird. Wenn es RINGed, dann steht bei 'cFos' dahinter die Nummer des Anrufers und das findet FD meist gar nicht mehr gut, da bei vielen Mailern der RING String auf "RING|" geaendert worden ist, um ein "RINGING" zu akzeptieren. Loesung 2: Leider kann man das "RING|" nicht in ein "RING " aendern, sondern muss dem Modem-Emulator ein "ATS9.2=0" geben. Damit wird das RINGING ausgeschaltet. FrontDoor benoetigt etwa 250kb freien Speicher, sodass es keinerlei Speicherprobleme geben solte (selbst unter DesQView nicht). InterMail Wir selbst hatten leider nicht die Moeglichkeit InterMail zu testen (da es PayWare ist), uns wurde jedoch gesagt, InterMail verhalte sich nicht anders als FD, somit gilt das oben geschriebene. (InterMail und FrontDoor entstammen den gleichen Sourcen). Ueber den Speicherbedarf von InterMail sind wir leider nicht informiert (Mail?). BinkleyTerm Binkley benutzt (ebenso wie FD) sehr saubere und schnelle Routinen, um das FOSSIL anzusteuern. Deshalb ist auch hier selbst auf langsamen Rechnern fuer guten Datendurchsatz gesorgt. Problem: Binkley 2.50 (und 2.50 EE bis Beta D incl.) verwendet (soweit wir wissen) fuer die Baudraten einen signed int. Das fuehrt somit bei CONNECT 64000 oder hoeher zu Fehlern. Loesung: Ein 'ATS9.1=1' gibt immer eine 9600 als Baudrate zurueck und das klappt. Leider stimmen dann auch hier die Timings nicht mehr. Binkley (2.50 EE Beta D, non-overlay) benoetigt etwas ueber 300kb Speicher, somit sollte es auch hier keine Probleme geben. D'Bridge D'Bridge (kurz: DB) ist ein Mailer von Chris Irwin aus dem sonnigen Miami. Um 'cFos' mit DB zum laufen zu bekommen, kann man im Menu unter CONFIG, Comm/Modem Setup in eine Setup-Screen wechseln. Dort muss man in einer der DATA/1 ... DATA/3 Zeilen in der Spalte 'MCF name' 'CFOS' eintragen. Dann muss noch im DB system-directory eine Datei namens CFOS.MCF (Modem Control File) liegen mit (mindestens) folgendem Inhalt: MCF CFOS ISDN-Karte + cFos BAUD 64000 LOCKED DELAY 0 INIT ATZ OFFHOOK ATH1 ANSWER ATA DIAL 300 ATD DIAL 19200 ATD DIAL 38400 ATD DIAL 64000 ATD TRANSLATE 9600 CONNECT 9600 TRANSLATE 38400 CONNECT 38400 TRANSLATE 64000 CONNECT 64000 Allerdings muss der CONNECT String mit einem der angegebenen Strings voellig uebereinstimmen, sonst meldet DB eine Baudrate von 0. Deshalb sollte man ein ATS9.4=0 setzen, damit das '/X75...' hinter dem CONNECT nicht kommt. Wenn es eine andere Loesung fuer DB gibt, bitten wir um einen Hinweis. Das sollte alles sein. Es ist zu empfehlen, D'Bridge ab Version 1.54 zu benutzten, da der Autor in dieser Version die FOSSIL Aufrufe verbessert hat. Yuppie! Yuppie ist ein 3d-Pointprogramm von YEAsoft aus Aachen. Wir hatten die Version 2.10 im Test. Es basiert in den Uebertragungsroutinen auf Binkley und laeuft entsprechend gut. Allerdings kann es kein 'CONNECT 64000' vertragen, weshalb ein 'ATS9.1=0' erforderlich ist, damit es bemerkt, dass eine Anwahl erfolgreich war. Ansonsten benoetigt es recht viel Speicher (es wurde in Clipper geschrieben), also moeglichst CAPI und/oder FOSSIL in UMB's laden. Portal of Power PoP macht beim Senden ab dem 2. File aus unbekanntem Grund eine kurze Pause. Dies liegt nicht an 'cFos', ist aber auch kein Grund zur Besorgnis. Man muss ein wenig aufpassen, dass man nicht automatisch einen X00 laedt. Im Zweifel sollte die POP.BAT Datei aendern, um dies zu verhindern. Von PoP Usern haben wir gehoert, dass zumindest die Version 0.61 fuer eingehende Rufe nicht zu gebrauchen ist. Das scheint aber kein Problem von 'cFos' zu sein, da es auch mit anderer ISDN Soft/Hardware auftritt. CrossPoint Ab der Version 2.14 des Fido-Mailers unterstuetzt XP auch FOSSILs. Damit XP-FM ueberhaupt das FOSSIL unterstuetzt statt seinen internen Routinen muss im XP Verzeichnis eine Datei mit Namen "FOSSIL" existieren (Inhalt egal), am besten mit "ECHO > FOSSIL" eine solche erzeugen. Bis zur Version 2.10 von XP kann NUR der XP-FM (ab 2.14) zum Pollen auf das FOSSIL zugreifen. Terminal-Modus laeuft NICHT! XP erwartet, dass hinter jedem Communication Port auch ein physikalisches Modem haengt und testet dies, indem es auf die Ports mit eigener I/O zugreift. Um trotzdem mit XP ueber ISDN pollen zu koennen, sollte man Mail von Hand packen und XP-FM von Hand aufrufen. Ab der Version 2.92 von XP ist die FOSSIL-Unterstuetzung jetzt auch vollstaendig verfuegbar, z.B. im Terminalprogramm etc. Dafuer muss einfach unter Kommunikation/Modem der Punkt 'FOSSIL' angeschaltet werden. Maximus Maximus ist ein BBS Program von Scott J. Dudley. Wir benutzen es hier selber und hatten deshalb ausgiebig Zeit, sein Verhalten zu testen. Sowohl das WFC Interface von Maximus, wie der 'SpawnBBS' Start macht auch mit 64000 Baud keine Probleme. Menus und Textfiles werden characterweise ausgegeben, deshalb ist hier nicht die volle ISDN Geschwindigkeit zu sehen, aber das tut auch keinen grossen Abbruch. Bei einem Download schickt Maximus Daten in 128 Byte Bloecken an das FOSSIL und erreicht dadurch eine gute Transferspeed. Leider benutzt Maximus beim Empfangen von Daten (Upload) nicht die receive_block() Funktion des FOSSILs, sondern liesst Byte fuer Byte mittels receive_char(). Dadurch entsteht ein riesiger Overhead und die maximale Uebertragungsrate liegt bei langsamen Rechnern unter der maximal moeglichen. Wir haben zwar die receive_char() und get_status() Funktionen in Assembler geschrieben und dadurch einen akzeptablen Durchsatz erreicht. Allerdings wird Maximus beim Download immer schneller sein, als beim Upload. RemoteAccess RemoteAccess ist eine BBS Software von Andrew Milner. Es lief in unseren Tests gut und problemlos, erreicht Datenuebertragungsraten von ueber 7300 cps und kann auch selber ohne weiteres Anrufe entgegennehmen. Zumindest die Version 2.00 sollte keine Probleme mit Baudraten von 38400 oder 64000 haben. Leider kann RemoteAccess auch nur "canned" CONNECT Strings, die in RACONFIG eingestellt werden muessen. In der Version 2.00 sind aber alle fuer ISDN benoetigten Strings vorhanden. Lediglich den RING-String sollte man auf "RING " einstellen, damit "RING CallerID" nicht mit "RINGING" verwechselt werden kann. PCBoard Man benoetigt fuer die FOSSIL-Unterstuetzung eine PCBoard/M Version. Damit laeuft 'cFos' dann aber ohne grosse Probleme, allerdings muss mit 'ATS9.4=0' die CONNECT Meldung auf ein 'CONNECT ' beschraenkt werden, da PCBoard die letzte Zahl des CONNECT Strings als Baudrate benutzt. Weiterhin darf der BIOS Emulator von 'cFos' bei PCBoard nicht auf force stehen (also kein -e2). Terminate Terminate ist ein recht neues Terminalprogramm von Bo Bendtsen aus Daenemark. Es hat Features "bis zum Abwinken", unter anderem auch FOSSIL Support. Wir haben hier die Version 1.41 getestet. Terminate benutzt leider die receive_char() und transmit_char() Funktionen des FOSSIL's, somit kann der Transfer auf langsamen Rechnern weit unter den maximalen 8000 cps liegen. Terminate benoetigt zum Laufen seit der Version 1.3/1.4 etwa 300kb Speicher, Bo hat sich nochmal ins Zeug gelegt und den Speicherbedarf drastisch gesenkt. Zumindest ein Bug scheint in der Version 1.41 noch drin zu sein, der dafuer sorgt, dass der INT 14 Vector vom Terminate verdreht wird. Daher kann es sein, dass cFos z.b. beim Deinstallieren meldet "cFos not found in memory". TeleMate TeleMate ist eines der bekanntesten Terminaprogramme auf dem PC und verfuegt seit einigen Versionen auch FOSSIL Support. Das Besondere an TeleMate ist vor allem sein internes Multitasking, d.h. man kann gleichzeitig eine Datei downloaden und einen Text editieren. Allerdings kostet dieses Multitasking erheblich Transferspeed, wenn der Rechner nicht schnell genug ist, soll heissen: ein 386DX-40 sollte es schon sein, damit die Transferspeed angenehm ist. Ansonsten hat TeleMate eine sehr elegante Art, das FOSSIL anzusprechen, leider hat es aber lange Zeit mit TeleMate beim Download CRC Fehler gegeben, die wir erst in der 'cFos' Version 0.95 fixen konnten. Der Speicherhunger von TeleMate allerdings ist mit ueber 430kb recht hoch. Auch hier sollte man mit Treibern und residenten Programmen sparen. Wichtig: bei Konfigurieren des FOSSIL's in TeleMate darf die Baudrate des Ports unter "Communication" auf maximal 38400 gestellt werden, sonst akzeptiert TeleMate das Setting "FOSSIL" im "Terminal" Window nicht. Wenn das FOSSIL nicht reagiert, erstmal checken, ob im "Terminal" Window "Connection" noch auf "FOSSIL" steht. XBTX XBTX ist ein BTX Decoder von Juergen Buchmueller, und verfuegt zumindest in der Version 1.50 uber FOSSIL Unterstuetzung. Da man BTX auch ueber ISDN fahren kann und die Datex-J Ports der Telekom ISDN-faehig sind, haben wir BTX Support in 'cFos' eingebaut (ATB5). XBTX sucht die Ports 0-7 nach einem FOSSIL ab. Allerdings verwendet XBTX eine sehr unsanfte Methode, festzustellen, ob ein FOSSIL geladen ist. Diese entstammt leider nicht der FOSSIL Spec, sondern der Docu zu X00. Somit laueft ein FOSSIL mit XBTX *NUR*, wenn dieses sich so meldet, wie X00 das tut. Da das so nicht in der FOSSIL Spec vorgesehen ist, muss man bei 'cFos' diese Option extra aktivieren; dazu dient der Commandline-Switch '-jx'. XBTX benoetigt zum erfolgreichen Laden ueber 490kb Speicher; es ist daher hoechste Disziplin bei der Auswahl der TSR's angesagt ;-). DoorWay Laeuft. Allerdings sollte man die Debug-Zeile auf dem 'ge-DoorWay-ten' Rechner ausschalten, da DoorWay sonst dauerhaft die Aenderungen der Debug-Zeile uebertraegt (nicht schlimm, aber stoerend). DesQView Wir haben 'cFos' mit DesQView als MultiPort-FOSSIL getestet; dazu muss 'cFos' VOR DesQView mit mehreren -c Parametern (fuer mehrere Ports) geladen werden, damit alle Tasks auf das gleiche FOSSIL zugreifen koennen. Wir haben unter DesQView von einem FrontDoor das andere angerufen und hatten Transferraten >7500 cps (386DX-40). MS-Windows Soll 'cFos' mit MS-Windows benutzt werden, so MUSS es vor Windows geladen werden. Einige Windows-Programme haben zwar keine FOSSIL Unterstuetzung, koennen aber den INT 14h nutzen. Mit diesen kann 'cFos' ebenfalls eingesetzt werden. Im Anhang findet eine Vertraeglichkeits-Liste. 14. ISDN Hardware/Software: 'cFos' setzt zwar auf dem CAPI, einer in Deutschland genormten Schnittstelle auf, aber diese laesst leider einige Fragen offen, sodass eine Applikation erst mit anderer Hardware getestet werden muss. Hier unsere Erfahrungen (oder die anderer User zum Thema ISDN Hardware): TELES 'cFos' wurde an einer TELES.S0 ISDN Karte entwickelt und getestet. Bei der Entwicklung stand und steht uns die Fa. TELES GmbH, Berlin durch Support durch ihre CAPI-Entwickler zur Verfuegung. Wir betreiben unsere Mailbox (Zaphods BBS) mit 'cFos' an einer TELES.S0 Karte und versuchen hier auch immer die neueste Version des TELES CAPI's bereitzustellen (z. Zt. 2.4l). 'cFos' erkennt das CAPI von TELES und ermittelt, ob die Module fuer V.110 oder Buendelprotokoll geladen sind. Entsprechend wird die Benutzung von V.110 und TELES channel bundling und damit ATB1..ATB3 erlaubt. AVM Sowohl auf der passiven AVM A1+ wie auf der aktiven AVM B1 laeuft 'cFos' gut. Probleme gibt es u.U. mit dem atypischen Verhalten des X.75 der ISDN Blaster. Dazu gibt AVM aber mittlerweile neue Treiber heraus (Version 2.07-10 oder hoeher). Wenn man eine ISDN Blaster, die mit FOSSIL PCIF V5.78 laeuft, anrufen will, sollte man bei 'cFos' das -jp Flag (s. auch Kapitel 3) verwenden. Teilweise ist im AVM CAPI kein V.110 enthalten; wenn dies der Fall ist, sollte bei einem Anwahlversuch nach einer CONNECT-Meldung ein ERROR/B2 auftreten. Wenn das der Fall ist, sollte eine neue Version der CAPI's von AVM Abhilfe schaffen. Allerdings gibt es alte A1 Karten (V1.3), fuer die es keinen V.110 Treiber gibt. CPV Stollmann Auf den aktiven Karten Tina D und Tina DS laueft 'cFos' gut und selbst auf langsamen Rechnern schoen schnell. Das CAPI von Stollmann kann zwar z.Z. noch kein V.110, aber das wird sich wohl demnaechst nach Auskunft von Stollmann aendern. In unserer Mailbox bieten wir die neuesten Treiber fuer diese Karten an (TINACAPI.ZIP und TINAETSI.ZIP). Diese sollte man unbedingt verwenden und auch, wie dort beschrieben, den Aufruf TICAPI -b, um mit der ISDN Blaster keine Probleme beim Verbindungsaufbau zu haben. Es existiert eine COM-Port Emulation, die, wenn geladen, leider verhindert, dass 'cFos' sich beim CAPI erfolgreich registrieren kann. Wenn man 'cFos' benutzen moechte, darf dieses Modul nicht geladen werden. CPV Stollmann hat uns freundlicherweise eine TINA DS zu Test- zwecken zur Verfuegung gestellt. 'cFos' sollte deshalb problemlos mit ihr laufen. {+} Mit der TINA D und Tina DS funktioniert das Channel Bundling leider nicht (wohl aber mit der Tina DD), da der zweite B-Kanal hardwaremaessig mit dem integrierten A/B Adapter verbunden ist und dem CAPI nicht zur Verfuegung steht. mbp SOLIS Die SOLIS Karten der Firma mbp laufen mit 'cFos' gut, wenn man folgendes beachtet: Bei Laden von 'cFos' muss der Switch -jr angegeben werden. Die SOLIS hat eine COM Port Modem-Emulation. Am besten man schaltet diese aus. Diese Emulation hoert defaultmaessig auf EAZ 9. Dies kann man mit dem Util ICOMCONF umstellen. Man muss darauf achten, dass nicht 'cFos' und der COM Port gleichzeitig auf die selben EAZs hoeren. Bitte auf jeden Fall die neueste bei MBP verfuegbare CAPI Version benutzen, da die alten Versionen Probleme machen koennten. ITK iX1 Das iX1 CAPI erlaubt nicht, mit einer Windowsize kleiner als 2 zu registrieren ('cFos' default ist 2). Ansonsten laeuft 'cFos' gut. ELSA MicroLink ISDN/PC, ISDN/PCC ELSA stellte uns freundlicherweise ihre Microlink ISDN/PC Einsteckkarte samt CAPI 1.43 zum Test. 'cFos' laeuft in dieser Konfiguration gut. Das ELSA CAPI ist schoen klein und schnell, kann aber (noch) kein V110. Als "Ausgleich" besitzt die ISDN/PC dafuer aber einen COM-Port mit einem 16550. {+} Ab CAPI 1.43 laeuft auch 'cFos' Channel Bundling problemlos. Sedlbauer S0-Box Die S0-Box ist ein externes Geraet, welches auf den Printer-Port aufgesteckt wird. Alle Daten zwischen ISDN und Rechner werden ueber den Printer-Port ausgetauscht. Z.Z. kann die S0-Box nur einen Kanal. Dies soll sich aber in Zukunft aendern, so dass 'cFos' Channel Bundling dann auch moeglich sein wird. Weiterhin unterstuetzt die S0-Box bisher nur Windowsize 7, daher muss 'cFos' mit "cfos i -w7" geladen werden. Wenn man das beachtet, laeuft die Box nach Angaben der Entwickler mit 'cFos' ohne Probleme. Diehl Diva: Die Diva ist eine aktive ISDN Karte. 'cFos' laeuft mit ihr gut, insbesondere auf langsamen Rechnern. Demnaechst wird die at- run-time auf die Karte ladbare Firmware auch V.110 unterstuetzen. Wir danken Diehl fuer die Teststellung ihrer {+} Karte, die uns geholfen hat, noch einen Bug im CCB zu fixen. Nach Auskunft von anderen 'cFos' Usern, laeuft cFos ebenfalls mit der Diehl SX und der SCOM Karte. Andere: Falls Probleme mit ISDN-Hardware, deren Hersteller hier nicht erwaehnt ist, auftreten, bitte zuerst ueberpruefen, ob es nicht inzwischen neuere CAPI Treiber o. ae. gibt und wenn ja, diese benutzen. Ansonsten Mail an uns. Wir moechten uns an dieser Stelle nochmal fuer die gute Zusammenarbeit mit den ISDN Karten Herstellern bedanken, insbesondere bei TELES, aber auch bei CVP/Stollmann, ELSA und Diehl. 15. Verschiedenes: - Disconnect Reasons, die 'cFos' an die Gegenseite meldet, sind: 0x00 : normal disconnect (auch 0x80) 0xbe : call rejected 0xbb : user busy 0xb9 : out of order Die Reasons kommen dann bei der Gegenseit als 0x34?? Causes an, je nach dem, ob sie von den Vermittlungsstellen weitergegeben werden. - Service Indicator (SI) ungleich 7 Waehlt man in S14 andere Services als "Datenuebertragung", meldet 'cFos' bei eingehenden Rufen (wenn in der Service Mask das entsprechende Bit gesetzt ist) "CONNECT VOICE" bei SI = 1 und selektiert als B2-Protokoll "bittransparent". Auf diese Weise kann man "Telefonie" betreiben. Ist SI <> 7 und SI <> 1 meldet 'cFos' z.Z. noch "CONNECT ?" und selektiert X.75 als B2-Protokoll. Beim aktiven Verbidungsaufbau kann man mit S16 selbst einen Service Indicator bestimmen, genauso wie man mit S17, S20, S21 den Additional Service Indicator, sowie B2- und B3-Protokoll waehlen kann. - For further Study Wer gerne etwas tiefer in die ISDN Materie einsteigen will, der sei hier auf folgende Literatur (inclusive Programme) verwiesen: CAPI Dokumentation COMMON-ISDN-API, Einheitliche Schnittstelle zwischen Applikationsprogrammen und ISDN-Adaptern, Spezifikation, Version 1.1, Profil A, Editorisches Datum: 07.09.90 z.B. bei Zaphods BBS als ISDNAPI.ZIP, 24k 1.TR.6 Dokumentation Die 1.TR.6 Dokumentation ist bei folgender Adresse erhaeltlich: DBP Telekom FA Bad Kreuznach Projekt Roland Arbeitskreis CAPI/PCI z. Hd. Herrn Kreuzer Postfach 9100 W-6550 Bad Kreuznach PAPI Source PAPI ist ein ISDN Packetdriver fuer TCP/IP, der auf dem CAPI aufsetzt. Ein gutes Lehrstueck. z.B. bei Zaphods BBS als PAPI016.ZIP, 38k Wessen Interesse durch das Lesen dieser Doc oder das Benutzen unseres FOSSIL an den FOSSIL Specs geweckt worden ist, der lese folgendes: FSC-0015 DIE FOSSIL Doc von Rick Moore. Als FSC-0015.A?? in jeder guten FIDO-Box erhaeltlich, 25k. X00REF.DOC Die Function Refence von Ray Gwinn fuer FOSSIL developer. enthaelt einige gute und wichtige Kommentare. z.B. bei Zaphods BBS als X00150.ZIP, 105k. - Falls tatsaechlich jemand die "V.110 inband negatiation" benutzen sollte bekommt eine CONNECT 9600 Meldung, da 'cFos' nicht wissen kann, mit welcher Baudrate tatsaechlich connected wurde. 16. Addressen, Autoren, Verfuegbarkeit: - Lizenzbedingungen Siehe hierzu unsere Lizenz in COPYING.CF. - Autoren Christoph Lueders Martin Winkler Fidonet: 2:2453/30.1 2:2453/30.6 Internet: chris@rhein.de winkler@zaphod.rhein.de Surface Mail: Reuterstr. 133 Dorotheenstr. 38 53113 Bonn 53111 Bonn Germany Germany .---- Voice: +49-228-223359 +49-228-650389 | | | Telefon-Anrufe: | | Da wir seit neuerem wegen 'cFos' sehr viel Zeit am Telefon | damit verbringen, Fragen, die eigentlich in dieser | Dokumentation beantwortet sind, zu beantworten, haben wir | mittlerweile eine im FidoNet erhaeltliche elektronische Mail- | Conference ins Leben gerufen, in der die meisten Fragen | angesprochen werden koennen. Sie heisst CFOS_HELP. Ausserdem | kann eine Mail an den SYSOP von Zaphods BBS (ISDN 0228- | 9111041, V32b 0228-262894) oft schneller weiterhelfen, als ein | Anruf. | `---> Bevor wir telefonischen Support leisten, moechten wir, dass der Anrufer CFOS.DOC, WHATSNEW, MODEM.DOC, CFOS.FAQ und APPENDIX.DOC vollstaendig gelesen hat und schon einige Zeit anhand dieser Dokumentationen mit 'cFos' experimentiert hat. Wir bitten um Verstaendnis, dass wir aus Kostengruenden nicht zurueckrufen koennen. Anrufen kann man aber gerne, wenn man ISDN Equipment benutzt, das in dieser Dokumentation nicht aufgefuehrt ist. Bei Problemen mit der Konfiguration von Software ist es u.U. eine gute Idee, Kontakt mit den "Help-Sites" der entsprech- enden Software aufzunehmen. Mail/Bug-Reports: Was uns immer interessiert, sind - offensichtliche Bugs in 'cFos' oder der Dokumentation. - Erfahrungsberichte mit uns noch unbekannter Software oder ISDN Hardware. - Anregungen, was man noch in 'cFos' einbauen sollte. - was man alles noch mit 'cFos' machen kann. Willkommen sind z.B. Telefonnummern fuer DATEX-P <--> ISDN Gateways, etc... Eine Mail an uns sollte auf Fall folgendes enthalten: - den Namen und bei Bug Reports oder ISDN Karten, die nicht in dieser Dokumentation aufgefuehrt sind, die Voicenummer, damit wir im Bedarfsfalle kurzfristig zurueckrufen koennen. - Versionsnummer von 'cFos' - Verwendeter Rechner, Software, CAPI Treiber und ISDN Karte, bitte immer mit Versionsnummer. - Neue Versionen Die neueste Version von 'cFos' ist immer in unserer eigenen Box, Zaphods BBS in Bonn erhaeltlich. Allerdings geben wir uns Muehe, die Archive moeglichst schnell moeglichst weit zu verbreiten, dazu gehoeren FIDO Mailboxen, Internet Fileserver und MAUS Boxen. Telefonnumern und Adressen stehen auch in COPYING.CF. In zukuenftigen Versionen planen wir - Den Speicherbedarf von 'cFos' weiter zu reduzieren. - Die ATIn displays uebersichtiger zu gestalten. - Die +++ escape sequence zu unterstuetzen. - AT&E Kommandos im MultiPort Betrieb fuer jeden Port seperat einstellbar zu machen. - Eine FOSSIL user appendage speziell fuer ISDN Zwecke z.B. mit der Funktion "Get charging info" mit in 'cFos' einzubauen. - Ralf Brown's AMISL Alternate Multiplex Interrupt Specification fuer residente Programme zu unterstuetzen. {+} - Beim 'cFos' Channel Bundling fuer Highest Speed Transfers unter Minimierung der Kosten lastabhaengiges Kanal Zu- und Abschalten zu implementieren. {+} - Zahlreiche Log Funktionen zur Auswertung der Telefon-Kosten, eingegangener Rufe, etc. einzubauen. 17. Credits: Die Reihenfolge impliziert keine Wertung ;-) Andreas Illg, Alexander Bell, Eberhard Mattes, Dietmar Friede, Uwe Engelmann, Mirko Mucko, Scott J. Dudley, Robert Bergermann, Jens Osterwohldt, Markus Kessler, Olaf Droege, Tobias Erichsen, Jan Ceuleers, Kalle Braun, Roland Steinmeyer, Oliver von Bueren, Rainer Schuetze. 18. End of Documentation; Thanx for using 'cFos'. Practice random kindness and senseless acts of beauty! ---------------------------------------------------------------- ANHAENGE ---------------------------------------------------------------- A. CAPI Fehlermeldungen: Im folgenden eine Auflistung der CAPI Fehlermeldungen des CAPI Arbeitskreises, erweitert durch V.110 Fehlermeldungen, 1.TR.6 Causes und herstellereigene Fehlermeldungen: 0x0000: No error 0x1001: Error on API_REGISTER 0x1002: Illegal application-id 0x1003: Illegal message 0x1004: Illegal command or subcommand 0x1005: Queue is full 0x1006: Queue is empty 0x1007: Queue overflow 0x1008: Deinstall error 0x1009: Windows address error 0x2001: Illegal Controller 0x2002: Illegal PLCI 0x2003: Illegal NCCI 0x2004: Illegal type 0x3101: B-channel erroneous 0x3102: Infomask erroneous 0x3103: Serviced-EAZ-mask erroneous 0x3104: Serviced-SI-mask erroneous 0x3105: Illegal B2 protocol 0x3106: Illegal DLPD 0x3107: Illegal B3 protocol 0x3108: Illegal NCPD 0x3109: Illegal NCPI 0x310A: Illegal flags 0x3201: General controller error 0x3202: non-unique LISTEN_REQs 0x3203: function not supported 0x3204: PLCI inactive 0x3205: NCCI inactive 0x3206: B2 protocol not supported 0x3207: can't select B2 protocol now 0x3208: B3 protocol not supported 0x3209: can't select B3 protocol now 0x320A: illegal DLPD parameters 0x320B: illegal NCPD parameters 0x320C: illegal NCPI parameters 0x320D: data length not supported 0x3301: D channel layer 1 setup error 0x3302: D channel layer 2 setup error 0x3303: B channel layer 1 setup error 0x3304: B channel layer 2 setup error 0x3305: D channel layer 1 shutdown 0x3306: D channel layer 2 shutdown 0x3307: D channel layer 3 shutdown 0x3308: B channel layer 1 shutdown 0x3309: B channel layer 2 shutdown 0x330A: B channel layer 3 shutdown 0x330B: B channel layer 2 reestablished 0x330C: B channel layer 3 reestablished 0x3400: Normal disconnect, no cause given by network 0x3480: Normal disconnect, no cause given by network 0x3481: Invalid CR value 0x3483: Bearer service not implemented 0x3487: Unknown caller identity 0x3488: Call Identity already suspended 0x3489: No channel available 0x348a: No channel available 0x3490: FAC Code unknown in this network 0x3491: requested service rejected 0x34a0: Outgoing calls barred 0x34a1: User access busy 0x34a2: Nonexistent CUG 0x34a3: Nonexistent CUG 0x34A5: Invalid or unknown destination 0x34b5: Destination not obtainable 0x34b8: Number changed 0x34b9: Out of order 0x34ba: No user responding 0x34bb: User busy 0x34bd: Incoming calls barred 0x34be: Call rejected 0x34d8: Invalid destination address 0x34d9: Network congestion 0x34da: Remote user initiated 0x34f0: Local procedure error 0x34f1: Remote procedure error 0x34f2: Remote suspended 0x34f3: Remote not suspended 0x34ff: Local reject of User to User info 0x4001: Stollmann: too many applications 0x4002: Stollmann: block size too large 0x4003: Stollmann: error on init of message queue 0x4004: Stollmann: no PLCI cntl block available 0x40ff: Stollmann: function not allowed in current context 0x4101: Verlust der Frame-Synchronisation 0x4201: Stollmann: can't deinstall, not on top of int chain 0x4202: Stollmann: can't deinstall, application still active B. Format der V.110 User Rate (ATS27): Bit 76 01 Erweiterung der asynchr. Uebertragung Bit 5 Bit 4 Bit 3 0 8 Datenbits 0 1 Stopbit 0 no parity 1 7 Datenbits 1 2 Stopbits 1 even parity Bit 210 000 38400 bit/s 11 Asynchr. Uebertragung mit Bitratenadaption nach CCITT V.110 Bit 5 Bit 4 Bit 3 0 8 Datenbits 0 1 Stopbit 0 no parity 1 7 Datenbits 1 2 Stopbits 1 even parity Bit 210 User Rate in bit/s 000 1200 001 1200/75 010 75/1200 011 2400 100 4800 101 9600 110 14400 111 19200 10 Synchrone Uebertragung mit Bitratenadaption nach CCITT V.110 (ist in unseren Breiten so gut wie nicht gebraeuchlich) Bit 54 10 never change Bit 3210 User Rate in bit/s 0000 1200 0001 1200/75 0010 75/1200 0011 2400 0100 4800 0101 9600 0110 14400 V.32bis 0111 19200 1000 48000 1001 56000 1010 56000 USA 1111 in band negatiation C. B2-Frames und Windowsizes bei X.75: Fuer alle, die immer noch glauben 16k Byte Frames und Windowsize 1 waeren eine gute Sache, hier ein paar Diagramme, die das Zeitverhalten mit unterschiedlichen Frame- und Windowsizes verdeutlichen sollen: Die Windowsize gibt an, wieviele Frames gleichzeitig losgeschickt werden duerfen, bevor der Sender eine Confirmation (conf) auf einen Frame empfangen muss, bevor er weitere Frames schicken darf. Windowsize 1, 2k Byte Frames: sender -<2kb daten>------<2kb daten>------<2kb ... receiver --------------------------- ... Totzeit ------------!!!!!!-----------!!!!!!---- ... zeit -----------------------------------------------> Bei 1 MB uebertragenen Daten hat man also 512 mal die CPS kostende Totzeit. Bei 16k Bytes Frames gibt es immer noch 64 mal diese Totzeit. Man kann also die maximale CPS Rate so nicht erreichen. Hier nun Windowsize 2 und 2kb Frames: sender --<2kb daten1><2kb daten2><2kb daten3><2kb daten4>-- receiver ------------------------------- zeit --------------------------------------------------------> Totzeit: keine! Eine Windowsize von 1 ist vergleichbar mit einer Datenuebertragung mit X-Modem, waehrend groessere Windowsizes mit der full-streamed Datenuebertragung von Z-Modem vergleichbar sind. Obwohl Z-Modem einen hoeheren Protokoll-Overhead hat, ist es doch schneller als X-Modem. CRC Fehler auf der ISDN Leitung: Die Telekom garantiert auf ISDN lines eine Fehlerrate kleiner 1:1000000. Also gibt es pro uebertragenes MB im schlechten Fall einen Frame-Resend. Der kostet bei 16k Byte Frames aber 2 sec (bei 64000 bps). Im Fehlerfall verliert man also pro Uebertragungsfehler bei 1 MB Daten ca. 300 CPS - bei 2k Byte Frames aber nur ca. 40 CPS ! D. Connect Probleme mit ISDN Blaster (X.75): Bei Stollmann und AVM Karten kann es Connect-Probleme bei X75 mit ISDN Blaster Karten geben, selbst wenn ihre Framesize auf 2k Bytes gestellt sind. Diese treten immer dann auf, wenn man eine ISDN Blaster anruft - nicht wenn man von einer angerufen wird und zwar dann, wenn die ISDN Blaster Karte mit dem FOSSIL Treiber PCIF V5.78 oder V5.80 betrieben wird. Dort legt die ISDN Blaster ein etwas atypisches Verhalten beim Aufbau der X.75 an den Tag. In der Version 5.82 ist dieses Problem geloest ! CPV/Stollmann User besorgen sich deshalb die allerneuesten CAPI Treiber bei CPV/Stollmann oder aus unserer Mailbox. Mit diesen ist es moeglich die ISDN Blaster Karte mit LAP B anzusprechen (TICAPI -b). Dabei treten diese Probleme naemlich nicht auf. Von AVM gibt es mittlerweile fuer alle Karten Treiber mit einem work-around fuer dieses Problem. Im Zweifel kann man 'cFos' aber auch mit -jp laden. Dies hilft zumindest bei PCIF V5.78 nicht aber bei PCIF V5.80. Auf jedenfall kann man aber mit V.110, 38400 connecten (ATB1) und dem Betreiber der Blaster Karte raten 2k Bytes Frames (bei Blaster ATS75=0x0800) und PCIF V5.82 zu verwenden. E. Connect Probleme zu ELINK "Modems": Viele Elink Besitzer stellen ihre "Modems" so ein, dass es entweder zu Connect Problemen fuehrt oder das Elink gar nicht erst abhebt. Um auch dieses Problem aus der Welt zu schaffen hier die Settings, damit die Elinks kompatibel sind. V.110-Subkanal (S18): 000 Betriebsart &B16 : 64kbps,sync Protokollmodus \N6 : X.75 Extended mode \X0 : aus SIN unbekannt \S1 : Ruf annehmen SIN <> abgehend \S3 : Ruf annehmen SIN abgehend \S5\S7 : herst.spez. Rate adjust \J1 : ein Blocklaenge \A3 : 256 Bytes XID-Prozedur : aus Wir bitten diese Settings jedem Elink Betreiber zukommen zu lassen. Ausserdem soll er die EPROM Release ab 2.12 benutzen, da dort noch einige Bugs behoben worden sind. F. CCB mit mehreren S0-Bussen unterschiedlicher Rufnummer: Abgehende Rufe: Um mehrere S0-Busse mit unterschiedlicher Telefonnummer an- rufen zu koennen kann man bei ATD Kommando mehrere Rufnummern, durch ':' oder '|' getrennt angeben, z.B. ATD 123456:234567. Sie werden folgendermassen verwendet: Kanaele Anwahl Kanal 1 Kanal 2 Kanal 3 Kanal 4 AT&B2 ATD A A A - - ATD A:B A B - - AT&B3 ATD A A A A - ATD A:B A A B - ATD A:B:C A B C - AT&B4 ATD A A A A A ATD A:B A A B B ATD A:B:C A A B C ATD A:B:C:D A B C D Mit 'A', 'B', 'C', 'D' sind natuerlich Telefonnummern gemeint. Zugegeben: Normalerweise braucht dies kein Mensch. Aber man kann auf diese Weise jemanden mit CCB anrufen, der z.B. 4 Kanal CCB unterstuetzt und zwar mittels zwei ISDN Karten in einem Rechner an zwei S0-Bussen mit unterschiedlicher Telefon- nummern. :-) Ankommende Rufe: Um CCB mit "aehnlichen" Caller Ids zu ermoeglichen gibt es das Register S49. Dies gibt an, wieviele Stellen beim Caller Id Vergleich (von rechts nach links) ignoriert werden sollen. Default ist 0. Beispiel: Man wird einem Caller mit dem S0-Bus mit den Telefonnummern 12345-01 und 12345-67 angerufen. (Er hat mehrere ISDN Karten an einer Telefonanlage.) Stellt man nun S49 auf 2 werden die '01' und '67' beim Caller Id Vergleich ignoriert. Fuer 'cFos' gibt es dann nur die Caller ID '12345'. Die Gesamt-Laengen der Caller Ids muessen aber uebereinstimmen. Der Normalfalls wird aber sicher sein, dass man die S0-Busse mit Sammelrufschaltung benutzt. So hat man obiges Problem mit mehreren Telefonnummern und Caller Ids nicht. :-) G. 'cFos' Modem Fehlermeldungen: ERROR Das Modem Command ist syntaktisch falsch, oder die im Command angegebenen Werte sind ausserhalb der (z.Z.) erlaubten Bereiche. ERROR/B2: Die Selektion des B2-Protokoll beim CAPI fuehrte zu einem Fehler. In den meisten Faellen bedeutet dies, dass das CAPI das jeweilige Protokoll nicht unterstuetzt. Wird z.B. versucht eine Verbindung mit V.110 aufzubauen, ohne dass das CAPI dieses Protokoll unterstuetzt, kann diese Fehlermeldung erscheinen (in diesem Fall sperrt cFos die V.110). ERROR/B3: Die Selektion des B3-Protokoll beim CAPI fuehrte zu einem Fehler. In den meisten Faellen bedeutet dies, dass das CAPI das jeweilige Protokoll nicht unterstuetzt. ERROR/LISTEN: Bei der Bestimmung auf welche Arten von einkommenden Rufen das CAPI/cFos hoeren soll ist nicht erlaubt. In diesem Falle sollte man die Werte fuer die Serviced SI Mask, die Info Mask und die Serviced EAZ Mask ueberpruefen, Register S13, S14, S41, S42. ERROR/CAUSE=xxxx Beim Verdindungsaufbau hat das CAPI einen Fehler gemeldet. Naeheres s. Anhang A. Meistens laesst sich dies durch Ueberpruefen der Modem Register beheben. H. Vertraeglichkeitsliste: 'cFos' laeuft u.a. mit folgender Software: Produkt Hersteller Programm-Typ ------- ---------- ------------ FrontDoor Absolute Solutions, Fido-Mailer Joaquim H. Homrighausen Intermail Peter Stewart Fido-Mailer BinkleyTerm Vince Perriello/Bob Hartman Fido-Mailer D'Bridge Chris Irwin Fido-Mailer Yuppie! ab V2.10 YEAsoft, Aachen Fido-Point System Portal of Power Soren Ager & The Portal Team Fido-Mailer CrossPoint ab V2.14 Peter Mandrella Point-System Maximus Scott J. Dudley BBS Software RemoteAccess Andrew Milner BBS Software PCBoard/M Clark Development BBS Software SuperBBS Risto Virkkala & Aki Antman BBS Software Terminate ab V1.40 Bo Bendtsen, Daenemark Terminal Prg TeleMate ab V4.12 White River Software Terminal Prg Unicom Data Graphics Terminal Prg PCPLUS/Procomm Plus Datastorm Technologies, Inc Terminal Prg HS/Link Samuel H. Smith Uebertragungs protokoll Engine CEXYZ Cutting Edge Computing Uebertragungs protokoll Engine PC-Anywhere Symantec, Inc. Remotecontrol for Windows Software DoorWay Marshall Dudley Remotecontrol Software DOS-CIM Compuserve, Inc. CompuServe Info.Manager WIN-CIM CompuServe Info.Manager XBTX Juergen Buchmueller, BTX Dekoder Bonn Waffle Darkside International UUCP BBS Prg cFos ist vertraeglich mit DesQView, MS-Windows, PAPI 0.16, X00, ISDN-Talk. Wir danken allen, die uns beim Testen diverser Software geholfen haben.