Per ROM-Port vernetzt: Arcnet für ATARI-Rechner (Teil 1)
Da der Trend mittlerweile zum Zweit- oder Drittrechner geht, werden viele schon Probleme mit dem gleichzeitigen Zugriff auf Daten beider Rechner gehabt haben, oder sie wollen keine zweite Festplatte anschaffen. Das Problem läßt sich einfach lösen: vernetzen wir die Rechner einfach. Aber entweder gibt es nur recht langsame Möglichkeiten, z.B. über MIDI oder die Serielle, oder alles bewegt sich sofort in schwindelerregenden Preisregionen...
Man braucht also etwas, das schnell und gleichzeitig billig ist. Bei „billig“ fallen einem natürlich sofort Bauelemente aus der PC-Weit ein. Die Wahl fällt also auf eine Netzwerkkarte mit (Standard)ISA-Bus, welche in jedem besseren PC-Laden erhältlich ist. So, jetzt hat man solch eine Karte vor sich liegen, aber seltsamerweise kann man die nirgendwo in den ATARI reinstecken... Irgendwie wird also ein Interface benötigt, um dieses Ding benutzen zu können -aber wo soll man das nun wieder anschließen? Die Suche beginnt, der VME-Bus wäre ja was Feines, aber, o Graus, da steckt schon eine Grafikkarte drin, und mein alter 1040STF hat gar keinen VME-Bus! Also braucht man einen Anschluß, der an allen (original)-ATARIs vorhanden, halbwegs schnell und gleichzeitig meistens unbenutzt ist. Dafür kommt demnach eigentlich nur der ROM-Port in Frage.
Was wollen wir denn?
Wie wir bereits (evtl. in eigener Erfahrung) gemerkt haben, soll so ein Netz halbwegs schnell sein, so daß es im Idealfall keine Unterschiede im Verhalten zu einer Festplatte bietet. Es sollte sich auch ansonsten genauso verhalten, d.h. eine normale Verzeichnisstruktur mit Möglichkeit zum Kopieren, Programme starten etc. bieten. Dies wurde hier durch einen Client-Treiber für MetaDOS realisiert, der Server läuft als eigenständiger Prozeß (unter Multitasking-Systemen im Hintergrund). Beide Programme setzen auf eine hardwarenahe Schicht auf, welche diverse Grundfunktionen zum Transport von Daten zur Verfügung stellt. Diese Schicht kann von mehreren Treibern gleichzeitig benutzt werden, so daß man mehrere Dienste wie z.B. Drucker oder anderes über das Netz verteilen kann. Als Übertragungsmedium wird Arcnet verwendet, die erreichbare Geschwindigkeit (laut How-Fast) liegt zwischen 120 KB/s beim Lesen und 80KB/S Schreiben bei einem „normalen“ 8-MHz-ST (1040, Mega ST) und 190KB/S bzw. 150KB/ s bei schnelleren Rechnern (TT, Falcon). Mehr hierzu im zweiten Teil. Das benötigte Interface soll eine PC-Netzwerkkarte aufnehmen können, also muß es viele Eigenschaften eines ISA-Busses beherrschen. In diesem Fall sollten neben Netzwerk- auch andere Karten funktionieren. Dem ist auch so, solange die Karte mit I/O- und Memory-Zugriffen steuerbar ist, DMA-Zugriffe sind nicht möglich. Wenn man Interrupts braucht, muß man sich eine passende Schnittstelle dafür aussuchen, z.B. RI einer seriellen Schnittstelle oder Busy des Drucker-Portes. Man muß auch die relativ geringe Transfergeschwindigkeit beachten, die z.B. für eine Grafikkarte völlig inakzeptabel ist.
Busse...
Am ROM-Port ist eine reduzierte Anzahl Signale des 68000-Prozessors vorhanden, eigentlich nur die für eine EPROM-Karte unbedingt notwendigen. Es fehlen zum Beispiel Adreßleitungen, die durch zwei ROM-Selects ersetzt wurden. Damit ist der Adreßraum auf zwei aufeinanderfolgende 64KB-Blöcke beschränkt. Des weiteren fehlt die Read/Write-Leitung, so daß man eigentlich nicht in den ROM-Port-Bereich schreiben kann [3]. Dies ist das erste Hindernis, welches zu überwinden gilt. Der ROM-Port hat außerdem die Besonderheit, daß seine Zugriffsdauer immer gleich lang ist. Er wartet auf Daten, und wenn diese Zeit um ist, müssen die Daten an den Datenleitungen anstehen. Der „Lieferant“, seien es nun Eproms oder Netzwerkkarten, muß also innerhalb dieser Zeit (~300ns) merken, daß ein Zugriff geschieht, die Adreßleitungen auswerten, verarbeiten und das Ergebnis auf die Datenleitungen legen. Das ist, insbesondere für eine ISA-Bus(PC-)-Karte, oft zuviel verlangt. Schaut man sich so einen ISA-Bus mal etwas näher an, fallen einem mehrere Unterschiede zum ATARI-Bussystem auf: Er hat getrennte Read- und Write-Enable-Leitungen, mehrere unterschiedliche Zugriffsarten und eine Adressierungsunterteilung in Speicher- und I/O-Bereich. Die Zyklen sind teilweise variabel und haben keine feste Zeitdauer, in denen sie beendet sein müssen (async. Bus).
Hierbei bedürfen zwei Speicherzugriffsvarianten besonderer Beachtung: der Zugriff mit und ohne Waitstates. Manche Karten, vor allem die neuerer Bauart und mit 16-Bit-Bus, haben einen sog. Null-Waitstate-Mode, der meistens mit einem Jumper einstellbar ist. Ist dieser Modus aktiv, wird jeder Zugriff auf eine Speicherstelle besonders schnell, was uns später zugute kommen wird. Weiterhin gibt es noch den Standard/Ready-Mode, bei dem ein Zugriff auf die Karte im allgemeinen wesentlich länger als die Zugriffszeit des ROM-Ports dauert. Man muß sich also etwas einfallen lassen, um trotzdem an die Daten zu kommen.
Loch ins Knie...
Die Mankos des ROM-Ports kann man wie folgt überwinden: Man nimmt zum Schreiben Teile des Adreßbusses als Datenbus, was somit aber den verfügbaren Adreßbereich einschränkt (8 KB) und eine Verlangsamung der Transfer-rate mit sich bringt. Dies führt außerdem dazu, daß nur ein 8-Bit-Slot auf dem Interface Sinn macht. Die gegebenenfalls zu kurze Zyklusdauer des Ports für den Standard/Ready-Mode kann man so umgehen, indem man mit einem ersten Zugriff die Adresse und/oder die Daten anlegt. Diese werden vom Interface gespeichert und an die PC-Karte weitergegeben. Die arbeitet dann so lange vor sich hin, bis sie fertig ist und das Ergebnis wiederum im Interface speichert. Der ST kann nun mit einem zweiten Zugriff das Ergebnis auslesen. Wenn man einen schnellen Rechner hat (>16 MHz), muß dieser währenddessen öfters mal nachsehen, ob die PC-Karte nun endlich fertig ist und im negativen Fall Däumchen drehen.
Ein weiteres Problem bei schnellen Rechnern ist die Vorlaufzeit der Adresse vordem Schreib-/Lese-Kommando. Diese ist bei 680x0-Prozessoren etwa ein Taktzyklus des Prozessortaktes, also etwa 125ns bei 8 MHz (ST) und ~31 ns bei einem TT. Das ist eine kleine Inkompatibilität zum ST, welche wohl auch für das Versagen mancher ROM-Port-Hardware am TT sorgt. Die ISA-Spezifikation [2] verlangt etwa 100nS, so daß der Zugriffsbefehl für die Karte, während die Adresse stabil anliegt, auf ~100ns verzögert werden muß, damit die Adreßdekodierung keine Fehler macht.
Die Netzwerkkarte
Als Netzwerkkarte wird eine ARC-Net-Karte verwendet. Sie ist sehr einfach zu programmieren, leicht zu verkabeln und hat eine physikalische Transferrate von 2.5 MBit/s. Außerdem sind sie auf Computerflohmärkten in Massen zu finden, zu Preisen, welche meistens die 20,- DM-Grenze unterschreiten. Die Karte hat einen eigenen Microprozessor, welcher sich um die gesamte Kommunikation auf dem Kabel kümmert, sowie einen 2 KB großen Speicher für empfangene oder zu sendende Daten. Die Karten werden im allgemeinen mit Koaxkabel und BNC-Steckern verbunden, es gibt aber auch Versionen für Twisted-Pair (Westernkabel). Das Koaxkabel sollte eine Impedanz von 93 Ohm besitzen, aber kürzere Strecken (~10m) können auch mit 50- oder 75Ohm-Kabel überbrückt werden. Die Kabel müssen aber auf jeden Fall an beiden Enden mit einem 93Ohm-Terminator (Abschlußwiderstand) abgeschlossen werden, um Reflexionen und somit Übertragungsstörungen zu vermeiden. Im Arcnet können bis zu 255 Rechner gleichzeitig aktiv sein, welche durch eine per DIP-Schalter einstellbare Netzwerkadresse auf der Karte unterschieden werden. Die physikalische Übertragung funktioniert nach dem Token-Bus-System, d.h.,jede aktive Karte wird vom Token angesprochen, welches dann an die nächste weitergereicht wird. Die Karten dürfen nur senden, wenn sie gerade ein an sich gerichtetes Token bekommen haben, was Kollisionen zwischen Datenpaketen wirksam verhindert. Jetzt können sie einen Datenblock (Paket) versenden oder einfach nur das Token weiterreichen. Wenn es aus irgendwelchen Gründen verschwindet (ein anderer Rechner wird ausgeschaltet, Kabelfehler), würde das Netz eigentlich auf ewig ruhen, weil jeder Rechner auf das Token wartet, es aber nie ankommt. Deshalb hört jede Karte auf der Leitung nach Token-Aktivität und erzeugt ein neues, wenn für eine bestimmte Zeit keines mehr vorbeikommt. Kompliziert? Egal, das macht ja zum Glück der Controller auf der Arcnet-Karte für uns [1].
Das Interface
Wegen der oben benannten „Einsparungen“ am ROM-Port hat das Interface drei Zugriffsarten: Modus einstellen, Datentransfer und Zyklustest. Im Modusregister ($FB0xxx) stellt man ein, ob man von der PC-Karte lesen oder schreiben bzw. einen Speicheroder I/O-Zugriff machen will. Außerdem werden hier die Adreß-Bits A7...A12 festgelegt. Der Datentransfer erfolgt über die Adressen ab $FA-xxxx. Durch einen Lesezugriff auf Adresse $FB8001 erhält man in Bit D7 den Status der Leitung /IOCHRDY (bei Waitstate-Karten). Weil man am ROM-Port nur lesen kann, werden zu schreibende Daten-Bytes grundsätzlich in den Bits 1...8 der Zugriffsadresse übertragen. A0 bleibt „1“, A9...A15 sind beim Datentransfer der untere Teil der Zieladresse. Jeder Zugriff ist ein Byte-Zugriff. Der oberste Teil der Kartenadresse, A16...A19, wird durch den DIP-Schalter auf dem Interface fest eingestellt, A13...A15 liegen fest auf Masse („0“). Ein Zugriff auf eine Karte läuft nun beispielsweise folgendermaßen ab: Wir wollen die Speicherstelle an Adresse $14e8 auslesen. Demnach müssen wir uns schon mal $2a für das Modusregister merken (Bits 7...12 von $14e8). Da wir einen Lesezugriff machen wollen, kommt eine „0“ für Bit 6, durch den Memory-Zugriff eine „1“ für Bit 7 hinzu, das ergibt $aa für das Modusregister. Daraus folgt ein Dummy-Aufruf z.B. „move.b $fb0154,d0“. So wird mit /ROM3 ein Zyklus auf den ROM-Port ausgelöst, welche das Latch IC1 zur Datenübernahme der Adreßleitungen A1...A8 veranlaßt. Der auf diese Weise gespeicherte Teil der Adresse wird hierdurch auf A7...A12 der PC-Karte gelegt und ist bis zum nächsten Zugriff auf das Mode-Register stabil. Wird ein Memory-Zugriff verlangt, legt das entsprechend gesetzte Bit über den DIP-Schalter die entsprechenden Adreßleitungen A16...A19 am PC-Bus auf „1“, die anderen werden durch das Pulldownarray auf „0“ gezogen. Der „Rest“ der Adresse, A0...A6, ist z.B. $68 und muß in den nächsten ROM-Port-Zugriff eingebaut werden, z.B. „move.b $fad001,d0“. Dieser Zugriff löst mit /ROM4 einen weiteren Zyklus aus, Latch IC2 speichert die Adreßleitungen A9...A15 und legt sie als A0...A6 an den PC-Bus. Bis jetzt hat die PC-Karte noch nichts von einem Zugriff gemerkt. /ROM4 triggert Monoflop A von IC5, welcher nun einen Low-Impuls von ca. 100ns liefert. Die steigende Flanke am Ende dieses Impulses triggert den zweiten Monoflop, welcher nun ein ca. 100µs lowaktives Signal liefert. Dessen genaue Länge ist nicht kritisch. Diese beiden Signale werden zusammen mit /ROM4 durch GAL IC8 so verknüpft, daß das Signal /COMMAND entsteht, welches ca. 100ns nach /ROM4 beginnt und gleichzeitig mit ihm endet (O-WS). Der 1-aus-4-Decoder IC6 erzeugt aus /RD und /IO des Mode-Registers und /COMMAND die vier Kommandosignale für den Zugriff auf die PC-Karte (low-aktiv), der karteneigene Zyklus wurde jetzt gestartet. Ist es eine Null-Waitstate-Karte, legt sie nun die Daten der gewollten Speicherstelle über das für die Dauer von /ROM4 transparentgeschaltete Latch IC4 auf D0...D7 auf den Datenbus des ROM-Ports (Lesezugriff). Der Schreibzugriff funktioniert ähnlich. Die zu schreibenden Daten werden von A1...A8 des Adreßbusses in Latch IC3 gespeichert und auf den interfaceinternen „Datenbus“ gelegt. Ist allerdings eine Waitstate-Karte eingesetzt, verkompliziert sich die ganze Angelegenheit. Bis zum Ende von /ROM4 bleibt alles beim alten, außer, daß die Netzwerkkarte die Leitung /IOCHRDY mit Beginn des Zugriffs auf „0" gezogen hat. /IOCHRDY beendet irgendwann mit der steigenden Flanke den Zugriff und muß somit auch /COMMAND steuern, es bleibt also für die gesamte Dauer „0“. Der interne Datenbus ist allerdings zum ROM-Port-Zyklusende noch Undefiniert, weil die Karte mehr Zeit benötigt. Dieser allererste Zugriff war also vorerst wirkungslos. Während sich der ST nun schon wieder um andere Sachen kümmert, werkelt die PC-Karte vor sich hin und speichert irgendwann die Daten mit der steigenden Flanke von /IOCHRDY im Latch IC4. Nun kann der ST wiederum auf den ROM-Port (Daten-Port) zugreifen und sich das Ergebnis aus dem Latch abholen. Gleichzeitig wird bereits der Adreßbus wieder gespeichert und der nächste Zugriff gestartet, beim kontinuierlichen Auslesen oder Beschreiben von mehreren Speicherstellen ist also nur ein zusätzlicher vorgreifender Zugriff nötig. Der ATARI, insbesondere ein schnellerer Rechner wie der TT, muß wissen, wann die PC-Karte ihre Daten gespeichert hat, damit nicht mitten im laufenden Zyklus die Adressen durch einen erneuten Zugriff auf den Datenbereich verändert werden. Das kann durch Auslesen der Adresse $fb8001 des ROM-Ports erreicht werden. GAL IC7 liefert dann in Bit D7 das Signal /IOCHRDY zurück; der Rechner muß also solange diese Adresse pollen, bis Bit D7 wieder „1“ (Negative-Flag) ist.
Außerdem...
Die benötigten -5 Volt für die Netzwerkkarte werden aus einem Takt, in diesem Fall aus der Adreßleitung A15 und einer einfachen Kaskade (CI, 2;D1,2), erzeugt. Die so entstehenden ca. -4,2 Volt sind für diesen Verwendungszweck völlig ausreichend. Die LED leuchtet während der /COMMAND-Phase und zeigt somit einen laufenden Zugriff an. Ein Problem sind die UDS/LDS-Signale. Diese sollten eigentlich bei einem byteweisen Zugriff die Hälfte des Datenbusses selektieren, die benötigt wird. Nun haben allerdings mehrere Geräte, z.B. Mega STE und viele 16MHz-Beschleuniger, einen Prozessor-Cache. Diese haben in der Testphase teilweise ein seltsames Verhalten gezeigt. Es wurden z.B. beim Mega STE mit eingeschaltetem Cache immer 16-Bit-Zugriffe initiiert, auch wenn man eigentlich nureinen 8 BitTransfer machte. Diese Leitungen werden also sicherheitshalber für die Datenübertragung per Adreßbus ohne Funktion gelassen und nur für ihre eigentliche Aufgabe, die Selektion der Datenbushälfte, benutzt.
Im nächsten Teil werden wir uns mit der Einbindung der Netzwerkkarte in das TOS befassen.
[1] SMC’s ARCnet-Controller unter der Lupe, c’t 6/1991, S. 158
[2] Edward Solarif AT BUS Design IEEE P999, Annabooks San-Diego AT-Busr c’t 11+12/1991, S. 336/313
[3] ATARI-Profibuch, 10. Aufl.f Sybex-Verlag, S. 805ff.
Ein Platinen-Layout im EPS-Format (doppelseitig) können sie gegen Zusendung eines ausreichend frankierten Rückumschlags (3,- DM) und einer Leerdisk beim Autor erhalten. Außerdem kann es im öffentlichen Programmteil der Maus WI2 (0611-9419126) oder der Redaktions-Mailbox downgeloaded werden (ROMISAPL.LZH).
Bauteilliste
3 x 74LS374 IC 1,2,3
1 x 74LS373 IC 4
1 x 74LS123 IC 5
1 x 74LS139 IC 6
2 x GAL 16V8 25ns IC 7,8
2 x 1N4148
1 x LED 3mm
2 x 10µF Elko C1,C3
1 x 4.7µF Elko C2
1 x 1800Ω R2
2 x 2.7kΩ R4,Rp
1 x 15kΩ Rw
1 x 3.3kΩ R1
1 x SIL 4+1 10kΩ
1 x 100nF Cw
1 x 22pF Cp
1 x DIP-Schalter vierfach
1 x Platinenstecker 2*31Pol (PC-Slot 8-Bit)
;Listing 1: GAL ISACV (IC 7)
;ISA-Adapter v1.7 (27.3.95)
;(c)1996 MAXON Computer
;**Autor:** Thorsten Pohlmann
*Identification
ISACV1.7 *Type
GAL16V8; *Pins
/ROM3 = 7,
/IOCHRDY = 4,
/WS = 6,
A15 = 2,
/LDS = 9,
/ROM4 = 8,
/RD = 5,
/DATAWOE.T = 19,
/MODECP.T = 14,
/ADRCP.T = 12,
D7.T = 18,
-5V.T = 15,
/STDATOE.T = 17,
STDATEN.T = 16,
/ADROE.T = 13;
*BOOLEAN-EQUATIONS
D7.E = LDS & ROM3 & A15 ;
D7 = /IOCHRDY;
/DATAWOE.E = VCC;
/MODECP.E = VCC;
/ADRCP.E = VCC;
-5V.E = VCC;
/STDATOE.E = VCC;
STDATEN.E = VCC;
/ADROE.E = VCC;
-5V = A15;
MODECP = /ROM3 + A15;
/DATAWOE = RD + /ROM4 & (/IOCHRDY + /WS);
ADRCP = /ROM4 ;
/STDATOE = /LDS + /ROM4 ;
STDATEN = /( /WS & /ROM4 + ROM4 & WS + (/IOCHRDY & WS) );
/ADROE = /ROM4 & (/IOCHRDY + /WS);
*End
;Listing 2: GAL ISASLT (IC 8)
;ISA-Adapter PC-Slot v1.6
;(C)1996 MAXON Computer
;**Autor:** Thorsten Pohlmann
*Identification
ISACS1.6
*Type
GAL16V8;
*Pins
/ROM4V = 3,
/WS = 7,
/ROM4 = 4,
/PULSE = 2,
IOCHRDYx = 8,
/COMMAND.t = 17,
/IOCHRDY.t = 13,
ROM4x.t = 18;
*BOOLEAN-EQUATIONS
ROM4x = ROM4;
/COMMAND = (PULSE + /ROM4V + /ROM4) & /IOCHRDY;
/IOCHRDY = IOCHRDYx;
*End
Thorsten Pohlmann