OVERSCAN.PRG  Version 1.6   Karsten Isakovic , Berlin 05.07.89
--------------------------------------------------------------

Das vorliegende Programm arbeitet nur mit folgenden TOS-Versionen

   ROM-TOS 1.4   Messe-Version getestet
   RAM-TOS 1.4   Deutsches Entwickler TOS
   BETA-TOS      Englisches Test-TOS
   ROM-TOS 1.2   BlitterTOS
   RAM-TOS 1.2   BlitterTOS (nicht getestet !)
   KAOS-TOS      aus CT 11/88

und auch nur wenn die OVERSCAN-Modifikation am Rechner erfolgt ist.
In den Farbmodi luft es nur bei 50 Hz korrekt !

Bei allen anderen TOS-Versionen oder wenn der Schalter nicht auf OVERSCAN
steht sollte eine Fehlermeldung kommen.

        Anleitung
        ---------

Das Programm gehrt als erstes Programm in den AUTO-Ordner der BOOT-Diskette.
Dazu mu man einen neuen AUTO-Ordner anlegen und die BOOT-Programme in der
gewnschten Reihenfolge in den Ordner kopieren.
Den Schalter umlegen und Rechner einschalten. Beim Laden des Programms eine
der SonderTasten Control/Shift oder Alternate drcken und schon landet man
im InstallationsMenu. 
Auf dem ansonst schwarzen Bildschirm ist eine Box mit ihren Diagonalen
gezeichnet. Die Box kann mit den CursorTasten in der Hhe und Breite
verndert werden. Die linke obere Ecke kann mit den Tasten / * - + des
ZehnerBlocks frei auf dem Bildschirm verschoben werden.
Diese Box ist durch Verschieben und Vergrern nun so gro wie mglich
einzustellen, so das die Box gerade noch zu sehen ist. Beim SchwarzWei-
Monitor kann man sehr gut sehen wie die Box im Strahlenrcklauf umklappt,
wenn man sie zu breit macht. Hat man einen Farb-Monitor angeschlossen,
so sollte man die Einstellung auch gleich fr beide Auflsungen vornehmen.
Dazu kann man mit den Tasten L, M und H in die Auflsungen Low,Middle und
High (fals man eine AutoMonitorSwitchBox hat) umschalten.
Auderdem kann man mit P den Physbase-Emulator einschalten, der einige
wenige Programme (z.B. Calamus) doch noch zum laufen bringt, Mit C kann
man festlegen ob das BildschirmLschen mit Alt/Help oder mit 
RechtsShift/Alt/Help aktiviert werden soll.

Sind alle EinstellungsArbeiten erledigt, so drckt man einfach S fr 
Speichern und die Werte werden permanent im OVERSCAN.PRG gespeichert. Drckt
man nur Q, so werden die Werte zwar bernommen, doch nicht gespeichert.
Wei man nicht mehr, welche Taste wofr ist, kann man sich die Liste nochmals
mit der HELP-Taste anzeigen lassen.

        Was gibt es sonst noch fr den NUR-USER ?
        -----------------------------------------
Das Programm passt die grundlegenden Ausgabe-Routinen des ST an die durch
den Schalter vernderte BildschirmBreite und Hhe an.
Da bisher nur wenige Programm mit einem greren Bildschirm zurechtkommen,
sind im Programm Vorkehrungen getroffen, um nach Beendigung eines solchen
Programms das Desktop wieder korrekt darzustellen. Sollte einmal ein
Accessory den BildschirmAufbau zerstren besteht noch die Mglichkeit den
Bildschirm manuell durch Drcken der eingestellten ClearTaste wieder
zu restaurieren.
In allen TOS-Versionen existiert ein Fehler beim Scrollen von TOS-Texten.
Wenn es sich um ein RAM-TOS handelt, so wird der Fehler im RAM gepatched.
Dieser Fehler ist ATARI mindestens seit BIGSCREEN (Hallo Julian !) bekannt und
sollte in der Offiziellen ROMTOS-1.4 Version behoben sein.
    (Ach was haben wir nicht alles schon von ATARI geglaubt)
