rtsi.com/2014.01.www.rtsi.com.tar/www.rtsi.com/OS9/OSK/EFFO/forum13.lzh/LETTERS/brief.hemmerling

Text File | 1990-09-04 | 22KB | 394 lines

Rolf Hemmerling                                           Hannover,16.06.90
Asternstr. 28
D 3000 Hannover 1
0511-702905

Beitrag zu FORUM 13.

**** SF oder DM
Da doch ein wohl ein Grossteil der EFFO Teilnehmer in der BRD sitzt
und daher keinen preiswerten Zugang zu Schweizer Franken hat, ergibt
sich die Frage, wie man die Bezahlung von EFFO-Jahresbeitraegen
und alten FORUM/PD-Disketten am billigsten abwickelt. Ich verfuege
(als Student) leider ueber keinerlei Kreditkarten und zur Zeit auch
ueber keinen Eurocheck. Einen Scheck in einer Fremdwaehrung von der Bank
ausstellen zu lassen ist extrem teuer, insbesondere bei den doch i.d.R.
relativ geringen Ausstellungsbetraegen. Liebe EFFO, kann man Euch auch
Betraege in DM (aus Kulanzgruenden vielleicht in selber Hoehe wie der
angegebene SF-Betrag) ueberweisen ? Oder fallen dann bei Euch so hohe
Gebuehren an ? Ansonsten fallen mir nur die "Internationalen Postanweisungen"
ein, aber auch das ist nicht billig, ausserdem muss man da doch eine
reale Adresse und nicht nur eine Postfachadresse angeben, oder ?
Und ich kann doch nicht hier in der BRD bei der Post eine Ueberweisung
in DM in die Schweiz als SF auf ein SF-Postscheckkonto transferieren, oder ?

<< Nach den vielfaeltigen Arten der Ueberweisungen zu schliessen,
   fuehren tatsaechlich viele Wege nach Rom, wobei es auch hier
   angenehmere und beschwehrlichere dieser Art gibt.
   Natuerlich schaetze ich es sehr, wenn ein Mitglied eine direkte
   Postanweisung oder via Eurocheck seinen Beitrag an den EFFO
   gelangen laesst. Falls man nicht in Besitz von solchen Zettelchen
   ist, so kann man auch den Vater, Mutter, Tante, Onkel, Freunde
   oder Hackerkumpel nach einem Eurocheck anfragen.
   Dies stellt fuer den Auserwaehlten (fast) keinen
   Aufwand oder Risiko dar, ausser das Ausfuellen des Checks.
   Danach muesst Ihr euren Check-Spender lediglich
   zu einen guten Essen einladen oder sonst irgendwie die Differenz
   begleichen.
   Wie jedoch oben schon erwaehnt, ist die Postueberweisung nach meiner
   Ansicht das einfachste und angenehmste Verfahren.
   Die direkte Zusendung von DM betrachte ich als schlechte Loesung.
   Nicht nur weil dann der EFFO zu kurz kommt, sondern auch weil die
   Post-Taxen ins Ausland hoeher sind als Innlaendische.
   Schliesslich ist der EFFO-Beitrag zur Deckung der Unkosten der
   Redakteure gedacht und sollte deshalb nicht noch mehr belastet
   werden.
                                                              PHILM >>

<< Im Uebrigen sollte es auf jeder Post problemlos moeglich sein, eine
   internationale Postueberweisung direkt in Schweizer Franken auszustellen.
   Der bekanntermassen aeusserst nette und zuvorkommende Schalterbeamte
   berechnet dann den in DM zu bezahlenden Betrag aufgrund seines Tageskurses.
                                                                WS >>

**** Bemerkung zu FORUM12:
Die Datei /d0/soft_list auf FORUM12-A enthaelt an vielen Stellen
Steuerzeichen vom Typ "^H" (Backspace), die wohl beim Editieren
uebrig geblieben sind. Zumindest im UMACS sind sie als solche sichtbar.
Abstellbar mit dem naechsten Forum ?
<< Konnte ich leider nicht nachvollziehen. Ich habe mir mit einem
   patch-Programm direkt den disk-file angesehen. WS >>

