Anwendungsentwicklung für CP/M 2.x

Christian J. schrieb:
> Hallo,
>
> [...] Die Editoren sind
> gelinde gesagt grausam!

Echt? Wordstar auch? :-)

> Dagegen ist "edlin" von DOS 3.x noch ein echte
> Perle! Beim Apple II hatte ich schon einen besseren Editor in der Schule
> um 1985 herum.

Auf Apple II könnte das sogar Wordstar gewesen sein.

> [...]

OK. Ist mir nur spontan eingefallen. Ich fand den damals recht gut, aber 
was dem einen "sin Uhl ..." :-)

Ctrl-K S, Ctrl-K X :-)

Danach kam nur noch Brief. Aber das ist ein anderes Thema.

Jörg W. schrieb:
> Theor schrieb:
>> Ctrl-K S, Ctrl-K X :-)
>
> Ctrl-K D (wie "done")? ;-)
>
> Dunkel ist die Erinnerung …

Na, bei Dir ist jedenfalls mehr Licht als bei mir ... :-)

Das Handbuch liegt irgendwo auf der NAS.

Jörg W. schrieb:
> Bzw. der Editor von Turbo-Pascal.

Der hiess "Applewriter" und war im Paket für UCSD Pascal, von dem ich 
nach 35 Jahren die Tastensequenzen noch im Kopf habe, so oft wie ich die 
drücken musste. Eine Floppy fiel fast auseinander, so oft wie die 
gerödelt hat, da konnte man fast durchgucken so durch war die Scheibe. 
360kb.....
Cntrl K-S war Schreiben und Cntrl-K-Q war Editor verlassen. meist wurde 
aber Aztec gespielt wenn der Pauker mal raus war.

Aber keine CP/M Entwickler hier? Zuerst gilt es ja die Umgebung auf zu 
setzen und da fehlen mir bisher noch die idee, bzw Werkzeuge. Beim 
eigenen Z80 Bau habe ich erstmal einen Intel Hex Interpreter geschrieben 
und den ins ROM gebrannt, damit wir überhaupt miteinander reden konnten. 
Ist aber alles schon da, man kopiert den Intel-Hex einfach ins Terminal 
Window mit C&P und der zieht sich das rein, legt es als .COM ab und man 
kann es zünden und starten. Als Debug die rote LED am HALT Pin, mehr 
hatte ich früher auch nicht. HALT war Universal Debugger.

Naja. Alles schon ne Weil her für mich. :-)

Aber Du könntest mal MESCC angucken (http://www.z80.eu/c-compiler.html). 
Da es komplett im Quellcode vorhanden ist, müsstest Du den ASM-Code 
übernehmen können. Überprüft habe ich das allerdings nicht.

Überhaupt sind da einige "Freaks" noch am Werke. (Ich habe zwar noch 
einen Z80 Rechner mit CP/M+, aber schon lange nichts mehr mit gemacht).

Mit relativ wenig Suche kommt man auch auf Seiten, wo komplett CP/M, 
MP/M etc. und Unterlagen und einige Anwendungen heruntgergeladen werden 
können. Ist nicht besonders versteckt. :-)

Christian J. schrieb:
> Aber keine CP/M Entwickler hier?

Keine noch aktiven - ich habe weit mehr als 100000 Zeilen Code in 
Prospero Pascal für CP/M geschrieben, für Messmaschinen mit 
Z80-Steuerungen, hauptsächlich für die Autoindustrie.

Propas war natürlich an CP/M angepasst, um Floppy, BDOS usw. musste ich 
mich nicht extra kümmern. Für die Grafik hatte ich eine eigene 
Bibliothek erstellt, da es eine Grafik mit Funktionen wie Kreise, 
Balken, verschiedene Schriftgrössen  usw. natürlich nicht gab. Ebenso 
wurde der Hardwarezugriff z.B. auf Motorantriebe in Assembler 
programmiert. Mit Pascal, Assembler, Linker und Makefiles ergab sich ein 
weitgehend automatisches Abarbeiten für am Ende mehr als 200 
Programmteile. Eine Vorverarbeitung für Sprachdateien gab es auch, da 
die Steuerungen in Deutsch, Englisch, Französisch, Spanisch, Italienisch 
und Russisch ausgeliefert wurden - vollautomatisch.

