KC-News 2/1996

Top-Themen:

• Blockanzeige am M011
• DIASHOW 1.1
• Supercalc und dBase II auf dem KC
• Umbau M011 auf M032
• PCX-Bilder konvertieren
• IDE-Festplatte am KC
• neues Betriebssystem ZSDOS
• Z-System
• Clubtreffen 1996

Einleitung

von Klaus Witzenhausen

Hallo Leute!

Zunächst möchte ich mich erst einmal für das zahlreiche Erscheinen beim Clubtreffen bedanken. Immerhin waren 37 Mitglieder anwesend. Auch unsere Gäste waren sehr zahlreich. Für alle, die nicht kommen konnten, möchte ich die Namen noch einmal erwähnen: Helmut Jungkunz (Z-Node), Tilmann Reh (GIDE-Interface), Michael Kalb (Club-80), Thomas Karsten (ZX-Team), Helmut Huhnstock und Frank Pischel (beide aus Mühlhausen). Auch bei unseren Gästen möchte ich recht herzlich bedanken.

Man kann also aus dieser kleinen Auflistung erkennen, daß auch dieses Mal wieder kräftig die Post abging! Vom Leiter der Jugendherberge, Herrn Lentje, und im Namen des gesamten Herbergsteams soll ich allen Teilnehmern ein dickes Kompliment aussprechen und ausrichten, daß unser Club sehr vorbildlich gewesen ist.

Bedanken möchte ich mich außerdem bei allen, die mich in Wort und Tat unterstützt haben.

Für den Fall, daß jemand bei mir Fotos bestellen möchte, habe ich mich nach dem Preis für Abzüge erkundigt. Er beträgt pro Foto 0,55 DM. Leider ziemlich hoch, aber noch keine Mark! Etwa 30 Aufnahmen sind etwas geworden. Wer also ein paar Fotos haben möchte, kann seine Bestellung bei mir loswerden. Ich werde die Bestellungen in der Reihenfolge des Eingangs abarbeiten. (Natürlich hat das Porto auch jeder selber zu tragen!)

Das soll es erst einmal von mir gewesen sein, denn alles andere über das Treffen wird ja von verschiedenen Teilnehmern gesagt werden.

Meinen ganz besonderen Dank, ich hoffe doch, daß ich damit im Interesse des gesamten Clubs spreche, gilt der JH Erfurt unter der Leitung von Herrn Lentje. Ohne den selbstlosen Einsatz des Personals wäre unser Treffen wohl niemals so reibungslos abgelaufen!

Vielen Dank!

2. Clubtreffen 1996 in Erfurt

von Jörg Linder

So, nun "hänge" ich mal wieder in den Seilen. Klaus stellte in seinem Artikel die Vermutung an, daß sich einige zum Clubtreffen äußern werden. Doch wie schon im letzten Jahr bleibt diese ehrenvolle Aufgabe mir vorbehalten. Also werde ich jetzt versuchen, das ganze Geschehen ein wenig zu schildern.

Natürlich nahm auch in diesem Jahr mit der Anreise "das Übel" seinen Lauf. Als einer der ersten traf ich am Freitag, den 08. März ein. Zunächst bekam ich das 3-seitige Arbeitsprogramm in die Hände gedrückt und die scheinbar endlose Reihe von Namensschilder zu sehen. Schon nach dem ersten Überfliegen des uns bevorstehenden Pensums wußte ich: Das schaffen wir nie! (Im Hinterkopf hatte ich noch das Sprach-Wirrwarr der diversen Personengruppen des letzten Jahres.)

Im Laufe des Nachmittags wurde unser Raum schon richtig voll und die Namensschilder nahmen den ihnen zugedachten Platz an der geschwollenen KC-User-Brust ein. Mit den Teilnehmern stellte sich auch sofort der rege Erfahrungsaustausch ein. Zwar waren in diesem Jahr wesentlich mehr Mitglieder und Gäste anwesend, jedoch zeichnete sich ein erschreckender Trend ab: Nur drei KCs waren zu sehen! Daneben machten sich ein ZX81, zwei CPU280, ein "großer" PC, ein Notebook und ein Laptop breit. Für wahre KC-Enhusiasten ein erschreckendes Ergebnis.

Wie sich später herausstellte, eignet sich ein PC jedoch hervorragend als komfortable Tastatur für den KC. Doch nicht nur das; inzwischen ist uns auch der Dateiaustausch via Seriellschnittstelle gelungen. Dirk Walther wird sich diesem Thema eingehender widmen und uns seine Erfahrungen schildern. Sicherlich ist dies auch der erste wichtige Schritt in Richtung Modemanschluß.

Doch nun zum Samstag. Es war echter Streß angesagt, schließlich stand um 8.00 Uhr schon der erste Tagesordnungspunkt an. Dazu muß man noch erwähnen, daß der Freitag erst am Samstagmorgen gegen 1.00 Uhr sein Ende fand. Erschwerend kam hinzu, daß es erst ab 8.00 Uhr Frühstück gab. Mit anderen Worten: Wir hingen in der Zeit :-)

In der ersten Arbeitsstunde wurden clubbezogene Themen behandelt. So wurden z. B. zwei Entwürfe für unsere (endlich zustande gekommenen) Leitsätze vorgestellt. Außerdem legte ich den Kassenbericht vor. Demnach hatte der Club am 01.03.1996 ein Guthaben von 1.600,65 DM. Dies mag zunächst sehr hoch erscheinen, wird jedoch durch die Tatsache relativiert, daß davon noch 139 KC-News herzustellen und zu versenden sind. Im letzten Jahr standen 2.570,00 DM Einnahmen Ausgaben in Höhe von 2.127,47 DM gegenüber.

Darüberhinaus haben wir auch einen neuen Hardware-Koordinator gewählt. Jörg Helbig übernimmt diese Funktion von Klaus Witzenhausen. Er wird außerdem (im Rahmen seiner Möglichkeiten) Reparaturen an unserer KC-Hardware ausführen. Wer also in dieser Richtung ein Problem hat, wendet sich am besten an ihn. (Wer Kopien von Schaltbildern oder Serviceanleitungen haben möchte, muß ihm nur einen frankierten Rückumschlag und 0,15 DM pro Kopie zusenden.)

Inzwischen war es schon nach 9.00 Uhr. Für diesen Zeitpunkt war der Vortrag von Hans-Rudolf Stoeßer über Redabas/dBase vorgesehen. Wir hingen also immer noch in der Zeit und außerdem forderten die Raucher eine etwa 10-minütige Pause. Hans-Rudolf hatte seinen Vortrag sehr gut vorbereitet und stellte uns dBase nicht nur als Datenbank- sondern auch als Programmiersystem vor. Sein Beitrag in diesem Heft basiert auf seinem Vortrag, allerdings wird er dieses Mal auf einen Applaus verzichten müssen...

Auf dem Plan stand als nächstes die Einwahl in die ZNODE 51 von Helmut Jungkunz. Ein technisches Problem ließ endgültig das zeitliche C(H)AOS über uns hereinbrechen: Die ZNODE ist erst nachmittags zu erreichen. Für einen Moment drohte ein ähnliches Durcheinander wie im letzten Jahr. Doch ein Gast zog mit einer kleinen schwarzen "Schachtel" das Interesse auf sich. Die Rede ist von Thomas Karsten, der uns einen seiner ZX81 vorstellte. Als Vertreter des ZX-Teams machte er natürlich ordentlich Werbung. Schließlich ist der ZX81 der erste (und wohl einzige) Computer, der mit 4 Schaltkreisen auskommt. Leider hatte Thomas nicht allzu viel Zeit und mußte kurz vor dem Mittagessen wieder von dannen ziehen, so daß wir auf die versprochene Vorführung verzichten mußten (aufgeschoben ist aber nicht aufgehoben - oder!?).

Nach dem Mittag war die neue Version von UNIPIC zu sehen. Besser gesagt die lauffähige (Alpha?-)Version 2.0. Auf den allerersten Blick unterscheidet sich diese Version für den Anwender nur in Feinheiten. "Unter der Haube" hat sich aber einiges getan. Im Grunde genommen handelt es sich um ein komplett neues Programm, das nun vollständig per Maus gesteuert wird. An dieser Stelle möchte ich jedoch nichts Falsches übermitteln und einem Artikel von Ralf Kästner nicht vorgreifen. Mehr über UNIPIC 2.0 gibt's demnächst hier in den KC-News.

Ein weiterer Höhepunkt (wenn nicht gar DIE Sensation) war die Festplatte am KC von Mario Leubner. Hardwareseitig ist sie über das GIDE-Interface von Tilmann Reh angeschlossen. Wesentlich komplizierter gestaltete sich die softwaremäßige Einbindung in das System. Dazu hat Mario ein komplett neues CP/M-kompatibles Betriebssystem entwickelt, das auf ZSDOS beruht. Somit stehen ihm jetzt 42 Megabyte Festplattenspeicher zur Verfügung und darüberhinaus auch ein größerer TPA-Bereich. Sowohl über den Festplattenanschluß als auch über das neue System ist in dieser Ausgabe etwas zu lesen.

Den ursprünglich vorgesehenen "Besuch" in der ZNODE wollten wir eigentlich auf den frühen Abend verlegen. Doch statt dessen machte Helmut Jungkunz mal wieder Unmögliches möglich - ein GENIE Live-Chat mit Amerika! Als Chat bezeichnet man eine Unterhaltung per Computer in einer Mailbox oder einem Netzwerk; GENIE ist (ähnlich wie Compuserve oder T-Online) der Netzwerkdienst von General Electrics in den USA.

Helmut hatte mit Bill Kibler aus Texas einen Termin für unseren Chat ausgemacht. Während wir uns um 17.00 Uhr MEZ vor dem Rechner versammelten, war Bill um 9.00 Uhr Ortszeit am anderen Ende der Leitung anwesend. Auf der Beilagen-Diskette findet Ihr sowohl den Originalmitschnitt (in englischer Sprache) als auch eine deutsche Übersetzung des Chats in Form von Textdateien.

Der Vollständigkeit halber möchte ich nicht verschweigen, daß wir unser Arbeitspensum nicht erfüllen konnten. Die Vorführung des Soundmoduls und ein Vortrag zur Programmierung von Farbe und Grafik unter MicroDOS waren leider nicht zu erleben. Doch Uwe Felgentreu hat mir versprochen, seinen Vortrag in Form eines Artikels in den KC-News nachzuholen.

Selbstverständlich möchte ich mich bei unseren Gästen für Ihre Teilnahme bedanken. Mit ihrer Hilfe erreichten wir einen neuen Teilnehmerrekord. Insgesamt waren 43 Personen bei unserem Treffen anwesend. Neben 37 Clubmitgliedern waren 6 Gäste gekommen: Helmut Jungkunz, Tilmann Reh, Michael Kalb, Thomas Karsten, Frank Pischel und Helmut Huhnstock. Die drei letztgenannten schauten leider nur kurz vorbei. Von den beiden Mühlhäusern waren eine Menge Unterlagen und KC-Hardware zu erstehen.

Außerdem möchte ich auch dem Personal der Jugendherberge danken, daß sie uns so gut beherbergt haben. Zwar sind nur wenige in unserem Club noch Jugendliche, aber wir haben uns trotzdem sehr wohl gefühlt.

In diesem Jahr hat es sogar rechtzeitig mit den Fotos geklappt. Hier und da werdet Ihr in dieser Ausgabe ein paar davon finden. Für mich bleibt nur zu hoffen, daß nach dem Kopieren noch etwas zu erkennen ist. Doch jetzt will ich Euch nicht länger von den (fast) unzähligen Artikeln abhalten, die mich diesmal erreicht haben. Viel Spaß beim Lesen und Ausprobieren wünscht

Euer Redakteur

Neue BASIC-Programme

von Jörg Linder

Gerade zu unermüdlich versorgt mich Herr Riehl mehr oder weniger regelmäßig mit neuen BASIC-Programmen. So sind auch wieder für diese Ausgabe einige zusammengekommen, die er wie folgt beschreibt:

Von Mühlhausen gab es seinerzeit ein Programm namens TVH.SSS, das ich leider nicht mehr auftreiben konnte. So habe ich selbst ein entsprechendes Programm geschrieben, das eine kleine Idee besser ist, wie ich meine.

PIXZEI.SSS ermöglicht aus einem PIP-Bild ein kleineres mit max. 128 Zeichen (Bytes) auszuschneiden, die durch das Programm als Zeichensatz abgelegt werden können. Leider sind nur quadratische Ausschnitte möglich! Irgendwie funktioniert die Berechnung der Adressen nicht so wie sie sein sollten. Sonst ist die Bildausgabe völlig chaotisch!!! Vielleicht hat ein User eine Idee, wie auch rechteckige Formate als Zeichensatz abgelegt werden können und sollte (!) es mich wissen lassen!

Die anderen Programme sind von Herrn Helmut Teitzel aus Quedlinburg. Seine Anwenderprogramme sind von der Sache her schon gut, nur in der Anwendung (Menüführung) als solches etwas umständlich aufgebaut. Das betrifft auch die Anleitungen - aus meiner Sicht.

Meine Programme:

KUGEL - 20 KB, 3 Prg.
LABY - 26 KB, 3 Prg.
TVH-1 - 26 KB, 5 Prg.
PIXZEI - 8 KB, 2 Prg.

Zu allen Spielen vorher <H>ILFE lesen!

Das war's dann wieder bei sehr sommerlichen Temperaturen!

Ruthart Riehl

Jede Menge Software

von Mirko Wieblitz

Hallo, Ihr KC-Freaks!

Im Archiv WIEBLITZ.PMA ist für jeden User etwas dabei. Folgende Programme sind enthalten:

Im Programm FUBDAT.SSS sind auch Hilfsroutinen enthalten. Deshalb läuft das Programm auch nur auf dem /3. Ich habe Euch einmal diese Routinen aufgelistet:

Viel Spaß mit allen Programmen und viel Spaß beim Experimentieren mit den Routinen!

BÖRSE 1.4

von Mirko Wieblitz

1. Etwas allgemeines zu Börse

Wie Ihr sicher schon erkannt habt, gab es schon mehrere Versionen von Börse. Diese hier ist jedoch die kürzeste von allen, aber auch die Leistungsfähigste! Man lernt eben im Laufe der Jahre dazu! Sicher ist nicht alles bei Börse korrekt und wahrheitsgemäß (!), aber ich finde es ist mir ganz gut gelungen, oder?

Ich wünsche Euch allen viel Spaß mit dem Programm. Sollten Fehler auftreten oder Verbesserungsvorschläge vorhanden sein, so bitte ich diese, dem Autor mitzuteilen! Die nachfolgene Beschreibung durchlesen oder auch nicht (da ja alles gut Menugesteuert ist) und ran an die Börse und Aktien kaufen!

2. Voraussetzungen für das Programm

Softwaremäßig:

Man benötigt: BOERSE.SSS, BOERSE.PIP und eventuell die entsprechenden abgespeicherten Dateien für die Gewinne, Aktien u.a. Diese sind aber nicht für den Programmstart notwendig!!

Hardwaremäßig:

Hardwaremäßig kann man einen KC 85/4 benutzen. Die /3 User müßten das Titelbild umrechnen lassen, so daß es auf dem /3er läuft. Oder sie nehmen diese Routine ganz aus dem Programm! Der Diskettenaufsatz D004 muß nicht unbedingt vorhanden sein.

3. Start von Börse

Startet wie gewohnt das BASIC-Programm, egal ob mit Diskette oder Kassette. Nach dem Start von Börse wird gefragt, ob der D004-Aufsatz vorhanden ist. Die Frage ist entsprechend zu beantworten! Das Titelbild wird geladen. (Sieht gut aus, was) Nun müßt Ihr eine Taste betätigen zum "richtigen" Start von Börse.

4. Die einzelnen Menus

Der folgende Teil ist Menugesteuert. Ich will aber trotzdem zu einigen kritischen Punkten etwas sagen.

5. DAX-Kurve

Bei Anwahl dieses Menupunktes, dauert es eine Ewigkeit bis etwas geschieht. (Nachteil von BASIC) Mit den Kursortasten kann man die DAX-Kurve verfolgen. Mit Enter gelangt man zurück zum Menu.

6. Gewinne/Verluste

Hier werden alle Aktien angezeigt, mit den Gewinnen und Verlusten. Sollten Ihr einen Kredit aufgenommen haben und es hier plötzlich piepen, so ist dies ein Zeichen dafür, daß der Kredit abgezahlt wurde. Die gelben Aktien sind die von Euch gekauften Aktien.

7. Aktien aufkaufen

Der Wert der aufgekauften Aktie wird vom Konto abgezogen!

8. Save-Menu

Kein Aufruf möglich, wenn ein Kredit noch nicht abgezahlt wurde. Solltet Ihr negative Summen oder kein Geld auf dem Konto haben, so könnt Ihr dieses Menu ebenfalls nicht aufrufen!

9. Zusammenfassung

Der Rest dürfte klar sein! Euer Startkapital beträgt 6000 DM. Mit dem Geld könnt Ihr Aktien kaufen. (Anfangswert für alle Aktien: 800 DM) Sollte das Geld alle sein, so könnt Ihr einen Kredit aufnehmen! Der DAX wird aus den Werten der Aktien berechnet!

LOTTO

von Mirko Wieblitz

1. Voraussetzungen

1.1 Hardwaremäßig:

Voraussetzung ist ein KC 85/4 mit Floppyerweiterung D004. Zusätzlich empfehle ich ein Drucker, für die Auswertung.

1.2 Softwaremäßig:

Hierzu benötigt man das BASIC-Programm LOTTO12.SSS sowie die 3 Bilddateien LOTTOSH.PIP, LOTTOTB.PIP, LOTTOED.PIP. Die entsprechenden Lottozahlendateien werden nicht für den Programmstart benötigt !!

2. Hauptmenu

1. Lottoscheine laden
2. Lottoscheine speichern
3. Lottoscheine eingeben
4. Lottoscheine vergleichen
5. Grafisch Darstellen
6. Programm beenden

Durch Eingabe der entsprechenden Zahl, wird das links danebenstehende ausgeführt. Möchten Sie einen Lottoschein ausfüllen, so geben Sie die 3 ein.

2.1 Lottoschein laden

Durch Eingabe des Dateinamen werden Ihre Lottoscheine in den Computer geladen und stehen somit wieder zur Verfügung.

2.2 Lottoschein speichern

Durch Eingabe des Dateinamen werden Ihre Lottoscheine unter diesem Namen auf Diskette gesichert. Sie stehen aber weiter im Programm zur Verfügung.

2.3 Lottoschein eingeben

Als erstes geben Sie ein, wieviel Spielscheine sie anfertigen wollen (z.b. 13). Maximal sind 45 Spielscheine möglich. Pro Spielschein sind maximal 10 Tips möglich. Nachdem Sie diese Fragen für jeden Spielschein beantwortet haben, erscheint die Frage 'Per Zufall j/n'.

Möchten Sie die Spielscheine selber ausfüllen, so geben Sie 'n' ein, andernfalls übernimmt diese Aufgabe der Computer für Sie, jedoch füllt der Computer die Scheine mit zufällig gewählten Zahlen aus.

Haben Sie vorhin 'n' eingegeben, so ist der nachfolgene Text für Sie wichtig! Auf dem Bildschirm erscheint folgenes:(gekürzt)

 1  2  3  4  5  6  7
 8  9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31 32 33 34 35
36 37 38 39 40 41 42
43 44 45 46 47 48 49

Das Kreuz auf dem Spielschein ist eine Art Kursor. Sie bewegen sich mit den Kursortasten. Möchten Sie z.b auf der 8 ein Kreuz haben, so gehen Sie auf die 8 und betaetigen Sie die Enter-Taste. Nun verschwindet Ihr Kreuz. Gehen Sie nun von der 8 herunter und Sie sehen auf dieser Zahl Ihr Kreuz.

Pro Tip muß man 6 Kreuze verteilen. Haben Sie auf einer falschen Zahl Ihr Kreuz gesetzt, so gehen Sie abermals da drauf und betätigen Sie SPACE.

2.4 Lottoscheine vergleichen

Haben Sie Ihre Lottoscheine entweder geladen oder eingegeben oder per Zufall ermittelt, so gelangen Sie in folgenes Untermenu:

1. Lottozahlen laden
2. Lottozahlen speichern
3. Lottozahlen eingeben
4. Zahlen vergleichen
5. Hauptmenu

2.4.1 Lottozahlen laden

siehe 2.1

2.4.2 Lottozahlen speichern

siehe 2.2

2.4.3 Lottozahlen eingeben

Das entsprechende Grafikbild erscheint auf dem Bildschirm. Sie müssen nun 6 Zahlen in die Vierecke eingeben. Der runde Kreis signalisiert eine Zusatzzahl. Diese darf mit den anderen 6 nicht übereinstimmen. Nachdem Sie auch das andere ausgefüllt haben, gelangen Sie wieder in das Untermenu.

2.4.4 Zahlen vergleichen

Sie müssen sich jetzt etwas gedulden. Es erscheint nun die Frage 'Drucken j/n'. Diese ist entsprechend zu beantworten. Auf dem Bildschirm erscheint nun die Auswertung.

2.4.5 Hauptmenu

Zurück zum Punkt 2

2.5 Grafisch darstellen

Ihre Lottoscheine werden nun, wie bei Punkt 2.3 dargestellt (durch Kreuze). Jedoch übernimmt diese Darstellung der Computer, was sehr viel an Zeit spart.

2.6 Programm beenden

Rücksprung zum BASIC-Interpreter. Nun kann man beispielsweise sich das Listing ein wenig näher ansehen.

3 Veränderungen am Programm LOTTO12

Grundsätzlich stehe ich positiv zu Veränderungen. Sie sind ja im Sinne des Fortschrittes !! Jedoch sollte dabei kein verändern des Autors vorgenommen werden!! Man könnte sich jetzt streiten und meinen, daß man mehr als die Hälfte des Programmes geändert hat. Jedoch bleibt bei dem Programm dann immer noch ein "Rest" hängen, das die Idee des ursprünglichen Autors in sich widerspiegelt.

