KC-News 4/1999

Top-Themen:

• ZILOG läßt die Bytes tanzen
• PCX-Bilderzeugung
• Scannermodul M051
• MTOOLS: Version 1.2

Ein paar Worte zur Einleitung

von Frank Dachselt

Geschafft! Pünktlich zum bevorstehenden Weihnachtsfest sind die letzten KC-News dieses Jahres fertiggeworden. Ich hoffe, daß auch die Kopierer noch rechtzeitig mit ihrer Arbeit fertigwerden, damit Ihr in aller Ruhe die Neuigkeiten lesen und ausprobieren könnt.

Alles andere als ruhig waren dagegen die letzten Wochen für mich und einige andere Clubmitglieder. Bereits in der vorangegangenen Ausgabe habe ich an dieser Stelle über das verstärkte Medieninteresse berichtet, das der KC auf sich gezogen hat. Was ich damals noch nicht wissen konnte: Das alles war nur ein kurzer Vorgeschmack dessen, was noch auf uns zukommen sollte...

Medien

Ausgelöst wurde das erneute Interesse am KC und am KC-Club offenbar durch eine Reuters-Meldung. Vorangegangen war ein etwa einstündiges Telefoninterview, das eine Mitarbeiterin dieser Agentur Anfang November mit mir geführt hatte. Kurze Zeit später hatte ich dann insgesamt vier (!!) weitere Anfragen nach möglichen Interviews vor mir liegen. Wer per E-mail erreichbar ist oder ab und zu mal in das Gästebuch auf unserer Homepage schaut, hat vielleicht schon zu dieser Zeit einen Eindruck von diesen Aktivitäten bekommen. Da ich diesen Ansturm natürlich nicht allein bewältigen konnte, habe ich auch immer versucht, geeignete Kontakte innerhalb des KC-Clubs weiterzuvermitteln.

Das herausragende Ergebnis all dessen war, daß neben verschiedenen Zeitungen und Zeitschriften sowie einem Radiosender auch ein Team des MDR-Fernsehens intensiv um eine Termin gebeten hatte. Da wir dieser Bitte nicht lange widerstehen konnten, und zudem auch mehrere Clubmitglieder zusammen an einem Ort gezeigt werden sollten, haben wir sogar kurzfristig ein kleines Clubtreffen bei Mario Leubner organisiert, bei dem noch Jörg Linder und meine Wenigkeit anwesend waren. Daneben hat das Fernseh-Team aber auch noch einige weitere Clubmitglieder (Udo Hoffmann und Sebastian Czech haben sich freundlicherweise auch noch ,,überreden`` lassen) einzeln besucht und interviewt.

Der ganze Aufwand war notwendig, um schließlich ein kleines 3-Min-Filmchen daraus zusammenzuschneiden, das ziemlich kurzfristig im Nachmittagsprogramm des MDR gesendet werden sollte. Allerdings stellte sich heraus, daß dieser Beitrag so ein Art ,,Lückenfüller`` war und der geplante Sendetermin mehrmals verschoben wurde. Nach zwei Wochen geduldigen Wartens wurde er dann schließlich zwei Tage vor dem Redaktionsschluß dieser News-Ausgabe doch noch gesendet.

Alle, die diesen Beitrag schließlich doch verpaßt haben oder erst jetzt von alle dem erfahren, kann ich beruhigen: Alle veröffentlichten Beiträge, seien es nun Zeitungsartikel, Radio- oder Fernsehberichte liegen uns im Club vor und werden beim nächsten Clubtreffen zu bewundern sein. Und damit wären wir auch schon beim nächsten Punkt...

Clubtreffen 2000

Die Planungen zum Clubtreffen im nächsten Jahr haben in der Zwischenzeit konkrete Formen angenommen. Das Anmeldeformular, das dieser Ausgabe beiliegt, habt Ihr sicher schon entdeckt. Das Clubtreffen 2000 wird also vom 14. bis 16. April im ,,Jugenddorf am Müggelsee`` in Berlin stattfinden. Der Organisator vor Ort ist Axel Hermann. Die in den letzten News genannten Preise gelten auch im nächsten Jahr weiter. Wie üblich, ist die Anreise 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 Anmeldeformulare sollten bis zum 31. Januar an Axel Hermann geschickt werden. Bitte beachtet, daß die Anmeldung wegen der notwendigen Nutzungsverträge auch eine gewisse Verbindlichkeit besitzt. Sollten also im nachhinein noch Veränderungen bei den Teilnahmedaten oder gar eine Verhinderung eintreten, bitten die Organisatoren um eine entsprechende Mitteilung.

An dieser Stelle möchte ich nun noch allen Lesern der KC-News ein frohes Weihnachtsfest und alles Gute für das Jahr 2000 wünschen! Viel Vergnügen beim Lesen dieser Ausgabe!

Euer Redakteur Frank

ZILOG läßt die Bytes tanzen

von Jörg Linder

Am 20. September 1999 erlebte ich bei meinem alltäglichen Streifzug durch die News des Heise-Verlages (www.heise.de) eine Überraschung. Die Schlagzeile ,,Z80: nicht totzukriegen`` prangte über einer Meldung, in der es im weiteren hieß, daß ZILOG auf der Grundlage des Z80-Designs einen neuen Prozessor mit dem Namen eZ80 entwickelt und diesen mit Internetfähigkeiten ausgestattet hat. Ein paar Klicks weiter im World Wide Web war bei ZILOG die Präsentation zu sehen:

Dort ist auch die technische Beschreibung zu finden, der ich die folgenden Informationen entnommen habe.

Der eZ80 gehört zu den schnellsten 8-Bit Prozessoren (für die Technikfans: zunächst 80 MIPS), die derzeit erhältlich sind. Bei gleichem Takt führt der implementierte Z80-Kern die Befehle viermal schneller aus als eine originale Z80-CPU. Durch höhere Taktraten ist sogar die 16-fache Leistung möglich. Hinzu kommt der 16 MB große, lineare Adreßraum, der entsprechend des gewählten Betriebsmodus Z80-kompatibel (64 kB), Z180-kompatibel (1 MB MMU) oder vollständig (24 Bit, 16 MB) verwaltet werden kann.

Neben der eigentlichen Recheneinheit (ALU, Arithmetic Logic Unit) verrichtet parallel dazu ein digitaler Signalprozessor in Form des MAC (Multiply and Accumulate Core) sein Werk. Additionen mit 40 Bit sowie 16-mal-16-Bit-Multiplikationen können damit berechnet werden.

