Discussion:
Datentransfer CP/M-Rechner -> Linux via. Druckerport?
(zu alt für eine Antwort)
Peter Heitzer
2012-02-15 18:04:30 UTC
Permalink
Hallo,
ich möchte von einem CP/M-System mit 8"-Laufwerken gerne die Daten von ca. 50 Disketten auf
einen Linux-PC übertragen. Ich dachte daran, dies über den Parallelport zu machen, da
es über die serielle Schnittstelle wohl zu langsam ist.
Hat jemand schon so etwas gemacht und kann mir Hinweise zu Quellen für Transferprogrammen
(sowohl CP/M als auch Linux) geben?
Am elegantesten wäre eine Übertragung via Netzwerk. Gibt es für CP/M Treiber für Parallelport-
Ethernetadapter (z.B. circom)?

Danke schon mal
--
Dipl.-Inform(FH) Peter Heitzer, ***@rz.uni-regensburg.de
HTML mails will be forwarded to /dev/null.
Holm Tiffe
2012-02-15 20:08:48 UTC
Permalink
Post by Peter Heitzer
Hallo,
ich möchte von einem CP/M-System mit 8"-Laufwerken gerne die Daten von ca. 50 Disketten auf
einen Linux-PC übertragen. Ich dachte daran, dies über den Parallelport zu machen, da
es über die serielle Schnittstelle wohl zu langsam ist.
Hat jemand schon so etwas gemacht und kann mir Hinweise zu Quellen für Transferprogrammen
(sowohl CP/M als auch Linux) geben?
Am elegantesten wäre eine Übertragung via Netzwerk. Gibt es für CP/M Treiber für Parallelport-
Ethernetadapter (z.B. circom)?
Danke schon mal
Nein,nein und nein.

Die Parallelports von CP/M Rechnern sind nicht standardisiert,
geschweige denn deren Treiber. Du wirst die Software nach der konkreten
Hardware selbst schreiben müssen.

Einen TCP/IP Stack für CP/M gibts auch nicht, simpel weil der im
Adressraum keinen Platz hat. Dafür sind CP/M Rechner "zu klein" womit
sich auch die Frage nach den Circom Adaptern erübrigt.

Es gibt allerdings eine Netzwerkschnittstelle für diverse DDR CP/M
Computer, suche mal im Forum von www.robotrontechnik.de. Ich habe hier
eine unbestückte Platine dafür liegen, bin aber noch nicht dazu gekommen
die zu bestücken (wird noch).

Gruß,

Holm
Goetz Hoffart
2012-02-15 20:32:42 UTC
Permalink
Post by Holm Tiffe
Einen TCP/IP Stack für CP/M gibts auch nicht, simpel weil der im
Adressraum keinen Platz hat. Dafür sind CP/M Rechner "zu klein" womit
sich auch die Frage nach den Circom Adaptern erübrigt.
Contiki kann es doch auf 8Bittern auch?

Grüße
Götz
--
http://www.knubbelmac.de/
fritz chwolka
2012-02-15 20:58:17 UTC
Permalink
Post by Peter Heitzer
Hallo,
ich möchte von einem CP/M-System mit 8"-Laufwerken gerne die Daten von ca. 50 Disketten auf
einen Linux-PC übertragen. Ich dachte daran, dies über den Parallelport zu machen, da
es über die serielle Schnittstelle wohl zu langsam ist.
Hat jemand schon so etwas gemacht und kann mir Hinweise zu Quellen für Transferprogrammen
(sowohl CP/M als auch Linux) geben?
Am elegantesten wäre eine Übertragung via Netzwerk. Gibt es für CP/M Treiber für Parallelport-
Ethernetadapter (z.B. circom)?
Danke schon mal
Einen alten 386er, MSdos, ein 8" drive anklemmmen und mit einem
Programm wie 22disk oder supercopy oder ?? auf die Diskette zugreifen.


Welches Format haben denn die Disketten?

MfG.

fritz
Roger Schwentker
2012-02-15 20:54:22 UTC
Permalink
Post by Peter Heitzer
ich möchte von einem CP/M-System mit 8"-Laufwerken gerne die Daten von ca. 50 Disketten auf
einen Linux-PC übertragen.
Hmm. Kermit läuft fast überall.
Post by Peter Heitzer
Ich dachte daran, dies über den Parallelport zu machen, da
es über die serielle Schnittstelle wohl zu langsam ist.
pip, dies aber ohne jede Fehlererkennung oder -korrektur.
Post by Peter Heitzer
Am elegantesten wäre eine Übertragung via Netzwerk. Gibt es für CP/M Treiber für Parallelport-
Ethernetadapter (z.B. circom)?
Treiber? Für CP/M?

CP/M bietet keine Schnittstelle zur Installation von nachladbaren
Treibern. Wenn überhaupt Treiber, dann selbst ins BIOS hinein-
compilieren.

Und einen IP-Stack für CP/M habe ich auch noch nie gesehen. Selbst
KA9Q läuft erst ab MS-DOS. Ich kann mir auch nicht vorstellen, wie
selbst eine minimale TCP-Implemantation inklusive Buffer in die MTA
passen soll.

Viele Grüße
Roger Schwentker
***@regioconnect.net
--
F.D.P. - Die parlamentarische Vertretung der Heuschrecken
[Georg Schramm, 2008]
Klemens Krause
2012-02-16 08:38:54 UTC
Permalink
Post by Roger Schwentker
Post by Peter Heitzer
ich möchte von einem CP/M-System mit 8"-Laufwerken gerne die Daten von ca. 50 Disketten auf
einen Linux-PC übertragen.
Hmm. Kermit läuft fast überall.
Das ist sozusagen der dekadente Weg. Kermit läuft noch auf der absurdesten
Hardware. Es gab und gibt es vermutlich immer noch, einen "generischen"
CP/M-Kermit bei Frank da Cruz.
Post by Roger Schwentker
Post by Peter Heitzer
Ich dachte daran, dies über den Parallelport zu machen, da
pip, dies aber ohne jede Fehlererkennung oder -korrektur.
Das ist das "Bordwerkzeug" von CP/M, übrigens geerbt von den älteren
DEC-Betriebssystemen. Um mal wieder mein übliches Mantra runterzubeten:
Sowohl MS-DOS als auch CP/M sind sehr schlechte Kopien von OS/8.

