KC-News 4/1998

Top-Themen:

• Modul M051: Scanner-Interface
• Rechnerkopplung: MTOOLS-Update
• EPROM-Brenner-Modul M030

Ein paar Worte zur Einleitung

von Frank Dachselt

So, nun sitze ich wieder vor einem leeren Bildschirm und tippe die letzten Worte vor der Fertigstellung dieser News-Ausgabe ein. Morgen soll Redaktionsschluß sein und die Kopiervorlage auf die Reise geschickt werden. Daß es in letzter Zeit immer zu mehr oder weniger großen Differenzen zwischen ,,angestrebtem' und ,,tatsächlichem`` Redaktionsschluß (siehe Impressum) kommt, ist natürlich höchst unbefriedigend, leidet doch die Aktualität unserer Zeitung darunter. Die Schuld dafür muß ich ehrlicherweise in den meisten Fällen auf mich nehmen. Trotzdem ein Dank an alle Leser, die diesen Zustand bis jetzt ohne Protest ertragen haben. Der bevorstehende Jahreswechsel ist ein guter Zeitpunkt für gute Vorsätze; Ihr dürft raten, was ich mir in diesem Zusammenhang für das nächste Jahr vornehme...

Bleiben wir gleich mal beim nächsten Jahr. Große Ereignisse werfen ihre Schatten voraus, so auch unser nächstes Clubtreffen seit der vorangegangenen Ausgabe. Heute nun liegen bereits wieder die Anmeldeformulare für dieses Treffen bei, die von allen Teilnehmern bis zum 15. Januar ausgefüllt und an Dietmar Meyer zurückgeschickt werden sollten. In der nächsten Ausgabe gibt es dann weitere Anreise- und Ablaufinformationen, unter anderem auch zu möglichen Fahrgemeinschaften bei der An- und Abreise.

Doch nun zu dieser Ausgabe: Besonderes Gewicht (auch in physischer Hinsicht) genießt weiterhin der Assemblerprogrammierkurs, der heute mit einem weiteren Teil fortgesetzt und dieses Mal sicherlich auch einige Zeit zum Durcharbeiten beanspruchen wird. Weitere Infos zum Kurs findet Ihr wieder in der Rubrik ,,Programmierecke``. Zusammen mit den regulären News-Beiträgen dürfte also dafür gesorgt sein, daß die langen Winterabende nicht der Langeweile geopfert werden müssen.

Bevor ich Euch den inhaltlichen Teil dieser News-Ausgabe überlasse, möchte ich allen Lesern und ihren Familien ein frohes Weihnachtsfest sowie alles Gute für das Jahr 1999 wünschen.

Und nun viel Vergnügen beim Lesen dieser Ausgabe!

Euer Redakteur Frank

7. Elmshorner Computertage

von Mike Preuß

Am 24. und 25. Oktober 1998 fanden die 7. Elmshorner Computertage statt. Der Computerclub Elmshorn (CCE) hatte dafür mal wieder die Gesamtschule in Beschlag genommen. Neben der Computerausstellung hatten die Modellbahnfreunde die Sporthalle in Beschlag genommen.

Es gab aus vielen Bereichen der Computerbranche etwas zu sehen. Ein paar Computerhändler, unter anderem auch spezielle Atari-Händler, sowie Homebanking, Netzwerkspiele, Musikbearbeitung waren dort zu finden. Auch der Amiga-Club Hamburg stellte sich dort mit vor. Zusätzlich hat der CCE eine Tombola und die Cafeteria dort angeboten.

Etwas, das nicht jeder dort erwartet hätte, fand man gleich an den Eingängen. Beim Haupteingang stand ein Fernschreiber (Lorenz 15), beim Hintereingang stand eine Lochkartenstanzmaschine (IBM 026), die sogar lief, obwohl sie nicht ganz funktionstüchtig war. Nach dem Transport stanzten nicht mehr alle Löcher, aber das Prinzip konnte gezeigt werden. Das waren zwei Exponate des Computermuseums der Fachhochschule Kiel, das auch noch eine kleine Ausstellung in einen Klassenraum mitgebracht hatte.

Zur Sammlung des Computermuseums gehörten ein paar mechanische Rechenmaschinen, ein paar ältere Heimcomputer sowie verschiedene Datenspeicher, von Lochstreifen, über Magnetbänder und 8-Zoll-Disketten bis hin zum ZIP-Laufwerk. Bei den Platinen waren auch einige Generation vertreten. Die ältesten kamen aus der Siemens 2002 und der Zuse 22, bis hin zu einer PCI-Ethernet-Karte von 1995. Die Sammlung wird in der nächsten Zeit auch aufgearbeitet und im Internet unter

zu finden sein.

Im gleichen Raum befand sich auch das ZX-TEAM. Dieses hatte auch die Rechner dabei, die vom ZX-TEAM betreut werden: Sinclair ZX 81, ZX 80, diverse Nachbauten, wie T/S 1000, T/S 1500, Bit 90, Lamda. Am Sonntag kam dann auch ein Schmuckstück: Willi hatte sein Jupiter ACE mitgebracht. Dieser Rechner hat Forth als Programmiersprache von Hause aus. Dieser Rechner wird im ZX-TEAM dringend gesucht, bisher sind aber nur zwei Rechner in unserem Wirkungskreis bekannt.

Obwohl dort auch einige ZX 81 standen, die auch als solche erkennbar waren, gab es andere, die sahen gar nicht mehr danach aus. Besonders Joachims ZX 96 (er kann einfach nicht mehr ZX 81 genannt werden) im Desktop-Gehäuse mit Festplatte und PC-Tastatur, Handscanner und Tintenstrahldrucker sah nicht unbedingt nach dem Rechner aus. Auch Kai's Rechner, im Laptop-Gehäuse und mit LCD-Bildschirm, fiel aus dem Rahmen.

In diesem Raum kamen wir mit vielen Leuten ins Gespräch. Viele erzählten, sie hätten noch mit einigen solcher Geräte gearbeitet und hatten es nicht erwartet, diese noch mal wieder zu sehen. Viele Leute finden es gut, daß es noch Leute gibt, die sich mit den alten Rechnern beschäftigen. Einige wollten es auch mit neuen Exponaten, die bei ihnen noch auf den Dachboden oder im Keller stehen, unterstützen.

Auf alle Fälle war die Ausstellung ein Erfolg für das ZX-TEAM und das Computermuseum. Ein Dank gilt der guten Betreuung durch den CCE. An einer solchen Veranstaltung werden wir jederzeit wieder teilnehmen. Es gilt aber auch der Dank an alle, die dabei geholfen haben, daß das Computermuseum und ZX-TEAM dort mitwirken konnten, die ich nun nicht alle aufzählen möchte, da es den Artikel sprengen würde.

Mike Preuß (Förderverein Computermuseum Kiel e.V.),
E-mail: Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein., Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.

Modul M051 - Das Scanner-Interface

von Enrico Grämer

In der vorletzten KC-News stellte Ralf Kästner das Scanner-Interface vor. Bekanntlich besteht es aus einer Kombination von M001, einer Anpaßschaltung und dem eigentlichen Scanner-Interface für den Atari.

Vom M001 wird nur die PIO benötigt, der GAL U1 stellt die Signale zur Erzeugung des Strukturbytes (STRB) ECH über U2, zum Schalten des Moduls (MODSW) und die CS-Signale für PIO (/CSPIO) und Microcontroller (/CSµC) zu Verfügung. Des weiteren realisiert er die MEI-MEO-Kette. Der GAL U4 bildet aus den Leitungen PB7 der PIO, /IORQ, /CSPIO, AB0, AB1 und /RD die Signale /ROM4, /ROM3, /UDS, /LDS zu Ansteuerung des Scanner-GALs U11. Zusätzlich habe ich /ROM4 noch mit /RESET verknüpft. Dadurch ist sichergestellt, daß der Scanner nach jedem Einschalten des KCs deaktiviert ist. In der Scannerschaltung habe ich noch zusätzlich IC2, IC3 und U13 eingefügt, die mittels PB6 der PIO die Signale CLK und /LINE vom Scanner teilen, und somit die Auflösung (DPI) halbieren.

Wie in der letzten KC-News angedeutet, kann das Modul optional mit einem Microcontroller bestückt werden. Dabei handelt es sich um den AT89S8252, der mit 8 kB downloadbaren Flash-EEPROM, 256 Byte RAM, 2 KB EEPROM, UART und 3 Timern ausgestattet ist. Damit läßt sich schon eine ganze Menge anfangen.

