DE69030861T2

DE69030861T2 - Bus-Master-Steuerprotokoll

Info

Publication number: DE69030861T2
Application number: DE69030861T
Authority: DE
Inventors: David L Flower; David L Grant; David E Neufeld; David S Schmenk; Stephen M Schultz
Original assignee: Compaq Computer Corp
Current assignee: Compaq Computer Corp
Priority date: 1989-11-03
Filing date: 1990-11-02
Publication date: 1998-01-15
Anticipated expiration: 2010-11-03
Also published as: EP0426184A2; CA2029199A1; US5249279A; EP0426184B1; EP0426184A3; DE69030861D1

Description

Die Erfindung betrifft die Steuerung von Mehrfach-Plattenlaufwerken in Rechnersystemen, insbesondere Befehlsprotokoll und -definition, wie sie zur Erleichterung von Hochgeschwindigkeits-Datentransfers für Personal- Computer-Systeme verwendet werden.
Mikroprozessoren und Personal-Computer, die sie verwenden, sind in den vergangenen Jahren leistungsstärker geworden. Derzeit verfügbare Personal-Computer haben Kapazitäten, die mühelos die der Großrechner von vor 20 bis 30 Jahren überschreiten, und besitzen die Fähigkeiten zahlreicher derzeit hergestellter Rechner. Mikroprozessoren mit Wortbreiten von 32 Bits sind derzeit in großem Umfang verfügbar, während in der Vergangenheit 8 Bits konventionell und 16 Bits üblich waren.
Personal-Computer-Systeme sind im Laufe der Jahre entwickelt worden, und täglich werden neue Einsatzmöglichkeiten entdeckt. Die Verwendungen variieren, und demzufolge weisen sie verschiedene Anforderungen für verschiedene Subsysteme auf, die ein vollständiges Rechnersystem bilden. Wegen Anforderungen bezüglich des Fertigungsvolumens und den verringerten Kosten bei gesteigerten Größen ist es wünschenswert, daß möglichst viel gemeinsame Merkmale in umfangreichen Einheiten zusammengefaßt werden. Dies ist auf dem Gebiet der Personal-Computer durch die Entwicklung einer Grundsystemeinheit geschehen, die im allgemeinen eine Stromversorgung, Einrichtungen zur baulichen Unterbringung der verschiedenen Massenspeichereinrichtungen und eine Systemplatine enthält, die ihrerseits einen Mikroprozessor, zu dem Mikroprozessor gehörigen Schaltungen, Verbinder zur Aufnahme von Schaltungsplatinen, die weitere Subsysteme enthalten, Schnittstellen- Schaltungen für die Schnittstellen zwischen den Schaltungsplatinen und dem Mikroprozessor und Speicher enthalten. Der Einsatz von Verbindern und austauschbarer Schaltungsplatinen macht es möglich, Subsysteme gewünschter Kapazität für jedes Rechnersystem mühelos in das Rechnersystem einzubeziehen. Der Einsatz von austauschbaren Schaltungsplatinen erfordert die Entwicklung einer Schnittstellen- oder Bus-Norm, so daß das Subsystem einfach ausgelegt werden kann und sich keine Probleme aus nicht kompatiblen Entscheidungen der Systementwerfer einerseits und der Entwerfer der austauschbaren Schaltungsplatine andererseits ergeben.
Die Verwendung austauschbarer Schaltungsplatinen und einer Schnittstellen-Norm, üblicherweise als Bus-Spezifikation bezeichnet, weil die verschiedenen Signale für sämtliche Verbinder über einen Bus geleitet werden, war Gegenstand des ursprünglichen Personal-Computers der International Business Machines Corporation (IBM), dem IBM PC. Der IBM PC verwendet als Mikroprozessor einen Intel-Corporation 8088. Der 8088 besitzt eine 8 Bits oder 1 Byte umfassende externe Datenschnittstelle, arbeitet aber intern auf der Grundlage eines 16 Bits umfassenden Worts. Der 8088 besitzt 20 Adreßleitungen, was bedeutet, daß er maximal 1 Mbyte Speicher direkt adressieren kann. Darüber hinaus waren die für die Einbeziehung in den ursprünglichen IBM-PC verfügbaren Speicherkomponenten relativ langsam und teuer im Vergleich zu derzeitigen Bauelementen. Die verschiedenen Subsysteme, beispielsweise Videoausgabeeinheiten oder Massenspeichereinheiten, waren nicht komplex und besaßen außerdem relativ geringe Leistungsstufen aufgrund der relativen Einfachheit der verfügbaren Bauelemente bei vernünftigen Kosten zu jener Zeit.
Eingedenk dieser verschiedenen Faktoren und Bauelement-Wahlmöglichkeiten wurde eine Schnittstellen-Norm entwickelt und in dem IBM- PC verwendet. Die Norm verwendete 20 Adressenleitungen und 8 Datenleitungen, besaß individuelle Leitungen zum Kennzeichnen von Operationen im Eingangs- oder Ausgangs-Raum (E/A) oder Lese- /Schreib-Operationen im Speicherbereich, und besaß eine beschränkte Verfügbarkeit für Unterbrechungen und Direktspeicherzugriffs-Kanäle (DMA). Die Komplexität der verfügbaren Komponenten erforderte keine größere Flexibilität oder Kapazitäten der Schnittstellen-Norm, um die notwendigen Operationen zu ermöglichen. Diese Schnittstellen-Norm war für eine Reihe von Jahren zufriedenstellend.
Wie in der Rechner- und Elektronikindustrie unvermeidlich, verbesserten sich die Kapazitäten der verschiedenen verfügbaren Bauteile dramatisch. Preise für Speicherbauelemente fielen, Kapazitäten und Arbeitsgeschwindigkeiten nahmen zu. Die Leistungsfähigkeit und die Kapazitäten von Massenspeicher-Subsystemen nahmen zu, im allgemeinen durch die Einbeziehung von Festplatteneinheiten für frühere Floppy-Disk-Laufwerke. Die Videoprozessor-Technologie wurde derart verbessert, daß hochauflösende Farbsysteme zu vernünftigen Preisen erschwinglich wurden. Diese Entwicklungen beschleunigten die Kapazitäten der existierenden IBM-PC-Schnittstellennorm derart, daß die zahlreichen Beschränkungen der Schnittstellen-Norm zu einem Problem wurden. Mit der Einführung des 80286 der Intel Corporation entwickelte IBM einen neuen, leistungsstärkeren Personal-Computer mit der Bezeichnung AT. Der 80286 besitzt einen 16 Bits umfassenden Datenweg und 24 Adreßleitungen, so daß er direkt 16 Mbyte Speicher adressieren kann. Darüber hinaus besitzt der 80286 eine erhöhte Arbeitsgeschwindigkeit und kann mühelos zahlreiche Operationen ausführen, die die Leistungsgrenzen für den 8088 darstellten.
Erwünscht war, daß die vorhandenen Subsystem-Schaltungsplatinen in der Lage waren, in dem neuen AT eingesetzt zu werden, so daß die in dem PC verwendete Schnittstellen-Norm genutzt und erweitert wurde. Es wurde eine neue Schnittstellen-Norm entwickelt, die unter der Bezeichnung Industriestandard-Architektur (ISA) bekannt wurde. Es wurde ein zweiter Steckverbinder für jeden Steckplatz hinzugefügt, um zusätzliche Leitungen für die Signale zu haben, die in der Erweiterung verwendet werden. Diese Leitungen enthielten zusätzliche Adressen- und Datenleitungen, um die 24 Bits umfassende Adressierfähigkeit sowie 16 Bits umfassende Datentransfers nutzen zu können, außerdem gab es zusätzliche Unterbrechungs- und Direktspeicherzugriffs-Leitungen sowie Leitungen zum Kennzeichnen, ob die Subsystem-Schaltungsplatine in der Lage war, die erweiterten Merkmale zu nutzen. Während die Adressenwerte von dem 80286 Mikroprozessor innerhalb des Arbeitszyklus relativ früh angeboten werden, konnte die PC-Schnittstellen-Norm die einleitenden Abschnitte der Adressenverfügbarkeit deshalb nicht nutzen, weil es andere Zeitsteuer-Normen für den 8088 gab, um den herum die PC-Schnittstelle ausgestaltet war. Dies beschränkte die Geschwindigkeit, mit der Operationen ausgeführt werden konnten, weil sie nun auf die Schnittstellen-Norm-Spezifikationen für den zeitlichen Ablauf im Speicher beschränkt waren und nicht mit den Geschwindigkeiten arbeiten konnten, die mit dem 80286 verfügbar waren. Deshalb enthielten die neu hinzugekommenen Adressenleitungen vorab verfügbare Adressensignale, jedoch waren die neu hinzugefügten Signale innerhalb des Zyklus zu einem frühen Zeitpunkt verfügbar. Diese Änderung des zeitlichen Ablaufs der Adressensignale ermöglichte eine raschere Ausführung von Operationen, die die erweiterten Bereiche der Architektur benutzten.
Mit der Verfügbarkeit von Bauelementen höherer Leistung wurde es möglich, eine andere Haupteinheit verfügbar zu haben als den System- Mikroprozessor oder eine den Bus betreibende Direktspeicherzugriffs- Steuerung. Wegen der Notwendigkeit allerdings, mit Schaltungsplatinen zusammenzuarbeiten, die unter dem neuen 16-Bit-Standard oder dem alten 8-Bit-Standard arbeiteten, mußte jede Haupteinheit sämtliche möglichen Kombinationen von Schaltungsplatinen verstehen und mit ihnen arbeiten können. Dies erhöhte die Komplexität der Haupteinheit und führte zu einer Verdopplung der Bauelemente, weil die Haupteinheit viele von denjenigen Funktionen und Merkmalen beinhalten mußte, die bereits von der Logik und der Schaltung auf der Systemplatine und anderen Haupteinheiten ausgeführt wurden. Außerdem mußte die Haupteinheit die Direktspeicherzugriffs-Steuerung verwenden, um die Steuerung des Busses übernehmen zu können, wodurch die Prioritätsverteilung und die Anzahl von möglichen Haupteinheiten in einem gegebenen Rechnersystem beschränkt wurden.
Die Steigerung der Kapazität der Bauelemente hielt an. Die Speicherzugriffsgeschwindigkeiten und -größen nahmen zu, Massenspeichereinheiten und deren Größe wurden gesteigert, die Auflösungen von Videoeinheiten nahmen zu, und es wurde der Intel-80386 eingeführt. Die gesteigerten Möglichkeiten der Bauelemente führten zu dem Wunsch, Bus-Master-Einheiten zu verwenden, allerdings war die Leistungsfähigkeit einer Bus-Master-Einheit beschränkt durch die ISA-Spezifikation und die Kapazitäten. Der 80386 konnte deshalb nicht voll genutzt werden, weil er die Möglichkeit bot, direkt 4 Gbyte eines Speichers mit Hilfe von 32 Adressen-Bits zu adressieren und 32 Bit breite Datentransfers abzuwickeln, während die ISA-Norm lediglich 16 Daten-Bits und 24 Adressen-Bits zuließ. Das Konzept des lokalen Netzwerks (LAN; Local Area Network), nach welchem Information und Datei, die in einem als Server bezeichneten Rechner gespeichert und auf lokale Arbeitsplätze verteilt waren, die beschränkte oder überhaupt keine Massenspeichermöglichkeiten hatten, wurde mit relativ geringem Kostenaufwand mit hoher Bauelementleistung, wie sie für angemessene Server erforderlich war, und bei geringen Kosten für die Bauteile der Arbeitsplätze in die Praxis eingeführt. Es konnte eine Erweiterung ähnlich derjenigen, die bei der Entwicklung der ISA erfolgt war, realisiert werden, um die Möglichkeiten des 80386 zu nutzen. Allerdings hatte dieser Erweiterungstyp gewisse Nachteile. Mit dem Aufkommen des LAN-Konzepts und den Hochleistungsanforderungen des Servers und den Videografik-Arbeitsplätzen, die beim rechnergestützten Entwurf und der Animations-Arbeit eingesetzt wurden, wurde der Bedarf an sehr hohen Datentransfergeschwindigkeiten kritisch. Eine Erweiterung ähnlich derjenigen, die bei der Entwicklung der ISA stattgefunden hatte, konnte diese Möglichkeiten auch dann nicht bieten, wenn ein etwas kürzerer Norm-Zyklus geschaffen wurde, weil dies die Leistungsfähigkeit immer noch unterhalb der gewünschten Werte gehalten hätte.
Mit der zunehmenden Leistungsfähigkeit von Rechnersystemen wurde ersichtlich, daß Massenspeicher-Subsysteme, wie z. B. festinstallierte Plattenlaufwerke, eine zunehmend bedeutendere Rolle bei dem Transfer von Daten zu dem Rechnersystem und aus dem Rechnersystem spielten. In den vergangenen wenigen Jahren kam es zu einem neuen Trend solcher Speicher-Subsysteme zur Verbesserung der Datentransferleistung, der Kapazität und der Zuverlässigkeit. Bekannt ist dies allgemein als Plattengruppen-Subsystem. Ein Hauptgrund für den Wunsch, ein Plattengruppen-Subsystem aufzubauen, besteht in der Schaffung eines logischen Bauelements, welches eine sehr hohe Datentransfergeschwindigkeit aufweist. Erreicht werden kann dies durch "Gruppenbildung" mehrerer Standard-Plattenlaufwerke und Transferieren von Daten zu diesen oder von diesen Laufwerken zu dem Systemspeicher. Wenn n Laufwerke als Gruppe zusammengefaßt sind, erhöht sich die effektive Datentransfergeschwindigkeit um das n-fache. Diese als "Striping" bezeichnete Methode hatte ihren Ursprung in der Superrechner-Umgebung, in der der Transfer umfangreicher Datenmengen zu und von einem Sekundärspeicher ein häufiges Erfordernis darstellt. Mit dieser Vorgehensweise werden die schließlichen baulichen Laufwerke zu einem einzigen logischen Bauteil und können entweder durch Software oder durch Hardware implementiert werden.
In den vergangenen Jahren ist eine Anzahl von Artikeln über den Entwurf und die Verwaltung von Laufwerk-Gruppen (Arrays) veröffentlicht worden, darunter "Some Design Issues of Disk Arrays" von Spencer Ng, April 1989; IEEE; "Disk Array Systems" von Wes E. Meador, April 1989, IEEE; und "A Case for Redundant Arrays of Inexpensive Disks (RAID)" von D. Patterson, G. Gibson und R. Catts, Report Nr. UCB/CSD 87/391, Dezember 1987, Computer Science Division, University of California, Burkley, California.
Die EP-A-0 294 287 offenbart ein Beispiel für ein Speichersystem.
Die vorliegende Erfindung ist gemäß den beigefügten Ansprüchen auf ein Verfahren für ein intelligentes Plattengruppen-Steuerungssystem gerichtet, welches es der Steuerung ermöglicht, den Betrieb einer Gruppe von bis zu 8 genormten, integrierten Plattenlaufwerken zu verwalten, die zu Laufwerk-Paaren gekoppelt sind, ohne signifikante Überwachung durch den Hauptrechner des Rechnersystems. Außerdem zielt die vorliegende Erfindung ab auf ein Kommunikationsprotokoll zwischen der Plattengruppen-Steuerung und einem Hauptrechner. Die erfindungsgemäße Steuerung schafft zwei Kommunikationswege für Befehle und Daten, über die der Hauptrechner Plattenanforderungen wie Lese-, Schreib- oder Diagnosebefehle an die Plattengruppe geben kann. Diese Kommunikationswege sind bekanntlich die Kompartibilitäts-Schnittstelle und die Busmaster-Schnittstelle. Die Kompartibilitäts-Schnittstelle und die Busmaster-Schnittstelle arbeiten parallel und können alternativ oder gleichzeitig dazu eingesetzt werden, Befehle und Daten zwischen dem Hauptrechner und der Plattenlaufwerkgruppen-Steuerung zu übergeben. Die erfindungsgemäße Steuerung ist so ausgebildet, daß außerdem der Hauptprozessor unabhängig von der baulichen Konfiguration des Arrays und der Laufwerke, die die Plattengruppe bilden, ebenso unabhängig sein kann wie von der Datenverteilungsmethode, die zum Verteilen der Daten unter den Laufwerken innerhalb des Arrays eingesetzt wird, des Laufwerk-Paritätsbetriebs und den meisten Fehlernachweis- und Störungstoleranz-Aktivitäten.
Der Kommunikationsmechanismus zwischen dem Platten-Array und existierender Hauptrechner-Treibersoftware innerhalb der vorliegenden Erfindung erfolgt über die Kompartibilitäts-Schnittstelle. Diese Schnittstelle ermöglicht den Betrieb der Software, die eine Hardware-Schnittstelle erwartet, die mit existierenden ISA-Festplatten-Registersätzen kompartibel ist.
Der Kommunikationsmechanismus zwischen der Plattengruppe und der neuen Hauptrechner-Treibersoftware erfolgt über die Busmasterschnittstellensteuerung (BMIC). Die Steuerung ist in der lage, Datentransfergeschwindigkeiten über den EISA-Bus von 32 Mbyte pro Sekunde unter Verwendung von 32 Bit umfassenden Busmaster-Burst-DMA-(Typ C)Zyklen, wie sie in der EISA-Spezifikation definiert sind, über die Busmasterschnittstellensteuerung auszuführen.
Die vorliegende Erfindung zielt ab auf ein Befehlsprotokoll für die Implementierung dieses Hochgeschwindigkeits-Plattengruppen-Datentransfers. Bei der vorliegenden Erfindung gibt der Hauptrechner logische Befehle an die Plattengruppen-Steuerung, zusammengesetzt aus detaillierter Platteninformation, beispielsweise einer Plattenlaufwerk-Zahl,Kopf-, Zylinder- und Sektorinformation. Diese logischen Anforderungen werden von der Plattengruppensteuerung verarbeitet, welche die Information für den detaillierten Level entwickelt, um Funktionen innerhalb der Plattengruppe ausführen zu können, ohne diesen Aufwand dem System-Hauptrechner aufzubürden.
Ein besseres Verständnis der Erfindung ergibt sich aus der nachfolgenden detaillierten Beschreibung der bevorzugten Ausführungsform in Verbindung mit den begleitenden Zeichnungen. Es zeigen:
Fig. 1 und 2 schematische Blockdiagramme eines Rechnersystems, welches die vorliegende Erfindung beinhaltet;
Fig. 3 ein schematisches Blockdiagramm einer Plattengruppensteuerung, welche die vorliegende Erfindung beinhaltet;
Fig. 4 ein schematisches Blockdiagramm einer Busmasterschnittstellensteuerung, die die vorliegende Erfindung beinhaltet;
Fig. 5 ein schematisches Diagramm einer Befehlsliste, einschließlich des Befehlslisten-Vorsatzes und der Anforderungsblöcke;
Fig. 6 ein Flußdiagramm, welches die Art und Weise veranschaulicht, nach der E/A-Anforderungen der PlattenLaufwerksteuerung gemäß der Erfindung zugeleitet werden;
Fig. 7 ein Flußdiagramm, welches die Art und Weise zeigt, in der die Plattengruppensteuerung einem Hauptprozessor oder einem Gerätetreiber signalisiert, daß die Anforderung abgeschlossen wurde;
Fig. 8 ein Flußdiagramm der Art und Weise, wie das erfindungsgemäße Verfahren initialisiert wird;
Fig. 9A und 9B detaillierte Flußdiagramme, die die Art und Weise veranschaulichen, in der logische Befehle verarbeitet werden;
Fig. 10A und 10B Flußdiagramme der speziellen Art und Weise, in der die Plattensteuerung dem Hauptprozessor oder dem Gerätetreiber signalisiert, daß der Befehl abgeschlossen wurde;
Fig. 11 ein Flußdiagramm der Art und Weise, auf die die vorliegende Erfindung Unterbrechungen seitens entweder des EISA-Busses oder der Plattengruppensteuerung verarbeitet;
Fig. 12 ein Flußdiagramm der Art und Weise, in der die vorliegende Erfindung einen Lese-Befehl verarbeitet;
Fig. 13 ein Flußdiagramm der Art und Weise, in der die vorliegende Erfindung einen Schreib-Befehl verarbeitet;
Fig. 14A und 14B Flußdiagramme der Art und Weise, in der die vorliegende Erfindung die Konfiguration des PlattenLaufwerks einrichtet;
Fig. 15 ein Flußdiagramm der Art und Weise, in der die vorliegende Erfindung die Konfiguration für das Platten-Array festlegt;
Fig. 16 ein Flußdiagramm der Art und Weise, in der die vorliegende Erfindung einen Befehl zum Identifizieren individueller Platten- oder Plattengruppensteuerungen verarbeitet;
Fig. 17A und 17B Flußdiagramme der Art und Weise, in der die vorliegende Erfindung Transfers über den EISA- Bus verwaltet;
Fig. 18A und 18B Flußdiagramme der Art und Weise, in der die vorliegende Erfindung logische Anforderungen mit Mehrfachplazierungen für Daten verwaltet;
Fig. 19 ein Flußdiagramm der Art und Weise, in der die vorliegende Erfindung eine Transfer-Schlange verwaltet;
Fig. 20 ein Flußdiagramm der Art und Weise, in der die vorliegende Erfindung einen PEEK-Datentransfer abwickelt;
Fig. 21 Flußdiagramm der Art und Weise, in der die vorliegende Erfindung einen POKE-Datentransfer verwaltet;
Fig. 22A und 22B Flußdiagramme der Art und Weise, in der die vorliegende Erfindung eine Anforderungsliste liest, um eine Anfangszulässigkeit zu bestimmen;
Fig. 23A und 23B Flußdiagramme der Art und Weise, in der die vorliegende Erfindung ermittelt, ob eine Plattengruppen-Konfiguration zulässig ist;
Fig. 24 ein Flußdiagramm der Art und Weise, in der die vorliegende Erfindung Anzeigen über die Beendigung oder Fehler in der Ausführung einer Anforderung abarbeitet;
Fig. 25 ein Flußdiagramm der Art und Weise, die die vorliegende Erfindung abwechselnd dazu benutzen kann, die Beendigung eines Befehls zu signalisieren;
Fig. 26 ein Flußdiagramm der Art und Weise, in der die vorliegende Erfindung die Anfangsgültigkeit einer Anforderung überprüft und feststellt; und
Fig. 27 ein Flußdiagramm der Art und Weise, in der die vorliegende Erfindung spezifische Einheiteninformation für eine Einheit innerhalb des Plattenlaufwerks bestimmt.

