Per ROM-Port vernetzt: Arcnet für ATARI-Rechner (Teil 2)

Im zweiten Teil soll es nun um die weiche Seite des Netzwerks, also um die Client- und Server-Programme, die benötigten Systemvoraussetzungen, die Bedienung des Ganzen sowie die Programmierschnittstelle gehen.

Erst einmal ein kleiner Grundkurs im Netzwerken: Es gibt im allgemeinen mehrere Rechner in einem Netz, die auf verschiedene Art voneinander abhängig sein können. Davon existieren zwei sehr häufig anzutreffende Varianten, das Netz mit dediziertem Server und Peer-to-Peer Netze. Bei einem Netz mit dediziertem Server gibt es einen oder mehrere Server, über die die gesamte Kommunikation der Rechner abläuft. Alle Files, alle Druckaufträge usw. gelangen ohne Umweg direkt auf den Hauptrechner beziehungsweise direkt von dort zum Empfänger. Die Clients, also die Benutzer, können sich nicht direkt untereinander verständigen, jede Information (z.B. eine Datei) muß zuerst auf den Server und dann gegebenenfalls zu einem zweiten Client transportiert werden. Der Server selbst hat aber keine Möglichkeit, von sich aus auf die Festplatten eines Clients zuzugreifen. Dieses Verfahren hat unter anderem den Vorteil, daß der Server z.B. zu jeder Zeit genau weiß, wer welche Dateien schreibt/liest. Das ist z.B. bei großen Datenbanken mit vielen Zugriffen nötig, damit nicht zwei Personen gleichzeitig denselben Datensatz verändern können. Der Nachteil ist, daß der Server je nach Anzahl der Clients sehr schnell und groß sein muß, um die anfallenden Anforderungen nach Speicherplatz und Geschwindigkeit der Abarbeitung erfüllen zu können. Deshalb ist an diesem Rechner ein normales Arbeiten meistens nicht mehr möglich, der Server ist also im Prinzip ein totes Gerät. So etwas ist für den Heimgebrauch in der Regel Verschwendung, zumal man für die Vernetzung eines Zweitrechners nicht noch einen dritten anschaffen will. Die Version mit einem „richtigen“ Server ist also eher etwas für ein Netz mit vielen Benutzern oder hohen Ansprüchen. Eine Lösung für kleine Heimnetze bietet das sogenannte Peer-to-Peer-Netz-werk. Dort kann jeder gleichzeitig Client und/oder Server sein, und trotzdem kann an den Rechnern noch gearbeitet werden. Das klingt im ersten Augenblick nach der Lösung aller Probleme, allerdings hat diese Version mindestens genauso viele Nachteile. Wenn an einem Server-Rechner gearbeitet wird, merkt das sowohl der Arbeitende als auch der Client, denn es wird nämlich alles ein gutes Stück langsamer. Außerdem ist meistens der Rechner, dessen Daten man am dringendsten braucht, gerade abgeschaltet oder überlastet. Die hier vorgestellte Software benutzt trotzdem diesen Lösungsansatz, da er sowohl leistungs- als auch mengenmäßig die geringsten Ansprüche an die verwendete Rechner-Hardware stellt.

Stapelei