Man kann brigens seine Bekannten schocken, indem man im Monochrom-Modus
einen Mini-Bildschirm von 320x320 einstellt und diesen in die rechte untere
Ecke plaziert. Sieht echt s aus.
Der GemDesktop hat einen Fehler bei 'Voreinstellung'. Er steht immer auf
Mittlerer Auflsung und man kann hchstens von Mittel nach Niedrig wechseln,
aber nicht mehr zurck. Deswegen kann man beim Wechsel der Auflsung eine
eine der SonderTasten gedrckt halten und landet dann im Setup-Modus. Dort
kann man dann in die gewnschte Auflsung wechseln.

        Zusammenfassung fr Interessierte
        ---------------------------------
Zuerst testet das Programm, ob ein gltiges TOS vorliegt, ob der Schalter
umgelegt ist und ob das OVERSCAN.PRG nicht doch schon installiert ist.
Jetzt wird erst einmal der ntig Bildschirmspeicher beschafft, indem man
den zustzlich bentigten Speicherplatz aus der MemoryAllocatedList
austrgt. Damit wird er bei Programmende nicht mehr freigegeben.
Bei einem RAMTOS wird der Fehler beim Scrollen von TOS-Texten gepatched.
Dieser Fehler beruht darauf, da davon ausgegangen wird, das die Breite
des Bildschirms in Bytes immer durch 16 teilbar ist.
Danach werden der AES/VDI-Trap ,der GEMDOS-Trap, der XBIOS Trap und der
HARDCOPY-Vektor umgehngt. Bei BlitterTOS werden zustzlich der VB-Vektor
und der Mouse_Vektor umgesetzt, da die Orginal-Routinen zum Zeichnen der
Maus nicht mit Bildschirmen grer 32K zurechtkommen.
Danach werden die LineA-Variablen auf die neuen Werte gesetzt und die
TOS-Ausgabe neu initialisiert.Der Bildschirmspeicher wird komplett auf
Schwarz gelscht, da man sonst die Rcklaufstrahlen sehen wrde.
Nun wird getestet, ob eine SonderTaste gedrckt ist und gegebenenfals zur
BenutzerInstallation geprungen, wo man das Programm auf seinen Bildschirm
anpassen kann.
Wurde keine SonderTaste gedrckt folgt ein kleines Intro, der Bildschirm
vergrert sich (symbolisch) von seiner alten Gre bis zur neuen Gre.
Auerdem wird der alte BildschirmInhalt der ja nicht lesbar war in den
neuen OverscanBildschirm kopiert.
Je nachdem welcher Fall vorlag, beendet sich OVERCAN.PRG mit der Meldung
'OVERCAN installed' und bleibt resident im Speicher oder mit einer der 
Fehlermeldungen und bleibt nicht im Speicher.
  Wozu sind nun die Traps und Vektoren ???
Es reicht nicht aus, den OVERSCAN-Modus einmal einzustellen, weil z.B.
das GEM beim Starten alle LineA-Werte berschreibt und auch gleich noch
32K des Bildschirms auf Wei setzt, die sich beim SchwarzWei-Monitor als
strende Rcklaufstreifen bemerkbar machen.Ausserdem gibt es Programme,die
direkt in den Bildschirmspeicher schreiben oder den Bildschirmspeicher mit
SetScreen an eine andere Stelle verlegen, und dabei den notwendigen Offset
zwischen v_bas_add und dem VideoAddresszhler vernichten. (Zum Aufbau des
Bildschirmspeicher siehe weiter unten).
Der AES/VDI-Trap ist so installiert, das ein ffnen der BildschirmWorkstation
(v_opnwk) abgefangen wird, die Orginal-Routine ausgefhrt wird (lscht unter
anderem auch den Bildschirm s.o.) und DANACH der OVERSCAN-Modus neu
installiert wird, und die Rnder des Bildschirms wieder gesubert werden. 
Diese Routine wird nur beim Starten des Desktops und beim Wechseln der
Auflsung mit 'Voreinstellung' im Desktop aufgerufen. ( Das dort immer die 
Mittlere Auflsung als Aktuelle angezeigt wird, ist ein weitere Fehler im GEM )
Der GEMOS-Trap wartet auf die Aufrufe Pterm und Pterm0, also das Ende eines
Prgramms. Es wird vorsichtshalber (s.o.) der OVERSCAN-Modus wieder
eingestellt und die BildschirmRnder gelscht.
Der XBIOS-Trap ist fr den PhysbaseEmulator. Manche Programme die ansonsten
laufen benutzen zum Feststellen der BildschirmAddresse die Funktion Physbase
anstatt Logbase. Beim OVERSCAN-Modus existiert leider ein Offet zwischen beiden
Funktionen. Wenn ein Programm also korrekt luft und nur teilweise verschoben
auf dem Schirm erscheint kann man diesen Emulator aktivieren, der nichts weiter
tut als statt Physbase den Wert von Logbase zurckzuliefern. Nun knnen aber
speziell an OVERSCAN-Modus angepasste Programme den Offset nicht mehr erkennen.
(Da es noch nicht viele solcher Programme gibt, kann man den Emulator ruhig 
aktivieren)
Der HARDCOPY-Vektor fragt auf die eingestellte Cleartaste ab und stellt dann auf
Wunsch den OVERSCAN-Modus wieder ein, usw...
Der VB-Vektor und der Mouse-Vektor werden nur bei BlitterTOS benutzt. Die 
OrginalRoutinen werden durch die MausRoutinen von TOS 1.4 ersetzt.

        Warum viele Programme nicht laufen
        ----------------------------------