Inhaltsverzeichnis

I. Rechnersystemüberblick
II. Plattengruppensteuerung
III. Busmasterschnittstellensteuerung
IV. Befehlsprotokoll und -definition
V. Systembetrieb
A. Überblick Befehlsvorlage
B. Überblick Befehlsabschluß-Signalisierung
C. Befehlsprotokollsystem
1. Initialisierung
2. Lokalprozessor-Unterbrechungsbehandlungsprozedur
3. logische Befehlsvorlage
4. Befehlslisten-Gliederung/-prüfung
5. Prüfung Anforderung für nächste Platte
6. Streu-/Sammel-Blocktransfer
7. BMIC-Datentransfer
8. BMIC-Datentransfer-Schlange
9. BMIC-Daten-Lesen
10. BMIC-Daten-Schreiben
11. PEEK-Modus-Datentransfer
12. POKE-Modus-Datentransfer
13. Befehlsabschluß-Signalisierung
14. Befehls-Signalisierung
15. Befehls-Abschluß-Nachsignalisierung
16. Konfigurieren Logikeinheit
17. Lesen Logikeinheiten-Konfiguration
18. Lesen Einheitenstatus
19. Identifizieren Steuerung oder Platte
20. Prüfung der Logikeinheiten-Konfiguration
VI. Schlußfolgerung

I. Rechnersystemüberblick

Bezugnehmend auf die Fig. 1 und 2 bezeichnet der Buchstabe C allgemein ein Rechnersystem, welches die vorliegende Erfindung beinhaltet. Aus Gründen der Klarheit ist das System C in zwei Teilen dargestellt, wobei die Verbindungen zwischen den Fig. 1 und 2 anhand der eingekreisten Zahlen 1 bis 8 erkenntlich ist. Das System C besteht aus emer Reihe von Blockelementen, die über vier Busse miteinander verbunden sind. In der vorliegenden Beschreibung bedeuten mnemonische Signalzeichen, bei denen den Signaldeskriptoren ein Sternchen folgt, daß das Signal bei einem logisch niedrigen Pegel aktiv ist. Signalzeichen mit Ziffern oder Bereichen zwischen spitzen Klammern beziehen sich auf jene speziellen Bits oder Stellen innerhalb eines Busses.
In Fig. 1 ist ein Rechnersystem dargestellt. Eine zentrale Verarbeitungseinheit CPU enthält einen Prozessor 20, einen numerischen Coprozessor 22 und eine Cachespeicher-Steuerung 24 und die dazugehörigen Logikschaltungen, die an einen lokalen Prozessorbus 26 angeschlossen sind. Zu der Cache-Steuerung 24 gehört ein Hochgeschwindigkeits-Cachedaten-Schreib-/Lese-Speicher 28, eine nicht-cachebare Speicheradressenkarten-Programmierlogikschaltung 30, ein nicht-cachebarer Adressenspeicher 32, eine Adressenaustausch-Zwischenspeicherschaltung 34 und einen Datenaustausch-Sendeempfänger 36. Zu der CPU gehören außerdem eine lokale Bus-Bereit-Logikschaltung 38, eine Folgeadressen- Freigabelogikschaltung 40 und eine Busanforderungs-Logikschaltung 42.
Der Prozessor 20 ist vorzugsweise ein Mikroprozessor Intel-80386. Der Prozessor 20 ist mit seinen Steuer-, Adressen- und Datenleitungen an den lokalen Prozessorbus 26 angeschlossen. Der Coprozessor 22 ist vorzugsweise ein Intel-80387 und/oder ein Weitek WTL 3167-Numerik- Coprozessor, der an den lokalen Prozessorbus 26 und an den Prozessor 20 in konventioneller Weise angeschlossen ist. Der Cache-RAM 28 ist vorzugsweise ein geeigneter statischer Hochgeschwindigkeits-Schreib- /Lese-Speicher, der an die Adressen- und Datenelemente des Busses 26 unter der Steuerung der Cache-Steuerung 24 angekoppelt ist, um die erforderlichen Cachespeicher-Operationen auszuführen. Die Cache- Steuerung 24 ist vorzugsweise eine Cache-Steuerung Intel-82385, konfiguriert für den Betrieb im assoziativen Zweiwege-Mastermodus. In der bevorzugten Ausführungsform sind die Bauteile 33-MHz-Versionen der jeweiligen Einheiten. Die Adressenzwischenspeicherschaltung 34 und der Daten-Sendeempfänger 36 sind an die Cache-Steuerung 24 mit dem Prozessor 20 angeschlossen und bilden eine lokale Bus-Schnittstelle zwischen dem lokalen Prozessorbus 26 und dem Haupt-Bus 44.
Die Schaltung 38 ist eine Logikschaltung, die ein Bus-Bereit-Signal bereitstellt, um Zugriff auf den lokalen Bus 26 zu steuern und zu signalisieren, wann der nächste Zyklus beginnen kann. Die Freigabeschaltung 40 wird dazu benutzt, zu signalisieren, daß auf den lokalen Bus 26 die nächste Datenadresse oder der von den Subsystem-Elementen im Pipeline-Adressenbetrieb verwendete Code plaziert werden kann.
Der Adressenkartei-Programmierer 30 für den nicht-cachefähigen Speicher arbeitet mit dem Prozessor 20 und dem nicht-cachefähigen Adressenspeicher 32 zusammen, um nicht-cachefähige Speicherplätze zu kartieren. Der nicht-cachefähige Adressenspeicher 32 dient zur Kennzeichnung solcher Bereiche des Systemspeichers, die nicht-cachefähig sind, um zahlreiche Arten von Cachespeicher-Inkohärenz zu vermeiden. Die Busanforderungs-Logikschaltung 42 wird von dem Prozessor 20 und dazugehörigen Elementen dazu benutzt, Zugriff auf den Hauptbus 44 in solchen Situationen anzufordern, in denen z. B. angeforderte Daten sich nicht in dem Cachespeicher 28 befinden und Zugriff auf den Systemspeicher erforderlich ist.
In der Zeichnung ist das System C konfiguriert durch den Prozessorbus 26, den Hauptbus 44, einen erweiterten Industrienorm-Architektur-Bus (EISA-Bus) 46 (Fig. 2) und einen X-Bus 90. Die Einzelheiten des in Fig. 2 dargestellten Systemabschnitts, die im folgenden nicht diskutiert werden, sind für die vorliegende Erfindung nicht signifikant, außer daß sie ein Beispiel für ein vollständig konfiguriertes Rechnersystem darstellen. Die EISA-Version 3.1 ist als Anhang 1 beigefügt, um die Anforderungen eines EISA-Systems vollständig zu erläutern. Der in Fig. 2 dargestellte Abschnitt des Systems C ist im wesentlichen ein konfiguriertes EISA-System, welches den benötigten EISA-Bus 46, eine EISA- Bussteuerung 48, Daten-Zwischenspeicher und -Sendeempfänger 50 sowie Adressenspeicher- und -puffer 52 zur Bildung der Schnittstelle zwischen dem EISA-Bus 46 und dem Hauptbus 44 enthält. Außerdem ist in Fig. 2 eine integrierte Systemperipherie 54 dargestellt, die eine Anzahl von Elementen beinhaltet, die in einem Rechnersystem auf EISA- Basis verwendet werden.
Die integrierte Systemperipherie (ISP) 54 enthält eine Direktspeicherzugriffs-Steuerung 26 zum Steuern des Zugriffs auf den Hauptspeicher 58 (Fig. 1) oder einen in EISA-Steckplätzen enthaltenen Speicher sowie Eingabe-/Ausgabe-Stellen (E/A), ohne daß das Erfordernis eines Zugriffs auf den Prozessor 20 besteht. Das Hauptspeicherfeld 58 wird als lokaler Speicher betrachtet, es enthält ein Speicherschaltungsfeld mit einer Größe, die sich für die speziellen Anforderungen des Systems eignet. Die ISP 54 enthält außerdem Unterbrechungssteuerungen 70, eine nicht maskierbare Unterbrechungslogik 32 und System-Timer 74, die die Steuerung von Unterbrechungssignalen gestatten und die benötigten Zeitsteuersignale sowie Wartezustände in einer Weise erzeugen, die der EISA-Spezifikation und üblicher Praxis entspricht. Bei der bevorzugten Ausführungsform werden vom Prozessor erzeugte Unterbrechungsanforderungen über Doppel-Unterbrechungs-Steuerschaltungen gesteuert, welche die konventionellen Intel-8259-Unterbrechungssteuerungen emulieren und erweitern. Die ISP 54 enthält außerdem eine Busentscheidungslogik 75, die in Zusammenarbeit mit der Bussteuerung 48 unter den verschiedenen Anforderungen des EISA-Busses 46 durch die Cache-Steuerung 24, die DMA-Steuerung 56 und an dem EISA-Bus 46 angeordnete Master-Bauelemente steuert und entscheidet.
Das Hauptspeicherfeld 58 ist vorzugsweise ein dynamischer Schreib- /Lese-Speicher. Der Speicher 58 steht mit dem Hauptbus 44 über eine Datenpufferschaltung 60, eine Speichersteuerschaltung 62 und einen Speicher-Kartierer 68 in Verbindung. Der Puffer 60 führt Daten-Sende- /Empfangsvorgänge und eine Paritätsgenerierung sowie Prüffunktionen aus. Die Speichersteuerung 62 und der Speicherkartierer 68 stehen mit dem Speicher 58 über Adressen-Multiplexer und Spaltenadressen-Strobe- Puffer 66 sowie eine Reihenadressenfreigabelogikschaltung 64 in Verbindung.
Der EISA-Bus 46 enthält ISA- und EISA-Steuerbusse 76 und 78, ISA- und EISA-Steuerbusse 80 und 82 sowie Adressenbusse 84, 86 und 88. Systemperipherieeinrichtungen sind über den X-Bus 90 in Kombination mit dem ISA-Steuerbus 46 von dem EISA-Bus 46 aus zugänglich. Die Steuerung und der Daten-/Adressen-Transfer für den X-Bus 90 werden erleichtert durch die X-Bus-Steuerlogik 92, die Daten-Sendeempfänger 94 und die Adressenspeicher 96.
An den X-Bus 90 angeschlossen sind verschiedene Peripheriegeräte, beispielsweise eine Tastatur-/Maus-Steuerung 98, die die Schnittstelle zwischen dem X-Bus 90 und geeigneten Tastatur- bzw. Maus-Verbindern 100 und 102 bildet. Ebenfalls an den X-Bus 90 angeschlossen sind Festspeicherschaltungen 106, die Software für Basisoperationen für das System C und für System-Videooperationen enthalten. Ein serieller Übertragungsport 108 ist ebenfalls über den X-Bus 90 an das System C gekoppelt. In einer Blockschaltung 110 sind ein Floppy- und ein Festplattenträger, ein paralleles Port, ein zweites serielles Port und Videounterstützungsschaltungen vorgesehen.

2. Plattengruppensteuerung:

Die Plattengruppensteuerung 112 ist an den EISA-Bus 46 angeschlossen, um über diesen Bus die Übertragung von Daten- und Adresseninformation zu ermöglichen. Festplattenverbinder 114 sind an das Festplatten- Trägersystem angeschlossen und stehen ihrerseits in Verbindung mit einer Festplattengruppe 116. Fig. 3 ist ein schematisches Blockdiagramm der Plattengruppensteuerung 112 gemäß der Erfindung. Die Plattengruppensteuerung 112 gemäß der Erfindung enthält eine Busmaster-Schnittstellensteuerung 118 (BMIC), vorzugsweise vom Typ Intel-Corporation 82355, die zur Verwendung mit der EISA-Busmaster-Erweiterungsplatine für 32 Bits ausgelegt ist und sämtliche für Transfers über den EISA- Bus benötigten EISA-Steuer-, Adressen- und Datensignale bereitstellt. Die BMIC 118 wickelt 16 und 32 Bits umfassende Burst-Transfers zwischen dem Plattengruppensystem und dem Systemspeicher ab. Weiterhin ist die BMIC in der lage, einen Transfer in zwei 32-Bit- Transfers umzusetzen, wenn der für den Transfer vorgesehene Speicher nicht burstfähig ist. Darüber hinaus liefert die BMIC 116 die Transfers variierender Datengrößen zwischen einer Erweiterungsplatine und EISA- sowie ISA-Bauelementen.
Die Plattengruppensteuerung 112 gemäß der Erfindung enthält außerdem eine Kompartibilitätsport-Steuerung 120 (CPC). Die CPC 120 ist ausgelegt als Kommunikationsmechanismus zwischen dem EISA-Bus 46 und vorhandener Haupttreiber-Software, die nicht dazu ausgelegt ist, von den Möglichkeiten der EISA vorteilhaften Gebrauch zu machen.
Außerdem in der Plattengruppensteuerung 112 gemäß der Erfindung enthalten ist ein Mikroprozessor 122, vorzugsweise ein 80186-Mikroprozessor der Firma Intel Corporation. Der lokale Prozessor 122 ist mit seinen Steuer-, Adressen- und Datenleitungen an die BMIC 118, die CPC 120 und die Transferkanal-Steuerung 124 angeschlossen. Außerdem bildet der lokale Prozessor 122 eine Schnittstelle bezüglich einem lokalen Festspeicher (ROM) 126 und einem dynamischen Schreib-/Lese- Speicher (RAM) 128, die sich innerhalb der Plattengruppensteuerung 112 befinden.
Die Transferkanal-Steuerung 124 (TCC) steuert den Betrieb von vier Haupt-DMA-Kanälen, die auf einen statischen RAM-Transferpuffer 130 zugreifen. Die TCC 124 weist DMA-Kanäle der BMIC 118, der CPC 120, dem lokalen Prozessor 122 und dem Plattengruppen-DMA-Kanal 114 zu. Die TCC 124 empfängt von den vier Kanälen Anforderungen und weist jedem Kanal eine Prioritätsstufe zu. Der lokale Prozessor 122 hat die höchste Prioritätsstufe. Der CPC-120-Kanal hat die zweithöchste Prioritätsstufe. Der BMIC-118-Kanal besitzt die dritthöchste Prioritätsstufe, und der Plattengruppen-DMA-Kanal 114 besitzt die niedrigste Prioritätsstufe.
Der Plattengruppen-DMA-Kanal 114 wird gemeinsam von vier Plattenlaufwerk-Subkanälen genutzt. Die vier Plattenlaufwerk-Subkanäle können irgendeinem der in der Plattengruppe vorhandenen acht verschiedenen Plattenlaufwerken zugeordnet sein. Die vier Laufwerk-Subkanäle haben innerhalb des Plattengruppen-DMA-Kanals gleiche Priorität. Die Subkanäle werden gleichmäßig durchlaufen, um die Quelle für den Plattengruppen-DMA-Kanal zu werden. Einer der Subkanäle wird in diese Rotation nur dann eingefügt, wenn er eine aktive DMA-Anforderung aufweist. Die verbleibenden drei Subkanäle sind innerhalb der Rotation stets aktiv.
Erfindungsgemäß wird eine Anforderung an die Plattengruppensteuerung 112 über die BMIC 118 gegeben. Der lokale Prozessor 122 erstellt bei Empfang diese Anforderung über die BMIC 118 in dem RAM-Speicher 128 des lokalen Prozessors eine Datenstruktur. Diese Datenstruktur ist auch bekannt als Befehlsliste und kann eine einfache, an die Plattengruppe gerichtete Lese- oder Schreibanforderung sein, oder es kann sich um einen komplexeren Satz einer Anforderung handeln, der mehrfaches Lesen/Schreiben oder Diagnose- und Konfigurationsanforderungen beinhaltet. Die Befehlsliste wird dann an den lokalen Prozessor 122 gegeben, um das erfindungsgemäße Verfahren auszuführen.
Zuerst übersetzt der lokale Prozessor 122 die Befehlsliste oder den "logischen Befehl" in eine Reihe kleinerer Befehlsanforderungen, die weiter unten in Fig. 5 beschrieben sind. Diese Befehlsanforderungen können Platten-E/A-Operationen oder andere Diagnosefunktionen enthalten. Wenn die Befehlsanforderungen Nicht-E/A-Operationen sind, plaziert sie der lokale Prozessor in einer Warteschlange für die Ausführung. Wenn die Befehlsanforderungen E/A-Funktionen betreffen, führt der lokale Prozessor einen zweiten Satz von Übersetzungen aus, um Laufwerksanforderungen zu generieren, welche spezifische Plattenparameter enthalten, beispielsweise Kopf-, Zylinder- und Sektorinformation bezüglich der Quellen- oder Zieladresse für jeden Transfer.
Die Laufwerksanforderungen werden außerdem in eine Ausführungs- Warteschlange gestellt. Der lokale Prozessor 122 wählt den ersten Befehl in der Ausführungs-Warteschlage aus. Der lokale Prozessor 122 führt den Befehl in Verbindung mit der TCC 124 aus, um einen Datentransfer in die Plattengruppe oder aus der Plattengruppe in einen Transferpuffer abzuwickeln. Dann lädt der lokale Prozessor 122 die Register der BMIC 118 mit Transferinformation und die BMIC 118 wickelt den Transfer zwischen dem Hauptrechner und der Plattengruppe ab.
Ist die Ausführung der Befehlsliste abgeschlossen, signalisiert der lokale Prozessor 122 dies dem Betriebssystem-Bauelementtreiber. Die Übergabe der Befehlsliste und die Signalisierung der Abarbeitung der Befehlsliste werden mit Hilfe eines Protokolls erreicht, welches die E/A- Register der BMIC 118 benutzt. Um mehrere anstehende Anforderungen an der Plattengruppensteuerung 112 zu ermöglichen, sind diese E/A- Register in zwei Kanäle unterteilt: einen Befehlslisten-Übergabekanal und einen Befehlslisten-Fertig-Kanal.

III. Bus Master-Schnittstellensteuerung:

