###   Projekte und Informationen rund um den KC85   ### 

KC85

Projekte

CP/M

KC-News 3/2000

Beitragsseiten


Top-Themen:

  • UNIPIC 2.01
  • MTOOLS - Version 1.3
  • Scannermodul M051
  • Datenverbindung KC-PC über parallele Schnittstellen

Ein paar Worte zur Einleitung

von Frank Dachselt

In diesem Jahr haben wir also nur drei News-Ausgaben geschafft. Die aufgelaufenen Verzögerungen und der ständige Beitragsmangel in der Redaktion ließen leider nicht mehr zu. Ich hoffe, daß die Kopierer trotz Jahresendstreß etwas Zeit finden werden, damit diese Ausgabe noch in diesem Jahr (ich meine 2000) bei Euch ankommt. Denn trotz allem finde ich, daß es wieder eine interessante Zeitung geworden ist.

Natürlich geht dadurch niemanden der Clubbeitrag verloren. Da ja nur die Zeitungen damit finanziert werden, verlängert sich die Beitragsperiode, bis die entsprechende Anzahl von News-Ausgaben erschienen sind (4 Ausgaben pro Jahresbeitrag). Im Zweifelsfall sollte darüber die Zahl auf dem Adresßaufkleber Auskunft geben. Doch nun werfen wir mal einen Blick voraus ins nächste Jahr:

Clubtreffen 2001

Inzwischen haben bereits wieder die Planungen für unser nächstes Clubtreffen begonnen, für das Hendrik Wagenknecht die Organisation übernommen hat. Per E-mail wurden auch schon entsprechende Mitteilungen verschickt, um den Termin abzustimmen. Nachdem die erste Planung für ein Treffen in Halle wegen Nichtverfügbarkeit der ausgesuchten Örtlichkeit fehlgeschlagen ist, steht nun fest, daß das 7. Clubtreffen vom 20. bis 22.4.2001 in der Jugendherberge Naumburg stattfinden wird.

In der Jugendherberge sind für uns 2 Gemeinschaftsräume reserviert, die sich mit einer großen Schiebetür verbinden lassen. Parkplätze sind auch genügend vorhanden. Die Zimmer sind 4- und 5-Bettzimmer mit Dusche/WC und meist mit Doppelstockbetten ausgerüstet. Und nun zu den Preisen:

  • Unterkunft: 22,00 DM pro Nacht
  • Frühstück: 7,00 DM
  • Mittag: 8,00 DM
  • Abendessen: 7,00 DM
  • Bettwäsche: 6,00 DM

Wer eigene Bettwäsche mitbringt, kann die angegebene Ausleihgebühr sparen. Die notwendige DJH-Mitgliedschaft für den KC-Club kostet 50 DM. Dieser Betrag wird von den übernachtenden Teilnehmern aufgebracht und dürfte nicht sehr ins Gewicht fallen (Wir hoffen auf starke Beteiligung!).

Die Anreise ist wie üblich ab Freitag Nachmittag möglich und die Abreise bis Sonntag nach dem Mittagessen vorgesehen. Genauere Informationen zum Ablauf des Treffens und eine detailierte Anreisebeschreibung gibt es in der nächsten News-Ausgabe und können zu gegebener Zeit auch auf unserer Homepage nachgelesen werden.

Die beiliegenden Anmeldeformulare sollten bis zum 31. Januar an Hendrik Wagenknecht geschickt werden. Es ist auch eine Online-Anmeldung über unsere Homepage oder per E-mail möglich. Bitte beachtet, daß die Anmeldung wegen der notwendigen Nutzungsverträge auch eine gewisse Verbindlichkeit besitzt. Sollte sich also etwas an den gemeldeten Teilnahmedaten ändern, dann informiert bitte Hendrik darüber. Außerdem sollten sich auch alle Tagesgäste, die keine Übernachtung planen, anmelden, da ansonsten die Verpflegung in der Jugendherberge nicht garantiert ist.

Nachdem das Titelbild vielleicht noch etwas nachweihnachtliche Stimmung verbreitet, bleibt mir an dieser Stelle nur noch, allen Lesern ein erfolgreiches KC-Jahr 2001 und nun viel Vergnügen beim Lesen dieser Ausgabe zu wünschen!

Euer Redakteur


UNIPIC 2.01

von Ralf Kästner

Bereits in der letzten News-Ausgabe konnte man auf der Beilagendiskette das komplette Archiv UP201.PMA finden. Ich wollte damit ein Versprechen vom diesjährigen Clubtreffen einlösen. Ab sofort ist UNIPIC Freeware - das komplette Archiv darf (unverändert) frei genutzt und weitergegeben werden. Im Archiv befinden sich nicht mehr, wie bisher, nur Updates für registrierte Nutzer, sondern das komplette Programm in der aktuellen Version und die zugehörige Beschreibung.

Da vor der letzten Ausgabe die Zeit wieder mal sehr knapp war, hatte es leider nicht mehr für einen entsprechenden News-Beitrag gereicht. Das soll heute nachgeholt werden. Die Aktualität hatte mich ebenfalls überholt - neuer PCX-Filter, Posterdruck und Scanner-Plugin für das M051 waren vorhanden, aber in der Beschreibung gab es wenig oder gar nichts darüber zu lesen.

Wer zum Treffen dabei war, konnte sich die Neuigkeiten praktisch anschauen. Da es mit zunehmendem Alter immer schwerer fällt, sich alles Gesehene oder Gehörte zu merken, habe ich mich in den letzten Wochen hingesetzt und die Beschreibungen zum PRINT MENU und SCAN MENU komplett neu geschrieben, diesmal auch nicht als Kurzbeschreibung, sondern ziemlich ausführlich und detailliert als richtige Anwenderbeschreibung.

Da Mario Leubner ebenfalls in den letzten News WordPro6 zur allgemeinen Nutzung freigegeben hat, gibt es zukünftig die Beschreibungen für UNIPIC nur noch als TXW-Dateien. Perspektivisch habe ich vor, die gesamte Kurzbeschreibung für UNIPIC 2.0 zu überarbeiten. Ziel ist eine richtige Anwenderbeschreibung für Version 2.01, wo die einzelnen Kapitel thematisch abgegrenzte Bereiche behandeln und in Form einer einzelnen TXW-Datei geliefert werden. Alle TXW-Dateien ergeben dann die komplette Anwenderbeschreibung. Das ist natürlich nicht von heute auf morgen machbar, aber zum nächsten Treffen bin ich sicher ein ganzes Stück weiter.

Wir fangen dann heute schon mal an, auf der Beilagendiskette befinden sich zwei Kapitel:

SCANNER.TXW
Anwenderbeschreibung zum experimentellen Plugin mit Scannermenü in UNIPIC 2.01
DRUCK.TXW
Anwenderbeschreibung zum Druckmenü in UNIPIC 2.01

Zum Ausdrucken benötigt man ein installiertes WordPro6 und in der Regel auch ein RAM-Erweiterungsmodul für den Textspeicher - dort wird nur ein RAM-Modul M011 (64 KByte) oder M022 (16 KByte) akzeptiert, welches im Schacht 08 oder 0C des Grundgerätes stecken muß! Der Beschreibungstext ist bereits formatiert und steuert den Ausdruck über Punkt-Befehle selbst. Dazu benötigt man A4-Papier im Drucker. Nach dem Start von WordPro6 und einladen der TXW-Datei im Text-Menü kann man über das Drucker-Icon sofort drucken. Die beiden ersten Abfragen 'von' / 'bis' bestätigt man mit ENTER, die dritte 'ASCII deutsch' in Abhängigkeit vom Drucker (in der Regel auch ENTER, siehe Beschreibung WordPro). Dann wird das gesamte Kapitel Seite für Seite ausgedruckt.

PCX-Import

Kommen wir zu den Neuigkeiten der Version 2.01. Um den Posterdruck überhaupt sinnvoll einsetzen zu können, benötigt man entweder selbstentworfene übergroße Grafiken (größer als ein KC-Bild von 320 x 256 Bildpunkten) oder man lädt fertige Bilder direkt ein. Bisher konnte das UNIPIC aber gar nicht, bei PCX-Bildern wurden alle Teile größer als 320 Pixel horizontal bzw. 256 Pixel vertikal einfach abgeschnitten.

Der neue Filter kann jetzt PCX-Dateien vollständig laden, beim Import werden die Bilddaten automatisch auf mehrere UNIPIC-Bilder verteilt und zwar von links nach rechts (je 320 Pixel horizontal) und oben nach unten (je 256 Pixel vertikal). Nach dem Import liegen die Bilder bereits so im Speicher, wie sie die Posterdruckfunktion erwartet. Ein anderer Mangel wurde auch noch beseitigt: Der rechte Bildrand wird auch dann sauber übernommen, wenn er nicht mit der Bytegrenze im Speicher zusammenfällt.

