Discussion:
Hardware abzugeben
Add Reply
Günter Frenz
2017-12-16 17:13:51 UTC
Antworten
Permalink
Raw Message
Hallo zusammen,

ich habe wieder etwas alte Hardware wegen Platzmangel abzugeben:

1.: HP 9000/735 mit externer Grafikeinheit und 20" Monitor, Tastatur und
Maus. Die Maschine ist letztes Wochenende noch problemlos angelaufen
und man konnte sich anmelden (Passworte sind leer).

2.: HP EnvizeX X-Terminal bislang nicht getestet.

3.: IBM Drucker 5202 mit Papiereinzug ebenfalls nicht getestet.

Alles ist gegen Selbstabholung in Köln zu verschenken.

bis denn

Günter
Juergen Nickelsen
2017-12-18 17:08:11 UTC
Antworten
Permalink
Raw Message
Post by Günter Frenz
1.: HP 9000/735 mit externer Grafikeinheit und 20" Monitor, Tastatur und
Maus. Die Maschine ist letztes Wochenende noch problemlos angelaufen
und man konnte sich anmelden (Passworte sind leer).
Die bekam ich 1994 oder '95 als Arbeitsplatz, in der 125-MHz-Version
und mit 144 MB RAM. Das war für die Zeit eine sehr schöne und
schnelle Maschine, vermutlich eine der schnellsten Workstations an
der TUB.

Zwei Jahre später wechselte ich ins wirkliche Leben. Da war's dann
ein PC mit Windows 95. Schnüff.
--
Q: How many mathematicians does it take to screw in a lightbulb?
A: One. He gives it to six Californians, thereby reducing the problem
to the earlier joke.
Gerrit Heitsch
2017-12-18 17:15:05 UTC
Antworten
Permalink
Raw Message
Post by Juergen Nickelsen
Post by Günter Frenz
1.: HP 9000/735 mit externer Grafikeinheit und 20" Monitor, Tastatur und
Maus. Die Maschine ist letztes Wochenende noch problemlos angelaufen
und man konnte sich anmelden (Passworte sind leer).
Die bekam ich 1994 oder '95 als Arbeitsplatz, in der 125-MHz-Version
und mit 144 MB RAM. Das war für die Zeit eine sehr schöne und
schnelle Maschine, vermutlich eine der schnellsten Workstations an
der TUB.
Zwei Jahre später wechselte ich ins wirkliche Leben. Da war's dann
ein PC mit Windows 95. Schnüff.
Ja, da lernte man mit Grausen womit sich ein großer Teil der Menschheit
täglich rumschlagen durfte.

Ich bin schnell zu Linux gewechselt als es weit genug das man nicht mehr
selbst an der XF86-Config schrauben musste.

Gerrit
Hermann Riemann
2017-12-19 09:16:51 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Post by Juergen Nickelsen
Zwei Jahre später wechselte ich ins wirkliche Leben. Da war's dann
ein PC mit Windows 95. Schnüff.
Ja, da lernte man mit Grausen womit sich ein großer Teil der Menschheit
täglich rumschlagen durfte.
Windows 95 war das beste System für käufliche computerspiele.
Post by Gerrit Heitsch
Ich bin schnell zu Linux gewechselt als es weit genug das man nicht mehr
selbst an der XF86-Config schrauben musste.
SuSE?

Hermann
dem außer computerspiele und verammalter software nichts kennt
was mit windows besser geht als mit Linux.
( Und die computerspiele unter windows 9* manchmal vermisst.)
--
http://www.hermann-riemann.de
Gerrit Heitsch
2017-12-19 09:41:15 UTC
Antworten
Permalink
Raw Message
Post by Hermann Riemann
Post by Gerrit Heitsch
Post by Juergen Nickelsen
Zwei Jahre später wechselte ich ins wirkliche Leben. Da war's dann
ein PC mit Windows 95. Schnüff.
Ja, da lernte man mit Grausen womit sich ein großer Teil der
Menschheit täglich rumschlagen durfte.
Windows 95 war das beste System für käufliche computerspiele.
Ja, als Spielestarter taugte es... Aber das war es auch schon. Gut
gefunden haben es nur Leute die noch schlechteres gewöhnt waren, also
Windows 3.11.
Post by Hermann Riemann
Post by Gerrit Heitsch
Ich bin schnell zu Linux gewechselt als es weit genug das man nicht
mehr selbst an der XF86-Config schrauben musste.
SuSE?
Nein, YAST war nicht mein Fall. Erst Slackware, dann Mandrake/Mandriva.

Gerrit
Hermann Riemann
2017-12-19 15:54:32 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Post by Hermann Riemann
Windows 95 war das beste System für käufliche computerspiele.
Ja, als Spielestarter taugte es... Aber das war es auch schon.
Nein xemacs funktionierte auch auf windows.
Post by Gerrit Heitsch
Post by Hermann Riemann
Post by Gerrit Heitsch
Ich bin schnell zu Linux gewechselt als es weit genug das man nicht
mehr selbst an der XF86-Config schrauben musste.
SuSE?
Nein, YAST war nicht mein Fall.
sax war bezüglich grafischer Oberfläche mal ideal.
Monitor Frequenzen eintragen, und es lief.
Sogar im Multimonitorbetrieb.
Besser als heutzutage.

Andere Distributionen haben da nur aufgegeben.
Post by Gerrit Heitsch
Erst Slackware, dann Mandrake/Mandriva.
Mein erstes Linux ( > 30 Disketten?) war Version 0.99
vielleicht Yggdrasil Linux.
386 AMD CPU 8 MB RAM, 60 MB Wechselplatte.
Mit 387 ging es dann nicht mehr.
Allerdings habe ich damit praktisch nichts gemacht.

Erst bei SuSE mit grafischer X Oberfläche habe ich ernsthaft
mit Linux angefangen.

Da war die grauenvolle Zeit bezüglich programmieren
mit OS/2 und windows vorbei.

Hermann
der, wenn er in die Vergangenheit reisen könnte
und sich einen computer Ratschlag geben könnte:
"Nach Atari ST nur Linux" empfehlen würde.
--
http://www.hermann-riemann.de
Martin Peters
2017-12-19 11:35:22 UTC
Antworten
Permalink
Raw Message
Post by Juergen Nickelsen
Post by Günter Frenz
1.: HP 9000/735 mit externer Grafikeinheit und 20" Monitor, Tastatur und
Maus. Die Maschine ist letztes Wochenende noch problemlos angelaufen
und man konnte sich anmelden (Passworte sind leer).
Die bekam ich 1994 oder '95 als Arbeitsplatz, in der 125-MHz-Version
und mit 144 MB RAM. Das war für die Zeit eine sehr schöne und
schnelle Maschine, (...)
Ich hab auch noch eine 735 im Vollausbau, also mit 384 MB RAM. Lange
nicht mehr in Betrieb gehabt. IIRC kam die 735 1992 auf den Markt...
Post by Juergen Nickelsen
Zwei Jahre später wechselte ich ins wirkliche Leben. Da war's dann
ein PC mit Windows 95. Schnüff.
... und zu dieser Zeit boten selbst die besten PCs kaum mehr als einen
maximalen Speicherausbau von vielleicht 64 MB. Echte x86-Workstations
gab's erst mit Einfuehrung des Pentium Pro, mit Wohlwollen mit
Einfuehrung des Pentium. Und fuer einen anstaendigen Speicherausbau
brauchte es dann schon ein Board im Stile des Tyan S1562.

Aber jemandem, der bis dahin an einer 735 gearbeitet hat einen PC mit
Windows 95 vorzusetzen? Wer macht denn sowas? Eine 735 war wenigstens
bis in dieses Jahrtausend hinein ein brauchbares Geraet, wohingegen
schon zur Jahrtausendwende niemand mehr einen PC von 94, 93 oder gar
1992 verwenden wollte, i.d.R. auch keinen Win95-PC mehr.
Volker Borchert
2017-12-19 23:12:58 UTC
Antworten
Permalink
Raw Message
Post by Martin Peters
Aber jemandem, der bis dahin an einer 735 gearbeitet hat einen PC mit
Windows 95 vorzusetzen? Wer macht denn sowas?
Jemand, der über natürliche Fluktuation Stellen abbauen will?
--
"I'm a doctor, not a mechanic." Dr Leonard McCoy <***@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <***@despammed.com>
Juergen Nickelsen
2017-12-20 14:45:46 UTC
Antworten
Permalink
Raw Message
Post by Martin Peters
Aber jemandem, der bis dahin an einer 735 gearbeitet hat einen PC mit
Windows 95 vorzusetzen? Wer macht denn sowas?
Ein anderer Arbeitgeber. Ein sehr guter, nebenbei, aber ein
Jahresgehalt des Mitarbeiters übrig für den Rechner hatte er auch
nicht. Die Hauptanwendung war dann ohnehin MS Word; FrameMaker (der
auf der 735 *sehr* gut lief für meine Diplomarbeit) gab's da auch
nicht.
--
About that little altercation I had with the Ayatollah Khomeini,
I'd like to point out that one of us is dead. My advice: Don't mess
with writers. -- Salman Rushdie
Goetz Hoffart
2017-12-20 17:04:25 UTC
Antworten
Permalink
Raw Message
FrameMaker (der auf der 735 *sehr* gut lief für meine Diplomarbeit)
Gibt es überhaupt eine Plattform, auf der Framemaker _nicht_ gut lief?

Isch schwör ja auf mein Framemaker 3 :-)

Grüße
Götz
--
http://www.knubbelmac.de/
Juergen Nickelsen
2017-12-21 13:32:24 UTC
Antworten
Permalink
Raw Message
Post by Goetz Hoffart
FrameMaker (der auf der 735 *sehr* gut lief für meine Diplomarbeit)
Gibt es überhaupt eine Plattform, auf der Framemaker _nicht_ gut lief?
Mein Macintosh Classic II mit 10 MB RAM. Das war *sehr* langsam.
--
Q: How many mathematicians does it take to screw in a lightbulb?
A: One. He gives it to six Californians, thereby reducing the problem
to the earlier joke.
Goetz Hoffart
2017-12-21 15:09:30 UTC
Antworten
Permalink
Raw Message
Post by Juergen Nickelsen
Post by Goetz Hoffart
Gibt es überhaupt eine Plattform, auf der Framemaker _nicht_ gut lief?
Mein Macintosh Classic II mit 10 MB RAM. Das war *sehr* langsam.
Okay, der ist 20-30% langsamer als mein SE/30. Da lief es (für mich)
immer recht flott, wobei ich da über 10 Seiten auch nie raus bin, dann
gab es neuere Hardware.

Grüße
Götz
--
http://www.knubbelmac.de/
Juergen Nickelsen
2017-12-22 13:13:51 UTC
Antworten
Permalink
Raw Message
Post by Goetz Hoffart
Post by Juergen Nickelsen
Mein Macintosh Classic II mit 10 MB RAM. Das war *sehr* langsam.
Okay, der ist 20-30% langsamer als mein SE/30. Da lief es (für mich)
immer recht flott, [...]
Vor allem war der Speicher für FrameMaker zu klein, das hat es so
langsam gemacht. Etwas später bekam ich einen NextCube mit deutlich
mehr RAM (und 25 MHz 68040) als Leihgabe, das war *erheblich*
besser.
--
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin
Goetz Hoffart
2017-12-22 23:41:44 UTC
Antworten
Permalink
Raw Message
Post by Juergen Nickelsen
Vor allem war der Speicher für FrameMaker zu klein, das hat es so
langsam gemacht.
Hm, okay, die 20 MB in meinem SE/30 waren (natürlich) nie ein Problem
für meine 10seiter.
Post by Juergen Nickelsen
Etwas später bekam ich einen NextCube mit deutlich mehr RAM (und 25 MHz
68040) als Leihgabe, das war *erheblich* besser.
Nun gut, ein Cube mit 68040 spielt aber in jeder Hinsicht in einer
anderen Liga als ein Classic II, der so bei 2 MIPS rumdümpelt, während
ein 68040/25 bei etwa 30 MIPS liegen dürfte, vom Speicherdurchsatz mal
ganz abgesehen.

Grüße
Götz
--
http://www.knubbelmac.de/
Martin Peters
2017-12-21 10:06:59 UTC
Antworten
Permalink
Raw Message
Post by Juergen Nickelsen
Post by Martin Peters
Aber jemandem, der bis dahin an einer 735 gearbeitet hat einen PC mit
Windows 95 vorzusetzen? Wer macht denn sowas?
Ein anderer Arbeitgeber. Ein sehr guter, nebenbei, aber ein
Jahresgehalt des Mitarbeiters übrig für den Rechner hatte er auch
nicht. Die Hauptanwendung war dann ohnehin MS Word;
Verstaendlich. Ja, echte Workstations waren damals verdammt teuer, auch
die von SGI, Sun und IBM.
Post by Juergen Nickelsen
FrameMaker (der
auf der 735 *sehr* gut lief für meine Diplomarbeit)
Ich weiss, bt;dt
Gerrit Heitsch
2017-12-21 11:07:56 UTC
Antworten
Permalink
Raw Message
Post by Juergen Nickelsen
Post by Martin Peters
Aber jemandem, der bis dahin an einer 735 gearbeitet hat einen PC mit
Windows 95 vorzusetzen? Wer macht denn sowas?
Ein anderer Arbeitgeber. Ein sehr guter, nebenbei, aber ein
Jahresgehalt des Mitarbeiters übrig für den Rechner hatte er auch
nicht. Die Hauptanwendung war dann ohnehin MS Word; FrameMaker (der
auf der 735 *sehr* gut lief für meine Diplomarbeit) gab's da auch
nicht.
Ich hab meine auch in FrameMaker geschrieben, auf Solaris. War schön
stressfrei da die Vorlage von der Uni kam, man also nur noch den Inhalt
beisteuern musste. Word für die Diplomarbeit haben damals nur
Masochisten oder Leute die es nicht besser wussten benutzt.

Ich hab noch das .ps, welches an einen PS-Drucker geschickt, die Arbeit
ausdruckt. :)

Gerrit
Ralf Kiefer
2017-12-21 12:25:27 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Word für die Diplomarbeit haben damals nur
Masochisten oder Leute die es nicht besser wussten benutzt.
Es gab noch eine Ausnahme: "nur" ein Mac für die Diplomarbeit verfügbar
und das vor der Portierung von Framemaker auf den Mac, also vor 1990.
Von Tex wußte ich zu diesem Zeitpunkt auch noch nichts.

Daher entstand meine Diplomarbeit mit Word 3. Mein Zimmernachbar im
Studentenwohnheim quälte sich mit einer Herculeskarte und "fast"[tm]
runden Kreisen mit seinem Word in der Variante "What you see is what you
never get", während ich "What you see is what you hope to get" auf einem
Mac 512 hatte.
Post by Gerrit Heitsch
Ich hab noch das .ps, welches an einen PS-Drucker geschickt, die Arbeit
ausdruckt. :)
Einmalig Apfelmenü -> Auswahl -> LaserWriter, dann in Word den Menüpunkt
"Drucken". Mußte man mehr tun? ;-)

Gruß, Ralf
Gerrit Heitsch
2017-12-21 12:59:48 UTC
Antworten
Permalink
Raw Message
Post by Ralf Kiefer
Post by Gerrit Heitsch
Word für die Diplomarbeit haben damals nur
Masochisten oder Leute die es nicht besser wussten benutzt.
Es gab noch eine Ausnahme: "nur" ein Mac für die Diplomarbeit verfügbar
und das vor der Portierung von Framemaker auf den Mac, also vor 1990.
Von Tex wußte ich zu diesem Zeitpunkt auch noch nichts.
Daher entstand meine Diplomarbeit mit Word 3. Mein Zimmernachbar im
Studentenwohnheim quälte sich mit einer Herculeskarte und "fast"[tm]
runden Kreisen mit seinem Word in der Variante "What you see is what you
never get", während ich "What you see is what you hope to get" auf einem
Mac 512 hatte.
Post by Gerrit Heitsch
Ich hab noch das .ps, welches an einen PS-Drucker geschickt, die Arbeit
ausdruckt. :)
Einmalig Apfelmenü -> Auswahl -> LaserWriter, dann in Word den Menüpunkt
"Drucken". Mußte man mehr tun? ;-)
Ja, fluchen wenn das 'hope to' zu 'don't' wird. Dann geht der Spass los.

Mit obigem ist gemeint, daß ich zwar keinen Framemaker mehr im Zugriff
habe, aber trotzdem jederzeit ein neues Exemplar meiner Arbeit drucken
könnte. Mach das mal mit alten .doc

Gerrit
Ralf Kiefer
2017-12-21 13:33:27 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Mit obigem ist gemeint, daß ich zwar keinen Framemaker mehr im Zugriff
habe, aber trotzdem jederzeit ein neues Exemplar meiner Arbeit drucken
könnte. Mach das mal mit alten .doc
Ich habe alte Framemaker (in der Mac-Version) im Zugriff sowie die alten
Rechner, um alte Software laufen zu lassen. An Postscript-Druckern
mangelt es genausowenig :-) Ein Mac, der auch mit M$-Software verseucht
ist, ist speziell dafür betriebsbereit Software und Daten der 1990er
Jahre zu nutzen.

Die Idee die Postscript-Datei zu bewahren sollte ich für ein paar
besondere Dokumente vielleicht übernehmen.

Gruß, Ralf
Gerrit Heitsch
2017-12-21 14:12:48 UTC
Antworten
Permalink
Raw Message
Post by Ralf Kiefer
Post by Gerrit Heitsch
Mit obigem ist gemeint, daß ich zwar keinen Framemaker mehr im Zugriff
habe, aber trotzdem jederzeit ein neues Exemplar meiner Arbeit drucken
könnte. Mach das mal mit alten .doc
Ich habe alte Framemaker (in der Mac-Version) im Zugriff sowie die alten
Rechner, um alte Software laufen zu lassen. An Postscript-Druckern
mangelt es genausowenig :-) Ein Mac, der auch mit M$-Software verseucht
ist, ist speziell dafür betriebsbereit Software und Daten der 1990er
Jahre zu nutzen.
Hin und wieder mal reinschauen wie es der Li-Batterie geht. Diese 1/2
AA-Zellen in vielen Macs können auslaufen und dann ist die Platine hin.
Post by Ralf Kiefer
Die Idee die Postscript-Datei zu bewahren sollte ich für ein paar
besondere Dokumente vielleicht übernehmen.
.PS oder .PDF sollte in dieser Hinsicht äquivalent sein.

