Ich habe ein Gerät das Daten direkt an einen Parallel Port Drucker ausgibt. Nun habe ich keinen Parallel Port Drucker mehr. Jetzt meine Frage, wie wurden die ersten Parallel Port Drucker von MS-Dos angesteuert? Wurde da einfach das Ascii Zeichen auf den Datenbus gelegt und dann ein Strobe gesendet. Für neue Zeile ein Line Feed und dann druckte der Drucker die Zeile? Ich weiß zwar grundsätzlich wie bei IBM Pc der Parallel Port angesteuert wurde. Habe aber keine Infos wie das Protokoll beim Drucken war. Könnte ich also in der Theorie, die parallelen Daten mit einem AVR einlesen und dann einfach auf die serielle Schnittstelle kopieren und bekommen den Stream der Ascii Zeichen ausgegeben um ihn in einem Terminal Programm am PC anzuzeigen?
Johannes M. schrieb: > Jetzt meine Frage, wie wurden die ersten Parallel Port Drucker von > MS-Dos angesteuert? Wurde da einfach das Ascii Zeichen auf den Datenbus > gelegt und dann ein Strobe gesendet. Für neue Zeile ein Line Feed und > dann druckte der Drucker die Zeile? Grundsätzlich: JA
Johannes M. schrieb: > Wurde da einfach das Ascii Zeichen auf den Datenbus > gelegt und dann ein Strobe gesendet. Für neue Zeile ein Line Feed und > dann druckte der Drucker die Zeile? Im Prinzip Ja. Für Grafik bei ESC A nachlesen, welche Befehle für eine Grafik-Zeile benutzt werden. Es gibt auch einige andere ESC-Sequenzen, z.B. zur Schriftauswahl. Übrigens: CR und LF. Der Drucker macht eben genau das was befohlen ist. Georg
Johannes M. schrieb: > Jetzt meine Frage, wie wurden die ersten Parallel Port Drucker von > MS-Dos angesteuert? Google nach IEEE 1284 oder Centronics Port zusammen mit Timing
Cyblord -. schrieb: > Johannes M. schrieb: >> Jetzt meine Frage, wie wurden die ersten Parallel Port Drucker von >> MS-Dos angesteuert? Wurde da einfach das Ascii Zeichen auf den Datenbus >> gelegt und dann ein Strobe gesendet. Für neue Zeile ein Line Feed und >> dann druckte der Drucker die Zeile? > > Grundsätzlich: JA ...wenn der Drucker den entsprechenden Mod unterstütz (was aber wohl die meisten getan haben). Aber eine ganze Reihe von Druckern hat durchaus auch andere Dialekte wie z.B.: PCL verstanden. Da ist die "Formatierung" schon etwas anspruchsvoller. - https://de.wikipedia.org/wiki/IEEE_1284 - https://de.wikipedia.org/wiki/Printer_Command_Language
Johannes M. schrieb: > Ich habe ein Gerät das Daten direkt an einen Parallel Port Drucker > ausgibt. Nach der Hardware und dem Timing ist die Frage also: Was für Daten?
Das Gerät ist von 1989 und sendet eigentlich nur Statistikdaten in Textform. Daher würde ich zunächst erstmal davon ausgehen, dass es keine PCL codierten Daten sind. Dann werde ich mir das mal in Ruhe anschauen. Danke schonmal für eure Antworten.
Die "Centronix" Parallelschnittstelle hatte 8 Datenleitungen und 3 Handshakesignale. Als Handshake wurden anfangs meist nur das ready / not busy-Signal vom Drucker genutzt. Wenn der Ready signalisierte, wurde ein Datenbyte (meist 7-Bit ASCII und das 8.Bit auf Null) angelegt und dann dem Drucker mit einem Strobe-Impuls signalisiert, dass die Daten für ihn bereit standen. Dann gab der Drucker ein not ready- Signal aus als Signal, dass er das Zeichen nun verarbeiten würde. Ging das Signal wieder auf ready, konnte das nächste Zeichen gesendet werden. Alternativ konnte der Drucker als Antwort auf den Datenstrobe auch ein acknowledge (auf der dritten Handshakeleitung) senden und so dem Rechner zeigen, dass das Datenwort angekommen war. Diese Signale wurden später weitgehend so auf dem IEC-Bus übernommen,dass ein Centronix kompatibler Drucker direkt an den Bus angeschlossen werden konnte und den Datentransfer ausdruckte. An die Parallelschnittstelle konnte übrigens auch ein UART wie der AY3-1014 von General Instruments angeschlossen werden. Dieser gab dann die Daten über eine RS232-Schnittstelle aus. Auch hier "passten" die Steuersignale zu dem UART.
Unter MS-DOS gibt es aber doch auch die Möglichkeit, die LPTx-Ausgabe direkt auf eine serielle Schnittstelle umzuleiten, dann sparst Du Dir die Sache mit dem AVR. "MODE" heisst der Befehl.
Additionelle Suchbegriffe : Epson FX80 Das war jahren lang ein breit unterstuetzten Drucker
Johannes M. schrieb: > Das Gerät ist von 1989 und sendet eigentlich nur Statistikdaten in > Textform. Daher würde ich zunächst erstmal davon ausgehen, dass es keine > PCL codierten Daten sind. Da würde ich das Gerät mal aufschrauben und schauen ob da EPROMs drin sind. Und falls ja von denen eine Sicherheitskopie anfertigen. Nicht dass kippende Bits das nächste Problem werden...
Günni schrieb: > Die "Centronix" Parallelschnittstelle hatte 8 Datenleitungen und 3 > Handshakesignale. Als Handshake wurden anfangs meist [...] Handshake gut erklärt! Das Ding schreibt sich allerdings „Centonics“. Centronics hing ursprünglich als ‚Division‘ an den Wang Laboratorie, einem US Computer Hersteller (frühe 50er). Der ‚Centronics-Drucker‘ Modell 101 wurde 1970 vorgestellt und besaß einen innovative Druckkopf mit 7 Nadeln (klingelt was?). Produziert wurde viel beim US-Zweig von ‚Brother Industries Ltd‘, einem Hersteller von Näh- und Schreibmaschinen. Ich hatte mal so‘n olles Centronics-Ding rumstehen, hab‘s dann leider aus Platzgründen entsorgt. Könnte mir heute noch ein Muster in Arsch beißen ... Hab noch einen Auszug aus dem Manual der FX-80 angehängt. Dort ist die Schnittstelle nochmals kompakt erklärt.
Johannes M. schrieb: > Das Gerät ist von 1989 und sendet eigentlich nur Statistikdaten in > Textform. Daher würde ich zunächst erstmal davon ausgehen, dass es keine > PCL codierten Daten sind. Schreit nach Kassen-/Bon-Drucker. Gibt's manchmal auf ebay für schmales Geld. Die alten Laserjets (lj-2100 und so) können auch noch Centronics. Falls du dies Daten elektronisch haben willst (und um beim Thema zu bleiben): Ein Arduino mit 'ner SD-Karte rangehäkelt ist keine Option?
Kannst Du mal eine Datei mit den Druckdaten zur Analyse liefern? Gruß WIRO
jo schrieb: > Das Ding schreibt sich allerdings „Centonics“. Fast. Zur Ergänzung: diese Drucker bekommen ASCII-Zeichen (und ev. ESC-Sequenzen) Byte für Byte, die drucken auch nicht zeilenweise, sondern die empfangenen Zeichen und dann ein CR (Druckkopf läuft zurück) und ein LF (Zeilenvorschub), man kann also alle Bytes direkt 1:1 weitergeben. Ein Problem könnten Umlaute sein, im ASCII-Code kann man nur entweder ÄÖÜ oder Französisch oder Skandinavisch usw. drucken, das muss man am Drucker einstellen. Die meisten hatten dafür eine Reihe Mäuseklaviere. Ein Messgerät wird wahrscheinlich keine Umlaute drucken. Georg
Der 80C451 (MCS51) enthält als Peripherie einen Centronics-Port (druckerseitig). Damit kann ein Host in den 80C451 "reindrucken". Einen USART hat der auch noch, wie bei MCS51 üblich, damit kannst du dann die empfangenen Bytes wieder ausgeben. Mehr als 20 Jahre alt inzwischen, gibts aber immer noch neu auf ebay. Braucht halt noch ein EPROM, auf ein externes SRAM kannst du bei deiner Anwendung verzichten.
Georg schrieb: > jo schrieb: >> Das Ding schreibt sich allerdings „Centonics“. > > Fast. Hab ich was verpasst ?????
Georg schrieb: > Zur Ergänzung: diese Drucker bekommen ASCII-Zeichen (und ev. > ESC-Sequenzen) Byte für Byte, die drucken auch nicht zeilenweise, > sondern die empfangenen Zeichen und dann ein CR (Druckkopf läuft zurück) > und ein LF (Zeilenvorschub), man kann also alle Bytes direkt 1:1 > weitergeben. Viele Drucker sammeln erst eine ganze Zeile und drucken die erst nach einem CR oder LF. Dann bleibt der Druckkopf am Papierende stehen und druckt die nächste Zeile im Rücklauf. Wenn die Zeichen in schneller Folge in den Druckerpuffer eingegeben werden geht so der Druck schneller. Bei einigen Druckern konnte man über Steckbrücken und / oder einen "Auto-LF"-Mode einstellen. Dann wird nach einem CR automatisch ein LF ausgeführt. Der Epson FX80 war schon ein tolles Teil, aber von OKI gab es einen, der viel kleiner war und vom Design her richtig "was hermachte". Außerdem war der leiser und konnte mehrere Durchschläge (Papierlagen mit Kohlepapier als Zwischenschichten) drucken.
Georg schrieb: > jo schrieb: >> Das Ding schreibt sich allerdings „Centonics“. > > Fast. jo schrieb: > Hab ich was verpasst ????? ja(r) Anarchist schrieb: > Centronics-Port
Johannes M. schrieb: > Ich habe ein Gerät das Daten direkt an einen Parallel Port Drucker > ausgibt. Nun habe ich keinen Parallel Port Drucker. Sehr schade. Ein Nadeldrucker von etwa 1990 könnte Dein bester Kandidat sein. mfg
Schon sehr früh (DOS-Zeit) wurden explizit Steuerzeichen - meist Druckerspezifisch - in die Ausgabe eingefügt. Ob und wie gut die sich rausfieseln lassen weiß ich nicht. Es gibt/gab aber USB-Centronics-Konverter. Falls Du einen "echten" Drucker füttern willst. Ansonsten würde ich, wie bereits gesagt, ein wenig mit dem Mode-Befehl rumspielen. Und natürlich die Umleitungsfunktionen (zum COM-Port und dann in eine Datei) bemühen.
Sebastian S. schrieb: > Es gibt/gab aber USB-Centronics-Konverter. Falls Du einen "echten" > Drucker füttern willst. Der TE braucht es aber umgekehrt !!!
jo schrieb: > Das Ding schreibt sich allerdings „Centonics“. Ein Erfrischungsgetränk?! Ich könnte noch Druckerkabel beisteuern. 1,8m, 3m, 5m, 7,5m Alles noch mehrfach vorhanden. ;-) Gruß Jobst
Johannes M. schrieb: > Ich habe ein Gerät das Daten direkt an einen Parallel Port Drucker > ausgibt. Nun habe ich keinen Parallel Port Drucker mehr. Was spricht dagegen, einen gebrauchten Drucker mit Centronics- oder Parallel-Schnittstelle bei einem bekannten Auktionshaus zu erwerben, oder hier im Markt? Suche mal nach LQ-xxx und Konsorten (-350, -550, -570, -850 etc, die können alle ASCII und Endlospapier. Den LQ-350 gibt es sogar noch neu. Nach meiner Erfahrung ist die LQ-Serie über Jahrzehnte unverwüstlich, hier arbeiten 2 Stück aus 1994 !!!
Auch viele Tintenstrahl oder Laser können den ASCII-Modus. Wenn ein Parallelport vorhanden ist, einfach damit füttern. Evtl. etwas im Menü einstellen.
Georg schrieb: > Zur Ergänzung: diese Drucker bekommen ASCII-Zeichen (und ev. > ESC-Sequenzen) Byte für Byte, [..] Ist nicht ganz richtig. ASCII ist genau genommen keine 8-Bit- (also kein Byte), sondern eine 7-Bit-Zeichencodierung. Diese entspricht der US-Variante von ISO 646, dem „Internationalen Alphabet Nr. 5“ (IA5). ASCII diente als Grundlage späterer Zeichen-Codierungen wie z.B. „Erweitertes ASCII“ inklusive der vielen unsäglichen Codepages (1 Byte) aber auch UTF-8 .. UTF-32 (1 .. 4 Byte). > [...] die drucken auch nicht zeilenweise, > sondern die empfangenen Zeichen und dann ein CR (Druckkopf läuft zurück) > und ein LF (Zeilenvorschub), man kann also alle Bytes direkt 1:1 > weitergeben. Auch das ist nicht ganz richtig. Auf Anhieb fällt mir nur ein einziger Drucker ein, der direkt die empfangenen Zeichen zum Druckwerk durchgereicht hat. Das war eine zum Drucker umgebaute Typenrad-Schreibmaschine (basierend auf i8048), genau genommen ein Eigenbau aus ‚79 oder ‚80. Bei deren Firmware hatte ich den Tastatur Scan Code durch einen Centronicshandshake sowie Ringbuffer ersetzt. Alle anderen mit bekannten Drucker hatten zumindest eine ganze Zeile zwischengespeichert - weil wenn der Druckkopf mal unterwegs war, gab‘s da kein Bremsen (d.h. Warten auf das nächste Zeichen) mehr! Mein RENA-Drucker (ein 2-Mann-Drucker, alleine konntest den nicht bewegen - RIP) hatte dazu 2 massive Scheibenbremsen! Laserdrucker speichern sogar eine ganze Seite; diese so nach und nach ausbelichten - ich denke kaum, das würd' was werden ...
jo schrieb: > Laserdrucker speichern sogar eine ganze Seite; diese so nach und nach > ausbelichten - ich denke kaum, das würd' was werden ... Geht schon, ich habe mal vor langer Zeit einen ESC-A Interpreter geschrieben, der Nadeldruckerdaten in Ausgaben für Laserdrucker uminterpretiert hat, der hat in unseren Firmen die Nadeldrucker ersetzt (und die plötzliche Stille hat alle begeistert). Es wurden auch Durchschläge durch die Ausgabe mehrer Seiten simuliert. Leider nützt das dem TO nichts, weil das Abfangen der Nadeldaten auf dem PC erfolgte und den hat der TO ja nicht. Aber Software mit Druckerausgaben für Epson und NEC (P6) konnten viele Jahre lang weiter benutzt werden. Georg
Hier hat sich schon mal jemand mit dem Thema beschäftigt. Am Ende auch ein Lösungsansatz in Software. https://www-user.tu-chemnitz.de/~heha/basteln/PC/LptCap/
Im Notfall könnte ich einen Drucker beisteuern..aber Nadeldrucker mit Centronics Interface werden nach wie vor gebaut, in nahezu jeder Arztpraxis steht so ein Ding und druckt Rezepte u.Ä. bei denen ein echter Durchschlag gefordert wird. Nur die Preise für die Dinger haben sich indessen grundsätzlich geändert, ich kann mich erinnern das irgend ein Star Nadeldrucker Anfang der 90er für rd. 120DM zu haben war, das kann man sich indessen grundsätzlich abschminken. Pille
Beispiel beim Buchhändler: https://www.amazon.de/Oki-01091302-Microline-3390-Nadeldrucker/dp/B0000AT4UQ Pille
Pille schrieb: > Nadeldrucker mit > Centronics Interface werden nach wie vor gebaut, in nahezu jeder > Arztpraxis steht so ein Ding und druckt Rezepte u.Ä. bei denen ein > echter Durchschlag gefordert wird. Selbst die haben mittlerweile USB, weil die PCs ja ebenfalls keinen Parallelport mehr besitzen. Gruß Jobst
Pille schrieb: > https://www.amazon.de/Oki-01091302-Microline-3390-Nadeldrucker/dp/B0000AT4UQ Jepp. Auch USB.
Beitrag #6868503 wurde von einem Moderator gelöscht.
Man sollte sich da auch nicht am Parallelport festhalten. Es geht genau so die Ser. Schnittstelle. Bei meinem Laser OKI B4250 kann man neben Par,. USB auch eine Ser. nachrüsten. Und er macht auch das EPSON-FX Protokoll. Sollte also für die Forderung des TO genügen. Zum Test kann man den Treiber Generic/ Text Only (W7) verwenden.
nochmal: der EPSON LQ-350 hat parallel, seriell und USB-Interface, den kannst Du also direkt an Dein unbekanntes Gerät hängen. Die EPSON-Nadeldrucker leben ewig, die gleiche Aussage gilt auch für OKI Mircoline, die sind aber 1. lauter und 2. meist teurer.
Danke, es geht mir nicht darum ein Drucker da dran zu hängen. Die Überlegung war die Daten aus dem Gerät (Kein Dos Betriebssystem) raus zu bekommen in einen PC, da war der Tipp mit dem FT245RL nicht so schlecht. Ich werde das mal ausprobieren :) Jetzt muss ich nur noch rausfinden wie genau es das Gerät so mit dem ACK Signal nimmt.
Wenn Du was fertiges brauchst, ohne basteln zu müssen: https://www.wut.de/e-28000-ww-dade-000.php fchk
Johannes M. schrieb: > es geht mir nicht darum ein Drucker da dran zu hängen. Die Überlegung > war die Daten aus dem Gerät (Kein Dos Betriebssystem) raus zu bekommen > in einen PC, In der Eröffnung klang das ganz anders. Aber vor paar Wochen wurde das hier schon behandelt. Da ging es vor allem um Grafik. Such mal danach. Einfach ein Parallel-Linkkabel und einen DOS-PC. Dazu den NC. Für Buchstaben reicht das.
Johannes M. schrieb: > es geht mir nicht darum ein Drucker da dran zu hängen. Die Überlegung > war die Daten aus dem Gerät (Kein Dos Betriebssystem) raus zu bekommen > in einen PC, da war der Tipp mit dem FT245RL nicht so schlecht. Ich > werde das mal ausprobieren :) Man kann sich aber auch so was von anstellen. Wieso verbessere ich den Günne, was die Schreibweise der Schnittstelle angeht? Vielleicht, dass auch Tante Google was findet? War unter den ersten 5 Hits (allerdings @duckduckgo): https://github.com/boriz/CentronicsArduino Zitat: „It is not uncommon for electronic enthusiast to use an outdated test gears in their labs. Actually it is pretty common even for companies to rely on vintage instruments born in 80s/90s/00s. There is probably a good reason for it, these relics are usually moderately priced and indestructible. They are extremely well built, can withstand hurricanes and small nuclear explosions. These tools are obviously outdated and lacking modern features, but pretty adequate for most cases. The problem I am typically having (and probably other users of these antique tools) is that I can‘t easily take a screenshot of the instrument.“ > Jetzt muss ich nur noch rausfinden wie genau es das Gerät so mit dem ACK > Signal nimmt. Kuck beim FX-80 nach, PDF (Beitrag "Re: Interface Parallel Port Drucker") hatte ich Dir neulich schon geschickt. Dort gibt es auch das Timing ... just my 2ct (heißt: Ich bin dann mal raus ...)
Wenn ich jetzt nicht falsch liege beschreibt ihr alle den ursprünglichen Parallelport-Standard. Es gab aber noch SPP, EPP und ECP als erweiterte Betriebsmodi mit bidirektionaler Kommunikation, höherem Datendurchsatz und teilweiser Protokollautomatisierung mit Sende/Empfangs-FIFOs. Auf die Schnelle gefunden, sieht ganz brauchbar aus: http://wearcam.org/seatsale/programs/www.beyondlogic.org/ecp/ecp.htm
Johannes schrieb: > Es gab aber noch SPP, EPP und ECP als erweiterte Betriebsmodi mit > bidirektionaler Kommunikation Was soll ein Messgerät mit Centronics-Druckeranschluss mit bidirektionaler Kommunikation? Georg
https://www.digikey.de/de/pdf/a/ak-nord/ser2usb-lpt2usb-xtmicrosxlc-cables Es gibt ein deutsches Produkt, das einen Centronics-Ausgang mit einem USB-Laserjet verbindet, ein weiteres von einem seriellen Messgerät auf denselben Laserjet. Nicht ganz so billig wie die umgekehrte Richtung, aber für den Zweck überlegenswert. Die Baudrate der seriellen Schnittstelle wird automatisch erkannt, kann aber mit einem PC auch verändert werden. https://www.digikey.de/products/de?keywords=SER2USB €84,24
:
Bearbeitet durch User
Georg schrieb: > Johannes schrieb: >> Es gab aber noch SPP, EPP und ECP als erweiterte Betriebsmodi mit >> bidirektionaler Kommunikation > > Was soll ein Messgerät mit Centronics-Druckeranschluss mit > bidirektionaler Kommunikation? > > Georg Druckerstatus abfragen? Es wurde ja nirgends geschrieben um welche Hardware es sich handelt, wir wissen nur, dass das Messgerät scheinbar ein DOS basierter PC ist. Ob der Druckerhersteller dem Drucker EPP spendiert hat oder es sogar voraussetzt wissen wir z.B. nicht. Dos konnte auch schon EPP und ECP, eine LPT Umleitung kann da auch zu Problemen führen. Wenn man den Drucker emulieren will sollte man sich halt nicht wundern wenn da per EPP aus dem Messgerät gesendet wird. Kann sein, muss natürlich nicht. Der Parallelport war halt bei weitem kein so einfaches Stück Hardware wie häufig angenommen.
Johannes schrieb: ... > Druckerstatus abfragen? Es wurde ja nirgends geschrieben um welche > Hardware es sich handelt, wir wissen nur, dass das Messgerät scheinbar > ein DOS basierter PC ist. Haben hier alle Alzheimer? Könnt euch nicht mal was von jetzt auf nachher merken? Oder liegt es ganz einfach an der mangelhaften Lesekompetenz? Soll ja mitunter vorkommen - bei zu viel DuRöhre gucken ... Johannes schrieb: ... > Es gab aber noch SPP, EPP und ECP als erweiterte Betriebsmodi mit > bidirektionaler Kommunikation, höherem Datendurchsatz und teilweiser > Protokollautomatisierung mit Sende/Empfangs-FIFOs. Nochmals - laut um‘s sich vorlesen zu lassen: Beim Gerät ist kein DOS im Spiel - KEIN DOS!!! KEIN DOS - und erst recht kein Windows. Johannes M. schrieb: (DAS IST DER TO) > Die Überlegung war die Daten aus dem Gerät (Kein Dos Betriebssystem) > raus zu bekommen in einen PC [...] Johannes schrieb: ... > Ob der Druckerhersteller dem Drucker EPP spendiert hat oder es sogar > voraussetzt wissen wir z.B. nicht. Dos konnte auch schon EPP und ECP, > eine LPT Umleitung kann da auch zu Problemen führen. Es gibt keinen Drucker und kein DOS, auch keine LPT-Umleitung. Einfaches Centronics, kein EPP oder ECP. Es gibt einzig ein Gerät aus 1989. Johannes M. schrieb: (ZUR ERINNERUNG: DAS IST DER TO) > Das Gerät ist von 1989 und sendet eigentlich nur Statistikdaten in > Textform. Daher würde ich zunächst erstmal davon ausgehen, dass es keine > PCL codierten Daten sind. Johannes schrieb: ... > Wenn ich jetzt nicht falsch liege beschreibt ihr alle den ursprünglichen > Parallelport-Standard. Johannes - damit liegst Du richtig. GOLDRICHTIG!
1989 war SPP Standard, aber selbst da gab es Differenzen im Timing der Leitungen BUSY, _STROBE, _ACK. Ausweg: mit LA Timing aufnehmen, µC oder SBC entsprechend programmieren.
Fliegt die Rakete schon, oder wird in Villabacho noch geschrubbt?
Kleine aber wichtige Frage. Reden die Geräte (PC + dein Teil miteinander). Die ersten Drucker (meist Nadeldrucker) habe NICHT miteinander geredet. Da ging es nach den Motto "Drucker friss was du bekommst" was auch Unsinn im Druckbild bei Störungen führte. Später kamen die Bidirektionalen-Drucker. Die hatten auch was zu melden. Was bedeutete aber die brauchen ein VOLL-Bestückten Kabel. Für dich zum Nachbau würde das Bedeuten das du diese Funktion berücksichtigen solltest. Wenn der PC ein Desktop-Rechner ist würde ich einfach 14 Euro + VK ausgeben und das Problem wäre gelöst. https://www.reichelt.de/2-port-parallel-pci-karte-pci-parallel-x2-p53285.html?CCOUNTRY=445&LANGUAGE=de&&r=1
@Hannes Also der TO hat explizit gefragt wie es unter MSDOS funktioniert. Kannst du nicht lesen? Johannes M. schrieb: (ja das ist der TO!!einself) > Jetzt meine Frage, wie wurden die ersten Parallel Port Drucker von > MS-Dos angesteuert? Dein künstlicher Aufreger bringt das Thema nicht weiter, er ersetzt lediglich Information durch Emotion. Ich schrieb deutlich, dass es kein EPP sein muss und wollte das Thema nur angerissen haben für den Fall, dass der TO etwas unerwartetes vorfindet. "Centronics" normt übrigens einerseits die komplette Schnittstelle, andererseits aber auch nur den Stecker. Viele Geräte hatten einen Centronics-Stecker aber kein entsprechendes Protokoll. Auch das manche Drucker herstellerspezifische Steuerzeichen erwarten wurde hier ja schon angesprochen. Und auch mit einem SPP Parallelport kannst du Protokolle fahren wie du willst (sogar EPP und ECP die einen anderen Handshake einsetzen), letztlich kontrollierst du ja einfach direkt die Pins am Port.
Johannes schrieb: > Also der TO hat explizit gefragt wie es unter MSDOS funktioniert. Nicht ganz, er hat gefragt, wie MS-DOS den Drucker angesteuert hat, weil sein Gerät mit Druckern arbeitet, wie man sie damals an "IBM-kompatible" PCs angeschlossen hat. Johannes schrieb: > Und auch mit einem SPP Parallelport kannst du Protokolle fahren wie du > willst (sogar EPP und ECP die einen anderen Handshake einsetzen), > letztlich kontrollierst du ja einfach direkt die Pins am Port. Wenn die Hardware nur unidirektionale Datenleitungen hat, wird das nichts. Aber zurück zum eigentlichen Thema, hier das Parallelport-Timing der alten Centronics-Drucker (vorletzte Seite): http://vtda.org/docs/computing/Centronics/101_101A_101AL_102A_306_SpecificationsInterfaceInformation.pdf Wenn Du Glück hast, braucht Dein Gerät neben den Datenleitungen nur Strobe und Busy (also kein Acknowledge), so war es z.B. beim Atari ST.
Johannes M. schrieb: > Könnte ich also in der Theorie, die parallelen Daten mit einem AVR > einlesen und dann einfach auf die serielle Schnittstelle kopieren und > bekommen den Stream der Ascii Zeichen ausgegeben um ihn in einem > Terminal Programm am PC anzuzeigen? https://www.i8086.de/dos-befehle/mode-umleiten.html Das sollte deine Frage beantworten oder dich zumindest weiter bringen.
Schlaumaier schrieb: > https://www.i8086.de/dos-befehle/mode-umleiten.html > > Das sollte deine Frage beantworten oder dich zumindest weiter bringen. Ganz sicher nicht, denn: Johannes M. schrieb: > es geht mir nicht darum ein Drucker da dran zu hängen. Die Überlegung > war die Daten aus dem Gerät (Kein Dos Betriebssystem) raus zu bekommen
Prinzipiell bin ich bei dir, nur noch eine Anmerkung: Hmmm schrieb: > Wenn die Hardware nur unidirektionale Datenleitungen hat, wird das > nichts. Auch SPP hat Leitungen in beide Richtungen, man benutzte die Statusleitungen als Return. So konnte man z.B. per Nullmodemkabel bis zu 5 Bits pro Transfer in jeder Richtung austauschen: http://www.nullmodem.com/LapLink.htm (auf der Seite wird zwar EPP/ECP empfohlen, aber das ging auch über SPP nur halt langsamer.) Letztlich ist die Frage ob sich der Druckerhersteller an den Standard gehalten hat (vermutlich) oder halt nicht. (Unwahrscheinlicher, aber gabs damals ja alles.)
Johannes schrieb: > Hmmm schrieb: >> Wenn die Hardware nur unidirektionale Datenleitungen hat, wird das >> nichts. > > Auch SPP hat Leitungen in beide Richtungen, man benutzte die > Statusleitungen als Return. Ja, aber ohne bidirektionale Datenleitungen (nicht Statusleitungen) bekommst Du eben kein ECP/EPP hin, das meinte ich. Workarounds a la LapLink gingen natürlich.
Wenn man einen Port mit Unidirektionalen Leitungen hat hast du natürlich recht. SPP konnte die Datenleitungen teilweise auch Bidirektional treiben. Jetzt wird's nur kompliziert weil es den Namen "SPP" erst zusammen mit "EPP" gab. Vorher war einfach ein "Parallel Port" oder "Printer Port" der es wohl manchmal konnte und manchmal nicht, was die Sache nicht einfacher macht. Also Zusammenfassung für den TO: Schau ob es das übliche Druckerprotokoll ist, entweder mit einem 4kanal Oszi oder halt einem LA. Wenn ja ist es relativ einfach, wenn nicht wird es komplizierter.
Leider auch ohne Quellen, aber ich vermute es hat sich nicht ohne Grund gehalten: > The original IBM parallel printer adapter for the IBM PC of 1981 was designed to support limited bidirectionality, with 8 lines of data output and 4 lines of data input.[citation needed] This allowed the port to be used for other purposes, not just output to a printer. This was accomplished by allowing the data lines to be written to by devices on either end of the cable, which required the ports on the host to be bidirectional. This feature saw little use, and was removed in later revisions of the hardware. Years later, in 1987, IBM reintroduced the bidirectional interface with its IBM PS/2 series, where it could be enabled or disabled for compatibility with applications hardwired not to expect a printer port to be bidirectional. (https://en.wikipedia.org/wiki/Parallel_port#History)
Johannes schrieb: ... > Also der TO hat explizit gefragt wie es unter MSDOS funktioniert. Kannst > du nicht lesen? Textverständnis 6 - setzen! Kuck mal weiter IchRöhre. Du reißt einen Satz aus dem Kontext, dann wird das leider nichts. Das meinte ich mit „nicht denken von jetzt bis nachher“. So entstehen Lösungsvorschläge, die auf „EPP, ECP und ominöse Protokollautomatisierungen“ oder auf „Sende-FIFOs“ hinweisen. Nur ist das dann komplette Makulatur. Nochmals: Der TO wollte einzig wissen, wie alte (die ersten) Parallel-Port-Drucker angesteuert wurden - um rauszufinden, wie seine alte Kiste aus 1989 das gemacht haben könnte - und als Beispiel hatte er dann nachgeschoben, wie das DOS das wohl gemacht hat ... Johannes M. schrieb: ... > Ich habe ein Gerät das Daten direkt an einen Parallel Port Drucker > ausgibt. Nun habe ich keinen Parallel Port Drucker mehr. > > Jetzt meine Frage, wie wurden die ersten Parallel Port Drucker von > MS-Dos angesteuert? > „Centronics“ normt übrigens einerseits die komplette Schnittstelle, > andererseits aber auch nur den Stecker. Viele Geräte hatten einen > Centronics-Stecker aber kein entsprechendes Protokoll. Auch das manche > Drucker herstellerspezifische Steuerzeichen erwarten wurde hier ja schon > angesprochen. Centronics Ltd., eine amerikanisch Computerklitsche, hat gar nichts genormt. Einzig, sie haben 36 polige „Micro Ribbon Connectors“ in ihre Drucker eingesetzt. Und andere haben‘s dann nachgemacht. Der Stecker kam von Amphenol, wurde nämlich dort erfunden. Erst viel später wurde die Schnittstelle als IEEE 1284 standardisiert. Übrigens wurde früher (tm) die Druckerschnittstelle vom BIOS bedient- und nicht vom OS (CP/M, PC-DOS). CP/M such ich jetzt nicht raus (das ist noch aug 8"-Disketten), dafür hier ein Auszug aus dem BIOS der IMM-PC:
1 | ;--- INT 17 --------------------------------- |
2 | ;PRINTER_IO |
3 | ; THIS ROUTINE PROVIDES COMMUNICATION WITH THE PRINTER |
4 | ; (AH)=0 PRINT THE CHARACTER IN (AL) |
5 | ; ON RETURN, AH=1 IF CHARACTER COULD NOT BE PRINTED (TIME OUT) |
6 | ; OTHER BITS SET AS ON NORMAL STATUS CALL |
7 | ; (AH)=1 INITIALIZE THE PRINTER PORT |
8 | ; RETURNS WITH (AH) SET WITH PRINTER STATUS |
9 | ; (AH)=2 READ THE PRINTER STATUS INTO (AH) |
10 | ; 7 6 5 4 3 2-1 0 |
11 | ; | | | | | | _ TIME OUT |
12 | ; | | | | | _ UNUSED |
13 | ; | | | | _ 1 = I/O ERROR |
14 | ; | | | _ 1 = SELECTED |
15 | ; | | _ 1 = OUT OF PAPER |
16 | ; | _ 1 = ACKNOWLEDGE |
17 | ; _ 1 = BUSY |
18 | ;
|
19 | ; (DX) = PRINTER TO BE USED (0,1,2) CORRESPONDING TO ACTUAL VALUES |
20 | ; IN PRINTER_BASE AREA |
21 | ; DATA AREA PRINTER BASE CONTAINS THE BASE ADDRESS OF THE PRINTER CARD(S) |
22 | ; AVAILABLE (LOCATED AT BEGINNING OF DATA SEGMENT, 408H ABSOLUTE, 3 WORDS) |
23 | ;REGISTERS AH IS MODIFIED |
24 | ; ALL OTHERS UNCHANGED |
25 | ;-------------------------------------------- |
26 | ASSUME CS:CODE,DS:DATA |
27 | PRINTER_IO PROC FAR |
28 | STI ; INTERRUPTS BACK |
29 | PUSH DS ; SAVE SEGMENT |
30 | PUSH DX |
31 | PUSH SI |
32 | PUSH CX |
33 | PUSH BX |
34 | MOV SI,DATA |
35 | MOV DS,SI ; ESTABLISH PRINTER SEGMENT |
36 | MOV SI,DX ; GET PRINTER PARM |
37 | SHL SI,1 ; WORD OFFSET INTO TABLE |
38 | MOV DX,PRINTER_BASE[SI] ; GET BASE ADDRESS FOR PRINTER CARD |
39 | OR DX,DX ; TEST DX FOR ZERO, INDICATING NO PRINTER |
40 | JZ B1 ; RETURN |
41 | OR AH,AH ; TEST FOR (AH)=0 |
42 | JZ B2 ; PRINT_AL |
43 | DEC AH ; TEST FOR (AH)=1 |
44 | JZ B8 ; INIT_PRT |
45 | DEC AH ; TEST FOR (AH)=2 |
46 | JZ B5 ; PRINTER STATUS |
47 | B1: ; RETURN |
48 | POP BX |
49 | POP CX |
50 | POP SI ; RECOVER REGISTERS |
51 | POP DX ; RECOVER REGISTERS |
52 | POP DS |
53 | IRET
|
54 | |
55 | ;------ PRINT THE CHARACTER IN (AL) |
56 | |
57 | B2: |
58 | PUSH AX ; SAVE VALUE TO PRINT |
59 | MOV BL,10 ; TIME OUT VALUE |
60 | XOR CX,CX ; ESTABLISH SHIFT COUNT |
61 | OUT DX,AL ; OUTPUT CHAR TO PORT |
62 | INC DX ; POINT TO STATUS PORT |
63 | B3: ; WAIT_BUSY |
64 | IN AL,DX ; GET STATUS |
65 | MOV AH,AL ; STATUS TO AH ALSO |
66 | TEST AL,80H ; IS THE PRINTER CURRENTLY BUSY |
67 | JNZ B4 ; OUT_STROBE |
68 | LOOP B3 ; DECREMENT COUNT ON TIME OUT |
69 | DEC BL |
70 | JNZ B3 ; WAIT FOR NOT BUSY |
71 | OR AH,1 ; SET ERROR FLAG |
72 | AND AH,0F9H ; TURN OFF THE OTHER BITS |
73 | JMP SHORT B7 ; RETURN WITH ERROR FLAG SET |
74 | B4: ; OUT_STROBE |
75 | MOV AL,0DH ; SET THE STROBE HIGH |
76 | INC DX ; STROBE IS BIT 0 OF PORT C OF 8255 |
77 | OUT DX,AL |
78 | MOV AL,0CH ; SET THE STROBE LOW |
79 | OUT DX,AL |
80 | POP AX ; RECOVER THE OUTPUT CHAR |
81 | |
82 | ;------ PRINTER STATUS |
83 | |
84 | B5: |
85 | PUSH AX ; SAVE AL REG |
86 | B6: |
87 | MOV DX,PRINTER_BASE[SI] |
88 | INC DX |
89 | IN AL,DX ; GET PRINTER STATUS |
90 | MOV AH,AL |
91 | AND AH,0F8H ; TURN OFF USED BITS |
92 | B7: ; STATUS_SET |
93 | POP DX ; RECOVER AL REG |
94 | MOV AL,DL ; GET CHARACTER INTO AL |
95 | XOR AH,48H ; FLIP A COUPLE OF BITS |
96 | JMP B1 ; RETURN FROM ROUTINE |
97 | |
98 | ;------ INITIALIZE THE PRINTER PORT |
99 | |
100 | B8: |
101 | PUSH AX ; SAVE AL |
102 | ADD DX,2 ; POINT TO OUTPUT PORT |
103 | MOV AL,8 ; SET INIT LINE LOW |
104 | OUT DX,AL |
105 | MOV AX,1000 |
106 | B9: ; INIT_LOOP |
107 | DEC AX ; LOOP FOR RESET TO TAKE |
108 | JNZ B9 ; INIT_LOOP |
109 | MOV AL,0CH ; NO INTERRUPTS, NON AUTO LF, INIT HIGH |
110 | OUT DX,AL |
111 | JMP B6 ; PRT_STATUS_1 |
112 | PRINTER_IO ENDP |
Dein völlig unnötiger Beispielcode ist ja schön und gut, sagt nur leider
nichts aus und zerreißt den ganzen Thread. Klar gabs einen BIOS Int
dafür, hat aber nicht jeder genutzt.
Den Teil von vorher hast du vermutlich überlesen:
ich schrieb:
> Letztlich ist die Frage ob sich der Druckerhersteller an den Standard
gehalten hat (vermutlich) oder halt nicht. (Unwahrscheinlicher, aber
gabs damals ja alles.)
Also bitte lies doch richtig bevor du antwortest. Hätte viel unnötigen
Text gespart. Außerdem empfehle ich dir irgendwas gegen deine
Aggressionen zu tun, dir fehlt offenbar das richtige Ventil dafür.
Johannes schrieb: > Dein völlig unnötiger Beispielcode ist ja schön und gut, sagt > nur leider nichts aus und zerreißt den ganzen Thread. Der TO wollte wissen, wie 1989 Parallel-Drucker angesteuert wurden. Und das ging NICHT übers OS, sondern übers BIOS. Der Thread wird zerrissen - von dümmliche Kommentaren, die mit warnendem Zeigefinger auf EPP und ECP hinweisen. Und darauf, dass moderne Drucker eh einen USB-3 Port hätten. >> Letztlich ist die Frage ob sich der Druckerhersteller an den Standard > gehalten hat (vermutlich) oder halt nicht. (Unwahrscheinlicher, aber > gabs damals ja alles.) Bitte lerne lesen: ES GIBT KEINEN DRUCKER!!! Der TO hat keinen, und will auch keinen. Aber wem erzähl ich das ...
Och mensch, jetzt hats dich aber echt erwischt, oder? Tief durchatmen, das wird schon wieder. Natürlich hat der TO keinen Drucker. Aber mit irgend was wird sein Messgerät ja kommuniziert haben, oder? Richtig, da hing mal ein Drucker dran. Und jetzt schalten wir mal unser Hirn ein und lesen zwischen den Zeilen: Der TO hat ein Messgerät an dem irgendein Drucker hing. Baujahr grob '89. Konstruktionsjahr möglicherweise auch 10 Jahre früher, Messgeräte wurden ja über längere Zeit gebaut. Wir wissen nicht ob das ein Standardgerät war oder irgendwas spezielles. Und wir wissen nicht, ob sich der Hersteller von diesem Drucker an einen Standard gehalten hat oder nicht. (Da isser wieder der Drucker!) Wenns blöd läuft möchte der Drucker z.B. EBDCI sehen und wurde vom Messgerätehersteller zusammen mit dem Messgerät vertickt - dann sendet das Messgerät z.B. auch EBDCI statt ASCII. Das ECP und EPP erst nach '89 eingeführt wurden ist richtig. Bei 30 Jahre alten Standards hab ich auch nicht alle Jahreszahlen im Kopf und das ist auch nicht mein Problem. Es wurden über die Jahre aber lustige Dinge mit dem Parallelport angestellt, das sollte man wissen. Lies nochmal in meinen letzten Beiträgen, der TO soll halt nachmessen, ist das einfachste. Mit einem Logic Analyzer sieht man z.B. auch recht schnell ob da ASCII, PCL, EBDCI oder sonstwas für ein Hokus Pokus rauskommt. Und jetzt hör auf den Thread voll zu spammen.
Johannes schrieb: > Och mensch, jetzt hats dich aber echt erwischt, oder? Tief durchatmen, > das wird schon wieder. > > Natürlich hat der TO keinen Drucker. Aber mit irgend was wird sein > Messgerät ja kommuniziert haben, oder? Richtig, da hing mal ein Drucker > dran. > > Und jetzt schalten wir mal unser Hirn ein und lesen zwischen den Zeilen: > Der TO hat ein Messgerät an dem irgendein Drucker hing. Baujahr grob > '89. Konstruktionsjahr möglicherweise auch 10 Jahre früher, Messgeräte > wurden ja über längere Zeit gebaut. Wir wissen nicht ob das ein > Standardgerät war oder irgendwas spezielles. > > Und wir wissen nicht, ob sich der Hersteller von diesem Drucker an einen > Standard gehalten hat oder nicht. (Da isser wieder der Drucker!) > Wenns blöd läuft möchte der Drucker z.B. EBDCI sehen und wurde vom > Messgerätehersteller zusammen mit dem Messgerät vertickt - dann sendet > das Messgerät z.B. auch EBDCI statt ASCII. > > Das ECP und EPP erst nach ‚89 eingeführt wurden ist richtig. Bei 30 > Jahre alten Standards hab ich auch nicht alle Jahreszahlen im Kopf und > das ist auch nicht mein Problem. Es wurden über die Jahre aber lustige > Dinge mit dem Parallelport angestellt, das sollte man wissen. Jaja, hätte, hätte, Fahrradkette ... Eigentlich wollte ich den ganzen Blahfasel löschen. Es ist aber zu putzig zu lesen, wie sich hier manche zum Affen machen. Einschläfernd - und komplett ohne Gehalt. > Lies nochmal in meinen letzten Beiträgen, der TO soll halt nachmessen, > ist das einfachste. Mit einem Logic Analyzer sieht man z.B. auch recht > schnell ob da ASCII, PCL, EBDCI oder sonstwas für ein Hokus Pokus > rauskommt. Ich habe Deine Beiträge gelesen. Auch die, in denen du penetrant über PC-basiere Messgeräte und bidirektionale Schnittstellen fabulierst. Du machst ein Hokuspokus aus Nichts, faselst völlig belangloses Zeugs, denkst Dir Probleme aus, wo keine sind. Ergo: Du produzierst patologisch Spam! PCL ist eine Entwicklung von HP aus Mitte der 80er. Sofern TO‘s Gerät nicht von HP stammt würd ich sagen: extrem unwahrscheinlich. EBDCI sagt mir nichts. Ist das was zum Wichtigmachen? Dafür kenne ich aber EBCDIC. Das war Ende der 50er auf IBM Mainframes zu Hause - aber auch nur da. Fazit: absolut unwahrscheinlich. Aber wie auch immer, der TO kann nur aufzeichnen, was da ist. Und drum ist es erst mal schnurzegal, was da über die Leitung geht - selbst wenn es diese ominöse „EBDCI“ sein sollte. Der TO muss das noch nicht mal nachmessen! Denn hat er die Daten erst mal auf seinem PehZeh, kovertiert er die in Null-Komma-Nichts um - z.B. mit „iconv“ oder ganz profan mit „dd“. Ganz ohne programmieren. Konvertieren muss er aber nicht - da kommt reinstes ASCII, 24 Karat! Wetten? > Und jetzt hör auf den Thread voll zu spammen. Fass dir mal an die eigene Nase ...
Schade, so viel Geschreibsel und dabei hattest du doch nichts verstanden.
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.