In diesem Fall wird er mit 22,1184 MHz getaktet und kann damit exakte serielle Übertragungsraten von 300 bis 115200 Baud realisieren. Die MAX202 (U15, U6) dienen der Pegelanpassung zwischen Controller und Schnittstelle. Wie am Schaltplan zu erkennen ist, ist die Schnittstelle fast vollständig belegt. Allerdings muß sich DCD einen Port des Controllers mit /INT1 vom zweiten I²C-Bus teilen. Damit beim Datenaustausch zwischen KC und Controller nichts verloren gehen kann, wird durch Verknüpfung von CSuC und einem Port des Controllers (uCWAIT) der WAIT-Zustand des Z80 erzwungen. Pin 8 ist mit PB2 der PIO verbunden und legt diesen auf Masse. Dadurch kann per Software festgestellt werden, ob der Controller vorhanden ist.

Die Funktionen des Controllers (SIO und I²C) habe ich bereits fertig, auch Übertragungsraten von 115200 Baud gehen schon. Was noch fehlt ist die Einbindung in das Interruptsystem des KCs, aber das wird auch noch hinzukriegen sein. Der I²C-Bus ist vielseitig verwendbar, so gibt es A/D- und D/A-Wandler, Equalizer, 8-Bit-I/O-Ports und vieles, vieles mehr, also ideal zum Beispiel für die Modellbahnsteuerung.

Am Platinenlayout ist deutlich zu erkennen, daß die Leiterbahnen ziemlich eng beieinanderliegen und damit das Herstellen der Platine und der Zusammenbau nicht gerade einfach sind. Wir kommen also nicht umhin, einen Leiterplattenservice mit der Anfertigung der Platinen zu beauftragen. Bei 10 Platinen würde eine einzelne ca. 70 DM und damit das Modul mit dem Scannerinterface als Bausatz ca. 110 DM kosten. In diesem Preis ist die optionale Aufrüstung mit dem Microcontroller für I²C- und serielle Schnittstelle noch nicht mit enthalten. Für letzteres würden noch einmal etwa 35 DM zu berappen sein. Die Platinen werden mit Lötstoplack hergestellt, so daß jeder halbwegs im Löten versierte KC- User das Modul selbst zusammenbauen können sollte.

Die genannten Preise sind zwar erst mal nur eine grobe Schätzung, können aber schon als absolute Obergrenze angesehen werden. Unter Umständen liesen sich insbesondere bei den Bauelementen noch einige Mark sparen, was auch von der Anzahl der bestellten Module abhängt. Ich möchte nun hiermit alle Interessenten eines solchen Moduls aufrufen, sich bis Ende Januar bei mir zu melden, damit dann die verbindliche Bestellung der Leiterplatten abgeschickt werden kann. In den nächsten KC-News wird es hierzu sicherlich noch einiges mehr zu lesen geben. Zum Clubtreffen im April werden die neuen Module dann auf alle Fälle in Aktion zu bewundern sein!

Rechnerkopplung - MTOOLS-Update

von Frank Dachselt

Dieser Beitrag knüpft direkt an das Thema Rechnerkopplung aus den KC-News 3/98 an. Dort wurde bereits das Programmpaket MTOOLS vorgestellt, für das es heute ein Update mit einigen Erweiterungen und wesentlichen Verbesserungen gibt. Die grundlegenden Funktionen zur Bedienung des MS-DOS-Filesystems vom KC aus sowie zum Dateitransfer zwischen KC und PC sind ja bereits vorhanden, allerdings gab es bisher noch einige Unzulänglichkeiten. Das wäre zum einen das fehlende Handshaking für die Übertragungsrichtung KC --> PC (wie bereits in den KC-News 3/98 beschrieben) sowie - wie sich inzwischen herausgestellt hat - die fehlende Verträglichkeit mit dem ,,Mutlitaskingbetriebssystem`` Windows. Letzteres hat es unmöglich gemacht, die Batch-Steuerschleife in einem MS-DOS-Fenster unter Windows aller bekannten Versionen fehlerfrei abzuarbeiten. Die Ursache dafür liegt in dem ungenügendem Standardtreiber für die serielle Schnittstelle in MS-DOS. Dieser verwendet zur Abfrage der seriellen Schnittstelle ein einfaches Polling ohne jegliche Hardware-Puffer (auch wenn solche auf dem SIO-Schaltkreis vorhanden sind). So kommt es unter Windows unweigerlich zu Datenverlusten bei der Übertragung KC --> PC, was mit entsprechenden Fehlermeldungen im MS-DOS-Fenster und dem Abbruch der Steuerschleife einhergeht. Die Anwendung der MTOOLS war damit bisher auf den reinen MS-DOS-Mode des PC beschränkt. Abhilfe war nur durch einen neuen Treiber für die serielle Schnittstelle zu erwarten.

Ein neuer Treiber löst (fast) alle Probleme

Nach einigem Suchen war dann auch ein geeigneter Treiber gefunden: Er nennt sich ADF und befindet sich im Archiv ADF_144.ZIP auf der Beilagendiskette. Dieser Treiber arbeitet interruptgesteuert, verwendet Sende- und Empfangspuffer (sowohl hard- als auch softwaremäßig) und realisiert ein richtiges RTS/CTS-Handshaking. Aus dem Paket werden eigentlich nur die Programmdateien ADF.EXE und REGISTER.EXE benötigt. Leider ist die Beschreibung in Englisch, deshalb im folgenden ein paar Hinweise zur Benutzung. Der Aufruf von ADF initialisiert den neuen Treiber und ersetzt das bisher verwendete MODE-Kommando. In der Datei START.BAT ist das MODE-Kommando also durch einen entsprechenden ADF-Aufruf auszutauschen. Beim Aufruf können eine Reihe von Parametern übergeben werden. Soll die COM1-Schnittstelle benutzt werden, sieht die Kommandozeile etwa wie folgt aus:

C:\>ADF COM1 3F8 4 2400 1024 1024 1

Die übergebenen Parameter haben in der angegebenen Reihenfolge folgende Bedeutung:

• Name des COM-Ports (COM1)
• I/O-Basisadresse des verwendeten COM-Ports (3F8)
• Nummer des verwendeten Interrupts (4)
• Baudrate (2400)
• Größe des FIFO-Puffers im Hauptspeicher für Empfangsdaten (1024)
• Größe des FIFO-Puffers im Hauptspeicher für Sendedaten (1024)
• Steuerbyte für den Hardware-FIFO-Puffer des SIO-Schaltkreises (1)

Soll ein anderer COM-Port benutzt werden, dann sind die ersten drei Parameter entsprechend anzupassen. Die Standardwerte dafür lauten:

C:\>ADF COM2 2F8 3 2400 1024 1024 1

C:\>ADF COM3 3E8 4 2400 1024 1024 1

C:\>ADF COM4 2E8 3 2400 1024 1024 1

Es können noch weitere Parameter übergeben werden, aber bei denen sind die Vorgabewerte bereits passend gesetzt. Das betrifft auch das Datenformat (8,N,1), das standardmäßig verwendet wird. Die Größen für Empfangs- und Sendepuffer können auch höher gewählt werden, aber für die derzeitigen Übertragungsraten von maximal 2400 Baud sind 1024 Bytes völlig ausreichend.

Mit dem Wert 1 für den Hardware-FIFO-Puffer wird dieser praktisch ausgeschaltet. Das ist notwendig für ein datenverlustfreies Zusammenwirken mit der Z80-SIO am KC. Wird bei der Übertragung vom PC zum KC die Handshake-Leitung von der KC-Seite zurückgesetzt, um das Datensenden zu unterbrechen, wird stets noch der gesamte Pufferinhalt der PC-SIO gesendet. Das würde den 3-Byte-Empfangspuffer der Z80-SIO leicht überfüllen. Mit dem Wert 1 ist gesichert, daß nach dem Rücksetzten der Handshakeleitung maximal noch ein Byte gesendet wird, für das die Z80-SIO garantiert noch aufnahmefähig ist.

Der Beschreibung zum ADF-Paket ist zu entnehmen, daß der Hardware-FIFO-Puffer auch in der Systemsteuerung von Windows 95/98 auszuschalten sowie in der Datei SYSTEM.INI die Größe des Empfangspuffers im Hauptspeicher anzugeben ist (siehe ADF.TXT für Einzelheiten). Inwieweit letzteres wirklich notwendig ist, kann ich nicht genau beurteilen. Die Datenübertragung funktioniert auch ohne diese Angabe.