Gerrit
Ralf Kiefer
2017-12-21 14:33:42 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Hin und wieder mal reinschauen wie es der Li-Batterie geht. Diese 1/2
AA-Zellen in vielen Macs können auslaufen und dann ist die Platine hin.
Ich weiß :-( Ich habe Macs deswegen bereits beerdigt, z.B. diesen
hier:
www.ralf-kiefer.de/Mac/Small_Bad_IIsi.jpg

Der erwähnte Mac läuft daher ganz ohne Batterie und mit dem richtigen
Kontrollfeld ("PRAM Auto-Restore").
Post by Gerrit Heitsch
.PS oder .PDF sollte in dieser Hinsicht äquivalent sein.
Der LaserWriter-Treiber im Mac hat die Option die Postscript-Textdatei
nicht an den Drucker zu schicken, sondern als Datei abzulegen. Mit dem
"Apple Drucker Dienstprogramm" kann man die später zum Drucker schicken.

Gruß, Ralf
Bernd Laengerich
2018-01-01 22:08:23 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Ich hab meine auch in FrameMaker geschrieben, auf Solaris. War schön
Was für ein Komfort.
Bei mir Wordstar. Und die Escapesequenzen für den geliehenen
Typenraddrucker musste man auch erstmal einpatchen...

Bernd
Juergen Nickelsen
2018-01-03 10:16:59 UTC
Antworten
Permalink
Raw Message
Post by Bernd Laengerich
Post by Gerrit Heitsch
Ich hab meine auch in FrameMaker geschrieben, auf Solaris. War schön
Was für ein Komfort.
Bei mir Wordstar. Und die Escapesequenzen für den geliehenen
Typenraddrucker musste man auch erstmal einpatchen...
Nu, das ist der Unterschied der Technikgenerationen der 70er und der
90er Jahre, schönes Beispiel!
--
There are 10^11 stars in the galaxy. That used to be a huge number.
But it's only a hundred billion. It's less than the national
deficit! We used to call them astronomical numbers. Now we should
call them economical numbers. -- Richard P. Feynman
Hermann Riemann
2018-01-03 11:24:29 UTC
Antworten
Permalink
Raw Message
Post by Juergen Nickelsen
Post by Bernd Laengerich
Bei mir Wordstar. Und die Escapesequenzen für den geliehenen
Typenraddrucker musste man auch erstmal einpatchen...
Nu, das ist der Unterschied der Technikgenerationen der 70er und der
90er Jahre, schönes Beispiel!
Also bei meine alten Nadeldrucker hatte ich keine Speicherprobleme
mit großen Bilder.
Wenn ich die noch hätte würde ich einfach die Daten
aus der Speicherdarstellung übetragen.

Mein Laser Drucker von brother hat ein großes Bild verweigert.

Hermann
der gerne alles selber herstellen würde.
--
http://www.hermann-riemann.de
Markus Elsken
2018-01-03 12:23:00 UTC
Antworten
Permalink
Raw Message
Moin!
Post by Hermann Riemann
Mein Laser Drucker von brother hat ein großes Bild verweigert.
Nachdem ich meinem HL-1870DTN einen RAM-Riegel verpasst habe tat er das
nicht mehr. Aktuell hat er 144MB drin.

mfg Markus
Kay Martinen
2018-01-03 17:47:20 UTC
Antworten
Permalink
Raw Message
Post by Hermann Riemann
Post by Juergen Nickelsen
Post by Bernd Laengerich
Bei mir Wordstar. Und die Escapesequenzen für den geliehenen
Typenraddrucker musste man auch erstmal einpatchen...
Nu, das ist der Unterschied der Technikgenerationen der 70er und der
90er Jahre, schönes Beispiel!
HäHä, 70er? Das Druckerinterface um eine El.Schreibmaschine an einen
Homecomputer zu klöppeln erinnere ich dunkel eher in den 80er'n - in der
ELRAD (oder c't Beilage)

Ich selbst hab in den 80er'n noch ESC-Sequenzen in SAA-Menüs ein
geklöppelt um Nadeldrucker zum Rennen zu bringen.

In den 90er'n gab es doch m.E. schon GUI-Drucker die all das nicht mehr
brauchten - und alleine eh nix konnten.

Immer wieder ein Vorteil eines Alten Parallelen Druckers an Alter HW.
Man kann einfach Print Screen im BIOS/Setup Drücken und bekommt sofort
eine Hardcopy.
Post by Hermann Riemann
Also bei meine alten Nadeldrucker hatte ich keine Speicherprobleme
mit großen Bilder.
Wenn ich die noch hätte würde ich einfach die Daten
aus der Speicherdarstellung übetragen.
AFAIR hatten Nadler auch nur genug RAM für den Prozessor und eine
Grafikzeile oder Textseite - je nach Fähigkeit. Der Nachschub kam
häppchenweise vom Host über die Parallele Schnittstelle.

Da kann es keine Probleme mit Großen Bildern geben weil der Host den
Ausdruck eh in der Warteschlange hortet. Dafür war nach einem
Stromausfall ggf. der Druckauftrag weg und man hatte nur einen Halben Druck.
Post by Hermann Riemann
Mein Laser Drucker von brother hat ein großes Bild verweigert.
Das tat mein IBM 4000'er Laser auch weil er zu wenig RAM hatte. Laser
sind IMHO per-se Seitendrucker und bauen gern die gesamte Seite in ihrem
RAM zusammen. Wenn sie ihnen nicht vom Host gestreamt wurde. Aber ich
denke das nicht alle Laser diesen Modus (Bezeichnung?) kannten.
Post by Hermann Riemann
Hermann
   der gerne alles selber herstellen würde.
Hermann, das ist heute doch weniger ein Problem als damals. Besorge dir
einen vielseitigen 3D-Drucker, suche dir die gewünschten
OpenHardware-Dateien und leg los. Vielleicht kann man damit in Zukunft
sogar Körper(teile) drucken. Alles eine Frage der richtigen Backmischung. ;)

Ich wünscht ich könnte mir einen Leisten um die Gebrochenen
Papierführungs-nasen an o.G. Laser nachbauen zu können. Bis auf die
Funktionierte der noch - vor einigen Jahren.

Kay
Ralf Kiefer
2018-01-03 18:24:18 UTC
Antworten
Permalink
Raw Message
Post by Kay Martinen
Post by Hermann Riemann
Mein Laser Drucker von brother hat ein großes Bild verweigert.
Das tat mein IBM 4000'er Laser auch weil er zu wenig RAM hatte. Laser
sind IMHO per-se Seitendrucker und bauen gern die gesamte Seite in ihrem
RAM zusammen. Wenn sie ihnen nicht vom Host gestreamt wurde. Aber ich
denke das nicht alle Laser diesen Modus (Bezeichnung?) kannten.
1985: der LaserWriter erschien mit 1,5MB RAM, davon wurden knapp über
1MB fürs Image genutzt. Wenn das Postscript allerdings mehr als die
450kB brauchte, wurde gesplittet. D.h. der Postscript-Interpreter bekam
das, was er brauchte, und die entsprechenden Bildteile wurden ggf. in
mehreren Durchgängen berechnet. Langsam wäre noch übertrieben als
Beschreibung der Druckgeschwindigkeit in diesem Modus. Der Ausdruck vom
Platinenlayout einer knapp DIN-A4-großen Platine dauerte so rund 45min.
Aber es kam was raus :-)


Gruß, Ralf
Markus Elsken
2018-01-04 17:05:13 UTC
Antworten
Permalink
Raw Message
Moin!
Post by Ralf Kiefer
Der Ausdruck vom
Platinenlayout einer knapp DIN-A4-großen Platine dauerte so rund 45min.
Es gab seinerzeit verschiedene Apfel.ps, wo der Drucker ein
Apfelmännchen berechnete (!) und ausdruckte. Das konnte einen
LaserWriter II aka Laserjet 3 schon mal einen Arbeitstag lang lahmlegen...

mfg Markus
Hermann Riemann
2018-01-03 18:46:15 UTC
Antworten
Permalink
Raw Message
Post by Kay Martinen
HäHä, 70er? Das Druckerinterface um eine El.Schreibmaschine an einen
Homecomputer zu klöppeln erinnere ich dunkel eher in den 80er'n - in der
ELRAD (oder c't Beilage)
Ich selbst hab in den 80er'n noch ESC-Sequenzen in SAA-Menüs ein
geklöppelt um Nadeldrucker zum Rennen zu bringen.
Zu Z80 6502 und Atari ST Zeiten
gab es bei mir noch Nadeldrucker, deren bytes ich über einen IO-port
oder bei Atari ST über BIOS verschickte

Zu den Drucker gab es noch kleine übersichtliche Beschreibungen.
Post by Kay Martinen
In den 90er'n gab es doch m.E. schon GUI-Drucker die all das nicht mehr
brauchten - und alleine eh nix konnten.
Mit dem Wechsel zu 386 mit Linux OS/2 und windows 9*
ging es dann mit Tintenspritzer und Treiber ( postscript ) los.
Post by Kay Martinen
Immer wieder ein Vorteil eines Alten Parallelen Druckers an Alter HW.
Man kann einfach Print Screen im BIOS/Setup Drücken und bekommt sofort
eine Hardcopy.
Man konnte einfach selber malen und gut steuern.
Post by Kay Martinen
AFAIR hatten Nadler auch nur genug RAM für den Prozessor und eine
Grafikzeile oder  Textseite - je nach Fähigkeit.
Nein, da waren kleine micocontroller ( 8048?) drin.
Ob die mehr las 10 byte pufferten, ..
Post by Kay Martinen
Da kann es keine Probleme mit Großen Bildern geben weil der Host den
Ausdruck eh in der Warteschlange hortet.
Bis incl. Atari ST Zeiten habe ich die Speicherverwaltung
selber gebastelt.
Post by Kay Martinen
Dafür war nach einem Stromausfall ggf. der Druckauftrag weg
Der war in München sehr selten
Post by Kay Martinen
und man hatte nur einen Halben Druck.
Den man fortsetzen konnte.
Post by Kay Martinen
Post by Hermann Riemann
Hermann
    der gerne alles selber herstellen würde.
Hermann, das ist heute doch weniger ein Problem als damals.
Besorge dir einen vielseitigen 3D-Drucker,
Ein 3D-Drucker der auch fräsen kann, gibt es zwar,
allerdings fehlen noch Roboter zum Austausch der Köpfe
und Piezo-Kistallzusätze zur Positionierung im Nanometerbereich
und..
( Und Platz)
Post by Kay Martinen
suche dir die gewünschten OpenHardware-Dateien und leg los.
Oder selber mit Arduino L293 ..
Post by Kay Martinen
Vielleicht kann man damit in Zukunft sogar Körper(teile) drucken.
http://www.spiegel.de/wissenschaft/medizin/gewebe-aus-3d-drucker-ohren-kiefer-muskeln-a-1077677.html

Also Zellspritzer statt Tinterspritzer
( mit passenden Zellen deren genetischen code
dem eigenen Körper entnommen und korrigiert wurde ..)
Post by Kay Martinen
Alles eine Frage der richtigen Backmischung. ;)
Von Dr. Quacksalber
Post by Kay Martinen
Ich wünscht ich könnte mir einen Leisten um die Gebrochenen
Papierführungs-nasen an o.G. Laser nachbauen zu können.
In 10 Jahren geht es.
Und dann gibt es Probleme mit interne Uhrenchip
wegen Ablaufdatum überschritten.
( Und fehlender internet Verbindung.)

Hermann
der vermutet, dass die meisten Roboter in 20 Jahren
kleiner als Insekten sind.
--
http://www.hermann-riemann.de
Andreas Kohlbach
2018-01-03 22:48:28 UTC
Antworten
Permalink
Raw Message
Post by Hermann Riemann
Post by Kay Martinen
HäHä, 70er? Das Druckerinterface um eine El.Schreibmaschine an einen
Homecomputer zu klöppeln erinnere ich dunkel eher in den 80er'n - in
der ELRAD (oder c't Beilage)
Ich selbst hab in den 80er'n noch ESC-Sequenzen in SAA-Menüs ein
geklöppelt um Nadeldrucker zum Rennen zu bringen.
Zu Z80 6502 und Atari ST Zeiten
gab es bei mir noch Nadeldrucker, deren bytes ich über einen IO-port
oder bei Atari ST über BIOS verschickte
Und kein Drucker eines Herstellers funktionierte bei einem anderen
Computer. Eine genormte Parallel-Schnittstelle hatten C64 und Kollegen
aus dem 8Bit Bereich nicht. Der Amiga dann aber, wohl auch der Atari ST.
Post by Hermann Riemann
Zu den Drucker gab es noch kleine übersichtliche Beschreibungen.
Und laaaaange Tabellen für Escape-Sequenzen. Oder auch wie man das in
BASIC machten. Ich scheine mich an

PRINT CHR$(27):PRINT CHR$(WAS_ANDERES)

zu erinnern. Die 27 sagte, dass nun die eigentliche Sequenz kommt.

[...]
Post by Hermann Riemann
Post by Kay Martinen
Immer wieder ein Vorteil eines Alten Parallelen Druckers an Alter
HW. Man kann einfach Print Screen im BIOS/Setup Drücken und bekommt
sofort eine Hardcopy.
Man konnte einfach selber malen und gut steuern.
Aber nur ASCII.

Wenn man z.B. einen Textverarbeitungsprogramm, wie erwähntes Wordstar [1]
hier, nahm, was u.a superscripts und subscripts konnte, was aber nicht
jeder Drucker gleich handhabt.

[...]
Post by Hermann Riemann
Post by Kay Martinen
Da kann es keine Probleme mit Großen Bildern geben weil der Host den
Ausdruck eh in der Warteschlange hortet.
Bis incl. Atari ST Zeiten habe ich die Speicherverwaltung
selber gebastelt.
In BYTE Magazinen bis etwa 1985 (IIRC) werden externe Druckerpuffer (Spooler)
angeboten, Preis je nach RAM (bis zu 512K!!!elf ;-). Und damit beworben,
dass man nicht mehr warten müsste, bis der PC wieder erreichbar
war. Darunter meist zwei Bilder. Eines mit einem Büroangestellten ohne,
und eines mit einem mit der Hardware. *g*

Dabei hätte man MP/M oder ein anderen Multitasking OS einsetzen können,
und die teure Hardware sparen können.

[...]

[1] Ich hatte neulich auf einem Osborne I mal mit Wordstar und SuperCalc
sowie dBase II kurz gespielt, und das auch auf YouTube hochgeladen. Muss
eine aufregende Zeit Anfang der 80er gewesen sein, als das alles noch neu
war, und ohne Mausbedienung. Und man wirklich, wie auch ich, erst lesen
musste, um damit arbeiten zu können. Wordstar Diamond und so.
--
Andreas
You know you are a redneck if
you have started a petition to change the national anthem to "georgia
on my mind".
Kay Martinen
2018-01-03 23:18:16 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Post by Hermann Riemann
Zu Z80 6502 und Atari ST Zeiten
gab es bei mir noch Nadeldrucker, deren bytes ich über einen IO-port
oder bei Atari ST über BIOS verschickte
War doch beim PC prinzipiell kaum anders. Die IO-Ports waren da halt
$3bc, $278 und $378 und die IRQ 5 und 7 - wenn man sie brauchte.
Und die Druckroutine stecke schon im BIOS.
Post by Andreas Kohlbach
Und kein Drucker eines Herstellers funktionierte bei einem anderen
Computer. Eine genormte Parallel-Schnittstelle hatten C64 und Kollegen
aus dem 8Bit Bereich nicht. Der Amiga dann aber, wohl auch der Atari ST.
Stimmt. Der C-64 hatte von Haus aus nur seine IEC. Es gab aber
Centronics-Interfaces für den Userport, die brauchten dann aber wieder
Software-seitige Unterstützung vom Programm. Oder ein Extra EEPROM mit
den Druckroutinen wo dann z.B. der Druck via IEC auf das
Userport-interface umgebogen wurde. Wenn es angestöpselt und der Drucker
an war dann kam sogar was raus. ;)

Alternative. Ich hatte damals einen Riteman C+ von C.Itoh (IEC-Port).
Den gab es auch als Riteman F+ direkt mit Centronics.
Post by Andreas Kohlbach
BASIC machten. Ich scheine mich an
PRINT CHR$(27):PRINT CHR$(WAS_ANDERES)
zu erinnern. Die 27 sagte, dass nun die eigentliche Sequenz kommt.
Die 27 war halt der ASCII-Wert des ESCAPE Zeichens. Daher wohl auch
ESC-P codes weil IMHO von ePson eingeführt.
https://de.wikipedia.org/wiki/ESC/P
Post by Andreas Kohlbach
Post by Hermann Riemann
Post by Kay Martinen
HW. Man kann einfach Print Screen im BIOS/Setup Drücken und bekommt
sofort eine Hardcopy.
Man konnte einfach selber malen und gut steuern.
Aber nur ASCII.
Konkret US-ASCII aber MIT den Blockgrafik-Zeichen so das Rahmen u.a. aus
dem BIOS Setup durchaus korrekt dargestellt wurden. Wenn der Drucker von
haus aus auf diesen Zeichensatz eingestellt war. Wenn nicht kam nur
kauderwelsch raus.
Post by Andreas Kohlbach
Wenn man z.B. einen Textverarbeitungsprogramm, wie erwähntes Wordstar [1]
hier, nahm, was u.a superscripts und subscripts konnte, was aber nicht
jeder Drucker gleich handhabt.
Ja, die 8/9-Nadler taten sich etwas schwer mit Hoch und Tief gestelltem.
Das konnte man kaum noch erkennen. Die 24-Nadler konnten es dann besser.
Warum wohl.
Post by Andreas Kohlbach
In BYTE Magazinen bis etwa 1985 (IIRC) werden externe Druckerpuffer (Spooler)
angeboten, Preis je nach RAM (bis zu 512K!!!elf ;-).
Ich habe hier noch so einen herum liegen. Darin ein kleines TTL-Grab und
an der Front Zwei Tasten. Reset und COPY.
Post by Andreas Kohlbach
Dabei hätte man MP/M oder ein anderen Multitasking OS einsetzen können,
und die teure Hardware sparen können.
Ja, dieser unselige Trend Dinge der HW in Software nach zu klemptnern
hält ja bis heute an. ;-)

Nach SDN kommt dann das Total Virtualisierte Rechenzentrum... und
irgendwann sind wir selbst auch nur noch Emulationen unserer Selbst.

Willkommen in der "Welt am Draht"

Kay
Michael Welle
2018-01-04 09:26:29 UTC
Antworten
Permalink
Raw Message
Hallo,

Kay Martinen <***@martinen.de> writes:
[...]
Post by Kay Martinen
Nach SDN kommt dann das Total Virtualisierte Rechenzentrum... und
Sun Developer Network?