Die Software besteht aus vier Teilen, von denen ein Programm für jegliche Konfiguration, egal ob Client, Server oder beides benötigt wird. Es handelt sich dabei um das LAYER1_X.PRG. Dieses residente Programm bildet die unterste Schicht der Netzwerk-Software. Sie ist für die grundlegende Kommunikation der Programme über das Netz verantwortlich. Sie stellt über einen Cookie („TNET“) Funktionen bereit, mit denen man Daten an andere Rechner verschicken kann. Es kommt dabei ein Protokoll zur Verwendung, welches für Fehlerfreiheit und diverse Bestätigungen und die Anmeldung neuer Rechner im Netz sorgt. Die Cookie-Schnittstelle ist dokumentiert, so daß man sehr einfach weitere Dienste, wie z.B. Netzwerkdrucker oder Spiele, selbst programmieren kann. Auf sie setzt auch die Client- und Serversoftware auf, die somit die nächste Schicht in unserem Software-Stapel bildet. Ganz obenauf kommt dann beim Client noch die Einbindung ins Betriebssystem durch Meta-DOS, welche das Netzwerk als gewöhnliches Laufwerk erscheinen läßt. Der Server braucht so etwas nicht. Ergreift einfach wie jedes andere Programm auf die lokalen Geräte zu. In der Tat verhält sich der Server wie ein „gewöhnliches“ Programm, außer daß er keine Bedienung benötigt. Soll der Rechner gleichzeitig Server und Client sein, d.h., er bietet seine Laufwerke anderen im Netz an und benutzt selbst Netzwerklaufwerke, wird noch ein weiteres Programm benötigt. Dieses (LAYER2.PRG) ist ebenfalls resident im Speicher und sorgt dafür, daß sich die Client- und Serversoftware nicht gegenseitig ins Gehege kommen.

Hü oder Hott?

Zuerst einmal sollte man sich vor der Installation Gedanken darüber machen, wer welche Funktionen übernimmt. Bei den meisten wird es wohl so sein, daß sie einen neuen, schnellen Rechner mit allem Drum und Dran haben sowie einen alten abgelegten, der nun wiederbelebt werden soll. In einem solchen Fall ist die Sache klar. Der neue Rechner wird zum Server ernannt und stellt so dem kleineren seine Festplatte, CD-ROM etc. über das Netzwerk zu Verfügung.

Installation

Zur Installation benötigt man für jeden Rechner ein Interface und eine Arcnet-Karte. Hierbei ist es egal, ob es eine 8-oder 16-Bit-ISA-Buskarte ist, beide Varianten funktionieren im Interface. Es sind Karten mit 0-WS-Jumper zu bevorzugen, weil sie im späteren Netzwerkbetrieb schnelleren RAM-Zugriff erlauben. Des weiteren gibt es Stern- und Buskarten, die sich in der Verkabelung des Netzes unterscheiden. Bei der Bus-Topologie werden alle Karten einfach mit Koaxialkabel und einem T-Stück pro Karte hintereinander angeschlossen. An jedes der beiden Enden des so entstehenden Stranges kommt ein 93Ω-Abschlußwiderstand (Terminator). Bei der Sterntopologie werden jeweils drei Arcnet-Karten mit einem kürzeren Stück Kabel an einen sogenannten passiven Hub angeschlossen, ein kleines Kästchen mit 4 BNC-Steckern. Mit der vierten Kupplung werden dann die Hubs miteinander verbunden, wobei eventuell freibleibende Anschlüsse terminiert werden müssen. Für welche Topologie man sich entscheidet, ist in erster Linie von den Räumlichkeiten abhängig. Man muß nur beachten, daß man die beiden Netzarten nicht ohne weiteres mischen darf, für diesen Fall ist ein sog. aktiver Hub nötig. Ist das geklärt, sollte man, um die Geschwindigkeit zu optimieren, darauf achten, daß der schnellste Rechner die langsamste Karte bekommt. Das ist auf jeden Fall immer eine Waitstate-Karte. Je schneller der Rechner das Interface pollen kann, desto weniger Verzögerungen gibt es. Des weiteren wird für den Client Meta-DOS in einer Version >= 2.44 benötigt. Dies ist PD der Firma ATARI, es liegt in div. Mailboxen (z.B. Maus WI2) und ist auch auf PD-Disketten zu bekommen.