PIP heisst Peripheral Interchange Program und dient genau dazu: Daten
zwischen Peripherie und Rechner auszutauschen. Das PIP Deiner 8"-Kiste
sollte wissen, wie es den Parallelport anspricht "PRN:" oder "PUN:" auch
"AUX:" wären Kandidaten.
Wegen der fehlenden Fehlersicherheit würde ich mir keine sehr grossen Gedanken
machen. Erstens geht die Übertragung ja nicht über grosse Entfernungen,
src und dest stehen ja vermutlich nebeneinander. Und zur Not kannst Du es ja
machen wie einst bei den Datentypisten am Lochkartenstanzer: Zweimal eingeben
und vergleichen.
Der Vorteil von Kermit ist, dass die Filenamen mit übertragen werden und es
fehlersicher ist, dafür ist es aber recht langsam. Aber den musst Du erst mal
auf Deinem System zum laufen bringen.
Die Geschwindigkeit spielt aber keine Rolle: Sowohl PIP als auch die Kermiten
verstehen Wildcards und sie produzieren nicht alle 13 Minuten eine Alertbox
mit der Du bestätigen musst, dass Du Deinem Rechner auch genügend Aufmerksam-
keit widmest. Einfach abends starten, dann ist es morgens fertig.

Einige weitere Erinnerungen von CP/M an OS/8:
Auch bei OS/8 wurden Gerätenamen mit nachgestelltem Doppelpunkt gekennzeichnet:
CON:, LPT:, DSK:, SYS:
Und der Informationsfluss bei Kommandos geht ebenso wie bei den alten Programier-
sprachen von rechts nach links:
FORTRAN:
I=I+1
OS/8:
PIP AUX:<SOURCE.TX
REN DEST.TX<SOURCE.TX
CP/M:
PIP PRN:=SOURCE:TXT
REN DEST.TX=SOURCE.TXT

Dabei haben sich die DEC-Leute sogar etwas gedacht, was die CP/Mer wieder vergessen
haben: Sie haben das Gleichheitszeichen bei der Zuweisung, was jeden logisch denkenden
Menschen auf die Palme bringen muss (I=I+1 ist ein Widerspruch!), durch einen Richtungs-
operator ersetzt. Das war ursprünglich etwas, was aus der ALGOL-Ecke kam:
Da hat es auch geheissen: I <- I+1. Weil es aber auf den alten Computern das Pfeilsymbol
nicht gab, "durfte" man den Pfeil nach links durch := ersetzen, was sich ja bis heute
noch gehalten hat, genauso wie diese erbärmliche Laufwerksbuchstaberei gewisser Betriebs-
systeme.


Klemens
Wolfgang Broeker
2012-02-16 19:06:08 UTC
Permalink
Post by Klemens Krause
Dabei haben sich die DEC-Leute sogar etwas gedacht, was die CP/Mer wieder
vergessen haben: Sie haben das Gleichheitszeichen bei der Zuweisung, was
jeden logisch denkenden Menschen auf die Palme bringen muss (I=I+1 ist ein
Widerspruch!), durch einen Richtungsoperator ersetzt.
Naja, ich fand es schon immer ein wenig professoral-theorielastig,
in dem Gleichheitszeichen ein Problem zu sehen. In dem in Rede ste-
henden Kontext bezeichnet das "=" keine Gleichheit, sondern ist ein
Zuweisungsoperator. Ich habe noch keinen Programmierer erlebt, der
damit ein wirkliches Problem hatte, in welcher Programmiersprache
auch immer, und mich selbst hat es in nunmehr fast 40 Jahren Praxis
noch nie auf irgendeinen Baum, geschweige eine Palme gebracht.
Post by Klemens Krause
Da hat es auch geheissen: I <- I+1. Weil es aber auf den alten
Computern das Pfeilsymbol nicht gab, "durfte" man den Pfeil nach
links durch := ersetzen, was sich ja bis heute noch gehalten hat,
Die Beschränkungen lagen seinerzeit nicht in den Rechnern, sondern
bei den Eingabegeräten, und dass hieß in meinem Umfeld damals IBM026.
Ich habe aber gerade mal nachgesehen und gefunden, dass die Zeichen
"<-" dort durchaus verfügbar waren, siehe
<Loading Image...>

Dein Hinweis auf Algol unterstützt im Übrigen meine Einschätzung als
"theorielastig": Diese Sprache wie auch das noch "lastigere" Algol68
sind über enge akademische Kreise nie hinausgekommen, im Gegensatz
zu bei den Puristen so verhassten Sprachen wie FORTRAN oder PL/1.

Gruß - Wolfgang
Wolfgang Broeker
2012-02-16 19:25:28 UTC
Permalink
Post by Wolfgang Broeker
Ich habe aber gerade mal nachgesehen und gefunden, dass die Zeichen
"<-" dort durchaus verfügbar waren, siehe
<http://en.wikipedia.org/wiki/File:IBM_026_card_code.png>
Ich sehe gerade, dass das mit dem Zeichen "<" auf der IBM026 doch
etwas anders war. Wir haben seinerzeit mit Vergleichsoperatoren
wie .GT. oder .LT. für > oder < unter Fortran gearbeitet. Es ist
halt lange her.

Gruß - Ingrid
Torsten Schneider
2012-02-17 07:30:17 UTC
Permalink
Post by Wolfgang Broeker
Ich sehe gerade, dass das mit dem Zeichen "<" auf der IBM026 doch
etwas anders war. Wir haben seinerzeit mit Vergleichsoperatoren
wie .GT. oder .LT. für > oder < unter Fortran gearbeitet. Es ist
halt lange her.
Zumindest unter Fortran 77 *musste *man doch .gt. und .lt. anstatt > und <
schreiben, oder hab ich das jetzt falsch in Erinnerung?