**** MSFM
Ich waere sehr an einer Anpassung des MSDOS-Filemanagers an den ATARI-ST
interessiert, mit einem Device-Descriptor sowohl fuer Drive 0 und Drive 1.
So ganz habe ich die Einleitung im Buch von Peter Dibble auf Seite
265 nicht verstanden: Der Filemanager ist nur Softwareformat-spezifisch
fuer MSDOS-Disketten, der Zugriff auf den Diskettencontroller findet aber
im hardwareabhaengigen Device Treiber statt. An ihm haengt es, ob ein
System mit diesem Filemanager ueberhaupt MSDOS Disketten lesen kann.
Wie ist das nun beim ATARI-ST ? Der Quelltext der mir zur Verfuegung
stehenden Descriptor d0.a auf ATARI-ST hat schon vom Aufbau (Include-Dateien,
Variablennamen) her keine Aehnlichkeit mit dem mitgelieferten msD1.a,
leider. Ich habe es schlichtweg auch nicht hinbekommen, den msD0.a
ATARI-like und fuer /d0 zu modifizieren. (Ich habe neben der Harddisk
nur 1 Laufwerk ). Haette das ueberhaupt ausgereicht ?

Ich habe meinen modifizierten msd0.A diesem Brief beigefuegt, vielleicht
kann ja mal jemand von der EFFO mit ATARI-ST schauen, was noch falsch
laeuft. Die alten Angaben stehen in der naechsten Zeile als Kommentar.
(Anmerkung an die EFFO: diese Datei sollte natuerlich in diesem
unkorrekten Zustand so nicht veroeffentlicht werden, ich erhoffe mir
nur Hilfestellung von der EFFO).

Laed man den noch nicht korrekten msd0 nach dem Laden des msfm und
versucht mit /msd0 das Laufwerk anzusprechen, so meckert OS-9
daran herum (can't open), ebenso wie wenn man den original Deskriptor
von der FORUM-Diskette msd1 laed. Was mache ich falsch ? Bootdrive
ist die Harddisk.

<< Die oben erwaehnten Dateien zu msd0 befinden sich auf diesem Forum
   im Directory SOFTWARE/ASSEMBLER. THGSCH >>

**** "Bildschirmschoner" fuer ATARI-ST unter OS/9
Laed man unter ATARI-TOS das Programm "C't NIGHT", das eine automatische
Dunkelschaltung des Bildschirms nach einer gewissen Zeitdauer (300 sec)
ohne Benutzeraktivitaeten bewirkt, so funktioniert dies nach dem Booten
von OS-9 (Dr. Keil) vom GEM-Desktop aus weiter, da sich OS-9 allgemein
den Rechner nicht voellig unter den Nagel reisst, im Gegensatz z.B.
zu RTOS-UH. "C't NIGHT" wurde in der Zeitschrift C't 12/86 vom Heise
Verlag veroeffentlicht und ist in abgetippter Form auf der ATARI-ST
Sammeldiskette 2 der Firma eMedia GmbH zu finden. Die noch viele andere
Programme enthaltende Sammeldiskette kostet 20 DM. Die Vertriebsanschrift
der Firma eMedia GmbH ist in der Zeitschrift C't im Impressum abgedruckt.
Die Firma eMedia ist vor einiger Zeit wohl aus kaufmaennischen Gruenden
zum Vertrieb von in der Zeitschrift C't vorgestellter Software gegruendet
worden.

Im Gegensatz zur Situation in den USA sind in der BRD (und wohl bald auch
in ganz Deutschland) in Zeitschriften abgedruckte Programme nicht
"public-domain", daher kann das fuer jeden OS/9 Benutzer auf ATARI-ST
sinnvolle Programm leider nicht ueber die EFFO als Quelltext verteilt
werden. Eine Weitergabe von in Zeitschriften veroeffentlichten Programmen
im privaten Bekanntenkreis ist aber zulaessig.

Vielleicht koennte mal ein Benutzer des CUMANA OS/9 fuer ATARI-ST
das Programm testen, ob es in dieser Implementierung auch laeuft.
<<Die Chance ist minim, denn Cumana "reisst sich den Rechner vollstaendig
unter den Nagel" (was m.E. gegenueber der extrem crashfreudigen Keil-
Implementation nur von Vorteil ist). Vor allem aber ist es nicht
noetig, da Cumana einen eingebauten screen-saver (setscreen -p=..)
besitzt. LZ>>


