Andreß Freystatzky

Anleitung und Dokumentation zu

CASTOR und POLLUX 0.96

ALLGEMEINES

Was machen CASTOR und POLLUX?

Das Duo CASTOR und POLLUX stellt einem Schneider/Amstrad JOYCE die Laufwerke eines PC zur Verfügung. Beliebige Verzeichnisse auf den Laufwerken des PC werden auf dem JOYCE unter verschiedenen, frei wählbaren, Laufwerksbuchstaben zugänglich gemacht. Die Zuordnung von Laufwerksbuchstaben des JOYCE zu PC-Verzeichnissen kann zur Laufzeit beliebig geändert werden.

CASTOR und POLLUX liegen zur Zeit in der Version 0.96 vor. Die Versionsnummer deutet schon an, dass es sich noch um ein Programmpaket im Versuchsstadium handelt. Die Grundfunktionen laufen schon recht stabil, die Geschwindigkeit ist (im Rahmen des auf der seriellen Schnittstelle möglichen) recht brauchbar, aber einige spezielle CP/M-Funktionen sind bisher nur rudimentär implementiert.

Hardwarevoraussetzungen

Ein Schneider/Amstrad JOYCE, beliebiges Modell. (Bei mir ein PCW 8256 mit 512 kByte RAM, 3" und 5 1/4" Laufwerk)

Eine CPS 8256 kompatible serielle Schnittstelle für den JOYCE. (Bei mir eine CPS 8256 serielle/parallele Schnittstelle) Dazu ein Standard Nullmodemkabel. (Steckerbelegung siehe unten)

Alternativ dazu eine Selbstbauschnittstelle auf Basis einer 8255 PIO und ein 25-poliges Kabel.

Ein beliebiger (IBM-kompatibler) PC. An die Ausstattung des PC werden keine besonderen Anforderungen gestellt. 512 kByte RAM, beliebige Grafikkarte. Eine Festplatte wäre nett. Natürlich muss eine freie serielle bzw. parallele Schnittstelle vorhanden sein.

Softwarevoraussetzungen

CASTOR und POLLUX setzen keine spezielle Software voraus.

Auf dem JOYCE benötigt CASTOR CP/M plus, unter LocoScript arbeitet es leider nicht.

Auf dem PC wird DOS in einer halbwegs aktuellen Version (ab 3.0) voraus- gesetzt. Tests in den DOS-Boxen anderer Betriebssysteme (WIN, OS/2, Linux) habe ich nicht durchgeführt. Sofern dort der Zugriff auf die Register der seriellen bzw. parallelen Schnittstelle möglich ist, sollte es aber keine größeren Probleme geben. Allerdings möchte ich darauf hinweisen, dass POLLUX ständig aktiv die Tastatur und die Schnittstelle pollt. Von einer recht ansehnlichen Systembelastung ist also auszugehen.

Programmaufruf

Um die PC-Laufwerke vom JOYCE aus nutzen zu können sind zwei Programm- aufrufe nötig.

Auf dem JOYCE muss CASTOR gestartet werden.

A:CASTOR

Durch diesen Aufruf wird eine RSX im RAM des JOYCE installiert. Diese RSX versucht eine Verbindung zu POLLUX auf dem PC aufzunehmen. Auch wenn der PC sich nicht meldet, wird die normale Arbeit am JOYCE nicht beeinträchtigt.

Damit der PC antwortet, muss dort POLLUX gestartet werden.

C:\>POLLUX

POLLUX versucht nur ebenfalls eine Verbindung zum JOYCE aufzubauen. Nach erfolgtem Verbindungsaufbau stehen die Laufwerke des PC für den JOYCE zur Verfügung. Da POLLUX ein normales Programm ist, belegt es den PC mit Beschlag.

Ob zuerst CASTOR oder zuerst POLLUX aufgerufen wird, ist übrigens irrelevant. Auch einen Programmabbruch oder gar Neustart eines der Rechner überstehen CASTOR und POLLUX normalerweise ohne größere Probleme.

DIE SOFTWARE AUF DEM PC

Die Arbeitsweise von POLLUX

POLLUX belegt den PC nach seinem Aufruf mit Beschlag. Während es aktiv ist, steht der PC nicht für andere Aufgaben zur Verfügung.

POLLUX kennt keine Kommandozeilenparameter, kann aber über eine Konfigura- tionsdatei eingestellt werden.

Das Programm kann jederzeit durch Druck auf eine beliebige Taste (außer RETURN) verlassen werden. Wenn gerade größere Datenmengen zum JOYCE übertragen werden, kann die Reaktion ein paar Sekunden auf sich warten lassen.

Die Konfigurationsdatei POLLUX.CFG

Da nicht zu erwarten ist, dass die Grundeinstellungen von POLLUX bei allen Anwendern gleich sind, können diese über die Datei POLLUX.CFG eingestellt werden. Vor allem die Zuweisung von CP/M-Laufwerken zu DOS-Pfaden und die Einstellung der seriellen oder parallelen Schnittstelle werden sich sicher von Anwender zu Anwender unterscheiden.

Damit POLLUX.EXE seine Konfigurationsdatei auch findet müssen sich beide im selben Verzeichnis befinden.

POLLUX.CFG ist eine reine Textdatei (ASCII) die mit einem beliebigen Editor erstellt werden kann. Die Form der Datei und der einzelnen Einträge ist recht unkritisch.

Alle Zeilen die kein Gleichheitszeichen enthalten werden als Kommentarzeilen betrachtet und schlichtweg ignoriert.

Für POLLUX relevante Zeilen enthalten einen Bezeichner, ein Gleichheitszeichen und rechts davon den Wert des Bezeichners. Also etwa

NAME = WERT

Leerzeichen am Zeilenanfang, vor und nach dem Gleichheitszeichen und am Zeilenende dürfen beliebig eingesetzt werden und werden ignoriert. Zwischen Groß- und Kleinschreibung wird nicht unterschieden. Bei Wahrheitswerten und Alternativen (z.B. Parität) ist nur der erste Buchstabe rechts vom Gleichheitszeichen relevant. Bei Wahrheitswerten werden J, Y, T, + und 1 als TRUE sowie N, F, - und 0 als FALSE gewertet, bei allen anderen Zeichen wird der Vorgabewert benutzt.