Den Aussagen von ZILOG zufolge bildet der eZ80-Prozessor die Grundlage für eine ganze Familie von Microprozessoren. Diese werden mit unterschiedlicher Peripherie ausgestattet sein: UARTs, DMA, Serial I/O, Analog-Modem, Digital-Modem, A/D, D/A, Timer, I2C, MMU, Echtzeituhr usw. Ganz offensichtlich ist der eZ80 somit als Embedded-Chip konzipiert, was ZILOG durch das Angebot eines optimierten TCP/IP-Stacks unterstreicht.

Bis hierhin hört sich alles ganz gut an, aber das tat es bei Erscheinen des Z380 auch. Für die CP/M-Fans war diese CPU jedoch eine herbe Enttäuschung. Zu verlockend schienen die höheren Taktraten und der große Adreßraum zu sein, so daß immer wieder Ideen zur Verwendung in CP/M-Rechnern aufkeimten. Letztendlich scheiterten alle Theorien an der fehlenden Möglichkeit, die Betriebsmodi des Z380 während der Laufzeit beliebig wechseln zu können.

Daher ist es also von besonderem Interesse, wie ZILOG sich beim eZ80 dieser Problematik angenommen hat. Gleich vorweg: Es ist wieder Zeit, neue Ideen für CP/M-Hardware zu entwickeln!

Aber nun im Detail. Mit den verschiedenen Betriebsmodi ist es möglich, unveränderten Z80- und Z180-Code (in sog. virtuellen Z80- bzw. Z180-Bereichen) zusammen mit neuem Code in derselben Anwendung zu benutzen und somit vom 16 MByte großen Adreßraum und dem erweiterten Befehlssatz Gebrauch zu machen.

Vier Faktoren bestimmen den Betriebsmodus:

• ein Statusbit namens ADL (Address and Data Long)
• ein weiteres Statusbit namens mixed ADL
• ein 8-Bit-Register namens MBASE
• der Status der 80180-kompatiblen MMU (Memory Management Unit)

Nativer Z80 Modus: Die Statusbits ADL und mixed ADL sind ebenso wie das MBASE-Register auf 0 gesetzt, und die MMU ist inaktiv geschaltet. Im nativen Z80 Modus stehen 16-Bit-Register und 16-Bit-Adressen zur Verfügung. Der 64 kB große Arbeitsspeicher liegt am Beginn des potentiell 16 MB großen Adreßraumes des eZ80.

Virtueller Z80 Modus: Ist das Statusbit ADL gelöscht und die MMU abgeschaltet, jedoch im MBASE-Register ein von Null verschiedener Wert enthalten, dann umfaßt die Programmumgebung weiterhin 16-Bit-Register und einen 64 kB großen Adreßraum. Dessen Basisadresse wird allerdings vom Wert in MBASE bestimmt. Im virtuellen Z80 Modus können mehrere Tasks jeweils ihren eigenen Z80-Bereich haben.

Nativer Z180 Modus: Sind ADL und MBASE gleich Null, während die MMU aktiv geschaltet ist, dann ist die Programmumgebung vollständig Z80180-kompatibel. In diesem Fall stehen 16-Bit-Register und ein 64 kB großer, logischer Adreßraum zur Verfügung. Die logischen Adressen werden dabei von der MMU in physikalische Adressen von 20 Bit umgesetzt. Die 64 kB logischer Adreßraum können in ein bis drei Bereiche unterteilt werden, von denen zwei innerhalb der ersten 1 MB des maximal 16 MB umfassenden Adreßraum des eZ80 beliebig angeordnet werden können.

Virtueller Z180 Modus: Ist das Statusbit ADL gelöscht, die MMU aktiviert und in MBASE ein von Null verschiedener Wert enthalten, dann verwaltet die MMU die Umsetzung in physikalische Adressen für 1 MB virtuellen Adreßraum, dessen Basisadresse vom Wert in MBASE bestimmt wird. Auf diese Weise können mehrere Tasks jeweils in ihrem eigenen Z180-Bereich laufen.

ADL Modus: Wenn das ADL-Statusbit gesetzt ist, haben weder die MMU noch der Wert in MBASE Einfluß auf die Adressierung des Arbeitsspeichers. In diesem Modus werden der Programmladezähler (PC) sowie die Register BC, DE, HL, IX und IY von 16 auf 24 Bit erweitert. Anstelle des 16 Bit umfassenden Stackpointers (SPS, Stack Pointer Short) wird ein 24 Bit großer Stackpointer (SPL, Stack Pointer Long) benutzt. Erhält der Prozessor in diesem Modus unmittelbar Daten eines anderen Modus oder einen Befehl, der eine 16-Bit Adresse beinhaltet, dann werden diese 16-Bit-Werte automatisch in 24-Bit-Werte umgewandelt. Zur Erzeugung von Programmcode, der im ADL Modus ausgeführt wird, muß ein eZ80-kompatibler Compiler oder Assembler benutzt werden.

Der eZ80 schaltet zwischen dem ADL Modus und den anderen Modi nur über speziell eingeleitete CALL-, JP-, RET- oder RST-Befehle oder Interrupt-/Trap-Operationen um. Das MBASE-Register kann nur im ADL Modus verändert werden. Hingegen kann die MMU in jedem Modus programmiert werden. Allerdings muß der Programmierer darauf achten, daß der Programmladezähler währenddessen nicht verändert wird. Lediglich im ADL Modus muß darauf keine Rücksicht genommen werden.

Soweit zur technischen Beschreibung. Die weiteren Einzelheiten (Interrupt- und Trapbehandlung, Befehlsumfang usw.) möchte ich lieber den Experten überlassen. Alles in allem glaube ich aber, daß uns ZILOG mit dem eZ80 einen sehr interessanten Prozessor beschert hat, der mit Preisen zwischen 3 und 8 Dollar auch noch recht günstig ist.

Wie gesagt, wird es wieder Zeit, neue Ideen für CP/M-Hardware zu entwickeln!

PCX-Bilderzeugung auf dem KC85/4

von Mario Leubner

Um die Popularität des KC85 plattformübergreifend zu dokumentieren, ist es erforderlich, Bildschirmanzeigen von verschiedenen Programmen als Bilddatei zur Verfügung zu haben. Das Bildformat sollte dabei möglichst universell nutzbar sein, die KC-spezifischen Formate PIP/PIF und HIP/HIF scheiden also aus. Am besten scheint noch das relativ alte, aber dennoch weitgehend unterstützte PCX-Format von Z-Soft geeignet zu sein.

Varianten

Vom PCX-Format gibt es zahlreiche Versionen, jedoch keine allgemeingültigen Definitionen des Dateiaufbaus. Nicht alle Programme erzeugen aus den gleichen Bildern identische Dateien und hier gilt es einen Kompromiß zu finden. Am KC85/4 haben wir zwei Farbmodi zu unterscheiden: LORES, den Bytemodus und HIRES, den Bitmodus. Diese sind entsprechend unterschiedlich zu handhaben, da die IRM-Inhalte je nach Modus auch von der KC-Hardware unterschiedlich interpretiert werden. Für die PCX-Bilder gibt es demnach ebenfalls zwei Formen:

LORES: Vordergrund- und Hintergrundfarbinformationen gelten jeweils für 1 mal 8 Bildpunkte horizontal in einer Linie (1 Byte). Mit dem Farbbyte können 16 Vorder- und 8 Hintergrundfarben eingestellt werden. Im Pixelbyte liegt dagegen nur die Information, ob der Bildpunkt in der Vorder- oder Hintergrundfarbe darzustellen ist.

HIRES: Ein Bit aus jeder Ebene (Farb- und Pixel-RAM) wird direkt als Farbinformation eines Bildpunktes gewertet. Mit den zwei zur Verfügung stehenden Bits können 4 Farben dargestellt werden. Jeder Punkt kann eine der Farben schwarz, rot, türkis oder weiß annehmen.

PCX-Formate: Das PCX-Format muß also entweder 24 Farben für LORES oder 4 Farben für HIRES darstellen können. Definiert ist das PCX-Format aber nur für 2, 4, 8, 16, 256 oder 16,7 Millionen Farben. Der HIRES-Modus stellt kein Problem dar, hier eignet sich direkt das Format mit 4 Farben. Für den LORES-Modus ist entweder eine Reduzierung auf 8 Farben erforderlich, dabei könnte zum Beispiel nicht mehr zwischen den Vorder- und Hintergrundfarben unterschieden werden oder die Vordergrundfarben 8 bis 15 würden im gleichen Farbton wie die Farben 0 bis 7 dargestellt. In beiden Fällen gehen wichtige Details verloren. Es bleibt also nur die Möglichkeit, 24 der möglichen 256 Farben der nächsten Stufe zu verwenden. Dabei entsteht zwar eine gewisse Redundanz, man erhält aber alle Farbinformationen. Ich habe mich für diese Variante entschieden. Für die zu erzeugenden PCX-Formate ergeben sich demnach die in der nachfolgenden Tabelle gegenübergestellten Daten:

Farbpalette: Die Farbpalette besteht aus 3 Byte je darzustellender Farbe. Diese drei Bytes enthalten die Anteile der Grundfarben rot, grün und blau - jeweils im Bereich zwischen 0 und 255. Für bis zu 16 Farben hat die Palette im PCX-Header am Dateianfang Platz. Bei 256 Farben befindet sich die Palette am Dateiende. Und hier gibt es ein nur schwer lösbares Problem: Die Programme auf dem PC suchen die Palette direkt vom Dateiende aus und ignorieren diese, falls sie nicht genau an der geforderten Stelle steht.

Eine unter CAOS oder CP/M erzeugte Datei läßt sich jedoch nur sektorweise erzeugen, ist also immer genau ein Vielfaches von 128 lang. Das logische Dateiende liegt also irgendwo im letzten Sektor und kann normalerweise nicht näher bestimmt werden.

Der Trick

Binärdateien können alle Zeichen (Byte-Werte von 0 bis 255) enthalten, Textdateien enthalten dagegen nur darstellbare Zeichen, deren Zeichenvorrat vom verwendeten Programm abhängt. Unter CP/M werden Textdateien mit dem Zeichencode EOF (1Ah) am Dateiende gekennzeichnet, falls das Dateiende nicht mit dem Sektorende zusammenfällt. Textdateien lassen sich somit in der Größe genau auf das Zeichen bestimmen.

Bei der Betrachtung des PCX-Formates für LORES-Bilder enthält der PCX-Header keinen Wert 1Ah und auch im Datenbereich wird niemals der Wert 1Ah auftreten, da die möglichen 24 Farben mit den Werten 0 bis 23 codiert sind (0..17h) und als Komprimierungszähler nur Werte größer als C0h vorkommen. Es ist also möglich, durch einfaches Anhängen eines Bytes EOF das genaue Dateiende zu kennzeichnen. An dieser Stelle nutzt man die Redundanz gezielt aus. Jetzt muß die Datei nur als Textdatei behandelt und z.B. mit der MTOOLs ohne die Option -b zu einem PC übertragen werden. Damit hat die Datei auf dem PC genau die richtige Größe und wird korrekt weiterverarbeitet.

Für PCX-Dateien, die HIRES-Bilder des KC darstellen, muß dagegen die Option -b benutzt werden, damit die Übertragung nicht beim Auftreten eines Bytes mit dem Wert 1Ah abgebrochen wird. Die Daten einer solchen Datei können jeden beliebigen Wert annehmen, es besteht keine Redundanz. Die Weiterverarbeitung einer solchen Datei stellt jedoch kein Problem dar, auch wenn sie ein paar Bytes länger ist. Die Farbpalette steht ja am Dateianfang und wird auch von dort aus ermittelt.

Programmbeschreibung

Das vorliegende Programm PCX.KCC läuft unter CAOS. Es erfordert einen KC85/4 mit D004. Die Dateiausgabe erfolgt über die Byteschnittstelle von DEP. Das Programm leitet die Tastatur-Interrupts (vom System-PIO und der SIO Kanal 2) auf sich selbst um und kontrolliert das Auftreten einer Hardcopy-Forderung. Falls diese vorliegt, wird statt dessen die Dateiausgabe aufgerufen. (Das einfache Eintragen auf der Hardcopy-Adresse reicht nicht aus, da dann nur ein Aufruf möglich wäre, wenn eine Tastatureingabe über die KBD-Funktion angefordert wird.) Vom Programm bekommt man nun die Aufforderung zur Eingabe eines Dateinamen, bestehend aus maximal 8 Zeichen. Der Dateityp PCX wird automatisch ergänzt. Nach Bestätigung mit der Enter-Taste verschwindet das Fenster mit dem Dateinamen wieder und die Ausgabe der Datei beginnt. Je nach Komplexität des Bildinhaltes dauert es nun einige Zeit, als Fertigmeldung ertönt ein BEEP und danach kann man mit dem gerade laufenden Prozeß fortfahren. Die Fehlerbehandlung wurde auf ein Minimum reduziert. Unter der Annahme, daß keine Fehler erwartet werden, läuft das Programm ohne Probleme durch. Das Auftreten eines Fehlers (Diskette voll, Schreibfehler usw.) führt nur zu einem Sprung auf E000h, wirkt also wie die Betätigung der RESET-Taste. Über die Art des Fehlers muß man sich selbst Gedanken machen, z.B. durch den Versuch, eine andere Datei auszugeben.

Das Programm PCX besteht aus zwei Teilen und ist voll verschieblich:

• Hauptprogramm: belegt ca. 600h Bytes an einer beliebigen Stelle im RAM bzw. IRM des KC85/4.
• Interrupt-Umleitung: belegt 80h Bytes im RAM0 (oder im RAM4).

Die MC-Datei PCX.KCC wurde auf der Adresse 0 erzeugt, muß also stets mit Offset geladen werden. Der Ladeoffset ist gleich der Zieladresse, wo das Hauptprogramm laufen soll. Die Dateigröße gestattet das Laden innerhalb der IRM-Bereiches ab BA00H, wodurch der gesamte RAM für andere Programme weiterhin nutzbar bleibt. Beim Programmaufruf mit dem Menüwort %PCX wird der zweite Teil, die ISR-Umleitung, aktiviert. Diese ist standardmäßig auf die Adresse 0 voreingestellt, kann aber per Menüwort verändert werden. Als Parameter ist dann nur die Anfangsadresse des 128 Byte großen Bereiches anzugeben. Es sollte möglichst eine Adresse innerhalb des RAM0 gewählt werden, da dieser immer zugeschalten ist. Falls der RAM4 nicht geschalten wird, kann der Interrupt auch in diesen Bereich umgeleitet werden.

Aktivierung: Beim Aufruf des Menüwortes %PCX erscheint eine der folgenden Meldungen. Daran kann der Status des Programmes abgelesen werden:

DEP nicht aktiv!

Es ist kein D004 vorhanden oder das D004 ist nicht in der CAOS-Betriebsart.

 

ISR bereits modifiziert!

Entweder wurde der Treiber bereits aktiviert (Menüwort 2mal aufgerufen) oder die Interrupts wurden von einem anderen Programm umgestellt.

 

Screen-Saver aktiviert auf ADR1 ADR2

Das Programm ist aktiv und kann ab sofort mit Hardcopy (Shift-CLR) aufgerufen werden. Zur Kontrolle werden die Anfangsadressen der beiden Programmteile angezeigt

 

Deaktivierung: Deaktiviert wird das Programm durch die Zurückstellung der Interrupts. Das kann entweder durch RESET, einen Sprung auf die Adresse E000h oder F000h oder durch einen Aufruf der CAOS-Funktion SIXD erreicht werden. Solange das Hauptprogramm im Speicher unverändert vorliegt, kann durch erneute Eingabe des Menüwortes %PCX eine erneute Aktivierung erfolgen. Dabei wird die zuletzt benutzte ISR-Adresse verwendet, solange keine andere Adresse angegeben wird.

Da das Programm verschieblich ist, kann es auf unterschiedliche Adressen geladen werden. Hierbei muß beachtet werden, daß CAOS alle im Speicher stehenden Menüworte sucht, der Speicher wird dabei linear von C000H bis 0000H durchsucht. Befindet sich ein Menüwort mehrmals im Speicher, erscheint es zwar mehrmals im Menü, der Aufruf erfolgt aber stets zu dem ersten gefundenen Menüwort! Also bevor das Programm auf einen anderen Speicherbereich geladen wird, die alte Version entfernen: Entweder manuell durch MODIFY die Prologbytes 7Fh überschreiben oder durch einen Sprung auf die Adresse F000h (Speicher löschen).

Bilder von BASIC-Programmen

Für BASIC-Programme empfiehlt sich der Speicherbereich ab BA00h für das Hauptprogramm. Prinzipiell ist die Zusammenarbeit mit BASIC gewährleistet, da von PCX.KCC keinerlei Zustände verändert werden. Laufende BASIC-Programme werden nach der Ausgabe der Bilddatei automatisch fortgesetzt. Viele BASIC-Programme (besonders Spiele) erzeugen jedoch ab BA00h Zeichensätze und überschreiben PCX.KCC. Hier sollte die Möglichkeit der Begrenzung des von BASIC benutzten RAM geprüft werden (BASIC-Befehl CLEAR). Dann könnte man PCX.KCC z.B. ab 7A00h laden und ausführen.

Bekannte Probleme

CAOS stellt ein System dar, bei dem jedes Programm den Speicher nutzen kann wie es will. Sollen mehrere Programme gleichzeitig im Speicher liegen, darf ein Programm das andere nicht beeinflussen. Dieses Problem tritt bei dem PCX-Generator verstärkt auf, da das Programm zum Erzeugen von Bildern aus laufenden Programmen heraus dient.

PCX ist voll verschieblich und kann sich so jedem anderen Programm anpassen. Vielfach ist jedoch nicht bekannt, welche Bereiche frei sind. Sollte die Standard-Speicherbelegung von PCX (BA00h bis C000h für Hauptprogramm und 0000h bis 0080h für ISR-Umleitung) nicht funktionieren, kann man auf andere Adressen ausweichen. Aber welcher Bereich ist nicht genutzt?

Ich empfehle folgende Vorgehensweise:

1. CAOS-Betriebsart starten
2. Sprung auf Adresse F000h, um den Speicher zu löschen. (%go F000 bei CAOS 4.3 oder in BASIC: CALL*F000)
3. Falls nicht mit CAOS 4.3 gearbeitet wird: JUMP FC 0 (lädt das Hilfsprogramm FLOAD ab Adresse 0)
4. gewünschte Anwendung laden und ausführen
5. Anschließend den Speicher mit DISPLAY untersuchen. Ungenutzte Bereiche enthalten immer noch 00h. Man sucht 80h Byte im RAM0 und weitere 600h Byte im gesamten Speicher.
6. PCX-Programm auf einen der freien Bereiche laden und aktivieren.

Sollte auch das nicht funktionieren oder nicht genug ungenutzter Speicher vorhanden sein, kann man mit ESC-2 in das alternative Bild des KC umschalten. Dort wird das Anwendungsprogramm ausgeführt und an der gewünschten Stelle RESET gedrückt. Damit wird der Inhalt dieses Bildes ,,eingefroren``. Jetzt kann man das PCX-Programm laden und aktivieren. Im CAOS-Menü schaltet man mit ESC-2 wieder in das andere Bild (für HIRES-Bilder noch mit ESC-A den Modus wechseln) und drückt Shift-CLR. Aufpassen, daß der blinkende Cursor nicht gerade stört! Unter CAOS 4.3 kann man die Namenseingabe auch mit BRK abbrechen.

Wenn nicht genug RAM-Speicher zur Verfügung steht, kann man auch versuchen, das Hauptprogramm in ein RAM-Modul zu laden. Ein 16K- oder 64K-Modul ist dazu z.B. auf der Adresse C000h zu aktivieren. Die ISR-Umleitung sollte trotzdem bevorzugt im RAM0 stehen, notfalls im RAM4. Probleme treten jedoch auf, wenn das ausgeführte Anwendungsprogramm anderen Speicher auf den Bereich ab C000h schaltet. Das läßt sich leicht an den Modul-LEDs kontrollieren, aber auch die Aktivierung des BASIC-ROM überdeckt ein RAM-Modul ab C000h.

