KC-News 4/1996

Top-Themen:

• Einbau 3,5"-Laufwerk
• Tastatur K 7672 am KC
• universelle Druckertreiber für Nadeldrucker
• Konzept neue Speicherverwaltung
• Online-Calculator
• neues Betriebssystem ZSDOS
• Z-System

Ein paar Worte zur Einleitung

von Jörg Linder

Tja, was soll ich schreiben? Während draußen die Temperaturen wieder auf Werte unter Null sinken, sind in der guten KC-Stube noch die Auswirkungen des Sommerlochs zu spüren. Mein Aufruf wegen des GIDE-Interfaces hat sage und schreibe 4 Interessenten dazu bewogen, sich bei mir zu melden. Das war eine herbe Enttäuschung für mich. Besonders, wenn ich mich an das '95er Treffen erinnere, wo sich zahlreiche User meldeten. So wird es ab sofort "nur" noch den Bausatz geben.

Zum Glück sieht es auf der Softwareseite nicht ganz so traurig aus. Mario Leubner hat (mal wieder) eine beachtliche Menge Updates geliefert, die vorrangig das neue System betreffen. Übrigens ist das Interesse daran auch recht verhalten. Ein bißchen mehr hätte ich schon erwartet.

Doch nicht nur von Mario kamen Updates. Ralf Kästner beschert uns diesmal ein paar Exemplare dieser Spezies. In seinem Artikel verheißt er uns auch die Version 2.0 von UNIPIC - das läßt doch hoffen! Ansonsten will ich hier nicht mehr über den Inhalt dieser Ausgabe verraten, schließlich könnt Ihr doch selbst lesen!

Treffen 1997

Doch ich will nicht länger klagen, sondern zuversichtlich in die Zukunft schauen. Konkreter gesagt auf das Wochenende vom 18.04. bis 20.04.1997. Dann findet nämlich unser drittes Treffen statt. Wie sich schon vor einiger Zeit abzeichnete, ist Treffpunkt wieder Gusow. Das Anmeldeformular liegt dieser Ausgabe bei. Bitte beachtet unbedingt den "Einsendeschluß"! Eine Anfahrtsbeschreibung wird dann in den nächsten KC-News zu finden sein. (Für alle, die neu hinzugekommen sind: Finger auf die Landkarte, Berlin suchen, nach Osten, Frankfurt (Oder) suchen, nach Norden, Seelow suchen, ein wenig nach Norden, Gusow finden.)

Führungswechsel

Nein, nein, keine Bange, wir fangen mangels anderer Beiträge keinen Tanzkurs an! Es geht vielmehr um jenen kleinen Kreis von Clubmitgliedern, der sich Leitung nennt. Jens Neumann, unser Diskothekar, wird zum Jahresende nicht mehr in unserem Club sein und demzufolge auch seine Funktion nicht mehr ausüben (können). Er schreibt dazu: "...durch die Zwänge des Arbeitslebens eine 'MS-DOSE' zulegen. Leider habe ich dann in meiner Wohnung keinen Platz mehr, den KC zu stellen. Aber ganz ehrlich, mir werden die 8 Bit fehlen." Du wirst uns auch fehlen; wir danken für Deine geleistete Arbeit, Jens.

Doch nicht genug der Hiobsbotschaften. Als ich vor nunmehr zwei Jahren die "Geschäftsführung" des Clubs an mich gerissen habe, um ihn wiederzubeleben, ahnte ich nicht, was alles auf mich zukommt. Neben der gestiegenen beruflichen Belastung bleibt kaum noch Freizeit. Bevor den Club ein ähnliches Schicksal wie im Sommer/Herbst 1993 ereilt, möchte ich mein Amt (und die damit verbundenen Aufgaben) weiterreichen.

Dazu benötigen wir aber mindestens einen Freiwilligen, der nicht nur übermütig genug ist, sondern auch die notwendigen (technischen) Voraussetzungen hat. An dieser Stelle also wieder einer meiner berühmt-berüchtigten Aufrufe: Wer die Redaktion des KC-Clubs übernehmen möchte, soll sich bei mir melden!

Das Treffen und die nächste Ausgabe der KC-News sind aber in keinster Weise durch diesen Wechsel gefährdet.

Tonnenweise Software

Von Frank Pischel habe ich kürzlich seine gesammelten Werke rund um unseren KC bekommen. Auf dem von ihm zugesandten Streamerband befanden sich mehr als 30 MB (!) Software, die ich nun auf einer CD-ROM habe. Diese Übermenge Bits und Bytes muß kopiert, gesichtet, sortiert und katalogisiert werden. Eine wunderschöne Aufgabe für die (hoffentlich) langen Winterabende. Wenn Ihr nichts dagegen habt, könnte ich vielleicht in Zukunft Diskothekar sein!?

Es werde Sound...

Kurz vor Redaktionsschluß benachrichtigte mich Enrico Grämer über seine ersten Erfolge in Sachen Sound-Modul. Er konnte dem AD-Wandler bereits erste Töne entlocken. Im Prinzip funktioniere es schon, sagte er, allerdings wird es bis zum fertigen Modul noch ein ganzes Stück Arbeit sein. Er hofft, uns im April schon Ergebnisse präsentieren zu können.

Das alles können wir aber in Ruhe (?) auf unserem nächsten Treffen besprechen. Vorher gibt's auf alle Fälle nochmal die KC-News. Bis dahin wünsche ich Euch mit dieser Ausgabe VIEL VERGNÜGEN

Euer Redakteur

Neues Spiel, neues Glück!

von Ruthart Riehl

Vom aktivsten Nicht-Mitglied, Herrn Riehl aus Leipzig, bekam ich wieder etliche BASIC-Anwendungen. Schwerpunkt ist natürlich auch diesmal ein Spiel. Zu den von ihm übersandten Dateien (auf der Beilagen-Diskette in BASPRG03.PMA) schreibt er:

Auf dem 386er habe ich AQUANOID. Weil es von der Grafik her einfach ist und sich gut spielen läßt, kam ich auf die Idee, es für den KC umzuschreiben. Für die Maus muß beim KC die Tastatur herhalten. Das Spiel nennt sich BREAK.

Mit einer Kugel, die mit einem Schläger im Spiel zu führen ist, sind Blöcke abzutragen, die bei Berührung mit der Kugel gelöscht werden. Jede Farbe hat einen bestimmten Wert, der unter BONUS angezeigt wird. Fällt die Kugel ins Leere, verliert der Spieler ein Leben.

Ab und zu fallen aus gelöschten Blöcken Symbole, die der Spieler mit dem Schläger auffangen kann, aber nicht muß. BREAK, die gelbe Kugel, wird von den Blöcken nicht reflektiert! Die Schutzlinie reflektiert die Kugel auch. Das kostet aber 100 BONUS-Punkte! Ein übernommenes Symbol löscht die Schutzlinie wieder. Eins kann man nur haben!

Ist ein Bild beendet, wird das nächste angezeigt. Die Bilder 7 bis 9 sind von mir. Die anderen habe ich übernommen. Mit dem gelben Kreuz wird das gleiche Bild wiederholt, mit dem roten beendet und das nächste Bild angezeigt.

Die Tasten CUL/CUR sind für STEP 1 ausgelegt und CUU/CUD für STEP 2. Am Spielende kommt dann die Auswertung, in der angegeben wird, wieviele Bilder, Blöcke und Punkte der Spieler erreicht hat. Im ersten Spiel hatte ich 10 (12) Bilder, 758 Blöcke und 29690 Punkte.

Ich hoffe, BREAK-1 ist mit seinen 693 Zeilen / 22 kB eine kleine Bereicherung nicht nur für die Kassetten-User (170 Sekunden Ladezeit!)

Wenn nur noch einige Blöcke im Bild sind, kann das etwas langatmig werden. Die Kugel bewegt sich nunmal im KC-Tempo! Doch die zweite Variante namens BREAK-2 hat eine kleinere Spielfläche von 16 * 16. Somit ist die Zeit bis zum Bildende nicht mehr so groß, die jetzt bei etwa 10 Minuten liegt.

Von Herrn Helmut Teitzel kam ein Programm in BASIC, mit dem sich Bytes nach Angaben vergrößern lassen. Da er PTEST(X) nutzte, dauerte es recht lange - Minutenbereich. So habe ich VRGROES, das mit GRZEI läuft, geschrieben. Da geht's Ruck-Zuck!!!

Von ihm kam außerdem ein Tip zu PIXZEI. Dort sind nur quadratische Bildausschnitte möglich. Zumindest bisher. Er hat den Fehler gefunden. Es waren nur zwei Schleifen auszutauschen. Jetzt ist auch ein rechteckiger Bildausschnitt möglich! Geändert habe ich noch die Ausgaben bei Fehleingaben. PIX-KEY ist auch neu. Da die Änderung geringfügig ist, habe ich V 1.0 beibehalten.

Die anderen Programme sind zum Testen und für die eigene Anwendung gedacht: SOUNDT-1..3 und ZAHLSOR1..3.

ESCAPE-Steuerfolgen (2)

von Mario Leubner

Aus aktuellem Anlaß möchte ich an dieser Stelle den Beitrag von Uwe Felgentreu fortsetzen. Mit dem neuen SYSGEN ist es ja leicht möglich, ZAS direkt in die Systemspuren zu integrieren. Darum soll auch jeder wissen, welche Möglichkeiten sich dadurch ergeben. Ich möchte jedoch für alle, die ZAS noch nicht kennen, kurz ein paar Grundlagen erläutern bevor ich zu den ESC-Sequenzen komme.

Mit JUMP FC werden zunächst 3 Standardtreiber im Grundgerät erzeugt. Diese stammen aus dem EPROM im D004 und enthalten:

• einen einfachen V.24-Druckertreiber mit 1200 Baud (Kanal 1)
• einen einfachen Koppeltreiber mit 1200 Baud (Kanal 2)
• einen Terminaltreiber für die Standardfunktionen

Wer andere Treiber benötigt, kann mit MSYSG.COM seine eigenen in den Systemspuren installieren. Die installierten Treiber überschreiben dann beim Booten die Standardtreiber. Eine Möglichkeit zum Ersetzen des Terminaltreibers gab es jedoch nicht. Deshalb entstand ZAS, zunächst als COM-Datei und später als ZAS-Treiberdatei.

Beide Varianten sind identisch, nur daß die COM-Datei den Programmteil zum Laden des Treibers mit enthält, während für *.ZAS eine spezielle Laderoutine eines anderen Programmes genutzt wird. Es gibt also zunächst 3 Varianten, ZAS zu laden.

1. Start der Datei ZAS.COM:
   Das dürfte den meisten schon bekannt sein und ist die einfachste Art ZAS zu laden. Der Ladevorgang wird am Bildschirm angezeigt.
   
   
2. Laden der Datei *.ZAS mit dem Programm LADE.COM:
   Das Programm LADE.COM stellt einen universellen Lader für die KC-Treiber dar. Es können also Druckertreiber *.LST, Koppeltreiber *.KOP und Terminaltreiber *.ZAS geladen werden.
   
   
3. Installation in den Systemspuren des neuen Systems:
   Wer das ZSDOS-Paket besitzt und damit die Möglichkeiten des neuen Systems nutzen kann, hat jetzt noch die Möglichkeit ZAS mit in die Systemspuren zu schreiben. Das hat den Vorteil, daß ZAS nicht mehr als Datei von der Diskette (Festplatte) geladen werden muß und der Bootvorgang alle gewünschten Treiber automatisch lädt.

ZAS4 V1.1

ZAS wurde ja bereits in den KC-News 2/95 (Version 1.0) und KC-News 4/95 (Version 1.1) vorgestellt. Seit dieser Version gab es keine Änderungen mehr, es gibt jedoch bereits Vorstellungen über eine effektive Erweiterung zur Verwaltung des RAM4, wie in dieser Ausgabe nachzulesen ist.

ZAS läuft nur auf dem KC85/4 (bzw. KC85/5)! ZAS belegt im Grundgerät den Speicher von 400H bis 2000H. Beim Laden von ZAS wird außerdem der RAM4 benutzt, da das laufende ZAS nicht einfach überschrieben werden kann. Allgemein gilt im Grundgerät folgende Belegung:

0200H..037FH	Druckertreiber
0380H..03FFH	Koppeltreiber
0400H..1FFFH	Terminaltreiber
2000H..3AFFH	frei
3B00H..3CFFH	RAM-Floppy-Verwaltungstabelle (für max. 4 MByte)
3D00H..3FFFH	Bildschirmhilfstabelle für KC85/2,3
4000H..7FFFH	bei KC85/2,3 nicht vorhanden, bei KC85/4,5 frei.

Gegenüber dem Terminaltreiber aus dem EPROM FC wurden einige Fehler beseitigt und viele neue Funktionen eingebaut. Dabei sind viele Programmteile optimiert worden. Es ist davon auszugehen, daß kein Programmteil mehr auf der ursprünglichen Adresse läuft. Aber das ist ja eigentlich nicht von Bedeutung, wenn man sich an die definierten Schnittstellen hält.

Bildschirmsteuerzeichen und ESC-Sequenzen:

Die Steuerzeichen und ESC-Sequenzen sind aufwärtskompatibel. Alle im "Handbuch für den Programmierer" abgedruckten Funktionen sind also uneingeschränkt weiterverwendbar. Als Programmierer sollte man beachten, daß die neuen Funktionen nur mit ZAS und nur auf dem KC85/4 verfügbar sind. Wer also Programme schreiben will, die auch auf dem KC85/3 laufen sollen, muß sich mit den alten Funktionen begnügen - doch auch dabei sind noch Abstriche zu machen bei den Funktionen ESC-60H bis ESC-62H.

Als erstes folgt eine Tabelle aller zur Zeit gültigen Bildschirmsteuerzeichen. Die in der ersten Spalte mit einem + gekennzeichneten Funktionen sind nur mit ZAS verfügbar. Vergleiche dazu Anlage 2 im Handbuch für den Programmierer.

Neu	ASCII	Hex.	dez.	Wirkung der Kommandos
	^A	01H	1	Cursor in HOME-Position (links/oben)
+	^B	02H	2	Cursor einschalten
+	^C	03H	3	Cursor ausschalten
+	^D	04H	4	Normaldarstellung (invers aus)
+	^E	05H	5	Inversdarstellung ein
	^G	07H	7	BEEP (Signalton)
	^H	08H	8	Cursor eine Position nach links
+	^I	09H	9	Tabulatorschritt vorwärts
	^J	0AH	10	Cursor eine Zeile nach unten
+	^K	0BH	11	Zeichen löschen (Zeichen rechts rücken nach)
	^L	0CH	12	Bildschirm löschen und Cursor HOME
	^M	0DH	13	Cursor zum Zeilenanfang
+	^N	0EH	14	Zeichensatz 1 (deutsch)
+	^O	0FH	15	Zeichensatz 2 (amerikanisch)
+	^R	12H	18	Leerzeichen einfügen
	^T	14H	20	Löschen bis Bildschirmende
	^U	15H	21	Cursor um eine Position nach rechts
	^V	16H	22	Löschen bis Zeilenende
+	^W	17H	23	Leerzeile einfügen
	^X	18H	24	Zeile löschen
+	^Y	19H	25	Zeile löschen (Zeilen unterhalb rücken nach)
	^Z	1AH	26	Cursor um eine Zeile nach oben
	ESC	1BH	27	ESCape-Funktion bzw. Cursorpositionierung
+		1CH	28	Scroll-Modus einschalten
+		1DH	29	Page-Modus einschalten
	DEL	7FH	127	Zeichen links vom Cursor löschen
		82H	130	Cursor einschalten
		83H	131	Cursor ausschalten
+		84H	132	Normaldarstellung (invers aus)
+		85H	133	Inversdarstellung ein