Ein in POLLUX.CFG fehlender Bezeichner nimmt seinen Standardwert an. Fehlt POLLUX.CFG ganz, dann nehmen alle Bezeichner ihre Standardwerte an. Treffen die Daten der Standardkonfiguration auf ihre Umgebung zu, dann können sie also auf POLLUX.CFG verzichten.

Nachfolgend sind alle von POLLUX ausgewerteten Bezeichner mit einer beispielhaften Zeile aufgeführt. Der Eintrag rechts vom Gleichheitszeichen in den Beispielen stellt den Standardwert dar.

UserName =

Hier können sie ihren Namen (Vor- und Nachnamen) eintragen. Er wird dann zum Programmstart ausgegeben.

UserStrasse =

Hier können sie die Straße in der sie wohnen eintragen. Sie wird eben- falls zum Programmstart ausgegeben.

UserOrt =

Selbiges für ihren Wohnort, eventuell mit Postleitzahl. Straße und Wohnort werden, außer der Anzeige auf dem Bildschirm, von POLLUX in keiner Weise benutzt oder ausgewertet. Sie stellen nur eine kleinere Spielerei dar die ich irgendwann einmal eingebaut habe.

RegCode = 0

Den Unsinn mit der Warteschleife am Programmanfang und -ende habe ich inzwischen herausgenommen. RegCode ist also jetzt völlig überflüssig. POLLUX war nur ein willkommenes Opfer um die entsprechenden Routinen einmal auszuprobieren.

Port = COM

Hier tragen sie ein, über welche Art von Schnittstelle Joyce und PC verbunden sind. Über die serielle Schnittstelle 'COM' oder über die parallelel Schnittstelle 'LPT'.

LptNummer = 2

Die Nummer der benutzten parallelen Schnittstelle. Erlaubt sind die Werte eins bis vier. Belegt die Schnittstelle eine Adresse außerhalb des Standards, dann ist hier eine Null einzutragen. In diesem, und nur in diesem, Fall wird der unter LptAdresse eingetragene Wert benutzt.

Diese und die folgende Angabe sind natürlich nur relevant, wenn unter Port der Wert 'LPT' eingetragen ist.

LptAdresse = $278

Entspricht die Adresse ihrer parallelen Schnittstelle nicht dem Standard, dann müssen sie diese hier angeben. Damit dieser Wert von POLLUX benutzt wird, muss LptNummer gleich Null sein.

ComNummer = 1

Die Nummer der benutzten seriellen Schnittstelle. Erlaubt sind die Werte von eins bis vier. Benutzen sie eine ungewöhnliche Adresse und/oder einen ungewöhnlichen Interrupt, dann tragen sie hier eine Null ein. In diesem Fall, und nur in diesem Fall, werden die Angaben unter ComAdresse und ComIRQ benutzt.

Die Angaben zur seriellen Schnittstelle sind natürlich nur relevant, wenn bei Port der Wert 'COM' eingetragen ist.

ComAdresse = $3F8

Entspricht die Adresse ihrer seriellen Schnittstelle nicht dem Standard, dann müssen sie diese hier angeben. Damit dieser Wert von POLLUX benutzt wird, muss ComNummer gleich Null sein.

ComIRQ = 4

Entspricht die Interruptnummer (richtiger: IRQ-Nummer) ihrer seriellen Schnittstelle nicht dem Standard, dann müssen sie diese hier angeben. Damit dieser Wert von POLLUX benutzt wird, muss ComNummer gleich Null sein. ComNummer und ComIRQ sollten immer zusammen angegeben werden.

BaudRate = 14400

Die Baudrate der seriellen Schnittstelle. Vorgabewert ist hier die momentan von CASTOR und POLLUX maximal erreichbare Baudrate. Höhere Werte führen zu Fehlern oder werden schlichtweg ignoriert. Sollten sie mit diesem Wert Probleme haben, dann können sie es mit einem niedrigeren Wert probieren. ACHTUNG: eine Änderung der Baudrate muss auch in CASTOR auf dem JOYCE aktiviert werden.

Folgende Baudratenwerte sind zulässig:

14400     12800     11520     10473     9600

Alle anderen Werte führen zu einer Baudrate von 14400 Baud

DatenBits = 8

Die Anzahl der Datenbits für die Übertragung. Sie kann nur der Form halber angegeben werden. Andere Werte führen mit Sicherheit zu Fehl- funktionen.

Paritaet = N

Auch dieser Eintrag ist eigentlich nur der Form halber vorhanden. Mögliche Werte sind None, Even, Odd, Mark oder Space. Ausgewertet wird nur der erste Buchstabe.

StopBits = 1

Grmmpf. Naja, selbiges wie oben. Aus rein formalen Gründen vorhanden. Ehrlich gesagt, weniger aus formalen, denn aus Bequemlichkeitsgründen. Den Programmteil, der die Einstellung der seriellen Schnittstelle vornimmt, habe ich aus einem anderen Programm übernommen. Und da Änderungen immer(!) zu Fehlern führen, habe ich halt so viel wie möglich eins zu eins übernommen.

MapNummer = 255
MapAdresse = $2F8
MapIRQ = 3
MapBaudRate = 2400
MapDatenBits = 8
MapParitaet = N
MapStopBits = 1

Die serielle Schnittstelle des JOYCE wird von CASTOR und POLLUX mit Beschlag belegt. Um sie, wenigstens auf BDOS-Ebene, dennoch nutzen zu können werden die vier die serielle Schnittstelle betreffenden BDOS- Aufrufe an den PC und dort an eine zweite serielle Schnittstelle weitergeleitet.

Die für die umgelenkte Schnittstelle eingestellten Parameter dürfen sich durchaus von den Daten der Verbindung JOYCE-PC unterscheiden. Die einzelnen Werte werden analog zu den Daten der Verbindung JOYCE-PC eingestellt.

