DRVNEW.PRG / DRVDIR.PRG
***********************


Das wird wohl nie eine "endgltige" Version, sondern immer quasi 
Betateststatus haben, sollte aber trotzdem funktioniern. Es ist davon 
auszugehen, da der Treiber aus einem MICODR-Paket nicht mit Treibern aus 
lteren oder neueren Paketen zusammen funktioniert. Wenn er es trotzdem 
tut, Glck gehabt.

<<<<<<<< der Text ist teilweise etwas durcheinander, aber ich habe mich 
bemht, ihn wenigstens auf den aktuellen Stand zu berarbeiten. <<<<<<<<



Dies ist ein universeller Treiber fr das Netzwerkprogramm MIDICOM (ab 
V3.91) von Harald Blees @KL. MIDICOM ist ab Version 3.9 nicht mehr auf 
MIDI beschrnkt, sondern kann beliebige andere Schnittstellen nutzen, wenn 
die notwendigen Routinen von einem Treiber zur Verfgung gestellt werden.

Dieser Treiber erfordert ein MIDICOM, das den MCTR-Cookie auswertet. 
ltere Versionen sollte man updaten lassen.

Es gibt eine Demoversion von MIDICOM, die als einzige Einschrnkung ber 
das Netz nur den Zugriff auf Laufwerk A: und C: erlaubt. Diese Demo mte 
in der Maus KL liegen, ansonsten Harald Blees fragen.


Da ich keine Zeit fr eine (noch) ausfhrlichere Anleitung habe, setze ich 
einiges Computerwissen und Intelligenz des Benutzers voraus. Sollte die 
Resonanz entsprechend sein, wird die Anleitung noch besser. Eine Bitte: 
Bevor jemand seine Umwelt (bzw mich) mit seinem Problem nervt, sollte er 
selbst versuchen, es zu lsen. Dazu gehrt, die Anleitungen zu lesen und 
verschiedene Konfigurationen (alle nicht unbedingt ntigen Programme raus) 
zu testen. Wenn man dann doch seine Umwelt um Hilfe bittet, sollte man die 
Fakten, die man gesammelt hat, mglichst genau darlegen.


DRVNEW ist optimiert, so da mglichst selten Daten bertragen werden, 
wenn das Netz keine Nutzdaten transportiert. Es kann nach dem Start des 
MIDI_COM.ACC einige Sekunden dauern, bis sich die Rechner alle "kennen".



Voraussetzungen
---------------
Treiber entsprechend dem SERSOFST-Standard (z.B. HSMODA-Paket), die auch 
die Fcntl TIOCFLUSH Nr.1 untersttzen. Ab HSMODA04-Paket der Fall. Der 
RSVF-Cookie mu angelegt sein und die Informationen zu den Treibern 
enthalten.


Installation
------------
Zuerst mu man den oder die entsprechenden Treiber des HSMODA-Paketes 
installieren, siehe dort. Dann konfiguriert man DRVNEW.PRG mit Hilfe von 
SETTER.TTP, siehe dazu SETTER.TXT. SETTER findet man u.a. im HSMODA-Paket. 
Nun wird DRVNEW.PRG in den AUTO-Ordner kopiert, so da es nach den ganzen 
Treibern ausgefhrt wird. Der originale MIDI-Treiber von MIDICOM mu aus 
dem AUTO-Ordner entfernt werden!

Dieser Treiber installiert den MCTR-Cookie entsprechend den 
Spezifikationen von MIDICOM.

Das SERIAL.CPX oder hnliche Exemplare, die die Werte der seriellen 
Schnittstellen verndern, knnten sich nachteilig bemerkbar machen. Wenn 
man diese Dinger nicht ganz rauswirft, sollte man dort die fr MIDICOM 
benutzte Schnittstelle auf die gleiche Baudrate wie in DRVNEW und auf 
8n1/NONE (8 Bit, keine Paritt, 1 Stoppbit, kein Handshake) einstellen.


Konfiguration
-------------
BAUD:
Fr die Baudrate sollte man eine passende Baudrate whlen und exakt 
eingeben. Es empfiehlt sich fr den ersten Versuch nur 19200 zu whlen. 
Die Baudrate mu natrlich auf dem Device (=Schnittstelle) verfgbar 
sein.

Einige maximale Wartezeiten werden anhand der Baudrate bestimmt. Wenn man 
eine Schnittstelle benutzt, die jede Baudrate akzeptiert, intern aber mit 
einer unvernderlichen Rate arbeitet, so sollte man hier annhernd diese 
unvernderliche Rate einstellen.

