Hallo! Mir schwirrt da so eine Retro-Idee durch den Kopf: Der Bau einer (Logik-Baustein-diskreten) Grafikkarte für 8-Bit-Controller/Prozessoren. Sie soll ungefähr wie ein NES funktionieren, also extreme (konzeptuelle) Kompression zwecks geringem Datendurchsatz bzw. Speicherverbrauchs. Ich habe schon gewisse Vorstellungen zum Bau einer Tile-Hintergrund-Platine und auch schon einige Ideen für die (8 + X)Sprite-Platine. Jetzt das Problem: Durch die Kompression mittels (Block- und Pixel-) Paletten benötigt allein die Tile-Platine 3 bis 4 Speicherbausteine, und die müssen alle vom Mikrocontroller/Prozessor-Bus abkoppelbar sein und jeder Speicher muss einzeln/exklusiv an seinen Teil der Logik-Pipeline angekoppelt sein. Das bedeutet zig Umschaltlogik-Bausteine für die Speicherbusse usw. Die Tile-Platine kommt bestimmt auf 1000 Lötpunkten bei 50-70 Logikbausteinen oder gar mehr. Die Sprite-Platine wäre bestimmt ähnlich komplex. Dieses Projekt wäre bestimmt toll und würde den Retro-Bereich am Leben halten. Doch die Bastelei und vor allem Löterei der Riesenplatinen wäre vermutlich grausam. Was meint ihr ?
Ja, zieh das Ding durch. Wenn du fertig bist, kannst du hier ein Bild einstellen.
Halligalli schrieb: > Was meint ihr ? Keiner braucht sowas, und dann auch noch inkompatibel, so dass jede Software neu geschrieben werden müsste. ENTWEDER eine genial einfache neue Umsetzung "nur 10 Chips", ODER etwas kompatibles (als FPGA Realisation).
MaWin schrieb: > Halligalli schrieb: >> Was meint ihr ? > > Keiner braucht sowas Das ist der Grund, das zu machen. Ein bisschen Verrückt macht die interessantesten Dinge. Wahnsinn hat auch seine guten Seiten. ;)
Leroy M. schrieb: >> Keiner braucht sowas > > Das ist der Grund, das zu machen. > > Ein bisschen Verrückt macht die interessantesten Dinge. > Wahnsinn hat auch seine guten Seiten. ;) Und genau aus diesem verrückten Grund hab ich mal eine Elektrodampfmaschine gebaut, mit einem 24V-Hubmagneten aus einem Bundeswehrfahrzeug als Kolben mit Kolbenrückholfeder. Wenn man da einen Fahrraddynamo anschließen würde, käme höchstens nur noch ein Zehntel der Energie raus, die vorher reingegeben wurde. Eine Reflexlichtschranke mit Reflexnocke sorgt für den richtigen Impuls im richtigen Moment. Da das Bauen am meisten Spaß gemacht hat, kann ich nur sagen, setze Deine Retro-Idee auf jeden Fall um, und wenn es auch nur ein PC-Monitor in einem Röhrenradiogehäuse ist. Man lebt vermutlich nur einmal.
MaWin schrieb: > Halligalli schrieb: > Was meint ihr ? > > Keiner braucht sowas, und dann auch noch inkompatibel, so dass jede > Software neu geschrieben werden müsste. > > ENTWEDER eine genial einfache neue Umsetzung "nur 10 Chips", ODER etwas > kompatibles (als FPGA Realisation). Es geht nicht ums jeder braucht sowas. Das machen an sich ist das spannende. Ich bau mir gerade eine 4 Bit CPU nur aus Transistoren und Widerständen (und noch etwas Kleinkram drumrum, aber keine ICs). Just four fun. Die ALU habe ich schon, jetzt baue ich die Register und Steuereinheit. Bisher sind ca. 600 BC547 verbaut. Und leider 4 IC, der Multiplexer in der ALU. Die werden aber auch als nächstes auch rausfliegen.
Moin, > Mir schwirrt da so eine Retro-Idee durch den Kopf: > Der Bau einer (Logik-Baustein-diskreten) Grafikkarte für > 8-Bit-Controller/Prozessoren. Wenn du rein diskret, also mit 74er-Bausteinen arbeiten möchtest, bekommst du relativ zwingend ein Gattergrab. Davon abgesehen ist das eine durchaus interessante Idee mit Spaßfaktor. > Sie soll ungefähr wie ein NES funktionieren, also extreme > (konzeptuelle) Kompression zwecks geringem > Datendurchsatz bzw. Speicherverbrauchs. Kannst du machen, wobei 32 KB SRAM (ergibt 256x256x4) heutzutage kein Problem sind. Halligalli schrieb: > Durch die Kompression mittels (Block- und Pixel-) Paletten > benötigt allein die Tile-Platine 3 bis 4 Speicherbausteine, > und die müssen alle vom Mikrocontroller/Prozessor-Bus abkoppelbar > sein und jeder Speicher muss einzeln/exklusiv an seinen Teil > der Logik-Pipeline angekoppelt sein. Nein. Der Speicher muss nicht exklusiv an die GPU-Logik angebunden sein, denn er wird nur einen Teil der Zeit dort benötigt. Wenn du dein System mit starren Metazyklen arbeiten lässt, dann kannst du die Speicher zu geeigneten Zeiten fix für die CPU zugreifbar machen. Entweder, indem du die Speicherbusse umschaltbar an die CPU koppelst, oder indem du CPU-Zugriffe ebenfalls durch die GPU-Logik durchführen lässt. Arbitrationslogik (d.h. die CPU warten lassen, wenn der Zeitpunkt gerade ungünstig ist) brauchst du in beiden Fällen. > Dieses Projekt wäre bestimmt toll und würde den Retro-Bereich am Leben > halten. Doch die Bastelei und vor allem Löterei der Riesenplatinen wäre > vermutlich grausam. Was meint ihr ? Der Retro-Bereich bleibt auch ohne dich am Leben, und der Aufwand für so ein Projekt ist enorm. Wenn es dir das nicht wert ist, lass es sein oder passe dein Projekt an. Andernfall "go for it", es macht Spaß.
:
Bearbeitet durch User
Halligalli schrieb: > Doch die Bastelei und vor allem Löterei der Riesenplatinen wäre > vermutlich grausam. Was meint ihr ? Baue das Ding modular und mit SMD auf. Das vermeidet Riesenplatinen und einem Reflowofen ist es egal, wie viele Lötstellen auf der Platine vorhanden sind. IMO wurden auf der ersten CeBIT 1986 schon SMD-Bestückung und Reflow vorgestellt. Oder wie viele Jahrzehnte möchtest du mit deinem Projekt zurück gehen?
Hallo mach es, wenn es dir Spaß macht. Nicht alles, besonders im Hobby, muss sinnvoll sein. Wobei, was ist eigentlich sinnvoll? Wie sinnvoll ist eine Modelleisenbahn, eine Dampfmaschine im Jahr 2018, ein Kunstobjekt...? Allerdings sei nicht schockiert wenn du feststellen musst das der Spaß nicht ganz billig wird und die Begeisterung außerhalb der absoluten Nerd Szene sehr gering ist - mit einer Dampfmaschine, den meisten "Kunst" Projekten und alles was groß, laut und kraftvoll ist (Steampunk, Retromechanik...) wirst du mehr Begeisterung bei den "normalen" (LOL) Leuten erlangen - aber brauchst du das - ich denke mal: Nein Mach dein Ding, denk nicht über einige hundert Euro nach die du ausgeben wirst und zähle nicht die Stunden die das Projekt benötigen wird. Jemand
Und ich dachte hier geht es um wichtige Dinge wie ein Haus bauen, einen Baum pflanzen und Kinder in die Welt setzen? Danach kämen dann die Sachen wie die hiesige Politik und in der Firma das "Klima" beeinflussen und mal eine satte Spende an ein Kinderheim o.ä., aber wieder nur Spielkram? Wenn´s schö und Spaß macht?
Halligalli schrieb: > Der Bau einer (Logik-Baustein-diskreten) Grafikkarte für > 8-Bit-Controller/Prozessoren Retro ist ja recht, wenn es einen interessiert, aber war Grafik jemals diskret? Grafik-Chips gibt es fast so lange wie Prozessoren, ich habe schon in den 80er Jahren Grafik entwickelt mit NEC-Grafik-Prozessoren, die konnten schon in Hardware Kreise zeichnen. Auch C64, ZX81 usw. hatten mienes Wissens (ist ja ewig her) schon ordentlich integrierte Grafikchips. Es kann natürlich auch interessant sein, eine Vergangenheit zu rekonstruieren, die es garnie gab. So eine Art Tolkien-Elektronik. Georg
einen Grafikkontroller für 8bit Systeme gibt es noch heute zu kaufen. ilitek, solomon tech oder Raio bauen so was. Mit integrierter Beschleunigungsfunktion einfach mal das Datenblatt von RA8875 anschauen: https://cdn-shop.adafruit.com/datasheets/RA8875_DS_V19_Eng.pdf Seite 7 Adafruit Board bestellen, Treiber für Zielplattform schreiben, fertig. Gruß, dasrotemopped.
Halligalli schrieb: > Der Bau einer (Logik-Baustein-diskreten) Grafikkarte für > 8-Bit-Controller/Prozessoren. Eine Graka braucht auch ein Ausgabegerät, was hast Du Dir da vorgestellt? Mit TTL-ICs ist etwa bei 10MHz Schluß und da hast Du schon massive Probleme mit Laufzeiten und Reflexionen auf Deinem Kuchenblech. Ohne super Kenntnisse beim Layouten läuft da nix. Viel mehr, als flackernde 640*480 oder 320*240 werden das nicht werden. Und wenn die Graka fertig ist, brauchst Du auch noch jemanden, der dafür Programme schreibt.
Ach Du grüne Neune schrieb: > Und genau aus diesem verrückten Grund hab ich mal eine > Elektrodampfmaschine gebaut Der gewaltige Unterschied ist aber, Dein Projekt ist für sich lauffähig! Eine Graka ohne dazu passendes Ausgabegerät, Rechnersystem, Software ist nur eine Platine, die Strom verbraucht und wo absolut garnichts passiert oder zu sehen ist.
Danke für die vielen Antworten! Als erstes habe ich bemerkt dass mein beabsichtigtes gebuffertes Konzept nicht passt, da nach jedem Buffer-Wechsel der um einen Schritt veraltete vorige Buffer-Inhalt drinsteht und nicht mehr verwendet werden kann. Ich wollte eigentlich etwas bauen was in 10 Jahren noch funktioniert und nicht etliche Generationen Computer-, Windows- und Entwicklungssoftware-Upgrades benötigt. Die alten C64,NES usw. sterben bestimmt auch irgendwann den Chiptod wenn man nicht neue Ersatzteile produziert. Ein Projekt aus Standard-74HC-Logikbausteinen wäre bestimmt langlebig , noch dazu an verschiedenen Prozessoren/Controllern anschliessbar weil als Grafikkarte ausgelegt. Dass niemand dafür programmiert ist klar da selbst für die "tollen" C64/NES kaum jemand etwas macht. Grundsätzlich aber brauchte ich eine Programmierplattform die nicht so verhunzt ist wie der PC mit seiner quasi-Zwangsvernetzung und den ewigen Upgrades sowie der allgemeinen Komplexität. Ich traue mich einfach nicht an dem Ding zu programmieren weil ich ständig beobachtet werde und sogar leicht sabotiert werden kann. Nunja ... mal gucken was sich ergibt.
Halligalli schrieb: > Ich wollte eigentlich etwas bauen was in 10 Jahren noch funktioniert Ich habe noch einen IBM-PC von 1981, der funktioniert einwandfrei. Dass ein TTL-Grab auf mehreren Platinen so lange lebt ist ziemlich unwahrscheinlich, und eine Grafikplatine ist ja nur ein Teil eines verwendbaren Systems. Georg
Ich las heute dass sich so ein neues und gut gemachtes NES-Spiel um die 300 mal verkauft hat :-) Das heisst nichts gutes für den Retro-Bereich wenn da sowenige interessiert sind.
Mich überkamen gerade voll die Eingebungen :-) Man könnte den Bildbuffer am Ende der (Render-) Pipeline anbringen also nur das fertige Bild buffern weil es dann beliebig lange vom VGA-Sync-Generator ausgegeben werden kann. Dadurch wäre es auch einfacher die Doppelzeilen auszugeben die man beim 320x240-Modus benötigt. Das würde ausserdem sogar die Bindung der Pipeline an die 12MHz des VGA-Teils lösen - ich habe aber noch keine Ahnung was das bringen soll. Und ich kenne nur den Z80 und den 6502 als 8-Bit-Prozessoren mit extern ausgelöster Stop-Funktion. Eigentlich müssten sie ja nicht stoppen, sondern sie dürfen nur nicht auf den Grafikspeicher zugreifen wenn die Render-Pipeline gerade den durcharbeitet. Ich wüsste aber auch nicht wo da viel Zeit wäre denn der Schwarzbereich zwischen den Zeilen ist nicht gerade lang. Dafür zeigt der VGA-Sync-Teil den Ausgangsbuffer mit konstant 60Hz an, egal wieviele Bilder pro Sekunde der Hauptprozessor verändern kann. Das Ding zu konzeptionieren scheint etwas aufwendiger als gedacht :-)
Halligalli schrieb: > Man könnte den Bildbuffer am Ende der (Render-) Pipeline anbringen also > nur das fertige Bild buffern weil es dann beliebig lange vom > VGA-Sync-Generator ausgegeben werden kann. Ah, ein Raster Image Processor. Idealerweise programmiert man den dann in Adobe PostScript oder HPGL.
Ne das Bild wird einfach Pixel für Pixel nacheinander abgearbeitet. Mithilfe von ein paar Zählern und Latches kann man Referenzen auf Speicherinhalte zusammenstricken. Die Pixeldaten liegen wie beim C64 wie an einer Schnur aufgereiht im Speicher. Wenn man Zähler/Latches richtig verschaltet ergeben sie am Ende genau die Adresse wo die Pixel-Farbdaten bzw. Palettenreferenzen liegen. Die Pipeline wird ein paar Stufen haben da zB. erst die Tile-Nummer (0-255) aus dem Speicherchip der Tile-Karte (etwa 1000 Byte) geladen werden muss. Im nächsten Schritt wird aus den Zählerständen die aktuelle Position innerhalb der Tile-Pixeldaten komposiert. Danach wird von dieser Position die Farb-Referenz zu der Farbpalette geladen und in ein Latch geschoben usw. Ich weiss ehrlich gesagt noch gar nicht wie ich das zeichnen soll :-)
Halligalli schrieb: > Man könnte den Bildbuffer am Ende der (Render-) Pipeline anbringen also > nur das fertige Bild buffern weil es dann beliebig lange vom > VGA-Sync-Generator ausgegeben werden kann. Unfug. Das ganze Tile-Zeug ist eigentlich nur für Spiele relevant, und die wollen Bewegung (Animationen) darstellen. Damit muss deine Karte fähig sein, die Rohdaten mit 60 Hz (60 fps) zu rendern. Doppelzeilen ausgeben ist einfach, indem du den Zeilenzähler für die Rohdaten um einen Pin versetzt anschließt (= den Zählerstand durch zwei teilst). Halligalli schrieb: > Das würde ausserdem sogar die Bindung der Pipeline an die > 12MHz des VGA-Teils lösen - ich habe aber noch keine Ahnung was das > bringen soll. Mit CMOS-Bausteinen und den passenden Abblockkondensatoren solltest du auch 25 MHz Pixeltakt hinbekommen. Irgendwie finde ich 640x480 relativ angenehm, weil man 80 Textzeichen nebeneinander bekommt. Die Hälfte geht aber auch, wobei 12 MHz schon recht weit von den nominalen 12.6 MHz weg ist. Halligalli schrieb: > Und ich kenne nur den Z80 und den 6502 als 8-Bit-Prozessoren mit extern > ausgelöster Stop-Funktion. Eine jede CPU, die mit echter Hardware kommunizieren können will, muss damit rechnen, dass die Hardware langsamer ist als die CPU. Also muss die CPU auch irgendwelche "Waitstate"-Möglichkeiten bieten, notfalls extern. Halligalli schrieb: > Ich wüsste aber auch nicht wo da viel Zeit wäre denn der > Schwarzbereich zwischen den Zeilen ist nicht gerade lang. Zwischen der letzten und der ersten Zeile (VSync) ist genug Platz für Zugriffe. Greift die CPU zwischendurch rein, muss sie entweder warten (= Waitstate) oder Vorrang bekommen (= kaputte Daten in der Pipeline, vgl. CGA-Schnee und umschaltbare Busse). Halligalli schrieb: > Mithilfe von ein paar Zählern und Latches kann man Referenzen auf > Speicherinhalte zusammenstricken. Die Pixeldaten liegen wie beim C64 wie > an einer Schnur aufgereiht im Speicher. Einen nackten Framebuffer rendern ist der einfache Teil. Da in Echtzeit mehrere Sprites draufzurendern ist schon schwieriger. Halligalli schrieb: > Die Pipeline wird ein paar Stufen haben da zB. erst die Tile-Nummer > (0-255) aus dem Speicherchip der Tile-Karte (etwa 1000 Byte) geladen > werden muss. Deine Pipeline muss pro Pixeltakt ein Pixel produzieren können. Wenn deine Sprites 16 Pixel breit sind, dann hast du also gerade mal 16 Pixeltakte Zeit, um aus den Koordinaten die darzustellende Sprite zu gewinnen und ihre Daten in ein Latch zu lesen. Viele Speicherzugriffe kriegst du da nicht unter, weil dir jeder zwischengeschaltete Chip ein bisschen Zeit frisst. Bedenke außerdem, dass eine Sprite an eine beliebige Koordinate gerendert werden können sollte, und zwar auch teilweise außerhalb des Bildschirms (d.h. X = -15 zeigt nur das rechteste Pixel der Sprite, X = 319 nur das linkste). Und bedenke, dass du theoretisch gleichzeitig mehrere überlappende Sprites haben kannst. Halligalli schrieb: > Das Ding zu konzeptionieren scheint etwas aufwendiger als gedacht :-) Es gibt einen Grund, warum man sowas so gut wie nie diskret gemacht hat...
S. R. schrieb: > Unfug. Das ganze Tile-Zeug ist eigentlich nur für Spiele relevant, und > die wollen Bewegung (Animationen) darstellen. Damit muss deine Karte > fähig sein, die Rohdaten mit 60 Hz (60 fps) zu rendern. Würden etwa 30FPS nicht auch reichen ? Damit hätte die CPU vor jedem Bufferwechsel 30ms Zeit Daten zu schieben oder etwas zu berechnen. Die Render-Pipeline würde mit 16MHz Takt (wegen 55ns SRAM) etwa 4ms davon verbraten. Bei 60FPS bleiben nur etwa 16ms bis der Buffer voll sein muss. Ich weiss nicht wie lange eine angeschlossene CPU benötigt um die nötigen Pixeldaten für zB. eine angefügte Tile-Zeile zu verschieben. Und ein paar Register muss er auch noch beschreiben und kalkulieren. Die 8-Bitter waren ja lahme Krücken mit Ausführungszeiten nahe der Mikrosekundengrenze (korrigiert mich). S. R. schrieb: > Doppelzeilen ausgeben ist einfach, indem du den Zeilenzähler für die > Rohdaten um einen Pin versetzt anschließt (= den Zählerstand durch zwei > teilst). Doppelzeilen sind zur Laufzeit der Renderpipeline eine Katastrophe weil man nicht einfach die Zähler zurückstellen kann (auf den Zeilenanfang) denn sie zeigen schon auf den Beginn der nächsten Zeile. Ein (Doppel-)Buffer am Ende der Pipeline würde das ganze Bild aufnehmen und man könnte die von dir erwähnte Pin-Verschiebung benutzen um den Buffer auszulesen. S. R. schrieb: > Mit CMOS-Bausteinen und den passenden Abblockkondensatoren solltest du > auch 25 MHz Pixeltakt hinbekommen. Irgendwie finde ich 640x480 relativ > angenehm, weil man 80 Textzeichen nebeneinander bekommt. Die Hälfte geht > aber auch, wobei 12 MHz schon recht weit von den nominalen 12.6 MHz weg > ist. Ich denke die Auflösung von 256x2yy wie beim NES ist eher 8-Bit-mäßig, ausserdem passt das gut zu den Zählern die man für die Tiles/Blöcke einer Zeilenbreite benötigt. S. R. schrieb: > Einen nackten Framebuffer rendern ist der einfache Teil. Da in Echtzeit > mehrere Sprites draufzurendern ist schon schwieriger. Eine Sprite-Renderpipeline würde parallel zur Tilepipeline laufen. S. R. schrieb: > Deine Pipeline muss pro Pixeltakt ein Pixel produzieren können. Wenn > deine Sprites 16 Pixel breit sind, dann hast du also gerade mal 16 > Pixeltakte Zeit, um aus den Koordinaten die darzustellende Sprite zu > gewinnen und ihre Daten in ein Latch zu lesen. Viele Speicherzugriffe > kriegst du da nicht unter, weil dir jeder zwischengeschaltete Chip ein > bisschen Zeit frisst. Eine Pipeline spuckt an ihrem Ausgang immer pro Takt ein Ergebnis aus, die Speicherzugriffe zur Laufzeit sind egal weil während die 2. Stufe den Inhalt weitergibt sich die 1. Stufe bereits den nächsten Speicherinhalt holt usw. S. R. schrieb: > Bedenke außerdem, dass eine Sprite an eine beliebige Koordinate > gerendert werden können sollte, und zwar auch teilweise außerhalb des > Bildschirms (d.h. X = -15 zeigt nur das rechteste Pixel der Sprite, X = > 319 nur das linkste). Das ist ein Problem dass noch zu lösen ist. S. R. schrieb: > Und bedenke, dass du theoretisch gleichzeitig mehrere überlappende > Sprites haben kannst. Ich dachte an ein Prioritätensystem je nach Spritenummer (0-7) , ich meine der C64 hat soetwas. Es braucht vor dem Speichern des Pixels im Buffer eine Logik die das Pixel mit höchster Priorität auswählt bzw gar nicht zeichnen lässt (unterdrückt). Es kommen ja auch die durchsichtigen Pixel dazu, dann muss entweder der Hintergrund oder das Tile-Pixel an der Stelle in den Buffer.
Moin, Halligalli schrieb: > Würden etwa 30FPS nicht auch reichen ? Klar. Und warum nicht 29.97FPS? Haste 1 Promille mehr Zeit. Nur - ueber was fuer ein Videointerface willste das eigentlich ausgeben? Und was fuer einen Monitor dran anschliessen? Halligalli schrieb: > Ich weiss nicht wie lange eine angeschlossene CPU benötigt um die > nötigen Pixeldaten für zB. eine angefügte Tile-Zeile zu verschieben. Ich weiss nicht, ob man bei der Informationslage schon so in die Vollen gehen sollte. Halligalli schrieb: > Eine Sprite-Renderpipeline würde parallel zur Tilepipeline laufen. Also bevor da irgendwelche Pipelines laufen, wuerd' ich mal dazu raten, ganz simpel anzufangen. Also zB. irgendein Trumm Speicher irgendwie auslesen und irgendwie zu einem Videosignal ueber irgendein Videointerface formen. Vielleicht sogar erst Schwarzweiss, dann in Farbe. Und erst wenn das funktioniert und die Begeisterung immer noch am Ueberschaeumen ist, langsam irgendwelche Rohre verlegen. Gruss WK
Dergute W. schrieb: > Klar. Und warum nicht 29.97FPS? Haste 1 Promille mehr Zeit. Nur - ueber > was fuer ein Videointerface willste das eigentlich ausgeben? Und was > fuer einen Monitor dran anschliessen? Es soll halbes VGA 640x480 rauskommen, damit man es über einen VGA-zu-HDMI-Konverter auch an einen TV anschliessen kann. Da der TV die 320x240 um 5% an jeder Seite beschneidet würden eh nur 288x216 sichtbares Bild übrigbleiben. Da ist es nicht weit hin zu den 256x2yy des NES. Übrigens vermute ich dass es mit den X-Koordinaten der Sprites zu tun hatte beim NES und seiner 256er Bildschirmbreite - da wollte man wohl Zähler sparen. Deshalb ging beim NES nie das Sprite links über den Bildschirmrand - nur rechts konnte man seinen Anfangspixel bis zum Rand schieben. Dergute W. schrieb: > Ich weiss nicht, ob man bei der Informationslage schon so in die Vollen > gehen sollte. Ja, man könnte sich in die C64-Assembler-Foren einlesen ... Dergute W. schrieb: > Also bevor da irgendwelche Pipelines laufen, wuerd' ich mal dazu raten, > ganz simpel anzufangen. Eine Pipeline-Stufe besteht nur aus dem Zählerausgang der direkt ein SRAM ansteuert gefolgt von einem Latch das am Systemtakt hängt (mit LE) und dieses nimmt das Ergebnis des SRAM_Ausgangs auf. Die folgenden Stufen sind dann ähnlich, also nichts besonderes eigentlich.
Halligalli schrieb: > Eine Pipeline-Stufe besteht nur aus dem Zählerausgang der direkt ein > SRAM ansteuert gefolgt von einem Latch das am Systemtakt hängt (mit LE) > und dieses nimmt das Ergebnis des SRAM_Ausgangs auf. Die folgenden > Stufen sind dann ähnlich, also nichts besonderes eigentlich. Man kann sich ja einfache Dinge auch kompliziert reden. Was hat das denn mit einer Pipeline zu tun, durch die Daten oder Befehle durchgeschoben werden? Erfindest du jetzt auch noch deine eigene Terminologie? Hört sich halt geil an, so wie die Pipelines in den Core-Prozessoren... Georg
Moin, Was fuer eine schwere Geburt schon so ein VGA-zu-HDMI-Konverter-Dingens sein kann, kann man hier sehen: Beitrag "VGA Testbild-Fehler-Symptome bekannt ?" Halligalli schrieb: > Ja, man könnte sich in die C64-Assembler-Foren einlesen ... Das kann man immer machen. Aber wozu? Willst du einen 6502 dranhaengen? Oder doch einen Z80? Oder doch was anderes? Sollte vorher klar sein, denn die haben schon unterschiedliche Bussignale und Gimmicks, die man ausnutzen kann, um klammheimlich aufs (Video)RAM zuzugreifen. Denn unklammheimlich aufs RAM zuzugreifen, waehrend die CPU das will (und die solange anhalten) ist nicht so guenstig fuer die Spieleperformance. Gruss WK
Halligalli schrieb: > Würden etwa 30FPS nicht auch reichen ? VGA hat 60 Hz. Du kannst natürlich jeden geraden Frame rendern + puffern und jeden ungeraden Frame puffern, aber ob das so sinnvoll ist... Die Alternative wäre, einen Framebuffer zu bauen, der beliebig langsam gefüttert und dann irgendwann umgeschaltet wird. Siehe unten. > Damit hätte die CPU vor jedem Bufferwechsel 30ms Zeit Daten zu > schieben oder etwas zu berechnen. Die Render-Pipeline würde mit > 16MHz Takt (wegen 55ns SRAM) etwa 4ms davon verbraten. Du scheinst in Frames zu denken. Das ist nicht unbedingt zielführend, weil du die Pixel in Echtzeit auf den Bildschirm schreiben musst. Klassische Sprite-Renderer tun genau das. Außerdem empfehle ich alte Cache-SRAMs, die haben eher so 10ns und kleinere Gehäuse. > Doppelzeilen sind zur Laufzeit der Renderpipeline eine Katastrophe weil > man nicht einfach die Zähler zurückstellen kann (auf den Zeilenanfang) > denn sie zeigen schon auf den Beginn der nächsten Zeile. Wenn dein Renderer pro Zeile (oder sogar pro Pixel) läuft, dann kannst du problemlos jede Zeile zweimal rendern. Wenn dein Renderer pro Frame läuft, geht das natürlich nicht. > Ein (Doppel-)Buffer am Ende der Pipeline würde das ganze Bild > aufnehmen und man könnte die von dir erwähnte Pin-Verschiebung > benutzen um den Buffer auszulesen. Dann brauchst du schonmal allein 64 KB (2 Frames á 256x256 @ 16 Farben) für den Framebuffer. Der ursprüngliche Gedanke, mit möglichst wenig RAM auszukommen (wie die damaligen Systeme), ist dann natürlich dahin. Andererseits ist genau das ein diskret machbares, nicht unbedingt ausuferndes Projekt für sich selbst. Hinreichend komplex ist es außerdem (Koordination CPU-Zugriff vs. VRAM-Zugriff, außerdem muss der VRAM stückweise in den Adressraum gemappt werden können, das Timing muss sitzen). Die gesamte "Renderpipeline" säße dann dazwischen und ist ein separates Projekt. Schneller RAM in der Größe ist billig und erlaubt dir, eine beliebig komplexe GPU zu entwickeln, die nicht an das fixe VGA-Timing gebunden ist. Dergute W. schrieb: > Denn unklammheimlich aufs RAM zuzugreifen, waehrend die CPU das > will (und die solange anhalten) ist nicht so guenstig fuer die > Spieleperformance. Och, wenn man mit Schnee leben kann, geht auch das gut. ;-) Aber ich vermute, dem TO schwebt eine Renderpipeline wie in modernen Grafikkarten vor, wo immer ein volles Bild gerendert und, wenn das erledigt ist, nach dem nächsten VSync auch dargestellt wird. Ist nicht verkehrt, der Ansatz.
S. R. schrieb: > Dann brauchst du schonmal allein 64 KB (2 Frames á 256x256 @ 16 Farben) > für den Framebuffer. Der ursprüngliche Gedanke, mit möglichst wenig RAM > auszukommen (wie die damaligen Systeme), ist dann natürlich dahin. Nur wegen der lahmen ((-Bit-Retro-)CPU soll der Datendurchsatz und die Datenmenge klein sein. Was der Buffer der Grafikeinheit macht ist egal und kann daher größer sein. Ich wollte es eigentlich einfach halten und normales 55ns-SRAM verwenden - das ist auch immer verfügbar wie ich hoffe. Die CPU anzuhalten usw. scheint mir zu unrentabel. Die Pipeline rennt einmal durch und fertig. Ein Problem könnte die vertikale Doppelung der Sprites darstellen wenn es keinen Echtzeit-Eingriff gibt. Aber selbst das kann man mit Hilfe mehrerer Positions-/Umschaltregister machen.
So ein Mist ... wir ziehen bald um und ich kann womöglich eine Weile oder vielleicht gar nicht mehr basteln :-( Dabei langweile ich mich zu Tode! Seit ich keine Gewaltspiele mehr zocken kann/darf weil die Nachbarschaft empfindlich reagiert (kleines Kind, Omi oben und neben mir) wird es wirklich komisch. Selbst meine Filmauswahl muss angepasst werden. Hätte ich das vorher gewusst hätte ich unbedingt Geld gespart für irgendeine Wohnmöglichkeit wo niemand direkt angrenzend wohnt ... ich werd noch depressiv :-)
So...Umzug überstanden und Gehirn hat wieder Kapazitäten frei ? Es scheint dass ein "live-rendern" im VGA-Takt das Parallax-scrollen über Rasterzeilen-interrupt ermöglichen würde. Vermutlich wird da wohl der Bildschirm zeilengenau für einen bestimmten Bildbereich per Scrollfunktion des VIC-chips gescrollt. So eine Scrollfunktion wäre eventuell machbar wenn man die Startwerte der Tile-Pixel-X Zähler mit einem Versatz lädt. Ein Einfügen eines neuen Tiles in die Tile-karte würde ich realisieren, indem ich die Startadresse der Tilekarte als veränderbaren Zeiger auslege und das ganze Ding samt Einfüge/Nachschieb-tiles durch seinen Speicherchip umherschiebe samt Rollover. Zeileninterrupt wäre ja möglich dank vorgeladenen Abwärtszähler, welcher pro Zeile um 1 dekrementiert wird. Übrigens sah ich im C64-Talk auf YouTube dass sie demnächst den VIC-Chip abschleifen und reverse-engineeren...bestimmt funktioniert der auch so ähnlich bis auf das Scrolling - der hat bestimmt flexible Zeilen-Anfangszähler für die Tiles.
Dergute W. schrieb: > janeeeisklaaa Ich hätte genügend Lust ein Diagramm zu Zeichnen wo man die Tiles, Blöcke, Pixel und Zähler sieht. Ich muss nur noch ein Malprogramm finden, denn Paint ist so billig - ob es wohl dieses Pixia noch gibt ...
Also ist jetzt die Frage nicht mehr "Bauen oder nicht bauen", sondern eher "Zeichnen oder nicht zeichnen" - und wenn nicht, warum? SCNR, WK
Erinnerst du dich da mit x0 noch dran? Tüfteln ist gut, aber macht es wirklich Spaß? Echte Erlebnisse sind besser.
> Seit ich keine Gewaltspiele mehr zocken kann/darf weil > die Nachbarschaft empfindlich reagiert (kleines > Kind, Omi oben und neben mir) wird es wirklich komisch. > Selbst meine Filmauswahl muss angepasst werden. Kaufe Dir doch einen Kopfhörer.
Vielleicht hat es eine Zukunft ...falls die Zähler-Apokalypsen-Wurst wirklich so "einfach" und linear funktioniert könnte man es eventuell mal zusammenkloppen Übrigens fing mein Hirn nach dem Lesen einiger Details zu den C64 und NES Tiles an über Speicherorte deren Adressen und Zählern zu denken. Es ging plötzlich voll ab und baute für jedes neue Problem eine Lösung mit Zählern und Logik. So etwas habe ich noch nicht erlebt...das ging voll in die Tiefe mit 100% Leistung. Es war soviel Detail dass ich Angst hatte etwas zu vergessen.
> Ich muss nur noch ein Malprogramm finden
Für Diagramme ist yEd meine erste Wahl.
Stefanus F. schrieb: > Kaufe Dir doch einen Kopfhörer. Das wird nicht reichen ...die haben andere Sinne ? Es kommt noch schlimmer: wir haben jetzt mohammedanischen Nachbarn, auch mit Kleinkind ?
Es scheint ich muss das Projekt beenden, da mich sonst der Mario anspringt ? War aber recht interessant... damals waren ja C64, NES, Master Sytem gleichzeitig draussen. Ob die wohl das Tile/Palette/Sprite/Scrolling alle etwas abgeändert gelöst haben um Patentklagen zu umgehen ?
Halligalli schrieb: > Ob die wohl das Tile/Palette/Sprite/Scrolling > alle etwas abgeändert gelöst haben um Patentklagen zu umgehen ? "Prior Art" sagt dir was?
S. R. schrieb: > "Prior Art" sagt dir was? Heisst das die Technik war schon veröffentlicht worden ? BTT: Ich werde zu Plan C zurückgehen und es einfacher angehen...wer will schon Ärger kriegen...
Es gibt Hoffnung! Es könnte möglich sein eine Abwandlung zu finden die keinem der Retro-Systeme gleichkommt. Dabei scheint es ein Maximum an 2 Bit pro Pixel zu geben bei der Farbkodierung, damit man maximal 4kB Speicher benötigt für die 256 aktiven Tiles. Das Paletten-Referenzsystem bzw. die Anzahl Farben müssten aber anders gewählt werden Man müsste nochmal die Wikis abklappern um die Retrosysteme zu klassifizieren und dann irgendwo dazwischen etwas eigenes zu kreieren.
Wär schon super, wenne das fertig bekommen würdest. Also bau es! Vllt können wir das dann mit dem hier zusammenstöpseln: http://www.fritzler-avr.de/spaceage2/index.htm Zu deinem Problem: Schonmal über DualPort RAMs nachgedacht? Ein 7134LA20PDG zB, der ist auch direkt TTL Pegel kompatibel. Bei der Terminal Videokarte zu dem Spaceage2 Projekt nutzen wir den als Zeichensatzspeicher und Zeichenspeicher. http://www.fritzler-avr.de/spaceage2/down_splan.htm 50 TTL ICs sind zudem doch noch im handhabbaren Rahmen!
Wieso nimmst Du nicht einen FPGA und bildest einen µPD7220 nach. Da hast Du fast keine 74er-Bausteine und es gibt jede Menge fertige Software zum Thema Ansteuerung. Hier mal ein Link zu dem Controller: http://electrickery.xs4all.nl/comp/qx10/doc/nec7220.pdf Du musst das Rad nicht neu erfinden.
Mw E. schrieb: > Schonmal über DualPort RAMs nachgedacht? Werden die noch in Serie produziert ? Das wäre natürlich ideal ! Codix schrieb: > Wieso nimmst Du nicht einen FPGA und bildest einen µPD7220 nach. Der 7220 gibt nur FBAS aus wie es scheint, ist recht komplex und ich finde nirgends eine Angabe wie die Farben funktionieren. Geometrische Formen zu zeichnen wird nicht benötigt, ist auch mit 800ns pro Pixel recht lahm. Ich müsste wohl als nächstes die sichtbare Bildfläche am HDMI-Eingang des TV überprüfen, denn die 288x216 Bildpunkte sind nur Theorie. Sollte ich die benutzen wollen muss ich das wissen. Also wieder ran an den AVR bzw. erstmal ein Programm schreiben und eingeben dass einen Doppelrahmen zeichnet.
Codix schrieb: > Wieso nimmst Du nicht einen FPGA und bildest einen µPD7220 nach. > Da hast Du fast keine 74er-Bausteine und es gibt jede Menge fertige > Software zum Thema Ansteuerung. Ja genau. Oder etwas bestehendes adaptieren ... Zb. den GameDuino: https://playground.arduino.cc/Main/Gameduino Ist super simpel zu programmieren. Aus Sicht der CPU sind es einfach 32KB RAM. Es hat 255 Sprites und große Tiles. Es gibt eine ausgereifte Lib in C und bereits viele Demos und Spiele.
@Halligalli Bei digikey gibts den noch für 15€. Ob der noch hergestellt wird weis ich nicht. Aber soll dein Projekt denn in Serie produziert werden? Also kauft man sich 2 mehr als man brauch und gut isdas. Bzw es wird sicher noch modernere geben. Das war jetzt nur son Vorschlag damit du nen komkretes IC+DaBla hast um mal zu gucken ob son DualPort RAM deinen ANsprüchen genügen würde.
Thomas W. schrieb: > Ja genau. > Oder etwas bestehendes adaptieren ... > > Zb. den GameDuino: > https://playground.arduino.cc/Main/Gameduino > > Ist super simpel zu programmieren. > Aus Sicht der CPU sind es einfach 32KB RAM. > Es hat 255 Sprites und große Tiles. > Es gibt eine ausgereifte Lib in C und bereits viele Demos und Spiele. Leider traue ich mich nicht mehr am PC zu programmieren...da kann ja Hinz und Kunz quasi live zuschauen und rumtun ... Aber ich sah gerade dass das Master System voll die krasse GPU hatte und der C64 extrem wenig draufhatte. Damit bleibt nur noch das NES dessen Palettentechnik ich nicht kopieren sollte. Mal schauen ob sich da ein Weg findet ohne der CPU zuviel aufzubürden bzw. zuviel Speicher zu verbrauchen und gleichzeitig ein paar mehr Farben wie der C64 zu schaffen.
Halligalli schrieb: >> Wieso nimmst Du nicht einen FPGA und bildest einen µPD7220 nach. > > Der 7220 gibt nur FBAS aus wie es scheint, ist recht komplex und ich > finde nirgends eine Angabe wie die Farben funktionieren. Wenn du ihn in einem FPGA nachbildest, ist es dir freigestellt, Farbe zu implementieren. Inklusive RGB-Ausgang.
S. R. schrieb: > Wenn du ihn in einem FPGA nachbildest, ist es dir freigestellt, Farbe zu > implementieren. Inklusive RGB-Ausgang. Soetwas komplexes und undokumentiertes an einem FPGA nachzubilden übersteigt meine Fähigkeiten bei weitem, ich habe lediglich vor etwa 20 Jahren ein paar Gatter an einem solchen mit der kostenlosen Lizenz verwurstet (für eine gescheiterte SCART-Grafikkarte-unlötbar komplex mit falschem Kupferlackdraht).
Ein VGA-Signal mit fixem Timing in einem FPGA zu erzeugen ist nicht besonders schwierig. Zumindest ist es deutlich einfacher als auf einem AVR. Wenn du TTL kannst, kannst du das auch für einen FPGA einfach hinschreiben - die Denkweise ist ähnlich. Und du musst ja keinen existierenden Controller nachbauen.
Hier mal etwas zum vertieften lesen. https://ia801904.us.archive.org/7/items/bitsavers_necuPD7220ec85_3707077/uPD7220-uPD7220A_User_Manual_Dec85.pdf Der Videoausgang ist RGB. Wie das zu Monitor kommt, FBAS, usw. entscheidet der Entwickler des Boards.
Noch eine gute Doku dazu: http://www.nj7p.org/Manuals/PDFs/Intel/231035-004.pdf Bei Intel ist die Bezeichnung des Chips: Intel 82720
Max S. schrieb: > Gibt es denn schon Fotos vom jetzigen Status? Ich bin noch in der Konzeptionierungsphase der Farbanzahl bzw. deren Referenzierung. Soweit ich lesen konnte: - Der C64 benutzt 2 Bit per Pixel und ein "Color-RAM" genanntes, 1000 Byte grosses Areal und 2 Register um 2 fixe Farben und eine wählbare (aus 16 oder so) darzustellen. Die Tile-Karte ist wie üblich 1000 Byte gross. Das heisst beim C64 kämpft die CPU mit etwa 2kB pro Tilebildschirm (zB. beim Scrollen). - Das Master System geht in die Vollen und benutzt 4 Bit per Pixel die auf eine aus 16 Farben einer Palette zeigen, und das "Color-RAM" scheint für mehrere Dinge Flags zu haben und ist 13 Bit breit, benutzt werden aber wohl 2 ganze Byte. Die Tilekarte scheint auch aufgedickt zu sein. - Das NES scheint das sparsamste weil am stärksten komprimierte System zu sein. Es benutzt 2 Bit per Pixel und ein Farbreferenz-System aus 2x2-Tile-Blöcken die nur etwa 64 Byte Speicher belegen, was im Vergleich zu den 1000 Byte der anderen Color-RAMs sehr wenig ist. Dafür hat das NES aber auch nur 4 Farben pro Block aus 12 Farben insgesamt. Die Tile-Karte ist wie beim C64 etwa 1000 Byte. Ich weiss nicht was davon "common knowledge" ist, aber ich würde gerne jedem Tile ein Byte als Farb/Paletten-Referenz spendieren ("Color-RAM"). Dabei sollen sparsame 2 Bit per Pixel verwendet werden im Tilespeicher (4 kB). Details und Palette/Farben sind noch zu erarbeiten. Insgesamt ergäbe es dann 4kB Tilespeicher, etwa 1kB Tilekarte und etwa 1kB "ColorRAM". Durch mein zu prüfendes Zeiger-Scrolling wäre das Nachschieben einer Tile-Zeile/Spalte wohl schnell genug machbar.
Nachtrag: Ein halbes Byte vom Color-RAM pro Tile wäre wohl günstiger, damit kann man aus 16 Paletten wählen. Das klingt immer noch recht brutal, das NES hat nur 2 Bit benutzt um aus 4 Paletten zu wählen ... grübel... ich überdenke das lieber eine Weile. Ich hätte ja am liebsten Farben aus dem 3R3G2B-Farbraum benutzt weil ich den aktuell beherrsche und per VGA ausgeben könnte.
Nachtrag 2: Mir schmerzt oben links das Hirn ... ich glaube ich habe zuviel kompliziertes Zeug geschrieben ?
Fangen wir nochmal von vorne an: Wenn du das Design diskret aufbauen möchtest, dann gilt vor allem, dass es einfach und erweiterbar sein sollte. Außerdem solltest du dich auf Chips beschränken, die es noch gibt, bei den damals üblichen DRAMs wird das schwierig. Von daher wäre es empfehlenswert, erstmal einen ganz stinknormalen Framebuffer zu bauen und den später zu erweitern. Ein billiges SRAM (bevorzugt alter Cache) speichert 32 KB an Daten. Damit erreichst du eine zeitgenössische Auflösung von 256x240 bei 16 Farben, die du pro Pixel frei wählen kannst. Eine Palette "16 aus 256" bekommst du mit zwei zusätzlichen 74LS189 zwischen Framebuffer und DAC. Die Adressierungslogik kannst du mit Scrolling-Registern ausstatten, dann brauchst du nur sehr wenig Bandbreite pro Frame. Dazu parallel kannst du eine Sprite-Engine legen, der ebenfalls auf das SRAM zugreift: Während HSYNC liest sie die Liste der darzustellenden Sprites für die nächste Zeile aus und während der Zeile ersetzt sie die vom Framebuffer erzeugt Adresse, während eine Sprite dargestellt wird. Dazu brauchst du mehrere Register und musst in Hardware sortieren können. Ein zweiter SRAM für die Sprite-Engine erlaubt dir halbtransparente Sprites auf Hintergrund. In einem FPGA gelten andere Randbedingungen, aber ich empfehle die gleiche Vorgehensweise.
Für die Sprite-Engine dachte ich an Register+Abwärtszähler für jedes einzelne Sprite :-) Aber mal schauen was da kommt - erstmal die Tile-Engine probieren! Ich habe übrigens die beteiligten Zähler gezeichnet (mit einer Testversion von Paint.net). Die Pixelzähler laufen alle über und können wenn sie variabel initialisiert werden ein Scrollen bewirken in der fertigen Engine. Der Tile_Zähler wird horizontal vom Pixel_X-Zähler inkrementiert und wenn der Pixel_Y-Zähler überläuft wird ein oberes Bit des Tile_Zählers inkrementiert damit die Nummer/Position auf den richtigen Platz in der Tile-Karte zeigt. Also so ungefähr, Details muss man noch besser aufzeichnen. Die nächste Zeichnung wäre dann das genaue Referenzsystem dieser Zähler in den Tile-Detail-Speicher, doch die Zeichnung muss ich später nachliefern da sie mich jetzt zuviel Hirnschmalz kostet. Die Schmerzen gestern kamen übrigens von der Zugluft im Auto :-).
Und schon taucht ein Problem mit dem Tile_Zähler auf...er war ja in der einfachen Form ideal für 256 Tiles Bildschirmbreite. Da wäre er einfach übergelaufen mit den unteren 8 Bit. Aber nun muss da etwas anderes hin da ich nicht dem NES zu nahe treten möchte...
Halligalli schrieb: > Aber nun muss da etwas anderes hin > da ich nicht dem NES zu nahe treten möchte... Was willst du denn damit sagen?
Bevor ihr fragt: Ich spürte einen alten Japaner und einen hübschen mittleren Alters und die waren beide nicht angetan. Noch dazu las ich vor Jahren eine Verschwörungstheorie wo einem abtrünnigen Nintendo-Mitarbeiter das Auto sabotiert wurde und dieser dabei starb. Ich will mir auf keinen Fall einen Ninja einfangen ...hüstel...?
Der olle Tile-Zähler muss ja nach jedem "Zeilenrücklauf"wieder auf das erste Tile der Zeile zurückgestellt werden, solange nicht eine komplett neue Tile-Zeile anfängt...
Ausserdem braucht der Tile-Zähler nur 10 Bit wie es scheint. Gerade kam die Eingebung dass man die ersten 6 Bits dieses Zählers am Zeilenbeginn in ein Latch kopieren könnte und dann zu Beginn jeder Zeile den Wert in einen extra Zähler laden könnte. Klingt ätzend aber wäre wohl machbar.
Ich habe die erste Stufe der Render-Pipeline aufgezeichnet :-) Dabei mag noch das ein oder andere Problem auftauchen wie zB. was macht das Latch wenn das SRAM den Datenbus löscht bevor sein LE auf Low geht usw. Jedenfalls sollte diese erste Pipeline-Stufe dafür sorgen dass für jeden Pixel das zugehörige Byte aus der Tile-Karte wo dieses Pixel hingehört in diesem Latch bereitsteht. Natürlich nur für einen Taktzyklus des Pixeltaktes, aber das sollte für die weiteren Stufen ausreichen, die übernehmen das Byte dann weiter. Dieses Byte ist übrigens dazu gedacht, den oberen Teil einer Adresse zu bilden aus der hervorgeht wo genau im Tile-Detailspeicher die Pixeldaten liegen (2 Bit für jedes Pixel). Den unteren Teil der Adresse und die Byte-Viertelung (um 2 Bit zu kriegen) bilden dann die zwei anderen Zähler (Tile_Pixel_X und Tile_Pixel_Y). Ich versuche das auch aufzuzeichnen.
Halligalli schrieb: > Ich habe die erste Stufe der Render-Pipeline aufgezeichnet :-) Es ist so phantastisch geworden! Ich haett's nicht schoener hingekriegt. Vor allem haett' ich's nicht mit 9 Adressleitungen und 9 Zaehlerstufen geschafft, bis 849 zu zaehlen. Und ich haett's auch nicht geschafft, mir die kuenstlerische Freiheit herauszunehmen und entgegen den klaren Anweisungen die Zeichnung eben doch als jpg und nicht als png oder gif hochzuladen. Ein Hoch auf Genies, die sich ueber solch Kleingeistigkeit grandios hinwegsetzen koennen. SCNR, WK
Mist...eine Zählerstufe zuwenig.... :-) Ich dachte beim Hochladen muss es nur einige kB klein sein...ich habe immer jpg hochgeladen.
Hast Du schon mal was mit Controllern gemacht? Etwas mehr integriert anstatt mit TTL tut nicht weh, der Zeitverbrauch und das riesige Geld- und Lötzinngrab schon eher.
Matthias K. schrieb: > Hast Du schon mal was mit Controllern gemacht? > Etwas mehr integriert anstatt mit TTL tut nicht weh, der Zeitverbrauch > und das riesige Geld- und Lötzinngrab schon eher. Ich will etwas 8-Bit-Mäßiges machen und nicht das Problem mit einem STM32 erschlagen! So... das neue Bild dürfte passen! Ich habe den Tile_Zähler korrigiert, die Latches auf flankengesteuerte Typen umgestellt und die Pixel_Zähler mit in die zweite Pipeline-Stufe gerettet. Diese braucht nämlich die Pixelzähler so wie sie zum Zeitpunkt dieses einen (vorigen) Pixel-CLK waren. Ausserdem muss das Latch-Ausgangssignal permanent anliegen für die zweite Stufe (Speicherzugriff), daher die flankengesteuerte Version.
Kinder ... vergesst es... Papi hat gepfuscht :-) Jetzt aber ohne die Inverter!
Moin, Halligalli schrieb: > Kinder ... vergesst es... Papi hat gepfuscht :-) <Loriot-Mode>Ach</Loriot-Mode> Wenn der blaue und der gruene und der orangene Zaehler alle am PixelClk haengen, dann zaehlen die doch auch mit jedem Pixel eines hoch. Das heisst, nach jedem Pixel Bildausgabe wird in deinem SRAM eine neue Speicheradresse angelegt, es wird Tile_Pixel_Y und Tile_Pixel_X hochgezaehlt. Soll das so? Gruss WK
Dergute W. schrieb: > Wenn der blaue und der gruene und der orangene Zaehler alle am PixelClk > haengen, dann zaehlen die doch auch mit jedem Pixel eines hoch. > Das heisst, nach jedem Pixel Bildausgabe wird in deinem SRAM eine neue > Speicheradresse angelegt, es wird Tile_Pixel_Y und Tile_Pixel_X > hochgezaehlt. Soll das so? Omann ... danke für den Hinweis! Hier nun die Korrektur: wenn der Pixel_X_Zähler überläuft - also nach jeder Tile-Breite - wird der Tilezähler um 1 erhöht. Leider ist das nur die halbe Wahrheit, da eine Teilzeile 8 Pixelzeilen enthält. Es muss ein wenig um den Tile-Zähler drumherum gebaut werden, damit 8 mal vom selben Startwert hochgezählt wird am Zeilenanfang. Leider kann ich das nicht einzeichnen weil die Steuerlogik dazu recht umfangreich ist da auch die Zeilen-Endsignale wie zB. das Sync- oder Blank-Signal herhalten müssen.
Dergute W. schrieb: > Soll das so? Ich glaube, es ist nicht unsere Aufgabe, halbausgegorene Vorschläge solange zu korrigieren, bis es funktioniert. Sondern es ist Halligallis Aufgabe, seine GPU selbst zu entwickeln, zu debuggen und zu bauen. Halligalli schrieb: > Kinder ... vergesst es... Papi hat gepfuscht :-) Kleine Zeichnungen in Paint zu malen ist einfach. Zur so einem Projekt gehört aber ein bisschen mehr als nur ein bisschen Tile-Zähler und ich sehe nicht, dass du dir darüber Gedanken gemacht hast.
Moin, Halligalli schrieb: > Leider kann ich das nicht > einzeichnen weil die Steuerlogik dazu recht umfangreich ist da auch die > Zeilen-Endsignale wie zB. das Sync- oder Blank-Signal herhalten müssen. Also, mir isses ja eigentlich wurscht - aber wenn du's nicht mal zeichnen kannst, weils zu umfangreich ist, wie willst du's dann bauen koennen? Der Tile_Pixel_Y Zaehler wird vermutlich auch eher an irgendeinem H-Sync- oder Austastsignal haengen sollen... Gruss WK
Ihr habt natürlich recht...dieses Projekt bewegt sich knapp an der Machbarkeitsgrenze. Ich wollte hauptsächlich interessierten Bastlern zeigen wie eine Tile-Engine funktionieren könnte...daher dieser Thread. Ich könnte natürlich auch aufhören aber es ist derzeit mein einziges Hobby :-)
Omg der Tile_Pixel_Y-Zähler...natürlich hängt der am H-Sync ... ich brauch wohl eine komplett neue Zeichnung !
Halligalli schrieb: > Ihr habt natürlich recht...dieses Projekt bewegt sich knapp an der > Machbarkeitsgrenze. Das mag für dich gelten. Andere nehmen einen FPGA und beschreiben die Schaltung mit VHDL oder Verilog statt Paint. Wenn der Monitor nicht synchronisiert, wird der Simulator angeschmissen, bis das Design wie gewünscht funktioniert. Wenn man dann lustig ist, kann man das gern auch in TTL nachbauen, weiß aber zumindest, das es funktionieren kann.
Ich bin nicht studiert genug für sowas. Doch ich habe nachgedacht: das gesamte Projekt ist noch weit komplizierter da auch Adressierungen von Registern und Speicher seitens einer CPU sowie die fürchterliche Initialisierung der Pipeline und die erst recht grausame VGA-Signalerzeugung ausstehen. Ich denke ich begrabe das Projekt und spiele Match3- Spiele auf Bigfish :-)
Ich habe dir genug Anstöße gegeben, was du wie machen könntest, um den Rahmen überschaubar zu halten. Hast du aber ignoriert und stattdessen Witze gemacht. Schade um die Zeit. :-(
@Tom genauso haben wir das beim Spaceage2 (32Bit MIPS in TTL) gemacht. Was da noch an Bugs gefunden wurde ist zum Haare raufen. Die sieht man in den riesengroßen A2 Schaltplänen aus der Konzeptphase einfach nicht. Oder sie kamen erst beim verschalten von Teilschaltungen zum Vorschein. Im VHDL Simulator sieht man alles. Wenn der Ausgang nicht das tut was er soll, dann zieht man sich solange vorgelagerte Signale ind en Viewer bis man sieht ab wos falsch wird und kann den Bug fixen. Die hier haben das leider nicht so gemacht und hatten somit mit so vielen HW Bugs zu kämpfen, dass sie aufgegeben haben: http://www.6502.org/users/dieter/trex/trex.htm Sehr Schade! Ich hätts den sowas von gegönnt!
Warum ist der thread nicht schon lange in Offtopic? Es ist doch klar, dass das hier nie realisiert wird und der TO sich nur aus Langeweile hier ein bißchen mit denen, die ernsthaft helfen wollten, "vergnügt" hat. Sonst geht das selbst bei weniger eindeutigen Angelegenheiten viel schneller.
Nun mach mal halblang... :-) Wäre das Ding was geworden hätte es ein grosses Problem gelöst. Ausserdem wusste ich nicht wie schwer es wirklich ist...
Halligalli schrieb: > Nun mach mal halblang... :-) Nö, er schrieb die Wahrheit. Halligalli schrieb: > Wäre das Ding was geworden hätte es ein grosses Problem gelöst. Nö, hätte es nicht. Halligalli schrieb: > Ausserdem wusste ich nicht wie schwer es wirklich ist... Genau daran hat man gemerkt, dass es ein Langeweile-Projekt war. Denn du hast währenddessen nichts gelernt außer den Specs antiker Spielekonsolen.
> Wäre das Ding was geworden hätte es ein grosses Problem gelöst.
Welches Problem?
Für mich klingt das wie ein klassisches Computerproblem, welches man mit
Computertechnik löst aber ohne Computer gar nicht gehabt hätte.
So kommt man zu der Kosten/Nutzen Überlegung. Wo liegt der Nutzen dieser
Schaltung? Wer braucht das? Jeder popelige 32bit Controller kann
Videospiele über ganz simple I/O Pins anzeigen.
Ich hab mir "Ritterburg" von GaMons besorgt :-) Ne im ernst... vom Gameduino gibts schon V3 und auf youtube scheint tote Hose zu sein. Mir schwebt aber eine Farb-Referenzierungs-Lösung vor, die niemandem auf die Füsse treten sollte: das eine Byte pro Tile aus der Farbenkarte zeigt auf 256 verschiedene feste Paletten zu je 3 Farben plus Trasparenz. Diese müssen nicht linear durch den Zahlen/Farbraum angelegt sein sondern könnten "günstig" vermischt sein, z.B. durch vertauschen der Codierleitungen des 3R3G2B-Erzeuger-Schaltkreises. Es sollten die wichtigsten Farbkombinationen vorhanden sein. Das klingt recht schwer zu entwickeln ...ohne ein selbsgeschriebenes Programm am PC dürfte das übelst werden.
Oder man benutzt 7 Bit der Farbkartenbytes um 128 3-Farben-Paletten zu adressieren und schaltet mit dem 8. Bit auf 4-Farben-Paletten um falls keine Transparenz benötigt wird.
Nachdem du ja eher "herum spielen" möchtest, besorge dir mal sowas wie Logisim, https://en.wikipedia.org/wiki/Logisim Damit kannst du dann wirklich mal einen Schritt weitergehen und musst nicht bei paint stehen bleiben...
2⁵ schrieb: > Nachdem du ja eher "herum spielen" möchtest, besorge dir mal sowas wie > Logisim, https://en.wikipedia.org/wiki/Logisim Oh das sieht ja genial aus ... mal gucken ...
Ich weiss jetzt wie die Kompressionsmethode der 8-Bit-Ära-Graphik funktioniert: Alle Pixel eines Tiles haben die selben 8 Bit-Werte in ihrem oberen Adressteil. Das hat man gemerkt und den Wert in einer extra "Datei" (der Tile-Karte) abgelegt. Beim Zeichnen wird das ausgelesen und einfach zu jeder Pixel-Datenadresse hinzugefügt.
S. R. schrieb: > Das nennt man "Alignment". Kann sein denn das Byte aus der Tilekarte entspricht auch der Position im Detailspeicher ... recht krass das Ganze :-)
Mir lässt die grobe und stark einschränkende 8-Bit-Graphik keine Ruhe...kein Wunder dass nur Schund und Ballerei erschienen damals :-) ...mit Ausnahmen natürlich. Mit 16-Bit-Technologie und doppelter Auflösung sähe die Sache schon anders aus! Leider waren die 16-Bit-CPUs nur ein Zwischenspiel bis die dickeren 32-Bitter erschienen. Denkt ihr es gibt noch 16-Bit-CPUs mit externem Bus die noch produziert werden - evtl. noch länger ?
Moin, Halligalli schrieb: > Mit 16-Bit-Technologie und doppelter Auflösung sähe die Sache schon > anders aus! Leider waren die 16-Bit-CPUs nur ein Zwischenspiel bis die > dickeren 32-Bitter erschienen. Die Bitbreite der CPU hat doch mit der Videoaufloesung und den evtl. eingebauten Faxen ueberhaupt nix zu tun. Wer mit 8bit CPUs kein Video gebacken kriegt, kriegt's auch nicht mit 'ner 512 bit VLIW CPU hin. Gruss WK
Die 16-Bit-Konsolen hatten ganz andere Kaliber als Graphikeinheit. Das muss an der 16-Bit-CPU mit liegen. Grösserer Speicheradressraum, Datendurchsatz usw. Da konnte man sich die 4-fache Menge an Pixeldaten und die erhöhte Bit-pro-Pixel (Farbe) erlauben. Wenn ich schon ständig von der Kiste träume dann muss es wohl die 16-Bit-Version sein :-)
Mir ist wieder eingefallen, warum ich auf 8 Bit bauen wollte: der relativ einfach zu erstellende graphische Inhalt! 16-Bit-Graphik zu zeichnen überfordert die meisten und die grossen Tile-Karten geben einem den Rest, ganz zu schweigen vom Audio...
Halligalli schrieb: > Das muss an der 16-Bit-CPU mit liegen. Unfug. Die "neuen Technologien" mit mehr Transistoren auf einem Chip sind nicht auf CPUs beschränkt, sondern erlaubten auch bessere VPUs und größere RAMs. Halligalli schrieb: > der relativ einfach zu erstellende graphische Inhalt! Unfug. Du kannst die gleiche Grafik auch auf einem 16- oder einem 32-Bitter benutzen. Nur andersrum wirds schwierig.
Ich sehe gerade dass ich mich für diesen vermurksten Thread entschuldigen muss :-) Ich wollte wohl die Tile-Technik kundtun und wegen dem Umfang nachfragen ob es sinnvoll wäre. Hoffentlich ist wenigstens die Funktionsweise klar geworden ... ich wollte sie mitteilen solange ich das kann ...könnte ja einen Unfall haben usw.
Ich glaube ich habe eine mögliche Lösung für das Farb-Referenzsystem gefunden, und zwar als eine weitere Form des "Aligning": Wenn man die jeweils 4 Farbenbytes einer Pallette bei Null beginnend in ein Palletten-RAM schreibt und die restlichen Palletten anreiht, so kann man mittels der 2-Bit-per-Pixel aus dem Detail-RAM direkt auf die Farbe des Pixels zugreifen - solang man diese 2-Bit-per-Pixel als unteren Teil der Adresse verwendet und den oberen Adressteil mithilfe des Bytes aus der Farbkarte/"Color-RAM" des Tiles bildet. Dabei kann man ein Bit der Farbkarte verwenden, um zwischen Transparenz+3Farben oder 4-Farben-Modus umzuschalten - es würden somit 7 Bit in der Farbkarte verbleiben um etliche Basisadressen für Palletten zu referenzieren.
S. R. schrieb: > Pic or it didn't happen. Ich habs gewusst :-) Es wird tatsächlich Zeit das Ganze zusammenzuwursten und eine grössere Zeichnung zu erstellen...erst mit Bleistift und dann am PC.
Es gibt noch ein Problem: Es braucht eine 2-aus-8-Logik um das Bitpaar für den aktuellen Pixel aus dem Detail-RAM zu isolieren (siehe Bild). Hat jemand eine Idee ?
Moin, 74153, Teile von 2x74157, 4052 ... Zum Verbinden der Signale zwischen solchen Chips nimmt man ueblicherweise elektrische Leitungen, oft aus Kupfer. Ich sag's mal nur so, zur Sicherheit. Gruss WK
Prima: 2 ineinander verzahnte 74hc153 mit parallel geschalteten Steuereingängen dürften funktionieren ...hab Dank!
Was für ein Murks so spät am Abend :-) Natürlich braucht die Zählerkombination für Pixel Null die Bits 6 und 7 aus dem Speicher - da kann man leicht etwas verdrehen. Ausserdem scheint ein einzelner 74hc153 auszureichen, sogar die Steuereingänge sind schon intern zusammengelgt.
Halligalli schrieb: > Ausserdem scheint > ein einzelner 74hc153 auszureichen, sogar die Steuereingänge sind schon > intern zusammengelgt. <loriot-mode=on> Ach! <loriot-mode=off>
Hier erstmal eine berichtigte und aktualisierte Zeichnung zu der Aufteilung/Lage der Pixel im Tile, und die Zähler. Ich habe mich für eine Auflösung von 320x240 entschieden, damit kann man an einem Monitor mit VGA-Eingang ein Bild anzeigen. Der Modus ist VGA 640x480@60Hz bei Pixel-Clock von 25,175 MHz, welche aber für die Render-Pipeline mittels Flipflop halbiert wird auf etwa 12 MHz. Ein Pixel wird durch 2 Bit repräsentiert, ein Tile besteht somit aus 16 Bytes. Dadurch ergibt sich ein Tile-Detail-Speicher von 4096 Byte (4 kB), weil 256 verschiedene Tile-Muster gespeichert werden sollen.
Halligalli schrieb: > Ich habe mich für eine Auflösung von 320x240 entschieden, > damit kann man an einem Monitor mit VGA-Eingang ein Bild anzeigen. Das ist jetzt vollkommen überraschend und wäre vor einem halben Jahr eine gute Entscheidung gewesen. > Der Modus ist VGA 640x480@60Hz bei Pixel-Clock von 25,175 MHz, > welche aber für die Render-Pipeline mittels Flipflop halbiert > wird auf etwa 12 MHz. Du halbierst die Pixel pro Zeile. Halbiere einfach den Pixeltakt. Halligalli schrieb: > Hier erstmal eine berichtigte und aktualisierte Zeichnung zu der > Aufteilung/Lage der Pixel im Tile, und die Zähler. Normalerweise fängt man "rechts" an zu zählen. Das Bild ist für mich unverständlich und sieht aus, als ob du das mal eben mit Paint hingeklatscht hättest. Halligalli schrieb: > eine 2-aus-8-Logik Da kannst du zwei 1-aus-8-Logiken benutzen.
S. R. schrieb: > Du halbierst die Pixel pro Zeile. Halbiere einfach den Pixeltakt. Er wird ja auf 12MHz halbiert für die Pipeline. S. R. schrieb: > Normalerweise fängt man "rechts" an zu zählen. Das Bild ist für mich > unverständlich und sieht aus, als ob du das mal eben mit Paint > hingeklatscht hättest. Wenn der Tile_Pixel_X-Zähler auf 000 steht muss das linke obere Pixel-Bitpaar ausgelesen werden, und zwar aus dem Detailspeicher an Adresse 00000000000 - der Pixelzähler ist ja ein Teil der Adresse. Glaubst du da ist der Wurm drin ? Ich nehme stark an dass die Pixelzähler zwingend aufwärts zählen müssen ... S. R. schrieb: > Da kannst du zwei 1-aus-8-Logiken benutzen. Es scheint dass die 2 internen Hälften des 74hc153 ausreichen für diese Aufgabe, es würde also nur ein einzelner Baustein benötigt. S. R. schrieb: >> Ich habe mich für eine Auflösung von 320x240 entschieden, >> damit kann man an einem Monitor mit VGA-Eingang ein Bild anzeigen. > > Das ist jetzt vollkommen überraschend und wäre vor einem halben Jahr > eine gute Entscheidung gewesen. Ich wollte unbedingt an den TV, das ist nun aber nur noch optional per HDMI-Konverter - dabei aber rundum um 5% beschnitten.
Es scheint dass es insgesamt Probleme mit der Konzeptionierung der Auflösung eines Tiles geht. Es sieht aus als ob der C64 z.B. nur noch 4 Pixel breite Charakter-Tiles hat im Mehrfarbmodus, ich finde über google aber nichts genaues ...seltsam die Suchmaschiene enttäuscht mich des öfteren. Weniger Tile-Auflösung könnte den Tile-Detailspeicher verkleinern, was den Adressraum des ganzen 8-Bit-Systems schonen würde. Doch ist es möglich per Register-Schrieb bestimmte Bereiche der Grafikkarte dynamisch auszublenden wenn diese nicht mehr beschrieben werden müssen. Wenn man zwingend von rechts nach links designen sollte müsste wohl der Pixelzähler_X abwärts zählen und ich müsste es neu zeichnen.
Halligalli schrieb: > Ich wollte unbedingt an den TV, das ist nun aber nur noch optional per > HDMI-Konverter - dabei aber rundum um 5% beschnitten. Es gibt VGA-zu-HDMI-Konverter variabler Qualität. Wobei die bei nur 75 Kilopixeln ziemlich scheißegal ist - man sieht eh jedes Pixel und bei deiner Wunschfarbtiefe fällt nichtmal eine falsche Farbkorrektur auf. Gegen den Overscan (also die 5%-Beschneidung) hilft ein Rand: Es gibt einen Grund, dass frühe 8-Bitter eher 256x240 gemacht haben. Antike Technik erfordert antike Lösungen. Halligalli schrieb: > Wenn der Tile_Pixel_X-Zähler auf 000 steht muss das linke obere > Pixel-Bitpaar ausgelesen werden, und zwar aus dem Detailspeicher an > Adresse 00000000000 - der Pixelzähler ist ja ein Teil der Adresse. Rechnest du in Bytes oder in Worten? In der "normalen" Darstellung listet man 16 Bit-Worte so:
1 | Byte [ Byte 01 | Byte 00 ] |
2 | Bit [ 15 14 13 12 11 10 09 08 | 07 06 05 04 03 02 01 00 ] |
3 | Wert [ xx xx xx xx xx xx xx xx | xx xx xx xx xx xx xx xx ] |
Einzelne Bytes listet man entweder nicht nebeneinander oder als Datenstrom. Letzteres ist für deinen Tile-Speicher ungeeignet. Ich fände das Adressraumlayout wesentlich nützlicher als ein "diese Adressbits sind das und jene Adressbits sind welches". Daraus ergibt sich nämlich die gewünschte Adressierung auch. Dafür fällt auf, wenn man sich mit den Bits vertan hat. Halligalli schrieb: > Weniger Tile-Auflösung könnte den Tile-Detailspeicher > verkleinern, was den Adressraum des ganzen 8-Bit-Systems > schonen würde. Ein 8-Bitter hat nur wenig Adressraum, dafür oft getrennt für I/O und Speicher. Ein hochauflösender Framebuffer im normalen Adressraum ist ungeeignet, wenn man ohne Paging-Unit auch noch RAM haben will. Reserviere zwei Adressen im I/O-Adressraum (zwei Latches, ein Dekoder) und setze die oberen Adressbits separat. Dann reichen 256 Bytes (8 Bit) im normalen Adressraum für 16 MB (24 Bit) Grafikadressraum.
Einen Framebuffer wird das Ding nicht haben, da lediglich die Tile-Karte die Anordnung der Tiles am Bildschirm bestimmt. Dabei kommen die "Muster" im Teil aus bis zu 256 fixen Bereichen aus dem 4kB-Detailspeicher, da muss man sparen mit Musterdopplung usw. Ich habe schon mit dem Gedanken an eine Bitmap-Ebene als Hintergrund gespielt aber ich glaube dass kein 8-Bit-System so aufgebaut war, so eine Highres-Grafik hätte etliche Kilobyte Speicher verbraucht. Natürlich mag es Spiele geben die nur Sprites vor einem Bitmap-Hintergrund bewegen oder Text. Der C64 hatte da diverse Grafikmodi, das NES wohl nicht. Ich habe eigentlich nicht in Wortbreiten gedacht, lediglich ein Bit eines Zählers entscheidet welches der 2 nebeneinanderliegenden Bytes ausgelesen wird. Übrigens gibt es ein Entscheidungskriterium bezüglich der Auflösung der Tiles in der Breite: maximale Auflösung zu benutzen bedeutet komplexere Objekte darstellen zu können. Wenn ich da an manche C64-Pixelbrei-Gurke denke dann bleibt eigentlich keine Wahl. Das NES verwendet ja scheinbar auch die maximale Auflösung für seine Tiles.
"Sams Jouney" auf dem C64 sieht gut aus, aber man sieht dass die geringe Auflösung zum Erstellen relativ grosser Objekte führt. Der Hintergrund im Spiel scheint komplett aus Tiles zu bestehen.
Halligalli schrieb: > Einen Framebuffer wird das Ding nicht haben, Ich weise dich mal darauf hin, dass du, um 76800 frei definierbare Pixel darstellen zu können, auch 76800 frei definierbare Speicherstellen für die Pixel brauchst. Du darfst deine "Tiles" auch "Zeichen" nennen. Mit frei definierbarem Zeichensatz kommt dasselbe bei raus.
S. R. schrieb: > Ich weise dich mal darauf hin, dass du, um 76800 frei definierbare Pixel > darstellen zu können, auch 76800 frei definierbare Speicherstellen für > die Pixel brauchst. Da kann man aber die Bits pro Pixel reduzieren, was aber wieder eine Render-Einheit benötigen wird (vermutlich). Übrigens habe ich wieder Paint angeworfen und die aktuelle Tile-Definition nebst Zählern sowie auch die Speicher-Bereiche der Tile-Engine aufgemalt - hoffentlich erkennt man was.
Ich alter Schlamperer... ich hätte in die Speicher-Zeichnung eintragen müssen, dass die Tile-Karte und die Tile-Farb-Karte jeweils ein Byte für jedes Tile am Bildschirm enthalten. Ich kann das Wort "Tile" schon nicht mehr hören bzw. denken :-)
Ich glaube ich habe jetzt die Über-Zeichnung geschaffen, die alle Klarheiten beseitigen wird :-)
Denkt ihr dass 128 Farb-Paletten zuviel sind für die 256 Tile-Muster ? Man könnte die Anzahl Paletten auf 64 reduzieren und das freigewordene Bit 6 der Tile-Farb-Karte dafür benutzen, festzulegen ob ein Tile im Vorder- oder Hintergrund vor den Sprites gezeichnet wird. Soetwas hat mal ein Sonic-Spiel benutzt.
Was ist wohl schneller: 1200 Byte in einem linearen Adressraum von der CPU in die Tile-Karte schreiben, oder komplizierte Adresskalkulationen und Logikoperationen durchführen um ein Zeiger-basiertes Tile-Scrolling zu erreichen ? Es müssten etwa 40 Byte horizontal und etwa 30 Byte vertikal eingefügt werden beim Zeiger-Scrolling (man verändert dabei den Tile-Zähler sodass er in der Tile-Karte wandert). Dabei muss auf Speicher-Überlauf geachter werden bei der Adress-Erzeugung, sowie beim Anfügen der vertikalen neuen Tile-Spale muss immer etwa 30 zur Adresse dazu addiert werden.
Mir fiel gerade ein: es handelt sich um einen 2kB-Speicherbaustein, in dem die Tile-Karte wandert. Um den möglichen Überlauf bei der Adress-Erstellung zu handhaben, könnte man einfach vor jedem Schreibvorgang die oberen Adress-Bits weg-AND-en.
Es gibt ein größeres Problem mit dem Zeiger-Scrolling: Wenn nach rechts gescrollt wird und die Einrückspalte links eingeschoben werden muss fehlt ein Einrück-Byte links unten im Bild. Man könnte das wohl richten wenn man den Tile-Zähler mit Überlauf ausstattet und ihn auf das Einrückbyte ganz rechts oben im Bild - aber der zählt bis zu so einer krummen Zahl hoch, da müsste ich eine taktsynchrone Lösch-Logik einbauen die 11 Zählerbits berücksichtigt ... würg.
Es scheint dass die Tile-Karte gar nicht durch die ganzen 2kB des Speicherbausteins wandert, sondern sich eher in seinem eigenen 1271-Byte-großen Areal umherstülpt. Das liegt wohl daran dass der Tile-Zähler nach dem Zählerstand 1271 überläuft (durch externer Logik-Beschaltung), das heisst es kann nie eine Speicheradresse höher als 0 bis 1270 in den Tilezähler geladen werden bzw. sollte nicht gemacht werden. Ich bin mir immer noch nicht zu 100% sicher ob das Ganze funktioniert, und das Programm zum Berechnen der Startadresse des Tilezählers und der Einrückzeile/-Spalte beim Scrollen dürfte einiges an Hirnschmalz kosten.
Ich habe alle Scrolling-Möglichkeiten aufgezeichnet und es scheint machbar zu sein, dank des überlaufenden Tile-Zählers. Zu beachten ist dass wenn kein horizontales Scrolling stattfindet, der Tilezähler das letzte Tile-Byte einer Zeile überspringt. Das macht eine externe Logik die überwacht, ob der Pixel-X-Zähler abweichend vom Grundzustand initialisiert wurde. Entschuldigt die miese Bildqualität, die nach dem verkleinern der 20MB-Originalbilder übrigblieb. Auch ist der Grüne Rahmen der den sichtbaren Bildschirm darstellen soll schlecht sichtbar. Paint ist eben doch nicht so das wahre... Man kann aber das Bild in voller Hochlade-QUalität anschauen wenn man das Kreuz unten rechts anklickt im BIldbetrachter vom MC.Net.
Es gibt noch das vertikale und horizontale Scrollen während die Tiles bereits halb gescrolled sind, das scheinen aber nur Sonderformen des Diagonal-Scrolling zu sein und somit auch machbar.
Hmm...wenn man den Tile-Zähler als vollen 11-Bit-Zähler belässt und damit den ganzen 2kB-Speicher durchlaufen lässt scheint es die Adress-Berechnungen beim Scrollen zu vereinfachen, so kann man einfach die oberen 5 Bit löschen (nach Addition) oder setzen (bei Subtraktion) um den Überlauf zu simulieren - das benötigt man wenn man den Speicher der Tile-Karte beschreiben will. Die 1272-Byte-Überlauf-Lösung würde zwar Speicherplatz sparen, aber solche krummen Speichergrößen würden wohl nur in einem FPGA möglich sein. Dazu kommt noch eine schwere Berechnung der Einrück-Bytes wenn man Scrollen will und es benötigt externe Logik um den Tile-Speicher bei 1270 überlaufen zu lassen.
Ich habe im 3. Anlauf etwas zusammengekritzelt und dann gepainted was eine gewisse Möglichkeit des Funktionierens aufweisen könnte ... hüstel... entschuldigt die große Bilddatei aber ich habe wohl Paint falsch eingestellt als ich das 230MB-Bild malte und konnte es dann nur soweit verkleinern lassen wie man die Schrift im Bild noch lesen konnte. Die Sache mit den Pulsformern, die aus einem invertierten 7er-Puls einen maximal 3er-Puls machen sollen ist etwas heikel, aber ich habe es durchgespielt und es hat eine gewisse Chance selbst wenn die maximale Toleranz der 74HC-Inverter ausgenutzt wird. Es sieht auch ziemlich nach Inverter-Invasion aus- es müssten etwas 70 sein! Ich sah mir 74C-/4000- Bausteine an um sie eventuell als Verzögerungsglieder zu verwenden aber das sind komische 15V-Dinger mit 100ns Verzögerungszeiten und so. Der nächste Schritt wäre der Pipeline-Teil mit den ganzen Speichern.
Mist...da fehlt eine Init1-Verbindungslinie im grossen Schaltplan ? war ja klar...
Irgendwelche Delays mit NOT Gattern sind kein gutes Design und gehen meist schief. Mach da lieber was aus Zählern und Enable Signalen. Ansonsten besorg dir mal nen Schaltplan Editor, Kicad kann das zB. Zudem wurde das png Format erfunden, das ist ganz gut für Schaltpläne. Es empfielt sich auch sowas immer mal zu simulieren in VHDL. Als Simulator wäre GHDL eine Möglichkeit
S. R. schrieb: > Außerdem gilt "nur ein Nick pro Thread". Tut mir leid ... ich bin vom PC zum Tablet und da war der falsche Name gespeichert.
Mw E. schrieb: > Es empfielt sich auch sowas immer mal zu simulieren in VHDL. > Als Simulator wäre GHDL eine Möglichkeit Ich würde gerne mit Logisim spielen aber ich traue dem Sourceforge Zeug nicht...ich muss am PC Homebanking und so machen ...
Mw E. schrieb: > Irgendwelche Delays mit NOT Gattern sind kein gutes Design und gehen > meist schief Kann eigentlich ein Signal zerfetzt werden wenn es am Eingang umgeschaltet wird aber noch nicht den Ausgang erreicht hat ?
Und schon gibt es die erste größere Korrektur: die alte Schaltung zur Unterdrückung des ersten Pix-Clk-Pulses ist intern zu langsam und würde den zweiten Pix_Clk-Puls verstümmeln. Daher habe ich sie umgebaut, sodass sie bereits bei der fallenden Flanke des ersten Pix-Clk-Pulses aktiv wird und umschaltet. Weiterhin habe ich ein zweites UND-Tor eingebaut um die Pix-Clk des Speicherteils zeitlich zu der Pix-Clk des Pix_X-Zählers anzugleichen. Vermutlich weichen die zwei Takte nun um maximal etwa 10ns voneinander ab wenn die 74HC-Bausteine maximal in der Toleranz auseinanderliegen.
Nach @fritzlers Zweifel an den Invertern habe ich alle Inverter-Verzögerungslinien auf Puffer (74HC365) umgebaut. Nur die Pulsformer behalten den Inverter kurz vor dem Eingang des AND.
Worauf ich eher hinauswollte, dass es kein gutes Design ist durch solche Gatterketten Signale zu verzögern. Die realen ICs streuen da zu sehr. Was genau sollen die Kettendinger denn erreichen? Ich hab da jetz was gelesen von Takten durchlassen wennse gebraucht werden. Dann nimm nen Zähler der nach x Takten feuert. Definiere "Signal zerfetzt werden". Eine minimale zeit die das Signal gehalten werden muss gibts zB bei FlipFlops. Wenn ein normales Gatter ein Impuls erhält der zu kurz ist, dann passiert einfach garnichts, das Gatter erkennt den nicht. Sobald das Gatter am Eingang eine Änderung erkennt kommt nach dem propagation delay (siehe Datenblatt) am Ausgang eine Reaktion raus.
Mw E. schrieb: > Was genau sollen die Kettendinger denn erreichen? Sie sollen ein Signal verzögern, und zwar um mindestens die minimum tPD (ich vermute da 8-10ns). Dieses verzögerte Signal soll später etwas steuern bzw. wird zu einem Puls geformt. Mw E. schrieb: > Definiere "Signal zerfetzt werden" Wenn in einer Inverterkette zB. sich das Eingangssignal ändert während es einen Inverter noch nicht in tPD-Länge passiert hat. Aber es sind ja steilflankige 5V-Pulse, da wird es wohl keine Hysterese-Probleme geben ... Da ist eine Stelle wo aus einem 5tPD-Puls ein 3tPD-Puls geformt werden soll. Wenn der 5er Puls nur 40ns lang wäre aber die Gatter des 3er Pulses jeweils 20ns tPD haben sollten dann durchquert der Eingangspuls die 3 Gatter nicht auf ganzer Länge sondern nur die ersten 2 werden durchgesteuert (womöglich das zweite nichtmal ganz). Das hat mir etwas Sorge bereitet. Aber möglicherweise werden die 20ns tPD nur bei starker Belastung des Gatterausgangs auftreten ?
Halligalli schrieb: > Sie sollen ein Signal verzögern, Dafür gibt es Verzögerungsleitungen und Zähler.
S. R. schrieb: > Dafür gibt es Verzögerungsleitungen und Zähler. Das ist mir nicht simpel genug :-) Erstmal ohne versuchen... Ich bin übrigens zu dem Schluss gekommen dass ein Signal eine Gatteranreihung unverändert durchquert wenn der Puls länger dauert wie die Laufzeit des langsamsten Gatters.
Magst Du Dich vielleicht mit Josef zusammentun? Der baut dann das Ganze mit in seine FPGA-CPU ein: Beitrag "Befehlssatz der bo8-CPU - was ist gut, was ist schlecht" Das wäre echt der Knüller!
Ich habe vor es erst zu zeichnen, dann irgendwie modulweise als Prototyp zu testen. Das zieht sich bestimmt ewig hin. Wenn es irgendwann laufen sollte kann jedermann seine FPGA-Finger drantun :-)
Sagt mal kommen alle Dual-Port-SRAM von IDT und haben TTL-Pegel am Ausgang ? Das wäre schon recht komisch ...
Moin, Halligalli schrieb: > Sagt mal kommen alle Dual-Port-SRAM von IDT und haben TTL-Pegel am > Ausgang ? Das wäre schon recht komisch ... Wenn du eine Laubsaege hast: In FPGAs sind oft auch solche RAMs eingebaut. Die gehen dann wohl eher mit 1.x V Pegel. Wird man aber wohl eher ein feines Saegeblatt brauchen. Inverteranhaeufungen sind ein genauso sicheres Zeichen fuer ein fuerchterlich schlechtes Schaltungsdesign, wie Monoflops und Digitalpotis. SCNR, WK
Seitdem es FPGAs gibt braucht "keiner" mehr Dualport RAMs. Diese Niesche für alle restlichen Anwendungsfälle hat eben IDT gefüllt. Und nochmal: Mach diesen Müll von Verzögerungsgattern weg zur Flankenerkennung oder wann was ausgeführt werden soll. Das funktioniert NICHT! Oben rechts kommt bei dir ne PX_CLK rein und aus der erzeugst du selber H/V SYNC, die sollten auch nicht extra reinkommen. Und dann Zählt da ein Zähler den Pixeltakt, nach X Takten ist VSYNC und nach x,y Takten ist ebene dein 5tpd etc. Diese 5tp, +6tpd usw erzeugen durch Verzögerung ist absoluter Murks. Es hat alles nach x y z Takten zu erfolgen, synchrones Design eben. Hier mal Lektüre wie wir das bei der Terminalkarte (die kann nur Text Ausgeben) für den MIPS TTL Rechner gelöst haben: Doku: http://www.fritzler-avr.de/spaceage2/!Files/Doku/periph/Videokarte/03_VIDEO.pdf Schaltplan: http://www.fritzler-avr.de/spaceage2/!Files/Schaltplan/2016-03-06%20Schaltplan%20Video-Karte.pdf Da sind Horizontalpixelzähler verbaut um zu steuern was nun auf der Zeile ausgegeben werden muss. Dann auch noch ein Zeilenzähler für die weitere Orientierung. Hier mal noch ne Übersicht was es so an TTL ICs gibt inkl Sortierung nach Funktionsgruppen:
Halligalli schrieb: > habe ich alle > Inverter-Verzögerungslinien auf Puffer (74HC365) umgebaut. Nur die > Pulsformer behalten den Inverter Durch die Verwendung einer einzigen Verzögerungsleitung mit Abgriffen können noch 3 Gatter eingespart werden. Ein 4050 mit 6 Gattern wird komplett eingesetzt und ein Drittel von einem 4049 kommt noch dazu.
Die BMP-Datei ist viel zu groß geworden. Hier nochmal die gleiche Schaltung in gleich guter Qualität als PNG-Datei, aber mit weniger Speicherplatzbedarf.
Mit einem registrierten Account hättest du das falsche Bild löschen können.
Stefanus F. schrieb: > Mit einem registrierten Account hättest du das falsche Bild löschen > können. Ich habe mich gerade mal mit meinem richtigen Namen (Accaunt) angemeldet, konnte das Bild aber trotzdem nicht mehr löschen, obwohl die Bearbeitungszeit, von einer Stunde, noch nicht abgelaufen ist.
Ach Du grüne Neune schrieb: > Ich habe mich gerade mal mit meinem richtigen Namen (Accaunt) > angemeldet, konnte das Bild aber trotzdem nicht mehr löschen, > obwohl die Bearbeitungszeit, von einer Stunde, noch nicht > abgelaufen ist. Du kannst natürlich nur deine eigenen Beiträge ändern. Als Gast bist du jemand anderes (anonym). Wenn jeder registrierte Benutzer die Beiträge der Gäste ändern könnte, wäre hier aber was los.
Stefanus F. schrieb: > Als Gast bist du > jemand anderes (anonym) Ach soo. Und ich habe gedacht, dass das System so schlau ist und erkennen kann, das die IP-Adresse von Ach Du grüne Neune und meinem Acount gleich ist. Sonst könnte der Moderator ja auch nicht erkennen, wenn man mit zwei unterschiedlichen Gastnamen in einem Thread unterwegs ist.
Ach Du grüne Neune schrieb: > Ach soo. Und ich habe gedacht, dass das System so schlau ist und > erkennen kann, das die IP-Adresse von Ach Du grüne Neune und meinem > Acount gleich ist. Sonst könnte der Moderator ja auch nicht erkennen, > wenn man mit zwei unterschiedlichen Gastnamen in einem Thread unterwegs > ist. Moderatoren können die IP Adressen der Schreiber sehen.
Danke für eure Ratschläge, ich werde darüber nachdenken ! Weiss jemand ob so ein 74hc-Baustein schneller durchsteuern kann wie im Datenblatt angegeben (typ 8ns) ?
Es ist sehr wahrscheinlich, dass ein konkreter Mikrochip bei vielen, eventuell sogar bei allen technischen Daten tatsächlich besser ist, als das Datenblatt verspricht. Nur kannst du dich nicht auf dein Glück verlassen. Nur die Daten aus dem zugehörigen Datenblatt des Herstellers sind verlässlich.
Es könnte möglich sein, mit dem H-Sync-Puls einen Zähler (bis 8) zu starten und bei jedem Zählstand etwas auszulösen. Der Zählertakt müsste aus dem herunter-geteilten Pix_Clk abgeleitet werden. Ich vermute dass der H-Sync sowieso synchron zur Pix_Clk ist da er aus einer bestimmten Anzahl davon abgeleitet werden wird im VGA-Signal-Erzeugungsteil.
Wenn dir 74HC zu langsam ist, dann nimm 74AC. Aber nur da wo dus brauchst, die Flankensteilheit stellt dann so langsam Anforderungen ans Layout.
Ich habe mich mit der Steuerpuls-Erzeugung mittels Zähler beschäftigt und etwas zusammengezeichnet. Zur Ansteuerung des Takteingangs des Zählers musste ich eine Verzögerungsstrecke einbauen damit der Zähltakt nicht gleich nach dem Master-Reset anfängt. Auch bedurfte es eines Pulsformers beim CPU-Signal, damit das X=7-Signal nicht das ODER-Gatter blockiert - ich habe den Puls aber vorsichtshalber mit 5 Gattern aufgebaut. Es sieht insgesamt wirklich kompakter aus, obwohl es 4 Bausteine mit 4-fach-UND benötigt.
Mir ist ein potenzielles Problem aufgefallen: wenn der Pix_X-Zähler am Zeilenanfang mit 7 geladen wird könnte das einen ungewollten CPU-Puls auslösen ...
Und schon ist eine Lösung gefunden: H-Sync blockiert den möglichen Puls während seiner Dauer.
Ei ei ei ... gerade merkte ich dass 74HC-Zähler viel zu langsam sind für die Aufgabe. Bei der Suche nach 74AC-Zählern musste ich feststellen dass es scheinbar nur noch 74AC161 und 74AC163 gibt, der 74AC193 ist wohl obsolet. Ich weiss gar nicht was der Unterschied ist zwischen den 161 und den 163, aber es sind beides Aufwärtszähler - der 193 konnte noch abwärts zählen, was ich für den Pix_X-Zähler benötigen würde. Wenn Zähler gar nicht und VGA-Quartze fast nicht mehr hergestellt werden dann sieht es gar nicht gut aus für solche Projekte. Scheinbar muss man auf ARM oder FPGA umsteigen und am PC herumwerkeln.
Ich hab dir nen Link zu meiner Webseite zu meiner Aufzählung an TTL ICs gepostet. Da steht das drinne. Villeicht musste ja auf F, AS, A oder ALS ausweichen. Also die "echten" 74er TTL Serien. Die sind nämlich lustigerweise schneller als HC/AC und als NOS bekommt man noch alles aus den USA. Da bekommt man nich Dinger dies auch als HC nicht mehr gibt, wie den 825 oder 867.
Kannst du den Link nochmal posten ? Was heisst eig. NOS ....sheis google...
New Old Stock, also alter Kram aus den 70ern Original verpackt und unbenutzt. Nicht nur DDR Ware taucht immermal aus dem Nichts auf, sondern auch amerikanische TTL ICs. (so hab ich mir mal 400Stück VQB201 16 Seg Anzeigen zu 1ct/Stück an Land gezogen) Hier der Link, dieser beinhaltet alle HC/AC welche zur Zeit der Erstellung bei Digikey lieferbar/gelistet waren: http://fritzler-avr.de/HP/Librarys/list_ttl.htm Was man zusätzlich noch als TTL bekommt ist nicht gelistet.
Dank dir! Es sieht aus als müsste ich FPGA lernen um weiterzumachen, denn Originalbausteine aus den 70ern sind keine langfristige Lösung.
Halligalli schrieb: > Es sieht aus als müsste ich FPGA lernen um weiterzumachen, denn > Originalbausteine aus den 70ern sind keine langfristige Lösung. Das wurde Dir schon am 12.3. und ab 2.7. nachdrücklich empfohlen: MaWin schrieb: > ENTWEDER eine genial einfache neue Umsetzung "nur 10 Chips", ODER etwas > kompatibles (als FPGA Realisation). Codix schrieb: > Wieso nimmst Du nicht einen FPGA und bildest einen µPD7220 nach. Du hattest 7 (in Worten sieben) Monate Zeit FPGA zu lernen. Statt Dir ein HDL-Buch, einen Simulator und eine Webseite zu nehmen (z.B. https://www.fpga4fun.com/PongGame.html) führst Du hier obskure Selbstgespräche über (inzwischen) exotische Zählerbausteine. Wie alt bist Du, welche Erfahrung hast Du und was ist Dein eigentliches Ziel? Das Forum vollmüllen oder auch mal ein Projekt durchziehen und was dabei lernen?
In meiner zusammenstürzenden Welt war das Basteln mit diskreten Logikbausteinen noch möglich ...:-) Nunja...ich wälz mich gerade durch das CPLD/FPGA-Tutorial hier ... ich lerne das mal alles. Gibts ein tolles und einfaches Buch ?
Moin, Nur keine Sorge. Monologe halten, Bilder malen und Unmengen Inverter/Bustreiber zusammenstoepseln geht auch voellig ohne FPGA. Halligalli schrieb: > Gibts ein tolles und einfaches Buch ? Ganz bestimmt. Sogar mehrere. https://www.fpgarelated.com/documents.php SCNR, WK
Halligalli schrieb: > In meiner zusammenstürzenden Welt war das Basteln mit diskreten > Logikbausteinen noch möglich ...:-) Das geht auch heutzutage noch. Mein Z80 lebt.
S. R. schrieb: > Halligalli schrieb: >> In meiner zusammenstürzenden Welt war das Basteln mit diskreten >> Logikbausteinen noch möglich ...:-) > > Das geht auch heutzutage noch. Mein Z80 lebt. Z80 aus TTL Gattern? Haste da maln Link?
Halligalli schrieb: > Es sieht aus als müsste ich FPGA lernen um weiterzumachen, denn > Originalbausteine aus den 70ern sind keine langfristige Lösung. Was ja kein Fehler ist. Damit eröffnet sich für dich eine neue, großartige Welt. Eine Welt voller ungeahnter Möglichkeit, die du sonst nicht hättest.
Also nach dem Lesen des CPLD/FPGA-Artikels hier muss ich sagen dass es mir unmöglich ist, etwas auf einem FPGA zu entwerfen. Vielleicht geht es noch gerade so mit einem CPLD, obwohl man da scheinbar auch die FPGA-Entwicklungswerkzeuge benötigt. Ich sehe schwarz für die Bastler-Zukunft...
Also VHDL is nu wirklich nicht schwer. Inner Uni wird man als Erstsemester direkt ins kalte VHDL Wasser geworfen und soll ne kleine MIPS CPU in VHDL bauen und simulieren. Guck dir doch mal an was ne entity ist und was ne architecture is. Dann wie man den Simulator anwirft, die Herstellertools kommen später.
Moin, Halligalli schrieb: > Ich sehe schwarz für die Bastler-Zukunft... Der Jonathan Sieber sieht das anscheinend nicht so. In dem Link, den ich weiter oben gepostet hab', wird auf ein Pamphlet von ihm verwiesen, das zufaellig den Titel: "Implementing the Nintendo Entertainment System on a FPGA" hat. Und kaum, dass man mal ein bisschen googelt, findet man das auch ohne dass man sich da irgendwo anmelden muss. Da hat dir also schon einer alles vorgekaut. Gruss WK
Ich werde das Projekt erstmal auf Eis legen bis mir eine Eingebung kommt wie es weitergehen könnte... Falls es jemand trotzdem versuchen möchte hier ein paar Ergänzungen: Der erste Puls einer Pix_Clk-Zeile muss nicht mehr unterdrückt werden. Stattdessen lässt man den Zähler mit der ersten ansteigenden Flanke sofort los-/vorauszählen und latcht dafür den Ausgang des Zählers mit dieser Flanke durch ein Latch. Dadurch bekommt der Zähler einen Vorsprung den er braucht weil mitsamt der Logik einiges an tPD zusammen kommt. Ferner bewirkt diese Lösung dass wenn der Pix_X-Zähler mit 7 geladen wird (kein hor. Scrolling) automatisch ein extra-Puls am Zeilenende erzeugt wird und dieser nicht mehr während des H-Sync erzeugt werden muss (bei XL=7). Der Rest der Pipeline ist eigentlich recht einfach: Speicher mit Zählern verbinden und flankengesteuerte Latches dzwischen. Die Extrahierung der 2 Bits ist auch machbar. Man sollte nicht vergessen am Ende die Anzahl der Pipeline-Stufen bis zum VGA-Ausgang zu bestimmen und daraus zu bestimmen, um wieviele Pix_Clk vorher die Pipeline beginnen muss (vor dem ersten realen sichtbaren Bildschirm-Pixel).
Ha...es gibt alle Bausteine als doppelt so schnellen 74ALS-Typ! Also kann es weitergehen :-) Die Zähler-Ansteuer-Logik ist wirklich furchtbar zu entwickeln - vor allem da man während der 80ns Pix-Clk nicht viel Zeit hat für Logikgatter zwischen Pix_X und dem Tilezähler. Während ich mir den Kopf zerbrach habe ich eine Skizze zur Pipeline mitsamt den Speichern hingekritzelt - und es scheint funktionsfähig zu sein. Zum Thema Verzögerungen mittels Puffer muss ich Versuche anstellen, denn es braucht für die flankengesteuerten Latches eine Haltezeit von um die 2-3ns.
Verd.... Der Pix-X-Zähler geht natürlich mit 2 Leitungen zur 2-aus-8-Logik...
Und unten müsste es heissen: "Transparenz bei Bitpaar "00"", also wenn Transparenz-plus-3-Farben-Modus für dieses Tile besteht. Eine Logik unterdrückt später das Zeichnen des Pixels dessen Bitpaar 00 ist. Bitpaare 01,10,11 werden am Ende dann am Bildschirm ausgegeben.
Upps...dafür muss erstmal das Bitpaar weitergereicht worden sein ...seht die Zeichnung mehr als Skizze an :-)
Hier ist die korrigierte Zeichnung! Nachfolgend käme eine Auswahl-Logik welche das Pixel-Farbbyte entweder zeichnet oder (bei Transparenz) stattdessen das Farbbyte der Hintergrund-Farbe zeichnet. Die Hintergrundfarbe steht in einem Register-Latch welches am CPU-Bus angeschlossen ist. An dieser Auswahl-Logik würde auch eine eventuelle Sprite-Engine andocken, ebenfalls mit ihrem RGB-Farbbyte und einem Transparenz-Flag. Das Ganze wird schliesslich über den D/A-Wandler ausgegeben, gleichzeitig aber auch in einen 320-Byte-Puffer-Speicher gespeichert. Es werden ja nur die ungeraden Bildzeilen von der Tile-/Sprite-Engine produziert, die geraden Zeilen müssen aus diesem Puffer-Speicher geholt werden. Da wird dann wohl ein Zähler bis 320 an den Adressleitungen des Puffer-Speichers angeschlossen sein, der die Adressierung sowohl beim Beschreiben als auch beim Auslesen erledigt.
Gerade kam mir die krasse Idee dass man den Pix_Y-Zähler immer nur jede zweite Zeile erhöhen könnte. Möglicherweise bewirkt das eine Zeilendoppelung, wodurch man sich den 320-Byte-Pufferspeicher am Ende sparen könnte.
Es ist mir fast schon peinlich ..hüstel... aber der Pix_X-Zähler in der Zeichnung müsste bis zur 2-aus-8-Logik mit jeder Pipelinestufe durchgelatcht werden, damit er zum Pixel aktuell ist. Auch kann es sein dass die 2-aus-8-Logik zu langsam ist um in einem Takt das Pixelpaar aus dem Byte des SRAM zu trennen. Es wäre wohl besser das in eine zusätzliche Pipelinestufe zu legen. Es ist sowieso seltsam: das Projekt zieht sich über mehrere Wochen/Monate und ständig kommt irgendeine neue Idee oder Fehlerkorrektur dazu. Manchmal fällt mir kurz vor dem Einschlafen etwas wichtiges ein und ich muss aufstehen und es auf einen Notizzettel schreiben. Von denen habe ich auch schon einen kleinen Stapel... Das schlimmste ist aber dass ich keine Wand oder Tafel habe um alles übersichtlich darzustellen, alles liegt übereinander. Erst vor kurzem fiel mir ein dass die Scroll-Funktion für eine Raster-Scrollfunktion (zB. nach Rasterzeilen-Interrupt) eine zweite Einrückspalte links vom Bildschirm benötigt, damit man eine Zeile zB. nach rechts scrollen kann während die vorherige nach links scrollte. Also alles nochmal auf Papier simulieren usw. Ich sah in einem youtube-Video dass der C64 scheinbar mit Einschränkungen beim Scrolling kämpfte, da musste man wohl den Bildschirm um ein Teil verkleinern weil beim Scrollen von mehr als 8 Pixel links eine Lücke entstand da kein Tile nachkam. Vermutlich haben die Entwickler die Scroll-Engine des C64 aus Vereinfachungsgründen recht einfach konstruiert. Ob sie wohl alles so einfach wie möglich programmierbar machen wollten um die Kundschaft nicht zu überfordern ?
Halligalli schrieb: > Ob sie wohl alles so einfach wie möglich > programmierbar machen wollten um die Kundschaft nicht zu überfordern ? Die haben sich zumindest nicht verzettelt und offenbar was recht erfolgreiches zuwege gebracht. Außerdem plädiere ich für "nicht bauen", damit der nervende Monolog mal ein Ende hat. Wenn Du Dir wiedererwarten doch mal ein FPGA-Board mit VGA-Ausgang anschaffst, kannst Du Dich ja gern wieder melden.
Hier hats jedenfalls wer in HC Logik geschafft. SEHR! Beeindruckend! Da klappt eine echt die Kinnlade runter. Videos: https://www.youtube.com/watch?v=HqSYwKYwtOo https://www.youtube.com/watch?v=XuzK2BwvmKQ https://www.youtube.com/watch?v=3fXuFCxMHVI https://www.youtube.com/watch?v=chACO3WNtg0 https://www.youtube.com/watch?v=M9kUlFZM0gM https://www.youtube.com/watch?v=nQtSusVWgk4 Forenfred: http://forum.6502.org/viewtopic.php?f=4&t=3329
Sieht verdammt gut aus auf dem Monitor! Die haben scheinbar den Spatz mit der Kanone erschossen :-) Scheint reine Speicher-Schieberei zu sein, ohne Tile-Logik. Die vielen Sprites sind genial...
Halligalli schrieb: > Irgendwie macht mir das Steckbrett ein bisschen Angst Mir würde das Steckbrett nur dann Angst machen, wenn ich es komplett voll bestücken müsste. :)
Es sind etwa 60 Bausteine, komplett mit Adressdecodern. Zusätzlich muss noch ein 8051 samt Anhang drauf... und es soll mehr oder weniger von oben nach unten gebaut werden...und das Brett sollte später eine mögliche Sprite-Engine aufnehmen können.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.