PCX-Bilder werden im DISK MENU über das IMPO(rt)-Icon importiert, am Menü ändert sich von der Handhabung her nichts, ich habe deshalb erst mal nur das PRINT und SCAN MENU textmäßig überarbeitet. Mit den folgenden Informationen sollte eine sinnvolle Nutzung der neuen Fähigkeiten möglich sein.

Zu beachten ist, daß erstens genug UNIPIC-Bilder für die Aufnahme der PCX-Daten vorhanden sind und zweitens das Anfangsbild richtig eingestellt ist. Eine Ablage ist nur in aufsteigender Bildreihenfolge ohne Überlauf! möglich, ansonsten kommt eine Fehlermeldung. Man benötigt beispielsweise für ein Bild mit 800 x 600 Bildpunkten (gängige PC-Bildgröße) 9 UNIPIC-Bilder für den Import.

Um die Übersicht beim Import zu erhöhen, wird während des Einlesens der Daten ein Fenster 'PCX-INFO' eingeblendet, dort kann man die wichtigsten Daten zum importierten Bild ablesen. Wenn man das Bild als Poster drucken möchte, sollte man sich die Größen WIDTH (= Breite) für X und HEIGHT (= Höhe) für Y notieren; damit kann man die rechte (X) und untere (Y) Posterdruckkoordinate (= Bildgröße - 1) unkomplizierter eingeben.

Weiterhin gab es noch eine Erweiterung bei den PCX-Farbtiefen: Der Filter akzeptiert jetzt auch Bilder mit 256 Farben, die nach LORES konvertiert werden. Das ist vor allem für die PCX-Dateien des KC-Capture-Programmes von Mario Leubner gedacht; diese PCX-Dateien können damit direkt in UNIPIC eingelesen werden. Für andere PCX-Dateien mit 256 Farben bringt das nicht viel, da der KC die Farben nicht darstellen kann.

PC-Handscanner

Seit dem diesjährigen Treffen steht ja nun das Scanner-Modul M051 offiziell zur Verfügung. Leider konnte mir Enrico Grämer erst zum Treffen einen Prototypen zur Verfügung stellen. Ich hatte für das Treffen aber dann schon mal auf Verdacht etwas vorbereitet. Da sich ohne Hardware eine Software schlecht testen läßt, habe ich mich dabei auf die notwendigsten Sachen beschränkt. Immerhin lief das ungetestete SCAN MENU dann aber wenigstens auf Anhieb, was nur sehr selten vorkommt.

Den Stand habe ich jetzt erst mal dokumentiert - in der Datei SCANNER.TXW als Beschreibung zum experimentellen Scanner-Plugin. Dort findet man alle notwendigen Informationen zur Handhabung der ganzen Angelegenheit, ich möchte deshalb an dieser Stelle darauf verzichten. Im Programm-Archiv der letzten News war das Plugin schon eingebunden als Datei UNIPIC.014 (siehe Beschreibung). Wer das nicht benötigt, einfach diese Datei umbenennen in beispielsweise SCANNER.UP2, dann verzichtet UNIPIC automatisch auf das Laden des Plugins.

Posterdruck

Kommen wir zu dem Teil, der die meiste Arbeit gemacht hat - den Ausdruck von mehreren UNIPIC-Bildern in einem Rutsch auf den Drucker. In der Datei DRUCK.TXW findet ihr nun auch die entsprechenden Informationen, um damit arbeiten zu können. Der gesamte Inhalt zum Thema Druck und Drucker wurde grundlegend überholt. Wer auch mal an ein paar Hintergrundinformationen interessiert ist, sollte das Kapitel unbedingt lesen, wenn irgendetwas nicht geht oder unklar ist, sowieso - es werden eigentlich alle möglichen Probleme angesprochen.

Ursprünglich wollte ich noch ein Druckbeispiel mit aufnehmen, da der Text aber schon sehr umfangreich ausgefallen ist, habe ich darauf verzichtet und werde dafür einfach mal die KC-News nutzen, dazu sind sie ja schließlich da.

In ein paar Wochen ist das historische Jahr 2000 vorbei, vorher steht wie immer im Dezember Weihnachten an. Für diesen Anlaß habe ich mal acht passende Bilder aus meiner Sammlung ausgesucht und in das Archiv WEIHNACH.PMA auf die Beilagediskette gepackt. Dieses Archiv muß unter CP/M entpackt werden, zum Vorschein kommen dann die entsprechenden PCX-Dateien, die man nun im DISK MENU von UNIPIC 2.01 über IMPO vollständig einladen und im PRINT MENU dann auch ausdrucken kann.

U.a. gibt es auch das Bild WMANMENU.PCX, es stellt den Weihnachtsmann mit einer Speisekarte dar und kann z.B. eine Einladung zum gemeinsamen Weihnachtsessen verschönern. Zunächst ist also UNIPIC 2.01 zu laden und zu starten. Falls noch nicht geschehen, weist man im MAIN MENU gleich seinem Drucker die entsprechende Schnittstelle zu.

Anschließend ruft man das DISK MENU auf und stellt links unten das Laufwerk und den Userbereich mit WMANMENU.PCX ein, das kann man rechts unten in der Dateiliste auch kontrollieren. Bei vielen Dateien im Userbereich kann man als Anzeigemaske für die Dateiliste beispielsweise *.PCX eingeben, dann werden nur noch PCX-Dateien in der Liste angezeigt.

Wenn man das Bild gefunden hat, ruft man Funktion IMPO(rt) auf, kontrolliert, ob rechts in der Liste die PCX-Option aktiv ist und markiert dann links im Dialog das gewünschte Bild für den Ladevorgang mit <ET> oder linker Maustaste, über der Dateiliste wird die Anzahl der markierten Dateien angezeigt - dort muß dann '0001' stehen. Wenn das alles erledigt ist, kann man mit der Schaltfläche <OK> den Import starten. Ich habe jetzt stillschweigend vorausgesetzt, daß Bildnummer 1 eingestellt war und nach oben mindestens 9 Bilder vorhanden sind, wer weniger als neun Bilder frei hat, bekommt eine Fehlermeldung wegen Speichermangel.

Während des Imports sieht man nun ein PCX-INFO Fenster mit den wichtigsten Daten aus dem PCX-Header. Die ersten beiden Zahlen hinter WIDTH: 849 und HEIGHT: 710 sollte man sich für den Posterdruck gleich notieren, später dazu mehr. Wenn der Import abgeschlossen ist, befindet man sich wieder im DISK MENU und kann mit <BRK> oder rechter Maustaste über denn Menü-Manager gleich in das PRINT MENU wechseln.

Dort angekommen kann man rechts unten in der Bilderliste den erfolgreichen Import von WMANMENU sehen. Das vor dem Import eingestellte Bild enthält den ersten Teil WMANMEN1 und die folgenden acht Bilder den Rest bis WMANMEN9. Wer möchte, kann sich die einzelnen Teile mit der Funktion VIEW auch anschauen, wenn man mit dem Pfeil vorwärts von Bild zu Bild blättert, kann man sehr schön optisch erkennen, wie UNIPIC die einzelnen Teile des PCX-Bildes auf die UNIPIC-Bilder verteilt - in diesem Fall 3 Zeilen mit je 3 Bildern, wobei ganz rechts und unten noch Platz übrigbleibt, den das PCX-Bild nicht benötigt.

Kommen wir zum Ausdruck und damit zu den Druckeinstellungen. Ganz wichtig ist die richtige Einstellung der EMULATION ESC/P oder ESC/P2, was in der Beschreibung ausführlich erklärt wird, ebenso wie die beiden Werte für TOP und LEFT MARGIN, darauf möchte ich jetzt nicht eingehen.

Wir wollen das Poster im Hochformat drucken, also FORMAT auf 'HORIZ.', da das Bild nur in schwarzweiß ist, reicht für DUMP 'MONO' und es soll normal gedruckt werden also 'pos.' ein. Den Ausdruck starten wir gleich in hoher Qualität, bei ESC/P kann man Vollgas geben - VER dpi auf 144 und HOR dpi auf 240, bei ESC/P2 reichen 180 dpi für beide Richtungen. An dieser Stelle müssen wir uns keine Gedanken mehr um die Druckgröße des Bildes machen, das erfolgt alles später, hier kann man erst mal nach Herzenslust herumspielen.

Bevor wir nun die Posterdruckfunktion aufrufen, kontrollieren wir noch einmal die eingestellte Bildnummer - aktuelles Bild muß das erste Teilbild (WMANMEN1) des PCX-Bildes sein, das ist bei Posterbildern immer die linke obere Ecke!