FINA:
ist der Name des zu benutzenden Devices innerhalb von U:\DEV\ (d.h. 
das U:\DEV\ ist nicht mit einzugeben) und darf maximal 13 Zeichen lang 
sein.

ININ:
Dies ist die Nummer des Rechners im Netz. Der Nutzer mu hier jedem seiner 
Netz-Rechner eine andere Nummer von 0 bis 6 geben. Dies ist erforderlich, 
da es nicht 100% zuverlssig ist, aus dem Nichts automatisch die Maschinen 
Kennungen whlen zu lassen. Die hier vergebene Nummer ist beliebig, wenn 
man von der geforderten Einmaligkeit absieht, und wird an MIDI_COM 
gemeldet. Die Aussage "beliebig" gilt ab MIDI_COM 3.96, eventuell bereits 
ab 3.94, jedoch defintiv nicht fr 3.93 und lter!

Diese alten MIDI_COM-Versionen fordern ab 0 lckenlos aufsteigende 
Rechnernummern im Netz. Mit drei Rechnern im Netz mu man beispielsweise 
0, 1 und 2 einstellen. Wenn man Rechner 1 mal aus dem Ring nimmt, mu man 
Rechner 2 umkonfigurieren auf 1. Dies ist natrlich unbequem, aber es gibt 
ja neuere MIDI_COM-Versionen, die diesen Aufwand nicht erfordern, fr die 
dieser Treiber gemacht ist.

MAXR:
Die maximale Rechneranzahl bestimmt die Gre des Empfangspuffers und 
einige Wartezeiten auf Nachrichten, deren Umlaufzeit von der Rechneranzahl 
abhngt. Es gibt keine Probleme, wenn hier mehr Rechner (bis zu 7) 
angegeben werden, als das Netz hat. Man sollte aber hchstens einen 
Rechner weniger angeben als vorhanden, mindestens aber 2.

DRVNEW vergrert den Sendepuffer auf 9200 Byte, wenn er nicht schon 
mindestens 9200 Byte umfat. Es wird eine Meldung ausgegeben. Generell 
reichen die 9200 Byte, und eine Vergrerung auf 
maximale_Rechneranzahl*4600 bringt nur eine extrem geringe Verbesserung, 
falls berhaupt.

Der Empfangspuffer wird von DRVNEW auf maximale_Rechneranzahl*4600 
vergrert, falls er nicht schon mindestens so gro ist. Wer jedes Byte 
Speicherplatz sparen will, sollte die Puffer in dem fr DRVNEW/MIDICOM 
benutzten seriellen Treiber so gro einstellen, wie sie DRVNEW machen 
wrde.


Momentane Hardwareempfehlung
----------------------------
Gut eignen sich die MODEM2- oder SERIAL2- Schnittstellen von MegaSTE, TT 
und Falcon. Der LAN-Port wird in Zukunft auch benutzt werden knnen. Auf 
dem ST ist fr ein gutes Arbeiten der Einsatz meiner Schnittstellenkarte 
ST_ESCC empfehlenswert (Informationen bei mir).

Man kann beliebige RS232-Schnittstellen untereinander koppeln. Es ist also 
mglich, auf einem TT MODEM2 und auf einem MegaSTE SERIAL2 zu benutzen.


Arbeitsweise
------------
DRVNEW arbeitet ohne Handshake, mit hinreichend groen Puffern. Es werden 
an jedem Rechner also nur ein Empfangsdateneingang (RXD) und ein 
Sendedatenausgang (TXD) bentigt.

DRVNEW ruft die GEMDOS-Funktionen des (seriellen) Schnittstellentreibers 
auf, ohne da garantiert ist, da zur Zeit ein bestimmter Proze luft. 
Wenn der GEMDOS-Teil des DRVIN benutzt wird (unter TOS und Mag!X/Magic2), 
so ist das problemlos, da die Handles global sind. Auch unter Magic3 
(GEMDOS von Magic3 verwaltet die Aufrufe) scheint es keine Probleme zu 
geben. Das mgliche Problem liegt darin begrndet, da die Schnittstelle 
beim Starten geffnet wird und spter das erhaltene Handle benutzt wird, 
obwohl (aus Sicht des GEMDOS) gerade ein anderer Proze luft. Allerdings 
ist auch Magic3 nicht so restriktiv, die Handles anderer Prozesse 
abzuweisen, so da man auch fr Magic3 sagen kann, ein Handle gilt global 
(-> es funktioniert).

