KC-News 2/1995

Top-Themen:

• ZAS 1.0
• Maustreiber für WordPro 6
• Anschluß 3,5" Diskettenlaufwerk
• Festplatte am KC
• KC-Bildformate
• Modulübersicht
• Clubtreffen 1995

Ein paar Worte zur Einleitung

von Jörg Linder

Auch wenn ich mir nicht ganz sicher bin, ob diese Artikel überhaupt gelesen werden, tippe ich mal wieder die letzten Bemerkungen für die KC-News. Der Aufruf zum "großen" Logo-Wettbewerb an dieser Stelle in der Ausgabe 1/95 bewegte immerhin 2 Mitglieder zu einer Beteiligung. Tröstend ist (zumindest für mich), daß es in anderen Clubs kaum besser aussieht. Der Club-80 suchte auch nach einem neuen Logo mit einer ebenso "starken" Resonanz wie bei uns - 2 Personen!

Ähnlich erfolglos verlief auch der Aufruf die persönliche Vorstellung der Mitglieder betreffend. Mit Ausnahme der "Leitungsmitglieder", die ich persönlich angesprochen hatte, hat mir niemand einen derartigen Artikel zukommen lassen.

Hoffentlich täusche ich mich, was das Lesen der Einleitung betrifft, denn sonst würden Euch die folgenden Neuigkeiten "durch die Lappen" gehen:

Mitgliederzahl - Kontostand

Wie bereits beim letzten Mal angedeutet, werden alle säumigen Zahler nicht mehr als Clubmitglied geführt. Das gilt zumindest so lange, bis der Beitrag auf dem Clubkonto eingegangen ist. Aufgrund dieser Tatsache, sind inzwischen 63 Mitglieder registriert, jedoch nur 52 davon haben bezahlt, und nur diese sind auf der letzten Seite abgedruckt.

Auf dem Clubtreffen habe ich einen Kassenbericht vorgelegt, der von Klaus Witzenhausen geprüft wurde. Es kam zu keinen Unregelmäßigkeiten und der aktuelle Kontostand (Stichtag: 01.05.95) beträgt 1.271,67 DM. Diese recht hohe Zahl sollte jedoch nicht täuschen, denn immerhin müssen in diesem Jahr noch drei KC-News davon finanziert werden (Nr. 2, 3 und 4/95). Doch eventuell ist eine Beitragssenkung im nächsten Jahr möglich...

Das Clubtreffen 1995/1996

Hoppla, "Clubtreffen 1996" - da hat er sich wohl verschrieben!? Dem ist nicht so. Auch wenn wir noch lange nicht das Jahr 1996 schreiben, sollten wir schon mal daran denken! An dieser Stelle kommt wieder einer meiner berühmten Aufrufe: Wer es sich zutraut, das Clubtreffen 1996 zu organisieren, sollte sich bei mir melden. Oftmals haben die Hotels (sehr) lange Voranmeldezeiten; hinzu kommt die Tatsache, daß in diesem Jahr nur noch 2 Ausgaben der KC-News erscheinen, mit denen wir Termin und Ort veröffentlichen könnten.

Von einigen Leuten wurde der Wunsch geäußert, uns beim nächsten Mal etwas weiter südlich zu treffen. Andere meinten, daß ein westlich von Berlin gelegener Ort günstiger wäre. Meiner Meinung nach ist es jedoch am wichtigsten, erstmal jemanden zu finden, der es überhaupt machen will (egal wo)!

Eigentlich sah die Planung auch ein paar Fotos und ein paar persönliche Eindrücke vom Treffen vor... Doch ich wollte nicht noch länger darauf warten - also muß es auch ohne gehen. Die beiden Herren fühlen sich jetzt hoffentlich angesprochen und sind nächstes Mal etwas flinker!

Schneller Informationsaustausch

Mal ganz ehrlich: Mit den KC-News ist man zwar auf dem Laufenden, aber wenn es um brandheiße Neuigkeiten geht, ist die vierteljährliche Erscheinungsweise doch nicht so optimal. Daher kam von Ralf Kästner der Vorschlag, die Zeitschrift "Computer-Flohmarkt" sozusagen als Zweit-Medium zu nutzen. Dieser Gedanke gefiel mir sofort, so daß jetzt auch dort regelmäßig von mir etwas zu lesen sein wird. (Wem die monatlichen 7 DM zuviel sind, braucht ja im Laden nur mal kurz ab Rubrik 4800 nachzuschauen. ;-))

Eine weitere Möglichkeit wäre die Nutzung von Helmut Jungkunz' Mailbox, der ZNODE 51. Solange wir keine eigene Mailbox haben, ist dies sicherlich eine (sehr) günstige Alternative. Zumal dort auch Software für die gesamte 8-Bit-Technik zum Download bereitsteht. Nachteilig ist das nur für die Mitglieder ohne PC und Modem. Doch unsere Tüftler sitzen ja schon am Modemanschluß für den KC.

Doch wer sich dort einloggt, bedenke bitte, daß keine Umlaute erlaubt sind (wegen der verschiedensten Rechner). Wer also eine Nachricht für mich hinterlassen will - ich heiße dort: JOERG LINDER.

Hardware-Nachschub

Auf dem Treffen konnte ich Kontakt zu zwei ehemaligen Mitarbeitern des Ex-Produzenten unseres geliebten KCs knüpfen. Einiges an Hardware ist bei ihnen noch vorhanden. Wer also noch etwas braucht, schreibt mir bitte. Ich leite das dann weiter.

Auch über eine Nachauflage der Platine des 1 MB RAM-Modules haben wir nachgedacht. Allerdings wird dies erst ab einer bestimmten Stückzahl interessant. Wer Interesse hat - Postkarte genügt!

Neue Rubriken

Zwei neue Rubriken sind ab dieser Ausgabe in den KC-News zu finden. Der Name der ersten - Programmierecke - erklärt sich eigentlich von selbst. Auch wenn es einen "richtigen" Programmierkurs nicht ersetzen kann, werden hier unsere Software-Autoren ihre Kniffe und Tricks zum Besten geben. (Für alle Interessenten: Die Programmierkurse sind nicht vergessen, jedoch muß man auch jemanden finden, der so etwas schreibt!)

Der Name der zweiten Rubrik - Speaker's Corner - entstand in Anlehnung an den gleichnamigen Platz im Londoner Hyde Park. Dort darf jeder so ziemlich alles sagen; ähnlich soll es auch hier sein. Hauptsächlich werden hier Beiträge ihren Platz finden, die für einen "richtigen" Artikel zu kurz sind.

In dieser Ausgabe, die übrigens bis zum Sommerloch im August reichen muß, ist hoffentlich wieder für viele Geschmäcker etwas dabei. Beim Stöbern, Staunen und Studieren wünsche ich wie immer viel Spaß!

Euer Redakteur

BASIC-Programme

von Ruthart Riehl

Mangels anderweitiger Tätigkeit und auch etwas Langeweile, habe ich sechs Programme geschrieben, die ich dem KC-Klub zur Nutzung übergeben möchte. Ich hoffe, daß Sie diese auch von einem Außenseiter übernehmen.

ADRESS-1.SSS Neue grafische Bedieneroberfläche
ADRESS1M.IRM
ADRESS1T.IRM
ADRESS1Z.PTB
ADR1-DA1.TTT
ADR1-DA2.TTT
ADR1A.TTT (Dateiname) diese und
ADR1B.TTT (Datenname) diese als Vorgabe so weitergeben!

GEWICHT .SSS berechnet das Körpergewicht nach der Größe
GEWICHT1.IRM
GEWICHT2.IRM

WEINKART.SSS Text zu bekannten Weinmarken
WEINKAR1.IRM
WEINKAR2.IRM

RACHE .SSS Wer rächt sich wann, wie und warum

SAVEBILD.SSS Anwenderprg.: Laden und speichern von Bildern,
SAVEBILD.PIP die auf BILD 1 (2) sind. PIP-Bilder nur auf Bild 0 (1)!

Für HCBASIC:

HCBASIC(cr)
DRIVE1(cr)
CLOAD"name"(cr)
RUN (cr) ....

ADRESSHC.SSS 12 ist schneller als ADRESS-1 !!! (4 MHz)

Bis auf RACHE laufen alle Programme nur mit Floppy!

ZAS 1.0 - die neue Steuerschleife für MicroDOS

von Mario Leubner

Einigen KC85/4-Usern ist ZAS (in einer älteren Version) sicher schon bekannt. Für alle anderen will ich erst mal das Anliegen des Programms erläutern: ZAS ("Z"entrale "A"bfrage"S"chleife) ersetzt die Steuerschleife, die während der Arbeit mit MicroDOS im CAOS-Grundgerät läuft und die Terminalfunktionen (Eingabe, Ausgabe, Drucken...) gewährleistet. ZAS läuft nur auf dem KC 85/4 (bzw. KC 85/5), da Programmcode enthalten ist, der speziell für den IRM-Aufbau dieser Rechner geschrieben wurde. Das Programm testet selbst das Vorhandensein eines KC 85/4 und bricht sonst mit einer Fehlermeldung ab.

Zum Laden von ZAS in der PC-Betriebsart einfach "ZAS" eingeben oder "ZAS" in die INITIAL.SUB-Datei schreiben und nach wenigen Sekunden erscheint die Bereitschaftsmeldung von ZAS. Erkennbar ist ZAS schon an der inversen Schrift, dem neuen Zeichensatz (!) und dem blinkenden Strichcursor.

Beim Start von ZAS wird das gesamte Programm zunächst ab 4000H in den RAM4 übertragen, um es dann mit einem LDIR-Befehl im DI auf den Bereich ab 400H zu kopieren. Im RAM4 wird ZAS danach gelöscht und dieser Speicherbereich ist wieder frei für andere Anwendungen. Die bereits installierten Drucker- und Koppeltreiber sowie die RAM-Floppy-Verwaltungstabelle bleiben unverändert erhalten! ZAS läuft wie die Originalsteuerschleife auf der Adresse 400H, ist aber etwas länger.

Da der Speicherbereich der Originalroutine nirgends dokumentiert wurde, kann man davon ausgehen, daß bisher kaum Programme in den nahen Bereich der Steuerschleife geschrieben wurden und so Konflikte mit ZAS bekommen. Allgemein gilt für die (alte als auch neue) zentrale Steuerschleife folgende Speicherbelegung im CAOS- RAM:

0200H..037FH	Druckertreiber
0380H..03FFH	Koppeltreiber
0400H..17FFH	Zentrale Steuerschleife mit KTAB, CCTL80, ESCTAB
1800H..1FFFH	hier liegen bei ZAS die IBM-Zeichencodetabellen für den 40-Zeichenmodus, wenn nicht mit dem IBM-Zeichensatz von CAOS4.3 (ZAS43.COM) gearbeitet wird.
2000H..3AFFH	mit Vorsicht als frei anzusehen (Erweiterungen!)
3B00H..3CFFH	RAM-Floppy-Verwaltungstabelle (für max. 4 MByte)
3D00H..3FFFH	Bildschirmhilfstabelle für KC85/2,3
4000H..7FFFH	bei KC85/2,3 nicht vorhanden, bei KC85/4,5 frei. Wird zum Laden von ZAS benötigt, ist danach aber wieder frei verfügbar.

Das Ziel von ZAS ist es, Fehler der Originalsteuerschleife zu beseitigen und dem Programmierer wie dem Anwender eine komfortablere Arbeitsumgebung zu bieten. Welche Möglichkeiten hat ZAS nun gegenüber der mit "JUMP FC" aus dem D004-ROM geladenen Steuerschleife?

Fehlerbeseitigung

• Cursor on/off von Tastatur ohne Nebeneffekte
• sichere Tastatur-Routine
• Wechsel 80/40 Zeichen ohne Nebeneffekte
• (IX+1) stimmt zu jeder Zeit mit OUT84 überein
• Wechsel zwischen PAGE- und SCROLL-Modus jederzeit möglich
• Punkttesten (ESC-'d') jetzt wirklich 16 Bit in XX
• Bildschirm-Steuerzeichen funktionieren jetzt auch im 40-Zeichenmodus
• Kein Absturz bei Tastencodes 81H und 92H..0F0H (Diese Codes könnten z.B. von einer externen V.24-Tastatur oder einer geänderten KTAB kommen.)
• Quittierung von ESC-'Ö' (Exit): Nach Warmstart wird dieses Zeichen nicht nochmals auf dem Bildschirm dargestellt
• Deutscher Zeichensatz auch bei Code 40H: Klammeraffe/Paragraph
• Blinken ein/aus bei Wechsel zwischen HIRES- und Normalmodus
• ESC-Funktionen vordefiniert bis ESC-7FH, dadurch kein Absturz durch Programmfehler mehr möglich
• über HEX-Funktion (F1+STOP) kann jetzt auch der Code 00H erzeugt werden, bei eingeschaltetem Tastenclick erfolgt die Tonausgabe nach der zweiten Hex-Ziffer, also bei Aktivierung des Codes als Tastencode.

Änderungen/Erweiterungen

Die KC85/4-Overlays wurden aufgelöst und teilweise effektiver programmiert. Deshalb ist ZAS auch nur auf dem KC85/4 lauffähig. Eine neue 80-Zeichen-Routine für Zeichensatz mit 10*4 Pixel gestattet wahlweise auch IBM-Grafikzeichen (Codes 20H-0FFH). Die Zeichenhöhe von 10 Byte ist erforderlich, damit bei den Grafikzeichen geschlossene Linien entstehen!

Im Vierzig-Zeichenmodus kann wahlweise ein IBM-Zeichensatz nachgeladen (ZAS.COM) bzw. der IBM-Zeichensatz aus CAOS4.3 (ZAS43.COM) verwendet werden. Der Cursor kann in 4 Varianten dargestellt werden. Eine Umschaltung ist nur über die Tastatur möglich. Das Blinken erfolgt mit CTC-Steuerung. Neue Tastenkombinationen gestatten außerdem den Wechsel des Zeichensatzes (ASCII/IBM) und die Nutzung der beiden Bilder des KC85/4.

ZAS V1.0

Mit der Version 1.0 hat ZAS die bisher umfangreichsten Erweiterungen erhalten. Das betrifft vor allem Funktionen zum Einfügen und Löschen von einzelnen Zeichen und ganzen Zeilen, und die Möglichkeit, Farbe und Fenstertechnik auch im 80- Zeichenmodus effektiver nutzen zu können. Im folgenden sind alle Neuerungen gegenüber der Version vom 09.06.94 erläutert, ausführlich ist alles nochmals in der Datei ZASINFO.DOK beschrieben, die im Archiv ZAS4.COM enthalten ist.

Zur Tastatureingabe ist zwischen der Steuerschleife und MicroDOS ein 32 Byte langer Puffer im Koppel-RAM angelegt. Schnelle Tastatureingaben werden also zwischengespeichert bis der Puffer voll ist ­ dann gehen die Tastencodes verloren. ZAS 1.0 erzeugt bei gefülltem Tastenpuffer einen "Puffer-voll-Click", um den Bediener anzuzeigen, daß der Tastencode nicht übernommen wurde. Der erzeugte Ton ist etwas tiefer und doppelt so lang wie der normale Tastenclick und damit gut von diesem zu unterscheiden.

Neue Bildschirmsteuerzeichen und ESCape-Routinen wurden definiert, um den Programmierern eine bessere Betriebssystemumgebung zu präsentieren und Programmieraufwand abzunehmen. Das Einfügen/Löschen von Zeilen/Zeichen sollte (wenn möglich) von den neuen Routinen ausgeführt werden. Daraus ergibt sich ein schnellerer Bildaufbau, da die Bytes direkt im IRM verschoben werden und nicht wie sonst üblich der Bildschirmrest komplett neu geschrieben werden muß. In den folgenden beiden Tabellen sind nur die neuen Funktionen aufgelistet, die komplette Liste steht in der Datei ZASINFO.DOK:

Tabelle 1: neue Bildschirmsteuerzeichen