Die Steuercodes 82H bis 85H sind nur im ASCII-Modus wirksam, im IBM-Modus werden hiermit Zeichen erzeugt! Im IBM-Modus sollten deshalb nur die Steuerzeichen 2-5 für diese Funktionen eingesetzt werden. Kommen wir nun aber zu den ESC-Funktionen, die dem KC unter CP/M die Verwendung von Grafik, Farbe und Tonausgabe ermöglichen. Vergleiche dazu Anlage 3 im Handbuch für den Programmierer.

	ASCII	Hex.	dez.	Bedeutung	Name	Anz.	Parameter
	A	41H	65	Punktsetzen	PSET	3	XX,Y
	B	42H	66	Punktlöschen	PRES	3	XX,Y
	C	43H	67	Grafikfarbe	GFARB	1	F
	D	44H	68	Linie	LINE	6	XX1,Y1,XX2,Y2
	E	45H	69	Kreis	CIRCL	4	XX,Y,R
	F	46H	70	Fensteraufruf	WINDOW	1	N
	G	47H	71	Tonausgabe	SOUND	6	T1,V1,T2,V2,L,Z
	H	48H	72	Textfarbe	COLORZ	2	F,H
+	I	49H	73	Tabulator rückwärts	BACKTAB	0	-
+	J	4AH	74	IBM-Zeichensatz	ZIBM	0	-
+	K	4BH	75	ASCII-Zeichensatz	ZASCII	0	-
	L	4CH	76	Fenster initial.	WININI	5	N,X1,Y1,X2,Y2
	M	4DH	77	Pixel löschen	CLSG	0	-
	N	4EH	78	Vordergrund wechseln	INK	1	F
	O	4FH	79	Hintergrund wechseln	BACK	1	H
	P	50H	80	Bildschirmmode 80/40	BSMODE	0	-
	Q	51H	81	1 Byte lesen	READ1	2	AA
	R	52H	82	256 Byte lesen	READN	3	AA,D
	S	53H	83	1 Byte schreiben	WRITE1	3	AA,B
	T	54H	84	nn Bytes schreiben	WRITEN	4+	AA,NN,(NN*B)
	U	55H	85	Unterprogrammaufruf	GOSUB	2	AA
	V	56H	86	CAOS-Zeichenausgabe	CAOSBS	1	B
	W	57H	87	Ausgabe USERPORT 2	USOUT2	1	B
	X	58H	88	Ausgabe USERPORT 3	USOUT3	1	B