So nebenbei: Das Installieren eines Netzwerkes ist keine kinderleichte Angelegenheit, insbesondere, wenn man sich auch noch mit der Änderung diverser Konfigurations-Files, Jumper-Stellungen auf Steckkarten oder gar dem Aufbau des Interfaces beschäftigen muß. Wenn man nicht grundlegende Kenntnisse des gesamten Zusammenhanges hat, sollte man sich auf jeden Fall von einem „wissenden“ Bekannten helfen lassen. Gerade beim Aufbau und Test des Interfaces kann ein falsch bestücktes IC mindestens das Interface, eventuell auch den Rechner, mit Rauchzeichen ins Nirwana schicken.

Die Arcnet-Karte muß auf die I/O-Adresse HEX $320 und auf die RAM-Adresse HEX $C0000 eingestellt werden. Das geschieht je nach Karte mit Jumpern oder DIP-Schaltern, dazu muß auf jeden Fall das Handbuch/Datenblatt der Interface-Karte hinzugezogen werden.

Sowohl beim Server als auch beim Client muß als erstes das richtige LAYER1_X.PRG gestartet werden, z.B. im Autoordner. Hiervon gibt es zwei Versionen, eine für Waitstate-Karten (LAYER1_W.PRG) und eine für 0-WS-Karten (LAYER1_0.PRG). Das Programm macht einen kurzen Test des Karten-RAMs und Interfaces und beendet sich dann wieder, wobei es resident im Speicher verbleibt. Ist man sich nicht sicher, welche Karte man nun drin hat, kann man vorher einmal TESTSPED.TOS starten. Dieses Programm gibt einem Auskunft über den verwendeten Kartentyp sowie die Geschwindigkeit, mit der das Karten-RAM gelesen und beschrieben werden kann (4). Hier sieht man auch deutlich die Grenzen des Interfaces, z.B. fürGrafik-karten außer vielleicht für eine Text-mode-Herkules-Karte ist die Transferrate viel zu langsam.

Beim Client folgt nun das Meta-DOS, welches eine Datei „CONFIG.SYS“ erwartet. Welche Einträge darin stehen müssen, erklärt (1). Meta-DOS lädt die Clientsoftware („METANET.NOS“) nach, welche sich dann mit LAYER1 verknüpft. Im optionalen METANET.CFG (2) gibt es nur einen Eintrag,,Server „Servername“Er bewirkt, daß der Client im Augenblick des Starts nach dem Server mit dem Namen „Servername“ sucht. Damit ist die Installation des (nur-)Clients schon abgeschlossen.

Der Server(G_SERV.PRG) kann nicht in den Autoordner gelegt werden. Er muß ab TOS 1.4 als Autostartapplikation angemeldet, unter MagiC in den APPS-Ordner oder von Hand gestartet werden. Der Server benötigt auf jeden Fall ein Konfigurations-File (G_SERV. CFG) (3), in dem z.B. die zu vernetzenden Laufwerke angegeben werden.

Bei gleichzeitigem Client- und Server-Betrieb ist der Ablauf wie folgt: Zuerst LAYER1_x starten, dann LAYER2. PRG (auch im Autoordner), danach Meta-DOS und zum Schluß den Server.

Nun sollten beim Client im Netzlaufwerk die vom Server angegebenen Platten erscheinen.

Für den Heimwerker