Viele Grüße, Torsten
Nils M Holm
2012-02-17 10:47:37 UTC
Permalink
Post by Torsten Schneider
Zumindest unter Fortran 77 *musste *man doch .gt. und .lt. anstatt > und <
schreiben, oder hab ich das jetzt falsch in Erinnerung?
Habe ich auch so in Erinnerung.
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Klemens Krause
2012-02-17 13:20:54 UTC
Permalink
Post by Nils M Holm
Post by Torsten Schneider
Zumindest unter Fortran 77 *musste *man doch .gt. und .lt. anstatt > und <
schreiben, oder hab ich das jetzt falsch in Erinnerung?
Habe ich auch so in Erinnerung.
Stellt Euch doch einen IBM-Drucker vom Anfang der 60er Jahre vor. Der konnte
44 oder 48 verschiedene Zeichen drucken:
Leerzeichen, A-Z und 0-9. Das sind schon 37. Bleiben 7 oder 11 Satzzeichen.
Also haben sie ab FORTRAN IV, als das logische IF eingeführt wurde, zu
der Hilfskonstruktion .GT. .LT. usw gegriffen. Den Luxus von < > usw gab es
in FORTRAN nie.


Klemens
Nils M Holm
2012-02-18 07:05:44 UTC
Permalink
Post by Klemens Krause
Stellt Euch doch einen IBM-Drucker vom Anfang der 60er Jahre vor. Der konnte
Leerzeichen, A-Z und 0-9. Das sind schon 37. Bleiben 7 oder 11 Satzzeichen.
Also haben sie ab FORTRAN IV, als das logische IF eingef?hrt wurde, zu
der Hilfskonstruktion .GT. .LT. usw gegriffen.
Ja, aber FORTRAN 77 assoziiere ich dann doch eher mit einer S/370,
und die 3270 Terminals, die wir an den Dingern hatten, konnten schon
den vollstaendigen EBCDIC, also auch <, >, etc. (Und die Kettendrucker
hatten damit auch keine Probleme.)
Post by Klemens Krause
Den Luxus von < > usw gab es
in FORTRAN nie.
In FORTRAN nicht, aber in Fortran (90 und spater) meines Wissens nach
schon (selbst gesehen habe ich das aber nie).
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Klemens Krause
2012-02-20 12:51:11 UTC
Permalink
....
Post by Nils M Holm
Post by Klemens Krause
Also haben sie ab FORTRAN IV, als das logische IF eingef?hrt wurde, zu
der Hilfskonstruktion .GT. .LT. usw gegriffen.
Ja, aber FORTRAN 77 assoziiere ich dann doch eher mit einer S/370,
und die 3270 Terminals, die wir an den Dingern hatten, konnten schon
den vollstaendigen EBCDIC, also auch <, >, etc. (Und die Kettendrucker
hatten damit auch keine Probleme.)
Das ist ja kein Widerspruch. Ich meinte lediglich, dass die Sprachversion,
in der es das logische IF erstmals gab, zu Beginn der 60er Jahre erschien.
Und damals gab es eben diese Sonderzeichen noch nicht. Und die IBM-Leute
waren wohl Pragmatiker, die es nicht so sehr mit der Theorie hatten (I=I+1).
An zukünftige Zeichensatzerweiterunge (es wird einmal die Zeichen < oder >
geben), oder an gegenwärtige Einschränkungen haben die vermutlich nicht
gedacht. Dadurch war .GT. und .LT. eben eine eigenständige Konstruktion
und nicht eine Umschreibung für ein auf der aktuellen Maschine grade
nicht vorhandenes Zeichen, wie es das := für die Algoliker war.

Klemens
Torsten Schneider
2012-02-21 08:20:23 UTC
Permalink
Post by Klemens Krause
Post by Nils M Holm
Post by Torsten Schneider
Zumindest unter Fortran 77 *musste *man doch .gt. und .lt. anstatt > und <
schreiben, oder hab ich das jetzt falsch in Erinnerung?
Habe ich auch so in Erinnerung.
Stellt Euch doch einen IBM-Drucker vom Anfang der 60er Jahre vor. Der konnte
Irgendwie habe ich so meine Zweifel, dass man sich Anfang der 60er schon
mit Fortran *77* herumgeschlagen hat. ;)

Aber nichtsdestotrotz wurde das wohl aus traditionellen Gründen
beibehalten, vermute ich mal.


Viele Grüße, Torsten

Torsten Schneider
2012-02-17 07:32:07 UTC
Permalink
Post by Wolfgang Broeker
Ich sehe gerade, dass das mit dem Zeichen "<" auf der IBM026 doch
etwas anders war. Wir haben seinerzeit mit Vergleichsoperatoren
wie .GT. oder .LT. für > oder < unter Fortran gearbeitet. Es ist
halt lange her.
Zumindest unter Fortran 77 *musste* man doch .gt. und .lt. anstatt > und <
schreiben, oder hab ich das jetzt falsch in Erinnerung?


Viele Grüße, Torsten
Michael Baeuerle
2012-02-17 09:16:45 UTC
Permalink
Post by Wolfgang Broeker
Post by Klemens Krause
Dabei haben sich die DEC-Leute sogar etwas gedacht, was die CP/Mer wieder
vergessen haben: Sie haben das Gleichheitszeichen bei der Zuweisung, was
jeden logisch denkenden Menschen auf die Palme bringen muss (I=I+1 ist ein
Widerspruch!), durch einen Richtungsoperator ersetzt.
Naja, ich fand es schon immer ein wenig professoral-theorielastig,
in dem Gleichheitszeichen ein Problem zu sehen. In dem in Rede ste-
henden Kontext bezeichnet das "=" keine Gleichheit, sondern ist ein
Zuweisungsoperator.
Das ist kein Problem solange man nicht Operatoren fuer beides braucht.
Und wie man dann z.B. bei C auf die Idee kommen konnte "==" fuer
Gleichheit zu verwenden (statt fuer die Zuweisung was anderes) verstehe
ich bis heute nicht. Pascal mit "=" und ":=" fand ich da deutlich
intuitiver.


Micha
Axel Schwenke
2012-02-17 12:47:07 UTC
Permalink
Post by Michael Baeuerle
Post by Wolfgang Broeker
Naja, ich fand es schon immer ein wenig professoral-theorielastig,
in dem Gleichheitszeichen ein Problem zu sehen. In dem in Rede ste-
henden Kontext bezeichnet das "=" keine Gleichheit, sondern ist ein
Zuweisungsoperator.
Das ist kein Problem solange man nicht Operatoren fuer beides braucht.
Und wie man dann z.B. bei C auf die Idee kommen konnte "==" fuer
Gleichheit zu verwenden (statt fuer die Zuweisung was anderes) verstehe
ich bis heute nicht.
Ach was. Wenn man programmiert, kommt man mit nur einem Äquivalenz-
operator meistens sowieso nicht hin. Wenn es Referenzen gibt, kommt
noch === dazu. Für dreiwertige Logik (0,1,NULL) vielleicht <=> und
z.B. Perl kennt noch eq für Strings (vs. == für Zahlen).