Fig. 4 ist ein schematisches Blockdiagramm der BMIC 118. Was folgt, ist eine kurze Diskussion der Funktionen und der Merkmale der BMIC 118.
Im EISA-Slave-Modus überwacht die BMIC 118 die Adressenleitungen des EISA-Busses 46 zur allgemeinen E/O Adressendekodierung, zur steckplatzspezifischen Adressendekodierung und für den Zugriff auf gemeinsam benutzte Register 144. Während Slave-Modus-Operationen sind sämtliche internen Register der BMIC 118 über die Schnittstelle 142 des lokalen Prozessor zugänglich, und sämtliche gemeinsam benutzten Register 144 sind für den EISA-Bus 46 oder den lokalen Prozessor 122 über die EISA-Schnittstelle 140 bzw. die Schnittstelle 142 des lokalen Prozessors zugänglich.
Im EISA-Master-Modus wird die BMIC 118 der Master für den EISA- Bus 46. Sie kann Bursts, Nicht-bursts, fehlangepaßte oder Peek-/Poke- Datentransfers ausführen. Während Mastermodus-Operationen sind sämtliche internen Register der BMIC 118 für den lokalen Prozessor 122 (Fig. 3) über die Schnittstelle 142 des lokalen Prozessors der BMIC 118 zugänglich. Die Entscheidungsstelle der EISA-Schnittstelle 140 bestimmt, in welchem Modus sich die BMIC 118 befindet; sie führt die EISA-Entscheidung durch, und sie liefert das Steuersignal, welches zum Regulieren der Slave- und Master-Aktivität im Inneren der BMIC 118 erforderlich ist. Im Slave-Modus vermittelt die Entscheidungsstelle der EISA-Schnittstelle 140 auch zwischen der EISA-Seite und der lokalen Seite während Zugriffen auf gemeinsam benutzte Register 144.
Die EISA-Schnittstelle und -Entscheidung 140 beinhaltet zwei identische, unabhängige Transferkanäle, die so konfigurierbar sind, daß entweder Burst- oder Nicht-Burst-Zyklen zu und von dem Systemspeicher 58 (Fig. 1) abgewickelt werden. Die BMIC 118 wickelt automatisch Nicht-Burst oder fehlangepaßte Zyklen ab, wenn der von der BMIC 118 adressierte Speicher keine Burst-Zyklen abwickeln kann. Fehlangepaßte Zyklen werden abgewickelt, wenn eine Datengrößen-Umsetzung von 32 Bits auf 16 Bits oder 8 Bits erforderlich ist.
Jeder Transferkanal besitzt drei Registersätze zum Regulieren von Datentransfers. Es sind dies die Basisregistergruppe, die laufende Registergruppe und die Datenstatus-/-Steuerregistergruppe. Diese Implementierung eines Dreifach-Registersatz ermöglicht es dem lokalen Prozessor 122, den nächsten Transfer auf dem Kanal zu programmieren, während gerade der laufende Transfer ausgeführt wird.
Das Basisregister enthält sieben 8-Bit-Register. Diese Register werden von dem lokalen Prozessor 122 programmiert, wenn ein Transfer über einen der Kanäle angefordert wird. Vier Transferkanal-Basisadressenregister werden kombiniert, um die während des Transfers zu benutztende Anfangs-32-Bit-EISA-Adresse zu bilden. Die übrigen drei Register sind die Transferkanal-Basiszählregister. Die Basiszählregister werden dazu benutzt, die Anzahl durchzuführender Transfers zu bestimmen. Die Anzahl von Bits, die übertragen werden können, reicht von 1 Bit bis zu 4 Gbytes. Das höchstwertige Bit des Transferkanal-Basiszählregister dient zum Steuern des Start des Transfers, das zweithöchstwertige Bit dient zum Steuern der Transfer-Richtung.
Der laufende Registersatz enthält sieben Register, von denen jedes einem Basisregister entspricht. Diese Register werden aus den Basisregistern geladen. Die laufenden Transferkanal-Adressenregister enthalten die 32 Bits umfassenden Echtzeit-EISA-Speicheradressen. Die laufenden Transferkanal-Zählregister enthalten die Anzahl der Bits, die noch über den Kanal zu übertragen sind. Der laufende Registersatz kann von dem lokalen Prozessor 122 über dessen Schnittstelle 142 (Fig. 3) ausgelesen werden. Der Status-/Steuer-Registersatz enthält drei Register: das Transferkanal-Strobe-Register, das Transferkanal-Konfigurationsregister und das Transferkanal-Statusregister. Das Transferkanal-Strobe-Register dient zum Einleiten des Datentransfers von dem dem Basisregistersatz zugeordneten laufenden Register. Eine Transferanforderung für den Kanal wird im Anschluß an das Laden des laufenden Registers generiert. Das Transferkanal-Konfigurationsregister dient zum Programmieren des Transfer-Modus. Das Transferkanal-Statusregister liefert den Status des FIFO 146 und des Transferkanals.
Beim Einleiten eines Transfers über einen der beiden Transferkanäle bestimmt die vorliegende Erfindung als erstes, ob die Basisregister für den gewünschten Transferkanal verfügbar sind. Der lokale Prozessor 122 programmiert oder lädt den Transferkanal-Basisregistersatz mit der gewünschten Transferinformation. Der lokale Prozessor 122 lädt dann den laufenden Registersatz aus dem Basisregister und plant eine Anforderung durch Einschreiben in das Transfer-Strobe-Register des Kanals. Wenn gerade ein Transfer auf dem angeforderten Kanal abgewickelt wird, erfolgt das Laden vom Basis- in das laufende Register sofort nach Abschluß des Datentransfers über den angeforderten Kanal.
Die BMIC 118 kann für Burst- oder Nicht-Burst-Datentransfers zu und von dem EISA-Speicher programmiert werden. Bestimmt wird dies durch ein Einschreiben in das Kanalkonfigurationsregister. Wird ein Burst-Modus freigegeben, so schaut die BMIC 118 nach einem Slave- Burst-Signal zu Beginn des Transfers, um festzustellen, ob die Slave- Einrichtung, die adressiert wird, in der Lage ist, Burst-Zyklen abzuwickeln. Reagiert die Slave-Einrichtung nicht mit einem aktiven Slave- Burst-Signal, unternimmt die BMIC 118 keinen Versuch, einen Burst- Transfer abzuwickeln und macht weiter mit entweder einem Nicht-Burst- oder einem fehlangepaßten Datentransfer.
Um dem lokalen Prozessor 122 (Fig. 3) zu ermöglichen, mit anderen Einrichtungen in dem Rechnersystem C (Fig. 1, 2) zu kommunizieren, ermöglicht das erfindungsgemäße Verfahren dem lokalen Prozessor 122, individuelle E/A- oder Speicherzyklen über den EISA-Bus 46 auszuführen. Diese Zyklen kann man sich ähnlich denken wie die Statements "Peek" und "Poke" der Programmiersprache BASIC. Diese Zyklen können Lesevorgänge, Schreibvorgänge oder starre Austauschvorgänge von 8, 16, 24 oder 32 Bits umfassenden Werten sein. Peek- /Poke-Transferzyklen müssen innerhalb eines einzigen Doppelworts enthalten sein. Die Peek-/Poke-Operation erfordert vier 8 Bits umfassende Peek/Poke-Adressenregister, die kombiniert werden, um die 32 Bits umfassende Peek/Poke-Adressen zu bilden, ein 8 Bits umfassendes Peek/Poke-Steuerregister, welches die Bits enthält, die festlegen, ob der Zyklus ein E/A-Vorgang oder ein Speicher-, Peek (Lese)/Poke- (Schreib-) oder ein verrasteter Austausch ist, und welches Bit während des Zyklus aktiv ist, außerdem vier 8 Bits umfassende Peek/Poke-Datenregister, welche dazu dienen, die Daten für den Peek/Poke-Zyklus aufzunehmen. Zum Ausführen eines individuellen Schreibzyklus (Poke) lädt der lokale Prozessor 122 das Peek/Poke-Adressenregister, um die 32 Bits umfassende Speicheradresse oder die 16 Bits umfassende E/A- Adresse zu spezifizieren. Anschließend lädt der lokale Prozessor 122 die zu übertragenden Daten in den Peek/Poke-Datenregistersatz innerhalb der entsprechenden Bitpositionen der Datenregistersätze in der Weise, daß die Daten auf den korrekten Bitleitungen während eines 32-Bit- Busmastertransfers übertragen werden. Dann lädt der lokale Prozessor 122 die Peek/Poke-Steuerregister, um den Zyklustyp zu spezifizieren und den Datentransferzyklus einzuleiten. Bit 2 innerhalb des lokalen Status/Steuer-Registers wird von der BMIC 118 auf "1" gesetzt, um anzuzeigen, daß eine Peek/Poke-Anforderung ansteht und die Peek/Poke- Register belegt sind. Wenn der Poke-Zyklus über den EISA-Bus 46 abgeschlossen ist, wird das Peek/Poke-Statusbit in dem lokalen Status/Steuer-Register auf Normal (0) zurückgestellt. Um einen individuellen Lesezyklus (Peek) auszuführen, lädt der lokale Prozessor 122 die 32 Bits umfassende Speicheradresse in das Peek/Poke-Adressenregister. Dann lädt der lokale Prozessor 122 das Peek/Poke-Steuerregister um den Lesezyklus einzuleiten. Das Bit 2 des Peek/Poke-Zyklus in dem lokalen Status/Steuer-Register wird von der BMIC 118 auf einen hohen Pegel gesetzt und verbleibt aktiv, bis der Peek-Zyklus auf dem EISA-Bus 46 abgeschlossen ist. Dann kann der lokale Prozessor 122 die Daten- aus dem Peek/Poke-Datenregister lesen. Wenn ein starrer Austauschzyklus von dem lokalen Prozessor 122 angefordert wird, wird als erstes der Peek-Zyklus geplant, direkt gefolgt von einem Poke-Zyklus. Das Signal "SPERRE" wird während des verrasteten Austauschzyklus gegeben, um anzuzeigen, daß kein anderer Zugriff auf die adressierte Stelle möglich ist.
Die Plattensteuerung 112 beginnt den Mastermodus-Betrieb zu jeder beliebigen Zeit, zu der eine Transferanforderung ansteht. Stehen mehr als eine Transferanforderung an, bedient sie die Plattensteuerung in folgender Reihenfolge: Peek/Poke-Zyklen haben beim Zugriff auf den EISA-Bus 46 höchste Priorität, gefolgt von den beiden Datenkanälen. Wenn die Plattensteuerung 112 die Steuerung des EISA-Busses 46 übernommen hat, führt die Steuerung als erstes jeden Peek-, Poke- oder verrasteten Austauschtransfer aus, der möglicherweise ansteht. Steht von diesen Peek-, Poke- oder verrasteten Austauschtransfers keiner an, wickelt die Plattensteuerung 112 Datentransfers ab, die von einem der beiden Transferkanäle stammen. Die beiden Transferkanäle haben gleiche Priorität und werden alternierend bedient. Die Plattensteuerung fährt damit fort, den Besitz des EISA-Busses 46 zu behaupten, bis sämtliche ausstehenden Datentransfer-Anforderungenm bedient sind, oder sie von dem EISA-Bus 46 mit Beschlag belegt wird. Die Plattensteuerung 112 kann so konfiguriert werden, daß sie den EISA-Bus 46 sofort aufgibt, oder aber für eingestellte Zeitspannen, nachdem ein Belegungssignal über den EISA-Bus empfangen wurde.
Die Transferpuffer-Schnittstelle 148 der BMIC 118 liefert Signale, die wesentlich sind für die Schnittstellenbildung zwischen der Plattengruppensteuerung 112 und der baulichen Plattengruppe. Die Transferpufferschnittstelle 148 ist an eine Hochgeschwindigkeits-Datentransfer- Steuerung angeschlossen und macht Gebrauch von einer einfachen Logik, ähnlich derjenigen, die bei traditionellen DMA-Entwürfen benutzt wird. Diese Schnittstelle enthält einen 16-Bit-Datenbus, einen Takteingang und sieben Steuersignale. Die 16 Datenleitungen dienen der BMIC 118 für den Transfer von Daten zu und von der Transfersteuerung 124 (Fig. 3) innerhalb der Plattengruppensteuerung 112. Die BMIC 118 stellt automatisch die von der Transfersteuerung 124 empfangenen Daten zu 32 Bits umfassenden Doppelwörtern für 32-Bit-Transfers über den EISA- Bus 46 zusammen. Außerdem werden die Datenleitungen von der BMIC 118 dazu benutzt, intern generierte Start- oder Echtzeitadressen zur Verwendung während Datentransfers zu dem lokalen Prozessor 122 zu transportieren. Die Transferdaten-Puffer-Schnittstelle 148 enthält vier 8- Bit-Transferpuffer-Schnittstellenregister: zwei Basisregister und zwei laufende Register, die sämtlich mit 16 Bits umfassenden Startadressen von dem lokalen Prozessor 122 programmiert werden können. Jedem Transferkanal ist ein Paar aus einem Basis- und einem laufenden Register zugeordnet. Die Basisregister enthalten die Startadresse, die laufenden Register liefern die Echtzeitadressen, die zum Verfolgen des laufenden Transfers verwendet werden. Die laufenden Register gehen automatisch jedes Mal um eine Adresse weiter, wenn ein 16 Bits umfassendes Wort über die Transferpufferschnittstelle 148 übertragen wird. Die 16-Bit-Startadresse wird von der Transferpufferschnittstelle 148 in die Transferkanalsteuerung 124 (FIg. 3) zu Beginn sämtlicher neuen Datentransfers übertragen. Die Inhalte der Basisregister der Transferpufferschnittstelle 148 werden zu den laufenden Registern der Transferpufferschnittstelle 148 übertragen. Die BMIC 118 liefert ein Ladesignal, welches dazu benutzt werden kann, die Startadresse in einem externen Adressenzähler zwischenzuspeichern, um von der Transferkanalsteuerung 124 benutzt zu werden.
Die BMIC 118 kann auch von dem lokalen Prozessor (Fig. 3) so programmiert werden, daß sie jedes Mal dann die Transferadresse generiert, wenn ein zugehöriges Signal wieder die Steuerung über den EISA- Bus 46 erlangt, zu welchem Zeitpunkt die Adresse in dem Basisregistersatz auch die Adresse im Echtzeit-Registersatz ist. Durch Programmieren des Bits 7 in dem Kanalkonfigurationsregister auf eine "1", wird eine Startadresse an die Transferkanalsteuerung 124 zu Beginn sämtlicher neuer Transfers übertragen, und die Echtzeitadressen werden jedes Mal übertragen, wenn der zugehörige Kanal erneut die Steuerung des EISA-Busses 46 wiedererlangt. Wenn das Bit 7 in dem Kanalkonfigurationsregister auf eine "0" eingestellt ist, wird die Transferstartadresse zu Beginn sämtlicher neuen Transfers übertragen, und die Echtzeitadresse braucht nicht zu dem laufenden Kanalkonfigurationsregister übertragen zu werden.
Die BMIC 118 enthält außerdem zwei identische First-in-first-out-Puffer (FIFOs), einen pro Transferkanal, und einen gemeinsamen Datenausrichter für Datentransfers zwischen dem Rechnersystem- Speicher und der Plattengruppensteuerung. Die Primärfunktion der FIFO-/Datenausrichter-Einheit 146 besteht darin, die zeitlichen Relationen zwischen dem EISA-Bus 46 und den Bauteilen innerhalb der Plattengruppensteuerung 112 zu trennen und zu vereinfachen. Der FIFO 146 ermöglicht die zeitliche Abwicklung auf der Seite der Plattengruppensteuerung 112 der BMIC 118, mit lokal generierten Taktsignalen gekoppelt zu werden. Dieser lokale Takt kann unabhängig von dem EISA-Bus-Taktsignal sein, der den zeitlichen Ablauf des EISA-Busses 46 bestimmt. Das FIFO liefert außerdem Latenz-Schutz für Wartezustände, die entweder auf dem EISA-Bus 46 oder in der Plattengruppensteuerung entstehen. Jeder FIFO 146 innerhalb der BMIC 118 hat eine Größe von 25 Bits. Die Transferdaten werden aus entweder der Plattengruppensteuerung 112 oder seitens des EISA-Busses 46 in die FIFOs geladen, abhängig von der Richtung des Datentransfers. Die Daten werden in den FIFO während des Datentransfers als Doppelwort eingeschrieben. Wenn allerdings die Daten nicht aus einem ausgerichteten Doppelwort bestehen, erfolgen teilweise FIFO-Ladevorgänge zu Beginn oder am Ende eines Transfers, abhängig von der Bitzählung, dem Adressenprogramm und der Transfer-Richtung. Der Zustand der FIFOs 146 läßt sich ermitteln anhand des Transferkanal-Statusregistersatzes, der anzeigt, ob die FIFOs 146 im Ruhezustand oder aktiv sind. Ein FIFO-Ruhezustand ist dadurch definiert, daß ein FIFO während eines EISA-Lesevorgangs gefüllt oder während eines EISA-Schreibvorgangs leer ist. In jedem Fall wird die Transferkanalsteuerung 124 nicht in der Lage sein, den von der EISA-Einrichtung angeforderten Datentransfer aufrechtzuerhalten. Kommt es zu einen FIFO-Ruhezustand, wird der Datentransfer angehalten, und die BMIC 118 bedient entweder die Transferanforderung mit der höchsten Priorität oder gibt den EISA-Bus 46 zugunsten des Rechnersystems auf.
Die Datenausrichtungsfunktion ordnet die 16 Bits umfassenden Daten von der Transferkanalsteuerung 124 um in eine beliebige Bit-Ausrichtung für den Systemspeicher 58. Der Datenausrichter übernimmt auch das Zusammenstellen und das Zergliedern von EISA-Daten während des Transfers. Der Datenausrichter 146 wird auch dazu benutzt, eine Bit-Ausrichtung für den EISA-Bus 46 für den Fall vorzunehmen, daß eine fehlausgerichtete Doppelwort-Grenze vorliegt. Der Datenausrichter 146 ermöglicht der BMIC 118 Teil-Doppelwort-Transfers abzuwickeln, wie es zu Beginn und am Ende sämtlicher derartiger Transfers erforderlich ist.
Die Schnittstelle 142 des lokalen Prozessors der BMIC 118 enthält zwei 8-Bit-Register, über die der lokale Prozessor 122 (Fig. 3) auf sämtliche internen Register der BMICs 118 zugreifen kann. Die Register werden in die Schnittstelle 142 des lokalen Prozessors einkopiert und enthalten ein lokales Datenregister und ein lokales Indexregister. Diese Register werden von dem lokalen Prozessor 122 über die Adressenleitungen der Schnittstelle 142 des lokalen Prozessors ausgewählt. Das lokale Status/Steuer-Register wird ebenfalls direkt in die Schnittstelle 142 des lokalen Prozessors einkopiert und dient zur Bereitstellung des Unterbrechungs-Peek/Poke- und Basisregister-Status für den lokalen Prozessor 122.
Der lokale Prozessor 122 (Fig. 3) und der EISA-Bus 46 kommunizieren miteinander über einen Satz von Befehls/Status-Registern, die als die gemeinsam benutzten E/A-Register 144 bekannt sind. Die gemeinsamen Register 144 beinhalten einen Satz von Briefkasten-Registern, Semaphor- Ports und Türklingel-Registern. Die Briefkasten-Register dienen zum Durchleiten von Befehlen und Daten zwischen dem lokalen Prozessor und dem EISA-Bus 46 und werden von den Semaphor-Ports gesteuert.
Der Türklingelregistersatz dient zum Informieren des lokalen Prozessors 122 oder der Seite des EISA-Busses 46 über das Auftauchen neuer Nachrichten. Auch enthalten als Teil des gemeinsam benutzten E/A- Registersatzes 144 sind Identifikationsregister, die zur Unterstützung von EISA-Identifizierungsfunktionen benutzt werden.
Zwei Semaphor-Ports innerhalb der gemeinsamen E/A-Register 144 dienen zum Einstellen und Testen von Funktionen in dem E/A-Raum. Die Ports dienen zum Sperren des Zugriffs auf Briefkastenregister. Jedes der beiden Semaphor-Ports besteht aus einem Semaphor-Flag-Bit und einem Semaphor-Test-Bit. Erfolgt ein Schreibvorgang für das Semaphor- Flag-Bit bei entweder der EISA-Schnittstelle 140 oder der Schnittstelle 142 des lokalen Prozessors, so wird der alte Wert des Semaphor-Flag- Bits in das entsprechende Semaphor-Test-Bit einkopiert. Der alte Wert des Semaphor-Flag-Bits steht dann zur Verfügung, und das zu lesende Test-Bit gelangt entweder zu dem lokalen Prozessor 122 oder einer Einrichtung an dem EISA-Bus 46 zurück. Wenn der von dem Semaphor- Test-Bit zurückgelesene Wert eine "1" ist, steht das angeforderte Betriebsmittel nicht für den Gebrauch zur Verfügung. Wenn hingegen der zurückgelesene Wert eine "0" ist, ist das angeforderte Betriebsmittel für den Gebrauch verfügbar und wird von dem anfordernden Prozessor oder Busmaster gesperrt.
Der Briefkastenregistersatz enthält einen Satz aus sechszehn 8-Bit-Allgemeinregistern, die dazu dienen, Information zwischen der Plattengruppensteuerung und dem EISA-System C durchzuleiten. Die sechszehn Register werden kontinuierlich in den steckplatzspezifischen EISA-E-A- Raum kopiert, und man kann auf sie bitweise, wortweise oder doppelwortweise zugreifen. Die Register können direkt dazu verwendet werden, Befehls- und Statusinformation durchzuleiten, oder können als Zeiger auf größere Befehlsblöcke innerhalb des Speichers benutzt werden. Die Briefkastenregister stehen zum Lesen oder Schreiben zu jeder Zeit seitens entweder dem EISA-Bus 46 oder der Schnittstelle 142 des lokalen Prozessors zur Verfügung. Der Briefkastenregistersatz enthält außerdem ein internes Entscheidungsschema, welches die Existenz von unbestimmten Bits für den Fall verhindert, daß es von beiden Seiten des Briefkastenregisters gleichzeitig zu einem Lesen und einem Schreiben kommt.
Der gemeinsam benutzte E/A-Registersatz 144 enthält außerdem zwei 8- Bit-Türklingel-Unterbrechungs/Status-Register; das eine ist der EISA- Seite der Plattengruppensteuerung zugewiesen. Der EISA-System-Türklingelregistersatz wird von dem lokalen Prozessor 122 dazu verwendet, Dienste von der EISA-Seite der BMIC anzufordern, das lokale Türklingelregister wird von einem Bauteil auf der EISA-Seite der BMIC 118 dazu benutzt, eine Unterbrechungsanforderung an den lokalen Prozessor 122 der Plattengruppensteuerung zu senden. Die 8 Bits in jedem Türklingelregister ermöglichen, daß gleichzeitig bis zu acht Bauteile oder Ereignisse in jeder Richtung gleichzeitig Unterbrechungsanforderungen anstehen haben. Jedem Türklingelregister ist ein 8-Bit- Unterbrechungsfreigaberegister zugeordnet, welches dazu benutzt werden kann, die Unterbrechungen für das Türklingelregister auf individueller Basis freizugeben oder zu sperren. Die BMIC 118 enthält außerdem ein Systemunterbrechungs-Freigabe/Steuer-Register und ein lokales Status- /Steuer-Register, die dazu dienen, die system- und lokalen Unterbrechungen zu sperren und den Status der system- und lokalen Unterbrechungen auf globaler Grundlage zu verifizieren. Jedem Bauelement oder Ereignis, welches möglicherweise die Plattengruppensteuerung 112 unterbricht, ist eine Bitstelle innerhalb des lokalen Unterbrechungs/Status-Türklingelregisters der BMIC 118 zugeordnet. Wenn das Bauelement an dem EISA-Bus 46 versucht, an die Plattengruppensteuerung eine Unterbrechungsanforderung zu senden, so schreibt sie von der EISA-Seite in das lokale Unterbrechungs/Status- Türklingelregister ein, wobei die dem Bauteil zugeordnete Bitstelle aktiv gemacht wird. Dies stellt das Bit in dem lokalen Unterbrechungs/Status- Türklingelregister ein, beläßt jedoch die übrigen Bits in dem Register unbeeinflußt. Wenn die Bitposition von dem System-Unterbrechungsfreigabe/Steuer-Register nicht gesperrt war, läuft das Unterbrechungssignal weiter durch die Schnittstelle 142 zu dem lokalen Prozessor 122. Wenn der lokale Prozessor 122 die Unterbrechung bedient, liest er den Inhalt des lokalen Status/Steuer-Registers, um den Ursprung der Unterbrechung zu ermitteln. Zeigt das Steuerregister an, daß das lokale Türklingelregister eine der freigegebenen Unterbrechungsquellen ist, liest der lokale Prozessor 122 den Inhalt des lokalen Türklingelregisters, um festzustellen, welche Bits aktiv sind, und eine Unterbrechung anzufordern. Der lokale Prozessor bedient eine der Anforderungen aus dem lokalen Türklingelregister, er schreibt in das lokale Türklingelregister mit der gesetzten Bitstelle. Dies veranlaßt jenes Bit innerhalb des lokalen Türklingelregisters zum Rücksetzen, jedoch bleiben die übrigen Bits unbeeinflußt.
Das erfindungsgemäße Verfahren wird implementiert in Form einer Anzahl von Anwendungstasks, die auf dem lokalen Prozessor 122 laufen (Fig. 3). Aufgrund der Natur interaktiver Eingabe/Ausgabe-Operationen ist es für die vorliegende Erfindung unpraktisch, als Einzel-Stapelverarbeitungstasks auf dem lokalen Prozessor 122 zu operieren. Folglich verwendet der lokale Prozessor 122 ein Echtzeit-Multitasking-System, welches die Adressierung von Mehrfach-Tasks durch den lokalen Prozessor gestattet, einschließlich der vorliegenden Erfindung. Vorzugsweise ist das Betriebssystem des lokalen Prozessors 122 das AMX 86- Multitasking-Executiv von Kadak-Products-Limited. Das AMX-Betriebssystem Kernel stellt eine Anzahl von Systemdiensten zusätzlich zu den Anwendungen gemäß dem erfindungsgemäßen Verfahren bereit.

IV. Befehlsprotokoll und -Definition:

Nunmehr auf Fig. 5 bezugnehmend, enthält das erfindungsgemäße Verfahren die Entwicklung einer Datenstruktur für die Plattengruppensteuerung 112, die als Befehlsliste 200 bekannt ist. Die Befehlsliste 200 besteht aus einem Befehlslistenvorsatz 202, gefolgt von einer variablen Anzahl von Anforderungsblöcken 204. Die Anforderungsblöcke haben variable Länge und können irgendeine Kombination aus E/A-Anforderungen darstellen, die weiter unten erläutert werden. Eine Befehlsliste 200 enthält typischerweise eine Anzahl von zugehörigen Anforderungsblöcken 204 zwischen 1 und irgendeiner Zahl, die weniger als 16 Kbytes Speicherplatz in Anspruch nimmt. Der Befehlslistenvorsatz 202 enthält Daten, die für sämtliche Anforderungsblöcke 204 in einer gegebenen Befehlsliste 200 gelten: logische Laufwerksnummer, Priorität und Steuerflags. Die Anforderungsblöcke 204 bestehen aus einem Anforderungsblockvorsatz 206 und weiteren erforderlichen Parametern, abhängig von der Beschaffenheit der Anforderung. Der Anforderungsblockvorsatz 206 hat eine fixe Länge, wohingegen andere Anforderungsparameter eine variable Länge besitzen.
Die individuellen Anforderungsblöcke 204 repräsentieren jeweils eine individuelle E/A-Anforderung. Durch Bilden einer Befehlsliste 200 aus den verschiedenen individuellen Anforderungsblöcken und durch Übersenden der Befehlsliste 200 an die Plattengruppensteuerung 112 (Fig. 2) reduziert sich der Mehraufwand des Microprozessors 20 des Rechnersystems C.
Immer noch auf Fig. 5 bezugnehmend, enthält ein Befehlslistenvorsatz 202 Information, die für jeden der Anforderungsblöcke 204 gilt, der in der Befehlsliste 200 enthalten ist. Der Befehlslistenvorsatz 202 hat eine Gesamtlänge von 4 Bytes. Die logische Laufwerknummer spezifiziert, für welches logische Laufwerk sämtliche Anforderungsblöcke 204 innerhalb der Befehlsliste 200 gelten. Das erfindungsgemäße Verfahren ermöglicht die Spezifizierung von insgesamt 256 logischen Laufwerken. Das Prioritätsbit dient zur Schaffung einer Steuerung über die Verarbeitung der Befehlsliste. Die Plattengruppensteuerung 112 ist in der lage, gleichzeitig mehrere Befehlslisten zu bearbeiten. Durch Spezifizieren der Priorität macht es das erfindungsgemäße Verfahren möglich, daß eine Befehlsliste vor jenen verarbeitet wird, die bereits von der Plattengruppensteuerung für die Verarbeitung eingeplant sind. Die Steuerflag- Bytes werden im Rahmen des erfindungsgemäßen Verfahrens zur Fehlerverarbeitung und zum Abwickeln einer Anforderung gleicher Priorität verwendet. Geregelte Anforderungen werden nach Priorität verplant, allerdings werden sie hinter sämtliche früheren Anforderungen gleicher Priorität gesetzt. Wenn sämtliche Anforderungen gleiche Priorität haben und das Regel-Flag gesetzt ist, werden die Anforderungen nach der Regel "wer zuerst kommt, wird zuerst bedient" bedient.
Durch Fehlerflags in den Steuerflag-Bytes werden Fehlerbedingungs- Meldeoptionen spezifiziert. Im Fall eines Fehlers kann die Plattengruppensteuerung 112 entweder dies dem anfordernden Gerät signalisieren und die Verarbeitung der Anforderungsblöcke 204 innerhalb der Liste fortsetzen, oder dem anfordernden Gerät den Fehler signalisieren und die Verarbeitung für sämtliche übrigen Anforderungsblöcke 204 innerhalb der Liste anhalten, oder den Fehler dem anfordernden Gerät nicht signalisieren. In sämtlichen Fällen wird ein Fehlercode dann, wenn die nächste Signalisierung über die Abarbeitung der Befehlsliste erfolgt, in das Befehlslisten-Statusregister zurückgegeben, außerdem in das Fehlercodefeld in demjenigen Anforderungsblock 204, wo der Fehler aufgetreten ist. Außerdem kann die Beendigungs-Signalisierung für jeden individuellen Anforderungsblock 204 oder für die gesamte Befehlsliste 200 gesetzt werden. Für den Fall, daß der EISA-Bus 46 jedes Mal zu informieren ist, wenn ein Anforderungsblock abgearbeitet ist, kann ein Flag "signalisieren bei Beendigung jeder Anforderung" innerhalb des Steuerflag-Feldes gesetzt werden.
Ein Anforderungsblock 204 besteht aus zwei Teilen, einem Anforderungsvorsatz 206 fixer Länge und einer Parameterliste 208 variabler Länge. Die Parameter werden als Datenstrukturen erzeugt, die als Streu/Sammel-(S/G-) Descriptorzähler bekannt sind, welche Datentransferadressen definieren. Die Felder des Anforderungsvorsatzes 206 enthalten eine Verbindung zu dem nächsten Anforderungsblock 204, den E/A-Befehl, Raum für einen Rückkehrstatus, eine Blockadresse und einen Blockzähler, sowie einen Zähler für Streu/Sammel-Descriptorstrukturelemente für zwei S/G-Descriptorzähler. Der Anforderungsvorsatz hat insgesamt eine Länge von 12 Byt.
Die Streu/Sammel-Descriptorzähler dienen zur Bestimmung der Anzahl von Streu/Sammel-Descriptoren 208, die in der speziellen Anforderung verwendet werden. Die Anzahl von Streu/Sammel-Descriptoren 208, die zu dem Anforderungsblock 204 gehören, schwankt. Wenn außerdem der Befehl ein Lesebefehl ist, so kann die Anforderung bis zu zwei unterschiedliche Sätze von Streu/Sammel-Descriptoren enthalten. Damit ist die vorliegende Erfindung in der lage, Daten aus zwei verschiedenen Bereichen innerhalb des Systemspeichers zu lesen. Jeder Streu/Sammel- Descriptor 208 enthält einen 32 Bit langen Puffer und eine 32 Bit umfassende Adresse. Diese Information dient zur Bestimmung der Systemspeicher-Datentransferadresse, die die Quelle oder das Ziel des Datentransfers ist. Im Gegensatz zu den Anforderungsblöcken 204 innerhalb der Befehlsliste müssen die Streu/Sammel-Descriptoren direkt aufeinander folgen, und wenn es einen zweiten Streu/Sammel-Descriptorsatz für eine Anforderung gibt, so muß er direkt an den ersten Satz von Streu/Sammel-Descriptoren anschließen.
Eine Befehlsliste 200 besitzt eine variable Anzahl von Anforderungsblöcken 204. Um rasch und effizient durch die Liste von variablen Anforderungsblöcken 204 zu gelangen, enthält der Anforderungsvorsatz einen Zeiger oder den Abstand zur nächsten Anforderung, der einen Abstand von "n" Bytes zwischen der Adresse des laufenden Anforderungsblocks und dem nächsten Anforderungsblock spezifiziert. Dieses Feld macht die Befehlsliste 200 zu einem Satz von verbundenen Listen-Anforderungsblöcken 204. Der letzte Anforderungsblock 204 besitzt an der Stelle "Abstand zur nächsten Anforderung" den Wert 000H, um das Ende der Befehlsliste 200 zu kennzeichnen. Hierdurch ermöglicht das erfindungsgemäße Verfahren einen Zwischenraum zwischen Anforderungsblöcken 204 innerhalb einer Befehlsliste 200, der von einem Bauelementtreiber des Betriebssystems genutzt werden kann. Allerdings sei angemerkt, daß, je größer der verbliebene Raum zwischen den Anforderungsblöcken 204 ist, desto länger die Plattengruppensteuerung 112 benötigt, die Befehlsliste 200 in ihren lokalen Speicher zu übernehmen.
Der Befehl spezifiziert die Funktion des speziellen Anforderungsblocks und bestimmt das Format der Parameterliste. Die von der Plattengruppensteuerung 112 ausgeführten Befehle der bevorzugten Ausführungsform beinhalten:

BEFEHL

IDENTIFIZIERUNG LOGISCHES LAUFWERK
IDENTIFIZIEREN STEUERUNG
IDENTIFIZIEREN STATUS DES LOGISCHEN LAUFWERKS
STARTEN WIEDERHERSTELLUNG
LESEN
SCHREIBEN
DIAGNOSEBETRIEB
LESEN KONFIGURATION
EINSTELLEN KONFIGURATION
Der Befehl "Identifizieren logisches Laufwerk" dient zum Identifizieren der definierten logischen Laufwerke innerhalb der Plattengruppe. Die Abarbeitung des Befehls liefert Information über das logische Laufwerk zurück in einen 28 Byte großen Puffer. Die Information beinhaltet Blocklänge; Anzahl der Blöcke; Parametertabelleneinträge des logischen Laufwerks und Fehlertoleranztyp. Wenn ein logisches Laufwerk nicht definiert ist, werden die Länge und Anzahl der Blöcke für jenes logische Laufwerk als Null-Werte zurückgegeben. Bei der derzeitigen Implementierung der vorliegenden Erfindung können nur logische Laufwerke 0 und 1 definiert werden.
Der Befehl "Identifizieren Steuerung" dient zum Identifizieren der Konfiguration der Plattengruppensteuerung 112. Der Befehl gibt Information in einen 256 Byte große Puffer zurück und dient vornehmlich zum Zurückmelden der Anzahl definierter logischer Laufwerke. Bei der derzeitigen Implementierung der vorliegenden Erfindung enthält die zurückgelieferte Information die Anzahl der logischen Laufwerke, die Konfigurations-Signatur für die Plattengruppensteuerung und die Firmware- Revision für die Plattengruppensteuerung.
Der Befehl "Identifizieren Status des logischen Laufwerks" dient zum Anzeigen des Status eines speziellen logischen Laufwerks. Information wird nach Ausführung dieses Befehls in einen 256 Byt großen Puffer zurückgemeldet. Die Information enthält den Status des logischen Laufwerks und Laufwerks-Fehlzuordnungsinformation. Mögliche Werte, die über den Status des logischen Laufwerks zurückgemeldet werden, beinhalten: des Ausfall des logischen Laufwerks; die Notwendigkeit einer Konfiguration des logischen Laufwerks; das Arbeiten des logischen Laufwerks im Regenerierungs-Modus. Den Bereitschaftszustand für den Beginn der Wiederherstellung des logischen Laufwerks, und das Wiederherstellen des logischen Laufwerks nach einer Netzabschaltung. Der Befehl "Start Wiederherstellung" ist ein Befehl, der ausschließlich von dem ROM-Speicher des Rechnersystems C während eines POSTs verwendet wird. Dieser Befehl gibt der Plattengruppensteuerung die Erlaubnis, den Wiederherstellungsprozeß einzuleiten.
Die E/A-Befehle instruieren die Plattengruppensteuerung, Streu/Sammel- Operationen für sequentielle Datenblöcke auszuführen. Diese Streu/Sammel-Descriptorstruktur wird von der Plattengruppensteuerung dazu benutzt, Daten innerhalb der Gruppe für den Transfer zu lokalisieren. Die Descriptorstruktur kann Pufferadressen und Pufferlängen für Daten spezifizieren, die zu dem Systemspeicher 58 oder aus diesen zu transferieren sind. Die Gesamtpufferlänge muß genauso groß sein wie die Anzahl von zu transferierenden Bytes bei jeder E/A-Operation.
Der Befehl "Lesen" überträgt sequentielle Datenblöcke von der Platte in Puffer innerhalb des Systemspeichers 58. Zwei Streu/Sammel-Descriptoren stehen zur Verfügung, um Doppel-Ziele für die Daten zu spezifizieren. Die vorliegende Erfindung beinhaltet auch ein Verfahren zum Spezifizieren von Teilblocktransfers. Wenn eine Anfangs-Pufferadresse 0FFFFFFFh (Null) lautet, springt die vorliegende Erfindung zu dem Abstand der angeforderten Bytes, und die Daten für das spezifizierte Intervall werden effektiv ignoriert. Dann liest die vorliegende Erfindung den Rest der Daten innerhalb des speziellen Blocks und überträgt ihn zu der angeforderten Adresse. Die Null-Adresse generiert einen Fehler während eines Schreibvorgangs.
Der Befehl "Schreiben" überträgt Daten aus dem Systemspeicher 58 und schreibt sie in sequentielle Blöcke der Plattenlaufwerksgruppe. Bei einem Schreibbefehl wird der Streu/Sammel-Descriptorzählerstand ignoriert.
Der Diagnosebefehl ist ein spezieller Befehl im Rahmen der Erfindung, der das direkte Manipulieren von Hardware ermöglicht. Im allgemeinen wird dieser Befehl als die einzige Anforderung in einer Befehlsliste ausgegeben. Das einzige zulässige Feld in einem Diagnosebefehl ist das Befehlsfeld. Existiert irgendeine ausstehende Anforderung, wenn der Diagnosebefehl abgegeben wird, so wird ein Abbruchfehler zurückgemeldet. Nachdem die Plattengruppensteuerung in den Diagnosemodus eingestellt ist, ist die Plattengruppensteuerung bereit für den Empfang von Diagnosebefehlen nach Erhalt der Rückmeldung, daß der Befehl ausgeführt ist. Die Plattengruppensteuerung bleibt im Diagnosebetrieb, wenn nichts anderes signalisiert wird, und verarbeitet nicht eine Befehlsliste, die keine Diagnose betrifft.
Der Befehl "Lesen Konfiguration" dient zum Bestimmen der Konfiguration einer Plattengruppensteuerung und meldet die Information in einen 56-Byte-Puffer zurück. Die zurückerreichte Information beinhaltet eine Konfigurations-Signatur, die von der EISA-Konfigurationseinrichtung geliefert und auf reservierte Sektoren in jedem der baulichen Laufwerke eingeschrieben wird. Die Konfigurations-Signatur wird von der Firmware der Plattengruppensteuerung 112 dazu benutzt, zuverlässig zu bestätigen, daß ein bauliches Laufwerk ein Mitglied der konfigurierten Laufwerksgruppe ist. Der Puffer für das Lesen der Konfiguration enthält außerdem Information darüber, ob ein Kompatibilitäts-Pord konfiguriert wurde, bei dem es sich um die Primär- oder Sekundäreinrichtung für den Eingang in die Plattengruppe handelt. Der Puffer für das Lesen der Konfiguration enthält außerdem einen Wert, der den Typ des Betriebssystems angibt, der während der EISA-Konfiguration spezifiziert wurde. Dieser Befehl liefert auch Information über die Gesamtanzahl von baulichen Laufwerken zurück, die durch die Konfigurations-Einrichtung mittels des Diagnosebetriebs nachgewiesen wurde, außerdem die Anzahl von baulichen Laufwerken, die dem logischen Laufwerk während der Konfiguration zugeordnet wurden, und schließlich den Typ des Fehlertoleranzenmodus (Parität gegen Spiegel), der dem logischen Laufwerk von der Konfigurationseinrichtung zugewiesen wurde. Der Puffer für das Lesen der Konfiguration enthält ferner Information über den spezifischen Laufwerksparameter, beispielsweise Sektoren pro Zylinder, Anzahl von Zylindern, Anzahl von Köpfen und Anzahl von Platten. Der bei Beendigung des Befehls "Lesen Konfiguration" wiederhergestellte Puffer enthält außerdem Logik-Laufwerk-Parameter, die von der Konfigurationseinrichtung geliefert werden, und eine Bitkarte, welche anzeigt, welche baulichen Laufwerke welchem speziellen logischen Laufwerk zugeordnet sind.
Das erfindungsgemäße Verfahren basiert auf einem Kommunikationsprotokoll, welches unidirektionale Kanäle für die Kommunikation zwischen dem Systemprozessor 20 und dem logischen Prozessor 122 der Plattengruppensteuerung verwendet. Der Kanal, der zum Senden einer neuen Befehlsliste 200 zu der Plattengruppensteuerung 112 dient, dient auch zum Senden der Länge der Befehlsliste 200 in Bytes sowie einer Etiketten-Kennung zum Identifizieren der Befehlsliste 200. Die Länge wird benötigt, damit die Plattengruppensteuerung 112 die richtige Speichermenge in ihrem lokalen Speicher bereitstellen kann, um die Befehlsliste zu verarbeiten. Die Etiketten-Kennung wird ausschließlich von dem Betriebssystem-Gerätetreiber benutzt und beeinflußt nicht die Verarbeitung der Befehlsliste 200 durch die Plattengruppensteuerung 112. Der Kanal, der die Beendigung der Befehlsliste 200 sowie Fehler signalisiert, verwendet die Adressen der Befehlsliste 200 und den Versatz-Zeiger zu dem Anforderungsblock 204, der die Signalisierung erzeugt hat, die Befehlsliste 200, den Status zur Zeit der Signalisierung und die Etiketten-Kennung, die bei der Übersendung der Befehlsliste 200 gegeben war.

V. System-Betrieb

A. Überblick Befehlsvorlage

Wenn eine neue Befehlsliste 200 an die Plattengruppensteuerung 112 gegeben wird, bestimmt der Systemprozessor 20, ob der Transferkanal frei ist. Ist der Kanal belegt, so kann der Systemprozessor 20 aufrufen, auf das Freiwerden des Kanals warten, oder er kann die Kanal-Frei- Unterbrechung demaskieren, so daß ihm signalisiert wird, wenn die Plattengruppensteuerung den Kanal freigibt. Fig. 6 ist ein Flußdiagramm des Verfahrens, mit dem eine neue Befehlsliste 200 der Plattengruppensteuerung 112 vorgelegt wird. Dieser Vorgang des Vorlegens beginnt mit dem Schritt 300. Der lokale Prozessor 122 empfängt die Meldung über die Vorlage einer Befehlsliste aus dem Türklingelregister im Schritt 302 über die BMIC 118. Die Steuerung geht weiter zum Schritt 304, in welchem der lokale Prozessor 122 ermittelt, ob der Kanal 0 (Befehlsübergabekanal) frei ist. Ist der Kanal frei, geht die Steuerung weiter zum Schritt 306, der das Kanal-Frei-Bit setzt. Die Steuerung geht weiter zum Schritt 308, in welchem die BMIC 118 die Befehlslistenadresse, die Länge und die Etiketten-Kennung in eine Ringschleife lädt. Wenn die Schleife von dem lokalen Prozessor 122 bedient wird, wird die Befehlsliste in die Briefkastenregister übertragen, um von dem lokalen Prozessor 122 gelesen zu werden. Die Steuerung geht weiter zum Schritt 310, in welchem der lokale Prozessor 122 das Kanal-Frei-Bit auf "belegt" einstellt. Die Steuerung geht weiter zum Schritt 332, der die Vorlage des Befehls beendet. Wenn im Schritt 304 der lokale Prozessor 122 feststellt, daß der Befehlsübergabekanal nicht frei ist, fährt der lokale Prozessor 122 damit fort, einen freien Kanal abzufragen. Wenn der Kanal frei ist, geht die Steuerung zum Schritt 304. Wenn der lokale Prozessor 122 im Schritt 312 feststellt, daß die Befehlslistenvorlage eine Prioritäts-Vorlage ist, so geht die Steuerung zum Schritt 316, der die zu übertragende Befehlsliste in eine Warteschlange stellt. Die Steuerung geht zum Schritt 318, in welchem der lokale Prozessor 122 das Kanal- Frei-Unterbrechungsbit demaskiert. Bei der Bedienung der Unterbrechung durch den lokalen Prozessor geht die Steuerung über zum Schritt 320, der das Kanal-Frei-Bit zurückstellt. Die Steuerung geht weiter zum Schritt 322, wo der lokale Prozessor die Befehlsliste aus der Warteschlange nimmt. Die Steuerung geht weiter zum Schritt 324, der die Befehlslistenadresse, die Länge und die Etikettenkennung in die Kanalregister lädt. Die Steuerung geht zum Schritt 326, der ermittelt, ob die Befehlslisten-Vorlageschlange leer ist. Wenn die Befehlslisten-Vorlagenschlange leer ist, geht die Steuerung zum Schritt 328, in welchem der lokale Prozessor 122 das Kanal-Frei-Unterbrechungsbit maskiert. Die Steuerung geht weiter zum Schritt 332, der die Befehlslistenvorlage abschließt. Wenn der lokale Prozessor im Schritt 326 feststellt, daß die Schlange nicht leer ist, geht die Steuerung weiter zum Schritt 330, der das Kanal-belegt-Bit setzt. Dann geht die Steuerung zum Schritt 332, der die Vorlage der Befehlsliste abschließt.

B. Überblick Befehlsabschluß-Signalisierung:

Fig. 7 ist ein Flußdiagramm-Überblick, der die Art und Weise verdeutlicht, in der die vorliegende Erfindung dem den Befehl ausgebenden Gerät meldet, daß der Befehl von der Plattengruppensteuerung abgeschlossen ist. Die Verarbeitung beginnt im Schritt 350. Im Schritt 352 lädt der lokale Prozessor 122 die Befehlslisten-Adresse, den Blockversatz, den Status und die Etiketten-Kennung in Transferregister. Die Steuerung geht weiter zum Schritt 354, in welchem der lokale Prozessor 122 das Kanal-1-Bit als belegt zurückstellt. Die Steuerung geht zum Schritt 356, wo das Kanal-1-Frei-Bit gesetzt wird. Die Steuerung geht zum Schritt 358, in welchem der lokale Prozessor 122 bestimmt, ob ein von 0 verschiedener Blockversatz vorhanden ist. Ist ein Blockversatz von 0 vorhanden, geht die Steuerung zum Schritt 360, der die Befehlsliste als abgeschlossen verarbeitet. Die Steuerung geht zum Schritt 374, der den Ablauf der Meldeprozedur beendet.
Wenn der lokale Prozessor 122 im Schritt 358 feststellt, daß kein von 0 verschiedener Blockversatz vorhanden ist, geht die Steuerung zum Schritt 352, der den Versatz auf die Basisadresse addiert. Die Steuerung geht zum Schritt 364, in welchem der lokale Prozessor 122 feststellt, ob der Befehlslisten-Anforderungsstatus gesetzte Fehlercodes enthält. Gibt es einen gesetzten Fehlercode, so geht die Steuerung zum Schritt 368. Ist kein Fehlercode gesetzt, geht die Steuerung zum Schritt 366, in welchem der lokale Prozessor 122 den Anforderungsblock bis zur Beendigung verarbeitet. Die Steuerung geht zum Schritt 370. Wenn im Schritt 364 der lokale Prozessor 122 feststellt, daß ein Fehlercode gesetzt war und das System im Schritt 368 eine Meldung empfangen hat, geht die Steuerung zum Schritt 370. Im Schritt 370 bestimmt der lokale Prozessor 122, ob weitere Anforderungsblöcke innerhalb der Befehlsliste vorhanden sind. Falls ja, geht die Steuerung zum Schritt 362, und der lokale Prozessor 122 bleibt in einer Schleife so lange, bis sämtliche Anforderungsblöcke als abgeschlossen verarbeitet wurden. Gibt es keine weiteren Anforderungsblöcke, so geht die Steuerung zum Schritt 352, in welchem der lokale Prozessor 122 die Befehlsliste als vollständig verarbeitet. Die Steuerung geht zum Schritt 374, der die Meldeprozedur abschließt.