Wenn alles stimmt, kann es losgehen, POST(er) Icon aufrufen, es erscheint ein Dialog. Hier kann man innerhalb der belegten UNIPIC-Bilder punktgenau eingeben, von wo bis wohin die Koordinaten des Posters reichen. Zuerst stellt man unter PICTURES die belegten UNIPIC-Bilder für X- und Y-Richtung ein, das wären bei WMANMENU 3 x 3 = 9 Bilder, hinter diesen beiden Angaben kann man gleich die maximale Breite und Höhe des sich ergebenden Posters sehen (hier 960 x 768). Da WMANMENU.PCX eine Größe von 849 x 710 Bildpunkten hatte, passen wir die Druckkoordinaten unter COORDINATES entsprechend an. Ein PCX-Bild beginnt nach einem Import immer in der linken oberen Ecke des ersten Bildes, die linke obere Ecke des Posters ist damit auch 0000/0000 (ersten beiden Werte für X/Y). Die rechte und untere Endkoordinate des Posters entspricht dann der Bildgröße - 1, da die Koordinate 0 dort auch mitzählt. Wir geben deshalb bei X ganz rechts 848 und bei Y darunter 709 ein.

Wenn man auf die Schaltfläche MAX drückt, werden von UNIPIC automatisch die Maximalkoordinaten eingetragen. So kann man zwar auch drucken, allerdings dauert der Ausdruck länger als notwendig und was viel wichtiger ist, die leeren Flächen in den UNIPIC-Bildern gehören dann auch mit zum Posterbild und fließen damit in die Berechnungen für die Größe des Druckbildes ein, was sicherlich in den meisten Fällen unerwünscht ist.

Wenn alles eingegeben ist, kann man mit Hilfe von 'OK' bestätigen und gelangt in den Druckdialog. Hier kann man nun die Größe des Druckbildes einstellen, sowie seinen Abstand vom oberen und linken Papierrand. An dieser Stelle nur ein Vorschlag, in der Beschreibung gibt es ausführliche Informationen zu den einzelnen Eingabemöglichkeiten.

Unser Beispielbild soll in der oberen Hälfte des Blattes mittig gedruckt werden. Ich stelle persönlich immer zuerst die Größe und dann die Ränder ein. Der Schalter 'proportional' muß eingeschaltet sein, damit das Bild nicht verzerrt gedruckt wird, hinter SIZE steht die Option auf 'mm', damit man die Größe direkt in mm eingeben kann. Hinter WIDTH wird die Druckbreite eingegeben, das sollen hier 160 mm sein, dann bleiben bei 210 mm Papierbreite (A4) links und rechts jeweils 25 mm übrig. Dort müssen für den nichtbedruckbaren Bereich (siehe Beschreibung) links noch etwa 8 mm berücksichtigt werden, als linker Rand wird hinter LEFT deshalb ein Wert von 17 mm eingegeben. Für den oberen Rand trifft sinngemäß das Gleiche zu, hier tragen wir mal hinter TOP 28 mm ein, dann ergibt sich je nach Drucker ein oberer Rand von ca. 40 mm. Die Bildhöhe rechnet UNIPIC bei 'proportional' ein automatisch aus, je nach Geschmack kann man den oberen Rand entsprechend anpassen, so daß das Bild im oberen Bereich des Blattes richtig positioniert wird.

Das waren dann auch schon alle Eingaben, UNIPIC kümmert sich hier um die Berücksichtigung der Druckerauflösungen und Seitenverhältnisse der Bilder, man muß eigentlich nur noch seine Wünsche eingeben und kann losdrucken und das jetzt im Bereich von 1 x 1 bis 2560 x 2048 Bildpunkten, solange man die internen Grenzwerte nicht über- oder unterschreitet, ist ein sehr angenehmes Arbeiten möglich.

Unser Posterdruck wird schließlich mit 'OK' gestartet, vorher Drucker auf 'online' und Papier einlegen! Dann kann man allerdings auch getrost Kaffee trinken gehen, da der Ausdruck doch eine ganze Weile dauern kann - das ist letztendlich der Preis, den man für die hohe Leistungsfähigkeit des Programmes auf dem KC zahlen muß. Ich denke allerdings auch, daß die Qualität der Ausdrucke entschädigt, insbesondere wenn man solche großen Bilder wie im heutigen Beispiel zur Verfügung hat. Dort kann man mit den hohen Druckerauflösungen locker auch mal um 400% vergrößern, ohne daß gleich jedes Pixel deutlich sichtbar ins Auge springt.

Damit möchte ich die nachträgliche Vorstellung von UNIPIC 2.01 verbunden mit einem kleinen Workshop für heute beenden und hoffe, daß alle mutigen Nachahmer und Ausprobierer damit klarkommen und zu den Neuheiten des Programmes leichter Zugang finden. Ich denke mal, es lohnt, sich damit zu beschäftigen. Bildmaterial steht bei mir ausreichend zur Verfügung, so daß bei entsprechendem Feedback zukünftig weitere thematisch zusammengehörige Pakete für die KC-News möglich sind. Solche Anleitungen für bestimmte zielorientierte Tätigkeiten in bzw. mit Hilfe von UNIPIC sind auch kein Problem, teilt mir Eure Schwierigkeiten oder Fragen mit, dann kann ich zielgerichtet hier etwas für alle schreiben, die heute behandelte Thematik beruht u.a. auf Fragen und Anregungen von Herrn Räder.


Testbericht zum Scannermodul M051 und zu UNIPIC 2.01

von Henning Räder

Mit großem Interesse habe ich am KC85 Versuche mit dem M051 durchgeführt. Für den Bau des Moduls und die guten Hinweise danke ich Enrico Grämer und Ralf Kästner bestens. Seit dem ersten Einsatz des M051 vor ca. 14 Tagen arbeitet es unter UNIPIC 2.01 super. Besonders positiv sind die vielfältigen Druckmöglichkeiten, vor allem bezüglich Auflösung, Größe und Intensität des Druckbildes.

Die Beschreibung zu UNIPIC ist sehr umfassend und wirklich Spitze! Wünschenswert wäre eine Beschreibung für die Scannermöglichkeiten. Erfreulicherweise arbeitet Ralf Kästner wohl bereits daran.

Für den Handscannerbetrieb am M051 scheinen solche Scanner mit Umschaltmöglichkeiten optimal zu sein. So konnte ich bereits Abschnitte von Briefmarken in guter Qualität einscannen und ausdrucken.

Mit viel Freude und Schmunzeln habe ich den abgebildeten Briefkopf erstellt und am Epson LQ400 ausgedruckt.


Posterdruck mit UNIPIC 2.01

von Ralf Däubner

Die meisten von Euch haben sicherlich schon die neue Ausgabe von UNIPIC. Neu ist der Posterdruck, der jetzt realisiert wurde.

Also was kann man damit anstellen?

  1. Poster drucken (logisch ;--))
  2. Nachbarn ärgern... (und PC-User)

Als Beispieldatei habe ich eine einfache Schaltung gewählt, die ich am 386-er mittels Handscanner eingescannt habe. Deshalb auch die originale PCX-Datei. Damit kann jeder selbst die Ergebnisse nachvollziehen.

Nun das Ganze in Stichpunkten:

  • Bilder laden (entweder die PCX- oder die 2 HI*-Bilder)
  • in das Poster-Menu gehen (Grundeinstellung ist 'Senkrecht'!)

Also um ein waagerechtes Bild zu bekommen, müßen wir wissen, wie breit das Bild ist. Die Auflösung des KC ist 320 x 256, und das Bild selbst 640 x 256 (in Wirklichkeit ist es größer, da vom PC). Im Normalfall sollte man wissen, wie groß das Poster werden soll. Am einfachsten kann man sich merken, 3 Bilder breit und 3 Bilder lang, um sich zu veranschaulichen, wie es funktioniert.

  • Drucken (und Kaffee trinken oder am Zweitcomputer spielen).

Nun, das war's oder doch nicht!?

Also um ein Poster zu erstellen, kann man - muß aber nicht - einen Zettel und einen Stift nehmen und Skizzen (vor allem für die Übergänge) anfertigen.

Das Beispielbild zeigt eine Schaltung, die es ermöglicht, Programme über die Tape-Buchse einzuspielen, bei denen die Qualität gelitten hat. Der KC braucht 500 mV Spitze-Spitze.

Das zweite Bild ist etwas größer und ist ebenfalls nur zur Festigung des neuen Wissens gedacht, d.h. man kann damit herumexperimentieren.


Scannermodul M051

von Frank Dachselt