ASCII	hex.	dez.	Wirkung der Kommandos
^B	02H	2	Cursor einschalten
^C	03H	3	Cursor ausschalten
^D	04H	4	Normaldarstellung (invers aus)
^E	05H	5	Inversdarstellung ein
^I	09H	9	Tabulatorschritt vorwärts
^K	0BH	11	Zeichen löschen, alle rechts vom Cursor befindlichen Zeichen der Zeile rücken um eine Stelle nach links
^N	0EH	14	Zeichensatz 1 (deutsch)
^O	0FH	15	Zeichensatz 2 (amerikanisch)
^R	12H	18	Leerzeichen an der Cursorposition einfügen, alle rechts davon befindlichen Zeichen werden um eine Stelle nach rechts verschoben. Der Cursor befindet sich anschließend auf dem erzeugten Leerzeichen.
^W	17H	23	Alle Zeichen ab der Cursorzeile (diese eingeschlossen) werden um eine Zeile nach unten verschoben. In der Zeile, in der sich der Cursor befindet, wird eine Leerzeile erzeugt. Der Cursor befindet sich anschließend am Anfang dieser Leerzeile.
^Y	19H	25	Löschen der Cursorzeile, alle weiteren Zeilen rücken von unten auf. Der Cursor befindet sich danach am Anfang der gelöschten bzw. der ersten nachgerückten Zeile.
	1CH	28	Scroll-Modus einschalten
	1DH	29	Page-Modus einschalten

Tabelle 2: neue ESCape-Funktionen

ASCII	hex.	dez.	Bedeutung	Name	Anz.	Parameter
I	49H	73	Tabulator rückwärts	BACKTAB	0	-
J	4AH	74	IBM-Zeichensatz	ZIBM	0	-
K	4BH	75	ASCII-Zeichensatz	ZASCII	0	-
Y	59H	89	256 Byte lesen	RD256	2	AA
Z	5AH	90	256 Byte schreiben	WR256	2	AA
f	66H	102	Farbmodus ein/aus	FARB80	1	S
g	67H	103	Fenster setzen	WIN80	6	X1,Y1,X2,Y2,F,H
h	68H	104	Fenster löschen	WCLS	0	-
i	69H	105	Schatten um Fenster	SHADOW	2	F,H
j	6AH	106	Rahmen in Fenster	FRAHM	1	F,N
k	6BH	107	Rahmen zeichnen	RAHM	7	XX1,Y1,XX2,Y2,N

Hinweise zu den ESCape-Funktionen

ESC-J und ESC-K

ESC-J schaltet den IBM-Grafikzeichensatz (8 Bit) ein. Der eingestellte Zeichensatz deutsch/amerikanisch bleibt davon unbeeinflußt. Wenn der IBM-Zeichensatz angewählt wurde, bewirken die Codes 80H die Anzeige des entsprechenden Grafikzeichens des IBM-Zeichensatzes, auch für die Codes 82H bis 85H, die im ASCII-Modus Steuerfunktionen haben! Diese Steuerfunktionen sind im IBM-Modus nur noch über die Codes 02 bis 05 erreichbar.

Wird Kompatibilität bei SCP-Programmen gewünscht, muß im ASCII-Modus gearbeitet werden. Im 40-Zeichenmodus wird der geladene IBM-Zeichensatz ab Adresse 1800H verwendet (bei ZAS43.COM der IBM-Zeichensatz von CAOS4.3 durch Setzen von Bit 5 von STBT). ESC-K schaltet auf ASCII-Zeichensatz (7 Bit) zurück, das entspricht der alten Darstellungsweise. Die Steuercodes 82H bis 85H sind wieder aktiv. Im 40-Zeichenmodus wird der Zeichensatz des CAOS-ROM auf den Adressen EE00H/FE00H verwendet (bei ZAS43.COM durch rücksetzen von Bit 5 von STBT).

ESC-Y und ESC-Z

Diese bisher nicht belegten ESC-Sequenzen wurden mit zwei neuen Funktionen zum schnellen Datenaustausch mit dem Grundgerät belegt. Dem Aufruf müssen 2 Parameter folgen, die der Anfangsadresse des gewünschten Bereiches im Grundgerät entspricht. Der Puffer für beide Routinen liegt im D004 von FD00H bis FDFFH, das hat den Vorteil, daß ein folgender RAM- Floppy-Zugriff den Inhalt des Puffers nicht verändert. ESC-Y liest 256 Bytes vom Grundgerät in den Koppelpuffer und ESC-Z schreibt 256 Bytes vom Koppelpuffer in den RAM des Grundgerätes. Es werden immer alle 256 Bytes übertragen, wobei dies von beiden Routinen nach Beendigung in der Speicherzelle MEMANF in gewohnter Weise quittiert wird.

ESC-f

Diese Funktion schaltet den Farbmodus für die 80-Zeichenroutine ein (S=1) bzw. aus (S=0). Die Rückmeldung erfolgt in Bit 5 von BSSTAT. Bei zugeschaltetem Farbmodus werden die Zeichen entsprechend der eingestellten Textfarbe eingefärbt. Zu beachten ist, daß durch die Zeichenbreite von 4 Bit jeweils 2 benachbarte Zeichen die gleiche Farbe erhalten!

Das gleiche Problem besteht ja auch bei der Erzeugung von Linien oder dem Setzen von Punkten. Die Berücksichtigung des Color-RAM erfolgt außerdem bei den Funktionen CLS, Zeile löschen, Zeile einfügen und beim Scrolling am Bildschirmende, nicht beim Einfügen/Löschen einzelner Zeichen mit ^K bzw. ^R. Im HIRES-Modus sollte der Farbzugriff ausgeschaltet werden, da hier eine andere Belegung der Pixel- und Color-Ebene erforderlich ist. Dies wird von ZAS noch nicht unterstützt.

ESC-g bis ESC-j

Diese Gruppe von Funktionen ist für den Einsatz im 80-Zeichenmodus gedacht. Mit ESC-g kann ein Fenster unter Angabe der Anfangszeile/Anfangsspalte, Breite und Länge definiert werden. Die anderen Funktionen beziehen sich auf dieses definierte Fenster und erzeugen Rahmen, Schatten oder Löschen den Pixelinhalt.

ESC-k

Zeichnet einen ein- oder mehrfachen Rahmen (wie bei ESC-j), die X- und Y-Koordinaten können frei gewählt werden.

Erweiterte Belegung des Koppel-RAM

Der Status, mit dem alle BS-Ausgaben von ZAS ausgeführt werden, ist an der Speicherzelle BSSTAT (0FFB6H) im MicroDOS zu erkennen. Die Aktualisierung von BSSTAT erfolgt von ZAS bei der Ausführung von Steuerzeichen, die die Einstellungen verändern. Beim Testen der Speicherzelle von Programmen aus, muß jedoch beachtet werden, daß zur Ausgabe ein Puffer von 32 Zeichen vorhanden ist und BSSTAT erst dann aktualisiert wird, wenn ZAS das entsprechende Steuerzeichen abgearbeitet hat. Die Zeit hängt also ganz davon ab, welche Ausgaben vorher noch auszuführen sind.

BSSTAT
(Adresse FFB6, Anfangswert=0)

Bit 0 0=80 Zeichen, 1=40 Zeichen
Bit 1 0=amerikanisch, 1=deutsch
Bit 2 0=groß, 1=klein
Bit 3 0=Scroll-Modus, 1=Page-Modus
Bit 4 0=ASCII (7 Bit), 1=IBM (8 Bit)
Bit 5 0=Pixelmodus, 1=Farbmodus

VERSION
(Adresse FFB9)

Beim Starten von ZAS wird hier die ZAS-Versionsnummer eingetragen, der Wert 10H entspricht dabei der Version 1.0. Ältere Versionen nutzen diese Speicherzelle nicht, beim Start von MicroDOS steht auf FFB9H der Wert 0. Zu beachten ist, daß ein Nachladen einer älteren ZAS-Version, die von ZAS V1.0 eingetragene Versionsnummer nicht zurücksetzt. Die Leistungen von ZAS V1.0 stehen dann nicht zur Verfügung, obwohl die Versionsnummer 1.0 noch erkannt wird!

Hinweise bei Problemen

ZAS ist so geschrieben worden, daß alle vorhandenen Funktionen weiterhin verfügbar sind ­ abgesehen von den beseitigten Fehlern! Dennoch ist es nicht auszuschließen, daß einige Programme nicht mehr laufen können. Hier noch ein paar Tips zur Abhilfe:

1. Programme, die direkt auf den IRM des KC zugreifen und diesen schalten, ohne die CAOS-Arbeitszelle (IX+1) zu aktualisieren, bekommen Probleme mit den Interrupts für den blinkenden Cursor. In solchen Fällen, kann es helfen wenn man sich eine nicht blinkende Cursorform zur Darstellung auswählt.
2. Programme, die im KC-Grundgerät RAM-Bereiche im Adreßbereich von 400H bis 2000H benutzen, können den Programmcode der neuen Steuerschleife zerstören. Eigene Programme sollten deshalb nur oberhalb 2000H, oder besser noch im RAM4 laufen.
3. Programme, die die Originalsteuerschleife teilweise durch Überschreiben modifizieren, sind unter ZAS nicht mehr lauffähig.
4. ZAS nutzt die ESC-Sequenzen des Grundgerätes. Wenn diese erweitert werden, muß sichergestellt sein, daß die Funktionen '0' bis 'A' unverändert weiter verfügbar bleiben.

Programm ZSMENU.COM

ZSMENU ist ein Beispiel für die Anwendung der neuen Möglichkeiten von ZAS. Es wird getestet, ob die Version 1.0 von ZAS geladen wurde (Speicherzelle VERSION). ZSMENU enthält auch eine Kurzform der Dokumentation, die anschaulich unter Verwendung der Fenstertechnik, Farbe, Inversdarstellung und Nutzung der Grafikzeichen und auf dem Bildschirm dargestellt wird. Der Ausdruck der Informationen ist außerdem mit einem EPSON-kompatiblen Drucker möglich. Weitere Menüpunkte in ZSMENU stellen die möglichen Zeichensätze dar und demonstrieren die Möglichkeiten zu Grafik und Tonausgabe.

 

Alle hier beschriebenen Programme sollen den KC85/4 unter MicroDOS, CP/M und NZ-COM aufwerten. Eine kostenlose Weitergabe der Programme unter Wahrung der Urheberschaft ist erwünscht. Zum Programmpaket gehören:

ZAS.COM

die neue Steuerschleife (IBM-Zeichensatz ab 1800H)

 

ZAS43.COM

ZAS-Version für IBM-Zeichensatz von CAOS4.3

 

ZSHOW.COM

ein Programm zur Anzeige des Zeichensatzes

 

ZSMENU.COM

menügeführtes Demoprogramm

 

ZASINFO.DOK

die Beschreibung

 

TYPEMOD,COM

Schreibmaschinenmodus der Tastatur ­ ZAS-Version

 

COMPUMOD.COM

Computermodus der Tastatur ­ ZAS-Version

Ursprünglich wurden diese Dateien in einem selbstentpackenden Archiv zusammengefaßt. In Anlehnung an die anderen Archive auf der Beilagen-Diskette wurden sie jedoch in einem "normalen" PMA-Archiv abgelegt. Die Bezeichnung ZAS4V10.PMA leitet sich von ZAS für KC 85/4 Version 1.0 ab.

Für Hinweise und Vorschläge, die ZAS betreffen, bin ich jederzeit zum Erfahrungsaustausch bereit. Die Tabelle der ESC-Sequenzen läßt sich noch bis ESC-7FH erweitern, auch hierfür nehme ich gern noch Vorschläge entgegen. Viel Spaß und wenige Rechnerabstürze bei der Arbeit mit ZAS wünscht

Mario Leubner

Serielle Maus unter MicroDOS

von Dirk Walther

Nach der Veröffentlichung von (1) lag es nah, neben den vorgestellten Maustreibern für das CAOS auch eine Lösung für MicroDOS zu suchen. Unter Verwendung und Abwandlung der MC- Routine MOUSE0.KCC aus (1) habe ich deshalb einen Maustreiber für die PC-Betriebsart des KC realisiert.

Das Programm MOUSE.COM selbst ist in Turbo-Pascal geschrieben. Der Quelltext ist in den beiden Dateien MOUSE.PAS und MOUSE.UPS enthalten. Ich stelle ihn jedem zur freien Verfügung.

Der Treiber schreibt eine Interrupt-Service-Routine in den RAM des KC-Grundgerätes und initialisiert Kanal 2 des ersten gefundenen V.24-Moduls für den Mausbetrieb. Falls es User gibt, die ihre Maus an einem anderen Kanal betreiben, sollten diese sich bitte bei mir melden.

Bei Interesse läßt sich der Treiber dann auch noch für andere Kanäle einrichten. Der Maustreiber läßt sich ohne Schwierigkeiten in die Datei INITIAL.SUB einbinden. Dazu war jedoch eine Umleitung aller Ausgabeoperationen auf die BIOS-Routine nötig.

Beim Aufruf des Programms lassen sich eine Reihe von Optionen angeben. Eine Liste aller möglichen Optionen erscheint bei dem Aufruf "MOUSE /?". Für die Optionen sind schon sinnvolle Voreinstellungen getroffen, die eine vernünftige Benutzung der Maus im 80-Zeichen-Modus erlauben.

Die möglichen Belegungen der rechten Maustaste in der PC-Betriebsart sind (2) zu entnehmen. Als Adresse der Interrupt-Service-Routine im Grundgerät ist 0000H voreingetellt, weil in der PC-Betriebsart der Speicherbereich unterhalb des Systemstacks noch frei ist.

Die Voreinstellungen lassen sich auch dauerhaft den eigenen Bedingungen anpassen. Im Programmkopf von MOUSE.PAS stehen die Voreinstellungen in der CONST-Vereinbarung und lassen sich dort nach Belieben modifizieren. Beim Compilieren des Quelltextes in ein .COM-File bitte unbedingt als Endadresse 4200H angeben! Das ist wichtig für die Speicherorganisation, falls MOUSE.COM aus einem anderen Programm heraus aufgerufen wird.

Für den Maustreiber war es erforderlich, EDAS-Programme in den Pascal-Quelltext einzubinden. Ein kleiner Tip, wie das einfach zu realisieren ist, soll im folgenden gegeben werden.

1. Das fertige und getestete EDAS-Programm wird mittels der Assembler-Option S in ein .KCC-File auf die Zieldiskette assembliert.
2. In der PC-Betriebsart wird am Eingabeprompt die Zeile ">>name.txt" eingegeben.
3. Mit einem geeigneten Programm (z.B. in POWER oder DIENST mit "TYPEH") wird der vollständige HEX-Dump des Programms ausgegeben. Ein anschließender Warmstart beendet die Ausgabe in eine Datei.
4. Mit einem Texteditor kann die Datei name.txt anschließend nachbearbeitet werden: alle überflüssigen Zeilen sowie der Vorblock werden entfernt, alle Leerzeichen durch ", $" ersetzt.
5. Dann kann der HEX-Dump in den Quelltext eingefügt werden und z.B. in eine CONST-Vereinbaruwg oder ein INLINE eingebunden werden.

Literatur

(1) Hendrik Haftmann: "Serielle Maus am KC" in KC-News 1/95; S.10 ff.

(2) KC 85 D004 Manual; S.22 ff.

Ein Maustreiber für WordPro6

von Mario Leubner

Endlich ist er da, der schon so lange erwartete Maustreiber für WordPro6. Eigentlich war es gar kein großes Problem, einen "MAUSALL"-Treiber WordPro6-tauglich zu machen. Grundproblem ist, daß unter WordPro6 der IRM teilweise abgeschaltet ist, freier Speicher aber nur von BA00H bis BBFFH, also im IRM zur Verfügung steht.

Interruptroutinen dürfen demnach nicht in den IRM-Adreßbereich springen. Der Maustreiber für WordPro6 steht aber in diesem IRM-Bereich, der Interrupt selbst wird auf 100H geleitet, wo nur ein kleines Programmstück zum Einschalten des IRM steht, danach kann die eigentliche Routine im IRM abgearbeitet werden.
Hardwarevoraussetzungen:

Es ist eine 3-Tastenmaus (Mouse-Systems-Modus), ein V.24-Modul und eventuell ein Adapterkabel zur Umsetzung des Diodenausgangs auf den 9-poligen Stecker erforderlich. Der Anschluß selbst wurde in den KC-News 1/95 ausführlich beschrieben und ist so z.B. auch mit dem Grafikprogramm UNIPIC nutzbar.

Der Maustreiber für WordPro6

Der Maustreiber MSWP61 wurde aus dem Quelltext MOUSE1.ASM abgeleitet, er kann also auch zwei Interruptquellen an einem V.24-Modul bedienen. Dies ist z.B. erforderlich, wenn mit einer V.24-Tastatur am Kanal 2 und der Maus am Kanal 1 des gleichen Moduls gearbeitet werden soll. Verwendet wird immer das erste gefundene V.24-Modul, welches automatisch zugeschalten wird. Zwei Module,wie bei dem Treiber MOUSE2.ASM unterstützt der WP-Treiber nicht!

