Interface Parallel Port Drucker

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

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.

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.

Sebastian S. schrieb:
> Es gibt/gab aber USB-Centronics-Konverter. Falls Du einen "echten"
> Drucker füttern willst.

Der TE braucht es aber umgekehrt !!!

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

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

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.

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

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.