Meine Idee an diesem Programm war ursprüglich, die Zahlen graphisch anzukreuzen, was mir glaube ich gelungen ist. Die erste Version von LOTTO war nur auf das pure Eingeben und Vergleichen aus, was jedoch die Grafik beeinträchtigte und somit keine Chance hat, angesehen zu werden!

4. Schlußwort

In diesem Sinne wünsche ich allen Nutzern und diesen, die es noch werden wollen, viel Spaß mit LOTTO12. Sollten trotz dieser sehr ausführlichen Beschreibung noch Fragen oder Verbesserungsvorschläg auftreten dann nur her damit.

Beschreibung zu SOFT/4

von Mirko Wieblitz

Diese Routine belegt die Speicherplätze 7000-7FFFH. Man kann, die im folgenden aufgeführten Teilroutinen aus Anwenderprogrammen aufrufen.

SCHATTEN

Zeichnet Schatten um gerade aktives Fenster. Schattenfarbe ist schwarz.
?WI ERROR - Schatten nicht darstellbar.

CALL * 7023

 

GROß

Vergrößert gerade aktives Fenster um jeweils 1 Spalte/Zeile.
?WI ERROR - Fenster nicht vergrößerbar.

CALL * 709E

 

KLEIN

Verkleinert gerade aktives Fenster um jeweils 1 Spalte/Zeile. Vor Aufruf Hintergrundfarbe auf BA00H poken.
?WI ERROR - Fenster nicht verkleinerbar.

CALL * 7169

 

RAHMEN

Zeichnet um aktives Fenster einen Rahmen mit weißer Farbe. Rahmen wird im XOR- Mode gezeichnet, daß heißt, er kann mit einem weiteren Aufruf gelöscht werden.
?WI ERROR - Rahmen nicht darstellbar.

CALL * 72A5

 

SPIEGELN

Inhalt des aktiven Fensters wird gespiegelt. KEINE Farben!
?WI ERROR - Zeile 0 nicht spiegelbar.

CALL * 7428

 

SCHATTEN I

Wie oben, jedoch wird direkt auf den Farb-RAM zugegriffen. Farbe wird XOR-verknüft. Analog Rahmen.

CALL * 7538

 

CLS UM FENSTER

Ganzer Bildschirm, außer aktives Fenster + Inhalt werden gelöscht. Vor Aufruf auf BA00H Hintergrundfarbe poken!
?WI ERROR - Fenster zu groß

CALL * 7603

 

TESTEN

Testet, ob in der Zeile/Spalte und der Byteposition sich ein Bildpunkt befindet. Wenn ja, dann Sp.0H = 1 ansonsten 0. Angaben vor Aufruf:
7A00H - Zeile
7A02H - Spalte
7A04H - vertikale Byteposition

CALL * 7739

 

LESEN

Liest das Byte aus Pixelram und schreibt es auf Sp. 0H. Angaben wie oben.

CALL * 775E

 

SCHREIBEN

Schreibt das Byte, daß man vorher auf Sp. 2H schreiben sollte, in den Pixelram. Angaben wie oben.

CALL * 776B

Viel Erfolg beim Experimentieren und beim Programmieren!

BASICODE 2 lebt!!

von Henning Räder

Sensation aus den Niederlanden - Nach einer fast 2-jährigen Odyssee auf der Suche nach einer Save Routine im Basicode-2-Modus bin ich nun dank zweier sympathischer ZX81-User aus Holland fündig geworden.

Nach einer Information von Herrn Leo Moll hat Herr Jack Raets eine Basicode-2 Save Routine für den ZX81 geschrieben. Telefonisch hat mir dies Herr Raets bestätigt. Er hat die Save Routine bereits am ZX81 und am PC erfolgreich getestet.

Damit ergibt sich erstmals die Chance, daß der ZX81 aufschließt und über BASICODE 2 voll kompatibel zu den Computern:

Apple II + IIe, BBC Model A + B, Colour Genie, Commodore 3000, 4000 und 800, C64, PET 2001, VC20, DAI, DRAGON 32, JUNIOR (9k Version), JUNIOR STANDARD mit VDU-Karte, SHARP MZ80A, SHARP MZ80K, ZX SPEKTRUM, TRS80 Modell I + III sowie VIDEOGENIE und vielleicht zum KC 85 wird.

Ich habe mich über diese Chance sehr gefreut und bedanke mich herzlich bei den beiden ZX-Usern aus den Niederlanden.

Modernste Methoden der wissenschaftlichen Datenanalyse

von Henning Räder

Am Ausgangspunkt meines Interesses für statistische Auswertungsmethoden stand das sehr gute ZX81-Programm "Tecstat I" und der Fachartikel "Statistische Auswertung von Meßreihen" von Herrn B. Friedrich aus dem Heft "Happy Computer" SH 1, Seiten 71-79. Nachhaltig beeindruckte mich anschließend das ausgezeichnete Fachbuch von Herrn Prof. Henrion und seinen beiden Söhnen "Beispiele zur Datenanalyse mit BASIC-Programmen", erschienen 1988 im Deutschen Verlag für Wissenschaften, gelesen.

Dort werden vollständige Listings der ZX81-Programme CLASS, VARDIS, HIERAG, EXTRAKT, MULTIREG, HKANLM, MINDIST und CLUPOT einschließlich Bedienungserläuterungen gegeben. Zusätzlich gibt es noch 2 Programmversionen für den KC 85/2 und eine Version für den PC 1715 in TurboPascal.

Die Programme sind vom Feinsten, stellen allerdings an den Anwender schon beträchtliche mathematische Anforderungen, wenn er die ermittelten Ergebnisse auch naturwissenschaftlich richtig interpretieren will. Aus großem Interesse und nicht zuletzt, um mehr über "Varianz- und Diskriminalanalyse", "Klassifizierungsmethoden", "Display-Methoden" und "Clusteranalysen" zu erfahren, habe ich mich direkt an Prof. Henrion vom Institut für angewandte Analytik und Umweltchemie gewandt.

Ich habe in diesem Zusammenhang natürlich auch über einige Neuentwicklungen am ZX81 durch das "ZX-Team" informiert. Prof. Henrion war sehr interessiert und freundlich; er berichtete, daß er Ende der 80er Jahre verstärkt mit dem ZX81, dem KC 85/2, dem PC 1715, später mit dem Spectrum QL und natürlich dann mit dem PC weitergeforscht hat.

Im Ergebnis seiner Arbeiten ist 1990 das Fachbuch "Chemometrische Strategien in der Analytik" ebenfalls im Deutschen Verlag für Grundstoffindustrie in Leipzig erschienen. Zur Zeit beginne ich dieses sehr gute und anspruchsvolle Buch, einschließlich der Programmlistings, zu studieren. Die Programme sind in KC 85/2-BASIC.

Das Neuste, Modernste in dieser Buchreihe stellt das von Prof. Henrion und seinem Sohn Dr. R. Henrion 1994 im Springer-Verlag Berlin erschienene Buch "Multivariante Datenanalyse" einschließlich Diskette mit Computerprogrammen in TurboPascal 5.0 dar.

Was an den genannten Büchern und Programmen nicht nur für den Chemiker interessant ist, ist die Tatsache, daß diese auch für Biologen, Physiker, Mediziner, Mathematiker und nicht zuletzt Kriminologen zur Aufarbeitung Ihrer anfallenden Daten phantastische Lösungsmöglichkeiten bieten.

Für uns als ZX-Team ist es immer wieder erstaunlich, in wie konzentrierter Form unser ZX81 im naturwissenschaftlichen Einsatz zu Ehren gekommen ist. Wir bedanken uns bei Herrn Prof. Henrion und seinen Söhnen und wünschen Ihnen weiterhin persönlich und beruflich alles erdenklich Gute.

Sind mehr als 128 Dateien auf einer Diskette möglich?

von Wolfram Schütze

Aus gutem Grund umfassen die Bildersammlungen auf den Beilagendisketten nie mehr als 128 Kunstwerke. Sonst käme nämlich beim Entpacken auf eine neue Diskette die Meldung "Diskette voll" (natürlich auf englisch). Voll ist dabei aber lediglich die Directory, für die 2 Blöcke (zu je 2048 Bytes) reserviert sind, die maximal 128 Eintragungen aufnehmen können. Da die PIC-, PIF-, PIP-Dateien häufig recht kurz sind, bleibt ein beachtlicher Teil der Disketten-Speicherkapazität ungenutzt und ist nicht erreichbar.

Mich reizte es, hier einmal eine Veränderung, d. h. eine Vergrößerung des Directory-Bereiches auszuprobieren. Mit einem vorgegebenen Installationsprogramm wie z. B. MSYSG geht das natürlich nicht. Man muß in das Betriebssystem (Spuren 0 und 1) einsteigen und dort die Diskettenparameterblöcke (DPB) suchen. Wenn man das "Handbuch für den Progrmmierer" besitzt, findet man schließlich die für die Directory-Definition maßgebenden Bytes, die man nun verändern kann. (Ich wurde dabei unwillkürlich an die immer aktueller werdende Genmanipulation erinnert.)

Beim MicroDOS-Betriebssystem ist es zweckmäßig, zunächst das vorgesehene Laufwerk (ich habe H gewählt) mittels MSYSG mit unserem "Normalformat" zu installieren. Dann sind im DPB nur zwei Werte zu ändern (die Anzahl der DIR-Eintragungen und der Belegungsvektor). Im CAOS-Betriebssystem (mit DEP22!) ist H bereits im "Normalformat" installiert und es sind auch nur zwei Bytes und ggf. die Nummer des physischen Laufwerks zu ändern.

Es ist ausreichend, die Directory auf 3 Blöcke, d. h. 192 Eintragungen zu vergrößern. (Prinzipiell wäre natürlich auch mehr möglich.) Eine solche Diskette kann auch auf einem mit "Normalformat" installierten Laufwerk betrieben werden. Das Auflisten der Directory erfolgt dann nur mit 128 Positionen; die weiteren bleiben verborgen. Abspeichern weiterer Dateien wird abgewiesen, wenn schon 128 Eintragungen vorhanden sind; bei weniger als 128 wird der dritte Directory-Block überschrieben.

Auf jeden Fall ein interessantes Experiment, ob man es nutzen will oder nicht! Möglich wäre auch eine Installation im 800 kB-Format (keine Systemspuren!) mit vergrößerter Directory. Dann ist aber die bedingte Kompatibilität mit dem Normalformat nicht mehr gegeben.

Der HP 500C mit PCL-3

von Hendrik Wagenknecht

Dieser Beitrag soll sich vor allem mit der Beschreibung der Grafikmöglichkeiten des HP 500C befassen. Für die Textverarbeitung gibt es nach Ansicht des Autors genügend Literatur. Selbst das mitgelieferte Handbuch enthält ausreichende Informationen. Grundsätzlich ist der Treiber für alle Drucker ab PCL-3 aufwärts (auch für Laserdrucker) verwendbar. Der bisherige Treiber benötigt einen Speicherplatz von ca. 1,5 kByte. Das Quellisting bezieht sich dabei auf EDIPIC 41.

Doch wie fuktioniert eigentlich eine Rastergrafik? Zuerst ist auffallend, daß die Pixel nicht, wie beim Nadeldrucker, untereinander, sondern nebeneinander angeordnet sind (siehe Tabelle 1). Bevor man die Grafikdaten senden kann, braucht der Drucker aber noch einige Angaben. Zuerst wird dem Drucker die Auflösung mitgeteilt. Anschließend sendet man dem Drucker die Pixelbreite des Bildes. Diese kann bei s/w-Grafiken auch entfallen. Bei Farbe ist die Angabe der Breite unbedingt notwendig, da der Drucker den Rest der Zeile sonst schwarz druckt.

Als nächstes gilt es festzulegen, ob s/w oder Farbe gedruckt werden soll. Nun wird festgelegt, ob die Grafik am linken Zeilenanfang oder ab Cusorposition beginnen soll. Diese Einstellung gilt bis zu einer anderen Festlegung. Jetzt kann der Code für die Grafikdaten gesendet werden. Dabei ist darauf zu achten, das die Anzahl der Grafikbytes dezimal im ASCII-Code zu senden ist.

Eine Aufteilung, wie bei Nadeldruckern, in zwei Bytes ist nicht nötig. Bei Farbgrafiken ist die Farbe in Lagen an den Drucker zu senden. Wird dabei die RGB-Tabelle verwendet, so ist die erste Lage der Farbe rot zugeordnet. Nach grün und blau muß noch eine Pixelzeile folgen, da der Drucker sonst nichts zu Papier bringt. Der Inhalt dieser Pixelzeile ist dabei völlig egal. Im Beispiel wird FFH gesendet. Es ist jedoch darauf zu achten, daß die Anzahl der Bytes einer Farblage mit der einer Pixelzeile übereinstimmt.

Nach Abschluß einer Pixelzeile kann gleich eine weitere Pixelzeile folgen. Es ist nicht notwendig, den Cursor neu zu positionieren. Auch der Papiervorschub regelt sich automatisch. Zum Abschluß einer Grafik wird noch Grafik-Off gesendet.

Bei Farbgrafiken kann noch vor Grafik-On die Grafikhelligkeit fesgelegt werden. Soll Folie bedruckt werden, so ist noch eine Versetzung der Grafik nötig. Diese wird ebenfals vor Grafik-On gesendet. Tabelle 2 zeigt noch einmal die Reihenfolge für die Befehle anhand eines KC-Bildes. Sowohl der Grad der Versetzung, als auch die Helligkeit sollten vom Nutzer jederzeit einstellbar sein.

Tabelle 1

o  o  o  o  o  o  o  o
D0 D1 D2 D3 D4 D5 D6 D7

Tabelle 2

Blockanzeige am M011

von Wolfram Schütze

Zuweilen kann es ganz nützlich sein, den jeweils im Adreßbereich 4000H ...8000H aktiven Block des 64k-Moduls M011 angezeigt zu bekommen. Mir geht es so z. B. bei TEMO4.6 (Assembler, bei dem das Quellprogramm in vier Blöcken bzw. Bänken untergebracht werden kann) oder EDIPIC (vier Bilder).

Durch "Anzapfen" der D-Flip-Flops, die vom Steuerbyte eingestellt werden, läßt sich über einen 1-aus-8-Dekoder (internationaler Typ SN 74LS138 oder DDR-Typ DS 8205D) die gewünschte Information gewinnen und mit Leuchtdioden anzeigen. Wenn die Leitungen A, B, E3 wie gezeichnet an die DL 074 angeschlossen sind, entspricht die LED-Anzeige 1-2-3-4 genau der Nummer des im Bereich 4000H... liegenden Blockes gemäß Modulbeschreibung (Steuerbytes 4x-0x-Cx-8x). Wenn man die Leitung A ein Raster nach rechts versetzt, d. h. von Pin 6 auf Pin 5, erhält man LED 1-2-3-4 mit der Steuerbytefolge 0x-4x-8x-Cx.

Als Leuchtdioden sind 3-mm-Typen (Farbe beliebig) zu empfehlen, die in eine "Aufreihung" eingesetzt werden. Diese wird zusammen mit dem Schaltkreis und dem Widerstand auf eine kleine Lochrasterplatte montiert. Durch Bohrungen in der Modul-Frontplatte werden die Leuchtdioden sichtbar gemacht. Eine besondere mechanische Befestigung der Schaltung erübrigt sich, wenn man die Zuführungen für +5V und 0V von der Modul-Leiterplatte mit kurzen, dicken Drähten ausführt. Die Verbindungsleitungen zu den "anzuzapfenden" Schaltkreisen werden mit dünnen Schaltdrähten oder -litzen realisiert.

Späte Gedanken zum Anschluß eines 1541-Floppys am KC

von Ralf Däubner

Durch eine Anzi im CF, ich habe BoulderDash kostenlos angeboten, bekam ich Post von einem C64-Freak. Der schickte mir eine 5,25" Disk, welche meine Kiste nicht mochte. So organisierte ich mir so|n C64/1 mit 1541/2. Wahnsinn!!! Nur der Standardkassettenlader des KC ist langsamer. Und das dauert und dauert, es will kein Ende nehmen. Also wenn, dann so und nicht anders.

Damit möchte ich sagen, dann muß das Floppy auch modifiziert werden, damit es schneller wird und das MFM-Format lesen kann. Das 1570 und das 1571 wären da günstiger und das 1581 besser, da sie schneller und CP/M-fähig sind.

Laufwerk	Bemerkung
1541	einseitig, langsam, kein MFM-Format
1570	einseitig, schnell, MFM-Format
1581	zweiseitig, schnell, 3,5", 790k
1571	zweiseitig, schnell, 5,25", 360k

Leider ist die 1571 inkompatibel zu unserem Format (8 * 1024 * 2 *23? = 360k). Die C64-Disketten haben eh meist eine geringe Speicherkapazität.

Im Funkamateur 6/92 auf Seite 319 bis 321 wurde der Anschluß der Floppy 1541/2 an einen Zetty (Z 1013) beschrieben. Verfügbar sind nur 170 kB pro Seite. Die Software ist nur auf die Belange des Zettys zugeschnitten. Wenn geeignete Commodore-Floppys genutzt werden können, wäre ein Datenaustausch mit CP/M-Kisten möglich.

Die 1541-Story kann man als günstige Alternative zum D004 betrachten, zumindest für KC-Freaks ohne Floppy, da man schneller an so eines rankommt als an ein originales D004-Drive. Ich habe jetzt einen Z80-Freak aufgetrieben, dem ich die Story erzählte.

Er hat mindestens drei Z 1013. Einer davon hat ein Floppy (teac-clone 1.6). Er ist jetzt durch Zufall an einen KC 85/3 rangekommen. Vielleicht hat er eine einfachere Lösung zum Anschluß geeigneter Floppys an unseren Kisten. Inzwischen ist das Hexlisting eingetippt und wartet auf die weitere Verwendung.

Technische Daten 1541:
totale Speicherkapazität:	174848 Bytes pro Diskette
sequentielle Files:	168656 Bytes pro Diskette
relative Files:	167132 Bytes pro Diskette
Records pro File:	65535
Einträge in die Directory:	144 pro Diskette
Sektoren pro Spur:	17 - 21
Bytes pro Sektor:	256
Spuren:	35
Blöcke:	683 (644 Blöcke frei)

 

Service-Information Nr. 3/89

vom MPM-Kundendienst, 10.07.89

Beim Einsatz von zwei D002 bzw. eines D002 in Verbindung mit einem D004 kommt es zu Laufzeitproblemen der Modulprioritätskette bzw. des MREQ-Signals.

Es sind folgende Änderungen im zweiten D002 bzw. im D004 vorzunehmen:

1. Auftrennen der Verbindung von D02 (DL541) Pin 14 zu XV10 (siehe Bestückungsplan) kurz hinter Pin 14 von D02 (MREQ).
2. In das Rasterfeld neben D12 (DL051) einen IS DL004 einsetzen und mit der Stromversorgung verbinden (Pin 7 an Masse, Pin 14 an 5P).
3. Pin 14 von D02 durch eine Drahtbrücke mit Pin 13 des eingesetzten DL004 verbinden.
4. Pin 12 des eingesetzten DL004 mit Pin 11 verbinden und von Pin 11 einen Kondensator 680 pF nach Masse legen.
5. Pin 10 des eingesetzten DL004 durch eine Drahtbrücke mit XV10 12B verbinden.

Mit XV10 ist der Steckverbinder aus dem Bestückungsplan gemeint. Durch die vorgenommene Änderung wird das MREQ-Signal verzögert. In einer Gerätekonfiguration mit zweimal D002 oder D002 und D004 darf nur das Gerät mit der höchsten Adresse umgerüstet werden und dieses Gerät ist stets als letztes Gerät auf dem Turm zu betreiben.

Im Schaltbild KC85-Bustreiber/Treiber 1 (4484.895-00001) bzw. KC-Floppy Disk sind die Steckverbinder-Bezeichnungen XV10/XV20 zu tauschen. Entsprechendes gilt für das Schaltbild KC85-Bustreiber/Treiber 2 (4484.895-00001) mit dem Steckverbinder XV11/XV21.

Die Kosten einschließlich Material in Höhe von 18,24 M (Serviceeinr.: Handwerker und PGHen) bzw. 30,50 M (Serviceeinr.: VEB) sind an den VEB Mikroelektronik "Wilhelm Pieck" Mühlhausen abzurechnen.

VEB Mikroelektronik "Wilhelm Pieck" Mühlhausen
- Kundendienst -

Es ist "SHOWTIME" - die Zweite

von Ralf Kästner

Wie versprochen, enthält die Beilagediskette der heutigen Ausgabe die neuen Shows vom diesjährigen Treffen. Diesmal setzen wir noch etwas oben drauf - zwei der Shows laufen komplett im HIRES-Modus.

Damit alle Nichtbesitzer von "UNIPIC" die Möglichkeit zum Abspielen dieser beiden Shows haben, gibt es mit dieser Ausgabe das Update von "DIASHOW 1.0", jetzt in der Version 1.1. Neben der Herstellung der Kompatibilität zu "UNIPIC" haben darüber hinaus alle Nutzer bzw. Nachbauer der RAM8-Erweiterung bis auf 2 MB jetzt (hoffentlich - noch nicht getestet!) die Möglichkeit, diese Ressourcen auch zu nutzen. Die beiden anderen Shows laufen im Lores-Modus und setzen ein gut ausgebautes System mit etwa 1 MB RAM voraus. Alle Bilder sind aufsteigend durchnumeriert.

Diesmal geht es hauptsächlich um Echtzeitanimationen, wobei die Grenzen des KC hier relativ schnell erreicht sind, durch die Verkleinerung des laufenden Fensters und die optische Aufpeppung der "Umgebung" kann man etwas tricksen, so daß das nicht immer sofort erkennbar sein muß. Es ist immer wieder erstaunlich, was visuell erreichbar ist, auch wenn einem die arme CPU leid tut, hier muß sie echte Schwerstarbeit im KC verrichten.

Wie gehabt, nachfolgend eine ganz kurze Beschreibung der Shows, sie wurden wieder mit PMARC gepackt und sind vorher deshalb auf eine KC-Diskette zu entpacken.

ROBOFROG.DSH