VG
hmw
Kay Martinen
2018-01-04 12:46:26 UTC
Antworten
Permalink
Raw Message
Post by Michael Welle
Hallo,
[...]
Post by Kay Martinen
Nach SDN kommt dann das Total Virtualisierte Rechenzentrum... und
Sun Developer Network?
Oh, sorry. Mist-verständlich. Software-Defined Networking!

Kay
Michael Welle
2018-01-04 13:42:24 UTC
Antworten
Permalink
Raw Message
Hallo,
Post by Kay Martinen
Post by Michael Welle
Hallo,
[...]
Post by Kay Martinen
Nach SDN kommt dann das Total Virtualisierte Rechenzentrum... und
Sun Developer Network?
Oh, sorry. Mist-verständlich. Software-Defined Networking!
alles klar, danke.

VG
hmw
Andreas Kohlbach
2018-01-04 22:18:06 UTC
Antworten
Permalink
Raw Message
Post by Kay Martinen
Post by Andreas Kohlbach
Post by Hermann Riemann
Zu Z80 6502 und Atari ST Zeiten
gab es bei mir noch Nadeldrucker, deren bytes ich über einen IO-port
oder bei Atari ST über BIOS verschickte
War doch beim PC prinzipiell kaum anders. Die IO-Ports waren da halt
$3bc, $278 und $378 und die IRQ 5 und 7 - wenn man sie brauchte.
Und die Druckroutine stecke schon im BIOS.
IIRC war das Polling, kam ohne Interrupt aus. I/O Ports gab es, aber
verschieden von Hersteller zu Hersteller.

[Druckerpfuffer]
Post by Kay Martinen
Post by Andreas Kohlbach
Dabei hätte man MP/M oder ein anderen Multitasking OS einsetzen können,
und die teure Hardware sparen können.
Ja, dieser unselige Trend Dinge der HW in Software nach zu klemptnern
hält ja bis heute an. ;-)
Aber das ist bis heute so, und soll auch.

Vielleicht kennst du Früher [TM] nicht? Als man einen Druck-Job zum PC
abschickte, und man Däumchendrehen konnte. Weil der PC mit dem Senden der
Daten an den Drucker beschäftigt war, und nichts anderes machen
konnte. Irgendwann in den frühen 80ern kamen Hardwareentwickler auf den
Trichter, einen Puffer mit viel RAM (bis zu 512 KB *g*) dafür zu
verkaufen, die Daten des PC anzunehmen statt des Druckers
(Proxy). Nachdem der PC die Druckerdaten an den Puffer übergab, war der PC
wieder frei. Der Puffer bediente in der Zwischenzeit den PC mit Daten.

Heute, aber auch schon ab 1979, als es MP/M (Concurrent OS) gab, hätte
man sich den teuren Puffer sparen können. Weil concurrent (Multitasking)
es erlaubt, weiter zu arbeiten, während man die Druckdaten gleichzeitig
direkt vom PC zum Drucker schickt.

Ich schaue mal, ob ich eine Werbung in der BYTE oder anderen finde, die
diese Puffer anpreist. Mit Bildern von *genervten* Büroaffen in einem
Bild. Und *fröhlichen* Bürohengsten im anderen, die den Puffer hatten.
Schlangenöl der 80er... Werde die Werbung dann in ein PDF packen und auf
einen meiner Server hochladen und die URL hier posten - wenn jemand hier
Interesse hat.
--
Andreas
You know you are a redneck if
the fifth grade is referred to as "your senior year."
Kay Martinen
2018-01-05 14:49:21 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Post by Kay Martinen
War doch beim PC prinzipiell kaum anders. Die IO-Ports waren da halt
$3bc, $278 und $378 und die IRQ 5 und 7 - wenn man sie brauchte.
Und die Druckroutine stecke schon im BIOS.
IIRC war das Polling, kam ohne Interrupt aus. I/O Ports gab es, aber
verschieden von Hersteller zu Hersteller.
Ich schrieb ja "wenn man sie brauchte" und Polling-betrieb ist bekannt.
Das funktionierte "meistens". Den IRQ musste man bei ISA-Karten oft
dennoch per Jumper festlegen.
Post by Andreas Kohlbach
[Druckerpfuffer]
Post by Kay Martinen
Post by Andreas Kohlbach
Dabei hätte man MP/M oder ein anderen Multitasking OS einsetzen können,
und die teure Hardware sparen können.
Ja, dieser unselige Trend Dinge der HW in Software nach zu klemptnern
hält ja bis heute an. ;-)
Aber das ist bis heute so, und soll auch.
Das sollte ein halber Scherz sein. Es ist zwar so und kann auch Vorteile
haben. Aber ich finde auch das es nicht in jedem fall sinnvoll ist.

Aktuelles (Halb)Beispiel: Die Lücken in einem Haufen Prozessoren haben
doch unter anderem nur darum so viel macht weil man seit etlichen Jahren
ein Flat Memory Modell fährt und alle neueren Schutztechniken
(NoExecute, ASLR) darauf ausgelegt werden oder Folgen der Defizite dabei
sind.

Nix neues das ich meine: hätte man sich an die seit i386 eingebauten
Hardware-Mechanismen (Controlbits in GDT und LDTs) gehalten dann hätte
man diese Probleme heute nicht in dem Maße. Denn dann wäre es einem
Prozess nicht möglich im Speicher eines anderen herum zu sauen.
Post by Andreas Kohlbach
Vielleicht kennst du Früher [TM] nicht? Als man einen Druck-Job zum PC
abschickte, und man Däumchendrehen konnte. Weil der PC mit dem Senden der
Daten an den Drucker beschäftigt war, und nichts anderes machen
Doch, kenne ich. Ich Stamme; wie du; aus dem Früher [TM]. :)
Manchmal denke ich, ich lebe sogar noch dort... ;)
Post by Andreas Kohlbach
konnte. Irgendwann in den frühen 80ern kamen Hardwareentwickler auf den
Trichter, einen Puffer mit viel RAM (bis zu 512 KB *g*) dafür zu
verkaufen, die Daten des PC anzunehmen statt des Druckers
(Proxy). Nachdem der PC die Druckerdaten an den Puffer übergab, war der PC
wieder frei. Der Puffer bediente in der Zwischenzeit den PC mit Daten.
Ich hatte doch schon geschrieben das ich selbst auch noch so einen
Bufferkasten habe. Ich weiß es also.
Post by Andreas Kohlbach
Heute, aber auch schon ab 1979, als es MP/M (Concurrent OS) gab, hätte
man sich den teuren Puffer sparen können. Weil concurrent (Multitasking)
es erlaubt, weiter zu arbeiten, während man die Druckdaten gleichzeitig
direkt vom PC zum Drucker schickt.
Ja, möglichkeiten wie diese gab es. Aber kaum für Heimanwender tragbare.
Da war ein Buffer auch eine Teure Investition. Wenn es also nicht per
Software ging musste man halt warten. Und die Drucker damals waren teils
kaum schneller als eine 50Baud Fernschreibmaschine.

Ich erinnere einen Seikoska SL-IP 80 den ich mir vor jahren ein fing.
Gemächliches Gerät für einen Nadler.
Post by Andreas Kohlbach
Ich schaue mal, ob ich eine Werbung in der BYTE oder anderen finde, die
diese Puffer anpreist. Mit Bildern von *genervten* Büroaffen in einem
Und wenn andererseits Bedarf besteht ein Photo von meinem
Druckerbuffer-Kasten zu sehen kann ich das auch gerne mal wo hochladen.
Ist ein Flaches Alu-Profilgehäuse mit Centronics Buchse und einem
Flachkabel mit Stecker zum Drucker.

Kay
Gerrit Heitsch
2018-01-05 15:04:41 UTC
Antworten
Permalink
Raw Message
Post by Kay Martinen
Aktuelles (Halb)Beispiel: Die Lücken in einem Haufen Prozessoren haben
doch unter anderem nur darum so viel macht weil man seit etlichen Jahren
ein Flat Memory Modell fährt und alle neueren Schutztechniken
(NoExecute, ASLR) darauf ausgelegt werden oder Folgen der Defizite dabei
sind.
Nix neues das ich meine: hätte man sich an die seit i386 eingebauten
Hardware-Mechanismen (Controlbits in GDT und LDTs) gehalten dann hätte
man diese Probleme heute nicht in dem Maße. Denn dann wäre es einem
Prozess nicht möglich im Speicher eines anderen herum zu sauen.
Auf der anderen Seite ist es gut, daß die idiotische Segmentierung tot
ist. Das war ein Überbleibsel der Anfangszeit als man den Trick brauchte
um mehr als 64KB adressieren zu können.

Das aktuelle Problem liegt eher daran, daß die Auswertung des 'darf ich
das überhaupt?' erst NACH dem Zugriff passiert und wenn die Antwort
'nein!' ist ein Rollback passiert. Leider nur im Prozessorstatus, nicht
im Cache. Zusammen mit Out-of-Order Execution und spekulativer
Ausführung ergibt das eben Meltdown und Spectre.

Gerrit
Hermann Riemann
2018-01-05 16:52:57 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Auf der anderen Seite ist es gut, daß die idiotische Segmentierung tot
ist.
Träumer? ;-)

Hermann
der gerne seine Ordner ohne softlink auf SSD und Magnetplatten
selber verteilen würde, ohne dafür noch extra partitions
anlegen zu müssen.
--
http://www.hermann-riemann.de
Kay Martinen
2018-01-05 17:17:52 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Post by Kay Martinen
Aktuelles (Halb)Beispiel: Die Lücken in einem Haufen Prozessoren haben
doch unter anderem nur darum so viel macht weil man seit etlichen Jahren
ein Flat Memory Modell fährt und alle neueren Schutztechniken
(NoExecute, ASLR) darauf ausgelegt werden oder Folgen der Defizite dabei
sind.
Nix neues das ich meine: hätte man sich an die seit i386 eingebauten
Hardware-Mechanismen (Controlbits in GDT und LDTs) gehalten dann hätte
man diese Probleme heute nicht in dem Maße. Denn dann wäre es einem
Prozess nicht möglich im Speicher eines anderen herum zu sauen.
Auf der anderen Seite ist es gut, daß die idiotische Segmentierung tot
ist. Das war ein Überbleibsel der Anfangszeit als man den Trick brauchte
um mehr als 64KB adressieren zu können.
Ja, schon. Nur damit waren ja bis zu 1MB RAM addressierbar. Aber später
mehr. Und da wurde es mit den im Protected Mode laufenden OS IMHO doch
eher zur Seltenheit das man direkt mit SEGMENT:OFFSET arbeitete. Da war
das Segment nicht mehr als ein Index in die [G|L]DT die außerdem noch
durch paging modifiziert werden konnte. Und ab Protected Mode waren auch
die eingebauten Schutzmechanismen für die Segmente und Ringe aktiv.

AFAIR war bei den frühen CPUs (i286?) die Granularity kleiner. Aber;
ebenfalls AFAIR; ab dem i386 oder später waren damit bis zu 4 GB Große
Segmente möglich, egal ob für Daten oder Code (oder Stack/ES, FS?)
Und wäre man nicht in die Flatmem-Richtung gegangen hätte es vielleicht
heute statt NX u.a. weitere CPU-Features gegeben. Denkbar wäre doch 4TB
Große Segmente mit feinerer Granularity oder variabler größe, weiteres
aufmotzen der x86vm in richtung hypervisor...
Essentiell sind m.E. immer noch die eine GDT und über LDT's sind bis ca.
8000 Segmente möglich. Mit obigen verbesserungen... hat man echt
maschinen bei denen über 8000 Prozesse laufen?

Ich glaube das Descriptor-tabellen Konzept ist seit den 32Bit CPUs auch
nicht mehr aufgebohrt worden. Theoretisch müsste da doch auch noch mehr
drin sein (X millionen Segmente/Prozesse und ein eigener Cache dafür...)

Aber: Alles Eier die nicht mehr gelegt werden sollen weil es keiner
will. Richtig?
Post by Gerrit Heitsch
Das aktuelle Problem liegt eher daran, daß die Auswertung des 'darf ich
das überhaupt?' erst NACH dem Zugriff passiert und wenn die Antwort
'nein!' ist ein Rollback passiert. Leider nur im Prozessorstatus, nicht
im Cache. Zusammen mit Out-of-Order Execution und spekulativer
Ausführung ergibt das eben Meltdown und Spectre.
Willst du sagen das der Match zwischen RPL und CPL von der CPU nicht
richtig nach außen kommuniziert wird und dadurch Code der falschen
Privilegstufe in der CPU zur ausführung gelangt - bis zur
Ergebniss-weitergabe an den Speicher? Und das evtl. sogar aus einer nur
vorhergesagten Ausführung die nicht mal gebraucht würde?