Würde übrigens alles noch funktionieren, ist halt einfach vorbei. Es gab 
auch noch andere vergleichbare Projekte wie etwa Messautomaten für die 
Pharmaindustrie.

Georg

Turbo-Pascal 3.0 habe ich noch als sehr angenehm in Erinnerung. Damit 
habe ich unter CP/M und MSDOS viel gemacht. Ja, ist kein C, aber mit 
etwas Grips in der Birne bekommt man das auch nach 30 Jahren wieder hin.

{} -> begin end
= -> :=
== -> =
!= -> <>

So schwer ist das nicht. Und Du findest den auch noch im Netz.

fchk

CP/M habe ich so bis 1993 gewerkelt.
und Wordstar konnte nur Dateien bis 1023KB bearbeiten, dass habe ich 
auch erst bemerkt, als die RAM-Diskette 2MB hatte.

Moin,

danke für die Infos. Meine Pascal Mappe mit den Ausdrucken von 1985 habe 
ich noch im Keller liegen, Epson FX 80 Endlos Papier. Und die 
Datenträger auch aber die waren nur für Apple II und auf nichts anderem 
lesbar. Borland Turbo Pascal auch 1993 für die Studienarbeit unter DOS, 
sogar mit aufwendigen Grafik Messkurven. Aber alles weg, Datenunfall von 
2002 und die CD mit der Diplomarbeit ist nicht mehr lesbar gewesen nach 
25 Jahren.

Pascal im nicht dabei, zumindest nicht im ROM. Da sind nur die Standard 
Sachen dabei. Alles andere werde ich einspielen müssen, Floppy war schon 
dran aber die war auch hinüber. Klar, kam ja auch aus unserer 
Elektroschrott Tonne. Zuckte nur noch. 5V reichen aber, 12V hatte die 
nicht am Berg Stecker. Erstmal ne neue bestellt, dann kann ich da was 
draufspielen. Ohne Verzeichnisse ...grrr.... wie das aussieht, alles 
zusammen geklatscht.

Hoffen wir mal dass es dieses WE ordentlich regnet und stürmt, dann ist 
es umso gemütlicher im Arbeitszimmer....

Christian

Christian J. schrieb:
> Woher kriege ich eine Lib, die...

..für printf und xprintf dient?

Nein, bei einem System, wo man für seinen Code + seine Daten deutlich 
weniger als 64K an RAM hat, leistet man sich nicht eine Lib für sowas 
wie printf und Konsorten, sondern paßt seine I/O an die 
BDOS-Schnittstelle an. Selbst das Zugreifen auf die BIOS-Sprungleiste 
sollte man nach Möglichkeit vermeiden.

Aber was willst du eigentlich tun? Einen weiteren CP/M-Emulator für den 
PC schreiben? Oder einen bildschirm-orientierten Editor für CP/M 
schreiben? Find ich als solches OK. Wenn du es fertig hast, dann poste 
es bitte hier.

Mache dich aber von Anfang an darauf gefaßt, daß du für die Funktionen 
des Editors und auch für das Navigieren auf dem Terminal-Bildschirm 
keinerlei Funktionstasten hast - und daß du deinen Editor so gestalten 
mußt, daß andere Leute ihn an ihren jeweiligen Bildschirm anpassen 
können.

CP/M arbeitet strikt nur mit 7 Bit ASCII (wird gnadenlos im BDOS so 
maskiert) - und wer sich irgend etwas Anderes ausdenkt, wird eben 
inkompatibel zu allen anderen CP/M-Systemen sein. Da ist es schlichtweg 
normal, daß man notgedrungen mit Ctrl+Buchstabe an der Konsole arbeiten 
muß.

Bedenke mal, daß es z.B. ganz normal war, WordStar mit seinen 
Escapesequenzen an das gerade vorhandene Videoterminal anzupassen.

So herum ging das damals bei CP/M. Dem OS waren bis auch wenige 
Ctrl-Kommandos die Controlcodes herzlich schnurz und zur Anpassung an 
vorhandene Hardware mußten die Anwendungen, die es brauchten, angepaßt 
werden. Es ist ja mittlerweile auch 40 Jahre her!

Also nochmal, wenn du einen schicken Editor schreiben willst, dann mußt 
du zwangsweise in/für selbigem eine Art Patchfeld vorsehen, das für die 
diversen Editorkommandos dient und wo man dein Programm an die 
unterschiedlichen Hardware-Gegebenheiten anpassen kann.