Zur Lsung solcher Probleme wurde in der RSVF-Definition ein extra Bit 
eingefgt, das angibt, ob ein Zeiger existiert, mit dem man auf den 
(seriellen) Schnittstellentreiber direkt (ohne GEMDOS) zugreifen kann. 
Siehe DRVDIR.


DRVDIR
------
DRVDIR ist ein Ersatz fr DRVNEW. Es ist im Netz zu DRVNEW kompatibel. 
Bis auf die im Folgenden erklrten Ausnahmen gelten alle fr DRVNEW 
gemachten Aussagen auch fr DRVDIR.

DRVDIR bentigt einen SERSOFST-konformen Treiber (U:\DEV\...), der in 
seinem RSVF-Objekt Byte4.Bit0 gesetzt hat und damit anzeigt, da er den 
Direktzugriff auf eine Routinentabelle erlaubt. DRVDIR nutzt fr alle 
Aufrufe nach der Initialisierung diese Hintertr, umgeht so mgliche 
Handle-Probleme und ist eine Winzigkeit schneller als DRVNEW.

RSVF-Byte4.Bit0 ist bei den Treibern des HSMODA-Paketes ab HSMODA05 (schon 
in den Betaversionen ab Dezember 1994) gesetzt. Ist dieses Bit nicht 
gesetzt, so meldet DRVDIR nur "*** Direct way impossible" und installiert 
sich nicht. Erst HSMODA06 enthlt ein passendes MIDI.PRG.

DRVDIR sendet nicht fr den eigenen Rechner bestimmte Pakete 
sofort nach Empfang des Headers parallel zum Empfang des restlichen 
Paketes wieder in den Ring. Deshalb sollten Ringe mit mehr als 2 Rechnern 
nun (fast) genauso schnell sein wie Ringe mit nur 2 Rechnern. Diese gute 
Eigenschaft wurde bisher nur auf einem 3er-Netz mit 2 STs mit ST_ESCC und 
einem Performa475 mit MagiCMac und in einem 5er-Netz mit 3 TTs, einem ST 
mit ST_ESCC und einem Mac getestet und funktionierte dort wunderbar. 
Klartext: 2 Rechner im Netz: 9 KByte/s, 5 Rechner: 8.5 KByte/s 
(Schnittstellen auf 115200 bps) dabei wurde die grte Entfernung fr das 
Dateilesen gewhlt, d.h. beim Ring 1->2->3->4->5->und_einmal_rum liest 5 
von 1, so da die groen Pakete ber 2, 3, 4 laufen mssen.


Fehlermeldungen
---------------
Die Fehlermeldungen sind englisch und beginnen alle mit "***" und enden 
mit "bing bing". Im Wesentlichen kann DRVNEW den RSVF-Cookie oder den 
Schnittstelleneintrag im RSVF vermissen oder der Cookie Jar voll _und_ zu 
gro sein (wer hat 8KByte Cookie Jar?). Tritt ein Fehler auf, wird DRVNEW 
nicht installiert.


Verdrahtung fr RS232-Schnittstellen
------------------------------------
Sollen nur zwei Rechner gekoppelt werden, gengt ein einfaches 
Nullmodemkabel. Da ohne Handshake gearbeitet wird, ist sogar eine 
Dreidrahtverbindung (GND an GND, RXD an TXD, TXD an RXD) ausreichend. Die 
Kabel sollten geschirmt sein. Ich selbst habe ein 13 Meter langes 
geschirmtes Kabel mit 115200Bd und RS232-Schnittstelle getestet. Es lief 
fehlerfrei, wenn ich das Kabel nicht gerade um die 230V-Stromnetzleitungen 
gewickelt hatte.

Zur Kopplung mehrerer Rechner werden alle GND verbunden, und jeweils 
ringfrmig TXD des einen an RXD des nchsten Rechners gekoppelt. 
Sinnvollerweise benutzt man fr den Ring selbst das (natrlich 
abgeschirmte) MIDI-Kabel und hat an jedem Rechner einen kleinen Verteiler 
aus einer SUB-D-Buchse (zum Rechner hin) und zwei 5poligen 
DIN-Diodenbuchsen. Bei den Diodenbuchsen ist Pin2 GND und Pin5 wird an RXD 
bzw TXD angeschlossen. Pin4 und die dazugehrige Leitung bleibt (erstmal) 
ungenutzt.