Was für ein Epic Fail. :(

Als ich das erste mal von dem Fehler las dachte ich das sei ein reines
Software-problem - weil einfach details fehlten und es hieß "alle seien
anfällig". Logisch oder?

Auch jetzt fällt es mir schwer zu glauben das so viele Architekturen
betroffen sind. Bei intel und AMD naheliegend weil im gleichen Segment
unterwegs. Aber ARM hat mir so grad wenig mit PC's zu tun. Wirkt als
hätte da jemand die Spekulation "ausspekuliert" und einer kupferte vom
anderen ab.

Kay
Hanno Foest
2018-01-05 18:41:58 UTC
Antworten
Permalink
Raw Message
Post by Kay Martinen
Willst du sagen das der Match zwischen RPL und CPL von der CPU nicht
richtig nach außen kommuniziert wird und dadurch Code der falschen
Privilegstufe in der CPU zur ausführung gelangt - bis zur
Ergebniss-weitergabe an den Speicher?
Nein, es wird lediglich abhängig vom Ergebnis Speicher gelesen. Aber das
bedeutet auch, daß diese Speicherinhalte gecachet werden. Wenn jetzt der
angreifende Prozeß selber noch mal auf die entsprechenden
Speicherstellen zugreift und dabei die Zugriffsgeschwindigkeit mißt,
bekommt er raus, welcher Speicherstellen gecachet waren. Abhilfe wäre
Cache oder speculative excecution abschalten, aber das möchte man aus
Performancegründen eher nicht.
Post by Kay Martinen
Auch jetzt fällt es mir schwer zu glauben das so viele Architekturen
betroffen sind. Bei intel und AMD naheliegend weil im gleichen Segment
unterwegs. Aber ARM hat mir so grad wenig mit PC's zu tun. Wirkt als
hätte da jemand die Spekulation "ausspekuliert" und einer kupferte vom
anderen ab.
Wenn man genug Silizium hat, um Befehle vorsorglich schon mal sozusagen
auf Vorrat auszuführen (und das auch möchte), dann wird man das
prinzipiell immer so machen.

Aber ob das eine gute Idee ist, darüber wird in der nächsten Zeit viel
diskutiert werden.

Hanno
Gerrit Heitsch
2018-01-05 20:09:00 UTC
Antworten
Permalink
Raw Message
Post by Hanno Foest
Aber ob das eine gute Idee ist, darüber wird in der nächsten Zeit viel
diskutiert werden.
Meltdown kann man recht einfach verhindern wenn man bereit ist etwas
Performance zu opfern und eben den Test auf 'darf ich das?' macht bevor
der Lesezugriff wirklich stattfindet.

Oder der andere Vorschlag, einfach den Adressraum hart aufteilen, Ist
das oberste Adressbit '1' und beim Zugriffsbit fehlt die Freigabe für
Zugriff auf Kernal krachts. Die Abfrage wäre einfach und schnell zu
implementieren und dürfte wenig bis keine Performance kosten. Dafür ist
es eben eine harte Aufteilung.

Ohne Designänderung wirds aber nicht gehen.

Gerrit
Kay Martinen
2018-01-05 20:31:21 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Post by Hanno Foest
Aber ob das eine gute Idee ist, darüber wird in der nächsten Zeit viel
diskutiert werden.
Fraglos.
Post by Gerrit Heitsch
Meltdown kann man recht einfach verhindern wenn man bereit ist etwas
Performance zu opfern und eben den Test auf 'darf ich das?' macht bevor
der Lesezugriff wirklich stattfindet.
Das CPUs hochkomplexe Gebilde sind unbenommen. Aber wie das passieren
konnte wäre auch mal interessant. Ich denke aber das werden wir nicht so
schnell erfahren. Aber die Hersteller sollten wirklich intern intensive
Ursachenforschung betreiben.
Post by Gerrit Heitsch
Oder der andere Vorschlag, einfach den Adressraum hart aufteilen, Ist
das oberste Adressbit '1' und beim Zugriffsbit fehlt die Freigabe für
Zugriff auf Kernal krachts. Die Abfrage wäre einfach und schnell zu
implementieren und dürfte wenig bis keine Performance kosten. Dafür ist
es eben eine harte Aufteilung.
Also z.B. Kernelspace oben, userspace unten, durch entsprechende
Segmentdescriptoren getrennt oder sprichst du von einer abfrage der
physischen Adresse (inkl. paging) ohne Segment-aufteilung (=FLAT, Ein
Segment für alles)
Post by Gerrit Heitsch
Ohne Designänderung wirds aber nicht gehen.
So wird's wohl sein. Abwarten und 'tee' denken (und 'fork' meinen :)

Kay
Gerrit Heitsch
2018-01-05 20:58:51 UTC
Antworten
Permalink
Raw Message
Post by Kay Martinen
Post by Gerrit Heitsch
Post by Hanno Foest
Aber ob das eine gute Idee ist, darüber wird in der nächsten Zeit viel
diskutiert werden.
Fraglos.
Post by Gerrit Heitsch
Meltdown kann man recht einfach verhindern wenn man bereit ist etwas
Performance zu opfern und eben den Test auf 'darf ich das?' macht bevor
der Lesezugriff wirklich stattfindet.
Das CPUs hochkomplexe Gebilde sind unbenommen. Aber wie das passieren
konnte wäre auch mal interessant. Ich denke aber das werden wir nicht so
schnell erfahren. Aber die Hersteller sollten wirklich intern intensive
Ursachenforschung betreiben.
Wie das passieren konnte? Einfachste Erklärung: Um die CPU kümmerte sich
Team A und um den Cache Team B. Team A baut das Out-of-Order-Feature ein
und erzählt Team B nichts davon (wozu auch?). Team B designt den Cache
incl. Controller. Beides landet auf dem Chip, hier und dort kommen
kleine Bugs noch, die werden berichtigt und das Resultat tut was es
soll. Hätte Austausch zwischen den Teams stattgefunden hätte man sich
vielleicht drüber unterhalten und jemandem wäre aufgefallen, daß der
Rollback bei einer Exception nur die CPU betrifft, aber nicht den Cache.

Bei Intel scheint es, nachdem was man so finden kann, eine interne
Kultur des Wettbewerbs zu geben. Das ist der Kommunikation zwischen den
Teams eher abträglich.

Das Problem kann man, damit wir hier wieder OT sind, durchaus mit dem
VIC aus dem C64 vergleichen. Der tut auch alles was er soll, kann aber
mehr wenn man das Timing der Schreibzugriffe auf seine Register korrekt
hinbekommt. Z.B. den Rahmen öffnen und so mit Hilfe der Sprites ein
Rahmenloses Bild erzeugen. Dinge die die Designer nie beabsichtigt hatten.
Post by Kay Martinen
Post by Gerrit Heitsch
Oder der andere Vorschlag, einfach den Adressraum hart aufteilen, Ist
das oberste Adressbit '1' und beim Zugriffsbit fehlt die Freigabe für
Zugriff auf Kernal krachts. Die Abfrage wäre einfach und schnell zu
implementieren und dürfte wenig bis keine Performance kosten. Dafür ist
es eben eine harte Aufteilung.
Also z.B. Kernelspace oben, userspace unten, durch entsprechende
Segmentdescriptoren getrennt oder sprichst du von einer abfrage der
physischen Adresse (inkl. paging) ohne Segment-aufteilung (=FLAT, Ein
Segment für alles)
Nix Segmente, den Spass will sich keiner mehr antun der es nicht
wirklich muss und es kostet Performance. Ich meine damit schon die
physikalische Adresse.

Gerrit
Gerrit Heitsch
2018-01-05 20:03:24 UTC
Antworten
Permalink
Raw Message
Post by Kay Martinen
Post by Gerrit Heitsch
Das aktuelle Problem liegt eher daran, daß die Auswertung des 'darf ich
das überhaupt?' erst NACH dem Zugriff passiert und wenn die Antwort
'nein!' ist ein Rollback passiert. Leider nur im Prozessorstatus, nicht
im Cache. Zusammen mit Out-of-Order Execution und spekulativer
Ausführung ergibt das eben Meltdown und Spectre.
Willst du sagen das der Match zwischen RPL und CPL von der CPU nicht
richtig nach außen kommuniziert wird und dadurch Code der falschen
Privilegstufe in der CPU zur ausführung gelangt - bis zur
Ergebniss-weitergabe an den Speicher?
Nein, es wird ein Speicherzugriff auf eigentlich geschützen Speicher
durchgeführt weil eben der Test auf 'darf ich das' nicht vorher
passiert. Aber es wird dabei kein Byte in den Speicher geschrieben, das
verhindert die CPU schon. Aber man kann, bis der Rollback kommt einen
weiteren Lesezugriff durchführen was den Cacheinhalt verändert (eine
vorher nicht im Cache befindliche Page ist nachher drin). Das wiederrum
kann man testen und somit die Daten die man nicht haben sollte
extrahieren. Du brauchst dafür nur 256 * 4096 Bytes, das 'geklaute' Byte
wird zu einem Index für den Lesezugriff der den Cache beeinflusst. Zur
Extraktion schaut man dann nach welche der 256 Pages jetzt im Cache ist
(Über Timing, gecachtes wird schneller gelesen). Kennt man die
Page-Nummer, kennt man das Byte.

Lies es dir mal durch, ist eine ziemlich geniale Idee wie man 1 Byte da
durchmogelt. Mit allen Tricks kann man so 500KB/sec aus dem Kernel
extrahieren. Fehlerquote ist wohl so 0,02%.
Post by Kay Martinen
Auch jetzt fällt es mir schwer zu glauben das so viele Architekturen
betroffen sind. Bei intel und AMD naheliegend weil im gleichen Segment
unterwegs. Aber ARM hat mir so grad wenig mit PC's zu tun. Wirkt als
hätte da jemand die Spekulation "ausspekuliert" und einer kupferte vom
anderen ab.
Meltdown ist rein INTeL, erklärt vielleicht warum sie immer schneller
waren als AMD. Letztere sind nicht anfällig, die scheinen vorher zu
testen, oder zumindest früh genug, daß es bisher keiner geschafft hat
einen Exploit zu schreiben.

Gerrit
Andreas Kohlbach
2018-01-05 21:00:35 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Post by Kay Martinen
Post by Gerrit Heitsch
Das aktuelle Problem liegt eher daran, daß die Auswertung des 'darf ich
das überhaupt?' erst NACH dem Zugriff passiert und wenn die Antwort
'nein!' ist ein Rollback passiert. Leider nur im Prozessorstatus, nicht
im Cache. Zusammen mit Out-of-Order Execution und spekulativer
Ausführung ergibt das eben Meltdown und Spectre.
Willst du sagen das der Match zwischen RPL und CPL von der CPU nicht
richtig nach außen kommuniziert wird und dadurch Code der falschen
Privilegstufe in der CPU zur ausführung gelangt - bis zur
Ergebniss-weitergabe an den Speicher?
Nein, es wird ein Speicherzugriff auf eigentlich geschützen Speicher
durchgeführt weil eben der Test auf 'darf ich das' nicht vorher
passiert. Aber es wird dabei kein Byte in den Speicher geschrieben,
das verhindert die CPU schon. Aber man kann, bis der Rollback kommt
einen weiteren Lesezugriff durchführen was den Cacheinhalt verändert
(eine vorher nicht im Cache befindliche Page ist nachher drin). Das
wiederrum kann man testen und somit die Daten die man nicht haben
sollte extrahieren.
Kommt nicht eine Zeitkomponente hinzu? Man kommt auch nicht an den Cache
heran. Kann aber testen, wie schnell eine Reihe von Zahlen, sagen wir ein
Array von 1..16, zurück kommt. Wenn langsamer, war sie nicht im Cache.
--
Andreas
You know you are a redneck if
your school fight song was "dueling banjos".
Gerrit Heitsch
2018-01-05 21:02:57 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Post by Gerrit Heitsch
Post by Kay Martinen
Post by Gerrit Heitsch
Das aktuelle Problem liegt eher daran, daß die Auswertung des 'darf ich
das überhaupt?' erst NACH dem Zugriff passiert und wenn die Antwort
'nein!' ist ein Rollback passiert. Leider nur im Prozessorstatus, nicht
im Cache. Zusammen mit Out-of-Order Execution und spekulativer
Ausführung ergibt das eben Meltdown und Spectre.
Willst du sagen das der Match zwischen RPL und CPL von der CPU nicht
richtig nach außen kommuniziert wird und dadurch Code der falschen
Privilegstufe in der CPU zur ausführung gelangt - bis zur
Ergebniss-weitergabe an den Speicher?
Nein, es wird ein Speicherzugriff auf eigentlich geschützen Speicher
durchgeführt weil eben der Test auf 'darf ich das' nicht vorher
passiert. Aber es wird dabei kein Byte in den Speicher geschrieben,
das verhindert die CPU schon. Aber man kann, bis der Rollback kommt
einen weiteren Lesezugriff durchführen was den Cacheinhalt verändert
(eine vorher nicht im Cache befindliche Page ist nachher drin). Das
wiederrum kann man testen und somit die Daten die man nicht haben
sollte extrahieren.
Kommt nicht eine Zeitkomponente hinzu? Man kommt auch nicht an den Cache
heran. Kann aber testen, wie schnell eine Reihe von Zahlen, sagen wir ein
Array von 1..16, zurück kommt. Wenn langsamer, war sie nicht im Cache.
Ja, eben, man testet über die Zugriffszeit. Da man nicht alleine auf der
CPU ist kann das auch mal nicht klappen, aber es scheint sehr
zuverlässig zu funktionieren. Es reicht 1 Zugriff pro Page da das reicht
um die komplette Page in den Cache zu holen.

Gerrit
Ralf Kiefer
2018-01-06 01:41:55 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Nein, es wird ein Speicherzugriff auf eigentlich geschützen Speicher
durchgeführt weil eben der Test auf 'darf ich das' nicht vorher
passiert.
Ich habe meine Probleme das in der Intel-Architektur genau zu verstehen,
weil ich mit anderen sozialisiert wurde :-)

Beim 680x0 mit MMU als Speicherschutz sitzt die MMU zwischen CPU und
Cache. Beim Kontextwechsel erhält die MMU einen Satz anderer
Tabelleneinträge zugewiesen, womit anschließend die neuen Rechte
(entweder kein Zugriff, R oder R/W pro Kachel) gültig sind. Das erschien
mir immer und heute erst recht als zwingend logisch, da so die Caches
denselben Zugriffsregeln unterliegen wie das RAM weiter draußen. Wenn
eine 68060-CPU irgendwas in den Pipelines hat, dann werden diese Inhalte
mit einem Kontextwechsel nicht "exportiert".

Wenn das die Intel-Welt anders macht, dann ist das wohl der Epic Fail,
der gerade ans Tageslicht gekommen ist. Da stelle ich mir die nächste
Frage, warum das erst jetzt nach Jahrzehnten auffällt. Da sind mehrere
Generationen Kernel-Hacker dran vorbeigekommen und haben damit ihre
Scheduler und ihren Speicherschutz gebaut. Oder haben die in der
Anfangszeit, als es nur L1-Cache gab, diesen beim Kontextwechsel einfach
für vollständig ungültig erklärt und auf diese Weise den Speicherschutz
gewährleistet, was sich mit fortschreitenden Cache-Größen und weiteren
Cache-Instanzen als Bremse rausstellte?

Dann bekamen die CPUs mehrere Kerne mit einem gemeinsamen L2- oder
L3-Cache. Wo hat Intel die Aufgabe des Speicherschutzes eingebaut bzw.
nicht eingebaut? Eine Schad-Software, die diese "aktuellen" Lücken
ausnutzt, kann eigentlich(?) nicht feststellen, aus welchem Cache sie
die fremden Daten liest. Denn ein zweiter, benachbarter Kern könnte
gleichzeitig eine Kachel (berechtigt) in seinem L1-Cache bearbeiten, die
der erste Kern aufgrund des Fehlers aus dem L3-Cache in seiner
vorherigen Form lesen kann, d.h. in seinem L1-Cache erhält.
Post by Gerrit Heitsch
Lies es dir mal durch, ist eine ziemlich geniale Idee wie man 1 Byte da
durchmogelt. Mit allen Tricks kann man so 500KB/sec aus dem Kernel
extrahieren. Fehlerquote ist wohl so 0,02%.
Hast Du eine Quelle, die das in verständlicher Form erklärt? Die
üblichen Heise-, Golem- und sonstwas-Artikel bleiben recht
oberflächlich. Und Intel traue ich nicht zu, daß die ihr Problem leicht
verständlich darstellen wollen.


Gruß, Ralf
Ralf Kiefer
2018-01-06 02:21:24 UTC
Antworten
Permalink
Raw Message
Post by Ralf Kiefer
Hast Du eine Quelle, die das in verständlicher Form erklärt?
Gefunden :-)

https://heise.de/-3935124
Autor: Andras Stiller, wer sonst :-)

Gruß, Ralf
Gerrit Heitsch
2018-01-06 06:28:53 UTC
Antworten
Permalink
Raw Message
Post by Ralf Kiefer
Post by Ralf Kiefer
Hast Du eine Quelle, die das in verständlicher Form erklärt?
Gefunden :-)
https://heise.de/-3935124
Autor: Andras Stiller, wer sonst :-)
Ich fand er mixed Meltdown und Spectre... Deshalb finde ich die PDFs besser.

Gerrit
Goetz Hoffart
2018-01-06 02:50:30 UTC
Antworten
Permalink
Raw Message
Da stelle ich mir die nächste Frage, warum das erst jetzt nach Jahrzehnten
auffällt.
Tut es doch gar nicht.

https://marc.info/?l=openbsd-misc&m=118296441702631&w=2

Theo de Raadt:

»Various developers are busy implimenting workarounds for serious bugs
in Intel's Core 2 cpu.

These processors are buggy as hell, and some of these bugs don't just
cause development/debugging problems, but will *ASSUREDLY* be
exploitable from userland code.«

Grüße
Götz
--
http://www.knubbelmac.de/
Ralf Kiefer
2018-01-06 03:12:52 UTC
Antworten
Permalink
Raw Message
Post by Goetz Hoffart
»Various developers are busy implimenting workarounds for serious bugs
in Intel's Core 2 cpu.
These processors are buggy as hell, and some of these bugs don't just
cause development/debugging problems, but will *ASSUREDLY* be
exploitable from userland code.«
Dazu:
"At this time, I cannot recommend purchase of any machines based on the
Intel Core 2 until these issues are dealt with (which I suspect will
take more than a year)."
2007-06-27 17:08:16 in der OpenBSD-Welt.

Wie kaputt ist das denn? M$ hat nichts mitbekommen, Apple hat nichts
mitbekommen, der größte Teil der Linux-Welt weiß 10Jahre lang genauso
wenig. Irgendwas stinkt ein bißchen. Findet sich nicht ggf. was in den
Snowden-Unterlagen zu diesem Thema? Wundern würde es mich nicht.

Gruß, Ralf
Gerrit Heitsch
2018-01-06 06:36:08 UTC
Antworten
Permalink
Raw Message
Post by Ralf Kiefer
Post by Goetz Hoffart
»Various developers are busy implimenting workarounds for serious bugs
in Intel's Core 2 cpu.
These processors are buggy as hell, and some of these bugs don't just
cause development/debugging problems, but will *ASSUREDLY* be
exploitable from userland code.«
"At this time, I cannot recommend purchase of any machines based on the
Intel Core 2 until these issues are dealt with (which I suspect will
take more than a year)."
2007-06-27 17:08:16 in der OpenBSD-Welt.
Wie kaputt ist das denn? M$ hat nichts mitbekommen, Apple hat nichts
mitbekommen, der größte Teil der Linux-Welt weiß 10Jahre lang genauso
wenig. Irgendwas stinkt ein bißchen. Findet sich nicht ggf. was in den
Snowden-Unterlagen zu diesem Thema? Wundern würde es mich nicht.
Wobei weder Meltdown oder Spectre auch nur ansatzweise beschrieben wird.
Es wird nur ziemlich allgemein im Bezug auf die Bugs in den Core 2 CPUs
eingegangen und die Liste auf

Loading Image...

ist auch ziemlich lang.

BTW: MacOS benutzt das Verfahren, was MS und Linux jetzt erst
implementieren schon länger, deshalb war es auch immer etwas langsamer
als Windows. Hilft gegen Meltdown, aber nicht gegen Spectre.

Gerrit
Hanno Foest
2018-01-06 13:32:18 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Wobei weder Meltdown oder Spectre auch nur ansatzweise beschrieben wird.
Es wird nur ziemlich allgemein im Bezug auf die Bugs in den Core 2 CPUs
eingegangen und die Liste auf
https://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif
ist auch ziemlich lang.
Wenn Theo hätte konkret werden können, wäre der Kram ja gefixt worden.
Ich halte es durchaus für eine Leistung, Exploits bestimmter Kategorien
vorherzusehen, auch wenn die konkrete Ausführung derzeit noch zu komplex
ist - wobei letzteres im Kapitalismus natürlich dazu führt, daß der
Verursacher deren Relevanz abstreitet.

Leider kann ich nicht nachlesen, was die genannten Errata genau sagen,
denn der genannte Link zu den Intel Errata ist tot.

Hanno
Gerrit Heitsch
2018-01-06 14:05:43 UTC
Antworten
Permalink
Raw Message
Post by Hanno Foest
Post by Gerrit Heitsch
Wobei weder Meltdown oder Spectre auch nur ansatzweise beschrieben
wird. Es wird nur ziemlich allgemein im Bezug auf die Bugs in den Core
2 CPUs eingegangen und die Liste auf
https://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif
ist auch ziemlich lang.
Wenn Theo hätte konkret werden können, wäre der Kram ja gefixt worden.
Ich halte es durchaus für eine Leistung, Exploits bestimmter Kategorien
vorherzusehen, auch wenn die konkrete Ausführung derzeit noch zu komplex
ist - wobei letzteres im Kapitalismus natürlich dazu führt, daß der
Verursacher deren Relevanz abstreitet.
Ja, zumindest bis ein ready-to-use Exploit verfürbar ist. Dann wird
gehandelt. Ist aber auch an anderen Stellen so. Siehe S21... Bisher sind
eigentlich alle Warnungen der Gegnger eingetroffen, trotzdem wurden sie
ignoriert.

Gerrit
Andreas Kohlbach
2018-01-06 18:35:14 UTC
Antworten
Permalink
Raw Message
Post by Ralf Kiefer
Post by Goetz Hoffart
These processors are buggy as hell, and some of these bugs don't just
cause development/debugging problems, but will *ASSUREDLY* be
exploitable from userland code.«
"At this time, I cannot recommend purchase of any machines based on the
Intel Core 2 until these issues are dealt with (which I suspect will
take more than a year)."
2007-06-27 17:08:16 in der OpenBSD-Welt.
Ja, erst mal die Regale abverkaufen. Hatte IIRC schon Microsoft mit (war
es?) Vista gemacht, als praktisch jede Version beim Online-Gehen sich
sofort mit einem Virus infizierte.

Da Intel angeblich am 9. Januar von sich aus den Bug veröffentlichen
wollte, dürfte man bereits den Blueprint für eine CPU haben, die den Bug
nicht mehr hat, die auch schon in der Produktion sein wird.
--
Andreas
You know you are a redneck if
your school fight song was "dueling banjos".
Gerrit Heitsch
2018-01-06 18:47:03 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Post by Ralf Kiefer
Post by Goetz Hoffart
These processors are buggy as hell, and some of these bugs don't just
cause development/debugging problems, but will *ASSUREDLY* be
exploitable from userland code.«
"At this time, I cannot recommend purchase of any machines based on the
Intel Core 2 until these issues are dealt with (which I suspect will
take more than a year)."
2007-06-27 17:08:16 in der OpenBSD-Welt.
Ja, erst mal die Regale abverkaufen. Hatte IIRC schon Microsoft mit (war
es?) Vista gemacht, als praktisch jede Version beim Online-Gehen sich
sofort mit einem Virus infizierte.
Da Intel angeblich am 9. Januar von sich aus den Bug veröffentlichen
wollte, dürfte man bereits den Blueprint für eine CPU haben, die den Bug
nicht mehr hat, die auch schon in der Produktion sein wird.
So schnell geht ein Redesign bei einem solch komplexen Chip nicht. Wenn
überhaupt wird es einen Fix erst in der nächsten Generation geben die
irgendwann Ende 2018 erscheint.