Der Treiber MSWP61.KCC enthält ein Menüwort "MOUSE", mit dem die Maus installiert wird. Ist WordPro6 geladen, dann trägt sich MSWP61 beim Aufruf des Menüwortes selbst in WordPro6 ein, so daß ein nachfolgender Aufruf von WordPro6 diesen Maustreiber immer mit aktiviert! Zur Installation können noch 3 Parameter übergeben werden, die auch nachträglich noch verändert werden können:

%MOUSE [ n [ m [ r ]]]

Dabei bedeuten:

n - SIO-Kanal (1/2) oder Portadresse (8/9),
n=0 legt den Maustreiber tot.
(bei Angabe der Portadresse können auch Eigenbaumodule benutzt werden, diese müssen dann aber vorher eingeschaltet werden!)

m - Tastencode, den die mittlere Maustaste erzeugt

r - Tastencode, den die rechte Maustaste erzeugt

Wird kein Parameter angegeben, dann erfolgt die Aktivierung entsprechend der letzten Einstellung.

Zur kompletten und dauerhaften Installation des Maustreibers in WordPro6 sind die folgenden Arbeitsschritte erforderlich:

1. Laden von WordPro6
2. Mit Taste E zurück zum CAOS
3. Laden von MSWP61.KCC
4. Aufruf des Menüwortes MOUSE mit den gewünschten Parametern
5. Laden von WP6COPY.KCC
6. eventuell Installation von Tastatur und Drucker
7. Abspeichern von WordPro6, bei der Frage nach dem Bereich BA00 bis BFFF mit J antworten, damit der Maustreiber mit abgespeichert wird!

Mit dem Punkt 4 ist die Einbindung des Maustreibers in WordPro6 bereits abgeschlossen. Soll nur vorübergehend mit der Maus gearbeitet werden, können die Schritte 5-7 weggelassen werden. Zu Beachten wäre noch, daß eine WP6-Version mit installiertem Maustreiber nicht mehr ohne den Bereich BA00 bis BFFF abgespeichert werden darf, da die Einsprungadresse des Maustreibers erhalten bleibt! Neuinstallationen deshalb nur von den WordPro6-Dateien der Originaldiskette vornehmen!

Funktion der Maus in WordPro6

Ist die Maus ordnungsgemäß angeschlossen und installiert, müßte bereits im CAOS-Menü die Bewegung des Cursors mit der Maus möglich sein. Die Maustasten erzeugen Tastencodes, die wie normale Tastatureingaben ausgewertet werden:

• linke Taste: Enter
• mittlere Taste: F1 (IN/OUT-Menü)
• rechte Taste: F2 (Grafik-Menü)

Bei der Installation können die Codes der mittleren und rechten Maustaste auch anders belegt werden. Die Maustasten haben keine Repeat-Funktion!

Anpassungen

Um anderen Usern die Anpassung eines eigenen Treibers in WordPro6 zu erleichtern, gebe ich den Quelltext MSWP61.ASM mit. Insbesondere die Werte STEPX und STEPY können verwendet werden, um die Empfindlichkeit der Mausbewegung zu verändern. Als Anregung könnte der Treiber aber auch für die Einbindung einer parallelen Maus oder eines Joysticks dienen.

Viel Spaß mit dem Maustreiber unter WordPro6 wünscht Euch
Mario Leubner

EDAS-Arbeitszellen

von Mario Leubner

Vielfach wurde der Wunsch geäußert, die Arbeitszellen von EDAS zu veröffentlichen. Ich habe EDAS V1.4 weiterbearbeitet zu den Versionen 1.5 und 1.6 und deshalb die vollständige Liste aller Arbeitszellen. Leider liegt mir kein Quelltext von EDAS V1.4 mehr vor, so daß ich nicht genau sagen kann, welche Änderungen es gegeben hat. Da aber EDAS V1.4 die Ausgangsbasis war, dürfte es (abgesehen von den Erweiterungen) keine großen Unterschiede geben.

Beim Start von EDAS V1.5/1.6 mit dem Menüwort "EDAS" lassen sich die zu benutzenden RAM-Bereiche einstellen. EDAS V1.5/1.6 kann auch mit dem RAM-8 arbeiten, wobei der IRM ausgeblendet wird. EDAS schaltet keine Module! Die vorgegebenen Werte entsprechen den mit den aktuell zugeschalteten Speicherbereichen möglichen maximalen Werten:

Top of Text: 0200 untere RAM-Grenze
End of Text: C000 oberen RAM-Grenze
Start of MC: 0200 Standard-MC-Adresse
ASM-Offset : 0000 Assembleroffset für Option "O"

Der Quelltext liegt grundsätzlich geteilt vor, Trennstelle ist der Bildschirmanfang. Nach TOP liegt der Text ganz hinten, nach BOTTOM ganz vorn. Die Markentabelle liegt im Anschluß an den zweiten Textteil. Der in der Statuszeile angegebene freie Speicher ist der Zwischenraum zwischen den beiden Teiltexten. Während des Assemblerlaufes liegt der Text ungeteilt am Speicheranfang, so daß die Markentabelle von der vereinbarten Speicherobergrenze nach unten wachsen kann. Dabei wird überwacht, daß sie nicht in den Text hineinwächst.

 | Text 1  |  freier Speicher  |  Text 2  |  Markentabelle  |
 +---------+-------------------+----------+-----------------+
 |         |                   |          |                 |
T1A       T1E                 T2A      T2E/MTOP            MBOT
0200H                                                      C000H

1. Editor-Arbeitszellen:

Name:    Adr.: Länge:   init.   Bedeutung:
NAME      0      11             aktueller Dateiname
T1A      40H      2     0201H   Beginn Text 1
T2E      42H      2     BFFFH   Ende Text 2
T1E      44H      2     0201H   Ende Text 1
T2A      46H      2     BFFFH   Beginn Text 2
COL      48H      1        0    EDIT-Cursor (Spalte)
LIN      49H      1        0    EDIT-Cursor (Zeile)
M4A      4AH      1        0    wenn ungleich 0 - no Memory
STRING   4BH     33        -    String-Puffer (für FIND-Funktion)
STAT     6CH      1       13H   Kassetten-/Diskettenstatus
                          Bit 0 = 1 - Floppy vorhanden
                          Bit 1 = 1 - Umleitung auf Floppy
                          Bit 2 = 1 - Diskettenfehler
                          Bit 3 = 1 - Option 'S' merken
                          Bit 4 = 1 - DEP mit LW-Steuerung
                          Bit 7 = 1 - END-Befehl erkannt

2. Assembler-Arbeitszellen:

Name:    Adr.: Länge:   init.   Bedeutung:
OPT      6DH      1        0    Assembler-Optionen
                          Bit 0 L - Listing ausgeben
                          Bit 1 P - Umschaltung Drucker
                          Bit 2 + - Markentab. erweitern
                          Bit 3 1 - nur PASS 1!
                          Bit 4 3 - PASS 3 läuft (Save MC)
                          Bit 5 B - Bildschirmformat
                          Bit 6 O - MC in Speicher laden
                          Bit 7 2 - nur PASS 2
OFFS     6EH      2     0000H   Assembler-Offset
MCA      70H      2     0200H   Beginn Maschinencode
MBOT     72H      2     C000H   RAM-Ende+1
MTOP     74H      2     C000H   Marken-Tabelle (Anfang)
PBL      76H     18        -    Rechenregister für Assemblerlauf
NERR     88H     64        -    Assemblierpuffer

Die in der Spalte "init." eingetragenen Werte entstehen, wenn EDAS am KC85/4 mit Floppy und DEP2.2 gestartet und alle Eingabemöglichkeiten beim Programmstart mit Enter übergangen wurden. Der Textbeginn auf 201H ist programmtechnisch erforderlich, auf 200H steht ein 0DH. Beide Teiltexte und die Markentabelle sind leer.

Die Markentabelle, die meist nur im RAM8 steht, kann unter CAOS4.3 einfach mit MODIFY/DISPLAY angezeigt werden, indem man vorher mit SWITCH 1 0 den IRM ausblendet. Die Arbeit von EDAS bleibt davon unverändert. Auch SAVE, LOAD, FSAVE und FLOAD ist dann von der CAOS-Kommandoebene aus möglich. Unter älteren CAOS- Versionen ist es natürlich nicht so einfach möglich.

Viel Spaß beim Probieren wünscht Euch
Mario Leubner

Anschluß eines 3,5"-Diskettenlaufwerkes

von Mario Leubner

Wie beim Klubtreffen zu sehen war, habe ich mein D004-Drive um ein 3,5"-Diskettenlaufwerk erweitert. Erfreulicherweise funktioniert auch der Datenaustausch mit dem KC-Format (780K), was durch ein fehlerfreies Lesen der 3,5"-Disketten von Uwe Felgentreu bewiesen wurde. Auch Jörg Linder kann dieses Format mit seiner CPU280 verarbeiten.

Der Vorteil der kleineren Disketten:

• 3,5"-Disketten sind in einer stabilen Plastikhülle und deshalb unempfindlicher.
• Nach eigenen Erfahrungen sind die 3,5"-Disketten auch sicherer als 5,25"-Disketten, bis jetzt hatte ich noch keinen einzigen Diskettenfehler!
• Nicht zuletzt der Transport auf dem Postweg in einem Standardbrief für 1,- DM ist preiswerter.

Aus diesen Gründen habe ich mich entschlossen, den Anschluß meines Laufwerkes in Form dieses Beitrages aufzubereiten und somit für andere nachvollziehbar zu machen.

Verwendet habe ich ein PC-Laufwerk vom Typ "Teac FD235HF", angegeben mit 1,44MB - also ein HD-Laufwerk. Da wir zwar für unsere 800K nur DD-Disketten brauchen, ist zwar ein HD-Laufwerk nicht erforderlich, aber das HD-Laufwerke kann problemlos auch DD-Disketten verarbeiten. DD-Laufwerke werden für PC's auch nicht mehr angeboten. Dazu kommt die Möglichkeit, daß man später ja auch mal 1,44MB-Disketten auf dem KC verwenden könnte!?

Folgendes Material wird benötigt:

Bezeichnung	Preis
Stromversorgungskabel	5,95
Uni-Floppy-Kabel	14,90
PC-Laufwerk 1,44 MB	89,00

Die Preise sind noch von '95, ich habe 1994 für das Laufwerk noch 10,- DM mehr bezahlt, eventuell sind die Laufwerke auch noch preiswerter zu haben.

Das Gehäuse des D004-Drive bietet genug Platz zwischen dem Original-Laufwerk und dem Netzteil, um das neue Laufwerk aufzunehmen. Der mechanische Aufwand für den Umbau beschränkt sich auf das Aussparen der Frontplatte und das Einbauen eines kleinen Bleches, worauf das 3,5"-Laufwerk befestigt wird. Hier sollte jeder nach seinen Möglichkeiten vorgehen.

Für den elektrischen Anschluß ist ein Stromversorgungskabel erforderlich. Das oben angegebene Kabel wird einfach zwischen das vorhandene Kabel und das 5,25"-Laufwerk gesteckt und die beiden anderen Stecker zu den Laufwerken geführt.

Etwas mehr Aufwand ist für den Anschluß an den Datenbus erforderlich. Das oben angegebene Uni-Floppy-Kabel besitzt genügend Steckverbinder, um verschiedene Laufwerke miteinander zu verbinden. Das Kabel muß aber etwas modifiziert werden, um die unterschiedliche Belegung auszugleichen. Ich habe das alte Flachbandkabel aus der Klemmverbindung auf der Leiterplatte gelöst, und das neue dort eingesetzt. Dabei ist größte Sorgfalt geboten, damit alle Kontakte der Schneidklemmen wieder richtigen Kontakt geben. Denkbar wäre es auch, auf der Leiterplatte eine entsprechende Pfostenleiste einzusetzen und das neue Kabel anzustecken.

Wie aus der nachfolgenden Tabelle hervorgeht, gibt es einige Unterschiede in der Belegung der Steckverbinder. Die ersten 6 Kontakte sind an unserem Original-Laufwerk nicht angeschlossen. Der /HD-Anschluß muß nicht unbedingt belegt werden, wenn man nur DD-Formate verwenden will.

Steckerbelegung:

K5601	Kontakt	Masse	PC-Laufwerk
frei	2	1	/High Density
/IN USE	4	3	reserviert
/DS3	6	5	frei
/Index	8	7	/Index
/DS0	10	9	/Motor on A
/DS1	12	11	/Drive Select B
/DS2	14	13	/Drive Select A
/Motor on	16	15	/Motor on B
/DIR	18	17	/Direction
/Step	20	19	/Step Pulse
/WR-Daten	22	21	/Write Daten
/WR-Befehl	24	23	/Write Enable
/Track 0	26	25	/Track 0
/WR-Protect	28	27	/Write Protect
/RD-Daten	30	29	/Read-Daten
/SS	32	31	/Select Head 1
/Ready	34	33	/Disk Change

Das KC-Floppy-System gestattet den Anschluß von 4 physischen Laufwerken - entsprechend den Signalen /DS0 bis /DS3. Jedes Laufwerk ist dabei als /DS0 angeschlossen. Die Drehung der Signale erfolgt auf der Leiterplatte zwischen den Anschlüssen XFI und XFO, an XFD ist das Laufwerk angeschlossen:

XFD      XFI      XFO
/DS0 <-- /DS0
/DS1 <-- /DS1 --> /DS0
/DS2 <-- /DS2 --> /DS1
         /DS3 --> /DS2

Das Signal /DS0 wird nicht zu XFO weitergegeben, da hier das Laufwerk angeschlossen ist, /DS3 wird nicht zum Laufwerk weitergeleitet. Jetzt muß eine Entscheidung getroffen werden, mit welchem Signal das neue Laufwerk angesteuert werden soll. Ich habe mich dafür entschieden, /DS2 zu benutzen. Das 3,5"-Laufwerk ist demnach mit der physischen Adresse 2 ansprechbar. Damit ergibt sich die Möglichkeit, ein zweites D004-Drive an XFO anzuschließen, das unverändert die physische Adresse 1 besitzt. Wird ein weiteres 3,5"-Laufwerk in das zweite D004-Drive eingebaut und ebenfalls auf /DS2 gelegt, ergibt sich durch die Drehung die physische Adresse 3. Als Resultat erhält man 2 völlig identische Geräte und alle 4 Laufwerke sind ansprechbar.

Da am PC-Bus nur 2 Laufwerke (Drive A und B) anschließbar sind, ist das Interface-Kabel so zu modifizieren, daß bei aktivem /DS2 die Anschlüsse "/Motor on B" und "/Drive Select B" gleichzeitig aktiviert werden. Das Laufwerk ist dabei mit dem Jumper als Drive 1 zu konfigurieren, was der Standardeinstellung bei Auslieferung entspricht. Die folgende Skizze zeigt, welche Leitungen dafür getauscht werden müssen, um die erforderliche Beschaltung zu erreichen:

Eine weitere Besonderheit stellt das Signal auf Leitung 34 dar. Dieses Ready-Signal wird vom D004-Basis ausgewertet und meldet die Bereitschaft des Laufwerkes (Diskette ist eingelegt und Motor dreht sich). Das 3,5"-Laufwerk meldet auf dieses Leitung einen Diskettenwechsel als Impuls. Das Signal läßt sich also nicht verwenden. Als Ausweg habe ich das Signal /DS2 nach zweimaliger Negation mit einem Open-Kollektor-Gatter eines DL003 zum Ready-Signal geleitet. Der Anschluß 34 des Laufwerkes bleibt frei. Das Ready-Signal steht also sofort mit Aufruf des Laufwerkes an. Da aber beim Einsatz im PC ohnehin keine Ready- Meldung verwendet wird, kann das Laufwerk auch so fehlerfrei arbeiten. Eine nicht eingelegte Diskette kann jedoch nicht mehr erkannt werden.

Bild 1: Modifikationen zum Anschluß eines 3,5"-Diskettenlaufwerkes

Die Modifikation des Kabels besteht also in einer Drehung der Leitungen 14 bis 16 und dem Auftrennen der Leitung 34. (ACHTUNG! Das Kabel für die PC-Laufwerke ist an anderer Stelle gedreht!) Da der Anschluß XFD nur 26 Kontakte hat, ist wie bei dem Kabel aus dem D004-Drive ein Teil der Leitungen an dieser Seite abzutrennen. Um einen neuen Steckverbinder in Schneidklemmtechnik anzupressen immer eine neue Stelle des Kabels benutzen. Zum Pressen selbst gibt es Spezialzangen, bewährt hat sich auch ein Schraubstock wenn man entsprechend vorsichtig an die Sache geht. Wichtig ist nur, daß alle Kontakte gleichmäßig in die Schneidmesser gedrückt werden. Nach der Kabelherstellung sollte man zur Kontrolle nochmal alle Kontakte durchprüfen.