Ein weiteres Problem stellt das CAOS-Unterprogramm SIXD dar, das die Interrupts zurückstellt. Wird dieses Unterprogramm innerhalb einer Anwendung aufgerufen, dann geht die Umleitung zum PCX-Treiber verloren und eine Bilderzeugung kann nicht mehr erfolgen. In einigen Fällen gelingt es, die Aufrufe SIXD zu entfernen (Programmpatch). Ansonsten bleibt nur die Nutzung des zweiten Bildes. Wenn das auch nicht funktioniert (nicht alle Programme laufen im zweiten Bild!), dann gibt es momentan noch keine allgemeingültige Lösung.

Screen-Saver für Bilder im KC-Format

Als eine weitere Variante habe ich im oben beschriebenen Programm PCX.KCC die PCX-Routine ersetzt zur Erzeugung von Bilddateien im KC-Format *.PIP/PIF für LORES- bzw. *.HIP/HIF für HIRES-Bilder. Die Eigenschaften des so entstandenen Programmes SCREEN.KCC sind identisch bis auf folgende Details:

• Menüwort %SCREEN anstatt %PCX
• Programmcode ist kürzer (480h Bytes), dadurch kann der Hauptteil auch im Bereich A880h bis AD00h liegen;
• schnellere Programmausführung, da keine Formatumwandlung; erforderlich ist und die Datei blockweise ausgegeben wird;
• Ausgabe erfolgt stets in zwei Dateien (unkomprimiert)

Ausblick

Eine Weiterverarbeitung der Bilder im KC-Format kann mit den KC-eigenen Programmen wie UNIPIC, DIASHOW, WordPro6, ML.COM usw. erfolgen. Eventuell wäre auch ein Programm zur Konvertierung PIP/PIF nach PCX sowie HIP/HIF nach PCX denkbar. Aber wenn der KC zwar etwas langsamer das PCX-Format selbst erzeugt, dann dürfte der Aufwand einer nachträglichen Konvertierung diesen Geschwindigkeitsverlust wieder ausgleichen. Aber vielleicht schreibt ja trotzdem jemand ein Konvertierungsprogramm?

Einbau der Festplatte in das KC-System

von Lothar Stephan

Mit dem Einbau des GIDE und der Festplatte in das KC-System habe ich mich sehr schwer getan. Aber ich glaube, meine Lösung kann ich jetzt den KC-Freaks vorstellen und es dürfte auch einem nicht so versierten Elektronikbastler nicht schwerfallen, den Einbau zu realisieren. Jetzt macht die Arbeit mit dem KC erst richtig Spaß! Da alle Teile steckbar miteinander verbunden sind, macht eine Trennung bei Bedarf keine Probleme.

• Das GIDE erhielt einen um 90Grad abgewinkelten 40-pol. Stecker. Damit umgeht man die Platzprobleme über dem GIDE.
• Das 40-pol. Kabel zielt Richtung Netzteil. In die schmale LP wurde ein Schlitz gesägt und das Kabel durchgeführt. An das Kabel wurde eine Pfosten-Stecker-Wanne mit Schneid-Klemm-Montage angeschlossen und dieser mittels Klebepistole auf der schmalen LP festgeklebt. Das D004 erhält an dieser Stelle einen Durchbruch. Die rote Ader des 40-pol. Kabels muß vom Netzteil wegzeigen. Dann braucht man das Kabel im Floppy Disk Drive nicht zu drehen. Man bekommt bei der Montage des Steckers unmittelbar neben dem Netzteil keine Probleme mit den FD-Interface-Steckverbindern.
• Meine Festplatte habe ich neben LW E eingebaut (Neben LW B befindet sich ja bereits das 3.5``-LW (LW H)). Die Rückwand erhielt nur einen Schlitz zum Durchführen des Kabels.
• Da im Normalfall lediglich LW B verwendet wird, ist Floppy Disk Drive E nicht eingeschaltet (Sparfreak! hi). Die Erweiterung des Netzteils wurde deshalb im Floppy Disk Drive B vorgenommen. Zur Vollständigkeit halber hier noch die Verbräuche der einzelnen Geräte:
  

   

  	5 V	12 V
  Floppy Disk Drive	250 mA	3 mA
  Floppy Disk Basis	880 mA	8 mA
  Basis Device	1300 mA	50 mA
  meine Festplatte (WD 93044 A)	400 mA	460 mA
  		1.2 A	(Anlaufstrom)

   

  Damit kommen für den Umbau des Netzteils FD-Basis und FD-Drive in Frage. Da die Sekundärspannung des Netztrafo sehr hoch ist (etwa 21 V) und die überschüssige Leistung verbraten werden muß, wurde ein Trafo mit der Sekundärspannung 15 V gewickelt. Die 5 V wurden unverändert übernommen. Die 12 V für die FP wurden über einen MA7812 bereitgestellt. Die kleine LP findet am Trennblech zwischen Netzteil und FD-Drive genügend Platz. Über einen 4-pol. Floppy- Stromversorgungsstecker (5.25``) werden die Spannungen herausgeführt. Es wurde Marios Schaltungsvorschlag verwendet.

• Trafodaten: EI 78

   

  primär:	230 V	6.5 Wdg/V	1495 Wdg	0.2 mm CuL
  sekundär:	15 V	7.0 Wdg/V	105 Wdg	1.0 mm CuL

   

Zur Vervollständigung dieses Beitrages hat Mario Leubner noch die zwei folgenden Schaltbilder beigesteuert.

Bild 1: Modifizierte Stromversorgung für die Festplatte

Bild 2: Zusätzliche RESET-Schaltung für das GIDE-Interface

Potentiometrische Maßanalyse mit TITRA.SSS

von Lothar Stephan

Ein interessantes BASIC-Programm aus meiner aktiven Zeit hätte ich den Freaks anzubieten. Hier wird ein Rechenprogramm mit einer Grafik verbunden, um die Auswertung der Analyse zu beschleunigen.

Wir bestimmten regelmäßig einen Stoff in einem Elektrolyten in der Leiterplattengalvanik mit potentiometrischer Maßanalyse. Normalerweise titriert man eine Säure oder Lauge unter Verwendung eines Farbindikators, der am Äquivalenzpunkt (Umschlagspunkt/Neutralpunkt/Endpunkt) im Farbton z.B. von rot nach gelb oder von rot nach farblos - je nach Indikator - umschlägt. Für verschiedene Stoffe gibt es keinen Farbindikator.