Programme , die mit den Funktionen Setscreen den BildschirmSpeicher verlegen,
zerstren den notwendigen Offset zwischen BildschirmSpeicher und VideoAddress-
zhler. Auerdem reservieren sie nur 32Kb Speicher und legen den Bildschirm
auf eine durch 256 teilbare Addresse. Beim OVERSCAN-Modus sind es aber 68KB
BildschirmSpeicher und der Bildschirm beginnt an einer 'schrgen' Addresse.
(Dieser minimal Offset wird zur horizontalen Poitionierung benutzt).
Programme, die den BildschirmAnfang mit Phybase holen bekommen einen falschen
Wert (Bildschirm - VideoOffset) geliefert. Nur Logbase liefert den richtigen
BildschirmAnfang.Um diese Programme doch noch zum Laufen zu kriegen gibt es
ja noch den PhysbaseEmulator.
Viele Programme schreiben direkt in den BildschirmSpeicher und nehmen dabei
eine konstante Breite von 80, bzw 160 Bytes pro Zeile an. 
Beispiele zu diesem Thema :
   eigene Textausgabe  GFA-Assembler,Tempus und TemplMon.
   eigene Graphik      Degas, CyberPaint, MonoStar, Stad und CAD-3D
   zuwenig Speicher    bei TurboC, alle GraphikProgramme 
                            (ausser Doodle, dem GEM-Beispiel Programm !)
In manchen GEM-Programmen, die ansonsten laufen,sind die Grenzen fr den
FormDial-Aufruf zur BildschirmRestaurierung fest auf 640/400 gesetzt und somit
wird der Bildschirm nach DialogBoxen nicht berall korrekt wieder aufgebaut. 

Programme, die direkt in den BildschirmSpeicher schreiben, Ihn nicht verlegen
und den BildschirmAnfang mit Logbase geholt haben, sind auch noch benutzbar.
Einfach den Schalter wieder zurckschalten und normal arbeiten - nach dem
ProgrammEnde wird automatisch der BildschirmSpeicher gesubert und man kann
wieder auf OVERSCAN-Modus schalten. (Vorsicht bei GEM-Programmen, die eine 
eigene MausRoutine einbinden, manche strzen ab, wenn beim Starten die Maus
'auerhalb' des Orginal-32K-BildschirmBereiches ist -- einfach mit der Maus
vorher nach Links Oben fahren . Bemerkt bei GFA-Assembler.)

        Der Aufbau des BildschirmSpeichers
        ----------------------------------

Hier eine kleine Graphik :
--------------------------

 freier Speicher        |                                                   |
                        |                                                   |
 memtop             ->  +---------------------------------------------------|
                        |      SicherheitsPuffer fr den Rcklauf zum       |
                        |      Bildschirmanfang, mu schwarz sein, da       |
                        |      man sonst den Rcklaufstrahl sieht.          |
 VideoAddressZhler ->  +---------------------------------------------------+
                        | Das Signal, was durch die kleine Schaltung erzeut | 
                        | wird setzt leider schon im Rcklauf ein, also wird|
                        | einfach ein Offset angebracht, der dieses wieder  |
                        | ausgleicht.                                       |
 v_bas_add          ->  +-------------------------------------------+-------+
                        | Beginn des eigentlichen                   |       |
                        | BildschirmSpeichers. Das Signal der       |       |
                        | Schaltung dauert leider zu lange und      |Unge-  |
                        | reicht in den Zeilenrcklauf hinein.      |nutzter|
                        | Deswegen existiert rechts ein ungenutzter |       |
                        | Bereich, der schwarz sein mu, damit man  |Bereich|
                        | ihn nicht sieht.Die Breite des Bereiches  |       |
                        | hngt davon ab, wieviele Pixel auf dem    |       |
                        | Monitor dargestellt werden und ab wann der|       |
                        | Strahlrcklauf beginnt. Die ganze Breite  |       |
                        | des BildschirmSpeichers ist durch das     |       |
                        | HardwareSignal vorgegeben.                |       |
                        +-------------------------------------------+-------+
                        | Ein kleiner Bereich hinter dem Bildschirm mu auch|
                        | Schwarz sein . Siehe oben.                        |
 SpeicherEnde        -> +---------------------------------------------------+

