Hallo Besucher, der Thread wurde 2k mal aufgerufen und enthält 8 Antworten

letzter Beitrag von Jogi am

Welche Video-Modes können ST und STE?

    Hallo,


    ich beschäftige mich ein wenig mit ST und STE und habe bisher nicht viel über die Video-Modes gefunden. Es gibt wohl ein Bit, das zwischen PAL und NTSC umschaltet, aber selbst das 1500-Seiten-"Profibuch" schweigt sich über Details aus wie "Zeilen pro Screen" und "Pixel pro Zeile". Klar dass diese Werte zwischen low-, mid- und Hires unterschiedlich sind. Aber sind die PAL/NTSC-Modes nur single-frame wie beim C64, oder kann man auch interlace einschalten?


    Meine Hauptfrage ist, ob man auch andere Screenmodes darstellen kann, ähnlich wie beim Amiga, wo Zeilenlänge und Anzahl Zeilen nach einem VBlank in Grenzen, jedoch sehr frei programmierbar sind.


    danke,
    Jens

    Moin Jens,


    Zitat von Wiesel

    Aber sind die PAL/NTSC-Modes nur single-frame wie beim C64, oder kann man auch interlace einschalten?
    Meine Hauptfrage ist, ob man auch andere Screenmodes darstellen kann, ähnlich wie beim Amiga, wo Zeilenlänge und Anzahl Zeilen nach einem VBlank in Grenzen, jedoch sehr frei programmierbar sind.


    Der ST ist deutluch unflexibler als der Amiga (ich meine sogar als Atari 8-Bit, aber das lassen wir mal außen vor...) in den Videomodes. Der ST hat im Grunde genommen keinen echten Videoprozessor, denn der Shifter ist letztlich nur ein D/A Wandler. Der eigentliche Bildaufbau wird durch den GLUE erzeugt (dieser generiert auch HSYNC, VSYNC und Blanking-Signale) und steuert wiederum die MMU. An der MMU ist das DRAM angekoppelt, die MMU wiederum "taktet" den Shifter über einen getrennten 16 Bit Datenbus zu den DRAMs und läßt den Shifter die darzustellenden Daten aus dem DRAM auslesen.


    Suche mal im Netz nach Overscan ST. Das war eine kleine Hardware-Erweiterung (im Prinzip nur ein GAL), die den GLUE ein wenig austrickst und eine größere Auflösung ermöglicht. Diese ehemals kommerzielle Lösung wurde von den Autoren freigeheben, im Archiv sind auch technische Details zum Videoaufbau enthalten.


    Gruß, Jürgen

    Der ST/STE liefert immer ein PAL-Videosgnal im Farbmodus. Es ist identisch egal ob man ST-LOW (320x200) oder ST-MED (640x200) Auflösung auswählt. Das einzige was man umschalten kann, ist die Bildwiederholfrequenz, sie ist wie du erkannt hast, 50 oder 60 Hz. Dafür gibts Programme, die man in den AUTO-Ordner legt (changehz.prg, 5060hz.prg), die bei jedem Aufruf auf jeweils die andere Frequenz umschalten, oder man macht das in seiner Anwendung/Spiel/Demo/... selber.


    Die Auflösung 320x200 oder 640x200 bezieht sich immer nur auf die offiziell ansteuerbaren Pixel innerhalb des Bildschirmrahmens. Der Rahmen ist aber mit Tricks durch geschicktes kurzzeitiges Switchen der Videosmodis verwirren) auch nutzbar, wie viele Szenedemos eindrucksvoll zeigen. Wahrscheinlich ist es 720 × 576 interlaced 50/60 Hz mit 35 kHz Zeilenfrequenz. Wieviele Pixel davon mit Overscan-Tricks benutzt werden können, weiß ich nicht mehr genau, 720x288 ist aber wahrscheinlich (beide Halbzeilen sind identisch).


    Das Farb-Videosignal sollte weitestgehend identisch zu dem vom Amiga sein, das Timig kann sich durch den verschiedenen Grundtakt des Systems (7,15909 Mhz Amiga NTSC, 7,09379 Amiga PAL, 8 MHz ST PAL und NTSC) minimal unterscheiden.



    Im Monochrom-Modus, der normalerweise nur eingeschaltet wird, wenn das Mono-Detect-Signal am Videoanschluss auf Low geschaltet wird, siehts wieder ganz anders aus. Aber auch da wird mit Bildschirmrand gearbeitet (wohl weil man die Qualität der Monitor-Zulieferer (LG und weitere ...) nicht so steuern konnte). Die offizielle Auflösung ist 640x400 mit Rand drumherum, aber das eigentliche Monochrom-Videosignal ist 720x576 Pixel groß, noninterladed, 70 Hz (es sind exakt 70 Hz, auch wenn man öftes 71 oder 72 Hz ließt), was mit Hardware wie AutoSwitchOverscan (raffinierte Shifter-Verwirr-Hardware) komplet bepixelt werden kann.



    Hast du die Seiten 828ff im Profibuch gesehen? Wenn das zu wenig ist, musst du mal ins atari-home.de rüber kommen.

    Zitat von 1ST1

    An der Hardware (Videotiming: Pixeltakt, H-Sync, V-Sync) ändert das aber nichts, Denise wählt nur aufgrund dieser Register andere Betriebsmodis

    Der Amiga kann sehr wohl die HSync/VSync Frequenzen ändern. Es gibt Register in denen steht, wie viele CCK-Takte eine Zeile haben soll, und mit der Copperliste wird festgelegt, wann der nächste VSync kommt. Auch wenn der OCS-Agnus nach oben hin Grenzen hat, kann schon der die Vertikalfrequenz mit dem entsprechenden Copper-Code erhöhen.


    Ich würde von Dir auch gern mehr über den ST lesen - nicht über den Amiga, über den Du ganz offensichtlich nicht genug Kenntnisse hast - nicht Denise legt das Video-Timing fest, sondern Agnus. Denise ist nur ein Haufen Schieberegister und die Farbpalette, nebst mehr Schieberegistern für Sprites. Im Prinzip also ein "shifter", nur halt auf die DMA-Zugriffe von Agnus ausgelegt.


    Zitat von 1ST1

    Am Amiga gab es sowas - sprich auf der Kiste per Software was machen, was die Hardware eigentlich garnicht kann - eher nicht.

    Hust.. das hier soll kein Amiga vs. Atari-Thread werden, sondern soll mir die Frage beantworten, ob GLUE so programmiert werden kann, dass eine andere Anzahl Zeilen ausgegeben wird, oder dass eine Zeile verkürzt oder verlängert wird.


    Overscan durch Shifter-Übertaktung ist langweilig. OK, es hat einen schönen Nutzen wenn man den Monitor entsprechend einstellen kann, aber es ändert nichts an der Vertikal/Horizontalfrequenz. Außerdem ist das Ändern des Shifter-Taktes vermutlich nicht gut für den tatsächlichen PAL/NTSC-Ausgang, denn die Synchronisation zum H-Sync geht sehr wahrscheinlich verloren.


    Speaking of: Was mich beim Studium der Schaltpläne gewundert hat war, dass es dort einen signifikanten Unterschied zur Literatur gibt: Der Shifter-Basistakt ist eben *nicht* exakt 32MHz wie so oft zu lesen, sondern 32,04 oder 32,08, je nach PAL/NTSC Modell. Zwecks Synchronisation mit dem HSync gibt es eine recht aufwändige und vermutlich auch anfällige Schwingschaltung mit PLL-Funktion, die mindestens die Phase der 32,0xMHz-clock an den H-Sync anpasst. Das deutet darauf hin, dass die H-Sync Frequenz entweder gar nicht, oder nur in ganz engen Grenzen verändert werden kann. Und genau das interessiert mich - wie kann der HSync per Software beeinflusst werden?


    Jens

    Overscsan per Shifter-Übertaktung ist was anderes als AutoSwitchOverscan bzw. Software-Overscan, denn der Takt bleibt bei letzterem bei 8 Mhz. Es werden die Sync-Signale zwischen Shifter, Glue und MMU verändert, so dass der Shifter nicht mehr weiß, wo der Rand ist und einfach weiter malt. Da läuft im Shifter intern ein Zähler, der rückgesetzt wird, und das Zeilen-Anfang/Ende-Signal wird entweder vom GAL neu gesetzt, oder durch die Software, die an den richtigen Stellen von 50/60 Hz kurz auf 70 Hz umschaltet. Der Shifter kann aber nicht mehr oder weniger Zeilen (brutto), das ist beim Shifter fest vorgegeben. Software-Overscan bzw. AutoSwitchOverscan erhöhen nur die Netto-Auflösung in dem der Rand verkleinert wird, bis er schließlich 0 ist.


    Bei der Shifter-Übertaktung, wenn man z.B. den Systemtakt auf 10 oder 12 Mhz des ganzen Rechners anhebt, erhöht gleichzeitig den Pixeltakt, Zeilenanzahl und die Bildwiederholfrequenz. Dann wirds fies für den Monitor. Aus 50 hz werden 75 Hz, aus 70 Hz werden 105 Hz Bildwiederholfrequenz. Das geht werder mit einem PAL-Monitor noch mit einem SM-124, dazu braucht man dann einen guten Multiscanmonitor.


    Was die Zeilenanzahl beim Amiga angeht, am Ende kommt dennoch wieder ein sauberes PAL bzw. NTSC-Signal raus, denn sonst kann der 1081/1084 das nicht mehr darstellen. Die Frage ist nur, ist eine Pixelzeile so hoch wie eine Elektronenstrahl-Zeile, oder wie zwei oder drei, werden auf 10 mm Breite auf dem selben Monitor X oder Y Pixel angezeigt (Pixeltakt). Die Bild- und Zeilenfrequenz müssen aber gleich bleiben, denn sonnst fängt der PAL/NTSC-monitor an zu fiepen.

    Zitat von 1ST1

    Ja so in der Art, wbei ich nicht weiß, wie das beim C64 geht. Beim ST hab ich das mal in Assembler hinbekommen, aber scheinbar so ineffektiv, dass kaum Rechenzeit für was anderes übrig blieb. :(

    Wahrscheinlich war es gar nicht so ineffektiv. Da man ja umschaltet, wenn der Rasterstrahl eine bestimmte Position bzw. Positionen erreicht hat, ist es eben ein Kniff , die "Wartezeit" dazwischen sinnvoll mit dem übrigen Code zu füllen ( inkl. Rechnerei, wieviel Taktzyklen bzw. "Rasterstrahlzeit" die jeweiligen Befehle verbrauchen... oh da werden Erinnerungen wach ). Wenn man da nichts tut ( weil man es nur mal ausprobieren will ), verbrät man halt die ganze Zeit nur mit warten bzw. Rechenzeitverplempern.