Wird in MapNummer eine Zahl größer als vier eingegeben, dann ist die Umleitung der seriellen Schnittstelle deaktiviert. Die anderen Map-Einträge sind dann irrelevant.

Die Umlenkung der seriellen Schnittstelle auf den PC ist auch beim Einsatz der parallelen Version von CASTOR und POLLUX wirksam.

MaxRetry = 5

Hin und wieder kommt es leider vor, dass ein Datenblock im ersten Anlauf nicht richtig übertragen wird. Dies kann durch Störungen auf der Leitung, häufiger aber durch Interrupts auf dem PC oder JOYCE, verursacht sein. CASTOR und POLLUX wiederholen die Übertragung in diesem Fall bis zu 'MaxRetry' mal, bevor sie aufgeben und die Verbindung abbrechen.

Der angegebene Wert betrifft nur die Anzahl der vom PC ausgelösten Wiederholungsversuche. Für die vom JOYCE ausgelösten Wiederholungen ist er irrelevant.

A:=
...
P:=

CP/M kennt die Laufwerke A: bis P:. Jedem dieser Laufwerke kann ein Verzeichnis auf einem beliebigen PC-Laufwerk zugeordnet werden. Steht rechts vom Gleichheitszeichen nichts, dann wird das Originallaufwerk des JOYCE benutzt.

Wollen sie ein Laufwerk schon beim Start von POLLUX auf einen bestimmten Pfad des PC umleiten, dann muss dieser Pfad eingetragen werden. Wollen sie z.B. über N: auf den Pfad C:\DOS des PC zugreifen, dann tragen sie einfach

N:=C:\DOS\

in die POLLUX.CFG ein.

ChangeCfg = FALSE

Während sie mit CASTOR und POLLUX arbeiten werden sie eventuell neue Zuweisungen von CP/M-Laufwerken zu PC-Pfaden treffen. Diese gehen normalerweise mit Programmende von POLLUX verloren.

Setzen sie ChangeCfg auf TRUE, dann werden diese Änderungen automatisch in die POLLUX.CFG eingetragen und stehen beim nächsten Programmstart sofort zur Verfügung.

Vorgabe ist FALSE, so dass die einmal in POLLUX.CFG eingetragene Pfadzu- weisung bei jedem Programmstart wieder unverändert zur Verfügung steht.

Protokoll = FALSE

Legt fest, ob die gemeldeten BDOS-Aufrufe des JOYCE auf dem Bildschirm protokolliert werden sollen. Diese Option hat mir beim Aufspüren von Fehlern sehr geholfen. Man kann sich aber auch einfach mal ansehen, was z.B. PIP alles aufruft wenn es eine Datei kopiert.

ProtokollDatei =

Der Name einer Datei in der das Verbindungsprotokoll festgehalten wird. Ist kein Dateiname angegeben, dann wird auch keine Protokolldatei geführt. Ist ein Dateiname angegeben, dann wird die Datei auch dann geführt, wenn 'Protokoll' auf FALSE steht. Auch diese Option wird Otto Normalverbraucher höchst selten benötigen. Eingeführt habe ich sie, um einige Fehler einzukreisen.

TickSound = FALSE

Da bei mir der JOYCE und der PC zur Zeit einige Meter voneinander entfernt stehen, kann ich vom JOYCE aus nur schlecht auf den Bildschirm des PC gucken. Ist TickSound gesetzt, dann gibt der PC bei jedem BDOS- Aufruf und bei jeweils 256 übertragenen Datenbytes einen kurzen Laut von sich. Außerdem produziert er ein langsames Ticken wenn er auf eine (Re-) Synchronisation mit dem JOYCE wartet. Das machte es mir bei Änderungen wesentlich leichter gelegentliche Abstürze zu erkennen. Im normalen Betrieb ist das Geknatter jedoch eher nervig. Aber, wer's mag kann TickSound gerne auf TRUE setzen.

SetTime = TRUE

POLLUX setzt, was bis zur Version 0.94 undokumentiert war, die Uhrzeit des JOYCE auf die Uhrzeit des PC. Ist dies nicht gewünscht kann dieses Verhalten jetzt auch abgeschaltet werden.

Statistik = FALSE L

egt fest, ob POLLUX bei Programmende die Zahl der übertragenen Bytes anzeigt. Das dient beim Anwender nur der Befriedigung der Neugierde. Mir half es dabei, den Verwaltungsoverhead etwas zu reduzieren.

Es gibt noch ein paar weitere mögliche Eintragungen in die CFG-Datei, diese dienen aber wirklich nur Debuggingzwecken. Ich möchte sie hier nicht im einzelnen beschreiben. Zum Einen sind sie für die Benutzung von POLLUX völlig irrelevant, zum Anderen können sie in folgenden Versionen einfach wieder wegfallen.

SOFTWARE AUF DEM JOYCE

Die Arbeitsweise von CASTOR

CASTOR installiert bei seinem Aufruf eine RSX im RAM des JOYCE. Sollte bereits eine Kopie der RSX im Speicher vorliegen, so wird dies erkannt und auf eine erneute Installation verzichtet.

Einige Optionen von CASTOR können per Kommandozeilenparameter gesteuert werden. Wird CASTOR ohne Parameter aufgerufen, dann wird das Programm sofort nach der Installation der RSX wieder verlassen.

Der Anwender merkt im ersten Moment nichts von der Anwesenheit der RSX. Der JOYCE funktioniert weiter wie gewohnt. Der einzige Unterschied ist, dass ihm jetzt (sofern sie in der POLLUX.CFG eingetragen sind und die Verbindung zum PC steht) einige neue Laufwerke zur Verfügung stehen. Diese Laufwerke können wie jedes echte Laufwerk des JOYCE benutzt werden. Dateien können gelesen, geschrieben, kopiert oder gelöscht werden.

Ein paar kleine Haken sind allerdings dabei. Die Dateien auf diesen zusätzlichen Laufwerken tauchen unter allen Usernummern auf. Hier könnte man ansetzen, um POLLUX noch ein wenig aufzubohren, so dass unter den 16 möglichen Usernummern eines Laufwerks 16 verschiedene DOS-Pfade zugänglich gemacht werden.