Wie man sieht hngt alles von dem Signal ab, das Stefan zusammengebraut hat.
Dieses ist leider frequenzabhngig, deswegen geht es nicht bei 60 Hz
(ungerade Anzahl Bytes) und im Monochrom Betrieb gibts nicht dieselbe
Breite wie in Farbe.
Stefan hat sehr lange gesucht, aber es ist kein Signal Vorhanden, bei dem der
ungenutzte Bereich rechts kleiner wre. Das benutzte Signal ist also 
ein Kompromiss zwischen Speicherplatz-Vergeudung und maximaler Pixelbreite
auf dem Monitor. 
( Das Signal kann man brigens ganz auf High legen, dann wrde der Shifter
  immer den BildschirmSpeicher auslesen, also auch im ZeilenRcklauf und im
  StrahlenRcklauf. Somit htte man nochmehr BildschirmSpeicher verschenkt...)
Wenn irgendwer in der Lage ist, ein Schaltung zu entwerfen (PAL), die das
eigentlich bentigte Signal in allen Auflsungen liefert (auch bei 60 Hz !)
der sollte sich bei Uns melden.
Der neue Bildschirmspeicher hat eine Lnge von 68 KB, bei BlitterTOS 100KB,
davon werden auf dem Monitor ca 55KB in niedriger , 58KB in mittlerer und
40KB in hoher Auflsung dargestellt, hngt natrlich alles von der Einstellung
ab.
Die Gre wurde konstant gewhlt, weil beim Wechseln des Monitors von Schwarz/
Wei auf Farbe( und umgekehrt) geschaltet werden kann, und dann eine andere
Bildschirmspeichergre notwendig wre. 
Den richtigen Zugewinn an Bildpunkten hat man also in der mittleren Auflsung !

        Und nun zu den Fakten
        ---------------------

Auflsung  Breite  Hhe   BytesProZeile  Theoretische Breite  Offset
---------------------------------------------------------------------
Niedrig     400     280       236             464              252
Mittel      832     280       236             928              248
Hoch        672     480       100             800             9800

Die Breite ,Hhe und Offset sind jeweils Monitor abhngig und mssen
eingestellt werden. Die bisher erreichten MaximalWerte auf blichen
Monitoren mit geringer Modifikation (Verschieben und Verkleinern des
Monitorbildes mit den vorhandenen Monitorreglern) :

    Fernseher     : Niedrig 416x280, Mittel 848x280
    SC1224        : Niedrig 400x280, Mittel 832x280
    SM124         : 688x480
    NEC-Multisync : Niedrig 432x280, Mittel 864x280, Hoch 732x480

Stefan arbeitet noch an einer kleinen Modifikation des SchwarzWei-Monitors
mit dessen Hilfe der Strahlrcklauf verkrzt und somit die Anzahl der
sichtbaren Punkte erhht wird. Noch hat sich aber nichts ergeben, auer das
es fr den Monitor (und fr einen selbst) ttlich sein kann, die Steilheit
des Ablenksignals zu erhhen, da aus diesem Signal die Hochspannung generiert
wird.

 
        Welche Programme laufen ????
        ----------------------------
 Generell alle Programme die auf Grobildschirmen laufen.
 Alle sauber programmierten GEM und TOS Programme
   Doodle       
   GDOS         (mu vor OVERSCAN im AUTO-Ordner gestartet werden)
   AMC-GDOS
   1stWord      3.11(BRD)
   Calamus      1.01.8 (mit PhysbaseEmulator)
   That's Write
   KumaResource 1.0
   KumaGraph    3.2
   KumaSpread   2.09
   EasyDraw     2.32
   GemDraw   
   GemPaint     1.3b2
   SuperBase    2.01
   DataMatST    1.06
   DBaseST      1.0

   Control.Acc
   Kubis.Acc
   Procalc.Acc
   Ti59.Acc
   DeskAssist2+.Acc

   ST-Digital   1.1 (Fenster drfen nicht ganz so gro werden)    
   SoftSynth    2.0  

        Welche noch nicht ???
        ---------------------
 Programme die in den Bildschirmspeicher schreiben oder die die
 BildschirmSpeicherAddresse verndern.
   SuperCharger 1.2 (Strzt bei Vollbild ab, sonst ok)
   GFA-Basic    3.06 Editor nicht/Programme gehen 
   Turbo-C      Editor/Compiler/Linker ja  /  Starten von Programmen nein
   Degas Elite
   TempleMon
   Tempus       (sofort ndern !!!!, CCD Dalli zack !)
   CyberPaint
   Cad3D
   Signum
   etc.         (leider !)


        Zur Geschichte von OVERSCAN.PRG
        -------------------------------