Wenn man eine andere Hardware benutzt (z.B. mein Mulpri, fr das aktuell 
aber noch kein Treiber existiert), sieht die Verdrahtung natrlich anders 
aus.

Die LAN-Schnittstelle bleibt momentan den Leuten vorbehalten, die wissen, 
was sie tun. Ich werde dazu keine Fragen beantworten, es sei denn, jemand 
berredet mich dazu mit 50DM pro Stunde, die ich an der Antwort sitze. In 
der nchsten Version wird wahrscheinlich etwas mehr zu diesem Thema zu 
lesen sein. Hier nur soviel: Nur Falcons ber LAN koppeln ist trivial: 
alle GND zusammen, ringfrmige Verdrahtung RXD an TXD und natrlich /RXD 
an /TXD. Als Schnittstelle "SERIAL2" auswhlen. TTs und MegaSTEs koppelt 
man genauso, braucht aber HSMODA-Treiber _neuer_ als das HSMODA04-Paket, 
da erst die neueren auf "LAN" schalten knnen. Wenn man nur zwei Computer 
ber LAN koppeln will, kann man "seinen" Apple-Hndler aufsuchen und ein 
Apple-Drucker-Kabel kaufen und benutzen.

Achtung! RS232 ist _nicht_ fr extrem lange Leitungen vorgesehen. 
RS422/423 (LAN-Port) ist fr lngere Leitungen als RS232 vorgesehen, 
ABER!: Bei der Kopplung ber MIDI waren beide Rechner _nicht_ elektrisch 
verbunden (sofern man wirklich "MIDI"-Kabel und nicht berspielkabel mit 
beidseitig am Steckerschirm angeschlossenem Kabelschirm verwendete), falls 
sie nicht auer der MIDI-Kabel weitere Verbindungen hatten. Bei 
RS232/422/423 sind die Gerte durch das Schnittstellenkabel elektrisch 
verbunden. Das kann bei weit auseinanderliegenden Rechnern (z.B. in 
verschiedenen Husern), die an verschiedenen Stromkreisen hngen, zu 
massivstem rger fhren (Schnittstelle qualmt, Nutzer bekommt eine 
gewischt). Ich werde mir wohl diesbezglich noch was einfallen lassen, 
natrlich hardwaremig, das die Rechner galvanisch trennt und fr 
Leitungen bis 100m oder mehr brauchbar ist.

Man kann die Rechner auch ber Standleitung und Modem koppeln, falls die 
Modems beim Einschalten automatisch die Verbindung herstellen oder ein 
Programm vor diesem Treiber dafr sorgt.


Sinnvolle Baudraten
-------------------
Man darf nur Baudraten einstellen, die der serielle Treiber auch kennt. 
Man sollte keine zu hohen Baudraten whlen, da dann nur bertragungsfehler 
auftreten, was im schlimmsten Fall zum Zusammenbruch des Netzes fhrt.

Im Treiber sind einige Zeitkonstanten fr die Fehlererkennung vorhanden, 
die auf Baudraten von 19200 und aufwrts ausgelegt sind. Mit weniger als 
19200 wird DRVNEW also nicht vernnftig funktionieren.

Einige Erfahrungswerte:

ST_ESCC-Karte in 8MHz-ST (1040ST, MegaST z.B), Device MODEM2 oder SERIAL2: 
115200Bd (Info bei mir)

MODEM1 auf 8MHz-ST: 9600Bd oder 19200Bd, mit Mag!X ab Version 2.0 und NVDI 
>2.5 auch 38400Bd (nur mit meiner Zusatzhardware RSVE, Info bei mir, oder 
auch mit RS-Speed von Stephan Skrodzki)

MODEM1 zwischen TTs: 19200Bd, mit RSVE auch 38400Bd, eventuell 57600Bd, 
mit Mag!X ab 2.0 und NVDI 2.5 (ab 28.10.1993) auch 115200Bd

SERIAL1 des TT: 19200Bd, mit RSVE (eingebaut fr SERIAL1 !!) wie MODEM1 
mit RSVE

MODEM2 oder SERIAL2 auf MegaSTE: 57600Bd, eventuell 76800Bd bzw. 115200Bd, 
manche MegaSTE haben wohl einen Hardwarefehler, der durch Austauschen 
eines GALs zu beheben ist. Dieser Fehler kann Files zermatschen und auch 
eine ganze Plattenpartition killen.