Und sogar in der Mathematik ist die Verwendung von "=" fließend. Mal
ist es eine Aussage "P=NP", ein andermal eine Zuweisung "f(x)=x²-1"

Am Ende ist es eine Geschmacksfrage. Als notorisch tippfaulem Mensch
kommt mir = als Zuweisungsoperator vs. == als Gleichheit(stest) aber
entgegen. Ich brauche die Zuweisung deutlich öfter.


XL
Martin Peters
2012-02-17 13:39:06 UTC
Permalink
Axel Schwenke schrieb:
(...)
Post by Axel Schwenke
Und sogar in der Mathematik ist die Verwendung von "=" fließend. Mal
ist es eine Aussage "P=NP", ein andermal eine Zuweisung "f(x)=x²-1"
Nein. Auch letzteres ist eine Aussage und eben keine Zuweisung.
Es ist eine Aussage, die den Zusammenhangs zwischen x und den
Funktionswerten f(x) beschreibt.

Mit Zuweisung hat das nichts zu tun.
Axel Schwenke
2012-02-17 14:43:06 UTC
Permalink
Post by Martin Peters
(...)
Post by Axel Schwenke
Und sogar in der Mathematik ist die Verwendung von "=" fließend. Mal
ist es eine Aussage "P=NP", ein andermal eine Zuweisung "f(x)=x²-1"
Nein. Auch letzteres ist eine Aussage und eben keine Zuweisung.
Es ist *keine* Aussage. Einer Aussage ließe sich ein Wahrheitswert
zuordnen. Dazu müßte f(x) schon vorher definiert sein.
O.g. Ausdruck *ist* aber gerade erst die Definition.
Post by Martin Peters
Es ist eine Aussage, die den Zusammenhangs zwischen x und den
Funktionswerten f(x) beschreibt.
Mit Zuweisung hat das nichts zu tun.
In der Mathematik sagt man auch lieber "Definition" als "Zuweisung"
Praktisch läuft es auf das gleiche hinaus:

Mathematik: "f(x)=x²-1" -> "Wenn ich in Zukunft sage 'f(x)',
dann bedeutet das 'x²-1'"

Programmierung: "y=x²-1" -> "wenn ich in Zukunft Variable y
referenziere, dann meine ich den Wert den x²-1 eben hat"

Der Unterschied ist, daß die Mathematik Dinge immer nur einmal
(bzw. immer gleich) definiert während es in Programmen vollkommen
normal ist, daß Variablen zu verschiedenen Zeitpunkten verschiedene
Werte haben.


XL
Martin Peters
2012-02-17 16:27:36 UTC
Permalink
Axel Schwenke schrieb:
(...)
Post by Axel Schwenke
Post by Martin Peters
Post by Axel Schwenke
Und sogar in der Mathematik ist die Verwendung von "=" fließend. Mal
ist es eine Aussage "P=NP", ein andermal eine Zuweisung "f(x)=x²-1"
Nein. Auch letzteres ist eine Aussage und eben keine Zuweisung.
Es ist *keine* Aussage.
Du wirst _immer_ irgendeinen Kontext brauchen, der Deine Aussagen in
einen aussagenlogischen Zusammenhang stellt. Da unterscheidet sich
P=NP nicht f(x)=x²-1.

Wenn Du schreibst:

Es gelte: f(x)=cos(x)

ist die Aussage

f(x)=x²-1

falsch. Wenn Du aber schreibst:

Es gilt: f(x)=-1+x²

ist die Aussage

f(x)=x²-1

wahr.
Post by Axel Schwenke
Einer Aussage ließe sich ein Wahrheitswert zuordnen.
Habe ich gegenteiliges behauptet?

Aussagen werden immer in einem Kontext getroffen, der ihnen einen
Wahrheitswert zuordnet (z.B. bei einer Definition) bzw. diesen
hinterfragt (z.B. bei einem Beweis). Auch "f(x)=x²-1" ist eine Aussage,
die je nach Kontext richtig oder falsch sein kann oder die man einfach
als richtig in den Raum stellt, indem man z.B. "es gilt:" davor
schreibt.
Post by Axel Schwenke
Dazu müßte f(x) schon vorher definiert sein.
Ja eben. Glaubst Du, dass Du bei Deinem P-NP-Problem verher keine
Aussage darueber treffen musst, was mit P und NP gemeint ist? In
diesem Zusammehang musst Du ja vorher schon sagen, was "=" bei
Komplexitaetsklassen ueberhaupt bedeutet?
Post by Axel Schwenke
O.g. Ausdruck *ist* aber gerade erst die Definition.
Wie kommst Du darauf? Eine Definition wird es dadurch, dass Du
"Def.:" oder "es gilt:" oder irgendwas in der Art davor schreibst.

Erst damit hast Du f(x)=x²-1 als wahre Aussage festgelegt, woraus
Du dann Deine aussagenlogischen Schluesse entsprechend ziehen
darfst.
Post by Axel Schwenke
Post by Martin Peters
Es ist eine Aussage, die den Zusammenhangs zwischen x und den
Funktionswerten f(x) beschreibt.
Mit Zuweisung hat das nichts zu tun.
In der Mathematik sagt man auch lieber "Definition" als "Zuweisung"
In der Mathematik sagt man Zuweisung garnicht. Hat jedenfalls keiner
meiner Profs jemals in diesem Zusammenhang in den Mund genommen...
doch: in Numerik. Aber da ging's um Algorithmen.
Michael Baeuerle
2012-02-17 13:26:08 UTC
Permalink
Post by Axel Schwenke
[...]
Am Ende ist es eine Geschmacksfrage.
Schon irgendwie.
Post by Axel Schwenke
Als notorisch tippfaulem Mensch
kommt mir = als Zuweisungsoperator vs. == als Gleichheit(stest) aber
entgegen. Ich brauche die Zuweisung deutlich öfter.
Das war bestimmt auch das Argument es so zu machen wie es ist ... in C
kann man ja grausam tippfaul programmieren, bis zur Unlesbarkeit wenn
man kein Compiler ist ;-)


