Mal eine Frage an die alten Z80 Experten hier..ich habe Probleme mit
einer Z80 Sio.
Ich versuche zu, bzw. habe einen Treiber geschrieben für seriellen
asynchronempfang mit der Z80 Sio der Hardware Handshake unterstützt.
die Hardware ist ein Einplatinen Lernsystem, Nachfolger des DDR LC80 (
http://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=11373
)
der um eine Sio erweitert wurde. Rein aus Jux habe ich das im Netz
gefundene Lochband des TDL 8K Basicinterpreters (nein, nicht der 12k)
konvertiert, disassembliert und portiert. Die Hardware des LC80ex
unterstützt derzeit nur 4800 Baud bei maximal 3,6 Mhz Taktfrequenz,
eigentlich dachte ich das die 3,6Mhz ausreichend sind das da der Z80
jedes Byte der seriellen Schnittstelle abholen kann, aber dem ist selbst
bei 4800 Baud und dem Interpreter dran nicht so.
Ich habe deshalb eine Weile herum geopert mit einem Umlaufpuffer und
erst gedacht das ich wohl ein Bisschen zu doof sei das in den Griff zu
bekommen, scheinbar liegts aber an der SIO:
"Sobald das RTS-BIT eines Kanals gesetzt ist, geht die zugehörige
RTS-Leitung in den Low-Zustand über. Wird das RTS-BIT in der asynchronen
Betriebsart rückgesetzt, geht die zugehörige RTS-Leitung in den
High-Zustand, sobald das Senderegister leer ist. In der synchronen
Betriebsart..."
D.h. das RTS reagiert wann es will wenn noch was im Senderpuffer ist was
wiederum nicht unwahrscheinlich ist wenn der Rechner jedes Zeichen als
Echo zum Terminal schickt...
Dieses Misfeature ist wohl dem Bug in der 6850 ACIA geschuldet die
mitten im Zeichen das Senden abbricht wenn RTS verschwindet. Mir ist
sonst nicht klar warum das in der SIO an den Sender geknotet ist..
Ich habe mal spaßeshalber auf DTR umverdrahtet welches sich voll
softwaremäßig kontrollieren läßt und das scheint so zu funktionieren.
Jedenfalls kann ich "ELIZA" aus der Maus aufs Terminal Window fallen
lassen und der LC80ex löffelt das ohne sich zu verschlucken.
Auf die Lösung bin ich durch Grübelei gekommen, habe das aber erst
gemacht als ich das Selbe im TCP/IP Stack hier
http://dr.ea.ms/update/lxt/ den ich auf der Suche nach anderen
Sio-Hardware-Handshake Quellen ausgegraben hatte, gefunden habe.
Ich finde trotz der großen Verbreitung der Z80 Systeme keine
"Referenzimplementierung" mit Interrruptbetrieb, Umlaufpuffer und
Hardwarehandshake, schon gar nicht mit RTS der Sio.
Senderseitig ist die Sache einfach, mit autoenable in WR3 unterstützt
die Sio da eine hardwaremäßige Kontrolle so das man bei blockender
Ausgabe nicht mal einen großartigen Handler dafür braucht.
Weiß hier Jemand mehr? Gutes Erinnerungsvermögen?
Gruß,
Holm
Holm T. schrieb:> Mir ist> sonst nicht klar warum das in der SIO an den Sender geknotet ist..
RTS schaltet(e) das Sendeteil des/eines Modems ein. Wär blöd, wenn das
Sendeteil schon abgeschaltet wird, bevor das letzte Zeichen die SIO
verlassen hat.
Heutzutage ist die Funktion noch nützlich, um den Transmitter einer
RS-485 zu steuern.
Das heutige Hardware-Handshake war "damals" ziemlich unüblich.
Leo C. schrieb:> RTS schaltet(e) das Sendeteil des/eines Modems ein. Wär blöd, wenn das> Sendeteil schon abgeschaltet wird, bevor das letzte Zeichen die SIO> verlassen hat.
Tja, das ist der angesprochene ACIA Bug.
> Das heutige Hardware-Handshake war "damals" ziemlich unüblich.
Nö, nur kaputt.
RTS heisst REQUEST to send. Es geht also nicht um das eigene Senden,
sondern um den Sender der Gegenseite. Dem sollte man ein "bereit zum
Senden" signalisieren, wenn der eigene Empfangspuffer leer ist.
Dummerweise gab es damals genau so viel Deppen wie heute, die munter ICs
gezeichnet haben, ohne sich im Klaren zu sein, was in der Praxis
wirklich abgeht.
So entstanden kaputte ACIAs und kaputte SIOs, undd aher haben sich die
Leute damals nicht auf Harwdare-Handshake verlassen können, sondern
mussten XON/XOFF verwenden. Was wiederum die Binärübertragung ruinierte.
Holm T. schrieb:> "Sobald das RTS-BIT eines Kanals gesetzt ist, geht die zugehörige> RTS-Leitung in den Low-Zustand über. Wird das RTS-BIT in der asynchronen> Betriebsart rückgesetzt, geht die zugehörige RTS-Leitung in den> High-Zustand, sobald das Senderegister leer ist. In der synchronen> Betriebsart...">> D.h. das RTS reagiert wann es will wenn noch was im Senderpuffer
Nein, nicht wann es will. Es reagiert sobald das Senderegister leer ist.
> Mir ist> sonst nicht klar warum das in der SIO an den Sender geknotet ist..
Na, weil der /RTS-Pin Oldschool-mäßig anzeigt, ob der (die?) SIO noch
etwas zu senden hat oder nicht. Solange was im Senderegister zum Senden
steht hat der SIO offensichtlich noch etwas zu senden. Also ist /RTS-Pin
== aktiv (low) richtig.
Das Problem was du faktisch hast ist ein anderes. Die Bedeutung /
Verwendung von RTS hat sich im Lauf der Zeit etwas geändert. RTS sagte
ursprünglich wirklich nur, ob der Sender senden möchte. Bei RTS/CTS
Handshake soll RTS anders interpretiert werden, nämlich dass die
Gegenseite (nicht die eigene) mit dem Senden beginnen/aufhören soll.
Eigentlich ist das ein völlig anderes Signal.
Verwendest du das Oldschool-RTS der SIO für RTS/CTS Handshakes, dann
bekommst du eine Verzögerung beim deaktivieren (high) von /RTS, nämlich
bis das Senderegister leer ist, wofür du sorgen solltest. Aktivieren
(low), also der Gegenseite anzeigen das sie senden soll, solltest du
allerdings jederzeit können. Was bedeutet, dass musst du zur gewünschten
Zeit in Software machen.
Holm T. schrieb:> Dieses Misfeature ist wohl dem Bug in der 6850 ACIA geschuldet die> mitten im Zeichen das Senden abbricht wenn RTS verschwindet.
Da verwechselst Du was. Das Problem hat nicht die 6850, sondern die
6551.
Michael B. schrieb:> RTS heisst REQUEST to send.
genau:
RTS: „Sendeanforderung“; Ein High-Pegel an diesem Ausgang signalisiert,
dass DTE Daten senden möchte [1]
> Es geht also nicht um das eigene Senden,> sondern um den Sender der Gegenseite.
Das ist Quatsch.
> So entstanden kaputte ACIAs und kaputte SIOs
Die SIO ist in dieser Hinsicht nicht kaputt.
Die RS-232- (und V24-) Schnittstelle dient zur Verbindung eines
Datenendgerätes mit einem Datenübertragungsgerät (Modem). Nur dafür
wurde sie definiert. Daß sie auch zur direkten Verbindung zweier
Datenendgeräte mißbraucht wird, dafür kann sie nichts.
[1] https://de.wikipedia.org/wiki/RS-232
Leo C. schrieb:> Holm T. schrieb:>> Mir ist>> sonst nicht klar warum das in der SIO an den Sender geknotet ist..>> RTS schaltet(e) das Sendeteil des/eines Modems ein. Wär blöd, wenn das> Sendeteil schon abgeschaltet wird, bevor das letzte Zeichen die SIO> verlassen hat.>> Heutzutage ist die Funktion noch nützlich, um den Transmitter einer> RS-485 zu steuern.>> Das heutige Hardware-Handshake war "damals" ziemlich unüblich.
Naja nö.
Aus dem Name Request To Send geht IMHO nicht hervor das das irgendwie
den eigenen Sender beeinflussen sollte wie Michael auch schon schreibt.
Andererseits ist es wohl nahezu unmöglich alle Seiten von V.24
Datenübertragungen zu kennen bzw. die möglichen Varianten.
und es ist eigentlich "unüblich" 2 DTEs miteinander zu koppeln mittles
Kreuzung der Leitungen. Die ITU V.43 geht auf RTS (105) zur
Flußkontrolle überhaupt nicht ein, auf CTS (106) schon, nur kommt eben
aus der DCE auch ein Signal Namens CTS...
Ein allerdings übliches "Nullmodem"(-kabel) kreuzt aber RTS mit CTS und
dieses Kabel gibts ja schon seit Jahrmillionen.
Ich würde nicht unbedingt sagen das die Sio von der Konstruktion her
kaputt ist, jedenfalls deutlich weniger kaputt als andere damals übliche
U(S)Arts. Irgendwas müssen die sich dabei gedacht haben sonst hätten die
das nicht implementiert und dann auch explizit nur im Asynchronmodus.
In den Synchronmodi verhält sich RTS der Doku nach exakt so wie es
programmiert wird. Haben die wirklich bei Zilog um den Bug der ACIA
drumherum gewurschtelt? Trouble shooting für ICs der Konkurrenz?
Gruß,
Holm
Rufus Τ. F. schrieb:> Holm T. schrieb:>> Dieses Misfeature ist wohl dem Bug in der 6850 ACIA geschuldet die>> mitten im Zeichen das Senden abbricht wenn RTS verschwindet.>> Da verwechselst Du was. Das Problem hat nicht die 6850, sondern die> 6551.
Ok, kann gut möglich sein, mit den Prozessorfamilien ohne Register kenne
ich mich nicht so dolle aus..ich werde versuchen mir das zu merken.
Gruß,
Holm
Jay schrieb:> Holm T. schrieb:>> "Sobald das RTS-BIT eines Kanals gesetzt ist, geht die zugehörige>> RTS-Leitung in den Low-Zustand über. Wird das RTS-BIT in der asynchronen>> Betriebsart rückgesetzt, geht die zugehörige RTS-Leitung in den>> High-Zustand, sobald das Senderegister leer ist. In der synchronen>> Betriebsart...">>>> D.h. das RTS reagiert wann es will wenn noch was im Senderpuffer>> Nein, nicht wann es will. Es reagiert sobald das Senderegister leer ist.>
Ach? Hatte ich das nicht schon irgendwo gelesen? :-)
>> Mir ist>> sonst nicht klar warum das in der SIO an den Sender geknotet ist..>> Na, weil der /RTS-Pin Oldschool-mäßig anzeigt, ob der (die?) SIO noch> etwas zu senden hat oder nicht. Solange was im Senderegister zum Senden> steht hat der SIO offensichtlich noch etwas zu senden. Also ist /RTS-Pin> == aktiv (low) richtig.>> Das Problem was du faktisch hast ist ein anderes. Die Bedeutung /> Verwendung von RTS hat sich im Lauf der Zeit etwas geändert. RTS sagte> ursprünglich wirklich nur, ob der Sender senden möchte. Bei RTS/CTS> Handshake soll RTS anders interpretiert werden, nämlich dass die> Gegenseite (nicht die eigene) mit dem Senden beginnen/aufhören soll.> Eigentlich ist das ein völlig anderes Signal.>> Verwendest du das Oldschool-RTS der SIO für RTS/CTS Handshakes, dann> bekommst du eine Verzögerung beim deaktivieren (high) von /RTS, nämlich> bis das Senderegister leer ist, wofür du sorgen solltest. Aktivieren> (low), also der Gegenseite anzeigen das sie senden soll, solltest du> allerdings jederzeit können. Was bedeutet, dass musst du zur gewünschten> Zeit in Software machen.
Ok, durchaus glaubwürdige Interpretation. Es ist allerdings hinsichtlich
des Datendurchsatzes ziemlich schräg erst den Senderpuffer leer laufen
zu lassen bevor man RTS abschalten kann. Klar kann man einem Semaphor
implementieren der das bewerkstelligt, aber der Aufwand ist immens.
Da ich 64 Byte Ringpuffer hatte und sich die Kiste trotzdem verschluckt
hat weist das darauf hin das der Senderpuffer kaum mal von alleine leer
wird obwohl die Sendeseite im Polling arbeitet (dort mach die Hardware
das Handshaking und ich denke der PC ist auch so schnell genug das er
4800 Bd vertragen kann).
Aus heutiger Sicht ist es doof das die Sio die Handshake-Hardware für
den Sender und nicht für den Empfänger implementiert.
Gruß,
Holm
Holm T. schrieb:> unterstützt derzeit nur 4800 Baud bei maximal 3,6 Mhz Taktfrequenz
9600 Baud bei 2,4 MHz CPU waren mit dem SIO möglich. So wurden
nachweislich V24-Drucker z.B. LX86, 1162 und Modems angesteuert. Es gab
aber bei V24 regelmäßig Verwirrung mit den Brücken bei HW-Handshake.
Frag mal im Museum.
Holm T. schrieb:> Aus heutiger Sicht ist es doof das die Sio die Handshake-Hardware für> den Sender und nicht für den Empfänger implementiert.
Es ist eben keine "Handshake-Hardware" sondern eine
"Modem-Control-Hardware".
Es spricht aber nichts dagegen, für Deinen Zweck die DTR-Leitung zu
nehmen (Hast Du ja schon getstet).
Holm T. schrieb:> Ok, durchaus glaubwürdige Interpretation. Es ist allerdings hinsichtlich> des Datendurchsatzes ziemlich schräg erst den Senderpuffer leer laufen> zu lassen bevor man RTS abschalten kann.
Dafür war /RTS ursprünglich nicht gedacht. Der alte Oldschool-Ablauf für
RTS war grob:
DTE (Data Terminal Equipment, "Computer") aktiviert RTS um dem DCE (Data
Communication Equipment, Modem) mitzuteilen, dass es (das Terminal)
Daten senden möchte.
Das Modem stellte darauf hin (Pfeifkonzert) die Verbindung mit der
Gegenseite her, wenn es noch keine Verbindung hatte.
Nachdem die Verbindung stand informierte das Modem das Terminal durch
setzen von CTS dass das Terminal jetzt senden kann.
Erhielt das Terminal CTS begann es mit dem Senden.
> Aus heutiger Sicht ist es doof das die Sio die Handshake-Hardware für> den Sender und nicht für den Empfänger implementiert.
RS-232: Anfang der 60er entstanden
Z80 SIO: Um 1977 entstanden
Neue Interpretation von RTS/CTS: Gegen Ende der 80er entstanden.
oszi40 schrieb:> Holm T. schrieb:>> unterstützt derzeit nur 4800 Baud bei maximal 3,6 Mhz Taktfrequenz>> 9600 Baud bei 2,4 MHz CPU waren mit dem SIO möglich. So wurden> nachweislich V24-Drucker z.B. LX86, 1162 und Modems angesteuert. Es gab> aber bei V24 regelmäßig Verwirrung mit den Brücken bei HW-Handshake.> Frag mal im Museum.
:-)
Glaubs mir einfach, ich habe keine Sorgen damit Baudraten und
Teilerfaktoren zu berechnen. es liegt auch nicht an der CPU Taktfrequenz
sondern am Vorteiler des CTC der hier Baudratengenerator spielt. Wenn
man den Clockeingang des CTC mit der halben Taktfrequenz verbindet ist
mehr möglich.
Gruß,
Holm
Holm T. schrieb:> Clockeingang des CTC mit der halben Taktfrequenz verbindet ist> mehr möglich.
Recherisch bestimmt, aber auch die zugehörige Z80-CPU braucht genügend
Rechenzeit und die verwendeten Kabel müssen von der Länge her noch
brauchbar sein.
Man sollte bei der klassischen Verwendung von RTS/CTS an Modems im
Halfduplex-Betrieb denken. Wenn also immer nur eines der beiden senden
darf. Dann wird es verständlich.
Jay schrieb:> Neue Interpretation von RTS/CTS: Gegen Ende der 80er entstanden.
Hardware-Handshake gab es schon früher, im Zusammenhang mit seriellen
Terminals und Druckern. Ich meine freilich, dass Drucker dafür ein
anderes Leitungspaar verwendeten.
A. K. schrieb:> Hardware-Handshake gab es schon früher, im Zusammenhang mit seriellen> Terminals und Druckern. Ich meine freilich, dass Drucker dafür ein> anderes Leitungspaar verwendeten.
DTR/DSR
oszi40 schrieb:> Holm T. schrieb:>> Clockeingang des CTC mit der halben Taktfrequenz verbindet ist>> mehr möglich.>> Recherisch bestimmt, aber auch die zugehörige Z80-CPU braucht genügend> Rechenzeit und die verwendeten Kabel müssen von der Länge her noch> brauchbar sein.
Was willst Du denn? Meinst Du mit 3,6864 Mhz geht weniger als Mit
2,4576?
Nochmal: Ich habe keine Probleme mit Baudraten.
Gruß,
Holm
Jay schrieb:> A. K. schrieb:>> Hardware-Handshake gab es schon früher, im Zusammenhang mit seriellen>> Terminals und Druckern. Ich meine freilich, dass Drucker dafür ein>> anderes Leitungspaar verwendeten.>> DTR/DSR
Kein DSR an einer Sio...
Gruß,
Holm
Holm T. schrieb:> Jay schrieb:>> A. K. schrieb:>>> Hardware-Handshake gab es schon früher, im Zusammenhang mit seriellen>>> Terminals und Druckern. Ich meine freilich, dass Drucker dafür ein>>> anderes Leitungspaar verwendeten.>>>> DTR/DSR>> Kein DSR an einer Sio...
Ja und? Nur weil die SIO keinen DSR-Pin hat ändert es nichts daran, dass
DTR/DSR die andere Art ist HW-Handshake zu machen. Missbrauch CTS,
verwende einen anderen GIO-Pin, was auch immer. Die SIO ist nun mal fast
40 Jahre alt, da musst du freundlich zu der alten Dame sein.
Holm T. schrieb:> mit den Prozessorfamilien ohne Register kenne ich mich nicht so dolle> aus
Haha.
Der Clown ist kaputt, er ist nicht komisch. Selbst der kastrierte 6502
hatte etliche Register.
Rufus Τ. F. schrieb:> Der Clown ist kaputt, er ist nicht komisch. Selbst der kastrierte 6502> hatte etliche Register.
Was nicht heisst, dass alle Prozessorfamilien notwendigerweise frei
verwendbare Register hätten. Es geht auch ohne.
Rufus Τ. F. schrieb:> Holm T. schrieb:>> mit den Prozessorfamilien ohne Register kenne ich mich nicht so dolle>> aus>> Haha.>> Der Clown ist kaputt, er ist nicht komisch. Selbst der kastrierte 6502> hatte etliche Register.
Dein Schlips hängt wohl ziemlich weit runter ehy? ..oder war das gar
nicht Dein Schlips?
Ich korrigiere mich:
"mit den kastrierten Prozessorfamilien kenne ich mich nicht so dolle
aus"
ist Dir jetzt besser?
Gruß,
Holm
Jay schrieb:> Holm T. schrieb:>> Jay schrieb:>>> A. K. schrieb:>>>> Hardware-Handshake gab es schon früher, im Zusammenhang mit seriellen>>>> Terminals und Druckern. Ich meine freilich, dass Drucker dafür ein>>>> anderes Leitungspaar verwendeten.>>>>>> DTR/DSR>>>> Kein DSR an einer Sio...>> Ja und? Nur weil die SIO keinen DSR-Pin hat ändert es nichts daran, dass> DTR/DSR die andere Art ist HW-Handshake zu machen. Missbrauch CTS,> verwende einen anderen GIO-Pin, was auch immer. Die SIO ist nun mal fast> 40 Jahre alt, da musst du freundlich zu der alten Dame sein.
Gottchen, ja doch. Ich ziehe die Hosen nicht mit dem Kran an.
Gruß,
Holm
Rufus Τ. F. schrieb:> Der Clown ist kaputt, er ist nicht komisch. Selbst der kastrierte 6502> hatte etliche Register.
... SIO..."Zusätzlich zum 8-bit-Empfängerschieberegister besitzt der
Empfänger in einer FIFO-Anordnung drei 8-bit-Pufferregister, um eine
3-byte-Verzögerung zu erreichen. Durch diese Anordnung wird der CPU
zusätzliche Zeit für... verschafft". ...meint Kieser-Meder S.113
Ob sie in diesem Mode genutzt werden? Da muß wohl ein SIO-Profi ans
Werk.
da man den r Byte Fifo in der Sio weder ein noch ausschalten kann sehe
ich keine Grund warum der nicht funktionieren sollte, der ist implizit
immer an.
Oszi40 ich habe irgendwie das Gefühl das Du an einer ganz anderen
Baustelle kämpfst. Kann ich Dir irgendwie helfen? Für mich ist die Sache
an und für sich geklärt, es ging mir ja nur um das Zeitverhalten der SI
internen RTS Steuerung.
Gruß,
Holm
Holm T. schrieb:> irgendwie helfen?
Danke, zu historisch. Gern erinnere ich mich in diesem Zusammenhang nur
noch die großen Augen der weitgereisten Entwickler als sie das erste Mal
ihren volllllllllständig mit Leiterplatten bestückten MUX sahen und die
Zeitscheibe der CPU im Betrieb nicht mehr reichte um alle Anschlüsse
zuverlässig zu bedienen. :-)
@Oszi40: Keine Ahnung von welchem Mux Du redest, aber ich habe hier 2
Muxer in der PDP11 unterm Tisch die auf jeweils 8 Lines ausgelegt sind
und bei denen empfohlen wird nur jeweils 4 zu nutzen weil es sonst die
8051 CPU auf den Dingern nicht schafft die Leitungen zu bedienen..
Hersteller dieser Muxer ist DEC (frage mich nicht nach dem Typ, ich weiß
nur Emulex konnte es besser. Von Denen treibst sich auch noch eine
Platine hier herum).
Die langen Gesichter wirds wohl also auch in Maynard Mass. gegeben
haben.
Gruß,
Holm
Nachtrag: DHV11, SCN2681 Uarts.
Der MUX der K1840 benutzte IMHO SCN2661 und die CPU war die selbe AM2901
Bit-Slice Mimik wie beim Original. Da wurde also ein eventueller Fehler
im Design mitkopiert.
Gruß,
Holm