Stefan dreht mit seinem ST kleine VideoFilme... Dabei strte ihn etwas 
aber sehr, das nmlich das das Bild nur ein kleines Rechteck in der Mitte des
Videofilmes ist und nicht wie beim AMIGA der ganze Bereich genutzt wird.

Mehrere DEMOs von TEX, irgendwann 88
------------------------------------
Das BIG-Demo von TEXT hatte ein Bild ohne unteren Rand. Und dies hat Stefan
so fasziniert, das er wissen wollte was dabei in der Hardware vorgeht. Er hat
also die Signal mit dem Oszilloskop berprft und hat so gesehen, das der
Shifter im unteren Rand von der Software so irritiert wurde, das er einfach
weiterschrieb.  Alle folgenden Demos wurden nun auch per Oszi untersucht.
Z.B das FNIL-Demo mit den 4096-Farben, was sich einfach also Humbug heraus-
stellte. Einfach in MidResolution bei 60Hz jeden 2. Bildpunkt mit unter-
schiedlicher Farbe ,ergibt jeweils die Mischfarbe daraus. Aber die Krnung
des Ganzen war dann das DeathOfTheLeftBorder von TEX, bei dem es garkeine
Rnder mehr gab. Was dabei auf dem Oszi passierte brachte Stefan auf die
Idee, den Shifter per HardwareSignal zum weiterschreiben anzuregen. Er fing
an, in dem Rechner nach einem geeigneten Signal zu suchen. Wenn man den 
Shifter mit einem andernen Signal ftterte, war der komplette Bildschirm von
oben Links bis unten Rechts vollgeschreiben. Ich(Karsten) fing an die Sache
von der SoftwareSeite aus anzugehen. Die Breite in BytesProZeile wurde
festgestellt und ich habe ein RAMTOS von 6.2.86 (UraltTOS ) mit den neuen
Werten gepatched. Wie wir schnell sahen, strzte LineA ab weil es nicht fr
solch lange Bildschirmspeicher ausgelegt war. Ein Artikel im ST-Sonderheft
brachte aber den ersehnten LineA-Patch und schon gab es die erste 
OVERSCAN-Version. Als nchstes gab es eine Version mit dem BETATOS.IMG, dem
Englischen EntwicklerTOS, bei dem LineA nicht mehr gepatched werden mute.


BETATOS.IMG und POKE.PRG von Karsten Isakovic, November 88
----------------------------------------------------------
Es gab ein kurzes GFA-Basic Programm, das ein vorhandenes
BETATOS.IMG auf Diskette patchte und ein POKE.PRG , das in den
AUTO-Ordner gehrte und den Bildschirm-Offset einstellte. Es ging
also nur mit einem RAMTOS und auch nur in den Farb-Modi.
Diese Version wurde an das ST-Magazin geschickt, lag dort ein halbes
Jahr auf Eis und wurde dann dank Julian wieder ausgegraben.

OVERSCAN.PRG   Version 1.1 , 30.03.89
-------------------------------------
                  (abgedruckt als HEX-DUMP im ST-Magazin Mai 89)
Das OVERSCAN.PRG arbeitete jetzt mit 2 TOS-Versionen, mit dem BETA-RamTos
und dem deutschen Entwickler-RamTos. (Beide nichtffentlich zu haben...).
Der SchwarzWei-Modus ist schon eingebaut,die Sache mit der Hardcopy auch
schon. Um die Bildschirmwerte zu ndern mu man das Programm neu bersetzen
und eine Umschaltung der Auflsung vom Desktop aus war nicht mglich...
Diese Version wurde von Julian auf der Hanover-Messe vorgefhrt.