Mittels der Kommandozeile

C:\>ADF UNLOAD

wird der ADF-Treiber deaktiviert und aus dem Speicher gelöscht. Eventuell noch im Sende- oder Empfangspuffer vorhandene Daten gehen dabei verloren.

Das ADF-Paket ist Shareware. Vor der Benutzung ist eine Registrierung mittels REGISTER.EXE notwendig, sonst verweigert ADF seine Dienste. Die Frage nach dem Namen des zu registrierenden Programms ist mit ,,ADF.EXE`` zu beantworten. Die Eingabe des Nutzernames übergeht man mit ENTER, dann ist das Programm für eine Testphase von 30 Tagen ,,registriert``. Ob man sich nach diesem Zeitraum ,,richtig`` registrieren läßt, muß jeder selbst mit seinem Gewissen ausmachen. Das Programm funktioniert jedenfalls auch noch danach uneingeschränkt und läßt sich beliebig oft für eine neue Testphase ,,freischalten``...

Ein neues Kabel

Wie bereits erwähnt, beherrscht der ADF-Treiber im Gegensatz zum MS-DOS-Standardtreiber das RTS/CTS-Handshaking-Protokoll. Dessen Fehlen hatte ja für die erste Version der MTOOLS einige Konsequenzen. Um dieses Protokoll nun für die Datenübertragung zwischen KC und PC zu benutzen, muß am bisherigen Nullmodemkabel (Bild 4(d) auf Seite 7 der KC-News 3/98) nur ein Draht am PC-seitigen Stecker umgelötet werden, und zwar ist der wegführende Draht vom Anschluß DTR auf den noch freien Anschluß RTS zu legen. Das resultierende Kabel ist im Bild 1 noch einmal dargestellt.

Bild 1: Nullmodemkabel für das RTS/CTS-Protokoll mit ADF.EXE

Auch wenn der ADF-Treiber ebenso mit der alten Kabelvariante zusammenarbeitet, so ist die Benutzung dieses Protokolls dringend zu empfehlen. Die Übertragung wird dadurch erheblich sicherer, insbesondere bei den uns bevorstehenden wesentlich höheren Übertragungsraten.

Der Effekt des nunmehr vollständigen Handshakings kann am deutlichsten im Zusammenhang mit den Puffern des ADF-Treibers beobachtet werden. Dazu installiert man den neuen Treiber mit einer der oben angegebenen Kommandozeilen für einen Sende- und Empfangsdatenpuffer von jeweils 1024 Byte. Auf dem KC erzeugt man mit einem Texteditor eine Textdatei TEST.TXT, die eine Länge von etwa 2000 Byte hat, also ungefähr das Doppelte der Pufferkapazität im PC. Diese sendet man nun mittels KCSEND (KC-News 2/98) an den PC, ohne daß am PC schon etwas für den Empfang dieser Datei vorbereitet wurde:

A0>KCSEND TEXT.TXT

An der Ausgabe von KCSEND erkennt man, daß etwas gesendet wird. Etwa in der Mitte der Übertragung unterbricht der KC das Senden der Datei, weil jetzt der Empfangspuffer des ADF-Treibers voll ist und dieser diesen Zustand mittels eines inaktiven RTS-Signals dem KC mitteilt. Erst wenn die Bytes mit

C:\>COPY COM1 TEXT.TXT

aus dem Puffer abgeholt werden, wird die RTS-Leitung wieder aktiv und es können weitere Bytes gesendet werden. Der Test für die Gegenrichtung könnte wie folgt aussehen: Auf dem PC erzeugt man eine Textdatei TEXT1.TXT, die etwa 500 Bytes lang ist und damit bequem im Sendepuffer des ADF-Treibers Platz findet. Wird diese Datei mittels

C:\>COPY TEXT1.TXT COM1

an den KC gesendet, dann meldet die COPY-Routine am PC sofort den Erfolg dieser Aktion, auch wenn am KC noch kein Byte empfangen wurde. Die Textdatei steht jetzt vollständig im Sendepuffer und der ADF-Treiber wartet auf das aktive CTS-Signal, um mit den Senden beginnen zu können. Das geschieht, indem man am KC die Datei empfängt:

A0>KCEMPF TEXT1.TXT

Der Empfang muß an dieser Stelle noch mittels BRK-Taste am KC beendet werden, da der PC bekanntermaßen kein EOF-Zeichen am Ende einer Textdatei sendet.

Wenn diese beiden Experimente erfolgreich, d.h. ohne Datenverlust, verlaufen sind, dann kann man sich sicher sein, daß der ADF-Treiber richtig installiert ist. Nun ist es auch an der Zeit, die neue Version der MTOOLS auszuprobieren.

MTOOLS-Erweiterungen

Die Programme zur Fernsteuerung des PC und zum Zugriff auf das MS-DOS-Filesystem vom KC aus liegen jetzt in der Version 1.1 vor. Die Versionsnummer wird jetzt auch im Hilfetext angezeigt (Option -h). Die Veränderungen betreffen insbesondere die beiden Programme MPUT.COM und MGET.COM. Zum einen können beim Senden wie auch beim Empfangen von Dateien die Jokerzeichen ? und * verwendet werden und so ganze Dateigruppen mit jeweils einer Kommandozeile übertragen werden. Des weiteren sind diese beiden Programme jetzt mit der UUE-Kodierung (siehe KC-News 3/98) ausgerüstet worden, so daß auch Binärdateien übertragen werden können. Die Übertragung von Binärdateien wird mit der Option -b veranlaßt. Bei der Übertragung solcher Dateien vom KC zum PC (MPUT.COM) werden die einzelnen Bytes vor dem Senden kodiert. Die Dekodierung im PC geschieht durch einen (automatischen) Aufruf des Programms UUDECODE.COM, so daß nach der Übertragung sofort wieder die Binärdatei vorliegt. In der Gegenrichtung wird eine Binärdatei im PC zunächst (automatisch) mit dem Programm UUENCODE.COM kodiert. Danach wird die kodierte Datei gesendet und beim Empfang im KC durch MGET.COM wieder dekodiert. Damit dieses Verfahren funktioniert, müssen in PC die Programme UUENCODE.COM und UUDECODE.COM in einem Verzeichnis stehen, das Bestandteil der PATH-Variable von MS-DOS ist, damit ein grundsätzlich ein einfacher Aufruf über den Programmnamen möglich ist.

Es folgen einige Beispiele, die die neuen Möglichkeiten von MPUT.COM und MGET.COM demonstrieren:

• Übertragen aller Textdateien (*.TXT) vom Laufwerk A, Userbereich 1 an den PC:

  MPUT 1/A:*.TXT
  
  

• Dem Programm MPUT.COM kann auf der Kommandozeile eine Liste von zu übertragenden Dateien übergeben werden, wobei jeder Eintrag in dieser Liste auch Jokerzeichen einhalten kann. Übertragung aller TXT- und DOK-Dateien sowie der Datei PROG.ASM aus dem aktuellen Laufwerk/Userbereich an den PC:

  MPUT *.TXT *.DOK PROG.ASM
  
  

• Werden dem Programm MPUT.COM mehrere Dateibezeichnungen übergeben, dann können diese auch auf unterschiedlichen Laufwerken stehen. Übertragung aller TXT-Dateien von den Laufwerken B und E (aus dem aktuellen Userbereich) an den PC:

  MPUT B:*.TXT E:*.TXT
  
  

• Alle PMA-Archive vom Laufwerk C: werden als Binärdateien an den PC gesendet:

  MPUT -B C:*.PMA
  
  

• Dem MGET-Kommando kann nur eine einzelne Dateibezeichnung übergeben werden, die aber auch Jokerzeichen enthalten kann. Übertragen aller TXT-Dateien aus dem aktuellen PC-Verzeichnis an den KC:

  MGET *.TXT
  
  

• Die Dateibezeichnung beim MGET-Kommando kann auch eine absolute oder relative Pfadangabe enthalten. Übertragen aller TXT-Dateien aus dem PC-Verzeichnis mit dem relativen Pfad ..\TEXT an den KC:

  MGET ..\TEXT\*.TXT
  
  