Es gibt aber die Möglichkeit, mit einem Elektrodensystem bei der Zugabe einer für diesen Stoff spezifischen Chemikalie (mit exakt bekannten Gehalt) eine Potentialänderung zu messen. Dieses macht man sich bei der potentiometrischen Maßanalyse zu nutze. In die Lösung, die untersucht werden soll, taucht man ein Elektrodensystem, mißt die Spannung (ein paar Millivolt), gibt langsam durch eine Bürette die für den zu bestimmenden Gehalt spezifische Chemikalie hinzu und schreibt nach jeweils 1 ml Zugabe den neuen Millivoltbetrag auf. Am Äquivalenzpunkt (Umschlagspunkt/Neutralpunkt) steigt die Spannung stark an und man kann die Analyse beenden. Früher mußte man die Meßwerte auf Papier auftragen und die Mitte des steilen Anstiegs ermitteln. Diesen ml-Wert setzte man in die Gleichung ein und berechnete den Gehalt der zu bestimmenden Substanz.

Mit diesem BASIC-Programm kann das Eintragen der Werte in ein Koordinatensystem eingespart werden. Das Programm ermittelt den Umschlagspunkt selbst und berechnet gleichzeitig den Gehalt der Substanz im Elektrolyten.

Dieses Programm soll als Anregung dienen. In REM-Zeilen habe ich einige Meßwerte eingetragen. Diese wären also dann bei der Abfrage der Meßwerte einzutragen.

Scannermodul M051

von Enrico Grämer

Seit dem letzten Artikel zum Modul ist ja nun leider einiges an Zeit vergangen. Ist eigentlich auch kein Wunder, denn wer beim letzten Clubtreffen dabei war, konnte sehen, daß es nichts zu sehen gab.

So ist das leider, wenn man vor einer Vorführung fremde Hardware ausprobiert. Deswegen ist noch eine umfangreiche Schutzbeschaltung aus Dioden und Widerständen hinzugekommen. Außerdem hat sich herausgestellt, daß das Interruptsystem des KC wesentlich komplizierter als gedacht ist. Das läßt sich allein mit der Controller-Software nicht mehr bewältigen. Deshalb kommt jetzt noch der GAL U5 hinzu.

An Bestellungen gingen bei mir 20 Stück ein; eigentlich erstaunlich - bei dem Preis! Ich schätze mal, daß es den meisten nur um die serielle Schnittstelle geht. Die Platinen konnte ich nun auch endlich bestellen und ich hoffe, daß mit Erscheinen der nächsten KC-News jeder sein Modul bekommen hat.

Aufbau des Moduls

Für alle diejenigen, die das Modul selbst zusammenbauen wollen/können, sind in diesem Beitrag noch einmal die aktuellen Schaltpläne veröffentlicht. Wie auf dem Bestückungsplan zu sehen ist, geht es auf der Leiterplatte sehr eng zu. Das höchste Bauteil ist der Quarz am Controller. Wird er stehend eingebaut, dann gibt es ein kleines Platzproblem mit dem Modulgehäuse. Man kann es lösen, wenn das Plasteteil der oberen Gehäusehälfte entsprechend bearbeitet (ausgespart) wird. Da sich an dieser Stelle gerade das Metallschild befindet, gibt es ,,optisch`` keine Beeinträchtigungen. Als Alternative kann man auch versuchen, den Quarz ,,auf der schmalen Seite liegend`` einzusetzen.

Ansteuerung des Controllers im Modul M051

Wer sich auch softwareseitig näher mit den Modul beschäftigen möchte, der findet im folgenden noch einmal eine Zusammenstellung der wichtigsten Informationen zur Verwendung des Controllers. Nicht enthalten in der folgenden Darstellung ist die Programmierung der Interruptbetriebsart, da deren Entwicklung noch nicht abgeschlossen ist. Sie wird erst in der Version 1.1 der Controllersoftware nutzbar sein. Alle mit Null belegten Bits in den Steuer- und Statusbytes sind für zukünftige Erweiterungen reserviert. Beim Schreiben sind diese Bits auf Null zu setzen, beim Lesen ist von einem unbestimmten Inhalt auszugehen.

• Strukturbyte des Moduls: 0ECh
• Wenn ein Controller vorhanden ist, dann liegt PB2 der PIO auf L-Pegel
• Basisadresse PIO: 20h
• Basisadresse Controller: 24h
• I/O-Adressen des Controllers:

   

  24h	...	SIO-Daten
  25h	...	I2C-Daten
  26h	...	SIO-Befehle
  27h	...	I2C-Befehle

   

• SIO-Befehle schreiben
  
  

  	7	6	5	4	3	2	1	0
  1. Byte:	|	0	0	0	|	|	|	|
  	|				Baudrate:					0000 ...	300 Baud
  	|									0001 ...	600 Baud
  	|									0010 ...	1200 Baud
  	|									0011 ...	2400 Baud
  	|									0100 ...	4800 Baud
  	|									0101 ...	9600 Baud
  	|									0110 ...	19200 Baud
  	|									0111 ...	28800 Baud
  	|									1000 ...	38400 Baud
  	|									1001 ...	57600 Baud
  	|									1010 ...	115200 Baud
  	1 ... nur noch Status lesen (bei Befehle lesen)

   

  	7	6	5	4	3	2	1	0
  2. Byte:	0	0	0	0	|	|	|	|
  					|	Handshake:				000 ... kein Handshake
  					|					001 ... RTS/CTS-Handshake
  					1	... 64 Byte Puffer bei Handshake aktiv

   

• SIO-Befehle lesen
  
  

  	7	6	5	4	3	2	1	0
  1. Byte:	|	0	0	0	0	0	|	|		Statusbyte
  	|						|	1	... Empfänger abgabebereit
  	|						1	... Sender aufnahmebereit
  	1	... nur ist Status lesbar

  • 2./3. Byte: wie schreiben 1./2. Byte
  • 4. Byte: Versionsnummer (max. 15.15 = 0FFh), z.Z. 10h = Version 1.0

   

• I²C-Befehle schreiben

   

  	7	6	5	4	3	2	1	0
  1. Byte:	0	0	0	0	|	|	|	|
  					|	|	|	0	... Bus 0 aktiv
  					|	|	|	1	... Bus 1 aktiv
  					|	0	0	... Einzelbyteübertragung
  					|	0	1	... Blockmodus
  					|	1	1	... ,,per Hand``
  					0	... 7 Bit I2C-Adresse
  					1	... 10 Bit I2C-Adresse

  
  oder

  1. Byte:

  0

  1

  0

  0

  0

  0

  0

  0

  I2C-Gerät auf Adresse (7/10 Bit) vorhanden?

  • 2./3. Byte: 7/10-Bit-Adresse, L-Teil zuerst
  • Rückmeldung: 01h vorhanden, 0FFh fehlt

   