Das ist die Erfurter Eröffnungsshow, sie lief zwar nicht zuerst, die Überschrift soll aber auch später mal an das Treffen erinnern. Es werden original 35 Bilder (nur LORES) benötigt, man kann aber auch nur jedes zweite oder dritte Bild laden. Ein Roboterfrosch oder Froschroboter springt gemütlich in Richtung Erfurt, mit 35 Bewegungsphasen hat man nahezu fließende Bewegungen und damit eine sehr ansprechende Show.

SNEEZE.DSH

Diese Show besteht aus 31 Einzelbildern. Sie enthält ebenfalls nur LORES-Bilder und stellt ein "niesendes" Gesicht dar. Durch die vielen Einzelphasen entsteht wieder ein geschlossener und gleichmäßiger Bewegungsablauf.

WANKEL.DSH

Diese Show benötigt 12 Bilder und stellt das Arbeitsprinzip des Wankelmotors dar. Sie läuft komplett im Hires-Mode ab, so daß auch mal etwas Farbe ins Spiel kommt.

MOON.DSH

Jetzt wird gemorpht, diesmal aber richtig. Aus einem Männergesicht wird ein Werwolf - aber erst nach 24.00 Uhr! Mit 13 Bildern (alle HIRES) dürfte sie auch von vielen Usern geladen werden können. Da man eine Show hin und her laufen lassen kann, spart man gegenüber dem Original auf dem PC die Hälfte an notwendigen Bildern ein.

Das war es dann auch erst mal wieder für heute. Mein persönlicher Eindruck war, daß alle 4 Shows sehr gut angekommen sind. Sicher wird sich niemand hinsetzen und solche Sachen per Hand zeichnen. Wie bereits mehrfach gesagt, eignet sich der PC an dieser Stelle vorzüglich als Rechenknecht. Da ich auf dieser Strecke mittlereile eine ganze Menge an Erfahrungen sammeln konnte, nachfolgend einige Tips zur Herstellung solcher Shows.

Das Ausgangsmaterial waren diesmal FLI-Animationen, welche auf CD reichlich unters Volk gebracht werden. Besonders vorteilhaft am FLI-Format - die Bildgröße der Animation ist mit 320*200 Pixel festgelegt und nicht veränderbar, das entspricht schon fast dem KC, nur die Farben muß man noch herunterrechnen. Im Artikel zur Konvertierung von PCX-Dateien in dieser Ausgabe gebe ich zur Umwandlung der Einzelbilder noch ein paar Hinweise.

In einer FLI-Datei sind nun mehr oder weniger viele Bilder zu einer Animationssequenz in einer Datei zusammengefaßt, welche man mittels geeigneter Programme erst in Einzelbilder extrahieren muß. Das hatte ich zuerst mit GRAPHIC WORKSHOP for WINDOWS Version 1.1r gemacht, ist etwas mühselig bei sehr vielen Bildern, da man immer nur ein Bild anwählen und herausziehen kann.

Komfortabler geht es mit COREL MOVE aus dem COREL DRAW 5.0-Paket, dort kann man eine komplette FLI-Datei importieren und in einem Arbeitsgang in die Einzelbilder (automatische Nummerierung) exportieren, das ist zwar sicher nicht im Sinne des Erfinders aber für den KC eine Top-Funktion.

Anschließend bearbeitet man die einzelnen Bilder für den KC auf dem PC vor (Farbreduktion) und bringt sie mittels 4PCX090.KCC (jetzt 4PCX092.KCC!) in das UNIPIC-Format. Dort erfolgt das Feintuning und fertig ist die Show.

Leider hatte ich dann vor dem Treffen keine Zeit mehr, sonst hätte ich noch mehr gemacht, aufgeschoben ist aber nicht aufgehoben. Nach der dritten Show war es dann bereits Routine, für die 4 Beispiele habe ich knapp 2 Wochen gebraucht.

Ich wünsche wie immer viel Spaß beim Ausprobieren.

Update "DIASHOW 1.1"

von Ralf Kästner

Nachdem "UNIPIC 1.0" fertiggestellt war, hatte ich eigentlich nicht mehr die Absicht am Vorprodukt "DIASHOW 1.0" etwas weiterzuentwickeln. Als ich beim Packen der Shows zum diesjährigen Treffen war, dachte ich wieder an das leidige Problem mit der Inkompatibilität der Dateiformate beider Programme. Da es mittlerweile sehr viele Grafiken im KC-Bildformat mit den PIP/PIF- und HIP/HIF-Dateien gibt, wäre es unsinnig, dort noch irgendetwas zu ändern. Es war also naheliegend die notwendigen Anpassungen vorzunehmen, incl. Beschreibung hatte ich das in etwa 10 Tagen auch geschafft, da ein Großteil der Quellen bereits zur Verfügung standen. Ich kann also heute allen KC 85/4-Usern das neue "DIASHOW 1.1" als Freeware zur Verfügung stellen.

Die Version 1.1 ist vor allem als Ergänzung zum Programm "UNIPIC" gedacht, man kann damit alle dort erzeugten Bilder und Shows anschauen bzw. abspielen. Für alle, die sich "UNIPIC" noch nicht zugelegt haben, besteht damit die Möglichkeit fertige Produkte ohne Einschränkungen zu nutzen.

Alle Dateitypen für Bilder und Shows sind jetzt in der neuen Version voll kompatibel zu "UNIPIC 1.0", so daß man Dateien beider Programme problemlos laden kann. Die in "DIASHOW 1.0" eingeführten HIP/HIF-Dateien für die hochauflösende Grafik des /4 werden jetzt beim Abspeichern/Laden ebenfalls komprimiert/dekomprimiert.

Das Programm enthält bereits einige Neuheiten bei der RAM-Verwaltung unter CAOS, wie gehabt, wird die Bilder-RAM-Bank auf Adresse 08000H zusammengefaßt. Es gab aber spezielle Wünsche nach einer Möglichkeit, die Nutzung bestimmter RAM-Bereiche für das Programm zu sperren, so daß nicht automatisch der gesamte zur Verfügung stehende interne und externe RAM in Beschlag genommen wird (s. Artikel in dieser Ausgabe). Für alle "Normalverbraucher" bleibt aber alles beim Alten, wenn man "DIASHOW" unmittelbar nach dem Einschalten des KC startet, wird der zur Verfügung stehende RAM erkannt und als Bildspeicher initialisiert.

Im Programm kommen bereits Programmteile aus "UNIPIC 2.0" zum Einsatz. Der RAM8 wird durch programmeigene Routinen getestet und erkennt nun auch Erweiterungen lt. KC-News 4/95:

Moduladresse 03 - 64 kB, 256 kB, 512 kB, 768 kB oder 1 MB
Moduladresse 06 - 256 kB, 512 kB, 768 kB oder 1 MB

Die Erkennung größer 256 kB ist zwar noch nicht getestet, müßte aber funktionieren. Ich hoffe hier auf positive Rückmeldungen durch die User, welche den RAM8 bereits auf mehr als 256 kB ausgebaut haben!

Wie gehabt, kann man im VIEW PICTURE Betrieb über die installierte Hardcopyroutine des Betriebssystems drucken. Dazu wurde der Joysticktreiber für das M008 den Erfordernissen nach Ausbau zum M021 angepaßt (lt. KC-News 1/95). Bei Start von "DIASHOW" wird es auf kombinierte Druckausgabe mit Joystickbetrieb initialisiert. Außer den RAM-Modulen, welche "DIASHOW" verwaltet und schaltet, werden alle anderen Modultypen nicht in ihrem Zustand beeinflußt, so daß jeder eigene Druckroutinen nutzen kann.

In der Version 1.1 werden nun auch DEP-Versionen ab 2.0 erkannt, wodurch alle Laufwerke und Userbereiche genutzt werden können. In Hinsicht auf den Betrieb einer Festplatte unter CAOS über DEP gab es auch Änderungen bei der Behandlung des Directories. Zunächst liest das Programm bis zu 1489 Einträge (entspricht 16 kB Speicherbedarf) vom eingestellten Laufwerk/Userbereich ein und sortiert daraus bis zu 256 passende Dateibezeichnungen entsprechend dem eingestellten Directorytyp heraus, welche intern maximal verwaltet werden können, PIP/PIF- bzw. HIP/HIF-Bilder benötigen dabei nur einen Platz. Damit dürfte man erst mal den Großteil der Anwendungsfälle abdecken.

Der Show-Generator wurde auf die drei verschiedenen Laufrichtungen vorwärts, rückwärts und alternierend erweitert. Der AUTO-Betrieb entspricht jetzt auch "UNIPIC 1.0", d.h. nach >STOP< schalten die Cursortasten ins nächste Bild, nach >ET< geht es an der Stelle weiter, wo man gerade steht.

Weiterhin gibt es eine wichtige Änderung beim Laden von Bildern oder Shows, wird bei den PIP-Bildern keine Farbdatei gefunden, löscht das Ladeprogramm selbständig den Color-IRM sw/wß, so daß man die Bildspeicher vor dem Laden nicht mehr per Hand löschen muß.

Durch die Erweiterungen ist das Programm natürlich auch etwas größer geworden, der Speicherbereich von 00200H bis 04000H wird jetzt vollständig benötigt, 04000H bis 06800H dient als Pufferbereich für die Bildebenen, 06800H bis 08000H wird benötigt, wenn PIC-Dateien mit Farben (vom KC 85/2,3) geladen werden, FRC-Bilder geladen oder gespeichert werden oder Directories mit mehr als 930 Einträgen gelesen werden müssen. Der Bereich von 0BA00H bis 0C000H ist frei, dort stehen im Normalfall SERVICE.KCC oder DIENST.KCC und dort ist auch der sicherste Platz für eigene Hardcopyroutinen.

Das war's, viel Spaß beim Ausprobieren mit den Show's der heutigen Beilagediskette wünscht *SUSOWA*

TRANSFER 1.91 - Der dritte Versuch

von Mario Leubner

Viele Anfragen gab es in letzter Zeit zur Lesbarkeit von 360K MS-DOS Disketten. Erstens war es bisher nicht möglich, das 360K-Format mit der Organisation 9 * 512 * 40 * 2 am KC85 einzustellen, zweitens arbeitete TRANSFER 1.90 ausschließlich mit 80-Spur-Formaten.

Mit der Version 1.91 will ich versuchen, auch die noch im Umlauf befindlichen MS-DOS Disketten auf dem KC85 zugänglich zu machen. Einen Hinweis möchte ich aber an dieser Stelle unbedingt nochmal geben:

Obwohl das Lesen von 40-Spur-Disketten mit 80-Spur-Laufwerken keine Probleme bereitet (Doppelspurschritte), dürfte es in umgekehrter Richtung nicht funktionieren. Also die 40-Spur-Disketten nur Lesen und dann beiseite legen, jedenfalls nicht wieder in 40-Spur-Laufwerke einlegen, wenn einmal mit 80-Spur-Laufwerken darauf geschrieben wurde!

Benötigt wird zum Lesen (Schreiben) der 360K-Disketten zuerst mal eine Möglichkeit, am KC das 360K-Format einzustellen. MSYSG.COM bietet dieses Diskettenformat ja nicht an. Unter diesem Gesichtspunkt entstanden fast zeitgleich die neuen Versionen von MODF.COM und FORMAT.COM. Beide Programme sind jetzt systemunabhängig programmiert worden. Das heißt, es wird nur ein Systemtest auf das Vorhandensein eines KC-Systems vorgenommen. Unabhängig ob MicroDOS 2.6 oder das neue CP/M 2.2 mit ZSDOS oder einem anderen BDOS-Ersatz läuft, und unabhängig von den Arbeitszellen des BIOS (also mit jeder Laufwerkzuordnung) funktionieren beide Programme gleichermaßen.

Ich habe MODF.COM dahingehend weiterentwickelt, daß alle möglichen physischen Formate mit jedem Diskettentyp kombiniert werden können. Die logische Organisation der neuen Formate (Blockgröße, Anzahl der Verzeichniseintragungen) habe ich dabei mit sinnvollen Werten belegt und übernehme keine Garantie, ob solche Formate in CP/M-Umgebungen bereits existieren bzw. korrekt sind.

MODF ändert dabei nur den DPB im BIOS, also nicht permanent in den Systemspuren der Diskette! Nach jedem Bootvorgang von Diskette sind demnach die auf der Diskette in den Systemspuren gespeicherten Einstellungen aktiv. Das alte MODF.COM (siehe Archiv SYS-DAT.PMA der Beilagendiskette der KC/News 4/95) bitte durch die neuere Version ersetzen, da sich dies besser mit den unterschiedlichen Systemen (MicroDOS 2.6 und ZSDOS 1.0) verträgt.

Das neue FORMAT.COM ist ebenfalls auf alle möglichen physischen Diskettenformate erweitert worden. Bei der Auswahl des Diskettenformates wird das Format des Laufwerkes vorgegeben, das zur Formatierung benutzt werden soll. Es kann jedoch zu jedem mit dem Laufwerk nutzbaren Format gewechselt werden.

TRANSFER.COM wurde in der Version 1.91 außer bei der Unterstützung des 360K-Formates auch noch etwas verändert:

• So wird beim Start das aktuelle Laufwerk automatisch zum CP/M-Laufwerk, kann aber aus dem Menü heraus neu gewählt und auch während der Arbeit mit TRANSFER gewechselt werden. Zusätzlich dazu der Userbereich.
• Akzeptiert werden jetzt CP/M-Versionen 2.2 bis 2.x (kein CP/M3).
• Bei der Anzeige des Bootsektors wird der MEDIA-Descriptor jetzt hexadezimal angezeigt, wie es eigentlich in der Literatur auch üblich ist. Zusätzlich berechne ich noch die Gesamtkapazität der Diskette, was für Kontrollzwecke sicher auch hilfreich ist.
• In der Directoryanzeige der MS-DOS Diskette habe ich den Dateiattributen Namen gegeben. Es kann sich ja keiner merken, welches der Bits für welche Funktion steht. Ein 'S' für Systemdatei oder ein 'A' für das Archivflag ist bedeutend aussagekräftiger.
• Speziell für die Nutzung auf dem KC85 wird jetzt beim Start von TRANSFER auf den amerikanischen Zeichensatz umgeschalten und bei der Rückkehr der alte Zeichensatz regeneriert.

Neben den in TRANS2.TXT angesprochenen Erweiterungen würde ich mir für das Zusammenspiel mit CP/M 2.2 und DateStamper (Datumseinträge unter CP/M 2.2) noch wünschen, daß das CP/M-Directory ähnlich dem MS-DOS Directory mit Attributen, Datum und Dateigröße erweitert wird. Außerdem sollten beim Transfer die Datumseinträge mit konvertiert werden.

Da dies jedoch auf die Schnelle nicht zu realisieren war, stelle ich meine Erweiterungen einschließlich der geänderten Quelltexte mit dem heutigen Stand zur Verfügung.

Supercalc und dBASEII auf dem KC 85

von Hans-Rudolf Stoeßer

Für alle die sich nicht nur darüber freuen, was sich durch schöpferische Arbeit an Hardware, Betriebssystem und Software aus dem KC 85 herausholen läßt, ergibt sich die Frage für welche ganz profanen alltäglichen Arbeiten der KC außerdem noch brauchbar ist. Dabei denkt man sicherlich sofort an die Textverarbeitung, die wohl jeder nutzt. Aber wer arbeitet regelmäßig mit dBASEII oder sogar mit SC? Dabei ist die Ausstattung mit der sogenannten Unisoftware durchaus geeignet alle Rechnerarbeiten für einen kleinen Handwerks- oder Industriebetrieb und erst recht für die im privaten Bereich anfallenden Arbeiten zufriedenstellend zu erledigen.

Zur Unisoftware gehört mindestens:
(für KC geeignet)

• ein Textverarbeitungssystem
  WordStar oder TPKC
• ein Kalkulationsprogramm
  Supercalc oder KP
• ein relationales Datenbanksystem
  dBASEII oder Redabas

darüberhinaus empfiehlt sich:

• eine Programmiersprache
  Turbopascal
• ein Diskettenmanipulationsprogramm
  Power oder Dienst

Schwerpunkt der weiteren Ausführungen sollen dBASEII und SC sein. Allerdings wird das keine vollständige Einführung in dBASEII und Supercalc sein. Vielmehr sollen die, die diese Komponenten der Unisoftware noch nicht nutzen angeregt werden, sich damit zu beschäftigen. Weiterhin sollen Tips und Hinweise denen helfen, die mit dBASEII irgendwann mal Schwierigkeiten hatten oder noch haben. Diese Hinweise resultieren u. a. aus eigenen Mißerfolgen die vor allem darauf zurückzuführen sind, daß die Literatur über dBASEII entweder lückenhaft ist oder wichtige Angaben an Stellen enthält wo man sie nicht sucht. Der Beitrag wird mit einer Kurzbeschreibung von Supercalc abgeschlossen.

Zuerst aber sollen die folgenden Komponenten kurz beschrieben werden:

Textverarbeitung:

WS und TPKC sind praktisch identisch. Sie sind für alle Schreibarbeiten einschließlich Serienbriefen einsetzbar. Die für Mailmerge (Kombodruck) erforderlichen Variablenlisten können durch dBASEII mit geringem Aufwand zur Verfügung gestellt werden. WS/TPKC kann auch als Editor für Turbopascal und dBASEII verwendet werden. Damit ist der Komfort größer als bei den internen Editoren.

 

Programmiersprache:

Für Aufgaben, die nicht mit dBASEII bearbeitet werden können oder sollen empfiehlt sich Turbopascal. Wegen der Vielzahl der Dialekte ist Basic unzweckmäßig. Compilierte Turbopascalprogramme können (z. B. für laufzeitkritische Programmteile) in Redabas- oder dBASEII-Programme höherer Version eingebunden werden. Zum Programmieren ist der eigene Editor oder WS/TPKC nutzbar.

 

Diskettenmanipulationsprogramm:

Das Programm Power/Dienst ist gewissermaßen eine Betriebssystemergänzung.

1. Datenbanksystem dBASEII

1.1 Allgemeines

Bei der Bearbeitung von Datenbanken mit den üblichen Programmiersprachen entstehen starre Verknüpfungen. Alle Änderungen in Verknüpfung von Daten in Inhalt und Aufbau der Datei erfordern umfangreiche Programmänderungen. Das gleiche gilt für Programme die auf die Datenbanken zurückgreifen. Hierarchische Datenbanksysteme vermeiden einen Teil der Mängel, haben aber noch Abhängigkeiten und Verzeigerungen zwischen den verschiedenen Dateistrukturen. Dadurch sind Änderungen und Anpassungen schwierig.

In relationalen Datenbanksystemen gibt es praktisch keine fest bestehenden Abhängigkeiten und Beziehungen zwischen den Datenbanken. Es kann praktisch jede Relation (Beziehung) durch Einzelbefehle flüchtig hergestellt werden. Wird sie nicht mehr benötigt zerfällt sie wieder so, daß sie dem Aufbau einer anderen Beziehung nicht mehr im Wege steht. dBASEII erfüllt diese Anforderungen, ist also ein relationales Datenbanksystem und hat darüberhinaus eine Menge mächtiger Befehle, die weiteren Komfort in die Arbeit mit Datenbanken bringen.

Es ist für die Verwaltung riesiger Datenmengen in Tabellen hervorragend geeignet. Es kann wegen der mächtigen Befehle weitgehend direkt im Anwenderbereich (im Dialog) genutzt werden. Programme werden recht einfach und übersichtlich. Es können auch Aufgaben programmiert werden die nichts mit Datenbanken zu tun haben. Datenbanken können für die Bearbeitung in Programmiersprachen auch im Systemdatenformat (sdf) bereitgestellt werden.

Die Robotronversion Redabas ist weitgehend identisch, gestattet aber wie die leider nicht sehr weitverbreitete letzte Version von dBASEII das Laden und Starten von Maschinenprogrammen und in einigen Versionen den Hardwarezugriff. Der Editor verkraftet je nach Version nur 2000 oder 4000 Zeichen und hat wenig Komfort. Daher sollte für lange Programme WS/TPKC genutzt werden.dBASEII arbeitet interpretativ (Compiler erst ab dBASE4).

dBASEII ist besonders in Verbindung mit WS-Mailmerge geeignet auf einfache Weise Mahnungen, Bestellungen, Einladungen, Gratulationen usw. herzustellen. dBASEII sucht die richtigen Adressen, Daten und Werte heraus und bereitet sie für Serienbriefe auf. Mit dBASEII lassen sich Lagerhaltung mit Bestandskontrolle und Bestellauslösung auf der Grundlage einer Bestands- und einer Lieferantendatei organisieren.

Anhand von Mitgliederlisten mit Adressen, Telefonnr. und Geburtstag erstellt der KC Einladungen und Gratulationen. Es sind Dateien für planmäßige Instandhaltung und Ersatzteilbestellung, Kundendateien mit Termin- und Zahlungskontrolle, Dateien für Lohnberechnung, Preisberechnung, Rechnungslegung und Bilanzen möglich. Zu den Serienbriefen können direkt von dBaseII Postetiketten auf Leporellolabels gedruckt werden (Etikettendruckprogramm).

Für ein mittelgroßes Einkaufszentrum mit ca. 30000 Artikeln erlaubt dBASEII eine Warendatei für alle Artikel zu führen (maximal ca. 60000 Artikel, siehe auch dBASEII-Leistungsparameter). Wenn jeder Satz nur 100 byte belegt (1000 möglich) wird aber für eine Datei bereits ein Massenspeicher von 3 Mbyte benötigt. Das heißt, lange bevor wir an die Grenzen von dBASEII stoßen sind wir an der Grenze der KC-Hardware angelangt.

1.2 dBASEII-Leistungsparameter

max. Anzahl von Dateien	beliebig
Anzahl der während der Verarbeitung eröffneten Dateien	max. 16
Sätze pro Datei	max. 65535
Zeichen pro Satz	max. 1024
Feldvariable pro Satz	max. 32
Zeichen pro Feldvariable	max. 254
Darstellungstyp	alphanumerisch, numerisch, logisch
Größte Zahl	ca.+/-1.8*10+63
Kleinste Zahl	ca.+/-1.0*10-63
Numerische Genauigkeit	10 Stellen
Zeichenkettenlänge	max. 254 Zeichen
Zeilenlänge eines Befehls	max. 254 Zeichen
Länge einer Kommandozeile im Programm (incl.0D)	max. 75 Zeichen *
"Report"-Listenkopflänge	max. 254 Zeichen
"Report"-Spalten pro Liste	max. 24
Indexschlüssellänge (incl.0D)	max. 100 Zeichen
Anzahl Speichervariablen	max. 64
Anzahl Ausdrücke im SUM-Befehl	max. 5
Anzahl pending GET's	max. 64 **
Länge einer Programmdatei	unbegrenzt ***