• Alle PMA-Archive aus dem aktuellen PC-Verzeichnis werden als Binärdateien an den KC gesendet:

  MGET -B *.PMA
  
  

Die Übertragung einer Datei als Binärdatei muß also explizit durch die Angabe der Option -b veranlaßt werden, im anderen Fall wird von einer Textdatei ausgegangen und die Übertragung beim ersten Byte 1AH beendet. Eine automatische Unterscheidung zwischen Text- und Binärdateien ist prinzipiell nicht möglich. Bestenfalls könnte man die Dateierweiterungen auswerten, aber auch das verspricht nur beschränkten Erfolg. Auf der sicheren Seite wäre man, wenn alle Dateien als Binärdateien übertragen werden. Auf diese Möglichkeit habe ich aber vorerst wegen der noch ungenügenden Übertragungsgeschwindigkeiten verzichtet, da das Senden als Binärdatei etwa 30 Prozent mehr Zeit in Anspruch nimmt. Allerdings ist auch hier Vorsicht geboten, da eine als Binärdatei an den KC gesendete Textdatei am Dateiende keine EOF-Marke mehr besitzt, was zum Anhängen ungütiger Zeichen am Dateiende führt.

Eine weitere Veränderung hat das Programm MEXIT.COM erfahren, mit dem die Batch-Steuerschleife im PC beendet wird. Um nach der Benutzung des ADF-Treibers (oder auch anderer) definierte Verhältnisse zu erreichen, wird jetzt noch die Datei EXIT.BAT aufgerufen (Bild 2). In dieser Datei können Kommandos zum Deaktivieren von Treibern und anderen ,,Aufräumarbeiten`` stehen. Im vorliegenden Fall enthält diese Datei nur den Befehl ADF UNLOAD (siehe oben) zum Deaktivieren des ADF-Treibers.

Bild 2: Batch-Steuerschleife für die MTOOLS-Version 1.1

Zum Schluß noch ein Hinweis, den ich nicht ausführlich begründen möchte: Bedingt durch eine Time-Out-Funktion des ADF-Treibers arbeiten die MTOOLS erst ab der aktuellen Version 1.1 korrekt mit diesem zusammen. Bei der Verwendung der Version 1.0 aus den KC-News 3/98 mit dem ADF-Treiber kommt es dagegen mitunter zu Fehlfunktionen (aber zu keinen Datenverlusten). Andererseits können die MTOOLS der Version 1.1 uneingeschränkt mit der ursprünglichen Treibervariante (MODE-Kommando) eingesetzt werden.

Installationshinweise

An dieser Stelle sollen die Schritte zur Installation der MTOOLS auf dem KC und dem PC noch einmal in kompakter Form zusammengestellt werden:

• Installationsschritte auf dem KC
  
  
  1. Entpacken der MTOOLS-COM-Dateien aus dem Archiv MTOOLS11.PMA
  2. Installieren des Koppeltreibers (siehe auch KC-News 2/98) für 2400 Baud:

     
     A0>DRIVER V24H24A.KOP

     oder

     A0>DRIVER V24H24B.KOP

     Diese beiden Befehle trägt man günstigerweise in die Start-SUBMIT-Datei ein, so daß die Treiber beim Booten des Systems automatisch geladen werden.

• Installationsschritte auf dem PC
  
  
  1. Aus dem Archiv ADF_144.ZIP werden die Dateien ADF.EXE und REGISTER.EXE benötigt. Diese gehören in ein Verzeichnis, das auch Bestandteil der Path-Variable von MS-DOS ist.
  2. Nach dem Wechsel in das Verzeichnis, in dem sich ADF.EXE und REGISTER.EXE befinden, wird das Programm REGISTER.EXE ausgeführt. Die Frage nach dem Namen wird mit ,,ADF.EXE`` beantwortet, die Frage nach dem Usernamen mit ENTER übergangen.
  3. Aus dem selbstentpackenden Archiv MTOOLS11.EXE gehören die Programme UUENCODE.COM und UUDECODE.COM in das gleiche Verzeichnis wie bereits der ADF-Treiber.
  4. Die BAT-Dateien sowie die Datei EOF.EOF aus MTOOLS11.EXE werden in ein neues Verzeichnis (z.B. C:\KCNET) kopiert.
  5. In der Datei START.BAT werden die beiden Variablen KCPORT und PCPATH - falls notwendig - angepaßt. KCPORT ist der Name der seriellen Schnittstelle, über die der KC angeschlossen ist. KCPATH ist der Pfad des Verzeichnisses mit den BAT-Dateien. Weiterhin muß der Aufruf des ADF-Treibers an die Nummer der verwendeten Schnittstelle angepaßt werden (siehe Beispiel am Beginn dieses Beitrages).

Nach diesen Schritten sind die MTOOLS startklar! Dabei wird immer zuerst die Datei START.BAT aus dem im Punkt 4 genannten Verzeichnis auf dem PC gestartet, womit die in Bild 2 gezeigte Steuerschleife in Aktion tritt. Danach können vom KC aus durch Aufruf der entsprechenden Programme die gewünschten Aktionen ausgelöst werden.

Schneller, weiter, höher, ...

An dieser Stelle soll es vorwiegend um das ,,schneller`` gehen. Jeder, der das langsame Wachsen des Balkens auf dem KC-Bildschirm beim Übertragen von Dateien beobachtet, wird sich unweigerlich fragen, ob das nicht auch schneller geht. Die Antwort lautet: Vorerst nicht! Bedingt durch die ,,krumme`` Taktfrequenz des KC-Grundgerätes ist es nicht möglich, im V.24-Modul hinreichend exakte Übertragungsraten jenseits der 2400 Baud zu erzeugen. Unter günstigen Umständen funktionieren zwar auch noch 4800 Baud, aber dazu ist ein kleiner Trick notwendig, mit dem ich hier nicht erst anfangen möchte.

Inzwischen zeichnet sich eine viel bessere Lösung ab. Mit der vollen Ausbaustufe des Scanner-Moduls von Enrico Grämer wird es möglich sein, Übertragungsraten von bis zu 115200 Baud zu erreichen. Mit geeigneten Schnittstellentreibern und einer angepaßten Kopplung von Grundgerät und D004 könnten damit die Übertragungsraten von derzeit etwa 0,2 KByte/s bis auf nahezu 10 KByte/s steigen. Wer also an einem schnellen Datenaustausch zwischen KC und PC interessiert ist, der sollte sich schon mal für eines dieser Module vormerken lassen!

Damit aber erst mal genug der Zukunftsmusik. Wie auch bereits beim letzten Mal bin ich wieder sehr an Erfahrungsberichten über das Nachvollziehen der Rechnerkopplung und über die Anwendung der MTOOLS interessiert.

Viel Spaß beim Experimentieren!

ZPATCH 1.7b - Update

von Mario Leubner

Wer das Z-System kennt und die sehr guten dazugehörigen Tools, der kennt bestimmt auch das Programm ZPATCH oder einfach ZP. Damit lassen sich Dateien komfortabel patchen, also im Bytemodus Änderungen vornehmen. Ein Beispiel dazu wäre das Anpassen von Steuerzeichen an den eigenen Rechner oder das Ändern von Texten in Programmdateien, um zum Beispiel englische Meldungen durch deutsche zu ersetzen. Natürlich muß man dabei genau wissen, was man ändern kann - eine gewisse Erfahrung gehört also schon dazu.

ZP hat aber noch zwei weitere Betriebsarten: den Speichermodus und den Laufwerksmodus. Im Speichermodus kann man direkt auf den Speicher des Rechners zugreifen - beim KC natürlich nur auf den TPA im D004. Interessant ist dies für den Koppel-RAM mit seinen speziellen Arbeitszellen oder bei entsprechender Kenntnis auch andere Teile des Betriebssystems und des Arbeitsspeichers. Auch hier gilt, daß nur bei entsprechender Kenntnis Änderungen vorgenommen werden sollten. Sonst kann man das System ganz leicht zum Absturz bringen, denn ZP überwacht nicht was der Anwender eingibt!

Der dritte Anwendungsfall ist der Zugriff auf jeden beliebigen Sektor eines Datenträgers. Darauf will ich etwas näher eingehen und die möglichen Kommandos erläutern. Zunächst sollten wir uns jedoch verdeutlichen, wie ein Datenträger aufgebaut ist. Als Beispiel nehmen wir unsere 780K-Diskette. Wie sind diese 780K aufgeteilt? Und wie verwaltet unser Betriebssystem diese?