+	Y	59H	89	256 Byte lesen	RD256	2	AA
+	Z	5AH	90	256 Byte schreiben	WR256	2	AA
	Ä	5BH	91	CAOS-Sprungverteiler	CAOSP	1	N
	Ö	5CH	92	Rückkehr zu CAOS	EXIT	0	-
	Ü	5DH	93	Wechsel USA/deutsch	ZSATZ	0	-
	^	5EH	94	PAGE/SCROLL-Mode	SCRMOD	0	-
	_	5FH	95	KEYBOARD klein/groß	KBDMOD	0	-
	`	60H	96	Wechsel IRM-Ebene	IRMEB	1	S
	a	61H	97	IRM-Auflösung normal	IRMLO	0	-
	b	62H	98	IRM-Auflösung hoch	IRMHI	0	-
	c	63H	99	Module schalten	SWITCH	2	M,S
	d	64H	100	Punkttesten	PTEST	2	XX
	e	65H	101	F-Taste belegen	FKEY	1	N
+	f	66H	102	Farbmodus ein/aus	FARB80	1	S
+	g	67H	103	Fenster definieren	WIN80	6	X1,Y1,X2,Y2,F,H
+	h	68H	104	Fenster löschen	WCLS	0	-
+	i	69H	105	Schatten um Fenster	SHADOW	2	F,H
+	j	6AH	106	Rahmen in Fenster	FRAHM	1	F,N
+	k	6BH	107	Rahmen zeichnen	RAHM	7	XX1,Y1,XX2,Y2,N
		80H	128	Locate Zeile, Spalte
		..D0H	..208

Bedeutung der Parameter:

1 Zeichen	= 1 Byte
Doppelzeichen	= 2 Byte (Wort, low/high)
AA - Adresse	M - Moduladresse	V - Vorteiler
B - Byte	N - Nummer	XX - X-Koordinate
D - Dummy	NN - Anzahl	Y - Y-Koordinate
F - Farbcode	R - Radius	Z - Tondauer
H - Hindergrund	S - Steuerbyte
L - Lautstärke	T - Tonhöhe

Auch hier habe ich den neuen Funktionen wieder ein "+" vorangestellt. Neue Funktionen ohne Parameter können auch ohne ZAS4 aufgerufen werden, d. h. sie richten keinen Schaden an - es erfolgt aber auch keine Reaktion! So kann man z. B. durch Ausgabe von ESC-J testen, ob ein ZAS mit IBM-Steuerzeichen aktiv ist. Der IBM-Zeichensatz wird ja in Bit 4 von BSSTAT zurückgemeldet.

Auf eine ausführliche Beschreibung der neuen ESC-Sequenzen möchte ich an dieser Stelle verzichten. In der Datei ZASINFO.DOK ist alles nachzulesen und kann bei Bedarf auch ausgedruckt werden. Eine Kurzübersicht gibt auch das Demoprogramm ZASDEMO.COM.

Hinweise zum Einbau des 3,5"-Laufwerks

von Lothar Stephan

Hurra! Das Floppylaufwerk ist nach Marios Beschreibung in KC-News 2/95 installiert und nach längerer Fehlersuche läuft es nun auch. Bei Beachtung dieser Hinweise sollte es möglich sein, daß auch ein Nichtelektroniker sein Laufwerk einbauen und in Betrieb nehmen kann.

Das LW paßt neben das 5,25"-LW. Es sind lediglich von der senkrechten Stabilisierungsstrebe an der Vorderfront ca 2 mm wegzufeilen. Vorher ist natürlich die Aussparung für das 3.5"-LW einzuarbeiten und das 5.25"-LW auszubauen.

Reichelt-Elektonik, Elektronikring 1, 26452 Sande, bietet unter

AK 3192	Stromvers.kabel für 3,5/5,25"	1,45 DM
AK 750	Comp-Datenkabel "	3,95 DM
AWG 28-26G	Flachbandkabel 26 pol. "	2,15 DM/m

an. Der Mindestbestellwert beträgt 10 DM.

Eigentlich braucht man das Datenkabel nicht. Es muß sowieso demontiert werden. Der Kartenstecker vom 5,25"-LW und der Busverbinder vom FDD-XFD kann verwendet werden. Eine 34-pol. Pfostenbuchse bekommt man in einem Elektronikladen. Ebenso ca. 60 cm 26-pol. Flachbandkabel (Buskabel).

Zur notwendigen Veränderung an der Leiterplatte "FD-Interface IN/OUT" ist diese aus dem FDD auszubauen. Der Artikel in KC-News 3/92, S. 8-13 ist dabei hilfreich. In den 26-pol. Busverbinder und den 34-pol. Kartenstecker wird das neue Buskabel im Schraubstock eingepresst.

Hier gibt es keine Veränderung. Der Kartenstecker sitzt in der Mitte des neuen, längeren, Buskabels. (Mein Kartenstecker war numeriert). PIN 1-7 und 33 bleiben frei. Hierzu wird das Buskabel in der Mitte zwischen Ader 32 und 34 auf ca 6 cm aufgetrennt. Die farbige Ader liegt in PIN 34. Im 26-pol. Busverbinder liegt die farbige Ader in PIN A1.

Achtung!
Bei der Konfektionierung der Pfostenbuchse kann der entscheidende Fehler passieren. Die Pfostenbuchse besitzt normalerweise 2 Kerben an den Seiten und eine Erhebung in der Mitte. Auf dieser Seite befinden sich die geradzahligen PIN's. PIN 1-7, 33 und 34 bleiben frei. Die farbige Ader 34 wird nicht eingepresst.

Belegt sind im 3,5"-LW also PIN 8-32. Das Buskabel wird vor dem Pfostenstecker zwischen Ader 13/14 und 16/17 auf einer Länge von ca. 6 cm aufgetrennt. Diese 3 Adern werden und um 180° gedreht. Nun werden die 25 Adern in die Pfostenbuchse eingepreßt.

Die Pfostenbuche ist nicht numeriert. Bei manchen Pfostensteckern am LW wurde auch noch der Plastrand eingespart, sodaß auch die Markierungen der Pfostenbuchse nicht weiterhelfen. Also muß auf der Leiterplatte des LW's nach einer Numerierung gesucht werden. Auf manchen LW'en ist 1 bis 34 aufgedruckt, auf manchen auch nur 1.

Auf meinen beiden 3,5"-LW liegt PIN 34, von vorn gesehen, auf der linken Seite. Die Pfostenbuchsenkerben und -Erhebungen zeigen nach oben. Achtung! LW nicht verkehrt herum in Betrieb nehmen. Drehteller soll nach unten zeigen.

Beim 5,25"-LW liegt die farbige Ader (PIN 34) von vorn gesehen auf der rechten Seite. Die kleine Platine mit dem D003/SN74LS03 wurde, wie beschrieben, an B11/B10 und A1 des IXD angeschlossen. Der Pull-UP-Widerstand vom Ausgang des D003 befindet sich im FDD. Die Stromversorgung erfolgt entweder vom Netzteil oder man zieht aus den großen Stecker des Stromvers.kabels den roten (5 V) und den schwarzen Kontakt (Masse) aus dem Plastgehäuse und lötet dort 2 ca 25 cm lange isolierte Drähte an.

Damit die Kontakte aus dem Gehäuse gezogen werden können, sind die beiden Hemmungen an den Kontakten mit einer dünnen Pinzette, von vorn gesehen, zusammenzudrücken. Anschließend wieder etwas auseinander drücken. Nun können die Kabel gesteckt werden.

Nachdem der Jumper des 3,5"-LW auf DS1 eingestellt ist (manche LW besitzen an der Seite einen Schiebeschalter 0123, manche Lötkontakte; die verschiedenen Stellungen sind auf dem Gehäuseblech eingeprägt), kann das LW mit MSYSG 1J8H2382N45 als LW H: eingetragen werden. Dabei muß das LW neben dem LW B: sitzen! (1. Etage). Soll LW H: neben dem LW E: betrieben werden, ist mit MSYSG 1J8H3382N45 einzutragen (2.Etage).

Da das 3,5"-LW nur DD-Disketten verarbeiten kann, ist bei Verwendung von HD-Disketten das 1,44 MB-Loch zuzukleben. Ansonsten gibt es nur BDOS-Fehler-Meldungen auf H:. DD-Disketten dürfte es kaum noch zu kaufen geben.

Sollten trotzdem an beiden LW'en die Leuchten aufleuchten, so ist das Buskabel verkehrt herum eingesteckt. Durch die Verpolung geht nichts kaputt!

Wenn schon mal das FDD offen ist, sollte man gleich die ca 10 cm langen Schienen (D etwa 3,5 mm) des Schreib- und Lesekopfes mit 1-2 Tropfen Öl versehen. Nachdem ich das gemacht hatte, höre ich das LW kaum noch. Vorher ratterte es doch manchmal recht laut.

Nun wünsche ich viel Erfolg bei der Installation! Ein LW bekommt man bereits für knappe 50 DM. Bei einem Elektronikschrotthändler bereits für 10 DM!

Noch ein Hinweis: Im PC liegt die farbige Ader der Buskabel fast ausschließlich in PIN 1. Wer sich mit dem Einbau der Festplatte beschäftigt, kann auch gleichzeitig bei Reichelt-Elektronik (Katalogpreise 6/96)

AK 671	AT-Bus-K. 40-pol.	3,35 DM
AK 319	Stromvers.kabel f. FP + 5"-LW	1.35 DM

mitbestellen.

Tastatur K7672 am KC - DIE Lösung?

von Kai-Uwe Irrgang

Auf der Suche nach einer besseren Tastatur für den KC sind wir ja schon lange Zeit. Neben dem D005 sind auch gute Eigenbaulösungen entstanden, denkt man z. B. an die P8000 von Hendrik Wagenknecht. Mir kamen vor einiger Zeit eine K7672.06 und eine K7672.03 zwischen die Finger, so daß ich auf dieser Basis meine Tastatur aufgebaute.

Ein großer Vorteil der K7672 ist, daß man an der Hardware, je nach Ausbaustufe, nichts bzw. fast nichts ändern muß. Außerdem sind reichlich Tasten vorhanden. Zur Anzeige von Statusinformationen sind 6 LED's und zur Ausgabe eines internen Click ein Signalgeber eingebaut.

Eine Arbeit, die ich mir wegen der deutlichen Gebrauchsspuren "angetan" habe, war das einzelne Abschleifen jeder Taste mit feinem Sandpapier und die Beschriftung mit Abreibebuchstaben. Für das Auge hat sich diese Mühe auf jeden Fall gelohnt, zumal man dann seine individuelle Belegung auch richtig gekennzeichnet hat.

Um möglichst kompatibel zu bleiben, habe ich mir von Mario Leubner die D005-Quellen und von Frank Rydz die U806-Datenblätter geben lassen, wobei sich herausstellte, daß beide ebenfalls an einer K7672 "stricken". Dies läßt die Vermutung zu, daß mehrere solcher Tastaturen im Umlauf bzw. beschaffbar sind und sich eventuell eine Standardlösung schaffen läßt.

In Zusammenarbeit mit Mario habe ich dahingehend schon etwas "vorgearbeitet", so daß ich heute meine Variante präsentieren und zur Diskussion stellen möchte. Angesichts des Z8-Mikrocontrollers und der 4 kByte Speicher wären so viele "Raffinessen" programmierbar, daß am Ende keiner mehr durchsieht. Ziel muß es also sein, eine komfortable und vor allem kompatible Tastatur zu schaffen, die genau die Funktionen enthält, die wirklich benötigt werden. Doch nun zu den Besonderheiten meiner Version:

• der tastaturinterne Signalgeber wurde "stillgelegt", da dieses Signal für die Keybord-Ausgabe benutzt wird
  
  
• Umschalttaste für Senden über SIO ODER Keyboard-Buchse, der Zustand wird mittels einer LED angezeigt, d. h. momentan kann einfach während der Arbeit die Betriebsart gewechselt werden. Dazu muß die Tastatur natürlich gleichzeitig an beide Buchsen angesteckt sein.
  
  An dieser Stelle tritt sicher die Frage nach dem Sinn auf. Ich habe es eigentlich nur für die Erprobungsphase vorgesehen, denn erstens sollten beide Betriebsarten getestet werden und zweitens habe ich mein M003 noch nicht so umgebaut, daß es TTL-Signale führt und auch einen +5V-Anschluß hat. In einer endgültigen Lösung wird man sich wahrscheinlich auf eine Variante festlegen, wobei dann auch der tastaturinterne Click wieder möglich wäre. Jede Betriebsart hat eine eigene Umcodierungstabelle, so daß Variationen in der Tastenbelegung zwischen beiden Betriebsarten möglich sind.
  
  
• Mittels eines über eine Taste schaltbaren Repeat, der nur in der SIO-Ausgabe sinnvoll und aktivierbar ist, kann die Wartezeit vor dem Einsetzen des Repeat unterbunden werden. Auch dies wird mittels LED gekennzeichnet. In der Keyboard-Variante übernimmt der KC selbst die Überwachung des Repeat.
  
  An dieser Stelle möchte ich anmerken, daß die Übertragungsgeschwindigkeit der SIO um ein Vielfaches höher ist. Um diesen Mangel der Keyboard-Variante etwas zu kompensieren, ist hier ein Puffer eingebaut, dessen Länge vorgewählt werden kann. In der Testphase hat sich herausgestellt, daß er aber nicht länger als drei Byte sein sollte, da dies einerseits ausreicht, um bei schnellem Schreiben wirklich keine Taste zu "verschlucken", so wie es bei der Orginaltastatur oft der Fall ist, andererseits ist bei einem langen Puffer der etwas eigenartige Effekt zu beobachten, daß die Zeichen auf den Bildschirm nachlaufen, wenn extrem schnelle Tastenbetätigung (die bei normalen Schreiben keiner erreicht) erfolgte.
  
  
• Umschalttaste für CP/M - CAOS - Umschaltung der Tasten-Belegungstabellen, wobei möglichst nahe an der Orginaltastatur orientiert wurde.
  
  Die CAOS-Betriebsart unterscheidet vier Belegungen:
  Erstbelegung, nur Shift, nur Lock, Shift UND Lock.
  
  Der CP/M-Modus unterscheidet drei Belegungen:
  Erstbelegung (auch bei Shift UND Lock), Zweitbelegung (Shift XOR Lock) und Drittbelegung (Ctrl), Zustandsanzeige über LED.
  
  In den EPROM's ist noch Platz, so daß weitere Ebenen, z.B. Shift+Ctrl+Taste, programmierbar wären. Allerdings ist mir dafür keine sinnvolle Nutzung eingefallen.
  
  
• HEX-Modus, der sich nur im SIO-Modus aktivieren läßt und das Senden jeder Codierung erlaubt. Der aktive HEX-Modus wird über eine LED angezeigt. Ein dezimaler Eingabemodus wäre ebenfalls denkbar, aber umständlicher zu programmieren.
  
  
• Im CP/M-Modus wird bei eingeschaltenem Keyboard-Modus ein Zeichen mit Control-Taste mit der Folge F1-Zeichen gesendet.
  
  
• Die Shift-Lock-Taste wird tastaturintern behandelt. Ein Senden von 'CAPS' an den KC erfolgt auch im Keyboard-Modus nicht. Zustandsanzeige über LED. Um im Keyboard-Modus an die nur über CAPS erreichbaren Zeichen, wie z.B.: 'ß' zu gelangen, ist eine intelligente Senderoutine vorhanden, die in Abhängigkeit des zu sendenden Zeichen 'CAPS' vorausschickt und 'CAPS' erst genau dann nachschickt, wenn das vorhergehende Zeichen mit 'CAPS' war, das aktuelle aber ohne. Somit ist ein normal schneller Repeat auch dieser Zeichen gewährleistet. Der im KC vorhandene 'CAPS'-Zustand wird über LED gekennzeichnet.

ACHTUNG!
Das ist zwar die momentane Variante, aber Mario hatte angeregt, dies so nicht zu programmieren, da es Programme gibt, die das CAPS-Bit im KC unabhängig von der Tastatur schalten.

• Der Ziffernblock wurde zum HEX-Eingabe-Block erweitert bzw. umfunktioniert, da ich bei der täglichen PC-Praxis zu der Erkenntnis gelangt bin, daß man den externen Ziffernblock, wenn überhaupt, nur zur Eingabe von Ziffern benutzt. Die zweite Belegung mit den Sondertasten benutzt wohl kaum jemand. Andererseits fehlt aber gerade in der Assembler-Programmierung eine komfortable HEX-Eingabe, so daß ich diese Tastenbelegung gewählt habe.
  
  
• Beim Einschalten der Tastatur wird nach einer Wartezeit im SIO-Modus das Zeichen ENTER gesendet, um die Tastatur anzumelden. Wird eine CAOS-Version unter 4.3 verwendet, so muß in der SIO-Ausgabe jedem Zeichen eine Null nachgeschickt werden. Ab 4.3 ist dies nicht mehr nötig, dafür werden aber 15 F-Tasten unterstützt.

An dieser Stelle muß die Belegung der Tastatur noch einmal überdacht werden, da 12 F-Tasten vorhanden sind, die bis 4.3 gereicht hätten. Andererseits könnte man, wenn sowieso eine doppelte Belegung notwendig ist, gleich nur acht Tasten (F1 und F2/F9 bis F8/F15) vorsehen und die dann freien vier Tasten (ehemals F9 bis F12) anderweitig verwenden, z.B. zum Schalten des internen Click.

Soviel an dieser Stelle von mir. Jetzt seid Ihr an der Reihe, weitere Vorschläge zu unterbreiten bzw. Euch darüber zu äußern, welche der vorgestellten Funktionen gewünscht werden und welche vielleicht überflüssig sind. Besonders würde mich interessieren, ob Ihr die SIO- oder die Keyboard-Variante bevorzugt, oder ob es doch per zwei Leitungen umschaltbar bleiben soll, denn alles Gute ist nie beisammen.

Die Vorteile der SIO sind die erheblich schnellere Übertragung und die 256 statt nur 128 Sendeworte. Desweiteren ist der HEX-Modus verfügbar und der Repeat wahlweise abschaltbar. Auch die Repeat-Geschwindigkeit könnte veränderlich gestaltet werden. Nachteile: ein (-er der "knappen") Vollduplexkana(e)l(e) ist permanent blockiert, zudem muß das betreffende M003-Modul umgebaut werden und nicht jede Software unterstützt eine externe Tastatur.

Die Vorteile der Keyboard-Variante liegen ganz einfach darin, daß es die Nachteile der SIO nicht hat und sich aus KC-Sicht wie eine Orginaltastatur verhält. Die Nachteile sind die vergleichsweise geringe Geschwindigkeit und die Notwendigkeit, mit den Sendefolgen etwas zu tricksen. Der HEX-Modus fehlt ebenso wie die Möglichkeit der Einflußnahme auf den Repeat.

Für die Z8-kundigen habe ich die reichlich kommentierten Quelltexte kopiert. TO.ASM ist der für den oberen (0800H physisch aber 0000H logisch), also zu Einschaltzeitpunkt aktiven EPROM und TU.ASM der für den unteren (0000H physisch und logisch). Die Umcodierungstabellen sind zwar noch nicht bis ins Detail optimiert, aber für die Testphase völlig ausreichend.

Ich benutze einen OS/2 bzw. MSDOS-Assembler, so daß die Quellen vom CP/M-Z8-Assembler so nicht akzeptiert werden und etwas modifiziert werden müßten, falls sich jemand sein eigenes Programm schreiben möchte. An dieser Stelle wäre es aber sicher besser, seine Vorschläge einzubringen und so die "Endlösung" mit zu schaffen. Wenn diese gefunden ist, können die EPROM's (entweder 2*2716 oder 1*2732) bei Mario oder bei mir gebrannt werden.

Tastaturbelegung unter WordPro 6 leicht gemacht

von Peter Jung

Ich habe die Zeichensätze von WordPro 6 (von Mario Leubner) in eine andere übersichtliche Form gebracht. Man kann die Tastenbelegungen (KC-Tastaur) zum schnellen Aufsuchen von Grafiksymbolen bzw. von IBM-Sonderzeichen nutzen.

In der ersten Datei TASTEN_1.TXW habe ich alle Schriftzeichen und Symbole in Breitschrift gesetzt. In der zweiten Datei TASTEN_2.TXW sind sie in Normalschrift und versetzt zu einander aufgeführt. Dies ist jedoch mehr oder weniger Geschmackssache. Vielleicht sind sie für den einen oder anderen User von Interesse und er hängt sie in Sichtweite auf.

Revisionen "DIASHOW 1.1" / "UNIPIC 1.0" / 4PCX092.KCC

von Ralf Kästner

Dem allgemeinen Trend folgend gibt es heute einige überarbeitete Programme, die Änderungen sind nicht so gravierend, daß es mir eine neue Versionsnummer wert gewesen wäre. Vor allem für die Betreiber von Festplatten am KC soll damit die notwendige Stabilität beim Gebrauch der Programme gewahrt bleiben.

Das in den vorletzten News verbreitete "DIASHOW 1.1" hatte leider noch einige Fehler, die sich erst im Nachhinein herausgestellt haben, bitte nur noch die heutige Version verwenden! U. a. gab es die folgenden Änderungen:

• das Laden von PIP-Bildern ohne Farbebene erzeugt jetzt wirklich ein sw/wß Bild, auch wenn der Bildspeicher vorher anderweitig belegt war
  
  
• der Ausbau des RAM8 bis zu 2 MB (lt. News 4/95) wird jetzt korrekt erkannt (in der alten Version wurde immer nach 1 MB abgebrochen)
  
  
• die Directory-Behandlung speziell für die Festplatte unter CAOS hatte noch einen richtigen Fehler, das konnte nun getestet werden und funktioniert jetzt, auch wenn mehr als 256 gültige Einträge gefunden werden
  
  
• konform zum neuen DEP 3.0 werden die User-Bereiche jetzt in dezimaler Form angegeben, das läßt sich besser merken, vor allem wenn man mit der Festplatte arbeitet, dann erhält die Nutzung der User-Bereiche einen ganz neuen Stellenwert, früher habe ich das auch so gut wie nie benutzt

Zweitens befindet sich die Datei UNIPIC01.OVR auf der Diskette, dies ist das geänderte DISC-MENU für die Version 1.0! Vor allem nach einer hoffentlich erfolgreichen Inbetriebnahme einer Festplatte am KC sollten alle Nutzer von UNIPIC 1.0 das original gelieferte Overlay durch die heutige Datei ersetzen und das Programm neu installieren, folgende Änderungen wurden vorgenommen:

• korrekte STAT-Meldung mit DEP 3.0, auch bei Festplatten
  
  
• User-Bereiche in dezimal, so wie oben beschrieben
  
  
• Regenerierung der Markierung einer ausgewählten Datei, wenn man vor >ET< darauf stand
  
  
• wichtigste Sache: die DIRECTORY-Überwachung, das Programm gibt jetzt einen Fehlerton aus, wenn 128 oder mehr gültige Einträge gefunden wurden
  
  
• bedingt durch die damalige Orientierung auf eine CAOS-Diskette, werden nach wie vor maximal 128 Einträge verwaltet, findet das alte Programm aber mehr, stürzt es unweigerlich ab !!!, wer also mit Festplatte arbeitet - für den ist der Austausch ein Muß, 128 Bilder hat man schnell in einem User-Bereich

Drittens war noch eine kleine Änderung am PCX-Konverter notwendig. Dies betrifft vor allem die Nutzer von CAOS 4.3. Da dort der CAOS-Fehler der vorhergehenden Versionen, daß bei ESC 1 und 2 der Zugriff auf die Farbebene eines Hardwarebildes (Bit 1,(IX+1) wird immer auf 0 gesetzt, in meinem Systemhandbuch ist dort ein Fehler, wenn das Bit=0 ist, wird auf die Pixelebene, bei 1 auf die Farbebene zugegriffen) grundsätzlich abgeschaltet wird, beseitigt wurde, funktioniert unter dem neuen CAOS die >C<-Funktion und das Speichern von HIP/HIF-Bildern nicht mehr.

Das ist die Wunderwelt der Programmierung, man beseitigt einen Fehler und macht damit Programmen Schwierigkeiten, welche sich darauf verlassen! Jetzt läuft es aber mit und ohne Fehler korrekt. Außerdem wird bei allen eingelesenen Directoryzeichen Bit 7 zurückgesetzt (Dateiattribute), Mario L. schrieb mir, daß das die Ursache dafür ist, daß sich das Programm manchmal weigert, ein PCX-Bild zu konvertieren.

Für alle ungeduldigen User von "UNIPIC 1.0", die Arbeit an der Version 2.0 geht voran, allerdings hat sich in den vergangenen Monaten alles etwas verzögert. Der Einbau von CAOS 4.3, der Anschluß der Festplatte und die Einrichtung des neuen Systems hatten erst mal höhere Priorität. Um mit der Festplatte vernünftig arbeiten zu können, bin ich nun auch auf NZ-COM (siehe Artikel von J. Linder zum Z-System) um- bzw. aufgestiegen und kann das allen nur wärmstens empfehlen!

Man erhält damit unzählige Möglichkeiten und einen Komfort, welchen man nicht mal mit MS-DOS auf dem PC hat. Von den vielen neuen Programmen, welche dann auch auf unserem KC laufen, will ich gar nicht reden. Damit mußte ich mich ja auch erst mal auseinandersetzen, da sind dann ganz schnell ein paar Wochen ins Land gegangen.

Zum Zeitpunkt der Veröffentlichung dieser Zeilen, will ich aber so weit sein, daß der gesamte Editor fertig ist und vielleicht auch das TABLE MENÜ, dann sind noch größere Umstellungen im DISC- und PRINT-MENÜ geplant, welche bis zum Jahreswechsel abgeschlossen sein sollen. Das stellt dann in etwa die Beta-Version dar, bis zum Treffen will ich dann die notwendigen Tests und das Feintuning abgeschlossen haben, so daß dort neben einer Vorstellung auch die neue Version zu haben sein wird, größere Störfälle mal ausgeschlossen.

12 universelle Druckertreiber für Nadeldrucker

von Mario Leubner

Aus gegebenem Anlaß (ich hatte wieder mal Probleme mit meinem bisher verwendeten Druckertreiber) habe ich meine Treiber der CP/M-Betriebsart überarbeitet. Entstanden sind 7 Quelltexte bzw. REL-Files, die sich zu 12 Treibern kombinieren lassen.

Ausgangspunkt meiner Überlegungen war, daß die Hardcopyroutinen unabhängig vom verwendeten Druckermodul sind. So habe ich den Treiber zerlegt in einen Teil mit der Modulsteuerung und Zeichenausgabe und einen zweiten Teil, der nur die für den Drucker spezifische Hardcopyroutine enthält.

Für die drei Standard-Module M001, M003 und M021 sind Treiber vorhanden. Bei Eigenbauschnittstellen können die Programmteile entsprechend der vorhandenen Quelltexte angepaßt werden. Die externen Vereinbarungen (Marken mit zwei Doppelpunkten) sind zu übernehmen.

Als Hardcopyroutinen sind 4 verschiedene Treiber für EPSON-kompatible Matrixdrucker vorbereitet:

• LX400 ist für 9-Nadler
  
  
• LQ100 ist für 24-Nadler im Schnelldruck, 60 dpi
  
  
• LQ101 ist für 24-Nadler im Schöndruck, 180 dpi
  
  
• LQ102 ist für 24-Nadler im Grauwertdruck (nur für KC85/4!)

Um die Bestandteile zu einem Treiber zusammenzusetzen, sind die REL-Files durch folgendes Kommando zu verbinden:

LINK131 LQ101.LST=M021,LQ101 [L200]

Das Beispiel zeigt die Kombination für M021 und den 24-Nadler mit Schöndruck. Die Routinen können beliebig kombiniert werden, beim Linken ist die Reihenfolge einzuhalten. Wurden die Quelltexte *.MAC verändert, dann sind die REL-Files vorher neu zu erzeugen durch Aufruf eines Assemblers:

ASM LQ101=LQ101
ASM M021=M021

Hinweise zu den Hardcopyroutinen:

Alle Hardcopyroutinen lassen sich mit der STOP-Taste abbrechen. Eventuell muß man den Finger einige Zeit auf der Taste lassen, da die Abfrage nur am Ende einer Bildschirmzeile erfolgen kann. Außer LQ102 sind alle Treiber auf dem KC85/3 und /4 lauffähig. Für den Grauwertdruck mußte ich den IRM-Zugriff etwas vereinfachen um alle Programmteile in den Speicherbereich von 200H bis 37FH unterzubringen, deshalb ist dieser Treiber nur für den KC85/4 geeignet.

Der direkte IRM-Zugriff ist auch etwas schneller als der Zugriff über die CAOS-Funktion PADR. Eine Umstellung der anderen Treiber auf dieses Prinzip erhöht beim KC85/4 die Druckgeschwindigkeit.

Alle erforderlichen Dateien habe ich in der Bibliothek LST.LBR (als Archiv LST.PMA auf der Beilagen-Diskette) zusammengefaßt. Die enthaltenen Treiber *.LST sind mit M021 gelinkt.

AMIGA-Monitor am KC 85/3

von Wolfram Schütze

Wenn sich jemand, so wie ich, endlich für "Farbe im Bild" entschließt oder sich verbessern will: Es gibt z. Z. bei Quelle für den AMIGA 1200 einen guten Monitor, Typenbezeichnung M1438S. Der Preis von 599,00 DM kann allerdings abschreckend wirken. Wenn nicht, können die folgenden Hinweise nützlich sein:

Das mitgelieferte Handbuch ist typisch für Nicht-Elektroniker verfaßt. Man findet keinerlei verwertbare elektrische Daten. Es erscheint fast als Wunder, daß die Steckerbelegung (23-poliger Sub-D-Steckverbinder) angegeben ist. Daraus ersieht man, daß für horizontale (HSYN) und vertikale (VSYN) Synchronisation getrennte Anschlüsse vorhanden sind.

Kein Problem, dachte ich, denn in den KC-News 3/96 wurde von Enrico Grämer eine Lösung dafür beschrieben. Die angegebenen Anschlußpunkte waren allerdings beim /3 hardwaremäßig nicht zu finden. Man könnte sicherlich beim /3 analoge Punkte ausmachen. Zunächst konzentrierte sich aber meine Hoffnung auf die Signale ZI und BI, die an allen Modulsteckverbindern und dem Expansionssteckverbinder anliegen (Kontakt 25A bzw. 25B).

Sie sind im KC-Handbuch etwas mysteriös als "Zeileninhalt" bzw. "Bildinhalt" erklärt. Mit dem Oszilloskop ließen sich dort saubere Rechteckimpulse nachweisen. Das Anschließen an den Monitor brachte allerdings keinen Erfolg. Ein Synchronisationseffekt trat ein, aber mit völlig "zerrissenem" Bild. Probeweise verband ich daraufhin HSYN mit FBAS vom KC und ließ VSYN frei. Und siehe da: Synchronisation perfekt!

Der Betrieb des oben genannten Monitors am KC 85 erfordert also lediglich einen Adapter vom Steckverbinder TV-RGB des KC zum Kabelstecker des Monitors, bei dem R nach R, G nach G, B nach B und FBAS nach HSYN durchgeschaltet sind. Möglicherweise sind beide Betriebsarten vorgesehen, wobei eine "intelligente Elektronik" die Umschaltung vornimmt. Aber, wie gesagt, die Beschreibung verrät nichts.

Neue Speicherverwaltung - neuer Standard?

von Jörg Linder

Der ungenutzte Speicher im Grundgerät während der Arbeit unter MicroDOS bzw. CP/M hat schon so manchen Programmierer gereizt. Dabei gab es durchaus auch die eine oder andere Rangelei zwischen Programmteilen unterschiedlichen Ursprungs. Inzwischen hat sich zwar ZAS als Quasi-Standard behauptet und wird von vielen KC-Usern verwendet, aber grundsätzlich ist man nicht vor Komplikationen gefeit.

Eine für alle Programmierer / Programme einvernehmliche Lösung müßte also her. Dafür stehen mehrere Möglichkeiten zur Verfügung. So könnte z. B. der freie Speicherplatz durch die Anzahl der aktiven Programmierer geteilt werden. Als Ergebnis erhielte man die verfügbaren Bytes pro Kopf. Was daraus gemacht wird, wäre jedem selbst überlassen.

Etwas ernster hat Dirk Walther die Sache betrachtet und folgende Forderungen aufgestellt: Jeder Programmierer hat den Benutzer darüber zu informieren, welche(n) Speicherbereich(e) sein Programm verwendet. Über die Kommandozeile sollte die Basisadresse zu beeinflussen sein. Nach seinen Vorstellungen wären Programme / Treiber optimal, wenn sie frei verschiebbar (also relokatibel) wären.

Letzteres ist bei größeren Projekten kaum realisierbar. Wird das Programm bzw. der Treiber aber vom D004 in das Grundgerät "gepokt", so ließen sich erst beim Schreiben die Sprung- und Zeigeradressen eintragen. Erst zu diesem Zeitpunkt würde der Code also auf eine bestimmte (Basis)adresse gelinkt.

In der Entwicklungsphase des neuen Betriebssystems standen wir vor einem größeren Problem. Man konnte die drei Systembestandteile CCP, BDOS und BIOS nicht in einem Schritt linken, da die Basisadresse des Codes sich erst aus der Größe des gelinkten Codes ergab. Sowohl für Anwender als auch Linker eine schier unlösbare Aufgabe. Woher sollte man vorher wissen wie groß das Ganze wird? Welche Basisadresse könnte schätzungsweise die richtige sein?

Bei meiner (verschwindend geringen) Zuarbeit für Mario Leubner bin ich über ein besonderes Ausgabeformat des Linkers gestolpert. Hierbei werden zwar alle Segmente zusammengefügt, aber es steht noch keine feste Basisadresse fest. Es handelt sich also um eine Art "Zwischencode", der schon fast fertig ist. In diesem Zusammenhang sind mir wieder Dirk Walther's Ansätze eingefallen. Warum sollte man sich dieses Format nicht zunutze machen?

Das Zauberwort heißt "PRL". Diese Abkürzung steht für "Page ReLocatable" und ist gleichzeitig auch der Dateityp einer solchen Datei. Ein derartig gelinktes Programm hat einen 256 Byte langen Header, dem der Code mit einem originalen Offset von 0100h (also für ein normales CP/M-Programm) folgt. Anschließend ist eine Bit Map gespeichert, die ein Achtel der Codelänge umfaßt.

Diese Bit Map ist eine Kette von Bits, mit denen angezeigt wird, welches Byte des Codes noch reloziert werden muß. Für jedes Byte des Codes steht ein Bit zur Verfügung, also entspricht ein Byte der Bit Map 8 Codebytes. Das höchstwertigste Bit (Bit 7) des ersten Bytes der Bit Map bestimmt, ob das erste Byte des Codes reloziert werden muß. Ist das Bit gesetzt, so muß das Codebyte reloziert werden. Das nächste Bit (Bit 6) bezieht sich demzufolge auf das zweite Codebyte usw.

Eine PRL-Datei ist folgendermaßen aufgebaut:

0001 - 0002h	Programmgröße, (low, high)
0004 - 0005h	zusätzlich benötigter Speicher (im Normalfall leer)
0006 - 00FFh	momentan unbenutzt, reserviert für zukünftige Erweiterungen
0100 + Programmgröße	Beginn der Bit Map

Bei der Verwendung von PRL-Dateien sind zwei Dinge zu beachten. Zum einen können derartige Dateien immer nur auf eine volle Page reloziert werden, das untere Byte der Basisadresse ist also immer 00h. Zum anderen stehen die Informationen innerhalb der PRL-Datei nach dem Header nicht mehr Page-aligned, so daß die Bit Map z. B. bei 053Bh beginnen könnte.

Jetzt sind die Forderungen von Dirk Walther eigentlich ganz einfach zu erfüllen. Es werden nur noch ein paar Zeilen Assembler benötigt, um die PRL-Datei auf eine bestimmte Adresse zu linken. Auch größere Projekte lassen sich verwirklichen. Einige Routinen aus der SYSLIB mit den eigenen zu einer PRL-Datei verbinden - fertig! Doch bevor jetzt jeder wie wild drauflos programmiert und sich am Ende wieder alles im Grundgeräte-RAM bekriegt, hier der zweite Teil meiner Überlegungen.

Ein Programm oder Treiber darf sich nicht länger irgendwo im Speicher breit machen. Es muß sich korrekt einordnen. Dazu muß aber jemand (oder etwas) Regie führen. Grundgedanke des Systems ist die Zuteilung des/der freien Bereiche(s) durch ZAS. Diese Software-Erweiterung hat sich durchgesetzt und stellt meines Erachtens eine solide Basis für zukünftige Erweiterungen dar.

Soll ein Treiber oder eine Systemerweiterung in das Grundgerät übertragen werden, so muß eine dementsprechende PRL-Datei vorliegen. Ein Installationsprogramm beantragt die Anzahl der benötigten Pages (256 Byte Blöcke) bei ZAS. Dieses überprüft, ob noch genügend zusammenhängender Speicher verfügbar ist. Im positiven Fall gibt ZAS an das Installationsprogramm die Basisadresse zurück. Erst dann wird der Code gelinkt und übertragen.

Momentan "weiß" nur das Installationsprogramm, ob und wo sich das übertragene Programm im Speicher befindet. Ein Programm, welches davon Gebrauch machen will, hat aber überhaupt keine Ahnung davon. Weil sich der übertragene Programmcode überall und nirgends befinden könnte, muß noch ein Verfahren gefunden werden, das die Basisadresse zurückgibt. Daher ist die Einführung eines Identifizierungscodes (kurz: ID) für jeden Treiber notwendig.

Eigentlich sollte ein Byte dafür genügen. Verschiedene Versionen einer Software können stets gleiche IDs bekommen. Seitens eines Programmierers (ich will ja keine Namen nennen :-) kam jedoch die dringende Bitte, zwei Bytes vorzusehen. Eines als ID für die Software und das andere als ID für den Programmierer. (Type & Creator - schöne Grüße aus der Apple-Kiste) Welche Variante letztendlich Anwendung findet, ist aber zur Zeit unerheblich.

Doch nun weiter zur Funktionsweise. Möchte ein MicroDOS- oder CP/M-Programm einen speziellen Treiber im Grundgeräte-RAM nutzen, muß zunächst der ID an ZAS übermittelt werden, um von dort die Basisadresse zu erhalten. Einmal festgestellt, kann diese Adresse in einer Arbeitszelle hinterlegt und für weitere Operationen benutzt werden. Genaue Spezifikationen für die Treiber stehen augenblicklich noch nicht fest. Auf alle Fälle wird aber (analog zu den Drucker- und Koppeltreibern) am Anfang des Codes ein Programmverteiler stehen. Aus meiner Sicht sollten folgende Funktionen unterstützt werden: Initialisierungsroutine, Abfrage der Versionsnummer und Rückgabe einer kurzen Zeichenkette (mit Realname, Copyright u. ä.).

Wie man Sätzen mit den Worten "momentan", "zur Zeit" oder "augenblicklich" entnehmen kann, handelt es sich bei der hier vorgestellten Lösung eigentlich nur um einen Lösungsansatz. Derzeit enthält weder ZAS die notwendige Unterstützung, noch gibt es ordentliche Standards. Ein paar Ideen zur Nutzung sind allerdings schon vorhanden. Deshalb soll dieser Beitrag auch "nur" eine Diskussionsgrundlage bilden. Wer also etwas dazu zu sagen hat, der möge dies gern hier in den KC-News tun - jede Meinung zählt!

Besonders die folgenden Problemchen bedürfen noch einer Lösung:: Völlig ungeklärt ist zum Beispiel, wie man Programmcode aus einer Hochsprache installiert! Wichtiger ist jedoch, Kompatibilität zu bereits vorhandener Software zu erhalten. Eventuell sollten die Pages von ZAS in absteigender Folge vergeben werden, so daß der Bereich ab 4000h möglichst (lange) frei bleibt!? Ideen, wie ESC-Sequenzen derart installierter Treiber unterstützt werden können, sind ebenfalls herzlich willkommen!

Ich gehe davon aus, daß wir vielleicht schon beim nächsten Clubtreffen klüger sind und einen neuen Standard definieren können. Die großen Speicherkriege mit zahllosen verletzten Bytes sollten dann der Vergangenheit angehören. Übrigens, eine PRL-Datei auf eine bestimmte Adresse zu linken, ist ganz einfach - sogar ich hab's geschafft. Den Beweis in Assembler trete ich in der Programmierecke dieser Ausgabe an.

Zusammenfassung:

Treiber installieren

• benötigte Pages an ZAS übermitteln
• Rückmeldung: Startadresse oder Fehler
• Treiber relozieren und in Grundgerät übertragen
• Treiber initialisieren
• ID-Code(s) an ZAS übergeben

Treiber deinstallieren

• ID-Code(s) an ZAS übergeben
• Löschbefehl erteilen
• ZAS korrigiert Belegungsvektor und Tabelle

notwendige Routinen in ZAS

• Feststellung freie Pages/Belegung
• Belegungsvektor nach De-/Installation aktualisieren
• ID-Code(s) eintragen/löschen

von ZAS verwaltete Tabellen

• 8 Bytes Belegungsvektor (Bereich 4000 - 7FFFh = 64 Pages = 8 Bytes)
• je Treiber 1/2 Byte(s) ID-Code(s), 1 Byte Startpage, 1 Byte Länge (Anzahl Pages), evtl. 1 Byte ESC-Code
  
  

WA-TOR

(gefunden im INFO 39 des Club-80)

von Mario Leubner
(nach einer Idee von A. K. Dewdney)

Durch Zufall bin ich in den Besitz einiger Info's des Club-80 gekommen. Dies ist ein Computerclub, der sich wie wir ebenfalls mit 8-Bit-Rechnern befaßt(e). Leider ist es um die Aktivitäten des Club-80 ziemlich still geworden, da immer mehr zu den MS-DOSen wechseln und sich dann kaum noch um den Club kümmern.

Ein interessantes Programm habe ich in der INFO Nr.39 gefunden. Es geht um die Simulation eines Ökosystems auf dem Computer. Das Programm selbst ist in Turbo-PASCAL geschrieben und war als Quelltext abgedruckt. Ich habe den Quelltext eingetippt und WATOR lief auf Anhieb auf dem KC85! WATOR.PAS und WATOR.COM sind die entsprechenden Dateien.

Doch damit war ich noch nicht recht zufrieden: Der KC85-Bildschirm ist ja grafikfähig, warum sollte man die Kurven der Population also nicht grafisch darstellen? Dies habe ich in WATOR2.PAS / COM realisiert. Ich nutze das 2. Bild des KC85/4 um für jeden Bestand einen Punkt zu setzen. Während der Erstellung des einen Bildes wird das jeweils andere angezeigt, die Bilder werden also ständig hin- und hergeschalten. Ein Kompromiß, um beide Entwicklungen zugleich verfolgen zu können.

Doch genug der Vorrede, lest erst mal den Textbeitrag aus dem Club-80-INFO durch, damit Ihr versteht, worum es geht. In diesem Sinne wünsche ich viel Spaß bei einem mal etwas anderen Programm.

(Den Artikel aus dem Club-80-INFO findet Ihr im Anhang. Hoffentlich ist er nach dem nochmaligen Kopieren einigermaßen lesbar.)

Das neue Betriebssystem für den KC85 (3)

von Mario Leubner

Wie bereits gewohnt an dieser Stelle wieder die aktuellen Neuerungen vom KC-Betriebssystem mit ZSDOS / ZDDOS. Es gibt schon wieder Updates einiger Programme und Quelltexte. So langsam bin ich an dem Stand angekommen, wie ich mir das System immer vorgestellt habe. Das soll jedoch nicht heißen, daß es keine Änderungen mehr geben wird.

Hinweise, deren Realisierung möglich sind, nehme ich weiterhin dankend entgegen. Doch nun erst mal zu den "News" von heute:

Erstellung des eigenen ZBIOS
(ZBIOS.MAC, OPTION.INC, DEFDPB.INC)

Durch Weiterentwicklung der Quelltexte ist es jetzt möglich, die Anzahl der verwendenden logischen Laufwerke im Bereich von 5 bis 16 zu wählen. Dazu muß nur in der Datei OPTION.INC der Wert von NDRIVES entsprechend geändert werden. Eingestellt habe ich standardmäßig 8 Laufwerke.

Wer viel TPA wünscht und auf 3 Laufwerke verzichten will, kann dort eine 5 eintragen und hat demnach nur noch die Laufwerke A: bis E: zur Verfügung. Will jemand viele unterschiedliche Laufwerke installieren und benötigt mehr als die üblichen 8 Laufwerke, dann kann die Anzahl in NDRIVES auf bis zu 16 erhöht werden. Es stehen dann die Laufwerke A: bis P: zur Verfügung.

Jedes logische Diskettenlaufwerk benötigt 128 Byte Speicher im BIOS. Damit kann man sich ausrechnen, welche Veränderungen es im Adreßbereich gibt. Die Anfangsadresse des BIOS kann sich nur in Schritten von 100H ändern. Wird beim Assemblieren des BIOS ein freier Speicher von 128 Byte oder mehr angezeigt, kann man ein weiteres Diskettenlaufwerk definieren, ohne daß sich der TPA verkleinert.

Für jedes Laufwerk muß festgelegt werden, welches Diskettenformat erzeugt werden soll, Werte für nicht benutzte Laufwerke können beliebig sein. Und noch ein Hinweis: Nur die installierten Laufwerke können mit MODF.COM verändert werden. Eine nachträgliche Erweiterung ist damit nicht möglich!

Bei der Partitionierung der Festplatte lassen sich jetzt bis zu 3 Partitionen angeben. Dies erfolgt in der Variable HARD. Wird eine 0 eingetragen, erzeugt man wie bisher ein reines Diskettensystem. Werte im Bereich von 1 bis 3 geben an, wieviele Partitionen zu erzeugen sind, wobei die erste Partition immer C:, die zweite D: und die dritte E: ist. Die restlichen Laufwerke bis NDRIVES werden als Diskettenlaufwerke erzeugt.

Zur Partitionierung wird von den Gesamtzylindern der Platte jedem Laufwerk ein Teil zugeordnet. Laufwerk C: ist mit 1024, die anderen beiden mit 2048 Verzeichniseinträgen vorbereitet. Die Blockgröße ist stets 4 KByte. Das sollte man wissen, um die Gesamtkapazität der Platte sinnvoll aufteilen zu können.

Wird nur eine Partition benutzt, erhält diese die gesamten Zylinder. Dies ist jedoch nur bei sehr kleinen Festplatten sinnvoll, da dann für die gesamte Kapazität nur 1024 Einträge zur Verfügung stehen. Bei zwei Partitionen sind es 1024+2048 und die Gesamtkapazität der Platte sollte in drei Teile geteilt werden, wobei C: einen und D: zwei Teile zugeteilt bekommt. Das könnte bei 560 Zylindern z.B. so aussehen:

560 / 3 = 186 Rest 2	=> C: erhält 188 Zylinder
	=> D: erhält 372 Zylinder

Soll mit 3 Partitionen gearbeitet werden, ist die Gesamtkapazität entsprechend in 5 Teile zu teilen, dabei ergibt sich:

560 / 5 = 112	=> C: erhält 112 Zylinder
	=> D: erhält 224 Zylinder
	=> E: erhält 224 Zylinder

Dies soll nur ein Anhaltspunkt für eine optimale Partitionierung sein, eingeben kann man alle denkbaren Werte. Als weiterer Richtwert kann auch meine Erfahrung genutzt werden, daß mit 1024 Verzeichniseinträgen ca. 10 MByte Daten auf der Festplatte verwaltet werden können, das entspricht einer durchschnittlichen Dateigröße von etwa 10 KByte.

Es besteht auch die Möglichkeit bei großen Festplatten nur einen Teil der Gesamtkapazität zu verwenden: Ist die Summe der benutzten Spuren kleiner als die physisch vorhandenen, dann bleibt der Rest ungenutzt.

FORMAT.COM, Version 3.2
(FORMAT32.COM)

Es gibt zwei Neuerungen gegenüber der Version 3.1. Zum einen ist es die Option /Q: damit kann eine "Schnellformatierung" durchgeführt werden. Dies ist eine Alternative zum Befehl ERA *.* und geht wesentlich schneller als das einzelne Löschen aller Dateien. Die Schnellformatierung formatiert dabei von Spur 0 bis zum Ende des Verzeichnisses, bei 780K-Disketten also 3 Spuren.

Man sollte aber beachten, daß man eine arbeitsfähige Diskette nur erhält, wenn diese bereits einmal komplett im selben Format formatiert wurde. FORMAT.COM überprüft dies nicht!

Die zweite Neuheit ist das physische Löschen von "Nicht-Diskettenlaufwerken". Ein echtes Formatieren der Festplatte ist zur Zeit auf dem KC noch nicht möglich. Wird FORMAT V3.2 ohne zusätzliche Parameter von Diskette gestartet, dann erscheint das übliche Menü. Jetzt gibt man das gewünschte Laufwerk an. Erkennt FORMAT daß es kein Diskettenlaufwerk ist, dann erscheint eine Warnung die 2mal mit 'J' zu bestätigen ist um den Löschvorgang einzuleiten.

Gelöscht wird dabei das gesamte Laufwerk Sektor für Sektor durch Schreiben von E5H in jedes Byte. Eventuell vorhandene Systemspuren bleiben erhalten. Damit kann auch das RAM-Floppy physisch gelöscht werden. Sind jedoch EPROM-Modul(e) eingebunden, gehen beim Löschen deren Directory-Einträge mit verloren! Spätestens beim Beschreiben der Spuren des EPROM-Moduls treten dann natürlich Probleme auf.

HDPARK
(HDPARK11.MAC, HDPARK11.COM)

Das Parken der Festplatte erfolgt in der letzten Spur durch Lesen aller Sektoren dieser Spur. Version 1.1 wurde angepaßt um eine unterschiedliche Anzahl an Partitionen zu unterstützen.

Systemgenerierung
(SYSGEN.COM)

Wie bereits angekündigt, wurde SYSGEN wesentlich verbessert und mit einem Menü ähnlich MSYSG.COM versehen, jedoch stark erweitert. Es ist damit wieder möglich, das System in die Systemspuren einer 780K-Diskette zu schreiben. So entfällt der Umweg über MicroDOS und der Bootvorgang muß nur noch einmal erfolgen. Der Aufruf

SYSGEN //

bringt weiterhin eine Hilfeseite zur Erstellung des Systems. Zunächst ist die SPR-Datei mit dem System (CCP, BDOS, BIOS) zu erzeugen. Dazu sind zwei Kommandozeilen nötig:

A>ASM ZBIOS=ZBIOS
A>LINK131 SYSTEM.SYS=CCP,ZSDOS.ZRL,ZBIOS [D1600,OS,NR]

Beim Linken werden die drei Systembestandteile zu einer SPR-Datei zusammengefügt, für das richtige Format sorgt die Option OS. Als Dateityp habe ich *.SYS gewählt, da *.SPR eine allgemeingültige Bezeichnung ist und nicht unbedingt eine SPR-Datei mit dem Systemabzug darstellt. Der Name der SYS-Datei kann frei gewählt werden, alle Dateien *.SYS werden später im SYSGEN-Menü zur Auswahl angeboten.

Sind alle erforderlichen Dateien, also SYSGEN.COM, die SYS-Datei(en) und die zu installierenden Treiber auf dem aktuellen Laufwerk vorhanden, dann kann SYSGEN ohne Parameter aufgerufen werden und es erscheint das Menü:

Systemgenerierung für CP/M 2.2 auf dem KC85  -  V 0.4
       Copyright by ML-Soft 21.10.96
-----------------------------------------------------
Adresse CCP:				LST:
Adresse BDOS:				KOP:
Adresse BIOS:				ZAS:
-----------------------------------------------------
Funktionsauswahl:
 1 - Betriebssystem *.SYS
 2 - Druckertreiber *.LST
 3 - Koppeltreiber *.KOP
 4 - Terminaltreiber *.ZAS
 5 - RAM-Floppy konfigurieren
 6 - Start-SUBMIT
 7 - Beschreiben der Systemdiskette
 8 - Erzeugen einer COM-Datei
 9 - Aktivieren neues System im RAM
10 - installiertes SYSGEN.COM abspeichern
 0 - SYSGEN beenden

Zur Auswahl Ziffer eingeben:_

Jetzt muß nur noch die gewünschte Konfiguration zusammengestellt werden. Mit Menüpunkt 1 wird zunächst die erzeugte SYS-Datei eingelesen, danach sind die Systemadressen im Menü zu sehen und die Menüpunkte 6 bis 10 können aufgerufen werden. Es können mehrere SYS-Dateien auf dem aktuellen Laufwerk vorhanden sein, wobei dann die gewünschte ausgewählt werden kann.

Die Punkte 2 und 3 sind für die bekannten Treiber vorgesehen, analog dazu der Punkt 4 für den Terminaltreiber im ZAS-Dateiformat. Die Einbindung der Treiber ist nicht erforderlich wenn mit den Treibern des D004-EPROM gearbeitet werden soll. Dann geht der Ladevorgang etwas schneller.

Der ZAS-Treiber wird beim Booten als letztes übertragen, damit ist es möglich auch ZAS-Treiber einzubinden die keine KC-spezifischen Funktionen mehr enthalten (wie z.B. der Televideo-Treiber).

Unter Menüpunkt 5 kann die Konfiguration des RAM-Floppys verändert werden. Dabei erscheint eine Liste aller verwendeten RAM/EPROM-Module. Außer dem RAM8 werden die folgenden Module im RAM-Floppy verwendet:

	Strukturbyte	Blockanzahl	Steuerbyte	Offset
1. Modul:	F4 = M022	1	83H	00H
2. Modul:	F5 = M024	2	43H	40H
3. Modul:	F6 = M011	4	03H	40H
4. Modul:	78 = M036	8	83H	04H
5. Modul:	79 = M032	16	83H	04H
6. Modul:	7A = M034	32	83H	04H
7. Modul:	7B = M035	64	83H	04H
8. Modul:	73 = M048	16	83H	04H
9. Modul:	00 = M???	0	00H	00H
10. Modul:	00 = M???	0	00H	00H
11. reserviertes Modul:	00 = M???

Alle gängigen RAM-Module von 16K bis 1M und das 256K-EPROM-Modul sind bereits definiert. Für Standardanwendungen ist keine Veränderung erforderlich und alle RAM-Module werden zum RAM-Floppy zusammengefaßt. Zehn Module enthält die Tabelle, zwei davon sind noch frei und können durch Eigenbau-RAM-Module ergänzt werden.

Einzugeben ist für jedes Modul das Strukturbyte an dem es erkannt wird. Zur Verwaltung ist die Anzahl der 16K-Blöcke dezimal einzugeben. Das erste Steuerbyte mit dem das Modul auf Adresse 8000H online geschaltet wird und der Offset (Abstand zum nächsten Steuerbyte) sind schließlich für den Aufbau der Modulsteuertabelle im Grundgerät erforderlich und hexadezimal einzugeben.

Es können alle 10 Moduleinträge verändert werden. Um z.B. 16K-RAM-Module aus dem RAM-Floppy auszuschließen, ist einfach in Zeile 1 die Moduldefinition zu löschen indem für das Strukturbyte 0 eingegeben wird. Am Ende der Tabelle ist noch die Eingabe eines reservierten Moduls möglich. Damit kann bei einer Bestückung mit mehreren Modulen vom gleichen Modultyp nur eines ausgeschlossen werden.

Wenn also z.B. 4 Stück M011 vorhanden sind und ein M011 für spezielle Aufgaben aus dem RAM-Floppy ausgeschlossen werden soll, ist in Zeile 11 das Strukturbyte F6 einzugeben während die Definition des M011 in Zeile 3 unverändert bleibt.

Neu ist auch der Menüpunkt 6, mit dem ein Startkommando definiert werden kann. Zur Erklärung: CP/M 2.2 kann nicht wie von MicroDOS gewohnt mit einer INITIAL.SUB gestartet werden, da es keine interne SUBMIT-Unterstützung besitzt. Hier kann jedoch ein Mehrfachkommando definiert werden, welches einmalig nach dem Bootvorgang abgearbeitet wird.

Bei der Erstinstallation sollte jedoch noch nichts eingegeben werden, damit erst einmal die korrekte Funktion des Bootvorgangs getestet werden kann. Später kann dieses Startkommando dann z.B. ein SUBMIT-Programm starten, welches weitere Kommandos automatisch ausführt oder das komplette Z-System lädt. Um z.B. eine Datei INITIAL.SUB abzuarbeiten könnte eingegeben werden:

B:SUBMIT B:INITIAL.SUB

Die Dateien SUBMIT.COM und INITIAL.SUB müssen sich dabei auf der Startdiskette im Laufwerk B: befinden. Sollen mehrere Kommandos im Start-SUBMIT abgearbeitet werden, dann sind diese jeweils durch ein Semikolon voneinander zu trennen. Beim Bootvorgang wird diese Mehrfachkommandozeile in die entsprechenden Einzelkommandos zerlegt und als A0:$$$.SUB abgespeichert.

Der CCP arbeitet zunächst diese Kommandodatei ab, bevor er zur Tastatureingabe übergeht. Die maximale Länge der Mehrfachkommandozeile beträgt 127 Zeichen. Als Beispiel ein Start-SUBMIT für eine CAOS-Diskette mit ZDDOS und ein System ohne Festplatte:

T S;B:;DEP3 INITIAL.UUU

Diese Mehrfachkommandozeile wird in die drei Einzelkommandos

A0>T S
A0>B:
B0>DEP3 INITIAL.UUU

zerlegt. T S wartet auf Tastatureingaben und gestattet das Stellen der Uhr, bevor automatisch zu Laufwerk B: gewechselt und DEP3.COM mit der Stapeldatei INITIAL.UUU gestartet wird. Als Ergebnis dieses Bootvorgangs befindet man sich wieder im CAOS und im D004 läuft ZDDOS.

Da keine batteriegestützte Echtzeituhr vorhanden ist, kann bei jedem Bootvorgang Datum und Uhrzeit eingegeben werden und die Datumseinträge werden auf der CAOS-Diskette ordnungsgemäß protokolliert.

Die Menüpunkte 7 bis 9 dienen zur Erzeugung des Systems, wobei mit Punkt 7 in die Systemspuren einer 780K-Diskette geschrieben, mit Punkt 8 eine COM-Datei erzeugt und mit Punkt 9 das System zum Test im RAM aktiviert wird. Die COM-Datei wird dabei auf das aktuelle Laufwerk geschrieben, die Angabe von Laufwerk und Dateityp ist hier nicht vorgesehen.

Unter Menüpunkt 10 ist es schließlich möglich, SYSGEN.COM einschließlich des mühsam installierten Systems, also komplett mit allen Treibern, der Konfiguration des RAM-Floppy und des eingegebenen Start-SUBMIT abzuspeichern. Es wird der Name der zu erzeugenden COM-Datei angefordert, dabei sollte nicht SYSGEN angegeben werden um ein Überschreiben der uninstallierten Version zu vermeiden!

Beim Start der installierten Version von SYSGEN.COM sind sofort alle alten Einstellungen wieder verfügbar und es kann sofort erneut in die Systemspuren geschrieben werden.

HINWEIS:
Disketten mit ZSDOS / ZDDOS in den Systemspuren sowie COM-Dateien mit einem Systemabzug und das installierte SYSGEN.COM unterliegen dem Urheberrecht von ZSDOS und dürfen nicht weitergegeben werden. Zum Datenaustausch also nur Disketten verwenden, die neu formatiert wurden bzw. das System MicroDOS enthalten!

Kommandoprozessor CCP V1.4
(CCP.MAC, CCP.REL)

Am CCP wurden noch zwei kleinere Änderungen vorgenommen. Damit ist es jetzt möglich, den Uhrentreiber für ZSDOS als RSX (residente Systemerweiterung) zu installieren. Der RSX-Treiber wird unmittelbar unterhalb des CCP geladen und verlegt den BDOS-Einsprung nach vorn, so daß auch der CCP nicht mehr überschrieben werden kann.

Damit verringert sich der zur Verfügung stehende TPA um 2655 Byte. Der Uhrentreiber belegt davon zwar nur 607 Byte, aber die 2048 Byte vom CCP gehen dem TPA ebenfalls mit verloren.

Die zweite Änderung betrifft den ZSDOS-Fehlermodus. Der CCP stellt beim Start jedes Programmes jetzt den Modus 0 (CP/M-Modus) ein. Unter diesem Modus arbeitet auch PUTDS.COM korrekt und kann seine Zwischendatei !!!TIME&.TMP ordnungsgemäß in !!!TIME&.DAT umbenennen. Verlangen Programme einen anderen Fehlermodus, dann müssen sie diesen mit der BDOS-Funktion 45 selbst einstellen und am Programmende auf 0 zurücksetzen.

DEP3.COM
(DEP3.COM, DEP3.HLP)

Bisher war es noch nicht möglich, unter CAOS auf die Festplatte zuzugreifen. In den KC-News 2/96 hatte ich DEP 3.0 ja bereits angekündigt, es hat sich in der Realisierung jedoch etwas am geplanten Konzept geändert. DEP 3.0 ist ein "normales" CP/M-Programm geworden und benötigt zur Arbeit auch ein "normales" CP/M-System. Damit gibt es für die CAOS-Betriebsart kein modifiziertes System mehr.

Das hat den Vorteil, daß nur ein Betriebssystem für beide Betriebsarten erforderlich ist und problemlos von CP/M zu CAOS gewechselt werden kann. Soll eine CAOS-Startdiskette erzeugt werden, ist SYSGEN.COM zu verwenden. Zum Einstellen der Parameter ein paar Hinweise:

• Als BDOS empfehle ich ZDDOS, da dieses automatisch Datumseinträge erzeugt.
  
  
• Treiber brauchen nicht installiert werden, da diese nur für die CP/M-Betriebsart erforderlich sind.
  
  
• Die RAM-Floppy-Konfiguration ist eigentlich uninteressant, da DEP das RAM-Floppy ohnehin uminstalliert. Es müssen aber dennoch mindestens 2 Spuren im RAM-Floppy erzeugt werden, damit der Start-SUBMIT ordnungsgemäß abgearbeitet werden kann.
  
  
• Die Definition des EPROM-Floppymoduls (Strukturbyte 73H) kann gelöscht werden, dann entfällt das Erzeugen des dazugehörigen Verzeichnisses.
  
  
• Der Start-SUBMIT sollte DEP 3.0 starten, damit wird der automatische Wechsel zur CAOS-Betriebsart eingeleitet. DEP 3.0 kann als Parameter ein Laufwerk und der Name einer Stapeldatei übergeben werden. Ist der Start-SUBMIT ein Mehrfachkommando, dann muß der Aufruf von DEP am Ende stehen, da DEP nicht wieder zum CCP zurückkehrt.

Die Kommandozeile von DEP 3.0 sieht folgendermaßen aus:

A0>B:DEP3 du:dateiname.typ

Nachdem DEP3.COM geladen wurde, wechselt es zum angegebenen Laufwerk und USER-Bereich (du:) und übergibt die CAOS-Stapeldatei (dateiname.typ) in gewohnter Weise zur Abarbeitung an das Grundgerät. Da ein beliebiger Dateiname und ein beliebiges Laufwerk angegeben werden kann, gibt es praktisch keine Einschränkungen mehr zum Start einer CAOS-Anwendung von jeder beliebigen CP/M-Kommandozeile aus.

DEP 3.0 installiert das RAM-Floppy für TPA um und wechselt zur CAOS-Betriebsart. Dort kann man dann wie gewohnt weiterarbeiten. DEP 3.0 paßt sich beim Start automatisch dem laufenden System an. Je nachdem, wieviel freier TPA gefunden wird, ist die Kapazität des RAM-Laufwerkes A: auch unterschiedlich groß.

Die Funktionen von DEP 3.0 sind abwärtskompatibel zu allen früheren Versionen, so daß sich für den Anwender und Programmierer unter CAOS (fast) nichts ändert. Neu ist die Sortierung des Inhaltsverzeichnisses vor der Ausgabe und die Übergabe von Datum und Uhrzeit der Echtzeituhr. Die Beschreibung der kompletten Schnittstellen von DEP 3.0 ist der HELP-Datei DEP3.HLP zu entnehmen.

Ergänzend noch eine Bemerkung von Ralf Kästner zum neuen System:
Zusammenfassend festgestellt - nun sollte auch der unbedarfteste User sein System herstellen können, einer Nachnutzung des HDD-Anschlusses sollte wohl softwareseitig nichts mehr im Wege stehen - darauf kann in der nächsten Ausgabe der News auch mal mit aller Deutlichkeit und dem nötigen Nachdruck für die Unentschlossenen aufmerksam gemacht werden, Ausreden gibt es nun nicht mehr, außer 2 linke Hände, notorische Faulheit oder -2000,00 DM "Guthaben" auf dem Girokonto!

Die Zukunft beginnt mit "Z" - Teil 3

von Jörg Linder

Heute geht es in die dritte und letzte Runde. Im vorigen Artikel hatte ich die verschiedenen Elemente vorgestellt, aus denen sich ein Z-System zusammensetzen kann. Sicherlich hat die Vielfalt bei einigen für Verwirrung gesorgt. Manche haben bestimmt nur den Kopf geschüttelt und nach den ersten Zeilen aufgehört, den Artikel zu lesen.

Inzwischen sind jedoch ein paar NZ-COM Neulinge hinzugekommen und auch ZDDOS / ZSDOS erfährt immer mehr Verbreitung. Die kinderleichte Installation trägt ihr übriges dazu bei. Wer augenblicklich noch nicht zu den Usern gehört, könnte aber in Kürze mit von der Partie sein. Um eventuelle Schwierigkeiten beim Einstieg zu überwinden, will ich an dieser Stelle ein paar Tips geben.

Als erstes muß man sich bei der neuen Systemsoftware zwischen ZDDOS und ZSDOS entscheiden. In der letzten Ausgabe hatte Mario Leubner bereits die wesentlichen Unterschiede erläutert. Für die Arbeit ohne NZ-COM bzw. unter CAOS empfehle ich ZDDOS. Zwar muß man dann auf den DOS-internen Suchpfad verzichten, doch dafür sind bereits die DateStamper-Funktionen integriert. Somit werden auch die CAOS-Aktivitäten mit Datum und Uhrzeit protokolliert. Übrigens könnte man unter CAOS den Suchpfad sowieso nicht beeinflussen.

Kann oder will man unter keinen Umständen auf die Vorzüge von ZSDOS verzichten und trotzdem die DateStamper-Funktionalität nutzen, gibt es auch dafür eine Lösung. Dazu muß im BIOS-Bereich ein ausreichend großer Raum für die entsprechenden Treiber geschaffen werden. Anwendern von NZ-COM ist ZSDOS auf alle Fälle zu empfehlen, da hiermit größtmögliche Funktionsvielfalt und Flexibilität erreicht wird. Durch die geschickete Kombination von DOS-internem Suchpfad und ZCPR-Kommandosuchpfad kann man alle Programme von nahezu allen Laufwerken und Nutzerbereichen benutzen. Treiber für Datumsstempel können in geschützten Bereichen untergebracht werden und beanspruchen nur wenig zusätzlichen Arbeitsspeicher.

Die Einrichtung der ZCPR-Umgebung erfordert ein wenig Überlegung. Während der Arbeit unter einer bestimmten Konfiguration stellt sich dann heraus, ob sie den eigenen Gewohnheiten entspricht oder geändert werden müßte. Spätestens dann lernt man NZ-COM zu schätzen, denn das Betriebssystem ist keine starre Einrichtung mehr, wo der Anwender den vom Programmierer vorgegebenen Beschränkungen ausgeliefert ist. Vielmehr kann man es den eigenen Bedürfnissen und Vorlieben anpassen.

Jeder der im 2. Teil dieser Artikelreihe vorgestellten Bestandteile einer ZCPR-Umgebung bringt eine gewisse Steigerung des Komforts mit sich. Es soll aber nicht unerwähnt bleiben, daß dafür auch Arbeitsspeicher gebraucht wird, der den kostbaren TPA schmälert. Durch die vom verfügbaren Arbeitsspeicher vorgegebenen Einschränkungen muß man seinen eigenen Kompromiß zwischen den Ansprüchen an den TPA und an den Komfort finden.

Einrichtung der ZCPR-Umgebung

Bevor ich mich diesem Thema eingehender widme, möchte ich darauf hinweisen, daß die hier beschriebene Vorgehensweise auf eigenen Erfahrungen beruht und nur eine Empfehlung darstellt. Selbstverständlich hat jeder die Freiheit, nach seinen Vorstellungen und Wünschen zu verfahren! Auf alle Fälle sollte der Aufforderung im NZ-COM Handbuch Folge geleistet und eine Kopie der Orginaldiskette angefertigt werden. Sämtliche Manipulationen werden nur an der Kopie durchgeführt!

Bereits bei der Definition der Umgebung (System-Deskriptor) werden Entscheidungen getroffen, die das Erscheinungsbild und die Funktionalität des späteren System festlegen. Ganz wichtig: Der System-Deskriptor muß unter der Systemkonfiguration erstellt werden, mit der später NZ-COM laufen soll, da die enthaltenen Informationen adreßabhängig sind.

Auf einzelne Elemente kann man verzichten (z. B. ein I/O-Paket), bei anderen zwischen verschieden großen Versionen wählen (z. B. RCP - residente Befehle) oder zusätzlichen Platz im hohen Speicher (UMA) für die DateStamper-Routinen reservieren. Dies alles sollte im Hinblick auf den verbleibenden TPA geschehen.

Logischerweise bieten größere Pakete auch mehr Funktionen, doch oftmals können auch kleine Utilities die Aufgaben übernehmen. Wer mit dem von MicroDOS gewohnten Befehlsumfang arbeiten möchte, kann die von Mario Leubner angepaßte Version des RCP10H benutzen. Der Dateibezeichnung ist zu entnehmen, daß sie im Speicher 10 Records (1 Record = 128 Bytes) belegt. Legt man Wert auf absolute Funktionsvielfalt, kann ein mehr als 20 Records großer RCP verwendet werden. Die untere Grenze stellt ein nur 4 Records großes Paket dar.

Analog gilt dies auch für den FCP. Weil die Programmteile bereits im Speicher stehen und nicht erst vom Datenträger geladen werden müssen, werden interne Kommandos schneller ausgeführt. Kommen jedoch Bedingungen (IF, ELSE ...) kaum zur Anwendung, dann kann man eine Minimalvariante des FCPs benutzen oder ganz darauf verzichten. Alle Funktionen des FCPs können auch von IF.COM ausgeführt werden. (Erfahrungsgemäß entdeckt man den Nutzen von bedingten Kommandoausführungen viel zu spät!)

Die Anzahl der benannten Verzeichnisse ist reine Geschmackssache. Für die einen sind 7 schon zu viel und für die anderen 21 noch zu wenig. Doch Achtung - alles hat seinen (Speicher-)Preis! Auf den ersten Blick scheinen die Namen nur schmückendes Beiwerk der Eingabeaufforderung im jeweiligen Verzeichnis zu sein. Weiter unten in diesem Artikel werde ich jedoch Beispiele für die Benutzung in Aliasen zeigen.

Eine Komponente sollte jedoch unverändert bleiben: der Shell Stack. Der Platz für vier Einträge dürfte allen Ansprüchen genügen. Ein Verzicht ist nicht zu empfehlen, da überaus nützliche Tools wie ZFILER oder LSH zur "Gattung" der Shells gehören und ohne den Shell Stack ihren Dienst verweigern.

Start des Systems

Bevor das System gestartet werden kann, müssen noch die benötigten Bestandteile in der Bibliothek NZCOM.LBR abgelegt werden. Verwendet man die Namen der bereits vorhandenen Module (mit "NZ" beginnend), so werden sie beim Start automatisch geladen. Dazu entpackt man am besten die gesamte Bibliothek und kopiert die benötigten Komponenten in dasselbe Verzeichnis. Dann wird die Originaldatei gelöscht und die neue umbenannt, so daß sie jetzt den Namen der alten hat.

Kleines Beispiel gefällig? Das standardmäßige DOS-Segment namens NZDOS.ZRL wird gelöscht. Anschließend ZSDOS.ZRL (oder ZDDOS.ZRL) in NZDOS.ZRL umbenannt. Ebenso wird mit RCP, FCP usw. verfahren. Ist alles erledigt, werden die Dateien wieder in die Bibliothek NZCOM.LBR gepackt. Ab sofort startet das Z-System automatisch mit dem neuen BDOS-Segment und den definierten Bestandteilen.

Das wird auch gleich ausprobiert. Während des Startvorgangs kann man am Bildschirm verfolgen, wie NZ-COM die Systemumgebung entsprechend den Festlegungen zusammensetzt, linkt und startet. Jetzt ist das Z-System aktiv und es kann losgehen. Um es jedoch optimal an die eigenen Bedürfnisse anzupassen, ist noch ein wenig einzurichten...

Zuallererst sollte die richtige Datei für die Terminalansteuerung installiert werden. Der im Handbuch beschriebene Weg über den Startalias ist etwas mühselig. Eleganter geht es, wenn man die entsprechende Datei in NZCOM.Z3T umbenennt und ebenfalls in die Bibliothek NZCOM.LBR packt. Dann wird sie beim Start automatisch geladen. Für optimale optische Ergebnisse sollte man INVERS.COM (/3) oder ZAS v1.1 (/4 und höher) mit der passenden Z3T-Datei verwenden, die mit der neuen Systemsoftware geliefert werden.

Anpassung des Systems

So, nachdem das System jetzt läuft, geht es ans Tuning. Dazu werden wir unseren KC nicht tieferlegen und mit einem Heckspoiler versehen, sondern ein paar Systemeigenschaften beeinflussen, die die Arbeit noch beschleunigen.

Zunächst geht's an die Pfade. Dazu sollte man sich den Unterschied zwischen dem DOS-internen Suchpfad und dem Kommandosuchpfad von NZ-COM verdeutlichen. Beide können mit ZPATH eingestellt werden, unterscheiden sich aber in der Funktionsweise erheblich. Um nicht nach jedem Start die Pfade neu einstellen zu müssen, sollte man die ZPATH-Kommandos im Startalias speichern. Erfahrene User können den Kommandosuchpfad in NZ-COM patchen; wie das geht, steht im Handbuch.

Das letzte Pfadelement im Kommandosuchpfad nimmt eine Sonderstellung ein. Es bezeichnet das sogenannte "Root-Verzeichnis". Einige Programme und NZ-COM selbst legen dort spezielle Dateien ab. Deshalb sollte dieses Verzeichnis mit Bedacht gewählt werden. Als äußerst praktisch hat es sich erwiesen, A15: als Root-Verzeichnis zu wählen, während auf der Festplatte (in C0: oder C15:) die Utilities gespeichert sind. Die Einstellung für den Kommandosuchpfad könnte also lauten:

A0 C0 C15 $$ A15.

Kommen wir nun zu einem der mächtigsten Werkzeuge eines Z-Systems. Der Alias. Was man darunter zu verstehen hat, ist im NZ-COM Handbuch beschrieben. Mit der von Helmut Jungkunz ausgelieferten Version bekommt man auch schon eine Reihe von Aliasen in der Datei ALIAS.CMD. Diese können selbstverständlich angepaßt oder um eigene Schöpfungen ergänzt werden. Hier sind benannte Verzeichnisse besonders nützlich.

Folgender Alias sorgt bei mir für den richtigen Durchblick:

HILFE command:help helpfile:$1.h?p

Sobald ich das Kommando HILFE, gefolgt vom Dateinamen einer HLP-Datei eingebe, wird im Verzeichnis "COMMAND:" das Programm HELP.COM aufgerufen. Diesem wird der Dateiname übergeben, jedoch die Verzeichnisangabe "HELPFILE:" vorangestellt. Daß sich hinter dem Verzeichnis "COMMAND" eigentlich C15: und hinter "HELPFILE" C14: verbirgt, ist für alle Beteiligten - Bediener und Programm - völlig uninteressant. Der Kommandoprozessor setzt die Befehlszeile in ein gültiges Format um.

Und was ist nun der Vorteil daran? Zum einen brauche ich mir keine Gedanken mehr darum zu machen, in welchem Verzeichnis sich HELP.COM befindet. Nun ja, das bräuchte ich bei entsprechender Pfaddefinition auch nicht. Zum anderen muß ich mich nicht darum kümmern, daß HELP.COM die gewünschte Helpdatei findet. Das könnte man sich aber zur Not auch noch merken. Wie elegant diese Lösung ist, merkt man aber, wenn z. B. das Standardverzeichnis für die Helpdateien gewechselt wird.

Angenommen, es soll nicht mehr C14: sondern D3: sein. Bei einer direkten Verzeichnisangabe müßten alle Verweise in allen Aliasen von C14: auf D3: geändert werden. Dank der benannten Verzeichnisse genügt aber nur eine einzige Änderung - nämlich in der Definition für den Verzeichnisnamen. Ähnliche Lösungen hat sich auch Mario Leubner für diverse CAOS-Programme eingerichtet:

BASICODE caos:;:dep3 basicode.uuu
DEP e0:dep3 $td1$tu1:initial.uuu
UNIPIC=UP unipic:;:dep3 initial.uuu
WORDPRO,6=WP6 wp6:;:dep3 initial.uuu

Dies sind längst nicht alle Möglichkeiten, die das Z-System bietet. Aber der Artikel ist wieder länger geworden, als ursprünglich geplant. Ich hoffe, wenigstens bei einigen das Interesse geweckt zu haben. Zumindest ist erstmal Schluß mit dem ganzen Z-System-Zeugs. Aber nur hier in den News, auf dem KC geht's erst so richtig los! Schließlich beginnt die Zukunft für uns mit einem "Z".

HPKC - Ein Online-Calculator für den KC 85/4

von Frank Dachselt

Wer kennt nicht die folgende Situation? Man arbeitet mit einem Texteditor, schreibt einen Brief und möchte auf einmal wissen, wieviel sind 17 mal 3,35. Oder ein Programmierer benötigt die Anzahl der 128-Byte-Records, die sich im Speicherbereich 8500h ... B100h unterbringen lassen. Die Lösung dieser Probleme besteht meistens darin, daß man zum Taschenrechner greift und damit die jeweiligen Rechnungen durchführt. Und das, obwohl doch eine geballte Rechenleistung in Form des KC danebensteht ...

HPKC.COM ist entstanden, um das Arbeiten mit dem KC in solchen Fällen bequemer zu machen. Das Programm ist ein Online-Tool für die PC-Betriebsart und kann zusammen mit MicroDOS ebenso wie mit dem neuen Betriebssystem ZSDOS verwendet werden. Nach seiner Aktivierung steht der Calculator an beliebigen Programmstellen auf Tastendruck zur Verfügung.

HPKC ist zum Rechnen mit ganzen Zahlen mit einer Verarbeitungsbreite von 16 Bit bzw. für einfache Festkommaoperationen mit "gedachtem" Komma geeignet. Die Oberfläche und die Bedienung ist Hewlett-Packard-Taschenrechnern mit RPN-Arithmetik nachempfunden. RPN steht für "Reverse Polish Notation" bzw. auf deutsch "Umgekehrte Polnische Notation (UPN)". Die Besonderheiten dieser Arithmetik werden im folgenden noch näher erläutert.

Der Aufruf von HPKC.COM in der PC-Betriebsart löst nur die Installation des Calculators im Grundgerät aus, wobei der von Programmcode im Grundgerät belegte Speicherbereich angezeigt wird. Das Programm selbst belegt in der jetztigen Version den Bereich 3000h ... 3A00h und benötigt beim Aufruf den Bereich 6F80h ... 7FFFh als temporären Speicher. Nach der Installation kann in der PC-Betriebsart beliebig weitergearbeitet werden. Der Aufruf des Programms im Grundgerät erfolgt mit der Tastenkombination <SHIFT>-<CLR> zu einem beliebigen Zeitpunkt. Die Bedienung des Programms im D004 wird daraufhin unterbrochen und auf dem Bildschirm erscheint in einem Fenster die Oberfläche des Calculators. Nach dem Verlassen des Calculators wird die Bedienung wieder an das Programm im D004 zurückgegeben.

Der Vollständigkeit wegen noch die folgende Information. Der Kern des Calculators, also der Teil, der die arithmetischen Funktionen realisiert, wurde aus dem Programm HP11.COM von T. Hazen, das auch als HP11.RSX existiert, entnommen. Dieser Kern ist in CAOS eingebettet worden, wodurch jetzt eine wesentlich bequemere Oberfläche zur Verfügung steht. Die Bedienung ist unter Einbeziehung der Möglichkeiten der KC-Tastatur weitestgehend mit der des Originals identisch; die Funktionalität des Calculators ist dagegen etwas erweitert worden.

RPN-Notation

Reverse Polish Notation (RPN), die mitunter auch als Postfix-Notation bezeichnet wird, ist eine einfache aber leistungsfähige, stackorientierte Schreibweise, die unter anderen in Hewlett-Packard-Taschenrechnern verwendet wird. Dabei werden zunächst die Zahlen eingegeben, mit denen eine numerische Operation durchgeführt werden soll. Jeweils durch <RET> getrennt stehen diese Zahlen dann in aufeinanderfolgenden Ebenen des Stacks. Anschließend wird die gewünschte Funktion durch eine entsprechenden Eingabe ausgeführt. Dabei gehen die Operanden dieser Funktion durch Verschiebung der Stackregister bzw. Überschreiben mit dem Ergebnis verloren. Das Ergebnis selbst steht unmittelbar nach der Operation ebenfalls im Stack zur Verfügung.

Beispiele für RPN-Operationen (dezimale Anzeige wird angenommen):

zu lösen	Funktion	Tasten- betätigungen	Ergebnis- anzeige
9+3=12	9 plus 3	9<RET>3+	12
9-3=6	9 minus 3	9<RET>3-	6
9*3=27	9 mal 3	9<RET>3*	27
9/3=3	9 geteilt durch 3	9<RET>3/	3
9^3=729	9 hoch 3	9<RET>3^	729

Stack

Nach dem Aufruf des Calculators mit <SHIFT>-<CLR> werden die sieben Stackregister angezeigt, die während der Arbeit mit HPKC ständig sichtbar sind. Es ergibt sich folgendes Bild:

         0000       <- T-Register
         0000
         0000
         0000
         0000
         0000       <- Y-Register
H>       0000       <- X-Register

Die beiden unteren Stackregister sind das X- und das Y-Register. Das oberste Register ist das T-Register. Dem X-Register kommt die größte Bedeutung zu, es ist das Eingaberegister und zugleich das Ergebnisregister. Der Prompt vor dem X-Register zeigt an, welches Zahlenformat aktiv ist. Im angegeben Beispiel ist die hexadezimale Anzeige eingestellt, die zugleich die Vorgabe beim Start von HPKC ist.

Stackfunktionen

Es existieren verschiedene Funktionen, die zur Manipulation des Stacks benutzt werden, ohne daß numerische Operationen ausgeführt werden.

<CLR>
Löschen des gesamten Stacks:

Die Inhalte der sieben Stackregister werden auf Null gesetzt. Die Speicherregister sowie das LAST-X-Register bleiben unverändert.

 

<RET>
Eingabeübernahme:

Übernahme des Inhalts des Eingaberegisters (X-Register) in das Y-Register bei gleichzeitigem Verschieben aller weiteren Stackinhalte um eine Stufe nach oben. Der Wert des T-Registers geht dabei verloren. Im X-Register (Eingaberegister) wird eine Null eingetragen.

 

<CUU>
Zyklische Verschiebung der Stackinhalte nach oben,

<CUD>
Zyklische Verschiebung der Stackinhalte nach unten:

Alle Stackinhalte werden um eine Stufe nach oben bzw. nach unten verschoben. Der Inhalt des T-Registers wird in das X-Register bzw. der Inhalt des X-Registers in das T-Register übernommen.

 

=
Austauschen der Inhalte von X und Y:

Die Inhalte des X-Registers und des Y-Registers werden ausgetauscht. Diese Funktion kann verwendet werden, um die Reihenfolge von Operanden zu vertauschen, wenn numerische Operationen eine bestimmte Reihenfolge benötigen (z.B. Subtraktion, Division und Potenzierung).

 

L
Wiederherstellung des letzten Inhaltes des X-Registers:

Vor der Ausführung einer numerische Operation, wird der Inhalt des X-Registers in das LAST-X-Register kopiert. Dieser Wert wird mit dem L-Kommando wieder in das X-Register geschrieben, wobei der Stack zuvor um eine Stufe nach oben verschoben wird. Der Inhalt des LAST-X-Registers wird dabei nicht verändert.

Numerische Operationen

Mit HPKC können die folgenden acht numerischen Operationen ausgeführt werden:

+	Addition	Y+X
-	Subtraktion	Y-X
*	Multiplikation	Y*X
^	Potenzierung	Y^X (Y hoch X)
/	Ganzzahliger Quotient	INT(Y/X)
	- Rest	X*(Y/X-INT(Y/X)) -> Register R
&	Bitweises AND	X&Y
|	Bitweises OR	X|Y
~	Negation (2-er Komplement)	~X

Mit Ausnahme der Negation sind alle Funktionen binäre Operationen, d.h. es werden zwei Operanden benötigt, die sich im X- und im Y-Register befinden. Beide Operanden gehen bei der Ausführung einer Operation verloren, da der Stack um eine Stufe nach unten verschoben wird und sich das Ergebnis stets im X-Register befindet. Die Negation dagegen verändert nur das X-Register.

Bei der Division wird neben dem ganzzahligen Quotienten auch der Rest berechnet. Dieser wird im R-Register abgelegt, das als Speicherregister nicht Bestandteil des Stacks ist (siehe unten).

Eine Fehlermeldung (Beep) wird ausgegeben, wenn eine Taste gedrückt wird, die keiner numerischen, Stack- oder sonstigen Funktion zugeordnet und auch keine gültige Ziffer im gerade eingestellten Zahlenformat ist. Diese Fehlermeldung erscheint auch, wenn bei Multiplikation, Division oder Potenzierung ein 16-Bit-Zahlenüberlauf auftritt sowie bei einer versuchten Division durch Null. In diesen Fällen wird kein Ergebnis ausgegeben und die Operanden im X- und Y-Register bleiben unverändert.

Speicherregister

Neben den Stackregistern stehen weitere sieben Register zur Verfügung: die Speicherregister M0 ... M5 sowie das R-Register. Diese können verwendet werden, um Zwischenergebnisse bei längeren Rechnungen außerhalb des Stacks zu speichern. Ihre Inhalte werden beim Löschen des Stacks mit <CLR> nicht verändert. Dem R-Register kommt im Zusammenhang mit der Division eine besondere Bedeutung zu. Folgende Kommandos können für den Zugriff auf die Speichregister verwendet werden.

Sn
Speichern:

Der Inhalt des X-Registers wird in eines der Speicherregister übertragen (n = 0...5 oder R). Der vorherige Inhalt des Speicherregisters wird überschrieben, während das X-Register unverändert bleibt.

 

Rn
Speichern:

Der Inhalt eines der Speicherregister (n = 0...5 oder R) wird in das X-Register übertragen. Der vorherige Inhalt des X-Registers wird überschrieben, der Inhalt des Speicherregisters bleibt erhalten.

 

M
Anzeige der Speicherregister:

Die Anzeige wechselt von der Darstellung der Stackregister zur Darstellung der Speicherregister. In diesem Zustand können keine weiteren Kommandos ausgeführt werden. Jede Tastenbetätigung führt zurück zur Anzeige des Stacks.

Zahlenformate

Numerische Werte werden zur Anzeige als vorzeichelose 16-Bit-Zahlen interpretiert. Der Betrag von negativen Zahlen im Zweierkomplement kann im X-Register mit dem Kommando '~' zur Anzeige gebracht werden. Die Darstellung der Registerinhalte erfolgt in einem von fünf Zahlenformaten. Die Umschaltung zwischen den einzelnen Formaten wird durch Betätigung von <ESC> eingeleitet. Danach folgt der erste Buchstabe des gewünschten Formats:

<ESC>H Hexadezimales Zahlenformat:	0000 ... FFFF
<ESC>D Dezimales Zahlenformat:	00000 ... 65535
<ESC>O Oktales Zahlenformat:	000000 ... 177777
<ESC>B Binäres Zahlenformat:	00000000 ... 11111111 Es werden nur die niederwertigen 8 Bit der Reigisterinhalte angezeigt. Die Eingabe ist auf 8 Bit beschränkt.
<ESC>C Zeichenformat:	Die niederwertigen 7 Bit der Registerinhalte werden als ASCII-Zeichen interpretiert. Steuerzeichen wird ein '^' vorangestellt (z.B. erscheint 03h als '^C'). Alle Zeichen, die in HPKC keine Kommandofunktion besitzen, können in diesem Format direkt eingegeben werden. Zeichen mit Kommandofunktion (z. B. 'L', '/', '=', <CLR> usw.) können durch vorheriges Betätigen von <ESC> eingegeben werden. Die Zeichen 'H', 'D', 'O', 'B' und 'C' können im Zeichenformat nicht eingegeben werden.

 

Zahleneingabe

Die Betätigung von <RET> ist nur erforderlich, um zwei oder mehr Zahlen bei der Eingabe voneinander zu trennen. Die Eingabe der letzten Zahl vor einer numerischen oder Stackfunktion darf nicht mit <RET> abgeschlossen werden, da das Eingaberegister mit dem X-Register identisch ist. Anderenfalls kommt es zu einer ungewollten Verschiebung des Stacks.

In Abhängigkeit vom eingestellten Zahlenformat wird bei der Zahleneingabe eine maximale Anzahl von Ziffern akzeptiert. Wird diese Anzahl überschritten, werden die führenden Ziffern abgeschnitten. Trotzdem auftretende Zahlenbereichsüberschreitungen werden bei der Konvertierung in die interne Darstellung "modulo FFFFh" reduziert.

Bei der Zahleneingabe kann die Backspace-Taste <CUL> zum Löschen der jeweils letzten Ziffer verwendet werden. In allen anderen Fällen wird das X-Register mit <CUL> vollständig gelöscht.

Verlassen des Calculators

Durch Betätigung von <BRK> kann der Calculator verlassen werden. Der ursprüngliche Bildschirminhalt wird daraufhin wiederhergestellt und die Bedienung des Programms im D004 fortgesetzt.

Beispiele

Die folgenden Beispiele sollen einige der Möglichkeiten von HPKC illustrieren.

1. Wieviel ist (122+31)*8 ?
   Tasten: <ESC>D 122 <RET> 31 + 8 *
   Ergebnis: D>01224
   
   
2. Wieviele 128-Byte-Records finden zwischen den Adressen D000h und E100h Platz ?
   Tasten: <ESC>H E100 <RET> D000 - <ESC>D 128 /
   Ergebnis: D> 00034 (E100h-D000h)/128d
   
   
3. Welches Zeichen ergibt 'w' AND 5Fh ?
   Tasten: <ESC>C w <ESC>H 5F & <ESC>C
   Ergebnis: C> W
   
   
4. Wie sieht -115 in Binärdarstellung aus ?
   Tasten: <ESC>D 115 ~ <ESC>B
   Ergebnis: B> 10001101
   
   
5. Wieviel ist 5 hoch 4 ?
   Tasten: <ESC>D 5 <RET> 4 ^
   Ergebnis: D> 00625
   
   
6. Wieviel ist 6+7+8+9 ?
   Tasten: 6 <RET> 7 <RET> 8 <RET> 9 + + +
   Ergebnis: H> 001E

Programmsteuerung

Zur Verwaltung von HPKC im "CAOS-Fenster" besitzt der Calculator eine spezielle Programmsteuerung. Anwendern des Druckermanagers DRUCK.COM (KC-News 4/94) ist diese Steuerung bereits bekannt. Mittels <HOME> gelangt man in ein Menu, in dem das Programm HPKC deaktiviert werden kann oder zum vorhergehenden verzweigt wird. Nach dem Deaktivieren führt der erneute Aufruf über <SHIFT>-<CLR> nicht mehr zum Calculator (das ist erst wieder nach Aufruf der COM-Datei möglich), sondern zu dem ursprünglich über diese Tastenkombination zu erreichenden Programm. Ein solches Programm läßt sich auch direkt und ohne Deaktivierung von HPKC als 'ursprüngliches' aufrufen.

Wenn also zunächst DRUCK.COM und danach HPKC.COM gestartet wurde, gelangt man über das Programmsteuer-Menu von HPKC unter dem Punkt 'ursprüngliches' in den Druckermanager oder umgekehrt, wenn zunächst HPKC.COM und danach DRUCK.COM gestartet wurde.

Mit <CUL> oder <CUL> in der obersten Zeile der Programmsteuerung gelangt man zurück zur zugehörigen Anwendung, in diesem Fall also zum Calculator. Mit <RET> läßt sich die Anwendung vom Programmsteuer-Menu aus direkt beenden.

Wegen der anderweitigen Verwendung bestimmter Tasten in HPKC ist die Programmsteuerung des Calculators nicht vollständig mit der des Druckermanagers identisch. Bezüglich dieser Erscheinung sei aber auf den folgenden Ausblick verwiesen. Ein anderes Problem bringt die nur einfache Verkettung der Programme DRUCK und HPKC mit sich. Wird das zuerst geladene Programm mittels seiner Programmsteuerung deaktiviert, ist danach auch das zweite - und alle weiteren - nicht mehr über <SHIFT>-<CLR> erreichbar.

Ausblick

Die beiden Programme DRUCK und HPKC haben nicht nur äußerlich viele Gemeinsamkeiten, auch was den Programmcode im Grundgerät betrifft, sind einige identische Teile zu finden. Beide Programme sind aber völlig selbstständig und sollen es auch in Zukunft bleiben. Was aber unbedingt vermieden werden soll, sind identische Programmteile im eng begrenzten Speicher des Grundgerätes. Die Lösung des Problems wäre eine dynamische Speicherverwaltung, die zusätzlich sicherstellt, daß Routinen des einen Programms auch von anderen Programmen aufgerufen werden können und eine solche Code-Bibliothek nur einmal, nämlich bei Aktivierung des ersten Programms, ins Grundgerät geladen wird. Dann ist auch eine zentrale Programmsteuerung denkbar, die die oben beschriebenen Effekte beseitigt.

Für ein solches Speichermanagement im Grundgerät gibt es bei einigen Programmierern bereits konkrete Vorstellungen (siehe Artikel in dieser Ausgabe) und es ist zu erwarten, daß sich hier bald eine Einigung ergibt, aus der ein neuer Standard wird, an den sich dann hoffentlich viele KC-Anwender orientieren werden.

Programmieren mit der SYSLIB 2

oder: Wie man einen PRL-Linker bastelt

von Jörg Linder

Was macht ein Redakteur der KC-News, wenn er nicht gerade an einer neuen Ausgabe werkelt? Er denkt sich neue Standards aus und quält überdies auch noch unschuldige Assembler. So geschehen in den letzten Wochen in einer Kleinstadt namens Seelow. Im Artikel "Neue Speicherverwaltung ..." habe ich behauptet, daß es ganz einfach sei, eine PRL-Datei auf eine bestimmte Basisadresse zu linken. Hier nun der Beweis:

Bevor ich näher auf den Quelltext eingehe, noch ein paar Bemerkungen zum Format der PRL-Dateien. Der Header ist recht übersichtlich aufgebaut, denn ca. 99,22 % sind mit Nullbytes gefüllt. Für sämtliche Berechnungen stehen nur drei Größen zur Verfügung. Dies sind die Länge des Codes (im Header gespeichert), der orginale Offset des Codes von 0100h und der Beginn des Codes in der PRL-Datei (nach dem Header von 256 Bytes Länge).

Vorbemerkungen

Um nicht das berühmte Fahrrad ein zweites Mal zu erfinden, habe ich mich vor allem bei der Dateiarbeit auf die Routinen der SYSLIB verlassen. Diese sind langjährig erprobt und liefern (im Gegensatz zu meinen Programmierversuchen) garantiert die definierten Funktionen. Eine Besonderheit stellt der externe Bezug $MEMRY dar. Dabei handelt es sich nicht um eine Routine, sondern um ein spezielles Symbol, das der Linker mit der Adresse des ersten freien Bytes nach dem gelinkten Code belegt.

Da ich beim Programmieren nicht wissen kann, wie groß das Programm letztendlich wird (zumal einige SYSLIB-Routinen hinzukommen) habe ich zwei Möglichkeiten, die Adresse zum Laden der PRL-Datei festzulegen. Zum einen könnte ich eine ausreichend hohe Adresse (z. B. 1000 h) annehmen und die Datei dorthin laden. Zum anderen ließe sich durch einen ersten Assembler-/Linkerlauf die endgültige Größe des Programms feststellen und eine darauffolgende freie Adresse beim zweiten Lauf verwenden.

Wenn anschließend nochmal der Quelltext überarbeitet werden muß (wie das bei mir fast immer der Fall ist), kann jedoch für beide geschilderten Möglichkeiten nicht mehr garantiert werden, daß die Adresse noch zulässig ist. Warum sollte also nicht einfach der Linker diese Berechnung für mich übernehmen? Mit $MEMRY tut er das. Will man im Programm auf diese Adresse zugreifen, geht dies z. B. über LD HL,($MEMRY).

So, bevor es richtig losgeht, kann man sich noch zwischen einer deutschen und einer englischen Version entscheiden. Dank .ACCEPT-Anweisung können SLR-Besitzer dies während des Assemblerlaufs tun. Alle anderen müssen im Quelltext das Symbol "German" dementsprechend setzen. Ansonsten kann die Quelldatei unberührt bleiben. Übrigens habe ich zwei Versionen auf die Beilagen-Diskette kopiert, um fehlerfreies Arbeiten mit weniger intelligenten Assemblern und Linkern zu ermöglichen.

Mit folgenden Kommandozeilen wird die ausführbare .COM-Datei erzeugt:

ASM/M80 und LINK/L80

ASM PRL11=PRL11
LINK /P:100,PRL11,SYSLIB/S,PRLLNK11/N/E

SLR180 und SLRNK+

SLR180 PRL11/R
SLRNK+ /A:100,/J,PRL11,SYSLIBS/S,PRLLNK11/N/E

Aufbau des Programms

Der Quelltext ist recht linear aufgebaut. Ein kurzer Überblick ist daher schnell gegeben. Nach ein paar einleitenden Maßnahmen (Stack retten, Parameter prüfen) wird die eingegebene Basis-/Endadresse vom FCB2 geholt und in einer Arbeitszelle gespeichert. Diese Aktion muß unbedingt vor der ersten Dateioperation mit dem FCB1 durchgeführt werden, weil dabei die Daten des FCB2 überschrieben werden.

Anschließend wird versucht, die angegebene Datei (auf FCB1) zu öffnen. Schlug dies fehl, wird der standardmäßige Dateityp "PRL" eingesetzt und ein erneuter Versuch gestartet. Die Datei wird sektorweise in den DMA-Puffer gelesen und von dort auf die durch $MEMRY bezeichnete Adresse umkopiert. Nun geht's mit dem eigentlichen Linkvorgang los.

In Abhängigkeit von der Größe des Codes in der PRL-Datei und der gewählten Basis- oder Endadresse wird der Offset berechnet. Dies ist der wichtigste Schritt für ein fehlerfreies Resultat. Dabei muß unbedingt beachtet werden, daß der Code in der PRL-Datei bereits einen originalen Offset von 0100h hat und nur auf den Beginn einer Page gelinkt werden kann. Zur Kontrolle werden die berechneten Adressen auf den Bildschirm ausgegeben.

Sind die Zeiger (engl. Pointer) korrekt geladen, tritt die kurze Routine zum Relozieren in Aktion. Danach wird die Zieldatei mit dem Dateityp "CIM" sektorweise umkopiert und geschrieben. Sollte sie schon existieren, hat der Anwender die Möglichkeit, sie zu überschreiben. Danach wird der Stack wiederhergestellt und das Programm ohne Warmstart verlassen. Fertig!

Besonderheiten

Das war natürlich der fehlerfreie Weg. Anhand der möglichen Meldungen kann man erkennen, daß eine Vielzahl von Fehlern erkannt und angezeigt werden. In solch einem Fall wird das Programm nach der Bildschirmausgabe beendet. Zum größten Teil werden die Fehler übrigens von den SYSLIB-Routinen erkannt.

Die Fehlerbehandlung bzw. die Zeichenkettenausgabe soll noch etwas näher beleuchtet werden. Ich habe mich für die Adressierung der Zeichenketten über eine Tabelle entschieden. Dies ermöglicht den schnellen Zugriff auf unterschiedliche lange Meldungen, die trotzdem nahtlos aneinandergereiht im Programm stehen. Sofern der zur Verfügung stehende Platz nicht überschritten wird, können sie sogar im fertigen Programm frei editiert und angepaßt werden. Es muß anschließend nur die Tabelle überarbeitet werden.

Und so funktioniert die Subroutine: Anhand der im Register A übergebenen Nummer (Hexzahl) wird in der Tabelle nachgeschaut, wo sich die Zeichenkette befindet. Das Registerpaar DE wird mit der Adresse geladen und die entsprechende Routine des BDOS aufgerufen. Weil die Subroutine auch in anderen Teilen des Programms benötigt wird und dort keine Register verändern darf, werden über PUSH die Register gerettet und nach Ausführung mit POP wiederhergestellt.

Die paar Zeilen für das Relozieren sind kaum der Rede wert. Als Zeiger auf die Codebytes und die Bit Map werden die Registerpaare HL und DE benutzt. BC beherbergt indes die Länge des Codes (aus dem Header entnommen). Leider kann diese Zahl nicht ohne weiteres verwendet werden. Zunächst wird sie durch 8 geteilt und der Rest gespeichert, denn ein Byte hat genau 8 Bits - Codebytes und Bit Map - alles klar?

Für das Relozieren werden nun die Bytes der Bit Map sozusagen Bit für Bit untersucht und je nach Zustand (0 oder 1) der Offset zum dazugehörigen Codebyte addiert. Dies erledigt die Subroutine RELOZI, die entsprechend der Zahl im Registerpaar BC aufgerufen wird. Danach muß nur noch der Rest abgearbeitet werden. Dazu wird ebenfalls die Subroutine RELOZI verwendet.

Nutzen

Äh, ja, wozu taugt der PRL-Linker eigentlich? Zuallererst einmal zeige ich damit, daß ich die Hoffnung nicht aufgegeben habe und vielleicht doch jemanden zum Programmieren mit der SYSLIB anstiften kann. Eventuell bastelt auch momentan ein anderer Club an einem neuen System und kann den Linker dabei gebrauchen...

Doch eigentlich war es für mich nur wichtig, hiermit zu demonstrieren, daß man mit einer Handvoll Bytes die Basisadresse von PRL-Dateien festlegen kann. Von dieser Seite sollte es also für das neue Speichermanagement des Grundgeräte-RAMs kein Problem mehr geben. Sobald wir einen Standard festgelegt haben und ZAS entsprechend erweitert wurde, kann aus dem PRL-Linker ein einfaches Ladeprogramm entwickelt werden. Man könnte sogar eine Routine analog denen der SYSLIB ableiten und somit für jeden Programmierer zugänglich machen.

Jetzt haben der Assembler, die SYSLIB und natürlich auch Ihr erstmal Ruhe vor mir! Doch wer weiß, womöglich fällt mir wieder etwas ein ...

Alles über Sysops

(oder wer will eine Mailbox aufmachen)

Was ist ein Sysop?

Ein Sysop ist der, der immer alle Fragen der User beantworten muß. Manchmal hat er auch Ahnung von Software und kann eine Mailbox installieren.

 

Wie alt sollte ein Sysop sein?

Am besten um die 16 Jahre. Er ist jung, frisch und dynamisch. Hat immer einen coolen Spruch auf den Lippen und kann vom Staatsanwalt kaum verklagt werden.

 

Wie sieht ein Sysop aus?

Ein richtiger Sysop hat Übergewicht. Er sitzt pausenlos am Rechner, trinkt Bier und raucht Camel. Die Camel nützt ihm aber nichts bei seinem Gewichtsproblem, denn er ißt Schokoriegel gegen seinen Heißhunger. Zum richtigen Essen hat er keine Zeit.

 

Viele Sysops haben eine Glatze oder graue Haare. Warum? Weil das Gewichtsproblem den Stoffwechsel stört und die Haare ausfallen läßt. Die grauen Haare kommen vom täglichen Schreck, daß die Box wieder abgeranzt ist.

 

Sysops sind sportlich, denn sie können die Entfernung zwischen Rechner und Bett oder Rechner und Kühlschrank zurücklegen, ohne außer Atem zu kommen.

 

Fast alle Sysops tragen eine Brille, weil die Netzhaut durch das ewige Monitorgeflimmer schon milchig ist und nur noch Frequenzen über 70 Hz wahrgenommen werden.

 

Sysops haben einen ausgezeichneten Tastsinn. Sie finden die Zigarettenschachtel und die Bierflasche auch bei Monitorbeleuchtung.

 

Sysops hören sehr gut. Sie erkennen trotz ausgeschaltetem Modemlautsprecher, ob ein Connect zustande kommt oder nicht.

 

Sysops sind sehr musikalisch. Sie können eine 2400er und einen HST-Carrier täuschend nachahmen.

 

Wo findet man Sysops?

Sysops treten nie in Rudeln auf. Meist haben sie ihre eigene Meute (User genannt). Sysops sind fast nur Männchen und können sich deshalb nur ungeschlechtlich vermehren.

 

Sysops findet man überall im täglichen Leben. Meistens in Kneipen oder auf Usertreffen (die sie dummerweise wegen der Trägheit ihrer Meute selber organisieren müssen).

 

Sysops findet man in der Öffentlichkeit immer in der Nähe von Computerläden, wo sie ihre Hardware auffrischen. Meist umgeben von dem treuesten Teil ihrer Meute.

 

Woran erkennt man einen Sysop noch?

Er kann fließend eine Fremdsprache, die keiner (außer einem Teil seiner Meute und andere Sysops) versteht. Beispiel: "Mein letzter Poll beim NC lief wieder mal auf einen V32bis-Connect hinaus, weil sein Trailblazer kein DTR-Low-Signal verstanden hat!"

 

Sysops können teilweise programmieren. Meist beschränken sich ihre Kenntnisse aber auf den Videorecorder und die Waschmaschine.

Ähnlichkeiten mit bekannten Sysops sind rein zufällig und entsprechen nicht der Realität ;-)))

Aus dem Fidonet (Autor unbekannt), gesehen in der SCUG Clubzeitung 1/92