Auch einige der Tools die direkt in den Sektoren der Laufwerke rumwühlen verweigern ihren Dienst. Generelle Abhilfe wäre hier nur mit unverhältnis- mäßig hohem Aufwand möglich. Einzelne sich daraus ergebende Unzulänglichkeiten kann man aber vielleicht mit ein paar Änderungen in POLLUX korrigieren.

Falls die Verbindung zum PC im laufenden Programm verloren geht, stehen diesem die zusätzlichen Laufwerke nicht mehr zur Verfügung. Die ersten Versionen der RSX versuchten dann sofort eine neue Verbindung aufzubauen. Das führte dazu, dass auch der Zugriff auf die lokalen Laufwerke unerträglich langsam wurde. Der Aufruf von CASTOR /X um die RSX aus dem Speicher zu schmeißen dauerte dann länger als ein Neustart des Rechners. Jetzt versucht sich die RSX nur noch dann am Neuaufbau der Verbindung wenn der Rechner sowieso auf einen Tastendruck wartet. Das ist z.B. am Kommandoprompt der Fall. Wird eine Taste gedrückt, dann bricht die RSX ihren Synchronisationsversuch ab, so dass der Anwender keine Verzögerung bemerkt.

In einigen Programmen ist ein Neuaufbau einer verlorenen Verbindung zum PC dadurch leider nicht mehr möglich. In diesen, hoffentlich seltenen, Fällen muss das entsprechende Programm verlassen und neu gestartet werden falls es auf Daten von den PC-Laufwerken angewiesen ist.

Die Kommandozeilenparameter von CASTOR

Ein Aufruf von CASTOR ohne Parameter installiert die RSX und baut die Verbindung zum PC auf, falls dies nicht schon geschehen ist. Um die RSX wieder entfernen zu können, die Verbindung neu zu synchronisieren oder sich einfach die aktuelle Laufwerkszuordnung anzusehen, muss man CASTOR mit Parametern aufrufen.

Für einige der Optionen stehen mehrere Abkürzungen zur Verfügung. Zum einen die Abkürzungen die auch meine DISK-RSX benutzt, zum anderen Abkürzungen die an DOS-Konventionen angelehnt sind. Weiterhin akzeptiert CASTOR auch ein einleitendes '-' statt des '/'. Wer abwechselnd mit mehreren Betriebs- systemen arbeiten muss, flucht oft genug über diese kleinen Unterschiede, also lasse ich hier halt mehrere der üblichen Schreibweisen zu.

Die Parameter im Einzelnen.

/?
/H (hilfe)

Ausgabe eines kurzen Hilfstextes über die zur Verfügung stehenden Parameter.

/I (initialisiere)

Initialisiert die RSX neu und setzt dabei unter anderem die Schnittstellenparameter neu.

<baudrate>

Wir eine Zahl als Parameter angegeben, dann initialisiert POLLUX die RSX ebenfalls neu, aber mit der angegebenen statt der Standardbaudrate. Die parallele Version ignoriert diesen Parameter.

/E (erase)
/R (remove)
/X (exit)

Deaktiviert die RSX und entfernt sie aus dem Speicher.

/A (anzeigen)
/B (belegung)
/S (show)

Zeigt die aktuelle Laufwerkszuordnung der RSX an. In jeder Zeile der Ausgabe wird der CP/M-Laufwerksbuchstabe gefolgt von einem Gleichheitszeichen und dem zugeordneten MS-DOS-Verzeichnis angezeigt. Ist kein MS-DOS-Verzeichnis angegeben, dann wird das Laufwerk nicht auf den PC umgeleitet.

d:
d:=

Eine eventuell vorhandene Zuordnung des Laufwerkes d: ('A:'..'P:') zu einem MS-DOS-Verzeichnis wird aufgehoben. Unter dem Laufwerksbuchstaben ist, sofern vorhanden, nun wieder das lokale Laufwerk des JOYCE verfügbar.

Beispiel: CASTOR D:=

d:=pfad

Dem CP/M-Laufwerk d: ('A:'..'P:') wird ein MS-DOS-Verzeichnis zugeordnet. der MS-DOS-Verzeichnisname muss zwingend eine Laufwerksbezeichnung beinhalten, sonst wird er von CASTOR zurückgewiesen. Die Angabe des '/' nach dem Doppelpunkt oder am Ende des Pfadnamens (wie von /A ausgegeben) ist nicht nötig und wird ggf. von POLLUX ergänzt. Um bei einem deutschen Bildschirmzeichensatz nicht für unnötige Verwirrung zu sorgen, benutzt CASTOR auf dem CP/M-System statt des MS-DOS-üblichen '\' das Zeichen '/'.

In diesem Zusammenhang eine Bitte: Vermeiden sie im Verzeichnisnamen, die sie vom JOYCE aus nutzen wollen, Umlaute und Sonderzeichen soweit wie möglich. CASTOR und POLLUX sind damit noch nicht getestet worden und ich kann daher für nix garantieren. Insbesondere ein 'Ö' wird von POLLUX mit Sicherheit als Backslash '\' interpretiert.

Verzeichnisse komfortabler wechseln. CD für den JOYCE.

Die in CASTOR eingebauten Möglichkeiten zum Verzeichniswechsel sind recht rudimentär. Um CASTOR nicht mit Kommandozeilenparametern, die sich sowieso kaum jemand merken kann, zu überfrachten habe ich die erweiterten Möglichkeiten zum Verzeichniswechsel in ein eigenes Programm ausgelagert.

Im Folgenden bezeichnet ein CP/M-Laufwerk (A: bis P:). steht für ein Verzeichnis auf dem DOS-Rechner, es kann auch ein voll- ständiger Pfad, eventuell mit Laufwerksangabe, sein.

CD ?

Gibt eine, allerdings recht kurze, Hilfestellung zu den möglichen Parametern auf dem Bildschirm aus.

CD <cpm>