Bild 1: Aufbau einer 5,25''-Diskette

Bild 1 zeigt den Aufbau einer 5,25``-Diskette. Unter der quadratischen Schutzhülle befindet sich die eigentliche Diskette, eine runde Scheibe mit magnetisch empfindlicher Schicht. Nur an wenigen Stellen besitzt die Schutzhülle Öffnungen. Da wäre als erstes das große mittlere Loch genannt, was zum Antrieb der Diskette gebraucht wird. Liegt die Diskette im Laufwerk, dann kann über das Langloch der Schreib-Lese-Kopf die Daten abtasten. Der Kopf bewegt sich dabei von innen nach außen, also von einer Spur zur anderen, während sich die Diskette dreht. Seitlich befindet sich eine Schreibschutzkerbe. Wird diese zugeklebt, dann kann die Diskette nur noch gelesen jedoch nicht überschrieben werden. Das kleine Loch in der Mitte ist das Indexloch, es kennzeichnet den Anfang einer Spur. Eine 780K-Diskette besitzt bekanntlich 80 Spuren, diese werden von 0 bis 79 gezählt wobei die äußerste Spur immer die Spur 0 ist. Jede Spur ist in Sektoren aufgeteilt, für unsere Diskette sind das 5 Sektoren zu je 1024 Byte. Das ist zunächst die physische Organisation der Diskette, es werden also immer 1024 Byte zusammenhängend gelesen oder geschrieben. Außerdem besitzt unser Laufwerk zwei Schreib-Lese-Köpfe, die gleichzeitig Vorder- und Rückseite der Diskette abtasten - das nennt man ein doppelseitiges Format. Das ganze läßt sich für andere Diskettenformate oder auch Festplatten wiederholen. Man muß nur die entsprechenden Werte für die Anzahl der Spuren, Sektoren und Schreib-Lese-Köpfe einsetzen und kann die Kapazität berechnen:

Für unsere Diskette ergibt sich also 5 * 1024 * 80 * 2 = 800K. Doch unser Format wird mit 780K angegeben und nicht mit 800K? Das liegt daran, daß 2 Spuren als Systemspuren reserviert sind. Diese beiden Spuren stehen damit nicht für die Datenspeicherung zur Verfügung und man müßte eigentlich rechnen: 5 * 1024 * 78 * 2 und erhält richtig die 780K.

Mit dem physischen Diskettenformat kann unser CP/M-Betriebssystem nicht viel anfangen, da es zu viele verschiedene Formate gibt. Aus diesem Grund einigten sich die Entwickler auf eine einheitliche Aufteilung in logische Sektoren. Die Festlegung besagt, daß ein logischer Sektor immer 128 Byte groß ist. Die Umrechnung zwischen logischen und physischen Sektoren erfolgt im BIOS, also dort wo die Zugriffe auf den Datenträger stattfinden. Das BIOS rechnet also aus der logischen Sektornummer die entsprechende physische Sektornummer und die Diskettenseite aus. Beim Lesen und Schreiben werden also immer 128 Byte als logische Einheit übertragen, ein Zugriff auf den Datenträger erfolgt aber erst, wenn die physische Sektorgrenze erreicht ist. Im Falle der 780K-Diskette also erst nach 8 logischen Sektoren wenn der Reihe nach gelesen bzw. geschrieben wird.

Kommen wir zurück zum Programm ZP. Ruft man ZP mit einer Laufwerksbezeichnung auf, also etwa mit dem Kommando ZP B:, dann erhält man das in Bild 2 gezeigte Anfangsbild.

Bild 2: Anfangsbild von ZP

In der oberen Statuszeile stehen hinter der Programmversion als erstes das Laufwerk, danach Spur, Sektor und Blocknummer. Als Anfangseinstellung wird die erste Spur nach den Systemspuren angewählt, in unserem Falle die Spur 2. In dieser Spur beginnt das Diskettenverzeichnis. Jeder Verzeichniseintrag ist 32 Byte groß, in einem 128 Byte großen Sektor haben also 4 Einträge Platz. Im Bild kann man 4 Dateinamen erkennen, diese gehören zu den ersten 4 Dateien welche sich auf der Diskette befinden. Das erste Byte kennzeichnet den USER-Bereich und ist bei den ersten drei Einträgen 0. Der vierte Eintrag beginnt mit E5. Das ist die Löschmarkierung, die Datei wurde also nicht wirklich gelöscht sondern nur dieses eine Byte verändert. Nach der USER-Nummer folgen 8 Zeichen für den Dateinamen und 3 für den Dateityp, hierbei kann auch das Bit 7 eines Zeichens gesetzt sein um ein Dateiattribut zu kennzeichnen. Anschließend folgen 4 Bytes zur Dateigröße, den genauen Zusammenhang will ich an dieser Stelle nicht näher erläutern.

Zur Verwaltung von Dateien nutzt das BDOS von CP/M eine weitere Struktureinheit, den Block. Ein Block kann verschieden groß sein, die Größe ist unter anderem abhängig von der Kapazität des Datenträgers und der Anzahl der möglichen Verzeichniseinträge. Festgelegt wird die Blockgröße im Diskettenparameterblock (DPB) im BIOS. Dort ist zum Beispiel für unsere 780K-Diskette eine Blockgröße von 2 KByte festgelegt. Eine Datei besteht aus einer bestimmten Anzahl von Blöcken. Eine Datei mit nur einem einzigen Zeichen benötigt demnach einen Block und belegt 2K auf der Diskette. Bis zu 2048 Zeichen haben in diesem Block Platz, dann wird ein weiterer Block gebraucht. Um die Blöcke den Dateien zuordnen zu können, schreibt CP/M die Blocknummern ins Verzeichnis. Ab dem 16. Byte, also in der zweiten Zeile jedes Eintrages bei der Darstellungsweise von ZP stehen die Blocknummern in hexadezimaler Schreibweise. Für den ersten Eintrag mit dem Dateinamen !!!TIME&.DAT ist das die Blocknummer 0002h. Der nächste Eintrag belegt die Blocknummern 0003h, 0004h, 0005h und 0006h usw. Reicht ein Verzeichniseintrag nicht aus um alle Blocknummern aufzunehmen, wird ein weiterer angelegt.

Unter der Sektoranzeige von ZP werden die zur Verfügung stehenden Kommandos in drei Menüspalten angezeigt. Ganz links stehen die Tasten, mit denen man Spur- und Sektorweise blättern kann. Es sind die im Z-System üblichen Ersatz-Cursortasten. Mit den Tasten im mittleren Menü kann man einen bestimmten Sektor direkt anwählen:

Will man also wissen, was in einer Datei steht, die man im Verzeichnis gefunden hat, so liest man einfach die Blocknummer ab und gibt diese mit dem Kommando B ein. Die umständliche Umrechnung von Blocknummer in Spur und Sektor übernimmt dabei ZP. Die Blocknummern beginnen direkt nach den Systemspuren und werden mit 0 beginnend fortlaufend gezählt. Das Verzeichnis beginnt also immer mit der Blocknummer 0. Unsere 780K-Diskette ermöglicht 128 Verzeichniseinträge, das sind 4096 Byte oder 2 Blöcke zu je 2 KByte. Damit umfaßt das Verzeichnis die Blöcke 0 und 1. Ab dem Block 2 können Daten gespeichert werden. Die Datei !!!TIME&.DAT enthält die Datumseinträge als Ergänzung zum Verzeichnis. Diese Datei muß immer direkt nach dem Verzeichnis stehen, ist stets der erste Verzeichniseintrag und belegt die ersten Blöcke nach dem Verzeichnis. Wenn diese Datei korrekt erzeugt wurde, ist der erste Verzeichniseintrag einer 780K-Diskette mit dem in unserem Beispiel identisch.

In der rechten Menüleiste stehen die Kommandos zum Editieren, Suchen und zum Wechsel des Modus. Interessant ist in dem Zusammenhang eine Suche über den ganzen Datenträger! Man kann z.B. eine Zeichenkette suchen lassen und notiert sich die Blocknummern in denen sie gefunden wird. Dann geht man wieder zum Block 0, also den Beginn des Verzeichnisses, und sucht nach der Blocknummer, um die dazugehörige Datei zu ermitteln.