Und ob der Fix ohne Performanceeinbußen machbar ist wird man auch noch
sehen. Kann durchaus sein, daß die CPU mit dem Fix langsamer ist als die
ohne. Meltdown betrifft nur INTeL, vielleicht ein Grund warum ihre CPUs
immer schneller waren als die von AMD? :)

Gerrit
Gerrit Heitsch
2018-01-06 06:27:22 UTC
Antworten
Permalink
Raw Message
Post by Ralf Kiefer
Post by Gerrit Heitsch
Nein, es wird ein Speicherzugriff auf eigentlich geschützen Speicher
durchgeführt weil eben der Test auf 'darf ich das' nicht vorher
passiert.
Ich habe meine Probleme das in der Intel-Architektur genau zu verstehen,
weil ich mit anderen sozialisiert wurde :-)
Beim 680x0 mit MMU als Speicherschutz sitzt die MMU zwischen CPU und
Cache. Beim Kontextwechsel erhält die MMU einen Satz anderer
Tabelleneinträge zugewiesen, womit anschließend die neuen Rechte
(entweder kein Zugriff, R oder R/W pro Kachel) gültig sind. Das erschien
mir immer und heute erst recht als zwingend logisch, da so die Caches
denselben Zugriffsregeln unterliegen wie das RAM weiter draußen. Wenn
eine 68060-CPU irgendwas in den Pipelines hat, dann werden diese Inhalte
mit einem Kontextwechsel nicht "exportiert".
Wenn das die Intel-Welt anders macht, dann ist das wohl der Epic Fail,
der gerade ans Tageslicht gekommen ist.
Das ist eben die Nebenwirkung von Out-of-Order und spekulativer
Ausführung. Bringt gut Performance, deshalb macht man es.

Mein Netbook mit Atom N270 ist nicht betroffen, der führt brav jeden
Befehl einzeln aus. Deshalb ist er auch 'etwas' langsamer.
Post by Ralf Kiefer
Dann bekamen die CPUs mehrere Kerne mit einem gemeinsamen L2- oder
L3-Cache. Wo hat Intel die Aufgabe des Speicherschutzes eingebaut bzw.
nicht eingebaut? Eine Schad-Software, die diese "aktuellen" Lücken
ausnutzt, kann eigentlich(?) nicht feststellen, aus welchem Cache sie
die fremden Daten liest. Denn ein zweiter, benachbarter Kern könnte
gleichzeitig eine Kachel (berechtigt) in seinem L1-Cache bearbeiten, die
der erste Kern aufgrund des Fehlers aus dem L3-Cache in seiner
vorherigen Form lesen kann, d.h. in seinem L1-Cache erhält.
Deshalb funktioniert der Angriff auch nicht 100% zuverlässig.
Post by Ralf Kiefer
Post by Gerrit Heitsch
Lies es dir mal durch, ist eine ziemlich geniale Idee wie man 1 Byte da
durchmogelt. Mit allen Tricks kann man so 500KB/sec aus dem Kernel
extrahieren. Fehlerquote ist wohl so 0,02%.
Hast Du eine Quelle, die das in verständlicher Form erklärt? Die
üblichen Heise-, Golem- und sonstwas-Artikel bleiben recht
oberflächlich. Und Intel traue ich nicht zu, daß die ihr Problem leicht
verständlich darstellen wollen.
Hier sind die Orginal-Papiere zum Thema:

https://meltdownattack.com/meltdown.pdf
https://spectreattack.com/spectre.pdf

Ich hab ein bisschen gebraucht bis ich es kapiert habe und bei Spectre
ist es noch komplexer.

Gerrit
Stefan Reuther
2018-01-06 12:04:42 UTC
Antworten
Permalink
Raw Message
Post by Kay Martinen
AFAIR war bei den frühen CPUs (i286?) die Granularity kleiner. Aber;
ebenfalls AFAIR; ab dem i386 oder später waren damit bis zu 4 GB Große
Segmente möglich, egal ob für Daten oder Code (oder Stack/ES, FS?)
Und wäre man nicht in die Flatmem-Richtung gegangen hätte es vielleicht
heute statt NX u.a. weitere CPU-Features gegeben. Denkbar wäre doch 4TB
Große Segmente mit feinerer Granularity oder variabler größe, weiteres
aufmotzen der x86vm in richtung hypervisor...
Essentiell sind m.E. immer noch die eine GDT und über LDT's sind bis ca.
8000 Segmente möglich. Mit obigen verbesserungen... hat man echt
maschinen bei denen über 8000 Prozesse laufen?
Mit Segmenten alleine bekommst du Dinge wie 'mmap' oder 'fork' nicht
sinnvoll hin.

Ein Segment beschreibt ja nur einen zusammenhängenden Teil linearen
Speichers. Will ich das Segment vergrößern, muss ich den
dahinterliegenden Speicher freischaufeln und dazu Speicher kopieren. Das
ist halt aufwändig.

Windows im Standard Mode hat sowas gemacht, aber das hat weder mit
Gigabytes an RAM jongliert, noch war es für überragende Performance berühmt.