Das Thema Scannermodul scheint sich ja inzwischen fast zu einer unendlichen Geschichte auszuweiten, dennoch haben wir mittlererweile ein wichtiges Etappenziel erreicht: Seit nunmehr schon einigen Monaten sind die 20 Module der ersten Serie bei ihren Besitzern angekommen und funktionieren dort nach vereinzelten, meist durch den Selbstaufbau des Bausatzes verursachten Anlaufschwierigkeiten ohne Probleme. "Erste Serie" deutet es bereits an: Enrico Grämer sammelt bereits Vorbestellungen für eine eventuelle zweite Serie des Moduls. Wer also inzwischen Interesse an einem M051 bekommen hat, oder es in nächster Zeit bekommt, der sollte sich bei Enrico melden. Eine solche Serie lohnt sich natürlich erst ab einer bestimmten Stückzahl (in unserem Fall sind es mindestens 10), so daß wahrscheinlich auch noch etwas Geduld gefragt ist. Enrico wird uns natürlich über Stand der Dinge auf dem Laufenden halten.

Ich möchte mich mit diesem Beitrag insbesondere an alle diejenigen wenden, die das Modul mit Controller betreiben und die serielle Schnittstelle nutzen. Informationen zum Scannerbetrieb finden Ihr in anderen Beiträgen dieser Ausgabe.

Die Software im Controller ist zur Zeit noch eine vorläufige Version, die noch nicht alle in den vorangegangen Beiträgen beschriebenen Funktionen enthält. Das betrifft insbesondere die SIO-Betriebsarten. Die realisierten Funktionen laufen dafür aber endlich stabil und fehlerfrei. Die SIO-Funktion des Controllers kann derzeit nur in der Betriebsart "Senden/Empfangen mit RTS/CTS-Handshake und internen Puffer (je 64 Byte)" verwendet werden. Die Programmierung der anderen Betriebsarten ist noch nicht möglich, ebenso der Interruptbetrieb. Es wird also zu gegebener Zeit ein Software-Update geben, mit dem die Controller noch einmal umprogrammiert werden. Wer zum nächsten Clubtreffen kommt, sollte auf jeden Fall sein M051 mitbringen. Ansonsten muß dann der Controller an Enrico oder mich eingeschickt werden.

Auch hat sich die Programmierung der SIO-Betriebsarten, insbesondere die Belegung der Steuer- und Statusbytes gegenüber den zurückliegenden Veröffentlichungen etwas geändert. Die endgültige Fassung liegt noch nicht vor, da sich die günstigste Gestaltung erst bei der Programmierung im Zusammenhang mit den Treibern für den KC ergibt. Es ist aber sichergestellt, daß die jetzt verteilten Treiber aufwärtskompatibel sein werden, also auch mit späteren Controllerversionen funktionieren. Wer unbedingt jetzt schon an die Treiberprogrammierung Hand anlegen möchte, sollte sich daher zunächst mal an mich wenden, um den aktuellen Stand zu erfahren. Bei dem geringen Funktionsumfang, der bis jetzt zur Verfügung steht, sollte aber jeder mit den mitgelieferten CP/M-Treibern auskommen.

Die gesamte Koppeltreiber-Familie (insgesamt 11 Stück für 11 verschiedene Baudraten) ist in der Datei M051KOP.LBR zusammengepackt und sollte in dieser Form verbleiben. Das spart erheblich Platz auf der Festplatte (nur einmal 4 K statt 11 mal 4 K). Mit DRIVER.COM kann dann ein beliebiger Koppeltreiber aus der LBR-Datei heraus geladen und gestartet werden, z.B.:

   A0>DRIVER M051KOP.LBR M0510096.KOP

Als Parameter wird in der Kommandozeile erst die LBR-Datei und dann der gewünschte Treiber angeben. Die Koppeltreiber heißen alle M051xxxx.KOP, wobei xxxx für ein Hundertstel der Baudrate (mit führenden Nullen) steht. Das fängt bei 0003 für 300 Baud an und geht bis 1152 für 115.200 Baud. Das Beispiel lädt also den Treiber für 9600 Baud.

Als Kabel zur Verbindung zwischen dem M051 und dem PC verwendet man entweder ein handelsübliches Nullmodemkabel, oder man baut es sich selbst. In Bild 1 sind die möglichen Eigenbauvarianten zusammengestellt. Entweder man lötet sich dazu ein neues Kabel mit zwei passenden SUB-D-Steckern zusammen (Variante (a)) oder baut zu einem vorhandenen Kabel zwischen M003 und PC einen Adapter, der die Signale von der 9-pol. SUB-D-Buchse am M051 auf eine 5-pol. DIN-Buchse umsetzt (Variante (b)). Die Belegungen der einzelnen Stecker und Buchsen können in den KC-News 3/98 auf Seite 6 nachgeschlagen werden.

Zu beachten ist, daß das Modul M051 die Leitungen RTS und CTS zum Handshake benutzt. Die anderen Handshake-Leitungen (DTR, DSR und DCD) könnten am Modul zwar unbeschaltet bleiben, aber dann hat das Kabel eine exklusive KC-Seite. Wenn das Kabel auch mit vertauschten Enden funktionieren oder auch mal zur PC-PC-Kopplung Verwendung finden soll, dann müssen die gestrichelt gezeichneten Verbindungen an der KC-Seite ebenfalls vorhanden sein.

 

Kabel

Bild 1: Eigenbau-Kabelvarianten für die serielle Schnittstelle des M051.

Nun noch etwas zum Reset-Problem: Leider hat sich herausgestellt, daß die urspünglich vorgesehene Nutzung der zentralen RESET-Leitung im KC für den Controller nicht geeignet ist. Hier tritt wahrscheinlich ein ähnliches Problem auf wie damals beim RTC-Chip des GIDE-Interfaces. Von den zwei in der Bauanleitung angegeben Ausweichvarianten würde ich des geringeren Aufwandes wegen die mit dem alleinigen Kondensator vorschlagen. Das hat zwar den Nachteil, daß der Controller nur noch beim Einschalten der Betriebsspannung zurückgesetzt wird, aber nach allen bisherigen Tests bin ich der Meinung, daß die Controllersoftware hinreichend stabil funktioniert, so daß das Um- bzw. Neuprogrammieren vom KC aus immer möglich ist. Ich habe in meinem Modul die einfachere Variante verwendet und bisher noch keine Probleme damit feststellen können.

Die Umstellung der MTOOLS auf die Verwendung des M051 ist mit wenigen Handgriffen getan: Nachdem das passende Nullmodem-Kabel zwischen M051 und PC gesteckt ist, muß am KC der Koppeltreiber mit der gewünschten Baudrate geladen und am PC in der Datei START.BAT der MTOOLS diese Baudrate in das ADF-Kommando eingetragen werden. Schon kann es losgehen.

Nun stellt sich natürlich die Frage, was das ganze überhaupt bringt. Die potentiellen Übertragungsraten der Controller-SIO mit bis zu 115.200 Baud klingen ja vielversprechend. Doch an dieser Stelle muß ich die Erwartungen leider erst mal etwas dämpfen. Die tatsächlich erreichte Übertragungsrate wird nicht allein durch die Geschwindigkeit der seriellen Schnittstelle bestimmt, sondern auch von den beteiligten Softwarekomponenten. Und da haben im KC neben dem Koppeltreiber auch die ZAS-Schleife, die BIOS-Routinen und MTOOLS-Programme ihren Einfluß. Die maximalen Übertragungsraten, die ich beim Senden und Empfangen von und zum RAM-Floppy (RF) bzw. von und zur Festplatte (HD) erreicht habe, sind in der folgenden Tabelle zusammengestellt:

  Senden Empfangen
  RF,HD --> PC PC --> RF PC --> HD
MTOOLS v1.2 1550 Byte/s 920 Byte/s 840 Byte/s
  15500 Baud 9200 Baud 8400 Baud
MTOOLS v1.3 1400 Byte/s 760 Byte/s 680 Byte/s
  14000 Baud 7600 Baud 6800 Baud

 

Die Baudrate ist immer etwa 10 mal so hoch wie die Übertragungsrate in Byte/s, da pro Byte acht Datenbits sowie ein Start- und ein Stopbit - also insgesamt 10 Bits - übertragen werden. Daß die MTOOLS der neuen Version 1.3 etwas niedrigere Werte haben, liegt an der neu hinzugekommenen CRC-Berechnung. Doch dazu mehr im folgenden Beitrag.

Mit dem Treiber für 19.200 Baud (M0510192.KOP) wird also zur Zeit bereits die Geschwindigkeitsgrenze erreicht, und es lohnt sich - abgesehen von Tests - nicht, höhere Baudraten einzustellen. Niedrigere Baudraten haben zudem noch den Vorteil, daß die Energie pro übertragenem Bit auf der Leitung größer ist und damit die Fehlerwahrscheinlichkeit sinkt. Allerdings haben nächtelange Dauertests selbst bei der höchsten Baudrate mit einem etwa 10 m langen Kabel keine Übertragunsgfehler gezeigt, so daß man von einer ziemlich sicheren Übertragung ausgehen kann.