ZP ist in der Version 1.7a auf der V-Disk Nr. V047 vorhanden. Zur Nutzung mit großen Datenträgern, also Festplatten, habe ich eine Erweiterung der Arithmetik vorgenommen. Je nach Blockgröße funktionierte die Berechnung der Blocknummern nur bis zu einer bestimmten Grenze, da die Multiplikation auf 16 Bit beschränkt war - für Disketten völlig ausreichend. Durch meine Erweiterung auf 32 Bit tritt auch bei großen Festplatten kein Überlauf mehr auf und die Zuordnung der Blöcke erfolgt korrekt. Die aktualisierte Version 1.7b stelle ich dem KC-Club zur Verfügung, eine Nutzung ist allerdings nur möglich, wenn das Z-System läuft.

ML.COM - Version 2.5

von Mario Leubner

Als weiteres Update gibt es eine neue Version von ML.COM. Neu ist unter anderem der automatische Wechsel zum 80-Zeichenmodus, falls dieser nicht vorliegt. Außerdem habe ich noch ein paar neue Dateitypen definiert. Damit sind wir schon bei der nächsten Datei welche ich TYPEN.TXW genannt habe. Das ist ein Text im Format von WP6, er beinhaltet eine Liste von Dateitypen mit der zugehörigen Erläuterung. Die Liste wurde jetzt auf 150 verschiedene Typen erweitert. Hier kann jeder nachsehen, wofür eine Datei mit einer bestimmten Endung vorgesehen ist oder ob eine geplante Endung für ein anderes Programm vielleicht schon existiert. Änderungen und Ergänzungen bitte mitteilen, ich sammle weiter...

EPROM-Brenner-Modul M030

von Mario Leubner

Wie es der Zufall wollte, bekam ich von Ralf Däubner ein halbfertiges M030 in die Hand - der legendäre EPROM-Brenner von Mühlhausen. Legendär deshalb, weil ich bis heute niemanden ausfindig machen konnte, der ein solches Modul funktionstüchtig gesehen hat oder sogar besitzt. Wurde es wirklich produziert oder ist es bei halbfertigen Prototypen geblieben? Die Frage wird sich wohl nicht beantworten lassen oder hat jemand aus dem KC-Club nähere Informationen?

Was hatte ich in der Hand: Es war das Modul, auf dem noch ein paar Bauteile fehlten. Dazu hatte ich glücklicherweise einen Schaltplan mit Bestückungsplan. Und sogar die zugehörige Software war auf Diskette vorhanden. Also doch ganz gute Bedingungen für einen Versuch, das Modul zum Laufen zu bringen.

Zunächst erfolgte eine Analyse, welche Bauteile fehlten. Da war ein Steckplatz für einen 8K-EPROM vorhanden, der die Brennersoftware beinhalten sollte und fest auf Adresse C000H geschaltet wird, sobald das Modul online ist. Sockel und EPROM fehlten, aber für einen Test kann man das Programm ja erst mal in ein RAM-Modul laden. Dann fehlte ein PROM K155RT4, welcher als Adreßdecoder eingesetzt wurde. Der Programmiersockel, welcher vorn über das Modul herausragt, war natürlich auch nicht vorhanden. Und für die Erzeugung der Programmierspannung war noch ein freier Platz an einer Stelle, wo sich eine Drossel unbekannter Dimension befinden sollte. Ansonsten schien alles andere bestückt zu sein.

Für einen ersten Versuch könnte man das Modul ja trotzdem mal in einen KC stecken und sehen was passiert. Also Modul rein in den Rechner und einschalten: Kurzschluß auf der 5V-Betriebsspannung! Na dann Rechner schnell wieder aus und das Modul noch einmal kontrolliert. Der Fehler war ein falsch herum eingesetzter Schaltkreis. Alle IC's werden üblicherweise in einer Richtung bestückt, nur bei diesem Modul ein einzelner andersherum. Das hat man wahrscheinlich bei der Bestückung nicht beachtet und nur nach langer Sucherei bemerkte ich endlich diesen feinen Unterschied im Bestückungsplan. Der Schaltkreis (ein DL541) war natürlich hin, zum Glück befand sich ein solches Exemplar in meiner Bastelkiste.

Beim zweiten Versuch hielt wenigstens die Spannung stand und der Rechner spielte nicht mehr verrückt. Allerdings konnte ich weder das Modul einschalten, noch ein Kennbyte auslesen und auch das Laden der Software zeigte keine Reaktion. Jetzt brauchte man den nicht vorhandenen Adreßdecoder: Hier hatte ich die größten Probleme, denn weder hatte ich einen einen passenden PROM, noch kannte ich den den dazugehörigen Inhalt. Eine Analyse der Software mittels Reassembler brachte mich zu den benutzten Portadressen und daraus konnte ich die logische Funktion des Decoders herleiten. Zunächst wollte ich einen EPROM 2716 als Decoder ver(sch)wenden, das scheiterte aber wegen der zu langen Zugriffszeiten. Eine andere Lösung erforderte mindestens zwei Schaltkreise. Zwei DS8205 verrichten den selben Zweck und wurden mittels Wickeltechnik angeschlossen. Den Platz dafür konnte ich schaffen, indem ich einen größeren Elko an eine andere Stelle verlegte.

Bild 1: Ersatz des Decoder-PROM im Modul M030

Nachdem der Decoder arbeitete, meldete sich das Modul korrekt mit dem Kennbyte D9. In meiner Modul-Liste gibt es noch ein weiteres Kennbyte für einen EPROM-Brenner mit Kennbyte DB und anderen Portadressen. Ob es so etwas auch gab? Eventuell noch eine Weiterentwicklung oder eine Eigenerfindung?

Also weiter mit der Erprobung des vorhandenen Moduls. Jetzt mußte der fehlende Textool-Sockel eingesetzt werden, damit man mal versuchen kann einen bekannten EPROM zu lesen. Inzwischen hatte ich auch die Software auf einen 2764 gebrannt und den benötigten EPROM-Sockel eingesetzt. Doch zur Funktion: Fehlanzeige. Es fehlte noch ein Adreßbit an einem Treiber-IC, da war doch tatsächlich in der Leiterführung noch ein Fehler in der Platine. Obwohl bereits eine Drahtbrücke für eine Korrektur sorgen sollte, war das benötigte Signal noch nicht an allen erforderlichen Stellen vorhanden. Weitere Brücken mußten eingesetzt werden.

Jetzt konnte ich das Modul einschalten und sogar das Programm starten. An der Software habe ich keine Änderungen vorgenommen, wenn auch die Reassemblierung zeigte, daß etwa die Hälfte an Speicherplatz ausgereicht hätte für den Funktionsumfang und die Bedienung etwas umständlich ist. Ich wollte aber nichts neu erfinden sondern nur das Original zum Laufen bringen. Wenn alle Funktionen ausgeführt werden können, ist das Ziel erreicht. Und mit dem jetzigen Stand konnte ich wirklich schon die Inhalte von verschiedenen EPROM's lesen.

Fehlt nur noch die Programmierung. Da brauchte ich zunächst den Transverter, der die erforderliche Programmierspannung von 12V, 21V bzw. 25V erzeugt. Einen passenden Spulenkörper fand ich in der Bastelkiste, diesen habe ich mit soviel wie möglich Kupferdraht von einer alten Relaisspule bewickelt. Daten für die Spule hatte ich ja nicht, doch die genauen Werte scheinen nicht so kritisch zu sein denn eine Änderung war nicht nötig. Zur Kontrolle der Spannungen mußte ich die PIO-Ausgänge statisch setzen. Hier half nur das Reassembler-Listing, wo ich mir die entsprechenden Ausgabe-Befehle herausgesucht habe. Mittels TEMO habe ich die Ports dann manuell programmiert und konnte die Spannungen kontrollieren - alles OK.

Nun war also der letzte Schritt getan - also leeren EPROM stecken und Programmierversuch. Doch nichts passierte, außer der Fehlermeldung, daß die Programmierung nicht gelungen ist. Also wieder das Meßgerät holen, den EPROM-Sockel leer lassen und den gesamten Brennvorgang Schritt für Schritt mittels OUT-Befehle in TEMO durchgehen und die Pegel an den EPROM-Pin's kontrollieren. Wie immer steckte der Teufel im Detail. Zunächst fehlte eine weitere Verbindung vom Transverterausgang, die Programmierspannung konnte also gar nicht bis zum EPROM vordringen. Der heimtückigste Fehler war allerdings ein Transistor. VT04 ist laut Schaltplan ein SC307 (pnp-Typ), eingelötet war jedoch ein SC239 (npn-Typ). Nachdem der richtige Transistor eingelötet war, ging auch die Zuschaltung der Programmierspannung.