Christian J. schrieb:
> Um ein VT100 anzusteuern bedarf es einer ncurses Lib, damit man die
> Ausgaben direkt steuern kann und sich nicht mit den ESC Sequenzen
> herumschlägt. mcurses benutzen? Oder irgendwas was CP/M schon hat.

Das wäre genau verkehrt herum. Damals gab es diverse Video-Terminals - 
und die hatten so ihre eigenen Escape-Sequenzen, weswegen der Weg 
umgekehrt war, siehe oben. Um also z.B. ein VT100 anzusteuern, braucht 
es die Kenntnis von dessen Escapesequenzen. CP/M hat von alledem NICHTS. 
Das war Sache der Anwendungen, die es brauchen. Ähnliches gilt für 
Drucker-Ausgaben.

Ich halte es auch für falsch, irgendwelche mehr oder weniger fetten Libs 
zum Umsetzen, printf etc. verwenden zu wollen - dafür ist es in den 64K 
schlichtweg zu enge. Bedenke, daß das Konzept von CP/M aus den späten 
70er Jahren stammt und im Wesentlichen auf Assembler und PL/1 etc. 
aufbaut. Das war deutlich vor der Zeit von C.

Ach ja, und wenn du schon in diese Gefilde steigen willst, dann wäre ein 
bildschirmorientierter Ersatz für den CCP auch was ganz Nettes. Etwa so 
ähnlich wie QDOS am PC der frühen 90er Jahre.

W.S.

W.S. schrieb:

> Ich halte es auch für falsch, irgendwelche mehr oder weniger fetten Libs
> zum Umsetzen, printf etc. verwenden zu wollen - dafür ist es in den 64K
> schlichtweg zu enge.

Ich habe schon xprintf von Chan auf den Z80 portiert und das ist ganz 
schmal, keine 400 Bytes. Man muss nur die Putchar und getchar umbiegen 
in diesem Fall wäre es RST 8, der einen Software INT auslöst ins HBIOS. 
Die Doku habe ich, wie beim guten alten "DOS Intern" was ich als 
Virenschreiber damals auswendig kannte. Brauche aber noch etwas Zeit die 
Basics zu lernen und darin Routine zu entwickeln. Dann kommen die 
Updates und da die sowieso nur für mich sind müssen die auch nicht 
kompatibel sein. Das würde das Machbar für 1 Person übersteigen.

Und mcurses.c von Frank(ukw) tut genau das was ich will: Es gibt sogar 
bunt aus auf dem minicom. Ohne sich mit den Sequenzen herum zu schlagen.

Das wird schon..... nur dauert es eben und viel Lesen. Und vielleicht 
schreibe ich ja doch den ersten CP/M Virus :-)

Jörg W. schrieb:
> … auf solchen Systemen ist UNIX entstanden. ;-)

Ach Jörg.... unsere Vorfahren waren auch mal Einzeller in der Ursuppe.

W.S.

Christian J. schrieb:
> Man muss nur die Putchar und getchar umbiegen
> in diesem Fall wäre es RST 8, der einen Software INT auslöst ins HBIOS.

Moment mal... das ist dann aber nix, was für ein normales CP/M geeignet 
wäre. Ich nehme mal an, daß du dich speziell auf das RomWBW-Projekt 
beziehst.

Für normale Programme wäre der richtige Weg über's BDOS oder (wenn man 
das tatsächlich unbedingt will) über die BIOS-Einsprünge 2 bis 4 (Const, 
Conin, Cout).

W.S.

Christian J. schrieb:
> Der
> SDCC erzeugt sehr guten Code verglichen mit Asm, wenn man seine
> Iteration tief genug setzt, dann braucht er aber auch rund 10 Minuten.

Nimm doch etwas das damals auf CM/M verwendet wurde. Notfalls Tiny-C 
oder Small-C. Soweit ich mich erinnere war BDS C lange der Gold-Standard 
auf CP/M, aber da kann ich mich irren oder hatte in meiner Ecke des 
Universums nicht die richtigen Informationen (das war alles vor 
weitverbreitetem Internet).

Was hältst du denn von dieser Liste? http://www.z80.eu/c-compiler.html