C. Befehlsprotokollsystem:

Das erste der Modulen innerhalb des erfindungsgemäßen Verfahrens adressiert die Initialisierung der Plattengruppe, um das Verfahren auszuführen. In diesem Modul initialisiert der lokale Prozessor 122 die gesamte BMIC-118-Hardware und die bei dem Verfahren verwendeten Variablen. Außerdem installiert das Modul die BMIC-Unterbrechungs- Behandlungsprozedur.
Die BMIC-Unterbrechungs-Behandlungsprozedur legt die Art und Weise fest, in der die BMIC 118 Anforderungen und/oder Unterbrechungen zwischen dem Systemprozessor 20 und dem lokalen Prozessor 122 bedient.

1. Initialisierung:

Fig. 8 ist ein Flußdiagramm einer Programm-Task, die dazu ausgelegt ist, den Befehlsdurchlauf und das Protokoll zu installieren, die erfindungsgemäß verwendet werden. Die Operationen beginnen mit dem Schritt 400. Die Steuerung geht zum Schritt 402, in dem der lokale Prozessor 122 die unten im Detail näher erläuterte Unterbrechungsbehandlungsprozedur der BMIC 118 installiert. Die Steuerung geht zum Schritt 404, in welchem der lokale Prozessor 122 die Transferkanalsteuerung 148 und die Plattenlaufwerksunterbrechungen installiert. Die Steuerung geht zum Schritt 406, in welchem der lokale Prozessor 122 die gemeinsam benutzten Register und die Semaphor-Pords initialisiert. Die Steuerung geht zum Schritt 408, in welchem der lokale Prozessor die lokalen Türklingelregister, Türklingelunterbrechungen und -masken initialisiert. Die Steuerung geht zum Schritt 410, in welchem der lokale Prozessor 122 die EISA-Türklingelregister, -Unterbrechungen und -Masken initialisiert. Die Steuerung geht zum Schritt 412, in welchem lokale Prozessor die Unterbrechungen des lokalen Prozessors sperrt und die Schnittstellenunterbrechungen zwischen BMIC 118 und lokalem Prozessor einstellt. Die Steuerung geht zum Schritt 414, in welchem der lokale Prozessor 122 die Unterbrechungen des lokalen Prozessors wieder freigibt. Die Steuerung geht zum Schritt 416, der die Initialisierungsprozedur beendet.

2. Lokalprozessor-Unterbrechungsprozedur:

Fig. 11 ist ein Flußdiagramm des Verfahrens, welches dazu dient, Unterbrechungsanforderungen zu überwachen, die von der BMIC 118 und dem lokalen Prozessor 122 empfangen werden. Der Betrieb beginnt im Schritt 550. Der lokale Prozessor 122 transferiert die Steuerung zum Schritt 552, in welchem der lokale Prozessor 122 den laufenden BMIC- Indexwert rettet. Die Steuerung geht zum Schritt 454, wo der lokale Prozessor die lokale Türklingelregistermaske liest, um festzustellen, welche Bits aktiv sind. Die Steuerung geht zum Schritt 456, in dem der lokale Prozessor die lokalen Türklingelbits setzt. Die Steuerung geht zum Schritt 558, in welchem der lokale Prozessor feststellt, ob die Adresse für die Befehlsliste, die an dem Briefkasten entsprechend den aktiven Türklingelbits angekommen ist, verfügbar und unmaskiert ist. Wenn festgestellt wird, daß sie nicht verfügbar ist, oder daß sie nicht unmaskiert ist, geht die Steuerung zum Schritt 560, in welchem der lokale Prozessor ermittelt, ob andere Türklingelbits während dieser Unterbrechungsbedienung als aktiv eingestellt wurden. Sind andere Bits aktiv gesetzt, geht die Steuerung zum Schritt 562, in welchem der lokale Prozessor 122 zu dem nächsten aktiven Bit weiterschaltet, und die Steuerung geht zum Schritt 556. Wenn im Schritt 560 festgestellt wird, daß es keine weiteren aktiven Bits gibt, geht die Steuerung zum Schritt 582. Wenn im Schritt 558 festgestellt wird, daß das laufende Türklingelbit und das dazugehörige Briefkastenregister unmaskiert sind, und der lokale Prozessor 122 die Adresse für die Befehlsliste hat, geht die Steuerung zum Schritt 554, in welchem der lokale Prozessor 122 die Befehlslistenadresse und -Größe aus dem dem Türklingelbit entsprechenden Briefkastenregister ausliest. Die Steuerung geht zum Schritt 566, wo der lokale Prozessor eine Systemtürklingel-Unterbrechung sendet und das EISA-Befehlsvorlagebit löscht. Die Steuerung geht zum Schritt 568, in welchem der lokale Prozessor 122 die Funktion BMIC_IN aufruft, die die Befehlsliste zu dem BMIC-Befehlslader überträgt. Die Steuerung geht zum Schritt 570, wo der lokale Prozessor 122 das Unterbrechungsbit für das lokale Türklingelmaskenbit und den Befehlsvorlagezustand löscht. Die Steuerung geht zu dem Schritt 572, in welchem der lokale Prozessor das Befehlslistenbit löscht. Die Steuerung geht zum Schritt 574, in welchem der lokale Prozessor ermittelt, ob der Befehlsbeendigungskanal frei und unmaskiert ist. Ist er nicht frei und unmaskiert, geht die Steuerung zum Schritt 592. Falls er frei und unmaskiert ist, geht die Steuerung zum Schritt 576, wo der lokale Prozessor 122 die Funktion MELDUNG-LÖSCHEN aufruft, um anzuzeigen, daß die Unterbrechung bedient worden ist. Die Steuerung geht zum Schritt 578, der das lokale Türklingelbefehlsmeldebit in der Maske und das Maskenkanal-Frei-Unterbrechungsbit löscht. Die Steuerung geht zum Schritt 580, in welchem der lokale Prozessor 122 das lokale Befehlsmeldelöschbit in dem lokalen Türklingel-Unterbrechungsregister löscht. Weiterhin löscht der lokale Prozessor 122 das Kanal-Frei-Bit. Die Steuerung geht zum Schritt 582, in welchem der lokale Prozessor 122 den geretteten Wert BMIC_INDEX in das laufende BMIC-Indexregister zurückspeichert. Die Steuerung geht zum Schritt 584, der den Betrieb dieser Funktion beendet, und die Steuerung liegt bei dem Betriebssystem des lokalen Prozessors.
Der nächste Satz von Modulen wird in dem logischen Befehlsempfang durch die BMIC 118 und den lokalen Prozessor 122 verwendet. Diese Routinen beinhalten das Bedienen einer Systemprozessorunterbrechung und das Erhalten der Befehlsliste. In dem folgenden Modul zergliedert der lokale Prozessor die Befehlsliste, um festzustellen, ob die darin enthaltenen Befehle zulässige Befehle sind. Das dritte Modul führt außerdem eine Zergliederungsfunktion aus, jedoch auf individueller Anforderungsbasis, im Gegensatz zu der gesamten Befehlsliste.

3. Logische Befehlsvorlage:

Fig. 9A und 9B sind Flußdiagramme der Verarbeitung von gesendeten Befehlen unter Verwendung der Protokollbefehlsstruktur gemäß der Erfindung. Die Vorlage von Befehlen für den lokalen Prozessor wurde zuvor in Verbindung mit Fig. 6 beschrieben. Fig. 9A und 9B beschreiben die Art und Weise, in der der lokale Prozessor 122 und die BMIC 118 sowie die Transferkanalsteuerung 126 im Rahmen des erfindungsgemäßen Verfahrens arbeiten. Der Ablauf beginnt im Schritt 450 im Anschluß an die Vorlage eines Befehls, wie in Fig. 6 beschrieben ist.
Im Schritt 452 stellt der lokale Prozessor 122 fest, ob die Befehlsliste die maximale Größe von 16 Kbyte überschreitet, die durch die vorliegende Erfindung zugelassen ist. Wenn die Befehlsliste die Maximalgröße überschreitet, geht die Steuerung zum Schritt 454, in welchem eine Fehlernachricht eingerichtet wird, und die Steuerung geht zum Schritt 456, der mit einer Fehlernachricht zum Betriebssystem des lokalen Prozessors zurückkehrt. Wenn der lokale Prozessor im Schritt 452 feststellt, daß die Befehlsliste nicht die maximale Größe von 16 Kbyte überschreitet, geht die Steuerung zum Schritt 458. Im Schritt 458 richtet der lokale Prozessor lokalen Speicher für den Befehlslistenvorsatz, die Transferadresse und die Etikettenkennung ein. Die Steuerung geht zum Schritt 460, in welchem der lokale Prozessor 122 die ersten 1 Kbyte der Befehlsliste liest. Die Steuerung geht zum Schritt 462, der den Befehlslistenvorsatz, die Transferadresse und die Etikettenkennung in den BMIC-Befehlspuffer lädt. Die Steuerung geht zum Schritt 464, in welchem der lokale Prozessor 122 die Routine "Hole - Transferpuffer" aufruft, die die Befehlsliste über die Schnittstelle 124 des lokalen Prozessors in den lokalen Prozessor lädt. Die Steuerung geht zum Schritt 466, in welchem der lokale Prozessor 122 feststellt, ob weitere Elemente der Befehlsliste vorhanden sind. Gibt es zusätzliche Teile der Befehlsliste, geht die Steuerung zurück zum Schritt 460, der damit fortfährt, die Befehlsliste in maximal 1 Kbyte umfassenden Inkrementen einzulesen, bis die Befehlsliste vollständig in den Speicher des lokalen Prozessors übertragen ist. Wenn der lokale Prozessor 122 im Schritt 466 feststellt, daß es keine weiteren Elemente für die Befehlsliste gibt, geht die Steuerung zum Schritt 468, wo der lokale Prozessor 122 die Funktion "Zergliedere neue Liste" aufruft, um die Befehlsliste daraufhin durchzusehen, ob sämtliche Befehle und Anforderungen in ihr zulässig sind. Die Steuerung geht zum Schritt 470, in welchem der lokale Prozessor 122 den von "Zergliedere neue Liste" eingestellten Code überprüft, um festzustellen, ob die Befehlsliste zulässig ist. Ist die Befehlsliste in ihrer Gesamtheit nicht zulässig, geht die Steuerung zum Schritt 454, der eine Fehlernachricht einrichtet, gemäß der die Befehlsliste nicht zulässig ist. Die Steuerung geht zum Schritt 456, der zu dem Betriebssystem des lokalen Prozessors 122 zurückführt. Wenn im Schritt 470 der lokale Prozessor 122 feststellt, daß die Befehlsliste zulässig ist, geht die Steuerung zu den Schritten 472 bis 484, die die spezielle Befehlsanforderung ausliest und den korrekten Befehlssatz aufruft. Wenn der Befehl ein Lesebefehl ist, ruft der Schritt 472 die Funktion "BMIC_READ" auf. Ist der Befehl ein Schreibbefehl, so ruft der Schritt 474 ebenfalls BMIC_READ auf. Wenn der Befehl ein Befehl zum Identifizieren der Steuerung ist, ruft der Schritt 476 die Identifizierfunktion auf. Wenn der Befehl eine Identifiziereinheit ist, ruft der Schritt 478 ebenfalls die Identifizierfunktion auf. Wenn der Befehl "Einstellen Konfiguration" lautet, ruft der Schritt 480 die Funktion "Einstellen Konfiguration" auf. Ist der Befehl ein Befehl "Lesen Einheitenstatus", ruft der Schritt 482 die Funktion "Lesen Einheitenstatus" auf. Für den Fall, daß der Befehl keiner von den oben geschilderten Fällen ist, geht die Steuerung zum Schritt 484, bei dem es sich um den Standardbefehl handelt, und dies wird als schlechter Befehl oder Fehlerbefehl gemeldet. Wenn der Befehl einer von den in den Schritten 472 bis 482 aufgelisteten Befehlen war, geht die Steuerung zum Schritt 492, in welchem der Prozessor 122 feststellt, ob weitere Befehlsanforderungen in der Befehlsliste vorhanden sind. Gibt es weitere Befehle in der Befehlsliste, geht die Steuerung zum Schritt 472, in welcher der lokale Prozessor 122 erneut den Befehl untersucht und die entsprechende Funktion aufruft. Gibt es keine weiteren Befehle in der Befehlsliste, geht die Steuerung über zum Schritt 492.
Wenn im Schritt 484 festgestellt wird, daß der Befehl eine schlechte Anforderung war, geht die Steuerung zum Schritt 486, die eine Fehlernachricht einrichtet, gemäß der der Befehl keiner derjenigen Befehle war, die von BMIC_IN erkannt werden. Die Steuerung geht weiter zum Schritt 488, der den der Befehlsliste zugewiesenen lokalen Speicher freigibt. Die Steuerung geht über zum Schritt 490, in welchem der lokale Prozessor 122 eine Fehlernachricht "schlechte Befehlsliste" einrichtet. Die Steuerung geht weiter zum Schritt 452, in welchem der lokale Prozessor 122 die lokalen Türklingelunterbrechungen demaskiert, um anzuzeigen, daß entweder die Verarbeitung der Befehlsliste abgeschlossen ist, oder aber daß die Befehlsliste fehlerbehaftet ist. Die Steuerung geht weiter zum Schritt 494, der den lokalen Prozessor 122 zu der Betriebssystem-Task zurückgibt.

4. Befehlslisten-Zergliederung/Prüfung:

Fig. 22A und 22B sind Flußdiagramme der Funktion "Zergliedere-neue- Liste", die von der vorliegenden Erfindung dazu benutzt wird, die Zulässigkeit der Befehlsliste 200 zu verifizieren, die der Plattengruppensteuerung 112 überreicht wurde. Aufgerufen wird "Zergliedere-neue- Liste" im Schritt 1100. Die Steuerung geht weiter zum Schritt 1102, in welchem der lokale Prozessor 122 das erste Byte durch den laufenden Puffer auffindet. Die Steuerung geht weiter zum Schritt 1104, in welchem der lokale Prozessor Datenstrukturzeiger einrichtet, die den Befehlslistenvorsatz-Feldern entsprechen. Die Steuerung geht zum Schritt 1106, in welchem der lokale Prozessor 122 den Anforderungsblockzähler liest. Die Steuerung geht zum Schritt 1108, in welchem der lokale Prozessor die Streu/Sammel-Zählerstand-1-Felder in dem Befehlslistenvorsatz liest. Die Steuerung geht zum Schritt 1110, in welchem der Prozessor die Befehlsanforderungsgröße aus der Anforderungsvorsatz- Information ermittelt. Die Steuerung geht zum Schritt 1112, in welchem der lokale Prozessor ermittelt, ob der Streu/Sammel-Zählerstand 1 gleich groß ist wie die Größe in Bytes, die für jenen speziellen Streu/Sammel- Deskriptor spezifiziert ist. Wenn der Streu/Sammel-Zählwert nicht gleich groß ist, geht die Steuerung zum Schritt 1114, der einen Fehlercode einrichtet, und die Steuerung geht zum Schritt 1116, der mit diesem Fehlercode zu dem aufrufenden Programm zurückkehrt. Wenn der lokale Prozessor 122 im Schritt 1112 feststellt, daß der Streu/Sammel-Zählwert 1 der spezifizierten Größe entspricht, geht die Steuerung zum Schritt 1118, wo der lokale Prozessor 122 ermittelt, ob der zweite Streu/Sammel-Zählwert von Null verschieden ist. Ist der zweite Streu/Sammel-Zählwert Null, geht die Steuerung zum Schritt 1130. Wenn der zweite Streu/Sammel-Zählwert von Null verschieden ist, geht die Steuerung zum Schritt 1120, wo der lokale Prozessor 122 den zweiten Streu/Sammel-Zählwert in dem Anforderungsvorsatz liest. Die Steuerung geht zum Schritt 1122, wo der lokale Prozessor 122 die Größe der Anforderung aus dem Anforderungsvorsatz ermittelt. Die Steuerung geht zum Schritt 1124, wo der lokale Prozessor 122 ermittelt, ob der zweite Streu/Sammel-Zählwert der Größe der Daten gleicht. Wenn der zweite Streu/Sammel-Zählwert nicht gleich groß ist, geht die Steuerung zum Schritt 1126, der einen Beendigungscode auf falsch einstellt, und die Steuerung geht zum Schritt 1128, der zum aufrufenden Programm zurückführt. Wenn der zweite Streu/Sammel-Zählwert der richtigen Größe entspricht, geht die Steuerung zum Schritt 1130, wo der lokale Prozessor 122 feststellt, ob die Gesamtgröße der Befehlsliste die maximale Puffergröße von 16 Kbyte für jede Befehlsliste überschreitet und die Größe der spezifizierten Befehlsliste in dem Befehlsvorsatz der tatsächlichen Größe entspricht. Wenn die Gesamtgröße der Befehlsliste 200 die zugewiesene Puffergröße übersteigt, geht die Steuerung zum Schritt 1132, in welchem der lokale Prozessor 122 einen Beendigungscode auf "Falsch" einstellt, und die Steuerung geht weiter zum Schritt 1134, der zu dem aufrufenden Programm zurückführt. Wenn die Gesamtgröße der Befehlsliste gleich oder kleiner ist als der maximale Puffer von 16 Kbyte, geht die Steuerung zum Schritt 1136, wo der lokale Prozessor 122 ermittelt, ob es im Anschluß an die laufende Befehlslistenanforderung eine weitere Anforderung gibt. Gibt es keine weitere Anforderung, geht die Steuerung zum Schritt 1138, in welchem der lokale Prozessor 122 die nächste Anforderung auf Null stellt. Dann geht die Steuerung zum Schritt 1148. Gibt es eine nächste Anforderung, geht die Steuerung zum Schritt 1140, in welchem der lokale Prozessor 122 den Anforderungs-Versatz für die nächste Anforderung auf den Startvorsatz der laufenden Anforderung addiert. Die Steuerung geht weiter zum Schritt 1142, wo der lokale Prozessor 122 ermittelt, ob das Ende der laufenden Anforderung die berechnete Adresse für die nächste Anforderung überlappt. Findet eine Überlappung statt, so geht die Steuerung zum Schritt 1144, wo der lokale Prozessor 122 einen Beendigungscode auf "Falsch" einstellt, und die Steuerung geht weiter zum Schritt 1146, der die Steuerung zu dem aufrufenden Programm zurückbringt. Gibt es keine Überlappung, so geht die Steuerung zum Schritt 1148, in welchem der lokale Prozessor 122 feststellt, ob es zusätzliche Anforderungen in der Befehlsliste 200 gibt. Gibt es zusätzliche Anforderungen in der Befehlsliste 200, so geht die Steuerung zum Schritt 1106, und die Funktion fährt mit dem Zergliedern der Liste so lange fort, bis die Liste vollständig zergliedert ist. Gibt es keine zusätzlichen Anforderungen, geht die Steuerung zum Schritt 1150, der einen Zergliederungs-Beendigungs-Code auf "WAHR" einstellt. Die Steuerung geht zum Schritt 1152, der die Steuerung zu dem aufrufenden Programm zurückbringt.

5. Prüfung Anforderung für nächste Platte:

Fig. 26 ist ein Flußdiagramm für die Funktion "Zergliedere-nächste-Anforderung", die die nächste Anforderung aus der Befehlsliste zergliedert und eine Datenstrukrur für diese spezielle Anforderung aufbaut. Die Funktion "Zergliedere-nächste-Anforderung" wird im Schritt 1300 aufgerufen. Die Steuerung geht weiter zum Schritt 1302, wo der lokale Prozessor 122 feststellt, ob es einen nächsten Anforderungsblock bezüglich der laufenden Anforderung gibt. Gibt es keinen nächsten Anforderungsblock, geht die Steuerung zum Schritt 1324, der die Steuerung zum dem aufrufenden Programm zurückbringt. Gibt es einen nächsten Anforderungsblock, geht die Steuerung zum Schritt 1304, wo der lokale Prozessor 122 die Zeiger in dem Anforderungsvorsatz auf den entsprechenden Versatz bezüglich der nächsten Anforderung einrichtet. Die Steuerung geht zum Schritt 1306, wo der lokale Prozessor 122 lokalen Speicher für den S/G-Zählwert 1 zuweist. Die Steuerung geht zum Schritt 1308, wo der lokale Prozessor 122 die Größe des S/G-Zählwerts 1 und den Zählwert in den lokalen Speicher einkopiert. Die Steuerung geht zum Schritt 1310, wo der lokale Prozessor 122 ermittelt, ob der Anforderungsvorsatz einen zweiten S/G-Zählwert enthält. Gibt es keinen zweiten S/G- Zählwert, geht die Steuerung zum Schritt 1312, wo der lokale Prozessor 122 den S/G-Zählwert 2 auf Null setzt und den Anforderungsvorsatz auf Null stellt. Die Steuerung geht weiter zum Schritt 1318. Wenn der Schritt 1310 feststellt, daß es ein zweites S/G-Zählfeld, geht die Steuerung zum Schritt 1314, wo der lokale Prozessor 122 für den S/G-Zählwert 2 zuweist. Die Steuerung geht zum Schritt 1316, wo der lokale Prozessor 122 den S/G-Zählwert 2 und die Größe des S/G-Zählwerts in den lokalen Speicher einkopiert. Die Steuerung geht dann zum Schritt 1318. Im Schritt 1318 ermittelt der lokale Prozessor 122, ob es eine weitere Anforderung in der Befehlsliste gibt. Gibt es keine weitere Anforderung in der Befehlsliste, geht die Steuerung zum Schritt 1320, in welchem der lokale Prozessor den Zeiger auf die nächste Anforderung auf Null setzt. Die Steuerung geht zum Schritt 1324, der die Steuerung zum dem aufrufenden Programm zurückbringt. Gibt es zusätzliche Anforderungen in der Liste, geht die Steuerung zum Schritt 1322, wo der lokale Prozessor 122 den Zeiger auf den nächsten Anforderungsblock auf den Versatz in dem Anforderungslistenvorsatz einstellt. Die Steuerung geht zum Schritt 1324, der die Steuerung zu dem aufrufenden Programm zurückbringt.
Der nächste Modulsatz betrifft die Art und Weise, in der das erfindungsgemäße Verfahren Daten zu und von dem Hauptrechner und der Plattengruppe überträgt. Das Modul SG_BLOCK wird dazu benutzt, einen Datenblock in die Transferpuffer, die von dem Rechnersystemspeicher verwaltet werden, zu streuen oder ihn aus den Transferpuffern zu sammeln. Das Modul BMIC_XFER dient zum Transfer mehrerer Blöcke von Daten zu oder von dem Rechnersystem C unter Verwendung mehrerer Streu/Sammel-Deskriptoren 204, die in der logischen Anforderung 204 definiert sind. Das Modul BMIC_XFER_QUEUE bringt lediglich eine ankommende Transferanforderung in eine Warteschlange. Das Modul BMIC_READ wird von dem lokalen Prozessor 122 zum Lesen der Transferpuffer in der Plattensteuerung 112 und zum Transferieren der Daten zu dem Hauptsystem benutzt. In ähnlicher Weise wird das Modul BMIC_WRITE von der BMIC dazu benutzt, Daten aus dem Hauptspeicher in Transferpuffer innerhalb der Plattengruppensteuerung 122 einzuschreiben. Das Modul PEEK zeigt das Verfahren, mit dem die Erfindung ein Byte Daten im Systemspeicher liest. In ähnlicher Weise gibt das Modul POKE das Verfahren zum Schreiben eines Datenbytes in den Systemspeicher an.

