Was ist denn damit -> http://www.atari-forum.com/viewtopic.php?t=32445
Danke für den Link - der Mann hat den etwas komplexeren Ansatz, denn er bildet den Shifter nach. Auch wenn ich den Shifter nicht für sonderlich kompliziert halte, wäre das ein Level an Forschung, den ich nicht machen möchte. Die Daten kommen "auf dem Silbertablett" aus dem Shifter, und ich tendiere dazu, die Dinge einfach zu halten. Einen Schritt weiter als der Kollege aus "downunder" bin ich trotzdem schon: Meine Sync-Erkennung ist etwas aufwändiger, erkennt aber mehr als nur die Standard-Modes.
Außerdem nutzt der Australier eine FPGA-Generation, die etwas älter ist (Cyclone 2, EP2C5). Ich habe genau den gleichen auf meinem Produkt "Indivision AGA MK2" für den Amiga, und habe jetzt schon Schwierigkeiten bei der Beschaffung (das Design ist von 2011). Wenn ich was Neues für den ST mache, dann wird's auch ein FPGA einer neueren Generation.
Als letzten Unterschied plane ich, nicht nur einen Scandoubler zu bauen, sondern einen kompletten Framebuffer. Dafür klebe ich ein SD-Ram an den FPGA, und schreibe einfach die Pixeldaten "so wie sie sind" in diesen Puffer. Die Ausgabeseite kann dann asynchron laufen und auch bei 50Hz-Input einen schnelleren Output machen (60Hz oder mehr, je nach Config). So wird ausnahmslos *jeder* Monitor kompatibel, was ja Sinn der Übung sein soll. Die Methode ist "tried and true" mit meiner Produktreihe "Indivision" für alle Amiga-Modelle.
@gh-baden: Du hast vollkommen Recht, dass ein Fernseher auch non-interlaced Modes können muss. Der ST scheint aber (je nach Software) mit unterschiedlichen Zeilenlängen zu arbeiten, auch innerhalb eines Frames. Ich muss jetzt vorsichtig sein, weil ich (wie so oft geschrieben) kein ST-Experte bin, sondern nur C64 und Amiga sehr genau kenne. Ich glaube aber, dass einige Kenntnisse übertragbar sind: Democoder wollen in jedem Frame das gleiche Timing haben, und deswegen werden Timing-Tricks angewendet, um die Verschiebung von E-Clock zu V-Sync zu eliminieren. Diese Tricks haben aber zur Folge, dass simple Konverter-Chips mit analogem Eingang und HDMI-Ausgang zwar ihren Job machen, aber die Fernseher schlichtweg ihren Dienst verweigern, weil sie keinen Standard-Mode erkennen.
@czietz: Danke für die Infos - speziell dass "unbenutzte" Register keinen Bus error auslösen macht Hoffnung, dass man diese Register für die Kommunikation mit dem Framebuffer nutzen kann.
Ich gehe mal davon aus, dass in einem LOAD-cycle (Video-DMA) die fünf Adressleitungen ignoriert werden? Habe den Schaltplan nicht vor Augen, aber auf den Adressleitungen müsste doch der untere Teil der Videoadresse zu sehen sein, oder? Hier zeigt sich mal wieder meine Unwissenheit über das System. Auf dem Amiga ist es so, dass ein separater Register-Adressbus existiert, und bei einem DMA-Zugriff diese Registeradressen durch den DMA-Controller (Agnus) gesetzt werden. So weiß das Shifter-Äquivalent (im Amiga: "Denise"), für welche Bitplane die geschriebenen Daten gedacht sind. Inwiefern das auf den Shifter übertragbar ist, muss ich noch lernen.
@1ST1: Nein, ich werde natürlich NICHT genau das machen, was "Shadow" macht, denn Du schreibst ja selbst, dass der nur Monochrome ohne Overscan kann. Mein Ziel ist, dass jeder Video-Mode auf einem Standardmonitor darstellbar ist - also genau das, was Indivision AGA MK2 für Amigas mit AGA-Chipset macht: Egal was der Amiga ausgibt (auch 17Hz Vertikalfrequenz!), es wird auf einen Vesa-Mode umgesetzt. Vor Farbtiefe habe ich dabei überhaupt keine Angst, weil ich da schon 24 Bit verarbeite. Das ist alles nur eine Frage von Datenrate, und die ist mit einem SD-Ram kein Problem. Dual-Ported muss das auch nicht auf Hardwareseite sein, denn mit den Fifos im FPGA kann man das wunderbar entkoppeln. Und nein, Lag (Verzögerung des Ausgabebildes) ist an der Stelle kaum spürbar, das ist seit 2008 bewiesen (da ist die erste Version von Indivision AGA erschienen). Meist ist der Lag von Desktop-Monitoren noch heftiger als der von Indivision, aber selbst diese Kombi ist noch Turrican-tauglich. Und wen's trotzdem stört: Game-Mode am Monitor einschalten, dann ist der größte Teil des Lag schon weg.
Den STE habe ich ebenfalls im Blick, aber das wird "zweite Generation" (allein schon, weil der Adaptersockel, der in den PLCC84-Sockel geht, nicht leicht zu beschaffen ist). Das Schöne daran: Am "großen" Shifter fliegen auch Audiodaten vorbei, die ich mitschneiden kann. Die kann man gleich in den HDMI-Stream einbetten, und man hat eine komplett digitale Verbindung.
Jens