Es gibt noch eine Erscheinung, für die ich bisher noch keine Erklärung gefunden habe. Beim Empfangen mit Baudraten oberhalb der effektiv erreichbaren Baudrate (also ab etwa 19.200 Baud) kommt es beim Empfangen (PC --> KC) von längeren Dateien im DOS-Fenster unter WINDOWS mitunter zu einer Fehlermeldung, bei der Übertragung abgebrochen werden muß (mit <BRK> das Programm im KC beenden und dann mit <Cancel> oder <Abbruch> am PC). Die Ursache liegt offenbar im WINDOWS versteckt, denn im DOS-Mode tritt dieser Fehler nie auf. Genauere Messungen haben auch gezeigt, daß das Zeitverhalten der Handshake-Signale in beiden Fällen unterschiedlich ist. Wahrscheinlich gibt WINDOWS trotz des ADF-Treibers noch nicht ganz die Kontrolle über die serielle Schnittstelle auf...

Als Konsequenz empfehle ich allen, die die MTOOLS im DOS-Fenster unter Windows nutzen, die Baudrate nicht höher als 9600 Baud zu wählen. Wer die maximale Geschwindigkeit beim Senden ausnutzen möchte (z.B. bei einem nächtlichen Back-Up), der kann die Baudrate auf 19.200 Baud stellen, sollte dann aber am PC den DOS-Mode verwenden.


MTOOLS -- Version 1.3

von Frank Dachselt

Mit den höheren Übertragungsraten des M051 rücken nun auch verschiedene neue Anwendungen für die Rechnerkopplung in akzeptable Nähe. Die interessanteste davon dürfte sicherlich ein Festplatten-Backup vom KC auf den PC sein. Bisher war für solche Aktionen nicht nur ausreichend Geduld gefragt, sondern auch viel Vertrauen in die Übertragungssicherheit der Kabelverbindung, denn es erfolgte kein Test, ob die Dateien auch fehlerfrei übertragen wurden.

Die MTOOLS der Version 1.3 besitzen nun einen solchen Test. Dieser vergleicht jeweils die CRC-Werte der Quell- und der Zieldatei miteinander und kann auf diese Weise Übertragungsfehler erkennen. Damit schließt die Übertragungssicherheit der Kabelverbindung zu der von Diskette und Festplatte auf. Nun kann man guten Gewissens ein Back-Up mit Hilfe der MTOOLS anlegen und im Ernstfall die Dateien auf dem KC wieder rekonstruieren.

Funktionell geändert haben sich nur die Programme MGET.COM und MPUT.COM, da nur diese Dateien auf den jeweils anderen Rechner übertragen und abspeichern. Trotzdem empfehle ich, alle Programme aus dem Archiv MTOOLS13.PMA zu übernehmen, damit alle Kommandos die gleiche Versionsnummer zeigen. Eine ausführliche Installationsbeschreibung - auch für Neueinsteiger - ist in dem PC-Archiv MTOOLS13.ZIP enthalten. Ich werde im folgenden nur auf die Neuigkeiten eingehen.

Die KC-seitige CRC-Berechnung ist in die Kommandos MGET und MPUT integriert und läuft parallel zum Empfang bzw. zum Senden der Dateien ab. PC-seitig übernimmt das das Programm MCRC.EXE jeweils am Ende einer Übertragung. MCRC.EXE befindet sich im Archiv MTOOLS13.ZIP und muß in das gleiche Verzeichnis kopiert werden, in dem sich auch schon UUENCODE.COM und UUDECODE.COM befinden. Damit ist die CRC-Aufrüstung der MTOOLS bereits erledigt.

Nachdem MGET und MPUT eine Datei empfangen bzw. gesendet haben, werden jetzt neben der Anzahl der übertragenen Bytes auch die CRC-Werte für die Datei auf dem KC (l = lokal) und die Datei auf dem PC (r = remote) angezeigt. Stimmen beide Werte überein, dann war die Übertragung fehlerfrei und die Programme gehen - soweit vorhanden - zur nächsten Datei über. Im Fehlerfall - also bei unterschiedlichen CRC-Werten - wiederholen die Programme die Übertragung der betreffenden Datei bis sie fehlerfrei übertragen wurde oder die maximale Anzahl von Wiederholungsversuchen erreicht ist. Diese Anzahl kann mittels der Option -0 bis -9 beim Aufruf der Programme auf Werte zwischen 0 und 9 gesetzt werden. Fehlt diese Angabe, wird der Vorgabewert 2 benutzt.

An dieser Stelle ein Hinweis zur Angabe von Optionen, der für alle Programme des MTOOLS-Paketes gilt: Sollen mehrere Optionen gleichzeitig angegeben werden (zur Zeit ist das bei MGET.COM und MPUT.COM sinnvoll), dann müssen diese zu einer Zeichenkette mit einem führenden "-" zusammengefaßt werden. Die Reihenfolge der Optionen ist dabei beliebig. Als Beispiel wird mit der folgenden Kommandozeile der Empfang der Datei ARCHIV.PMA als Binärdatei mit maximal 9 Wiederholungsversuchen ausgelöst:

   A0>MGET -B9 ARCHIV.PMA

Sind alle in der Kommandozeile spezifizierten Dateien übertragen, folgt noch eine kurze Statistik, aus der hervorgeht, wieviele der angegebenen Dateien fehlerfrei übertragen wurden, ob es Übertragungsfehler (= Wiederholungsversuche) gab und ob dies letztlich zu fehlerhaften Dateien geführt hat. Kann eine Datei nicht fehlerfrei übertragen, dann wird sie auf dem Zielrechner nicht gelöscht, sondern verbleibt dort in dieser fehlerhaften Form!

Neu hinzugekommen als KC-seitiges Kommando ist das Programm MCRC.COM. Wie der Name bereits vermuten läßt, entspricht es dem Programm MCRC.EXE auf der PC-Seite. MCRC bestimmt für die angegebenen lokalen KC-Dateien (Jokerzeichen sind erlaubt) die CRC- Werte und gibt sie im gleichen Format (Dateilänge, CRC, Dateiname je Datei in einer Zeile) wie das PC-Gegenstück aus. Wie die Kommandos MGET und MPUT arbeitet auch MCRC im Normalfall im Textmode; sollen Binärdateien verarbeitet werden, dann muß die Option -B angegeben werden (dazu später mehr). Im Gegensatz zu den anderen MTOOLS-Kommandos arbeitet MCRC nur lokal und greift nicht auf die Koppelschnittstelle zu. So kann also auch noch nachträglich die Fehlerfreiheit von Dateien auf beiden Rechnern überprüft werden. Für eine größere Anzahl von Dateien protokolliert man günstigerweise die Ausgaben der Programme in Textdateien (auf dem KC z.B. mittels CAPTURE.COM) und vergleicht sie danach mit Hilfe eines der bekannten Differenzprogramme für Textdateien.

Eine Grenze, die bei der Verwendung der MTOOLS zu beachten ist, betrifft die Anzahl der mit einem Aufruf übertragbaren Dateien, wenn Jokerzeichen bei der Angabe verwendet werden. Da alle Dateinamen zunächst im TPA Platz finden müssen, ist diese Anzahl beschränkt. Bei MPUT verwende ich zur Auflösung der Jokerzeichenstrings eine Bibliotheksroutine, die diese Anzahl unabhängig von der resultierenden Länge der Namen auf 513 (= 2^9 + 1) begrenzt. Sollten mehr Dateien der angegebenen Spezifikation genügen, werden die überzähligen Namen ignoriert. Bei MGET habe ich die Dinge dagegen selbst in der Hand und habe hier die alte Beschränkung von 256 Dateien auf jetzt 2048 erweitert. Insgesamt darf die Länge aller Dateinamen aber 24 KByte nicht überschreiten, was bei maximaler Länge der Namen (jeweils 8 + 3) auch etwas weniger als 2048 sein können. Auch bei MGET werden beim Überschreiten dieser Grenzen die restlichen Dateien ignoriert, hier erfolgt aber zumindest eine entsprechende Meldung auf dem Bildschirm.

Back-Up der Festplatte mit den MTOOLS