* - Befehle über 75 Zeichen auf mehrere Zeilen aufteilen. (über 75 Zeichen auf !unsichtbare! Leerzeichen achten)

** - schwebende Eingaben. Unter Programmkontrolle eingegebene aber noch nicht mit "read" eingelesene Variablenwerte

*** - nur wenn mit WS/TPKC bearbeitet. Der dBASEII-Editor macht je nach Version ab 2000/4000 Zeichen Schwierigkeiten

1.3 Datenbankbearbeitung

In erster Linie ist dBASEII auf die Bearbeitung von Feldvariablen in Datenbanken und die Verarbeitung von Datenbanken orientiert. Dazu dienen u.a.die im folgenden gezeigten Befehle.

Im Folgenden soll die Mächtigkeit einiger dBASEII-Befehle dargestellt werden. Dabei sollte man sich vorstellen, welcher Aufwand in einer üblichen Programmiersprache getrieben werden müßte.

• beliebige Verknüpfungen - versch.Einzelbefehle
• Direktzugriff auf Satz und Feld - 2 Befehle
• Indexdir. Zugriff - 2 Befehle
• Konvert. dBASEII in sdf - 1 Befehl
• Konvert. sdf in dBASEII - 1 Befehl
• Änderung der Dateistruktur - 1 Befehl
• Sortierung - 1 Befehl
• Anhängen und Einfügen!! von Sätzen - 1 Befehl
• Zusammenfügen zweier Dateien - 1 Befehl
• Erstellen von Reports - 1 Befehl

Die meisten Befehle, nicht nur diese haben Optionen, die den Komfort erheblich erhöhen z. B. für Datensätze, Quellen, Umformung mit und ohne Eingaben, Feldlisten, Masken (mit Joker), Ausdrücke, Begrenzungen, Strukturen, auf- und absteigende Zählung etc. Wenn z. B. ein Handwerksbetrieb eine Kundendatei führt, kann mit folgendem Befehl die Datei erzeugt werden, die WS für einen Serienbrief braucht, der als Mahnung an die Schuldner herausgehen soll.

copy to mahnung for guthaben < 0 sdf delimited with ,

Bei der Abarbeitung dieses Befehls sucht dBASEII bei entsprechender Gestaltung der Kundendatei die Schuldner heraus und stellt Daten über den Namen, die Adresse, die Schuldsumme und die Fälligkeit bereit und kopiert alles in das sdf damit WS es zu einem Serienbrief verarbeiten kann.

1.4 Programmierung

Wenn auch, wie man sieht, recht umfangreiche Rechneraktivitäten im Dialog veranlaßt werden können, gibt es oft auch Gründe die Rechnerarbeit unter Programmkontrolle zu stellen z. B. umfangreiche Operationen, Datensicherheit, Bedienkomfort usw. Dazu stellt dBASEII eine Reihe von Programmkomponenten zur Verfügung. Die wichtigsten dieser dBASEII-Programmierkomponenten sind:

• Die Programmierung ist in verschiedenen Ebenen möglich (Unterprogramme - Prozeduren). Aus Unterprogrammen können wiederum Unterprogramme aufgerufen werden. Die Staffeltiefe ist nur dadurch begrenzt, daß nicht mehr als 16 Dateien gleichzeitig offen sein dürfen.
• Da mit den in den Datenbanken verwalteten Feldvariablen keine Programmabläufe programmiert werden können stellt dBASEII 64 Speichervariable für diesen Zweck bereit.
• do (Programmname)
  Start von dBASE-Programmen
• return
  Programmende - zurück auf höhere Programebene
• fast alle Dialogbefehle im Programm verwendbar
• Der Abschluß der Befehle für Schleife, Verzweigung und mehrzeiligen Text mit end... macht Programme übersichtlich.
• do while -> enddo
  kopfgesteuerte Schleife
• do case (.) -> case (.) -> case (.) -> otherwise (.) -> endcase
  Mehrfachverzeigung
• if -> else -> endif
  Verzweigung
• text -> endtext
  mehrzeiliger Text für Bediener
• mit der Befehlskombination @ zeile/spalte say/get ..... ist eine komfortable formatierte Aus- und Eingabe am Bildschirm und Ausgabe auf dem Drucker möglich. Mit einem Befehl (read) können bis zu 64 in der Bildschirmmaske eingegebene Variable (sowohl Feld- wie Speichervariable) gleichzeitig eingelesen werden. Bei der Eingabe erfolgt eine Prüfung von Datentyp und Länge ohne aufwendige Programmkonstruktionen. Dabei besteht eine Korrekturmöglichkeit für alle eingegebenen Werte vor dem Einlesen.
• Eingabemaske:
  set format to screen
  @ zeile,spalte say (zeile 0...23)
  @ zeile,spalte get (spalte 0..79)
  read
  
  set format to print
  @ zeile,spalte say (zeile0...254) (spalte 0..254)
  je nach Papierformat
  @ zeile,spalte get nicht zulässig!
• &(stringvariable)
  Makroersetzung erlaubt Variable wo nur Konstante erlaubt.
• reset
  Rücksetzung nach Diskettenwechsel
• * / remark / note
  Text
• erase
  Bildschirm löschen
• Systemeinstellungen:
  --- set on /off ---
  set debug / set echo / set step
  set talk set confirm
  set bell set colon
  set console set escape

Um dBASEII optimal zu nutzen muß die Programmierstrategie die Mächtigkeit und die Besonderheiten der Befehle berücksichtigen

1.5 Einige Tips zum Umgang mit dBASEII

Die zu dBASEII/Redabas gehörenden Dateien sind weitgehend kompatibel. Unterschiede bestehen in den Dateinamen zwischen Redabas und dBASEII.

dBASEII	Redabas
dbase.com	redabas.com
dbaseovr.com	rdbasovr.com
dbasemsg.txt	rdbasmsg.txt

Als Minimalausstattung genügen die com-Dateien. Die Hilfedateien (*.txt) sind durch Austauschen des Dateinamens für das jeweils andere System nutzbar. Der Inhalt bleibt natürlich unverändert. Die Hilfedateien sind nur nutzbar, wenn die Diskette nicht schreibgeschützt ist. Sonst erfolgt Meldung eines Diskettenfehlers und dBASEII wird verlassen. Die Hilfedatei selbst kann aber schreibgeschützt sein.

Weiterhin gibt es Unterschiede in den Dateinamenergänzungen der von dBASEII/Redabas erzeugten Dateien. Diese Unterschiede resultieren aus den verschiedenen englischen und deutschen dBASEII-Versionen und nicht aus dem Unterschied zwischen dBASEII und Redabas.

Programmdateien	*.cmd	*.prg	erzeugt mit modify command
Datenbanken	*.dbf	*.dbd	erzeugt mit create
Indexdateien	*.ndx	*.idx	erzeugt mit index
Memorydateien	*.mem	*.var	erzeugt mit save
Reportdateien	*.frm	*.def	erzeugt mit report form
SDF-Dateien	*.txt		erzeugt mit copy .... sdf

Wenn Dateien vom vorliegenden dBASEII/Redabas nicht akzeptiert werden empfiehlt sich die Verträglichkeit dadurch zu prüfen, daß alle Dateiarten wie o.a. erzeugt werden. Nach entsprechender Änderung der Dateinamenergänzung bei den ursprünglich nicht akzeptierten Dateien kann mit ihnen gearbeitet werden.

Für die Benennung von Variablen und Dateien sowie die Eingabe von Befehlen gibt es Regeln gegen die häufig verstoßen wird.

• Wie bei allen Programmiersprachen dürfen für Datei- und Variablennamen keine reservierten Worte verwendet werden. Das sind z. B. T, Y, N, F, Befehle, Optionen, Funktionen. dBASEII kann, muß aber nicht mißverstehen. Die Namen müssen mit Buchstaben beginnen. Danach können Buchstaben, Zahlen und Doppelpunkte folgen. Doppelpunkte müssen jedoch beidseitig von Buchstaben oder Zahlen eingeschlossen sein. Für Dateinamen sollten sie aber trotzdem nicht verwendet werden, weil solche Dateinamen vom Betriebssystem und z. B. von PIP und TPKC nicht akzeptiert werden.
• Variablennamen dürfen maximal 10 Zeichen lang sein
• Dateinamen. Es gilt die CP/M-Konvention. Das heißt 1-8 Zeichen für Dateinamen, 0-3 Zeichen für Ergänzung.
• dBASEII-Befehle sind englischer Klartext. Sie können bis auf 4 Zeichen verkürzt werden. Werden mehr Buchstaben verwendet müssen die weiteren Zeichen richtig geschrieben werden.

An dieser Stelle soll noch auf ein Problem hingewiesen werden das nicht nur für dBASEII gilt, bei dem aber häufig Programmierfehler gemacht werden. Beim Sortieren, Suchen oder Vergleichen mit Hilfe von Zahlen dürfen nur numerische Werte und keine charakter verwendet werden, sonst richtet sich der Rechner bei der Aktion nach der ASCII-Tabelle und nicht nach dem Zahlenwert und dann ist z. B. "11" kleiner als "2".

1.6 dBASEII-Programmbeispiele (mit und ohne Datenbank)

(Die Beispiele wurden bewußt auf den Einsteiger zugeschnitten)

englisch.cmd

Dieses Programm ist ein typisches Datenbankprogramm, das allerdings nur 2 der 32 möglichen Feldvariablen benötigt. Vorhandene Variable sollen dauerhaft erhalten bleiben (Wörterbuch). Die deutschen und englischen Begriffe sind in den 2 Feldern untergebracht. Es können allerdings auch in weiteren Feldern z. B. Erläuterungen untergebracht werden. Bei den wenigen Variablen geht das Suchen schnell.

Es ist jedoch nicht sinnvoll ein ganzes Wörterbuch in einer Datenbank unterzubringen, weil dBASEII auch indiziert hier zu lange sucht. Besser ist es z.B. für jeden Buchstaben und getrennt nach englischen und deutschen Anfangsbuchstaben mehrere Dateien anzulegen. Mit append kann das Wörterbuch jederzeit vervollständigt werden. Ein Programm ist dazu nicht erforderlich.

miete1.cmd

Dieses Programm muß keine Variablen dauerhaft bewahren. Es soll lediglich unter Nutzung von Variablen eine Rechnung durchgeführt und die Ergebnisse geordnet ausgegeben werden. Es wird keine Datenbank angelegt und nur Speichervariable genutzt. Die Werte der Variablen gehen zum Ende des Programms verloren. Das Programm ist bereit für neue Berechnungen.

Die vor Aufnahme der Berechnungen nötige erstmalige Wertzuweisung für die Variablen (Konstanten) wurde unabhängig vom Programm nur einmal vorgenommmen und in einer Memorydatei niedergelegt. Von dort werden die Werte zu Beginn des Programms eingelesen. Das reduziert die Programmschritte.

miete2.cmd

Ein Programm mit gleicher Zielstellung kann natürlich auch unter Nutzung von Feldvariablen in einer Datenbank bearbeitet werden. Die Datenbank kann z. B. nur Hilfsmittel sein und zum Ende des Programms wieder geleert werden. Sie kann aber auch alle Daten aufbewahren.

Im Beispiel wird dieser Weg gewählt. Dazu wird außer der Arbeitsdatenbank eine zweite unveränderliche Datenbank angelegt, aus der der für die Berechnung erforderliche neue Datensatz mit Leerfeldern und Konstanten übernommen wird.

Für weitere (nötige!!) Informationen gibt es folgende Dateien die von Clubmitgliedern zur Verfügung gestellt wurden:

• DBASE.DOK ca.35 Seiten (ähnlich HELP-Datei) auf NEWS-Diskette
• LEKTION.COM Redabas Lernprogramm beim Diskothekar
• DBASE1..DBASE14.DOK dBASEII-Handbuch (428 Seiten ausgedruckt) beim Diskothekar

2. Kurzbeschreibung von Supercalc

SC ist besonders geeignet für Planung, Kalkulation, Logistik, Koordinierung z. B. bei Kontoführung, Transportplanung, Haushaltplanung, Planung und Kalkulation beim Hausbau, Planung von Produktionsprozessen, Kalkulation der Produktionskosten unter Berücksichtigung von Arbeitszeiten / Lohn / Materialkosten / Abschreibungen usw, und vieles andere mehr.

