Hallo Freunde,
die Frage ist ein wenig Off Topic, aber ich frage mich, wie man zur Zeit
der Lochkarten eine Hochsprache wie Fortran umsetzen konnte.
Ich kann mir ja noch vorstellen, dass ein damaliger Computer
Maschinencode von Lochkarten lesen und abarbeiten konnte.
Aber wie hat man ohne Bildschirm-Terminal Sourcecode eingegeben?
Wie wurde der Compiler in den Computer geladen (oder war er fest
verdrahtet)?
Und wo wurde der vom Compiler erzeugte Maschinencode gespeichert?
Alles per Lochkarten?
Hat jemand vielleicht ein paar interessante Links?
Die Lochkarte hatte man auf einem schreibmaschinenähnlichen
Lochkartenstanzer eingetippt.
Falsch getippt -> neue Lochkarte
Der Text stand in Klartext in der unteren Zeile, insofern
Menschenlesbar.
Pro Zeile eine Lochkarte, nicht mehr als 72 Spalten.
Udo Schmitt schrieb:> Pro Zeile eine Lochkarte, nicht mehr als 72 Spalten.
… dieweil in Spalte 73 bis 80 die Kartennummer stand, damit man sie
nach dem Runterfallen des Stapels auch wieder sortiert bekommt. ;-)
Nein, Maschinencode haben die Maschinen auch damals schon eher nicht
von Lochkarten aus ausgeführt. Es macht sich ausgesprochen schlecht
für den Kartenleser, wenn man bei einer Schleife dann 10 Karten
zurück springen soll. :)
Bronco schrieb:> Alles per Lochkarten?
Der Programmcode eher auf Lochstreifen!
Auf Lochkarte waren hauptsächlich Daten (Kunden, Lieferanden,
Artikel,..)
Und man kam als "normaler" Programmierer auch nichteinmal in die Nähe
des Rechners.
Man durfte den Lochstreifen an einem Schalter abgeben, der wurde dann
irgendwann vom Bedienpersonal in weißen Kitteln durchlaufen lassen und
konnte ihn dann irgendwann mit eine Liste der Errors wieder abholen. Und
es nach ausbesserung der Fehler noch mal versuchen.
Aber wie muss man sich denn den Build-Vorgang vorstellen?
Hat man den Sourcecode (als Daten) am Schalter abgegeben und einen
Lochstreifen mit Executable zurückbekommen?
Oder hat der Rechner den Sourcecode eingelesen, ins RAM compiliert und
dann aus dem RAM ausgeführt?
Bei uns waren die Quelltexte auch auf Lochkarten.
Ein Programmjob bestand aus einem Stapel Lochkarten, der in einzelne
sections unterteilt war.
Es begann mit ein paar Steuerkarten (Accountkarte mit Projektname bzw.
Kostenstelle etc., dann je nach Bedarf ein paar Karten mit Anweisungen
an das OS, was zu tun ist, z.B. FTN-Compiler aufrufen und dann das
Programm ausführen).
Dann kommt eine spezielle Lochkarte "end of section".
In der zweiten section war dann (wenn in der ersten der Compiler
aufgerufen wird) der komplette Quelltext, je Karte das, was heute eine
Zeile ist.
Danach wieder eine Karte "end of section".
In der der dritten section kam dann die Standardeingabe des Programms,
also was man am Terminal eintippen würde, Zeile für Zeile.
Hinter allen sections kam wieder eine spezielle Karte "end of
information".
Mehrere solche Jobs wurden dann vom Operator in einem Rutsch in den
Kartenleser gefüttert.
Die Standardausgabe des Jobs landet dann auf dem Banddrucker auf
Elefantenklopapier, also die Diagnosemeldungen zu den Anweisungen der
Steuerkarten, evtl. Fehlermeldungen des Compilers, wnen alles gut läuft
die Standardausgabe des gelaufenen Programms, oder bei einem Abbruch der
Kerneldump als Text (Adressen und Hex-Werte des Speichers, Register...).
Bronco schrieb:> Aber wie muss man sich denn den Build-Vorgang vorstellen?> Hat man den Sourcecode (als Daten) am Schalter abgegeben und einen> Lochstreifen mit Executable zurückbekommen?> Oder hat der Rechner den Sourcecode eingelesen, ins RAM compiliert und> dann aus dem RAM ausgeführt?
Es gab den key Punch Operator, eine Sekretärin zum Lochkartenschreiben.
Die bekam einen handschriftlichen Zettel, oder die korrigierten
Lochkarten vom vorherigen Lauf.
Ärmere Programmierer mussten selber stanzen.
Immerhin kann man aus einem Satz von Karten (A=1; DO 100 I = 1, 10 ;
etc.) die Hälfte der Programmzeilen eines neuen Programms
zusammensuchen.
Bronco schrieb:> Aber wie muss man sich denn den Build-Vorgang vorstellen?> Hat man den Sourcecode (als Daten) am Schalter abgegeben und einen> Lochstreifen mit Executable zurückbekommen?> Oder hat der Rechner den Sourcecode eingelesen, ins RAM compiliert und> dann aus dem RAM ausgeführt?
Wir mussten den ganzen Stapel (siehe oben) in einem Regal ablegen, der
Operator kommt von Zeit zu Zeit vorbei und karrt das ganze Regal in den
magischen Raum und füttert alles in den Kartenleser.
In dem Raum, wo man die Karten abgibt, waren auch die Regale für die
Ausgabe auf Endlospapier (sortiert in Fächer nach der Projektnummer,
also anhand der Accountkarte aus der section mit den Steuerkarten.
Man legt also den Stapel mit den Lochkarten ab, und bekommt irgendwann
die Ausgabe auf Papier.
Dann schaut man, was schief gelaufen ist, versucht etwas Zeit an einem
Kartenstanzer zu bekommen, korrigiert bzw. schreibt falsche Karten neu
(gelocht ist gelocht), und gibt den Stapel wieder ab.
Nach ein paar Stunden ...
Klaus Wachtler schrieb:
...viele interessante Dinge...
Das heißt, man konnte dem Computer direkt den Hochsprachen-Sourcecode
auf Lochkarten geben, und dieser hat ihn übersetzt, ausgeführt und man
bekam dann als Ergebnis die Ausgabe zurück?
Bronco schrieb:> Klaus Wachtler schrieb:> ...viele interessante Dinge...>> Das heißt, man konnte dem Computer direkt den Hochsprachen-Sourcecode> auf Lochkarten geben, und dieser hat ihn übersetzt, ausgeführt und man> bekam dann als Ergebnis die Ausgabe zurück?
Genau.
Ich kann mich erinnern, dass ich am Ernst-Reuter-Platz in Berlin, wo die
FU ihren Rechner stehen hatte ab und zu mal eine Lochkarte gefunden
habe. Da lief ich auf dem Weg zur Bibliothek vorbei, von einem 6502
träumend meine Geldvorräte im Geiste zusammenzählend und lugte
sehnsüchtig ins Erdgeschoß, wo die Lochkartenstanzer standen.
Hoffe das das alles nur Fehllochungen waren, die ich da gefunden habe.
Klaus schrieb:> Hoffe das das alles nur Fehllochungen waren, die ich da gefunden habe.
Ja, sorry, das waren meine Fehllochungen.
Man konnte das Ergebnis ja auch auf das Punch-Device schicken, um es
dann mit dem nächsten Programm weiter zu verarbeiten. Dumm nur, wenn die
Daten wegen einer Endlosschleife endlos ausgegeben wurden. Zum Glück
schlug irgendwann das Card-Limit zu und terminierte das Programm, um
dann noch den aktuellen Speicher mit ein paar Seiten Core Dump
auszudrucken :-(
Es war übrigens der P-Pascal Compiler der ETH Zürich, der meine
persönlichen Pascal-Compiler in ca. 30.000 Zeilen P-Code übersetzen
sollte.
Leider war der Karton Lochkarten dann wertlos weil unvollständig.
Übrigens: die FU hatte dort keine Rechner, es war die TU, ein kleiner
wichtiger Unterschied.
Gruß,
Michael
Wir hatten an einem KRS4201
http://www.robotrontechnik.de/index.htm?/html/computer/r4201.htm
einen Lochkartenleser. Von den Datenerfasserinnen wurden auf
DARO-Maschinen
Produktions -und Lohndaten etc. auf Lochkarte ausgegeben, die dann im
Zuge der Programmausführung in das KRS4201 eingelesen wurden. Die
Programme selbst wurden in Algol 60 geschrieben und waren auf
Magnetrommelspeichern
"gelagert" Aufgerufen wurde immer eine Abfolge von Programmen, (eine Art
Batch-Datei, die jeweils per Lochstreifen eingelesen wurde.
Programmeldungen gab man auf sog. Bediendrucker aus, damit war auch
gleich der Programmlauf dokumentiert und falls Fehler auftraten, konnten
die Progarmmierer(innen) sehen, wo es hing.
Jeden Freitag war die Spätschicht für die Programmierer reserviert,
damit sie neue Programme ausprobieren und korrigieren konnten.
Ausgegeben wurden die Resultate auf Magnetband oder Listen eben auf
Parallel-Drucker.
MfG Paul
Michael Appelt schrieb:> Klaus schrieb:>> Hoffe das das alles nur Fehllochungen waren, die ich da gefunden habe.>> Ja, sorry, das waren meine Fehllochungen.
Nicht schlimm. Für mich waren das schöne Andenken. Wann kam man als
kleiner Lehrling schon mal an solche Lochkarten.
> Übrigens: die FU hatte dort keine Rechner, es war die TU, ein kleiner> wichtiger Unterschied.
Richtig. TU. FU ist ja im Südwesten. Bin zutiefst zerknirscht.
Hmmm ... Lochkarten, Compiler, Hiwis die die Stapel durch die Gegend
schleppten ... davon träumte ich damals als ich vor so einer Büchse
http://www.vintagecomputer.net/digital/pdp11-40/PDP11-40_fontpanel.JPG
saß und meine selbst assemblierten Programme binär in den Kernspeicher
geladen habe ...
Erst wenn man das zur Zufriedenheit des Prof. beherrschte durfte man die
"höheren" Gerätschaften wie TTY und Lochstreifenstanzer/leser nutzen ...
Als ich studierte, war an der Uni bereits das Terminal-Zeitalter
angebrochen. Die Lochkartengeräte waren aber noch nicht entsorgt,
sondern wurden in frei zugänglichen Räumen weiterbetrieben. So konnte
man – wenn es einen interessierte – diese alte, aber überaus geniale
Technik hautnah erleben.
Einen Stapel von ca. 500 Karten in den monströsen Kartenleser einzulegen
und zuzusehen, wie dieser den Stapel mit lautem Rattern in weniger als
30 Sekunden verschlang, ist ein Erlebnis, das man nicht so schnell
vergisst :)
Zusätzlich zu diesem Kartenleser gab es auch noch einen automatische
Stanzer (mit dem Dateien mit einem rasenden Tempo auf Lochkarten
gebackupt werden konnten), eine Lochkartenbeschrifter (der auf
bestehende Lochkarten den decodierten Quelltext aufdruckte) und einen
Kettendrucker.
Alles sauschnell und höllenlaut, richtige Mechanik eben, die bis an die
Grenze des physikalisch Machbaren optimiert war :)
Bronco schrieb:> Hat man den Sourcecode (als Daten) am Schalter abgegeben und einen> Lochstreifen mit Executable zurückbekommen?
Aus Sicht der Benutzer (Studenten) gab es sowas wie Executables
garnicht, und Lochstreifen waren sowieso extrem unüblich, die wurden für
NC-Maschinen verwendet, ganz andere Baustelle.
Für die Lochkarten mit dem Sourcecode gab es längliche Kästen wie heute
noch für Karteikarten, die hat man abgegeben und irgendwann wurden sie
der Anlage zum Frass vorgeworfen - es wurde compiliert, wenn kein Fehler
ausgeführt, und der Auftraggeber erhielt seine Lochkarten plus Ausdruck
der Rechenergebnisse oder eben Fehlermeldungen zurück. Was im
Erfolgsfall gedruckt werden sollte musste man natürlich im Programm
formulieren. Der Buildprozess war also für uns Lochkartenstapel ->
Ergebnisausdruck.
Georg
Georg schrieb:> Lochstreifen waren sowieso extrem unüblich
Bei Großrechnern schon, bei „Minis“ (PDP-11, oder das von Paul
genannte KRS-4201, das wohl ein Honeywell-Clone ware) dagegen eher
noch.
Ich weiß gar nicht, ob ich meine BASIC-Mondlandungs-Lochstreifen noch
irgendwo habe. ;-)
Am PDP-11-Clone (K1630) hatten wir allerdings Magnetbänder. Die lagen
zwar in der Rechenstation, aber jeder hatte ein persönliches.
Wenn man sich Eure Erzählungen so anhört, kann man sich schwer
vorstellen, dass damals Computer effizient zu produktiven Zwecken (in
Firmen und Behörden) eingesetzt werden konnte. Die Aufwand, Daten in
eine maschinenlesbare Form zu bringen, muß doch gigantisch gewesen sein,
von den Fehlerquellen ganz abgesehen.
Ich frage mich, wie man damals sichergestellt hat, dass eine so
berechnete Lohnbuchhaltung (o.ä.) tatsächlich halbwegs gestimmt hat.
Bronco schrieb:> Die Aufwand, Daten in> eine maschinenlesbare Form zu bringen, muß doch gigantisch gewesen sein,> von den Fehlerquellen ganz abgesehen.
Nein, so schlimm war das nicht. Die Programmierer haben einen ganz
normalen Quelltext in Algol 60 auf einem sog. DEG (Datenerfassungsgerät)
geschrieben.
Dort konnte man dann auf Lochstreifen ausgeben. Auf dem KRS konnte man
einen Kompiler laufen lassen, den Lochstreifen einlesen und übersetzen
lassen und die dabei entstehende ausführbare Datei entweder auf dem
Trommelspeicher "lagern", auf Magnetband ausgeben oder auch wieder
ausstanzen lassen. (Archivierung)
Man konnte (wenn Rechnerzeit frei war (o.g. Freitag Nachmittag)) auch
den
Quelltext direkt in den Bediendrucker oder das Bildschirmterminal
wämmern und brauchte den Zwischenschritt von oben nicht zu machen.
Fehler beim Kompilieren konnte man auch gleich auf den Bediendrucker
ausgeben lassen und enteder gleich beheben (Semikolon vergessen oder so)
Größer "Späße" wurden dann offline verbessert und erneut dem
freundlichen
Kompiler zum Fraß vorgeworfen.
Anders mache ich es heute auch nicht...
MfG Paul
Helmut Lenzen schrieb:> Wie Paul, du hast noch einen Stanzer an deinem PC :=)
Wie willst du denn sonst deine Software so archivieren, dass man sie
auch in 100 Jahren noch entziffern kann? 8.)
Bronco schrieb:> Ich frage mich, wie man damals sichergestellt hat, dass eine so> berechnete Lohnbuchhaltung (o.ä.) tatsächlich halbwegs gestimmt hat.
Hallo,
die Lohndaten wie geleistete Stunden wurden gelocht, d.h. am
Kartenlocher eingegeben.
Um Tippfehler zu verhindern wurde an einem 2. Arbeitsplatz Prüfgelocht,
d.h. es wurde mit der vorhandenen Karte erneut eingegeben und die
Tasteneingabe mit den vorhandenen Löchern verglichen.
Gruß,
Michael
Bronco schrieb:> Ich frage mich, wie man damals sichergestellt hat, dass eine so> berechnete Lohnbuchhaltung (o.ä.) tatsächlich halbwegs gestimmt hat.
Das war nie mehr Arbeit, als manuell, im Gegenteil, es wurde
automatisiert gerechnet, addiert etc., aber ja: Buchhaltung war damals
teuer.
Damals hat man sich bei den eingegebenen Daten noch Mühe gegeben, damit
sie gestimmt haben, denn jeder Fehler machte Mühe.
Heute wird drauf geschissen und täglich mehrmals Fehler gemacht die dann
der Kunde ausbaden muss.
Bronco schrieb:> Wenn man sich Eure Erzählungen so anhört, kann man sich schwer> vorstellen, dass damals Computer effizient zu produktiven Zwecken (in> Firmen und Behörden) eingesetzt werden konnte.
Computer wurden früher nicht für jeden möglichen Kleinkram eingesetzt,
sondern nur für einige wenige Vorgänge, bei denen die Produktivität
gewährleistet war. Für Geschäftsbriefe o.ä. hätte man damals eine
Schreibmaschine verwendet und keinen Computer, und zwar vor allem aus
Kostengründen.
Irgendwann gab es dann auch Grenzfälle, z.B. bei elektrischen
Schreibmaschinen mit Textspeicher. Kugelkopfschreibmaschinen
(insbesondere von IBM) und Terminals mit Kugelkopfdrucker waren
mechanisch sehr ähnlich aufgebaut.
> Die Aufwand, Daten in> eine maschinenlesbare Form zu bringen, muß doch gigantisch gewesen sein,> von den Fehlerquellen ganz abgesehen.
Es gab einen Haufen mechanischer Hilfsmittel, um sich das Leben einfach
zu machen. Damals ging man viel bewusster mit der Ressource Computer um,
insbesondere auch wegen der exorbitanten Kosten.
In meiner Kindheit begleitete ich meine Eltern des öfteren zum Einkaufen
in den Großmarkt, vergleichbar mit heutzutage Metro oder Citti. An den
Regalen befand sich bei jedem Artikel ein Fach mit Lochkarten. Man nahm
also z.B. eine Flasche Ketchup und die zugehörige Lochkarte heraus. Am
Einkaufswagen befand sich ein Klemmbrett für die Lochkarten.
An der Kasse wurde der eigene Einkaufswagen dann einem anderen leeren
Einkaufswagen gegenübergestellt. Man gab der Kassiererin den Stapel
Lochkarten und lud die Artikel dann auf den neuen Wagen um. Die
Kassiererin kontrollierte dabei die Vollständigkeit der Lochkarten. Das
ging alles mindestens so schnell wie heute an der Supermarktkasse. Der
leere eigene Einkaufswagen wurden zum Schluss umgedreht für den nächsten
Kunden.
Der Stapel Lochkarten enthielt als erste Karte die eigene Kundenkarte
und wurde auf ein Transportband oberhalb des Durchganges zwischen des
Kontrollstationen gelegt. Ich war als Kind immer ganz begeistert davon,
wie schnell die Lochkarten dann zum Lochkartenleser transportiert und
dort automatisch eingelesen wurden. Beim Hinausgehen ging man dann an
der eigentlichen Kasse vorbei und bezahlte. Dort lag schon die auf einem
unglaublich schnellen Kettendrucker erstellte Rechnung bereit.
Leider weiß ich nicht mehr, ob die Lochkarten schon gleich beim Einlesen
wieder sortiert wurden oder ob das separat erfolgte. Schließlich gab es
ja Tausende verschiedener Artikel mit jeweils eigenen Kartenfächern.
Die Relikte kann man heute in manchen Großmärkten noch sehen. Vielleicht
hat sich schon manch einer darüber gewundert, dass etliche ältere Regale
an der Vorderkante einen tiefen Schlitz aufweisen. Dort lagen früher die
Lochkarten drin.
> Ich frage mich, wie man damals sichergestellt hat, dass eine so> berechnete Lohnbuchhaltung (o.ä.) tatsächlich halbwegs gestimmt hat.
Wie schon erwähnt, gab es viele Hilfsmittel. Meine Eltern hatten für die
Buchhaltung ein System von Taylorix, welches aber nicht computergestützt
war. Den Begriff "Buchungsjournal" findet man auch heutzutage noch in so
ziemlich jeder Buchhaltungssoftware. Er stammt aber von Taylorix:
http://www.computermuseum-muenchen.de/computer/taylorix/http://www.stb-betzwieser.de/aktuelles/ausstellung/kategorien-1/taylorix.php
Yalu X. schrieb:> Als ich studierte, war an der Uni bereits das Terminal-Zeitalter> angebrochen. Die Lochkartengeräte waren aber noch nicht entsorgt,> sondern wurden in frei zugänglichen Räumen weiterbetrieben.
Es gab Anfang der 80er am Mainframe der Informatiker (TR440 von ~1970)
noch beides. Denn von den Terminals gab es relativ wenige (darunter aber
immerhin ein grafikfähiges mit Rollkugel), so dass die Anfänger noch
ganz klassisch per Lochkarte und Papierstapel arbeiten durften.
Udo Schmitt schrieb:> ie schönen Kettendrucker. Unsere Firma hat ihren letzten von ca. 12> Jahren verschenkt.
Konnte der überhaupt Umlaute drucken? Von Grafik mal ganz abgesehen. Und
das Endlospapier verursachte auch seine Kosten, ganz extrem wenn man
Durchschläge brauchte.
Georg
Bronco schrieb:> Oder hat der Rechner den Sourcecode eingelesen, ins RAM compiliert und> dann aus dem RAM ausgeführt?
RAM war teuer. Und Compiler brauchten damals oft mehrere Durchläufe. Da
konnte beispielsweise Magnettrommel-Speicher dazwischen liegen, oder
früher Plattenspeicher.
Im klassischen Batch-Ablauf bei den Mainframes wurden die Jobs von den
Lochkarten erst einmal von einem kleinen Vorrechner eingesammelt und
zusammen auf einem Band geparkt. Das Band landete dann irgendwann am
Mainframe und wurde von dem abgearbeitet. Mit den Ergebnissen lief es
ähnlich, d.h. der Mainframe schmiss es auf Band aus und der Vorrechner
schob es dann auf den Drucker.
Georg schrieb:> Udo Schmitt schrieb:>> ie schönen Kettendrucker. Unsere Firma hat ihren letzten von ca. 12>> Jahren verschenkt.>> Konnte der überhaupt Umlaute drucken? Von Grafik mal ganz abgesehen. Und> das Endlospapier verursachte auch seine Kosten, ganz extrem wenn man> Durchschläge brauchte.
Nur, wenn die Umlaute auf dem umlaufenden Stahlband waren. Also nein :-)
Georg schrieb:> Konnte der überhaupt Umlaute drucken? Von Grafik mal ganz abgesehen. Und> das Endlospapier verursachte auch seine Kosten, ganz extrem wenn man> Durchschläge brauchte.
Umlaute bin ich mir nicht sicher. Ich weiss nur, dass die Jungs, die bei
uns die Programme für IBM Host schrieben statt geschweifte Klammern
Umlaute eingetippt hatten.
Irgendwann hatte ich mal rausgefunden, das das eigentlich nur daran lag,
dass der alte C Compiler fest den US EBCDIC Zeichensatz benutzte, der
IBM Rechner bzw. die Terminals aber auf deutschen EBCDIC Zeichensatz
konfiguriert waren. Man hätte den neueren Compilern durchaus als
Parameter mitgeben können dass die Sourcen als deutscher EBCDIC codiert
wären, aber keine hat sich getraut das alles umzustellen.
Das Druckpapier war günstig, Durchschläge gabs ja nicht war ja reine SW
Entwicklung. Das war Recyclingpapier A3, das kam bei jedem Fehler als
Dump kiloweise aus dem Drucker gerattert.
Georg schrieb:> Konnte der überhaupt Umlaute drucken?
Im wissenschaftlichen Kontext waren 6-Bit Zeichensätze recht beliebt. Da
fehlten nicht nur die Umlaute, sondern auch die Kleinbuchstaben. Dafür
passten 6 Zeichen in ein 36-Bit Wort (1), oder 10 in ein 60-Bit Wort
(2). Textverarbeitung war sowieso nicht das Mass der Dinge auf diesen
Rechnern.
1: Die Begrenzung externer Namen in frühem C auf eindeutige 6 Zeichen
dürfte damit zu tun haben.
2: Weshalb man im Wirth'schen Pascal-Handbuch einem seltsam anmutenden
fest eingebauten 10-Zeichen String begegnete (implementation report).
Da aber auch 8-Bit Zeichensätze aufkamen fand man bei den Maschinen ein
ziemliches Wirrwar an Zeichensätzen vor. Die 60-Bit CDCs verwendeten
dann beides, 6 Bits und 8 Bits, je nach Kontext und Laune. War aber
letztlich egal, da deren Prozessoren Hardware keinerlei
Zeichenverarbeitung kannten, sondern eben nur 60 Bits breite Daten mit
Wortadressierung.
Bei den IBMs war es ab 360 klarer, die hatten Stringverarbeitung und
Byteadressierung und haufenweise Codepages für die jeweiligen nationalen
Umlaute. Aber dafür EBCIC- statt ASCII-Code.
Meine Güte .... und ich dachte schon, ich wäre ein alter Sack! <:-}
Aber sehr interessant, das alles. Meine "Karriere" begann erst 1983 mit
einem VC-20.
Chris D. schrieb:> Meine "Karriere" begann erst 1983 mit> einem VC-20.
Meine 1984 mit einem IBM PC XT clone für viel Geld.
Aber ich war/bin in einer Firma die heute noch die Software für alle
möglichen Betriebssysteme schreibt.
Unsere Hauptsoftware gab es damals für Windows16, Win-NT, OS/2, AIX,
SUN, HP-UX, AS400, VAX-MVS, BS-2000, und IBM Host mit MVS, CICS, und
noch 2 oder 3 anderen IBM Host Subsystemen.
Insofern hatte ich mehr oder weniger intensive Berührung mit diversen
Rechnern und Betriebssystemen, zumal wir alle diese Systeme im eigenen
Haus hatten.
A. K. schrieb:> 1: Die Begrenzung externer Namen in frühem C auf eindeutige 6 Zeichen> dürfte damit zu tun haben.
Bzw. „geerbt“ vom Linker, der wiederum zuvor FORTRAN gelinkt hat,
welches ebenfalls nur 6-Zeichen-Bezeichner kannte. Daher lesen
sich ja FORTRN PRGRME AUCH IMMER SO SCHLCH WAS WILL MAN MACHEN MIT
NUR SECHS ZEICHN? ;-)
Aber gut möglich, dass der das wiederum aus den 36-Bit-Zeichen
herleitete … auf der PDP-11 wiederum passten halt die 6 Zeichen
hervorragend in zwei RADIX50-Worte.
Jörg Wunsch schrieb:> Bzw. „geerbt“ vom Linker, der wiederum zuvor FORTRAN gelinkt hat,> welches ebenfalls nur 6-Zeichen-Bezeichner kannte. Daher lesen> sich ja FORTRN PRGRME AUCH IMMER SO SCHLCH WAS WILL MAN MACHEN MIT> NUR SECHS ZEICHN? ;-)
Stell dich nicht an, immerhin kann man Leerzeichen auch innerhalb von
Namen einstreuen, wie man will.
Das erlaubt sehr schöne Schreibweisen!
Udo Schmitt schrieb:> Weiss einer von euch noch was eine Patch-Area in einem Programm ist?
Klar. Wenn der Binärcode gepatcht werden musste. An der zu fixenden
Stelle landet dann ein Sprung in die Patch-Area und in dieser der
Ersatzcode, der anschliessend zurück sprang.
Beim AIM65 (6502 Rechnerlein) hatte Rockwell in seltsam anmutender
Hybris im Monitor keine Sprungleiste implementiert. Weshalb Anwendercode
in den Zusatz-ROMs direkt eine Funktion auf Adresse $EBDB aufrief.
Spätere Korrekturen durften folglich die Adresse nicht ändern und am
Ende vom ROM stapelten sich solche Flicken.
Ich meine mich zu erinnern, dass auch IBMs XT BIOS ein paar solcher
Flicken enthält.
A. K. schrieb:> Klar. Wenn der Binärcode gepatcht werden musste. An der zu fixenden> Stelle landet dann ein Sprung in die Patch-Area und in dieser der> Ersatzcode, der anschliessend zurück sprang.
Genau, weil eine offizielle Auslieferung auf Band wäre viel zu aufwändig
gewesen und der Betrieb des Hosts hätte zum Einspielen unterbrochen
werden müssen.
So konnte das des Systemoperator direkt im laufenden Betrieb patchen.
Ich komme wie gesagt aus der PC Ecke, als ich das das erste Mal erklärt
bekam waren meine Augen größer als 5Mark Stücke :-)
Udo Schmitt schrieb:> So konnte das des Systemoperator direkt im laufenden Betrieb patchen.
Und so etwas wird doch heute auch noch bei SPS-basierten Steuerungen
gemacht, wenn eine Anlage zwischendurch nicht angehalten werden darf. So
übel STEP7 auch ist, zumindest hat Siemens den Austausch von FB/FC usw.
im laufenden Betrieb wohl besser hinbekommen als andere Anbieter.
Dennoch kracht es aber ganz gewaltig, wenn z.B. die Daten in einem DB
auch nur etwas anders angeordnet sind.
Helmut Lenzen schrieb:> Wie Paul, du hast noch einen Stanzer an deinem PC :=)
Ich hab' noch einen Stanzer in Berlin....
;-)
Ha! Hast Du mich erwischt -ich habe mich verdrückt ausgekehrt.
MfG Paul
Udo Schmitt schrieb:> A. K. schrieb:>> Klar. Wenn der Binärcode gepatcht werden musste. An der zu fixenden>> Stelle landet dann ein Sprung in die Patch-Area und in dieser der>> Ersatzcode, der anschliessend zurück sprang.>> Genau, weil eine offizielle Auslieferung auf Band wäre viel zu aufwändig> gewesen und der Betrieb des Hosts hätte zum Einspielen unterbrochen> werden müssen.> So konnte das des Systemoperator direkt im laufenden Betrieb patchen.> Ich komme wie gesagt aus der PC Ecke, als ich das das erste Mal erklärt> bekam waren meine Augen größer als 5Mark Stücke :-)
Mittlerweile hält das wieder Einzug in Marktübliche Betriebssysteme:
http://en.wikipedia.org/wiki/Kpatch
Bei uns gabs 1973 eine IBM1620 im geheiligten Raum. Morgens wenn wir
Studenten zu früh kamen, war der Raum noch nicht auf einer der 1620
genehmen Temperatur und nichts lief bis dass der HiWi die Klimaanlage
passend reguliert hatte.
Unsere FORTRAN Programme mussten wir selber auf Karten stanzen. Käse
wenn man sich vertippt hatte oder Fehler im Code waren.
Ein Jahr später gab es dann so eine kleine Olivetti, halb so gross wie
eine Schreibmaschine, mit einer kleinen Tastatur und Ausgabe über
eingebautem Drucker. Wie die programmiert wurde kann ich mich nur noch
schemenhaft erinnern, auf jeden Fall schon was komfortableres als
Assembler.
Ja den AIM65 hab ich auch noch irgendwo rumstehen, einschließlich
einiger Compact-Cassetten mit Programmen drauf. 1979 gekauft mit
sagenhaften 1k RAM, bald auf 4k erweitert, später auf 32k. Dazu die
beiden teuren BASIC-ROMs ca. 300DM damals, auch ein Assembler im ROM.
Später hatte ich dafür ein "Elekterminal" mit SW-Fernseher dran.
Es gab einen AIM65-Emulator auf dem AppleÜÄ, vom Franzis-Verlag/mc, aber
der konnte natürlich die echte Hardware nicht emulieren. Damit ließe
sich heute der wieder auf dem PC emulieren.
Für die Lochkarten gab es an der TU Dresden am Zelleschen Weg eine Tür
mit dem Schild "Kundenlocherei".
Dahinter hätte sich auch eine sadistische Studentenvereinigung befinden
können.
Es war aber: die wissenschaftliche, marxistisch-leninistische und
friedenserhaltende Stelle zur Umsetzung des Programmes des
??.Parteitages der sozialistischen Einheitspartei Deutschlands (SED) für
die planwirtschaftlich gebotene Übertragung eines PL/1-Quelltextes auf
Lochkarten.
Krank, oder?
Bronco schrieb:> Aber wie hat man ohne Bildschirm-Terminal Sourcecode eingegeben?
Mit einem ganz gewöhnlichen Fernschreiber. Ein weit verbreiteter Editor
war z.B. TECO von DEC. Durch entsprechende Kommandos hat man sich im
Text bewegt und ihn bearbeitet. Ab und zu war es gut, mal ein paar
Zeilen zurück zu gehen und sie vollständig zu Papier zu bringen ;-)
Mit TECO konnte man aber auch ganze Makros zur Bearbeitung des Textes
bauen.
http://de.wikipedia.org/wiki/TECO_%28Texteditor%29
Wolfgang schrieb:> Ein weit verbreiteter Editor> war z.B. TECO von DEC
Editor war damals noch lange nicht. Egal ob Lochkarte oder Lochstreifen,
ein A auf der Tastatur tippen und sofort Ratsch waren die entsprechenden
Löcher gestanzt. Bei Fehlern neue Karte oder bei Lochstreifen zurück und
DEL (alle Löcher) drüberstanzen.
Fördert sehr das fehlerfreie Tippen.
Georg
Bronco schrieb:> Ich kann mir ja noch vorstellen, dass ein damaliger Computer> Maschinencode von Lochkarten lesen und abarbeiten konnte.
Falsch. Ganz falsch. Was man da gestanzt hatte, war Quellcode und der
auf dem Mainframe werkelnde Compiler hat daraus den eigentlichen
Maschinencode gemacht - den man freilich NIE selber gesehen hat.
Es ist schon erstaunlich, wie schnell es geht, bis daß die Leute niht
mehr begreifen können, was doch die eigentlichen Grundlagen ihrer
üblichen Betätigung sind.
Also:
Thema Lochkarten:
Da gab es im (oder sollte man besser sagen "beim") Rechenzentrum einen
Raum, wo Lochkarten-Stanzgeräte standen. Sah so aus wie eine Art zu groß
geratene Schreibmaschine auf einem Schreibtisch. Dort konnte man seinen
Quelltext in die Maschine reinhacken und mit jedem Tastendruck wurde
eine Spalte auf der Karte gestanzt. Vertippt? --> neue Karte und
nochmal.
Hatte man seinen Quelltext fertig getippt, kam er in eine Art flache
Blechkiste. Nun gab es ein winzig kleines Fenster in der fetten
Betonwand zwischen dem Userbereich und dem eigentlichen Rechenzentrum.
Dort konnte man auf nen Klingelknopf drücken und nach angemessener
Wartezeit erschien dann auch so ein Admi, um den Blechkasten mit dem
Quellcode entgegenzunehmen und dabei Kostenstelle und sonstige
kommerziellen Details abzufragen.
Nach einem Tag durfte man dann wieder an diesem Fensterchen antanzen und
bekam seinen Blechkasten zurück. Obendrauf lag ein mehr oder weniger
dicker Stapel von Leporellopapier in A3, quer gedruckt mit nem
Paralleldrucker (jede Zeile mit eigenem Wellengang, also kein Zeichen
auf der Höhe wie das andere und obendrein bei O und Nullen das Papier
drin halb rausgehackt).
Das war's.
War der Stapel ganz dünn, dann bestand er nur aus dem Abrechnungsbogen
mit Fehlermeldung, pro Sekunde Bearbeitungszeit etwa 100 Mark teuer.
Ätsch.
Thema Lochband:
Editieren von Quellcode mit einer Art Teletype direkt am Rechner,
natürlich OHNE den aktuellen Text sehen zu können. Dafür hatte man ja
seine Übersetzungsliste. Den zu editierenen Quelltext mußte man zuerst
in den Lochbandleser einlegen und den Lochbandstanzer mit ner frischen
Rolle Lochband bestücken. Dann Editor starten und los gings: COPY (bis
Zeile) 73, EDIT, (Zeile 74 wurde auf Teletype ausgedruckt) dann Zeile
nochmal und bittesehr richtig eintippen, dann PUNCH. Dann weiter mt COPY
196, EDIT.. und so weiter. Höchst komfortabel, sag ich euch!!!!
Natürlich bekam man als Student seine Rechenzeit zu den besten Zeiten,
also so etwa von 2.00 "morgens" bis 4.30 "morgens". Also, wo man am
besten konzentriert und wach war.. Anschließend auf den Knopf am Stanzer
drücken wegen des Nachlaufes, Lochband abreißen und aufwickeln. Dann
Editor beenden, den Fortran-Compiler reinladen, Lochband in den Leser
laden, Compiler starten.. warten bis er fertig war und nicht gemeckert
hat, Lochband nochmal aufrollen, nochmal in den Leser für den zweiten
Pass, neues Band in den Stanzer, zweiten Pass starten. Quell-Lochband
aufwickeln, vom Compiler gestanztes Band mit dem Objektcode aufwickeln,
Compiler beenden, Systemlinker laden, Objektcodeband in den Leser,
Linker starten, dann endlich das eigene Werk bewundern.. im Allgemeinen
gab's da nix außer entweder einem Ausdruck auf dem Paralleldrucker oder
wieder ein Lochband zu bewundern..
Ich hab wahrscheinlich zu meiner Studentenzeit den Äquator aus Lochband
mindestens dreimal aufgewickelt, wenn nicht noch mehr. Aus der Zeit
stammt auch, daß ich vorher lieber gründlich nachdenke. Die heurigen
Hasen machen es genau anders herum: zuerst was eintippen, dann Compiler
starten, dann Debugger starten, dann sehen (oder nicht) was draus
geworden ist - huch, da kommt ja was ganz anderes raus, als ich mir
gedacht habe.. nee, diese Spezies hat nicht gedacht.
W.S.
W.S. schrieb:> Falsch. Ganz falsch. Was man da gestanzt hatte, war Quellcode und der> auf dem Mainframe werkelnde Compiler hat daraus den eigentlichen> Maschinencode gemacht - den man freilich NIE selber gesehen hat
Doch, wir hatten 1974 bei der IBM1620 eine Speicher-Abbild Möglichkeit
und durften uns mit der Interpretation der Nullen und Einsen vergnügen.
Der Prof und der Labor Hiwi wollten uns augenscheinlich quälen.
Albert M. schrieb:> Doch, wir hatten 1974 bei der IBM1620 eine Speicher-Abbild Möglichkeit
Analyse von Dumps war eine sehr verbreitet Debugging-Technik.
W.S. schrieb:> dann Compiler> starten, dann Debugger starten, dann sehen (oder nicht) was draus> geworden ist
Das habe ich öfter als alternativen, aber etablierten
Software-Entwicklungsstil kennengelernt, ich nenne das analytisch
anstelle von synthetisch - man fängt mit einem einzelnen NOP als
Programm an, und von da an sucht man mit Debuggerhilfe nach Gründen,
warum nicht das gewünschte rauskommt.
Georg
Bronco schrieb:> Hallo Freunde,>> die Frage ist ein wenig Off Topic, aber ich frage mich, wie man zur Zeit> der Lochkarten eine Hochsprache wie Fortran umsetzen konnte.> Ich kann mir ja noch vorstellen, dass ein damaliger Computer> Maschinencode von Lochkarten lesen und abarbeiten konnte.> Aber wie hat man ohne Bildschirm-Terminal Sourcecode eingegeben?
Überraschung: zeitgenössische Telefone und Schreibmaschinen hatten auch
keine Displays. :-)
Ich habe noch als Gymnasiast Stunden und Tage an so einem Teil
http://www.columbia.edu/cu/computinghistory/026.html
verbracht, um Fortran- und dann später im Studium auch PL/I-Programme
abzulochen. Da der 026 z.B. kein Semikolon konnte, mußte man mit
Ersatzdarstellungen arbeiten, also ",." statt ";". Später gab es dann
zusätzlich 029, die hatten einen erweiterten Zeichensatz.
https://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV4002.html
Dummerweise waren die natürlich immer als erste besetzt. :-)
> Wie wurde der Compiler in den Computer geladen (oder war er fest> verdrahtet)?
Nein, auf Tape oder auf Platte. Die IBM 7094 hatte durchaus schon
Festplatten.
http://en.wikipedia.org/wiki/IBM_7090http://en.wikipedia.org/wiki/History_of_IBM_magnetic_disk_drives> Und wo wurde der vom Compiler erzeugte Maschinencode gespeichert?> Alles per Lochkarten?
Gab's auch.
>> Hat jemand vielleicht ein paar interessante Links?http://ibm-1401.info/1401-FORTRAN-Illustrated.html
Kann man sich heute gar nicht mehr vorstellen.
Wolfgang S. schrieb:> Überraschung: zeitgenössische Telefone und Schreibmaschinen hatten auch> keine Displays. :-)
Das Telefon in unserer WG hatte damals schon einen Gebührenzähler mit
Ziffern.
Klaus Wachtler schrieb:> Wolfgang S. schrieb:>> Überraschung: zeitgenössische Telefone und Schreibmaschinen hatten auch>> keine Displays. :-)>> Das Telefon in unserer WG hatte damals schon einen Gebührenzähler mit> Ziffern.
Es war ein Kommentar zu "wie hat man ohne Bildschirm-Terminal Sourcecode
eingegeben?", also die Verwunderung darüber, wie die Text- oder
Zifferneingabe auch ohne visuelle Rückkopplung funktioniert hat. Ein
Gebührenzähler ist dafür nicht hilfreich.
Ein noch weniger bekanntes resp. erinnertes Feature damaliger Locher ist
übrigens das sog. "Prüflochen". Ich selber habe das nie benutzt,
sondern die Compiler die Tippfehler raussuchen lassen, es war aber bei
einigen Datenerfassungen nützlich, die ich damals organisiert habe. Im
Prüflochmodus wurden die fertig gelochten Karten erneut eingelegt, statt
der Leerkarten, und dann erneut "abgelocht", wobei aber nicht gelocht,
sondern nur verglichen wurde. Ergab sich eine Diskrepanz, blockierte das
Gerät und man konnte z.B. korrigieren, indem man den Locher die Karte
bis zu dem Punkt duplizieren ließ und dann ausbesserte. So hat man auch
"editiert".
Ein weitereres Feature dieser gar nicht so trivialen Geräte war eine
Programmiertrommel, mit dem man das Verhalten beim Lochen spaltenweise
steuern konnte - Festwerte, Sprung nach Spalte x, etc. Details findet
man vielleicht noch irgendwo im Web.
Andreas Schweigstill schrieb:> Das> ging alles mindestens so schnell wie heute an der Supermarktkasse.
In meiner Kindheit war der Beruf einer Kassierin beim Hofer (Anm. Hofer
= österreichischer Aldi) ein angesehener Beruf. Die Kassierinnen kannten
alle Preise aller Produkte auswendig und tippten die in einer Windeseile
in die Kasse, dass einem schwindlig wurde. Geschätzt würde ich mal
sagen, dass 80% aller heutigen Kassierinnen selbst mit ihren
Scannerkassen dieses Tempo bei weitem nicht erreichen.
W.S. schrieb:> Ich hab wahrscheinlich zu meiner Studentenzeit den Äquator aus Lochband> mindestens dreimal aufgewickelt, wenn nicht noch mehr. Aus der Zeit> stammt auch, daß ich vorher lieber gründlich nachdenke.
In meiner Studentenzeit kriegten wir ebenfalls unsere Jobs des Nachts
gerechnet. Und zwar jeder Job genau ein einziges mal pro Nacht.
In jeder Woche gab es eine Übung, pro Übung 3 Stück 2 Wochen später
abzuliefernde Aufgaben. Bei genau einem Compilerlauf täglich war ein
vergessenes ';' eine mittlere Katastrophe. Wer 10 Compilerläufe brauchte
um seine Syntaxfehler auszumerzen hatte kaum noch Chancen eventuelle
Logikfehler zu beheben. Beherrschung der Syntax war das um und auf um
weiter zu kommen.
Wolfgang S. schrieb:>> Wie wurde der Compiler in den Computer geladen (oder war er fest>> verdrahtet)?>> Nein, auf Tape oder auf Platte. Die IBM 7094 hatte durchaus schon> Festplatten.
Wobei man sagen muss, dass Platten ein Vermögen gekostet haben bei einer
Kapazität, die einem heute nur noch ein müdes Lächeln entlockt.
Auch interessant: Die 'ROM's für die Apollo-Mondflüge wurden von Hand,
äh, gefädelt. (es war Kernspeicher)
https://www.youtube.com/watch?v=YIBhPsyYCiM
(ab 20:35)
>> Die IBM 7094 hatte durchaus schon Festplatten.Jörg Wunsch schrieb:> Die so genannten „Waschmaschinen“. ;-)
Ich hatte auch solche "Waschmaschinen" (m.E.n aus Bulgarien) bei der
Materialbörse von Onkel Robotron in Karl-Marx-Stadt erbeutet
Die hatten, glaube ich wnigstens 19MB Kapazität. Zwei davon habe ich
mittels einer selbstgebauten Anpass-Karte an einem A5120 Bürocomputer
betrieben. Der war der "Materialverwaltungsrechner" im Zentrallager und
brauchte Speicherplatz.
MfG Paul
Karl Heinz schrieb:> Wobei man sagen muss, dass Platten ein Vermögen gekostet haben bei einer> Kapazität, die einem heute nur noch ein müdes Lächeln entlockt.
Naja, meine erste 20MByte NEC Platte von 1986 hatte auch rund 900DM
gekostet.
Paul Baumann schrieb:> Die hatten, glaube ich wnigstens 19MB Kapazität.
Reicht ja locker fuer 4 Fotos......
Karl Heinz schrieb:> Auch interessant: Die 'ROM's für die Apollo-Mondflüge wurden von Hand,> äh, gefädelt. (es war Kernspeicher)
Kernspeicher war doch RAM?
W.S. schrieb:> Es ist schon erstaunlich, wie schnell es geht, bis daß die Leute niht> mehr begreifen können, was doch die eigentlichen Grundlagen ihrer> üblichen Betätigung sind.
Hmmm... von 1975 bis 2015... sind ja nur 40 Jahre, das ist echt verdammt
schnell.
Klaus Wachtler schrieb:> Karl Heinz schrieb:>> Auch interessant: Die 'ROM's für die Apollo-Mondflüge wurden von Hand,>> äh, gefädelt. (es war Kernspeicher)>> Kernspeicher war doch RAM?
In dem Fall nicht.
Der Lesedraht ging entweder durch den Ring durch oder nicht durch.
Dieser Speicher wurde wirklich in Handarbeit tatsächlich 'programmiert'.
Jörg Wunsch schrieb:> Helmut Lenzen schrieb:>> Reicht ja locker fuer 4 Fotos.>> Damals gab's ja auch den berühmten Snoopy als ASCII-Art. :)
Oh. Ja.
Die wurden damals regelrecht 'im Untergrund' gehandelt.
Ich hatte einen 'Jesus' und einen Snoopy Calender aus ca. 1965 (war ab
1982 an der Uni).
Im Rechenzentrum durften wir die nicht durch den Drucker jagen, das
hätte Ärger gegeben. Aber im JCL-Praktikum hatten wir unsere eigene
IBM-370/115 mit Kettendrucker :-) (und 4 MB Hauptspeicher in 2
Schränken, 2 Waschmaschinen, Lochkartenleser, Operator-Terminal mit
eingebranntem Bild und riesigem Notausknopf. gebootet wurde von einer 8'
Floppy)
An optional integrated printer attachment permits use of the newly-announced IBM 3203 printer, with speeds of 600 or 1,200 lines per minute,
1200 lines per minute sind 20 Zeilen in der Sekunde oder bei einer
Standard-80 Zeilen Seite ca 4 Sekunden pro Seite.
Hmm. Da sieht so mancher Laserdrucker heute alt aus. Von Tinenpissern
reden wir erst mal gar nicht :-)
(OK, ok. Das Schriftbild ist nicht zu vergleichen)
Karl Heinz schrieb:>> Kernspeicher war doch RAM?>> In dem Fall nicht.> Der Lesedraht ging entweder durch den Ring durch oder nicht durch.> Dieser Speicher wurde wirklich in Handarbeit tatsächlich 'programmiert'.
Das hatte ich auch noch gemacht bei Siemens Prozessrechnern. Das war
bei Softwareänderungen ganz übel......
ououfiodfu schrieb:>> In dem Fall nicht.>> Der Lesedraht ging entweder durch den Ring durch oder nicht durch.>> Dieser Speicher wurde wirklich in Handarbeit tatsächlich 'programmiert'.>> Das hatte ich auch noch gemacht bei Siemens Prozessrechnern. Das war> bei Softwareänderungen ganz übel......
Und ich dachte immer, dass Abtippen von seitenlangen Hexdump aus
1980er-Computer-Magazinen sei mühsam...
Vor allem, wenn man aus der Aprilausgabe ein Programm abtippt, das den
Atari ST beschleunigen soll, indem es angeblich die Taktfrequenz
irgendwie hochsetzt von 8MHz auf 8.wenig.
Und wenn man es fehlerfrei geschafft hat und es tatsächlich startet,
gibt es aus "April, April"...
(Glaube, das Pamphlet hieß "ST-Magazin").
ymmd
na wer das nicht geblickt hatt dem gehörte es nicht anders.
etwas HW Kenntis hätte den Unfug sicher vermieden, ebenso wenn man das
mal
im kopf dissasambliert hätte, aber dazu musste man schon etwas tiefer in
die materie schauen können.
Namaste
Jörg Wunsch schrieb:> Die so genannten „Waschmaschinen“. ;-)
So eine hatte ich an meinem ersten Z80 System. Was war ein Teil von DEC
5MB Fest, 5MB Wechselbar. 80Kg schwer. Der Controller war ein einziges
TTL-Grab. Hat mich ziemlich viel Nerven gekostet bis das ging. Das war
natürlich eine riesiger Sprung nach vorne. Die Kumpels die so etwas
nicht
hatten mussten sich noch mit Lochstreifen oder Kassettenrecordern
abplagen.
Erleuchteter schrieb:> Was war ein Teil von DEC> 5MB Fest, 5MB Wechselbar. 80Kg schwer.
Ja, sowas in der Gewichtsklasse habe ich für meine HP2100. Dreizehn Zoll
Plattendurchmesser. Allerdings nur mit je 2.5MB Speicherplatz.
Klaus Wachtler schrieb:> Aprilausgabe
Ich erinnere mich noch, dass es beim Amiga eine spezielle
Tastenkombination gab, mit der man eine Überspannung erzeugen konnte,
die zu einem gezielten Umprogrammieren der CustomChips führte, wodurch
der Chipsatz auf eine neuere Generation gepatch wurde...
Jörg Wunsch schrieb:> Wolfgang S. schrieb:>> Die IBM 7094 hatte durchaus schon Festplatten.>> Die so genannten „Waschmaschinen“. ;-)
nein die waschmaschinen waren die aus der udssr :D
So, jetzt wurde einige Male behauptet, man hätte die Ausdrucvke auf der
IBM mit Kettendruckern gedruckt - es waren vermutlich Trommeldrucker.
1 Walze mit rundum verteilten Ascii-Zeichen.
132 Hämmerchen, 1 pro Stelle, klopft im richtigen Moment das Papier an
die Type auf der Walze, die gerade vorbeirauscht. Daher erkennt man ein
Verwischen in vertikaler Richtung.
1-2 Seiten pro Sekunde schätz ich, das schafft kein Kettendrucker.
Gruß,
Michael
Michael Appelt schrieb:> So, jetzt wurde einige Male behauptet, man hätte die Ausdrucvke> auf der> IBM mit Kettendruckern gedruckt - es waren vermutlich Trommeldrucker.>> 1 Walze mit rundum verteilten Ascii-Zeichen.> 132 Hämmerchen, 1 pro Stelle, klopft im richtigen Moment das Papier an> die Type auf der Walze, die gerade vorbeirauscht. Daher erkennt man ein> Verwischen in vertikaler Richtung.>> 1-2 Seiten pro Sekunde schätz ich, das schafft kein Kettendrucker.>> Gruß,> Michael
man hat ganz genau erkannt was von der trommel und was von der kette
kam, selbst wenn die trommel perfekt eingestellt war.
wir haben die trommeel sowieso nur genutzt wenn es sein mußte, weil die
kette hatte besseren schallschutz und man konnte auch von draussen sehen
wenn papier nachgelegt werden mußte :D
morob65 schrieb:> wir haben die trommeel sowieso nur genutzt wenn es sein mußte, weil die> kette hatte besseren schallschutz und man konnte auch von draussen sehen> wenn papier nachgelegt werden mußte :D
und die Kette konnte "Kopien durch gemeinsamen Anschlag" ausdrucken -
ich glaube, so heißt das im Juristendeutsch.
Gruß,
Michael
Ich hatte eine ungarischen Parallel-Drucker VT27000 der Firma
"Videoton", der mit der (originalen) Centronics-Schnittstelle an einem
K1630-System hing.
Bild im unteren Drittel der Seite:
http://www.robotrontechnik.de/index.htm?/html/drucker/paralleldrucker.htm
Der war unheimlich schnell, laut, konnte 136 Zeichen breit drucken und
kostete unheimlich viel Geld. (Weshalb ich ihn auch für diese
Doppelnutzung ausrüstete)
Dort habe ich dann die Testkarte entfernt und mit einer Eigenbau-SIF1000
Schnittstelle versehen. So konnte ich aussuchen, welches der beiden
Systeme den Drucker nutzen konnte.
MfG Paul
A. K. schrieb:> Es gab Anfang der 80er am Mainframe der Informatiker (TR440 von ~1970)> noch beides. Denn von den Terminals gab es relativ wenige (darunter aber> immerhin ein grafikfähiges mit Rollkugel), so dass die Anfänger noch> ganz klassisch per Lochkarte und Papierstapel arbeiten durften.
Wer weiss denn heute noch, dass Telefunken mal Grossrechner gebaut hat.
Ich durfte an der Uni Würzburg Anfang der 70er an der TR440
http://de.wikipedia.org/wiki/TR_440 rechnen, die hatte 64k Kernspeicher
http://de.wikipedia.org/wiki/Kernspeicher, also aufgefädelte
Ferritringe! Die Anfänger mussten Lochstreifen stanzen, die mittleren
Cracks Lochkarten und nur die Profis durften an ein Terminal SIG50 oder
SIG100. Das Kommando-Taschenbuch der TR440 habe ich noch.
@Usuru
Dein Bild ist prima. Weißer Adler auf weißem Grund. Ich habe es mir
ausgedruckt, damit ich mal eine saubere A4-Seite zur Verfügung habe.
;-)
MfG Paul
Paul Baumann schrieb:> Weißer Adler auf weißem Grund.
Der Adler ist nicht weiß, sondern durchsichtig. Falls dein Drucker das
Bild richtig ausgedruckt hat, brauchst du den Ausdruck nur auf eine
schwarze Unterlage zu legen, und schon wird der Adler schwarz :)
Ah, ich hatte mich schon gewundert, warum bei mir der Adler nicht weiß,
sondern kariert ist. Mein Browser zeigt durchsichtige Sachen mit einem
karierten Hintergrund an.
Paul Baumann schrieb:> Dein Bild ist prima. Weißer Adler auf weißem Grund. Ich habe es mir> ausgedruckt, damit ich mal eine saubere A4-Seite zur Verfügung habe.
Pass auf Paul das dir weisse Toner nicht ausgeht...
usuru schrieb:> Ich durfte an der Uni Würzburg Anfang der 70er an der TR440> http://de.wikipedia.org/wiki/TR_440 rechnen, die hatte 64k Kernspeicher
Allerdings waren das 64K Worte zu 48 Bits (netto), also 384K Bytes.
Paul Baumann schrieb:> @Usuru> Dein Bild ist prima. Weißer Adler auf weißem Grund. Ich habe es mir> ausgedruckt, damit ich mal eine saubere A4-Seite zur Verfügung habe.> ;-)>> MfG Paul
Das Original ist 2-farbig schwarz auf weiss, in meinem Firefox wird es
aber hellgrau auf weiss angezeigt, im Chromium tatsächlich ganz weiss.
Lade ich es in Irfanview, ist es wieder s/w. Keine Ahnung warum.
A. K. schrieb:> usuru schrieb:>> Ich durfte an der Uni Würzburg Anfang der 70er an der TR440>> http://de.wikipedia.org/wiki/TR_440 rechnen, die hatte 64k Kernspeicher>> Allerdings waren das 64K Worte zu 48 Bits (netto), also 384K Bytes.
Deswegen habe ich ja 64k und nicht 64kB geschrieben.
Michael Appelt schrieb:> So, jetzt wurde einige Male behauptet, man hätte die Ausdrucvke auf der> IBM mit Kettendruckern gedruckt - es waren vermutlich Trommeldrucker.
Nö. Es war wirklich ein Kettendrucker an unserer 115-er
Bei geöffnetem Gehäuse sah man die Kette ganz deutlich und sie machte
beim Umlauf einen Höllenlärm. Drum stand das ganze Druckwerk auch in
einem schallgedämmten Schrank :-)
> 1-2 Seiten pro Sekunde schätz ich, das schafft kein Kettendrucker.
Kommt drauf an, was er drucken soll. Die Dinger waren allerdings
wirklich sauschnell. Ist ja nicht so, dass die Kette da im
Schneckentempo umlief.
Paul Baumann schrieb:> Ich hatte eine ungarischen Parallel-Drucker VT27000 der Firma "Videoton"
Hatten wir auch. Im Vergleich zu vielen anderen Paralleldruckern
war der unwahrscheinlich sauber im Druckbild, nicht diese sonst so
typischen Ausreißer nach unten und oben. Aber schweinelaut war er
natürlich und nur GROSSBUCHSTABEN.
Christoph Kessler (db1uq) schrieb:> Die Handbücher (und auch Software) gibts aber zum Teil noch bei den> Bitsavers
Ich hatte eigentlich mehr gemeint, dass ich mir heutige Handbücher ein
wenig mehr in diese Richtung wünschen würde :-)
Ausser in 20 verschiedenen Sprachen "Wir beglückwünschen sie zum Kauf"
steht doch da heute nichts wesentliches mehr drinnen.
Im Prinzip würde es reichen, wenn sie einen Zettel beiliegen, auf dem zu
lesen ist "Der übliche Blabla. Danke".
Natürlich in 20 Sprachen.
"Der übliche Blabla. Danke"
"The usual blah Thank you."
"Les bla habituels Merci."
「いつも何とかありがとうございました。」
"Обычные бла Спасибо."
"Звичайні бла Спасибо."
"A szokásos bla Köszönöm."
"Her zamanki falan teşekkür ederiz."
"Уобичајени бла Хвала."
"Il-blah soltu Grazzi."
"Обичайните бла Благодаря."
"ჩვეულებრივი blah დიდი მადლობა."
"Të blah zakonshme Ju faleminderit."
"De gebruikelijke bla Dank je wel."
"I soliti bla Grazie."
"Los bla habituales Gracias."
"Os blah habituais Obrigado."
"Zwykłe bla Dziękuję."
"De sædvanlige bla Tak."
"De vanlige blah Takk."
Bitte schoen, das Universal Handbuch fuer jeden Mist.
usuru schrieb:> Das Original ist 2-farbig schwarz auf weiss,
Nein, es ist transparent auf weiß (bzw.umgekehrt).
> in meinem Firefox wird es aber hellgrau auf weiss angezeigt,
In meinem auch. Das liegt daran, dass er das Bild auf einem hellgrauen
Hintergrund darstellt.
> im Chromium tatsächlich ganz weiss.
Offensichtlich verwendet Chromium einen weißen Hintergrund.
Bei den meisten Browsern kann man mittels Addons die Hintergrundfarbe
ändern. Hab's aber nicht ausprobiert.
> Lade ich es in Irfanview, ist es wieder s/w. Keine Ahnung warum.
GQView verwendet als Hintergrund ein Schachbrettmuster mit hell- und
dunkelgrauen Feldern. Entsprechend sehen die transparenten Flächen in
dem Scan gemustert aus.
Für das Bild in diesem Beitrag
Yalu X. schrieb:> Der Adler ist nicht weiß, sondern durchsichtig.
habe ich dem Bild mit Gimp einfach einen zweiten, komplett schwarzen
Layer hinterlegt und das Ganze wieder als PNG exportiert. Dadurch werden
alle ursprünglich transparenten Flächen unabhängig vom verwendeten
Viewer schwarz dargestellt.
Ein Computer muß nicht Speicherprogrammiert sein.
ES gibt auch Schalttafel programmierte.
Hier ein Bild Nettolohnabrechnung auf IBM609 Steuer- uns Sozialabzüge.
(1962)
Um vorzubeugen diese Tafel stammt aus dem prouktiven Betrieb eines
Betriebes mit 2000 Beschäftigten.
Es wurde auch die Produktionsplanung unterstützt, mit einer anderen
Tafel.
Nebenbei:
Die IBM305 war sowohl Speicherprogrammiert und gleichzeitig Schalttafel-
programmiert.
klausb schrieb:> Hier ein Bild Nettolohnabrechnung auf IBM609 Steuer- uns Sozialabzüge.> (1962)
Muss die bessere Programmierung gewesen sein, damals gab es mehr raus
und weniger Abzuege...
Helmut Lenzen schrieb:> Bitte schoen, das Universal Handbuch fuer jeden Mist.
:-)
Und jetzt fehlt nur noch ein passendes Piktogramm, denn Lesen ist doch
aber sowas von gestern, ey!
Helmut Lenzen schrieb:> Das darfst du jetzt machen...
Oje! Ich probier's mal auf Arduino-Art: Google fragen und dann einfach
irgendwas aus dem Internet zusammenkopieren. ;-)
Georg schrieb:> Udo Schmitt schrieb:>> ie schönen Kettendrucker. Unsere Firma hat ihren letzten von ca. 12>> Jahren verschenkt.>> Konnte der überhaupt Umlaute drucken? Von Grafik mal ganz abgesehen. Und> das Endlospapier verursachte auch seine Kosten, ganz extrem wenn man> Durchschläge brauchte.
Unserer Kettendrucker konnte, jedenfalls dann, wenn die Spezialkette
montiert war. Siehe den Scan einer 1979 gedruckten Seite.
Ein interessantes Feature der damaligen Kettendrucker war, daß man die
Druckgeschwindigkeit mit einer geeigneten Kette optimieren konnte, indem
man die Häufigkeitsverteilung der zu druckenden Zeichen berücksichtigte.
Üblicherweise verwendete man einen beschränkten Zeichensatz und eine
Kette, auf der die häufig zu druckenden Zeichen mehrfach vorkamen.
Details siehe z.B.
http://en.wikipedia.org/wiki/Line_printer#Chain_.28train.29_printer
Anders ausgedrückt, der der prinzipiell mögliche Umfang an Zeichen war
viel größer als das, was man üblicherweise zu sehen bekam (nämlich
Ziffern und Großbuchstaben) und nur durch die Länge der Kette (ca. 2 x
Zeilenlänge) beschränkt. Und das hatten wir ausgenutzt.
Wir hatten uns eine Kette anfertigen lassen, die jedes Zeichen nur
einmal enthielt, die dafür aber einen sehr umfangreichen Zeichenvorrat
drucken konnte, wenn auch nur relativ gesehen langsamer. Neben den
Umlauten ließen sich so diverse in der mathematischen Notation
gebräuchliche Zeichen drucken. Allerdings waren solche Spezialketten
sündhaft teuer, so daß es davon nur eine gab und die auch nur dann
montiert wurde, wenn sich genügend Outputs der entsprechenden
Outputklasse angesammelt hatten.
Karl Heinz schrieb:> Was ich am meisten aus der Zeit vermisse:> Die Handbücher.> Die waren ihren Kilopreis noch wert.
Und im Anhang waren sogar noch die Schaltpläne drinn!
(Macht ja heute keinen großen Sinn mehr bei der Integrationsdichte...)
Hallo,
Wolfgang S.
Die 7094 hört sich nach Garching an. Da war doch schon eine 1401 als
Spoolmaschine. Und eine 1402 als Stanzer und Leser.
War wohl in den 60gern eins der schweren Eisen :-)
Bronco schrieb:> Und im Anhang waren sogar noch die Schaltpläne drinn!
Bei meiner HP 2100 sind sogar die ROM-Listings vom "Microcode" in der
Dokumentation enthalten. Ja, gut, die paar Hundert Bytes machen bei
den Manuals jetzt auch nicht mehr viel aus
Konrad S. schrieb:> Bei meiner HP 2100 sind sogar die ROM-Listings vom "Microcode" in der> Dokumentation enthalten.
Damit ist HP aber nicht alleine gewesen.
In den "Field Maintenance Print Sets" von DEC für die PDP11s sind auch
sämliche Informationen vorhanden: Microcode-Listings, Verdrahtungspläne
für die Backplanes (die sind gewickelt), Schaltungen, Layouts usw.. Im
Prinzip alles, um die Funktion zu verstehen und die Boards nachbauen zu
können. Einfach traumhaft und auch sehr beruhigend.
Apropos HP2100: Hast du eventuell Unterlagen über das Board "12665-60001
serial interface". Darüber ist auf der ganzen durchsuchbaren Welt nichts
zu finden.
klausb schrieb:> Hallo,> Wolfgang S.>> Die 7094 hört sich nach Garching an. Da war doch schon eine 1401 als> Spoolmaschine. Und eine 1402 als Stanzer und Leser.
Nein, die stand im RHRZ in Bonn, und war wohl doch nur eine 7090. Leider
habe ich überhaupt keine Unterlagen mehr aus der Zeit. Damals habe ich
mich mehr für die Feinheiten von Fortran IV interessiert als für die
Hardware und für die Schnelldruckeroutputs gab es seinerzeit erstaunlich
viel Interesse. Da die Ausdrucke meist ziemlich blaß waren, konnte man
die großen Bögen sehr gut zweitverwerten.
>> War wohl in den 60gern eins der schweren Eisen :-)
Sie nahm jedenfalls einen großen Teil des Erdgeschosses in diesem Klotz
http://www.hrz.uni-bonn.de/ueber-uns/bilder-vom-hochschulrechenzentrum
ein.
Sinus Tangentus schrieb:> Apropos HP2100: Hast du eventuell Unterlagen über das Board "12665-60001> serial interface". Darüber ist auf der ganzen durchsuchbaren Welt nichts> zu finden.
Ich habe mindestens ein Board mit serieller Schnittstelle für die HP
2100 und habe die Schnittstelle auch schon mal mit einem eigenen
Programm angesteuert. Also müsste ich auch Dokumentation dazu haben. Ich
kann leider nicht sagen, ob es genau dieses Board ist, denn die Anlage
ist an einem etwas abgelegenen Ort eingelagert. Das kann durchaus ein
Jahr dauern, bis ich da mal wieder vorbeikomme. Dann guck ich mal, was
ich dazu habe. Hoffentlich finde ich dann diesen Thread wieder.
Mit den Kettendruckern konnte man auch einigen Schabernack anstellen,
z.B. Zeilen ohne LF ausgeben, die jeweils nur ein Zeichen enthielten und
die "zufällig" auf der Kette so angeordnet sind, dass ein kompletter
Zeichensatz durchlaufen muss, bis das nächst Zeichen kommt. Das LF
musste dann aber irgendwann kommen, bevor das Papier abgedruckt war...
Dann irgendwann zur Abwechslung eine Zeile, die den ganzen Zeichensatz
in Kettenreihenfolge enthält.
Das war eben noch richtige Hardware...
Uhu Uhuhu schrieb:> Mit den Kettendruckern konnte man auch einigen Schabernack anstellen.....
Du bist ein Elektronik-Sadist!
;-)
So ein Drucker ist auch nur ein Mensch.
MfG Paul
Paul Baumann schrieb:> Du bist ein Elektronik-Sadist!
Der Elektronik hat das nichts ausgemacht und die Mechanik hats auch
nicht übel genommen - im Gegensatz zum Operateur ;-)
Am Wochenende kam der Film "Password Swordfish", da hat Hugh Jackman als
Superhacker die "einzige PDP10, die noch am Internet hängt" aktiviert,
um seine Missetaten zu begehen.
Wer es ihm nachtun will: http://simh.trailing-edge.com/
Doku: http://simh.trailing-edge.com/pdf/pdp10_doc.pdf
Einschliesslich Ethernet. Zumindest dem Prinzip nach, denn "XU simulates
the DEUNA/DELUA Ethernet controller. The current implementation is
experimental, and its operation is not supported under any known
operating system."