Bei einem Back-Up überträgt man ja vorzugsweise ganze Verzeichnisse vom KC auf den PC. Das geschieht am besten userbereichsweise mit der Dateiangabe "*.*". Falls jemand mehr als 513 Dateien in einem Userbereich hat, dann müssen diese Dateien geeignet gruppiert und mit separaten Aufrufen von MPUT übertragen werden. Eine solche Gruppierung kann man z.B. anhand der Dateierweiterungen (wenn deren Anzahl in dem betreffenden Userbereich überschaubar ist) oder mit den Anfangsbuchstaben der Dateinamen vornehmen. Z.B.:

   D9>MPUT -B *.PIP          oder          D9>MPUT -B A*.*
   D9>MPUT -B *.PIF                        D9>MPUT -B B*.*
   D9>MPUT -B *.HIP                        D9>MPUT -B C*.*
   D9>MPUT -B *.HIF                            ...
   D9>MPUT -B *.DSH                        D9>MPUT -B Z*.*

Für diese Kommandofolgen legt man natürlich am besten eine SUB-Datei an. Bei der Rückübertragung zum KC kann man dann bis zu 2048 Dateien mit einem Aufruf übertragen. Hat jemand tatsächlich mehr Dateien in einem Userbereich?!

Es empfiehlt sich, bei solchen langwierigen Übertragungen die Ausgaben der Übertragungskommandos in eine Textdatei (auf ein anderes Laufwerk) zu protokollieren, damit man im nachhinein überprüfen kann, ob Fehler aufgetreten sind. So kann man ein Back-Up auch mal über Nacht laufen lassen und braucht den Vorgang nicht ständig beobachten.

Wenn eine Dateiangabe mit Jokerzeichen auch Binärdateien einschließt, dann muß die gesamte Übertragung - wie in den obigen Beispielen - mit der Option -B erfolgen. Auch in diesem Fall kann man die Dateien geeignet gruppieren, damit man Textdateien nicht unnötigerweise als Binärdatei überträgt, was ja durch die UUE-Kodierung etwa 30% länger dauert.

Text-, Binär- und Null-Byte-Dateien

An dieser Stelle möchte ich auch noch einmal auf die unterschiedliche Behandlung von Text- und Binärdateien eingehen, da mit der neu hinzugekommenen CRC-Überprüfung diese Problematik noch etwas verschärft wird. Da im CP/M-Directory die Dateigröße immer nur als ein Vielfaches von 128 Byte (eine Sektorlänge) angegeben ist, müssen für die Bestimmung der exakten Dateilänge spezielle - meist programmspezifische - Kennzeichnungen verwendet werden. Für Textdateien ist es das EOF-Zeichen (1Ah). Gleichzeitig ist EOF auch die Ende-Kennzeichnung für das von uns verwendete Übertragungsverfahren über die serielle Schnittstelle. Aus diesem Grund unterscheiden wir hier überhaupt zwischen Text- und Binärdateien, wobei Binärdateien eben alle die Dateien sind, die nicht zu den Textdateien gehören.

Im Dateisystem auf dem PC wird dagegen die exakte Länge einer Datei gespeichert, so daß die Notwendigkeit spezieller Kennzeichnungen entfällt - auch bei Textdateien. Eine Konsequenz daraus ist, daß Dateien auf dem KC und dem PC unterschiedliche Längen habe können, obwohl sie "logisch" völlig identisch sind. Eine Textdatei vom KC wird deshalb nur bis zum Auftreten des EOF-Zeichens an den PC übertragen und dort mit dieser exakten Länge (ohne das EOF-Zeichen, was auf dem KC Bestandteil der Datei ist) gespeichert. Zwar könnte man eine Textdatei auch als Binärdatei behandeln, dann würde sie auf dem PC die Länge eines Vielfachen von 128 Byte haben. Allerdings erscheinen dadurch am Dateiende zusätzliche zufällige und meist störende Zeichen, da das EOF-Zeichen in Textverarbeitungen oft nicht mehr als solches interpretiert wird.

Bei einem Back-Up auf dem PC, bei dem die KC-Dateien auf dem PC ja nicht weiterverarbeitet werden sollen, stört das natürlich nicht. In diesem Fall können also alle Dateien als Binärdateien übertragen werden, ohne daß Datenverluste oder Nebeneffekte - abgesehen von der längeren Übertragungszeit - auftreten.

Dennoch ist dabei einiges zu beachten, da die CRC-Bestimmung auf beiden Rechnern von der gleichen Dateilänge ausgehen muß, um einen sinnvollen CRC-Wert zu bestimmen:

Textdateien, die als Binärdatei zum PC übertragen wurden, müssen auch in der Gegenrichtung (vom PC zurück zum KC) als Binärdatei übertragen werden. Sollen die CRC-Werte solcher Dateien mit den MCRC- Kommandos auf beiden Rechnern bestimmt werden, dann muß auf dem KC der Binärmode (Option -B) verwendet werden.

Bei Binärdateien, die auf dem PC erstellt oder bearbeitet wurden und anschließend auf den KC übertragen werden, wird während des MGET-Kommandos eine exakte CRC-Bestimmung durchgeführt. Ein nachträglicher CRC-Vergleich mit den MCRC- Kommandos ist dagegen nicht sinnvoll, da sich die Dateilänge auf dem KC im allgemeinen von der auf dem PC unterscheidet.

Beim Transport von Dateien mittels Diskette zwischen den Rechnern, werden diese immer als Binärdatei übertragen. In der Richtung KC --> PC erhält man nur dann die richtigen CRC- Werte, wenn auf dem KC die Option -B im MCRC-Kommando angegeben wird. Nach einem Transport in der Gegenrichtung (PC --> KC) ist der CRC-Vergleich in den meisten Fällen nicht sinnvoll, insbesondere wenn die Datei auf dem PC erstellt oder bearbeitet wurde (siehe vorhergehenden Absatz).

Zu guter Letzt benötigen auch leere Dateien noch etwas Aufmerksamkeit: Werden leere Textdateien (Datei enthält das Byte 1Ah an erster Stelle) oder Null-Byte-Binärdateien (Datei belegt 0 Sektoren) im Textmode (ohne Option -B) von KC auf den PC übertragen, dann wird auf dem PC keine Datei angelegt. Der CRC-Test reagiert darauf mit einer Fehlermeldung und eventuellen Wiederholungsversuchen. Eine eventuell zuvor auf dem PC vorhandene Datei gleichen Namens wird dabei gelöscht.

Leere Textdateien und Null-Byte-Binärdateien müssen darum stets als Binärdatei (mit Option -B) zum PC übertragen werden. Eine solche Textdatei belegt dann auf dem PC 128 Byte, die Binärdatei dagegen bleibt eine Null-Byte-Datei. Wenn eine leere Textdatei vom KC auf dem PC 128 Byte belegt, dann sollte die Rückübertragung zum KC ebenfalls mit der Option -B erfolgen, da anderenfalls zwar die Datei richtig übertragen, aber dennoch ein CRC-Fehler erkannt wird und eventuelle Wiederholungsversuche beginnen.

Die Übertragung leerer Dateien in Gegenrichtung (vom PC zum KC) funktioniert dagegen sowohl im Text- als auch im Binärmode fehlerfrei.

Damit genug der Feinheiten! Wenn sich also einmal unterschiedliche CRC-Werte ergeben sollten, dann muß das nicht unbedingt auf einen Übertragungsfehler hindeuten. Im Gegenteil: Da die Übertragung mit dem seriellen Kabel doch recht sicher erscheint, ist bei einem CRC- Fehler wahrscheinlich einer der obigen Punkte nicht beachtet worden. Ich habe bei meinen Versuchen mit inzwischen mehreren Mega-Bytes übertragener Daten bisher - außer den selbst provozierten - noch keinen echten Übertragungsfehler feststellen können. Trotzdem schläft man natürlich besser, wenn man weiß, daß es den CRC-Test gibt.

Ausblick

Nachdem die Übertragung über das serielle Kabel ausreichend sicher geworden ist, geht es nun um Geschwindigkeit und Komfort. Um die Anwendung der MTOOLS bequemer zu machen, habe ich mir für die nächste MTOOLS-Version eine Log-Datei und die halbautomatische Erkennung von Text- und Binärdateien vorgenommen. Außerdem gibt es verschiedene Reserven für höhere Geschwindigkeiten, die schließlich die Möglichkeiten der vorhandenen Hardware besser ausnutzen werden.


Datenverbindung KC--PC über parallele Schnittstellen - Version 1.0ß

von Sebastian Heßler

1. Einleitung

Bis vor einiger Zeit stand der Kommunikation von Rechnern über die parallele Schnittstelle die Sparpolitik der PC-Hersteller im Wege. Die LPT Schnittstelle war zwar in der Lage, 8 Bit gleichzeitig zu senden, leider konnte sie diese aber nicht empfangen. Was auf dem KC schon lange möglich ist, wurde nun auch auf dem PC realisiert, die LPT Schnittstelle ist bidirektional geworden. Dies brachte mich auf die Idee, Daten über die schnellere parallele Schnittstelle auszutauschen. Die hier vorgestellte Software dient dem Ersatz der LOAD und SAVE Routinen des CAOS. Sicher ist das Verfahren aber auch anders nutzbar.