Ist <cpm> ein auf dem PC simuliertes Laufwerk, dann werden der aktuell zugewiesene Pfad und in einer Liste alle von dort aus erreichbaren Unterverzeichnisse angezeigt. Ist <cpm> ein lokales Laufwerk des JOYCE, dann erfolgt eine entsprechende Meldung.

CD <cpm> <verzeichnis>

Verbindet das CP/M-Laufwerk <cpm> mit dem Verzeichnis <verzeichnis> auf dem PC. Ist < cpm> zum Zeitpunkt des Aufruf noch nicht mit einem DOS-Pfad verknüpft, dann muss ein vollständiger Pfad inklusive Laufwerksbuchstaben angegeben werden. Sonst reicht auch der Name eines Unterverzeichnisses. Es funktioniert also z.B. auch ein 'CD ..'. Der neue Pfad und alle von dort erreichbaren Unterverzeichnisse werden angezeigt.

CD <cpm>

Löscht die Zuordnung des CP/M-Laufwerks zu einem DOS-Pfad. Unter < cpm> ist anschließend wieder das entsprechende lokale Laufwerk zu erreichen.

Der Parameter <cpm> darf weggelassen werden, wenn der CD-Befehl sich auf das aktuelle CP/M-Laufwerk bezieht.

Auch CD akzeptiert als Trenner zwischen den Verzeichnissen den Slash '/' (Shift-7). Der Backslash '\' (Shift-Ö) darf ebenfalls benutzt werden, ist allerdings bei deutschen Zeichensatz schlecht lesbar. C:/BP/BIN sieht halt besser aus als C:ÖBPÖBIN.

Das Programm CD ist recht klein geraten. Der größte Teil der Funktionalität wird von POLLUX auf der PC-Seite bereitgestellt. Da Turbo Pascal (die CP/M Version) immer seine gesamte Laufzeitbibliothek einbindet, ist die COM- Datei dennoch ca. 10 kByte groß. Eine signifikante Verkleinerung auf geschätzt unter 1 kByte ließe sich durch eine Umsetzung in Assembler erreichen. Nach solcher Bitpfriemelei steht mir jetzt jedoch nicht der Sinn. Die, aus anderen Gründen, nötigen Änderungen der RSX haben meinen Bedarf an Assemblerprogrammierung erstmal abgedeckt.

Anmerkung: Inzwischen habe ich mich doch einmal darangesetzt CD von TurboPascal in Assembler umzusetzen. Dabei habe ich noch einige Arbeit vom JOYCE auf den PC verlagert. Herausgekommen ist eine 1k-Datei. Benutzt werden weniger als 256 Byte, wovon das meiste auch noch der Text der Fehlermeldungen ist. Aber 1kByte ist nun mal CP/Ms minimale Dateigröße.

TECHNISCHES

Die serielle Verbindung vom JOYCE zum PC

JOYCE und PC sind über die serielle Schnittstelle mit einem sogenannten Nullmodemkabel verbunden. Nullmodem heißt es deshalb, weil zwischen den Rechner halt kein (Null) Modem, für das die serielle Schnittstelle ursprünglich mal gedacht war, vorhanden ist.

Eine Dreidrahtverbindung sollte ausreichen, also TxD und RxD gekreuzt, sowie eine Masseverbindung.

Da am PC sowohl 25- als auch 9-polige serielle Stecker vorkommen habe ich beide Pinbelegungen angegeben. Die Brücken von RTS zu CTS, bzw. zwischen DSR, DCD und DTR können für CASTOR und POLLUX wegfallen, schaden aber nicht und man hat dann ein standardmäßig beschaltetes Nullmodemkabel das man auch für andere Zwecke einsetzen kann.

Rechts ist die Belegung eines 7-adrigen Nullmodemkabels dargestellt, zur Zeit brauchen CASTOR und POLLUX sowas nicht, aber bei Version 0.3 war's der Fall und vielleicht muss ich ja irgendwann nochmal darauf zurückgreifen.

Wer mit dem Gedanken spielt auch mein Programm DOSPRINT einzusetzen, der sollte sich auf jeden Fall die Mühe machen ein siebenadriges Kabel zu löten. DOSPRINT braucht es nämlich.

By the way: Auch wenn es allgemein üblich geworden ist die Kabel von seriellen Schnittstellen bei laufendem Betrieb abzuziehen und wieder anzustöpseln, gut ist das nicht. In 99,9% der Fälle geht's glatt, aber wenn die Masseleitung die erste ist die getrennt wird, dann kann man sich auch die serielle Schnittstelle zerschießen. Schneider empfiehlt, die Strippen nur bei ausgeschalteten Rechnern zu ziehen.

Die parallele Verbindung vom JOYCE zum PC

Da die Verbindung über die serielle Schnittstelle doch recht langsam ist, habe ich mir Gedanken über eine parallele Verbindung gemacht. Leider gibt es hier, zumindest auf Seiten des Joyce, keine brauchbare Standardlösung.

Mit einer kleinen Schaltung am Erweiterungsport des Joyce ist es aber möglich eine Verbindung zur Druckerschnittstelle des PC herzustellen. Die Schaltung besteht aus einer 8255 PIO und vier TTL-Bausteinen.

Anmerkungen: Einen sauber ausgearbeiteten Schaltplan habe ich noch nicht fertig. Es gibt bisher nur eine 'Loseblatt-Sammlung'. Sollte Interesse an einem Schaltplan bestehen bin ich aber gerne bereit ihn endlich mal sauber zu Papier (bzw. Diskette) zu bringen. Eine Platine, oder gar einen Bausatz oder einen fertigen Aufbau wird es aber, zumindest von mir, nie geben.

Interna von CASTOR und POLLUX

Ich habe mir mal etwas Zeit genommen, um interessierten Nutzern ein paar Einblicke in die Interna von CASTOR und POLLUX zu geben. Erwartet hier aber bitte keine detaillierten wasserdichte Beschreibung.

Mit dem Start von CASTOR wird auf dem JOYCE eine sogenannte RSX (resident system extension) installiert. Wie eine solche aufgebaut sein muss, kann man in den entsprechenden Handbüchern zu CP/M nachschlagen. Eine RSX quetscht sich sozusagen zwischen das Programm und das BDOS (basic disk operating system), das Betriebssystem des JOYCE. Jeder BDOS-Aufruf des Programms geht erstmal an die RSX. Diese entscheidet, ob sie den Aufruf einfach an die Originaladresse weiterleitet, oder ihn selbst behandeln will.

Die RSX von CASTOR meldet, wenn sie eine Verbindung zu PC erkannt hat, alle dateibezogenen Betriebssystemaufrufe an den PC weiter. Dieser (bzw. POLLUX dort) schaut nach, welches Laufwerk betroffen ist. Ist es ein lokales Laufwerk des JOYCE (also üblicherweise A: B: oder M:), dann bekommt CASTOR den Auftrag, den Aufruf einfach an das BDOS weiterzugeben. Ist es ein Laufwerk das auf dem PC simuliert wird, dann übernimmt POLLUX all die Arbeiten die auf einem richtigen Laufwerk das BDOS des JOYCE durchführen müsste.

Natürlich gibt es etliche Unterschiede zwischen den Dateisystemen von CP/M und MS-DOS. CP/M kennt Usernummern, diese gibt es auf dem PC nicht. Dafür kennt MS-DOS benannte Verzeichnisse, diese gibt es wiederum unter CP/M nicht. Die interne Organisation des Dateisystems unterscheidet sich in vielen Punkten recht heftig. Diese Unterschiede muss POLLUX irgendwie ausbügeln.

Im wesentlichen schafft POLLUX das auch. Allerdings gibt's einige Falten die nur mit einem größeren Aufwand auszubügeln wären. Und davor habe ich mich schlichtweg gedrückt. Nur wenn die Falten die noch drin waren mir echte Sorgen gemacht haben, habe ich mehr Mühe darauf verwandt sie glattzubekommen.

Ein simples DIR ohne Parameter klappte schon recht schnell. Der Aufwand den ich brauchte um PIP zum Laufen zu bringen hat mich ein paarmal fast verzweifeln lassen. Aber PIP musste ganz einfach laufen, sonst wären CASTOR und POLLUX nur Spielerei ohne praktischen Wert geblieben.

Ein, eigentlich recht simples, DIR [SIZE] funktioniert auf Laufwerken die POLLUX simuliert, aber schon nicht mehr. DIR will in diesem Fall an Interna der Dateiverwaltung heran die sich aus den Daten die auf dem PC anfallen nur mühsam berechnen lassen. Klar, mit einer Woche (oder mehr) intensiver Programmierarbeit wäre auch das zu schaffen, aber es ist mir den Aufwand ehrlich gesagt nicht wert. Dafür müsste man sich auch recht tief in die, teilweise undokumentierten, Interna der FCBs (file control block) einarbeiten.

Fortschritte von CASTOR und POLLUX

Um einen groben Überblick über die Geschwindigkeitsverbesserungen von CASTOR und POLLUX zu haben, habe ich die Ladezeiten der CP/M-Version von Turbo-Pascal 3.0, das auf der Festplatte des PC gespeichert war, bis zum Erscheinen des Prompts gemessen. Die Datei TURBO.COM ist 30848 Byte groß. Als Vergleichswerte habe ich die Ladezeiten von RAM-Disk und Floppy herangezogen.

Bei den ersten Versuchen habe ich mir genaue Zeitmessungen verkniffen, die Zeiten waren eh indiskutabel und ich habe sie lieber zum Kaffeetrinken (anfangs reichte es auch noch für ein Stück Kuchen) als zum Messen genutzt.

Bei den ersten Versuchen mit 9600 Baud stellte sich der PC als Bremse heraus, so dass ich die Unit zum SIO-Zugriff von purem Turbo-Pascal auf Assembler umstellen musste.

Danach schaffte der JOYCE es nicht mehr, sein DTR-Signal rechtzeitig zu aktivieren wenn sein Empfangspuffer voll war so dass ich auf dem JOYCE direkt auf die Hardware zugreifen musste.

Der Code der RSX kann zur Zeit nicht viel mehr als die benutzten 13889 Baud verkraften, Optimierungen bis zu einem Faktor zwei oder etwas mehr wären aber durchaus noch möglich. Allerdings macht die Hardware des JOYCE uns bei höheren Baudraten einen Strich durch die Rechnung, so dass sich eine weitere Optimierung des Codes, außer um die RSX noch etwas kleiner zu machen, erübrigt.

Die reine zur Übertragung der 30848 Byte von TURBO.COM benötigte Zeit beträgt übrigens 22,2 Sekunden. Es sind also nur knappe drei Sekunden die ich durch zusätzliche Verwaltungsdaten und sonstigen Overhead verliere.

Mögliche Baudraten

Sowohl auf dem JOYCE als auch auf dem PC sind die Baudraten der seriellen Schnittstellen nicht beliebig, sondern nur in mehr oder weniger großen Schritten einstellbar. Die einzelnen Baudraten werden durch herunterteilen eines Grundtaktes erreicht. Der Grundtakt auf dem PC beträgt 3,4864 MHz, so dass dort die Standard-Baudraten erzeugt werden können. Auf dem JOYCE hat man sich leider einen eigenen Quartz für die Erzeugung der Baudraten gespart und leitet diese aus dem Systemtakt von 4 MHz ab. Damit ergeben sich dann leider krumme Werte die mehr oder weniger von den Standardwerten abweichen.

Glücklicherweise verkraftet die serielle Schnittstelle Abweichungen von bis zu +/- 5% zwischen den Kommunikationspartnern. Nur dadurch ist der JOYCE überhaupt in der Lage eine Verbindung zu etwas anderem als einem zweiten JOYCE aufzunehmen. Bei kleineren Baudraten sind die Unterschiede noch nicht so gewaltig, aber je höher die Baudrate wird, desto weniger Zwischenwerte gibt's und desto weiter liegen die Werte des JOYCE leider auch neben den Standardwerten. Die Werte im für CASTOR und POLLUX relevanten Bereich habe ich aufgelistet.