**** 68881/68882  FP-Emulator gesucht
Ich benutze das Betriebssystem RTOS-UH, das an der Universitaet Hannover
am Institut fuer Regelungstechnik entwickelt wurde. Der kommerzielle
Vertrieb liegt bei der Firma IEP,Bachstr.1,D3000 Hannover1,Tel [phone]
und bei der oben erwaehnten Firma eMedia. Ansprechpartner bei Software-
fragen zur RTOS-UH ist die Firma IEP, da dort die direkt an der
Weiterentwicklung des Betriebssystems beteiligten Ingenieure sitzen
und dort der beste Draht zum Autoren des Compilers (Prof. Gerth)
besteht. Bislang waren nur die Echtzeit-Programmiersprache PEARL und
ein einfacher 68020-Assembler fuer das Betriebssystem verfuegbar und
im Standard-Lieferumfang enthalten. Einige andere Compiler (C,PASCAL,F77)
waren zwar am Institut fuer Regelungstechnik entwickelt worden, wurden
aber nie zu kommerziell oder im universitaeren Bereich nutzbaren
Produkten fertiggestellt. Der PASCAL-Compiler z.B. kann bis heute leider
keine SETs, beim F77 Compiler ist das Laufzeitsystem nicht fertig,
der C-Compiler lagert mangels Installierungs- und Wartungskapazitaeten
im "Giftschrank" ...usw.

In Kuerze wird nun ein bei der Firma IEP entstandener ANSI-C Compiler
fuer dieses Betriebssystem fertiggestellt sein, der aber leider einen
68020 Prozessor und auch einen 68881/68882 Arithmetikprozessor zum Betrieb
sowohl des Compilers als auch bei der Ausfuehrung des erzeugten Codes
benoetigt.

Mit einem Wort, man benoetigt zum Betrieb des Compilers unter RTOS-UH
auf dem ATARI-ST oder AMIGA zusaetzliche Hardware, z.B. die
Platine PAK-68K, die in der Zeitschrift C't als Projekt realisiert
worden ist. Die Umstellung von 68020 Code auf 68000 Code ist kein
grosses Problem fuer IEP, wohl aber der Aufwand fuer die Realisierung
eines vernuemftigen Ersatzes fuer den Arithmetikprozessor.

**************************************************************
Wer weiss, ob je jemand einen Emulator fuer den 68881/68882
Arithmetikprozessor programmiert hat, egal ob dieser nun kommerziell
oder gar public-domain verfuegbar ist ?
**************************************************************

Ich meine damit in erster Linie ein Programm, das bei fehlendem 68881/
68882 die Aufrufe an diesen Prozessor abfaengt und selber die noetigen
Berechnungen ausfuehrt. Denn dann koennten Programme unveraendert
entweder mit oder ohne 68881/68882 Hardware ablaufen.
<< So ein Trap-Handler waere doch mal eine huebsche Aufgabe fuer einen
   EFFO-Beitrag. WS >>
