KC-News 3/1998

Top-Themen:

• Rechnerkopplung KC - PC
• Umbauanleitungen für das Modul M006/028
• Das LCD-Projekt

Ein paar Worte zur Einleitung

von Frank Dachselt

Sommer, Sonne, ... Naja, den Rest kennt Ihr ja sicherlich. Die dritte Ausgabe eines jeden Jahres ist für den Redakteur der KC-News immer mit der Hoffnung verbunden, nicht ganz so tief ins Sommerloch zu fallen. In dieser Zeit nämlich tauschen selbst die treuesten Fans des KC ihren Platz an der Tastatur gegen einen am Strand oder im Freibad. Deshalb an dieser Stelle an alle, die sich mit einem Beitrag an diesen KC-News beteiligt haben, einen ganz besonderen Dank.

In dieser Ausgabe melden sich auch wieder einige Hardware-Experten zu Wort. Wem das nicht unbedingt als das richtige Thema zur heißen Jahreszeit erscheint, der denke doch schon mal an verregnete Herbsttage und lange Winterabende. Nein nein, ich will jetzt keine trübe Stimmung verbreiten, aber mit den Planungen für das eine oder andere Hardware-Projekt kann man doch schon jetzt beginnen.

Als Beilage zu diesen KC-News findet Ihr auch drei neue Teile des Assemblerprogrammierkurses. In der Rubrik ,,Programmierecke`` gibt es noch ein paar mehr Infos dazu. Nur soviel im Voraus: Nach den theoretischen ,,Vorarbeiten`` beginnt heute der praktische Teil des Kurses. Das bedeutet, daß allein mit Papier und Bleistift dem Kurs nicht mehr zu folgen ist, sondern ab heute auch direkt der Assembler am Rechner benutzt werden muß.

Kurz vor dem Redaktioinsschluß erreichte mich noch die folgende Nachricht von Dietmar Meyer aus Reichenbach:

KC-Clubtreffen 1999 in Pechtelsgrün

Hallo KC-User,

mein Angebot für das nächste KC-Clubtreffen sieht so aus:

Termin:	16.04.99 - 18.04.99
Adresse:	Pension ,,Sonnenblick``
	Elke Franke
	Hauptstraße 11a
	08485 Pechtelsgrün
Preise:	Übernachtung 25,00 DM
	Frühstück 5,00 DM
	Abendbrot 6,00 ... 10,00 DM
	Mittagessen nach Bestellung im benachbarten Gasthof

Ich gehe davon aus, daß alle damit einverstanden sind und habe den Termin gebucht.

Wegbeschreibung:

Autobahn A72, Abfahrt Zwickau-West, Richtung Lengenfeld fahren bis zum Abzweig Pechtelsgrün. Die Dorfstraße hochfahren bis rechts die Pension ,,Sonnenblick`` erscheint. Wer Fragen dazu hat, bitte bei mir melden.

Es grüßt Euch Dietmar

Damit scheinen also auch die Weichen für unser nächstes Clubtreffen schon richtig gestellt zu sein. Das Datum also schon mal im Terminkalender - soweit bereits einer für das nächste Jahr vorhanden ist - vormerken! In den nächsten News gibt es dann wieder die Anmeldeformulare sowie zu gegebener Zeit weitere Infos zu Anreise und Ablauf des Treffens.

Nun aber erst mal zur aktuellen Ausgabe. Viel Vergnügen damit wünscht Euch

Euer Redakteur Frank

Bericht vom Z-Fest 1998

von Jörg Linder

Das KC-Jahr hatte mit dem Clubtreffen bereits im April seinen Höhepunkt erreicht. Bekanntlich gibt es aber noch eine andere alljährliche ,,Großveranstaltung`` in Sachen 8-Bit-Technik: das Z-Fest in Güglingen. Während wir uns beim KC-Clubtreffen den 20. Geburtstag des Betriebssystems CP/M zwar auf die Fahnen geschrieben, ihn aber eigentlich nur beiläufig gefeiert haben, war er DER Mittelpunkt des '98er Z-Festes. Aber alles hübsch der Reihe nach...

In diesem Jahr war es mir gelungen, meinen Chef von der Notwendigkeit eines zweiwöchigen Urlaubes im Frühsommer zu überzeugen. Bevor er seine Entscheidung revidieren konnte, hatte ich flugs meine Sachen gepackt und mich auf den langen Weg nach Güglingen bei Heilbronn/Neckar gemacht. Schließlich war es bereits das dritte Mal, daß ich dorthin fuhr, ohne auch nur das geringste von der Umgebung gesehen zu haben. Das sollte sich diesmal ändern! So habe ich unter anderem dem Kloster in Maulbronn einen Besuch abgestattet. Die am vollständigsten erhaltene und damit eindrucksvollste Klosteranlage nördlich der Alpen ist Teil des UNESCO-Weltkulturerbes und wirklich einen Besuch wert.

Leider widerfuhr auch diesen Urlaubstagen das gleiche Schicksal wie ihren Artgenossen zuvor - sie waren viel zu schnell vorbei. Doch somit rückte das Z-Fest näher. Am Freitag reiste Tilmann Reh mit Familie an; auf dem Heimweg vom Urlaub machten sie für das Treffen bei Vogelmanns Zwischenstation.

Aufgrund des erwarteten Andrangs hatten Roderich, Uwe und Christian anstelle der Räume im Obergeschoß des Hauses vorsorglich die ehemalige Scheune für das Treffen hergerichtet. Wie klug diese Entscheidung war, zeigte sich nach Anreise der ersten Teilnehmer. Bei durchschnittlich zwei Kisten Computerkram pro Person und daraus resultierend eine Stellfläche von jeweils ca. 2 Quadratmetern wurde der anfangs so üppig scheinende Platz zusehends knapp.

Mit dem Eintreffen von Helmut Jungkunz wurde es wahrlich eng. Er hatte seinen Kombi bis zum Achsbruch beladen und holte nun eine Rarität nach der anderen aus dessen Innenraum hervor. Abgesehen von Laptop und CPU280, die ja zu Helmuts Grundausstattung gehören, brachte er unzählige CP/M-Literatur und einen Videoprojektor mit.

Während wir uns Videos ,,aus der guten alten Zeit`` vom Trenton-Trip, dem '96er KC-Clubtreffen oder den Z-Festen ansahen, verteilte Helmut seine ,,Mitbringsel``. Irgendwie hatte es etwas von Weihnachten - niemand wurde vergessen, für jeden hat er aus den schier unendlichen Weiten der Kisten und Kartons genau den Leckerbissen hervorgeholt, nach dem man schon seit Ewigkeiten gesucht hat. Ich habe übrigens ein paar (Software-)Dokumentationen bekommen; natürlich in Englisch, aber wie sollte es anders sein...

Das größte ,,Mitbringsel`` war jedoch ein kompletter HP9000. Dieses Wunderwerk der Technik beherbergt nicht nur den Rechner einschließlich Tastatur und Drucker in einem (!) Kompaktgehäuse, auf den der via Steckverbinder angeschlossene Monitor aufgesetzt wird, sondern ist auch waaahnsinnig schwer. Zu seinen ,,Lebzeiten`` hat der HP9000 fast 100.000,- DM gekostet. Wenn ein Mann derart schwere Technik auffährt, kann nur eine Frau im Spiel sein, in diesem Fall eine äußerst charmante und attraktive dazu!

Gaby Chaudry, die ,,Neuentdeckung`` der CP/M-Szene, war absoluter Mittelpunkt des Treffens und wurde umschwärmt wie das Licht von den vielzitierten Motten. So mancher Technikverliebte würde beim Anblick ihrer Sammlung erblassen. Die Kölnerin gewährt unter www.gaby.de einen Einblick in ihr kleines Museum, das nun um den besagten HP9000 reicher ist.

