Hardware > Hardware (Classic 16-/32-Bit)

Welche Video-Modes können ST und STE?

<< < (8/11) > >>

Gast120501:
Eigentlich müsstest du "nur" das machen, was "Shadow" in der STacy auch macht. Shadow in der STacy ist ein zweiter Videochip, der allerdings nur Monochrom funktioniert (weil STacy ein Monochrom-Display hat, im Farbmodus wird Shadow ausgeschaltet). Shadow ist zum Shifter parallel angeschlossen und ließt die Pixeldaten mit und leitet sie an das Display weiter. Shadow arbeitet aber mit festem Timig/Zähler für Zeilenlänge und Zeilenanzahl, Overscan kann der nicht, aber das Display hat ja auch nur 640x400 Pixel. Auch die Vampire-Leute haben mit "Parasite" eine ähnliche Lösung für Denise (der Videochip im Amiga) entwickelt, und wahrscheinlich ist jeder Flickerfixer für Amigas nichts anderes. Du musst also am Shifter die Pixeldaten auslesen und in ein Dual-ported RAM reinschreiben, was auf der anderen Seite von einem HDMI-Chip wieder ausgelesen wird. Damit bekommst du aber sofort auch eine Ausgabeverzögerung rein, die sich in Spielen negativ auswirken kann. Außer den Videodaten musst du aber auch die Register.Zugriffe auf den Shifter mitlesen und auswerten, um die Auflösung und die ganzen Overscan und Farbeffekte (Stichwort Speltrum 512) mitzubekommen und nachzubilden. Und nicht vergessen, der STE mehr Farben. Das wird nicht Ohne!

Paradroid:

--- Zitat von: Lukas Frank am Mi 16.05.2018, 18:03:41 ---Was ist denn damit ->    http://www.atari-forum.com/viewtopic.php?t=32445

--- Ende Zitat ---
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

czietz:

--- Zitat von: Paradroid am Do 17.05.2018, 09:40:48 ---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?

--- Ende Zitat ---

Nein. Die MMU "füttert" den Shifter direkt mit Daten aus dem RAM. Die Adresse, von der dazu gelesen wird, gelangt nicht auf den Adressbus und liegt damit nicht am Shifter an.


--- Zitat von: Paradroid am Do 17.05.2018, 09:40:48 ---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).

--- Ende Zitat ---

Falls Du irgendwann Interesse hast: ich habe eine Quelle für PLCC-Adapter, die in den Sockel gesteckt werden.

Arthur:
@Paradroid, ein wirklich sehr wichtiges Thema denn ich finde auch das HDMI genau der Adapter ist den die ST/E's unbedingt noch benötigen.

Paradroid:

--- Zitat von: czietz am Do 17.05.2018, 18:50:08 ---Falls Du irgendwann Interesse hast: ich habe eine Quelle für PLCC-Adapter, die in den Sockel gesteckt werden.

--- Ende Zitat ---
..und das ist *nicht* CAB, die noch die Isolierkörper im Lager haben und auf Anfrage für 'n Arm und 'n Bein die Pins da reindrücken würden? Dann hätte ich Interesse. Die Dinger von CAB sind nämlich längst nicht so gut, wie man sie gern hätte. Die Coplanarität der SMD-Pins ist unter aller Sau, es gibt keinen empfohlenen Footprint nach IPC und wenn man dort nachfragt heißt es nur, dass die Kunden "nie ein Problem hatten".

Ich habe selbst noch ein paar hundert von den Dingern im Lager, aber die gehen jetzt für eine 2MB-Chipram Erweiterung für Amigas drauf. Danach habe ich entweder die Wahl, selbst ein Spritzgusswerkzeug machen zu lassen, oder bei CAB den Gegenwert eines Mittelklasse-Jahreswagens zu lassen. In Anbetracht der massiven Nacharbeit, die wir mit den CAB-Dingern hatten, kann ich mir Besseres vorstellen. Also.. jens ät icomp .de freut sich über Deine Kontaktvermittlung.

danke,
Jens

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete