06601030305800
F0110030
9[....................................................]001


Wir zeigten Ihnen inAusgabe5/89desST-Magazins,wie man mit Hilfe 
eines einfachen Umschalters, zweier Dioden, zwei Widerstnden, einem 
Transistor und einem Pufferkondensator,die zusammen nicht mehr als 
3 DM kosten oder noch in derBastelkiste vorhanden sind, dem Atari 
einen 67024 Bytes( 59640 Bytesdavon sichtbar; Angabe gilt fr den 
Farbmodus ) groen Bildschirmspeicherbeschert.

Das bedeutet: Im Low-Resolution-Mode stehen jetzt 420 * 284 Punkte bei
weiterhin 16 Farben pro Punkt und im Mid-Res-Mode sogar 840 * 284 Punkte
mit 4 Farben pro Punkt zur Verfgung.(Neue Hardwareauflsung; kann durch
unsere Software an die Monitorverhltnisse angepasst werden)
Im Monochromen Modus gibt der ST durch unsere Modifikation nun 800*500
Pixel aus, von denen der SM 124 ohne Umbau allerdings nur rund 688*480
Pixel anzeigen kann. Deshalb beschrnkt unsere Software die Gre des
Screens auf diese kleinere Auflsung(einstellbar ab Hyperscreen.PRG
Version 1.5).

Man hat damit nun nicht mehr nur ein Bildschirmfenster, sondern ein 
ausgeflltes Bild ohne strenden Rand auf einem Fersehschirm oder 
Farbmonitorund auf dem SM 124 ein deutlich greres "Arbeitsfenster".
Beim Amiga, der das schon von Hause aus durch seine Hardware kann, nennt
man diesen Modus: "Hyperscreen".

Der Atari kann nun also auch bildfllend Pixelgrafik darstellen, so da
man ihn jetzt auch professionell im Desktop-Video-Bereich, z.B. zusammen
mit einem Genlock-Interface einsetzen kann, um vielleicht am unteren Rand
eines Videobildes noch einen Scrolltext einzublenden, der dann aber
wirklich vom rechten bis zum linken Rand der Bildrhre durchluft und nicht
wie sonst immer nur im Bildschirmfenster des Ataris erscheint.

Der Farb-Grafik-Aufbau eines ST-Video-Bildesim 50 Hertz-Mode sieht
folgendermaen aus:
Das ST-Video-Bild besteht aus 313 Zeilen, die 50 mal in der Sekunde
geschrieben werden.
Es wird ohne Zeilensprungverfahren (Interlace; Fachbegriff aus der 
Fernsehtechnik fr Halbbildverkmmung) gearbeitet; zwei Halbilder 
liegen alsogenau aufeinander. Die ersten 39 Bildzeilen werden vom Atari 
normalerweiseohne Pixelgrafik, nur mit der Hintergrundfarbe 
(Farbpalette 0) dargestellt.
Danach kommen dann 200 Bildzeilen, wo jede Zeile links am Rand mit der
Hintergrundfarbe beginnt, dann in der Mitte die Pixelgrafik (320 oder
640 Pixel, je nach Mode) anzeigt wird und am rechten Rand wieder mit der
Hintergrundfarbe aufhrt.
Die darauffolgenden 45 Zeilen, die den unteren Rand darstellen, werden
normalerweise wieder ohne Pixelgafik, nur mit der Hintergrundfarbe
dargestellt.
Das ergibt dann das typische grne Desktop-Bild mit dem weien Rand
(Rahmen), wenn ohne Accessories und Desktop-Info eingeschaltet wird.
Der weie Rand (Rahmen) ist dabei die Hintergrundfarbe 
(Farbpalettenregister 0).
Die letzten 29 Zeilen von den 313 Zeilen werden durch das von dem Glue-
Baustein erzeugtem "Blank"-Signal dunkel ausgetastet.
Sie stellen also das vertikale Austastsignal dar (vertikale Austastlcke)
und sind somit nicht auf dem Fernseher oder Monitor sichtbar.

Dies hattendie TEX-Leute auchschon inihremArtikelimST-Magazin
beschrieben.Sieschalteten auch den rechten Rand ab, um
dort Pixelgrafik darzustellen, so trieb es die TNT-Crew noch ein Stck
weiter und prsentierte auch den linken Rand mit Pixelgrafik!!!

Wow!, dachte ich mir, wenn die Jungs es schaffen, den Atari per Software
so zu berlisten, etwas darzustellen, was hardwaremig eigentlich gar
nicht vorgesehen ist, dann mte das doch auch durch einen kleinen
Hardwareeingriff(-umbau) mglich sein, ohne da dafr komplizierte und
zeitraubende Interrupt- und Videoadrezhlersynchronisierung wie bei der
Softwareversion notwendig ist!
Auerdem wollte ich auch mal wissen, was fr interne Signale durch diese
neuen Demoprogramme verndert werden, wie also die Hardware durch die
Software ausgetrickst wird!

Gesagt, getan!

Nur mit einem Schaltplan vom ST und einem Osziloskop bewaffnet und 
mit Hilfe derneuen Demos durchforstete ich mit dem Tastkopf erst 
einmal die Shiftergegend und stellte auf einmal fest, da sich z.B. 
beim Hin- und Herschaltendes Amigademos zwischen "Hyperscreenmode" 
und Normal-Mode das DE (Display-Enable)-Signal nderte.

Das mute es sein!

Das Display Enable Signal ist also zustndig fr das Darstellen von
Pixelgrafik in einer Video- (Display-)Zeile.
Immer wenn es auf "High" steht wird Pixelgrafik vom Shifter ausgegeben,
geht es auf "Low", dann wird nur noch die Hintergrundfarbe dargestellt.

Die TEX- und TNT-Programmierer hatten es also geschafft, das High-Low
(Puls-Pausen-)Verhltnis von diesem Signal zu ndern, so da in jeder
Videozeile das DE-Signal lnger und schon eher(LT-PRG) auf High steht,
so da jede Zeile mehr Pixelgrafik als die normalen 320 bzw. 640 Pixel
ausgibt.

Das Display-Enable Signal wird, wie auch die anderen zum Fersehbildaufbau
bentigten Signale (Blank, HSync, VSync), vom Kleisterbaustein (GLUE)
erzeugt.
Es geht vom GLUE aus gleichzeitig zur MMU, zum Shifter und zum
Timer B-Eingang vom MFP-Baustein (zum Zhlen der Zeilen durch Interrupt).

Der Bildaufbau im Farbmodus bei 50 Hz spielt sich folgendermaen ab :

Mit dem vertikalen Synchron-Signal, das vom Glue nicht nur an die 
Monitorbuchse, sondern auch an die MMU geht, wird an die interne 
Zhlerkette inder MMU die Anfangsadresse des Bildschirmspeichers 
im Ram frs nchsteHalbbild (313 Zeilen) bergeben(Aus den +
Adressen FF8201 und FF8203geholt).
Wird das Display-Enable Signal jetzt High, so wird dadurch in der MMU das
DCYC(Display-Cycle-Clock) Signal wirksam, das aus dem Ram die 
Videodisplay-Informationen (Pixelgrafik) immer 16 bitweise in den Shifter transferiert
(clocked). (ber den Load-Eingang des Shifters)
Dabei wird die Zhlerkette in der MMU immer weiter hoch gezhlt.(wird im
Video- Adre-Zhler FF8205/07/09 registriert)
Bleibt das Display_Enable Signal jetzt lnger high, dann wird insgesammt
auch mehr Speicher von der MMU als Bildschirmspeicher adressiert und in
den Shifter als Pixelgrafik-Display bergeben.
Das CMPCS-Signal (Color map chip select), das auch von der MMU generiert
wird und zum Shifter an den CS(Chip Select)-Eingang gefhrt wird, ndert
sich brigens nur, wenn die Farbpalettenregister im Shifter mit neuen
Werten geladen werden sollen.
Schlielich tastet das vom GLUE generierte BLANK-Signal das vom
RGB-Widerstands-D/A-Netzwerk kommende Farbsignal in den horizontalen
Rcklufen jeder Zeile und in den ganzen 29 Zeilen des vertikalen
Bildsynchronimpulses aus (dunkel).

Die softwaremigen Tricks arbeiten nun so, da durch interruptgesteuerte
Umschaltung der Bildfrequenz in bestimmten Fernsehzeilen, das vom GLUE
erzeugte DE-Signal lnger auf "high" in einer Zeile steht. Dieses Ergebnis
kann man natrlich auch dadurch erreichen, da man statt dem DE-Signal ein
anderes Signal zur MMU und zum Shifter fhrt und zwar solch ein Signal,
da bereits das geeignete Puls-Pausen-Verhltnis besitzt.
Dann braucht man nicht mehr die rechenzeitintensiven 
Synchronisationstricks per Software und man kann sogar mit der neuen 
Hyperscreen-Auflsungunter GEM arbeiten!

Nun mute nur noch ein entsprechendes Signal im Rechner gefunden werden,
da ein geeignetes Puls-Pausen-Verhltnis aufwies, um es als neues
DE-Signal verwendet werden zu knnen.

Ich durchtrennte also auf der Rechnerplatine die Verbindung, die die MMU
und den Shifter mit dem normalen DE-Signal versorgt (siehe Bilder 1,2 und
6) und legte an diese alten DE-Eingnge(Pin 52 der MMU und Pin 37 des
Shifters) erst einmal nur "high"-Pegel (+5 Volt).

Es klappte tatschlich!

Nach dem Einschalten des Rechners sah man im oberen Teil des Bildschirms,
ungefhr bis zur Hlfte des Bildschirms wild verteilte bunte Pixels von
links nach rechts herber, jetzt aber ohne strenden Rand.

Im unteren Bereich aber erschienen merkwrdige sechszehner Pixelgruppen,
die dauernd ihre Farben wechselten.
Ich dachte erst, dieser untere Bereich wrde fehlerhaft dargestellt, bis
mich dann Karsten auf die Idee brachte, das knnten doch die Datenbus~
signale seien!Richtig!
Der 1 MByte ST plaziert ja beim Einschalten seinen Bildschirmspeicher
ganz am oberen Ende des Speicherraums.
Mit dem Umbau braucht er nun ja mehr Bildschirm- Speicher zum Auslesen, da
am oberen Ende aber nur 32 KBytes vorhanden sind, werden nach diesen 32
KBytes nur noch undefinierte Datenbussignale auf dem Monitor ausgegeben.

Na also: Nach Herunterlegen der Bildschirm-Speicher-Anfangs-Adresse
in den Speicherzellen FF8201 und FF8203 war von diesen wild umhertanzenden
Datenbussignalen nichts mehr zu sehen und der ganze Bildschirm war nun mit
Pixelgrafik gefllt!!!

Allerdings konnte man natrlich nicht mehr das Desktop sehen, da mit der
neuen Bildschirmspeicheranordnung nicht mehr dieselben Pixels wie vorher
bereinanderlagen und darum also nur bunte Pixels ber den ganzen
Bildschirm verteilt zu erkennen waren. (durch andere Aufteilung der
Bitplanes)
Wir versuchten daher erst einmal das alte RAM_TOS von 1985 zu patchen, um
wieder unter GEM jetzt mit Hyperscreen zu arbeiten.
Fr die Anpassung des GEMs auf der alten Ram-TOS Diskette gab es dann aber
eine Schwierigkeit: die einzelnen Fersehzeilen durften nur maximal 255
Bytes Bildschirmspeicher besitzen und die Anzahl der Bytes mute durch 4
teilbar sein, damit man das vernderte GEM in den beiden Auflsungen der
Farbmodi installieren konnte. (Die Beschrnkung auf die 255 Bytes pro
Zeile gilt brigens fr das neue TOS 1.4 nicht mehr!)

Da dies mit der simplen Lsung des einfach auf "high" legen der beiden
Eingnge nicht zutrifft und dadurch auch im horizontalen Zeilenrcklauf
zuviele Pixels ausgegeben wurden, die man aber durch das Austasten des
Blank-Signals gar nicht auf dem Monitor sah (Speicherplatzverschwendung),
mute also ein besseres Signal gefunden werden!
Nach Experimentieren mit dem HSync-Signal (kein einwandfreier 60 Hz-
Betrieb mglich), dem Blank-Signal (es bleibt noch ein kleiner linker Rand
sichtbar, 60 Hertz mit "zerfranstem" linken Rand) und dem VSync-Signal
(zuviele Bytes im Zeilenrcklauf = Speicherplatzverschwendung), wurde
schlielich das gemischte Synchronsignal ( Composite Sync, das aus einer
UND-Verknpfung von HSync und VSync besteht) gefunden, das die
Anforderungen erfllt.

Leider kann es nur auf die beiden oben besprochenen Eingnge (alte
DE-Eingnge von Shifter und MMU) gelegt werden. Legt man das
Synchronsignal auch auf den Timer B-Eingang vom MFP 68901 (Pin 20), wo das
normale DE-Signal auch anliegt, dann kann der ST nicht mehr nach einem
Reset oder nach dem Einschalten booten.
Das liegt wahrscheinlich an den Initialisierungsroutinen im Rom-Tos, da
der ST beim Starten auf 60 Hz anfngt und dann vielleicht zuviele
Interrupts ber den Timer B bekommt.
Das strt aber auch nicht weiter, denn man kann ja auch durch den HBL-
Interrupt die Zeilen zhlen, um z.B. nach jeder Zeile die Farbpaletten
umzuladen und damit in jeder Zeile 16 neue Farben anzeigen zu knnen.
(Fr spezielle Farbvideoeffekte)

                      Der Betrieb des OVERSCAN-Mode

Man kann problemlos whrend des Betriebs des STs zwischen den Modi
umschalten, ohne da der Rechner abstrzt. Es kann lediglich ab und zu
vorkommen, da beim Umschalten, bedingt durch Prellen des Schalters, die
Farbpaletten verschoben sind. Das lt sich aber durch nochmaliges Hin-
und Herschalten wieder beheben.
Man mu natrlich nach dem Umschalten von Normal-Mode auf Hyperscreen eine
entsprechende Software einsetzen, damit man nicht nur "Pixel-Mll" auf
dem Bildschirm sieht (wie schon oben erwhnt, liegen die Bitplanes im
Hyperscreen-Mode anders bereinander ).
Daher hat Karsten das Hyperscreen.PRG geschrieben, das im Auto-Ordner der
Harddisk oder Bootdisk steht und beim Hochfahren des Rechners das GEM mit
den negativen Line A-Variablen so patcht, da man auch mit den neuen
Auflsungen mit der gewohnten GEM Shell arbeiten kann.
Es luft allerdings nur mit dem Blitter-ROMTOS, dem neuen ROMTOS 1.4,
dem BETA-RAMTOS und dem Developer-RAMTOS 1.4 .
Es funktioniert nicht mit dem alten 1985er ROMTOS!!!

Beim Hochfahren des Rechners kann es manchmal zu Farbpalettenverschiebung
kommen. Das tritt aber nur sehr selten auf und auch nur beim Einschalten
des Rechners, so da man dann durch nochmaliges Hin- und Herschalten
wieder die richtige Farbpalette einstellen kann. Ist der Rechner erst
einmal richtig gestartet, so bringt ihn nichts mehr durcheinander.
(Einzige Ausnahme: Hin- und Herschalten zwischen 50 und 60 Hertz mit dem
"ChangeHertz.PRG"; man mu sich aber unter OVERSCAN wegen der unterschied~
lichen Bildgren sowieso fr eine bestimmte Bildfrequenz im Farbmodus
entscheiden und das wird hier in Europa 50 Hertz sein, da man ja etwas auf
Video aufnehmen mchte)

Ab der Version 1.5 vom Hyperscreen.PRG kann man durch Drcken der Control
Taste beim Hochfahren des Programms in ein Installationsmen gelangen, bei
dem man dann softwaremig, unabhngig von der durch den Umbau vor~
gegebenen neuen Hardwareauflsung, die Auflsung einstellen und abspeichern
kann.
Denn bei einem werksmig eingestellten Fernseher gehen einige von den 284
Zeilen oben und unten als Anzeigeflche verloren, da diese schon hinter
dem Bildrhrenrahmen verschwinden und auch in der Breite ist der Fernseher
so eingestellt, da die ganz links und rechts liegenden Punkte nicht mehr
zu sehen sind.
Durch das Installationsmen kann man also die neue Hyperscreen-Bildschirm~
gre begrenzen und an seinen eigenen Monitor anpassen, so da man noch
alles sieht oder aber auch den Screen so gro einstellen, da erst der
Bildrhrenrand die Begrenzung bildet.


Damit besteht aber auch die Mglichkeit, Objekte von allen Seiten vom Rand
der Bildrhre bis zum gegenberliegenden Rand laufen zu lassen, so da man
wirklich ein flchenfllendes Bild vor sich.
Gerade im Desktop-Video-Bereich sieht das dann richtig professionell aus
und nicht mehr nach Home-Computer!

Es kann dadurch aber auch sein, da Sie die Menleiste gar nicht mehr
sehen, weil sie jetzt zu weit oben liegt. Keine Angst, sie ist aber
trotzdem noch da.
Sie brauchen nur einmal mit der Maus ganz nach oben zu fahren und Sie
werden sehen, wie sich die Menleistenwindows nach unten aufklappen
werden!

Von nun an kann man dann mit einem ganz neuen Gefhl mit dem greren
Desktop arbeiten.


            Der Aufbau des Bildschirmspeichers beim Hyperscreen-Mode
            in den Farbmodi bei 50 Hertz (neue Hardwareauflsung,
               kann durch das Hyperscreen.PRG verndert werden!)

Wie schon oben erwhnt, bentigt der neue Hyperscreen-Bildschirmspeicher im
Farbmodus durch die Hardware-Modifizierung 67024 Bytes. Davon sind aller~
dings nur maximal 59640 Bytes sichtbar (also 840*284 oder 420*284 Punkte;
Mid- bzw. Low-Resolution-Modus).
Woher kommen nun aber die 7384 Bytes Differenz zwischen dem sichtbaren
(beim optimal eingestellten Monitor) und dem wirklich gebrauchten
Bildschirm-Speicher ?
Das liegt daran, da durch das Composite Synchron-Signal in der
horizontalen Austastlcke noch in jeder Fernsehzeile 26 Bytes dargestellt
werden, die aber durch das Blank-Signal ausgetastet werden und damit nicht
sichtbar sind.
Das horizontale Austastsignal in dem Composite Synchron-Signal ist nmlich
krzer als das des Blank-Signals. Folglich werden auch noch im Anfang des
Rcklaufs in jeder Zeile Pixel zum Shifter aus dem RAM bertragen.
Das strt aber weiter nicht, da man sie nicht sieht und diese ca. 7KBytes
ja auch nicht unbedingt bei Bildern auf Diskette mit abgespeichert werden
mssen.
Beim Auslesen und Einschreiben von Daten vom oder in den Bildschirm~
speicher mssen dann eben 26 Bytes in jeder Zeile bersprungen werden!
Wenn es auf diese berschssigen ca. 7 kBytes nicht ankommt, kann man aus
Geschwindigkeitsgrnden diese ja auch mit abspeichern. Das ist von der
Software-Seite aus gesehen auch einfacher und auerdem kann man dort ja
noch prima Zusatzinformationen zum Bild speichern, wie z.B.
Farbpaletten oder Texthinweise etc.

Eine Fersehzeile besteht im Hyperscreen-Mode bei 50 Hz Bildfrequenz jetzt
also aus 236 Bytes. (Bei 60 Hz sind es nur 234 Bytes)
210 Bytes sind sichtbar. Das macht im Midres-Modus 840 Pixel, im
Lowres 420 Punkte.
Bei 284 Zeilen sind das dann 284 * 236 Bytes(210 Bytes) = 67024 Bytes
(59640 Bytes).

Eine zweite Sache mu auch noch erwhnt werden, die bei der Lsung mit dem
Composite-Synchron-Signal noch nicht so ganz perfekt ist:

Da die vertikale Austastlcke im Composite Synchron-Signal sehr viel
krzer als im Blank-Signal ist, werden auch schon im vertikalen Strahlen~
rcklauf Pixel ausgegeben. (die DE-Eingnge sind dann durch das Composite
Synchron-Signal schon wieder auf "high" geschaltet)
Diese Pixel sind wiederum durch das Austasten des Blank-Signals nicht
sichtbar.
Dadurch ergibt sich aber ein Offset von 5876 Bytes, so da in den Adressen
FF8201 und FF8203 (Bildschirmspeicheranfang) eine, um diese 5876 Bytes
verringerte Anfangsadresse, geschrieben werden mu.
Dabei setzt man mit diesen 2 Adressen allerdings den Bildschirmspeicher
nur auf eine 256 Bytes genaue Anfangsadresse ( nur High- und Mid-Byte kann
im Video.bas-Register gesetzt werden), die Feinpositionierung geschieht
dann im Hyperscreen.PRG.

Eine bersicht ber die Hyperscreen-Bildschirmspeicher-Aufteilung, wie sie
durch das neue Composite-Sync-Signal erzeugt wird, zeigt Bild 7.

Man htte sich allerdings auch mit Hilfe einiger Flip-Flops und Zhler~
bausteine ein besseres Signal, als das Composite-Synchron-Signal als neues
DE-Signal zusammen setzen knnen, dann wre der Umbau aber gleich viel
komplizierter geworden und die Akzeptanz unter den Usern und
Programmierern wre gesunken.
Denn statt dem Einbau eines einfachen Umschalters, htte nun eine Platine
bestckt und eingebaut werden mssen. Ferner wre das auch mit einigen
Mehrkosten verbunden gewesen.

Auerdem sehe ich die Anwendung sowieso eher in solchen erweiterten
Programmen, wie z.B. der Cyber-Studio-Serie, die ihre eigenen schnellen
Zeichenroutinen besitzen,so da es nun mit dem CAD-3D-PRG und einem
angepaten Cyberpaint mglich wre, Objekte wie beim Amiga ber den ganzen
Bildschirm fliegen zu lassen.
Mit diesen schon jetzt sehr fhigen Programmen, knnte man dann richtig
professionell aussehende Computeranimationen erstellen. (ohne strenden
Rand)

Hiermit seien also Tom Hudson und Jim Kent aufgerufen, ihre tollen
Programme mglichst schnell an den neuen Hyperscreen-Modus anzupassen.

Wre dann noch ein Zusatzprogramm vorhanden, das Deltaanimationen
kontinuierlich von einer Harddisk in Realtime nachladen und gleichzeitig
abspielen wrde, dann ist es nicht schwer, sich vorzustellen, was fr
eindrucksvolle Filme man z.B. mit einer 100 MByte Harddisk realisieren
knnte!
Wre das Animationsprogramm dann noch ber Midi-Clock und Song-Position-
Pointer mit einem Musiksequenzer (z.B. einem zweiten Atari ST)
synchronisierbar, dann stnde einer Realtime-Multimedia-Show nichts
mehr im Wege.


Hier sollen nun noch ein paar grundstzliche Bemerkungen
ber den Unterschied von 50 und 60 Hertz Betrieb im neuen Hyperscreen-Modus
erfolgen :
Die Hardwarenderung mit dem Composite-Synchron-Signal lt auch einen 60
Hertz Betrieb zu, allerdings keine GEM-SHELL, da 234 Bytes pro Fernsehzei~
le nicht ganzzahlig durch 4 teilbar ist. Man kann sich aber seine eigenen
Applikationen programmieren , die dann die Farbpaletten in jeder Zeile
richtig setzen und somit z.B. auch ein Konvertierungs-Programm von
Hyperscreen-Bildern von 50 auf 60 Hertz schreiben.
Im Augenblick ist das Hyperscreen.PRG nur auf 50 Hertz-Betrieb
im Farbmodus eingestellt.
Das hat folgenden Grund : Im 60 Hertz Betrieb werden vom Atari im Hyperscreen-
Modus hardwarebedingt nur 238 sichtbare Zeilen dargestellt und 25 Zeilen
im Bildrcklauf ausgetastet. Das ergibt dann die 263 Zeilen fr ein
Halbbild im NTSC-System (amerikanische Fernsehnorm).
Auerdem stimmt die dargestellte Bytezahl in einer Fernsehzeile nicht mit
dem 50 Hertz-Modus berein (statt 236 Bytes nur 234), so da das Desktop~
bild wegen der dann nicht mehr bereinanderliegenden Bitplanes
verzerrt dargestellt wrde.
hnlich ist es auch bei dem Farbmalprogramm "Spectrum 512", dessen 60
Hertz-Version mit 50 Hz betrachtet auch nur "Pixel-Mll" auf den Bild~
schirm bringt.

Die Hardwarenderung mit dem Composite-Synchron-Signal lt bei 60 Hertz
Betrieb dann allerdings keine GEM-SHELL zu, da 234 Bytes pro Fernsehzeile
nicht ganzzahlig durch 4 teilbar sind. Man kann sich aber seine eigenen
Applikationen programmieren , die bei 60 Hertz dann die Farbpaletten in
jeder Zeile richtig setzen und kann sich somit z.B. auch ein
Konvertierungs-Programm schreiben, das die Hyperscreen-Bilder von
50 auf 60 Hertz umrechnet.


Hier in Europa nehmen ja die Videorecorder auch nur Bilder im 50 Hertz
Betrieb auf, so da fr uns eigentlich erst einmal der 50 Hertz Betrieb
ausschlaggebend ist.

Allerdings wird sich genau wie beim Amiga, die Situation einstellen , da
Programme in 2 verschiedenen Versionen erscheinen werden, eine "PAL"- und
eine "NTSC"- Version.
Im PAL-Mode hat man dann 46 sichtbare Zeilen mehr fr die Bilder, mu aber
mit der Flimmerei des 50 Hertz-Betriebes kmpfen!

Es kann nur gehofft werden, da sich die europischen Vorschlge des
Eureka-High-Definition-TVs nicht durchsetzen werden, beim zuknftigen
hochauflsenden Fernsehen auch wieder 50 Hertz-Bildfrequenz einzufhren,
denn wer schon einmal lnger im 50 Hertz-Betrieb im Farbmodus programmiert
hat, wei ein Lied ber die rechteckigen Augen zu singen.
60 Hertz Bildwechselfrequenz sind einfach viel ruhiger.
Wird aber doch HDTV wieder mit 50 Hertz bei uns eingefhrt, so werden sich
die zuknftigen Farbgrafikcomputer auch wieder daran halten mssen,um z.B.
Grafikanimationen auf HDTV-Video aufnehmen zu knnen. So hat man beim
Programmieren wieder das Flackern vor den Augen!
Da aber eine neue Fernsehnorm bestimmt ber 20 Jahre bestehen bleibt, kann
man nur hoffen, da das nicht passieren wird!
Bei einer einheitlichen Weltfernsehnorm mit 60 Hertz Bildfrequenz knnte
man endlich auch einmal Videocassetten mit Freunden z.B. aus der USA aus~
tauschen, ohne die umstndliche und mit immensen Kosten verbundene Normen~
konvertierung.
(was beim Telefon (die einheitliche Norm) geschafft wurde, mte doch auch
beim Fernsehen gehen)

Technisch gesehen und ohne finanzielle Mehrkosten ist der 60 Hertz Betrieb
auch bei uns in Europa berhaupt kein Problem mehr, denn die meisten
bestehenden Fernseher lassen sich z.B. ber die Scart-Buchse als bergangs~
lsung auch einwandfrei mit 60 Hertz Bildfrequenz betreiben, wie man es ja
mit Hilfe des Ataris ganz leicht zeigen kann!
Anscheinend haben das aber die Eureka_HDTV-Freaks noch nicht so ganz
mitbekommen.

            Hyperscreen- (Hyperscreen-) Betrieb im Monochrome Modus

Wenn man im S/W-Modus bei umgelegtem Hyperscreen-Schalter den Rechner ein~
schaltet, fallen einem sofort zuerst die weien Rcklaufstrahlen des SM
124 Monitors auf, die auer dem "Pixelmll" des Datenbusses (siehe oben)
auf dem Display  zu sehen sind.
Das liegt daran, da im S/W-Modus der SM124 Monitor kein Blank-Signal
geliefert bekommt, so da der ST sonst normalerweise selber durch ein
geeignetes Puls-Pausen-Verhltnis des DE-Signals fr die dunkle Austastung
des Rcklaufs des Elektronenstrahls sorgt.
Weil wir das aber gendert haben, sieht man nun aber auch die horizontalen
und vertikalen Rcklaufstrahlen.
Ende September 1988, als wir die erste Farbversion vom Hyperscreen-Modus ent~
wickelten, dachten wir, da mit dem Composite Sync Signal als DE-Signal
Ersatz der S/W-Modus nicht erweitert werden knne und wir begngten uns
mit der Farbversion.
Dann kam mir aber auf einmal Anfang Januar 1989 die Idee, einfach mal den
ganzen Bildschirmspeicherbereich auf Hex FF zu setzen: Und siehe da, der
ganze Bildschirm war schwarz, es waren auch keine Rcklaufstrahlen mehr
zu sehen!!!
Man konnte also durch auf $FF- Setzen der angezeigten Bytes, die schon im
Rcklauf-Strahl saen, diesen Teil der angezeigten Pixel "unsichtbar"
machen!
Mit diesem Trick konnte nun die eigentliche Hardwareausgabe von 800*500
Pixel durch das Composite Sync Signal, die der SM124 nicht verkraftet und
deshalb die Rnder als weie sichtbare Rcklaufstrahlen "klappt" und an~
zeigt, durch softwaremige Verkleinerung unterdrckt werden!
Durch das Installationsmen vom Hyperscreen.PRG (ab Version 1.5) hat sich ge~
zeigt, da ein guter werksmig eingestellter SM124 ca. 688*480 Pixel auf
diese Weise anzeigen kann.



Literatur :

1. Schaltplan Atari 520 ST
2. Data Becker: Atari ST Intern
3. Technische Mitteilungen: Hardwareinformation Nr. 4
Steckerbelegung der Monitorausgnge (Composite Sync-
Nachrstung) ; Atari Corp., Raunheim
4."Auer Rand und Band mit Hyperscreen", 
Artikels im Mai und Juni 1989 Heft vom ST68000-Magazin, 
Markt
 und Technik Verlag


Berlin, den 30.6.1989 (C) COPYRIGHT 1988,1989 und 1990 by Stefan Hartmann











Stefan Hartmann
Electronic Research and Development
Keplerstrasse 11 B
1000 Berlin 10
West-Germany
Tel. und BTX : 030 / 344 23 66
e-mail on Compuserve-ID: 72017,3216

Projekt des Monats:
Hyperscreen (Hyperscreen) fr 3 DM

Bauanleitung und Erklrung der Funktionsweise eines
"xtended graphics mode" fr die Atari ST Computer

von Stefan Hartmann (Hardware und Artikel) und
Karsten Isakovic (Softwareprogrammierung)