Zugegeben, neben Gabys Erscheinung wirkte alles andere beim Treffen etwas nebensächlich, doch einen weiteren Höhepunkt möchte ich keineswegs unerwähnt lassen. Helmut Jungkunz würdigte die herausragenden Leistungen um CP/M im allgemeinen und das Z-System im besonderen mit einem Preis: Mario Leubner aus unserem Club darf sich stolz ,,Z-User 1998`` nennen! Die Verleihung des Preises, den ich stellvertretend entgegennehmen durfte, wurde von Andreas Kißlinger auf Video gebannt. (So haben wir beim nächsten Z-Fest wieder 'was zu gucken. ;-)

Bereits beim Treffen des KC-Clubs zeichnete sich ab, daß 1998 ein gutes Jahr für Rekorde ist. Zwar reichte die Zahl der Teilnehmer bei weitem nicht an das von unserem Club gewohnte Niveau heran, aber 24 Personen sind doch auch eine recht beachtliche Zahl, zumindest ist es neuer Z-Fest-Rekord. Nicht minder positiv die Bilanz der aufgebauten Geräte: 22 Rechner aller Betriebssysteme und Leistungsklassen werkelten friedlich nebeneinander, während ihre Besitzer über Vorteile der eigenen und Nachteile der jeweils anderen Hardware heißblütig diskutierten.

Nicht ganz so aufregend war der Chat im Internet, mal abgesehen davon, daß sich der TCP/IP-Stack von Robert Sterff alle halbe Stunde verabschiedet hat und neu gestartet werden mußte. Nur Bill Kibler hat sich von der anderen Seite des Ozeans eingeklinkt. Ansonsten konnte man die Lage guten Gewissens als ruhig bezeichnen.

Das ist auch das Stichwort für mich. Ich bin jetzt ebenfalls ruhig und hoffe, daß die Fotos ein wenig von der Atmosphäre wiedergeben (können).

Man sieht sich im Zabergäu!

System-Updates

von Mario Leubner

Aufgrund des Sommerloches und wegen der heißen Temperaturen diesmal nur ein paar Updates von mir und die neuesten Meldungen von meinem KC, also los geht's:

MICRODOS.COM

Wer einen Windows-PC hat, der kennt sicher das MS-DOS Fenster. Also das Starten von DOS-Programmen aus Windows heraus. Wie wäre es demnach für den mit einem ,,MICRODOS-Fenster`` unter ML-DOS? Immer wieder bestand das Problem herauszufinden, ob Programme, die unter ML-DOS oder dem Z-System auf dem KC laufen, auch für MicroDOS geeignet sind. Da geht als erstes die Suche nach der seit Ewigkeiten nicht mehr benutzen MicroDOS-Systemdiskette los. Dann macht man sich davon eine Kopie, denn man will ja keinen Datenverlust riskieren. Das zu testende Programm wird ebenfalls kopiert und dann kann man mit dieser Diskette neu booten. Ist der Test beendet, verläßt man MicroDOS und bootet wieder neu.

Mit MICRODOS.COM geht es jetzt wesentlich einfacher: Das zu testende Programm wird ins RAM-Floppy kopiert und MICRODOS.COM aufgerufen. MICRODOS.COM rettet das laufende System in einer Datei A0:EXIT.COM, kopiert MicroDOS in den Speicher und startet es. Dabei bleiben alle Treiber im Grundgerät aktiv und auch das RAM-Floppy behält seinen Inhalt, auch die für ML-DOS übliche Systemspur, was für MicroDOS jedoch kein Problem darstellt. Jetzt kann man wie gewohnt unter MicroDOS arbeiten. Ruft man anschließend EXIT.COM auf, wird das vorher laufende System vollständig regeneriert und man kehrt genau an die Stelle zurück, an der man MICRODOS gestartet hatte. Voraussetzung ist nur, daß die Datei A0:EXIT.COM im RAM-Floppy noch unverändert vorhanden ist, der Programmtest also nicht zum Systemabsturz führte.

Mit MicroDOS.COM ist aber noch mehr möglich. So lassen sich Anwendungen, die nur unter MicroDOS laufen, als SUBMIT von ML-DOS aus starten und man merkt fast nicht, daß für die Laufzeit dieser Anwendung ein anderes Betriebssystem arbeitet. Möglich wird das durch die gegenseitige Übernahme laufender SUBMIT's im Laufwerk A0:, das für den Datenaustausch eine zentrale Rolle spielt. Alle während der Arbeit mit MicroDOS benötigten Dateien müssen zunächst von der Festplatte nach A0: kopiert werden. Dann wird MICRODOS.COM gestartet. Jetzt ist der Festplattenzugriff nicht mehr möglich, die Laufwerke C:, D: usw. sind wie unter MicroDOS installiert. Ist die Arbeit unter MicroDOS beendet, kehrt man zurück zu ML-DOS und kann die veränderten Dateien vom RAM-Floppy auf die Festplatte übernehmen. Und das kann alles automatisch - gesteuert von einem SUBMIT - erfolgen.

Dazu ein Beispiel: CLOCK.COM ist eine recht ansprechende Digitaluhr von Torsten Harder. Die Zeitbasis wird aus den MicroDOS-Arbeitszellen gelesen und angezeigt. ML-DOS enthält zwar eine Uhr, nutzt aber den RTC-Chip vom GIDE-Interface. Das Auslesen der Uhrzeit wird dabei über erweiterte BDOS-Aufrufe des ZSDOS vorgenommen. Aus diesem Grund kann CLOCK.COM unter ML-DOS nicht funktionieren. Beim Start von MICRODOS.COM wird die aktuelle Uhrzeit von ZSDOS gelesen und in die MicroDOS-Arbeitszellen eingetragen. Folgende SUBMIT-Datei CLOCK.SUB habe ich erstellt:

COPY CLOCK.COM A0: /X
COPY CLS.COM A0: /X
MICRODOS
CLOCK
CLS
EXIT

Zunächst werden die beiden benötigten Dateien CLOCK.COM und CLS.COM vom aktuellen Laufwerk nach A0: kopiert, die Option /X sorgt dafür, daß ACOPY 3.5 eventuell bereits vorhandene Dateien nicht überschreibt. Dann wird MICRODOS.COM aufgerufen. Wenn MicroDOS startet, ist der SUBMIT in A0: noch nicht abgearbeitet und wird von MicroDOS fortgeführt. Der nächste Befehl wäre also der Aufruf von CLOCK.COM - die Uhr wird angezeigt. CLOCK.COM läuft solange, bis es mit der Taste ,,E`` abgebrochen wird. Das Bild wird dabei nicht gelöscht, weshalb noch der Aufruf von CLS.COM erfolgt. Danach wird der letzte Befehl EXIT abgearbeitet, der ML-DOS zurückholt. Um diesen Ablauf zu starten, ist unter ML-DOS nur das eine Kommando

SUBMIT CLOCK.SUB

einzugeben. Oder man startet ML-COM, positioniert den Cursor auf CLOCK.SUB und betätigt 2-mal die Entertaste. Beim Rücksprung landet man dann selbstverständlich auch wieder bei ML.COM.

ML.COM

Damit bin ich schon beim 2. Update: Bei ML.COM habe ich in der Version 2.4 die Anzeige der Dateigrößen korrigiert. Bisher wurden Dateigrößen von mehr als 512 K nicht korrekt angezeigt, jetzt funktioniert es bis zu theoretisch 4 MByte. Ich glaube, das müßte auch den Festplatten-Anwendern erst einmal ausreichen. Als weitere Änderung wird die Liste der aktiven USER-Bereiche (beim Einloggen in ein Laufwerk) mit Bindestrich in der Bedeutung ,,von bis`` angezeigt. Dadurch sind mehr USER-Bereiche möglich bevor die Zeile voll ist.

POPCOM.COM

Als drittes Programm möchte ich POPCOM vorstellen. Es handelt sich um einen Packer für COM-Dateien. Autor des Programms ist wieder Yoshihiko Mino, der uns von den PMA-Packern PMARC/PMEXT bestens bekannt ist. Das neue Programm POPCOM (1992) ist leistungsfähiger als PMEXE2 & PMARC. Die Syntax von POPCOM ist recht einfach und wird angezeigt, wenn POPCOM ohne Argumente aufgerufen wird.

Eine Beschreibung zum Programm existiert leider nicht. Das Prinzip der Komprimierung von COM-Files beruht darauf, daß der Entpacker im komprimierten Programm enthalten ist und dieses nach dem Laden wieder dekomprimiert und danach sofort startet. Unter der Annahme, daß das Entpacken schneller geht als das Laden einer größeren Datei, benötigen derart gepackte Programme also nicht nur weniger Speicherplatz auf dem Datenträger, sie werden sogar schneller geladen. Als Anwender merkt man davon nichts, der Ablauf scheint unverändert zu sein, nur der benötigte Diskettenspeicherplatz ist geringer.

POPCOM ist kein ZCPR-Programm, der Z3ENV-Pointer wird also nicht eingetragen. Z-System-Programme lassen sich demnach nicht mit POPCOM packen. Auch bei Programmen, die als Overlays nachgeladen werden (z.B. RDBASOVR.COM von Redabas), darf nicht komprimiert werden.

POPCOM.COM ist mit sich selbst gepackt. Nach dem Auspacken kann am Programmanfang ein Patchbereich für einen Datumstreiber erkannt werden. Diesen habe ich für ZSDOS erstellt und eingebunden. Damit bleibt das Datum der Dateien beim Komprimieren und Dekomprimieren unter ZSDOS erhalten.

STARDATE.COM

Stardate V1.2 habe ich auf einer älteren V-Disk des Z-Archives gefunden. Es stammt aus dem Jahr 1986 und wurde 1988 auf die V-Disk übernommen. Es war zwar möglich, die Terminalinstallation zu verändern, aber nur für Televideo. Mit ein paar zusätzlichen Patches läuft es jetzt auch auf dem KC85.

Nach dem Aufruf muß zunächst das aktuelle Datum in der Reihenfolge Jahr, Monat und Tag eingegeben werden. Monat und Tag sollten immer zweistellig, also mit führender Null eingegeben werden, sonst verweigert das Programm die Annahme der Eingaben. Nach einer kurzen Rechenphase können ausführliche Informationen zum Kalender, Wochentag, Sonnenauf- und Untergang, Mondphasen, julian. und gregorian. Kalender abgerufen werden. Um genaue Werte zu erhalten, sind lokale Angaben zu Längen- und Breitengrad sowie Zeitzone möglich. Diese Angaben werden in einer Datei SD.PAR gespeichert und sind beim nächsten Aufruf sofort wieder vorhanden. Ich habe die Werte für Chemnitz eingegeben. Eine umfangreiche Beschreibung ist ebenfalls vorhanden, es ist aber alles in englisch. Doch vielleicht findet das Programm trotzdem bei jemandem Interesse.

Scanner-Interface

Letzte Meldung: Es funktioniert! - Das Scanner-Interface nach der Anleitung von Ralf Kästner. Nur soviel in aller Kürze: Ich habe alle Bauteile einschließlich GAL und Atari-Platine zusammengelötet und die drei TTL-ICs der Busanpassung auf einer kleinen Uniplatine daneben aufgebaut. Noch ein Kabel zum M001 - direkt innen rein, ohne Frontblende, fertig und funktionierte auf Anhieb! Also wieder mal große Klasse von Ralf. Jetzt muß nur noch die Schaltung für ein eigenständiges Scanner-Modul vervollkommnet werden. Und wie ich erfahren habe, ist in dieser Richtung schon etwas in Arbeit, genügend Interesse scheint ja vorhanden zu sein. Das wäre dann übrigens das erste vom KC-Club eigenständig neu entwickelte Modul.

Die Arbeit mit dem Scanner erfordert auch etwas Übung. So kommt zur Zeit alles, was so einigermaßen geeignet erscheint, nicht an meinem Scanner vorbei: Zeitungsartikel, Fotos, Grafiken, Werbeschriften... Unter anderem erhielt ich 1992 von einem KC-User mal eine Bildgeschichte zum Thema ,,Der Computer, Dein Freund und Helfer``. Anlaß waren Probleme mit einem Programm. Ich habe die 12 Bilder eingescannt, mit UNIPIC etwas nachbearbeitet und zu einer kleinen SHOW mit dem Name FRIEND.DSH zusammengestellt. Also dann viel Spaß beim Betrachten!

Hier nun Marios UNIPIC-Show, als GIF-Animation "geklont" (übrigens die erste Präsentation einer UNIPIC-Show auf der KC-Homepage):

Rechnerkopplung KC - PC

von Frank Dachselt

Unter dem Eindruck des Artikels zu den neuen V.24-Koppeltreibern von Mario Leubner in der letzten News-Ausgabe habe ich mich auch einmal etwas intensiver mit dem Thema Rechnerkopplung beschäftigt. Es stand sowieso auf meiner Vorhabenliste für dieses Jahr und der erwähnte Artikel liefert einen guten Anknüpfungspunkt. Das Thema ist nicht neu: Bereits in den KC-News 4/95 hat Dirk Walther eine Lösung für eine Rechnerkopplung veröffentlicht, die den PC als Komforttastatur nutzte und eine Datenübertragung ermöglichte. Ich möchte im folgenden Beitrag zunächst noch einmal die elementaren Dinge einer Rechnerkopplung etwas näher betrachten und im zweiten Teil eine Lösung für die Fernsteuerung des PC durch den KC vorstellen.

Nullmodemkabel und Hardware-Protokoll

Die Kopplung von KC und PC erfolgt über die serielle Schnittstelle. KC-seitig ist also ein M003 (inwieweit an dieser Stelle auch ein M053 mit seinen niedrigeren Signalpegeln gefahrlos funktioniert, kann ich leider nicht sagen) notwendig, am PC brauchen wir eine noch unbelegte serielle Schnittstelle (COM1 ... COM4). Die PC-Schnittstelle liefert folgende Signale:

Am KC ist die serielle Schnittstelle nur über eine 5-pol. DIN-Buchse erreichbar, an der folgende Signale zur Verfügung stehen:

Beide Schnittstellen müssen mit einem sogenannten Nullmodemkabel verbunden werden. Solche Kabel werden auch zur Verbindung von PC untereinander verwendet, aber ein handelsübliches Kabel nutzt uns nichts, da wir am KC keine für diesen Zweck genormte Steckverbindung haben. Bleibt also nur der Selbstbau: Die Minimallösung für einen bidirektionalen Datenaustausch wäre das 3-adrige Nullmodemkabel (Bild 1 (a)), bei dem nur die beiden Datenleitungen RxD und TxD verwendet werden. Diese werden gekreuzt, d.h. der Ausgang des einen Rechners wird mit dem Eingang des anderen Rechners verbunden und umgekehrt. Mit einem solchen Kabel ist kein Hardware-Handshaking möglich, die Anpassung der Geschwindigkeit des Datenstroms zwischen Sender und Empfänger ist hier nur mit einem Software-Protokoll (z.B. Xon/Xoff-Protokoll) zu erreichen.

Wir wollen aber ein Hardware-Protokoll verwenden, das ist eleganter, zuverlässiger und in den KC-Treibern bereits implementiert. Auch von PCs wird das Hardware-Protokoll im Prinzip immer unterstützt. Mit diesem Protokoll wird sichergestellt, daß der sendende Rechner nur so schnell Daten übermittelt, wie sie der empfangende Rechner ohne Datenverlust entgegennehmen kann. Dazu setzt der Empfänger ein Signal, wenn er bereit ist, neue Daten entgegenzunehmen, und setzt dieses Signal wieder zurück, wenn er eine Verarbeitungspause benötigt oder der Empfangspuffer voll ist. Der Sender erkennt dies und unterbricht die Sendung so lange, wie es das empfangende Gerät verlangt. KC-seitig stehen uns für diesen Zweck noch zwei Signalleitungen an der V.24-Buchse zur Verfügung: DTR und CTS, ein Ausgang und ein Eingang, die zwei Handshake-Leitungen ermöglichen - für jede Übertragungsrichtung eine. In den Koppeltreibern des KC ist das Handshaking über diese beiden Leitungen schon entsprechend programmiert, so daß an dieser Stelle bereits Klarheit besteht.

Die Probleme beginnen auf der PC-Seite: Trotz weiter Verbreitung und Standardisierung gibt es keine eindeutige Festlegung, wie die Steuerleitungen der seriellen Schnittstelle zum Handshaking verwendet werden. Das ist allein Sache der Software. Arbeiten Sender und Empfänger mit unterschiedlicher Software oder gar unterschiedlicher Hardware, wie in unserem Fall, dann wird wegen meist fehlender Dokumentation die ganze Sache leicht zum Geduldsspiel.

Es gibt mindestens zwei unterschiedliche Hardware-Protokolle, die auch verschiedene Beschaltungen des Nullmodemkabels voraussetzen. Auf der Betriebssystemebene von MS-DOS ist offenbar das sogenannte DTR-Protokoll üblich. Das zugehörige Kabel ist in Bild 1 (c) gezeigt. Hier dienen die Signale DTR und CTS zum Handshaking während der Datenübertragung.

Vor allem in amerikanischen Quellen findet man noch eine weitere Variante des Nullmodemkabels, die auf dem sogenannten RTS/CTS-Protokoll basiert (Bild 1 (b)). Neben diesen beiden Handshake-Leitungen sind in diesem Kabel noch zwei weitere Steuerleitungen geschaltet, die beim Aufbau einer Datenverbindung eine Rolle spielen. Kommunikationsprogramme wie ,,Interlink`` und ,,Laplink`` (???) sollen diese Kabelvariante benötigen. Leider war es mir bis heute noch nicht möglich, an einem handelsüblichen Nullmodemkabel die Beschaltung zu ermitteln. Alle von mir als kompetente Ansprechpartner angesehenen Leute bauen sich ihre Kabel selbst, wobei die Varianten (a) und (c) Verwendung finden.

Bild 1: Varianten des Nullmodemkabels - Welches ist das richtige???

Noch eine Bemerkung zum Kabel, das in den KC-News 4/95 von Dirk Walther vorgeschlagen wurde. Dort wird das Signal DTR des KC mit dem Signal RTS des PC verbunden. Das kann auf gar keinen Fall funktionieren, denn beide Signale sind Ausgänge des jeweiligen Rechners - die armen Treiber...

Da ich für meine Versuche die Betriebssystemebene des DOS-PC benutzen möchte, habe ich mich zunächst einmal für die Kabelvariante (c) entschieden. Dieses Kabel verbindet außerdem noch die Signale RTS, DSR und DCD direkt am Stecker der PC-Seite. Sobald eine Verbindung aufgebaut wird, soll die vom PC selbst aktivgeschaltete Leitung RTS dafür sorgen, daß dieser die Betriebsbereitschaft der Gegenstelle an seinen Eingängen DSR und DCD erkennt (ein sogenanntes loop back).

Für meine Versuche stand mir bis jetzt nur ein etwas älteres PC-Modell, ein XT mit DOS-Version 3.2, zur Verfügung. Das folgende muß also nicht repräsentativ für moderne PCs sein. Es trat folgendes Problem auf: Beim Empfang von Daten schaltet der PC das Signal RTS nicht aktiv, sondern tut dieses erst beim Senden. Danach bleibt dieses Signal für alle Zeit aktiv, auch beim Empfang. Soll der PC nach einer Initialisierung nun aber zuerst empfangen und danach erst senden, erkennt er die ,,Betriebsbereitschaft der Gegenseite`` nicht und ein Empfang von Daten ist nicht möglich. Deshalb habe ich das Kabel noch etwas modifiziert: Statt RTS benutze ich DTR - das eigentliche Handshake-Signal - dazu, dem PC die Bereitschaft der Gegenstelle ,,vorzugaukeln`` (Bild 1 (d)). DTR wird nämlich sofort nach dem Initialisieren der Schnittstelle am PC aktiv (!) und bleibt auch während der Datenübertragung stets in diesem Zustand. Dieses Verhalten wird später noch einige Konsequenzen haben, aber es ist zunächst einmal ein zufriedenstellender Betrieb über die serielle Schnittstelle möglich.

So, nun habe ich zum Thema Nullmodemkabel und Handshaking ziemlich viele Worte verloren. Trotzdem sind an dieser Stelle noch viele Fragen offen. Ich möchte daher alle aufrufen, mir ihre Erfahrungen auf diesem Gebiet - insbesondere auch beim Nachvollziehen der noch folgenden Experimente - mitzuteilen, die sicherlich auch für andere Clubmitglieder von Interesse sein dürften.

Initialisierung der Schnittstelle und einfacher Filetransfer

Nachdem wir nun das (hoffentlich) passende Kabel sowie KC und PC damit verbunden haben, kann es auch schon mit der Datenübertragung losgehen. Zuerst müssen die seriellen Schnittstellen beider Rechner initialisiert werden. Am KC geschieht das z.B. mittels DRIVER.COM und einem der neuen Koppeltreiber von Mario Leubner (siehe KC-News 2/98):

A0>DRIVER V24H24A.KOP

Damit ist der Kanal A des V.24-Moduls mit 2400 Baud zur Kopplung initialisiert. Um am PC auf Betriebssystemebene mit der seriellen Schnittstelle zu arbeiten, wird diese mit dem MODE-Befehl und den passenden Parametern eingerichtet:

C:\>MODE COM1:2400,N,8,1,P

Im Beispiel ist es also die Schnittstelle COM1, die auf eine Übertragungsrate von ebenfalls 2400 Baud eingestellt wird. Die weiteren Parameter ,,keine Parität`` (N), ,,8 Datenbits`` (8) und ,,1 Stopbit`` (1) entsprechen genau den Werten, die auch der KC-Treiber verwendet. Das ,,P`` als abschließender Parameter bewirkt, daß sich der PC ,,tolerant`` gegenüber einem nicht empfangsbereiten KC verhält, also beim Senden in Richtung KC auf dessen Bereitschaft wartet und nicht mit einer Fehlermeldung abbricht.

Nun können wir zwischen KC und PC Dateien senden; zunächst soll es sich dabei mal um Textdateien handeln. Für die Übertragung der Datei TEXT.TXT vom KC zum PC sind dazu die Kommandos

C:\>COPY COM1 TEXT.TXT        (für den empfangenden PC)
A>KCSEND TEXT.TXT             (für den sendenden KC)

zu verwenden. In der Gegenrichtung wären das die Kommandos

A>KCEMPF TEXT.TXT             (für den empfangenden KC)
C:\>COPY TEXT.TXT COM1        (für den sendenden PC)

An dieser Stelle können wir zunächst das Funktionieren des Handshakings überprüfen.

Bei der Übertragung vom KC zum PC habe ich kein wirksames Handshaking feststellen können. Das Signal DTR wird am PC sofort beim Initialisieren aktiv (+ 12V) und verbleibt danach ständig in diesem Zustand. Der KC geht also stets von einer empfangsbereiten Gegenstelle aus. Als Konsequenz daraus darf das Senden am KC erst gestartet werden, nachdem am PC das Empfangen eingeleitet wurde. Sonst sendet der KC ,,ins Leere``. Auch bei der Übertragung selbst ,,bewegt`` sich DTR am PC nicht. Ich habe allerdings auch keinen Datenverlust - auch bei sehr großen Dateien (siehe unten) - feststellen können. Offenbar wird der PC mit der effektiven Übertragungsrate des KC spielend fertig.

Bei der Übertragung vom PC zum KC funktioniert dagegen das Handshaking erwartungsgemäß. Ist das Signal DTR am KC inaktiv (- 12V), unterbricht der PC die Datenübertragung. Man kann das am KC einfach testen, indem der Empfang manuell unterbrochen wird, z.B. durch Aktivieren des Druckermanagers DRUCK mit der Tastenkombination <Shift>-<CLR> während des Empfangs. Der KC bedient dann die Koppelschnittstelle nicht mehr, solange das Fenster auf dem Bildschirm zu sehen ist. Erst nach dem Verlassen des Druckermanagers geht die Übertragung weiter. Wenn bei einer solchen Aktion kein Datenverlust in der empfangenen Datei festzustellen ist, ist das Handshaking zumindest in dieser Richtung in Ordnung. Der Taschenrechner HPKC eignet sich übrigens nicht zu diesem Test, da er mittels <BRK> verlassen wird. Diese Tastenbetätigung wird aber auch von der Schnittstelle erkannt und die Übertragung daraufhin grundsätzlich abgebrochen.

Das nächste Problem, das an dieser Stelle deutlich wird, ist die Behandlung des Dateiendes und die Beendung der Übertragung. Wenn der KC sendet, dann überträgt er, sobald er das Ende einer Textdatei erkannt hat, das Zeichen EOF (1AH) und beendet die Übertragung. Das ist auch genau das, was das Programm COPY am PC erwartet: Erst wenn es dieses Zeichen erkannt hat, werden die empfangenen Daten in die Datei geschrieben. Leider verhält sich COPY in der Gegenrichtung nicht so kooperativ. Es erkennt zwar das Dateiende - entweder logisch durch ein vorhandenes EOF in der Textdatei oder physisch durch die Dateigröße - und beendet daraufhin die Übertragung, es sendet aber unter keinen Umständen ein EOF an den KC. Dieses Verhalten von COPY ist total unverständlich, da es auch die Kopplung zweier PCs in der gleichen Weise erschwert. Um die Übertragung auch am KC zu beenden, bleibt uns also zunächst nur das Drücken der BRK-Taste.

Übertragung von Binärdateien

Will man nicht nur Texte, sondern beliebige Binärdateien, also z.B. auch Programme übertragen, dann gibt es Probleme mit dem EOF-Zeichen. Wenn es zufällig in der Datei vorkommt, wird die Übertragung beendet. Sendet der PC, läßt sich des Problem durch einen Zusatz beseitigen:

C:\>COPY PROGRAMM.COM COM1 /B

Nun werden die aus der Datei PROGRAMM.COM gelesenen Zeichen als Binärdaten behandelt, d.h. das Zeichen EOF (1AH) wird mit übertragen. Das Ende der Übertragung erkennt der sendende PC jetzt nur am physischen Dateiende (Dateigröße). Am KC können wir die so gesendeten Daten mit dem Kommando

A>KCEMPF PROGRAMM.COM S

empfangen. Diese Übertragung kann am KC nur mit der BRK-Taste beendet werden. In der Gegenrichtung fehlt allerdings eine Möglichkeit zum Übertragen von Binärdateien. Zwar können wir dem Programm KCSEND durch Nachstellen der Option S mitteilen, daß es eine Binärdatei senden soll, am PC fehlt jedoch die Möglichkeit, dem Programm COPY das Ende der Datei anzuzeigen. Die Variante, die Übertragung mittels Tastendruck abzubrechen, existiert hier nicht.

Die Problematik mit den Binärdateien ist so alt wie die Datenübertragung selbst. Es gibt daher bereits eine große Anzahl von Verfahren, mit denen diese Schwierigkeiten in den Griff zu bekommen sind.

Am einfachsten ist es, die Binärdatei vor der Übertragung in eine Textdatei zu konvertieren und diese nach der Übertragung im empfangenden Rechner wieder in die ursprüngliche Binärdatei zurückzuverwandeln. Voraussetzung für eine ,,systemübergreifende`` Datenübertragung, wie wir sie vorhaben, ist natürlich, daß auf beiden Seiten mit der gleichen Konvertierungsmethode gearbeitet wird.

Das bekannteste Konvertierungsverfahren für diesen Zweck ist die UUENCODE-UUDECODE- Methode. Es verwendet zwei Programme, die üblicherweise UUENCODE und UUDECODE heißen. UUENCODE übersetzt eine Binärdatei in eine Textdatei, in der sich nur noch sogenannte ,,druckbare`` Zeichen befinden. UUDECODE macht diesen Vorgang rückgängig und erzeugt wieder die ursprüngliche Binärdatei. Die entstehenden Textdateien haben stets den Namen der Originaldatei mit der Dateierweiterung UUE. Die Kommandos zur Konvertierung sind unter CP/M und MS-DOS identisch:

A>UUENCODE TEST.COM       

      C:\>UUENCODE TEST.COM

A>UUDECODE TEST.UUE       

      C:\>UUDECODE TEST.UUE

Das Ergebnis von UUENCODE ist eine Textdatei, die prinzipiell wie folgt aussieht:

begin 644 TEST.COM
M*@8`^0``PPP!PP``S6(#S;@(PWL$0`VX!T`-1@W#=P3#9P3#E@3#X`3#Q03#
M(^7K"7XC9F_)X5XC.LF``E^(V9OR2$!`,@KR2$``,@CR2$!`-@KR2$``-@C
MR2$!`/`KR2$!`/@KR1$!`,@;R1$``,@3R1$!`-@;R1$``-@3R1$!`/`;R1$!
MS70,T--_#,')S0H#Q0X"7_X*PK@,'@W-!0`.`AX*S04`P`G--P/%*@$`*RLK
M.E`&1XA`7Q8`&W4J4@9$32'B#./I;R8`PKG-"@/%(RM\MQ+N#,')$1`G&WJS
M#@(^"E_-!0`."\T%`+?"-`W!R0X!S04`_@/*(`'!R1H:&AH:&AH:&AH:&AH:
M&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:
%&AH:&LH`
`
end

Die erste Zeile beginnt mit dem Wort ,,begin``, gefolgt von einer dreistelligen Nummer (diese enthält die Zugriffsrechte der Originaldatei für UNIX-Systeme in kodierter Form und ist für alle anderen Systeme bedeutungslos) und dem Namen der Originaldatei. Danach folgt der Inhalt der der Originaldatei in konvertierter Form, sowie das Wort ,,end`` in der letzten Zeile.

Für alle, die es genau wissen wollen, hier noch eine etwas genauere Beschreibung, wie die Konvertierung funktioniert: Die Bytes des Originalfiles werden in Gruppen zu je drei Bytes konvertiert. Drei Bytes ergeben eine Kette von 24 Bits, die in vier Gruppen zu jeweils 6 Bits - also in vier 6-Bit-Dualzahlen - aufgespalten wird. Diese 6-Bit-Zahlen können Werte zwischen 0 und 63 annehmen. Zu jeder dieser Zahlen wird 32 addiert, so daß die entstehenden Zahlen im Wertebereich 32 ... 95 liegen. Diese Zahlen entsprechen den ASCII-Codes ,,druckbarer`` Zeichen, angefangen vom Leerzeichen (ASCII-Code 32) bis hin zum Unterstreichungszeichen (ASCII-Code 95). Die Konvertierung ersetzt also jeweils drei Bytes des Originalfiles durch vier ,,druckbare`` Zeichen. Jeweils 45 Bytes bzw. 60 konvertierte Zeichen werden in der UUE-Datei in einer Zeile angeordnet. Hinzu kommt als erstes Zeichen einer jeden Zeile die Information über die Anzahl der Bytes, die durch diese Zeile verkörpert werden, konvertiert nach dem gleichen Verfahren (45 + 32 = 77, normale 45-Byte-Zeilen beginnen mit einem ,,M``). Die letzte Zeile ist gewöhnlich kürzer, so daß das erste Zeichen ein anderes sein kann.

Die Dekodierung eines UUE-Files kehrt diesen Vorgang um, indem jeweils vier Zeichen in drei Bytes zurückverwandelt werden.

Da UUE-Files gewöhnliche Textdateien sind, können sie auch als solche ohne Einschränkungen über die serielle Schnittstelle übertragen werden. ,,Erkauft`` wird diese Transportierbarkeit allerdings durch eine etwa 33%-ige Zunahme der Dateigröße und damit auch der Übertragungszeit.

Zum Abschluß dieser Problematik noch ein Hinweis: Den ganzen Aufwand mit der Konvertierung von Binärdateien haben wir wegen nur eines Zeichens unternommen, dem EOF-Zeichen. Wenn man sich sicher ist, daß die zu sendende Datei kein solches Zeichen (außer evtl. am Dateiende) enthält, dann kann man Binärdateien auch ohne die eben beschriebene Konvertierung übertragen. Zu dieser Gruppe von Dateien gehören z.B. Textdateien, die Sonder- und Grafikzeichen enthalten (z.B. WordPro-Textdateien). Wegen der verwendeten höherwertigen Zeichencodes (Zeichen, bei denen Bit 7 gesetzt ist), gelten solche Dateien zwar schon als Binärdateien, können für die hier beschriebene Übertragung über die serielle Schnittstelle aber wie Textdateien behandelt werden.

Fernsteuerung des PC

Bis jetzt können wir einzelne Dateien zwischen KC und PC übertragen. Dazu müssen wir an beiden Rechnern entsprechende Kommandos eintippen. Viel bequemer wäre es aber, wenn wir das alles von einem Rechner aus erledigen könnten, insbesondere dann, wenn die beiden Rechner räumlich etwas weiter voneinander entfernt sind (bei mir persönlich stehen sie z.B. in verschiedenen Zimmern und das Kabel ist etwa 15m lang...), oder wenn wir bestimmte Abläufe unter Einbeziehung beider Rechner automatisieren wollen. Und da wir natürlich ,,KC-orientiert`` sind, kommt nur eine Fernsteuerung des PC vom KC aus in Frage...

Zu diesem Zweck müssen wir uns überlegen, wie wir dem PC mitteilen, was er für uns tun soll, und wie wir anschließend das Ergebnis am KC erhalten. Da ich ohne viel Programmieraufwand am PC zum Ziel kommen wollte, habe ich mich für einen Ablauf mittels Batch-Dateien entschieden. Drei Batch-Dateien sind dazu notwendig, die sich im Verzeichnis C:\KCNET befinden: START.BAT, LOOP.BAT und RCOM.BAT. Wie diese prinzipiell zusammenwirken, ist in Bild 2 dargestellt.

Bild 2: Die Batch-Steuerschleife im PC

Die Datei START.BAT initialisiert zunächst die serielle Schnittstelle wie oben beschrieben und ruft danach die Datei LOOP.BAT auf:

mode com1:2400,n,8,1,p
c:\kcnet\loop

LOOP.BAT erwartet an der seriellen Schnittstelle Daten und schreibt diese in die Datei RCOM.BAT. Danach ruft sie diese eben empfangene Batch-Datei auf:

copy com1 c:\kcnet\rcom.bat
c:\kcnet\rcom

RCOM.BAT wird also erst während der Abarbeitung von LOOP.BAT erzeugt bzw. bei einem bereits existierenden File mit neuen Daten überschrieben. Diese Datei ist variabel und enthält genau die Kommandos, die wir vom KC aus auf dem PC ablaufen lassen wollen. Soll zum Beispiel das aktuelle Directory zum KC gesendet werden, dann sieht RCOM.BAT wie folgt aus:

dir >com1
copy c:\kcnet\eof.eof /b com1
c:\kcnet\loop

Zunächst wird mit dem Kommando DIR das Directory ausgegeben, aber die Anzeige, die sonst auf dem Bildschirm erscheint, wird mittels einer Ausgabeumlenkung zur seriellen Schnittstelle gesendet. In der zweiten Zeile wird anschließend die Datei EOF.EOF zum KC gesendet. Diese Datei enthält nur ein einziges Zeichen, nämlich EOF. Als Binärdatei gesendet (Option ,,/b``) wird dieses Zeichen auch wirklich an den KC übertragen, der damit den Abschluß der durch das DIR-Kommando gestarteten Übertragung erkennt. Mit dieser Kommandozeile lösen wir übrigens auch das bereits oben genannte Problem des COPY- Kommandos, beim Senden von Textdateien kein abschließendes EOF zu übertragen. Dazu wird diese Zeile einfach jedem COPY-Kommando nachgestellt. Die dritte Zeile schließlich ruft wieder die Datei LOOP.BAT auf. Sie bildet (mit Ausnahme der EXIT-Funktion) stets den Abschluß der Datei RCOM.BAT und schließt die Schleife der beiden Batch-Dateien. Als nächstes erwartet der PC wieder eine neue Datei RCOM.BAT an der seriellen Schnittstelle mit den Befehlen für einen weiteren Zyklus.

Damit ist der PC bereits hinreichend für eine Fernsteuerung vom KC aus vorbereitet. Was jetzt noch fehlt, sind die zu dem beschriebenen Ablauf passenden Aktionen auf dem KC. Ich habe zunächst versucht, die Abläufe auf dem KC ebenfalls mit Stapeldateien zu realisieren und nur bereits vorhandene Programme zu nutzen.

Für die Anzeige des PC-Directories auf dem KC sieht die SUB-Datei wie folgt aus:

;
; MDIR1.SUB:  Anzeige des PC-Directories
;
c0:rm con.txt
c0:kcsend dir.bat
c0:kcempf con.txt
c0:power type con.txt

Mit dem RM-Kommando wird zunächst die Datei CON.TXT gelöscht, damit beim späteren Empfang die Abfrage zum Überschreiben dieser Datei durch KCEMPF entfällt. Danach wird die Datei DIR.BAT zum PC gesendet. Sie enthält genau die Befehle, die der PC als RCOM.BAT abarbeiten soll (siehe oben). Als nächstes geht der KC zum Empfang der PC-Ausgabe über, die er in die Datei CON.TXT schreibt; in diesem Beispiel ist es die umgeleitete Ausgabe des DIR-Befehls. Zum Schluß wird diese Datei mit der TYPE- Funktion von POWER auf dem KC-Bildschirm angezeigt.

Rufen wir diese SUB-Datei mit dem Kommando

A0>SUBMIT MDIR1

auf, so erscheint nach einiger Zeit das Directory des PC auf dem KC-Bildschirm. Damit haben wir die gewünschte Funktion realisiert und im Prinzip wäre es so auch möglich, weitere Funktionen zu programmieren. Aber diese erste Variante hat noch jede Menge Unzulänglichkeiten: Zunächst sind für jede Funktion zwei Dateien erforderlich, eine SUB-Datei für den KC und eine BAT-Datei, die die Kommandos für den PC enthält. Die BAT-Datei läßt sich nicht ohne weiteres konfigurieren und ist ist sehr aufwendig, Parameter aus der CP/M-Kommandozeile in diese BAT-Datei einzusetzen, wie es für viele Funktionen notwendig ist. Außerdem dauert der ganze Vorgang durch die zahlreichen Zwischenschritte unnötig lange.

Um diese Mängel zu beseitigen, habe ich die folgenden zwei Programme geschrieben:

COMSEND.COM

Dieses Programm sendet die nach dem Programmnamen in der Kommandozeile angegeben Zeichen einschließlich eines abschließenden Zeilenumbruchs (0DH, 0AH) über die Koppelschnittstelle an einen anderen Rechner. Bedingt durch den CP/M-Kommandointerpreter werden dabei alle Kleinbuchstaben in Großbuchstaben umgewandelt. Direkt nach dem Programmnamen kann die Option ,,-A`` angegeben werden, mit der nach dem Zeilenumbruch noch ein EOF-Zeichen (1AH) gesendet wird:

COMSEND [-a] <command line>

 

CONEMPF.COM

Dieses Programm gibt alle über die Koppelschnittstelle empfangenen Zeichen auf dem Bildschirm aus. Das geschieht solange, bis ein EOF-Zeichen empfangen bzw. die BRK-Taste gedrückt wird. Nach Ausgabe einer Bildschirmseite wartet das Programm auf eine Tastenbetätigung, um die Anzeige fortzusetzen. Die Option ,,-C`` nach dem Programmnamen bewirkt die Unterdrückung von evtl. empfangenen CLS-Steuerzeichen, um die Anzeige auf dem Bildschirm nicht zu beeinträchtigen:

CONEMPF [-c]

 

Mit der Option ,,-H`` kann bei beiden Programmen jeweils die Ausgabe einer kurze Hilfe erreicht werden, ohne daß die eigentliche Funktion ausgeführt wird. Unter Verwendung dieser beiden Programme sieht die SUB-Datei zur Anzeige des PC-Directories auf dem KC nun wie folgt aus:

;
; MDIR.SUB:  Anzeige des PC-Directories
;
c0:comsend dir >com1
g          copy c:\kcnet\eof.eof /b com1
g -a       c:\kcnet\loop
c0:conempf

Die ersten drei Kommandos (,,g`` sorgt für den erneuten Start des sich bereits im TPA befindenden Programms COMSEND) senden jeweils eine Kommandozeile an den PC (genau die drei Zeilen, die in der ersten Variante in der Datei DIR.BAT standen), wobei die letzte Zeile zusätzlich mit einem EOF-Zeichen abgeschlossen wird und so das Ende dieses Übertragungsvorganges kennzeichnet. Diese drei Zeilen stehen nun im PC wieder in der Datei RCOM.BAT und werden abgearbeitet. Als nächstes erwartet CONEMPF die Reaktion des PCs, um sie direkt, ohne Umweg über eine Datei, auf dem Bildschirm darzustellen.

Um den Vorteil der Konfigurierbarkeit der an den PC zu sendenden Kommandos deutlich zu machen, zeigt das folgende Beispiel die SUB-Datei zum Wechsel des PC-Directories:

;
; MCD.SUB:  Wechsel des PC-Directories
;
c0:comsend cd $1
g          chdir >com1
g          copy c:\kcnet\eof.eof /b com1
g -a       c:\kcnet\loop
c0:conempf

Wird diese Datei mit

A0>SUBMIT MCD ..\TEXT

aufgerufen, erfolgt am PC zunächst ein Wechsel in das übergeordnete Verzeichnis und danach ein Wechsel in das Unterverzeichnis TEXT, da vor dem Senden der Kommandozeilen der Platzhalter ,,$1`` durch ,,..\TEXT`` ersetzt wird. Das CD-Kommando in der ersten Zeile sorgt für den eigentlichen Wechsel des Verzeichnisses, CHDIR in der zweiten Zeile erzeugt noch einmal die Ausgabe des aktuellen Verzeichnisses, die zum KC umgeleitet wird, um über Erfolg oder Mißerfolg der Aktion zu informieren.

In der gleichen Art und Weise habe ich nun noch einige weitere elementare Funktionen zum Dateimanagement zwischen KC und PC als SUB-Dateien realisiert:

MDIR.SUB

Anzeige des PC-Directories

 

MCD.SUB

Wechsel des PC-Verzeichnisses

Beispiel:     SUBMIT MCD ..\TEXT

 

MGET.SUB

Kopieren einer (Text-)Datei aus dem aktuellen Verzeichnis des PCs zum KC; die Datei im KC erhält den gleichen Namen wie im PC.

Beispiel:     SUBMIT MGET TEXT.TXT

 

MPUT.SUB

Kopieren einer (Text-)Datei vom KC in das aktuelle Verzeichnis des PCs; die Datei im PC erhält den gleichen Namen wie im KC.

Beispiel:     SUBMIT MPUT TEXT.TXT

 

MTYPE.SUB

Anzeige einer Textdatei vom PC auf dem KC; die Angabe eines Laufwerkes und/oder Pfades - wie unter MS-DOS üblich - ist möglich.

Beispiel:     SUBMIT MTYPE C:\TEXT.TXT

 

MDEL.SUB

Löschen einer Datei im PC; die Angabe eines Laufwerkes und/oder Pfades - wie unter MS- DOS üblich - ist möglich; der Dateiname muß eindeutig sein.

Beispiel:     SUBMIT MDEL C:\TEXT.TXT

 

MEXIT.SUB

Beenden der Batch-Schleife im PC und Rückkehr in den normalen Eingabemode über die Tastaur; diese Funktion ist die einzige, die nicht als letzte Kommandozeile den Aufruf der Datei LOOP.BAT im PC veranlaßt.

 

Diese Funktionen ermöglichen also ein elementares Dateimanagement zwischen KC und PC. Natürlich läßt sich das Prinzip in gleicher Weise auch zwischen zwei KC realisieren. Dazu sind für den fernzusteuernden KC zwei geeignete SUB-Dateien START.SUB und LOOP.SUB zu erzeugen und die zu sendenden Kommandos in den Dateien M*.SUB an die entsprechende CP/M-Syntax anzupassen. Lediglich die Umleitung der Konsolenausgabe zur Koppelschnitstelle ist wahrscheinlich nur mit ein paar Tricks zu erreichen...

In Ermangelung eines zweiten KC-Systems bleibe ich an dieser Stelle bei der Variante KC - PC. Zum Abschluß dieses Abschnitts möchte ich noch ein etwas komplexeres Beispiel vorstellen, für das ich diese ganze Sache ursprünglich einmal in Angriff genommen hatte. Die Situation ist die folgende: Für den Microcontroller meiner KC-Tastatur bearbeite ich den Assemblerquelltext am KC. Einen Assembler für den Controller gibt es aber nur für MS-DOS, so daß ich den Quelltext nur auf dem PC übersetzten kann. Das EPROM-Programmiergerät betreibe ich wiederum am KC, so daß der übersetzte Objektcode (Binärdatei!!!) im KC vorliegen muß. Die drei notwendigen Abläufe Quelltext zum PC übertragen, Assemblieren und Objektcode zum KC übertragen werden mit der folgenden SUB-Datei automatisert:

c0:comsend c:
g          cd \8048\cherry 
g copy c:\kcnet\eof.eof /b com1 
g copy com1 cherry.asm 
g \8048\asm\asm48 cherry.asm >com1 
g copy cherry.lst com1 
g copy c:\kcnet\eof.eof /b com1 
g uuencode -o cherry.bin 
g copy cherry.uue com1 
g copy c:\kcnet\eof.eof /b com1 
g -a c:\kcnet\loop 
; 
c0:rm cherry.uue cherry.bin 
c0:conempf 
c0:kcsend cherry.asm 
c0:conempf -c 
c0:kcempf cherry.uue 
c0:uudecode cherry.uue

Ich überlasse es dem Entdeckungsdrang eines jeden einzelnen, das Beispiel gedanklich nachzuvollziehen. Als Hinweise nur soviel: Zwischen dem Senden der Kommandofolge an den PC und dem Übertragen des Quelltextes empfängt der KC mittels CONEMPF eine leere Datei, ein einzelnes EOF, ausgelöst durch die dritte übertragene Kommandozeile. Wegen des fehlenden Handshakings bei der Übertragung zum PC verhindert dies, daß der Quelltext CHERRY.ASM bereits gesendet wird, bevor der PC dafür empfangsbereit ist - also eine Art Handshaking auf Dateiebene. Der Assembler \8048\ASM\ASM48 erzeugt neben dem Objektcode CHERRY.BIN auch die Textdatei CHERRY.LST, die eine kurze Statistik über den Verlauf des Assembliervorganges enthält.

Das Beispiel soll vor allem zeigen, daß auch Funktionen mit komplexeren Übertragungsabläufen möglich sind. Wichtig ist, daß man bei der Programmierung den Überblick behält, was zeitlich nacheinander auf beiden Rechnern abläuft, und wie der Ablauf auf beiden Rechnern synchronisiert werden kann. In der SUB- Datei sind dann die Kommandos für beide Rechner getrennt aufgeführt (oberer Teil PC, unterer Teil KC), so daß es durchaus einige Mühe macht, den Gesamtablauf zu rekonstruieren.

MTOOLS

Das Dateimanagement mit den oben beschriebenen SUB-Dateien funktioniert zwar schon ganz gut, aber um die ganze Sache noch etwas komfortabler, schneller und übersichtlicher zu machen, habe ich zu jeder der SUB-Dateien ein COM-Programm erzeugt, das die gleiche Funktion realisiert. Jedem dieser Programme kann durch Aufruf mit der Option ,,-H`` eine kurze Hilfe ,,entlockt`` werden, die auch beim Aufruf mit fehlenden Parametern angezeigt wird.

MDIR.COM

Anzeige des PC-Directories; die Angabe eines Laufwerkes, eines Pfades und/oder Filenames mit Jokerzeichen - wie unter MS-DOS üblich - ist möglich; nach Ausgabe einer Bildschirmseite wartet das Programm auf eine Tastenbetätigung, um die Anzeige fortzusetzen.

Beispiele:

MDIR
MDIR *.BAT
MDIR A:\TEXT\*.TXT

 

MCD.COM

Anzeige des aktuellen Pfades, Wechsel des Pfades oder Wechsel des PC-Laufwerkes.

Beispiele:

MCD                (Anzeige des aktuellen Pfades)
MCD ..\TEXT        (Wechsel des Pfades)
MCD A:             (Wechsel des Laufwerkes)

 

MGET.COM

Kopieren einer (Text-)Datei vom PC zum KC; die Angabe eines Laufwerkes und/oder Pfades - wie unter MS-DOS üblich - ist möglich und wird beim Speichern im KC ignoriert; die Datei wird ins aktuellen KC-Laufwerk geschrieben und erhält den gleichen Namen wie im PC; es gibt keine Beschränkung für die Dateigröße; für jeden empfangenen Sektor (128 Bytes) wird ein ,,#`` auf dem Bildschirm ausgegeben; eine mit ,,#`` gefüllte Zeile entspricht damit 10 KB.

Beispiele:

MGET TEXT.TXT
MGET A:\TEXT\TEXT.TXT

 

MPUT.COM

Kopieren einer (Text-)Datei vom KC zum PC; die Angabe eines Laufwerkes und/oder Userbereiches (Syntax beachten!) ist möglich und wird beim Speichern im PC ignoriert; die Datei wird in den aktuellen PC-Pfad geschrieben und erhält den gleichen Namen wie im KC; es gibt keine Beschränkung für die Dateigröße; für jeden gesendeten Sektor (128 Bytes) wird ein ,,#`` auf dem Bildschirm ausgegeben; eine mit ,,#`` gefüllte Zeile entspricht damit 10 KB.

Beispiele:

MPUT TEXT.TXT
MPUT 1/A:TEXT.TXT            (Kopieren der Datei A1:TEXT.TXT)

 

MTYPE.COM

Anzeige einer Textdatei vom PC auf dem KC; die Angabe eines Laufwerkes und/oder Pfades - wie unter MS-DOS üblich - ist möglich; nach Ausgabe einer Bildschirmseite wartet das Programm auf eine Tastenbetätigung, um die Anzeige fortzusetzen.

Beispiele:

MTYPE TEXT.TXT
MTYPE A:\TEXT\TEXT.TXT

 

MDEL.COM

Löschen einer Datei im PC; die Angabe eines Laufwerkes und/oder Pfades - wie unter MS- DOS üblich - ist möglich; der Dateiname muß eindeutig sein.

Beispiele:

MDEL TEXT.TXT
MDEL A:\TEXT\TEXT.TXT

 

MEXIT.COM

Beenden der Batch-Schleife im PC und Rückkehr des PCs in den normalen Eingabemode über die Tastaur.

 

Der Aufruf von MDIR bringt nun z.B. in kürzester Zeit und ohne störende anderweitige Bildschirmausgaben das PC-Directory zur Anzeige:

A0>mdir

 Volume in Laufwerk C ist harddisk 01
 Verzeichnis von  C:\KCNET

.            <DIR>     21.06.98  23.12
..           <DIR>     21.06.98  23.12
START    BAT       81   9.07.98  23.58
LOOP     BAT       46   8.07.98  18.32
EOF      EOF        1   4.07.98  21.36
RCOM     BAT       63   3.08.98  22.44
        6 Datei(en)   3639296 Bytes frei

Im einzelnen lösen diese Programme die gleichen Aktionen aus wie die entsprechenden SUB- Dateien. Um die Konfigurierbarkeit trotz der jetzt fest einkompilierten Kommandos zu gewährleisten, habe ich die Batch-Dateien im PC noch etwas erweitert. Dazu werden in START.BAT die zwei Systemvariablen KCPATH und KCPORT definiert. Sie enthalten zum einen das Verzeichnis, in dem sich die Batchdateien START.BAT, LOOP.BAT und RCOM.BAT sowie die Datei EOF.EOF befinden, und zum anderen die Schnittstelle, über die der KC am PC angeschlossen ist. Im folgenden wird nun anstelle der expliziten Pfad- bzw. Schnittstellenbezeichnung immer - auch in den vom KC gesendeten Kommandozeilen - der Inhalt der entsprechenden Systemvariable (%KCPATH% bzw. %KCPORT%) verwendet. Damit können die MTOOLS auch verwendet werden, wenn der PC über eine andere Schnittstelle mit dem KC verbunden ist oder die genannten Dateien in einem anderen Verzeichnis stehen. START.BAT hat somit folgenden Inhalt:

set kcpath=c:\kcnet\
set kcport=com1
mode %kcport%:2400,n,8,1,p
%kcpath%loop

LOOP.BAT enthält jetzt die folgenden Zeilen:

copy %kcport% %kcpath%rcom.bat
%kcpath%rcom

Diese Variante befindet sich auch im Archiv auf der Beilagendiskette. In dieser Form ist sie kompatibel mit den oben vorgestellten SUB-Dateien, in denen sich noch die direkten Angaben für Pfad und Schnittstelle befinden. Diese müßten bei Bedarf noch angepaßt werden, was aber leicht mit einem Texteditor zu erledigen ist.

In der vorliegenden Form sind die MTOOLS wegen der Abhängigkeit von einigen Arbeitszellen im Koppel-RAM nur auf dem KC lauffähig. Weiterhin beinhalten sie noch nicht die Übertragung von Binärdateien. Zu letzterem ist noch die Implementierung des UUDECODE- UUENCODE-Verfahrens notwendig. Ich verweise an dieser Stelle schon mal vorab auf das erste Update...

Ausblick

Nachdem wir nun den PC zu einer Art ,,intelligenten Peripheriegerät`` für den KC gemacht haben, dem wir durch Senden von geeigneten Kommandofolgen die gewünschten Reaktionen entlocken können, lassen weitere Wünsche bestimmt nicht lange auf sich warten.

Sehr wünschenswert wäre es natürlich, sich die Kommandozeile des PC direkt auf den KC zu holen. Dann wären wir nicht mehr auf Spezialprogramme für einzelne Funktionen angewiesen, sondern könnten mit einem Universalprogramm gleich die ganze Funktionalität des PC am KC erreichen. Dazu ist am KC ein Terminalprogramm notwendig und für den PC brauchen wir ein sogenanntes Remote-Access-Programm - also ein Programm für den Fernzugriff. Auch darüber wird es mehr in einer der nächsten Ausgaben der KC-News zu lesen geben.

Für heute bleibt mir nur noch, Euch viel Spaß beim Experimentieren zu wünschen und auch noch einmal die Bitte an Euch zu richten, mir und allen anderen Lesern Eure Erfahrungen, Probleme und Hinweise zu diesem Thema (insbesondere zu den Punkten Nullmodemkabel und Handshaking) mitzuteilen.

Umbauanleitungen für das Modul M006/028

von Udo Hoffmann

Umbau des M006/028 (16 KByte ROM) zum M032 (256 KByte RAM)

1. Strukturbyte 79H einstellen:

• dazu wird als erstes der Widerstand R05 ausgelötet und dann der obere Anschluß (wo vorher der Widerstand drinnen war) zu der danebenliegenden Masseleiterbahn auf der Leiterseite, mit Hilfe eines großen Lötkleckses rübergebrückt;
• die Brücke der beiden quadratischen Felder R und M auf der Bestückungsseite muß geöffnet werden (einfach das viele Lötzinn entfernen);
• am Schaltkreis D03 (DL003) die Pins 1 mit 5 und die Pins 2 mit 4, durch kleine Drahtbrücken miteinander verbinden;
• den Ausgang von D03 (DL003) - Pin 6 an Datenbit 7 anschließen (das ist das äußere Lötauge zum Elko hin), auf der Bestückungsseite der Leiterplatte;
• jetzt noch am D03 (DL003) das Pin 12 mit einem kleinen Seitenschneider abknipsen. Nun ist das Strukturbyte 79H eingestellt, am besten gleich mit dem SWITCH-Befehl testen.

2. Steuerbyte-Latch erweitern:

• dazu wird als erstes auf die beiden Schaltkreise D15 und D16 (DL074), je ein DL074 Huckepack aufgelötet (die Huckepack-ICs werden im weiteren der Zuordnung wegen als D15H bzw. D16H bezeichnet);
• vor dem auflöten der beiden DL074 aber unbedingt die Pins 2, 5, 6, 8, 9 und 12 zur Seite biegen und die dünnen Lötfahnen der IC-Pins abknipsen (aus Platzgründen);
• jetzt muß noch das bisher ungenutzte Flip-Flop angeschlossen werden, dazu wird Pin 3 mit Pin 11 am D16 gebrückt;
• an die jeweiligen Eingänge der Flip-Flops (jeweils Pin 2 und 12) werden jetzt die verbleibenden Datenbits (Bit 2, 3, 4 und 5) angeschlossen und zwar wie folgt:
  • Bit 2 an D16H - Pin 2;
  • Bit 3 an D16H - Pin 12;
  • Bit 4 an D15H - Pin 2;
  • Bit 5 an D15H - Pin 12.

3. Einbau der RAM-Schaltkreise (HM628128 bzw. UM621024):

• Voraussetzung für den weiteren Umbau ist natürlich, das die beiden ROM- Schaltkreise U2364 (D18 und D19) vorher entfernt und an deren Stelle zwei IC-Fassungen eingelötet wurden;
• an den beiden RAM-Schaltkreisen müssen jetzt die unteren 5 Pins zur Seite gebogen werden (Pin 1, 2, 30, 31 und 32) und die dünnen Lötfahnen der IC-Pins abgeknipst werden (aus Platzgründen wie bei den beiden DL074);
• jetzt können die RAMs in die Fassungen gesteckt werden, so wie vorher die ROMs drinnen waren;
• als nächstes wird Pin 32 der beiden RAMs mit +5 Volt verbunden;
• dann die zusätzlichen Adressen vom Steuerbyte-Latch an die beiden RAMs anschließen, dazu werden die folgenden Verbindungen hergestellt:
  • D15H - PIN 5 an die RAMs - Pin 31 (Adresse A15);
  • D16H - PIN 9 an die RAMs - Pin 2 (Adresse A16);

   

• die Pins 1 bei beiden RAMs bleiben frei, werden nicht gebraucht.

4. Herstellen der restlichen Verbindungen/Unterbrechungen:

• Pin 30 (Signal CS2) der beiden RAMs müssen an Pin 12 des Schaltkreises D02 (DL000) angeschlossen werden;
• Widerstand R06 auslöten und auf der Bestückungsseite das Lötauge (wo vorher der Widerstand drinnen war) an Adresse A13 der beiden RAMs brücken (Anschluß B12 am Bussteckverbinder der Leiterplatte);
• jetzt kommt der etwas kniffligere Teil, weil auf der Leiterseite einige Leiterbahnen aufgetrennt werden müssen, um sie dann neu anzuschließen;
• zwischen den beiden Lötaugenreihen des D18 befinden sich 4 Lötaugen mit Leiterbahnen, die ca. 1 cm hinter dem Lötauge aufgetrennt werden (ich hoffe, jeder kann an Hand der Beschreibung die richtigen Lötaugen finden);
• jetzt werden die Lötaugen neu angeschlossen, dazu die Leiterplatte so hinlegen, das die Busanschlüsse von mir wegzeigen, mit Blick auf die Leiterseite;
• wir fangen mit dem linken oberen Lötauge (/CS1 - RAM2) an, dieses ist an D16H - Pin 5 anzuschließen;
• das rechts darunter befindliche Lötauge (/OE) wird an Masse angeschlossen;
• das linke von den beiden unteren noch verbleibenden Lötaugen, wird an /WR angelötet (Leitung 8A am Bussteckverbinder der Leiterplatte);
• das rechte noch verbleibende Lötauge (Adresse A14 der RAMs) wird an D15H - Pin 9 angelötet;
• jetzt muß noch die Leiterbahn von D19 - Pin 24 an D02 (DL000) - Pin 6 aufgetrennt werden und D19 - Pin 24 (/CS1 - RAM1) an D16H - Pin 6 angelötet werden.

Das müßte es gewesen sein und jetzt kann mit dem Austesten begonnen werden. Ich habe es so getestet, das ich nach korrekter Erkennung im Programm ML unter MicroDOS, mit Power das ganze RAM-Modul vollgeschrieben habe. Wenn dieses ohne Fehlermeldung funktioniert, dann ist das Modul o.k.

Wie Ihr sicher bemerkt habt, habe ich den Schreibschutz weggelassen, da ich mir unter MicroDOS den Nutzen nicht vorstellen kann, denn hier werden die Dateien ja über die Attribute geschützt und einen direkten Zugriff auf das Modul-Steuerbyte habe ich ja auch nicht.

Jetzt möchtet Ihr natürlich noch wissen, was denn der ganze Spaß kostet. Der gesamte Kostenaufwand beträgt ca. 20,- DM. Die RAMs habe ich bei Reichelt-Elektronic zu je 8,75 DM gekauft, sowie die DL074 zu je 0,42 DM und die IC-Fassungen zu je 0,16 DM das Stück.

Solltet Ihr noch Ideen und Vorschläge oder Tips zu diesem Umbauvorschlag haben, stehe ich dafür natürlich gerne zur Verfügung.

Umbau des M006 (16 KByte ROM) zum M035 (1 MByte RAM)

1. Strukturbyte 7BH einstellen:

• dazu wird als erstes der Widerstand R05 ausgelötet und dann der obere Anschluß (wo vorher der Widerstand drinnen war), zu der danebenliegenden Masseleiterbahn auf der Leiterseite, mit Hilfe eines großen Lötkleckses rübergebrückt;
• die Brücke der beiden quadratischen Felder R und M auf der Bestückungsseite muß geöffnet werden (einfach das viele Lötzinn entfernen);
• am Schaltkreis D03 (DL003) die Pins 1 mit 5 und die Pins 2 mit 4, durch kleine Drahtbrücken miteinander verbinden;
• den Ausgang von D03 (DL003) - Pin 6 an Datenbit 7 anschließen (das ist das äußere Lötauge zum Elko hin), auf der Bestückungsseite der Leiterplatte;
• nun ist das Strukturbyte 7BH eingestellt, am besten gleich mit dem SWITCH-Befehl testen.

2. Steuerbyte Latch erweitern:

• dazu wird als erstes auf die beiden Schaltkreise D15 und D16 (DL074), je ein DL074 Huckepack aufgelötet (die Huckepack ICs werden im weiteren der Zuordnung wegen, als D15H bzw. D16H bezeichnet);
• vor dem Auflöten der beiden DL074 aber unbedingt die Pins 2, 5, 6, 8, 9 und 12 zur Seite biegen und die dünnen Lötfahnen der IC-Pins abknipsen (aus Platzgründen);
• jetzt muß noch das bisher ungenutzte Flip-Flop angeschlossen werden, dazu wird Pin 3 mit Pin 11 am D16 gebrückt;
• an die jeweiligen Eingänge der Flip-Flops (jeweils Pin 2 und 12) werden jetzt die verbleibenden Datenbits (Bit 1, 2, 3, 4 und 5) angeschlossen und zwar wie folgt:
  • Bit 2 an D16H - Pin 2;
  • Bit 3 an D16H - Pin 12;
  • Bit 4 an D15H - Pin 2;
  • Bit 5 an D15H - Pin 12.

3. Einbau der RAM-Schaltkreise (HM628512):

• Voraussetzung für den weiteren Umbau ist natürlich, das die beiden ROM Schaltkreise U2364 (D18 und D19) vorher entfernt wurden und an deren Stelle zwei IC-Fassungen eingelötet wurden;
• an den beiden RAM-Schaltkreisen müssen jetzt die unteren 5 Pins zur Seite gebogen werden (Pin 1, 2, 30, 31 und 32) und die dünnen Lötfahnen der IC-Pins abgeknipst werden (aus Platzgründen wie bei den beiden DL074);
• jetzt können die RAMs in die Fassungen gesteckt werden, so wie vorher die ROMs drinnen waren;
• als nächstes wird Pin 32 der beiden RAMs mit +5 Volt verbunden;
• dann die zusätzlichen Adressen vom Steuerbyte-Latch an die beiden RAMs anschließen, dazu werden die folgenden Verbindungen hergestellt:
  • D15H - Pin 5 an die RAMs - Pin 31 (Adresse A15);
  • D16H - Pin 5 an die RAMs - Pin 2 (Adresse A16);
  • D15H - Pin 9 an die RAMs - Pin 30 (Adresse A17);
  • D16H - Pin 9 an die RAMs - Pin 1 (Adresse A18).

4. Herstellen der restlichen Verbindungen/Unterbrechungen:

• Widerstand R06 auslöten und auf der Bestückungsseite das Lötauge (wo vorher der Widerstand drinnen war) an Adresse A13 brücken (Anschluß B12 am Bussteckverbinder der Leiterplatte);
• einen DL000 Huckepack auf einen beliebigen Schaltkreis auflöten (nur die Betriebsspannungen Pin 7 und Pin 14 anlöten) und die restlichen 12 Beinchen hochbiegen;
• dann Pin 9 mit Pin 13 brücken und nun Pin 10 mit D15 - Pin 5 verbinden und Pin 12 mit D15 - Pin 6 verbinden;
• jetzt kommt der etwas kniffligere Teil, weil auf der Leiterseite einige Leiterbahnen aufgetrennt werden müssen, um sie dann neu anzuschließen;
• zwischen den beiden Lötaugenreihen des D18 befinden sich 4 Lötaugen mit Leiterbahnen, die ca. 1 cm hinter dem Lötauge aufgetrennt werden (ich hoffe, jeder kann an Hand der Beschreibung die richtigen Lötaugen finden);
• jetzt werden die Lötaugen neu angeschlossen, dazu die Leiterplatte so hinlegen, das die Busanschlüsse von mir wegzeigen mit Blick auf die Leiterseite;
• wir fangen mit dem linken oberen Lötauge (CS1 - RAM1) an, dieses ist an den Huckepack DL000 - Pin 8 anzuschließen;
• das rechts darunter befindliche Lötauge (/OE) wird an Masse angeschlossen;
• das linke von den beiden unteren noch verbleibenden Lötaugen wird an /WR angelötet (Leitung 8A am Bussteckverbinder der Leiterplatte);
• das rechte noch verbleibende Lötauge (Adresse A14 der RAMs) wird an D16 - Pin 5 angelötet;
• jetzt muß noch die Leiterbahn von D19 - Pin 24 (CS1 - RAM2) zu D02 - Pin 6 aufgetrennt werden und D19 - Pin 24 an den Huckepack DL000 - Pin 11 angeschlossen werden;
• als nächstes die Verbindung D16 - Pin 9 zu D17 - Pin 13 auftrennen und dieses (D17 - Pin 13) an +5 Volt anschließen;
• jetzt die Verbindung D15 - Pin 5 zu D17 - Pin 10 auftrennen und D17 - Pin 10 an Masse schalten;
• die gebrückten Anschlüsse des Huckepack DL000 (Pin 9 und 13), mit Pin 12 des Schaltkreises D02 (DL000) verbinden.

Das müßte es gewesen sein und jetzt kann mit dem Austesten begonnen werden. Ich habe es so getestet, das ich nach korrekter Erkennung im Programm ML unter MicroDOS, mit Power das ganze RAM-Modul vollgeschrieben habe. Wenn dieses ohne Fehlermeldung funktioniert, dann ist das Modul o.k.

Wie Ihr sicher bemerkt habt, habe ich den Schreibschutz weggelassen, da ich mir unter MicroDOS den Nutzen nicht vorstellen kann, denn hier werden die Dateien ja über die Attribute geschützt und einen direkten Zugriff auf das Modul-Steuerbyte habe ich ja auch nicht.

Jetzt möchtet Ihr natürlich noch wissen, was denn der ganze Spaß kostet. Der gesamte Kostenaufwand ist in diesem Falle nicht so ohne und beträgt ca. 100,- DM. Die RAMs habe ich bei Segor in Berlin zu je 45,- DM gekauft sowie die DL074 zu je 0,42 DM und die IC-Fassungen zu je 0,16 DM das Stück. Bei der Abnahme von min. 10 Stück der RAMs reduziert sich der Preis dann aber auf 31,- DM pro Stück. Wenn also genügend großes Interesse besteht, sollte man die ICs zusammen bestellen oder jemand weiß, wo man sie noch preiswerter bekommt.

Solltet Ihr noch Ideen und Vorschläge oder Tips zu diesem Umbauvorschlag haben, stehe ich dafür natürlich gerne zur Verfügung.

Viel Spaß beim Nachbauen wünscht Euch Udo!

       
Bild 1: Pinbelegungen der SRAM-Schaltkreise HM628128 (links o. oben) und HM628512 (rechts o. unten).

Bild 2: Bestückungsplan des Moduls M006/028

Das LCD-Projekt

von Kai Fischer

Für den ZX81 existiert seit längerer Zeit ein LCD-Interface, das der eine oder andere auch schon auf dem Treffen in Aktion gesehen hat. Passende Displays gibt es relativ billig als komplette Laptop-Deckel mit Hintergrundbeleuchtung und Transverter für 39,- DM (Pollin-Elektronik, ohne Gewähr!). Diese Displays sind in rauhen Mengen für Versicherungsvertreter-Laptops produziert worden und gehen uns daher auch nicht gleich aus. Intern sind es einfache VGA-Displays mit einer Auflösung von 640x480 Pixeln und einer Bilddiagonale von immerhin 9,5 Zoll (oder 19x14 cm). Unterlagen habe ich für einige Typen (Sharp, Epson, Sanyo) hier, die Displays sind alle sehr ähnlich in der Ansteuerung.

Angesteuert wird so ein Display durch einen 8 Bit breiten Datenbus sowie durch drei Steuersignale, die man als Pixeltakt, Zeilentakt und Bildtakt definieren kann. Die 8 Bit Daten teilen sich in je 4 Bit für die untere und obere (je 640x240-) Bildhälfte, was die Ansteuerung nicht gerade vereinfacht. Die Displays benötigen - im Gegensatz zu den kleinen alphanumerischen - eine ständigen Refresh, d.h. die Daten müssen zyklisch geschrieben werden. Kurz gerechnet: Für eine Bildfrequenz von 50 Hz bedeutet dies 50 Hz x 240 Zeilen x (640/4) = 1,92 MHz Pixeltakt. In diesem Takt müssen die 8 Bit am Displayeingang wechseln! Die Sache entschärft sich etwas, da ein LCD aufgrund der Trägheit bereits bei 40 Hz ,,flimmerfrei`` wird, 35 Hz können als noch erträglich gelten. Unterhalb dieser Frequenz nimmt nicht nur das Flimmern stark zu, sondern auch der Kontrast extrem ab (der Mathematiker schreibt: Flimmern = 1/Kontrast).

Die wichtigste Funktion eines Interfaces ist es nun, das im Rechner (=Host? gelernte Informatiker, helft mir...) vorhandene Bildspeicherformat auf das ,,LCD-Format`` (4 Bit oben, 4 Bit unten) zu transformieren und dann mit 2 MHz am Ausgang auszuspucken.

Mit ein paar Tricks habe ich mir die Sache für den ZX81 vereinfacht. Zum einen reichte die halbe Auflösung, also 320 x 240, mehr als aus. Schaltet man einfach je zwei Datenbits parallel, dann fährt damit das LCD in einem 4-Bit-Modus, wobei immer 2 benachbarte Pixel gekoppelt sind. Die Halbierung der Zeilenauflösung macht die Software. Dann besitzt der ZX81 keinen Pixel- sondern nur einen Zeichenspeicher von 768 Bytes, die Zeichen werden erst im Interface selbst in Pixel umgewandelt (megarechenintensiv...). Damit spielt die Sache relativ flott. Das Interface selbst ist ein Z80-Kartenrechner mit 8 MHz Takt, reicht gerade so aus, 12 MHz oder mehr wären mir lieber gewesen...

Das Konzept entstand aus der Not heraus, da ich mir mit der Ansteuersache nicht sicher war, TTL recht komplex geworden wäre, ich etwas programmierbares brauchte, um verschiedene Steuertakte und -sequenzen zu testen und ich halt auch nur Z80 kann...

Drei Nachteile haften dem Interface an: Erstens ist es relativ aufwendig und damit teuer (jenseits der 100 DM), zweitens für Auswertung reinen Pixelspeichers etwa um Faktor 5 (!!) zu langsam und letztlich kann es keine Graustufen darstellen.

Das leidige Thema Graustufen: Die Displays werden als ,,Graustufendisplays`` verscherbelt und tun dies mit einem speziellen Ansteuerchip wohl auch. Nur ist der 8-Bit-Eingang eben digital (0 = Pixel aus, 1 = Pixel an) und Graustufen liesen sich daher wohl nur über einige Umwege, sprich Interlacing realisieren. Sinn der langen Vorrede: Ich habe einige Anfragen auf die Vorstellung des LCD-Interfaces im WWW hin, die aber betreffs ZX81 kaum der Nennung wert sind. Viele suchen sowas für den Spectrum, und wie auf dem KC-Treffen zu erfahren war, dort wäre man auch nicht abgeneigt. Für beide Rechner treffen einen aber die o.g. drei Nachteile besonders hart, da man einen Pixelspeicher und Farbattribute auswerten und darstellen muß. Dafür ist das Interface eben nie gedacht gewesen.

Da aber bis heute noch niemand so richtig in die Gänge gekommen ist und mich die Sache persönlich reizt, würde ich einige hundert Stunden Freizeit in die Entwicklung eines LCD-Interfaces für BEIDE Rechner stecken. Letzten Endes wäre ein Universalinterface denkbar, das auch an einige andere Rechner passen würde. Im Konzept denke ich an ein Spezialchip namens FPGA (für Nichtkenner: sowas wie ein sehr großes und komplexes GAL), vorne den Rechnerbus rein, hinten das Display dran. Solche Tausendfüßler kosten um die 50 DM (Flohmarktpreise unter 10 DM) oder weniger und sind mit normalem Handwerkszeug gerade noch beherrschbar. Ausweichend wäre auch eine reine Logik-Lösung, eventuell mit ein paar GALs denkbar.

Das gesamte Interface könnte damit ohne Display für weniger als 100 DM angeboten werden!

Abschließend nun der Aufruf an alle: Finden sich definitiv mehr als 25 Leute, die sowas haben wollen, dann setze ich mich dran. Weniger lohnt wirklich nicht. Bitte nehmt auch zur Kenntnis: Ich habe mein LCD für den ZX81 und brauche selbst keines für Spectrum oder KC. Finden sich nur 20 Leute, dann ist die Sache begraben. Apropos ,,lohnen``: Ich mache das ohnehin umsonst und will da nicht auch noch zulegen müssen! Je nach Umfang müßten wir auch ein paar Displays mehr finanzieren, als Ersatzteilreserve. Und letztlich wird Pollin 50 Stück zusammen sicher auch preiswerter verkaufen wollen.

Bitte trommelt alles zusammen, was Ihr dafür begeistern könnt! Auch in anderen Clubs: Atari, Commodore, Oric,... das System ist mir egal! Nur kommt mir nicht mit DOS-PC...

Wünschenswert wäre mir ein Mitstreiter aus dem Raum Sachsen-Erzgebirge-Vogtland, der sich mit FPGAs auskennt und eventuell ein Entwicklungssystem mitbrächte. EPROMs kann ich brennen, zweiseitige Platinen bis Schwierigkeitsstufe 9 sind ebenfalls machbar. Die Platine ist ohnehin das kleinste Übel, das Interface könnte etwa Zigarettenschachtelformat haben! Zeit spielt keine Rolle, davon habe ich sowieso viel zu wenig.

Eines noch hinterher. Falls jemand eine Bezugsquelle für FARB-LCDs kennt oder Unterlagen dazu beschaffen könnte, immer her damit. Ein Farbinterface wäre ja wirklich der Hit. Da sage ich mal: das mach' ich auch für 10 Leute und weniger...

Die Legende vom Flug ins Blau

Warum ist Bill Gates der reichste Mann der Welt? Weil an einem bestimmten Tag im Sommer 1980 in Kalifornien gutes Flugwetter herrschte. Das verlockte Gary Kildall mit seinem Privatflugzeug abzuheben und zwei Abgesandte von IBM sitzen zu lassen. Schließlich zogen die grauen Herren beleidigt ab und ließen den Programmierer von CP/M, damals erste Wahl unter den Betriebssystemen für Microcomputer, davonfliegen. Sie wandten sich an Bill Gates von Microsoft, der wenig Ahnung von Betriebssystemen hatte, aber klare Visionen für den Markt. Und den wollte IBM mit einem eigenen Produkt zurückerobern, was mit dem IBM-PC bekanntlich auch gelungen ist.

Natürlich handelt es sich hier um eine Legende, und jeder Autor, der sie erzählt, schmückt sie auf seine Weise aus und beteuert gleichzeitig, seine Version sei die einzig wahre. Vielleicht waren es zwei IBMer, vielleicht auch vier, die vergeblich nach Pacific Grove gefahren waren. Vielleicht war Gary gar nicht in der Luft, sondern auf Geschäftsreise, während seine Gattin Dorothy McEwen, welche die gemeinsame Firma Digital Research Inc. managte, den Herren von IBM die Tür wies, weil sie gerade eine Sitzung mit Leuten von Hewlett Packard hatte und am folgenden Tag in Urlaub fahren wollte. So jedenfalls sieht es Gordon Eubanks, ein ehemaliger Mitarbeiter von Digital Research, später Boss von Symantec.

Nach anderen Quellen weigerte sich Dorothy, ein Geheimhaltungsabkommen zu unterschreiben, das ihr die Abgesandten von IBM vorlegten. Gary, zurück vom Ausflug, wollte sofort unterzeichnen, aber da war es schon zu spät. Tatsache ist: Sie konnten zueinander nicht kommen, Gary Kildalls kleine Digital Research und die große IBM, welche CP/M (Control Program/Microcomputer) für ihr PC-Projekt außerordentlich gut hätte brauchen können. Vielleicht wäre die weltweite PC-Gemeinschaft heute glücklicher mit einem schnellen, zuverlässigen, speichersparenden und robusten Nachfolger von CP/M, wenn es damals im Sommer 1980 - das Datum ist nicht bekannt - in Kalifornien geregnet hätte, und Gary nicht mit dem Sportflugzeug ins große Blau über den Wolken, sondern in die Zukunft mit Big Blue gestartet wäre. Und vielleicht wäre er heute noch am Leben.

Gary Kildall stammte wie Bill Gates aus Seattle, sie lernten sich im Umfeld der University of Washington kennen, wo Kildall 1972 in Computerwissenschaften promovierte. Die beiden späteren Konkurrenten arbeiteten Ellbogen an Ellbogen an einer PDP-10 von DEC - so will es die Legende. Später unterrichtete Kildall an der Marineuniversität von Monterey und begann mit seinen Studenten im Klassenzimmer die neuen Micros von Intel zu programmieren. Gordon Eubanks bezeichnet Gary als brillanten Programmierer, der das erste Betriebssystem für Intels 8-Bit-Prozessoren gleichsam nebenbei aus dem Ärmel schüttelte.

Zu diesem Zweck entwickelte er eine eigene Programmiersprache, PL/M, einen Dialekt von IBM's PL/1. Kompiliert wurde auf dem Großrechner, das Programm dann in EPROMs gebrannt. Obwohl Kildall anfangs nicht so recht wußte, wie er seine Software kommerziell verwerten könnte, gründete er die Firma ,,Intergalactic Digital Research``. Ein Legendenschreiber will sogar wissen, daß er CP/M ursprünglich für ein Astrologieprogramm entwickelt habe, das in Spielautomaten eingesetzt werden sollte. 1974 stand die erste Version von CP/M, das viele Eigenschaften von den Betriebssystemen von DEC geerbt hatte.

CP/M entwickelte sich in den späten Siebzigern zum Standard für 8-Bit-Micros wie Intel 8080 oder Zilog Z-80. Als die ersten Floppy Disk von Shugart Associates auf den Markt kamen, programmierte Kildall ein File-System. ,,Seine Einfachheit und Zuverlässigkeit war ein wichtiger Schlüssel zum Erfolg von CP/M``, schreibt er selber in einem Artikel in der Zeitschrift Byte. 1977 erfand er das Konzept des BIOS (Basic Input/Output System) und überarbeitete CP/M vollständig. Es bestand nun aus zwei Teilen, einem standardisierten Disk-Operating-System, in PL/M programmiert, und dem BIOS, in Assembler geschrieben, das an die spezifische Hardware angepaßt werden konnte. Zum Betriebssystem gehörten fortan auch Editor, Assembler, Debugger und verschiedene Utilities. CP/M lief schließlich auf hundert verschiedenen Systemen, auch auf dem legendären Apple II. Das Wort ,,Intergalactic`` hatte Digital Research inzwischen aus dem Namen gestrichen.

Das erste MS-DOS war mehr oder weniger eine Abkupferung von CP/M. Befehle wie DIR, TYPE, DATE und REN wurden eins zu eins übernommen, andere Eigenschaften mit geringen Anpassungen. ,,Wenig mehr als ein Klon``, schreibt Eubanks. Programmiert hatte den Klon Tim Patterson aus Seattle, der sich geärgert hatte, daß Digital Research nur zögernd in die 16- Bit-Technologie einstieg. ,,Tim wurde praktisch der Vater von MS-DOS``, schreibt Bill Gates in seinem Buch ,,Der Weg nach vorn``. Über seinen ehemaligen Freund Gary Kildall, den Schöpfer von CP/M, schweigt er sich aus. Er erwähnt nur, daß IBM auf ihrem ersten PC auch CP/M-86 anbot als Alternative - allerdings zu 175 Dollars, während MS-DOS nur 60 kostete.

Damit war die Zukunft von Digital Research besiegelt. Die Firma brachte zwar weitere ausgezeichnete Produkte auf den Markt, etwa GEM, ein Windows-ähnliches Benutzerinterface, das anfangs sehr erfolgreich war. Aber die große Chance war vertan, 1991 wurde Digital Research von Novell übernommen.

Gary Kildalls Tod im Jahr 1994 im Alter von 52 Jahren war der Fachpresse kaum mehr eine Notiz wert. ,,Er starb an Kopfverletzungen, die ihm eines Nachts im Ausgang in Monterey beigebracht wurden``, schreibt Eubanks. Andere Versionen seines Ablebens sind je nach Autor: Streit in einer Bar, Sturz von einer Leiter oder Herzanfall. Doch einig sind sich alle: Gary Kildall war der große, unverstandene Pionier der Microcomputer-Software. Gordon Eubanks nennt ihn ,,den Mann, der Bill Gates die Welt schenkte``. Seine Legende lebt weiter.