<< So schoen die Idee theoretisch ist, in der Praxis kann sie nur eine
   Notloesung sein, denn der Befehlssatz des 68881/2 ist so umfangreich,
   dass eine Emulation in Software zwangsweise aeusserst langsam wird, und
   zwar nicht in erster Line wegen der Berechnung selbst, sondern wegen
   der Emulation aller Adressierungsarten. Wenn auch der beschriebene
   Fall mit dem RTOS-UH-Compiler kaum anders geloest werden kann, so
   ist *unter OS-9* (EFF*O*) ist die Verwendung des Math-Traphandlers immer
   noch weitaus die schnellere Loesung (fuer den 68000). LZ>>

Da so etwas sowohl unabhaengig vom Betriebssystem ist als auch der
Speicherbereich fuer den Emulator bei Vorhandensein des Sourcecodes
wohl frei eingestellt werden kann, ist es egal, fuer
welchen 68000 Rechner und welches Betriebssystem die Loesung
urspruenglich gedacht worden ist.

Beim ungeliebten "Industriestandard" gibt es uebrigens fuer
80286 und 80386 Systeme (nicht aber fuer 808X,8018X oder V20/V30
Systeme) einen nachladbaren residenten Treiber, der auf Grundlage
der BORLAND (TURBO-C/TURBO-PASCAL) Arithmethik-Bibliothek dies
realisiert. Leider sind die BORLAND Bibliotheken nicht ganz
vollstaendig, einige wenige Befehle bzw. Verhaltensweisen des realen
8087 Arithmetikprozessors sind nicht implementiert worden. Der Verfasser
des Public Domain 8087-Emulators konnte da auch nichts mehr geradebiegen,
fuer den Inhalt der Arithmetikbibliotheken ist er ja nicht verantwortlich.
Aber mit TURBO-C und TURBO-PASCAL 4/5/5.5 Programmen laeuft der Emulator
recht ordentlich, mit dem WERUM-PEARL Compiler unter MSDOS bzw. mit von
WERUM-PEARL erzeugten Programmen gibt es Aerger (Absturz) bei einigen
32-Bit Integer (FIXED(31)) Berechnungen. Verfugbar ist das Programm in
der Serie PC-BLUE auf der Diskette 471 zusammen mit einem
Mandelbrot-Programm (und PKXARC). Leider liegt weder der Sourcecode des
Interfaces zur Arithmetikbibliothek bei noch ist die Anschrift des Autors
bekannt.

Die schoenen Konzepte von OS-9 mit der residenten math-Bibliothek sind
langsamer als diese Loesung und werden von den Compilerentwicklern bei
IEP wohl auch nicht gewuenscht, RTOS-UH und damit realisierte Projekte
zeichneten sich schon immer durch hohe Performance und schnelles
Echtzeitverhalten aus (z.B. keine Zeitscheiben beim Multitasking).
Falls jemand Literaturhinweise (Hinweise auf Diplom/Doktorarbeiten,
Veroeffentlichungen,Anzeigen,Tagungsberichte,..) zu diesem Thema kennt,
waere auch das fuer mich interessant. Ich privat waere auch an dem
Sourccode einer public-domain Floating-Point Bibilithek mit
IEEE-kompatiblen Routinen fuer 68000 Prozessoren interessiert,
die durch ***Aufruf von Routinen*** und eben nicht durch
Verwendung der 68881/68882-Anweisungen arbeiten. Geruechteweise hat
MOTOROLA selber einen solchen Emulator geschrieben, aber IEP
hat darueber bislang nichts in Erfahrung bringen koennen.
<< Motorola hat so einen Emulator, da sie damit eigene Forschung
betrieben haben. Ich habe dies in einem Paper vor langer Zeit gesehen,
kann ihn aber nicht mehr finden.
 Fuer den C-Compiler gibt es den Modul "math.l", der die gleichen routinen
wie traphandler zur verfuegung stellt. Ohne Source zwar, aber linkbar.
 In einer naechsten Forumsrunde wird ein Traphandler fuer einen 68881
als Peripherie fuer 68000 vorgestellt. Mit diesem Zusatz kann allen
Geschwindigkeitspuristen mit 68000 Processor geholfen werden. ZZG >>