Für Leute, die selbst Programme für Arcnet- oder andere Karten schreiben wollen, kommen nun ein paar Programmierbeispiele (5). Durch die Interface-Logik ist der Adreßbereich auf der Karte in 128 Byte-Pages aufgeteilt. Will man nun auf eine Speicher- oder I/O-Adresse zugreifen, muß man zuerst im Konfigurationsregister einstellen, ob gelesen oder geschrieben, eine I/O- oder RAM-Adresse angesprochen werden soll, sowie die Adreß-Page eintragen. Das kann man z.B. mit dem io_rd() aus (5) machen, welches auf die Zugriffsart I/O-Lesen ab Adresse $300 schaltet. Das $000c in diesem Macro setzt sich wie folgt zusammen: Wir wollen auf Adresse $300 zugreifen, das ist Segment $6 (Berechnung: HEX$300/128dez.). Da das Register allerdings erst ab D1/A1 anfängt, muß der Wert nochmals mit zwei multipliziert werden -> $C. Da Bit 7 und 8 nicht gesetzt sind, schaltet die Logik auf I/O und Lesen. Mit dem Macro read_ram(adr) kann nun der Inhalt des I/O-Adreßraumes von HEX$300 bis HEX$37F ausgelesen werden. Das Macro übersetzt den Adreßoffset schon richtig in das Interface-Format (A0->A9). Das Macro test_ws() liefert das Ergebnis <0, wenn eine Waitstate-Karte ihren Zugriff beendet hat. Dieses Macro muß man solange aufrufen, bis der Zugriff beendet ist, erst dann darf man etwas verändern. Die Funktionen Card_read/write() schreiben ganze Speicherblöcke in die Karte bzw. in den Rechner. Sie sollten bevorzugt benutzt werden, da sie viel schneller als die Einzel-Byte-Operationen durch Makros sind. Es gibt unterschiedliche Funktionen für Waitstate- und 0-WS-Karten. Das Listing (6) zeigt die Routine für Waitstate-Karten. Eine Methode für ein Programm, um herauszufinden, ob man eine WS- oder 0-WS-Karte hat, ist das Beschreiben und Auslesen der Karte mit der 0-WS-Funktion. Ist das Ausgelesene identisch mit dem Geschriebenen, hat man eine 0-WS-Karte vorliegen. Wenn nicht, probiert man das Ganze nochmal mit der WS-Funktion.

Alle Programme mit Teilen des Sourcecodes sind in der Maus WI2 (V34 28k8, Zyx 19k2, ISDN X75) oder in der Redaktionsmailbox downzuloaden. Da der Autor aus Zeitmangel nicht mehr an der Software weiterprogrammieren kann, können gewillte Personen den kompletten Sourcecode beim Autor (C, Assembler) bekommen.

Typische Werte der Transfergeschwindigkeit ins Karten-RAM: (r/50: 50 Bytes am Stück lesen, r/500: 500 Bytes am Stück)

WS-Karte am TT:	0-WS-Karte am TT:	0-WS am ST:
r/500: / ~480kB/s	r/500: / ~625kB/s	r/500: / ~133kB/s
r/50: / ~444kB/s	r/50: / ~600kB/s	r/50: / ~119kB/s
w/500: / ~406kB/s	w/500: / ~555kB/s	w/500: / ~98,5kB/s
w/50: / ~386kB/s	w/50: / ~500kB/s	w/50: / ~90kB/s

Tabelle 1

Config.sys:

; Das ist der einzige Eintrag,
; der in "config.sys" vorhanden sein muß, 
; sofern nicht noch andere 
; Metadosgeräte angemeldet sind:

*DOS , d:\turbo_c\gemnet\metanet.nos, N:0

; Der Pfad muß dementsprechend 
; angepaßt werden, das N:0 bedeutet 
; Netzlaufwerk N:. Wird hier 
; ein bereits existierendes Laufwerk 
; angegeben, ist das 'echte'
; Laufwerk nicht mehr ansprechbar!

Listing 1

[Metanet.cfg:]

Muß in das Verzeichnis, in dem Metados liegt, bzw. wenn 
im Autoordner, ins Root des Bootlaufwerks,

server "ATARI_TT"
; Sucht nach dem Server, der mit "ATARI_TT"
; betitelt ist. ("*" sucht nach allen Servern)
; Wird er nicht gefunden, erscheint im Directory 
; des Netzlaufwerks der Ordner 'OPEN.ME'. Wird er 
; geöffnet, wird eine erneute Suche gestartet.

Listing 2

G_SERV.CFG: Muß ins selbe Verzeichnis wie G_SERV.PRG

memsize 50000
; Speicher für den Server. 50kB ist ausreichend.