Micha
Stefan Reuther
2012-02-17 17:52:37 UTC
Permalink
Post by Michael Baeuerle
Post by Wolfgang Broeker
Post by Klemens Krause
Dabei haben sich die DEC-Leute sogar etwas gedacht, was die CP/Mer wieder
vergessen haben: Sie haben das Gleichheitszeichen bei der Zuweisung, was
jeden logisch denkenden Menschen auf die Palme bringen muss (I=I+1 ist ein
Widerspruch!), durch einen Richtungsoperator ersetzt.
Naja, ich fand es schon immer ein wenig professoral-theorielastig,
in dem Gleichheitszeichen ein Problem zu sehen. In dem in Rede ste-
henden Kontext bezeichnet das "=" keine Gleichheit, sondern ist ein
Zuweisungsoperator.
Das ist kein Problem solange man nicht Operatoren fuer beides braucht.
Und wie man dann z.B. bei C auf die Idee kommen konnte "==" fuer
Gleichheit zu verwenden (statt fuer die Zuweisung was anderes) verstehe
ich bis heute nicht. Pascal mit "=" und ":=" fand ich da deutlich
intuitiver.
BASIC nimmt '=' für beides. Noch intuitiver, dafür noch hässlicher zu
interpretieren für einen Compiler ('a=b=c').

Den Wechsel von Pascal zu C fand ich ansonsten ziemlich schmerzarm.
Anders ausgedrückt: wer '=' vs. ':=' für das größte Problem zwischen C
und Pascal hält, hat die richtigen Probleme noch nicht gefunden :-)


Stefan
Nils M Holm
2012-02-18 06:57:52 UTC
Permalink
BASIC nimmt '=' f?r beides. Noch intuitiver, daf?r noch h?sslicher zu
interpretieren f?r einen Compiler ('a=b=c').
Die Interpretation ist im Fall von BASIC (zumindest in den mir
bekannten Dialekten) kein Problem, da die Zuweisung nicht Teil
eines Ausdrucks sein kann.
Den Wechsel von Pascal zu C fand ich ansonsten ziemlich schmerzarm.
Anders ausgedr?ckt: wer '=' vs. ':=' f?r das gr??te Problem zwischen C
und Pascal h?lt, hat die richtigen Probleme noch nicht gefunden :-)
Amen!
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Klemens Krause
2012-02-17 13:07:30 UTC
Permalink
...
Post by Wolfgang Broeker
Post by Klemens Krause
vergessen haben: Sie haben das Gleichheitszeichen bei der Zuweisung, was
... I=I+1
durch einen Richtungsoperator ersetzt.
Naja, ich fand es schon immer ein wenig professoral-theorielastig,
in dem Gleichheitszeichen ein Problem zu sehen. In dem in Rede ste-
henden Kontext bezeichnet das "=" keine Gleichheit, sondern ist ein
Zuweisungsoperator.
Das weiss ich auch mit dem Zuweisungsoperator. Mich hat das auch nicht
gestört. Ich wollte nur mal darauf hinweisen, dass sich bestimmte
Eigentümlichkeiten, in einer angeblich so innovativen high-tech-Welt
auf irgendwelche technischen Unvollkommenheiten von 50 oder 60 Jahre
alten Maschinen zurückführen lassen.
Es war halt in dem Zusammenhang interessant, in dem ich auf den Umstand
hingewiesen habe, dass noch bis zu CP/M der Informationsfluss in einer
Kommandozeile von rechts nach links (copy dest=source) und nicht wie
heute von links nach rechts (cp source dest) verläuft. Auch dieses
etwas was Anfanf der 50er mit Autocoder und FORTRAN begann.

...
Post by Wolfgang Broeker
Die Beschränkungen lagen seinerzeit nicht in den Rechnern, sondern
bei den Eingabegeräten, und dass hieß in meinem Umfeld damals IBM026.
Die Beschränkung war überall: Weil die Rechner kleine Hauptspeicher
hatten, war für Zeichen ein 6-Bit-Code üblich. Aus dem Grund gab es
sehr viel Rechner mit 12, 18, 24, 36 oder 48 Bit Wortbreite. Und mit
6 Bit pro Buchstabe muss man sparsam sein.
Der Drucker unserer IBM 1130 kennt nur 44 Zeichen.
Post by Wolfgang Broeker
Ich habe aber gerade mal nachgesehen und gefunden, dass die Zeichen
"<-" dort durchaus verfügbar waren, siehe
Das war ein bewusster "Fehler" von mir: Algol hat nicht das Zeichen
"<" plus "-" gefordert, sondern ein hypothetisches Zeichen "Pfeil nach
links". Es wäre natürlich sinnlos zwei existierende Zeichen, durch zwei
andere zu ersetzen. Übrigens kann auf unserer IBM-Anlage der ":" durch
".." und ";" durch ".," ersetzt werden.
In dem Sinn waren die Algoliker ihrer Zeit voraus: Die haben gesagt, wir
machen uns doch nicht von den maschinenabhängigen Zufällen der Zeichen-
sätze abhängig. Algol ist schliesslich entstanden, bevor es den ASCII-
Code gab.
Bloss die Nachfolger, (Pascal, Oberon, Ada), die haben es nicht geblickt.
Post by Wolfgang Broeker
Dein Hinweis auf Algol unterstützt im Übrigen meine Einschätzung als
"theorielastig": Diese Sprache wie auch das noch "lastigere" Algol68
...
zu bei den Puristen so verhassten Sprachen wie FORTRAN oder PL/1.
Von PL/1 hiess es doch, es vereinige alle schlechten Eigenschaften von
FORTRAN und COBOL? :-)
Ich habe übrigens grade eines meiner neueren PL/1-Bücher rausgegriffen.
(A. Schulz, Einführung in das Programmieren in PL/1, W. de Gruiter 1984).
Da steht in der Einführung:
Es gibt den 60er Zeichensatz und den 48er Zeichensatz.
60er 48er

