Festplatte am KC

von Uwe Felgentreu

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

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

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

Für die Statistiker unter uns hier die Stromaufnahmen :

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

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

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

Wie schalten wir die Adressleitungen nun durch ?

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

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

PRINT INP(85)

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

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

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

Was tut die RAM-Disk-Weiche eigentlich ?

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

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

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

Hier noch ein paar allgemeine Worte

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

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

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

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

JUMP F8, die Alternative!

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

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

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

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

Hier aber nun ein wichtiges Wort an alle Programmierer.

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

Warum das ?

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

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

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

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

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

 

Anmerkungen der Redaktion:

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

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

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