servname "ATARI_TT"
; Gibt dem Server einen (max 8 Zeichen langen) Namen. 
; Im Root-Directory des Clients erscheint dann 
; "ATARI_TT.C, ATARI_TT.D" usw. timer 300
; überprüft bei Netzinaktivität nur alle z.B.
; 300 ms auf Anfragen. Das entbremst den Server.
; (Ist nur bei Multitasking sinnvoll. Unter 
; Singletos weglassen oder '0')

timer 300
; überprüft bei Netzinaktivität nur alle z.B. 300 ms 
; auf Anfragen. Das entbremst den Server. (Ist
; nur bei Multitasking sinnvoll. Unter
; Singletos; weglassen oder '0')

block
; bei Server+Client-in-1 Betrieb wird während 
; dem Zugriff der Rechner gesperrt, um Gemdos- 
; Reentranzen zu vermeiden. (Bremst gewaltig
; bei Zugriffen von Aussen)

delay 20
; Bei aktiviertem 'block' wird beim abarbeiten des Befehlsqueues z.B. 
; 20ms Pause gelassen, tun dem am Server Arbeitendem etwas Luft zu 
; gönnen. Ist bei Client+Server-Betrieb kein
; 'block' gesetzt, wird jeder Zugriff auf das Netzlaufwerk mit ’-19' 
; (Alertbox'Device not ready') beantwortet. Das ist im allgemeinen besser 
; wenn man am Server arbeitet, weil man dann kaum vom Netz gebremst wird.

ignore b m
; Laufwerke (z.B. B:, M:) dem Client _nicht_ zugänglich machen. Bei 
; Client+Server-Betrieb _MUSS_ das eigene Netzlaufwerk 'ignored' werden. oder

ignore all
; Kein Laufwerk wird automatisch zugänglich 
; gemacht. Alle Einträge im virtuellen Root 
; müssen per 'adddlr' gemacht werden.

readonly c d e
; Von diesen Laufwerken kann nur gelesen 
; werden.

diskinfo f
; Manche Programme machen Ärger, wenn auf ein 
; Dfree() kein sinnvolles Ergebnis kommt. Es 
; wird dann das Dfree() von z.B. Laufwerk F 
; gesendet. Es ist zu Beachten, daß das 
; Ergebnis nicht unbedingt sinnvoll für die 
; aktuelle Anwendung ist. (Ist dieser Eintrag 
; nicht gesetzt, enthält jeder Eintrag von 
; Dfree() NULL. Manche Programme können dann 
; nicht speichern->'Disk voll')

adddir "util","c:\utility\netz"
; Fügt dem virtuellen Root des Servers z.B. den 
; Eintrag 'SERVNAME.UTI' zu. In diesem Ordner 
; befindet sich der Directory-Zweig ab 
; C:\UTILITY\NETZ\ . Es kann in diesem Zweig 
; nicht weiter nach oben gewechselt werden. Der 
; Pfad kann auch auf einem 'ignorierten' 
; Laufwerk sein, ein 'readonly' dieses Drives 
; wird beachtet. Man kann auf diese Weise max. 
; 32 Dir-Einträge hinzufügen, auch mehrere für 
; ein Laufwerk. Zur Beachtung: Die Extension 
; muss _immer_ 3 Zeichen lang sein (ggfls. mit
; '_' auffüllen), der Pfad darf nicht mit "\" 
; enden.

Listing 3

/* Listing 4 */

/* romport.h */

typedef unsigned int word;

#define Seg_reg 0xfb0000L 
#define Dat_reg 0xfa0001L 
#define ws_reg 0xfb8001L

/* Romportbedingte I/O, RAM Umschaltfunktionen */

#define io_rd() (*(volatile char *)(Seg_reg + 0x000cL)) 
/* Umschalten auf I/O-Read ab Adresse $3xx */

#define io_wr() (*(volatile char *)(Seg_reg + 0x008cL)) 
/* Umschalten auf I/O-Write ab Adresse $3xx */