Das war also die Geschichte, die einem halbfertigen Modul zu Leben verhalf. Ich weiß nicht, ob ich noch etwas vergessen habe. Der ganze Vorgang zog sich ja über mehrere Monate hin. Zum Glück hatte ich zumindest den Schaltplan zur Verfügung und das Programm auf Diskette vorliegen. Ohne diese beiden Dinge, wäre eine Fertigstellung des EPROM-Programmiermoduls aus der Vorserie wohl nicht gelungen. Die gute Nachricht: Es funktioniert, zumindest habe ich dies mit verschiedenen 2716, 2732, 2764 und 27C256 ausprobiert. Es war ein ganz schönes Stück Arbeit bis zu diesem Punkt. Allerdings bleibe ich bei meinem EPROM-Brenner mit M001 und den Zähler-IC's.

Die Vorteile des M030:

• Die Software ist gleich im Modul enthalten, muß also nicht erst geladen werden.
• Der EPROM-Programmiersockel befindet sich gleich im verlängerten Modul, somit fällt das Kabel und der Stecker weg.
• Die Programmierspannung wird per Software geschalten. Damit fällt die umständliche Voreinstellung des EPROM-Typs und der Programmierspannung mit DIL-Schalter oder Drehschalter weg.

Die Nachteile des M030:

• Programmierung von 64K-EPROM's (27512) ist nicht möglich. Diese werden zum Beispiel für das EPROM-Floppy benötigt.
• Keine Schnellfunktion ,,View`` zum Betrachten des EPROM- oder RAM-Inhaltes.
• Keine Funktion zum Brennen mehrerer EPROM's in einem Schritt, zum Beispiel der 4 Stück 2716 für ein M025.
• Da das Brennprogramm im Modul den Speicherbereich C000H-DFFFH überlagert, kann aus diesem Bereich keine Software gebrannt werden. Es ist also nicht direkt möglich, CAOS-EPROM's oder BASIC, EDAS, FORTH usw. aus dem Speicher heraus zu brennen. Eine Kopierfunktion für Speicherinhalte existiert auch nicht.
• Den Programmiervorgang kann man nicht am Bildschirm verfolgen, es wird lediglich durch eine rot leuchtende LED angezeigt, daß die Programmierspannung anliegt. Hier wäre eine mitlaufende Adresse hilfreich.
• Beachten muß man die richtige Lage beim Stecken des EPROM's in die Programmierfassung. Die Kerbe (Pin 1) muß links sein und die ,,kurzen`` EPROM's (2716 und 2732) müssen rechtsbündig gesteckt werden. Hier wäre eine Kennzeichnung am Gehäuse sinnvoll, vielleicht war so etwas ja vorgesehen?

Soviel für heute vom Betriebssystem-Koordinator. Viel Spaß beim Ausprobieren der neuen Programme!

Datenanalyseprogramme

von Henning Räder

Seit einiger Zeit habe ich mich mit der Wiedernutzbarmachung von Datenanalyseprogrammen am KC und am ZX81 befaßt. Besonders die von Prof. Henrion finde ich sehr gut, leider gab es keine Kassettenaufnahmen mehr von diesen. Dank direkter Kontakte und vielen wertvollen Hinweisen von Prof. Henrion und seinen Söhnen liegen nun die für den KC und den ZX81 geschriebenen Programme aus den Fachbüchern [1] und [2] als Diskettenversionen vor. Ich habe für den KC die Programme eingetippt. Bei den Versionen für den ZX81 hat mich Herr Gerhard Dohnke aus Berlin tatkräftig unterstützt, wofür ich ihm sehr danke.

Eigentlich war das Programm EDIT (Seite 228 in [2]) als Editierprogramm für Kassette geschrieben worden. Ich habe es an den Diskettenbetrieb angepaßt. Im Archiv ANALYSE.PMA befindet sich auch der Beispieldatensatz IRIS (in [1] auf Seite 325), der mit EDIT eingegeben wurde und mit den Programmen HIERAG, NLM, HKA und DIMIN ausgewertet werden kann. Wird z.B. das BASIC- Programm HIERAG als gestartet, wird der IRIS-Datensatz automatisch eingelesen und bei Eingabe der Abfragen ausgewertet. Die gezeigte Auswertung nur eines Datensatzes ist nur eine Demonstration. Die vielen in [1] und [2] vorhandenen Datensätze und auch eigene können mit EDIT eingegeben und bearbeitet werden.

Bei der Übertragung der Datenverarbeitungsprogramme aus dem ZX81- BASIC in das KC-BASIC hatte ich bei EXTRAKT von Prof. Henrion doch einige Probleme. Das Programm lag nur als ZX81-Version vor und die unterschiedliche Stringverarbeitung sowie Unterschiede beim PRINT- Befehl bereiteten Probleme. Am häßlichsten waren die Dimensionierungsunterschiede. So nimmt der KC innerhalb eines Programms eine Umdimensionierung von DIM L(K) in DIM L(K2) nicht an und bringt konstant die Fehlermeldung ,,doppelte Dimensionierung``. Das ist sicher bei kurzen Programmen kein Beinbruch, aber bei langen Programmen mit Verzweigungen kommt man beim Erfinden neuer Dimensionierungszeichen und deren exakter Substitution ganz schön ins Schwitzen. Im Archiv ANALYSE.PMA befindet sich auch EXTRAKT für den KC. Zum Originalprogramm vom ZX81 mußten noch die PRINTAT-Befehle der Zeilen 4390 und 4400 geändert werden, da sonst die Blockdarstellung von F- und T-Test teilweise aufeinandergeschrieben werden. Die genaue Ursache dafür konnte ich nicht finden.

Alle meine Programmtests zeigten richtige Ergebnisse, auch im Vergleich zu den Ergebnissen am ZX81. Ich halte dieses umfangreiche Programm für sehr gut.

Literatur

[1] G. Henrion, A. Henrion und R. Henrion: Beispiele zur Datenanalyse mit BASIC-Programmen, Deutscher Verlag der Wissenschaften, Berlin, 1988.

[2] Chemometrische Strategien in der Analytik, Deutscher Verlag der Wissenschaften, Leipzig, 1990.

CD-ROM-Laufwerk und CP/M

Ohne viele begleitende Worte findet Ihr auf der heutigen Beilagendiskette das Archiv CPMCD.ARC. Wer dieses Archiv mit UNARC.COM auspackt, erhält das Programm CDSWEEP zum Zugriff auf CD-ROM-Laufwerke unter CP/M, einschließlich der (englischen) Dokumentation und einiger Quelltextteile. Der Autor ist Hal Bower, der bereits als Mitautor von ZSDOS bekannt sein dürfte. Über Helmut Jungkunz und Jörg Linder gelangte dieses Programmpaket nun schließlich auch zu uns.

Einziger Wehrmutstropfen bei der ganze Sache: Es gibt noch keinen Treiber für den - technisch möglichen - Anschluß eines CD-ROM-Laufwerkes an das GIDE. Insofern sollte dieses Paket nur als Information für Interessierte angesehen werden oder hat vielleicht jemand im KC-Club den Mut, sich des fehlenden Treibers anzunehmen?

Frank Dachselt

Probleme zum Schmunzeln?

entdeckt und zusammengestellt von Ralf Kästner und Mario Leubner

Durch aufmerksames Lesen einschlägiger Computerzeitschriften befördert man die eine oder andere Perle ans Tageslicht, welche uns als KC-Insider nur ein müdes Lächeln abgewinnen kann. Schließlich wissen wir beim Programmieren noch, was in unserem Gerät abläuft und wenn mal was nicht geht, läßt sich der Fehler eigentlich immer lokalisieren und abstellen - bei den heutigen PC-Programmen und Betriebssystemen wohl nur noch ein Märchen aus 1001 Nacht ...

Ganz zutreffend auf diese Problematik wurde im Sommer dieses Jahres Billy-Boy oft zitiert, als er auf einer Computermesse die Entwicklung in der Computertechnik mit der Automobilbranche verglich, leider fehlte bei vielen Zitaten der interessantere zweite Teil des Vergleichs ...

Computer-Fortschritt