MODEM2 oder SERIAL2 auf TT: 115200Bd bzw. 153600Bd

Falcon: Dieser Rechner ist nach meinen Erfahrungen leider sehr lahm. Mehr 
als 38400 oder im Hchstfall 57600 habe ich bisher nicht verwenden knnen.

Hardwareempfehlung fr MegaSTE, Falcon und TT: Austausch des 85C30 gegen 
einen Z85230 oder Am85C230A. Der hat mehr FIFO und verringert die 
Systembelastung durch Netzwerkinterrupts wesentlich. ST_ESCC ist auch mit 
diesem Schaltkreis ausgestattet.


Geschwindigkeit
---------------
Ich kann erstmal nur von meinen Erfahrungen berichten: Mein Netz besteht 
aus zwei normalen STs (68000 Prozessor mit 8MHz) mit ST_ESCC-Karten, 
gekoppelt ber SERIAL2 mit 115200Bd. Der eine ST hat eine 
AT-Bus-Festplatte (CP2044), der andere eine SCSI-Platte (GoDrive 80). 
Laden eines Files vom anderen Netzrechner oder Starten eines Programms 
bers Netz bringt eine Datentransferrate von real etwa 6.8KByte/Sekunde. 
Schreiben eines Files auf einen anderen Netzrechner wegen der dort 
stattfindenden ganzen Einzelzugriffe etwa 4.3KByte/Sekunde.


Zuknftiges & Gelaber
---------------------
Es hngt alles von der Resonanz der Nutzer ab - und die war bisher 
wirklich mager (ich meine nicht Geld, sondern generell Rckmeldungen!). 
Ich habe keinerlei kommerzielle Verbindungen zum Programm MIDICOM. Wenn 
jemand diesen Treiber "Geld wert" findet, sind kleine Anerkennungen immer 
willkommen. Auftragsanfertigungen von Treibern sind mglich, aber teuer.

DRVNEW ist ein noch hardwareunabhngiger Treiber. Deshalb sind die 
mglichen Transferraten zustzlich nochmal durch die Geschwindigkeit des 
Computers beschrnkt.

DRVNEW und DRVDIR funktionieren auch auf meinem SERSOFST-konformen 
seriellen Treiber fr den Atari-"Emulator" MagiCMac auf 
Apple-Macintosh-Computern. Einen Performa475 habe ich bei 115200Bd mit 
zwei STs zusammen in einem Netz betrieben.

Ob ich noch zu einer Implementation auf DOS oder Unix oder sonstwas komme, 
wei ich nicht. Ob ich einen Router schreibe, der die Nutzung mehrerer 
Schnittstellen ermglicht und damit die Ringstruktur aufhebt, wei 
nicht....

Mit einem speziellen Handshake kann man die Geschwindigkeitsbeschrnkungen 
des DRVNEW umgehen, so da auch 115200Bd zwischen STs ber MODEM1 und RSVE 
mglich sind. Die Gesamtleistung ist wegen des fehlenden FIFOs aber nicht 
so gut wie mit der ST_ESCC-Karte, dafr ist RSVE deutlich billiger. Man 
mu auch nicht RSVE benutzen, sondern knnte MODEM1 auch noch anders 
umbauen (Mitbertragung des Taktes), aber RSVE gibt es schon, RSVE ist 
sauber einzubauen, usw usf.

Wenn man den Spezialhandshake auf MODEM2 oder SERIAL2 bzw. dem LAN-Port 
anwenden wrde, wren dort ebenfalls noch hhere Baudraten mglich. Ob 
das auch hhere Datentransferraten ergibt, mte noch erprobt werden. Denn 
irgendwo setzt MIDICOM mit seinem stndigen Fopen/.../Fclose momentan eine 
Grenze.

Meine Parallelportkarte Mulpri hat vier Druckerports. Wenn man zwei davon 
fr ein Netz spendiert, sollten ebenfalls nicht geringe Datenraten mglich 
sein. Ich bin leider noch nicht zum Schreiben der Soft gekommen, lohnt 
sich momentan wegen der geringen Verbreitung von Mulpri auch kaum.

Den ACSI- oder SCSI-Port knnte man auch nutzen, aber nur mit noch nicht 
existierender Zusatzhardware. Also: vieles ist mglich, nicht alles 
sinnvoll, was wird oder wird berhaupt etwas gewnscht?

Achso: Wenn ich aus irgend einem Grunde keine Lust mehr habe, dann ist 
natrlich Schlu! Der Treiberquelltext wird dann freigegeben.