Tja, das war's dann. Mit 13889 Baud auf dem JOYCE und 14400 Baud auf dem PC ist das Ende der Fahnenstange erreicht. Bei höheren Werten ist die Abweichung leider zu groß.

Kleinere Baudraten als 9600 Baud werden von CASTOR und POLLUX zur Zeit nicht mehr unterstützt. Falls jemand sie benötigt, soll er sich melden.

Übertragungsgeschwindigkeit auf der parallelen Verbindung

Für eine, halbwegs aussagekräftige, vergleichende handgestoppte Messung der Geschwindigkeit reichte die Ladezeit von Turbo-Pascal nicht mehr aus. Ich habe also kurzerhand den gesamten Inhalt der RAM-Disk (ca. 120 kByte) mit PIP übertragen. Heraus kamen folgende Zeiten:

Damit ist die Verbindung Joyce-PC nur noch etwa ein Drittel langsamer als die RAM-Disk. In umgekehrter Richtung, vom PC zum Joyce, geht es sogar noch ein Sekündchen schneller.

Ehrlicherweise sei angemerkt, dass (wie ich später feststellte) von den 14 Sekunden bei der Übertragung von RAM-Disk zu RAM-Disk auch eine Sekunde auf das Konto von CASTOR und POLLUX geht.

Einige Anmerkungen zur umgeleiteten seriellen Schnittstelle.

Jeder BDOS-Aufruf zum Senden bzw. Empfangen von Daten über die serielle Schnittstelle bewegt nur jeweils ein Byte Nutzdaten. Dazu gesellen sich in den meisten Fällen noch eine oder zwei Statusabfragen. Dies bedeutet, dass auf der Verbindung JOYCE-PC für jedes Datenbyte ca. 15 (und mehr) Byte Verwaltungsoverhead anfallen. Die effektive Baudrate wird sich also um die 600 Baud oder sogar darunter bewegen.

Bei Bedarf kann man das aber über eine Sonderbehandlung der beteiligten Funktionen sicherlich auf bis zu 2400 und ein paar mehr Baud hochtreiben.

Zusätzlich kann man sich überlegen für eigene Projekte erweiterte Funktionen in die CASTOR-RSX einzubauen. Durch eine blockweise Übertragung der Daten kann man sicherlich eine effektive Baudrate um 9600 Baud erzielen.

Diese Werte gelten für die serielle Verbindung Joyce-PC mit 14400 bps. Mit der parallelen Verbindung sieht es (ungetestet) sicherlich um Klassen besser aus. Zumindestens 2400 bps sollten ohne Probleme erreicht werden.

Wie gut ist die Laufwerksemulation?

Die Emulation der BDOS-Funktionen des CP/M auf dem PC ist noch lange nicht vollständig, geschweige denn perfekt. In einigen Fällen wird der JOYCE beim Zugriff auf umgeleitete Laufwerke also schlicht Mist liefern. Allerdings betrifft das vor allem Systemaufrufe die selten(st) oder nur von sehr hardwarenahen Programmen benutzt werden. Das sind vor allem Formatierungsprogramme und Diskeditoren und für die sind CASTOR und POLLUX nun wirklich nicht gedacht.

Die folgende Liste gibt einen Überblick über all das, was nicht, nur eingeschränkt oder anders als auf lokalen Laufwerken des JOYCE funktioniert.