2. Hardware

Als Verbindung dient ein 11-adriges Kabel, 8 Datenleitungen, 2 Steuerleitungen zur Synchronisation und Masse. Erst wollen wir uns aber die Schnittstellen näher ansehen. Wer hier schon Bescheid weiß, kann die Punkte natürlich überspringen.

2.a Die LPT Schnittstelle des PC

Um den bidirektionalen Betrieb zu ermöglichen, muss die LPT Schnittstelle im BIOS umgestellt werden. Benutzer von älteren Modellen werden hier Probleme haben, soweit ich weiß, ist der bidirektionale Betrieb erst ab Pentium II vorgesehen, aber darauf möchte ich mich nicht festnageln. Die Adressen der LPT1 liegen bei 378...37A. Da die meisten nur eine parallele Schnittstelle haben werden, behandle ich nur diesen Adressraum.

0x378 ist das Datenbyte, hierüber werden die Datenbytes zur Schnittstelle geschickt, und auch von der Schnittstelle ausgelesen, falls die Schnittstelle bidirektional ist. Ansonsten bekommt man das zuletzt gesendete Byte. Dies ist also ein guter Test, ob die Schnittstelle für unsere Zwecke geeignet ist:

  1. Sicherstellen, dass keine Daten zur Schnittstelle gesendet werden;
  2. 32 zum Port 0x37A schicken, um Bidirektionalität einzuschalten ( outp(0x37A,32) );
  3. 0x55 zur Schnittstelle schicken ( outp(0x378,0x55) );
  4. Schnittstelle lesen; Falls sie 0x55 zurückliefert, sieht das nicht gut aus, sonst ist die Schnittstelle bidirektional und 5...6 entfällt;
  5. 0xAA zur Schnittstelle schicken ( outp(0x378,0x55) );
  6. Schnittstelle lesen; Falls sie jetzt 0xAA zurückliefert, ist die mit Sicherheit nicht bidirektional, sonst war der Eingang zufällig auf 0x55 geschaltet.

Falls sich herausstellt, dass die Schnittstelle nicht bidirektional ist, dann sind vielleicht die Einstellungen im BIOS falsch, oder man sollte über eine Aufrüstung seiner Hardware nachdenken. Sonst können eben nur Daten zum KC geschickt werden, das ist ja auch ein Anfang.

0x379 ist das Statusbyte. Hier interessiert uns vor allen Dingen Bit 6, in dem der Zustand der ACKN-Leitung steht (siehe auch 2.c).

0x37A ist das Kontroll-Byte. Hier interessiert uns Bit 0, hier wird das Signal NEG(Strobe) geschrieben. Ist das Bit auf Eins gesetzt, ist die Strobeleitung Low und andersrum. Bit 5 aktiviert die Bidirektionalität, muss also beim Empfangen auf Eins gesetzt werden.

2.b Die PIO-Schnittstelle des KC

Der PIO-Baustein des KC ist vergleichsweise einfach zu handhaben. Er besitzt zwei Ports, der eine wird als Datenport benutzt, der andere verbindet die beiden Steuerbits. Laut DIO-Handbuch, Seite 10 interessieren uns die Ports 04-07. Um einen Port zu initialisieren, wird sein Statusbyte auf 255 für die Bit-Ein/Ausgabe gesetzt. Dann muss an den PIO die Information gesendet werden, welche Bits auf Eingang (1) und welche Bits auf Ausgang (0) stehen sollen. Will man zum Beispiel nur Daten über den Port senden, muss eine Null geschickt werden. Sollen Bit 2 und 4 aber Daten empfangen, so muss eine 20 zum Steuerport gesendet werden, einfach oder?

In meinem Beispiel wird der Port B als Datenport in der LOAD-Routine mit 255 und 255 initialisiert, in der SAVE-Routine mit 255 und 0. Der Port A als Steuerport wird immer mit 255 und 64 initialisiert, da Bit 6 das Stobesignal des PC empfangen soll, und sonst alle Bits auf Ausgang stehen dürfen.

2.c Das Kabel

Als Verbindung schlage ich folgendes Kabel vor: Die KC-seitige Belegung ist dabei sicherlich auch anders möglich, ich musste mich nach meinem leicht defekten Modul richten, bei dem an Port A nicht mehr alle Bits funktionierten.

KC PC Beschreibung
1A + 1B 18...25 Masse
2B...9B 2...9 8 Datenbits
8A 1 PC-Strobe an KC, Bit 6
3A 10 PC-ACKN an KC, Bit 1

 

Da mein Modul eh schon halb defekt ist, habe ich eine männlich kodierte Buchse an die Stelle der Anschlussleiste geschraubt. So kann ein Verlängerungskabel die Verbindung herstellen. Sonstige Bastelideen sind sicher klar: Kleine zweiseitige Leiterplatte ein bisschen sägen, ein bisschen kratzen, ein bisschen löten und fertig. Falls Brücken im Kabel eingebaut werden, wird das durch die Software (siehe 3.b) mit einer Endlosschleife belohnt!

3. Software

Das von mir entworfene Protokoll ist sicher einfach gestrickt, ein Profi (ich bin erst ein kleiner Drittsemester) wird da vielleicht müde lächeln.

3.a Die Routinen Sendbyte und Loadbyte

Folgender Zyklus wird beim Datenaustausch durchlaufen:

  1. Sender wartet auf Empfangsbereitschaft (Empfänger muss auf High schalten);
  2. Sender schickt das Datenbyte;
  3. Empfänger wartet auf Sendebestätigung (Sender muss auf High schalten nachdem er das Datenbyte übertragen hat);
  4. Empfänger liest das Datenbyte aus;
  5. Sender wartet auf Empfangsbestätigung (Empfänger muss auf Low schalten nachdem er das Datenbyte gelesen hat);
  6. Empfänger wartet auf Sendeabschluss (Sender muss auf Low schalten).

Dies funktioniert ganz gut, Daten werden erst gelesen, wenn sie korrekt geschrieben wurden. Um einen definierten Beginn zu haben, müssen logischerweise beide Rechner am Anfang der Übertragung ihr Steuersignal auf Low geschaltet haben. Dies passiert auch am Anfang. Dabei entsteht ein kleines Problem: Steht einer der Sender zufällig auf Low, der Empfänger interpretiert dies falsch (siehe auch 3.b) und schaltet auf High, während das Sendeprogramm noch gar nicht läuft, dann hängen beide Programme in unterschiedlichen Schleifen fest, der Empfänger ist auf High und wartet auf High, der Sender ist auf Low und wartet auf Low. Die Methode, den Sender immer zuerst zu starten, ist sicher unbequem.

3.b Das Handshaking

Um dem genannten Problem zu begegnen, habe ich folgendes Handshaking entworfen:

Beide Rechner schalten auf Low und warten auf Low. Dann schaltet der Sender zwischen 0x55 und 0xAA hin und her (ein guter Leitungstest) und wartet auf High des Empfängers (dies ist schon Punkt 1 des Datenaustauschzyklus). Der Empfänger muss sowohl die 0x55 als auch die 0xAA empfangen haben, bevor er auf High schaltet (er initiiert somit den Datenaustauschzyklus). Der Empfänger kann also nichts mehr falsch interpretieren, da sich eine Änderung auf dem Port vollziehen muss, der Worst-case ist damit auf einen Zufall eingeschränkt, dass ein anderes Programm an den Sender Daten schickt, und somit den Empfänger verwirrt. Das sollte vermieden werden.

3.c Einfache Programmierung

Wie Anfangs erwähnt, habe ich die LOAD/SAVE-Routinen des CAOS4.3 ersetzt. Sicherlich arbeitet das Programm auch im Hauptspeicher. Alle Sprünge sind relativ. Nur die CALL-Befehle für die Funktionen SendByte und LoadByte müssen angepasst werden. Diese sind mit Ausrufezeichen im Kommentar gekennzeichnet. Die LOADPC Routine erwartet keine Parameter. Die Startadresse und die Anzahl der zu lesenden Bytes bekommt sie vom PC. Dieser liest die Daten aus dem KCC-Format aus. Die SAVEPC Routine erwartet zwei Parameter, die Startadresse und die Anzahl der zu sendenden Bytes. Der PC speichert dies in dem File KCFILE.KCC.

Wie sicherlich schon aufgefallen ist, ist der Platz im KC-Speicher nicht gerade üppig. Deswegen habe ich auf luxuriöse Programmfunktionen wie einen Abbruch, falls in den Schleifen zu lange gewartet wird, verzichtet. Hat die Übertragung nicht geklappt, muss eben die RESET Taste des KC gedrückt werden, macht ja nichts. Ich glaube SmartDrv ist noch nicht auf dem KC implementiert, oder? ;--)))))))