• I²C-Befehle lesen
  • 1. Byte: wie I²C-Befehle schreiben 1. Byte
  • 2. Byte: Versionsnummer (max. 15.15 = 0FFh), z.Z. 10h = Version 1.0
    
    

Controllerprogrammierung

Für den verwendeten ATMEL-Controller AT89S8252 gibt es bereits eine Lösung für ein Programmiergerät, anschließbar an den KC über ein M001, einschließlich der notwendigen Software. Durch die Verwendung der seriellen Programmierschnittstelle des Controllers ist der Hardwareaufwand sehr gering. Diese Lösung wird in einer der nächsten News-Ausgaben ebenfalls vorgestellt werden. Damit steht Interessenten die Möglichkeit offen, die interne Controllersoftware weiterzuentwickeln und den eigenen Wünschen anzupassen.

MTOOLS - Version 1.2

von Frank Dachselt

Es ist an der Zeit, eine neue Version der MTOOLS in Umlauf zu bringen. Immerhin ist das neue Modul M051 jetzt fertig und wird bald bei denen, die es bestellt haben, eintreffen. Und wer auch die serielle Schnittstelle mitbestellt hat, der wird die heute vorgestellten - und auch die in Aussicht gestellten - Veränderungen bestimmt gut gebrauchen können. Passende Koppeltreiber, die die serielle Schnittstelle des neuen Moduls benutzen und damit deutlich höhere Übertragungsgeschwindigkeiten erlauben, gibt es spätestens in der nächsten News-Ausgabe. Sobald ich mein eigenes Modul aufgebaut und getestet habe, schicke ich ganz Ungeduldigen die neuen Treiber auf Anfrage auch gern zu. Vielleicht gibt es auch eine Download-Möglichkeit auf unserer WWW-Homepage.

Außerdem haben inzwischen einige KC-User die MTOOLS ausprobiert und dabei einige Schwierigkeiten bei der Installation und der fehlerfreien Inbetriebnahme gehabt. Auch das soll mit diesem Beitrag beseitigt werden.

Die Sache mit dem FIFO-Speicher...

Bei meinen ersten Versuchen mit der Kopplung von KC und PC habe ich auch selbst ziemlich lange herumexperimentieren müssen, bis alles schließlich wunschgemäß und vor allem fehlerfrei funktionierte. Dabei habe ich offenbar nicht alle Versuche ausreichend dokumentiert, so daß schließlich bei den vorangegangenen Installationsbeschreibungen einige wichtige Punkte fehlten.

Die Probleme haben ihre Ursache alle im hardwareseitigen FIFO-Speicher, der auf der PC-Seite in allen modernen SIO-Schaltkreisen jeweils einmal für das Senden und das Empfangen zu finden ist. Bei Senden vom PC in Richtung KC passiert nun in Verbindung mit den Handshake-Signalen folgendes: Die zu sendenden Bytes werden in den Sende-FIFO-Speicher der SIO geschrieben und gleichzeitig wird mit dem Senden begonnen. Während des Sendens wird der FIFO-Speicher der SIO stets in möglichst gefülltem Zustand gehalten. Damit soll ein schnelles und weitgehend unterbrechungsfreies Senden garantiert werden, auch wenn der PC mal kurzzeitig anderweitig beschäftigt ist (Stichwort Multitasking) und keine Daten an die SIO liefern kann. Wenn nun der Empfänger auf der Gegenseite - in unserem Fall also der KC - eine Übertragungspause anfordert, weil er noch mit der Verarbeitung der empfangenen Daten beschäftigt ist, und dies dem sendenden PC mittels des Handshake-Signals mitteilt, dann wird das Senden nicht wie erwartet mit Beginn des nächsten Bytes unterbrochen, sondern es werden zunächst noch alle in der Sende-FIFO stehenden Bytes gesendet. Erst danach macht der PC eine Sendepause. Für dieses Übertragungsregime müssen also die Größen der FIFO-Puffer im Sender und Empfänger sowie die zugehörigen Handshake-Signale aufeinander abgestimmt sein, d.h. der Empfänger muß nach der Anforderung einer Übertragungspause noch mindestens die Bytes aus dem FIFO-Puffer des Senders aufnehmen können. Anderenfalls kommt es zwangsläufig zu einem Datenverlust während der Übertragung.

Da die Z80-SIO im V.24-Modul des KC keinen nennenswerten Empfangspuffer (nur 3 Byte) besitzt, muß der FIFO-Puffer auf der PC-Seite vollständig abgeschaltet werden. Nur so ist eine fehlerfreie Übertragung garantiert. Nun hat zwar der verwendete ADF-Treiber eine Kommandozeilenoption, die das Konfigurieren des FIFO-Puffers im Sender erlaubt, jedoch ist die Wirkung dieser Funktion abhängig vom tatsächlich verwendeten SIO-Schaltkreis. Sicher funktioniert das Abschalten des FIFO-Puffers nur, wenn man es unabhängig vom ADF-Treiber vornimmt. Unter Windows 95/98 geht das in der Systemsteuerung:

Systemsteuerung System Gerätemanager COM1 Eigenschaften Anschlußeinstellungen Erweitert

Hier kann man die Einstellungen für die FIFO-Puffer der seriellen Schnittstelle vornehmen. Es reicht hier offenbar nicht aus, die ,,Schieberegler`` auf 1 zu setzen. Man muß wirklich die FIFO-Benutzung auf der ersten Schaltfläche deaktivieren. Eine weitere Änderung ist in der Datei WINDOWS\SYSTEM.INI notwendig, die auch in der ADF-Beschreibung beschrieben ist. Unter dem Punkt [386Enh] muß die mit ,,<<<`` gekennzeichnete Zeile ergänzt werden. Das ist die Einstellung für den Software-Puffer. Der Wert stimmt zwar nicht mit der ADF-Kommandozeile in der Datei START.BAT überein, aber so funktioniert es:

  [386Enh]
  ...
  COM1Buffer=4096             <<<
  ...
  COM1Fifo=0

Der Eintrag COM1Fifo=0 ist zuvor schon automatisch durch die Einstellung in der Systemsteuerung erzeugt worden. Diese Einstellungen sind hier für den Fall gezeigt, daß die Schnittstelle COM1 verwendet wird. Bei Verwendung einer anderen Schnittstelle sind die entsprechenden Stellen natürlich entsprechend anzupassen.

Mit diesen Einstellungen sollten nun die MTOOLS im DOS-Fenster unter WINDOWS funktionieren. Sollen sie dagegen im reinen DOS-Mode verwendet werden, dann haben die WINDOWS-Einstellungen natürlich keine Wirkung. In diesem Fall hilft das Programm 16550A.EXE, das mit der folgenden Kommandozeile aufgerufen wird:

  C:\>16550a 1 off