> Woher kriege ich eine Lib, die mir Zugriff auf die BDOS und HBIOS
> Funktionen gewährt, ohne dass ich das alles selbst eintippen muss?

Lib? Assembler einbinden! So war das damals.

> Um ein VT100 anzusteuern bedarf es einer ncurses Lib,

Nein, ESC-Sequenzen für Terminals und Drucker wurden hart in die 
jeweiligen Programm-Binaries reingepatcht. Die entsprechenden Adressen 
standen im Handbuch des Programms und man muste selber wissen was das 
eigene Terminal braucht um z.B. eine Zeile hoch oder runter zu gehen.

> Oder irgendwas was CP/M schon hat.

CM/M hat nix.

> Ich möchte als erstes einen besseren Editor schreiben,

Warum nicht erst mal die 300 Disketten der SIG/M durchstöbern was sich 
so findet:

http://www.classiccmp.org/cpmarchives/ftp.php?b=cpm%2FSoftware%2FWalnutCD%2Fsimtel%2Fsigm

Oder direkt emacs :-))

http://www.classiccmp.org/cpmarchives/ftp.php?b=cpm%2FSoftware%2FWalnutCD%2Fsimtel%2Femacs

georg schrieb:
> ich habe weit mehr als 100000 Zeilen Code in
> Prospero Pascal für CP/M geschrieben,

Prospero Pascal? Da bekomme ich Vietnam-Flashbacks :-) Was war ich immer 
neidisch auf die Kollegen die Turbo Pascal mit der schnellen IDE, dem 
schnellen Compiler und den vielen Spracherweiterungen verwenden konnten. 
Prospero Pascal war ja ein fast reines ISO-Pascal.

Für berechnungsintensive Anwendungen war ich froh dass ich auf Prospero 
FORTRAN wechseln konnte. Vielleicht nicht besser, aber anders.

Der Preis für eine Lizenz war damals um die 75 britische Pfund.

Peter S. schrieb:
> An den user <n> Befehl denken.. hilft beim aufgräumten DIR. ;-)

Ah ja.... mal davon gehört :-)

So, erstmal alles hier innerlich verarbeiten... ne Menge Infos!
Danke!

Kriege trotzdem wieder das Zittern.... aber ich wollte es ja :-/
1987 kannte ich die Zahlen auswendig, konnte jeden Befehl für 8085
direkt in Hex-Code übersetzen....wegen Tabelle abtippen in die
Tastatur... und wehe da musste was geändert werden.

1

getfn:  lda mflag  ; has command line been fully processed?

2

  ora a

3

  jz gfnzz2  ;if so, go do something else...

4

5

  lhld cptr  ;no.

6

gfn0:  mov a,m

7

  call twhite  ;skip leading white space at the current position

8

  jnz gfna  ;of scanning

9

  inx h

10

  jmp gfn0

11

12

gfna:  ora a    ;have we reached the end of the line (so to speak)?

13

  jnz gfnb

14

gfnzz:  sta mflag  ;yes. set this flag to tell us so next time

15

16

  lda donef  ;If link has been completed already, and we were

17

  ora a    ;just scanning for more possible command line options,

18

  rnz    ;then return right here.

19

20

gfnzz2:  lda dflag  ;if haven't searched DEFF.CRL yet,

@Christian...ehe Du wieder unbremsbar los rennst...sieh zu das Du die 
Walnut Creek CDROM irgendwo bekommst oder schau wenigstens mal hier rein 
http://www.retroarchive.org/cpm/ .
Ich bezweifele sehr stark das du mit Deinen bisherigen Kenntnissen zu 
CP/M einen wie auch immer "besseren" Editor schreiben kannst. Vergiß 
RST8 so schnell wie möglich wieder.

Gruß,
Holm

PS: Ich weiß das Du sowieso nicht auf mich hörst, das geht wieder 
genauso aus wie der erste Z80 Rechner.

S. R. schrieb:
> Informierst du dich eigentlich, bevor du hier fragst?

Ich bin grad etwas erschlagen von Infos und muss die erstmal verarbeiten 
... das ist für den Moment noch etwas zu viel ... aber vor dem 
Selbstmachen steht erstmal das Studium... jedenfalls habe ich schonmal 
einen C Compiler drauf spielen können und an ZDE gewöhnt man sich auch. 
Nur seine Konfigurationfinde ich nicht. Da ist nur zde.com und nichts 
weiter.