#define ram_rd_u(n) (*(volatile char *) (Seg_reg + 0x0100L+ \ ((n)<<1)))
/* Umschalten auf RAM-Read auf Page n */

#define ram_wr_u(n) (*(volatile char * )(Seg_reg + 0x0180L + \ ((n)<<1)))
/* Umschalten auf RAM-Write auf Page n */

#define read_ram(adr) (*(volatile signed char *) (Dat_reg | (((word)adr & 0x007f)<<9)) )

#define write_ram(adr,wert) (*(volatile char *)(Dat_reg | \ (((word)adr & 0x007f)<<9) \ | ((wert)<<1) ) )

#define test_ws() (*(volatile signed char*)(ws_reg)) 
/* <0, Waitstatezugriff beendet, >0 Zugriff läuft */ 

/* Schnelle ArcnetRAM Read/Writeblock Funktionen */

extern word Card_read_0wsd(void *sadr, char *cadr,long page, long len); 
extern word Card_write_0ws(void *sadr, char *cadr,long page, long len); 
extern word Card_read_0ws (void *sadr, char *cadr,long page, long len);
extern word Card_write_ws(void *sadr,char *cadr,long page, long len);
extern word Card_read_ws (void *sadr,char *cadr,long page, long len);

Listing 4

/*******************************************
* Arcnetcard-Buffer mit Waitstates auslesen 
* (c) 1996 MAXON Computer
* Autor: Thorsten Pohlmann
* 0.991 Ist wohl die Endversion. 
* Jetzt auch mit /IOCHRDY-Abfrage!
*******************************************/


; a0: Zieladresse im Rechner-RAM 
; a1: Offsetadresse auf der Karte 
;               (z.B. $c0500 = $500)
; d0: Arcnetblocknummer
; (braucht man nicht unbedingt, dann 0) 
; d1: Länge des auszulesenden Blocks

Card_read_ws:

movem.l d2-d5/a2-a3,-(sp) 

subq.l  #1,d1       ; länge -1

move.l  #$fb0100,a2 ; memrd Grundadr 
lsl.w   #3,d0
adda.l  d0,a2       ; Pufferoffset

move.l  a1,d2 
lsr.w   #6,d2

; /64 (eigentlich 128, aber später *2 ) 
and.w   #$fffe,d2    ; deshalb Bit. 0 löschen

move.b  (a2,d2.w),d3 ; Das Segment

move.l  a1,d3
and.w   #127,d3     ; rest für dieses segment

asl.w   #8,d3       ; in die richtige Position 
asl.w #1,d3

move.l  #$fa0001,a1

adda.l  d3,a1
move.l  #$fafe01,d3 ; Schleifenende
move.l  #$0200,d4
; aus einem Register addieren geht schneller
move.l  #$fb8001,a3 ; Zum /IOCHRDY testen 
moveq.l #0,d5
moveq.l #0,d0

move.b (a1),d5; dummyaufruf für die 1. Adresse
cmp.l   d3,a1       ;Waitstates
bne     spuladdq.l #1,d1
; Immer nur Ausnahmen...bra next_seg

spu1:
    tst.b (a3)
    bpi spu1
    adda.l d4,a1 
spul2:
    move.b (a1),d5 
    move.b d5,(a0)+     ; Ausgelesene Speichern 
    add.w d5,d0         ; Prüfsumme

    cmp.l d3,a1
    beq next_seg
    ; Ist das segment fertig? 
    dbra d1,spul
    bra RTS

next_seg:
spult:
    tst.b ()a3)
    bpi spult
    move.l #$fa0001,a1
    addq.l #2,d2
    move.b (a2,d2.w),d5 ; Das Segment 

    dbra d1,spul2

RTS:
    movem.l (sp)+,d2-d5/a2-a3 
    rts

Listing 5

Thorsten Pohlmann

Aus: ST-Computer 05 / 1996, Seite 42

Links