Wie sind diese Grenzen? Kann man GLUE "frei" programmieren? Kann ein echtes Interlace mit Zeilensprung programmiert werden, oder ist das C64-ähnlich "flimmernd", aber auf dem gleichen Halbbild?
Kann man GLUE "frei" programmieren? Kann ein echtes Interlace mit Zeilensprung programmiert werden, oder ist das C64-ähnlich "flimmernd", aber auf dem gleichen Halbbild?
Der GLUE-Chip ist überhaupt nicht programmierbar. Man kann die von Atari vorgesehenen Videomodi: ST LOW (320 x 200 x 4 Planes), ST MID (640 x 200 x 2 Planes) und ST HIGH (640 x 400 x 1 Plane) verwenden, das war's. Interlace ist dabei (glücklicherweise, weil das wahrscheinlich dazu beigetragen hat, daß ich heute noch recht gut sehe ;) ) nicht vorgesehen.
Hardware […]
Vielen Dank - da sind schon ein paar Hinweise bei, die ich verwerten kann. Sind denn die genauen Frequenzen bekannt, die für H/V-Sync generiert werden? Ich meine *exakt* auf ein paar Nachkommastellen. Die Angabe von 50/60/70Hz für V-Sync ist mir natürlich geläufig. Interessant wäre "wie viele Pixel pro Zeile" und "wie viele Zeilen pro Frame".
Ach darum gehts? Warum so kompliziert, wenns auch einfach geht?
Beim Studium des Schaltplanes ist mir aufgefallen, dass der 32,0xMHz-Takt am H-Sync synchronisiert wird. Die Schaltung sieht für mich als "im wesentlichen digital" denkenden Menschen etwas abenteuerlich aus (bei Kapazitätsdioden werde ich etwas unsicher...), aber genau in die Richtung geht auch meine Frage: Scheinbar ist die Schaltung dafür da, um ein festes Phasenverhältnis zwischen Master-Clock und H-Sync herzustellen. Das kann natürlich nur in engen Grenzen gehen, die für den HSync gelten.
Die Angabe von 50/60/70Hz für V-Sync ist mir natürlich geläufig. Interessant wäre "wie viele Pixel pro Zeile" und "wie viele Zeilen pro Frame".
Hardware […]
Etwas Lesestoff, wie das ging:
https://groups.google.com/forum/#!topic/comp.sys.atari.st/fbUqsmrg31o
Leider fand ich den Originalartikel zu Hyperscreen auf stcarchiv.de nicht, das wäre besser.
Mein Ziel wäre vielmehr, einen HDMI-Fernseher der untersten Preisklasse anzuschließen.
Ich denke, Du verstehst die Schaltung ohnehin falsch. Erst einmal solltest Du wissen, dass diese Schaltung (im Prinzip eine PLL) nur in STs mit Modulator eingebaut ist. Ihr Zweck ist es, den Systemtakt auf ein festes Phasenverhältnis zur Farbträgerfrequenz (von einem separaten Quarz erzeugt), also ca. 4,43 MHz bei PAL, ca. 3,58 MHz bei NTSC, zu bringen.
Also das wird so direkt nicht gehen, aber eventuell mit einem VGA->HDMI Adapter.VGA zu HDMI wird so nicht gehen, weil es keine Vesa-Spec für Screenmodes <60Hz gibt. Die meisten VGA->DVI oder HDMI Konverter machen sofort Ärger, wenn's auch nur das kleinste Bisschen vom Standard abweicht.
Allerdings hab ich keine Ahnung wie genau da die Angaben sind.
HDMI ist halt rein digital und die Atari ausgänge sind analog, das wird ohne Umsetzer nicht funktionieren, vermute ich.Das vermute ich nicht nur, sondern es ist mir absolut klar. Und mein Ziel ist es, genau so einen Umsetzer zu bauen: A/D Konverter, TMDS-Encoder, Audio-AD Wandlung, ebenfalls ind en TMDS-Encoder, das *sollte* alles ohne Framebuffer möglich sein.
Mein Ziel wäre vielmehr, einen HDMI-Fernseher der untersten Preisklasse anzuschließen.Hallo Jens!
Im nicht-modulierten Signal ist das natürlich nicht vorhanden, daher hat Atari die Schaltung nur in Rechner mit HF-Modulator eingesetzt.
Burkhard Mankel: Jens schreibt doch, dass er so einen Umsetzer Atari=>HDMI selbst bauen will. Ich denke, Du musst ihm das nicht erklären!Und eben das stelle ich mir zimlich schwierig - ja für sauberes Bild nahezu unmöglich - vor!
... ich bin der Neue hier. ...... vermutet, daß Du eher unerfahren an die Marterie willst und insofern meine Ideen gepostet, nach denen ich auch schon verschiedene Monitore adaptiert habe!
Ich würde mir wünschen, der Koverter ist eine Box (also nix im Stecker integriert, vorne ein oder mehrere gleich beschaltete Videoeingänge, hinten HDMI Ausgang. Für die Eingänge gibts dann verschiedene, evtl. auch leicht selbst herzustellende (für Exoten!) Adapterkabel für die verschiedenen Systeme. Super wäre auch, wenn ST-Hoch unterstützt wird.Ich stelle mir vor, daß es kaum was Anderes als eine externe BOX werden kann. Internes könnte den sowieso recht schwachen GLUE am ehesten zerreißen! Nicht selten habe ich über Defekte an diesem Bauteil was zu lesen bekommen und sogar Artikel vor Augen gehabt, in denen man den mit GALs oder PALs nachzubilden versuchte!
Du dürftest auf diesem Sektor Genie^10 seinNa wenn das mal nicht zu viele Vorschusslorbeeren sind.
Ich stelle mir vor, daß es kaum was Anderes als eine externe BOX werden kann.Es könnte auch sehr gut etwas werden, was zwischen Mainboard und Shifter gesteckt wird: Da habe ich die Masterclock, Pixeldaten und das Blank-Signal, mit dem man (und da lehne ich mich jetzt mal etwas aus dem Fenster..) die Sync-Signale sicherlich herleiten kann. Blöd ist halt, dass es vom Shifter unterschiedliche Versionen in unterschiedlichen Bauformen gibt.
2. Man muss dafür ein Loch ins Gehäuse machen, um den HDMI rauszuführen. Das wird nicht jeden begeistern.
2. Man muss dafür ein Loch ins Gehäuse machen, um den HDMI rauszuführen. Das wird nicht jeden begeistern.
Muss man nicht, im Bereich des ROM-Ports bekommt man ein Flachbandkabel ganz gut rausgeführt.
Andere bauen Slimline-Floppylaufwerke ein, dann ist im Bereich des Floppyschachts auch Platz.
HDMI und Flachbandkabel? Ich weiß ja nicht...
nur wenige Fernseher können HDMI-Signale darstellen, die non-interlace sind,
Daher meine Frage: Da gehen 5 Adressleitungen in den 40-Pin Shifter, der folglich bis zu 32 Register hat, die sowohl per DMA, als auch per CPU beschrieben werden können. Gibt es dazu genauere Angaben?
Ich sehe in Register-Übersichten beispielsweise die recht unsinnige Angabe, dass der Shifter über die Adressen Bescheid wissen muss - was nicht der Fall sein kann, denn er adressiert nicht selbst (kann er mangels Adressleitungen gar nicht), so dass diese Register wohl im DMA-Controller verortet sein müssen.
Was ist denn damit -> http://www.atari-forum.com/viewtopic.php?t=32445Danke 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.
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?
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).
Falls Du irgendwann Interesse hast: ich habe eine Quelle für PLCC-Adapter, die in den Sockel gesteckt werden...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".
..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?
Wie es aussieht, muss ich aber auch ohne dass ich Speichererweiterungen baue einiges über den ST und seine Erweiterungen lernen, denn da scheint es zwei 4MB-Erweiterungen zu geben, die sich auf die MMU quetschen (und dabei den Sockel gewaltig ausleiern), und noch Signale vom Shifter holen.
Dieser von der MMU verwaltete Speicher wird ST-RAM genannt und ist universell einsetzbar, da für CPU, DMA, Shifter erreichbar. Außerdem kann er von allen TOS-Versionen ab 1.00 verwaltet werden und entsprechend von allen Anwendungen genutzt werden.
Nun kann man Speicher auch direkt am 68000 anschließen und in den sonst unbelegten Adressbereich zwischen 4 MB und 14 MB (10 MB beim MegaSTE) einblenden, wenn man entweder SRAM verwendet (Lösung MonSTer) oder sich um das DRAM-Refresh selbst kümmert (Lösung Magnum ST). Dieses sogenannte Alternate-RAM (Alt-RAM) kann aber nur mit TOS 2.06 verwaltet werden. Zudem kommen nicht alle Anwendungen damit klar, sei es, weil sie ihren Speicher auch für DMA-Transfers oder als Bildschirmspeicher nutzen wollen, sei es, weil sie einfach nicht erwarten, Zeiger auf Adressen größer 4 MB zu verwalten.
Wie Du siehst, gibt es zwei grundverschiedene Lösungen für Speichererweiterungen im ST, die beide ihre Vor- und Nachteile haben.
Hat noch niemand eine Erweiterung gebaut, bei der die MMU aus dem Sockel genommen wird, diese dann auf der Erweiterung in einen Sockel gesetzt wird und dann ein Adapter in den MMU-Sockel gesteckt wird?
Wo der Thread-Titel hier um Video-Modes geht, würde ich gern wissen, ob die CPU wirklich immer jeden zweiten Zyklus des ST-Ram bekommt, oder ob es Video-Modes gibt, die der CPU Zyklen klauen können?
Wo der Thread-Titel hier um Video-Modes geht, würde ich gern wissen, ob die CPU wirklich immer jeden zweiten Zyklus des ST-Ram bekommt, oder ob es Video-Modes gibt, die der CPU Zyklen klauen können?
Beim Amiga ist das abhängig von der Auflösung und Farbtiefe und kann so weit gehen, dass über die gesamte Bildschirmzeile kein Chipram-Zugriff für die CPU oder den Blitter möglich sind, weil die gesamte Speicherbandbreite für den Video-DMA benötigt wird. Gibt es solche Modes auch auf dem ST(E)?