% //
; ,.
: ..
(das liegende L) NOT
& AND
| OR
Post by Wolfgang Broeker
GT
< LT
_ kein Äquivalent
? kein Äquivalent

Und das im Jahr 1984!

Und was das .GT. .LT. .EQ. in FORTRAN betrifft: Das war schon immer so
(seit FORTRAN IV, davor gab es nur das arithmetische IF). FORTRAN stammt
ja aus einer ganz anderen Zeit.
Post by Wolfgang Broeker
Gruß - Wolfgang
Zum Schluss noch ein FORTRAN-IV-Joke, den die heutigen Kinder natürlich
nicht mehr verstehen:

37H GOD IS REAL, UNLESS DECLARED INTEGER


Grüsse
Klemens
Wolfgang Broeker
2012-02-17 18:19:04 UTC
Permalink
Post by Klemens Krause
Zum Schluss noch ein FORTRAN-IV-Joke, den die heutigen Kinder natürlich
37H GOD IS REAL, UNLESS DECLARED INTEGER
Schön :-)

Gruß - Wolfgang
Holm Tiffe
2012-02-16 17:18:20 UTC
Permalink
Post by Roger Schwentker
Post by Peter Heitzer
ich möchte von einem CP/M-System mit 8"-Laufwerken gerne die Daten von ca. 50 Disketten auf
einen Linux-PC übertragen.
Hmm. Kermit läuft fast überall.
Post by Peter Heitzer
Ich dachte daran, dies über den Parallelport zu machen, da
es über die serielle Schnittstelle wohl zu langsam ist.
pip, dies aber ohne jede Fehlererkennung oder -korrektur.
Post by Peter Heitzer
Am elegantesten wäre eine Übertragung via Netzwerk. Gibt es für CP/M Treiber für Parallelport-
Ethernetadapter (z.B. circom)?
Treiber? Für CP/M?
CP/M bietet keine Schnittstelle zur Installation von nachladbaren
Treibern. Wenn überhaupt Treiber, dann selbst ins BIOS hinein-
compilieren.
Und einen IP-Stack für CP/M habe ich auch noch nie gesehen. Selbst
KA9Q läuft erst ab MS-DOS. Ich kann mir auch nicht vorstellen, wie
selbst eine minimale TCP-Implemantation inklusive Buffer in die MTA
passen soll.
Viele Grüße
Roger Schwentker
Najaaa, ich habe auch schon mal einen nachladbaren Treiber für CP/M2.2
geschrieben, man sollte nur wissen waq man tut. Imkonkreten Falle war
Platz für ein paar Bytes zwischen Bios und BWS, da habe ich einen
nachladbaren V2.24 Treiber für einen Drucker reingebastelt, der den
entsprechenden Sprung im BIOS überschrieb.

Sag Niemals nie..

Gruß,

Holm
Michael van Elst
2012-02-16 21:55:36 UTC
Permalink
Post by Roger Schwentker
CP/M bietet keine Schnittstelle zur Installation von nachladbaren
Treibern. Wenn überhaupt Treiber, dann selbst ins BIOS hinein-
compilieren.
pip hat eine Patch-Area, in der man einen "Treiber" einarbeiten kann.
--
--
Michael van Elst
Internet: ***@serpens.de
"A potential Snark may lurk in every tree."
Roger Schwentker
2012-02-15 21:01:43 UTC
Permalink
Post by Peter Heitzer
ich möchte von einem CP/M-System mit 8"-Laufwerken gerne die
Daten von ca. 50 Disketten auf
einen Linux-PC übertragen.
Mal eine Idee: Prinzipiell sollten sich auch 8 Zoll Laufwerke
an einen PC montieren lassen. Eine Adapterplatine von 34 auf
50 polige Stecker sollte sich finden lassen, ansonsten gibt
Seitenschneider und Lötkolben. Die 1,2 MB Floppy ist im Prinzip
eine 8 Zoll Scheibe, Drehzahl und Übertragungsrate passen.

CP/M Dateisystemtreiber für DOS gibt es durchaus.

Ein TCP-Stack für DOS ließe sich auch arrangieren, beispielsweise
KA9Q und Packet-Treiber.

Wie ich schon schrieb: Nur eine Idee.

Viele Grüße
Roger Schwentker
***@regioconnect.net
--
F.D.P. - Die parlamentarische Vertretung der Heuschrecken
[Georg Schramm, 2008]
Holm Tiffe
2012-02-16 17:24:02 UTC
Permalink
Post by Roger Schwentker
Post by Peter Heitzer
ich möchte von einem CP/M-System mit 8"-Laufwerken gerne die
Daten von ca. 50 Disketten auf
einen Linux-PC übertragen.
Mal eine Idee: Prinzipiell sollten sich auch 8 Zoll Laufwerke
an einen PC montieren lassen. Eine Adapterplatine von 34 auf
50 polige Stecker sollte sich finden lassen, ansonsten gibt
Seitenschneider und Lötkolben. Die 1,2 MB Floppy ist im Prinzip
eine 8 Zoll Scheibe, Drehzahl und Übertragungsrate passen.
Geht, wenn der Controller das kann. Ich habe das vor 14 Tagen gerade
gemacht um Disketten für eine russische E60 formatieren zu können
(Program PUTR). Eine E60 ist im Prinzip eine LSI11/03 mit einem RX01
Disklaufwerk dran. Der 5 Controller konnte das. Ich habe aber noch einen
ATTiny2313 zusätzlich gebraucht der sie Steps mitzählt und ab Spur 43
das TG43 Signal für das 8 Zoll Laufwerk erzeugt. Es gibt Laufwerke die
das nicht benötigen.

Das Controller-Problem tritt auf, weil der Controller auch FM
produzieren können muß, was nicht jeder PC Controller kann.

Gruß,

Holm
fritz chwolka
2012-02-15 21:08:33 UTC
Permalink
Post by Peter Heitzer
Hallo,
ich möchte von einem CP/M-System mit 8"-Laufwerken gerne die Daten von ca. 50 Disketten auf
einen Linux-PC übertragen. Ich dachte daran, dies über den Parallelport zu machen, da
es über die serielle Schnittstelle wohl zu langsam ist.
Hat jemand schon so etwas gemacht und kann mir Hinweise zu Quellen für Transferprogrammen
(sowohl CP/M als auch Linux) geben?
Am elegantesten wäre eine Übertragung via Netzwerk. Gibt es für CP/M Treiber für Parallelport-
Ethernetadapter (z.B. circom)?
Danke schon mal
INfos auch Hier:


http://hc-ddr.hucki.net/wiki/doku.php/cpm:disketten_xp
http://www.li-pro.net/cpm-emu-linux-tools.phtml
http://home.iae.nl/users/pb0aia/cm/8-525.html
Holger
2012-02-16 02:33:29 UTC
Permalink
Post by Peter Heitzer
Hallo,
ich möchte von einem CP/M-System mit 8"-Laufwerken gerne die Daten von ca. 50 Disketten auf
einen Linux-PC übertragen. Ich dachte daran, dies über den Parallelport zu machen, da
es über die serielle Schnittstelle wohl zu langsam ist.
Hat jemand schon so etwas gemacht und kann mir Hinweise zu Quellen für Transferprogrammen
(sowohl CP/M als auch Linux) geben?
Am elegantesten wäre eine Übertragung via Netzwerk. Gibt es für CP/M Treiber für Parallelport-
Ethernetadapter (z.B. circom)?
Netzwerk kannst du vergessen, würde ich sagen. Am Einfachsten ist eine
Übertragung via serieller Schnittstelle. Transferprogramme könnten
minicom und picocom auf Linuxseite sein, oder Telix in der DOS-Box, geht
auch. CP/M-seitig würde ich es erstmal mit dem Kopieren auf das
PUN:-Device versuchen oder aber auch hier in Turbo-Pascal einen
entsprechenden Treiber schreiben.

Holger
Peter Heitzer
2012-02-16 09:49:42 UTC
Permalink
Post by Holger
Post by Peter Heitzer
Hallo,
ich möchte von einem CP/M-System mit 8"-Laufwerken gerne die Daten von ca. 50 Disketten auf
einen Linux-PC übertragen. Ich dachte daran, dies über den Parallelport zu machen, da
es über die serielle Schnittstelle wohl zu langsam ist.
Hat jemand schon so etwas gemacht und kann mir Hinweise zu Quellen für Transferprogrammen
(sowohl CP/M als auch Linux) geben?
Am elegantesten wäre eine Übertragung via Netzwerk. Gibt es für CP/M Treiber für Parallelport-
Ethernetadapter (z.B. circom)?
Netzwerk kannst du vergessen, würde ich sagen. Am Einfachsten ist eine
Übertragung via serieller Schnittstelle. Transferprogramme könnten
minicom und picocom auf Linuxseite sein, oder Telix in der DOS-Box, geht
Darauf wird es wohl hinauslaufen. Ich habe gerade überschlagen. Die Disketten sind i.d.R.
SS/SD und kaum randvoll. Bei geschätzten 200 KB/Diskette sollte die Übertragung bei 9600 Baud
in max. 5 Minuten erledigt sein.
Über das Protokoll muß ich mir noch ein paar Gedanken machen. Es sollte pro Diskette nur ein
Return erforderlich sein. Die Generierung des Diskettennamens kann automatisch erfolgen (disk<xx>)
und die Dateinamen müssen natürlich mit übertragen werden.
Am einfachsten ist es wohl, alle Dateien in ein (gepacktes) Archiv zu stecken und dieses
dann übertragen.
--
Dipl.-Inform(FH) Peter Heitzer, ***@rz.uni-regensburg.de
HTML mails will be forwarded to /dev/null.
fritz chwolka
2012-02-16 17:02:28 UTC
Permalink
Post by Peter Heitzer
Post by Holger
Post by Peter Heitzer
Hallo,
ich möchte von einem CP/M-System mit 8"-Laufwerken gerne die Daten von ca. 50 Disketten auf
einen Linux-PC übertragen. Ich dachte daran, dies über den Parallelport zu machen, da
es über die serielle Schnittstelle wohl zu langsam ist.
Hat jemand schon so etwas gemacht und kann mir Hinweise zu Quellen für Transferprogrammen
(sowohl CP/M als auch Linux) geben?
Am elegantesten wäre eine Übertragung via Netzwerk. Gibt es für CP/M Treiber für Parallelport-
Ethernetadapter (z.B. circom)?
Netzwerk kannst du vergessen, würde ich sagen. Am Einfachsten ist eine
Übertragung via serieller Schnittstelle. Transferprogramme könnten
minicom und picocom auf Linuxseite sein, oder Telix in der DOS-Box, geht
Darauf wird es wohl hinauslaufen. Ich habe gerade überschlagen. Die Disketten sind i.d.R.
SS/SD und kaum randvoll. Bei geschätzten 200 KB/Diskette sollte die Übertragung bei 9600 Baud
in max. 5 Minuten erledigt sein.
Über das Protokoll muß ich mir noch ein paar Gedanken machen. Es sollte pro Diskette nur ein
Return erforderlich sein. Die Generierung des Diskettennamens kann automatisch erfolgen (disk<xx>)
und die Dateinamen müssen natürlich mit übertragen werden.
Am einfachsten ist es wohl, alle Dateien in ein (gepacktes) Archiv zu stecken und dieses
dann übertragen.
Für DOS findest du CF/X da CP/M-Archive nicht zu gängigen
Packern/Entpackern kompatibel sind.

Hier findest du weitere Informationen
http://www.z80.eu/transfercpm.html
http://www.z80.eu/cpmcomp.html ( go down)

Für CP/M

ftp://ftp.gaby.de1.biz/2/268517_81539/pub/cpm/znode51/cpmtools/packer/


Was ist es den für ein CP/M System ?


MfG.