Im ,,Manager Magazin`` 8/98 wird über einen Vergleich der Computer mit der Autobranche berichtet. Microsoft-Chef Bill Gates sagte auf einer Computer-Messe, wenn General Motors ähnliche technologische Fortschritte gemacht hätte wie die Computer-Branche, würden Autos nur noch 5 Dollar kosten und für über 1000 Kilometer nur 4 Liter Kraftstoff brauchen.

Darauf General Motors: Das stimme schon, aber wer wolle schon ein Auto fahren, das zweimal am Tag zusammenbricht? Und jedes Mal einen neuen Wagen kaufen, wenn die Fahrbahnmarkierung erneuert wird? Sie müßten akzeptieren, daß Ihr Wagen ohne ersichtlichen Grund den Geist aufgibt. Sie würden auch hinnehmen, daß Ihr PKW ein Fahrmanöver einfach nicht mitmacht - klaglos würden Sie anhalten und den Motor auswechseln. Ihr Auto hätte nur einen Sitz, es sei denn, Sie kauften sich teure Sonderausstattungen. Der Airbag fragt: ,,Sind sie sicher?``, bevor er aufgeht. Macht nichts: Nach einem Crash wüßten Sie ohnedies nicht, was passiert ist.

gefunden in der ,,COMPUTER BILD`` Ausgabe 16/98

... dem läßt sich wohl nicht viel hinzufügen - oder liebe PC-Benutzer?

Der folgende Text geht in eine ähnliche Richtung und nimmt sich des Sprach-Problems ,,Computer-Englisch`` an, das in unserer Runde ebenfalls allgegenwärtig ist...

Was man beim Umgang mit Computern unbedingt wissen muß!

Den meisten von uns ist klar, daß das englische Wort Computer vom Verb `compute' (rechnen, schätzen) kommt, daß ein Computer also ein Rechner oder Schätzer ist. Aber noch immer gibt es viele Zeitgenossen, die vielleicht gerade erst anfangen, sich mit diesem komplexen Thema etwas näher zu befassen. Dieser Artikel soll all jenen helfen, die nicht mit einem Spielbuben (Game Boy) aufgewachsen sind und die nicht schon von Kind auf all diese verwirrenden Begriffe wie eine Muttersprache auf natürlichem Wege erlernen konnten.

Mutterbrett und Riesenbiss

Beginnen wir vielleicht mit den einfachen Dingen, die wir sehen, anfassen und damit auch noch begreifen können! Alle Bausteine eines Schätzers werden als Hartware (hardware) bezeichnet. Es ist sehr wichtig, daß man bei der Auswahl der Hartware sorgsam ist, denn nur auf guter Hartware kann die Weichware (software) richtig schnell laufen. Bei der Hartware ist das Mutterbrett (motherboard) von besonderer Bedeutung. Das Mutterbrett soll unter anderem mit einem Schnitzsatz (chipset) von Intel ausgerüstet sein. Natürlich gehört neben dem 3-1/2-Zoll Schlappscheibentreiber (floppy-disk-drive) auch ein Dichtscheiben-Lese-nur-Erinnerung (CD-ROM: Compact-Disk-Read-Only-Memory) zur Grundausrüstung. Eine Hartscheibe (harddisk) mit zwei Gigantischbiss (gigabyte) dürfte für die nächsten zwei bis drei Jahre ausreichend Platz für die Weichware und Daten bieten. Wenn wir unseren persönlichen Schätzer (PC) auch zum Spielen benutzen wollen, sollten wir uns neben der Maus auch noch einen Freudenstock (joystick) und ein gutes Schallbrett (soundboard) anschaffen.

Winzigweich und Kraftpunkt

So, damit sind nun die optimalen Grundlagen für Einbau und Betrieb der Weichware geschaffen! Damit die Weichware auf unserer Hartware überhaupt laufen kann, braucht es ein Betriebssystem. Es empfiehlt sich heute, ein solches mit einem grafischen Benutzer-Zwischengesicht (graphical user interface) zu installieren. Besonders weit verbreitet sind die Systeme Winzigweich-Fenster 3.1 (Microsoft Windows 3.1) und das neuere Fenster 95 des gleichen Herstellers. Für Leute, die mit ihrem Schätzer anspruchsvolle Arbeiten erledigen wollen, gibt es unter Fenster 95 das berühmte Bürofachmännisch 95 (Office Professional 95). Dieses Erzeugnis besteht aus den neuesten Ausgaben der Weichwaren Wort, Übertreff, Kraftpunkt und Zugriff (Word, Excel, Powerpoint und Access). Damit stehen dem Benutzer alle wichtigen Funktionen wie Wortveredlung (Word processing), Ausbreitblatt (Spreadsheet), Präsentationsgrafik und Datenstützpunkt-Behandlung (database management) zur Verfügung.

Aufsteller und Einsetzer

Wer selbst gerne Anwendungen entwickelt, kann dies unter Fenster beispielsweise mit dem modernen Sichtbar Grundlegend (Visual Basic) tun. Natürlich gibt es vor dem Gebrauch auch gewisse Hindernisse zu überwinden. Die Weichware muß zuerst via Aufsteller (setup) oder Einsetzer (install) auf der Hartscheibe eingerichtet werden. Das kann sehr viel Zeit brauchen, wenn sie ursprünglich auf Schlappscheiben geliefert wurde. Das Einrichten ab Dichtscheibe ist sehr viel angenehmer und schneller. Leider stellen aber auch hier die Aufsteller oft Fragen, die von vielen unverständlichen Begriffen nur so wimmeln. Aber die wollen wir uns ein andermal vornehmen...

gefunden im ,,CF`` Ausgabe 5/98, Seite 73

... ist jetzt alles klar?

Der letzte Text stammt aus dem ,,Funkamateur`` und beleuchtet die elektrischen Grundlagen all unseres Tun's und da sollte man sich ja auch ein wenig auskennen, zumindest schaden kann es nicht ...

Die Klassenarbeit

Nachdem der Lehrer mit viel Mühe den Schülern die Elektrizität erklärt hatte, lies er die berühmte Klassenarbeit schreiben. Dabei kam folgendes heraus:

DER STROM: Der Strom ist sehr dünn, aber man braucht für den Strom keinen Schlauch, er geht durch einfachen Draht. So dünn ist er. Mit Holz kann man keinen Strom übertragen. Wahrscheinlich saugt Holz ihn auf. Mit Kunststoff ist es genauso. Wenn Strom nicht gebraucht wird, ist er nicht dünn, im Gegenteil, er ist dickflüssig, damit er nicht aus der Steckdose läuft. Sonst müßte man immer einen Stopfen auf die Steckdose machen.

Woher der Strom weiß, wann er gebraucht wird und dann sehr dünn werden muß, ist noch unklar! Wahrscheinlich sieht er, wenn jemand mit einem Elektrogerät ins Zimmer kommt.

Strom ist nicht nur sehr dünn, sondern auch unsichtbar. Daher sieht man auch nicht, ob in einem Draht Strom drin ist oder nicht. Wenn Strom im Draht ist, tut es weh, wenn man ihn anfaßt. Das nennt man STROMSCHLAG.

Manchmal merkt man auch nichts. Entweder, weil kein Strom drin ist oder, weil man plötzlich tot ist. Das nennt man EXITUS.

Strom ist vielseitig, man kann damit kochen, bohren, heizen und vieles mehr. Wenn man einen Draht mit Strom an einen anderen Draht mit Strom hält, dann funkt und knallt es. Das nennt man KURZSCHLUSS. Aber dafür gibt es Sicherungen, die kann man wieder eindrehen. Außer dem Strom im Kabel gibt es noch Strom zum Mitnehmen. Der ist in kleine Schachteln verpackt. Der Fachmann nennt so etwas BATTERIE. Der Strom in der Schachtel kann natürlich nicht sehen, ob er gebraucht wird oder nicht. Deshalb läuft er manchmal so ohne Grund aus und frißt alles kaputt.

Es gibt mehrere Arten von Strom: STARKSTROM: Der Starkstrom heißt so, weil es unheimlich stark ist, was man mit ihm machen kann. WECHSELSTROM: Der Wechselstrom heißt so, weil seine Verwendung ständig wechselt. GLEICHSTROM: Der Gleichstrom heißt so, weil es ihm völlig gleich ist, was man mit ihm macht. Der Strom wird auch manchmal Elektrizität genannt.

ausgegraben und kräftig gelacht von Günter Gördes, DC6MF

gefunden im ,,FA`` 09/98, Seite 983