OVERSCAN.PRG   Version 1.2 , 25.04.89
-------------------------------------
Endlich lief das Programm auch mit dem ROMTOS 1.4 . Diese Version
ist auf der Leser-Service-Diskette von Markt und Technik zu haben.

OVERSCAN.PRG   Version 1.3 , 06.05.89
-------------------------------------
Unser Artikel vom November 88 ist im St-Magazin erschienen und leider vllig
verndert worden.
Vom der TOS 1.4 -Abhngigkeit und von den realen BildschirmWerten keine Rede,
es wurden alle Hinweise darauf gestrichen und die BildschirmWerte wurden
als groer Aufhnger verndert. Wenn man weiss , wie es wirklich ist, enthlt
der Artikel keine groben Fehler, sondern nur sehr viele Unterlassungen.
  (Warum haben sie auch noch den Namen in HYPERSCREEN gendert ???)
Dies ist die letzte Version in MegaMax-C, da Bernd das C-Programm an den
GFA-Assembler angepasst hat. Auserdem ist der Bus-Error beim MEGA-ST4 ist nun
beseitigt und das Programm etwas bersichtlicher geworden. 

OVERSCAN.PRG   Version 1.4 von Bernd Gebauer, Berlin 31.05.89
-------------------------------------------------------------
Der zweite Teil des Artikels ist erschienen. Trotz Beschwerden beim Verlag
immernoch kein Hinweis auf die falschen Werte bei den Grenangaben. Der
zweite Teil handelt von der allerersten Version mit dem gepatchten BETA-
RAMTOS und dem POKE.PRG im AUTO-Ordner, ist also vollkommen veraltet. Naja
der Aufbau des Bildschirmspeichers ist ja immerhin derselbe geblieben . 
Dank Bernd, der nicht so faul war wie ich und die MausRoutinen des TOS 1.4
umbaute (anhand des Beispiels aus BIGSCREEN von Julian F. Reschke) luft
das Programm jetzt auch mit Blitter-TOS 1.2 von 1987.
Dazu wurde vor dem Bildschirmspeicher ein 32KByte Sicherheitspuffer
angelegt und die Routinen, mit denen GEM das Mauszeichnen erledigt,
vollstndig ersetzt (siehe auch BigScreen-Artikel im ST-Magazin 11/88).
In einer spteren Version von OVERSCAN kann der Sicherheitspuffer
hoffentlich wegfallen.
Es luft jetzt auch mit einem richtig installiertem KAOS-TOS 
( siehe c't 11/88 ) .

OVERSCAN.PRG  Version 1.5 , Karsten 04.06.89
--------------------------------------------
Die Anpassung GFA-Assembler und BlitterTos von Bernd hatte mir soviel
Auftrieb gegeben, da ich drei Nchte durchgearbeitet habe um diese
Version fertigzustellen.
Nun gab es den BenutzerSetup, das Intro und das AutoRestore nach jedem
Programm.

OVERSCAN.PRG  Version 1.6 , Karsten 05.07.89
--------------------------------------------
Diese Version kopiert den alten BildschirmInhalt in den OverscanBildschirm,
beim Wechsel der Auflsung kann man in den SetupModus wechseln und die
Auflsung auch wirklich wechseln. Auerdem kann die BildschirmLschTaste
bestimmt werden und der PhysbaseEmulator fr weitere Kompatibilitt ist 
eingebaut. Diese Version wird wieder auf der Leser-Service-Diskette von
Markt und Technik zu haben sein. Nach einigem Hin und Her haben wir uns doch
wieder mit dem Verlag vertragen.


             karSTEN    22:17:48  am  05.07.89


P.S. :

    Bei Fragen einfach Post an

                Karsten Isakovic
                WilmersdorferStr. 82
                1000 Berlin 12

    oder ber Koppler in der Mailbox 

        Parrot Berlin    030-724467  

        mit   'login visitor visitor' 
        und   'write mail visitors.brd'

    eine Mail an mich (STEN) hinterlegen.

P.S.S. :
    Wenn Ihr noch Programme findet die laufen, teilt es uns bitte mit.
    ( Name und VersionsNr angeben ! ) 

P.S.S.S. :

 Viele Gre an Julian Reschke, Andreas Hoepfner, Konrad Hinsen,
 Patrik,Volker und an alle anderen die mich kennen.