Falls jemand die Rechte an einem oben beschriebenen 68881/68882 Emulator
zur direkten Emulation besitzt, so sollte er sich bei Interesse
direkt an die Firma IEP wenden, zwecks Verhandlungen. In allen
anderen Faellen waere **ich** an den Informationen oder
Bibliotheks-Quelltexten (auf Diskette, ATARI-ST OS/9 DR.KEIL 3 1/2 Zoll,
IBM XT/AT MSDOS, uebliche 40/80 TRACK CP/M Formate) selber interessiert.
Falls sinnvoll, wuerde ich so gewonnene Erkenntnisse natuerlich
dann auch an die Firma IEP weiterleiten.

Ich selber bin weder bei einer mit dem Vertrieb von RTOS-UH oder
des C-Compilers befassten Firmen beschaeftigt noch bekomme ich
eine Verguetung fuer diesen Aufruf. Ich wuerde nur gern in absehbarer
Zeit den C-Compiler auf meinem ATARI-ST nutzen, ohne mir zusaetzlich
die teure PAK-68K Hardware anzuschaffen. Ausserdem laeuft meine Version
des TOS-Betriebssystems (KAOS-TOS 1.41 von Andreas Kromke) leider
bis auf weiteres und in Zukunft nicht mit einem 68020 Prozessor,
ebenso andere mir nicht unbedingt zur Verfuegung stehende
Betriebssysteme (OS-9,EUMEL,MINIX,MIRAGE,PDOS,..) in der Version fuer
den ATARI-ST (selbst wenn es davon in den meisten Faellen 68020 Versionen
fuer andere Rechner geben sollte, wie bei OS-9) sowie die meisten
TOS-Anwenderprogramme. Im Grunde muesste man also zusaetzlich zum
"normalen" ATARI-ST noch einen extra fuer RTOS-UH mit PAK-68K
anschaffen, und das wird dann doch **zu** teuer.

Ebenfalls haette ich Interesse daran, eine Art "Kompatibilitaets-
bibliothek" fuer MICROWARE-C und RTOS-C zu erstellen, so dass
gewisse immer wiederkehrende Standardfunktionen in
Echtzeitanwendungen dann auf gleiche Art und Weise von
den uebergeordneten Programmen aufgerufen werden koennen.
Kommt Zeit, kommt Rat. Wenn (genauer: sobald) ich mich naeher mit
dem RTOS-C Compiler auseinander setzen sollte, werde ich mir dazu
auch Ueberlegungen machen.

Im Grunde ist ja so: Bei jedem Echtzeit-Betriebssystem ist eine
gewisse Palette an Funktionen vorhanden, mit der man die ueblichen
Echtzeitfunktionen (Semaphoren,Monitore,Warteschlangen,....) realisieren
kann. Nur hat das eine Betriebssystem z.B. echte Semaphoren, bei anderen
muss man dies ueber eine exklusive Warteschlange realisieren.. usw.

Es bietet sich daher an, einmal fuer alle Multitasking-Betriebssysteme
eine betriebssystemspezifische Bibliothek zu schreiben, die
betriebssystemsunabhaengige Schnittstellen fuer einige Standard-
funktionen fuer Echtzeitanwendungen und darauf aufbauende Dienste
bietet. Miele Datentechnik hat so etwas fuer ihren MODULA-2 Compiler
und eine allgemeine Standardbibliothek (ohne Echtzeitfunktionen) in
einem gewissen Rahmen wohl erfolgreich vorexerziert.

An zu unterstuetzenden Betriebssystemen bieten sich an:
MICROWARE OS-9,PDOS,MIRAGE,MINIX,DIGITAL RESEARCH CDOS,QUANTUM QNX,
MOTOROLA VERSADOS,MICROSOFT OS/2,RTOS-UH,INTEL IRMX,GPP PORTOS,...