SC greift direkt in den Anwenderbereich durch. Auf einem Arbeitsblatt mit maximal 63 Spalten (A-Z, AA-AZ, BA-BK) und 254 Zeilen (1-254) können strings (mit " vor dem string), numerische Werte und Formeln eingetragen werden. Während die strings für Überschriften und Erläuterungen verwendet werden, kann mit den numerischen Werten und Formeln auf dem Arbeitsblatt gerechnet, verknüpft und entschieden werden.

Dazu bietet SC eine Vielzahl von Funktionen an. So entsteht ein programmähnliches Schema. Bei Änderung eines Parameters rechnet SC das gesamte Blatt neu durch. So kann z.B. die Auswirkung einer Störgröße in einem kompliziert vernetzten System in wenigen Augenblicken nicht nur für die Endgrösse, sondern für alle Teilkomponenten ermittelt werden.

SC verwaltet für jedes Arbeitsblatt 2 Bilder, einmal mit den in den Zellen enthaltenen Formeln und im zweiten Bild mit den numerischen Werten. Es kann mit dem Befehl G zwischen den Bildern gewählt werden.

KP heißt die Robotronversion die in Aufbau und Wirkung identisch ist. Leider wurden aber alle Befehle umbenannt. Daher empfiehlt sich nur SC zu verwenden und vorhandene Arbeitsblätter damit weiter zu bearbeiten. Während zu allen Befehlen und Optionen in allen Phasen der Bearbeitung eines Arbeitsblattes durch Eingabe von ? Erläuterungen aufgerufen werden können, bietet SC keine Hilfe bei der Nutzung der Funktionen an.

In die NEWS-Diskette wurde daher eine Datei SC.TXT aufgenommen, die Befehle, Optionen, Funktionen und Fehlermeldungen beschreibt. Auf einer Datei TEST.CAL ist außerdem ein Arbeitsblatt vorhanden, auf dem die Funktion LOOKUP an einem Beispiel erläutert ist. Das Arbeitsblatt ist zum Üben vorgesehen.

Zu dBASEII gehören die Dateien:

ENGLISCH.CMD
ENGLISH.DBF
MIETE1.CMD
MIETE.MEM
MIETE2.CMD
MIETE.DBF
MIETE0.DBF
DBASE.DOK

Zu SC gehören die Dateien:

SC.TXT
TEST.CAL

Modul-"Chaos" unter CAOS

von Ralf Kästner

Mit dem "Modularmonster" (scherzhafte Bezeichnung von Nicht-KC-Nutzern für den KC 85 - ich will ja keine Namen nennen) lassen sich durch das integrierte Modulkonzept immer wieder neue Anwendungsbereiche erschließen - andere Heimcomputer können von diesen Möglichkeiten nur träumen. Das Betriebssystem stellt dafür auch passende Unterprogramme zur Verfügung, welche für kleinere Projekte auch vollkommen ausreichen.

Die Probleme beginnen erst dann, wenn man mehrere Module des gleichen Typs gleichzeitig betreiben will oder wenn speziell in RAM-Modulen zur Laufzeit von Vordergrundprogrammen bereits andere Programme laufen, die nicht gestört oder gar überschrieben werden dürfen. Hier wären z.B. anwenderspezifische Systemerweiterungen zu nennen, welche mittels pfiffiger Interruptroutinen fast autonom ihren Dienst verrichten oder auch Module, wo man zeitweise Daten oder Programme ablegt, um später wieder darauf zurückzugreifen.

Problembeispiel

Frank Dachselt zeigte zum Treffen 1995 eine Systemuhr, welche mit Hilfe eines M001 arbeitet. Die zugehörigen Programme laufen dort in einem M011 und beanspruchen im Prinzip fast keinen Speicher im direkten Adressbereich der CPU. Tritt ein Interrupt auf, wird eine wenige Bytes umfassende Interruptserviceroutine aufgerufen, welche das M011 einblendet und das dort enthaltene Uhrprogramm aufruft. Nachdem dieses abgearbeitet ist, wird das M011 wieder ausgeblendet und fertig.

Es wäre nun äußerst ungünstig, wenn ein anderes Programm den Inhalt dieses M011 einfach überschreibt, in der Regel dürfte ein Systemabsturz die Folge sein. Gleiches trifft auf das genutzte M001 zu, was bei Uminitialisierung z.B. zur CENTRONICS-Druckausgabe auch nicht mehr, wie beabsichtigt, die Uhr bedient.

Ich wurde mit diesem Problem bei der Weiterentwicklung von "UNIPIC" konfrontiert und habe mir dort erst mal eine einfache Lösung ausgedacht. Zum Treffen habe ich mit Mario Leubner und Frank Dachselt darüber diskutiert und wir sind zu der Meinung gelangt, es zum Standard zu deklarieren. Die nachfolgend beschriebene Variante läßt sich bei allen Modulen anwenden, egal ob es sich um RAM- oder I/O-Module handelt.

Zunächst stellt dies eine einfache Lösung dar, um beim Start von eigenen Programmen abzutesten, ob das Modul bereits anderweitig benutzt wird, nicht mehr und nicht weniger. Ein richtiges RAM-Managment erreicht man dadurch nicht, dort müßten die Programme u.a. den belegten Speicher nach Beendigung auch wieder freigeben, außerdem müßte der Zugriff auf ein bestimmtes RAM-Segment bzw. eine bestimmte I/O-Adresse am besten über ein universelles Unterprogramm erfolgen, was sich beispielsweise um das eventuelle Ausschalten von höherpriorisierten Modulen in niedrigeren Modulschächten beim Zugriff (im DI!) kümmert. Hier ist noch einiges an Entwicklungsarbeit notwendig.

Lösungsvorschlag

Zum Funktionsprinzip, grundsätzlich wird der Normzustand von CAOS vorausgesetzt, welcher bestimmte Zustände des Modulsteuerbytes kk festlegt. Dieser sieht so aus, daß die internen RAM-Bereiche, RAM 0, RAM 4, RAM 8, eingeschaltet sind (Bit 0=1) und der Schreibschutz ausgeschaltet ist (Bit 1=1). Alle externen Module, bis auf das erste gefundene M003 (Bit 0=1), sind aus (Bit 0=0) und der Schreibschutz ist ein (Bit 1=0), CAOS schaltet also alle Module in den externen Schächten immer mit 00! aus.

Ist ein externes Modul offline (Bit 0=0) spielt der Zustand von Bit 1 durch die niedrigere Priorität innerhalb von kk an sich keine Rolle, kann aber dann gezielt über das Lesen des entsprechenden Steuerbytes ausgewertet werden. An dieser Stelle wird angesetzt, bevor man ein beliebiges Modul für das eigene Programm nutzt, wird Bit 1 von kk (z.B. Lesen über UP 26H) getestet. Ist es 0, kann das Modul genutzt werden, ist es 1, wird das Modul bereits von vorher geladenen Programmen verwendet und darf nicht in Beschlag genommen werden. Beim RAM 8 testet man dagegen Bit 0, ist es 0 ist der RAM reserviert, ist es 1, kann man ihn verwenden.

In "DIASHOW 1.1" ist diese Variante bereits realisiert und soll auch in "UNIPIC 2.0" so integriert werden. Für den reinen Anwender ändert sich gar nichts, nach Einschalten des KC und Kaltstart von CAOS erkennt und nutzt das Programm den gesamten zur Verfügung stehenden internen und externen RAM. Alle "POWER-User" können sich eigene RAM-Module reservieren, indem in vorher gestarteten Programmen diese Module mit 02! (Bit 1=1) ausgeschaltet werden. Die internen RAM-Bereiche sollten zweckmäßigerweise den Anwenderprogrammen zur Verfügung stehen, so daß keine Reservierung sinnvoll erscheint und damit auch nicht getestet werden müßte. Zumindest für den RAM 8 besteht vor dem Laden von "DIASHOW 1.1" durch vorheriges Ausschalten dennoch diese Möglichkeit.

Besonderheiten

Um das o. g. Problem der höheren Priorität niedrigerer Modulschächte auszuschließen, wird eine Modulnutzung nach dem Prinzip der RAM-Floppy von MikroDOS vorausgesetzt! D. h. alle Module, welche von Fremdprogrammen genutzt werden, sind im ausgeschalteten Zustand zu betreiben, nur im DI dürfen z. B. während der Abarbeitung von Interruptserviceroutinen Bereiche beliebig online geschaltet werden, sind aber nach Benutzung auch wieder offline zu schalten! Das laufende Vordergrundprogramm geht hier also vor. Die Int-Routine muß selbst prüfen, ob vielleicht ein anderes Modul einen Zugriff auf das reservierte Modul blockiert.

Im Beispiel "DIASHOW 1.1" schaltet das Programm beim Start den RAM8 und alle RAM-Module offline, unabhängig davon, ob sie reserviert sind oder selbst verwendet werden. Der Zustand des Bit 1 (und Bit 2 bis 7!) von kk wird bei den reservierten Modulen nicht verändert, das Programm reserviert sich aber die gefundenen freien RAM-Module selbst, indem Bit 1 von kk dann gesetzt wird.

Die Konsequenz - hat man jetzt beispielsweise eine Störung und das im RAM befindliche Programm arbeitet nicht mehr, kann man das Programm nicht einfach von Diskette nachladen, da es keinen freien RAM finden kann! Entweder man schaltet den KC aus und wieder ein (dann ist der CAOS-Normalzustand wiederhergestellt) oder, was besser ist, man schaltet mit dem SWITCH-Kommando die benutzten Module mit 00 aus, dann kann man "DIASHOW 1.1" nachladen und die RAM-Module werden wieder korrekt als frei erkannt. Zur Kontrolle des Schaltzustandes der Module oder Speicherbereiche lassen sich an dieser Stelle die CAOS-Kommandos %MODUL bzw. %SYSTEM vorteilhaft nutzen.

Umbauhinweise M011 auf M032

von Maik Freitag

Bei dem Versuch, den Umbau eines M011 zum M032 (256 KByte Ram) nach Mikroprozessortechnik 12/1987 zu vollenden, traten einige Probleme auf. Obwohl das durch die von Kai-Uwe-Irrgang gezeigte Möglichkeit der Aufrüstung gleich auf 1 MByte Ram (M035) nicht mehr so bedeutungsvoll ist, will ich doch die gemachten Erfahrungen weitergeben. Grundlage des Umbaus ist ein Artikel in MP 12/87. Dort wird das Prinzip der Erweiterung genügend beschrieben, so daß ich das hier weglasse. Es werden folgende Arbeiten angeordnet:

Ein DL 074 und ein DL 051 huckepack auf bereits vorhandene IC an den im Bild gekennzeichneten Stellen auflöten. Dabei sind folgende Verbindungen herzustellen: DL 074: Die Pins 1, 3, 4, 7, 10, 11, 13 und 14 mit dem unteren IC verlöten. Pin 6 und 8 werden einfach hochgebogen und nicht verbunden. Pin 2 und 12 werden über je einen 100 Ohm Widerstand mit den Datenbits 2 bzw. 3 verbunden. Pin 5 mit Pin 9 und 10 am DL 051 verbinden. Pin 9 mit Pin 12 und 13 am DL 051 verbinden.

DL 051: Die Pins 1, 2, 7, 11 und 14 werden mit dem unteren IC verlötet. Pins 3, 4, 5, 6 hochbiegen. Pin 9 und 10 beide mit Pin 5 des neuen DL 074 verbinden. Pin 12 und 13 beide mit Pin 9 des DL 074 verbinden. Pin 8 mit Pin 1 an allen Ram-Bausteinen verbinden.

RAM: Alle Ramschaltkreise müssen ausgelötet und gegen neue des Typs 41256 oder 61256 ausgetauscht werden. Danach ist Pin 1 aller Rams miteinander zu verbinden und mit Pin 8 des DL 051 zu verbinden.

Zusätzlich zu den genannten Umbauten müssen noch folgende Änderungen vorgenommen werden, damit das neue Modul problemlos als M032 funktioniert:

1. Änderung des Strukturbytes von F6 in 79 (hex) , damit das Modul später auch als 256 KByte Ram erkannt wird. Dafür ist der einzige DL 003D (links oben) auf der Leiteplatte zuständig. Zuerst sind die von den Pin's 3 und 6 ausgehenden Leiterzüge aufzutrennen, bevor sie irgendeinen anderen IC erreicht haben. Dann sind die Pins 1, 12 und 13 miteinander zu verbinden. Danach sind folgende Verbindungen zu ziehen: Pin 3 mit Datenbit 1 Pin 6 mit Datenbit 2 Pin 11 mit Datenbit 7 Die Datenbits sind an den Rambausteinen an den Pins 2 und 14 vorhanden.
2. Das nach MP umgebaute Modul beachtet die Bits 2, 3, 6 und 7. Das originale M032 benutzt aber die Bits 2, 3, 4 und 5 im Steuerwort zur Ebenenselektierung. Das muß also ebenfalls geändert werden. Dazu ist der DL 008D oberhalb des Huckepack-DL 074 vorhanden. Zuerst sind die Leitungen zu Pin 1 und 2 sowie Pin 4 und 5 aufzutrennen. (Rechts neben dem D 008 auf der Bestückungsseite sind 2 Durchkontaktierungen, davor trennen). Dann ist Pin 1 mit Datenbit 4 Pin 4 mit Datenbit 5 zu kontaktieren.

Mit diesen zusätzlichen Maßnahmen funktioniert der Umbau problemlos und wird einwandfrei in Ramfloppy, Wordpro, Unipic usw. eingebunden.

Quellen: MP 12/87 S.373 M011 Schaltplan

Weil wir gerade so schön beim Thema RAM-Module sind:

Kai-Uwe Irrgang hat sich mit der Aufrüstung eines M011 auf 1 MB schon vor einiger Zeit befaßt und seinerzeit in den "KC 85/x Klubnachrichten" einen Artikel veröffentlicht. Darin wurde der Einbau von DIL-Schaltkreisen im Huckepackverfahren beschrieben.

Auf unserem Treffen präsentierte er eine neue, elegantere Lösung mit SIMM-Modulen. Die dazugehörige Diashow ist auf der Beilagen-Diskette gespeichert. Ebenso der damalige Artikel.

Neues aus der Mailbox-Szene

von Ralf Kästner

Neben der ZNODE 51 von Helmut Jungkunz gibt es noch weitere Mailboxen, welche den KC 85 nicht ganz vergessen haben. Jörg Linder gab mir Anfang des Jahres eine Telefonnummer in Halle, welche ich dann mal angewählt habe. Ich landete in der "TOP-BOX" und fand tatsächlich einen eigenen Filebereich für den KC 85. Mit dem Brettverwalter der KC-Files habe ich mittlerweile auch Kontakt aufgenommen, er heißt übrigens Jan Clauss und dürfte vielen als Autor von QDOS.KCC bekannt sein (er sucht noch ein D004 mit Drive(s)!).

Auf Nachfrage besteht unbedingtes Interesse daran, aktuelle Info's, Neuigkeiten und Programme zu allen KC's über die Box zu verbreiten. Bisher stehen vor allem Programme des KC 85/3 zum Download bereit. U. a. kann man sich auch den PC- Emulator für den KC 85/3 herunterziehen, für ihn sind zusätzlich noch 2 Toolprogramme vorhanden, um KC-Programme vom/in das Emulatorformat umzuwandeln.

Für die MikroDOS-Betriebsart sind noch keine Programme vorhanden, dort besteht lt. Aussage von Jan Clauss bei entsprechender Anzahl an Programmen die Möglichkeit ein extra Brett einzurichten.

Nun zum Wichtigsten, u.a. sind 2 Terminalprogramme im Filebereich zu finden, TERMINAL.KCC scheint für den KC 85/3 zu sein, da es auf dem /4 abstürzt. TERM_8_1.KCC läuft auf dem /4, wie zum Treffen zu sehen. Beide Programme befinden sich auf der Beilagediskette. Es gibt leider keinerlei Anleitung bzw. Beschreibung dafür, vielleicht befaßt sich mal ein DFÜ-Kundiger damit und berichtet demnächst über eventuelle Erfolge in den KC-News!

Nachfolgend nun die wichtigsten Daten zur "TOP-BOX" incl. der bisher vorhandenen Files. Ich werde in nächster Zeit zum KC-Club etwas schreiben und in die Box stellen und möchte alle, die die Möglichkeit zum Uploaden von Software haben, dazu aufrufen, ansprechende KC-Programme in die Box zu laden. Vielleicht findet dann der eine oder andere "stille" KC-User über die Box den Weg zu uns.

Die TOP-BOX in Halle

---

(0345) 78097-20/-21/-85/-86 (28.800 Bd)
(0345) 7700892 / 7759656    (14.400 Bd)
(0345) 7809787 / 7759230    (ISDN)

---

Brettverwalter für die KC-Files
Jan Clauss Tel: 0345/650600 20:00-23:00
          Mail: Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.
          Fido: Jan Clauss@2:249/999
        M-Netz: Jan Clauss@345:1000/1.7
           WWW: http://escher.hrz.fh-stralsund.de/~clauss

---

Derzeit sind ca. 40 Dateien für den KC 85 in der Filearea #90110200 vorhanden.

"4PCX092.KCC" - Konvertierung von PCX-Bildern in das KC-Format

von Ralf Kästner

Durch die Verbreitung der CLIPART-Disketten über die KC-News stehen mittlerweile den Clubmitgliedern eine ganze Menge an mehr oder weniger brauchbaren Bildern für den KC zur Verfügung. Es wurde deshalb höchste Zeit, diese Thematik mal zusammenfassend darzustellen, womit ich mein Versprechen vom diesjährigen Treffen erfüllen möchte. Es soll und kann keine Bedienungsanleitung werden, vielmehr möchte ich Zusammenhänge deutlich machen, um Lust und nicht Frust beim Konvertieren entstehen zu lassen und am Ende ein ansprechendes Bild auf dem KC erscheint.

Das originale PCX-Programm 4PCX090.KCC von Holger Joedicke befand sich (leider etwas versteckt) im DIASHOW.PMA-Archiv auf der KC-News Beilagediskette 4/94. Dieses sehr gute Toolprogramm "ist verantwortlich" für die ganze Bilderflut im PIP- bzw. HIP/HIF-Bildformat. Es ermöglichte erstmals auf dem KC den Zugriff auf eines der bekanntesten PC-Formate für die Speicherung von Bitmapgrafikdateien. Vor allem im DTP-Bereich kann nahezu jedes PC-Programm das PCX-Format lesen, auch auf dem Amiga ist es nicht unbekannt.

PCX-Format

Auf den genauen Dateiaufbau möchte ich hier verzichten, es gibt aber einige wichtige Punkte, die man wissen muß, um das Ergebnis der Konvertierung vorauszuplanen bzw. überhaupt zu verstehen. Das PCX-Format war einer der ersten Standards für Pixelgrafiken überhaupt. Es ist ein eher hardwareorientiertes Format, da im Wesentlichen ein zeilenweiser Speicherabzug des Grafikkarteninhalts (vergleichbar mit dem IRM im KC) der im PC verwendeten Grafikkarte in eine Datei geschrieben wird.

Mit der Entwicklung der Hardware und damit der Grafikkarten auf dem PC durchlief das PCX-Format ebenfalls eine Entwicklung. In der Literatur finden sich teilweise widersprüchliche Angaben, alles was jetzt folgt, habe ich aus mehreren Quellen zusammengetragen bzw. durch Analyse des Hexdumps von PCX-Dateien verschiedener Programme herausgefunden und muß nicht 100%ig stimmen. Benutzt werden heute die Versionen 2.5, 2.8 mit oder ohne Palette und die Version 3.0.

In Version 2.5 sind ausschließlich zweifarbige Bilder, in Version 2.8 Bilder mit bis zu 16 Farben und in Version 3.0 Bilder mit bis zu 16,7 Millionen Farben gespeichert. Die Versionsnummern deuten auf die verwendete Grafikkarte von Hercules (2.5) über CGA/EGA/VGA (2.8) zu SVGA (3.0) hin, welche bei Speicherung der Datei vorhanden war. Die Versionsnummer bestimmt dabei die Anzahl der maximal möglichen Farben, weniger ist natürlich erlaubt, es gibt also z. B. auch Bilder in der Version 3.0, welche nur 2 Farben enthalten.

Für die Konvertierung der Bilder auf dem KC kommen nur Bilder in Betracht, welche maximal 16 Farben enthalten. Um die Datenmenge der Datei zu reduzieren, enthält eine derartige PCX-Datei die Informationen zu den einzelnen Bildpunkten getrennt in 2 Teilen. Im ersten Teil werden die maximal 16 Farben in einer Tabelle (Farbpalette) nach einem festgelegten Schema zusammengefaßt. Den zweiten Teil bilden jetzt nur noch Bezüge (Indizes) zwischen jeweiligem Bildpunkt und seiner Farbe (Tabellenposition) in der Tabelle.

Beispiel:

• die Farbe weiß (RGB-Werte 255/255/255) steht an Position 15 der Tabelle
• jeder weiße Bildpunkt wird jetzt mit dem Wert 1111B=0FH=15 dez. im zweiten Teil abgelegt und erfordert dadurch bei 16 möglichen Farben nur noch maximal 4 Bit für seine eindeutige Darstellung.

Der Dateiaufbau bzw. die Bezüge zwischen Farben und Indizes sind nun in den den o. g. Versionen der PCX-Dateien unterschiedlich geregelt. Sehr wichtig an dieser Stelle ist aber die Erkenntnis, daß verschiedenfarbige Bildpunkte unterschiedliche Indizes hervorrufen, gleichfarbige Bildpunkte gleiche Indizes - die Indizes allein aber keinen Rückschluß auf die wirklich darzustellende Farbe erlauben, denn die steht nur in der Farbtabelle bzw. -palette!!! Bei sw/wß Bildern ist keine Palette notwendig, hier gibt es ja nur 2 "Farbinformationen", was sich dann direkt im Indizesbereich speichern läßt, eine 0 entspricht einem nichtgesetzten, eine 1 einem gesetzten Punkt, es ist also nur noch 1 Bit zur Aufnahme der Bildpunktinformation notwendig.

Was macht 4PCX092.KCC

Am einfachsten ist es bei den zweifarbigen Bildern, die Bildinformationen lassen sich 1:1 in den IRM des KC schreiben und das Ergebnis entspricht damit dem originalen PCX-Bild. Schwieriger wird es, wenn nun die Farben ins Spiel kommen, da man auf dem PC nicht, wie bei uns, auf feste vorgegebene Farben angewiesen ist. Bereits die EGA-Karten konnten zwar auch nur 16 Farben gleichzeitig auf dem Bildschirm anzeigen, allerdings aus einer Auswahl von 64 möglichen Farben, bei VGA waren in den Anfangszeiten 256 Bildschirmfarben aus 262144 zur Verfügung stehenden Farben möglich, heute ist man bekanntermaßen bei 16,7 Mill. Farben angelangt, wo das Monitorbild Fotoqualität erreicht.

Sinnvolle Grenze für den KC sind Grafiken mit max. 16 verschiedenen Farben. Wie bekommt man nun die Farbinformationen der einzelnen Bildpunkte in den IRM des KC? Holger Joedicke hat hier (ob bewußt oder unbewußt weiß ich nicht!?) den folgenden Weg gewählt. Farbige Bilder werden grundsätzlich in den HIRES-Mode des KC 85/4 konvertiert. Dort besteht der große Vorteil, daß man jedem Pixel eine aus vier zur Verfügung stehenden Farben zuordnen kann. Das kommt dem PCX-Format entgegen aber nur ein kleines Stück, weil sich diese 4 Farben nicht ändern lassen, sie sind durch die Hardware des KC fest vorgegeben.

Es hätte also auch nicht viel Sinn, die Farbpalette zu analysieren und zu versuchen, ädequate Bildpunkte in sw/rt/tü/wß zu finden und zu konvertieren, man weiß vorher ja nicht, ob diese 4 Farben überhaupt im Bild enthalten sind! 4PCX092.KCC ignoriert deshalb den Inhalt der Farbpalette und nutzt nur die Indizes für die Konvertierung (s.o.). Da nur vier Farben darstellbar sind, gehen beim Konvertieren des Originalbildes immer dann Informationen verloren, wenn dieses mehr als 4 Farben verwendet:

KC-Darstellung PCX-Indizies auf Position in Farbtabelle

      4   8   16 (verwendete Farben)

---

sw    0   0    0
rt    1   1    1
tü    2   2    2
wß    3   3    3
sw        4    4
rt        5    5
tü        6    6
wß        7    7
sw             8
rt             9
tü            10
wß            11
sw            12
rt            13
tü            14
wß            15

Die Aufstellung macht deutlich, will man ein mehrfarbiges PCX-Bild auf den KC bringen, erzielt man die besten Ergebnisse, wenn es nur 4 verschiedene Farben verwendet! Dann erscheinen alle verschiedenfarbige Punkte des Bildes auch in einer unterschiedlichen Farbe auf dem KC, so daß alle Details erhalten bleiben, Abstriche muß man nur in der Farbtreue machen, da es eben nur sw/rt/tü/wß gibt. Sind mehr Farben im Bild vorhanden, gehen Farbinformationen verloren und es kann passieren, daß ganze Bereiche die im Originalbild eine unterschiedliche Farbe hatten, auf dem KC gleich aussehen und damit im ungünstigen Fall die eigentliche Bildinformation bis zur Unkenntlichkeit verfremden.

Vorbearbeitung von Bildern auf dem PC

Soviel zur Theorie, kommen wir zur Praxis, Bilder gibt es wie Sand am Meer für den PC. Die rasche technische Entwicklung der letzten Jahre macht es aber zunehmend schwieriger, geeignete Bilder für den KC aufzutreiben. Das liegt zum einen an der Bildgröße, die meisten Dateien sind größer als 320*256 Bildpunkte und an der Farbtiefe, zunehmend werden Dateien mit 256, auf Photo-CD's beispielsweise nur noch mit 16,7 Mill. Farben unter das Volk gebracht.

In beiden Fällen ist es sinnvoll die Dateien bereits auf dem PC (ich weiß - nur wer hat, der kann - aber wer weiß, wo einer steht, kann auch!) vorzubereiten. Alle Hinweise beziehen sich auf Bitmap- bzw. Pixelgrafiken. Zunehmend erobern ja auch die vektororientierten Programme, wie CorelDRAW, den heimischen PC, derartige Dateien müssen vorher in das PCX- oder ein anderes Pixelformat exportiert werden, wobei gleich die KC-Bildschirmgröße (meist wählbar) angegeben wird, dann treten keine Skalierungsverluste auf und die Detailqualität bleibt voll erhalten! Die nachfolgend aufgeführten Programme erhält man auf gängigen Zeitschriften CD's, im Vierteljahresabstand erscheint z.B. die In'side Shareware mit CD im TRONIC-Verlag.

Zum Verkleinern ist fast jedes PC-Grafikprogramm in der Lage, allerdings mit unterschiedlichen Ergebnissen bezüglich der Qualität. Es wird zwar viel über PAINTBRUSH von Windows 3.1 gelästert, ich nutze es nach wie vor zum Verkleinern von großen sw/wß-Bildern (nicht für farbige Bilder!), da es dort über eine Kantenglättung verfügt und nicht einfach alle übrigbleibenden Pixel verschluckt, eine Linie bleibt so meist auch auch nach der Verkleinerung geschlossen. Farbige Bilder verkleinert man beispielsweise mit Programmen wie PAINTSHOP Pro f. Windows (Shareware, ab Version 3.0 sind dort auch Malwerkzeuge vorhanden, womit man kleinere Korrekturen schnell per Hand durchführen kann, außerdem kann dieses Programm nahezu jedes Pixelformat lesen, so daß es sich hervorragend als Konvertierungstool in das PCX-Format eignet).

Der zweite notwendige Schritt besteht darin, die erforderliche Farbtiefe (Anzahl verwendeter Farben im Bild) herzustellen. !Wichtig! Muß ein Bild auch verkleinert werden, ist dies zuerst durchzuführen, erst dann die Farbreduktion!!! Beim Reduzieren der Farben ist die Auswahl schon schwieriger, da nur die allerwenigsten Programme in der Lage sind, ein Bild bis auf die für 4PCX092.KCC optimalen 4 Farben herunterzurechnen (s. o.), meistens sind abwärts nach 16 nur noch 2 (sw/wß) möglich, dazwischen nichts.

Meine uneingeschränkte Empfehlung gilt hier GRAPHIC WORKSHOP for Windows (Shareware, aktuelle Version 1.1r unter Windows 3.1). Dieses Programm bietet neben vier verschiedenen Berechnungsverfahren auch alle Zwischenschritte (16/8/4/2) bei der Farbreduktion an und ist wie geschaffen für den KC. Auf der CD von In'side Multimedia EXTRA 2/96 (erscheint auch vierteljährlich im TRONIC Verlag) habe ich vor kurzem ein zweites Sharewareprogramm gefunden, BRENDA 2.0, welches das auch kann und gute Ergebnisse liefert.

Falls jemand andere Programme verwendet, sollten die PCX-Dateien in Version 3.0 gespeichert werden, wenn das Programm eine derartige Auswahl zuläßt!

Konvertierung auf dem KC mit 4PCX092.KCC

Zum Konvertieren der Bilder sind diese auf eine KC-Diskette (CAOS-Format) zu bringen, dazu stehen mittlerweile genug Programme zur Verfügung, auf dem PC z.B. 22DISK oder SUPERCOPY, auf dem KC bekanntermaßen TRANSFER.COM, die Übertragung per Nullmodemkabel o. ä. scheitert noch am Nichtvorhandensein komfortabler Programme, speziell auf der KC-Seite.

Da Holger Joedicke freundlicherweise den Quelltext für 4PCX090.KCC zur Verfügung gestellt hatte, gab es schon mal eine überarbeitete Version namens 4PCX091, welche ich einigen Usern zur Verfügung gestellt hatte, sie befand sich aber noch nicht auf den Beilagedisketten der News. Dafür gibt es aber heute auf der Beilagediskette 4PCX092.KCC - die allerneueste Überarbeitung, angeregt durch BRENDA 2.0 habe ich gegenüber Version 091 nochmals Erweiterungen vorgenommen:

• liest jetzt PCX-Versionen 2.5, 2.8 (4 Bit pro Pixel in 1 Ebene) und alle Varianten der Version 3.0 (1 Bit pro Pixel 1...4 Ebenen)
• Bilder mit mehr als 16 Farben werden nicht gelesen (Fehlermeldung)
• neue Funktion >C<, tauscht Inhalt von Pixel- und Color-IRM während der Anzeige des Bildes (HIRES-Mode)
• während das Bild von Diskette gelesen und aufgebaut wird, kann mit >BRK< abgebrochen werden, das bis dahin gelesene Bild ist verfügbar
• 256. Zeile des Quellbildes wird jetzt auch gelesen und konvertiert (Fehler noch aus 4PCX090.KCC)
• es werden auch unkomprimierte PCX-Dateien gelesen und konvertiert

Damit dürften sich jetzt alle gängigen Bilder bis zu 16 Farben lesen und anzeigen lassen, wie oben schon gesagt, erzielt man die besten optischen Ergebnisse, wenn im Quellbild nur 4 verschiedene Farben zum Einsatz kommen. 4PCX092.KCC läuft unter CAOS nur auf dem KC 85/4. Es enthält ein eigenes Menüsystem, deshalb möchte ich zur Bedienung nicht viel sagen. Man kann auch PCX-Bilder lesen, welche größer als 320*256 Bildpunkte sind, es wird dann immer ein Ausschnitt dieser Größe angezeigt und nach >F2< auch nur dieser Ausschnitt gespeichert. Hatte das Quellbild 2 Farben, wird eine PIP- Datei geschrieben, bei mehr Farben immer eine HIP/HIF-Datei.

Nachdem man das Programm gestartet hat, konvertiert man die eingestellte PCX-Datei über >ET<, sie wird zeilenweise gelesen und gleichzeitig am Bildschirm dargestellt. Mit den >CUT< kommt man immer 8 Pixel weiter in die jeweilige Richtung, mit >SH+CUT< bis zum entsprechenden Rand des PCX-Bildes, wenn es größer als 320*256 Bildpunkte ist. Dazu wird die Datei allerdings auch immer neu von Diskette gelesen, was entsprechend dauert. Steht der Ausschnitt fest, kann man bei farbigen Bildern bei Notwendigkeit mit einigen Tasten (siehe >?<-Funktion) noch Farbvertauschungen vornehmen und bei Gefallen dann über >F2< eine KC-Bilddatei auf die Diskette schreiben.

Weiterverwendung auf dem KC und Ausblick

Nachdem man alle diese Hürden gemeistert hat, befindet sich dann endlich das gebrauchsfertige KC-Bild auf der Diskette und kann weiterverarbeitet werden. Da ich selbst ziemlich ideale Arbeitsbedingungen habe, sind auf diesem Wege bereits fast 9 CLIPART-Disketten entstanden, vor kurzem ist eine Schallmauer gefallen, die 1000!!!, zusammen mit den alten "EDIPIC"-Bildern stehen zur Zeit bereits 1052 KC-Bilder zur Verfügung. Ich will damit vor allem Support für "UNIPIC" betreiben. Eine Nutzung ist aber auch in anderen Programmen möglich, z.B. WordPro 6.0, ML.COM, DIASHOW 1.1, EDIPIC 33 (PIP/PIF-Dateien auch für KC 85/3) oder auch zur Verwendung in eigenen Programmen, wie es Herr Riehl in seinen BASIC- Programmen praktiziert.

Das Grundprinzip der Originalversion 4PCX090.KCC habe ich noch nicht verändert, mit dem jetzigen Stand sind allerdings die Konvertierungsmöglichkeiten im HIRES-Mode ausgereizt. Angedacht sind bereits die versuchsweise Verwendung des LORES-Mode, um eventuell die 16 Farben nutzbar zu machen, es gibt dort natürlich zwangsläufig Konflikte mit der verminderten Farbauflösung von 1*8 Pixeln. Denkbar ist diese Variante vor allem für Zeichnungen oder cartoonähnliche Bilder, dort werden i. d. R. wenige Farben bzw. größere einfarbige Flächen verwendet, was der geringeren Auflösung entgegenkommt.

Ein wenig Nacharbeit ist zu verschmerzen, es entfällt dann aber ein Nachcolorieren des kompletten Bildes per Hand, was ja auch Talent erfordert - für alle, die es schon mal probiert haben! Weiterhin sollte auch der umgekehrte Weg mal realisiert werden, d.h. die Abspeicherung von KC-Bildern im PCX-Format auf dem KC. Das wäre schon heute dringend erforderlich, dann könnten die Beiträge in den News mit Abbildungen aufgewertet werden, welche jeder auf seinem KC erstellen kann, mit Bildern lassen sich ja meist Zusammenhänge anschaulicher und besser darstellen, bei Schaltplänen u. ä. geht es kaum anders.

Die IDE-Festplatte am KC

von Mario Leubner

Wie bereits in den letzten KC-News auf dem Titelblatt zu erfahren war, ist der KC an der Festplatte angeschlossen. Man beachte die Reihenfolge bei der Wortwahl! Diejenigen, die beim Klubtreffen in Erfurt dabei waren, konnten sich auch schon ein erstes Bild davon machen.

Herzstück des Ganzen ist das Generic IDE-Interface, welches von Tilmann Reh für Z80-Rechner entwickelt wurde. Dieses Interface wurde bereits in den KC-News 2/95 kurz vorgestellt. Ich erhielt das GIDE-Interface (Fertiggerät mit RTC) Ende 1995 über Jörg Linder zum Test am KC85/4. Zum Lieferumfang gehörte noch eine Diskette mit einem Testprogramm, einer kurzen technischen Beschreibung, ein paar Assemblerquelltexten und verschiedenen Textbeiträgen aus der amerikanischen Computerzeitschrift 'The Computer Journal' - alles perfekt in englisch.

Das GIDE-Interface wird direkt mit dem Z80-Prozessor verbunden und enthält eine Schnittstelle für max. zwei IDE-Geräte wie Festplatten oder CD-ROM-Laufwerke. Außerdem befindet sich eine Echtzeituhr (Seiko-Epson, RTC 72421) auf der Platine, für eine Batteriepufferung ist ein Steckanschluß vorgesehen. Angesprochen wird das GIDE-Interface ausschließlich über I/O-Befehle, welche mittels Jumper auf eine Basisadresse einzustellen sind. Für die Nutzung im D004 habe ich mich für die Basisadresse 0 entschieden, alle Jumper bleiben dabei gesteckt. Prinzipiell sind auch andere Adressen möglich, belegt sind nur FxH (für CTC und FDC) und 7xH (entsprechend FxH durch unvollständige Decodierung).

Zum Einbau des Interfaces gibt es die Möglichkeit, das Interface direkt 'huckepack' auf den Prozessor aufzulöten. Als bessere Alternative erscheint mir jedoch, den alten Prozessor zu entfernen, stattdessen eine 40-polige IC-Fassung einzulöten und das Interface einzustecken. Für den neuen Prozessor ist auf dem GIDE-Interface bereits eine Fassung vorgesehen. Diese Methode habe ich gewählt und kann sie nur weiterempfehlen.

Platzmäßig gibt es im D004 kaum Probleme. Eventuell stören die beiden Scheibenkondensatoren, die unter der GIDE-Platine sitzen. Ich habe diese durch neuere Typen mit geringeren Abmessungen ersetzt, denkbar ist auch, sie auf die Unterseite der Platine wieder einzulöten. Einen Kompromiß muß man jedoch eingehen: Das GIDE-Interface benötigt soviel Platz, daß im Modulschacht F4 kein Modul mehr gesteckt werden kann. Andererseits kann dieser Platz jetzt für die Pufferbatterie und die Herausführung des 40-poligen Verbindungskabels zur Festplatte verwendet werden.

Bei allen Lötarbeiten ist größte Vorsicht geboten, damit die D004-Hauptplatine nicht beschädigt wird. Der alte U880 kann herausgeschnitten werden, einen neuen Z80 gibt es für ca. 6,- DM. Zu beachten ist noch, daß das Rastermaß der DDR-Bauelemente 2,5mm und das international übliche 2,54mm beträgt. So ist das GIDE mit Fassungen im Abstand von 2,54mm ausgestattet, die Lötpunkte auf unserem D004 liegen jedoch im 2,5er Raster. Auf 20 Anschlüsse in einer Reihe ergibt sich ein Längenunterschied von insgesamt 0,76mm.

Mit ein wenig Fingerspitzengefühl läßt sich beides jedoch zusammenfügen. Ich habe eine noch vorhandene neue DDR-Fassung mit 2,5er Raster in die D004-Platine eingelötet. Diese Fassung hat flache Einsteck-Kontakte, welche ohne Probleme auch für Bauelemente im 2,54er Rastermaß geeignet sind.

Noch ein Hinweis: Der Einbau sollte Schritt für Schritt erfolgen wobei zwischendurch immer einen Funktionstest erfolgen kann:

1. JUMP FC FF (zunächst am Original-D004)
2. alten U880 auslöten und Fassung einlöten
3. neuen Z80 direkt stecken
4. JUMP FC FF (wenn OK, dann ist die Fassung in Ordnung)
5. Z80-Prozessor entnehmen
6. GIDE-Basisadresse 0 einstellen und Interface stecken
7. Z80 in Sockel des GIDE-Interfaces stecken
8. JUMP FC FF; Wenn auch hier nur OK-Meldungen kommen, dann ist das GIDE-Interface richtig angeschlossen. Mit einer MicroDOS-Diskette kann jetzt wieder wie bisher das normale System gestartet werden.

Als nächstes sollte man sich nach einer geeigneten Festplatte umsehen und Überlegungen zwecks Gehäuse und Netzteil anstellen. Geeignet sind prinzipiell alle IDE- oder AT-BUS-Platten. Die Kapazität sollte sich jedoch in der Größenordnung von 20 bis 80 MByte bewegen. Es werden also vorwiegend Festplatten aus alten PC's Verwendung finden.

Je größer die Platte ist, umso mehr Speicherplatz ist für die Verwaltung erforderlich und man hat dann nicht mehr genug Arbeitsspeicher zur Verfügung, oder man nutzt nur einen Teil der Gesamtkapazität der Platte. Die nachfolgende Tabelle verdeutlicht den Zusammenhang zwischen Plattengröße und TPA-Kapazität ausgehend vom gleichen Betriebssystem, wie ich es zur Zeit benutze:

Die TPA-Obergrenze sollte nach Möglichkeit die Adresse C900H nicht unterschreiten, damit zu unserem MicroDOS 2.6 keine weiteren Einschränkungen getroffen werden müssen und vorhandene Programme auch weiterhin laufen. Bei der von mir verwendeten Konfiguration des Z-Systems sind also Festplatten bis knapp 70 MByte möglich.

Eine nicht zu unterschätzende Aufmerksamkeit sollte auch dem Netzteil gewidmet werden. Ich wollte meine Festplatte zunächst an einem Netzteil betreiben an dem bisher nur ein 5,25"-Diskettenlaufwerk angeschlossen war. Ich hatte nicht beachtet, daß die Stomaufnahme der Festplatte mit 12V/2A und 5V/1,4A angegeben ist. Das Netzteil sollte die angegebenen Werte schon schaffen. Jetzt verwende ich ein umgebautes KC-Netzteil, das einen neuen Trafo und einen stärkeren 12V-Regler enthält. Den Anschluß der Versorgungsspannungen an die Festplatte kann man sich vom D004- Drive abschauen, die Steckverbinder sind identisch. Eine elegante Lösung wäre auch der Einbau der Festplatte in ein vorhandenes D004-Drive. Die 3,5" breite Festplatte paßt dort noch mit hinein!

Für die Verbindung der Festplatte mit dem GIDE-Interface ist noch ein 40-poliges 'Hosenträgerkabel' erforderlich. Dieses ist einfach 1:1 mit einem angepreßten Stecker an jeder Seite verdrahtet. Sollte der PC, der bereits die Festplatte gespendet hat, dieses Kabel noch benötigen, ist ein solches auch bei jedem PC-Händler oder Elektronikversand erhältlich. Zu beachten ist an dieser Stelle nur, daß die Stecker nicht verdreht angesteckt werden: An der Festplatte ist ein Anschlußstift weggelassen, dies ist das Pin 20, am GIDE-Interface liegt dieser Kontakt an der Innenseite!

Nach erfolgreichem Einbau von GIDE-Interface und Festplatte kann nun der erste Test mit dem Testprogramm GIDETEST.COM gestartet werden. Dabei muß als erstes die Portadresse definiert werden. Danach kann die Platte initialisiert oder das ID-Feld gelesen werden. Vorsicht ist bei den Menüpunkten 8 und 9 geboten, diese Zerstören den Platteninhalt! Wenn die Platte aber noch nicht für die Arbeit unter CP/M vorbereitet wurde, ist dies jedoch kein Problem, da die noch vom PC stammenden Daten ohnehin nicht weiterverwendet werden können.

Das Lesen des ID-Feldes sieht bei mir wie folgt aus:

Reading ID information...
ID constant              : 16972 (424C)
cylinders fixed          : 560
cylinders removable      : 0
number of heads          : 6
bytes per track phys.    : 15625
bytes per sector phys.   : 597
sectors per track        : 26
serial number            : >85397769<
controller revision      : >4.1/064<
buffer size (sectors)    : 4
number of ECB bytes      : 4
controller model         : >Seagate Technology ST157A <
total sector count       : 87360
capacity (MByte)         : 42.0

press ENTER

Diese 42MB-Festplatte ST157A scheint weit verbreitet zu sein. Abgesehen vom relativ hohen Strombedarf ist diese Platte bestens für den Einsatz am KC geeignet. Wer dieselbe Platte anschließt, kann darüberhinaus die von mir getestete Software verwenden und erspart sich die Konfiguration des eigenen Systems.

Zum Schluß noch ein Wort zur Echtzeituhr, die sich ebenfalls auf der GIDE-Platine befindet. Dieser RTC-Chip beinhaltet eine vollständige Uhr mit Datum und Uhrzeit und läuft mit einer Pufferspannung bis 2V auch bei ausgeschaltetem Rechner weiter. Damit steht uns ab sofort eine aktuelle Zeitbasis wie beim PC zur Verfügung. Zur Pufferung habe ich eine Lithium-Knopfzelle CR2430 eingesetzt, welche mit maximal 5 Mikorampere belastet wird. Die Kapazität dieser Lithiumzelle (270mAh) reicht dabei theoretisch 6 Jahre.

Ein Problem gibt es allerdings noch: Beim Einschalten des KC bleibt die Uhr manchmal stehen. Ursache sind unsaubere Pegel vor allem auf der RESET-Leitung, die beim Einschalten der Betriebsspannungen auftreten. Abhilfe soll hier ein mit einem Spezial-IS direkt aus den 5V gewonnenes RESET-Signal schaffen. Leider kann ich dazu noch keine Aussage treffen, da die Beschaffung des Schaltkreises verzögert wurde. Ich bin mir aber sicher, daß das Problem noch gelöst werden kann.

ZSDOS - Das neue Betriebssystem für den KC

von Mario Leubner

Mit dem erfolgreichen Anschluß der Festplatte am KC bestand nun das weitaus größere Problem der Einbindung in das Betriebssystem. Da bis zum heutigen Tag die Quelltexte des KC-MicroDOS 2.6 nicht vorliegen, blieb mir keine andere Wahl als MicroDOS komplett zu reassemblieren. Das Ergebnis bestätigte meine Vermutungen:

• Das System wurde bis auf wenige BIOS-Funktionen im 8080-Code programmiert.
• CCP, BDOS und BIOS sind derart verknüpft, daß ein Ersetzen einzelner Komponenten nicht ohne weiteres möglich ist.
• Die Verwaltung von Spur und Sektor erfolgt durchweg mit 8 Bit, was die Einbindung großer Laufwerke (Festplatte) nicht gestattet
• Es ist sehr viel Code enthalten, der an CP/M 3 angelehnt ist, obwohl MicroDOS nicht dazu kompatibel ist.
• Es sind weiterhin Programmreste enthalten, die auf die Entwicklungsphase in der ehemaligen Sowjetunion schließen lassen.

Fazit: Neben vielen nicht benötigten Programmteilen (die ohnehin nur wertvollen Speicherplatz verbrauchen) bietet MicroDOS nicht die Voraussetzungen, die Festplatte einzubinden.

Aus diesem Grund mußte über ein neues Systemkonzept für den KC nachgedacht werden. Bisher sollte davon ausgegangen werden, sinnvolle Funktionen von MicroDOS in das neue System zu übernehmen. Ich denke da z. B. an die BDOS-Funktion 47, die schon mehrfach benutzt wurde. Durch das unzureichende Konzept von MicroDOS mußte diese Forderung jedoch vernachlässigt werden, da eine Überarbeitung von MicroDOS nicht mehr sinnvoll ist. Nur das KC-spezifische BIOS-Segment habe ich letztlich von MicroDOS übernommen, jedoch stark überarbeitet und für die Anforderungen der Festplatte vorbereitet.

Ein völlig neues System mußte her!

Das neu zum Einsatz kommende Paket von DOS und Kommandoprozessor bestimmt im wesentlichen die Eigenschaften des neuen KC-Systems. Die Verwendung fertiger Systeme, die bereits erprobt sind erspart uns viel Entwicklungsaufwand. Es ist somit auch nicht nötig, das berühmte "Fahrrad neu zu erfinden". Der Vergleich mehrerer zur Verfügung stehender BDOS-Varianten ließ meine Wahl schließlich auf ZSDOS 1.0 fallen.

ZSDOS bedeutet soviel wie 'Z-System-DOS', ist kompatibel zu CP/M 2.2 und bestens als DOS-Segment für das Z-System geeignet. ZSDOS 1.0 unterstützt Laufwerke bis zu 1 Gigabyte, Dateigrößen bis zu 32 Megabyte und 262.144 logische Sektoren beim wahlfreien Dateizugriff. Das ist mehr als genug für die am KC einzusetzenden Festplatten! Außerdem bietet ZSDOS die Möglichkeit zur Verwaltung von Datum und Uhrzeit sowie die direkte Einbindung von DateStamper (Datumsstempel von Dateien), was der Echtzeituhr auf dem GIDE- Interface entgegenkommt.

ZSDOS/ZDDOS ist jedoch keine frei kopierbare Software, dafür ist etwas zu bezahlen. Jörg Linder hat schon Kontakt aufgenommen und für eine Gruppenlizenz für den KC-Klub einen Rabatt ausgehandelt; im Preis ist neben der Lizenz auch ein deutsches (!) Handbuch mit der Beschreibung der Utilities enthalten.

Inzwischen sind einige Dateien entstanden, die zur Einbindung von ZSDOS und des neuen BIOS benötigt werden. Die Entwicklung des Betriebssystems ist damit jedoch noch nicht abgeschlossen. Geplant ist noch ein neuer Bootlader, damit das System auch direkt geladen werden kann und eine spezielle CAOS-Version des Systems. Ich will jedoch hiermit zunächst einmal den momentanen Stand meiner Entwicklungsarbeit bekanntgeben, damit sich jeder eine Vorstellung machen kann, was sich in Zukunft auf dem KC für Möglichkeiten ergeben.

Benötigte Software

Alle Programme und Quelltexte, die zur Erstellung des neuen KC- Betriebssystems erforderlich sind, habe ich in ein Archiv gepackt. Es wird beim Erwerb der Lizenz für das ZSDOS/ZDDOS mitgeliefert. Zu den Dateien gehören unter anderem:

POWER.COM	universelles Dienstprogramm
GIDETEST.COM	Testprogramm für das GIDE-Interface
DIMA.COM	Disketten-Monitor (für KC-System!)
TIME.COM	Testprogramm für RTC-Schaltkreis
FORMAT.COM	FORMAT V3.0, Diskettenformatierung
MODF.COM	Einstellung der Diskettenlaufwerke
HDPARK.COM	Parken der Festplatte in der letzten Spur
CPM.COM	fertiges System für Festplatte ST157A

START.MAC	Quelltext des Startprogramms
START.DMP	Speicherabzug Startprogramm (100H-6FFH)
MODUL.INC	CAOS-Unterprogramm zum Aufbau der Modultabelle
CCP.MAC	Quelltext des Minimal-CCP
CCP.REL	REL-Code des Minimal-CCP
ZSDOS.ZRL	REL-Code des BDOS (ZSDOS V1.0)
ZBIOS.MAC	Quelltext des neuen BIOS
OPTION.INC	USER-Definitionen zu GIDE und Festplatte
DEFDPB.INC	8 DPB-Definitionen für Laufwerk 1.6

GIDE.TXT	Hardwarebeschreibung
NEWSYS.TXT	Softwarebeschreibung

Diverse Dateien für ein Z-System (z. B. TCAP, spezieller RCP).

Dateien für die CAOS-Diskette

Momentan ist die Entwicklung zwar noch nicht abgeschlossen, jedoch werden Lizenznehmer auf dem aktuellen Stand gehalten. Eine Verbreitung des Grundpaketes über die KC-News wird nicht möglich sein, da ZSDOS/ZDDOS Lizenzrechten unterliegen.

Erstellen des Startprogramms

(Die Angaben des folgenden Abschnittes geben den momentanen Stand wieder und können sich noch ändern. Wie heißt es so schön: Änderungen im Sinne des technischen Fortschritts vorbehalten!)

Wer sich die im weiteren beschriebenen Schritte nicht zutraut, dem unterbreite ich folgendes Angebot:

• Der erfolgreiche Einbau der Festplatte muß abgeschlossen sein, d. h. GIDETEST.COM muß fehlerfrei laufen.
• Die Lizenz von ZSDOS muß vorliegen.
• Die Daten der Festplatte mit dem Menüpunkt 'Read ID' von GIDETEST.COM anzeigen lassen und aufschreiben/ausdrucken.

Dieses zusammen mit den Vorstellungen zur Belegung der Laufwerke notieren und mir zuschicken. Ich erstelle danach das Startprogramm CPM.COM, welches von MicroDOS aufgerufen werden kann und das neue System einstellt. Hier jedoch erst mal eine Anleitung für alle, die ihr System selbst erstellen wollen:

Zum Starten des Systems ist vorerst noch ein 'Startprogramm' erforderlich. Später soll diesen Ladevorgang wieder ein Bootlader übernehmen und das System direkt aus den Systemspuren der Diskette bzw. Festplatte laden. Zur Zeit ist jedoch noch der Umweg über MicroDOS erforderlich. Ich habe mir eine Startdiskette eingerichtet, die MicroDOS mit allen benötigten Treibern (Druckertreiber, Koppeltreiber, ZAS...) startet. Der letzte Befehl in der INITIAL.SUB startet dann das Startprogramm CPM.COM und lädt das neue System in den Speicher.

Das Startprogramm CPM.COM enthält schon eine Art Bootlader, welcher mehrere Arbeitsschritte ausführt:

1. Stoppen der laufenden Interrupts von MicroDOS
2. Kopieren des neuen Systems (CCP, BDOS, BIOS)
3. RAM-Floppy neu berechnen, ein 256K-EPROM-Modul mit Strukturbyte 73H wird dabei als EPROM-Floppy eingebunden. Das RAM-Floppy muß mindestens 2 Spuren (32K) besitzen, da Spur 0 als Systemspur und Spur 1 für das Directory benötigt wird.
4. Directory für RAM-Floppy wird gelöscht und eventuell mit den Einträgen des EPROM-Floppy belegt.
5. CCP und BDOS wird in Systemspur des RAM-Floppy übertragen.
6. IDE-Festplatte initialisieren nach Angaben des DPB von Laufwerk C: (bei Fehler werden DPHC und DPHD gelöscht).
7. Test, ob RTC-Uhr arbeitet, eventuell Neustart mit 1.1.1996.
8. Übergabe der Steuerung an das neue System mit BIOS-Kaltstart.

Das Startprogramm enthält im Anschluß an den Bootlader (0700H) einen Speicherabzug des neuen Betriebssystems, also CCP, BDOS und BIOS. Zur Anpassung des BIOS an das eigene System, speziell die verwendete Festplatte, sind in der Datei OPTION.INC einige Parameter einzutragen und die Systembestandteile neu zu übersetzen. Im Quelltext des Startprogramms muß noch die CCP-Anfangsadresse eingetragen werden, damit das System an die richtige Zielposition kopiert wird. Dann können alle Systembestandteile zum Programm CPM.COM verbunden werden. Wer wie ich eine ST157A benutzt, kann das fertige CPM.COM aus dem Archiv direkt verwenden.

Folgende Parameter sind in der Datei OPTION.INC für die Festplatte einzutragen:

HARD   EQU 1           ; 0, wenn ohne Festplatte
GIDE   EQU 0           ; GIDE-Basisadresse
CYLS   EQU 560         ; Anzahl Zylinder
HEADS  EQU 6           ; Anzahl Köpfe
SECS   EQU 26          ; Anzahl Sektoren
PARTC  EQU 141         ; Partition C: ca. 10 MByte
OFFC   EQU 1           ; Anzahl Systemspuren in C:
PARTD  EQU CYLS-PARTC  ; Partition D: ca. 32 MByte

Die angegebenen Werte entsprechen meiner Festplatte. Diese ist in zwei Partitionen unterteilt. Partition C: ist mit 1024, Partition D: mit 2048 Verzeichniseinträgen definiert, die Blockgröße für beide Partitionen ist mit 4 KByte definiert. Die Platte sollte deshalb in zwei unterschiedlich große Partitionen aufgeteilt werden. Ob 2048 Einträge für 32 MByte ausreichen, wird jedoch erst die Erfahrung zeigen.

Für die Partition C: sollte außerdem eine Systemspur definiert werden, die später einmal den Systemstart von Festplatte vornehmen soll, 32 KByte dürften dabei ausreichen. Bei großen Partitionen ab 32 MByte ist der DPB manuell im BIOS einzutragen, da der Assembler dann wegen Arithmetiküberlauf die Werte nicht mehr korrekt berechnen kann. Meine Partition D: ist deshalb auch nur knapp 32 MByte: genau 33.466.368 Byte oder 32.682 KByte oder 31,92 MByte.

Die Laufwerke E: bis H: können frei definiert werden. In der Datei OPTION.INC wird mit 3 weiteren Parametern für jedes Laufwerk festgelegt, welches Diskettenformat erzeugt werden soll. Die Macros zur Erzeugung der DPB's stehen in DEFDPB.INC und brauchen nicht geändert werden. Definiert sind zur Zeit folgende 8 Formate für doppelseitige Laufwerke mit 80 Spuren:

1   16 *  256 * 40 * 1 => 160k
2    5 * 1024 * 40 * 1 => 200k
3    8 *  512 * 40 * 2 => 320k
4   16 *  256 * 80 * 1 => 320k
5    5 * 1024 * 80 * 1 => 400k
6   16 *  256 * 80 * 2 => 640k
7    9 *  512 * 80 * 2 => 720k
8    5 * 1024 * 80 * 2 => 800k

Als Beispiel sei ein 780K-Laufwerk als logisches Laufwerk E: im physischen Laufwerk 1 zu definieren, dazu sind die Parameter wie folgt zu belegen:

FORME  EQU 8           ; Format 5*1024*80*2
OFFE   EQU 2           ; 2 Systemspuren => 780K
UNITE  EQU 1           ; physisches Laufwerk 1

Wer es sich zutraut, kann die DPB's auch im BIOS direkt eintragen oder in DEFDPB.INC weitere DPB-Grundtypen definieren. Selbstverständlich können auch weitere Laufwerke definiert werden, jedes Diskettenlaufwerk benötigt jedoch einen eigenen Eintrag in der DPH-Tabelle (2 Byte), einen DPH (16 Byte), einen DPB (28 Byte), Verzeichnisprüfvektor (32 Byte) und Belegungstabelle (50 Byte). Das sind zusammen 128 Byte, die für jedes zusätzliche Diskettenlaufwerk zu reservieren sind. Dieser Speicher muß im BIOS bereitgestellt werden und geht beim TPA verloren.

In Abhängigkeit von der verwendeten Festplatte und den zur Verfügung stehenden Laufwerken wird jeder selbst die für ihn beste Lösung erarbeiten und ausprobieren müssen. Auch kann der Wunsch auftreten, die Festplatte in mehr als 2 Partitionen zu unterteilen oder Blockgrößen von 8 KByte und damit 4096 Verzeichniseinträge zu ermöglichen. Prinzipiell ist dies alles möglich, ich habe es jedoch bisher nicht geschafft, den BIOS-Quelltext so universell zu gestalten, daß diese Angaben alle in der Datei OPTION.INC gemacht werden können. Für den 'Normalverbraucher' wird meine Vorgabe wahrscheinlich ausreichen, im Einzelfall bin ich auch bereit die entsprechenden Anpassungen vorzunehmen.

Die Größe des BIOS-Segmentes ergibt sich im also wesentlichen aus der Größe der verwendeten Festplatte und der Anzahl der installierten Diskettenlaufwerke. Für jeden Block der Festplatte ist ein Bit im Belegungsvektor des BIOS erforderlich, also 32 Byte je MByte Kapazität bei 4K-Blöcken. Die Endadresse des BIOS ist vom Koppel-RAM begrenzt, der im KC-System spezielle Aufgaben bei der Kopplung mit dem Grundgerät erfüllt. In der folgenden Zusammenstellung ist die Lage der Systembestandteile unter MicroDOS und CP/M 2.2 mit und ohne Z-System zu sehen:

Aus dieser Darstellung läßt sich besonders gut erkennen, daß mein neues System mit Festplatten-BIOS, ZSDOS 1.0, ZCPR 3.4 und den residenten Bestandteilen des Z-Systems noch mehr TPA zur Verfügung stellt als bisher MicroDOS 2.6. Die Größe des BIOS-Segmentes entspricht dabei einer Belegung mit 8 logischen Laufwerken und einer maximal 43 MByte großen Festplatte.

Zu beachten ist noch, daß das CCP-Segment jetzt wie beim Original-CP/M von Anwenderprogrammen überschrieben werden kann, mit MicroDOS war das nicht möglich! Der TPA-Bereich ist damit also bis zum Beginn des DOS-Segmentes nutzbar. Das TPA-Ende sollte nach Möglichkeit C900H nicht unterschreiten, damit alle von MicroDOS 2.6 vorhandenen Programme auch weiterhin laufen.

Die Größe der residenten Z-Systembestandteile kann je nach den geforderten Leistungen variieren und unter Umständen auch verändert werden. Es gibt also in Zukunft keine festen Adresszuordnungen mehr. Für die Programmierer gilt damit stärker als bisher, sich an die CP/M-Konventionen zu halten. Programme, die speziell für das Z-System geschrieben wurden, können außerdem noch auf die residenten Teile des Z-Systems zurückgreifen.

Sind alle Vorstellungen vom gewünschten System vorhanden, geht es nun an das Erzeugen des Startprogramms CPM.COM. Dazu sind prinzipiell drei Arbeitsschritte erforderlich: Assemblieren, Linken und Zusammenfügen. Das klingt zwar etwas umständlich, mir ist es aber bisher noch nicht gelungen, alle Systembestandteile mit einem einzigen LINK-Lauf zu einem COM-File zu verbinden. Es bleibt zumindest der Vorteil, daß alle Systembestandteile unabhängig voneinander entwickelt werden können. Der zusätzliche Schritt mit POWER.COM ist jedoch leicht nachvollziehbar.

1. Editieren:

Datei OPTION.INC mit Daten des eigenen Systems.

 

2. Assemblieren:

A>ASM ZBIOS=ZBIOS
* ZBIOS fuer Betriebsart: -CP/M- *
* Festplatte Partition C: 10 MByte *
* System enthaelt: 78 KByte *
* Festplatte Partition D: 31 MByte *
* ZBIOS-Speicherbedarf : 1300H *
* 12 Bytes frei (dezimal) *

So könnte der Assemblerlauf des BIOS aussehen. Das Ergebnis dieses Arbeitsschrittes ist ZBIOS.REL. Zur Kontrolle werden die Festplattengrößen angegeben. Wichtig für die nächsten Arbeitsschritte ist der Speicherbedarf (1300H im Beispiel).

 

3. Linken:

A>LINK131 ZBIOS.DMP=ZBIOS.REL [LE900]

Das Ergebnis dieses Arbeitsschrittes ist eine Datei ZBIOS.DMP, die einen Speicherabzug des BIOS-Segmentes enthält. Im Parameter ist die BIOS-Adresse (FC00H - BIOS-Größe) anzugeben, damit der Linker die korrekten absoluten Adressen einträgt.

A>LINK131 ZSDOS.DMP=ZSDOS.ZRL [LDB00]

A>LINK131 CCP.DMP=CCP.REL [LD300]

oder

A>LINK131 SYSTEM.DMP=CCP.REL,ZSDOS.ZRL [LD300]

CCP und BDOS kann in einem Schritt gelinkt werden. Das CCP-Segment belegt 2 KByte (800H) und BDOS 3,5 KByte (0E00H). Daraus ergibt sich die Ladeadresse D300H. Nach ZSDOS kann kein weiteres Modul gelinkt werden, da sonst der für die BIOS-Rufe definierte COMMON-Bereich nicht direkt nach das BDOS gelegt wird.

Die CCP-Adresse (im Beispiel D300H) muß nun noch im Startprogramm START.MAC eingetragen werden. Das Startprogramm wird mit folgenden Befehlen übersetzt:

A>ASM START=START

A>LINK131 START.DMP=START.REL

 

4. Zusammenfügen der Teilprogramme:

A>POWER
A0=LOAD START.DMP 4100 (12 Sektoren belegt)
A0=LOAD CCP.DMP 4700 (16 Sektoren belegt)
A0=LOAD ZSDOS.DMP 4F00 (28 Sektoren belegt)
A0=LOAD ZBIOS.DMP 5D00 (38 Sektoren belegt)
A0=SAVE CPM.COM 4100 94 (alles zusammen abspeichern)
A0=EXIT

Die angegebenen Sektoren beziehen sich auf die im Beispiel verwendete Konfiguration. Bei ZBIOS.DMP kann es zu Abweichungen kommen. Die korrekte Zahl wird beim Laden mit POWER.COM angezeigt und kann auch rechnerisch überprüft werden:

Anzahl Sektoren = BIOS-Größe / 128

Die beim Abspeichern anzugebende Sektoranzahl ist dann ebenfalls neu aus den einzelnen Teilbereichen zu berechnen!

Start des neuen Systems

Nachdem das an das eigene System angepaßte CPM.COM erzeugt wurde, kann ein Startversuch unternommen werden. Der Bildschirm wird gelöscht und sollte in etwa folgendes anzeigen:

Neues System wird installiert:
RAM-Floppy...1872K
ROM-Floppy...OK.
Festplatte...OK.
RTC-Uhr......OK.

54K CP/KC 2.2 (beta-Version!)
Copyright by ML-Soft 08.02.96
A>_

• In der Zeile RAM-Floppy wird die erreichte Kapazität angezeigt, ist ein EPROM-Floppy-Modul vorhanden, dann sind diese zusätzlichen 256K bereits enthalten.
• Die Zeile ROM-Floppy erscheint nur, wenn ein EPROM-Floppy-Modul eingebunden wird.
• Ist die Festplatte nicht ansprechbar, so erscheint 'nicht bereit' und die DPH's von C: und D: werden entfernt. Ein erneuter Startversuch mit dem CCP-Kommando G ist möglich.
• Arbeitet die Uhr nicht, dann wird sie mit dem Datum 01.01.1996 neu gestartet.

Das so gestartete System enthält bereits eine arbeitsfähige CP/M-Umgebung, mit der die Festplatte getestet werden kann. Der CCP dieses Minimalsystems wurde dem MicroDOS 2.6 angelehnt und ist nur mit den nötigsten Befehlen ausgerüstet worden. Für eine effektive Festplattenarbeit empfiehlt sich ein Z-System wie z.B. NZ-COM mit ZCPR 3.4., dazu später noch ein paar Anmerkungen.

Der CCP des Startsystems enthält folgende Kommandos:

0	Rückkehr zum CAOS
1	Bildschirm löschen
D <maske>	Directory auflisten
U <user>	USER-Bereich wechseln
K <nr>	F-Tasten auflisten, wenn nr nicht angegeben bzw. F-Taste belegen, wenn nr angegeben ist
G	Sprung zu 100H (Wiederstart von Programmen)
T	Datum und Uhrzeit anzeigen
T C	kontinuierliche Zeitanzeige bis irgendeine Taste gedrückt wird
T S	Uhr stellen (Eingaben entsprechend Aufforderung)

Testen des Festplattentreibers im BIOS

Als erstes sollte das Programm DIMA.COM von Diskette gestartet werden. Es ist die Weiterentwicklung von DIMAKC.COM und vielleicht einigen bekannt. DIMA wurde speziell für die Arbeit mit der Festplatte weiterentwickelt und kann einzelne Sektoren aller Bereiche eines Laufwerks lesen, modifizieren und schreiben.

Zunächst sollten die Partitionen C: und D: angewählt werden und die im rechten Bildschirmteil angezeigten Parameter kontrolliert werden. Wenn diese mit den errechneten übereinstimmen, ist mit dem Kommando 'R' der Zugriff auf jeden Sektor der Platte möglich. Sollten die Parameter nicht stimmen, dann ist in ZBIOS.MAC bzw. OPTION.INC die Festplattendefinition nicht richtig erfolgt und die Angabe der Werte nochmal zu kontrollieren.

Zur Erläuterung:

• Spuranzahl ist die Zylinderanzahl, die für die jeweilige Partition festgelegt wurde.
• Sektoren/Spur ergeben sich aus den physischen Parametern der Platte wie folgt: HEADS * SECS * 4. Der Faktor 4 ergibt sich aus der physischen Sektorgröße der Festplatte von 512 Byte und der im CP/M verwendeten logischen Sektorgröße von 128 Byte.

Ich gehe davon aus, daß die Festplatte bereits in einem PC betrieben wurde und demnach formatiert ist. Sollte dies nicht der Fall sein, bleibt nur der Weg zu einem PC und die Platte dort erst mal zu formatieren - ein FORMAT.COM für die Festplatte gibt es (noch) nicht.

Da die Festplatte nicht für CP/M-Systeme vorgesehen war, kann man zwar alle Sektoren lesen, aber im Directory werden sich keine gültigen Informationen befinden. Wer Kenntnis vom MS-DOS-Dateisystem besitzt, kann zwar Bootsektor, die FAT's und das Hauptverzeichnis finden, für die Anwendung im CP/M-System können diese Daten aber nicht weiterverwendet werden. Als Alternative zu einer Neuformatierung der Festplatte, zu der es kein Programm gibt, verwende ich wieder POWER.COM. Folgende Befehle löschen das gesamte Directory:

A>POWER
A0=C:
C0=FILL 4000 BFFF E5
C0=WRITE 1 1 4000 256
C0=D:
D0=WRITE 0 1 4000 256
D0=WRITE 0 257 4000 256

Dabei geschieht folgendes: Als erstes wird der RAM-Bereich von 4000H bis BFFFH mit E5H gefüllt. Der WRITE-Befehl schreibt diese 32K in Spur 1 von Partition C: und löscht somit den gesamten Directory-Bereich mit 1024 Einträgen. Spur 1 ist deshalb zu verwenden, da Spur 0 als Systemspur definiert wurde. Für Partition D: sind zwei WRITE-Befehle erforderlich, damit 64K für 2048 Einträge gelöscht werden. Spur 0 wird verwendet, da D: keine Systemspur besitzt.

Die so vorbereitete Festplatte ist jetzt bereit, Daten aufzunehmen. Damit der Belegungsvektor der Festplattenpartitionen gelöscht wird, sollte an dieser Stelle das ganze System erneut hochgefahren werden. Die STAT-Meldung von POWER sollte danach auch anzeigen, daß 0K belegt sind.

Noch ein Hinweis: Obwohl ich sehr oft mit POWER.COM arbeite und auch alle oben beschriebenen Funktionen ordnungsgemäß ausgeführt habe, sollte man vorsichtig sein mit dem Programm wenn es um die Laufwerksparameter geht. POWER berechnet bei großen Laufwerken die Spuranzahl nicht korrekt. Fehler treten dann z.B. auch bei READGR auf.

EPROM-Floppy

Das neue Startprogramm, das in ähnlicher Form später im Bootlader untergebracht werden soll, initialisiert automatisch ein (!) EPROM-Modul mit dem Strukturbyte 73H im RAM-Floppy. Diese Funktion wird zum einen Teil im CAOS-Programmteil MODUL.INC ausgeführt, was die Modulsuche betrifft. Der zweite Teil, die Directory-Erzeugung geschieht im Startprogramm selbst. Mehrere EPROM-Module können zur Zeit noch nicht eingebunden werden. Es sollte auch nur ein einziges Modul mit dem Kennbyte 73H stecken, damit es zu keinem Programmfehler kommt. Für den Bootlader ist eine Lösung geplant, die auch mehrere EPROM-Module zuläßt.

Das EPROM-Modul muß natürlich gültige Dateien enthalten und ein dazugehöriges Verzeichnis. Zunächst ist jedoch ein 256K-EPROM-Modul mit einer Organisation von 16 mal 16 KByte analog dem 256K-RAM-Modul M032 herzustellen. Dazu sind am besten die segmented-ROM-Module (M033, M037, M045, M046, M047) geeignet. Das neue Modul habe ich analog der bekannten Module M048 genannt:

Das umgebaute und mit 4 EPROM's 27512 bestückte Modul ist funktionskompatibel zum 256K-RAM-Modul M032. Folgende Änderung sind erforderlich und können an den Schaltungsunterlagen nachvollzogen werden:

1. Strukturbyte 73H ergibt sich bei folgender Brückenbelegung:

RB01 = geschlossen
RB06 = offen
RB07 = offen
RB08 = offen

2. AB13 wird direkt zum EPROM geführt (für 16K-Blockgröße):

AB13 -> D05-Pin8
D05-Pin9 -> EPROM's-Pin26
D02-Pin6 -> auf Masse legen (Pin7)

3. Blockauswahl im EPROM auf A14/A15 umlegen:

EPROM-Pin27 -> RB03/RB04 (Adresse A14), Brücke RB04 gesetzt
EPROM-Pin1 -> RB02/RB05 (Adresse A15), Brücke RB05 gesetzt

Nun noch ein paar Worte zum Erstellen der EPROM's. Zunächst sollte man sich 256K der Dateien heraussuchen, die man am häufigsten benötigt und ständig verfügbar haben möchte. Die tatsächlichen Dateigrößen sind dabei auf volle 4K-Gruppen aufzurunden, da bei RAM-Floppy's ab 1 MByte 4K-Gruppen verwendet werden. Da im EPROM-Modul auch ein Verzeichnis untergebracht werden soll, muß die letzte im Modul befindliche Datei mindestens 4 freie Sektoren in der letzten 4K-Gruppe enthalten.

Eine der zu verwendenden Dateien erfüllt sicher diese Bedingung und kann an das Ende des Moduls geschrieben werden. In diese 4 Sektoren ist das Modulverzeichnis einzutragen, das vom Startprogramm gelesen und in das Verzeichnis des RAM-Floppys übertragen wird.

Das Modulverzeichnis habe ich ähnlich dem Verzeichnis im CP/M-System gewählt, mit dem Unterschied, daß noch keine Blocknummern vergeben wurden. Die Blocknummern sind ja abhängig von der RAM-Floppy-Größe und vom Steckplatz des Moduls. Im Modulverzeichnis steht neben dem Dateinamen nur der relative Dateibeginn (zum Modulanfang) und die Dateigröße. Ein Verzeichniseintrag belegt 16 Byte, somit sind in den 4 Sektoren insgesamt 64 Einträge möglich. Jeder Eintrag hat den folgenden Aufbau:

Byte 0	USER-Bereich der Datei (E5H, wenn nicht belegt!)
Byte 1-11	Dateiname (mit entsprechend gesetzten Attributen)
Byte 12	letzte Extentnummer (Anzahl 16K-Blöcke)
Byte 13,14	Startsektor im Modul
Byte 15	Anzahl Sektoren im letzten Extent

Auch bei Dateien größer als 16 KByte ist nur ein Eintrag erforderlich, im Byte 12 steht die letzte Extentnummer und im Byte 15 wieviele Sektoren der letzte Extent belegt. Mit diesen Angaben berechnet das Startprogramm den vollständigen Directory-Eintrag für das Laufwerk A:. Als Beispiel hier die ersten vier Einträge meines Modulverzeichnisses:

00 41 53 4D 20 20 20 20 20 C3 CF 4D 01 00 00 20  .ASM_____COM...
00 43 4F 50 59 20 20 20 20 C3 CF 4D 00 A0 00 20  .COPY____COM...
00 44 55 20 20 20 20 20 20 C3 CF 4D 00 C0 00 50  .DU______COM...
00 4C 4E 4B 20 20 20 20 20 C3 CF 4D 00 20 01 60  .LINK____COM...

• Der erste Eintrag gehört der Datei ASM.COM, Extent 0 ist voll und belegt 128 Sektoren, im Extent 1 sind weitere 32 Sektoren. Insgesamt ist die Datei also 160 Sektoren groß und belegt genau 20 KByte. Als letzte Datei ist diese somit nicht geeignet.
• Der zweite Eintrag gehört der Datei COPY.COM. Startsektor im Modul ist 00A0H, also direkt nach ASM.COM. Auch diese Datei ist mit 32 Sektoren und genau 4 KByte nicht als letzte Datei geeignet.
• Die dritte Datei im Modul heißt DU.COM, beginnt im Sektor 00C0H im Modul und ist 80 Sektoren groß. Das entspricht einer Dateigröße von 10 KByte, da aber auf volle 4K-Gruppen aufgerundet werden muß, sind 12 KByte zu reservieren. Wenn diese Datei am Modulende untergebracht würde, könnte hier das Modulverzeichnis eingetragen werden.
• Die vierte Datei LINK.COM beginnt also jetzt nach den vollen 12 KByte, die für DU.COM reserviert wurden. Startsektor ist somit 0120H. Bei der Dateigröße mit 96 Sektoren und genau 12 KByte wäre kein Platz für das Modulverzeichnis.

Dateien wie DU.COM, die bei 2K-Gruppen einen Block weniger belegen, also mehr als 15 freie Sektoren enthalten, lassen logischerweise einen freien Block im EPROM-Bereich offen. Das EPROM-Modul sollte deshalb auf dem höchsten Steckplatz stecken, da ein Beschreiben dieser Blöcke ist nicht gesperrt ist. Als Alternative könnte man diese Dateien auch um soviele Sektoren verlängern, damit kein freier Block mehr entsteht.

Es sollte jedoch vorher getestet werden, ob die Datei dann noch voll funktionsfähig ist! Alle Dateien des EPROM-Floppys befinden bei mir im USER-Bereich 0 und besitzen das R/O- und das SYS- Attribut. Das hat den Vorteil, daß die Dateien auch von anderen USER-Bereichen aufrufbar sind und nicht so einfach zu löschen sind.

Ausblick zum Z-System

Um alle Eigenschaften der Festplatte voll ausnutzen zu können, empfiehlt sich die Verwendung eines Z-Systems. Was sich darunter versteht, kann z.B. in den KC-News 4/94 nachgelesen werden. Dieses Z-System läßt sich auf einfache Art und Weise mit dem zur Verfügung stehenden Minimalsystem installieren. Es erkennt automatisch die Adressen des Systems und ersetzt CCP und BDOS. Die weiteren Systemkomponenten sind dabei in Grenzen frei definierbar. Mein System enthält zur Zeit folgende Belegung:

C400H	Kommandoprozessor ZCPR 3.4
CC00H	ZSDOS 1.0
DA00H	BIOS-Erweiterung des Z-Systems
DB00H	RCP (10 Sektoren, RCP09H + PORT + KEY + CAOS)
E000H	FCP (4 Sektoren)
E200H	21 Directory-Namen
E380H	Shell Stack (4 Einträge)
E400H	Environmentbeschreibung ENV
E480H	Terminaldefinition TCAP
E500H	Message-Buffer
E550H	Externer FCB (XFCB)
E574H	Suchpfad (5 Elemente)
E57FH	Wheel-Byte
E580H	Kommandozeilenpuffer MCL
E650H	System-Stack
E680H	DateStamper (USER-Speicherbereich von NZ-COM)
E900H	KC-BIOS (mit 42 MByte Festplatte)

An dieser Stelle werden sich einige fragen wozu diese Sachen alle gut sind. Man muß das auch nicht wissen: Die Programme, die für das Z-System geschrieben wurden, greifen darauf zu und passen sich dem eigenen System an ohne daß man etwas davon merkt. Einfacher geht es wirklich nicht.

Da man sich nicht merken kann, in welchen USER-Bereichen man welche Daten abgelegt hat, sind 21 Directory-Namen für Festplattensysteme mindestens zu empfehlen, eventuell wird diese Anzahl nicht mal ausreichen und ich werde bei Bedarf die nächsthöhere Anzahl einstellen müssen. Dann verschieben sich alle darunterliegenden Systemkomponenten zu Lasten des TPA um z. B. 100H Bytes.

Zur Installation von DateStamper(tm) habe ich bereits einen Uhrentreiber UHRKC.REL vorbereitet, der mit meinem ZBIOS zusammenarbeitet. Für NZ-COM ist das BIO-Modul durch die Version NZBIOKC.ZRL zu ersetzen, damit auch die BIOS-Sprünge mit Offset 33H und 36H korrekt weitergeleitet werden. DateStamper selbst habe ich im USER-Speicher des Z-Systems untergebracht, 5 Records (640 Bytes) sind dafür ausreichend.

Weiterhin ist für den KC85 bereits ein spezieller RCP entstanden. Dieser benötigt 10 Sektoren und basiert auf RCP09H.ZRL. Zusätzliche stehen in RCP10H.ZRL die Befehle CAOS, KEY und PORT zur Verfügung:

• CAOS geht zurück zum CAOS-System und entspricht dem MicroDOS-Kommando 0. Wird mit ZAS gearbeitet kann man mit QUIT von dort sofort wieder zum Z-System zurück.
• KEY ohne Argumente listet die F-Tasten auf, dies entspricht dem bisherigen Kommando 2.
• KEY mit folgender Nummer belegt eine F-Taste entsprechend dem bisherigen Kommando 3, die Nummer der F-Taste ist jedoch dezimal anzugeben. KEY 0 löscht alle F-Tasten, jedoch nur unter CAOS 4.3
• Das Kommando PORT fand ebenfalls noch Platz und ermöglicht direkte Port-ein/ausgaben. Dies kann unter Umständen zum Testen des GIDE-Interfaces bzw. der RTC-Uhr hilfreich sein.

Wer sich nicht das komplette NZ-COM zulegen will, hat noch die Möglichkeit, ein 'geblitztes' Z-System zu benutzen. Was ist darunter zu verstehen? Von einem laufenden Z-System wird ein Speicherabzug in Form einer ausführbaren COM-Datei erstellt. Diese COM-Datei geladen, erhält mann das Z-System mit den selben Eigenschaften wie vor dem Abspeichern zurück. Nachträglich ist es jetzt nur nicht mehr möglich, Speicherbereiche zu verändern um z.B. die Anzahl der Directorynamen weiter zu erhöhen oder neue Module einzubinden - die Flexibilität von NZ-COM fällt also weg und man müßte sich für ein System entscheiden.

Die Festplatte unter CAOS

Um auch im CAOS mit der Festplatte arbeiten zu können, ist ein neues DEP und eine CAOS-Startdiskette mit dem neuen System erforderlich. Zur Zeit erarbeite ich eine neue Version von DEP. Zwei Varianten teste ich gerade, bin jedoch noch nicht soweit daß eine Weitergabe sinnvoll ist. Ich gehe davon aus, daß DEP 3.0 fertig ist wenn es gebraucht wird - also dann wenn die ersten Festplatten laufen.

Ich möchte an dieser Stelle nur mal einen Ausblick geben, wie der momentane Stand ist. Alle Ausführungen haben nur informativen Charakter, mit der Fertigstellung wird an dieser Stelle sicher wieder etwas zu lesen sein.

DEP starte ich zur Zeit direkt vom laufenden CP/M oder Z-System aus. Dabei wird automatisch zur CAOS-Betriebsart gewechselt. Geplant habe ich, DEP+BDOS+BIOS in die Systemspuren der CAOS-Diskette zu schreiben. Damit fällt dann die INITIAL.UUU und DEP.COM auf der CAOS-Diskette weg. DEP ersetzt also den CCP des im Hintergrund laufenden CP/M-Systems. Für den Anwender und Programmierer unter CAOS bleibt (fast) alles wie gewohnt, alle alten Funktionen sind kompatibel zu den bisherigen DEP-Versionen.

DEP 3.0 paßt sich beim Start automatisch dem laufendem System an. Dies ist erforderlich, da es keine festgelegten Adressen mehr gibt. Je nachdem, wieviel freier TPA gefunden wird, ist die Kapazität des RAM-Laufwerkes A: auch unterschiedlich groß. Ich habe zwei Varianten von getestet: DEP3S.COM sortiert bis zu 255 Dateinamen, benötigt aber gegenüber DEP3N.COM 2.75K mehr Speicherplatz. Ich bevorzuge es, die Dateinamen alphabetisch sortiert zu erhalten, man findet die gesuchten Programme schneller.

Natürlich benötigt die Sortierung auch etwas Zeit, aber bis ca. 100 Dateinamen ist dies kaum zu spüren. Aus diesem Grund habe ich die Sortierung auch auf 255 Dateinamen begrenzt, die Dateinamen werden dann unsortiert angezeigt - verloren geht also nichts. Die Sortierung im D004 dürfte trotzdem aufgrund der höheren Taktfrequenz schneller ablaufen als im Grundgerät. Ich denke noch nach, die Sortierung über ein Optionsbyte im Koppel-RAM zu-/abzuschalten, der Grundzustand wird dabei mit Sortierung sein.

Um einen Vergleich zu haben, hier mal die erreichten RAM-Floppy-Kapazitäten bei meinem System mit 42MB-Festplatte in Gegenüberstellung zu DEP 2.2 und MicroDOS:

	MicroDOS	CP/M	Z-System
TPA-Ende:	C900H	DB00H	CC00H
DEP22.COM	46K frei	-	-
DEP3N.COM	-	51K frei	47K frei
DEP3S.COM	-	48K frei	44K frei

Mit dem neuen System ist also auch mit Sortieralgorithmus eine größere RAM-Floppy-Kapazität erreichbar als mit dem bisherigen DEP und MicroDOS. Das verdanken wir dem aufgeräumten System und der Möglichkeit, den CCP überschreiben zu können. Selbst wenn ich DEP3S.COM vom voll konfigurierten Z-System aus starte, stehen mir immerhin noch 44K zur freien Verfügung, was für die meisten Anwendungen ausreichen dürfte.

An dieser Stelle will ich noch kurz aufführen, was DEP 3.0 bereits von DEP 2.2 unterscheidet:

• Größe des RAM-Floppy wird beim Start automatisch errechnet.
  
  
• die USER-Bereiche im Dateinamen sind dezimal anzugeben
  Beispiel: D15:WORDPRO6 (bisher DF:WORDPRO6)
  
  
• veränderte STAT-Meldung, damit die freie Kapazität großer Festplatten 5-stellig angezeigt werden kann. Laufwerk und USER-Bereich werden stets vorangestellt.
  Beispiel: C10> 10500K frei.
  
  
• Im Fehlertext wird jetzt der Dateiname ebenfalls mit Laufwerk und USER-Bereich ergänzt.
  
  
• Überprüfung der Dateinamen nach gültigen Konventionen unter CP/M, Kleinbuchstaben werden in Großbuchstaben umgewandelt, Steuerzeichen und Zeichen > 7EH sind ebenfalls verboten. Das Zeichen '*' wird als Jokerzeichen jeweils für den Rest des Dateinamen bzw. Dateityp interpretiert. Jokerzeichen sind im Kommando ERA und im 2. Name bei REN möglich.
  Beispiel:
  %ERA *.BAK (löscht alle BAK-Files)
  %REN
  alter Name: EDAS164.KCC
  neuer Name: EDAS.* (umbenennen in EDAS.KCC)
  
  
• alphabetische Sortierung von bis zu 255 DIR-Einträgen.
  
  
• Bereitstellung der Uhrzeit und des Systemdatums im Koppel-RAM.
  
  

Die Zukunft beginnt mit "Z" - Teil 1

von Jörg Linder

Einleitung

Wer meine Vorliebe für das Z-System kennt und auf unserem '96er Clubtreffen war, ahnt sicherlich schon, was ihn hier erwartet. Doch in dieser Artikelreihe soll es nicht nur um den ZCPR gehen, sondern auch um das zukünftige CP/M-kompatible System für den KC. Auf dem Treffen konnte uns Mario Leubner schon einiges zeigen. In dieser Reihe will ich zeigen, was "dahinter" steckt.

In seinem Artikel zum neuen System hat Mario bereits geschildert, welch unschätzbare Mühe er sich mit der Entwicklung gemacht hat. Dank Helmut Jungkunz sind wir auf ein wunderbares Betriebssystem namens ZSDOS gestoßen. Mario ist die Anpassung des ZSDOS für unser D004 gelungen, wobei ein nagelneues (und vor allem CP/M-konformes) System herauskam.

Bemerkenswert ist dabei die Verwendung von rein Z80-codierten Segmenten. Normale CP/M-Systeme sind nämlich für i8080-Prozessoren geschrieben. Der Z80-Befehlssatz ist zwar voll kompatibel, wird aber nicht ausgenutzt. Programme für Z80-Rechner sind daher oftmals kleiner und trotzdem leistungsfähiger als i8080-Programme. Bevor wir uns jedoch vollends ins Vergnügen stürzen, sollten zunächst die verwendeten Begriffe erläutert werden.

Begriffe

Die Abkürzung ZCPR bedeutet "Z80 Command Processor Replacement" - zu deutsch: Z80-Ersatz des Kommandoprozessors. Was voerst recht nüchtern klingt, enthält vielfältige und fantastische Möglichkeiten. Der Kommandoprozessor stellt die Schnittstelle des Systems zum Anwender dar. Jede Veränderung dieses Segments hat also direkte Auswirkungen auf das Erscheinungsbild des Systems. Die inzwischen aktuelle Version 3.4 ist so komfortabel und flexibel, daß individuelle Anpassungen in Sekundenschnelle vorgenommen werden können und dabei kaum noch Wünsche offen bleiben.

ZSDOS steht für "Z-System Disk Operating System" - Diskettenbetriebssystem für Z-Systeme. Das ZSDOS ist eines der wenigen kommerziellen Ersatzsysteme für das BDOS des CP/M 2.2 und wahrscheinlich auch das beste. Es arbeitet "eine Schicht tiefer" im CP/M-System und stellt die Schnittstelle für alle Anwendungsprogramme dar. Veränderungen des BDOS-Segmentes offenbaren sich dem Nutzer nur spärlich, sind jedoch gravierend, wenn es um die Stabilität und die Geschwindigkeit des Systems geht. In ZSDOS können viele Einstellungen vorgenommen werden, die das Verhalten des Systems bestimmen.

Ein "Z-System" ist sozusagen das beste, was einem CP/M-Anwender passieren kann. Mit diesem Begriff werden CP/M-Systeme bezeichnet, deren Segmente vollständig in Z80 codiert sind. Das neue Betriebssystem für das D004 wird ein derartiges System sein; daher beginnt für uns die Zukunft mit einem "Z".

Artikelreihe

Dieser Beitrag ist der Auftakt einer Artikelreihe, die in den nächsten Ausgaben der KC-News weitergeführt wird. Ich habe mich aus zwei Gründen für eine Serie entschieden. Zum einen wäre der Gesamtumfang für eine Ausgabe zu groß. Zum anderen denke ich, daß eine Beschäftigung mit den Komponenten eines Z-Systems über einen längeren Zeitraum das Wissen festigt. Somit hat man eine bessere Grundlage beim "Erstkontakt" mit dem neuen System.

Einen Ersatz für das Handbuch wird diese Serie nicht darstellen. Dafür werde ich aber versuchen, auf Fragen zu reagieren und eventuell auftretende Probleme zu lösen. Ergebnisse werden innerhalb dieser Reihe veröffentlicht, wodurch diese gewissermaßen interaktiv wird (bzw. werden soll).

Nach dem derzeitigen Planungsstand wird hier folgendes zu lesen sein:

Teil 1 - Einleitung, ZSDOS
Teil 2 - ZCPR, Zusammenspiel der Komponenten
Teil 3 - Anwendungsbeispiele, Problemlösungen

ZSDOS

Die Entwicklung des ZSDOS war eine Gemeinschaftsarbeit von Harold F. Bower, Cameron W. Cotrill und Carson Wilson. Anhand der Namen kann man schon erkennen: made in U.S.A. Während der Programmierung sind die unterschiedlichsten Anregungen und Vorschläge in die Arbeit eingeflossen. Das ZSDOS ist einer der mächtigsten (das mächtigste?) und flexibelsten BDOS-Ersatzsysteme, die je für das CP/M-System geschrieben wurden. Es ist unmöglich, alle Funktionen und Verbesserungen in diesem Artikel aufzuzählen. Die wichtigsten möchte ich jedoch vorstellen.

Alle Fehlermeldungen des BDOS werden in (englischem) Klartext ausgegeben. Anstelle unverständlicher Zahlen für Sektoren und Spuren erscheinen nun Funktionsnummer und Dateiname, bei denen der Fehler aufgetreten ist. Darüberhinaus kann (wie bei MicroDOS, jedoch fehlerfrei) die Fehlerbehandlung vom Programm übernommen werden. In diesem Modus werden keine Fehlermeldungen auf den Bildschirm ausgegeben.

ZSDOS unterstützt nicht nur die beiden bekannten Dateiattribute "schreibgeschützt" (R/O) und "System", sondern auch sechs weitere. Unter anderem auch das Archivbit, mit dessen Hilfe Sicherheitskopien schneller und unkomplizierter erstellt werden können.

Die zulässige Größe für Laufwerke beträgt 1 Gigabyte (1.084.576 kByte). Dateien können bis zu 32 Megabyte (32.768 kByte) groß sein und im wahlfreien Zugriff bis zu 262.144 logische Records umfassen. Darüberhinaus gibt es die Möglichkeit, Laufwerke als "fest" zu definieren. Das Verzeichnis dieser Laufwerke wird dann nicht nach jedem Warmstart erneut eingelesen, was die Arbeit wesentlich beschleunigt.

Zu den interessantesten Eigenschaften gehören auf jeden Fall die unterschiedlichen Zugriffsarten. Normalerweise werden von CP/M nur Dateien gefunden, die sich im eingeloggten Verzeichnis befinden. Alle Dateien, die auf einem anderen Laufwerk und/oder in einem anderen Nutzerbereich vorliegen, kann CP/M nicht finden und demzufolge auch nicht laden. Unter ZSDOS gibt es diverse Möglichkeiten, diese Beschränkung zu überwinden - öffentliche Dateien und den DOS-Pfad. Beide Zugriffsarten können sogar kombiniert werden. Erfahrene Anwender können dadurch nahezu jede Datei von allen Verzeichnissen erreichen.

Beim Zugriff auf andere Nutzerbereiche wird die Nummer des Bereichs im FCB gespeichert und automatisch vom System verwaltet. Ein Programm kann nun auf die Datei im anderen Nutzerbereich zugreifen, ohne vorher über die entsprechende BDOS-Funktion den Nutzerbereich zu setzen.

Mit der Echtzeituhr des GIDE-Interfaces steht im neuen System auch eine "richtige" Uhr zur Verfügung. Von ZSDOS bzw. ZDDOS werden Datumsstempel für Dateien unterstützt. Zu jeder Datei können der Zeitpunkt der Erstellung, der Änderung und des letzten Zugriffs gespeichert werden. Dadurch wird die Verwaltung wesentlich transparenter, insbesondere bei mehreren Versionen einer Datei.

Außerdem lassen sich viele Eigenschaften von ZSDOS während der Laufzeit über ein spezielles Utility einstellen. Somit kann das System für spezielle Anwendungen angepaßt werden. Nach Abarbeitung kann man einfach wieder die alten Parameter einstellen.

So, das soll es für heute gewesen sein. In der nächsten Ausgabe folgt wie versprochen der Artikel zu ZCPR...

SPEAKER'S CORNER

Joachim Dittmanns Geheimtip:

Bildschirmfilter

Obwohl nicht am Umsatz beteiligt, empfehle ich dennoch Bildschirmfilter. Sie werden von verschiedenen Unternehmen angeboten. Die Bildschirmfilter für 14" Monitore bestehen aus einer Art Sieb und werden komplett mit Befestigung zum Preise ab 24,95 DM geliefert. Sogar die Direkt-Spiegelung eines Südseite-Fensters wird zu 90 % absorbiert. Das Bild wird klarer,die Auflösung besser. Z.B. hatte ich noch nie vorher ein so gutes TV-Bild wie mit Filter.

Vorbehalte? Vergeßt sie und gönnt Euren Augen etwas gutes!

Inhaltsverzeichnis sämtlicher KC-News

Für meine Sammelmappe mit den KC-News habe ich mir ein Inhaltsverzeichnis angelegt, mit dem ich schnell einen Beitrag zu einem bestimmten Thema auffinden kann. Damit diese Arbeit nicht jeder selbst nochmal hat, stelle ich dieses als Textdatei KC-NEWS.TXW im WordPro6-Format zur Verfügung. Die Steuerzeichen am Textanfang sind für meinen LQ-100 und müßten mit jedem anderen EPSON-kompatiblen Drucker genauso gedruckt werden.

Mario Leubner

Bitte Porto beachten!

Immer wieder treffen Briefe ein, zu denen ich "Strafporto" bezahlen muß. Das muß nicht sein, denn dann wird der Briefverkehr noch teurer als er ohnehin schon ist, denn die Nachgebühr ist noch höher als das normale Porto! Deshalb an dieser Stelle nochmal die Gebühren - auch wenn die Post bereits die nächste Erhöhung der Preise angekündigt hat:

• normaler Brief bis 20g 1,- DM
• normaler Brief mit 3,5"-Diskette 2,- DM
• A5-Brief mit oder ohne Diskette 3,- DM

Mario Leubner

Netzteilprobleme

Kurz vor dem Treffen in Erfurt fiel bei mir das Netzteil, genauer gesagt nur die +5Volt-Versorgung, der Floppy aus. Nach Tips von anderen Usern wechselte ich den Transistor SD347 , der an der rechten Gehäuseseite am senkrechten Aluminiumkühlblech angeschraubt ist, auf Verdacht aus. Damit war der Fehler schon behoben. Da dieser Transistor scheinbar eine Schwachstelle in der Netzteilschaltung darstellt, durchsuchte ich mein (kleines) Datenbuch nach einem Ersatz.

Die Suche nach einem stärker belastbaren Transistor mit gleicher Bauform, ähnlichen Grenzwerten, aber höherer zulässiger Verlustleistung blieb allerdings erfolglos. So bleibt bei Problemen an der +5V-Versorgung in den meisten Fällen weiterhin nur das Wechseln des SD347.

Maik Freitag

Datumsformat von SC2 ändern

Normalerweise erfolgt die Ausgabe eines Datums im Programm SC2 im (für unsere Verhältnisse ungewöhnlichen) US-Format. Zur Änderung auf das europäische Format müssen nur folgende Bytes geändert werden:

Adresse   von  auf
  5147     19   36
  5153     36   19
  5302     20   30
  5317     2F   2E
(alle Angaben in HEX)

Vielen Dank für diesen Tip an
Tilmann Reh