Das einzige Feature, das (i386-) Segmente haben und (i386-) Pages nicht,
war die Steuerung, ob Code ausgeführt werden darf. Das ist jetzt eher
eine Macke der i386-Variante, aber keine Macke des Konzepts "Paging" an
sich.
Post by Kay Martinen
Post by Gerrit Heitsch
Das aktuelle Problem liegt eher daran, daß die Auswertung des 'darf ich
das überhaupt?' erst NACH dem Zugriff passiert und wenn die Antwort
'nein!' ist ein Rollback passiert. Leider nur im Prozessorstatus, nicht
im Cache. Zusammen mit Out-of-Order Execution und spekulativer
Ausführung ergibt das eben Meltdown und Spectre.
Willst du sagen das der Match zwischen RPL und CPL von der CPU nicht
richtig nach außen kommuniziert wird und dadurch Code der falschen
Privilegstufe in der CPU zur ausführung gelangt - bis zur
Ergebniss-weitergabe an den Speicher? Und das evtl. sogar aus einer nur
vorhergesagten Ausführung die nicht mal gebraucht würde?
Was für ein Epic Fail. :(
Die Annahme ist, dass Lesen von Speicher keine Nebenwirkungen hat. Diese
Annahme trifft sehr häufig zu.

Mir schwebt ja da im Hinterkopf noch der Begriff "MTRR" rum: Memory Type
Range Registers, mit denen man einstellt, bei welchem Speicher Lesen
eben gerade *doch* Nebenwirkungen hat.

Epic Fail darf das nennen, wer die Probleme vorhergesehen hätte. Ich nicht.

Ich hab ja durchaus auch schon gemeinsam mit einem CPU-Hersteller
gelernt, dass da in dem Chip noch ein Write-Buffer verbaut ist, den der
Hersteller für so unwichtig gehalten hat, dass er ihn in
Blockschaltbildern weggelassen hat und erst nach wochenlanger Suche
gefunden hat. Aber wenn der beim Zugriff auf bankswitched memory den
Zugriff auf das Bankregister und die Speicherbank vertauscht ist halt
doof... Aber einen Seitenkanalangriff auf den Cache zu Produktionsreife
bringen? Das ist dann doch eine Menge Holz...


Stefan
Gerrit Heitsch
2018-01-06 14:10:54 UTC
Antworten
Permalink
Raw Message
Post by Stefan Reuther
Post by Kay Martinen
Was für ein Epic Fail. :(
Die Annahme ist, dass Lesen von Speicher keine Nebenwirkungen hat. Diese
Annahme trifft sehr häufig zu.
Wenn man keinen Cache benutzt, ja (*). Sobald Cache im Spiel ist gilt
das eben nicht mehr. Alleine die Tatsache, ob eine bestimmte Page im
Cache ist oder nicht ist schon 1 Bit Information. Meltdown erhöht die
Bandbreite dieses Nebenkanals (**) nur etwas.

(*) Es gibt I/O-Controller bei denen das reine Lesen eines
Statusregisters den internen Zustand ändert.

(**) Side effect = Nebenwirkung, also Side channel = Nebenkanal
Post by Stefan Reuther
Ich hab ja durchaus auch schon gemeinsam mit einem CPU-Hersteller
gelernt, dass da in dem Chip noch ein Write-Buffer verbaut ist, den der
Hersteller für so unwichtig gehalten hat, dass er ihn in
Blockschaltbildern weggelassen hat und erst nach wochenlanger Suche
gefunden hat. Aber wenn der beim Zugriff auf bankswitched memory den
Zugriff auf das Bankregister und die Speicherbank vertauscht ist halt
doof...
Dann stimmt aber bei der Implementation was nicht, wenn auch mit Puffer
sollten die Zugriffe in der richtigen Reihenfolge passieren.

Gerrit
Stefan Reuther
2018-01-06 14:58:39 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Post by Stefan Reuther
Post by Kay Martinen
Was für ein Epic Fail. :(
Die Annahme ist, dass Lesen von Speicher keine Nebenwirkungen hat. Diese
Annahme trifft sehr häufig zu.
Wenn man keinen Cache benutzt, ja (*). Sobald Cache im Spiel ist gilt
das eben nicht mehr. Alleine die Tatsache, ob eine bestimmte Page im
Cache ist oder nicht ist schon 1 Bit Information.
Das gilt genau dann, wenn diese Information auslesbar ist. Nimm dem
Angreifer die Möglichkeit, zyklengenau Zeiten zu messen, und das Leck
ist geschlossen. (Die Zeitmessung dann über außenstehende Systeme zu
machen, z.B. Ping-Zeiten, dürfte die Genauigkeit so stark reduzieren
sprich: so viele Messungen benötigen, dass der Angriff unpraktikabel wird.)

Ich würde mal annehmen, wenn Dinge wie "Stromaufnahme" messbar wären,
wäre auch das ein Nebenkanal (a la "Stromaufnahme korelliert mit der
Anzahl der Einsbits auf dem Adressbus -> ASLR ausgehebelt").

Wir haben jede Menge solcher Nebenkanäle in unserer Infrastruktur.
Dummes Beispiel: natürlich verbietet mir das Betriebssystem, in die
Innereien des Updaters zu schauen, aber wenn ich die Festplatte rattern
höre und die LAN-Lampe blinken sehe (vom 'netstat' mal zu schweigen)
weiß ich ziemlich genau, was der gerade tut.
Post by Gerrit Heitsch
(*) Es gibt I/O-Controller bei denen das reine Lesen eines
Statusregisters den internen Zustand ändert.
Deswegen "sehr häufig", nicht "immer".
Post by Gerrit Heitsch
Post by Stefan Reuther
Ich hab ja durchaus auch schon gemeinsam mit einem CPU-Hersteller
gelernt, dass da in dem Chip noch ein Write-Buffer verbaut ist, den der
Hersteller für so unwichtig gehalten hat, dass er ihn in
Blockschaltbildern weggelassen hat und erst nach wochenlanger Suche
gefunden hat. Aber wenn der beim Zugriff auf bankswitched memory den
Zugriff auf das Bankregister und die Speicherbank vertauscht ist halt
doof...
Dann stimmt aber bei der Implementation was nicht, wenn auch mit Puffer
sollten die Zugriffe in der richtigen Reihenfolge passieren.
Im konkreten Fall wurden die Zugriffe vor dem Puffer auf Speicherbänke
aufgeteilt. Jeder SDRAM tut das genauso.


Stefan
Gerrit Heitsch
2018-01-06 15:30:21 UTC
Antworten
Permalink
Raw Message
Post by Stefan Reuther
Post by Gerrit Heitsch
Post by Stefan Reuther
Post by Kay Martinen
Was für ein Epic Fail. :(
Die Annahme ist, dass Lesen von Speicher keine Nebenwirkungen hat. Diese
Annahme trifft sehr häufig zu.
Wenn man keinen Cache benutzt, ja (*). Sobald Cache im Spiel ist gilt
das eben nicht mehr. Alleine die Tatsache, ob eine bestimmte Page im
Cache ist oder nicht ist schon 1 Bit Information.
Das gilt genau dann, wenn diese Information auslesbar ist. Nimm dem
Angreifer die Möglichkeit, zyklengenau Zeiten zu messen, und das Leck
ist geschlossen.
Das wird gar nicht so einfach, immer wenn man meint, man hätte das Loch
geschlossen kommt jemand und findet ein neues. Es wird dann sicher
langsamer, aber solange man auch nur ein paar Byte / sec extrahieren
kann lohnt es sich weiterhin.

Leider sind diese präzisen Timer für andere Zwecke durchaus nützlich,
deshalb hat die CPU sie ja. In der Javascript-Engine eines Browsers
braucht man sowas hingegen nicht, deshalb gibt man sich dort gerade Mühe
die Genauigkeit des Timers runterzusetzen. Erste Umgehung war in einem
weiteren Script einfach eine Variable zu inkrementieren und die über
SharedArrayBuffer zugänglich zu machen. War anscheinend für Spectre
ausreichend genau. Deshalb flog diese Funktion jetzt erstmal raus.
Post by Stefan Reuther
Ich würde mal annehmen, wenn Dinge wie "Stromaufnahme" messbar wären,
wäre auch das ein Nebenkanal (a la "Stromaufnahme korelliert mit der
Anzahl der Einsbits auf dem Adressbus -> ASLR ausgehebelt").
Abhilfe dagegen geht nur in Hardware... Jeden Bus doppelt, einmal
normal, einmal invertiert.
Post by Stefan Reuther
Wir haben jede Menge solcher Nebenkanäle in unserer Infrastruktur.
Dummes Beispiel: natürlich verbietet mir das Betriebssystem, in die
Innereien des Updaters zu schauen, aber wenn ich die Festplatte rattern
höre und die LAN-Lampe blinken sehe (vom 'netstat' mal zu schweigen)
weiß ich ziemlich genau, was der gerade tut.
Aus diesem Grunde mag ich Festplatten und deren LEDs, man kann erkennen,
das da was passiert. Mit SSD und ohne LED kann der Rechner viel leichter
Dinge unbemerkt im Hintergrund erledigen.
Post by Stefan Reuther
Post by Gerrit Heitsch
Post by Stefan Reuther
Ich hab ja durchaus auch schon gemeinsam mit einem CPU-Hersteller
gelernt, dass da in dem Chip noch ein Write-Buffer verbaut ist, den der
Hersteller für so unwichtig gehalten hat, dass er ihn in
Blockschaltbildern weggelassen hat und erst nach wochenlanger Suche
gefunden hat. Aber wenn der beim Zugriff auf bankswitched memory den
Zugriff auf das Bankregister und die Speicherbank vertauscht ist halt
doof...
Dann stimmt aber bei der Implementation was nicht, wenn auch mit Puffer
sollten die Zugriffe in der richtigen Reihenfolge passieren.
Im konkreten Fall wurden die Zugriffe vor dem Puffer auf Speicherbänke
aufgeteilt. Jeder SDRAM tut das genauso.
War aber anscheinend nicht dokumentiert und damit ist es ein Fehler.

Gerrit
Volker Borchert
2018-01-06 18:10:01 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Post by Stefan Reuther
Ich würde mal annehmen, wenn Dinge wie "Stromaufnahme" messbar wären,
wäre auch das ein Nebenkanal (a la "Stromaufnahme korelliert mit der
Anzahl der Einsbits auf dem Adressbus -> ASLR ausgehebelt").
Abhilfe dagegen geht nur in Hardware... Jeden Bus doppelt, einmal
normal, einmal invertiert.
Einfach ECL statt MOS verwenden ;-)
--
"I'm a doctor, not a mechanic." Dr Leonard McCoy <***@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <***@despammed.com>
Ralf Kiefer
2018-01-06 15:01:45 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Wenn man keinen Cache benutzt, ja (*).
[...]
(*) Es gibt I/O-Controller bei denen das reine Lesen eines
Statusregisters den internen Zustand ändert.
Weswegen dem Cache-Controller und ggf. der MMU diese Speicherbereiche
mitgeteilt werden, so daß dort alle Zugriffe auf diese Adressen in der
exakten Reihenfolge, nicht out-of-order, und raus auf den Bus gehen. Das
betrifft nicht ausschließlich IO-Chips, sondern kann auch
Multi-Ported-RAM betreffen, insbesondere wenn der oder die
Cache-Controller nicht am Bus lauschen, um Inkonsistenzen zwischen
externem Speicher und Cache-Inhalt bemerken können.

Deswegen stellt man bei Bedarf im Betriebssystem in der
Hardware-Beschreibung ein, welche Speicherbereiche am Cache vorbei gehen
oder welche Bereiche in strikter Reihenfolge zu behandeln sind, oder
beides.

Gruß, Ralf
Hermann Riemann
2018-01-06 14:12:28 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Auf der anderen Seite ist es gut, daß die idiotische Segmentierung tot
ist. Das war ein Überbleibsel der Anfangszeit als man den Trick brauchte
um mehr als 64KB adressieren zu können.
Ja, schon. Nur damit waren ja bis zu 1MB RAM adressierbar.
Nein.
Bei meinen Z80 habe ich auch mehr al 64k adressiert
indem ich Bits vom Z80 PIO als zusätzliche Adressbits
in Teilen des Speicherraums verwendete.

Hermann
der vermutet, dass derartiges bei MMU und cache
allerdings Probleme bereitet.
--
http://www.hermann-riemann.de
Andreas Kohlbach
2018-01-05 20:50:08 UTC
Antworten
Permalink
Raw Message
Post by Kay Martinen
Post by Andreas Kohlbach
Heute, aber auch schon ab 1979, als es MP/M (Concurrent OS) gab, hätte
man sich den teuren Puffer sparen können. Weil concurrent (Multitasking)
es erlaubt, weiter zu arbeiten, während man die Druckdaten gleichzeitig
direkt vom PC zum Drucker schickt.
Ja, möglichkeiten wie diese gab es. Aber kaum für Heimanwender tragbare.
Da war ein Buffer auch eine Teure Investition. Wenn es also nicht per
Software ging musste man halt warten. Und die Drucker damals waren teils
kaum schneller als eine 50Baud Fernschreibmaschine.
Ich erinnere einen Seikoska SL-IP 80 den ich mir vor jahren ein fing.
Gemächliches Gerät für einen Nadler.
Weder Puffer noch Multitasking war damals für den Heimanwender
gedacht. Wir waren es gewohnt zu warten. Aber im Büro war es schlecht und
teuer (der Kollege arbeitet in der Zeit nicht), wenn der Drucker den PC
blockiert. Hier hätte man auf MP/M upgraden können, wenn man schon CP/M
vorher laufen hatte.

Btw. gab es vor Windows 3.11 MS-DOS, was multitaskingfähig war?
--
Andreas
You know you are a redneck if
your school fight song was "dueling banjos".
Kay Martinen
2018-01-05 21:21:25 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Post by Kay Martinen
Post by Andreas Kohlbach
Heute, aber auch schon ab 1979, als es MP/M (Concurrent OS) gab, hätte
man sich den teuren Puffer sparen können. Weil concurrent (Multitasking)
es erlaubt, weiter zu arbeiten, während man die Druckdaten gleichzeitig
direkt vom PC zum Drucker schickt.
Ja, möglichkeiten wie diese gab es. Aber kaum für Heimanwender tragbare.
Da war ein Buffer auch eine Teure Investition. Wenn es also nicht per
Software ging musste man halt warten. Und die Drucker damals waren teils
kaum schneller als eine 50Baud Fernschreibmaschine.
Ich erinnere einen Seikoska SL-IP 80 den ich mir vor jahren ein fing.
Gemächliches Gerät für einen Nadler.
Weder Puffer noch Multitasking war damals für den Heimanwender
gedacht. Wir waren es gewohnt zu warten.
Mein Reden.
Post by Andreas Kohlbach
Aber im Büro war es schlecht und
teuer (der Kollege arbeitet in der Zeit nicht), wenn der Drucker den PC
blockiert.
In einem Büro, okay.

Kaufmännische Betrachtung: Wie lange wartet der durchschnittlich und wie
oft = TotalCostofBusytime versus Preis für einen Spooler...
Post by Andreas Kohlbach
Hier hätte man auf MP/M upgraden können, wenn man schon CP/M
vorher laufen hatte.
... oder preis des Upgrades.
Post by Andreas Kohlbach
Btw. gab es vor Windows 3.11 MS-DOS, was multitaskingfähig war?
Ja. Desqview (laut U.L vom Stab von "Apocalypse now" zusammen
geklöppelt) oder GEOS und Novell DOS 7 konnten es zum teil auch.
Das müßte so in der Ära von Win 3.x gewesen sein.

BTW. Der HW-Spooler den ich hier hab saß früher im Büro meines Vaters
zwischen einem Lauten FACIT Nageldrucker und einem IBM-PC, IMHO ein PS/2
Model 80 mit MS Xenix drauf. Das konnte doch sicher auch per Software
spoolen oder?

Jedenfalls hingen dort noch ein Bandlaufwerk und 2 Terminals dran. Und
ein PESTmodem als Uplink zur Zentrale (für updates und Terminaldienste)

Kay
Ralf Kiefer
2018-01-06 01:41:53 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Btw. gab es vor Windows 3.11 MS-DOS, was multitaskingfähig war?
Ich saß so um 1986/1987 herum in einem Job vor einem Concurrent
CP/M-Gerät, AFAIR was von Siemens mit einem 80188: vier parallel
laufende Konsolen per Tastaturumschaltung zu "bändigen".

Ansonsten gab es ziemlich viele Multitasking-Betriebssysteme. Z.B. alles
mit *nix auf unterschiedlichsten CPUs von Sun, Apollo, Apple, HP,
Cadmus, Siemens, usw., die PDP-11 und Artverwandte samt ihrem "Zoo" an
Betriebssystemen, die AS/400-Welt, das Macintosh-System, AmigaOS, die
verschiedenen OS-9-Varianten, VxWorks und anderes aus der Echtzeitecke.
Usw.

Der Home-Computer-Bereich mit MS-DOS und Windows war nur eine bekannte
Ecke, aber es gab erheblich mehr (und Besseres) daneben. Nur meinte
diese Welt häufig, sie sei der Nabel selbiger ;-)

Gruß, Ralf
Andreas Kohlbach
2018-01-06 18:30:26 UTC
Antworten
Permalink
Raw Message
Post by Ralf Kiefer
Post by Andreas Kohlbach
Btw. gab es vor Windows 3.11 MS-DOS, was multitaskingfähig war?
Ich saß so um 1986/1987 herum in einem Job vor einem Concurrent
CP/M-Gerät, AFAIR was von Siemens mit einem 80188: vier parallel
laufende Konsolen per Tastaturumschaltung zu "bändigen".
Ansonsten gab es ziemlich viele Multitasking-Betriebssysteme. Z.B. alles
mit *nix auf unterschiedlichsten CPUs von Sun, Apollo, Apple, HP,
Cadmus, Siemens, usw., die PDP-11 und Artverwandte samt ihrem "Zoo" an
Betriebssystemen, die AS/400-Welt, das Macintosh-System, AmigaOS, die
verschiedenen OS-9-Varianten, VxWorks und anderes aus der Echtzeitecke.
Usw.
Mir ging es aber um die Zeit ab Herbst 1981 bis etwa 1984, wo man auf den
Drucker im Büro warten musste, bis man am PC weiter arbeiten konnte.

Mir ging es mit der Frage darum, ob es für Büroanwender multitaskingfähige
Alternativ-Betriebssystems (mit viel Software) neben MP/M gab. Wenn
nicht, warum man im Büro weiter MS-DOS und dann ggf. den teureren
Hardware Druckerpuffer nahm.

Andere Alternativen als MS-DOS oder CP/M (MP/M) konnte man praktisch
nicht einsetzen, weil es dafür nicht (genug) Büro-Software gab.
--
Andreas
You know you are a redneck if
your school fight song was "dueling banjos".
Gerrit Heitsch
2018-01-06 18:38:58 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Andere Alternativen als MS-DOS oder CP/M (MP/M) konnte man praktisch
nicht einsetzen, weil es dafür nicht (genug) Büro-Software gab.
Was einfach daran lag, daß keiner den Herstellern gesagt hat, daß es
Interesse an Bürosoftware auf anderen Platformen gab. Bei MS-DOS ist das
hingegen passiert, sonst hätte es dafür auch nichts gegeben und wir
wären immer noch bei CP/M.

Gerrit
Ralf Kiefer
2018-01-06 23:09:11 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Mir ging es aber um die Zeit ab Herbst 1981 bis etwa 1984, wo man auf den
Drucker im Büro warten musste, bis man am PC weiter arbeiten konnte.
Das war 10 - 7 Jahre *vor* Windows 3.11 und mitnichten direkt davor.
Post by Andreas Kohlbach
Mir ging es mit der Frage darum, ob es für Büroanwender multitaskingfähige
Alternativ-Betriebssystems (mit viel Software) neben MP/M gab. Wenn
nicht, warum man im Büro weiter MS-DOS und dann ggf. den teureren
Hardware Druckerpuffer nahm.
Im Jahr 1984 war MS-DOS in Büros noch wenig verbreitet. Der damalige
Standard-PC war der Apple II. Die klassischen Anwendungen liefen unter
DOS 3.3, und ab 1983 gab es ProDOS. Wenn man dort keine Lust hatte auf
den Drucker zu warten, kaufte man eine intelligente Druckerkarte, wie
bereits erwähnt.


Gruß, Ralf
Stefan Reuther
2018-01-07 10:27:26 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Post by Ralf Kiefer
Ansonsten gab es ziemlich viele Multitasking-Betriebssysteme. Z.B. alles
mit *nix auf unterschiedlichsten CPUs von Sun, Apollo, Apple, HP,
Cadmus, Siemens, usw., die PDP-11 und Artverwandte samt ihrem "Zoo" an
Betriebssystemen, die AS/400-Welt, das Macintosh-System, AmigaOS, die
verschiedenen OS-9-Varianten, VxWorks und anderes aus der Echtzeitecke.
Usw.
Mir ging es aber um die Zeit ab Herbst 1981 bis etwa 1984, wo man auf den
Drucker im Büro warten musste, bis man am PC weiter arbeiten konnte.
Ich würde auch mal behaupten, dass das Warten auf den Drucker einem um
1984 auch überhaupt nicht schlimm vorkam, denn die Alternative wäre die
Schreibmaschine gewesen, und das wäre noch langsamer.

Große Druckaufträge kamen doch eh aus dem Großrechner, mit Druckern,
deren Leistung man in Meter pro Minute misst.


Stefan
Markus Elsken
2018-01-07 13:40:53 UTC
Antworten
Permalink
Raw Message
Moin!
Post by Stefan Reuther
Große Druckaufträge kamen doch eh aus dem Großrechner, mit Druckern,
deren Leistung man in Meter pro Minute misst.
Wir (computerbegeisterter Freundeskreis) durften Anfang der 90er einen
defekten Grossrechner, bestehend aus mehreren Schränken "entsorgen".
Wirtschaftlicher Totalschaden, frei zur Schlachtung. Der Kettendrucker
wurde nicht zerlegt, sondern mit einer ziemlich wilden Adapterschaltung
auf Centronics angepasst - und sollte dann an einem Amiga laufen. War
glaube ich der erste Drucker, der auf den Rechner wartet ;-)

mfg Markus

Goetz Hoffart
2018-01-06 02:14:18 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Btw. gab es vor Windows 3.11 MS-DOS, was multitaskingfähig war?
Concurrent DOS, DESQview und TopView

Grüße
Götz
--
http://www.knubbelmac.de/
Andreas Kohlbach
2018-01-06 19:18:32 UTC
Antworten
Permalink
Raw Message
Post by Goetz Hoffart
Post by Andreas Kohlbach
Btw. gab es vor Windows 3.11 MS-DOS, was multitaskingfähig war?
Concurrent DOS, DESQview und TopView
Ich hatte Concurrent DOS immer mit Concurrent CP/M-86 gleich gesetzt. Wie
ich eben erst sehe, ist es das nicht. Es scheint nun ein optionales Modul
zu sein.

Ah TopView. Ich hatte nie Glück mal ein Image im Web
aufzutreiben. Btw. auch nicht von Concurrent CP/M-86 (von CP/M-86
allerdings schon)... Nun schon. Mal nicht nach "MP/M" sondern "Concurrent
CP/M-86" gesucht, und auf emuliertem IBM PC (5170) gestartet
<Loading Image...>. Da ich Concurrent CP/M vorher
nicht kannte, auch gleich noch die Anleitung dazu gefunden. Zeit nun einige
wichtige Büroarbeit zu erledigen. ;-)

Btw. der IBM hier macht einen Speichertest. Dauert doch ein paar
Sekunden, die 1664 KB zu testen. Kann man das nicht per Tastatur
abbrechen? CTRL-c und ESC gehen schon mal nicht.
--
Andreas
You know you are a redneck if
your school fight song was "dueling banjos".
Ralf Kiefer
2018-01-03 23:39:18 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Und kein Drucker eines Herstellers funktionierte bei einem anderen
Computer.
Die überwiegende Menge an Druckern, die für den Heimgebrauch geeignet
waren, sprachen Centronics-Parallel oder V.24-Seriell.
Post by Andreas Kohlbach
Eine genormte Parallel-Schnittstelle hatten C64 und Kollegen
aus dem 8Bit Bereich nicht.
Den C64 als Referenz zu betrachten ist suboptimal, IMHO. Die CP/M-, die
Apple-II-, die IBM-PC-, die Mac-Welt und einige andere einigten sich auf
die beiden oben erwähnten Schnittstellen.
Post by Andreas Kohlbach
Post by Hermann Riemann
Man konnte einfach selber malen und gut steuern.
Aber nur ASCII.
Für die Betrübssysteme auf dem Apple II gab's dutzende Lösungen für
Hardcopy vom Grafikbildschirm. Beim Mac waren die Grafikeigenschaften
sowieso eingebaut. Der betrieb seine Drucker nur im Ausnahmefall im
Textmodus.
Post by Andreas Kohlbach
In BYTE Magazinen bis etwa 1985 (IIRC) werden externe Druckerpuffer (Spooler)
angeboten, Preis je nach RAM (bis zu 512K!!!elf ;-). Und damit beworben,
dass man nicht mehr warten müsste, bis der PC wieder erreichbar
war.
Für den Applebus gab's Druckerkarten mit lokalen 64kB RAM [1]. RAM-Chips
waren teuer, so natürlich auch die Karten. Ich benutzte eine
Apple-IIe-Hauptplatine mit 128kB als EMUF, baute ein paar parallele und
serielle Schnittstellen dran und schrieb eine Firmware als Druckerpuffer
und -verteiler(!) für meine mehreren Rechner und den einen Drucker.
Post by Andreas Kohlbach
Dabei hätte man MP/M oder ein anderen Multitasking OS einsetzen können,
und die teure Hardware sparen können.
Mein UCSD-BIOS sollte das ebenfalls bekommen und lokales RAM am Applebus
sowie die Haupt-CPU nutzen. Nur fertig bekam ich das UCSD II.1 (Apple
Pascal 1.1) im Interrupt-Betrieb leider nie.
Post by Andreas Kohlbach
Und man wirklich, wie auch ich, erst lesen
musste, um damit arbeiten zu können. Wordstar Diamond und so.
Zu lesen gab's nicht viel. Das Handbuch zu Wordstar hatte aus
naheliegenden Günden keiner, also mußte er mc lesen.

Gruß, Ralf

[1]
z.B.
<http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Inter
face%20Cards/Parallel/AE%20Parallel%20Pro/Photos/AE%20Parallel%20Pro%20w
ith%20Buffer%20Pro%20-%20Front.jpg>

<http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Inter
face%20Cards/Parallel/Orange%20Micro%20Bufferboard/Photos/Orange%20Micro
%20Bufferboard%20-%20Front.jpg>
Letztere gab's auch als Nachbau aus Taiwan.
Andreas Kohlbach
2018-01-04 22:31:32 UTC
Antworten
Permalink
Raw Message
Post by Ralf Kiefer
Post by Andreas Kohlbach
Eine genormte Parallel-Schnittstelle hatten C64 und Kollegen
aus dem 8Bit Bereich nicht.
Den C64 als Referenz zu betrachten ist suboptimal, IMHO. Die CP/M-, die
Apple-II-, die IBM-PC-, die Mac-Welt und einige andere einigten sich auf
die beiden oben erwähnten Schnittstellen.
Ja, aber C64 und Atari 8Bit waren die meist verkauften Computer für den
Heimbereich damals. Die Welt der Profis sprach dagegen natürlich Centronics.

[...]
Post by Ralf Kiefer
Post by Andreas Kohlbach
Und man wirklich, wie auch ich, erst lesen
musste, um damit arbeiten zu können. Wordstar Diamond und so.
Zu lesen gab's nicht viel. Das Handbuch zu Wordstar hatte aus
naheliegenden Günden keiner, also mußte er mc lesen.
Haha!

Ja, ich hatte auch nur Software ohne Anleitung, aus Gründen, die ich
heute nicht mehr nachvollziehen kann. ;-)

Kam neulich aber in den Genuss, WordStar, dBase II oder SuperCalc auf
zeitgenössischen Computern zu testen, wenn auch nur emuliert. Ich hatte
mir gar die Zeit genommen, die Anleitungen (gibt es auch archive.org als
PDF) vorher zu lesen. Und wünsche mir, ich hätte eine Zeitmaschine, die
mich (mit heutigem Wissen) zurück nach etwa 1977 bringt. Denn damals war
ich zu jung (11), und im falschen Land (Deutschland), um das würdigen zu
können.
--
Andreas
You know you are a redneck if
the fifth grade is referred to as "your senior year."
Hermann Riemann
2018-01-04 10:50:30 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Post by Hermann Riemann
Post by Kay Martinen
HäHä, 70er? Das Druckerinterface um eine El.Schreibmaschine an einen
Homecomputer zu klöppeln erinnere ich dunkel eher in den 80er'n - in
der ELRAD (oder c't Beilage)
Ich selbst hab in den 80er'n noch ESC-Sequenzen in SAA-Menüs ein
geklöppelt um Nadeldrucker zum Rennen zu bringen.
Zu Z80 6502 und Atari ST Zeiten
gab es bei mir noch Nadeldrucker, deren bytes ich über einen IO-port
oder bei Atari ST über BIOS verschickte
Und kein Drucker eines Herstellers funktionierte bei einem anderen
Computer.
Bei mir funktionierten alle Nadeldrucker an alle Rechner,
an die ich sie anschloss.

Bei meinen 8-bit Systeme hab ich die passenden bytes
an das 8255 oder Z80 PIO verschickt,
beim Atari ST an das BIOS übergeben.
Damit gab es keine Probleme.
Post by Andreas Kohlbach
Eine genormte Parallel-Schnittstelle hatten C64 und Kollegen
aus dem 8Bit Bereich nicht.
Einen C64 g´hatte ich nicht nur mal einen nahezu unbenutzten
Kummerdore CBM 610. Da habe ich mich über einiges gewundert.
( Ich hatte mir den wegen der nie benutzten IEE-488 zugelegt.)
Post by Andreas Kohlbach
Der Amiga dann aber, wohl auch der Atari ST.
Als ich den Atari ST kaufte, war der Amiga zu teuer,
hatte flackernden Bildschirm und schien nur führ Spiel geeignet.
Post by Andreas Kohlbach
Post by Hermann Riemann
Zu den Drucker gab es noch kleine übersichtliche Beschreibungen.
Und laaaaange Tabellen für Escape-Sequenzen.
Ach was, die vielleicht 2 ESC-Sequenzen die ich auch eventuell benutzte,
machten keine Schwierigkeiten.
Post by Andreas Kohlbach
Oder auch wie man das in BASIC machten.
8-Bit Systeme habe ich praktisch nur hex programmiert
Mit Ausnahme von kurzen Experimente)
Post by Andreas Kohlbach
Post by Hermann Riemann
Post by Kay Martinen
Immer wieder ein Vorteil eines Alten Parallelen Druckers an Alter
HW. Man kann einfach Print Screen im BIOS/Setup Drücken und bekommt
sofort eine Hardcopy.
Man konnte einfach selber malen und gut steuern.
Aber nur ASCII.
Bei meinen ersten Drucker TX8o, ja.
Aber bei meinen Schinwa ?X80 und Nec CP6 konnt man
nach meiner Erinnerung auch Nadelanreihen ansteuen und damit mahlen.
Post by Andreas Kohlbach
Wenn man z.B. einen Textverarbeitungsprogramm, wie erwähntes Wordstar [1]
hier, nahm, was u.a superscripts und subscripts konnte, was aber nicht
jeder Drucker gleich handhabt.
Fremde software ist oft praktisch nicht reparierbares Gücksspiel.
Post by Andreas Kohlbach
Post by Hermann Riemann
Post by Kay Martinen
Da kann es keine Probleme mit Großen Bildern geben weil der Host den
Ausdruck eh in der Warteschlange hortet.
Bis incl. Atari ST Zeiten habe ich die Speicherverwaltung
selber gebastelt.
In BYTE Magazinen bis etwa 1985 (IIRC) werden externe Druckerpuffer (Spooler)
angeboten, Preis je nach RAM (bis zu 512K!!!elf ;-).
Rein vermutlich war da ein 2. Drucker oder Rechner billiger.
Und wenn der 2. Rechner über einen parallelen IO-port
Drucker spielt, und die Daten auf Floppy puffert ..
Die alten towers hatten doch bis zu 2 Parallel und 4 serielle ports,
sofern genügend interrupt Plätze ( Adaptec + bis 3 sound ..)
Post by Andreas Kohlbach
Und damit beworben, dass man nicht mehr warten müsste,
bis der PC wieder erreichbar war.
Mit einem PC habe ich erst mit OS/2 und später mit windows 9*
und danach mit Linux gedruckt.
( Später zwangsweise verübergehend mit windows XP)
Post by Andreas Kohlbach
Darunter meist zwei Bilder. Eines mit einem Büroangestellten ohne,
und eines mit einem mit der Hardware. *g*
Bei Bilder denke ich immer an den hohen Tintenverbrauch.
Einen malenden Roboter habe ich nicht,
und vielleicht hätte ich den Plotter nicht entsorgen sollen.
Post by Andreas Kohlbach
Dabei hätte man MP/M oder ein anderen Multitasking OS einsetzen können,
und die teure Hardware sparen können.
Oder sich ein multiasking basteln:
Ein timer, da in der interrupt routine Register tauschen.
Bei neuem task PC und stack wählen ..
Post by Andreas Kohlbach
[1] Ich hatte neulich auf einem Osborne I mal mit Wordstar und SuperCalc
sowie dBase II kurz gespielt, und das auch auf YouTube hochgeladen. Muss
eine aufregende Zeit Anfang der 80er gewesen sein, als das alles noch neu
war, und ohne Mausbedienung.
Vielleicht bastele ich nochmal mit
meinen alten Platinensysteme.
Die sind mit hoher Wahrscheinlichkeit ohne malware.
Post by Andreas Kohlbach
Und man wirklich, wie auch ich, erst lesen musste,
um damit arbeiten zu können. Wordstar Diamond und so.
Ich habe beruflich ein paar mal mit M$-word editieren müssen.
Ohne mich irgendwie einzulesen.
Ich habe dabei viel Zeit verbracht.
Buchstaben im richtigen Font hinzutricksen.
Die Meinungsverschiedenheiten zwischen mir und M$
zum Menu waren erheblich.

Hermann
der sehr selten office verwendete,
und vermutlich, mit der Ausnahme von export von excel Tabellen,
kein office mehr verwenden wird.
--
http://www.hermann-riemann.de
Kay Martinen
2018-01-04 13:15:21 UTC
Antworten
Permalink
Raw Message
Post by Hermann Riemann
Post by Andreas Kohlbach
Und kein Drucker eines Herstellers funktionierte bei einem anderen
Computer.
Bei mir funktionierten alle Nadeldrucker an alle Rechner,
an die ich sie anschloss.
Das ist kein Problem, wenn der Drucker weniger kann als die Rechner.
Solche gab es damals bestimmt auch.
Post by Hermann Riemann
Bei meinen 8-bit Systeme hab ich die passenden bytes
an das 8255 oder Z80 PIO  verschickt,
beim Atari ST an das BIOS übergeben.
Damit gab es keine Probleme.
Ja, und heute müsstest du einen Kompletten USB-Softwarestack entwerfen
um nur ein einziges Byte zum Drucker senden zu können - der das dann
vielleicht noch nicht mal versteht. Fortschritt...
Post by Hermann Riemann
Einen C64 g´hatte ich nicht nur mal einen nahezu unbenutzten
Kummerdore CBM 610. Da habe ich mich über einiges gewundert.
( Ich hatte mir den wegen der nie benutzten IEE-488 zugelegt.)
Und? Hast du es letztlich benutzt?
IEEE-488 gab es; als Cartridge; auch für den VC-20. Zwei stück davon
dürften hier noch rum liegen.
Post by Hermann Riemann
Post by Andreas Kohlbach
Und laaaaange Tabellen für Escape-Sequenzen.
Ach was, die vielleicht 2 ESC-Sequenzen die ich auch eventuell benutzte,
machten keine Schwierigkeiten.
Das war doch grad der Vorteil an den Parallel-Druckern. Die druckten
einfach "wie ihnen der Schnabel gewachsen ist" und hatten oft sogar
Tasten am Gerät um z.b. Zeilenabstand oder Font zu wählen.

Äh, moment. Da bin ich nicht sicher bei frühen modellen. Mein Deskjet
510 und der Nec P6 hatten mehrere Tasten (ersterer sogar Slots für
RAM/Font) kamen aber erst später raus. IMHO.
Post by Hermann Riemann
Post by Andreas Kohlbach
Aber nur ASCII.
Bei meinen ersten Drucker TX8o, ja.
Aber bei meinen Schinwa ?X80 und Nec CP6 konnt man
nach meiner Erinnerung auch Nadelanreihen ansteuen und damit mahlen.
Das ging m.W. sogar schon früh(er) und auch mit bestimmten Modellen von
Commodore das man die in eine art Grafikmodus setzen konnte. Dann wurden
die Druckdaten nicht mehr als Zeichen interpretiert sondern als "Punkt
oder nicht Punkt" Drucken auf der Zeile.
Post by Hermann Riemann
Post by Andreas Kohlbach
(Spooler)
Rein vermutlich war da ein 2. Drucker oder Rechner billiger.
Und wenn der 2. Rechner über einen parallelen IO-port
Drucker spielt, und die Daten auf Floppy puffert ..
AFAIR hatte die c't damals so ein Projekt vorgestellt. Bin nur nicht
sicher ob das schon zu Zeiten der Bidirektionalen LPTs war oder davor.
Dunkel erinnere ich das dem etwas HW-Bastelei zugrunde lag. Also
vermutlich früher.
Post by Hermann Riemann
Die alten towers hatten doch bis zu 2 Parallel und 4 serielle ports,
Nicht nur Tower und nicht nur 2 Parallele. Es waren bis zu Drei aber...
Post by Hermann Riemann
sofern genügend interrupt Plätze ( Adaptec + bis 3 sound ..)
... dann erst recht gab es Probleme mit den Interupts. Von denen
eigentlich nie genug da waren für alles.

Aber bei üblichem Betrieb damals war der IRQ für den Drucker eher nicht
wichtig.
Post by Hermann Riemann
Mit einem PC habe ich erst mit OS/2 und später mit windows 9*
und danach mit Linux gedruckt.
Hole dein OS/2 mal wieder raus und bespiele damit vorhandene Alt-HW. Bei
der aktuellen Aufregung um CPU-Probleme mit Spekulativer Ausführung,
ASLR u.s.w. denke ich das Segmentierte Speichermodell hatte doch seine
Vorteile. NX ist inklusiv in GDT und LDTs und Speicherverwürfelung
dürfte es da nicht brauchen = Kein Problem. ;-)

Mal wieder die FlatEarthler und die Probleme die sie schufen. :(
Post by Hermann Riemann
Post by Andreas Kohlbach
Dabei hätte man MP/M oder ein anderen Multitasking OS einsetzen können,
und die teure Hardware sparen können.
Wie viel hätte damals eine Maschine plus MP/M gekostet - nur zum
Druckspooler spielen? ;)

In einem Serverraum mit mehreren Teuren Druckern dran okay. Aber sonst...
Post by Hermann Riemann
Ein timer, da in der interrupt routine Register tauschen.
Bei neuem task PC und stack wählen ..
So was wurde ja auch gemacht. Als ASM oder TSR. Zumindest erinnere ich
mich an ähnliches bei C-64 und PCs. War halt alles nur nicht Reset-fest.
Außer man hatte HW-Extensions wie Reset-feste Ramdisks o.ä. dazu.

Kay
Hermann Riemann
2018-01-04 14:13:01 UTC
Antworten
Permalink
Raw Message
Post by Kay Martinen
Post by Hermann Riemann
Post by Andreas Kohlbach
Und kein Drucker eines Herstellers funktionierte bei einem anderen
Computer.
Bei mir funktionierten alle Nadeldrucker an alle Rechner,
an die ich sie anschloss.
Das ist kein Problem, wenn der Drucker weniger kann als die Rechner.
Solche gab es damals bestimmt auch.
Die Rechner konnten schon.
Den gängigen IO-Bausteine machte das keine Probleme,
Wenn allerdings ein Betriebssytem dazu "eigene" Meinung hat.
Post by Kay Martinen
Post by Hermann Riemann
Bei meinen 8-bit Systeme hab ich die passenden bytes
an das 8255 oder Z80 PIO  verschickt,
beim Atari ST an das BIOS übergeben.
Damit gab es keine Probleme.
Ja, und heute müsstest du einen Kompletten USB-Softwarestack entwerfen
um nur ein einziges Byte zum Drucker senden zu können - der das dann
vielleicht noch nicht mal versteht. Fortschritt...
Oder raspberry pi bzw Arduino verwenden.
Wobei bei raspberry pi noch beim input der level angepasst
werden müsste.
Post by Kay Martinen
Post by Hermann Riemann
Einen C64 g´hatte ich nicht nur mal einen nahezu unbenutzten
Kummerdore CBM 610. Da habe ich mich über einiges gewundert.
( Ich hatte mir den wegen der nie benutzten IEE-488 zugelegt.)
Und? Hast du es letztlich benutzt?
Nein.
Post by Kay Martinen
IEEE-488 gab es; als Cartridge; auch für den VC-20. Zwei stück davon
dürften hier noch rum liegen.
Die einzigen nahezu unbenutzen 8-bit Rechner mit Gehäuse, die ich hatte,
waren 2? ZX81 und ein CBM 610.

Der RASPBERRY COMM hat RS-485.
Post by Kay Martinen
Post by Hermann Riemann
Rein vermutlich war da ein 2. Drucker oder Rechner billiger.
Und wenn der 2. Rechner über einen parallelen IO-port
Drucker spielt, und die Daten auf Floppy puffert ..
AFAIR hatte die c't damals so ein Projekt vorgestellt. Bin nur nicht
sicher ob das schon zu Zeiten der Bidirektionalen LPTs war oder davor.
Dunkel erinnere ich das dem etwas HW-Bastelei zugrunde lag. Also
vermutlich früher.
Post by Hermann Riemann
Die alten towers hatten doch bis zu 2 Parallel und 4 serielle ports,
Nicht nur Tower und nicht nur 2 Parallele. Es waren bis zu Drei aber...
Post by Hermann Riemann
sofern genügend interrupt Plätze ( Adaptec + bis 3 sound ..)
... dann erst recht gab es Probleme mit den Interupts. Von denen
eigentlich nie genug da waren für alles.
Aber bei üblichem Betrieb damals war der IRQ für den Drucker eher nicht
wichtig.
Ich vermute es gab ein komplettes handshake,
es ist aber zu lange her.
Irgendwann grabe ich mein Z80 EPROM aus
und disassembliere wieder ( mit eigenen Disassembler)
Post by Kay Martinen
Post by Hermann Riemann
Mit einem PC habe ich erst mit OS/2 und später mit windows 9*
und danach mit Linux gedruckt.
Hole dein OS/2 mal wieder raus
Das habe ich entsorgt. hard- und software. Nie wieder OS/2.
Post by Kay Martinen
Post by Hermann Riemann
Post by Andreas Kohlbach
Dabei hätte man MP/M oder ein anderen Multitasking OS einsetzen können,
und die teure Hardware sparen können.
Wie viel hätte damals eine Maschine plus MP/M gekostet - nur zum
Druckspooler spielen? ;)
Sowas ging doch mit Leerplatine von elektor,
+ ICs von Dahms oder HW-Elektronik +..
Post by Kay Martinen
In einem Serverraum mit mehreren Teuren Druckern dran okay. Aber sonst...
Post by Hermann Riemann
Ein timer, da in der interrupt routine Register tauschen.
Bei neuem task PC und stack wählen ..
So was wurde ja auch gemacht. Als ASM oder TSR.
Ich habe mit GST-Assembler den stack für Pascal ST-Programme
modifiziert und damit parallele Programmierung vorbereitet.
( Einige Tricks waren notwendig da sich die beiden
nicht binden ließen.)
Post by Kay Martinen
War halt alles nur nicht Reset-fest.
Ein paar byte hinter dem Bildschirmpuffer vom Atari ST schon ..