So wie es mir berichtet wurde, besteht bislang eine gewisse
Kompatibilitaet zwischen RTOS-C und TURBO-C fuer den ATARI-ST,
der auch wohl das Entwicklungssystem fuer den RTOS-C Compiler darstellt.
Das ist an sich keine schlechte Ausgangsbasis. Fuer OS-9 gibt
es ja bis heute keinen ANSI-C Compiler, oder ?

Wer Vorschlaege fuer so eine Echtzeitbibliothek (inclusive
Funktionen zur bildschirmorientierten Terminal Ein/Ausgabe,
Warteschlangen,Monitore,Bolts,Semaphoren, darauf aufbauend vielleicht
auch eine echtzeitfaehige B-TREE Datenverwaltung, Routinen zur
allgemeinen Datenerfassung ....) machen moechte, ist hiermit gerne
aufgefordert. Eine Liste sinnvoller Funktionen inclusive Parameterlisten
waere der erste Schritt, auch bevor naehere Informationen ueber die
Bibliotheken von RTOS-C zur Verfuegung stehen. Informationen
ueber das zugrunde liegende Betriebssystem, seine Moeglichkeiten und den
Zugriff auf Systemfunktionen auf Assemblerebene sind im normalen RTOS-
Benutzerhandbuch ausreichend dokumentiert, das mir vorliegt. Ausserdem
kann ich einstweilen zu Ortsgespraechstarif der Entwicklungsfirma IEP
Loecher in den Bauch fragen. Genuegend Informationen stehen mir
ausserdem fuer CDOS zur Verfuegung.

In gut einem Jahr (also ab Herbst 1991 oder Winter 1991/1992) wird RTOS-C
wohl so stabil sein, dass man sich als normaler Anwender damit befassen
kann, ohne staendig Workarounds erfinden zu muessen. Bis dahin sind
wohl auch die Laufzeitbibliotheken ausgereift. Vorher wird wohl kaum
etwas bei mir damit laufen. Bis dahin hat sich vielleicht auch von selber
eine Loesung fuer den fehlenden 68881/68882 im ATARI-ST gefunden. Auf denn !

Ach ja: So eine Kompatibilitaetsbibliothek zu programmieren ist bei
der Echtzeitprogrammiersprache PEARL Sache der PEARL-Compilerhersteller,
da gerade bei PEARL viele wichtige Elemente von Echtzeitfunktionen
entweder Teil der nach DIN genormten Programmiersprache (SEMA,BOLT
Variablen, deklarierbare TASKs) sind oder sich vom Anwender auf
jedem PEARL-Rechner in Hochsprache leicht und portabel deklarieren
lassen (Monitore,...).

*** MODULA-2
Die Redakteure der EFFO erwaehnten in ihren Kommentaren in
brief.zweimueller in FORUM 12 einen public domain MODULA-2 Compiler
unter OS-9, wie komme ich da ran ?
<< Die Betonung lag dabei auf dem 'halben Herzen'. Es gibt eine rudimentaere
   geradeso lauffaehige Vor-alpha-Version, also absolut nichts Gebrauchs-
   faehiges.   WS >>

***
Kann man die GEM/AES Graphikfunktionen oder gar die GEM Funktionen
der ATARI ST Roms unter OS-9 nutzen ? Wenn ja, wie, und was muss
man beachten ? Waere da nicht eine einfache Moeglichkeit, MSDOS/TOS
Disketten zu lesen ?
<< ATARI ROMs sind nicht reentrant und arbeiten meines wissens
mit fixen Adressen. Da muesste man wohl zu viel *murksen*. ZZG >>

*** Disketteneditor
Gibt es einen PD-Disketteneditor fuer OS-9, er auf **jedem** System
ohne Anpassung an den Floppycontroller funktioniert, mit
"Dateimodus" ?
<< Uns ist noch nichts bekannt.  WS >>