Auf der Leiterplatte im D004-Drive ist die Verbindung XFI-B5 zu XFD-B11 aufzutrennen, XFD-B10 mit XFD-B11 zu brücken und die beiden Leitungen zum Anschluß des DL003 anzuzapfen. Der DL003 kann auf einer kleinen Uni-Leiterplatte im Gehäuse des D004- Drive befestigt werden. Eine zusätzliche Verbindung zu Masse und +5V im Netzteil ist ebenfalls noch vorzusehen, damit der DL003 arbeiten kann. Der pull-up-Widerstand von ca. 1kOhm zwischen den beiden Gattern des DL003 ist für eine ordnungsgemäße Funktion erforderlich. Am Ausgang des zweiten Gatters befindet sich die /Ready-Leitung, die eine Open-Kollektor-Busleitung darstellt. Statt des DL003 ist auch eine kleine Transistorschaltung denkbar, wodurch sich der Hardwareaufwand jedoch nicht reduziert.

Zum Betrieb des Laufwerkes muß noch erwähnt werden, daß das Laufwerk z.B. mit MSYSG.COM in der PC-Betriebsart installiert werden muß. Dabei ist es wie ein 5,25"-Laufwerk (Typ 1.6) zu behandeln und auf 780K einzustellen. Mit der angegebenen Beschal-tung kann man zwar nicht vom kleinen Laufwerk booten, ein Umschalter, der die beiden Signale /DS0 und /DS2 tauscht, könnte dies jedoch hardwaremäßig ermöglichen. Aus diesem Grund habe ich die Systemspuren vorgesehen und nicht das 800K-Format benutzt.

Wer unter CAOS die von mir geschriebene Version von DEP V2.2 (DEP22.COM) benutzt, kann ohne Modifikation das Laufwerk mit H: als 780K-Laufwerk ansprechen. Die Belegung aller Laufwerke ist u.a. in der Beschreibung DEP22.TXW enthalten.

Festplatte am KC

von Uwe Felgentreu

Nun möchte ich doch noch das "große Geheimnis" um den Festplattenanschluß lüften. Um es vorwegzunehmen, die Festplatte löst unsere Speicherprobleme nicht und ist auch nicht so schnell wie die RAM-Disk. Außerdem läuft sie nur unter MicroDOS und arbeitet nicht fehlerfrei, sodaß sie nur als 8MB große sRAM-Disk betrachtet werden kann.

Wer nun immer noch Interesse an der HD hat, der wird im folgenden den Hardwareanschluß und die Softwarelösung kennenlernen. Ich möchte hier kein Kochrezept zu besten geben, da potentielle Nachnutzer schon ein gewisses "KC-Feeling" haben sollten. Daher keine Bauanleitung im herkömmlichen Sinne, sondern ein historischer Abriß zu Entstehung der Lösung. Vieleicht können hier andere KC-Freaks meine Fehler erkennen und eine saubere Lösung finden.

Am Anfang stand eine Mülltonne beim Robotronvertrieb in Erfurt mit Rechnerschrott aus DDR-Zeiten. Die EC1834-HD-Controllerkarte war schnell gefunden und eine Tüte Kaffee brachte mir auch den Schaltplan und eine passende 20-MB-Platte vom EC 1834 ein. Eine Sromversorgung mit einem Robotronschaltnetzteil war auch schnell gefunden. Im übrigen passt die Karte gut in das C64- Spielkonsolengehäuse. (Auch eine Art, die Konkurenz zu bewältigen...)

Für die Statistiker unter uns hier die Stromaufnahmen :

Platte: 5V/5A, 12/2A (4A Anlauf)
Karte: 5V/2A!!, 12V/0,3A, -5V/0,05A

Nun lief die Platte und wollte angesteuert werden. Der EC1834 ist so ein altes Teil, daß man hier mit 8 Bit auf die I/O-Gruppen losgeht. Optimal für den KC...

Wir verwenden für die Ansteuerung erstmal das Grundgerät. Warum sage ich später! Ein M007-Usermodul mit maximal 10 cm Flachbandkabel zum HDD macht sich ganz gut. Also die 8 Datenleitungen können wir hart auf den KC-Bus legen. /RD geht an /IORD des HDD und /WR des KC geht an /IOWR des HDD. Die PIN's sucht sich bitte jeder selbst im Systemhandbuch des 1834 raus. Die Adresslogik auf des Karte wird die Adressen 320H-32FH selektieren. Also belegen wir einen Block von 16 I/O-Adressen im KC. Ich habe 50H-5FH genommen. Mit Sicherheit schreien jetzt wieder 99.9% aller User auf, weil private Hardware dort angesiedelt ist, aber bei mir war dort eben noch Platz.

Wie schalten wir die Adressleitungen nun durch ?

EC1834             KC85
  A0   x  ; 0..F    A0   ; 0..F
  A1   x            A1
  A2   x            A2
  A3   x            A3
  A4   0  ; 2       A5   ; 5
  A5   1            A4
  A6   0            A7
  A7   0            /IORQ
  A8   1  ; 3       A6
  A9   1            MEI
 A10   0            GND
 A11   0            GND

Diese einfache Anschaltung geht aber nur, weil wir keinen Speicherzugriff auf die Karte brauchen. Wer in BASIC mit

PRINT INP(85)

den Konfigurationsschalter der Karte einlesen kann, darf sich entspannt zurücklehnen und das Ergebnis bestaunen. Nun benötigen wir ein BIOS zur Ansteuerung. Ich habe es HIOS genannt (Harddisk_In_Out_System). Diese Software kann die Platte rücksetzen, einen Sektor von der Platte in den RAM lesen, einen Sektor aus dem RAM auf die Platte schreiben und einen Sektor suchen. Ein Sektor ist hier 512 Byte groß! Im übrigen wird die Platte bei einem guten Freund im MS-DOS-Rechner mit AMI-BIOS unter Nutzung des Typ 2 formatiert. (Low-Level, Fdisk und dann Format C:).

Nun brauchen wir noch das HDOS, das Hard_Disk_Operating_System. Damit können wir dann einen 128 Byte großen Sektor bearbeiten können. Gleichzeitig können wir 2 logische Platten anlegen. Eine 8 MByte-Platte und eine 2 Mbyte-Platte. Damit kann eine billige 10-MB-MFM-Platte voll ausgereizt werden. Nun läuft die Hardware und die Software ist prinzipiell auch nutzbar.

Warum der Anschluß der Platte im Grundgerät? Nur in der MicroDOS-Betriebsart ist ein vernünftiges Filesystem vorhanden. Die Platte ist unter CAOS nur schwer zu verwalten und nicht mehr überschaubar. Man stelle sich nur mal den DIR-Befehl unter CAOS vor... Grundgedanke ist, den RAM-Disktreiber zu modifizieren und im Grundgerät eine "Weiche" einzubauen. Voraussetzung ist aber ein neuer D004-Eprom, damit der Befehl JUMP F8 funktioniert. Der Umbautip dazu am Ende des Beitrags. Wir booten also mir JUMP F8. Damit sind alle notwendigen HD-Treiber im Grundgerät und die HD ist initialisiert. Auch die RAM-Weiche ist aktiv.

Was tut die RAM-Disk-Weiche eigentlich ?

MicroDOS übergibt im Koppelram das Kommandobyte für die RAM-Disk. 04H bedeutet Sektor schreiben,06H heißt Sektor lesen. Mit 00H meldet das Grundgerät fertig bzw. mit FFH Error! Ich nutze die oberen 4 Bit diese Bytes zur Geräteauswahl. 0xH ist die RAM-Disk, 1xH die logische HD 0 und 2xH ist die logische HD1. Die Weiche im Grundgerät wird im RAM-Disktreiber eingebaut. Nachdem die Parameter und das Kommando gelesen sind springt der KC die Weiche an, welche diese 4 Bits testet und bei 0xH zur RAM-Disk zurückspringt. Andernfalls wird der Sektor vom HDOS bearbeitet und als RAM-Disk-Operation für den KC beendet. Nicht mehr und nicht weniger läuft im KC ab.

Im D004 habe ich dank der MicroDOS-Quelltexte im BIOS einen Festplattentreiber eingebaut. Dazu müssen wir erst einmal Platz schaffen. Die Uhr braucht ohnehin keiner (oder ?). Damit habe ich genügend Platz für den Diskettenbelegungsvektor. Dieser üble Speicherfresser begrenzt unsere Festplattengröße. Je Block benötigen wir ein Bit zur Kennzeichnung der Belegung. Ein Schritt zur Lösung ist die Nutzung von 8k-Blöcken auf der HD. Damit kann ich mit 128 Byte=1024 Bit genau 8 MB-Plattenvolumen verwalten. Die kleine Platte wird mit 16 Byte=128 Bit und 2k-Blöcken genau 2 MB groß.

Hier ein Tip für MicroDOS-Insider. Die Adresse des Treibers ist vor dem DPB zu finden. Der Diskettentreiber im BIOS liegt ab 0F1A0H während der RAM-Disk-Treiber ab 0F150H zu finden ist. Wer sich also schon mal über die Bytefolge A0 F1 bzw. 50 F1 vor den DPB's gewundert hat, weiß nun wozu diese da sind. Wer einen eigenen Treiber schreiben will, muß nun dort seine Treiberadresse eintragen und sich die Parameterübergabe bei der RAM-Disk abgucken...

Hier noch ein paar allgemeine Worte

Wie schon gesagt, die Quellen gibts bei mir (alle !). Ich hoffe, daß ich damit ein Zeichen setze, und die Geheimniskrämerei unter den Programmierern aufhört. Mein Problem ist die starke berufliche Belastung. Bei mir liegen Quelltexte, Wissen und Programme brach, die unseren KC-Klub ein ganzes Stück weiterbringen könnten. Wenn sich andere Programmierer noch mal an meine Programme setzen, wird evtl. doch noch was Gutes draus...

Spätestens hier stellt sich die Frage nach der KC-news-Mailbox. Wir können die Quelltexte nicht immer per Post schicken. Das dauert zu lange und ist zu umständlich (zumindest mir). Auch sollten wir eine Rubrik schaffen, in der über die weitere Entwicklung des KC laut nachgedacht wird. Denn Assembler, TurboPascal und C kann inzwischen fast jeder programmieren. Aber es macht keinen Sinn, wenn jeder wild drauflos programmiert und das Rad zum 5. Mal neu erfunden wird. In diesem Sinne sollten wir unsere Erfahrungen in Form von Quelltexten, Bibliotheken und interessanten Systemeigenschaften allen zugänglich machen.

In diesem Zusammenhang stellt sich auch die Frage, ob das Sharewareprinzip auf dem KC übertragbar ist. Ich persönlich habe damit so meine Probleme. Der KC ist mein (Oldtimer-)Hobby, für das ich von anderen Fans kein Geld will. Betriebsausgaben für den Klub sind dabei selbstverständlich.

So, nun habe ich genug "geredet" und warte auf eure Reaktion. Zerreißt mich aber bitte nicht gleich in der Luft für meine evtl. strategischen Fehlentscheidungen und das laute Nachdenken.

JUMP F8, die Alternative!

Wer hat sich nicht schon über den leeren ROM FC geärgert? Da sind noch gut 3 KByte frei, aber unser KC kann weder von ROM Booten, noch beherrscht er IBM-Blockgrafik oder Inversschrift. Ich möchte aber JUMP FC, also mein altes System behalten, denn Nobody is perfect - und meine Software sowieso nicht. Also kann ich bei eigenartigen Systemverhalten unter MicroDOS immer noch Original-Booten und damit eigene Fehler ausschließen.

Die "geniale" Idee besteht in der Ausnutzung des freien Datenbits im D004. Der einzige DL175 hat noch ein Latch frei. Legen wir das richtige Datenbuspin vom Grundgerät an den Latcheingang, so wird der Ausgang bei JUMP FC auf L und bei JUMP F8 auf H liegen. Da der Boot-Eprom nun das /CS fest auf GND gelegt hat, kann man diesen PROM über das Latch schalten.

Mein Alternativ-PROM wird in eine Fassung gesteckt, die huckepack auf den Boot-PROM gelötet ist. Nur /CS der Fassung geht diesmal auf den invertierten Ausgang des Latches,während /CS des Original-PROM's auf den nichtinvertierenden Ausgang geht. Nun kann eigene Software geschrieben werden, die alle möglichen Treiber bei JUMP F8 mit lädt.

Ich habe IBM-Grafik, die Festplattetreiber, den Maustreiber, meinen eigenen Tastaturtreiber für Komforttastaturen, einen Treiber für COM1-COM4 statt Kanal 1 und Kanal 2 und den Treiber für 256k RAM on Board eingebunden. Ich könnte mir vorstellen, daß H. Haftmann's Mauspfeil hier als Treiber noch hingehört. (Henrik,kann ich den Quelltext haben ?)

Hier aber nun ein wichtiges Wort an alle Programmierer.

Der RAM auf der Adresse 400H-1100H ist TABU!!! Wer hier mit Programmen wie ZAS.COM herumpatcht bewegt sich mit Lichtgeschwindigkeit auf einen inkompatiblen KC85 zu.

Warum das ?

Viele Programmierer haben den Treibercode reassembliert und nutzen mit den Escapesequenzen diese Unterprogramme unter MicroDOS. (Vollständige M80-Quellen für den original-ROM FC und den von mir eingesetzten ROM F8 gibt es kostenlos bei mir.) So vertragen sich meine WINDOW's-Bibliothek für TurboPascal und das ZAS nicht. Ich brauche für schnelle Bytetransporte vom und zum Grundgerät eine bestimmte Escapefunktion.

Zum Umpolen der Transportrichtung poke ich ein Byte in des Grundgerät und mache aus dem Code OTIR den Code INIR und umgekehrt. Ich stelle aber sofort nach Nutzung wieder den Originalzustand her! Hat nun jemand in der "Zentralen Abfrageschleife" herumgehackt, so schmiert der KC klanglos ab...

Es geht besser ! Meine RAM-Weiche für die Festplatte zeigt das. Ich entferne 3 Bytes im Code durch einen Sprung in den (noch) freien Speicher und baue dort meine Zusatzroutinen ein. Dann hänge ich die 3 Bytes hinten dran und springe dorthin zurück, wo es weitergehen sollte. Die Wahrscheinlichkeit, das dann jemand genau diese Bytes umpoken will ist doch wesentlich geringer - oder?!

Im übrigen will ich hier nicht an ZAS.COM herumnörgeln. Diese Programm ist ein Spitzen-Tool und nur besonders agressiv zu meinen Programmen.