6. Streu-/Sammel-Blocktransfer:

Fig. 18A und 18B zeigen ein Flußdiagramm für das SG_ BLOCK-Verfahren zum Übertragen von Daten zu und von der Plattengruppensteuerung. Dieses Verfahren zum Übertragen der Daten wird in solchen Fällen verwendet, in denen die Befehlsliste möglicherweise mehr als einen Streu/Sammel-Deskriptorblock pro Befehlsanforderung enthält. Der Betrieb der Funktion SG_BLOCK beginnt im Schritt 960. Die Steuerung geht zum Schritt 962, in welchem der lokale Prozessor 122 das Streu/Sammel-Feld nach einem Zählwert absucht und die Adresse des Start-Deskriptorblocks bestimmt. Die Steuerung geht zum Schritt 964, wo der lokale Prozessor 122 die Hauptadresse und die Größe des durchzuführenden Transfers bestimmt. Es sei angemerkt, daß die Hauptadresse möglicherweise die Adresse von zu dem Hauptsystem zu übertragenden Daten oder die Adresse von Daten enthält, die von dem Hauptrechner zu der Plattengruppensteuerung zu übertragen sind. Die Steuerung geht zum Schritt 966, wo der lokale Prozessor 122 feststellt, ob die berechnete Adresse für den Beginn des Blocks eine Null-Adresse oder 0FFFFFFFh ist. Wenn die berechnete Adresse gleich Null ist, geht die Steuerung zum Schritt 968, der das Flag SG_TRANSFER auf "Falsch" einstellt. Die Steuerung geht zum Schritt 972. Wenn die berechnete Adresse nicht Null ist, geht der Prozessor 122 mit der Steuerung zum Schritt 970, der das Flag SG_TRANSFFR auf "WAHR" einstellt. Die Steuerung geht zum Schritt 972, wo der lokale Prozessor 122 feststellt, ob weitere Daten innerhalb eines laufenden Blocks enthalten sind. Es sei angemerkt, daß eine Anfangs-Null-Adresse dazu benutzt werden kann, einen Block zu kennzeichnen, in welchem die Daten nicht den gesamten Block belegen und um eine gegebene Anzahl von Bytes gegenüber dem Anfang des Blocks versetzt sind.
Wenn der lokale Prozessor 122 im Schritt 972 feststellt, daß weitere Daten sich innerhalb des Befehlsblocks befinden, geht die Steuerung zum Schritt 974, wo der lokale Prozessor 122 den Adressenversatz gegenüber dem Anfang der Blockdaten und die neue Datengröße einrichtet und SG_TRANSFER auf "WAHR" einstellt. Die Steuerung geht zum Schritt 978. Wenn der lokale Prozessor 122 im Schritt 972 feststellt, daß keine weiteren Daten in dem Block vorhanden sind, geht die Steuerung zum Schritt 976, der den Zeiger auf den nächsten Deskriptorblock richtet. Die Steuerung geht zum Schritt 978, wo der lokale Prozessor feststellt, ob das Flag SG_TRANSFER den Wert "WAHR" hat. Ist er "WAHR", geht die Steuerung zum Schritt 980, in welchem der lokale Prozessor 122 feststellt, ob die Operation ein EISA-Lesen oder -Schreiben ist. Es sei angemerkt, daß ein EISA-Lesen von der Plattengruppensteuerung als eine Schreiboperation angesehen wird, wohingegen ein EISA-Schreiben von der Plattengruppensteuerung als eine Leseoperation betrachtet wird. Ist der Befehl ein EISA-Lesen, geht die Steuerung zum Schritt 982, welche die Funktion BMIC_RAAD aufruft, um die erforderliche Information zu übertragen, und das Richtungsbit auf abgehend einstellt.
Wenn der lokale Prozessor im Schritt 980 feststellt, daß der Befehl ein EISA-Schreiben ist, geht die Steuerung zum Schritt 984, der BMIC_READ aufruft, um die Information zu dem Hauptrechner zu übertragen, und der das Richtungs-Bit auf ankommend einstellt. Im Anschluß an den Schritt 982 geht die Steuerung zum Schritt 986. Im Anschluß an den Schritt 984 geht die Steuerung zum Schritt 986. Im Schritt 986 aktualisiert der lokale Prozessor 122 die Anzahl von Blöcken, die zu dem Hauptrechner übertragen worden sind, und die Anzahl von noch für den Transfer verbliebenen Blöcken. Die Steuerung geht zum Schritt 988, der die Transferpufferadresse um eine Blockgröße (521 Byte) aktualisiert. Die Steuerung geht zum Schritt 990, in welchem der lokale Prozessor 122 feststellt, ob weitere Deskriptorblöcke zu oder von dem Hauptrechner zu übertragen sind. Wenn weitere Deskriptorblöcke zu übertragen sind, geht die Steuerung zum Schritt 964, und der lokale Prozessor 122 bleibt so lange in der Schleife, bis der Transfer vollständig ist. Wenn keine weiteren Blöcke zu übertragen sind, geht die Steuerung zum Schritt 992, der die Operation des SG_BLOCK beendet, und die Steuerung geht zurück zum Betriebssystem des lokalen Prozessors 122.

7. BMIC-Datentransfer:

Fig. 17A und 17B sind Flußdiagramme der Funktion BMIC_TRANSFER, die dazu dient, Daten von der Plattengruppensteuerung über die BMIC zu dem aufrufenden Gerät zu übertragen, sei es der Hauptrechner oder irgendein anderes Busmaster-Gerät. Die Funktion wird im Schritt 900 aufgerufen. Die Steuerung geht zum Schritt 902, wo der lokale Prozessor feststellt, ob die logischen Blöcke für die Anforderung beginnen, wozu der logische Eltern-Zeiger verwendet wird. Die Steuerung geht zum Schritt 904, wo der lokale Prozessor 122 feststellt, ob die zu übertragenden logischen Blöcke in einer zusammenhängenden Gruppe liegen. Sind die logischen Blöcke nicht in einer zusammenhängenden Gruppe, geht die Steuerung zum Schritt 906, der die Blockgröße auf den Sektorzählwert für den speziellen zusammenhängenden Block einstellt. Die Steuerung geht zum Schritt 910. Wenn der lokale Prozessor 122 im Schritt 904 feststellt, daß die zu übertragenden Blöcke in einer zusammenhängenden Gruppe liegen, geht die Steuerung zum Schritt 908. Im Schritt 908 setzt der lokale Prozessor 122 die Blockgröße auf den Wert für den gesamten Sektorzählwert für den Transfer. Die Steuerung geht zum Schritt 910, wo der lokale Prozessor 122 die Anfangsblockadresse und den Zeiger auf die logische Anforderung erhält. Die Steuerung geht zum Schritt 912, wo der lokale Prozessor 122 ermittelt, ob die logische Anforderung nur ein Streu/Sammel-Feld auf weist. Hat die logische Anforderung mehr als ein Streu/Sammel-Feld, so geht die Steuerung zum Schritt 938. Wenn die logische Anforderung nur ein Streu/Sammel-Feld hat, wird folgendermaßen ein Hochgeschwindigkeits-Datentransfer vorgenommen. Die Steuerung geht zum Schritt 914, in welchem der lokale Prozessor 122 die Hauptrechner-Startadresse berechnet. Die Steuerung geht zum Schritt 916, in welchem der lokale Prozessor ermittelt, ob die Basisregister verfügbar sind. Sind sie nicht verfügbar, geht die Steuerung zum Schritt 918, wo der lokale Prozessor in einen Warte- oder Abfragezustand eintritt und über den Schritt 916 eine Schleife ausführt, bis die Basisregister verfügbar sind. Sind die Basisregister verfügbar, geht die Steuerung zum Schritt 920, in dem der lokale Prozessor 122 das Transfer-Fertig-Bit löscht und die Transferpuffer-Schnittstellen-Daten in den BMIC-188-Kanal 0 lädt. Die Steuerung geht zum Schritt 922, in welchem der lokale Prozessor 122 die Adresse des BMIC-118-Kanal-0-Puffers gleichsetzt mit der logischen Blockadresse für den Transfer. Die Steuerung geht zum Schritt 924, in welchem der lokale Prozessor 122 die Haupt-Adresse und den Zählerstand in die Basisregister des BMIC-118-Kanal-0 lädt. Die Steuerung geht zum Schritt 926, in welchem der lokale Prozessor 122 die Ausgabe-Blockgröße des Transfers in den Puffer lädt. Die Steuerung geht zum Schritt 928, in welchem der lokale Prozessor 122 ermittelt, ob der Transfer ein Lese- oder ein Schreibvorgang ist. Handelt es sich bei dem Transfer um einen Lesetransfer, so geht die Steuerung zum Schritt 930, der das Richtungs-Bit auf Transferdaten zum EISA-Master einstellt (aus der Sicht der Plattengruppensteuerung 112 wird dies als Schreibvorgang betrachtet). Die Steuerung geht zum Schritt 934. Wenn der lokale Prozessor 122 im Schritt 928 feststellt, daß der Vorgang ein Schreibvorgang ist, geht die Steuerung zum Schritt 932, der das Richtungs-Bit auf Empfang von Daten von dem EISA-Master einstellt (aus der Sicht der Plattengruppensteuerung 112 ist dies effektiv ein Lesevorgang). Die Steuerung geht zum Schritt 934, in welchem der lokale Prozessor den Transfer von 32 Datenbits einleitet, die derzeitige Kanalkonfiguration, das Kanal-Strobe ausgibt und die Haupt-Adresse erhöht. Die Steuerung geht zum Schritt 936, in welchem der lokale Prozessor 122 feststellt, ob noch weitere Blöcke für den Transfer in der Befehlsliste vorhanden sind. Gibt es keine weiteren zu verarbeitenden Anforderungsblöcke, so geht die Steuerung zum Schritt 916, in welchem der lokale Prozessor 122 damit fortfährt, sämtliche Blöcke zu verarbeiten, bis die Befehlsliste 200 fertig ist. Gibt es keine weiteren Anforderungsblöcke 204 für die Verarbeitung mehr, so geht die Steuerung zum Schritt 950.
Wenn der lokale Prozessor 122 im Schritt 912 feststellt, daß die logische Anforderung mehr als einen Streu/Sammel-Deskriptorsatz 208 aufweist, so geht die Steuerung zum Schritt 938, der die SG_BLOCK-Funktion aufruft, die auf das Senden der Blockadresse, der Blockgröße zu der Funktion SG_BLOCK hin erfindungsgemäß die 32 Datenbits, die laufende Ausgangskanalkonfiguration, das Kanal-Strobe sendet und die Hauptadresse erhöht. Die Steuerung geht zum Schritt 940, in welchem der lokale Prozessor 122 feststellt, ob es einen zweiten Streu/Sammel-Deskriptorsatz 208 für die laufenden Anforderung gibt. Dies würde bedeuten, daß Adresseninformation für den Lesebefehl in zwei unterschiedlichen Bereichen des Systemspeichers aufgefunden werden kann. Gibt es keinen zweiten Streu/Sammel-Deskriptorsatz, geht die Steuerung zum Schritt 944. Gibt es einen zweiten Streu/Sammel-Deskriptorsatz, geht die Steuerung zum Schritt 942, in welchem die Blockadresse, die Blockgröße zu der Funktion SG_BLOCK gesendet und ein Transfer von 32 Datenbits erfolgt, die Kanalkonfiguration, das Kanal-Strobe zu dem Hauptgerät gesendet und die Hauptadresse erhöht wird. Die Steuerung geht zum Schritt 944, in welchem der lokale Prozessor 122 feststellt, ob es weitere Anforderungsblöcke für die Verarbeitung gibt. Gibt es weitere Anforderungsblöcke 204 zur Verarbeitung, so geht die Steuerung zurück zum Schritt 938, und die Funktion fährt in der Schleife fort, bis sämtliche Anforderungsblöcke 204 verarbeitet sind. Wenn der lokale Prozessor 122 im Schritt 944 feststellt, daß es keine weiteren Anforderungsblöcke 204 für die Verarbeitung gibt, geht die Steuerung zum Schritt 946, in dem der lokale Prozessor 122 den Zeiger der BMIC-Anforderungsschlange auf die nächste Befehlsliste 200 vorrückt. Die Steuerung geht zum Schritt 950, wo der lokale Prozessor 122 der Treiber-Task meldet, daß der Transfer abgeschlossen ist. Die Steuerung geht zum Schritt 952, der die Ausführung dieser Funktion abschließt und die Steuerung zu dem Betriebssystem des lokalen Prozessors 122 zurückbringt.

8. BMIC-Datentransfer-Schlange:

Fig. 19 ist ein Flußdiagramm der Funktion BMIC_XFER_QUE. Diese Funktion wird von der vorliegenden Erfindung dazu benutzt, BMIC- Transfers in die Warteschlange zu stellen, wenn es mehrere BMIC- Transfers gibt, die der lokale Prozessor zu bearbeiten hat. BMIC_XFER_QUE wird von dem aufrufenden Programm im Schritt 1000 aufgerufen. Die Steuerung geht zum Schritt 1002, wo der lokale Prozessor 122 ermittelt, ob die BMIC_XFER_QUE leer ist. Ist die BMIC_XFER_QUE nicht leer, geht die Steuerung zum Schritt 1004, der die Anforderung zu dem Ende der BMIC_XFER_QUE hinzufügt. Die Steuerung geht zum Schritt 1008. Wenn der lokale Prozessor 122 im Schritt 1002 feststellt, daß die BMIC_XFER_QUE leer ist, geht die Steuerung zum Schritt 1006. Im Schritt 1006 initialisiert der lokale Prozessor 122 die Schlange, setzt die Zeiger für den Kopf der Schlange und das Ende der Schlange auf die laufende Anforderung. Die Steuerung geht zum Schritt 1008, wo der lokale Prozessor 122 den Zeiger für die nächste Anforderung auf Null setzt. Die Steuerung geht zum Schritt 1010, der die Steuerung an das aufrufende Programm zurückgibt.

9. BMIC-Daten-Lesen:

Fig. 12 ist ein Flußdiagramm der Funktion BMIC_READ, die die vorliegende Erfindung dazu benutzt, zu der Plattengruppensteuerung 112 gesendete Information zu lesen (effektiv, von dem System oder dem Gerätetreiber zu schreiben). Die Funktion BMIC-READ wird im Schritt 600 aufgerufen. Die Steuerung geht zum Schritt 602, wo der lokale Prozessor 122 wartet, bis sämtliche BMIC-Kanal-0-Basisregister verfügbar sind. Die Steuerung geht zum Schritt 604, in welchem der lokale Prozessor 122 feststellt, ob die Hauptpufferadresse für die zu der Plattengruppensteuerung 112 zu sendenden Daten gemäß ungeradem Byte ausgerichtet sind. Wird festgestellt, daß die Hauptpufferadresse gemäß ungeradem Byte ausgerichtet ist, geht die Steuerung zum Schritt 606, in welchem der lokale Prozessor 122 die Adresse und die Daten erhält, die in dem ersten Byte enthalten sind, und lädt sie in den Transferpuffer. Die Steuerung geht zum Schritt 608, in welchem der lokale Prozessor 122 die PEEK-Funktion aufruft, um das erste Byte effektiv von dem Haupt- in den Transferpuffer zu transferieren. Die Steuerung geht nach 610, wo der lokale Prozessor 122 die Startadresse für die Daten aus dem Hauptpuffer auf das nächste Byte erhöht, wodurch effektiv die Bytes ausgerichtet werden, und er dekrementiert die Anzahl zu übertragender Bytes. Dann geht die Steuerung zum Schritt 612. Wenn im Schritt 604 der lokale Prozessor 122 feststellt, daß die Hauptpufferadresse nicht gemäß ungeradem Byte ausgerichtet ist, geht die Steuerung zum Schritt 612. Im Schritt 612 stellt der lokale Prozessor 122 die Richtung des Transfers ein und lädt die Transferpufferadresse in den BMIC-Kanal 0. Die Steuerung geht zum Schritt 614, wo der lokale Prozessor 122 die Datengröße und 32 Bits umfassende Daten von dem Haupt- in den Transferpuffer überträgt. Im Schritt 616 transferiert der lokale Prozessor 122 die Kanalkonfiguration und das Kanal-Strobe in den Transferkanalpuffer. Die Steuerung geht zum Schritt 618, der das laden der Transferkanal-Schnittstellen-Information in die BMIC 118 abschließt. Die BMIC-118 leitet dann den Transfer der Sektordaten mit der Transferkanalsteuerung 124 ein, was dazu führt, daß die Daten automatisch aus dem Hauptspeicher in den Transferpufferspeicher 130 zum späteren Transfer zu der Plattengruppe übertragen werden. Die Steuerung kehrt zu dem Betriebssystem des lokalen Prozessors 122 zurück.

10. BMIC-Daten Schreiben:

Fig. 13 ist ein Flußdiagramm der Funktion BMIC_WRITE, die von der vorliegenden Erfindung dazu benutzt wird, die Transferpuffer-Schnittstellen-Schreibbefehle aus der Plattengruppensteuerung 112 zu laden (es handelt sich effektiv um ein Lesen aus dem Systemprozessor). BMIC_WRITE wird im Schritt 650 aufgerufen. Die Steuerung geht zum Schritt 652, in welchem der lokale Prozessor 122 wartet, bis die Basisregister des BMIC-Kanals 0 verfügbar sind. Die Steuerung geht zum Schritt 654, in welchem der lokale Prozessor 122 ermittelt, ob die Transferpufferadresse gemäß ungeradem Bite ausgerichtet ist. Wenn festgestellt wird, daß die Transferpufferadresse aus der Plattengruppe gemäß ungeradem Bite ausgerichtet ist, geht die Steuerung zum Schritt 656, in welchem der lokale Prozessor 122 das erste Byte und die Adresse von Daten aus der Plattengruppe holt. Die Steuerung geht zum Schritt 658, in welchem der lokale Prozessor 122 die Funktion POKE aufruft, um das erste nicht-ausgerichtete Byte zu dem Hauptrechner zu holen. Die Steuerung geht zum Schritt 660, wo der lokale Prozessor 122 die Startadresse erhöht und die Anzahl von noch zu übertragenden Bytes verringert. Die Steuerung geht zum Schritt 662. Wenn im Schritt 654 bestimmt wird, daß die Transferpufferadresse nicht gemäß ungeradem Byte ausgerichtet ist, geht die Steuerung zum Schritt 662. Im Schritt 662 stellt der lokale Prozessor 122 die Transferrichtung ein und lädt die Transferpuffer-Schnittstellen-Adresse in den BMIC-Kanal 0. Die Steuerung geht zum Schritt 664, in welchem der lokale Prozessor 122 die Datengröße und 32 Datenbits zu dem Hauptrechner überträgt. Die Steuerung geht nach 666, wo der lokale Prozessor 122 die Transferkanal- Konfiguration und das Kanal-Strobe zu dem Transferkanalpuffer überträgt. Der Datentransfer aus dem Transferpufferspeicher 130 erfolgt in ähnlicher Weise wie bei dem Transfer von BMIC_DATEN_LESEN. Die Steuerung geht zum Schritt 668, der die Funktion BMIC-WRITE beendet und die Steuerung des Systems zum Betriebssystem des lokalen Prozessors 122 zurückführt.

11. PEEK-Modus-Datentransfer:

Fig. 20 ist ein Flußdiagramm der Funktion PEEK, mit der der lokale Prozessor 122 ein einzelnes Byte des Speichers von dem Hauptprozessor oder einem anderen Gerätetreiber liest. Die Funktion PEEK wird im Schritt 1020 aufgerufen. Die Steuerung geht zum Schritt 1022, in welchem der lokale Prozessor 122 ermittelt, ob ein weiterer PEEK/POKE- Zyklus aktiv ist. Stellt der lokale Prozessor 122 fest, daß ein weiterer PEEK/POKE-Zyklus aktiv ist, so geht die Steuerung zum Schritt 1024, in welchem der lokale Prozessor 122 wartet, bis die derzeit aktive PEEK/POKE-Operation abgeschlossen ist. Die Steuerung geht zurück zum Schritt 1022, der erneut abfragt, ob ein weiterer PEEK/POKE- Zyklus aktiv ist. Ist kein weiterer PEEK/POKE-Zyklus aktiv, geht die Steuerung zum Schritt 1026, in welchem der lokale Prozessor 122 das PEEK/POKE-Register mit der lokalen Adresse lädt, in die die Daten einzulesen sind. Die Steuerung geht zum Schritt 1028, in welchem der lokale Prozessor 122 die Hauptadresse in das PEEK/POKE-Register lädt. Die Hauptadresse repräsentiert diejenige Adresse im Systemspeicher 58 oder dem Gerätetreiberspeicher, aus dem die Daten erhalten werden. Die Steuerung geht zum Schritt 1030, in welchem der lokale Prozessor 122 die PEEK-Adresse zu der BMIC 118 sendet, die den PEEK-Zyklus ausführt, um die Daten aus dem Haupt- oder dem Gerätetreiber-Speicher zu lesen. Die Steuerung geht zum Schritt 1032, in welchem die von dem Haupt- oder Gerätetreiberspeicher gelesenen Daten für den lokalen Prozessor 122 ausgerichtet werden. Die Steuerung geht zum Schritt 1034, der die Steuerung zu dem Betriebssystem des lokalen Prozessors zurückbringt.