Ich melde mich ein paar Tage später mal wieder hier....

------
Das ist nachvollziehbar. Allerdings kannst du dann auch gleich in einem
CP/M-Emulator entwickeln, das erspart dir den Weg durch die reale
Hardware.
-----

Auch soweit bin ich schon, da es sehr mühsam ist per xmodem alles zu 
übertragen und leider sind gute Terminamlprogramme wie secureCRT auch 
sehr teuer. Und mit minicom... naja, man tastet sich halt durch..

Christian J. schrieb:
> Auch soweit bin ich schon, da es sehr mühsam ist per xmodem alles zu
> übertragen und leider sind gute Terminamlprogramme wie secureCRT auch
> sehr teuer. Und mit minicom... naja, man tastet sich halt durch..

...putty?

Gruß,
Holm

holm schrieb:
> ...putty?

Schonmal xmodem oder zmodem Transfer in Putty gesehen? Das ist nur ein 
Fenster aber nix was wir früher zur Mailboxzeit noch hatten mit 
crosspoint.
secureCRT ist ein gutes Tool, aber eben 129 USD.

Zumindets grad mal ZORK1 aufgespielt mit minicom... naja, die Grafik ist 
nicht so der Kracher :-)

S. R. schrieb:
> Picocom? Für mein Z80-System habe ich die relevanten Dinge einfach
> durchgescriptet. Drei Tastendrücke und das neue System läuft.

Naja, so ähnlich damals... mit der Kiste die nur Intel-Hex laden konnte 
und kaum etwas mehr, weil ich da arbeitslos war und Zeit hatte, als ich 
beim Befehlsparser war fand ich einen neuen Job und das war es dann.

#!/bin/bash
echo "---------------------------------"
echo "Datentrasnfer zum Z80"
echo "---------------------------------"

echo "Stelle tty/USB0 auf 9600 baud ein....."
stty 9600 raw -parenb -crtscts -ixoff -F /dev/ttyUSB0
echo "Sende "load" Startsequenz...."
echo -n -e "load\r" > /dev/ttyUSB0
sleep 1
echo "Uebertrage Daten...."
cat build/z80ram.ihx > /dev/ttyUSB0
#echo -n -e "\r" > /dev/ttyUSB0
#echo -n -e "run\r" > /dev/ttyUSB0
echo "Fertig!"

S. R. schrieb:
> ...und warum bist du dazu jetzt nicht mehr in der Lage?

Weil das meine eigene Suppe war. So ad hoc kriege ich es noch leider 
nicht hin ein COM Programm zu erstellen, was auf diesem System genau das 
macht, was ich damals gebaut habe, weil ich alles selbst machen musste. 
Aber xmodem werde ich noch bedienen können unter usr/bin/sx bla bla bla 
... Morgen, jetzt ist Amazon Prime Time :-) PICARD....

Christian J. schrieb:
> holm schrieb:
>> ...putty?
>
> Schonmal xmodem oder zmodem Transfer in Putty gesehen? Das ist nur ein
> Fenster aber nix was wir früher zur Mailboxzeit noch hatten mit
> crosspoint.
> secureCRT ist ein gutes Tool, aber eben 129 USD.
>
> Zumindets grad mal ZORK1 aufgespielt mit minicom... naja, die Grafik ist
> nicht so der Kracher :-)

Naja ..soll mir Banane sein. Ich nehme meist seyon, das dürften die 
Meisten gar nicht kennen (habe aber auch schon im Quelltext 
herumgemurkst). Den Transfer darüber, falls ich ihn wirklich mal 
benötige, erledigen die Standard Unix Tools wie sx, sz und Konsorten die 
da einfach geforkt werden. Windows fasse ich nicht an, wenn es nicht 
unbedingt notwendig ist, das geht mir auf die Nerven.

Gruß,
Holm

holm schrieb:
> Den Transfer darüber, falls ich ihn wirklich mal
> benötige, erledigen die Standard Unix Tools wie sx, sz und Konsorten die
> da einfach geforkt werden.

Hast Du zufällig ein COM Programm was das XMODEM Protokoll unterstützt, 
da ich damit mehrere Dateien übertragen kann und vor allem nicht deren 
Zielnamen eingeben muss. Dann tausche ich xmodem im ROM einfach aus.

Mit Teraterm kommt man ganz gut klar.