Hier wieder meine abschließenden Bemerkungen (ohne geht's bei mir offensichtlich nicht...) Ich biete alle Quelltexte an und erwarte eigentlich auch gleiches von den Programmierern des neuen CAOS und von ZAS. Dann können wir schnellstens!!! eine saubere Lösung finden. Auch sollten die neuen SOFTWAREAUTOREN des KC-Klubs unbedingt den Speicherplatz im Grundgerät unter MicroDOS aufteilen. Ich nutze für die Festplattentreiber z.B. 2000H-25FFH. Wer hier in der Laufzeit irgendwelche Daten hinpokt, zerschießt mir meinen Festplattentreiber! Ich kann natürlich auch andere Bereiche nutzen, nur wissen muß ich es ...

 

Anmerkungen der Redaktion:

Der oben geschilderte Anschluß einer Festplatte ist für die wenigsten nachvollziehbar. Zum Glück bahnt sich schon eine (fast komplette) Lösung an.

Da wir aus Mühlhausen die Quelltexte zum MicroDOS bekommen werden, sind zukünftige Einbindungen noch einfacher zu bewerkstelligen. Hierzu wird dann aber eine Abstimmung unter den Programmierern unumgänglich sein. Der Konflikt von ZAS und Uwes WINDOW-Treibern wäre sonst nur der Auftakt einer langen Reihe von Inkompatibilitäten. Die überaus große Akzeptanz von CAOS 4.3 und ZAS scheint hier richtungsweisend zu sein. Ähnlicher Erfolg dürfte auch dem ROM-F8 ins Haus stehen. (Ich wage einfach mal diese Prognose!)

Um auch in Zukunft nicht die Meldung "Allgemeine Schutzverletzung in Modul xx" am Bildschirm zu erhalten, bitte ich alle Programmautoren, sich untereinander zu verständigen, neue Standards festzulegen und diese dann der Allgemeinheit mitzuteilen! (Windows-Usern dürfte diese Meldung bekannt sein und auch das Gefühl, wenn man wieder mal die Reset-Taste betätigen darf!)

Generic IDE-Interface

von Tilmann Reh
(Texterfassung und -ergänzung: Jörg Linder)

Viele User von CP/M-Systemen wünschen sich (fast) nichts sehnlicher als eine Festplatte. Leider muß man das eigene System sehr gut kennen, um einen derartigen Anschluß herzustellen. Uwe Felgentreu nutzt für seine Lösung einige sehr spezielle Eigenschaften des KCs aus. Das macht sie allerdings inkompatibel zu anderen Systemen.

Tilmann suchte nach einer Lösung, die für (nahezu) jeden CP/M-Rechner nachvollziehbar ist. Er hat sie gefunden und in Form des GIDE verwirklicht. Ein paar Prototypen laufen bereits erfolgreich. Einer Mini-Serienproduktion stand bisher nur das fehlende Interesse im Wege. Doch inzwischen haben genügend Leute Ihr Interesse bekundet, so daß demnächst die Leiterplatten gefertigt werden.

Das Interface ist auf einer ca. 60 x 75 mm großen Platine, die direkt in den Z80-Sockel gesteckt wird und ihrerseits den Prozessor trägt. Falls dies nicht machbar ist, kann die Verbindung zum originalen Z80-Sockel auch per (möglichst kurzem!) Flachbandkabel realisiert werden. Nach der jüngsten Design-Änderung kann optional noch eine Echtzeituhr (RTC) auf der Platine untergebracht werden (Batteriepufferung optional, extern).

Besorgte Leser werden sich jetzt fragen: "Welcher CPU-Sockel? Im D004 ist kein Sockel für die U880!" Da ein Z80-Prozessor heutzutage nur noch ein Pfennig-Artikel ist, kann man ja die Pins abschneiden und darauf einen Sockel löten. Das ist auf alle Fälle günstiger als eine Platine, die der mangelnden Löterfahrung zum Opfer fällt!

Versorgt wird das Interface über den CPU-Sockel (ca. 100 mA). Es belegt 11 I/O-Adressen (die Basisadresse ist in 16er Schritten mit 4 Jumpern einstellbar), und dürfte bis 6 MHz problemlos laufen (vielleicht auch darüber). Unsere D004-Basis ist mit 4 MHz getaktet und bereitet dem GIDE also keine Probleme.

Die Einbindung ins System geschieht optimal durch eine entsprechende BIOS-Änderung, wie z.B. bei der CPU280. Bei Systemen, für die diese Möglichkeit (mangels Quellcode) nicht besteht, soll ein residenter Treiber geschrieben werden, der sich selbst reloziert und in die BIOS-Sprungleiste einklinkt (was ohne größeren Aufwand nur unter CP/M 2.2 gehen wird). Weitere Vorschläge und Angebote zur Unterstützung werden jederzeit gerne angenommen.

Da in Kürze der Quelltext des MicroDOS vorliegen wird, stellt die Einbindung in das BIOS kaum noch eine Hürde dar. Von Tilmann werden alle (gut dokumentierten) Quelltexte geliefert, so daß dann nur noch unsere Software-Spezialisten gefordert sind.

Sicherlich auch interessant sind die Kosten für das Ding. Nach der aktuellen Kalkulation (50 Platinen) muß ich folgendes berechnen:

Leerplatine	29 DM
Leerplatine mit GAL's	43 DM
Komplettbausatz ohne RTC	69 DM
Komplettbausatz mit RTC	84 DM
Fertiggerät ohne RTC	84 DM
Fertiggerät mit RTC	99 DM

Anmerkung: RTC = engl.: Real Time Clock = Echtzeituhr
(Bei Bausatz und Fertiggerät sind dabei alle IC's mit gedrehten Präzisionssockeln versehen.)

Wer Interesse an dem GIDE-Interface hat, meldet sich bitte bei mir (Jörg Linder)! Sobald eine Anpassung für das KC-System vorliegt und entsprechende Tests abgeschlossen sind, wird auf alle Fälle hier in den KC-News davon zu lesen sein!

Kontakt: Jörg Linder

Userbereiche - der Weg zu übersichtlichen Datenträgern

von Uwe Felgentreu

Wohl jeder User hat schon den Begriff Userbereich bzw. den MicroDOS-Befehl 'U' gehört. Ausprobiert haben diesen Befehl nur wenige und regelmäßig nutzen wird ihn niemand. Das liegt daran, daß diese Userbereiche zwar eine gewisse Ordnung in das Durcheinander auf dem Datenträger bringen, aber man weder die Daten wiederfindet, noch vernünftige Statusmeldungen über alle Userbereiche bekommt.

So muß ich jedes Mal auf der kc-news-Diskette suchen, in welchem Userbereich das gewünschte Thema ist. (Das war früher mal, ist aber jetzt nicht mehr aktuell. - Anm. d. Red.) Unter MS-DOS hat man die Pfade und SUB-Directories erfunden. Hier stelle ich eine Mischung aus Userbereich und Pfaden vor. Den Userbereichen werden nun Inhaltsbezogene Namen verpaßt, womit es dem Nutzer möglich wird, die Daten schneller wiederzufinden. Das vorgestellte Programmpaket realisiert nicht mehr und nicht weniger !

Zur Arbeit werden folgende Programme benötigt:

CD.COM

zum Wechsel zwischen den Usernamen

 

MD.COM

um die Usernamen zu Erzeugen

 

RD.COM

zum Löschen eines Usernamens

 

TREE.COM

um die Baumstruktur aller Usernamen anzuzeigen

 

FREE.COM

um die Diskettenbelegung anzuzeigen

Alle Programme sind in C geschrieben und als Quelltext verfügbar. Ich gebe ab sofort alle Quelltexte bedingungslos ab, um auf diesem Wege das beträchtliche Know-How, daß sich bei mir angesammelt hat , allen KC-Usern zugänglich zu machen. Ich hoffe, auf diesem Wege den KC noch einmal etwas Leben einzuhauchen.

Die Programme des Programmpaketes nutzen als Datenbasis die Datei USERLIST.DAT. Dort sind alle Informationen zur Baumstruktur und die Usernamen gespeichert. CD und TREE lesen die Datei nur. MD und RD schreiben auch in die Datei. Also muß zum Verändern der Baumstruktur der Datenträger im Zustand R/W sein !

Die Programme müssen Systemdateien sein. Ich empfehle eine Unterbringung auf LW A: (ROM-Disk) und Systemlaufwerk A: !!! Damit sind alle Programme wie Systembefehle anwendbar. Natürlich kann man auch auf jeder Diskette im Userbereich 0 diese Programme unterbringen, ist aber die totale Platzverschwendung.

FORMAT - Komfort

von Uwe Felgentreu

Hier möchte ich die Ablösung für unser reichlich veraltetes FORMAT.COM vorstellen. Ich habe versucht, die Parameter der MS-DOS-Version zu übernehmen. Mit KCFORMAT ? erhält man eine Hilfe zu den Kommandos. Bei Fehleingaben wird der fehlerhafte Parameter nochmals ausgegeben und das Programm beendet. Folgende Parameter stehen zur Verfügung :

KCFORMAT [drive:] [?] [/s[:name[.typ]]] [/u] [/v]

ohne Parameter grafische Oberfläche!
/u ohne Abfrage vor dem Formatieren (für Stapelverarbeitungen!)
/v Anzeige der Spur und des Kopfes (sonst in Prozent wie bei MS-DOS)
/s Standardsystem MICRODOS.SYS schreiben
/s:NEWDOS Systemdatei NEWDOS.SYS schreiben
/s:NEWDOS.COM Systemdatei NEWDOS.COM schreiben
? Hilfe

Fehleingaben werden weitestgehend abgefangen und erzeugen Warnungen bzw. Programmstop. Systemfehler wie nicht bereite Floppylaufwerke oder BIOS-/BDOS-Fehler werden nicht behandelt und führen zur berüchtigten Bildschirmmeldung.

Die Systemdatei muß auf dem Laufwerk vorliegen, von dem aus KCFORMAT gestartet wurde. Sollte also LW C: aktiv sein und mit A:>KCFORMAT E: /s das Laufwerk E mit System formatiert werden, so muß entweder die Datei MICRODOS.SYS auf Laufwerk C vorliegen oder der Aufruf mit A:>KCFORMAT E: /s:A:MICRODOS.SYS erfolgen. Die Datei MicroDOS.SYS erzeugt sich bitte jeder selbst mit POWER.COM!

POWER READ 0 1 4000 160
POWER SAVE MICRODOS.SYS 4000 160

Die grafische Oberfläche beim Aufruf ohne Parameter bietet mehr Möglichkeiten. Man kann das Programm mit der Maus bedienen, wenn die Maus den Cursor und die Entertaste ansteuert. Befindet sich der Cursor gerade auf einem Datenfeld, so kann diese Funktion mit der Entertaste aktiviert werden. Neu sind die Felder START, ENDE, KOPF0 und KOPF1. Damit ist erstmals selektives Formatieren möglich.

Ist also nur die Systemspur beschädigt, so kann man mit START=0 und ENDE=1 die Systemspuren formatieren und bei Bedarf gleich ein System aufspielen. Die "Fortschrittsanzeige" mit Balken gibt Auskunft über den Zustand der Diskette. Defekte Spuren werden mit F gekennzeichnet. Ist die Spur o.k., erscheint ein O!

Das Programm geht in der Kommandozeile ohne weitere Parameter von einer Formatierung mit Abfrage, Prozentanzeige und ohne System mit 780K aus. Also KCFORMAT B: wird fast immer ausreichend sein. Wenn es noch jemanden mit nur einem Laufwerk gibt, so kann der die Abfrage "Formatieren J/N : " zum Diskettenwechsel nutzen. Mehr ist zu diesem einfachen PD-Programm dann nicht zu sagen. Ich wünsche viel Spaß bei der Arbeit damit und bin für Kritik daran jederzeit offen.

WordPro 9 - Textsystem für den KC 85/3

Programm & Text von Wolfram Schütze
(bearbeitet von: Jörg Linder)

Anmerkung des Bearbeiters:

Wolfram Schütze hat WordPro '89 für den KC 85/3 weiterentwickelt. Wie er selbst sagt, war er bei der Vergabe neuer Versionsnummern etwas großzügig. WordPro 9 ist also nicht mit WordPro 5 oder 6 von Mario Leubner zu verwechseln.

Einleitung

WordPro 9 ist eine Weiterentwicklung des Textsystems WordPro '86. Es ist nur für den KC 85/3 geeignet. Eine Besonderheit ist die Nutzung des BASIC-Adreßbereiches C000H..DFFFH. Dazu, und gleichzeitig zur Realisierung des relativ großen Textspeichers von 383 Zeilen, ist ein Modul M011 erforderlich, der sich auf Steckplatz 08, 0C, F0 oder F4 befinden kann.

Das System wurde ausgebaut und verbessert. Neben den Kassettenfunktionen wurde der Diskettenbetrieb voll integriert. Es wurde versucht, sowohl das M003 - V.24 als auch M001 - Centronics als Druckerschnittstelle zu bedienen.

Nachfolgend wird eine gekürzte Fassung des Informationstextes wiedergegeben. Die prinzipiellen Eigenschaften von WordPro werden als bekannt vorausgesetzt. Weitere Einzelheiten sind den Dateien WP/INF.TXW.. WP/INF4.TXW (in WORDPRO9.PMA) zu entnehmen.

Statuszeile

Es wurde versucht, möglichst Vieles anschaulich und platzsparend mit Symbolen darzustellen. Von links nach rechts:

• Bankanzeige
  1 oder 2 (Erklärung s. unten)
• Tastatur
  Links vom Symbol erscheint bei aktiviertem SHIFTLOCK ein Zeichen; rechts wird die gewählte 1. oder 2. Tastaturblelegung angezeigt.
• Grafikzeichen Ein/Aus
  Bei "Ein" (= volles Symbol) wird zu den Zeichencodes 30H..5FH (Ziffern, einige Sonderzeichen, Großbuchstaben) 80H addiert und dadurch auf dem Bildschirm die Grafikzeichen des erweiterten EPSON-Zeichensatzes dargestellt. Diese erscheinen dann auch beim Ausdrucken, falls der Drucker über diesen Zeichensatz verfügt.
• Cursor-Spaltenzähler
  Die Spalten sind von 1 bis 80 numeriert (analog Drucker).
• Cursor-Zeilenzähler
  Die Zeilen sind von 0 bis 382 numeriert.
• Freie Zeilen
  Angabe der noch freien Zeilen, gezählt ab der Zeile unterhalb des Cursors.
• Eingestellte linke und rechte Randmarkierung
• Automatischer Wortumbruch, Seitenschaltung, Tastenclick E/A
  Symbolbedeutung wie bei Grafikzeichen. Der Flatterrandausgleich (Jus) wurde weggelassen. Das leistet der Drucker besser!

Geänderte und neue Funktionen

• Bankumschaltung
  Der Textspeicher ist von Zeile 177 bis 382 doppelt vorhanden. Beide Bereiche sind wechselweise nutzbar und getrennt löschbar.
• Blättern mit 29 Zeilen
  Nach dem Vorwärtsblättern ist die letzte Zeile der vorherigen Seite unterhalb der Statuszeile wieder sichtbar. Das erleichtert nahtloses Weiterschreiben.
• Vorwärtsschieben ("Teilblättern")
  Nützlich, wenn ein Teil der vorherigen Seite noch sichtbar bleiben soll.
• Geändertes Verhalten beim "Zeile einfügen" und "Zeile tilgen"
• Cursorpositionen HOME und Anti-HOME
  Wann braucht man den Cursor ganz oben links bzw. ganz unten rechts? Nie, also anders.
• Cursorsprung zum Initialwert der linken Randmarke
• Löschen des linken Zeilenteils, der Rest rückt nach vorn
• Löschen des rechten Zeilenteils
• Wort suchen
  Das vorgegebene Wort wird in Richtung Textende gesucht. Die Zeile mit dem gefundenen Word wird dann zur ersten Zeile auf dem Bildschirm.
• Wörter speichern
  Es lassen sich acht häufig gebrauchte Wörter (oder kurze Sätze) speichern und mit ihrer Nummer wieder abrufen. Der Speicher ist 200 Bytes lang und dynamisch organisiert.

Druckersteuerzeichen

Bei der Steuerzeichenauswahl und -definition wurde ein 24-Nadel-Drucker mit dem Betriebssystem ESC/P2 vorausgesetzt. Beliebige weitere Steuerzeichen lassen sich über "Beliebige Sequenz" mit nachfolgenden Hexzahlen realisieren. Eine entsprechende Funktion befindet sich auch im I/O-Menü ("Codes"). Sie dient der unmittelbaren Übermittlung (also ohne "Umweg" über die Textdatei) von Steuercodes an den Drucker.

Desweiteren gibt es spezielle "computerinterne" Steuerzeichen, mit den programminterne Funktionen aktiviert werden können.

In/Out-Menü

Das I/O-Menü ist auf 13 Symbole erweitert, die sich z. T. selbst erklären bzw. an anderer Stelle schon erwähnt sind.

SAVE, LOAD, VERIFY für Kassettenbetrieb

Diese Funktionen sind sowohl in normaler Geschwindigkeit als auch mit einem schnelleren Verfahren ausführbar. Mit S (schnell) erreicht man ein anderes Verfahren, das mit etwa zweieinhalbfacher Geschwindigkeit arbeitet, aber zusätzliche Hardware an zwei freien Anschlüssen der KC-internen PIO erfordert.

 

SAVE, LOAD, DIR für Diskettenbetrieb

SAVE und LOAD bieten bei "NAME" den zuletzt verwendeten Dateinamen wieder an, der beliebig überschrieben werde kann. Ein Dateityp ist nicht anzugeben; es wird automatisch ".TXW" angefügt. (Unter TXW-Dateien werde dabei die klassischen WordPro-Dateien verstanden, d. h. "linearer" Speicherabzug, kein Endezeichen, mit Vorblock.) Ladbar sind aber auch WordPro-fremde Dateien, und zwar solche, die 0DH und 0AH als Zeilenendezeichen und 1AH oder 03H als Dateiendezeichen enthalten und keinen Vorblock haben. Damti sind z. B. Dateien von TPKC und REDABAS (1AH) und BASIC PRINT#1 (03H) mit WordPro 9 bearbeitbar. In diesen Fällen muß der Dateityp mit angegeben werden.

 

Drucken

Es läßt sich eine Blatt- bzw. Seitennummer eingeben, deren Position als Mitte zwischen linker und rechter Bildschirm-Randmarke errechnet wird. Zwischen der Nummer und dem Text wird automatisch eine Leerzeile eingefügt.

Die Druckerschnittstelle ist universell gestaltet. Es ist sowohl V.24 über Modul M003 als auch Centronics über Modul M001 oder Centronics über Eigenbau-Modul möglich. Beim Start werden die Steckplätze 08, 0C, F0 und F4 abgefragt. Der zuerst gefundene Modul wird aktiv geschaltet, die passende Initialisierungsroutine durchlaufen und die passende Ausgaberoutine in eine Sprungzelle "eingeknöpft".

KC-Bildformate intern

von Ralf Kästner

Wie zum KC-Treffen gewünscht, soll im folgenden Artikel der Aufbau der PI_- und HI_-Bildformate beschrieben werden. Zunächst ein paar Worte zur Geschichte, ich beschäftige mich seit über 5 Jahren mit der Grafikprogrammierung auf dem KC. Angefangen hat alles mit "EDIPIC32" für den KC 85/2 und 3, welches 1989/90 auf einem "dienstlichen" KC 85/3 mit Kassette programmiert wurde und im August `90 fertig war. Seit August 1989 stand dann privat ein KC 85/4 zur Verfügung.

Durch die unterschiedliche IRM-Adressierung des Nachfolgemodells traten die bekannten Probleme auf, als es darum ging Grafiken auszutauschen. Der damalige Zustand war alles andere als zufriedenstellend, mit zur Verfügung stehenden Programmen, wie GRAFIK (KC 85/3) oder LEONARDO konnte man zwar mal eine einfache Zeichnung machen aber so richtig zu gebrauchen waren wohl alle nicht, schon gar nicht, wenn es um Bildtransfer zwischen /3 und /4 ging.

Unverständlicherweise wurde "ArtStudio" für den /4 von Mühlhausen "geheimgehalten", ich bekam es auch erst Anfang 1992 zu Gesicht, dort war das Transferproblem zwischen den beiden Typen aber auch nicht gelöst.

Ich habe mir damals Gedanken gemacht, wie man die ganze Misere etwas entschärfen könnte und vor allem, wie bringe ich die Zeichnungen von dem einen auf den anderen Rechner. Eines war klar, es mußte eine Formatdefinition her, welche auf die Hardware der KC`s zugeschnitten und für beide Typen gleichermaßen einlesbar ist, eine Begrenzung auf 256*256 Bildpunkte, wie in LEONARDO, sollte auch nicht erfolgen.

So entwickelte ich das Konzept mit den PIC/PIP/PIF-Dateien, welches ein wenig Ordnung und System in die Grafikwelt auf dem KC bringen sollte. Mit der Fertigstellung von "EDIPIC40" für den KC 85/4 im September 1991 standen dann zwei Programme zur Verfügung, welche einen Austausch von bildschirmgroßen Grafiken zwischen KC 85/2,3 und KC 85/4 ermöglichten, ohne daß sich der User Gedanken machen muß.

Man kann also die PIC-Dateien des KC 85/2,3 in den KC 85/4 und die PIP/PIF-Dateien des KC 85/4 in den KC 85/2,3 einlesen! Die jeweils laufende "EDIPIC"-Version speichert ein Bild im rechnerspezifischen Format, beim Einlesen erkennt das Programm anhand der Formatdefinition Bilder vom anderen Rechner und konvertiert sie automatisch in die richtige Form.

Inzwischen haben wir 1995, ich hätte damals auch nicht gedacht, daß mich die Grafik auf dem KC bis heute "verfolgt". Die Entwicklung ist weitergegangen, nach "EDIPIC41" 1992 folgte 1993 "DIASHOW", zum Treffen konnte man das neue "UNIPIC" aus 1994 begutachten, der KC 85/2,3 spielt nur noch eine Nebenrolle, da fast alle mit dem KC 85/4 und Diskette arbeiten.

Die überwiegende Zustimmung zu den genannten Programmen hat das damalige Dateikonzept eigentlich bestätigt, die Formatdefinition ist immer noch die gleiche von 1990. Für die Hires-Grafik des KC 85/4 habe ich mit "DIASHOW" 1993 den HIP/HIF-Typ eingeführt, so kann man die Farbauflösung schon aus der Dateierweiterung erkennen, was Mißverständnisse ausschließt.

Mittlerweile sind damit PIP/PIF- und HIP/HIF-Definition fast zum Quasi-Standard für den KC geworden und werden von anderen Programmierern angenommen und unterstützt, z. B. "WordPro 6" von Herrn Leubner oder "4PCX090" von Herrn Jödicke. Ich bin auch gern bereit zusätzlich zum heutigen Artikel weitere Quelltexte zur Verfügung zu stellen, man muß ja nicht jedesmal das Fahrrad neu erfinden.

Ich vertrete die Meinung, uns nützen viele verschiedene Formate für KC-Bilder gar nichts, wenn sich alle an ein Format halten, fällt die Arbeit auf dem KC leichter und die Programmierer haben es auch einfacher, insbesondere betrifft dies auch Grafik, welche unter MikroDOS entsteht, da dort der CAOS-Vorblock nicht zwingend erforderlich ist!

Die notwendigen Hintergrundinformationen sollen mit dem heutigen Artikel geliefert werden. Auf den KC 85/2,3 möchte ich nicht so genau eingehen, da er wohl nur noch eine untergeordnete Rolle spielt, "EDIPIC32" ist ja leider auch nur kassettenfähig, man kann aber alle PI_-Bilder mit einem normalen Kopierprogramm von/auf Diskette spielen und so auch auf diesem Wege weitergeben bzw. nutzen. Wird von Diskette auf Kassette kopiert, ist ein gesetzter Schreibschutz vorher zu entfernen!!!

Allgemeines

Jede Bilddatei enthält immer einen kompletten Bildinhalt des KC von 320*256 Bildpunkten. Der Dateiaufbau entspricht CAOS-Maschinenprogrammen, es ist also immer der 128 Byte umfassende Vorblock zu erzeugen, auch wenn von MikroDOS aus Grafiken gespeichert werden! Im Vorblock müssen die folgenden Bytes unbedingt enthalten sein (Zählung ab 0!):

0...15	beliebig
16	Anzahl der Parameter (2 oder 3 bei Selbststart)
17...18	Anfangsadresse LOW/HIGH
19...20	Endadresse+1 LOW/HIGH
21...22	Startadresse LOW/HIGH (bei Bedarf)
23...127	beliebig

Man bleibt so kompatibel zu den Kassettendateien, was für einen unkomplizierten Austausch einfach notwendig ist, bitte beachten, bei den Vorblockbytes der Kassettenaufzeichnung beginnen die Datenbytes erst ab dem 1. (bei Zählung von 0!) Byte, da im Byte 0 die Blocknummer auf Kassette gespeichert wird, im Systemhandbuch auf S.85 wird die Bytezählung allerdings bei 1 begonnen, so daß das Byte Nr.18 dort, dem Byte Nr.16 hier entspricht!

Eine Ausgabe von Bildern ohne CAOS-Vorblock halte ich auch heute noch für nicht sinnvoll, da die gesamte Grafik ohnehin im Grundgerät verwaltet wird und reine Grafikprogramme unter MikroDOS eher Raritäten sind. Sie wären wahrscheinlich durch den ESC-Flaschenhals des Koppel-RAM auch zu langsam und nur bei rechenintensiven Programmen sinnvoll, wo sich die 4 MHz auszahlen, Beispiel FRACTALE von Herrn Harder, die dort erzeugten PIP/PIF-Dateien sind aber mit der Formatdefinition nicht kompatibel, man kann diese Bilder beispielsweise über "WordPro 6" einlesen und als HIP/HIF-Bild von dort aus speichern.

Bei allen Formaten ist die Komprimierung durch einen beliebigen Algorithmus möglich, wobei folgende Punkte eingehalten werden müssen. Die komprimierte Datei darf nicht größer als die unkomprimierte Variante werden, das ist notwendig, damit nicht unnötig wertvoller Speicherplatz verschwendet wird, man muß also während der Komprimierung die entstehende Dateilänge überwachen und im Falle eines Überlaufes abbrechen und die Datei dann unkomprimiert speichern.

Die zugehörige Dekomprimierungsroutine muß in der komprimierten Datei am Anfang stehen (s.u.), auf 8000H entpacken und als Unterprogramm ausgeführt sein (Abschluß mit RET). Die Organisation der Bildbytes muß wie im IRM des Originalrechners erfolgen, also der Zusammenhang zwischen Pixel- bzw. Farbyteposition muß der Adressierung des KC 85/2,3 bzw. KC 85/4 entsprechen, in der Regel ist dies ja immer gegeben.

Lores-Grafiken

Als Lores-Grafik werden alle Bilder vom KC 85/3 bezeichnet und alle Bilder in der byteweisen Farbauflösung (1*8 Bildpunkte) des KC 85/4. Als Dateierweiterungen (Zeichen 9...11) sind vorgeschrieben:

PIC

IRM-Inhalt vom KC 85/2,3 mit oder ohne Farbbytes

 

PIP

IRM-Inhalt der Pixel-IRM-Ebene vom KC 85/4 (IRM-Ebene 0 bzw.2)

 

PIF

IRM-Inhalt der Color-IRM-Ebene vom KC 85/4 (IRM-Ebene 1 bzw.3)

Damit das ladende Programm erkennen kann, von welchem Rechner die Datei stammt, ob eine Komprimierung der Daten erfolgte und ob die Farbbytes beim KC 85/3 mit abgespeichert wurden, steht vor den eigentlichen Daten als erstes Byte ein Kennbyte in der Datei.

Danach folgt bei den unkomprimierten Dateien der Inhalt des IRM als Speicherabzug. Bei den komprimierten Dateien kommt nach dem Kennbyte die Dekomprimierungsroutine als Unterprogramm (s.u.), danach folgen die komprimierten grafischen Daten. Die Gesamtlänge einer komprimierten Datei darf nicht größer sein als ohne Komprimierung!

Die folgende Tabelle stellt den Zusammenhang zwischen Kennbyte und Dateiinhalt dar, die vierte Spalte enthält die jeweiligen Adressen, welche bei allen o.g. Programmen verwendet werden und welche dann auch so im Vorblock stehen.

Dateityp	Kennbyte	Dateiaufbau	Adressen
PIC	0	PIXEL- und COLOR-IRM des KC 85/2,3 unkomprimiert	3FFFH - 7200H
PIC	1	PIXEL-IRM des KC 85/2,3 unkomprimiert	3FFFH - 6800H
PIC	2	PIXEL- und COLOR-IRM des KC 85/2,3 komprimiert	3FFFH - 7200H
PIC	3	PIXEL-IRM des KC 85/2,3 komprimiert	3FFFH - 6800H
PIF	4	COLOR-IRM des KC 85/4 unkomprimiert	3FFFH - 6800H
PIP	5	PIXEL-IRM des KC 85/4 unkomprimiert	3FFFH - 6800H
PIF	6	COLOR-IRM des KC 85/4 komprimiert	3FFFH - 6800H
PIP	7	PIXEL-IRM des KC 85/4 komprimiert	3FFFH - 6800H

Alle Programme (bei "EDIPIC32" ähnlich) benutzen den Bereich von 03FFFH - 067FFH als Pufferbereich. Im Wesentlichen läuft das Speichern eines Bildes wie folgt ab, das Bild (die jeweilige Ebene beim /4) wird aus dem Bildspeicher in den IRM geladen, anschließend wird ein Komprimierungsversuch auf 4000H aufwärts durchgeführt.

Die Komprimierungsroutine gibt ein Fehlerkennbyte und im Register DE die Endadresse+1 der komprimierten Datei zurück, war alles in Ordnung, wird das Kennbyte auf 03FFFH eingetragen und die Datei gespeichert, kam eine Fehlermeldung, wird das Bild von 8000H auf 4000H mit einem LDIR-Befehl einfach umkopiert, das andere Kennbyte eingetragen und eine unkomprimierte Datei ausgegeben.

Beim Laden der Dateien läuft dies sinngemäß dann umgekehrt ab, also Laden der Datei auf 3FFFH, Kontrolle Kennbyte, wenn notwendig Dekomprimieren auf 8000H, wenn notwendig konvertieren von /3 nach /4 oder umgedreht und Retten der Datei in den Bildspeicher, bitte beachten, daß die PIC-Dateien bis 07200H reichen können!

Hires-Grafiken

Die Speicherung von HIRES-Grafiken in "DIASHOW" und "UNIPIC" wurde eingeführt, damit man aus der Dateierweiterung sofort auf den Dateiinhalt schließen kann und die Bilder nicht mit Lores-Grafik verwechselt werden können. Da diese Farbauflösung nur auf dem KC 85/4 existiert, wurde auf ein Kennbyte am Dateianfang verzichtet. Als Dateierweiterung ist vorgeschrieben:

HIP

IRM-Inhalt der Pixel-IRM-Ebene vom KC 85/4 im HIRES-Modus
(IRM-Ebene 0 bzw.2)

 

HIF

IRM-Inhalt der Color-IRM-Ebene vom KC 85/4 im HIRES-Modus
(IRM-Ebene 1 bzw.3)

Damit das ladende Programm erkennen kann, ob das Bild komprimiert wurde, ist eine komprimierte Datei selbststartend abgespeichert eine unkomprimierte nicht. Der Aufbau der Datei ist dann ähnlich wie oben, die unkomprimierten Dateien entsprechen dem Inhalt des IRM als Speicherabzug.

Bei den komprimierten Dateien kommt zuerst die Dekomprimierungsroutine als Unterprogramm (s.u.), danach folgen die komprimierten grafischen Daten. Die Gesamtlänge einer komprimierten Datei darf wieder nicht größer sein als ohne Komprimierung!

Nachfolgend die Tabelle:

Dateityp	Dateiaufbau	Adressen in "DIASHOW" / "UNIPIC"
		Anf.-adr.	End.-adr.+1	Startadr.
HIF	COLOR-IRM des KC 85/4 im HIRES-Modus unkomprimiert	4000H	6800H
HIP	PIXEL-IRM des KC 85/4 im HIRES-Modus unkomprimiert	4000H	6800H
HIF	COLOR-IRM des KC 85/4 im HIRES-Modus komprimiert	4000H	6800H	4000H
HIP	PIXEL-IRM des KC 85/4 im HIRES-Modus komprimiert	4000H	6800H	4000H

Das Dateihandling beim Speichern in den Programmen läuft wie in der Lores-Variante ab, wobei eine komprimierte Datei dann als selbststartendes File ausgegeben wird. Dies ist besonders beim Laden zu beachten, "UNIPIC" verwendet dort eine zugeschnittene Laderoutine. Darin wird das 16. Byte des Vorblocks in 0B781H eingetragen und der Selbststart nicht ausgeführt. Nach der Rückkehr vom Ladeprogramm (vergleichbar mit FLOAD) kann man so anhand des Inhalts von 0B781H nachprüfen, ob die geladene Datei dekomprimiert werden muß.

Leider legt das originale FLOAD nirgendwo Informationen ab, wo man nachträglich feststellen kann, ob eine Datei selbstartend war, bei Interesse kann der Quelltext der kompletten Bildlade- und speicherroutinen hier auch veröffentlicht oder von mir bezogen werden, dies würde den Rahmen des heutigen Artikels sprengen.

Komprimierung / Dekomprimierung

Eine komplette Bildebene umfaßt auf dem KC 85/4 10 kByte, arbeitet man mit Farben, kämen pro Bild schon 20 kB zusammen, bei den HIRES-Bildern muß man den Color-IRM z.B. immer mit speichern. Bezieht man sich auf eine normale 780 kB-Diskette (max. 776 kB frei) bekäme man 38 komplette Bilder auf eine Diskette. Platz ist aber für max. 64 Bilder, wenn man immer die Farben hinzurechnet.

1990 war das noch nicht so wichtig, da spielte eine möglichst kleine Datei eine Rolle, da dann das Laden von Kassette schneller geht. Deshalb wurde von Anfang an eine Komprimierung der Bilddateien berücksichtigt, inzwischen hatte ich von Herrn Leubner die recht leistungsfähige Variante aus FRACTAL4 erhalten.

Sie eignet sich eigentlich für alle Komprimierungsaufgaben und entspricht der auch auf PC's eingesetzten RLE-Kodierung, im Wesentlichen werden ab 4 aufeinanderfolgenden gleichen Datenbytes ein Steuercode (1BH), das Datenbyte und die Anzahl der Datenbytes abgelegt, wo man ein Byte Speicherplatz gewinnt.

Sind mehr als 4 gleiche Bytes vorhanden, verkürzt sich die Dateilänge entsprechend, z.B. reduzieren sich durch diese Variante abgespeicherte HIRES-Grafiken von original 10 kB auf durchschnittlich 2...6 kB. Die Geschwindigkeit der Komprimierung/Dekomprimierung ist dabei noch so hoch, daß die entstehenden Verzögerungen beim Speichern oder Laden überhaupt nicht bemerkbar sind.

Bei der Definition der Bildformate hatte ich damals festgelegt, daß die Dekomprimierungsroutine immer am Anfang der jeweiligen Datei enthalten sein muß, dadurch kann man jederzeit das verwendete Komprimierungsverfahren ändern.

Der Nachteil, daß solche Dateien immer auf die originale Adresse geladen werden müssen, läßt sich verschmerzen, so viele Alternativen hat man bei 64 kB Speicher ohnehin nicht, wird der Bereich benötigt, muß man den Inhalt vorher woanders hinschieben und danach wieder zurückholen, unter CAOS ist der RAM8 gut geeignet, unter MikroDOS ist der Speicher im Grundgerät ab 04000H, zumindest jetzt noch, in der Regel unbenutzt.

Sowohl in der Lores-, als auch in der Hires-Variante beginnt die Dekomprimierungsroutine immer auf Adresse 04000H. Sie wird in meinen Programmen nach dem Laden und Feststellen einer komprimierten Datei mit CALL 4000 aufgerufen und entpackt den Dateiinhalt auf Adresse 08000H, also den standardmäßigen IRM.

Sollen der Inhalt der PIF- bzw. HIF-Dateien im COLOR-IRM landen, ist dieser vorher mit ESC"9" aktiv zu schalten, da EDMOV (s.u.) den IRM nicht verändert!!! Dadurch hat man beispielsweise die Möglichkeit ein zu ladendes Bild "unsichtbar" in das aktive, aber nicht angezeigte Bild des KC 85/4 zu laden (nach ESC"3" oder ESC"4") oder nach Wegschalten des IRM unter CAOS direkt in RAM-Blöcke auf Adresse 08000H zu entpacken.

Der nachfolgende Quelltext enthält die in "UNIPIC 1.0" eingesetzte Variante, sie wird für alle Dateien PIF/PIP/HIF/HIP eingesetzt, zur Nutzung ist die zu komprimierende Ebene auf 08000H zu laden und aktiv zu schalten, dann ruft man sie mit CALL EDCOM auf und entscheidet anhand dem Inhalt von A bei der Rückkehr, ob komprimiert gespeichert wird, in DE wird die Endadresse+1 der erfolgreich komprimierten Datei zurückgegeben.

Über die Steuerzelle COMNF läßt sich eine Komprimierung der Dateien grundsätzlich unterbinden, dann bringt die Routine sofort einen Fehler. Alles Weitere kann den Kommentaren im Quelltext entnommen werden.

;-------------------------------------------
;
COMNF   DEFB 1                ;Steuerzelle Komprimierung (aus=0/ein0)
;
EDCOM   LD A,(COMNF)
        OR A
        JR Z,EKO7             ;bei aus
        LD HL,EDMOV
        LD DE,4000H           ;Komprimierung auf 4000H
        LD BC,EDTOP-4000H
        LDIR                  ;Dekomprimierung eintragen
        LD HL,8000H           ;Ebene auf 8000H im Zugriff !!!
EKO0    LD A,0A8H             ;bis 0A800H
        CP H
        JR Z,EKO6             ;fertig und ok!
        LD B,1
        LD C,(HL)             ;Zeichen
        INC HL
        LD A,0A8H
        CP H
        JR Z,EKO3             ;Bildende
EKO1    LD A,(HL)
        CP C
        JR NZ,EKO2            ;ungleich
        INC HL
        INC B
        JR Z,EKO5             ;maximal 256 mal
        LD A,0A8H
        CP H
        JR NZ,EKO1            ;bis Bildende
EKO2    LD A,C
        CP 1BH
        JR Z,EKO5             ;1BH immer codiert
        LD A,B
        CP 4
        JR NC,EKO5            ;erst ab 4 Bytes Wdhlgn. eintragen
EKO3    LD A,C
EKO4    CALL EKOTE
        JR Z,EKO7             ;Fehler - Bild wird zu groß
        DJNZ EKO4
        JR EKO0               ;weiter
EKO5    LD A,1BH              ;Kennung
        CALL EKOTE
        JR Z,EKO7             ;zu groß
        LD A,C                ;Zeichen
        CALL EKOTE
        JR Z,EKO7             ;zu groß
        LD A,B                ;Anzahl
        CALL EKOTE
        JR Z,EKO7             ;zu groß
        JR EKO0               ;weiter
EKO6    XOR A                 ;A=0 ENDE o.k., in DE Endadresse+1
        RET
EKO7    LD A,1                ;A=1 ENDE FEHLER
        RET
EKOTE   PUSH BC
        LD B,A
        LD A,68H
        CP D                  ;=6800H ?
        LD A,B
        POP BC
        RET Z                 ;Z=1 Fehler
        LD (DE),A
        INC DE
        RET                   ;Z=0 o.k.
;
;-------------------------------------------
;
; -Dekomprimierungsroutine von 4000H auf 8000H
; -ist in jedem komprimierten Bild ab 4000H enthalten
; -kann vom übergeordneten Programm mit CALL 4000H auf-
; gerufen werden, vorher richtige IRM-Ebene zuschalten !!!
;
EDMOV   LD HL,EDTOP
        LD DE,8000H           ;Zieladresse beim Dekomprimieren
EMOV0   LD A,0A8H
        CP D
        RET Z                 ;fertig!
        LD A,(HL)
        INC HL
        CP 1BH                ;Kennung
        JR Z,EMOV1
        LD (DE),A
        INC DE
        JR EMOV0
EMOV1   LD A,(HL)             ;Zeichen
        INC HL
        LD B,(HL)             ;Anzahl
        INC HL
EMOV2   LD (DE),A
        INC DE
        DJNZ EMOV2
        JR EMOV0
EDTOP   EQU $-EDMOV+4000H     ;Länge + 4000H
;
; ab hier folgen komprimierte Bytes bis
; maximal 67FFH
;
;-------------------------------------------

Nutzung in anderen Programmen

Alle Programme von "EDIPIC" über "DIASHOW" bis "UNIPIC" enthalten eigene Laderoutinen, welche den Vorblock einer CAOS-Datei zwar voraussetzen, es aber zulassen, bei den unkomprimierten Dateien beliebige Adressen zu nutzen. Dies wurde in den beiden letztgenannten noch auf beliebige IRM-Abzüge erweitert

In "UNIPIC" wurde dann auch der Dateityp ".KCC" nicht mehr vorgeschrieben. Dort muß man nur noch sicher sein, daß in der Datei der IRM-Inhalt eines KC's enthalten ist und unter CAOS abgespeichert wurde. Über diese Schnittstelle (DIR auf ALL FILES) ist alles einlesbar, was in irgendwelchen CAOS-Programmen als SCREEN-DUMP gespeichert wurde.

Aus den Adressen im Vorblock wird die Dateilänge berechnet, wenn notwendig auf 02800H Bytes begrenzt und dann ab Adresse 04000H...06800H geladen. So bekommt man nahezu jede Datei in das PIP/PIF- oder HIP/HIF-Format.

Die unkomprimierten Varianten entsprechen nach Ergänzung des Kennbytes bei Lores und Wahl des zugehörigen Dateityps in Lores- und Hires-Variante im Wesentlichen einem SCREEN-DUMP. Dort ist auch kein Programmcode enthalten, so daß sie frei verschieblich sind, da sie beim Laden in meinen Programmen wie die SCREEN-DUMPS adressmäßig umgerechnet werden.

Diese Eigenschaften kann man nutzen, wenn man Grafiken aus eigenen Programmen so speichern will. Folgendes Beispiel habe ich in BASIC schon praktiziert:

1. Inhalt von 7FFFH in einer Variable merken
2. mit POKE auf Adresse 7FFFH das entsprechende Kennbyte bei Lores eintragen
3. mit VPOKE in 0B781H...0B785H IRM-Adressen eintragen (Anf.adr.: 7FFFH bei Lores, 8000H bei Hires / Endadr.: A800H)
4. NAME.PI_ bzw. .HI_ für das Bild ab Adresse 0 poken
5. mit CALL*DB FSAVE in SERVICE oder DIENST aufrufen
6. in 0B781H wieder 0 eintragen mit VPOKE
7. Variableninhalt wieder in 07FFFH eintragen

Sehr wichtig ist hierbei, man verletzt dadurch die soeben gemachten Vorschriften bezüglich der Adressen der Originale. Das wirkt sich bei meinen Programmen nicht aus, da sie selbst für den richtigen Platz im Programm sorgen.

Will aber ein anderes Programm beispielsweise eine PIP-Datei laden, stimmen die Adressen nicht mehr und die Datei gerät an die falsche Stelle im RAM, im ungünstigen Fall ist ein Absturz die Folge. Solche Bilder sollte man unter keinen Umständen weitergeben!

Der sicherste Weg besteht darin, die Dateien in eines der genannten Programme einzulesen und noch einmal abzuspeichern, dann stimmen die Adressen wieder, wenn man komprimiert speichert, spart man zusätzlich noch Speicherplatz auf der Diskette.

Alle Programmierer, denen eine Komprimierung zu umständlich oder kompliziert erscheint, sollten immer auf die unkomprimierte Variante ausweichen, dort hat man es am leichtesten, in der Lores-Variante ist nur das Kennbyte vorzusetzen, die Hires-Speicherung beim /4 entspricht dann einem Screendump mit vorgeschriebener Dateierweiterung!

Es sollten im Interesse aller KC-User allerdings nur Bilddateien in Umlauf gebracht werden, wo die oben genannten Adressen im Vorblock stehen. Man kann so beispielsweise alle unkomprimierten Dateien mit einem Offset von 4000H direkt in den IRM laden (vorher 7FFFH merken, danach wieder eintragen bei Lores).

Dies verbraucht nicht ein Byte zusätzlichen Speicherplatz für die Bildpufferung, es funktioniert aber nur wenn die Adressen richtig eingetragen sind!!! Weiterhin halte ich es für wichtig, daß die benutzten Dateierweiterungen auch nur verwendet werden, wenn der eben beschriebene Aufbau zu 100% eingehalten wird. Wer möchte, kann ja eigene neue Bildformate erfinden, dann bitte aber nicht mit PIC/PIP/PIF- oder HIP/HIF-Erweiterung.

Modulübersicht für KC85

von Mario Leubner

Modul  Kenn.  Steuerb.  Bezeichnung

D001     -       -      Grundgerät KC85/2 (PIO 88-8B, CTC 8C-8F)
D001     -       -      Grundgerät KC85/3 (PIO 88-8B, CTC 8C-8F)
D001     -       -      Grundgerät KC85/4 (OUT 84-87, PIO 88-8B, CTC 8C-8F)
D002     -       -      Busdriver für 4 Module (OUT 80 zur Modulsteuerung)
D003*    -       -      Programmer (ähnl. D002, ROM-Module brennen?)
D004    A7    xxAxxKxM  Floppy Disk Basis (Koppel-RAM F0-F3, OUT F4-F7)
D004     -       -      Floppy Disk Drive (Laufwerk K5601, 5 1/4")
D005                    Komfort-Tastatur fÜr KC85/4 (mit EMR UB8830)

M000*   01              Spezial f. KC85/3: autom. Start in Schacht 8 ab 4000H
M001    EF    xxxxxxxM  Digital IN/OUT (CTC 00-03, PIO 04-07)
M002*   DA    xxxxxxxM  PIO 3 (PIO 10-13, PIO 14-17)
M003    EE    xxxxxxxM  V.24 (2 Kanäle, SIO 08-0B, CTC 0C-0F)
M005     -       -      USER-Leermodul (freie Ports: C0-CF, Kennbytes C0-D7)
M006    FC    AAxxxxxM  BASIC und CAOS 3.1 für KC85/2 (1 Block zu 16K ROM)
M007     -       -      Adapter (Busverlängerung für Modulschacht)
M008     -       -      Joystick (PIO 90-93)
M009*   ED    xxxxxxxM  TLCM (Spracheingabe- und Datenkompressionsmodul)
M010    E7    xxxxxxxM  ADU1: 4 Analogeingänge mit Multiplexer (PIO 40-43)
M011    F6    AAxxxxWM  64K RAM (1 Block zu 64K, rotierbar)
M012    FB    AAAxxxxM  Software: TEXOR + V.24-Treiber (1 Block ROM 8K)
M021*    -       -      Joystick + Centronics (PIO 90-93)
M022    F4    AAxxxxWM  Expander-RAM 16K (1 Block zu 16K)
M024*   F5    AAxxxxWM  32K RAM (1 Block zu 32K)
M025    F7    AAAxxxxM  USER PROM 8K (1 Block zu 8K, 4 Sockel für 2716)
M026    FB    AAAxxxxM  Software: FORTH (1 Block ROM 8K)
M027    FB    AAAxxxxM  Software: DEVELOPMENT+V.24-Treiber (1 Block ROM 8K)
M029    E3    xxxxxxxM  DAU1: 2 Analogausgänge + 1 Relais (OUT 44..47)
M030    D9              EPROMER ?
M030    DB    AAAxxxxM  EPROMER für 2-64K (8K EPROM, PIO D0-D3, PIO D4-D7)
M032    79    AxSSSSWM  256K segmented RAM (16 Blöcke je 16K, 4000 od. 8000)
M033    01    AA0SxxxM  Software: TYPESTAR+RAMDOS (2 Blöcke ROM zu je 8K)
M034    7A    ASSSSSWM  512K segmented RAM (32 Blöcke je 16K, 4000 od. 8000)
M035    7B    SSSSSSWM  1M segmented RAM (64 Blöcke je 16K, Adr. 8000)
M036    78    AxxSSSWM  128K segmented RAM (8 Blöcke je 16K, 4000 od. 8000)
M040    F8    AAxxxxxM  USER PROM 16K (1 Block zu 16KByte)
M045    70    AASSxxxM  32K segmented ROM (4 Blöcke je 8K)
M046    71    AASSxSxM  64K segmented ROM (8 Blöcke je 8K)
M047    72    AASSSSxM  128K segmented ROM (16 Blöcke je 8K)
M048*   73    AASSSSxM  256K segmented ROM (16 Blöcke je 16K)
M053    EE    xxxxxxxM  RS232: wie M003, jedoch 2. Kanal mit TTL-Pegel
M120*   F0    AAAxxxWM  8K CMOS-RAM (1 Block zu 8K)
M122*   F1    AAxxxxWM  16K CMOS-RAM (1 Block zu 16K)
M124*   F2    AAxxxxWM  32K CMOS-RAM (1 Block zu 32K)

Im Steuerbyte bedeuten:

A (Basis-)Adresse
K Kopplung ein/aus
S Segmentnummer
W Schreibfreigabe
M Modulschaltzustand
x nicht benutzt

Verwendete Kennbytes

01 Autostart-ROM
7x segmented Memory
Dx..Ex I/O-Module
Fx Memory

Mit '*' gekennzeichnete Module kamen offenbar nicht in den Handel!

Der "offizielle" Teil des Clubtreffens

von Jörg Linder

Da sich offenbar niemand berufen fühlte, einen Bericht über das Clubtreffen zu schreiben, bleibt es wieder an mir hängen. Ich will versuchen, den sogenannten "offiziellen" Teil so gut wie möglich wiederzugeben. Sollte ich das eine oder andere Detail vergessen haben, so bitte ich um Nachsicht.

Leider haben wir nicht annähernd das geschafft, was wir eigentlich erledigen wollten. Ralf Kästner hat das Treffen mit folgenden Worten auf den Punkt gebracht: "Beim ersten Mal lernen sich alle kennen, gearbeitet wird ab dem zweiten Treffen."

Nach dem Mittagessen sollte es am Samstag also zur Sache gehen. Wir hatten einiges vor uns: neue Standards festlegen, Logo für den Club wählen, Satzung beschließen, Projektgruppen bilden und noch einiges andere mehr.

Ich komme gleich mal zum peinlichsten Punkt: die Satzung. In mühevoller Arbeit habe ich sie erarbeitet und auf Diskette gespeichert und auch ausgedruckt. Das ausgedruckte Exemplar habe ich allerdings so gut weggelegt, daß ich es zum Clubtreffen nicht mehr finden konnte. Beinahe wäre es mir mit der Diskette genauso gegangen, doch in letzter Minute tauchte sie noch auf. Ursprünglich wollte ich dann auf dem Treffen den Text vorlesen und Änderungen bzw. Ergänzungen vornehmen. Wir hätten das Ganze dann beschlossen und mit diesen KC-News an jeden versenden können. Natürlich ist alles anders gekommen, doch das wird später erklärt.

Nachdem ich also die Satzung nicht präsentieren konnte, kamen wir zum Club-Logo. Voller Dankbarkeit an alle Mitglieder des KC-Clubs für Ihre überaus starke Beteiligung durfte ich die Entwürfe von Andreas Ose und Ralf Kästner zeigen - alle anderen hatten sich NICHT beteiligt! Diese Abstimmung ging kurz und schmerzlos mit einem klaren Sieg für das Logo von Andreas Ose über die Bühne. Dieses Logo ist ab sofort auf allen KC-News zu bewundern.

Anschließend begann die Diskussion über das Format der KC-News. Während des Treffens wurden nämlich Stimmen laut, sie gänzlich auf Diskette umzustellen. Jetzt kam ordentlich Stimmung auf! Befürworter und Gegner dieses Vorschlages legten die Vor- und Nachteile dar. Hinzu kam noch der Streit um das Format der Text- und Grafikdateien, wenn die KC-News auf Diskette erscheinen würden. Leider kann man diese Diskussion auf dem Papier nicht so wiedergeben, wie sie sich abgespielt hat.

Zum Schluß sind wir jedoch dort angekommen, wo wir jetzt sind: Alles bleibt beim Alten! Der anschließende Vorschlag, daß Papierformat von A4 auf A5 zu ändern, wurde abgelehnt. Hier bleiben wir ebenfalls beim Alten!

Auch die hitzige Diskussion um das Universal-Drive, welches Klaus Witzenhausen und Uwe Kerl entwickeln (wollen), ist hier kaum wiederzugeben. Das Ergebnis ließe sich etwa so zusammenfassen: Der Aufwand (sowohl finanziell als auch technisch) wäre zu hoch, um genügend Interessenten zu finden. Eventuell ist ja mit einem geänderten bzw. ausgereifteren Konzept mehr Interesse zu wecken!? Für das Sound-Modul, das die beiden entwickeln, interessieren sich jedoch etliche Mitglieder. Klaus hat versprochen, daß darüber demnächst in den KC-News zu lesen sein wird.

Weil wir gerade so schön bei der Hardware waren, stellte ich gleich das Generic IDE-Interface von Tilmann Reh vor. Damit ist der Anschluß einer Festplatte an nahezu jeden CP/M-Computer möglich (also auch unser D004). Für alle, die nicht zum Treffen gekommen sind, gibt es in diesen News einen kurzen Artikel darüber. Wer Interesse hat, melde sich bitte bei mir. Wenn es damit richtig losgeht, ist in den KC-News auf alle Fälle nochmal darüber zu lesen.

An diesem Punkt gingen wir nahtlos zur Festplatte, die Uwe Felgentreu an seinem KC angeschlossen hat, über. Er möge mir verzeihen, wenn ich an dieser Stelle den Aufbau als "abenteuerlich" bezeichne, aber mir fällt dazu nichts anderes ein. Zwar gibt es somit schon eine Festplatte am KC, doch wie Uwe selbst sagte, ist diese Lösung kaum oder nicht nachvollziehbar. Auch er gibt der Lösung von Tilmann den Vorzug.

Inzwischen war einiges an Zeit vergangen und die Leute wurden auf den Sitzen immer unruhiger. Besonders die Raucher brauchten mal eine Pause. Daß anschließend niemand mehr bereit sein würde, sich noch ein paar trockenen Beschlüssen hinzugeben, war mir irgendwie schon klar. So kam es dann auch - alles verteilte sich gleichmäßig im Raum und diskutierte im kleinen Kreis. Die Beschlüsse müssen wir wohl hier in den KC-News schriftlich fassen oder beim nächsten Treffen!

Auf alle Fälle soll es 1996 geordneter ablaufen, denn wir treffen uns ja schließlich nicht zum Vergnügen! ;-)

Kurzprotokoll einer "ganz normalen" Woche

von Jörg Linder

Wer sich schon immer gefragt hat, was ein "Clubleiter" so macht, dem habe ich nachfolgend mal den Ablauf einiger Tage aufgezeichnet. Zum Glück ist mein Leben nicht immer so stressig! Doch was tut man nicht alles für den Club...

Donnerstag, 06. April 1995

Letzte Vorbereitungen auf das Treffen: ein paar Sachen kopieren, die KC-Anlage von ihrem Stammplatz holen und einpacken....

Gegen 1.00 Uhr nachts ist dann alles erledigt und ich bin's auch

Freitag, 07. April 1995

Ausgerechnet heute morgen müssen Handwerker kommen! Der Tagesplan gerät leicht durcheinander. Zirka 12.45 Uhr kommt ein Anruf vom Motel - das erste Clubmitglied ist da. Schnell noch die letzten Sachen verstauen und ab nach Gusow.

Im Laufe des Nachmittags treffen immer mehr Leute ein und am Abend sind wir schon ein ganz beachtlicher Haufen. Zwei Gäste sind auch dabei: Frank Pischel und Helmut Huhnstock aus Mühlhausen. Sie haben seinerzeit unseren geliebten KC-Kisten das Leben eingehaucht. Sie erzählten einige Anekdoten, die es wirklich in sich hatten.

Ehe man es richtig merkt, hat auch schon der neue Tag begonnen - da treffen noch drei Mitglieder ein, die beinahe kein Bett mehr bekommen hätten, weil vom Motel niemand mehr da war.

Irgendwann um 1.00 Uhr morgens bin ich wieder zuhause (aber noch nicht im Bett!).

Samstag, 08. April 1995

Der Wecker ist um 8.00 Uhr der Meinung, daß ich aufstehen sollte. Irgendwie hat's dann auch geklappt und irgendwie bin ich auch nach Gusow gekommen. Dort geht's gegen 9.00 Uhr schon weiter. Auch wenn man es kaum glauben möchte: Es kommen immer noch Mitglieder dazu. Beim Mittagessen hatte ich die Gelegenheit, alle zu zählen - 28 (!) Mitglieder sind erschienen. Mit unseren Mühlhäuser Gästen, die leider vormittags abgereist sind, waren wir also 30 Personen. Das soll uns erstmal ein anderer Club nachmachen!

Alles in allem wurde dieser Tag noch länger als der vorherige. Gegen 1.45 Uhr war ich dann zuhause. Was kommt, kann sich wohl jeder denken:

Sonntag, 09. April 1995

War das eben der Wecker, oder wer macht solchen Lärm um 8.00 Uhr? Um neun soll's in Gusow weitergehen, also keine Müdigkeit vortäuschen.

Verständlicherweise ist nicht mehr allzu viel passiert. In der allgemeinen Aufbruchstimmung wurden nur noch zwischendurch ein paar Erfahrungen ausgetauscht. Nahezu jeder äußerte, daß das Clubtreffen ein voller Erfolg war. So etwas müssen wir nächstes Jahr wieder machen!

Beim Mittagessen saß nur noch der spärliche Rest von 6 Personen, die anschließend heimwärts fuhren.

Mittwoch, 12. April 1995

Fahrt nach Gera, dem Ausgangspunkt für die nachfolgenden "Abstecher".

Donnerstag, 13. April 1995

Mal eben 150 km in Richtung Mühlhausen, eine Kiste mit Software abholen und dann wieder 150 km zurück. So, oder so ähnlich könnte man diesen Tag beschreiben.

Ich war bei Frank Pischel und Helmut Huhnstock, mit denen eine Zusammenarbeit für alle nutzbringend sein dürfte!

Sonntag, 16. April 1995 (Ostersonntag)

Noch vor dem ersten Hasenschrei (schließlich ist Ostern :-)) aufstehen und Richtung Kronach fahren (wieder ca. 150 km) - das wollte ich schon immer mal machen. Diesmal hatte ich auch Grund dazu: Jahrestreffen des Club-80, der sich mit CP/M- und Z80-Rechnern beschäftigt.

Als ich dort eintraf, war noch ca. ein Dutzend Leute anwesend - schließlich hatte das Treffen schon am Karfreitag begonnen. Zwischen den ganzen anderen "exotischen" Rechnern fiel der KC etwas aus der Rolle. Ich habe ein paar Diashows laufen lassen, was ja wirklich beeindruckend sein kann.

Am Nachmittag kam auch Tilmann Reh, der nicht schlecht über unser Interesse am Festplattenanschluß staunte. Übrigens bezeichnete er die Kombination des KC mit Floppy als "heiße Kiste". So etwas habe er noch nie gesehen.

Montag, 17. April 1995

Heimreise nach Seelow mit einer Kiste Kassetten und jeder Menge guter Laune im Auto. (Beim Gedanken, daß ich ab Mittwoch wieder arbeiten muß, war die gute Laune natürlich fort!)

Speaker's Corner

Modellbahn und KC

Die Sächsische Modelleisenbahner-Vereinigung veranstaltet vom 1. bis 9. Juli 1995 eine Modellbahnausstellung in Radebeul bei Dresden. Zu sehen sein wird unter anderem auch die Gemeinschaftsanlage des Modellbahnclub Löbau, die vollautomatischen Fahrbetrieb von 10 Zügen auf einer Fläche von 34 qm gestattet. Die Steuerung übernimmt ein KC 85/4!

Die Ausstellung ist täglich von 10.00 - 18.00 Uhr geöffnet. Zu finden ist sie in Radebeul West, wenn man sich vom Bahnhof aus in Richtung Elbufer bewegt. Wegweiser werden das Auffinden erleichtern.

Frank Dachselt

 

Ein Hinweis für die Nutzer von CAOS 4.3:

Nach dem Austausch der EPROMs ist auch unbedingt die Aufrüstung des RAM auf 256 kByte notwendig. Im Prinzip geht es zwar auch mit 64 kByte, aber dann tritt folgender Effekt auf:

CAOS schaltet 14 (16) RAM-Ebenen. Bei Weglassen der höherwertigen Adreßbits ergeben sich somit 4 mal die selben vier RAM-Ebenen. Mit SWITCH 3 B würde die Ebene 2 geschaltet, was gleichzeitig der RAM 0 wäre. Die RAM-Floppy-Verwaltungstabelle, die bei der PC-Betriebsart vom D004 erzeugt wird, nutzt die beiden RAM8-Ebene mit den Befehlen SWITCH 3 7 und SWITCH 3 B ! (hier liegt der eigentliche Fehler!).

Bei CAOS 4.2 klappt es, da nur ein Bit zur Ebenenunterscheidung ausgewertet wird. CAOS 4.3 legt aber mit der zweiten Ebene den RAM0 ins RAM-Floppy und dort ist der Absturz des Rechners vorprogrammiert. Vorübergehend kann man RAM.COM verwenden, um den RAM8 ganz aus der RAM-Floppy zu entfernen, bis auch die 256k-Typen eingebaut sind.

Mario Leubner

ASM-Programmiertips

 

von Ralf Kästner

Dies soll kein Programmierkurs in Assembler werden aber speziell für Hans Wermeling die beiden gewünschten Routinen. Es sind ja oft die kleinen Details, welche einem das Programmieren erleichtern.

Das neue EDAS 1.64 bietet die Möglichkeit Quelltextteile zusammenzufügen oder einzeln abzuspeichern, so daß es endlich auch unter CAOS möglich ist, eigene Bibliotheken aufzubauen. Für immer wiederkehrende Aufgaben benutzt man zweckmäßigerweise dann auch immer die gleichen, schon bewährten und vor allem ausgetesteten Routinen.

Zwei dieser kleinen nützlichen Helfer möchte ich deshalb heute vorstellen.

Für die Ausgabe von programminternen Werten, welche meist in binärer Form vorliegen, ist das erste Progrämmchen gedacht. Es erwartet eine ganze Dualzahl (ohne Vorzeichen) im Register HL bzw. A und wandelt sie direkt in die dezimale ASCII-Darstellung um, welche von links nach rechts ziffernweise auf das aktuelle Ausgabegerät (i.d.R. Bildschirm) ausgegeben wird.

Im rufenden Programm muß sichergestellt werden, daß die beiden Wertebereiche (0...999 bzw. 0...99) eingehalten werden. Da nur Additions- und Subtraktionsbefehle verwendet werden, geht das ziemlich schnell. Je nach Anforderung an die Ausgabe kann man zwei- oder dreistellig ausgeben, indem man die entsprechende Einsprungadresse nutzt. Vor dem Aufruf mit CALL muß man den Cursor (0B7A0H) auf die gewünschte Position der ersten Ziffer einstellen.

;-------------------------------------------
; Ausgabe von Dezimalzahlen
;-------------------------------------------
; Eintritt für dreistellige Zahlen
;
; PE: HL - Wert (0...3E7H bzw. 0...999)
; PA: Ausgabe von 3 Dezimalziffern
; VR: A,BC
;
SHWRT   PUSH DE
        LD DE,064H
        LD B,D           ;=0
SHWR1   OR A
        SBC HL,DE
        JR C,SHWR2
        INC B            ;100er
        JR SHWR1
SHWR2   ADD HL,DE
        LD A,L           ;merken
        CALL SHWR6       ;100er ausgeben
        POP DE
;
; Eintritt für zweistellige Zahlen
;
; PE: A - Wert (0...63H bzw. 0..99)
; PA: Ausgabe von 2 Dezimalziffern
; VR: A,BC
;
SHW99   LD C,00AH
        CALL SHWR3
        LD B,A           ;1er
        JR SHWR6
SHWR3   LD B,000H
SHWR4   SUB C
        JR C,SHWR5
        INC B            ;10er
        JR SHWR4
SHWR5   ADD C            ;zurueck
SHWR6   PUSH AF          ;merken
        LD A,030H
        ADD B
        CALL 0F003H
        DEFB 24H         ;Ziffer ausgeben
        POP AF
        RET
;-------------------------------------------

Das zweite Unterprogramm stellt den BASIC-RND(X) Befehl zur Verfügung. In der Zelle RNDMX gibt man die Obergrenze für die zu erzeugenden Zufallszahlen (2...255 möglich) vor. Persönliche Zufallsanpassungen kann jeder selbst vornehmen. Die alte Zufallszahl wird zunächst als Basis für den "neuen Zufall" verwendet.

Durch Multiplikation und Addition werden hinreichend große Zahlen erzeugt, wobei der Überlauf des Akkus verloren geht. Durch Zugriff auf das Refresh-Register R wird der Zufall noch weiter verfeinert, abschließend wird von der entstandenen Zahl der Inhalt von RNDMX heruntersubtrahiert, so daß man in den gewünschten Bereich gelangt.

Die Wirkung dieser Routine kann man in der Sprühdose von "UNIPIC" erkennen, dort werden die X- und Y-Koordinaten getrennt für den Sprühbereich von 8*8 Pixel errechnet.

;-------------------------------------------
; Erzeugung von Zufallszahlen
;-------------------------------------------
;
; PE: /
; PA: A - Zufallszahl
; VR: AF, HL, DE, BC
;
RNDMX   DEFB 7           ;Vorgabe Obergrenze Zufallszahl
RNDOM   DEFB 0           ;Zufallmerker
;
ZUFAL   LD A,(RNDOM)
        INC A            ;0
        LD D,A
        LD C,16
        CALL 0F003H
        DEFB 41H
        ADD B
        LD C,A
        LD A,R
        ADD C
        PUSH AF
        LD A,(RNDMX)
        INC A
        LD B,A
        POP AF
ZUFA1 SUB B
        CP B
        JR NC,ZUFA1
        LD (RNDOM),A
        RET
;-------------------------------------------

Soweit für heute, vielleicht hat ja der eine oder andere auch interessante Routinen oder Tricks auf Lager. Das ist sicher für andere User ebenfalls interessant. Es sollte auch nicht auf eine Programmiersprache beschränkt bleiben. Es steigert sicherlich den Abwechslungsreichtum und den allgemeinen Wissensstand der gesamten KC-Gemeinde, wenn diese Rubrik in der Zukunft von vielen Beiträgen und Ideen ALLER KC-Anwender gefüttert wird.

Man könnte ja auch seine HILFE- bzw. SUCHE-Meldung betreffs Programmierung kleiner Probleme hier plazieren. Ich bin selbst auch noch lernfähig und -willig und ich bin auch zukünftig bereit, mir geläufige und bekannte Sachen an dieser Stelle zu erklären, mir ist allerdings die Zeit auch zu schade, Beiträge auf Verdacht zu schreiben, man muß schon ungefähr wissen, was von Interesse ist.