12. POKE-Modus-Datentransfer:

Fig. 21 ist ein Flußdiagramm der Funktion POKE, die von dem lokalen Prozessor 122 dazu benutzt wird, ein Informationsbit an den Haupt- oder Gerätetreiberspeicher zu senden. Die POKE-Funktion wird vom Schritt 1050 aufgerufen. Die Steuerung geht zum Schritt 1052, in welchem der lokale Prozessor 122 ermittelt, ob ein weiterer PEEK/POKE-Zyklus aktiv ist. Ist ein weiterer PEEK/POKE-Zyklus aktiv, so geht die Steuerung zum Schritt 1054, in welchem der lokale Prozessor 122 wartet, bis der laufende PEEK/POKE-Operationszyklus abgeschlossen ist. Die Steuerung geht zum Schritt 1052, in welchem der lokale Prozessor 122 erneut abfragt, ob ein weiterer PEEK/POKE-Zyklus aktiv ist. Ist kein weiterer PEEK/POKE-Zyklus aktiv, so geht die Steuerung zum Schritt 1056, in welchem der lokale Prozessor 122 das PEEK/POKE-Register mit der lokalen Adresse der Information lädt, die zu dem Haupt- oder Gerätetreiberspeicher gesendet werden soll. Die Steuerung geht zum Schritt 1058, wo der lokale Prozessor 122 die Hauptadresse in das PEEK/POKE-Register lädt. Die Hauptadresse repräsentiert diejenige Zieladresse, zu der die Daten von dem lokalen Prozessor aus zu senden sind. Die Steuerung geht zum Schritt 1060, wo die BMIC 118 das Datenbyte auf die richtigen Byte-Spuren ausrichtet und in das PEEK/POKE-Register lädt. Die Steuerung geht zum Schritt 1062, und der lokale Prozessor 122 sendet die POKE-Anforderung an die BMIC, die auf die POKE-Anforderung in der Weise einwirkt, daß sie die Daten zu dem Haupt- oder Gerätetreiberspeicher sendet. Die Steuerung geht zum Schritt 1064, der den Betrieb der POKE-Funktion beendet und die Steuerung zu dem Betriebssystem des lokalen Prozessors 122 zurückbringt.
Der nächste Modulsatz betrifft das Verfahren, mit welchem die vorliegende Erfindung dem Rechnersystem C die Befehls-Beendigung oder einen Fehler meldet. Das Modul BMIC_OUR ist das Hauptmodul, mit dem die Plattensteuerung 112 dem Rechnersystem den Zustand der Befehlsausführung meldet. Das Modul POST_NOTIFICATION wird dazu benutzt, die BMIC so zu programmieren, daß sie die in BMIC_OUT verlangte Meldung ausführt. Das Modul NOTIFICATION_CLEAR wird verwendet, wenn das Hauptsystem nicht in der Lage gewesen ist, mit den Beendigungs-Meldungen Schritt zu halten. Die Meldungen werden in die Warteschlange gestellt, bis der Meldekanal von dem Hauptsystem gelöscht ist.

13. Befehlsabschluß-Signalisierung:

Fig. 10A und 10B sind Flußdiagramme der Funktion BMIC-OUT, die von der vorliegenden Erfindung dazu verwendet wird, dem Systemprozessor zu signalisieren, daß die Befehlsliste abgeschlossen wurde oder ein Fehler aufgetreten ist. Der Vorgang dieser Meldung an den Systemprozessor 20, wonach ein Befehl abgeschlossen ist, wird allgemein in Verbindung mit Fig. 7 beschrieben. Fig. 10A und 10B spezifizieren das Verfahren, von dem die Erfindung Gebrauch macht. Der Ablauf von BMIC_OUT beginnt damit, daß ein System von dem lokalen Prozessor 122 im Schritt 500 aufgerufen wird. Die Steuerung geht zum Schritt 502, in welchem der lokale Prozessor 122 auf den Listenvorsatz einen Liste-Fertig-Zeiger einstellt. Die Steuerung geht zum Schritt 504, wo der lokale Prozessor 122 ermittelt, ob die Befehlsliste einen Befehlslistenfehler oder -abbruch angibt. Wenn der Listenstatus einen Fehler oder einen Abbruch anzeigt, geht die Steuerung zum Schritt 506, in welchem der lokale Prozessor 122 den Listenfehler in dem Listenstatusregister setzt. Die Steuerung geht zum Schritt 508, wo der lokale Prozessor die Subroutine POKE aufruft, um den Fehler zu dem Master- Gerät zu senden, welches den Befehl gesendet hat. Die Steuerung geht zum Schritt 510, in welchem der lokale Prozessor 122 ermittelt, ob das Steuerflag, welches in dem Befehlslistenvorsatz gesetzt ist, nach einem Abbruch bei Fehler verlangt. Wird ein Abbruch bei Fehler verlangt, so geht die Steuerung zum Schritt 512, der den Befehlsstatus auf Abbruch einstellt und den letzten fertigen Befehl sichert. Dann geht die Steuerung zum Schritt 536. Wenn im Schritt 510 festgestellt wird, daß das Steuerflag nicht auf Abbruch bei Fehler eingestellt wurde, geht die Steuerung zum Schritt 522, in welchem der lokale Prozessor 122 ermittelt, ob das Steuerflag gesetzt ist, um bei Fehler eine Meldung zu machen. Wenn dieses Melden bei Fehler nicht gesetzt ist, geht die Steuerung zum Schritt 536. Wenn Meldung bei Fehler gesetzt ist, geht die Steuerung zum Schritt 524, im welchem der lokale Prozessor 122 feststellt, ob der den Fehler verursachende Befehl die letzte Befehlsanforderung in der Liste war. Falls dies so ist, geht die Steuerung zum Schritt 526, wo der lokale Prozessor die letzte abgeschlossene Befehlsanforderung sichert. Die Steuerung geht zum Schritt 526. Wenn die Befehlsanforderung, die den Fehler verursacht, nicht die letzte Anforderung innerhalb der Liste war, geht die Steuerung zum Schritt 528, der die Funktion POST_NOTIFICATION aufruft, welche die Adresse des den Fehler verursachenden Befehls sendet. Die Steuerung geht zum Schritt 536.
Wenn im Schritt 504 der Listenvorsatz keinen Fehler oder einen Abbruch enthält, geht die Steuerung zum Schritt 514, in welchem der lokale Prozessor 122 ermittelt, ob das Steuerflag innerhalb des Befehlslistenvorsatzes gesetzt ist, um bei Beendigung zu melden. Wenn die Meldung bei Beendigung gesetzt ist, geht die Steuerung zum Schritt 516, in welchem der lokale Prozessor 122 ermittelt, ob die beendete Anforderung die letzte Befehlsanforderung in der Befehlsliste 200 war. Wenn die Befehlsanforderung 204 die letzte Anforderung in der Befehlsliste 200 ist, geht die Steuerung zum Schritt 518, in welchem der lokale Prozessor 122 die letzte Anforderung als Adresse der abgeschlossenen Befehlsanforderung sichert. Die Steuerung geht zum Schritt 530. Wenn im Schritt 516 ermittelt wird, daß die Anforderung nicht die letzte Befehlsanforderung in der Befehlsliste ist, geht die Steuerung zum Schritt 520, und der lokale Prozessor 122 ruft die Funktion POST_NOTIFICATION auf, um anzuzeigen, daß die spezielle Anforderung innerhalb der Liste abgeschlossen worden ist. Die Steuerung geht zum Schritt 536. Wenn im Schritt 514 anhand der Steuerflags des Befehlslistenvorsatzes festgestellt wird, daß die Anforderung bei Beendigung nicht zu melden ist, geht die Steuerung zum Schritt 530. Im Schritt 530 ermittelt der lokale Prozessor 122, ob die Befehlsliste vollständig ist. Wenn die Befehlsliste 200 vollständig ist, geht die Steuerung zum Schritt 532, und der lokale Prozessor 122 setzt den Listenstatus in dem Befehlslistenvorsatz auf "Liste vollständig". Die Steuerung geht zum Schritt 534, wo der lokale Prozessor 122 die Funktion "POST_NOTIFICATION" aufruft, um den Liste-Fertig-Status zu dem aufrufenden Gerät zu senden. Die Steuerung geht zum Schritt 536, der den lokalen Speicher, der den Befehlslistenvorsätzen, der Befehlslistenanforderung und den Feldern für die Befehlslisten-Streu/Sammel-Descriptoren zugeordnet war, frei. Die Steuerung geht zum Schritt 538, der die Steuerung des lokalen Prozessors 122 zu dem Echtzeitsystem zurückreicht.

14. Befehls-Signalisierung:

Fig. 25 ist ein Flußdiagramm der Funktion NOTIFICATION_CLEAR. NOTIFICATION-CLEAR wird im Schritt 1250 aufgerufen. Die Steuerung geht zum Schritt 1252, wo der lokale Prozessor 122 die Signalisier-Information in die Register des Kanals 1 lädt. Die Steuerung geht zum Schritt 1254, in welchem der lokale Prozessor 122 das System-Türklingel-Bit setzt. Die Steuerung geht zum Schritt 1256, wo der Prozessor 122 in die Transferregister die Adresse, den Versatz, den Status und die Etiketten-Kennung lädt. Die Steuerung geht zum Schritt 1258, in welchem der lokale Prozessor 122 das Kanal-Lösch-Bit zurücksetzt. Die Steuerung geht zum Schritt 1260, wo der lokale Prozessor 122 das System-Türklingel-Bit setzt. Die Steuerung geht zum Schritt 1262, wo der lokale Prozessor 122 ermittelt, ob die Signalisier-Warteschlange leer ist. Ist sie nicht leer, geht die Steuerung zum Schritt 1264, die das Löschen-Unterbrechungs-Bit für den lokalen Kanal 1 demaskiert. Die Steuerung geht zum Schritt 1266. Wenn im Schritt 1262 festgestellt wird, daß die Signalisier-Warteschlange leer ist, geht die Steuerung zum Schritt 1266. Im Schritt 1266 ermittelt der lokale Prozessor 122, ob die Funktion BMIC_OUT blockiert ist. Ist sie blockiert, geht die Steuerung zum Schritt 1268, in welchem der lokale Prozessor 122 ermittelt, ob BMIC_OUT bei Signalisierungen blockiert. Blockiert sie bei Signallsierungen, geht die Steuerung zum Schritt 1270, in welchem der lokale Prozessor 122 die Funktion POST_NOTIFICATION aufruft, um Meldungen für das System in die Warteschlange zu stellen. Außerdem wird ein Flag "NOTIFY_OUT-Blockierung" gesetzt. Die Steuerung geht zum Schritt 1274, der die Steuerung zu dem aufrufenden Programm zurückbringt. Wenn BMIC_OUT nicht bei Meldungen blockiert ist, geht die Steuerung zum Schritt 1272, der die Funktion POST_NOTIFICATION aufruft und ein Flag "NOTIFY_IN- Blockierung" setzt. Die Steuerung geht zum Schritt 1274. Wenn der Schritt 1266 ermittelt, daß BMIC_OUT nicht blockiert ist, geht die Steuerung zum Schritt 1274, der zum aufrufenden Programm zurückführt.

15. Befehlsabschluß-Nachmeldung:

Fig. 24 ist ein Flußdiagramm der Funktion POST_NOTIFICATION, die dazu dient, den Abschluß einer Befehlsliste zu melden. POST_NOTIFICATION wird im Schritt 1200 aufgerufen. Die Steuerung geht zum Schritt 1202, wo der lokale Prozessor 122 ermittelt, ob es eine Meldungs-Ring-Warteschlange gibt. Die Steuerung geht zum Schritt 1204, wenn es eine Warteschlange gibt. Der lokale Prozessor weist im Schritt 1204 Speicher für die Meldedatenstruktur zu. Die Steuerung geht zum Schritt 1206, wo der lokale Prozessor 122 die Adresse, den Versatz, die Etikettenkennung und den Status in die Meldedatenstruktur lädt. Die Steuerung geht zum Schritt 1208, der die Meldedatenstruktur an das Ende der POST_QUEUE stellt. Die Steuerung geht zum Schritt 1228. Wenn festgestellt wird, daß es im Schritt 1202 keine Warteschlange gibt, geht die Steuerung zum Schritt 1210, in welchem der lokale Prozessor 122 die lokale Türklingel-Unterbrechung demaskiert. Die Steuerung geht zum Schritt 1212, wo der lokale Prozessor 122 ermittelt, ob das lokale Befehlsmeldebit gelöscht ist. Ist das lokale Befehlsmeldebit nicht gelöscht, geht die Steuerung zum Schritt 1214, wo der lokale Prozessor 122 Speicher für die Melde-POSTIT zuweist. Die Steuerung geht zum Schritt 1216 wo der lokale Prozessor 122 die Adresse, den Versatz, den Status und die Etikettenkennung in die Datenstruktur lädt. Die Steuerung geht zum Schritt 1218, der eine Ring-Warteschlange erzeugt, und sie plaziert die Meldestruktur am Kopf der Schlange. Die Steuerung geht zum Schritt 1220, wo der lokale Prozessor die lokale Türklingel-Unterbrechung demaskiert. Die Steuerung geht zum Schritt 1228. Wenn im Schritt 1212 der lokale Prozessor 122 feststellt, daß das lokale Befehlsmelde-Löschbit gesetzt ist, geht die Steuerung zum Schritt 1222, wo der lokale Prozessor 122 Meldeinformation in Register lädt und die System-Türklingel setzt. Die Steuerung geht zum Schritt 1224, wo der lokale Prozessor 122 Adresse, Versatz, Status und Etikettenkennungs-Information in die Transferpuffer lädt. Die Steuerung geht zum Schritt 1226, in welchem der lokale Prozessor 122 die System-Türklingelunterbrechung demaskiert. Dann geht die Steuerung zum Schritt 1228, wo die Steuerung zum aufrufenden Programm zurückkehrt.
Der nächste Satz von Modulen wird von der vorliegenden Erfindung dazu benutzt, Nicht-E/O-Platten-Befehle auszuführen, beispielsweise das Einstellen und das Prüfen der Konfiguration der Plattengruppe. Das Modul SET-CONFIGURATION dient zum Erzeugen einer Konfiguration für die gesamte Gruppe. Das Modul SENSE_CONFIGURATION dient zum Bestimmen, welche Konfiguration innerhalb der Gruppe existiert. Der Befehl SET_CONFIGURATION wird von dem EISA-COMS bei Beendigung einer logischen Einheit durch die EISA-Konfigurationsroutine ausgegeben. Das Modul BMIC_SENSE_UNIT dient zum Bestimmen des Status einer spezifizierten Logikeinheit für das Hauptsystem. Das Modul IDENTIFY dient zum Identifizieren jeglicher Steuerung des speziellen Typs von Platte innerhalb der Gruppe, basierend auf dem ausgegebenen logischen Befehl. Das Modul CONFIGURATION_VALID dient zum Bestimmen, ob die existierende Konfiguration für die Plattengruppe zulässig für die Steuerung und die gesamte Systemkonfiguration ist.

16. Konfigurieren Logikeinheit:

Fig. 14A und 14B sind Flußdiagramme der Funktion Z_CONFIGURATION. Diese Konfigurations-Einstell-Funktion dient zum Initialisieren einer logischen Einheit durch den lokalen Prozessor 122 und läuft im allgemeinen dann ab, wenn die Plattengruppe als erstes initialisiert wird, oder wenn zusätzliche und/oder Austausch-Platten zu dem Plattengruppen-Laufwerksystem hinzugefügt werden. Z_CONFIGURATION wird im Schritt 700 von dem lokalen Prozessor 122 aufgerufen. Die Steuerung geht zum Schritt 702, in welchem der lokale Prozessor 122 feststellt, ob die Anzahl logischer Laufwerke, die in dem Befehl verlangt werden, die maximale Anzahl logischer Laufwerke für das System übersteigt. Übersteigen die logischen Laufwerke die maximale Anzahl, so geht die Steuerung zum Schritt 704, in welchem der logische Prozessor 122 einen Beendigungs-Code auf "Falsch" setzt und die Steuerung des Systems im Schritt 706 zu dem lokalen Prozessor 122 zurückgibt. Wenn im Schritt 702 festgestellt wird, daß die Anzahl der logischen Laufwerke nicht die maximale Anzahl zulässiger Laufwerke übersteigt, geht die Steuerung zum Schritt 708, in welchem der lokale Prozessor die Konfigurations-Puffergröße ermittelt. Die Steuerung geht zum Schritt 710, wo der lokale Prozessor 122 Speicherplatz für den Konfigurationspuffer zuweist. Die Steuerung geht zum Schritt 712, in welchem der lokale Prozessor 122 die Konfigurationsdaten von dem Hauptsystem zu der Transferpuffer-Schnittstelle überträgt. Die Steuerung geht zum Schritt 714, in welchem der lokale Prozessor 122 die Konfigurationsdaten aus dem Transferpuffer in den lokalen Speicher überträgt. Die Steuerung geht zum Schritt 716, in welchem der logische Prozessor 122 die Funktion CONFIGURATION_VALID aufruft, die einen zulässigen oder einen nicht zulässigen Rückkehr-Code zurückgibt. Die Steuerung geht zum Schritt 718, wo der lokale Prozessor 122 ermittelt, ob der Rückkehr- Code zulässig ist. Ist er nicht zulässig, geht die Steuerung zum Schritt 758. Ist der Rückkehr-Code zulässig, geht die Steuerung zum Schritt 720, in welchem der lokale Prozessor 122 ermittelt, ob die globalen reservierten Informationssektoren (RIS) einem Wert von Null entsprechen. Falls nicht Null, bedeutet die globale Plattengruppen-RIS- Information, daß eine frühere Konfiguration existierte, und im Schritt 722 wird ein Flag FIRST_CONFIG auf "Falsch" gesetzt. Die Steuerung geht zum Schritt 728. Wenn der Wert GLOBAL_RIS Null ist, so bedeutet dies, daß es keine frühere Konfiguration der Plattengruppe gegeben hat. Die Steuerung geht dann zum Schritt 724, der einer globalen RIS-Struktur lokalen Speicher zuweist und das Flag FIRST_CONFIG auf "WAHR" setzt. Die Steuerung geht zum Schritt 726, der die RIS- Signatur aus dem Hauptsystem in die lokale Datenstruktur kopiert. Die Steuerung geht zum Schritt 728. Im Schritt 728 kopiert der lokale Prozessor die Konfigurations-Signatur und die Daten des baulichen Laufwerks in die lokale Datenstruktur für die globale RIS. Die Steuerung geht zum Schritt 730. Wenn das Flag FIRST_CONFIG auf "WAHR" gesetzt ist, geht die Steuerung zum Schritt 723, wo der lokale Prozessor 122 sämtliche logischen Laufwerke liest. Die Steuerung geht zum Schritt 734, der den Laufwerkstatus für sämtliche Laufwerke auf "o.k." und verfügbar setzt. Die Steuerung geht zum Schritt 738. Wird im Schritt 738 festgestellt, daß das Flag "FIRST-CONFIG" "FALSCH" ist, so geht die Steuerung zum Schritt 736, in welchem der lokale Prozessor 122 das logische Laufwerk einstellt auf den Start bei dem als nächstes verfügbaren oder nicht benutzten Volumen setzt. Die Steuerung geht zum Schritt 738. Im Schritt 738 lädt der lokale Prozessor 122 das Transfervolumen, CPC-Port-Adresse, Betriebssystem, Verschachtelungsschema, Laufwerk-Zählerstand, Fehlertoleranz und Benutzer-Laufwerkzählerstand, die sämtlich Information darstellen, welche sich auf die bauliche Konfiguration der logischen Einheit bezieht. Die Steuerung geht zu den Schritten 740 und 742, in denen der lokale Prozessor 122 das Flag für die Fehlertoleranz liest, um festzustellen, wie die Anzahl der verfügbaren Laufwerke einzustellen ist. Wenn im Schritt 740 paritätische Laufwerkstoleranz eingestellt wurde, zeigt der lokale Prozessor 122 an, daß Laufwerke 3 und 7 für die paritätische Laufwerkstoleranz eingestellt sind und die Laufwerke nicht länger für die Benutzung verfügbar sind. Wenn die Fehlertoleranz auf Spiegelfehlertoleranz eingestellt ist, verringert im Schritt 742 der lokale Prozessor 122 die Anzahl von verfügbaren Benutzerlaufwerken, indem er anzeigt, daß es insgesamt vier verfügbare Benutzerlaufwerke im Gegensatz zu acht Laufwerken gibt, oder daß die Hälfte der Laufwerke verfügbar ist. Die Steuerung geht zum Schritt 744, in welchem der lokale Prozessor 122 den Blockversatz berechnet, um den ersten Zylinder für sämtliche Platten in der Gruppe zu reservieren für ein eventuelles Schreiben der gesamten RIS-Information in diesen ersten Zylinder. Die Steuerung geht zum Schritt 746, in welchem der lokale Prozessor sämtliche logischen Plattenparameter zu dem Transfer-Schnittstellenpuffer überträgt. Die Steuerung geht zum Schritt 748, wo der lokale Prozessor 122 eine logische Karte für jedes Laufwerk und für sämtliche Laufwerke innerhalb der Gruppe erstellt. Die Steuerung geht zum Schritt 750, in welchem der lokale Prozessor 122 ermittelt ob das Flag "FIRST_CONFIG" "WAHR" ist. Ist es nicht "WAHR", geht die Steuerung zum Schritt 754.
Wenn der Schritt 750 feststellt, daß das Flag "FIRST_CONFIG" "WAHR" ist, geht die Steuerung zum Schritt 752, in welchem der lokale Prozessor 122 RIS-Sektoren für sämtliche Laufwerke in der Plattengruppe auf Null setzt, wobei das Schreiben der RIS-Struktur in den im Schritt 744 reservierten Zylinder ansteht. Die Steuerung geht zum Schritt 754, in welchem der lokale Prozessor die Konfigurationssektoren auf die RIS-Sektoren der Platte einstellt. Die Steuerung geht zum Schritt 756, wo der lokale Prozessor 122 ein Flag "EINSTELLEN DER KONFIGURATION FERTIG" auf "WAHR" setzt. Die Steuerung geht dann zum Schritt 768.
Wenn im Schritt 718 festgestellt wird, daß die Konfiguration nicht zulässig ist, geht die Steuerung zum Schritt 758. Wenn der Zählerstand des baulichen Laufwerks den Wert Null hat, geht die Steuerung zum Schritt 764, in welchem der lokale Prozessor 122 das "SET_CONFIGURATION-FERTIG" Flag auf "FALSCH" setzt. Die Steuerung geht zum Schritt 768. Wenn im Schritt 758 festgestellt wird, daß der Zählwert für das bauliche Laufwerk nicht gleich Null ist, geht die Steuerung zum Schritt 760, der die Laufwerke auf unbenutzt und gesperrt einstellt. Die Steuerung geht zum Schritt 762, der das Flag für die Beendigung der Konfigurationseinstellung auf "WAHR" setzt. Die Steuerung geht zum Schritt 768. Wenn das "SET_CONFIGURATION- FERTIG" Flag "WAHR" ist, geht die Steuerung zum Schritt 770, in welchem der lokale Prozessor 122 die gesamte Konfiguration in den RIS-Sektoren auf sämtlichen Platten sichert. Die Steuerung geht zum Schritt 772, der die Steuerung dieses lokalen Prozessors zurück zu dem Betriebssystem gibt. Wenn festgestellt wird, daß das "SET_CONFIGURATION-FERTIG"-Flag nicht "WAHR" ist, geht die Steuerung zum Schritt 774, in welchem der lokale Prozessor einen Fehlercode einstellt und die Steuerung des lokalen Prozessors im Schritt 776 zurückgibt.