Hermann
der nicht weiß, wann er das letzte reset
über Netzstecker ziehen gemacht hat.
--
http://www.hermann-riemann.de
Andreas Kohlbach
2018-01-04 22:44:57 UTC
Antworten
Permalink
Raw Message
Post by Hermann Riemann
Post by Andreas Kohlbach
Post by Hermann Riemann
Zu Z80 6502 und Atari ST Zeiten
gab es bei mir noch Nadeldrucker, deren bytes ich über einen IO-port
oder bei Atari ST über BIOS verschickte
Und kein Drucker eines Herstellers funktionierte bei einem anderen
Computer.
Bei mir funktionierten alle Nadeldrucker an alle Rechner,
an die ich sie anschloss.
Aktuelle Rechnern? Ja, ich hatte mit für meinen PC mal einen Star LC-10 (?)
(IIRC einer der Martix Drucker) im Jahr 2002 vom Flohmarkt
geschossen. IIRC erkannte CUPS den und installierte einen "generic dot
matrix" Treiber.

Wenn man reinen Text hatte, konnte man auch

cat file.txt > /dev/lp

auf der Kommandozeile absetzen.

[...]
Post by Hermann Riemann
Post by Andreas Kohlbach
Und man wirklich, wie auch ich, erst lesen musste,
um damit arbeiten zu können. Wordstar Diamond und so.
Ich habe beruflich ein paar mal mit M$-word editieren müssen.
Ohne mich irgendwie einzulesen.
Ich habe dabei viel Zeit verbracht.
Buchstaben im richtigen Font hinzutricksen.
Die Meinungsverschiedenheiten zwischen mir und M$
zum Menu waren erheblich.
Hermann
der sehr selten office verwendete,
und vermutlich, mit der Ausnahme von export von excel Tabellen,
kein office mehr verwenden wird.
Ich habe hier nur LibreOffice, dort funktioniert der "WordStar Diamond"
*nicht*.

Hat jemand hier MS Office oder anderen, und kann in einem Text mal
schauen, ob etwa STRG-s, um den Cursor eine Position nach links zu
bewegen. -d für rechts, -e für hoch und -x für runter, funktioniert?

Denn es gab zu der Zeit, als WordStar "hot" war, noch Tastaturen ohne
Cursor-Tasten. Wäre interessant zu wissen, ob andere *aktuelle*
Textverarbeitungsprogramme das geerbt hätten.
--
Andreas
You know you are a redneck if
the fifth grade is referred to as "your senior year."
Hermann Riemann
2018-01-05 09:14:35 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Post by Hermann Riemann
Post by Andreas Kohlbach
Post by Hermann Riemann
Zu Z80 6502 und Atari ST Zeiten
gab es bei mir noch Nadeldrucker, deren bytes ich über einen IO-port
oder bei Atari ST über BIOS verschickte
Und kein Drucker eines Herstellers funktionierte bei einem anderen
Computer.
Bei mir funktionierten alle Nadeldrucker an alle Rechner,
an die ich sie anschloss.
Aktuelle Rechnern?
Die Nadeldrucker hatte ich nur an 8-Bit Rechner und Atari ST angeschlossen.
An i386 mit Linux OS/2 und windows hatte ich Tintenspritzen
mit Treiber.

Die Nadeldrucker habe ich aus Platzgründen entsorgt,
die 8-Bit Platinen habe ich noch, und werde sie vielleicht
auch nochmal anwenden.
Post by Andreas Kohlbach
Ja, ich hatte mit für meinen PC mal einen Star LC-10 (?)
(IIRC einer der Martix Drucker) im Jahr 2002 vom Flohmarkt
geschossen. IIRC erkannte CUPS den und installierte einen "generic dot
matrix" Treiber.
"generic dot matrix" scheint robust zu sein.
Post by Andreas Kohlbach
Wenn man reinen Text hatte, konnte man auch
cat file.txt > /dev/lp
Bei utf-8 und Binärdateinen (*.gif) wird das sicher abenteuerlich.
Post by Andreas Kohlbach
Hat jemand hier MS Office oder anderen, und kann in einem Text mal
schauen, ob etwa STRG-s, um den Cursor eine Position nach links zu
bewegen. -d für rechts, -e für hoch und -x für runter, funktioniert?
Denn es gab zu der Zeit, als WordStar "hot" war,
Bei mir nie.
Zu 8-bit Zeiten habe ich nahezu immer die bytes hexadezimal eingegeben.
Bei Atari ST hatte ich bei den Sprachen Editoren und später Tempus.
Unter windows war es vermutlich editor, und irgendwann xemacs
jedenfalls etwas für plain Text.
Irgend ein Editor hat bei Zeilenwechsel nur CR erzeugt,
was wie nur LF ( Linux) bei uralt Drucker auch nur
ausgeführt wurde.
( CR zum übereinander drucken. )
Post by Andreas Kohlbach
noch Tastaturen ohne Cursor-Tasten.
Klingt nach vi. Sollte da entsprechend noch gehen.

Hermann
der gelegentlich vi benutzt.
--
http://www.hermann-riemann.de
Bernd Laengerich
2018-01-04 22:30:37 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Und laaaaange Tabellen für Escape-Sequenzen. Oder auch wie man das in
BASIC machten. Ich scheine mich an
Ich erinnere mich an meinen Nadeldrucker, der außer normalem Text genau
ein frei definierbares Zeichen kannte. Mit etwas Geschick habe ich dann
Vollgrafik damit gedruckt. Dauerte etwas länger...
Post by Andreas Kohlbach
Dabei hätte man MP/M oder ein anderen Multitasking OS einsetzen können,
und die teure Hardware sparen können.
Wordstar konnte doch selber im Hintergrund drucken...

Bend
Kay Martinen
2018-01-05 14:53:10 UTC
Antworten
Permalink
Raw Message
Post by Bernd Laengerich
Ich erinnere mich an meinen Nadeldrucker, der außer normalem Text genau
ein frei definierbares Zeichen kannte. Mit etwas Geschick habe ich dann
Vollgrafik damit gedruckt. Dauerte etwas länger...
War das eventuell ein Commodore, MPS-800 oder so. Der nachfolger sollte
dann AFAIR "etwas" mehr gekonnt haben.
Post by Bernd Laengerich
Post by Andreas Kohlbach
Dabei hätte man MP/M oder ein anderen Multitasking OS einsetzen können,
und die teure Hardware sparen können.
Wordstar konnte doch selber im Hintergrund drucken...
WAS, echt? Neumodisches Teufelszeuch. Echte Fundamentalisten benutzen
EDLIN. ;-)