Georg G. schrieb:
> Christian J. schrieb:
>> Programm was das XMODEM Protokoll unterstützt
>
> Teraterm

Ich meine auf der anderen Seite, was ich auf CPM überspielen kann.

Christian J. schrieb:
> holm schrieb:
>> Den Transfer darüber, falls ich ihn wirklich mal
>> benötige, erledigen die Standard Unix Tools wie sx, sz und Konsorten die
>> da einfach geforkt werden.
>
> Hast Du zufällig ein COM Programm was das XMODEM Protokoll unterstützt,
> da ich damit mehrere Dateien übertragen kann und vor allem nicht deren
> Zielnamen eingeben muss. Dann tausche ich xmodem im ROM einfach aus.
>
> Mit Teraterm kommt man ganz gut klar.

lrzsz:
"This program uses error correcting protocols to send/receive
files over a dial-in serial port from a variety of programs
running under PC-DOS, CP/M, Unix, and other operating systems.

lrzsz is derived from the last unrestricted version of Chuck Forsberg's
rzsz package.  lrzsz is covered under the GNU copyleft.

WWW: https://ohse.de/uwe/software/lrzsz.html
"

Gruß,
Holm

...und es gibt natürlich auch immer noch kermit, auch für CP/M.

Gruß,
Holm

Georg G. schrieb:
> XMODEM... was sonst?

Ich meinte ZMODEM... damit kann man mehr überspielen.

S. R. schrieb:

> Du kannst dir auch ein Script schreiben, was einfach XMODEM mehrfach
> aufruft... ich sehe irgendwie kein Problem, außer dem, welches du
> machst.

Es gibt unter CPM Skripte? Vermutlich habe ich da noch einen Bug 
gefunden. Unter mbasic gespeicherte Dateien, egal ob als Token 
Binärdatei oder als ANSI (save "a:basic.bas",a) sind beim Reboot unter 
cp/m weder anzeigbar noch löschbar. Sie werden zwar mit dir angezeigt 
aber sind sonst unerreichbar. weder stat, noch type, noch era erkennen 
sie als existent.

Ich vermute mal, dass das was mit der Gross/Kleinschreibung zu tun hat. 
Musste die Buffer Batterie abklemmen, damit sie weg waren.

TREK.BAS wurde über xmodem eingespielt, das ist sichtbar, ausführbar und 
auch löschbar. Die über die mbasic eigenen Funktionen erzeugten Dateien 
leider nicht. Sind aber unter mbasic trotzdem wieder ladbar.

S. R. schrieb:
> Aber ich dachte an ein Script auf der Host-Seite.
> Genau so ein Teil, was du hier schon gepostet hast.
> Wo ich dich fragte, warum du das nicht mehr kannst.

Das wäre kein Problem, aber wenn Du xmodem aufrufst, dann verlangt es 
von Dir einen Dateinamen. Von daher ist keine Automatisierung möglich. 
Ich "spreche" zwar bash skript, zumindest einfache Sachen wie Backups 
machen, Rest gucke ich im großen Rheinwerk Buch nach aber das gilt nur 
für die Sendeseite.

Danke für den Hinweis mit mbasic. Dachte mit schon sowas. open und close 
usw. klappen leider auch nicht, da wird ein type mismatsch angezeigt. An 
Basic könnte ich mich wieder gewöhnen nach 30 Jahren.>

XMODEM v12.5 - 07/13/86
RBC, 06-Jun-2018 [WBW], UART0

Uploads files to specified or current disk/user
Private files to A0: (346k available for uploads)

++ Examples of valid options: ++ (use Ctrl-C or Ctrl-K to abort)

XMODEM S HELLO.DOC         send a file to you
XMODEM S B1:HELLO.DOC      send from a named drive/area
XMODEM SK HELLO.DOC        send in 1k blocks
XMODEM L CAT.LBR CAT.COM   send a file from a library
XMODEM LK CAT.LBR CAT.COM  send in 1k blocks
   The ".LBR" file extension may be omitted

XMODEM R HELLO.DOC         receive a file from you
XMODEM RP HELLO.DOC        receive in a private area
   Add "C" for forced checksum ("RC" "RPC")
   Add "X" for forced 128 byte protocol ("RX" "RPX")
   "R" switches from CRC to checksum after 5 retries

XMODEM A                   shows areas/space for uploads