17. Lesen Logikeinheiten-Konfiguration:

Fig. 15 ist ein Flußdiagramm der Funktion "SENSE_ KONFIGURATION_UNIT, mit der die Plattengruppensteuerung 112 den Typ der logischen Einheit für das Aufrufen der Geräte in Abhängigkeit des von dem aufrufenden Gerät ausgegebenen Befehls identifiziert. Der Betrieb der Funktion SENSE_KONFIGURATION beginnt im Schritt 800, wo sie aufgerufen wird. Die Steuerung geht zum Schritt 802, in welchem in eine Datenstruktur innerhalb des lokalen Speichers von dem lokalen Prozessor 122 die Signaturadresse, Kompatibilitäts-Bord-Adresse, Betriebssystem, Verschachtungs-Faktor, Laufwerkszählung, bauliche Laufwerkszählung, Toleranzmodus und andere baulich-logische Parameter geladen werden. Die Steuerung geht zum Schritt 804, in welchem der lokale Prozessor 122 die RIS-Datenstrukturen für sämtliche Laufwerke in den lokalen Speicher lädt, welche in der Laufwerksübersicht spezifiziert sind. Die Steuerung geht zum Schritt 806, in welchem der lokale Prozessor 122 die Datenstruktur von dem lokalen Speicher in den Transferpuffer überträgt. Die Steuerung geht zum Schritt 808, wo der lokale Prozessor 122 Laufwerksgruppeninformation in den Hauptspeicher überträgt. Die Steuerung geht zum Schritt 810, wo der lokale Prozessor ermittelt, ob es ein zweites Streu/Sammel-Zählfeld für die spezielle Konfiguration gibt. Gibt es keine zweite Streu/Sammel-Zählung, so geht die Steuerung zum Schritt 814, wo die Steuerung zu dem Betriebssystem des lokalen Prozessors 122 zurückkehrt. Gibt es eine zweite Streu/Sammel-Zählung, so geht die Steuerung zum Schritt 812, wo der lokale Prozessor 122 die zweite Streu/Sammel-Zählung von dem Transferpuffer in den Haupt- oder den Speicher des aufrufenden Geräts überträgt.

18. BMIC-Lese/Streu-Sammel-Struktur:

Fig. 27 zeigt ein Flußdiagramm der Funktion BMIC_SENSE_UNIT, die dazu dient, Parameter zu lesen, die ein spezifisches Laufwerk innerhalb der Plattengruppe betreffen. BMIC_SENSE_UNIT wird im Schritt 1350 aufgerufen. Die Steuerung geht zum Schritt 1352, wo der lokale Prozessor 122 den lokalen Speicher zuweist und die Daten des spezifizierten logischen Laufwerks in den lokalen Speicher einliest. Die Steuerung geht zum Schritt 1354, wo der lokale Prozessor 122 die Datenstruktur in den Transferpuffer überträgt. Die Steuerung geht zum Schritt 1356, wo der lokale Prozessor 122 die Einheitendaten unter Verwendung von SG_BLOCK zu dem Hauptsystem überträgt. Die Steuerung geht zum Schritt 1358, in welchem der lokale Prozessor 122 ermittelt, ob es in dem Anforderungsvorsatz ein zweites S/G-Zählfeld gibt. Gibt es keinen zweiten S/G-Zählvorsatz, so geht die Steuerung zum Schritt 1362. Gibt es einen zusätzlichen S/G-Zählvorsatz, so geht die Steuerung zum Schritt 1360, wo der lokale Prozessor 122 die Funktion SG-BLOCK aufruft, um die Daten aus dem Transferpuffer zu dem Hauptsystem zu übertragen. Die Steuerung geht zum Schritt 1362, der die Operation der Funktion BMIC_SENSE_UNIT beendet und die Steuerung zu dem Betriebssystem des lokalen Prozessor zurückgibt.

19. Identifizieren Steuerung oder Platte:

Fig. 16 ist ein Flußdiagramm der Funktion BMIC_IDENTIFIY gemäß der Erfindung. Aufgerufen wird die Funktion im Schritt 830, und die Steuerung geht weiter zum Schritt 832, in welchem der lokale Prozessor 122 ermittelt, ob der Befehl ein Befehl zum Identifizieren einer Steuerung oder eines Laufwerks war. Betrifft er die Identifizierung einer Steuerung, so geht die Steuerung über zum Schritt 834. Im Schritt 834 weist der lokale Prozessor 122 lokalen Speicher zu für eine Datenstruktur der RIS-Sektoren der Platten, und er liest die RIS-Sektorinformation in die Struktur ein. Die Steuerung geht zum Schritt 836, in welchem der lokale Prozessor 122 die Größe der zu dem aufrufenden Gerät zu sendenden Identifizierungsinformation bestimmt. Die Steuerung geht zum Schritt 838, in welchem der lokale Prozessor 122 die Steuerungsinformation in den Transferpuffer lädt. Die Steuerung geht zum Schritt 840. Wenn im Schritt 832 ermittelt wird, daß der Identifizierungsbefehl eine Identifikationsinformation für ein spezielles Laufwerk anfordert, so geht die Steuerung zum Schritt 842, in welchem der lokale Prozessor 122 lokalen Speicher für die Datenstruktur zuweist und die Plattenlaufwerkparameter einschließlich Kopf, Zylinder und Anzahl der Sektoren pro Zylinder liest. Die Steuerung geht zum Schritt 844, in welchem der lokale Prozessor 122 den Typ der Fehlertoleranz für die speziellen Laufwerke ermittelt. Die Steuerung geht zum Schritt 846, wo der lokale Prozessor 122 die Größe der zu dem aufrufenden Gerät zu sendenden Transferinformation bestimmt. Diese Transfergrößeninformation wird dann auf den Befehlsvorsatz addiert. Die Steuerung geht zum Schritt 848, in welchem der lokale Prozessor 122 die Einheiteninformation über die Platten in den Transferpuffer lädt. Die Steuerung geht zum Schritt 840, wo der lokale Prozessor 122 die Identifikationsinformation an das aufrufende Gerät sendet. Die Steuerung geht zum Schritt 850, in welchem die Operation der Funktion BMIC_IDENTIFY abgeschlossen wird, und die Steuerung geht zu dem Betriebssystem des lokalen Prozessors zurück.

20. Prüfung der Logikeinheiten-Konfiguration:

Fig. 23 ist ein Flußdiagramm der Funktion CONFIGURATION_VALID, die von anderen Tasks gemäß der Erfindung aufgerufen werden kann. CONFIGURATION_VALID wird im Schritt 1160 aufgerufen. Die Steuerung geht zum Schritt 1162, wo der lokale Prozessor 122 ermittelt, ob die Anzahl der Laufwerke in dem Konfigurationspuffer gleich ist der baulichen Anzahl von Laufwerken in der logischen Einheit. Ist die bauliche Laufwerkzahl in der Gruppe nicht gleich der Anzahl von Laufwerken in dem Konfigurationspuffer, so geht die Steuerung zum Schritt 1164, in welchem der lokale Prozessor 122 einen Rückkehr-Code auf "FALSCH" setzt und die Steuerung zum Schritt 1166 leitet, der zum aufrufenden Programm zurückkehrt. Wenn die Anzahl von Laufwerken im Konfigurationspuffer gleich ist der baulichen Laufwerkzahl in der logischen Einheit, so geht die Steuerung zum Schritt 1168, wo der lokale Prozessor 122 die Anzahl von Laufwerken über die Karte der Logikeinheit zählt. Die Steuerung geht zum Schritt 1170, wo der lokale Prozessor 122 ermittelt, ob der Zählwert, wie er über die Karte der logischen Einheit erhalten wurde, gleich ist der Plattenzahl, die in dem Konfigurationspuffer-Zählerstand spezifiziert ist.
Sind sie nicht gleich, geht die Steuerung zum Schritt 1164, in welchem der lokale Prozessor 122 einen Rückkehr-Code auf "FALSCH" setzt und im Schritt 1166 zum aufrufenden Programm zurückkehrt. Wenn der Zählerstand dem Zählerstand im Konfigurationspuffer gleicht, geht die Steuerung zu den Schritten 1172 bis 1178, die basierend auf Fehlertoleranz-Modi in der logischen Einheit einen Schalter beinhalten. Wenn im Schritt 1172 die Plattengruppe eingestellt ist für die PARITY_FAULT-PROTECTION, geht die Steuerung über zum Schritt 1180, in welchem der lokale Prozessor 122 ermittelt, ob die Laufwerke 3 und 7 für Parität eingestellt sind. Wenn die Laufwerke 3 und 7 nicht für Parität eingestellt sind, geht die Steuerung zum Schritt 1164, in welchem der lokale Prozessor 122 einen Rückkehr-Code auf "FALSCH" einstellt und im Schritt 1166 zum aufrufenden Programm zurückkehrt. Wenn die Laufwerke 3 und 7 für Parität eingestellt sind, geht die Steuerung zum Schritt 1186, in welchem der lokale Prozessor 122 einen Rückkehr-Code auf "WAHR" einstellt. Wenn der Schritt 1174 feststellt, daß die Konfiguration einen MIRROR_FAULT-Schutz verlangt, geht die Steuerung zum Schritt 1182, in welchem der lokale Prozessor 122 ermittelt, ob der Benutzerlaufwerks-Zählwert für den Spiegel eingestellt wurde, das heißt, die Laufwerke 0 bis 3 die einzigen aktiven Benutzerlaufwerke sind. Wenn die Laufwerkszählung so eingestellt ist, daß der MIRROR_FAULT-Schutz gegeben ist, geht die Steuerung zum Schritt 1186, in welchem der lokale Prozessor 122 einen Rückkehr-Code auf "WAHR" setzt. Wenn die Laufwerkszählung nicht gesetzt wurde, um den MIRROR_FAULT-Schutz darzustellen, geht die Steuerung zum Schritt 1164, in welchem der lokale Prozessor 122 einen Rückkehr- Code auf "FALSCH" setzt und im Schritt 1164 zum aufrufenden Programm zurückkehrt. Wenn der Schritt 1176 ermittelt, daß es keinen Fehlerschutz in der Plattengruppe gibt, geht die Steuerung zum Schritt 1186, in welchem der lokale Prozessor 122 einen Rückkehr-Code auf "WAHR" setzt. Wenn der Schritt 1178 feststellt, daß ein Feld frei ist oder auf einen Standardwert gestellt ist, geht die Steuerung zum Schritt 1184, in welchem der lokale Prozessor 122 einen Rückkehr-Code auf "FALSCH" setzt. Die Steuerung geht zum Schritt 1188, der zu dem aufrufenden Programm zurückkehrt. Im Schritt 1186 setzt der lokale Prozessor 122 einen Rückkehr-Code auf "WAHR", und die Steuerung geht zum Schritt 1188, der zu dem aufrufenden Programm zurückkehrt.

VI. Schlußfolgerung:

Man sieht, daß das erfindungsgemäß definierte Protokoll zu einer verbesserten Hauptprozessor-Effizienz führt. Der Hauptprozessor muß keine plattenspezifischen Befehle an die Laufwerksgruppe geben. Der Aufbau der plattenspezifischen Befehle ist auf den lokalen Prozessor innerhalb der Plattengruppensteuerung abgewälzt worden. Außerdem braucht der Systemprozessor nur Befehle auf logischer Ebene an die Plattengruppensteuerung zu geben.
Weiterhin entlastet der Einsatz der Busmaster-Schnittstellen-Steuerung den Systemprozessor von Datentransfer-Verwaltungsaufgaben, während die E/A-Operationen ausgeführt werden. Die Übertragung dieser Aufgaben auf die Plattengruppensteuerung führt zu einer gesteigerten Gesamtleistung des Rechnersystems.
Die obige Offenbarung und Beschreibung der Erfindung sind lediglich beispielhaft und anschaulich für die Erfindung, und es sind verschiedene Änderungen hinsichtlich Größe, Form, Materialien, Bauteilen, Verschaltung, Drahtanschlüssen und Kontakten ebenso möglich wie bezüglich der Einzelheiten der dargestellten Schaltung, des Aufbaus und des Arbeitsverfahrens, ohne vom Schutzumfang der Erfindung abzuweichen, wie er durch die beigefügten Ansprüche definiert wird.

Claims

1. Verfahren zum Verwalten des Transfers von Daten zwischen einem Hauptrechner, welcher ein Gehäuse, einen Hauptprozessor (CPU), einen Hauptbus (44) und einen Hauptspeicher (58) aufweist, einem Eingabe-/Ausgabe-Bus (46) und einer Plattengruppe (116), die mit dem Hauptbus (44) in Verbindung steht und eine Mehrzahl physischer Plattenlaufwerke enthält, die als ein logisches Plattenlaufwerk organisiert sind, weiterhin eine Plattengruppen-Steuerung (112) auf Mikroprozessorbasis und einen Speicher (126, 128), wobei die Plattengruppen-Steuerung (112) und der Speicher (126, 128) auf einer einzigen Schaltungsplatte angeordnet sind, die mit dem Eingabe-/Ausgabe-Bus (46) gekoppelt ist, umfassend die Schritte:

a) Der Hauptrechner generiert eine logische Plattenzugriffsanforderung, welche in dem Hauptspeicher (58) unter einer Hauptspeicheradresse gespeichert wird;

b) der Hauptrechner meldet der Plattengruppen-Steuerung (112) die Existenz und die Adresse der logischen Plattenzugriffsaufforderung;

c) die Plattengruppen-Steuerung (112) liest die logische Plattenzugriffsanforderung aus dem Hauptrechner-Speicher (58);

d) die Plattengruppen-Steuerung (112) übersetzt die logische Plattenzugriffsanforderung in mindestens einen plattenspezifischen Befehl für den Zugriff auf ein oder mehrere Plattenlaufwerke (116) innerhalb der Plattengruppe unabhängig von dem Hauptrechner;

e) die Plattengruppen-Steuerung (112) verarbeitet den plattenspezifischen Befehl;

f) die Plattengruppen-Steuerung (112) verwaltet den Transfer von Daten zwischen der Plattengruppe und dem Hauptrechner; und

g) die Plattengruppen-Steuerung (112) meldet dem Hauptrechner, wenn die logische Plattenzugriffsanforderung abgeschlossen ist.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Schritt, in welchem der Hauptrechner eine logische Plattenzugriffsanforderung generiert, außerdem den Schritt beinhaltet, bei dem der Hauptrechner eine Befehlsliste generiert, die der Plattenzugriffsanforderung entspricht, und die mindestens einen Plattenzugriffsbefehl beinhaltet.

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß der Schritt des Generierens einer Befehlsliste durch den Hauptrechner außerdem den Schritt aufweist, bei dem der Hauptrechner eine logische Plattengruppen-Adresse, eine Befehl-Ausgeführt-Information, eine Befehlsprioritäts-Information, eine Hauptspeicher-Adresse und -größe für jeden Plattenzugriffsbefehl innerhalb der Befehlsliste spezifiziert.

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß der Schritt des Übersetzens der logischen Plattenzugriffsanforderung in plattenspezifische Befehle durch die Plattengruppen-Steuerung (112) folgende Schritte beinhaltet:

a) Die Plattengruppensteuerung liest die Befehlsliste;

b) die Plattengruppensteuerung generiert mindestens einen plattenspezifischen Befehl, welcher Befehlsfunktion und Plattensuchinformation enthält.

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß der Schritt der Verarbeitung der plattenspezifischen Befehle durch die Plattengruppen-Steuerung folgende Schritte beinhaltet:

a) Der Plattengruppen-Prozessor stellt die plattenspezifischen Befehle anhand der in der Befehlsliste spezifizierten Befehlsprioritäts-Information in eine Warteschlange; und

b) die Plattengruppen-Steuerung transferiert die plattenspezifischen Befehle zu individuellen Plattenlaufwerken innerhalb der Plattengruppe zwecks Ausführung.

6. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Schritt, bei dem die Plattengruppen-Steuerung den Transfer von Daten zwischen der Plattengruppe und dem Hauptrechner verwaltet, außerdem folgende Schritte beinhaltet:

a) Die Plattengruppen-Steuerung übernimmt die Steuerung über den Hauptrechner-Bus;

b) die Plattengruppen-Steuerung bestimmt eine Datenbreiten-Größe für den Datentransfer;

c) die Plattengruppen-Steuerung transferiert Daten zu dem Hauptrechner-Speicher oder von dem Hauptrechner-Speicher; und

d) die Plattengruppen-Steuerung gibt die Steuerung des Hauptrechner-Busses wieder auf.

7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, daß der Schritt, bei dem die Plattengruppen-Steuerung den Transfer von Daten zu oder von dem Hauptrechner verwaltet, die Übertragung von 32 Bit breiten Daten beinhaltet.

8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß der Schritt, bei dem die Plattengruppen-Steuerung den Transfer von 32 Bit breiten Daten zu oder von dem Hauptrechner verwaltet, den Transfer von 32 Bit breiten Daten mit einer Geschwindigkeit von 33 Mbyte pro Sekunde beinhaltet.

9. Verfahren nach Anspruch 6, dadurch gekennzeichnet, daß der Schritt, bei dem die Plattengruppen-Steuerung den Transfer von Daten zu dem Hauptrechner verwaltet, den Transfer von 32 Bit breiten Daten zu einem Gerät beinhaltet, welches an den Hauptrechner gekoppelt ist und in der lage ist, Daten mit einer Breite von 8 Bit oder 16 Bit zu empfangen.

10. Verfahren nach Anspruch 6, dadurch gekennzeichnet, daß der Transfer von Daten zu oder von dem Rechnersystem den Transfer eines einzigen Speicher-Bytes zu oder von dem Rechnersystem oder einem an das Rechnersystem gekoppelten Gerät beinhaltet.

11. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Schritt, bei dem die Plattengruppen-Steuerung dem Hauptrechner meldet, wenn die logische Plattenzugriffsanforderung abgeschlossen ist, den Schritt beinhaltet, bei dem die Plattengruppen-Steuerung eine FERTIG-Information in ein Mailbox-Register des Hauptrechners einschreibt.

12. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Schritt, bei dem der Hauptrechner der Plattengruppen-Steuerung die Existenz und die Adresse der logischen Plattenzugriffsanforderung meldet, beinhaltet, daß der Hauptrechner in eine Mailbox-Register innerhalb des Speichers der Plattengruppen-Steuerung einschreibt.

13. Informationssteuerpaket zur Verwendung bei einem Rechnersystem mit einem intelligenten Massenspeicher-Plattengruppen-Subsystem, umfassend eine Mikroprozessorsteuerung, umfassend:

a) Mehrere Plattenbefehlsanforderungen, von denen jede Plattenbefehlsanforderung einen Anforderungs-Vorsatz und mehrere Descriptorpakete enthält;

b) einen Befehlslisten-Vorsatz, der Information enthält, die für sämtliche Plattenbefehlsanforderungen gemeinsam ist, einschließlich einer logischen Laufwerkbeschreibung, einer Priorität für die Befehlsliste und einer Steuerinformation, die auf jede Plattenbefehlsanforderung anwendbar ist, wobei die Steuerinformation außerdem eine zusätzliche Prioritätsinformation und eine Befehl-Ausgeführt-Information, die sich auf die gesamte Befehlsliste bezieht, enthält;

c) wobei der Anforderungs-Vorsatz beinhaltet:

ca) einen Plattenbefehl, der die Funktion des Befehls spezifiziert;

cb) einen Rückkehrcode, der die Art und Weise spezifiziert, auf die die Plattengruppen-Steuerung dem Rechnersystem bei Beendigung des spezifischen Befehls melden soll;

cc) eine Adresse, die eine Stelle in dem logischen Laufwerk spezifiziert, welche ihrerseits in dem Befehlslisten-Vorsatz spezifiziert ist;

cd) den Umfang der Daten, der zu oder von dem logischen Laufwerk, welches in dem Befehlslisten-Vorsatz spezifiziert ist, transferiert werden soll;

ce) die Speicheradresse des nächsten Anforderungs-Vorsatzes in der Befehlsliste; und

cf) die Anzahl von Descriptorpaketen innerhalb eines Satzes, der den Plattenbefehlsanforderungen zugeordnet ist.

14. Informationssteuerpaket nach Anspruch 13, bei dem der Anforderungs-Vorsatz außerdem eine zweite Zahl beinhaltet, die einen zweiten Satz von Descriptorpaketen spezifiziert, die zu der Plattenbefehlsanforderung gehören.

15. Informationssteuerpaket nach Anspruch 13 oder 14, bei dem ein Descriptorpaket beinhaltet:

a) eine Pufferadresse, die eine Stelle im Systemspeicher spezifiziert, die bei dem Plattenbefehl zu verwenden ist; und

b) eine Pufferlänge, die einen Datenumfang angibt, welcher bei der Pufferadresse beginnt.