Mit diesem Aufruf wird der FIFO-Puffer der Schnittstelle COM1 abgeschaltet. Der erste Parameter gibt Nummer der Schnittstelle an und ist bei Bedarf wieder entsprechend anzupassen. Dieser Aufruf ist sogar verträglich mit WINDOWS, d.h. man kann ihn fest in die Datei START.BAT einfügen und diese Batchdatei auch im DOS-Fenster unter WINDOWS aufrufen. Allerdings ersetzt sie nicht die vorher beschriebenen WINDOWS-Einstellungen; diese sind nach wie vor notwendig.

In der beiliegenden Version 1.2 der MTOOLS ist diese neue Kommandozeile in die Datei START.BAT bereits aufgenommen. Ebenso liegt dem Paket das Programm 16550A.EXE bei, das wiederum - wie bereits die anderen benötigten Hilfsprogramme - in ein Verzeichnis kopiert werden muß, das Bestandteil des DOS-Suchpfades ist.

Damit haben wir es zunächst einmal geschafft, die bisherige Version der MTOOLS sicher zum Laufen zu bringen. Doch kommen wir nun zu den wirklichen Neuerungen der Version 1.2. Wie so oft sind es mitunter Kleinigkeiten, die das Leben angenehmer machen.

Neue Zeichen und neue Pfade

Wie es sich für die Arbeit mi einem PC gehört, wird jetzt bei Anzeigen auf dem KC, die vom PC stammen, der IBM-Zeichensatz verwendet; natürlich vorausgesetzt, es wird mit ZAS ab Version 1.3 gearbeitet. Das ist insbesondere bei der Verwendung von Umlauten interessant und betrifft vorzugsweise die Funktion MTYPE zur Anzeige eines Textfiles vom PC auf dem KC. Aber auch alle anderen Programme, die Filenamen auf dem KC zur Anzeige bringen, wechseln jetzt stets zum IBM-Zeichensatz. Dabei muß beachtet werden, daß jetzt zwar Filenamen und Directories mit Umlauten auf dem KC angezeigt, solche Sonderzeichen aber (noch) nicht am KC eingegeben werden können und schon gar nicht innerhalb von Dateinamen am KC verwendet werden dürfen. Man kann sich in solchen Fällen nur so behelfen, daß man in die betreffenden Verzeichnisse auf dem PC wechselt, bevor die MTOOLS-Steuerschleife gestartet wird, bzw. bei problematischen Dateinamen geschickt die Jokerzeichen einsetzt (z.B. bei MGET). MGET ersetzt in solchen Fällen die Sonderzeichen in den lokalen Dateinamen durch Buchstaben aus dem Bereich A...P. Grundsätzlich sollte man aber aus Kompatibilitätsgründen auf die Verwendung von Sonderzeichen in Dateinamen möglichst verzichten.

Die zweite Veränderung betrifft die Übertragung von Binärdateien mit MGET bzw. MPUT. Da bei MGET in diesen Fällen zunächst die UUE-kodierte Datei im aktuellen Verzeichnis auf den PC erzeugt werden mußte, war es bislang nicht möglich, Binärdateien aus Read-only-Verzeichnissen (z.B. von CD-ROMs) zu übertragen. In ähnlicher Weise konnte auch das Lesen oder Schreiben von Binärdateien von bzw. auf Disketten scheitern, da auch hier jeweils die UUE-kodierte Datei ins aktuelle Verzeichnis passen mußte, was in Abhängigkeit vom Füllgrad der Diskette und der Größe der zu übertragenden Datei nicht immer garantiert werden konnte. In all diesen Fällen wird das Problem jetzt dadurch gelöst, daß die MTOOLS die UUE-kodierten Dateien in ein frei konfigurierbares temporäres Verzeichnis schreiben, das sich an geeigneter Stelle auf der Festplatte befinden kann. Die Konfiguration erfolgt - wie von einigen anderen Parametern bekannt - in der Datei START.BAT, z.B. wie folgt:

  set kctemp=c:\kcnet\temp\

Zu beachten ist, daß das angegebene Verzeichnis auch existieren muß. Es ist also vor der ersten Benutzung der neuen MTOOLS-Version anzulegen.

Ausblick: CRC - sicher ist sicher!

Eigentlich sollte in diesem Abschnitt über eine bereits realisierte Erweiterung berichtet werden. Leider sind die Arbeiten noch nicht abgeschlossen (die Gründe können in den einleitenden Worten diese Ausgabe nachgelesen werden...), so daß es an dieser Stelle nur einen Ausblick auf die Version 1.3 gibt, die in den nächsten KC-News veröffentlicht werden wird.

Die sich in Arbeit befindliche Erweiterung ist die Einführung der CRC-Prüfung beim Übertragen von Dateien. Diese Funktion ist besonders für die zukünftigen hohen Übertragungsgeschwindigkeiten des M051 wichtig, da die Fehlerwahrscheinlichkeit mit der Baud-Rate ansteigt. Bei den bis jetzt verwendeten 2400 Baud habe ich bei mir mit Kabellängen bis zu 15 m noch keinen Fehler bemerkt, so daß man zur Zeit noch von einer ziemlich sicheren Übertragung ausgehen kann.

Das verwendete Batchdatei-Protokoll läßt noch keine komfortable und schnelle blockweise Prüfung zu. Vielmehr werden die übertragenen Daten dateiweise verifiziert. Das kann im Fehlerfall zwar zu erheblich längeren Übertragungszeiten führen, da jeweils die gesamte Datei nochmals übertragen werden muß, bietet aber letztlich die gleiche Sicherheit wie das blockweise Verfahren. KC-seitig wird die Bestimmung des CRC-Wertes in die Programme MGET und MPUT integriert, auf dem PC wird sie in ein externes Programm verlagert, das in das Batchdatei-Protokoll eingebunden wird.

Dateien

Zum aktuellen MTOOLS-Paket gehören die folgenden Dateien auf der Beilagendiskette:

MTOOLS12.PMA

Dieses Archiv enthält die KC-seitigen Programme des MTOOLS-Pakets.

 

MTOOLS12.ZIP

Dieses Archiv enthält die PC-seitigen Programme des MTOOLS-Pakets. Dazu gehören die Dateien der Batch-Steuerschleife sowie alle benötigten externen Programme. In der Datei README.TXT stehen einige Installationshinweise.

 

ADF144.ZIP

In diesem Archiv befindet sich der ADF-Treiber zusammen mit dessen Beschreibung und einer Reihe von Zusatzprogrammen. Es werden nur die Programme ADF.EXE und REGISTER.EXE benötigt.

 

Zum Schluß noch der Hinweis, daß ich natürlich wieder sehr an Erfahrungsberichten über die Verwendung der MTOOLS interessiert bin.