• CP/M-Usernummern ignoriere ich zur Zeit noch vollkommen, es gibt die Dateien auf dem simulierten Laufwerk unter allen Usernummern zu sehen.
  
  
• In den FCBs (File Control Blocks) werden nur die absolut notwendigen Felder behandelt. Das eine oder andere Programm mag sich daran stören. Standardaufrufe laufen aber ohne Probleme.
  
  
• Alle mit Date- & Timestamping und Passwords in Zusammenhang stehenden Optionen (z. B. SFCB's), sowie die Vergabe von Directorylabels werden nicht unterstützt.
  
  
• Da ich die serielle Schnittstelle des JOYCE für eigene Zwecke benutze dürfen Anwenderprogramme nicht direkt auf sie zugreifen. Die entsprechen- dem BDOS-Aufrufe können auf eine zweite serielle Schnittstelle des PC umgeleitet werden. Programme die die BIOS-Einsprünge benutzen werden aber auf die Nase fallen.
  
  
• Ist der Laufwerkscode im FCB beim Aufruf von FindFirst oder FindNext ein '?', dann werden alle Einträge im Directory des aktuellen Laufwerks gesucht (z.B. um das Directory-Label zu finden). Diese Funktion wird z. Zt. nicht unterstützt. Die Implementierung ist auch etwas aufwendiger, da dann alle Bytes im FCB, und nicht nur Name und Extension, gesetzt werden müssen, denn Programme die diese Funktionalität ausnutzen, wollen normalerweise an die Interna des FCB heran.
  
  
• Für das simulierte Laufwerk mogle ich dem Anwenderprogramm den Allocation-Vector von Laufwerk M: unter. Das ist nicht ganz fair und es wird bestimmt das eine oder andere hardwarenahe Programm drüber stolpern, aber was anderes fällt mir leider nicht ein.
  
  
• Selbiges gilt für den Disk-Parameter-Block.
  
  

Für Hardwarebastler

Für all diejenigen, die nicht vom Lötkolben lassen können, habe ich noch drei Bastelideen:

Außer dem Takt von 4 MHz steht auf dem Erweiterungsbus des JOYCE auch noch ein Takt von 32 MHz zur Verfügung. Dieser könnte durch ein einzelnes IC, das Huckepack auf ein anderes in das Gehäuse der Seriell-/Parallel-Schnitt- stelle gelötet wird, durch neun geteilt werden. Damit hätte man einen Grundtakt von 3,5555 MHz. Das liegt 'nur' ca. 4% neben dem Grundwert des PC und diese Abweichung sollte die serielle Schnittstelle gerade so noch verkraften. Somit ständen dann im Prinzip alle Baudraten bis hinauf zu 115200 zur Verfügung. Dort oben wird die Luft dann aber für unseren kleinen JOYCE sehr dünn. Für jedes zu übertragene Byte hätte der JOYCE dann gerade mal 36 Taktzyklen zur Verfügung. Aber bis 28800 Baud könnte es mit Hoffen und Beten (und 'ner Menge Codeoptimierung) eventuell reichen.

Weiterhin ist es möglich, dem JOYCE eine zweite serielle Schnittstelle zu verschaffen. Im Z80-DART ist eine zweite Schnittstelle implementiert. Zusätzlich sind nur die Pegelwandler von 0V/5V auf -12V/+12V nötig, die ebenfalls Huckepack über den schon vorhandenen Pegelwandlern eingelötet werden können. Sind die vom Z80-DART gelieferten 0V/5V genug, dann können auch diese entfallen und es sind nur ein paar Beinchen des DART hochzu- biegen und mit einer zusätzlichen Buchse zu verbinden. Die Serielle des PC kann man, mit Hilfe von ein paar Dioden und Widerständen im Kabel, auch mit 0V/5V ansteuern.

Der Haken ist allerdings, dass es für diese zweite Serielle weder Unterstützung vom CP/M, noch Steuersignale (RTS/CTS und den ganzen Quatsch) gibt, diese werden nämlich für die parallele Schnittstelle verwendet. Man könnte diese zweite serielle Schnittstelle aber, bei (winzig) kleinen Änderungen im Quelltext der RSX, für CASTOR verwenden und hätte die normale serielle Schnittstelle dann gleichzeitig für andere Aufgaben frei.

Für beide Basteltips kann ich eine Skizze liefern. Ich muss allerdings dazusagen, dass ich weder die eine noch die andere Bastelei bisher ausgeführt habe und daher für die Korrektheit der Vorschläge in keiner Weise garantieren kann.

Ich selbst plane, eine 8255-PIO an meinen Joyce zu hängen und CASTOR und POLLUX dann über eine LapLink-ähnliche Verbindung an einer Parallelschnittstelle des PC zu betreiben. Ich hoffe, damit eine recht deutliche Geschwindigkeitssteigerung hinzubekommen.

Das ist inzwischen geschehen.

NOCHMAL ALLGEMEINES

Haftungsausschluss

Tja, ähh, garantieren kann ich nur dafür, dass CASTOR und POLLUX sowohl auf dem JOYCE als auch auf dem PC Disketten- bzw. Festplattenplatz belegt. Dass CASTOR und POLLUX auch das machen, und dann auch noch erfolgreich, was in diesem Text beschrieben ist, ist schon nicht mehr so sicher. Und dafür, dass CASTOR und POLLUX Dateien, FAT und Inhaltsverzeichnis sowie verwendete Hardware, insbesondere die seriellen Schnittstellen ohne dauerhaften Schaden neben sich existieren lassen, kann ich erst recht nicht garantieren. Also, testet CASTOR und POLLUX, benutzet es, aber alles auf eigenes Risiko. Ich habe mich bemüht ein funktionierendes Programm zu erstellen, aber man weiß ja nie.

Umsonst, oder was?

Ich habe 'ne ganze Menge Zeit und auch die eine oder andere Nachtsitzung in die Entwicklung von CASTOR und POLLUX investiert. Ich find's garnicht mal so übel, was ich da wieder verbrochen hab', und darum lass ich mein '(c) Andreß Freystatzky' auch drin stehen. Und ich mach' auch weiter. Eine Version 1.x soll's mindestens geben, aber wenn ihr wollt, dass ich die auch für jedermann verfügbar mache und nicht in meinem stillen Kämmerlein unter Verschluss halte, dann müsst ihr mich schon ein wenig motivieren. Ich möchte wenigstens wissen, was euch an der aktuellen Version noch stört, wo die Bugs sind die mir noch nicht aufgefallen sind, was ich noch dazupacken sollte oder könnte.

Wenn euch CASTOR und POLLUX jetzt schon gefallen, dann dürft ihr mir auch ein Lob oder gar eine kleine Aufmerksamkeit zukommen lassen. Zum Beispiel:

• Eine Postkarte aus eurem nächsten Urlaub
  
  
• 'ne weiße Crisp von Ritter-Sport
  
  
• Ein hübsches Bild von C. F. Gauß, dessen Geburtshaus bei mir gleich um die Ecke stand. So ein Bild ist leicht zu finden, gleich neben dem Portrait von Anette von Droste-Hülshoff ;-)
  
  
• Ach ja, ein paar 256kB oder 1MB SIPPs (!) könnte ich auch noch gebrauchen.

Langer Rede kurzer Sinn: Macht doch mit CASTOR und POLLUX 0.96 was ihr wollt. Solange ihr meine Urheberschaft nicht in Frage stellt und den Copyrightvermerk nicht rauspatcht dürft ihr's benutzen, kopieren und weitergeben so oft ihr Lust habt.

Der Quelltext

CASTOR und CD sind in Z80-Assembler und Turbo Pascal 3.0 unter CP/M auf dem JOYCE geschrieben.

POLLUX in Turbo Pascal 6.0 unter MS-DOS 5.0 auf einem PC.

Die Quelltexte, sie umfassen zur Zeit ca. 200 kByte, sind leidlich dokumentiert. An einigen Stellen gibt es noch recht abenteuerliche Hacks die man eigentlich niemandem zeigen darf, wenn man seinen Ruf als Programmierer behalten will.

Ich würde sie, zumindest im gegenwärtigen Zustand, nur ungern herausrücken. Bei wirklichem Interesse lässt sich aber mit ein wenig Beharrlichkeit und Quengelei eventuell was machen.

Der Autor

Falls ihr Fehler entdeckt habt, Verbesserungsvorschläge habt, einfach mal meckern wollt, oder mich (was mich noch mehr freuen würde) mal ein wenig loben wollt. Oder mir gar eine Kleinigkeit als Anerkennung für meine Arbeit mit CASTOR und POLLUX schicken wollt, hier meine Adresse:

    =   Castor & Pollux downloaden