Die PC-Routinen sind in C geschrieben und mit Borland C++ kompilierbar. Das ganze läuft auch im DOS-Fenster von Windows, anscheinend überwacht Bill Gates den parallelen Port nicht so akribisch.

4. Schlusswort

Bitte seid mir nicht böse, dass ich in das CAOS 4.3 eingegriffen habe. Alle benötigten Dateien liegen bei. Ich hoffe die Softwarekommentare sind ausreichend. Folgende Dateien gehöhren zum Paket:

   load.asm
   load.bin
   caos43pe.bin
   kcload.c
   kcload.exe
   kcsave.c
   kcsave.exe

Das war es erst mal, Verbesserungsvorschläge nehme ich gerne an. Ansonsten würde ich mich über die Umbauanleitung des M011 zum M035 freuen, ich habe Probleme, Daten über den Refresh zu finden.


Und nocheinmal in alten Zeitschriften gestöbert...

von Reinhard Gitter

Siehe auch KC-NEWS 3/95, S. 8/9; Zeitschriftenkürzel: BP = Bit Power, FA = Funkamateur, JU = Jugend & Technik, KL = Kleinstrechner Tips, ME = Modelleisenbahner, MP = Mikroprozessortechnik, NT = Neue Technik, Büro, SE = Sammler Express

Computertechnik der DDR

  • Heimcomputerszene, FA 1/92 ab S. 10, FA 2/92 ab S. 67
  • Kleincomputer, FA 4/87 S. 187, 6/87 ab S. 268, 7/87 ab S. 325
  • Computer in der DDR, CHIP 3/90 S. 14--17, CHIP 5/90 S. 46
  • ... und sie rechnen doch! CHIP 7/90 S. 260--264
  • DDR: Copyrights ausgebremst, CHIP 9/90 ab S. 40
  • Computerviren in der EX-DDR, CHIP 2/91 S. 3/4
  • Homecomputer - ein neues Gebiet, Kl 1/84, KL 2/84, KL 5/86
  • Computermagazine des DDR-Rundfunks, FA 5/89 S. 215
  • Computeroldtimern auf der Spur, BP 9/90 S. 66--69
  • Verwandschaft aus dem Osten, Konrad 8,9/99 S. 134--137

AC 1

  • Funkamateure entwickeln Computer, FA 12/83 S. 586/587

BIC

  • BIC - hält er, was seine Entwickler versprachen? BP 1/90 S. 5/6
  • Neuer Robotron-Computer, MP 7/88 S. 194, MP 10/88 S.292/293
  • Bildungscomputer A 5105, NT 2/89 ab S. 62, KL 11/89 S. 46
  • Grundlage der Informatikausbildung, FA 9/89 S. 428

KC compact

  • KC compact - der neue aus Mühlhausen, FA 1/90 S. 6

KC 87

  • Der Heimcomputer Robotron Z 9001, KL 2/84 S. 51--64
  • Farbausgabe von KC 85/1 & KC 87, MP 5/87 S. 150/151
  • SCART-Buchse anders genutzt, FA 3/91 S. 166
  • Speichererweiterungsmodul am KC 87, MP 9/87 S. 283
  • Standard-Interfaces über den User-Port, MP 10/87 S. 311--316
  • Generiert 24 x 80 Zeichen, MP 6/90 S. 186/187

LC 80

  • Messenachlese, ME 6/84 S. 31
  • Polycomputer 880, KL 3/85 S. 20--31
  • Analog-Digital-Umsetzung, KL 4/86 S. 35--49

ZX 81

  • Computeroldtimern auf der Spur, BP 1/91 S. 78--81

Z1013

  • Mikrorechnerbausatz, KL 7/87 S. 12--20
  • Komfortable Tastatur, KL 9/88 ab S. 53, MP 7/88 ab S. 215
  • Grafikbaugruppe, KL 11/89 S. 38/39
  • Die Maus ist los, FA 4/91 S. 195/196
  • Elektronische Taktfrequenzumschaltung, MP 9/87, MP 12/87
  • RAM-Speichererweiterung, MP 4/88 S. 119--121
  • Temperaturmessung mit Meßmodul, FA 6/92 S. 315/316
  • Sound per PIO, FA 10/91 S. 566/567

U880

  • Was brachte der Mikroprozessor? KL 1/84 S. 6--16
  • Zu einem Interruptproblem, MP 4/87 S. 123
  • Editor für Mikrorechner, MP 9/87 S. 278/279
  • U880-Bussignale, JU 9/85 ab S. 712, JU 10/85 ab S. 791

KC 85/2-4

  • Verbesserungen KC 85/4 gegenüber, KC 85/3 MP 11/88 S. 344
  • MODULE, MP 4,5,8,10,12/87
  • Bustreiberaufsatz D002, MP 5/88 S. 149--151
  • Computerkopplung mit PC1715, MP 5/87 S. 147
  • SCREENS - grafische Bedienoberfläche, FA 10/91 ab 559, 11/91 ab 617

Bauanleitungen

  • Spracheingabe für Mikrocomputer, KL 5/86 S. 11--20
  • Sprache & Musik sampeln mit dem KC, BP 1/91 S. 66/67
  • Sound-Modul für Z80-Rechner, FA 12/90 S. 604--606
  • Mehrfarbdruck mit S/W-Nadeldrucker, FA 3/93 S. 145/146
  • Der Drucker lernt sehen, FA 3/91 S. 133--135
  • Bequemer per Maus, FA 12/91 S. 678/679
  • Commodore-Maus am KC, FA 5/92 S. 263
  • einfacher Joystickanschluß, FA 4/90 S. 168
  • Joystickmodul, MP 4/88 S. 115
  • Joystick-Editor, FA 8/91 S. 446
  • Ferngesteuert - Infrarottastatur, FA 7/90
  • Schalten & walten - Leistungsmodul für Z80, FA 11/91 S. 619--621
  • Signale nach draußen - Relaisausgabekarte, FA 5/92 S. 260/261
  • Echtzeituhr am Heimcomputer, FA 11/90 S. 536/537, FA 1/88 S. 16
  • EPROM-Programmierzusatz, FA 6/89 S. 272--274, FA 3/91 S. 140

Disketten

  • Diskettenformate CP/M-kompatibler Systeme, MP 2/88 S. 35--38
  • Floppy-Disk-Controller U8272D, MP 4/88 ab S. 102, 7/88 ab S. 200
  • PC-Laufwerke - voller Rätsel? FA 12/90 S. 582/583

BASIC

  • Subroutinen des BASIC-Interpreters, MP 6/87 ab S. 182, 7/87 ab 221
  • Sprachübersicht, MP 9/87 S. 280/281, MP 3/88 3. \& 4. Umschlagseite
  • Graphikanwendung, BP 2/90 S. 6/7, BP 3/90 S. 8--11
  • Schön gestalten - Grafik-Utilities, FA 2/91 S. 81
  • Sprite-Grafik mit dem KC, FA 3/90 S. 117/118
  • Zeichensatzänderung, MP 10/88 S. 314
  • Der Kleincomputer als optischer Täuscher, KL 9/88 S. 39--43
  • KC als Morsezeichengenerator, FA 6/88 S. 273/274
  • Nutzung der Tape-LED, MP 9/87 S. 284
  • Mehr RAM-Speicher für BASIC-Programme, MP 4/89 S. 120/121
  • Philatelie & Computer, SE 16/89 ab S. 600, SE 21/89 ab S. 810

Programmieren

  • Programmiersprachen - ein Vergleich, KL 4/86 S. 4--34
  • FORTH - ein Softwarekonzept, KL 10/89 S. 4--21
  • FORTH - eine außergewöhnliche Softwarekonzeption, MP 6/87 S. 163--170
  • FORTH - eine moderne Softwarephilosophie, MP 2/88 S. 35--41, 53--56
  • FORTH83-Kurs, MP 3,5,7,9,11/89, MP 2/90
  • REDABAS/DBASE-Kurs, MP 8/87, MP 1/88
  • Pascal-Kurs, MP 9,11/87, MP 3,6,9,11/88, MP 8/89 S. 236/237
  • TurboPascal-Kurs, MP 6,8,10,12/89, MP 3,5/90, MP 6/89, MP 11/89

Sonstige Themen

  • Fachbegriffe Englisch-Deutsch, FA 6/90 S. 286
  • Gedruckte Schaltungen - Direkt-Toner-Methode, FA 3/94 S. 218/219
  • KC im PC emuliert, FA 2/97 S. 140/141
  • Stilblüten - Disketten gelocht & abgeheftet, FA 1/95 S. 19
  • Mal eine Idee für ein KC-News-Titelbild? FA 8/89 S. 374