*** OS-9 Diskettenformat
Gibt es ein PD-Programm als 68000 Assembler/C-Sourcecode, um
ohne OS-9 Betriebssystem OS-9 Disketten zu lesen ? Ich wuerde
es gerne fuer das Betriebssystem RTOS-UH anpassen, um von dort
aus auf OS-9 Disketten und insbesondere die OS-9 Partition auf
ATARI-Harddisks zugreifen zu koennen. Interessant waeren das
Dr.Keil und das Cumana Format fuer ATARI-ST sowie das neue
Standardformat ab OS-9 V2.3. (RTOS-UH kann standardmaessig
neben dem "eigenen" Format auch MSDOS/TOS Disketten sowie
TOS-Harddisk Partitionen verarbeiten).

*** Bezugsquellen der Software in der soft_list
In der soft_list sind bei den Hersteller/Vertreibernamen viele
Namen aufgefuehrt, die ich gar nicht kenne bzw. deren Kataloge
ich bislang aufgrund mangelnder Adressen gar nicht anfordern
konnte. Auch wenn die EFFO keine Werbung macht, waere eine
Adressenliste all dieser Firmen doch recht nuetzlich.
Was heisst "OS-9 Pool", wie kommt man an diese Software heran ?
<<OS-9-Pool war die Uralt-Bezeichnung fuer EFFO, bevor es EFFO
hiess>>
Auch wuerde der Hinweis, ob eine Software PD oder kommerziell
ist, viel nutzen.
<<Diese Information ist in der Datenbank im OS9-BBS - von wo das
File soft_list abgezogen wird - enthalten. Ich werde mich darum
bemuehen, bei neuen soft_listst diese Info mitrauszulassen. LZ>>
 Klar ist, das von Firmen vertriebene Software
nicht PD ist, aber eine grobe (wenn auch moeglicherweise veraltete)
Preisangabe wuerde helfen, "unbezahlbare Industrie-Produkte"
und "preiswerter Software" zu unterscheiden. Fuer einen MSDOS-Filemanager
zum Lesen und Schreiben von MSDOS Disketten habe ich zuletzt bei
Oettle & Reicher den ueblichen Industrie-Preis von 950 DM gesehen,
verfuegbar ab 2.Quartal 90. Hoffentlich erspart das auf der soeben
erhaltene FORUM-Diskette 12 enthaltene Programm den EFFO-Teilnehmern
diese Ausgabe.

Also, wenn es geht, fuegen Sie entweder hier als Kommentar die in
soft_list aufgefuehrten Firmen bzw. Vertriebsquellen auf, oder noch
besser, fuegen Sie diese Liste der Datei soft_list hinten/vorne an.

Vertreiber:
-----------
DMO <<User des OS9-BBS, unter diesem Namen>>
EFFO (ohne Angabe einer Forum- oder PD-Diskette) <<Alte Forumsrunden
(wir geben es zu, da gibt's noch einiges zu erfassen, bitte geduld...>>
OS9-POOL <<dito, siehe oben>>
where (keine Angabe) <<dummer Scherz von dem, der's eingegeben hat :-(>>
ELSOFT AG <<Zelgweg 12, CH-5405 Baden-Daettwil, ++41/56/83'33'77>>
MIELE DATENTECHNIK << Hermann-Josef Miele Datentechnik GmbH, Bergfreiheit 60,
                      D-5788 Winterberg, (02983) 8307 und 8337 >>
HOLI <<User des OS9-BBS>>
CODEX <<User des OS9-BBS, Implementator von OS-9 fuer den Gepard>>
MICROWARE -> Dr.Keil + Cumana Vertriebsadresse
(Die Adresse von Dr. Keil ist mir klar, aber wie wird genau
die Cumana Implementierung in der BRD vertrieben ?) <<recc-o-ware in Muenchen>>

SNOWWHITE <<User des OS9-BBS>>
PASCAL DORNIER <<Anfragen an FONEBONE in der OS9-BBS richten>>
ELBATEX <<AG, Hardstrasse 72, CH-5430 Wettingen>>

*** Ende