SCNR

Kay
Hermann Riemann
2018-01-05 16:48:09 UTC
Antworten
Permalink
Raw Message
Post by Kay Martinen
Post by Bernd Laengerich
Wordstar konnte doch selber im Hintergrund drucken...
WAS, echt? Neumodisches Teufelszeuch. Echte Fundamentalisten benutzen
EDLIN. ;-)
Oder Lochstreifen.

Bei jedem Tippfehler das Ganze neu eintippen.

Hermann
der auch davon gehört hat,
das jemand Lochkarten mit einem Handlocher
bearbeitet hat.
--
http://www.hermann-riemann.de
Martin Neitzel
2018-01-06 12:30:37 UTC
Antworten
Permalink
Raw Message
Hermann Riemann wrote:
HR>
HR> Oder Lochstreifen. Bei jedem Tippfehler das Ganze neu eintippen.

Noe. DEL hat nicht ohne Grund Code 127. Tape wieder auf's letzte
Zeichen zurueck, komplett durchloechern, weitermachen.

Martin
Volker Borchert
2018-01-05 19:45:16 UTC
Antworten
Permalink
Raw Message
Post by Kay Martinen
Post by Bernd Laengerich
Wordstar konnte doch selber im Hintergrund drucken...
WAS, echt? Neumodisches Teufelszeuch. Echte Fundamentalisten benutzen
EDLIN. ;-)
Wirklich echte Fundamentalisten stanzen Lochkarten.
--
"I'm a doctor, not a mechanic." Dr Leonard McCoy <***@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <***@despammed.com>
Kay Martinen
2018-01-05 20:51:11 UTC
Antworten
Permalink
Raw Message
Post by Volker Borchert
Echte Fundamentalisten benutzen EDLIN. ;-)
Wirklich echte Fundamentalisten stanzen Lochkarten.
"I'm a mechanic, not a doctor." Volker
Now, you're an REAL Mechanic! :)

Kay
--
104 141 163 40 155 165 163 163 40 144 157 143 150 40 141 165 143 150 40
155 151 164 47 155 40 116 141 147 145 154 144 162 165 143 153 145 162 40
147 145 150 145 156 56 56 56 oct.
Hermann Riemann
2018-01-06 14:23:38 UTC
Antworten
Permalink
Raw Message
Post by Volker Borchert
Post by Kay Martinen
Post by Bernd Laengerich
Wordstar konnte doch selber im Hintergrund drucken...
WAS, echt? Neumodisches Teufelszeuch. Echte Fundamentalisten benutzen
EDLIN. ;-)
Wirklich echte Fundamentalisten stanzen Lochkarten.
Mit einer Lochzange?

Hermann
der da gerne Testergebnisse hätte.
--
http://www.hermann-riemann.de
Volker Borchert
2018-01-06 18:22:27 UTC
Antworten
Permalink
Raw Message
Post by Hermann Riemann
Post by Volker Borchert
Post by Kay Martinen
Post by Bernd Laengerich
Wordstar konnte doch selber im Hintergrund drucken...
WAS, echt? Neumodisches Teufelszeuch. Echte Fundamentalisten benutzen
EDLIN. ;-)
Wirklich echte Fundamentalisten stanzen Lochkarten.
Mit einer Lochzange?
Mit einem weichen Bleistift.

Das ist durchaus ernstgemeint. Von Olivetti gab es in den 1980ern
Geräte, die mit Karten im Lochkartenformat arbeiteten, die man aber
nicht lochte, sondern auf denen man Kästchen mit weichem Bleistift
ausfüllte. An meinem Oberstufengymnasium wurden damit die Kurswahlen
abgewickelt. Als Primaner habe ich bei der Auswertung mitgeholfen.
Die 5B Bleistifte hab ich noch.
--
"I'm a doctor, not a mechanic." Dr Leonard McCoy <***@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <***@despammed.com>
Bernd Laengerich
2018-01-05 23:58:19 UTC
Antworten
Permalink
Raw Message
Post by Kay Martinen
War das eventuell ein Commodore, MPS-800 oder so.
Ja, vermutlich. Ich hatte nur abgelegtes Zeugs aufgebraucht, als Schüler
ohne Geld habe ich seinerzeit lange auf Bauteile etc. sparen müssen.
"Mein" Drucker war ein Fernschreiber Lorenz Lo15, für den ich
Linienstromversorgung und Interface zusammengelötet habe. Und die
Wandlung auf 5bit-Baudot-Code habe ich irgendwo in ein EPROM gebrannt.

Ich erinnere mich auch noch an den Drucker eines Bekannten, ein
"billiger" Commodore, der eine unendliche Lautstärke erzeugte, weil er
nicht auf einer gummierten Trommel druckte sondern mit einer Art
Axiallüfter das Papier von hinten anblies. Auf dem schwebenden Papier
prasselten dann die Nadeln nieder...
Post by Kay Martinen
Post by Bernd Laengerich
Wordstar konnte doch selber im Hintergrund drucken...
WAS, echt?
Ich meine ja, ich weiß aber nicht mehr ob das beim CP/M-Wordstar auch
ging oder beim Wordstar unter DOS.

Bernd
Gerrit Heitsch
2018-01-03 15:45:56 UTC
Antworten
Permalink
Raw Message
Post by Juergen Nickelsen
Post by Bernd Laengerich
Post by Gerrit Heitsch
Ich hab meine auch in FrameMaker geschrieben, auf Solaris. War schön
Was für ein Komfort.
Bei mir Wordstar. Und die Escapesequenzen für den geliehenen
Typenraddrucker musste man auch erstmal einpatchen...
Nu, das ist der Unterschied der Technikgenerationen der 70er und der
90er Jahre, schönes Beispiel!
Meinst du nicht eher die 80er als die 70er? Wordstar ist schliesslich
erst 1978 erschienen.

Gerrit
Andreas Kohlbach
2018-01-03 22:51:43 UTC
Antworten
Permalink
Raw Message
Post by Gerrit Heitsch
Post by Juergen Nickelsen
Post by Bernd Laengerich
Was für ein Komfort.
Bei mir Wordstar. Und die Escapesequenzen für den geliehenen
Typenraddrucker musste man auch erstmal einpatchen...
Nu, das ist der Unterschied der Technikgenerationen der 70er und der
90er Jahre, schönes Beispiel!
Meinst du nicht eher die 80er als die 70er? Wordstar ist schliesslich
erst 1978 erschienen.
Vielleicht noch früher, aber IMO nicht bis in die 90er, da es um Drucker
geht. Auch in den 60ern, oder seit wann man Textverarbeitung einsetzt,
dürfte man an den Sequenzen basteln müssen, wenn man ein Druckermodell
gegen eines einer anderen Firma austauschte.

Ist ja heute noch so, aber ein Druckertreiber nimmt einem das und anderes ab.
--
Andreas
You know you are a redneck if
you have started a petition to change the national anthem to "georgia
on my mind".
Andreas Kohlbach
2018-01-03 22:25:29 UTC
Antworten
Permalink
Raw Message
Post by Juergen Nickelsen
Post by Bernd Laengerich
Post by Gerrit Heitsch
Ich hab meine auch in FrameMaker geschrieben, auf Solaris. War schön
Was für ein Komfort.
Bei mir Wordstar. Und die Escapesequenzen für den geliehenen
Typenraddrucker musste man auch erstmal einpatchen...
Nu, das ist der Unterschied der Technikgenerationen der 70er und der
90er Jahre, schönes Beispiel!
90er? Ich würde 70er und 80er sagen. Ab Ende der 80er sollte kein Drucker
an keinem Computer (Homecomputer ausgenommen) ein Problem gewesen sein.

Aber Obiges beschreibt, dass es davor nicht wirklich Druckertreiber
gab. IIRC hatten die Wordstar Versionen nicht mal eine Handvoll von
Vorlagen für Drucker. Das waren Text Dateien, die Escape-Sequenzen
hatten, und beim Einrichten (besser: "Festlegen") des Druckers an das
Programm und ggf. die Schnittstelle übergeben wurden.

Vielleicht waren gerade Epson, Juki, Diabolo als Vorlagen vorhanden in
frühen Wordstar Programmen. Wenn man die nicht hatte, musste man einen
wählen, der möglichst nahe kommt, und wie Bernd sagt, diese Vorlage
patchen.
--
Andreas
You know you are a redneck if
you have started a petition to change the national anthem to "georgia
on my mind".
Ralf Kiefer
2018-01-03 22:52:02 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Wenn man die nicht hatte, musste man einen
wählen, der möglichst nahe kommt, und wie Bernd sagt, diese Vorlage
patchen.
Mitte der 1980er Jahre bestand die mc gefühlt zur Hälfte ihres Inhalts
aus Tips, wie man welchen Drucker für Wordstar anpaßt. Es nervte.

Gruß, Ralf
Kay Martinen
2018-01-03 22:58:30 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Aber Obiges beschreibt, dass es davor nicht wirklich Druckertreiber
gab. IIRC hatten die Wordstar Versionen nicht mal eine Handvoll von
Vorlagen für Drucker. Das waren Text Dateien, die Escape-Sequenzen
hatten, und beim Einrichten (besser: "Festlegen") des Druckers an das
Programm und ggf. die Schnittstelle übergeben wurden.
Sicher. Die "Druckertreiber" bestanden damals nur aus einer Zuordnung
der passenden Befehle für Sachen wie Reset, FettDruck, Kursiv,
Zeilenabstand, Tab, Rechter Rand, Seitenlänge u.a.

Das ganze paßt auch locker, wenn man statt *Drucker* mal *Modem* sagt.

Da hat; trotz AT-Befehlen; auch jeder Hersteller seine Spezialitäten ein
gebaut und man mußte oft genug von Hand Sequenzen zusammen stellen um
dem Gerät (Modell) und der Funktion (Modi) gerecht zu werden.


Kay
Andreas Kohlbach
2018-01-03 23:23:41 UTC
Antworten
Permalink
Raw Message
Post by Kay Martinen
Das ganze paßt auch locker, wenn man statt *Drucker* mal *Modem* sagt.
Da hat; trotz AT-Befehlen; auch jeder Hersteller seine Spezialitäten
ein gebaut und man mußte oft genug von Hand Sequenzen zusammen stellen
um dem Gerät (Modell) und der Funktion (Modi) gerecht zu werden.
Aber nur bei Besonderheiten. Wie bei IBM PC und seiner Klone wollten
alles Modemhersteller "Hayes-Kompatibel" sein. AT Kommandos wie das
wählen war über alle "ADT" und auch alles anderen zum einfachen Aufbau
einer Verbindung.

Ich hatte 1999 ein US Robotics Sportstar, was auch offline
Anrufbeantworter und Fax hatte. Diese Funktionen waren speziell, so dass
ich es zunächst nur in Windows zum Laufen bekam. Aber Internet- und BBS
Einwahl gingen auf Anhieb auch mit Linux, ohne dass mein Rechner wusste,
was für ein Modem das war.
--
Andreas
You know you are a redneck if
you have started a petition to change the national anthem to "georgia
on my mind".
Kay Martinen
2018-01-04 00:21:03 UTC
Antworten
Permalink
Raw Message
Post by Andreas Kohlbach
Post by Kay Martinen
Das ganze paßt auch locker, wenn man statt *Drucker* mal *Modem* sagt.
Da hat; trotz AT-Befehlen; auch jeder Hersteller seine Spezialitäten
ein gebaut und man mußte oft genug von Hand Sequenzen zusammen stellen
um dem Gerät (Modell) und der Funktion (Modi) gerecht zu werden.
Aber nur bei Besonderheiten. Wie bei IBM PC und seiner Klone wollten
alles Modemhersteller "Hayes-Kompatibel" sein. AT Kommandos wie das
wählen war über alle "ADT" und auch alles anderen zum einfachen Aufbau
einer Verbindung.
Das habe ich auch nicht anders gemeint. Die unterschiede fingen eben bei
diesen Speziellen Zusätzen an die viele Einbauten. Z.B. Erinnere ich
mich das ein Zyxel U-1496 bei den AT I befehlen deutlich mehr und
Informativere Daten lieferte als ein BEST 14k4. Dinge die Halbwegs
standardisiert oder wenigstens von den Herstellern koordiniert waren wie
Fax konnten ohne einstellung klappen. Wenn man nix anderes damit machte!

Sobald man aber einen Mailer als Frontend einer FTN-Box betreibt an dem
nach der eigentlichen Box und ihren Diensten (F.Request, Tosser, Tikker,
Areafix) evtl. auch noch Fax und Voice-Empfang hingen - dann wirds
kompliziert.

Mit einem einfachen ATZ kommst du dann nur weiter wenn die Programme
alle Ihre Eigenen Init-Sequenzen mit bringen. Wenn aber die Leitung
schon steht (usus) der FOSSIL-Treiber also schon /heiß/ läuft dann ist
nix mehr mit Init. Dann muss die Session stehen oder gnadenlos
abrauchen. Heißt: Nach dem Auflegen bekommt das Modem einen
Rattenschwanz an Init der für alles passen muß, oder man lagert die
ungefährlichen Teile (die keinen Carrier-lost auslösen) in das
entsprechende Programm aus. Der Mailer erkennt dann z.B. CONNECT FAX,
beendet sich; ohne ATH mit Errorlevel x und dein Batch springt in das
Faxprogramm (dem man ggf. noch ein /ONLINE mit geben musste) das dann
die eigentliche Arbeit übernahm.
Post by Andreas Kohlbach
Ich hatte 1999 ein US Robotics Sportstar, was auch offline
Anrufbeantworter und Fax hatte. Diese Funktionen waren speziell, so dass
ich es zunächst nur in Windows zum Laufen bekam. Aber Internet- und BBS
Einwahl gingen auf Anhieb auch mit Linux, ohne dass mein Rechner wusste,
was für ein Modem das war.
Klar. ATZ, ATH und ATD sind ja auch Standard-Befehle. Gutes Beispiel mit
dem Sportster. Hab auch so eine Schachtel. Und die Befehle um die im
Gerät Gespeicherten Faxe oder Anrufe ab zu holen waren sehr speziell und
kryptisch.

Anderes Beispiel. Ich hatte hier Teils eine Leitung die zu lahm
reagierte (Pulswahl = ATDT) und das Modem das Freizeichen der Anlage
nicht erkannte (ein paar Hz daneben). Also blieb (AFAIR) entweder ATX0
oder eine Kombination aus ATX1 und einem (vergessenen) weiteren der eine
"Halbe" Blindwahl ermöglichte. Dennoch schnallte das Modem dann oft
nicht wenn die Verbindung da ist, legte kurz vor dem Connect auf
(Timeout zu kurz) und bekommt generell nicht mit ob die Gegenseite
besetzt ist. Wenn dir das in der NMH mit einer Direktmail in der
Warteschlange passiert dann nervst du evtl. 1 Stunde lang irgendwen im
Lande zu nachtschlafender Zeit - bis du merkst das die Falsche
Telefonnummer gewählt wurde.

Alles schon passiert. Mir nicht oft aber anderen.

Als ich endlich einen eigenen Anschluß hatte sah mein Wählstring
ungefähr so aus. ATX4DT0W,<nummer> (und noch was dahinter das ich
vergaß) == wähl eine null, Prüfe auf Freizeichen, warte kurz und wähle
dann <nummer>

Kay
Ralf Kiefer
2018-01-04 00:51:34 UTC
Antworten
Permalink
Raw Message
Post by Kay Martinen
Dinge die Halbwegs
standardisiert oder wenigstens von den Herstellern koordiniert waren wie
Fax konnten ohne einstellung klappen.
AFAIR: ein Standard war das nie. Hayes hatte die Idee umgesetzt, wie man
Kommandos von Daten auf der einzigen Leitung ohne weitere Signalisierung
durch Hardware unterscheidet. Die Einleitung "AT" stand für Kommandos
und [Pause]"+++"[Pause] für das Verlassen des Datenmodus. Ein paar
übliche Kommandos etablierten sich, aber es herrschte ein riesiger
Wildwuchs. Ich habe hier für die Mac-Welt dutzende Steuerdateien für die
unterschiedlichsten Modem-Typen und dies jeweils für die
unterschiedlichen Kommunikationsarten von Fax über FirstClass und
SLIP/PPP bis Apple Remote Access. Ein Standard sieht anders aus.

Die Centronics-Schnittstelle war in den Anfangsjahren ebenfalls völlig
unreguliert und lediglich von der Firma Centronics für die eigenen
Drucker in Umlauf gebracht worden. Erst im Jahr 1994 wurde daraus mit
IEEE-1284 ein Standard. Vorher gab's den üblichen Wildwuchs, unter dem
ich selbst "litt", als ich z.B. einen Druckertreiber im OS-9 mit einem
HP Tintenpinkler nicht ans Laufen brachte. Erst mit Hilfe eines Logic
Analyzers haben wir dem HP-Drucker regelwidriges Verhalten nachgewiesen,
denn er las seine 8bit Daten erst lange, nachdem er die Übernahme
bereits signalisiert hatte. Bei DOS-PCs kein Problem, denn die
verwendeten ihre GPIOs für die parallele Druckerschnittstelle exklusiv
und ließen den Inhalt einfach stehen, wir in unserem OS-9 mit unserer
Hardware seinerzeit nicht. Ebenso waren vor der Standardisierung nur die
beiden wichtigen Handshake-Leitungen einigermaßen einheitlich (von den
erwähnten Timing-Fehlern abgesehen), nur nicht die Leitungen für
zusätzliche Signale. Da belegte auch jeder, wie er gerade Lust hatte.


Gruß, Ralf
Günter Frenz
2017-12-25 20:30:15 UTC
Antworten
Permalink
Raw Message
@Peter Geher:

Ich hatte dir vor einer Woche via Mail schon mal geantwortet aber
bisher keine weitere Reaktion von dir erhalten. Bist du an den Teilen
interessiert und wenn ja, wann kannst du das abholen kommen?

bis denn

Günter
Günter Frenz
2018-01-01 17:46:26 UTC
Antworten
Permalink
Raw Message
Post by Günter Frenz
Hallo zusammen,
1.: HP 9000/735 mit externer Grafikeinheit und 20" Monitor, Tastatur
und Maus. Die Maschine ist letztes Wochenende noch problemlos
angelaufen und man konnte sich anmelden (Passworte sind leer).
2.: HP EnvizeX X-Terminal bislang nicht getestet.
3.: IBM Drucker 5202 mit Papiereinzug ebenfalls nicht getestet.
Alles ist gegen Selbstabholung in Köln zu verschenken.
Da sich der bisherige Interessent nicht mehr meldet, ist das Angebot
wieder für alle offen.

Günter
Loading...