Fritz
Peter Heitzer
2012-02-16 17:25:36 UTC
Permalink
Post by fritz chwolka
Was ist es den für ein CP/M System ?
Ein ECB-System mit RZ-Eigenen BIOS-Anpassungen und ein CP/M Version 2.2. Soweit ich es
überblicke, ziemlich normal ohne grosse Spezialitäten.
--
Dipl.-Inform(FH) Peter Heitzer, ***@rz.uni-regensburg.de
HTML mails will be forwarded to /dev/null.
Holm Tiffe
2012-02-16 17:25:39 UTC
Permalink
[..]
Post by Peter Heitzer
Post by Holger
Netzwerk kannst du vergessen, würde ich sagen. Am Einfachsten ist eine
Übertragung via serieller Schnittstelle. Transferprogramme könnten
minicom und picocom auf Linuxseite sein, oder Telix in der DOS-Box, geht
Darauf wird es wohl hinauslaufen. Ich habe gerade überschlagen. Die Disketten sind i.d.R.
SS/SD und kaum randvoll. Bei geschätzten 200 KB/Diskette sollte die Übertragung bei 9600 Baud
in max. 5 Minuten erledigt sein.
Über das Protokoll muß ich mir noch ein paar Gedanken machen. Es sollte pro Diskette nur ein
Return erforderlich sein. Die Generierung des Diskettennamens kann automatisch erfolgen (disk<xx>)
und die Dateinamen müssen natürlich mit übertragen werden.
Am einfachsten ist es wohl, alle Dateien in ein (gepacktes) Archiv zu stecken und dieses
dann übertragen.
Huh, 8 Zoll Disketten können u.U bis 2 Megabyte Brutto enthalten
(Doppelseitig MFM).

Gruß,

Holm
Peter Heitzer
2012-02-16 17:29:18 UTC
Permalink
Post by Holm Tiffe
[..]
Post by Peter Heitzer
Post by Holger
Netzwerk kannst du vergessen, würde ich sagen. Am Einfachsten ist eine
Übertragung via serieller Schnittstelle. Transferprogramme könnten
minicom und picocom auf Linuxseite sein, oder Telix in der DOS-Box, geht
Darauf wird es wohl hinauslaufen. Ich habe gerade überschlagen. Die Disketten sind i.d.R.
SS/SD und kaum randvoll. Bei geschätzten 200 KB/Diskette sollte die Übertragung bei 9600 Baud
in max. 5 Minuten erledigt sein.
Über das Protokoll muß ich mir noch ein paar Gedanken machen. Es sollte pro Diskette nur ein
Return erforderlich sein. Die Generierung des Diskettennamens kann automatisch erfolgen (disk<xx>)
und die Dateinamen müssen natürlich mit übertragen werden.
Am einfachsten ist es wohl, alle Dateien in ein (gepacktes) Archiv zu stecken und dieses
dann übertragen.
Huh, 8 Zoll Disketten können u.U bis 2 Megabyte Brutto enthalten
(Doppelseitig MFM).
Mir sind hier bisher max. SS/DD untergekommen.
--
Dipl.-Inform(FH) Peter Heitzer, ***@rz.uni-regensburg.de
HTML mails will be forwarded to /dev/null.
Roger Schwentker
2012-02-16 18:45:11 UTC
Permalink
Post by Holm Tiffe
Huh, 8 Zoll Disketten können u.U bis 2 Megabyte Brutto enthalten
(Doppelseitig MFM).
Hmmm, sicher?

77 Spuren, zwei Seiten.

Weiter: MFM sind bei 8 Zoll (!) 500 KBit/s, bei 6 Umdrehungen pro
Sekunde sind das gut 83 KBit pro Spur, knapp 10,6 KByte. Mit
pfiffigen Formatieren bei 1 KByte pro Sektor könnten tatsächlich
10 KByte pro Spur netto herauskommen, alleine mir fehlt der Glaube.
Macht 10*2*77=1540 Kbyte pro Diskette.

Tut mich traurig, mehr wird es nicht.

Achja, die Spurnummer steht in der Präambel jedes Sektors, 8 Zoll
Laufwerke beginnen bei "1", nicht bei "0".

Viele Grüße
Roger Schwentker
***@regioconnect.net
--
F.D.P. - Die parlamentarische Vertretung der Heuschrecken
[Georg Schramm, 2008]
Holm Tiffe
2012-02-18 16:41:19 UTC
Permalink
Post by Roger Schwentker
Post by Holm Tiffe
Huh, 8 Zoll Disketten können u.U bis 2 Megabyte Brutto enthalten
(Doppelseitig MFM).
Hmmm, sicher?
77 Spuren, zwei Seiten.
Weiter: MFM sind bei 8 Zoll (!) 500 KBit/s, bei 6 Umdrehungen pro
Sekunde sind das gut 83 KBit pro Spur, knapp 10,6 KByte. Mit
pfiffigen Formatieren bei 1 KByte pro Sektor könnten tatsächlich
10 KByte pro Spur netto herauskommen, alleine mir fehlt der Glaube.
Macht 10*2*77=1540 Kbyte pro Diskette.
Tut mich traurig, mehr wird es nicht.
Achja, die Spurnummer steht in der Präambel jedes Sektors, 8 Zoll
Laufwerke beginnen bei "1", nicht bei "0".
Viele Grüße
Roger Schwentker
Da gibts ein bei google auffindbares Datenblatt zum NEC FD1165, grab
Dich mal da durch..

Gruß,

Holm
Christian Corti
2012-02-16 09:46:22 UTC
Permalink
Post by Peter Heitzer
Hallo,
ich möchte von einem CP/M-System mit 8"-Laufwerken gerne die Daten von ca. 50 Disketten auf
einen Linux-PC übertragen. Ich dachte daran, dies über den Parallelport zu machen, da
es über die serielle Schnittstelle wohl zu langsam ist.
Hat jemand schon so etwas gemacht und kann mir Hinweise zu Quellen für Transferprogrammen
(sowohl CP/M als auch Linux) geben?
Am elegantesten wäre eine Übertragung via Netzwerk. Gibt es für CP/M Treiber für Parallelport-
Ethernetadapter (z.B. circom)?
Einfachste Lösung (zumindest für mich ;-)): Diskette in ein 8"-LW am PC
einschieben (der Floppycontroller muß dabei zwingend FM beherrschen,
sehr viele können leider nur MFM) und mit 22DISK die Dateien rüberkopieren.

Bei 50 Disketten würde sich der Aufwand durchaus lohnen, das evtl.
vorhandene externe 8"-Laufwerk über einen Adapter an einen DOS-Rechner
mit gescheitem Floppycontroller (eine Liste gibt's z.B. auf der Seite
von Dave Dunfields ImageDisk) anzuschließen; oder jemanden in der Nähe
finden, der einen so aufgerüsteten PC hat.

Christian
Lesen Sie weiter auf narkive:
Loading...