home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Crawly Crypt Collection 1
/
crawlyvol1.bin
/
bbs
/
bt313a
/
docs
/
seriinfo.txt
< prev
next >
Wrap
Text File
|
1993-05-18
|
15KB
|
336 lines
Msg #55 / 1-65 Time: 12 May 93 13:12:46
From: Stefan Haake on 2:2407/35
To : Joerg Spilker on 2:245/96.42
Subj: Re: Serielle Schnittstellen
---------[FidoNetmail ]-----------------------------------------------
⇧MSGID: 2:2407/35@FidoNet AF8BB131
⇧REPLY: 2:2401/103.6@fidonet.org ed547800
⇧PID: LED 1.04/b
This message was originally addressed to Joerg Spilker on
2:245/96.0@fidonet.org and was re-addressed by 2:245/96@fidonet.org
* Originally from Area 'MAIL'
* Originally to Stephan Slabihoud
* Forwarded by Stephan Slabihoud on 2:2401/103.6, 14 May 93 18:20:24
In a message of <09 May 93 19:55:44>, Stephan Slabihoud (2:2401/103.6) writes:
[(u.a. :-) in Area 'ST_FIDO.GER']
Hallo Stephan
SS> Der Joerg Spilker und ich arbeiten ja fieberhaft daran, Binkley an
SS> ALLE Atari-Rechner anzupassen. Leider haben wir von den ganzen
Das ist ein löbliches Unterfangen.
SS> Wie koennen wir das CD (Carrier Detect) und CTS-Signal auf allen
SS> existierenden Schnittstellen direkt abfragen?
Ich bin kein Programmierer, aber folgendes hab ich aus diversen Mails entnehmen
können (es deckt sich mit der Anleitung des TT, den Du doch auch Dein Eigen
nennst, oder?):
Serial1 hat kein CD und kein RI, RTS ist immer an => auch kein CTS
Serial2 hat keinen RI (braucht Binkley den überhaupt?)
SS> Auch wuerde uns interessieren, wie Modem-1, Seriell-1 und Seriell-2
SS> auf 38400, 57600 und 115200 Bps eingestellt werden kann!
Zu Modem1 würde ich vorschlagen (bitten), die Anleitungen zu RSVE (das benutze
ich) und RS-Speed zu konsultieren.
Was mir aber besonders am Herzen liegt, ist die Unterstützung (oder zumindest
Rücksichtnahme) auf MiNT! Seit der Version 1.04 läuft es eigentlich ständig bei
mir, und mein langjähriger Traum von einer Mailbox nebenbei ist nahezu
verwirklicht. Leider verhält sich Binkley aber noch nicht so gut, wie es sein
könnte. Dank RSVE und HSMODEM1 sind die Übertragungsraten beim Senden
mittlerweile so gut wie ohne MiNT (vorher war dem nicht so). Beim Empfangen
lassen sie aber immernoch zu wünschen übrig (1000-1200 cps bei 14400 oder 16800
Connect). Janus geht übrigens überhaupt nicht. Vielleicht könntet Ihr Euch mal
mit Harun Scheutzow (MAUS B) in verbindung setzen, der entwickelt ein HSMODEM
mit "echter" MiNT-Unterstützung (-Ausnutzung). Damit sollen die
Übertragungsraten unter MiNT sogar besser werden können als ohne! Soviel ich
weiβ, arbeitet auch Franz Sirl (Maus M) an soetwas (Fast Serial).
Das speziell zur Übertragung, aber auch allgemein kann man das Verhalten von
Binkley unter MiNT sicher verbessern. Binkley verbrät ständig ca. 50%
Rechenzeit, auch wenn er "nichts" tut, was in meinen Augen vollkommen unnötig
ist. Als Beispiel, wie man's anders machen kann, möchte ich MTT
(MausTauschTerminal, kennst Du das?) nennen. Dort wird die Priorität den
Notwendigkeiten angepasst. Wenn er nicht viel braucht (sogar bei der Anwahl),
setzt er seine Priorität auf -16. Wenn er dann "schaffen" muβ, setzt er sie auf
0, und wenn das nicht reicht, z.B. bei HighSpeed-übertragungen (wie er das
merkt, weiβ ich nicht), setzt er sie auf +16. Damit sind dann normal hohe
Übertragungsraten möglich. Auch wenn Binkley ohne bestehenden Connect mehr
machen muβ (auf Ring warten, Events checken etc.), sollten dafür weniger als
50% TT-Power reichen, oder? :-)
Achja: Alle Angaben über Rechenzeitanteile und Übertragungsraten ohne
zeitaufwendige parallele Prozesse.
So, und wenn ich schonmal dabei bin, noch ein paar andere Dinge, die vielleicht
nicht in Deinen Zuständigkeitsbereich fallen:
Auf ein Problem möchte ich nochmal hinweisen, was dem Jörg aber bekannt sein
sollte: Wenn ich AKAs drin habe, schickt mir Binkley (auf der anderen Seite)
keine Protected Only Sachen, auch wenn das Passwort stimmt. Ohne AKAs geht's.
Ich polle bei einem Frodo, brauche aber das "FDBugFix" nicht. Bei mir hat sich
das Problem gelöst, als ich vor einem guten Jahr das 2400/MNP-Modem gegen ein
ZyXEL ausgetauscht habe. Das ESC-Problem, das mit "FDBugFix" gelöst werden
soll, ist doch das, daβ man ESC drücken muβ, um die Übertragung anzustoβen,
oder? Oder ist das Mausbewegen -> ESC empfangen gemeint?
Und noch eine Frage an Dich: Du bist ja wohl an einigen Fidoprogrammen noch am
basteln. Ist da auch Bythalon dabei? Es läuft unter MiNT nämlich nicht korrekt.
Zum einen stimmt die Bildschirmausgabe im TOSWIN nicht richtig, zum anderen
hängt das System beim Beenden (wenn im TOSWIN gestartet). Hast Du es in GFA
programmiert? Zumindest letzteres ist mir bisher nämlich nur bei GFA-Programmen
passiert. Auβerdem ist eine Dialogbox (wenn nicht genug Plattenplatz da ist) in
einem TTP nicht besonders gut. Vielleicht kannst Du eine vorherige Abfrage des
Plattenplatzes einbauen. Da ich ACS nicht zum Löschen nach Tagen überreden
kann, benutze ich Bythalon halt immernoch. Aus o.g. Gründen kann ich es aber in
mein Batch nicht einbauen.
So, das soll's für's erste gewesen sein. Ich würde mich freuen, wenn Du trotz
aller Arbeit, die Du Dir machst, noch ein wenig Zeit für eine Antwort auf diese
Mail finden würdest. Thanx und
Ciao, Stefan
P.S.: da fällt mir noch was ein: Unter MiNT legt Binkley seine Hilfsfiles
(.SCD, EMSI_DAT) manchmal auf der Rootebene statt dem Conf-Directory der
DFÜ-Partition ab. Vielleicht hat einer von Euch eine Idee, woran das liegen
kann.
===========================================================================
Stephan Slabihoud 2:2401/103.6@fidonet.org 51:601/7.6@atarinet.ftn
===========================================================================
⇧Via JetMail 0.87beta 2:2401/103.6@fidonet.org, May 14 1993 at 18:31
⇧Via FastEcho+ 2:2401/103@fidonet.org, Sat 15 May 93 at 10:59
⇧Via MTraX+ @2:2401/1.0, Sat, 15-May-93 09:23 UTC
⇧Via FrontDoor 2:2401/1, May 15 1993 at 17:16
⇧Via Itrack At 2:245/3@FidoNet, Sat 15 May 1993 16:29:34.49 UTC
⇧Via Squish 2:245/3.0, Sat May 15 1993 at 16:30 UTC
⇧Via Squish 2:245/54.0, Sun May 16 1993 at 01:40 UTC
⇧Via Squish 2:245/52.0, Sun May 16 1993 at 14:37 UTC
⇧Via JetMail 0.88beta 2:245/96@fidonet.org, May 18 1993 at 07:28
⇧Via JetMail 0.88beta 2:245/96.42@fidonet.org, May 18 1993 at 19:40
Msg #57 / 1-65 Time: 12 May 93 13:13:56
From: Philipp Reitberger on 2:2403/37.14
To : Joerg Spilker on 2:245/96.42
Subj: Re: Serielle Schnittstellen
---------[FidoNetmail ]-----------------------------------------------
⇧MSGID: 2:2403/37.14@FidoNet B1207513
⇧REPLY: 2:2401/103.6@fidonet.org ed547801
⇧PID: LED 1.04/b
This message was originally addressed to Joerg Spilker on
2:245/96.0@fidonet.org and was re-addressed by 2:245/96@fidonet.org
* Originally from Area 'MAIL'
* Originally to Stephan Slabihoud
* Forwarded by Stephan Slabihoud on 2:2401/103.6, 16 May 93 10:01:40
SS> Der Joerg Spilker und ich arbeiten ja fieberhaft daran, Binkley an ALLE
SS> Atari-Rechner anzupassen.
Hallo Stephan!
Ich selber kann Dir zwar nicht bei Euren Problemen helfen, aber ich besitze
eine Programm, das die von Euch gestellten Anforderungen erfüllt. Ich schick
einfach mal die Beschreibung, bei Fragen müβt Ihr euch halt an den Autor des
Programms wenden. Ich hoffe ich kann Euch damit helfen. Hier nun die
Beschreibung (Auszugsweise):
Fast_Ser
========
Fast_Ser ist ein erweiterter Treiber für serielle Schnittstellen
auf dem STE/TT (wer hat Unterlagen zum Falcon?).
Für Modem/Serial 1 (MFP) ist eine erweiterte Rsconf-Auskunftsfunktion
implementiert. Für Modem/Serial 2 (SCC) sind zusätzlich alle Bco...-
und Interrupt-Routinen neu (und hoffentlich fehlerfrei) implementiert,
und die Baudratentabelle ist mit eigenen Werten programmierbar.
Fast_Ser stellt eine Standardschnittstelle zur jeweiligen
Hardware mit Hilfe der Rsconf-Funtion her.
- Cookie 'FSER', zeigt auf Struktur FSER_INFO:
typedef struct
{
UWORD version;
unsigned unused:15;
unsigned baud_table_flag:1; /* bit 0 in einem word */
BASPAG *mem_blk;
} FSER_INFO;
- Rsconf( -3, -2, xx, xx, xx, xx ) liefert 'FSER' als long
- Rsconf( -3, -3, xx, xx, xx, xx ) liefert einen Pointer auf die
Struktur CHAN_INFO, die wie folgt definiert ist:
typedef struct
{
BAUD_INFO *baud_table;
BAUD_INFO *alt_baud_table;
UBYTE **chip_address;
UWORD chip_type;
unsigned flags:14;
unsigned extrd_flag:1; /* bit 1 in einem word */
unsigned irq_flag:1; /* bit 0 in einem word */
WORD task;
UBYTE WR5;
UBYTE RR0;
WORD resv[2];
ULONG dcd_on;
ULONG dcd_off;
UWORD rxbuffer_overflows;
UWORD framing_errs;
UWORD parity_errs;
UWORD charlost_errs;
} CHAN_INFO;
typedef struct
{
LONG baudrate;
UWORD SCC_BRG_value;
UWORD SCC_MISC_value; /* bit 15..14 Clock mode (Reg. 4)
bit 9..8 BRG mode (Reg. 14)
bit 6..3 Rx/Tx Clock Source (Reg. 11)
*/
} BAUD_INFO;
baud_table: Zeiger auf die Tabelle mit den Baudrateninfos, in der
eine Null bei 'baudrate' das Ende markiert, -1 steht
für eine nicht verfügbare Baudrate (nur bei den
ersten 16 Standardeinträgen!!),
-2 für einen freien Eintrag
alt_baud_table: wie baud_table, nur sind hier an den Indices
0 und 1 höhere Baudraten eingefügt. Dadurch können
auch Programme, die Fast_Ser nicht direkt unter-
stützen, die höheren Baudraten nutzen
chip_address: Hardwareadresse des Chips bzw. der internen
Peripherie bei 68302, etc
z.b $FFFF8C81 für Serial 2 auf MSTE/TT
chip_type: Welcher Chiptyp hängt an diesem Kanal dran?
$00: MFP
$10: Standard-SCC 8530
$11: VLSI-SCC VL85C30
$12: Zilog-SCC Z85C30
$13: AMD-ESCC Am85C30
$14: Zilog-ESCC Z85230
$15: AMD-ESCC Am85C230A
$20: ISDN-Coprozessor MC68302
$30: Ethernet-Coprozessor
flags: verschiedene bislang unbenutzte Flags
extrd_flag: Beim SCC ist in WR7' das ExtendedRead-Flag gesetzt.
irq_flag: gesetzt: Die Interruptroutinen nutzen die SCC-FIFOS.
task: hier trägt eine Task, die die Schnittstellenhardware für
sich haben will, ihre Nummer ein.
-1 steht für nicht reserviert.
WR5: Shadow Write Register 5 of SCC
RR0: wird bei jedem CTS oder DCD Wechsel mit Read Register 0
besetzt
dcd_on: letzter hz_200-Zeitpunkt, an dem DCD aktiv wurde
dcd_off: letzter hz_200-Zeitpunkt, an dem DCD inaktiv wurde
rxbuffer_overflows: Anzahl der Charakter, die bei einem vollem
Empfangsbuffer verlorengingen
framing_errs: Anzahl der empfangenen Charakter mit Framing-Fehler
(SCC-bedingt ein unsicherer Wert)
parity_errs: Anzahl der empfangenen Charakter mit Parity-Fehler
charlost_errs: Anzahl der Charakter, die verlorengingen, weil der
SCC nicht schnell genug abgefragt wurde
(tatsächliche Anzahl kann größer sein!)
Bei den Standard-Clockraten für den SCC unterstützt Fast_Ser momentan
folgende Baudratenliste (auf die alt_baud_table zeigt):
Liste für den MSTE
Index: Modem 2: Serial 2: Original:
0: 57600 57600 19200
1: 38400 38400 9600
2: 19200 19200 4800
3: 9600 9600 3600
4: 4800 4800 2400
5: 3600 3600 2000
6: 2400 2400 1800
7: 2000 2000 1200
8: 1800 1800 600
9: 1200 1200 300
10: 600 600 200
11: 300 300 150
12: 200 200 134
13: 150 150 110
14: 134 134 75
15: 110 110 50
16: 75 75
17: 50 50
18: 38400 38400
19: 57600 57600
20: 76800 115200
21: 153600
Liste für den TT:
Index: Modem 2: Serial 2: Original:
0: 38400 57600 19200
1: 76800 38400 9600
2: 19200 19200 4800
3: 9600 9600 3600
4: 4800 4800 2400
5: 3600 3600 2000
6: 2400 2400 1800
7: 2000 2000 1200
8: 1800 1800 600
9: 1200 1200 300
10: 600 600 200
11: 300 300 150
12: 200 200 134
13: 150 150 110
14: 134 134 75
15: 110 110 50
16: 75 75
17: 50 50
18: 38400 38400
19: 76800 57600
20: 153600 115200
Hardwarebug!
Serial 2 beim MSTE hat einen Hardwarebug, der Zeichen verschluckt.
Achtung!!
Die Verschiebung der Baudratentabelle gilt nur solange die üblichen
Terminalprogramme wie CoNnect oder Rufus dieses oder ein anderes
erweitertes Protokoll zum Ansprechen der höheren Baudraten nicht
unterstützen. Über die Baudraten mit einem Index größer 15 sind
keine Annahmen zulässig. (Abfragen mit Rsconf!)
So das war's vorläufig!
Falls jemand Fehlermeldungen, Wünsche, etc hat, bitte melden bei:
Post:
Franz Sirl
Bischof-Adalbert-Str. 29
8000 München 40
Maus:
Franz Sirl@M
===========================================================================
Stephan Slabihoud 2:2401/103.6@fidonet.org 51:601/7.6@atarinet.ftn
===========================================================================
⇧Via JetMail 0.87beta 2:2401/103.6@fidonet.org, May 16 1993 at 10:13
⇧Via FastEcho+ 2:2401/103@fidonet.org, Sun 16 May 93 at 18:05
⇧Via MTraX+ @2:2401/1.0, Sun, 16-May-93 21:07 UTC
⇧Via FrontDoor 2:2401/1, May 17 1993 at 3:30
⇧Via Itrack At 2:245/3@FidoNet, Mon 17 May 1993 03:03:43.19 UTC
⇧Via Squish 2:245/3.0, Mon May 17 1993 at 03:04 UTC
⇧Via Squish 2:245/54.0, Mon May 17 1993 at 13:44 UTC
⇧Via Squish 2:245/52.0, Mon May 17 1993 at 17:22 UTC
⇧Via JetMail 0.88beta 2:245/96@fidonet.org, May 18 1993 at 07:28
⇧Via JetMail 0.88beta 2:245/96.42@fidonet.org, May 18 1993 at 19:40