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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.