mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bauen oder nicht bauen ?


Autor: Halligalli (Gast)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
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 ?

Autor: Bürovorsteher (Gast)
Datum:

Bewertung
9 lesenswert
nicht lesenswert
Ja, zieh das Ding durch. Wenn du fertig bist, kannst du hier ein Bild 
einstellen.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Leroy M. (mayl)
Datum:

Bewertung
14 lesenswert
nicht lesenswert
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. ;)

Autor: Ach Du grüne Neune (Gast)
Datum:
Angehängte Dateien:

Bewertung
23 lesenswert
nicht lesenswert
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.

Autor: Alexander (Gast)
Datum:

Bewertung
10 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
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
Autor: Wolfgang (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Jemand (Gast)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
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

Autor: Niemand (Gast)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
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?

Autor: Marvin M. (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
http://www.mycpu.eu/

Da gibt's auch ne Grafikkarte aus TTLs ;)

Autor: georg (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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

Autor: dasrotemopped (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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...
Seite 7
Adafruit Board bestellen, Treiber für Zielplattform schreiben, fertig.

Gruß,
dasrotemopped.

Autor: Peter D. (peda)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Photovoltinator (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alexander schrieb:
> Just four fun.

Schade. Das ist ja blöd, wenn's nur vier mal Spaß macht ;)

SCNR

Autor: Halligalli (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: georg (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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 :-)

Autor: soul e. (souleye)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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  :-)

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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  :-)

Autor: Halligalli (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
janeeeisklaaa

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ist jetzt die Frage nicht mehr "Bauen oder nicht bauen", sondern 
eher "Zeichnen oder nicht zeichnen" - und wenn nicht, warum?

SCNR,
WK

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht genügt es, das Ding als imaginäres Projekt zu entwickeln 😀

Autor: Asche (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erinnerst du dich da mit x0 noch dran?
Tüfteln ist gut, aber macht es wirklich Spaß?
Echte Erlebnisse sind besser.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
> 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.

Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leroy M. schrieb:
> Das ist der Grund, das zu machen.

Mach du doch!

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
> Ich muss nur noch ein Malprogramm finden

Für Diagramme ist yEd meine erste Wahl.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 😀

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: F. F. (foldi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Für Diagramme ist yEd meine erste Wahl.

Geiles Programm, Stefan. Danke!

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Codix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas W. (Firma: privat) (diddl)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Halligalli (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Codix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal etwas zum vertieften lesen.
https://ia801904.us.archive.org/7/items/bitsavers_...

Der Videoausgang ist RGB.
Wie das zu Monitor kommt, FBAS, usw. entscheidet der Entwickler des 
Boards.

Autor: Codix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine gute Doku dazu:
http://www.nj7p.org/Manuals/PDFs/Intel/231035-004.pdf
Bei Intel ist die Bezeichnung des Chips: Intel 82720

Autor: Codix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Letzter Nachtrag von mir zu diesem Chip:
https://digitalcommons.utep.edu/dissertations/AAIEP02441/

Autor: Max S. (maximus-minimus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es denn schon Fotos vom jetzigen Status?

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Nachtrag 2:

Mir schmerzt oben links das Hirn ... ich glaube ich habe zuviel 
kompliziertes Zeug geschrieben 😀

Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:
Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
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  :-).

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Halligalli (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
S. R. schrieb:
> Was willst du denn damit sagen?

Ich habe da etwas echt schräges gespürt ...😁

Autor: Halligalli (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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...😀

Autor: S. R. (svenska)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
...ich bin dann mal raus.

Autor: Halligalli (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
S. R. schrieb:
> ...ich bin dann mal raus.

Kein Humor ? ... Schade ...

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Doch, aber nicht in einer technischen Diskussion.

Autor: Halligalli (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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...

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:
Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mist...eine Zählerstufe zuwenig.... :-)

Ich dachte beim Hochladen muss es nur einige kB klein sein...ich habe 
immer jpg hochgeladen.

Autor: Matthias K. (kannichauch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Kinder ... vergesst es... Papi hat gepfuscht  :-)

Jetzt aber ohne die Inverter!

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Halligalli (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Omg der Tile_Pixel_Y-Zähler...natürlich hängt der am H-Sync ... ich 
brauch wohl eine komplett neue Zeichnung !

Autor: Tom (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
:-)

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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. :-(

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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!

Autor: Tippgeber (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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...

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> 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.

Autor: Halligalli (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 2⁵ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MiMa (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wie wäre es mit einem fliegenden Aufbau?
http://techno-logic-art.com/clock.htm

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Halligalli schrieb:
> Kompressionsmethode

Das nennt man "Alignment".

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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  :-)

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Halligalli (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Pic or it didn't happen.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Prima: 2 ineinander verzahnte 74hc153 mit parallel geschalteten 
Steuereingängen dürften funktionieren ...hab Dank!

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Halligalli schrieb:
> Ausserdem scheint
> ein einzelner 74hc153 auszureichen, sogar die Steuereingänge sind schon
> intern zusammengelgt.

<loriot-mode=on>
Ach!
<loriot-mode=off>

Autor: Halligalli (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
Byte  [        Byte 01          |         Byte 00         ]
Bit   [ 15 14 13 12 11 10 09 08 | 07 06 05 04 03 02 01 00 ]
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: PCB (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Seufz.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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  :-)

Autor: Halligalli (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube ich habe jetzt die Über-Zeichnung geschaffen, die alle 
Klarheiten beseitigen wird  :-)

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Halligalli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.