S. R. schrieb:
> So eine richtige Funktion wie AUTOEXEC.BAT gibt es in CP/M nicht.
> Ich hab das bei mir im BIOS gelöst (nach einem Warmstart schreibt das

Kurze Zwischenfrage: Was gibt eine 3.5z Floppy bei Dir von sich, wenn du 
sie nur an 5V anschließt. Die 12V leitung ist gar nicht intern 
angeschlossen. Gehen auch 0ma raus. Ich habe noch kein Datenkabel. Bei 
mir tuckert der Motor ein paar Mal und dann geht alles aus. Es leuchtet 
nichts, dreht sich nichts. Ich weiss nicht sicher, ob sie kaputt ist. 
Ist aus der Elektroschrott Kiste meiner Firma. Nicht gerade die beste 
Quelle.

Christian J. schrieb:

> Kurze Zwischenfrage: Was gibt eine 3.5z Floppy bei Dir von sich, wenn du
> sie nur an 5V anschließt.

Nichts. Bestenfalls dreht der Motor beim Einlegen der Diskette für zwei 
Umdrehungen, um die Spindel zu zentrieren. Ansonsten passiert nichts, 
solange /DS high ist.

Um eine Floppy anzusprechen gibt es vier Drive Select-Signale, /DS0 bis 
/DS3. IBM PCs benutzen immer /DS1, daher sind spätere Laufwerke oft fest 
auf diese ID eingestellt. Ein echter CP/M-Rechner erwartet aber das 
erste Laufwerk an /DS0, das zweite an /DS1 etc. Wenn /DSx aktiv ist, 
sollte die Lampe vorne angehen.

Der Motor dreht wenn zusätzlich das Motor On-Signal /MO low ist. Dann 
kommen auch Pulse aus der Read Data (/RD) - Leitung. Den Kopf bewegt man 
über Low-Pulse auf /Step, der Pegel an DIR gibt die Richtung vor. 
Floppylaufwerke sind nur selten so dermassen kaputt, dass das nicht mehr 
funktioniert. Wenn sich die Köpfe nicht verfahren lassen und der Motor 
nicht dreht liegt ein Anschlußfehler vor.

Am Shugart-Bus gibt es drei Pins, deren Belegung nicht eindeutig ist. 
Durch den IBM PC hat sich ein Standard durchgesetzt, der passt aber 
nicht unbedingt zu dem was in den '80ern üblich war. Hier hilft der 
Blick ins Handbuch des Laufwerkes und in den Schaltplan des Controllers, 
um die Jumper für Ready, DiskChanged, Density, HeadLoad etc richtig zu 
setzen.

Martin H. schrieb:
>> - 8"-Laufwerke brauchen zusätzlich Netzspannung.
>
> ...für den Motor (für die Rotation)
>
> und 24 VDC für Stepper (zur Positionierung) und den Head-Load.

Die standen ganz am Anfang der Entwicklung und waren daher viel 
unterschiedlicher als spätere Floppy-Formen. Ich hatte sogar welche von 
BASF, da musste noch ein extra Daten-Demodulator für die rohen FM-Daten 
vorgesehen werden.

Abgesehen vom gewaltigen Gewicht - wir hatten Steuerungen mit 2 
Laufwerken, da brauchte man für den Einbau mindestens 2 starke Männer. 
Aber sie waren ausserordentlich zuverlässig, ausser wenn Mitarbeiter auf 
die Idee kamen, die Datenfloppies mit Magneten an eine Blechwand zu 
pinnen neben die Arbeitspapiere.

Georg

soul e. schrieb:
> Nichts. Bestenfalls dreht der Motor beim Einlegen der Diskette für zwei
> Umdrehungen, um die Spindel zu zentrieren. Ansonsten passiert nichts,
> solange /DS high ist.

Ok, also warten bis das Datenkabel kommt. Hier verlasse ich mich einfach 
nur drauf, dass das funktioniert. Ohne Floppy kriegt man ja nichts 
eingespielt auf die Kiste. Mühsam aber mit viel Lesen wird auch cp/m 
verständlicher und klarer:

Wenn ich auf user 1 umschalte, wie erreicht user 1 dann noch die 
Programme, die auf User 0 abgelegt sind und zum System gehlören? Sowas 
wie einen Suchpfad gibt es wohl nicht, also PATH=.....