Anfragen
--------
Anfragen bitte per Email oder per Post mit frankiertem Rckumschlag. Wer 
irgendein Programm von mir haben mchte, bitte eine 3.5" DD-Diskette (HD 
und ED sind auch kein Problem) beilegen, ein 5DM-Schein (10DM wenn ich 
auch noch den Rckumschlag+Porto spendieren soll) tut es auch.


Copyright
---------
Ich gestatte die bersetzung dieser Dokumentation in andere Sprachen. Der 
bersetzer hat seine Ttigkeit entsprechend zu vermerken. Das deutsche 
Original mu weiterhin beigelegt sein. Die im Folgenden genannten 
Bedingungen gelten auch fr die bersetzung.

Dieses Paket darf, aber immer nur zusammen mit diesem Text, zu nicht 
kommerziellen Zwecken frei kopiert werden. Die Verbreitung auf 
PD-Disketten zu blichen Preisen ist zulssig. Jede Verbreitung zusammen 
mit kommerziellen Programmen oder sonstige kommerzielle Verwertung, 
ausgeschlossen jedoch die Anwendung (Programm starten), ist nur mit meiner 
ausdrcklichen Genehmigung gestattet. Die Verbreitung zusammen mit MIDICOM 
(egal ob Demo oder Vollversion) ist ausdrcklich erlaubt.

Ohne meine besondere _kostenpflichtige_ Erlaubnis ist es verboten, in 
dieses Archiv Werbung einzufgen. Dazu zhlen auch und besonders diese 
dmlichen aufgeblasenen "downloaded from"-Texte einiger Mailboxen.

Ich habe dieses Programm und den Text sorgfltig berprft. Aber ich hafte 
in keiner Weise fr:
- Fehler und/oder (daraus resultierende) Beschdigungen irgendwelcher 
Objekte, Subjekte oder Werte.
- irgendwelche Auswirkungen des Einsatzes oder Nichteinsatzes dieses 
Programmes und dieser Dokumentation
- Sonstiges

Fehlermeldungen oder Verbesserungsvorschlge nehme ich gern an. Ich hasse 
allerdings unangemeldetes Auftauchen mir nicht persnlich bekannter 
Personen sowie Telefonanrufe auerhalb 10:00 bis 21:00 Ortszeit. Es gibt 
schlielich Email und die "normale" Post.

Meine Adressen:
Mausnetz: Harun Scheutzow @H
Post:
Harun Scheutzow
Dresdener Strae 83
D-10179 Berlin, Deutschland


Versionen
---------
Ich vergebe keine Versionsnummern, sondern berlasse die Unterscheidung 
dem in der Installationsmeldung ausgegebenen Datum. Ich notiere das Datum 
als Jahr-Monat-Tag, ist eindeutig unterscheidbar von der deutschen 
Schreibweise Tag.Monat.Jahr, da die Jahreszahl vierstellig ist.

Neue Versionen sind zuerst in der Maus Berlin3, Telefonnummer 030-6249514, 
zu finden und verbreiten sich schnell ber die Muse. Man sollte nach dem 
Filenamen "MICODR*.*" suchen lassen. Das Archiv heit MICODRxx.LZH, 
wobei xx fr die fortlaufende Verffentlichungsnummer steht.

1994-09-20  Erstverffentlichung
1994-10-22  vollstndig Assembler, vergrert Puffer bei Bedarf selbst, 
kann greren Cookie Jar anlegen, einige Fehler raus
1994-11-27  an CRC gebastelt, automatische interne Nummernbestimmung aus 
vom Nutzer einmalig vergebenen Nummern
1995-01-07  winziger Fehler raus (der nur bei mehr als 2 Rechnern sehr 
selten bremsen konnte), DRVDIR ist neu
1995-02-17  Erkennung von Netzunterbrechungen wieder korrekt
1995-02-18  NEUE VERSION AUF DEM WEG ZUM BUSSYSTEM
1995-03-25  Schnittstellenparameter werden auch nach einigen Sync-Pakten 
beim Versuch des Verbindungsaufbaus neu gesetzt
1995-05-10  "Rechnersimulation" (die DUMMY-Eintrge) raus: ist sptestens 
ab MIDI_COM 3.96 (evtl schon 3.94) unntig und wegen Paketnderung in 3.96 
sogar strend (Rechnerzeit verstellt)

Berlin, 1994-09-20 und spter
Harun Scheutzow
