Bauen oder nicht bauen ?

[Halligalli (Gast)]

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 ?

[Bürovorsteher (Gast)]

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

[MaWin (Gast)]

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).

[Leroy M. (mayl)]

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. ;)

[Ach Du grüne Neune (Gast)]

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.

[Alexander (Gast)]

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.

[S. R. (svenska)]

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ß.

[Wolfgang (Gast)]

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?

[Jemand (Gast)]

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

[Niemand (Gast)]

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?

[Marvin M. (Gast)]

http://www.mycpu.eu/

Da gibt's auch ne Grafikkarte aus TTLs ;)

[georg (Gast)]

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

[dasrotemopped (Gast)]

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.

[Peter D. (peda)]

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.

[Peter D. (peda)]

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.

[Photovoltinator (Gast)]

Alexander schrieb:
> Just four fun.

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

SCNR

[Halligalli (Gast)]

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.

[georg (Gast)]

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

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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 :-)

[Soul E. (Gast)]

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.

[Halligalli (Gast)]

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  :-)

[S. R. (svenska)]

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...

[Halligalli (Gast)]

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.

[Dergute W. (derguteweka)]

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

[Halligalli (Gast)]

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.

[georg (Gast)]

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

[Dergute W. (derguteweka)]

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

[S. R. (svenska)]

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.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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  :-)

[Halligalli (Gast)]

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. (derguteweka)]

janeeeisklaaa

[Halligalli (Gast)]

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 ...

[Dergute W. (derguteweka)]

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

SCNR,
WK

[Halligalli (Gast)]

Vielleicht genügt es, das Ding als imaginäres Projekt zu entwickeln ?

[Asche (Gast)]

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

[Stefan F. (Gast)]

> 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.

[F. F. (foldi)]

Leroy M. schrieb:
> Das ist der Grund, das zu machen.

Mach du doch!

[Halligalli (Gast)]

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.

[Stefan F. (Gast)]

> Ich muss nur noch ein Malprogramm finden

Für Diagramme ist yEd meine erste Wahl.

[Halligalli (Gast)]

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 ?

[Halligalli (Gast)]

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 ?

[F. F. (foldi)]

Stefanus F. schrieb:
> Für Diagramme ist yEd meine erste Wahl.

Geiles Programm, Stefan. Danke!

[S. R. (svenska)]

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?

[Halligalli (Gast)]

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...

[Halligalli (Gast)]

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.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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!

[Codix (Gast)]

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.

[Halligalli (Gast)]

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.

[Thomas W. (diddl)]

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.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

@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.

[Halligalli (Gast)]

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.

[S. R. (svenska)]

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.

[Halligalli (Gast)]

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).

[S. R. (svenska)]

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.

[Codix (Gast)]

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.

[Codix (Gast)]

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

[Codix (Gast)]

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

[Max S. (maximus-minimus)]

Gibt es denn schon Fotos vom jetzigen Status?

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

Nachtrag 2:

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

[S. R. (svenska)]

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.

[Halligalli (Gast)]

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  :-).

[Halligalli (Gast)]

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...

[S. R. (svenska)]

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?

[Halligalli (Gast)]

S. R. schrieb:
> Was willst du denn damit sagen?

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

[Halligalli (Gast)]

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...?

[S. R. (svenska)]

...ich bin dann mal raus.

[Halligalli (Gast)]

S. R. schrieb:
> ...ich bin dann mal raus.

Kein Humor ? ... Schade ...

[S. R. (svenska)]

Doch, aber nicht in einer technischen Diskussion.

[Halligalli (Gast)]

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...

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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.

[Dergute W. (derguteweka)]

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

[Halligalli (Gast)]

Mist...eine Zählerstufe zuwenig.... :-)

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

[Matthias K. (kannichauch)]

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.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

Kinder ... vergesst es... Papi hat gepfuscht  :-)

Jetzt aber ohne die Inverter!

[Dergute W. (derguteweka)]

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

[Halligalli (Gast)]

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.

[S. R. (svenska)]

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.

[Dergute W. (derguteweka)]

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

[Halligalli (Gast)]

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 :-)

[Halligalli (Gast)]

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

[Tom (Gast)]

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.

[Halligalli (Gast)]

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 
:-)

[S. R. (svenska)]

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. :-(

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

@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!

[Tippgeber (Gast)]

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.

[Halligalli (Gast)]

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...

[S. R. (svenska)]

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.

[Stefan F. (Gast)]

> 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.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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.

[2⁵ (Gast)]

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...

[Halligalli (Gast)]

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 ...

[Halligalli (Gast)]

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.

[MiMa (Gast)]

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

[S. R. (svenska)]

Halligalli schrieb:
> Kompressionsmethode

Das nennt man "Alignment".

[Halligalli (Gast)]

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  :-)

[Halligalli (Gast)]

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 ?

[Dergute W. (derguteweka)]

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

[Halligalli (Gast)]

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 :-)

[Halligalli (Gast)]

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...

[S. R. (svenska)]

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.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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. (svenska)]

Pic or it didn't happen.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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 ?

[Dergute W. (derguteweka)]

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

[Halligalli (Gast)]

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

[Halligalli (Gast)]

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.

[Dergute W. (derguteweka)]

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

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

[Halligalli (Gast)]

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.

[S. R. (svenska)]

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.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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.

[S. R. (svenska)]

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.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

"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.

[PCB (Gast)]

Seufz.

[S. R. (svenska)]

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.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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  :-)

[Halligalli (Gast)]

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

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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.

[Sepp (Gast)]

Mist...da fehlt eine Init1-Verbindungslinie im grossen Schaltplan ?  war 
ja klar...

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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. (svenska)]

Außerdem gilt "nur ein Nick pro Thread".

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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 ...

[Halligalli (Gast)]

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 ?

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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.

[Halligalli (Gast)]

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 ?

[S. R. (svenska)]

Halligalli schrieb:
> Sie sollen ein Signal verzögern,

Dafür gibt es Verzögerungsleitungen und Zähler.

[Halligalli (Gast)]

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.

[Tim (Gast)]

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!

[Halligalli (Gast)]

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  :-)

[Halligalli (Gast)]

Sagt mal kommen alle Dual-Port-SRAM von IDT und haben TTL-Pegel am 
Ausgang ? Das wäre schon recht komisch ...

[Dergute W. (derguteweka)]

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

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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:

[Ach Du grüne Neune (Gast)]

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.

[Ach Du grüne Neune (Gast)]

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.

[Stefan F. (Gast)]

Mit einem registrierten Account hättest du das falsche Bild löschen 
können.

[Ach Du grüne Neune (Gast)]

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.

[Stefan F. (Gast)]

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.

[Ach Du grüne Neune (Gast)]

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.

[Stefan F. (Gast)]

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.

[Halligalli (Gast)]

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) ?

[Stefan F. (Gast)]

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.

[Halligalli (Gast)]

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.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Wenn dir 74HC zu langsam ist, dann nimm 74AC.
Aber nur da wo dus brauchst, die Flankensteilheit stellt dann so langsam 
Anforderungen ans Layout.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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 ...

[Halligalli (Gast)]

Und schon ist eine Lösung gefunden: H-Sync blockiert den möglichen Puls 
während seiner Dauer.

[Halligalli (Gast)]

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.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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.

[Halligalli (Gast)]

Kannst du den Link nochmal posten ? Was heisst eig. NOS ....sheis 
google...

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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.

[Halligalli (Gast)]

Dank dir!

Es sieht aus als müsste ich FPGA lernen um weiterzumachen, denn 
Originalbausteine aus den 70ern sind keine langfristige Lösung.

[Tim (Gast)]

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?

[Halligalli (Gast)]

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 ?

[Dergute W. (derguteweka)]

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

[S. R. (svenska)]

Halligalli schrieb:
> In meiner zusammenstürzenden Welt war das Basteln mit diskreten
> Logikbausteinen noch möglich ...:-)

Das geht auch heutzutage noch. Mein Z80 lebt.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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?

[Thomas W. (diddl)]

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.

[Halligalli (Gast)]

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...

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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.

[Dergute W. (derguteweka)]

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

[S. R. (svenska)]

Mw E. schrieb:
> Z80 aus TTL Gattern?

Natürlich nicht. Nur der Rest außen rum.

[Halligalli (Gast)]

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).

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

Verd.... Der Pix-X-Zähler geht natürlich mit 2 Leitungen zur 
2-aus-8-Logik...

[Halligalli (Gast)]

nach dem Latch.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

Upps...dafür muss erstmal das Bitpaar weitergereicht worden sein ...seht 
die Zeichnung mehr als Skizze an :-)

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

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 ?

[Horst (Gast)]

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.

[Halligalli (Gast)]

Nagut ich werde mich erst wieder melden wenn es fertig ist :-)

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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

[Halligalli (Gast)]

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 (Gast)]

Irgendwie macht mir das Steckbrett ein bisschen Angst  :-)

[Ach Du grüne Neune (Gast)]

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.   :)

[Halligalli (Gast)]

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.

[Halligalli (Gast)]

Und Sync-Erzeugung ist auch schon in den 60 drin.

[Halligalli (Gast)]

Ich denke das könnte interessant sein:

Nach dem Aufbauen des Sync-Steuer-Teils (links oben auf dem Steckbrett) 
wollte ich es mit der kleinen Testbeschaltung in der Mitte des 
Steckbrettes überprüfen. Nachdem ich einen Fehler mit einer vergessenen 
Drahtbrücke beseitigte zeigte sich das angehängte Bild am Monitor. Da es 
nicht ganz wie erwartet funktioniert (das letzte Drittel des Bildes 
fehlt) machte ich mich auf die Fehlersuche.

Es hat sich herausgestellt dass die Comparatoren im Horizontalteil 
zweimal innerhalb des aktiven Bit8 des Horizontalzählers auslösen. Ich 
habe nämlich die unteren 8 Bit des Zählers an die Comparatoren 
angeschlossen anstelle der oberen 8. Dadurch sind sämtliche 
Horizontal-Signale fehlerhaft.

Dass man überhaupt ein buntes Bild sieht hängt kurioserweise damit 
zusammen, dass der Fehler genau die Frequenz des H-Sync-Signals hat  :-)

Ich habe mir die Comparatoren vom youtube-Video zum Vulcan-74-Projekt 
abgeschaut, aber nicht die Schaltung dazu...

[Ach Du grüne Neune (Gast)]

Halligalli schrieb:
> Ich denke das könnte interessant sein:

Ja, ist es. Auch das Steckbrett sieht sogar sensationell aus. Wenn du 
die Schaltung überarbeitet hast und du die Schaltung auf's geätzte Board 
übertragen hast, könntest du das Steckbrett mit Schaltung und Demografik 
als Leihgabe dem Siemens Nixdorf Museum in Paderborn überlassen.

[Halligalli (Gast)]

Ach Du grüne Neune schrieb:
> Wenn du
> die Schaltung überarbeitet hast und du die Schaltung auf's geätzte Board
> übertragen hast, könntest du das Steckbrett mit Schaltung und Demografik
> als Leihgabe dem Siemens Nixdorf Museum in Paderborn überlassen.

Ach, so schwer ist es nicht. Es zieht sich nur ewig hin. Zum Glück sah 
ich dieses Video wo der Typ zeigt wie man Drahtbrücken einfach mit der 
geraden manuellen Abisolierzange herstellt. Ich habe jetzt darin eine 
Routine. Der Draht ist aus einem Mehrdraht-Telefonkabel aus dem 
Baumarkt, die Abisolierzange gab es nur ausschliesslich auch in dem 
Baumarkt mit dem (exklusiven ?) 0,6mm-Durchmesser.

Der Fehler mit den falsch angeschlossenen Comparatoren betrifft übrigens 
nicht den V-Sync-Teil, da das Zeitfenster in dem das oberste Zählerbit 
auf 1 steht nur kurz ist. Auch kann ich den Horizontal-Teil leicht 
zurecht ändern ohne ihn groß zu zerlegen. Ich deklariere das Bit0 der 
Comparatoren zu Bit7, verbinde den einen Vergleichswert neu und 
schliesse die andere Seite an Bit8 des Zählers an. Dann noch ein paar 
Drähte an den Gatter ändern und fertig.

[Halligalli (Gast)]

So...jetzt funktioniert alles!

Es war aber kein Comparator-Überlauf wie ich erst vermutete sondern eine 
Störspitze weil 8 Busleitungen (an den 74ALS-Zählerausgängen) 
gleichzeitig auf Null gingen. Ich habe 2 Zähler mit der HCT-Version 
ersetzt, nur der erste Zähler musste ALS bleiben da er schnell sein 
musste. Das Umlegen der Comparatoren auf die oberen Zählerleitungen hat 
aber trotzdem geholfen bzw. die Funktion der Schaltung erst ermöglicht. 
Dadurch dass die Comparatoren an den oberen Zählerleitungen hängen sind 
sie schon durchgesteuert, bevor das unterste Zählerbit auf 1 (wichtig) 
geht. Dieses unterste Zählerbit geht dann über 2 schnelle ALS-Gatter und 
setzt alle Zähler zurück am Zeilenende. Anders wäre wohl so eine 
horizontale Comparator-Sync-Schaltung wohl nicht möglich gewesen.

Ich habe auch eine obere weisse Zeile in die Testschaltung eingebaut 
damit man die vertikale Stabilität prüfen kann. Links am Rand es Fotos 
fehlen 5 Farben da ich den früher beginnenden Pixeltakt der Pipeline 
angezapft habe. Dafür sieht man den Anfang der Farbpalette nochmal 
rechts wo schwarz in rot übergeht. Ganz am rechten Rand fehlt ein Stück 
Palette weil die Handy-Kamera das irgendwie unterschlagen hat 
(vielleicht Überbelichtung).

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Das klingt so als solltest du ein paar D FlipFlops einbauen zur 
Synchronisierung.
Bei 30° in Sibirien mit Mondschein fängt die Schaltung sonst sicher an 
zu zicken.

[Halligalli (Gast)]

Es sind ein paar Flipflops drin!

Krasser ist nur die Pipeline-Zähler-Steuer-Logik mit ihren 8 Flipflops. 
Ich habe die Bausteine schon auf dem Steckbrett, möchte aber erst die 
8-Steuerpulse-Schaltung mit den 2 Schieberegistern testen (meine 
Eigenentwicklung  :-)  ).

Bisher hat noch nie was beim Einschalten funktioniert, daher bin ich 
schon abgehärtet und erwarte nicht zuviel  :-)

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

AH!
Die Falle der Asynchronen Zähler.
Nimm Synchrone wie:
74ALS867, 74ALS869, 74AS867, 74AS869

Deine D-FF nutzte aber als RS-FF ;)

Ich meinte eher das Prinzip:
Logikwolke - Register - Logikwolke - usw
Also eine Pipelined Architektur.

Dann ist es egal inwiefern die Logik wackelt/glitcht, erst mit einer 
neuen Taktflanke wird das Ergebnis übernommen.

[Halligalli (Gast)]

Die Synchronzähler brauchen immer einen Begleittakt zum Laden und 
Rücksetzen - das ist kaum machbar ohne aufwendig am Takteingang 
rumzubasteln. Das Angebot an lieferbaren Zählern ist auch ziemlich 
begrenzt. Die 193er können vor-/rückwärts-/asynchron laden/rücksetzen 
...einfach toll   :-)

[Halligalli (Gast)]

Wenn das finale Konzept steht kann man ja alles nochmal überarbeiten um 
zu schauen wo Bausteine eingespart werden können. Vielleicht spart eine 
Lösung mit Synchronzählern ja ein paar Gatter... dieser Aufbau ist 
erstmal zum leichten Ändern gedacht und er scheint ja die nötigen 
Signale zu liefern...

[S. R. (svenska)]

Halligalli schrieb:
> Wenn das finale Konzept steht kann man ja alles nochmal überarbeiten um
> zu schauen wo Bausteine eingespart werden können.

Naja, wenn du da so rangehst, hätte ich noch einen sinnvollen 
Alternativansatz gehabt: Beschreibe die ganzen TTL-Bausteine als 
VHDL-Modelle und entwickle die Schaltung im FPGA. Breadboards sind nicht 
für viele Steckzyklen geeignet.

Der vom Fritzler vorgeschlagene Ansatz ist definitiv zuverlässiger, aber 
in TTL ziemlich sicher mit mehr Aufwand verbunden.

Ein Bekannter hat vor einiger Zeit eine VGA-Logik in TTL realisiert 
(Textmodus 80x50, 25 MHz Pixeltakt). Viele Bausteine waren nicht nötig, 
die Schaltung war allerdings durch die kreative Nutzung von Bitmustern 
auch gut optimiert.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Halligalli schrieb:
> Die Synchronzähler brauchen immer einen Begleittakt zum Laden und
> Rücksetzen - das ist kaum machbar ohne aufwendig am Takteingang
> rumzubasteln.

Dein Pixeltakt ist doch durchgängig? Also ist das dein bgleittakt und zu 
dem willste doch eh alles synchron halten.
Da du ja nur mit 0en lädst wär selbst das kein Problem.
Denn meinen vorgeschlagenen IC gibts auch mit async reset, die wissen 
warum!
Hab jetz aber nich im Kopf ob 867 oder 869 der mit async war, guck ins 
DB.

[Halligalli (Gast)]

Die Synchronzähler muss ich mir später mal reinziehen, ich war damals 
beim Auswählen etwas erschreckt von den komischen 74xx-Nummern die ich 
noch nie gesehen hatte.

Ich habe nun die (aktuelle, vielversprechende) Zähler-Steuerlogik 
aufgebaut. Das hat recht lange gedauert da ich nur in Phasen erhöhter 
Konzentration gesteckt und alles doppelt und dreifach überprüft habe.

Die vielen neuen Bausteine in der Mitte sind nicht etwa die Pipeline 
sondern nur die Tile-/X-/Y-Zähler und ein wenig Beilogik ... aber nicht 
alle Gatter werden verwendet.

[Halligalli (Gast)]

So...die Zähler wären verdrahtet. Man kann alles schaffen wenn man 
wenigstens ein paar Drahtbrücken pro Tag macht  :-) Leider kann ich kein 
Bild hochladen, warum auch immer.

Mir fiel auf dass die 12MHz-Takt-Leitung um die 50cm+ lang wird, denn 
die Pipeline geht wohl bis zum rechten Rand des Steckbretts. Ich habe 
bereits den Treiber der Takt-Leitung auf HCT umgestellt und hoffe dass 
es keine Schwierigkeiten gibt.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Baumförmige Taktverteilung mit mehreren Treibern führt da zum Erfolg ;)
Oder ein Quarzoszillator treibt die Eingänge eines 245ers und jeder 
Ausgang des 245er dann ~20 Takteingänge.

Alles an eine Taktleitung tackern wird schiefgehen.
Bzw um wieviel Takteingänge reden wir denn?
Mal abgesehen von der Leitungslänge.

[Halligalli (Gast)]

Mw E. schrieb:
> Alles an eine Taktleitung tackern wird schiefgehen.
> Bzw um wieviel Takteingänge reden wir denn?
> Mal abgesehen von der Leitungslänge.

Es geht um die 10 getakteten Latches der Pipeline, genauer gesagt wird 
der nicht gepufferte Takt verwendet. Der um einen Puffer verzögerte Takt 
soll dann lediglich 4 Speicher ansteuern.

Im günstigsten Fall ist die Leiterlänge 50cm, im ungünstigsten um die 
60cm. Vielleicht kann ich durch geschickte Platzierung Schlimmeres 
vermeiden.

Das Ziel ist ja dass bei jeder ansteigenden Taktflanke der Wert am 
Eingang übernommen wird. Da gibt es leider Haltezeiten, weswegen ich ja 
den gepufferten Takt benötige - der stellt sicher dass die minimal 
benötigte Haltezeit am Eingang der Latches eingehalten wird. Wenn ich da 
jetzt den Takt zwischenpuffern soll dann wird es etwas kompliziert  :-) 
mal sehen.

Bild hochladen geht immer noch nicht... vielleicht darf man als Gast nur 
eine bestimmte Anzahl davon hochladen.

[G. O. (aminox86)]

Tapfer, tapfer - lass' dich nicht irre machen - weiter so. Ein ähnliches 
Projekt habe ich vor Jahren im Forum veröffentlicht, einfach mal nach 
"Eine VGA-Karte, fast diskret" suchen. Vielleicht ist die eine oder 
andere Idee aus dem Projekt ja für dich nützlich.

Halligalli schrieb:
> Im günstigsten Fall ist die Leiterlänge 50cm, im ungünstigsten um die
> 60cm. Vielleicht kann ich durch geschickte Platzierung Schlimmeres
> vermeiden.

Die Jungs von TI haben sich in ihrem "TTL-Kochbuch" über Seiten mit 
diesem Problem (dh lange Signalleitungen und ähnliches) beschäftigt, 
denn zur Erscheinungszeit dieses Buches hat man sich mit IC-Gräbern auf 
wirklich großen Leiterplatten in Fädeltechnik herumgeschlagen. Ist 
sicher antiquarisch aufzutreiben.
Und vielleicht noch ein Tipp: Du setzt an verschiedenen Stellen ALS-IC 
ein. Diese Bausteinfamilie ist für ihr Störverhalten berüchtigt. Du 
solltest versuchen, wo immer möglich und natürlich noch erhältlich, 
diese ICs durch Bausteine der 'F'-Familie (Fast) zu ersetzen. Der 
FAN-OUT und das Übertragungsverhalten der ICs ist fast identisch mit der 
S/AS/ALS-Familie, aber sie stören so gut wie gar nicht, denn ihr 
interner Aufbau ist stark an die ECL-Technik angelehnt (schlucken halt 
ordentlich).
Also, gutes Gelingen.

[Halligalli (Gast)]

Danke für den Rat mit der F-Logikfamilie! Ich habe die ALS-Familie 
gewählt das sie bei Mouser und Co. gut verfügbar war und doppelt so 
schnell wie HCT-Logik ist.

Ich habe übrigens das Takt-Problem gelöst: rechts gleich einen Puffer 
hingesteckt und den Pixel-Clk hingeführt. Von da zurück zum Pix_X-Zähler 
und einige Male dann von diesem Puffer zu den Latches und SRAMs der 
Pipeline.

Es sieht aus als ob sich der Aufbau etwas hinzieht … aber ich habe 
berechnet dass ich bei einem Mindest-Fortschritt von 4 Drähten am Tag 
gegen Ende April die Pipeline verdrahtet habe! Das Problem ist dass 
jeder Draht ein Unikat ist und vorher alles geplant werden will, sonst 
hat man ein 3D-Knödel ohne rechten Halt.

Ich weiss nicht ob man so große Schaltungen auf dem Steckbrett aufbaut 
oder lieber schnell eine Platine layoutet und ätzen lässt. Doch bei 
dieser Schaltung ist gar nichts sicher  :-)  Es ist ein Wunder dass der 
Sync-Teil funktioniert. Aber es scheint auch die Steuerlogik und der 
Zählerteil größtenteils zu funktionieren, denn ich habe auf dem 
Oszilloskop Vielversprechendes gesehen.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Was gut werden soll braucht eben Zeit ;)

Wenn du da jetzt echtes TTL verbaust solltest du so langsam mal gucken 
wie der Stromverbrauch aussieht.
Der 7805 mit dem kleinen Kühler am oberen Bildrand sollte da bald an 
seine Grenzen kommen.
Ein Meanwell 5V SNT mit nen paar Amperchen kost ja nicht die Welt.

Ansonsten gibts noch ACT, ist schneller als HCT kommt aber glaube nicht 
gaaanz an F ran.
Zudem gibts noch ganz neue 74er Serien wie ALVC mit 2ns Laufzeiten, aber 
eben nurnoch 3,3V und SMD.
(einfach mal bei Mouser inspirieren lassen).

Dass man so das CLK Prob löst hab ich dir ja gesagt ;)

Eigentlich baut man auf dem Steckbrett nur Testmuster auf.
Also in deinem Falle einzelne in sich abgeschlossene Baugruppen.
Nach dem Test lässt sich dann das Layout bauen mit den anderen 
Baugruppen.

Eine VHDL Simulation wollteste ja nicht.
So haben wir das bei MIPS TTL gemacht.
Erst den Schaltplan entwickelt, den in VHDL nachgebaut und simuliert.
Da fanden sich massenweise Bugs die man im Schaltplan einfach nicht sah.
Danach wurde Layoutet, bestellt, bestückt, angesaftet uund lief.
(kleinere Bugs zeigten sich dann doch noch in der Physik)

[Stefan F. (Gast)]

Sag mal, bereiten Dir die parasitären Widerstände in der Stromversorgung 
keine Probleme? Diese Steckbretter haben ja beträchtliche 
Übergangswiderstände an den Kontakten und innerhalb der 
Stromversorgung-Leisten.

Ich würde dort an Deiner Stelle auf eine sternförmige Verkabelung 
setzen, so dass jedes Steckbrett eigene Leitungen zum Sternpunkt hat.

Ich bin nicht sicher, dass deine Kompromisslösung (Gitterstruktur) eine 
gute Idee ist, denn das findet man so in keinem Lehrbuch.

[F. F. (foldi)]

Bin gespannt darauf, ob es läuft.

[Halligalli (Gast)]

Ich habe mal mit dem Baumarkt-Multimeter die Gleichstrom-Aufnahme des 
Sync-Teils damals gemessen: etwa 300mA. Die Steuerlogik links unten ist 
nur sehr kurz zu Beginn einer sichtbaren H-Sync-Phase aktiv und dürfte 
fast nichts verbrauchen. Der Tile-Zähler mit seinen drei 74ALS191 
bekommt nur alle 8 Pix_Clk einen Zählpuls. Der Pix_X-Zähler (ALS) läuft 
im sichtbaren Bildbereich dauernd mit 12 MHz. Der Pix_Y-Zähler ist HCT 
und zählt nur jede zweite sichtbare Zeile hoch.

Die Pipeline dürfte ziemlich Strom ziehen weil da alles ständig läuft 
bei jedem Pix_Clk im sichtbaren Zeilenbereich.

Als ich damals mit der Testschaltung das Peletten-Testbild machte, fiel 
mir auf dass etwa 0,5V Versorgungsspannung unten beim 
D/A-Wandler-Treiber fehlten. Das dürfte die Farbtöne um 10% dunkler 
gemacht haben ...

[derjaeger (Gast)]

Respekt an den Breadboard-Aufbau und das du da noch weiter dran bist.
Kenne diesen Thread vom letzten Jahr noch.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Ja richtig, die HCT ziehen nur wirklich Strom wenn die was zu tun haben 
(CMOS).
Bei den TTL fließt aber immer Strom und ddas wird auch nicht wirklich 
mehr wenn dessen Pegel sich ändern.

[Halligalli (Gast)]

Ich habs gewusst: am 1. April funktioniert nix  :-)  Ich bin nämlich mit 
der Verdrahtung der Pipeline und des VGA-Ausgangs fertig geworden und 
hab auch noch eine neue Stromversorgung spendiert (mit 1,5 Ampere 
maximal auf 5,2V eingestellt, dadurch hat der D/A-Puffer 4,8V 
Versorgungsspannung).

Das Testbild läuft irgendwie durch bzw. verändert sich rhytmisch, ich 
kann aber nicht sagen ob es eine Fluktuation in einem Speicher ist, ein 
Sync-Problem oder etwas mit den X-Y-Tilezähler-Latches oder gar der 
Steuerlogik der Zähler.

Morgen packe ich das Oszilloskop aus ...

[Stefan F. (Gast)]

Was machst du damit, wenn du fertig bist? Spendest du es einem Museum?

[H-G S. (haenschen)]

Stefanus F. schrieb:
> Was machst du damit, wenn du fertig bist? Spendest du es einem Museum?

Nein, die wollen nur hochkonforme Vorzeigespender. Ausserdem ist es 
nicht transportfähig - ich bange bei jedem Stösschen, und die 
Beryllium-beschichteten Steckbrettkontakte sollen irgendwie ungesund 
sein ... mein Loch-Vorstosser-Draht hat schon so eine Schicht auf dem 
Kupfer - schlabber  :-)

Ich habe vergessen sie aus dem Warenkorb bei Mouser zu nehmen nachdem 
ich gesehen habe dass da noch eine dicke Steuer draufkommt. Mann war das 
eine teure Bestellung - der Paketbote hat das Paket einfach vor die 
Haustür gelegt weil keiner Zuhause war ... nagut der Eingang war schon 
ziemlich geschützt und ich kam relativ früh nach Hause.

Ähm... ich werde den Konzept-Prototypen zerlegen müssen um Platz für 
Neues wie eine Sprite-Engine zu schaffen. Davor muss ich es aber noch 
fertig machen: Zeilen-Interrupt, Adress-Dekoder und 8051 samt Speichern 
müssen noch auf das Steckbrett. Danach muss eine Funktions-Demo 
geschrieben werden.

[H-G S. (haenschen)]

OMG ... meine wahre Identität wurde entblösst ... ich bin geliefert  :-)

Nein Schmarrn - ich habe keine Lust das nochmal zu tippen. Also 
Entschuldigung Mods ...

[Halligalli (Gast)]

Nach langer Mess- und Ausbesserungs-Phase bin ich zufällig darauf 
gekommen, dass wenn ich den Finger auf die Clk-Leitung des Tile-Zählers 
halte ein stabiles Bild angezeigt wird. Davor lief es seltsam durch und 
ich befürchtete das Schlimmste.

Ein 4k7-Widerstand einmal als Pullup und einmal als Pulldown brachte 
nichts. Aber wenn ich einen Tastkopf des Oszilloskops an die Clk hing 
half es - auch wenn die Masse dieses Tastkopfes nicht angeklemmt war.

Was könnte das für Fehler sein ? Ich konnte den Clk nicht messen weil ja 
durch das Anschliessen des Tastkopfes der Fehler nicht mehr auftrat ... 
Es waren vorzeitige Pegeländerungen des Ausgangs des synchronen 
Tilezähler-Bausteins (74ALS191) zu sehen. Aus einem steten Pegelwechsels 
des Ausgangs-Bits-0 (wie beimn Hochzählen üblich) wurde irgendwann eine 
Spitze von 160ns. Könnte der Linearregler stören der direkt über dem 
Tile-Zähler sitzt ? Oder gar das Busleitungs-Gebüsch zwischen der 
Tile-Zähler-Einheit ?

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Das klingt doch nach dem Klassiker Wellenwiderstand.
Es braucht also eine Terminirung unf 4k7 sind da zu hochohmig.

Dazu gibts hier nen Artikel:
https://www.mikrocontroller.net/articles/Wellenwiderstand

[Soul E. (Gast)]

Halligalli schrieb:

> Ein 4k7-Widerstand einmal als Pullup und einmal als Pulldown brachte
> nichts. Aber wenn ich einen Tastkopf des Oszilloskops an die Clk hing
> half es - auch wenn die Masse dieses Tastkopfes nicht angeklemmt war.

Dann löte mal 18..47 pF von dem Signal nach Masse.

Letztendlich kommt Deine Clk zu früh, d.h. die Durchlaufzeit ist 
woanders zu hoch, so dass die Daten beim Clocken noch nicht stabil sind.

Klassische Pfuschlösung aus den '80ern wären 180 Ohm in Reihe und 
dahinter einige 10 pF nach Masse, der RC-Tiefpass liefert die benötigte 
Verzögerung. Besser wären Gatter als Verzögerungsglieder, z.B. zwei 
Inverter oder ein ungenutztes AND oder OR.

[Halligalli (Gast)]

Mw E. schrieb:
> Das klingt doch nach dem Klassiker Wellenwiderstand.
> Es braucht also eine Terminirung unf 4k7 sind da zu hochohmig.

Kann sein: es ist ein 74ALS08-Ausgang der über einen etwa 17cm-Draht und 
da dran noch zwei 3,5cm-Drähte insgesamt drei 74ALS191-Clk treibt.

Die TTL-Dinger sollen ja nicht viel Strom hergeben... vielleicht würde 
Serien-Terminierung reichen. Was für einen Widerstand bräuchte es da ? 
(Google spuckt wieder unbrauchbares Zeug aus).

soul e. schrieb:
> Letztendlich kommt Deine Clk zu früh, d.h. die Durchlaufzeit ist
> woanders zu hoch, so dass die Daten beim Clocken noch nicht stabil sind.

Ich hoffe doch nicht...das war das Horrorszenario von heute Mittag, wo 
ich schon an der Machbarkeit zweifelte. Es ist aber genau berechnet, wie 
die Tile-Zähler-Clk vom Pix_X-Zähler über ein paar wenige schnelle 
ALS-Gatter angesteuert wird.

[Halligalli (Gast)]

Versuche ergaben: mit 22-Ohm-Serienwiderstand zuckt noch eine Zeile. Mit 
50 oder auch 120 Ohm ist alles stabil - ich habe den 50 Ohm verwendet, 
um das Signal vielleicht nicht zu sehr zu verschleifen.  Danke für den 
Vorschlag @fritzler!

In der Hinsicht wundert es mich doch dass es zu funktionieren scheint: 
am Ende der Pipeline laufen etwas über 20cm lange Pix_Clk-Leitungen zu 
den Bausteinen. Aber die kommen von einem 74HCT244-Treiber - vielleicht 
ist es da nicht so schlimm mit Reflektionen.

Jetzt kann ich zum nächsten sichtbaren Fehler übergehen: den etwa 5 
gleich bleibenden Pixeln am rechten Bildschirmrand...

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Dann lag ich ja richtig.
Wenn Reflektionen auf der CLK Leitung sind, dann kann der IC einen 
zweiten CLK Puls erkennen wo keiner ist.
Dann haste 2 davon und es sieht aus als würde der IC zu früh durch 
takten.

Leider kann ich erst jetzt wieder Antworten zu dem Widerstandswert, aber 
du hast ja schon experimenteiert.
Das darf ruhig etwas mehr sein, bei TTL spielt man so im Wert um 100R 
rum.
Aber wenn 50R auch gehen, dann gehts natürlich auch ;)

Im Artikel steht ja, dass die Terminierung eine Impedanzanpassung ist 
und die Impedanzen für ein paar Kabel/Leiterbahnen sind ja gegeben.

Halligalli schrieb:
> In der Hinsicht wundert es mich doch dass es zu funktionieren scheint:
> am Ende der Pipeline laufen etwas über 20cm lange Pix_Clk-Leitungen zu
> den Bausteinen. Aber die kommen von einem 74HCT244-Treiber - vielleicht
> ist es da nicht so schlimm mit Reflektionen.

Reflektionen gibts wenn die Ausgangsimpedanz des Treibers nicht zur 
Impedanz der Leitung passt. Eine andere 74er Serie hat andere 
Ausgangstreiber.
Trotzdem kanns nicht Schaden die zu terminieren.

5 gleich bleibende SPalten klingen wie ein Pixelzähler der zu früh 
zurückgesetzt wird?
Also der ind en Framebufefr schreibende, ausgelesen werdense ja 
anscheinend.

[Stefan F. (Gast)]

Wir haben euch alle verstanden.

Das Wort heißt aber "Reflexionen" mit "x".

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Nicht vorm Kaffee trinken posten...

[Halligalli (Gast)]

Mw E. schrieb:
> 5 gleich bleibende SPalten klingen wie ein Pixelzähler der zu früh
> zurückgesetzt wird?
> Also der ind en Framebufefr schreibende, ausgelesen werdense ja
> anscheinend.

Es gibt keinen Framebuffer - alles wird in Echtzeit aber 5 Pixel im 
Voraus gerendert.

Der Fehler mit den 5 Pixeln am Zeilenende kam von einem zu langsam auf 0 
gehenden D/A-Treiberbaustein. Der nächste sichtbare Fehler hat es aber 
in sich: eine um ein Tile nach rechts verschobene erste Halbzeile zu 
Beginn jeder neuen Tile-Zeile. Um das zu beheben muss ich die 
Zähler-Steuerlogik umbauen. Auch sieht es aus als ob am linken 
Bildschirmrand ein Pixel zuviel ist und dafür rechts eins zuwenig - ich 
glaube das wäre dann der letzte Fehler.

[Joe F. (easylife)]

Bin gerade erst auf diesen Thread gestossen und wollte nur kurz mal 
meinen Respekt zollen.
Es wird noch eine Weile dauern, bis mir das Grinsen beim Anblick der 
Breadboard-Wand aus dem Gesicht geht.
Die parasitären Probleme sind ja bekannt, ich bin sehr gespannt, wo das 
ganze hingeht und schließe mich der Meinung an, dass das Ding später 
durchaus in ein Museum passen könnte (z.B https://www.mfk-berlin.de).
Ich sehe übrigens keinerlei Stützkondensatoren an deinen ICs... Absicht?

[Halligalli (Gast)]

Joe F. schrieb:
> Ich sehe übrigens keinerlei Stützkondensatoren an deinen ICs... Absicht?

Man sieht sie nicht, aber jeder Baustein hat einen ... da sind schon 
10uF an Keramikkondensatoren auf dem Steckbrett  :-)

Und fürs Museum reicht es nicht - jede bessere Firmen-Ingenieurs-Bude 
hat größere Sachen zusammenverdrahtet...

[Halligalli (Gast)]

Ich komme vom Weg ab: ich musste durch Probieren die Schaltung so 
einstellen, dass die 5-Stufen-Pipeline 6 Vor-Spül-Takte bekommt und mit 
dem 7. Takt das erste Pixel sichtbar wird. Das betrübt mich doch sehr 
weil es war messtechnisch und logisch gar nicht nachvollziehbar bzw. zu 
verhindern... Doch die Bildschirmanzeige wollte es so - vielleicht liegt 
es ja am VGA-zu-HDMI-Konverter, ich habe leider meinen alten 
VGA-Buchsen-Monitor nicht mehr.

Ich habe mal mit dem besch... 10-Euro-Baumarkt-Multimeter eine 
Stromaufnahme von 600mA bei 9V gemessen (im 10A-Messbereich - vor dem 
Spannungsregler, da am sichersten für die Schaltung).

Jetzt kommt erstmal eine Erweiterungsphase: Zeilen-Interrupt, 
Adress-Dekoder und 8051er mit Speichern müssen mit auf das Brett. Das 
dauert jetzt etwas   :-)

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Halligalli schrieb:
> Und fürs Museum reicht es nicht - jede bessere Firmen-Ingenieurs-Bude
> hat größere Sachen zusammenverdrahtet...

Es steht immernoch das Angebot das Teil mal an den MIPS TTL Rechner zu 
stöpseln: http://www.fritzler-avr.de/spaceage2/index.htm

Das Speicherinterface ist simpel:
- 32Bit Daten (davon wirste ja sicher nur 8Bit brauchen)
- 32Bit Adresse, die kann man mit 3 Vergleichern eindampfen auf nCE und 
Subadresse für deine Register
- nWE
- nRD

Dein Design ist jetzt völlig Taktsynchron oder?
Nocht, dass dir da sone Verzögerungslette von Gattern zwischenschießt?

[Halligalli (Gast)]

Mw E. schrieb:
> Es steht immernoch das Angebot das Teil mal an den MIPS TTL Rechner zu
> stöpseln:

Wenn es läuft mache ich ein Layout (nach der Optimierung) und ihr könnt 
eine Platine bestücken  :-)

Mw E. schrieb:
> Dein Design ist jetzt völlig Taktsynchron oder?
> Nocht, dass dir da sone Verzögerungslette von Gattern zwischenschießt?

Das Fehlerbild wäre dann bestimmt anders. Es wurden am Zeilenanfang 2 
Pixel aus dem letzten Tile der Zeile langgestreckt angezeigt. Das ist 
der Rest der am Zeilenende in der Pipeline verbleibt da der Pix_X-Zähler 
vorher abgeschaltet wird. Ich dachte das wird nach 4+1 Takten 
rausgespült am Zeilenanfang, da die ganze Pipeline bis zum VGA-Puffer 
nur 5 Stufen/Latches hat.

Endgültige Gewissheit wird es erst geben wenn der 8051 angeschlossen ist 
und den Speicher mit einem Testmuster füllt sowie ein wenig 
herumscrollt. Ausserdem besorge ich mir sowieso irgendwann einen 
VGA-Buchsen-Monitor, denn dieses ewige Umstöpseln am PC-Monitor nervt.

[Thomas S. (Gast)]

Was mir so auffällt. Ich sehe keinen einzigen Kondensator auf irgend 
einem Brett. Ich meine Elko's, So am uC, oder an den Speicher, und 
überhaupt.

Oder sehe ich falsch? - dann entschuldige bitte

[Halligalli (Gast)]

Thomas S. schrieb:
> Was mir so auffällt. Ich sehe keinen einzigen Kondensator auf irgend
> einem Brett. Ich meine Elko's, So am uC, oder an den Speicher, und
> überhaupt.

Das sind gelb-braune, winzige Dinger - die sieht man von oben nicht auf 
dem Smartphone-Foto. Die (100+) Tüte ist bald leer und ich muss 
Nachschub besorgen...

[Ach Du grüne Neune (Gast)]

Das Projekt gefällt mir immer besser :)

[Halligalli (Gast)]

Das könnte der neue Rekordhalter in Sachen Biegungen sein  :-)

[Stefan F. (Gast)]

Wenn das fertig ist, gehört es in ein Museum, finde ich.

[Halligalli (Gast)]

Stefanus F. schrieb:
> Wenn das fertig ist, gehört es in ein Museum, finde ich.

Ja: jemand muss die Threadseite ins Archive sichern lassen, nachdem ich 
ein letztes gutes Foto des (funktionierenden) Aufbaus eingestellt habe 
:-) Man sieht übrigens wie sich meine Drahtbiege-Fähigkeiten im Laufe 
des Aufbaus verbessert haben.

Ich muss jetzt nur noch tausend Busleitungen verbinden - es könnte sein 
dass ich irgendwann im Juli fertig bin.

Es ist auch noch ein Wettlauf gegen die Zeit: die fiese Katze hat 
herausgefunden dass ich vor Angst aufwache nachts wenn sie auf den PC 
springt und droht auf den Tisch mit dem Steckbrett zu steigen - ich muss 
dann aufstehen und schauen ob sie noch Futter hat oder sie nur einsam 
ist (ist nachtaktiv).

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Alleine, dass du die Muße hast die Kabel so ordentlich zu biegen.
Bei mir wär das der übelste Drahtverhau.

[Halligalli (Gast)]

Mw E. schrieb:
> Alleine, dass du die Muße hast die Kabel so ordentlich zu biegen.
> Bei mir wär das der übelste Drahtverhau.

Die Leitungen müssen zurückverfolgbar und notfalls verlegbar sein, falls 
irgendwo ein Fehler auftritt. Ich musste zB. die Zähler-Steuerlogik von 
8-Puls-Betrieb auf 16-Puls-Betrieb umbauen, und die saubere Verdrahtung 
hat es recht einfach gemacht. Die Farben helfen auch noch: rot/schwarz 
für Versorgungsspannung, weiss für statische Pullup/-downs, gelb für 
Takte, braun für normale Signale, grün für unteren Bus und blau für 
oberen Bus.

Ausserdem hoffe ich immer noch dass sich eine Leitungsführung über die 
Minus-Schiene des Steckbretts positiv auf die Störabstrahlung auswirkt. 
Auch ist immer ein kleiner Mindestabstand zwischen den Drähten vorhanden 
damit es nicht so stark überspricht.

Ich weiss nur noch nicht wie die langen Busleitungen zu den Speichern 
und Register-Latches am Ende aussehen werden - die müssen direkt 
Punkt-zu-Punkt damit sie nicht die 32cm Leitungslänge der HCT-Familie 
überschreiten...

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Wo hasten die 32cm für HCT her?
Bei nem Bus musste eher auf die kapazitive Last aufpassen bei einem 
"normalen" Gatter, sonst muss ein Bustreiber rein.

[Halligalli (Gast)]

Mw E. schrieb:
> Wo hasten die 32cm für HCT her?

Habe ich irgendwo im Netz aus google-Suchergebnissen. Das soll wohl die 
Grenze sein ab der Reflektionen auftreten (ohne Terminierung).

[Soul E. (Gast)]

Halligalli schrieb:

> Habe ich irgendwo im Netz aus google-Suchergebnissen. Das soll wohl die
> Grenze sein ab der Reflektionen auftreten (ohne Terminierung).

Reflektionen treten immer auf. Die Frage ist nur, ob sie Dich stören 
oder ob der eingeschwungene stationäre Zustand ("Ohmsches Gesetz") 
dominiert. Das hängt von der Frequenz (bzw bei Rechtecksignalen von der 
Flankensteilheit) und von der Lichtgeschwindigkeit ab.

"Unter lambda/4 ist unkritisch" wäre so eine Faustregel.

[Halligalli (Gast)]

Na toll: da kauft man sich billig mehrere Meter Telefonkabel aus dem 
Internet und dann ist die Qualität zu gut! Das (Voka-)Kabel lässt sich 
nicht am Ende aus dem Mantel ziehen wie bei den Baumarkt-Kabeln. Jetzt 
muss ich irgendwo einen günstigen Kabel-Längsschneider besorgen - ich 
klapper morgen die Baumärkte ab, wenn die nichts haben braucht es wohl 
einen aus dem Netz.

Aber die Farben und der Isolationsdurchmesser der Kabel-Adern sind 
perfekt - bei der Baumarktware schwankten grün und braun recht stark, 
auch der Isolationsdurchmesser war manchmal kleiner.

Ich war auch fleissig und habe das Tagespensum von 4 Drähten ziemlich 
eingehalten: Raster-Interrupt und Adressdekoder sind verdrahtet. Der 
Teil mit dem 8051 ist zur Hälfte verdrahtet - es müssen "nur" noch 
EEProm und SRAM angebunden werden. Danach gehts an die 
Freiluft-Direktverdrahtung.

[Bürovorsteher (Gast)]

> Das (Voka-)Kabel lässt sich
> nicht am Ende aus dem Mantel ziehen wie bei den Baumarkt-Kabeln.

Zuz meiner Zeit (TM) hatte Voka noch einen Reißfaden drin. Ist aber 
schon 40 Jahre her. 10 cm lang abmanteln und kräftig am Faden scharf 
über die Kante des Mantels ziehen.

[Halligalli (Gast)]

Bürovorsteher schrieb:
> Zuz meiner Zeit (TM) hatte Voka noch einen Reißfaden drin.

Leider reisst der fluffige "Faden" nach ein paar cm. Eigentlich ist es 
ein luftiges, pinseliges Büschel und noch 2 hauchdünne Fädelchen. Das 
metallische Äderchen reisst auch sofort.

Naja ... morgen gehts in die Baumärkte  :-)

[Halligalli (Gast)]

Ich bin mit 10 Euro davongekommen im Baumarkt :-) Es gab da so einen 
Abmantelwerkzeug mit Klingentiefen-Verstellung, und die Klinge dreht 
sich von selbst in die Richtung des durchgezogenen Kabels. Es braucht 
trotzdem ein wenig Übung und Geduld bei längeren Schnitten.

Meine Wahl, 0,6mm-Drähte zu benutzen scheint gar nicht mal so günstig 
gewesen zu sein. Es gibt diesen Durchmesser praktisch nur als 
Klingeldraht und nur mit geringer Farbauswahl - und scheinbar nicht 
einzelfarbig zu kaufen. Auch gibt es kaum gerade Abisolierzangen für den 
Durchmesser.

Aber es lässt sich gut damit fädeln, es passen mehr Drähte nebeneinander 
als mit den dicken 0,8er Drähten die man sonst so auf Steckbrettern 
benutzt - nur sollte man das Loch auf dem Steckbrett ein paarmal 
vorstechen, da es beim ersten Einstecken gern hakt und den Draht 
verbiegt.

[Stefan F. (Gast)]

Wenn wir später mal Fragen zu Steckbrettern haben, wissen wir jetzt, wen 
wir ansprechen müssen .-)

[Halligalli (Gast)]

Mw E. schrieb:
> Dein Design ist jetzt völlig Taktsynchron oder?
> Nocht, dass dir da sone Verzögerungslette von Gattern zwischenschießt?

Da ist ein einzelner Puffer (rechts oben in der Pipeline-Skizze) der 
dafür sorgt, dass es eine kleine "Hold"-Zeit gibt zwischen den 
SRAM-Ausgängen und den darauffolgenden Latches. Den Puffer kann man aber 
wahrscheinlich ausbessern/weglassen indem man nach jedem Speicher einen 
Puffer-Baustein am Ausgang anschliesst - dessen interne Signallaufzeit 
sollte genug Hold-Zeit liefern. Dieser Puffer war aber für die 
Steckbrett-Version günstig, da es die ganzen Speicher-Ausgangs-Puffer 
samt Verdrahtung einspart.

Weiterhin habe ich das H_Blank-Signal durch eine Puffer-Kaskade 
geschickt, um ein wenig mit dem sichtbaren Bildbereich herumspielen zu 
können. Dabei habe ich festgestellt dass es scheinbar unbedingt nötig 
ist, den D/A-Wandler-Ausgangspuffer mit einem Multiplexer anzusteuern. 
Nur dadurch lässt sich wohl eine blitzschnelle schwarz-Schaltung 
gewährleisten am Zeilenende. Die gegenwärtige Lösung (H_Blank steuert 
/OE des Puffers) braucht etwa 100ns um das VGA-Signal auf schwarz zu 
ziehen.

[Halligalli (Gast)]

Puh... 2 Monate hat sich das Verdrahten hingezogen - am Ende hat es viel 
Überwindung gekostet jeden Tag. Vor allem der 8051er war schwer zu 
verdrahten.

Jetzt kommt der Endspurt: die Freiluft-Verbindungen der CPU-Busleitungen 
zu den Dualport-RAMs und Register-Latches. Ich denke 2 Wochen dürfte das 
schon dauern.

Kurioserweise treiben die Bus-Puffer (74HCT244) die ganze Bus-Aktivität 
der CPU in die Freiluftverdrahtung - auch wenn sie nur Befehle aus dem 
EEPROM holt. Ich habe nämlich nicht daran gedacht dass ich zB. die 
Adresse A15 benutzen könnte um die Treiber erst dann einzuschalten, wenn 
die CPU etwas in den Tile-Engine-Speicherbereich schreiben will. Ich 
komme nicht mehr an die /OE-Leitungen der Bus-Puffer, da sie unter 
Drähten liegen - ich kann sie nichtmal abzwicken.

[Halligalli (Gast)]

Die Freiluftverdrahtung wäre fertig ... nur leider hat der 8051 von ebay 
einen Schuss und gibt kein /WR und kein /RD aus. Ich muss jetzt auf 
Ersatz warten.

Währenddessen habe ich die Schaltung an einen alten 4:3-TFT-Monitor mit 
VGA-Buchse angeschlossen. Wie gedacht zeigte sich ein anderes Bild an 
den Rändern: links war etwa 1 Pixel vom verdeckten Tile aus dem Rand zu 
sehen. Ich habe danach alles wieder auf 4+1-Pipeline-Takt-Funktion 
umgebaut und es wurde sogar noch schlimmer: man sah jetzt noch mehr 
Pixel am linken Rand.

Messungen ergaben aber dass alles irgendwie passt. Ich habe sogar das 
H_Blank vor dem DA-Wandler wieder auf Widerstände (470 Ohm) umgebaut, 
weil das nun in 20ns auf 0 schaltet (gemessen). Vorher zeigte sich 
sporadisch dass ein nacktes /OE manchmal zu einer Eauer-Eins am Ausgang 
führte.

Ich werde irgendwie nicht schlau aus diesen TFT-Glotzen - vielleicht 
zeigt sich ein Schema wenn ich ein Prüfbild anzeigen kann (mit 
1-Pixel-Rand und so).

[Stefan F. (Gast)]

Ich liebe diese Fotos, der Aufbau ist echt der Hammer. Daran kann man 
sich gar nicht satt gucken. Bau da später bloß einen ordentlichen 
Schaukasten drumherum, damit das lange erhalten bleibt.

Ich bin ein bisschen irritiert, das du da einen 8051 verbaut hast. 
Wolltest du nicht eine diskrete CPU selber bauen? Welchen Zweck erfüllt 
denn der 8051?

[Ach Du grüne Neune (Gast)]

Stefanus F. schrieb:
> Ich liebe diese Fotos, der Aufbau ist echt der Hammer. Daran kann man
> sich gar nicht satt gucken. Bau da später bloß einen ordentlichen
> Schaukasten drumherum, damit das lange erhalten bleibt.

Ich werde mir dein Foto vom Steckbrett auf DIN A1 mit maximaler 
Farbsättigung auf dem Plotter ausdrucken und dann in einen alten 
Bilderrahmen setzen. Den habe ich irgendwo noch auf dem Dachboden 
rumliegen. Die Glasplatte kann ich beim Glaser passend anfertigen 
lassen. Das Bild kommt dann bei mir ins Arbeitszimmer! Ich freu mich 
jetzt schon drauf.   :D

[Bernd (Gast)]

Ach Du grüne Neune schrieb:
> Das Bild kommt dann bei mir ins Arbeitszimmer!
Ein Bild ohne Strom rockt nicht...

Quelle: http://www.ycdt.de/kc2014/

[Timo N. (tnn85)]

Erinnert mich an das hier:
https://www.youtube.com/watch?v=HyznrdDSSGM

[G. O. (aminox86)]

Halligalli schrieb:
> nur leider hat der 8051 von ebay
> einen Schuss und gibt kein /WR und kein /RD aus. Ich muss jetzt auf
> Ersatz warten
Das gleiche Verhalten wird hier beschrieben:
Beitrag "P80C51 gibt weder /WR noch /RD aus ?"
Systhematischer Fehler?

[Modellbauer (Gast)]

Total geiles Projekt!
Nicht nur gelabert man könnte, müsste, sollte, sondern durchgezogen.

Sieht absolut genial aus.

[Halligalli (Gast)]

Solche Kollagen-Bilder hängen immer im Altenheim, damit die Senilen sich 
ein wenig erinnern können... gute Idee eigentlich!

[Stefan F. (Gast)]

Wofür ist denn jetzt der 8051?

[Halligalli (Gast)]

Stefanus F. schrieb:
> Wofür ist denn jetzt der 8051?

Der füttert die Tile-Engine mit Bilddaten und Befehlen. Also Tile-Muster 
ins Tile-Detail-RAM laden, Scroll-Register setzen, 
Hintergrund-Farben-Register setzen usw.

Leider - hüstel - funktioniert am 8051 etwas nicht ... war ja klar (hab 
ich ganz vergessen)  :-)

[Halligalli (Gast)]

Ach Du grüne Neune schrieb:
> Ich werde mir dein Foto vom Steckbrett auf DIN A1 mit maximaler
> Farbsättigung auf dem Plotter ausdrucken und dann in einen alten
> Bilderrahmen setzen.

Warte bis es funktioniert! Es fehlen noch ein paar Drähte und wer weiss 
ob es überhaupt läuft wie es soll.

[Halligalli (Gast)]

Bernd schrieb:
> Ein Bild ohne Strom rockt nicht...

Was ist das denn für eine "Spectral" Platine ? Ist das von einem Automat 
?

[Bernd (Gast)]

Halligalli schrieb:
> Was ist das denn für eine "Spectral" Platine ?
https://de.wikipedia.org/wiki/Spectral_(Heimcomputer)

[Halligalli (Gast)]

Bernd schrieb:
>> Was ist das denn für eine "Spectral" Platine ?
> https://de.wikipedia.org/wiki/Spectral_(Heimcomputer)

Interessantes Teil...mit 8 Farben doch recht sparsam - bestimmt ein 
Büro-Arbeitsgerät.

Ich habe die Tile-Engine fertig verdrahtet und ein wenig programmiert: 
Schwarz/Weiss-Umschalten des Hintergrundes funktioniert einwandfrei, 
auch das Scrollen in Y-Richtung scheint fehlerlos zu sein.

Aber jetzt kommts: Als ich das Scrollen in X-Richtung prüfte, scrollte 
nur die oberste Tile-Zeile fehlerlos. Die Tile-Zeilen darunter hatten 
irgendwie eine Inkonsistenz, folgten also nicht exakt der obersten 
Tile-Zeile. Ausserdem flackert das Bild am Monitor einmal bei jedem 
Scroll-Schritt (nicht V-Blank-synchronisiert) - ich hatte schon Angst 
dass der Drahtverhau mit den HCT-Treibern die Betriebsspannung 
einbrechen lässt bei jedem Schrieb auf den Bus :-) Das muss ich noch 
beobachten.

Das kann ja heiter werden ... wenn ich demnächst ein Prüfbild einspeise 
weiss ich mehr (hoffentlich).

[Halligalli (Gast)]

Es sieht nicht gut aus ...

Nach anfänglichen Erfolgen mit Zeilen-Interrupt, Hintergrundfarbe und 
Y-Scrolling  musste ich feststellen dass es nicht weitergeht. Ein 
Befüllen der Dual-Port-RAMs zeigt nicht genau das Muster an dass ich 
übertrage. Selbst das Übertragen scheint gestört zu sein, da bei 
verschiedenem Einschalten der Versorgungsspannung bisweilen die 
Test-Zeile woanders erscheint am Bildschirm. Und ständig flackern 
einzelne Pixel ...

Ich müsste Platinen ätzen! 4-lagige mit 25x20cm sollten taugen denke 
ich. Wenn ich die kritischen Teile (Pipeline, 8051) auf Platinen packe 
sollte es anders aussehen.

Doch das Dualport-RAM stört mich: Exklusives seltenes Ding und es 
bleiben eh nur 1ms zwischen V-Sync und erster Bildzeile. Mir würde eine 
Auto-Transfer-Lösung gefallen, wo aus einem einzelnen großen Speicher 
alle Speicherbereiche übertragen werden kurz vor der ersten sichtbaren 
Zeile. Das würde eine Art Bild-Puffer ergeben bei dem man endlos Zeit 
hat ihn zu füllen (wenn man den Auto-Transfer blockiert per 
Register-Schrieb).

Dummerweise ist praktisch alles ungetestet und könnte im Groschengrab 
enden ...

[Halligalli (Gast)]

Ich habe es mal fotografiert ... die Muster sollten eigentlich rote 
Diamanten sein, doch die linke Hälfte ist weiss :-) Ausserdem sollten es 
nur 10 Tile-Muster am Zeilenanfang sein - es sind aber eine Menge mehr.

Auch habe ich gesehen dass wieder der Spannungsregler der 
Stromversorgung abschaltete - Überstrom beim Einschalten ?

[Stefan F. (Gast)]

Halligalli schrieb:
> Ich müsste Platinen ätzen!

Och nö, eine Platine würde den ganzen Aufbau versauen.

> es bleiben eh nur 1ms zwischen V-Sync und erster Bildzeile.

Lass doch einfach ein paar Bildzeilen ungenutzt, oder geht das nicht?

[Halligalli (Gast)]

Und nicht zu vergessen: der Zeilen-Interrupt-Test ...komplett mit 
vertikalen Streifen, obwohl ich den Speicher vorher gelöscht hatte...

[Halligalli (Gast)]

Stefanus F. schrieb:
> Och nö, eine Platine würde den ganzen Aufbau versauen.

Irgendwo sind tausend Fehler drin  :-) Vielleicht geht soetwas nicht mit 
fliegendem Drahtaufbau.

Stefanus F. schrieb:
> Lass doch einfach ein paar Bildzeilen ungenutzt, oder geht das nicht?

Keine Chance - der Bildschirm ist sowieso zu klein bei der Pixelgröße.

[Stefan F. (Gast)]

Ich hatte dich schon einmal darauf hingewiesen, dass die Hauptverteilung 
der Stromversorgung über die horizontalen Leisten der Steckbretter ein 
Problem werden könnte. Ersetze die mal durch Drähte, dann wird deine 
Stromversorgung stabiler. Rechts daneben auch.

[Halligalli (Gast)]

Es graust mir irgendwie da Drähte überall hinzuziehen  :-) aber ich 
werde es mir merken.

Ich werde erstmal kleinere Schritte machen, also kleine Programme die 
Kleines bewirken.

Vielleicht ergibt sich dann ein Fehlerbild von dem man etwas ableiten 
kann - vor allem im Bereich der Speicher.

[Zeitjäger . (forgoden)]

Das rumverdrahten ist zwar schön und gut, aber mich würde die 
Herstellung eigener ICs mehr interessieren.

Wieso gründet ihr nicht gleich eine Chipherstellerfirma ? Selber 
belichten und IC-Schaltung immer weiter verkleinern bis Intel alt 
aussieht.

Der erste Intel-Chip 4004 sah so aus:
https://pbs.twimg.com/media/DRp-8beXUAEpxGV.jpg:large

Und danach atmega168 nachbauen

Solche 8bit Atmega Prozessoren werden bis heute noch verwendet.

Frag mal bei Infineon ob die alte Werkzeuge zum Belichten hergeben 
würden

[Halligalli (Gast)]

Helmut V. schrieb:
> Das rumverdrahten ist zwar schön und gut, aber mich würde die
> Herstellung eigener ICs mehr interessieren.

Da gibts keinen Markt dafür - die gehen alle auf Emulatoren.


Übrigens scheint es wirklich etwas zu bringen, sich auf mc.net 
auszuheulen:

Ich habe scheinbar am Anfang des Programmes vergessen den 
Teilzähler-Basiszeiger auf 0000 zu initialisieren - daher die 
verschiedenen Positionen der Musterstreifen bei jedem Einschalten.

Ausserdem scheint das Tile-Muster nicht zu stimmen, weil es 
möglicherweise gespiegelt ist - der Pixel_X-Zähler zählt ja vom höchsten 
Bit des (zweiten ?) Bytes abwärts. Das muss ich nochmal durchspielen - 
möglicherweise muss man da heftig Bitpaare spiegeln, um den richtigen 
Wert in das RAM zu schreiben.

[Stefan F. (Gast)]

Helmut V. schrieb:
> Wieso gründet ihr nicht gleich eine Chipherstellerfirma ?

Meinst du die Frage ernst?

Hier eine ernst gemeinte Antwort: Weil das sehr viel mehr Geld kostet, 
als wir alle jemanls zu Gesicht bekommen werden. Und weil niemand mit 
Verstand im Kopf so viel Geld für die Herstellung einer einzigen 
Spielerei ausgeben würde.

Obwohl: Es gibt da gewisse Leute, die ein rotes Auto ins Weltall 
schießen...

[Halligalli (Gast)]

Ich bin auf ein etwas größeres Problem gestossen: horizontale und 
vertikale Streifen-Tile-Muster werden scheinbar richtig angezeigt, aber 
ein komplexes Muster wird verstümmelt.

In dem Testprogramm wurde abwechselnd ein horizontales, dann ein 
vertikales Streifenmuster geschrieben. Als letztes wurde das 
Dreieck-Muster hineinkopiert. Leider sieht das Dreieck nicht sehr gut 
aus  :-)

Vielleicht hat die Verstümmelung ein System - oder die Schaltung hat 
einen Fehler.

[Halligalli (Gast)]

Vielleicht ist hier der Wurm drin - immerhin kann man mit Multiplexern 
recht schnell Fehler machen   :-)

Die Schaltung soll aus einem Byte 4 Bitpaare aus dem Speicherausgang 
erzeugen - je nach Stellung der 2 Steuer-Bits. Horizontale und vertikale 
Balken mag die Schaltung, wenn auch die vertikalen Balken nicht ihre 
vorgesehene Position haben füllen sie doch das ganze Tile ...

[Halligalli (Gast)]

Das ist nicht gut: ich habe keinen Fehler in der Verdrahtung gefunden! 
Auch die Daten- und Adressleitungen zu den SRAMs habe ich 
durchgeklingelt.

Kein Fehler finden bedeutet keine Hoffnung auf Funktion  :-)

Vielleicht ist der Fehler fundamentaler Natur. Ich werde mal ein neues 
sauberes, ausführliches Testprogramm aufsetzen.

[Stefan F. (Gast)]

Wie wäre es mit Messen? Augendiagramme von allen Signalen und Takt 
versus Daten.

[Halligalli (Gast)]

Fakt ist dass die Pipeline das Bytepaar richtig im Tile-Muster-Block 
adressiert. Auch habe ich einmal die Positionen in der Tile-Karte 
hochzählen lassen - das ging auch. Die horizontale Adresse im Tile 
scheint korrekt - das prüfe ich nochmal mit anderen Mustern/Balken. Die 
Farbbildung aus dem Bitpaar des Pixels scheint auch zu funktionieren (01 
war rot und 11 war blau, das Ganze bei 00 weisser Grundfarbe) - das wird 
auch nochmal genau geprüft.

Der Fehler muss zwischen Pixel_X-Zähler, Tile-Karte, 
Tile-Detail-Speicher und Multiplexer liegen. Die Leitungen scheinen alle 
zu stimmen - müssen sie ja auch sonst hätte das Tile gar nicht mit der 
Adresse auf dem Freiluftverbindungs-Bus angesprochen werden können und 
hätten nicht das sichtbare Tile mit den horizontalen/vertikalen Linien 
ergeben.

Auch hat der Tile-Detail-Speicher bestimmt das Durchbiegen an den Enden 
beim Einstecken auf das Steckbrett überlebt (war das erste Mal dass ich 
so einen fetten Baustein ins Brett stecke) :-) Der Speicher verhält sich 
ja recht nachvollziehbar.

[Halligalli (Gast)]

Halligalli schrieb:
> Die horizontale Adresse im Tile
> scheint korrekt

Natürlich scheint die vertikale Adresse im Tile korrekt zu sein also die 
liegenden Balken... habe mich verschrieben.

[Halligalli (Gast)]

Ich habe ein Spezial-Testmuster durchgeschickt und das ist dabei 
herausgekommen - vielleicht hat die Verschiebung der Pixel ja ein 
System.

Auch habe ich den Multiplexer-Baustein ausgetauscht - das brachte aber 
keine Änderung.

[Halligalli (Gast)]

Ich habe alles durchgeklingelt was man so durchklingeln kann: 
Busleitungen bis zum 8051, Pix_X- und Pix_Y-Leitungen und keine Fehler 
gefunden.

Jetzt heisst es in den sauren Apfel beissen und das Oszilloskop 
aufbauen. Vielleicht hilft es ein einzelnes Pixel pro leerem Bild zu 
zeichen, damit zu triggern und mit dem zweiten Kanal herumzumessen.

Laut Symptombild wird jeder Pixel um 2 Stellen nach links rotiert, wobei 
jede 3. Zeile sogar über die Nibble-/Byte-Grenze rotiert wird ... Das 
vertikale Zeilensystem scheint in Ordnung, denn ich habe einen 
Testbalken in Zeile 3 erfolgreich anzeigen lassen.

[Halligalli (Gast)]

Nach etwas schwierigem Oszilloskopieren hat sich ergeben dass bei der 
Pix_X-Position "10" an den Eingängen A/B des Multiplexers anlag. Das 
heisst dass tatsächlich an der Position des 3. Bits von rechts 
Pixel-Farbdaten im Dualport-SRAM lagen. Ich habe diese Pixel-Farbdaten 
eigentlich woanders hingespeichert (wollte das Pixel ganz rechts 
anzeigen lassen).

Daher liegt die Vermutung nahe, dass das Dualport-SRAM defekt ist - ich 
habe es ja auch recht verbogen beim Einsetzen.

Bei mouser kostet es nur 15 Euro, aber die wollen 20 Euro Versand und 
vielleicht kommt am Ende noch Steuer drauf... also etwa 40 Euro rum  :-) 
Aber auf ebay kosten die genauso viel.

[Bernd (Gast)]

Halligalli schrieb:
> Bei mouser kostet es nur 15 Euro, aber die wollen 20 Euro Versand
Vielleicht kannst Du Dich hier mit dranhängen?
https://www.mikrocontroller.net/articles/Sammelbestellungen(Mouser)

[Bernd (Gast)]

Oder Du strickst die Geschichte um: Es gibt Homecomputer, wo der 
Speicherzugriff über einen Arbiter geht: zu geraden Takten darf die CPU 
zugreifen und zu ungeraden Takten der Videocontroller...

[Halligalli (Gast)]

Bernd schrieb:
> Vielleicht kannst Du Dich hier mit dranhängen?
> https://www.mikrocontroller.net/articles/Sammelbestellungen(Mouser)

Ich habe das Problem anders gelöst: ich brauchte sowieso ein besseres 
Multimeter, also habe ich eins für 30 Euro von Digilent dazubestellt. So 
war es mit 50 Euro versandkostenfrei und es kamen noch 10 Euro 
Zoll/Steuern dazu.

Bernd schrieb:
> Oder Du strickst die Geschichte um: Es gibt Homecomputer, wo der
> Speicherzugriff über einen Arbiter geht: zu geraden Takten darf die CPU
> zugreifen und zu ungeraden Takten der Videocontroller...

Ich würde gerne das Dualport-Zeug loswerden und alles aus einem 
einzelnen Puffer-SRAM auf die einzelnen Pipeline-SRAMs verteilen (mit 
Auto-DMA kurz vor Beginn des sichtbaren Bildschirms).

[Thomas W. (diddl)]

Bernd schrieb:
> Oder Du strickst die Geschichte um: Es gibt Homecomputer, wo der
> Speicherzugriff über einen Arbiter geht: zu geraden Takten darf die CPU
> zugreifen und zu ungeraden Takten der Videocontroller...

Ja, die alten Commodore PET haben das so gemacht.
Die hatten noch keinen Videocontroller, das war ein riesiges TTL Grab.

Die moderneren mit VIC als Videocontroller halten bei Bedarf die CPU an.
Weil es nicht mehr langt in der PHI1 Phase zuzugreifen.

[Stefan F. (Gast)]

Ich habe noch nicht verstanden, warum du da einen Mikrocontroller 
eingebaut hast. Das ganze Projekt sollte doch ein Computer aus 
dedizierten Komponenten sein, oder nicht?

Welche Aufgabe hat der Mikrocontroller, und welche Aufgabe hat der 
dediziert aufgebaute Teil?

[Thomas W. (diddl)]

Stefanus F. schrieb:
> Ich habe noch nicht verstanden, warum du da einen Mikrocontroller
> eingebaut hast. Das ganze Projekt sollte doch ein Computer aus
> dedizierten Komponenten sein, oder nicht?

Ohne µC sind Tests ja nur sehr sehr schwierig durchzuführen.

Wie willst du den Daten ins RAM bringen, damit fängt es schon an.
Und dynamische Tests gehen gar nicht ohne µC.

[Stefan F. (Gast)]

> Stefanus F. schrieb:
>> Ich habe noch nicht verstanden, warum du da einen Mikrocontroller
>> eingebaut hast.

Thomas W. schrieb:
> Ohne µC sind Tests ja nur sehr sehr schwierig durchzuführen.

Das macht Sinn, gefällt mir.

Frage an Halligalli: Also dient der Mikrocontroller Quasi als 
Debug-Schnittstelle?

[Halligalli (Gast)]

Stefanus F. schrieb:
> Frage an Halligalli: Also dient der Mikrocontroller Quasi als
> Debug-Schnittstelle?

Ich habe keine Ahnung von dirskret aufgebauten Prozessoren  :-) 
Ausserdem ist der erste Schritt der Versuch diese Tile-Engine zum Laufen 
zu bringen. Der 8051 nimmt wenig Platz auf dem Steckbrett ein und 
füttert die Tile-Engine-Speicher- und -Register mit Bilddaten/-Farben 
und -Scroll-Register-Werten.

Es hätte auch ein 6502 sein können, da der auch einen externen Bus hat. 
Doch diesen Prozessor habe ich noch nichtmal aus der Nähe gesehen ... 
mit dem 8051 habe ich schon etwas Erfahrung.

Ich vermute übrigens dass der aktuelle 8051 mit 10MHz Takt etwa so 
schnell ist wie ein NES-Prozessor und doppelt so schnell wie ein 
C64-Prozessor. Der C64 hat aber absurd viele 
Echtzeit-Eingriffs-Möglichkeiten um grafisch mehr herauszuholen - das 
erreicht meine Tile-Engine nicht. Wenn ich das Dualport-SRAM entfernen 
sollte kann man auch nicht mehr in Echtzeit den Speicher manipulieren - 
wozu auch immer.

Erschreckend ist auch dass nur etwa 1ms bleibt während V-Sync. Und dem 
Rasterstrahl nachlaufend in das Bildschirm-RAM schreiben ist sowieso 
etwas schwierig mit Dualport-SRAM - es scheint das verträgt 
Schreibkonflikte auf die gleiche Speicherzelle nicht so gut... da gibt 
es extra Signalleitungen am Dualport-SRAM.

Sollte die Tile-Engine laufen kann ich ja ein wenig 
herumexperimentieren, also mit Datenübertragungsraten/-Fenster, 
Echtzeit-Zugriffsbedarf usw.

[Stefan F. (Gast)]

Halligalli schrieb:
> Der C64 hat aber absurd viele Echtzeit-Eingriffs-Möglichkeiten

Das stimmt. Sowohl dessen Hardware als auch Software steckt voller 
damals "genialer" Tricks. Die haben aus der minimalen Hardware wirklich 
alles raus geholt, was ging.

Wenn ich heute so entwickeln würde, wäre ich längst arbeitslos, denn 
solide und langfristig pflegbar ist so eine Konstruktion nicht. Aber 
damals war das wohl die richtige Strategie.

[Thomas W. (diddl)]

Halligalli schrieb:
> Erschreckend ist auch dass nur etwa 1ms bleibt während V-Sync.

Eine Millisekunde genügt, das ist eine Ewigkeit für einen µC.
Selbst für einen 6502 ist das viel Zeit …

[Halligalli (Gast)]

Thomas W. schrieb:
> Eine Millisekunde genügt, das ist eine Ewigkeit für einen µC.
> Selbst für einen 6502 ist das viel Zeit …

Das sind tausend 1-Zyklus-Befehle zu je 1us ... wenn da eine Schleife 
ist kann man nicht viel Bilddaten schreiben. Beim Scrollen muss der 
nachrückende Rand manchmal neu beschrieben werden - das sind 30 bis 40 
Byte. Vertikal Scrollen geht noch, da sie hintereinander im Speicher 
stehen. Aber beim horizontal Scrollen muss man immer etwa 40 
dazuaddieren zu jeder Byte-Adresse. Naja, vielleicht kann man eine 
aufgerollte Schleife nehmen, aber Speicherplatz ist knapp :-)

[Thomas W. (diddl)]

Halligalli schrieb:
> Beim Scrollen muss der
> nachrückende Rand manchmal neu beschrieben werden - das sind 30 bis 40
> Byte.

Ja genau, jetzt werden Erinnerungen wach …

Beim C64 gab es im VIC die Möglichkeit, das ganze Bild nacht rechts und 
unten zu bewegen, von 0 bis 7 Pixel.

Damit konnte man ein ganz "weiches" Scrolling in alle 4 Richtungen 
realisieren. man musste nur jedes 8 mal die Tiles versetzen. Und nie die 
Tile Pattern daten

[Halligalli (Gast)]

Thomas W. schrieb:
> Beim C64 gab es im VIC die Möglichkeit, das ganze Bild nacht rechts und
> unten zu bewegen, von 0 bis 7 Pixel.
>
> Damit konnte man ein ganz "weiches" Scrolling in alle 4 Richtungen
> realisieren. man musste nur jedes 8 mal die Tiles versetzen. Und nie die
> Tile Pattern daten

Musste beim C64 nicht die ganze Tile-Karte (plus Farb-Karte ?) um 1 
versetzt neu in den Speicher geschrieben werden nachdem man um 7 Pixel 
soft-gescrollt hatte ? 1000+ Bytes zu schreiben ist schon heftig - 
soweit ich weiss sind die dem Rasterstrahl gefolgt   :-)

[Markus M. (adrock)]

Halligalli schrieb:
> Thomas W. schrieb:
>> Beim C64 gab es im VIC die Möglichkeit, das ganze Bild nacht rechts und
>> unten zu bewegen, von 0 bis 7 Pixel.
>>
>> Damit konnte man ein ganz "weiches" Scrolling in alle 4 Richtungen
>> realisieren. man musste nur jedes 8 mal die Tiles versetzen. Und nie die
>> Tile Pattern daten
>
> Musste beim C64 nicht die ganze Tile-Karte (plus Farb-Karte ?) um 1
> versetzt neu in den Speicher geschrieben werden nachdem man um 7 Pixel
> soft-gescrollt hatte ? 1000+ Bytes zu schreiben ist schon heftig -
> soweit ich weiss sind die dem Rasterstrahl gefolgt   :-)

Ihr beschreibt ja beide das gleiche - und ja, es ist korrekt. Genau so 
lief es :-) Man konnte aber das kopieren der "Tiles" allerdings schon 
blockweise während der ersten 7 Schritte des Verschiebens per Register 
versteckt durchführen. Am Ende hat man dann nur noch den Buffer im 
Rasterzeileninterrupt umgeschaltet. Also double buffering sozusagen.

[Halligalli (Gast)]

Das Problem scheint heftiger zu sein: ein Austausch des 
Tile-Detail-SRAMs brachte keine Besserung. Ich habe sogar einen 
UND-Baustein dazugebastelt um die "11"-Position des 
2-aus-8-Multiplexer-Ausgangs als Triggerbasis für das Oszilloskop nutzen 
zu können.

Als dieser Ausgang auf "11" (also blauer Pixel) ging war der 
Pix-X-Zähler auf "00" mit seinen niedrigsten Bits - zeigte also 
richtigerweise auf die rechte obere Ecke des Tiles. Doch dieses Pixel 
erscheint um 2 Stellen nach links versetzt am Bildschirm!

Es scheint ein fundamentales Problem mit der Pipeline vorzuliegen, ob 
Funktions- oder Schaltungstechnisch wird sich hoffentlich aufklären. 
Vielleicht hängt es auch mit der seitlichen Überzeichnung am TFT-Monitor 
zusammen.

Auch ist die verteilte Pixel-CLK an den Pipeline-Bausteinen ein Witz: 
von der negativen Halbwelle ist nur ein Spitzchen übrig  :-) Da sind 
wohl zuviele Puffer im Spiel ... dass es doch irgendwie funktioniert ist 
ein Wunder - den fixen (20ns ?) SRAMs sei dank!

[Halligalli (Gast)]

Kennt sich jemand mit den IDT-Dualport_Rams aus (zB. IDT 7134...20ns) ? 
Ich habe gesehen dass das Timing vermurkst ist da der Takt der Pix_CLK 
wegen 2-fach-Pufferung asymmetrisch geworden ist (der Low-Teil dauert 
nichtmal 20ns, der High-Teil etwa 60ns). Dadurch kann ich den 
2-aus-8-Multiplexer am Datenbus nicht richtig betreiben.

Ich habe das /OE der Dualport-RAMs fest auf GND gelegt und die Pix_CLK 
an /CE angeschlossen.

Kann man diese Speicher auch auf Dauer-Lesebetrieb laufen lassen ? Also 
ohne Pix_CLK ? Im Datenblatt steht irgendwie es wäre nötig dass vor dem 
Adresswechsel /CE oder /OE runtergehen ...

Dass dieser Aufbau etwas am Monitor anzeigt wird immer wunderlicher - 
ich sah gerade dass die RAMs der Tile-Karte scheinbar ein 55ns-Typ ist 
:-) Wie kann das funktionieren wenn der Low-Teil der Pix_Clk mit weniger 
als 20ns am /CE ankommt.

[Halligalli (Gast)]

Ich habe versuchsweise die Pufferung des Pix-CLK für die Speicher durch 
einen anderen freien Puffer geleitet und jetzt ist die negative 
Halbwelle etwa 27ns. Das könnte sogar für ein /OE-Signal am 55ns-RAM 
reichen. Der vorherige Puffer, aus dem das Signal davor abgezapft wurde 
musste bereits insgesamt 9 Eingänge treiben - das war wohl etwas 
ungünstig.

Ich muss den LHC jetzt umbauen  :-) Das verbesserte Pix_CLK-Signal muss 
an die /OE-Eingänge der Speicher und die /CS-Eingänge verbinde ich mit 
V-Blank. Ich habe gesehen dass sich das letzte Tile des Bildes (rechts 
unten im Eck) nicht löschen lässt. Vielleicht ist das Dualport-RAM zu 
der Zeit im Lesemodus und blockiert den Lösch-Schrieb auf der anderen 
Seite (Zugriffskonflikt).

[Halligalli (Gast)]

Der Umbau ging schneller als gedacht - an einem Tag war es vollbracht. 
Der Zugriffs-Konflikt auf die Tile-Karte ist beseitigt - ich habe jetzt 
einen komplett schwarzen Bildschirm mit einem einzelnen blauen Pixel mit 
dem ich triggern kann. Leider hat es das Problem mit den nach links 
verschobenen Pixeln der Diagonal-Testlinie nicht behoben. Ausserdem 
blitzen (beim Zufalls-Bildschirm) jetzt überall einzelne rote Pixel 
herum - wie ein lustiger Sternenhimmel  :-) Ich werde weiter Fehler 
suchen müssen.

Auf youtube hat einer vorgemacht wie man Baustein-effizient Sync-Signale 
erzeugt:

https://www.youtube.com/watch?v=l7rce6IQDWs

https://www.youtube.com/watch?v=uqY3FMuMuRo

Vielleicht kann ich da später etwas davon gebrauchen.

[Stefan F. (Gast)]

Warscheinlich nerve ich mit der folgenden Frage: Hast du die Verteilung 
der Stromversorgung in Ordnung gebracht?

[Halligalli (Gast)]

Stefanus F. schrieb:
> Warscheinlich nerve ich mit der folgenden Frage: Hast du die Verteilung
> der Stromversorgung in Ordnung gebracht?

Noch nicht - das wird eine der letzten Optionen sein wenn alles andere 
versagt!

Ich messe mich gerade durch den Bereich wo die 2-aus-8-Logik ist. Es 
scheint dass der Ausgang dieser Logik über eine Pix-CLK später seinen 
Wert hält - also die Pipeline dann um eine Stufe verschoben ist. Eine 
erste Mess-Sitzung war nicht vollständig genug - ich muss nochmal das 
Oszilloskop aufbauen. Ist übrigens echt nervig: das Ding aus der 
Plastik-Box und Folie holen, die Mess-Spitzen und das Stromkabel aus 
ihren Hüllen, alles aufstellen und anschliessen, dabei auf ESD achten 
und beim Einpacken das Ganze rückwärts. Wenn ich das nicht mache stirbt 
das Gerät den Staubtod! Die Bausteine auf dem Steckbrett haben bereits 
eine leicht feuchte Staubschicht, die sich nur schwer mit den Fingern 
abwischen lässt - und eine Mini-Spinne hat ihre Mini-Seidenfäden über 
Spannungsregler und 8051-Bereich gezogen. Wie kommt die nur überall hoch 
um die Enden zu befestigen ?  :-)

[Stefan F. (Gast)]

Du scheinst sehr überzeugt zu sein, dass die Stromversorgung unkritisch 
ist. Ich wünsche dir viel Erfolg.

Auch allen kranken Veganern, die alles versuchen, außer ihre Ernährung 
zu überprüfen.

[Halligalli (Gast)]

Stefanus F. schrieb:
> Du scheinst sehr überzeugt zu sein, dass die Stromversorgung unkritisch
> ist. Ich wünsche dir viel Erfolg.

Das habe ich nicht gesagt, nur dass ich es am Ende mache wenn alle 
anderen Möglichkeiten nichts geholfen haben. Es scheint klar dass die 
Masseleitung auch in die Gesamtlänge einer Verbindung mit einfliesst 
(oder nicht ?  :-)).

[Stefan F. (Gast)]

Halligalli schrieb:
> Es scheint klar dass die
> Masseleitung auch in die Gesamtlänge einer Verbindung mit einfliesst

Wobei deine Masseverbindung aus zahlreichen zusammen geklemmten 
Eisenblechen besteht, und hauchdünnen Übergängen zu Kupferdrähten. Ich 
würde die Stromversorgung als allererstes verbessern, denn

a) Bei schlechter Stromversorgung ist alles möglich
b) Der Schwachpunkt ist bereits erkannt, da offensichtlich
c) Die Korrektur ist einfach und schnell umzusetzen

Du bist hingegen schon dabei, Chips die eigentlich funktionieren 
sollten, durch andere zu ersetzen. Du doktorst an den Symptomen herum. 
Ich finde das sehr schade, denn dein Projekt an sich finde ich 
Mega-Geil, ebenso deine Ausdauer. Versaue das doch bitte nicht!

[Halligalli (Gast)]

So ... die Oszillokop-Messungs-Sitzung wäre durchgeführt! Jetzt heisst 
es nur noch Auswerten. Die Zeitbasis sollte überall 100ns /div sein.

Ich glaube ich brauche ein Quinoa-Frühstück mit Walnüssen, und zu Mittag 
ein paar Heringshappen - damit das Gehirn mehr Dampf hat  :-)

[Mampf F. (mampf)]

Kann irgendein Mod den Thread-Titel in etwas sinnvolles ändern? xD

[Stefan F. (Gast)]

Bei deinen Oszilloskopbildern sehe ich heftige Schwingungen an 
sämtlichen Flanken. Teilweise stören Flanken sogar andere benachbarte 
Signale.

Das passiert zum Beispiel, wenn die Masse Verbindung zu hochohmig (oder 
induktiv) ist. Falls jemand noch einen anderen möglichen Grund kennt: 
Bitte melden.

[Halligalli (Gast)]

Stefanus F. schrieb:
> Bei deinen Oszilloskopbildern sehe ich heftige Schwingungen an
> sämtlichen Flanken

Das sind die langen Drähte am Tastkopf! Erstens der Masse-Draht mit der 
Kroko-Klemme (10cm ?) und dazu noch ein Steckdraht (3-5cm) damit ich auf 
dem Steckbrett messen kann.

Ich habe früher mal nur mit dieser kurzen Feder am Tastkopf gemessen und 
das Signal sah in Wirklichkeit recht sauber aus. Ich nehme an dass die 
hier gemessenen Signale in Wirklichkeit nur wenig überschwingen. Auch 
sind diese langsam steigenden und fallenden Flanken an der Pixel-CLK 
bestimmt aus dem selben Grund so. Man muss da irgendwie den Mittelwert 
des Abstandes messen bzw. mit steileren Flanken rechnen... das sind die 
Tücken der Oszilloskop-Messung  :-)

Ich musste die Bilder am Android-Handy beschriften ... das war ja was...

[S. R. (svenska)]

Das dürfte auch passieren, wenn die Versorgung allgemein scheiße ist 
oder das Gesamtsystem eine Schwingneigung aufweist. Muss ja nicht die 
Masse sein, die da schwankt - ist aber eine Möglichkeit.

Der Halligalli könnte ja mal das Oszilloskop auf die Masse der 
verschiedenen Chips loslassen, verglichen mit einer stabilen Masse (z.B. 
direkt am Netzteil).

[Stefan F. (Gast)]

Halligalli schrieb:
> Das sind die langen Drähte am Tastkopf!

Oh ja, das kann natürlich auch die Ursache sein.

Versuch mal, besser Bilder zu bekommen, sonst kann man nur raten, ob ein 
Messfehler vorliegt, oder ob die Signale wirklich so schlecht sind.

[Halligalli (Gast)]

Laut den gemessenen Signalen sollte eigentlich alles in Ordnung sein. 
Vier Spültakte für die Pipeline, mit dem fünften Takt kommt Pixel 7 des 
Tiles raus (ganz linker Pixel) und wenn Pixel 0 des Tiles rauskommt geht 
es auf blau bei steigender Pix-CLK und auch bei der darauffolgenden 
steigenden Flanke auf schwarz zurück.

Ich habe wieder das alte Testmuster am Monitor laufen lassen und es war 
fürchterlich - nichts stimmte und es flackerten rote Pixel herum.

Beim Testbild 3 sieht man dass der blaue Balken des vertikalen 
Streifenmuster-Tiles ganz rechts an den Tiles einfach dranhängt und 
sogar scheinbar zu dem Zufalls-Tile dazugehört  :-)

Entweder ist es ein EMI-Problem, also Reflektionen oder soetwas oder die 
Pipeline hat einen unentdeckten Funktionsfehler - die 
Oszilloskop-Messungen zeigen aber einwandfreie Funktion.

[Dergute W. (derguteweka)]

Moin,

Halligalli schrieb:
> Entweder ist es ein EMI-Problem, also Reflektionen oder soetwas oder die
> Pipeline hat einen unentdeckten Funktionsfehler - die
> Oszilloskop-Messungen zeigen aber einwandfreie Funktion.

Erinnert mich an den alten Kalauer, als zu kommunistischen Zeiten in 
Moskau eine Strip-Bar eroeffnet wurde, die immer voellig leer war.
Die Funktionaere haben sich ueberlegt, an was es liegen kann - 
keinesfalls an den Maedels, die waren alle schon seit 50 Jahren in der 
Partei...

Duck&Weg
WK

[Mampf F. (mampf)]

Könnt ihr euch nicht 74xx-Teile in VHDL bauen und damit ein VHDL-Model 
der GraKa basteln, das ihr dann simuliert und falls die Simulation 
funktioniert, das ganze dann in einem FPGA ausprobieren und falls das 
dann ebenfalls funktioniert, das ganze dann auf einem Steckbrett mit 
echten Teilen aufbauen? xD

[Halligalli (Gast)]

Mampf F. schrieb:
> Könnt ihr euch nicht 74xx-Teile in VHDL bauen

VHDL ist schwer - der Syntax scheint nicht viel mit anderen 
Programmiersprachen gemein zu haben und der kleinste Fehler führt zum 
Versagen.

Ich werde noch einen Test machen: den blauen Pixel mit roten leeren 
Tiles rechts und unten umgeben - dann sieht man ob es als Pixel rechts 
oben im Eck angezeigt wird oder ob der Pixel auch nach links rotiert 
ist...

[Halligalli (Gast)]

Der blaue Punkt scheint tatsächlich nicht in der rechten oberen Ecke zu 
sein!

Ich habe die Pixelpaare der umgebenden Tiles auf eine andere Farbe in 
der Palette zeigen lassen - die Pixelpaare des Tiles mit dem blauen 
Punkt zeigt immer noch auf schwarz (ausser dem blauen Punkt). Man sieht 
dass am linken Rand eine vertikale Farblinie der umgebenden Tiles 
gezeichnet wird. Ausserdem ist der blaue Pixel scheinbar um 1 nach links 
verschoben und an der Stelle wo er sein sollte ist plötzlich die Farbe 
der umgebenden Tiles zu sehen.

Sehr komisch!

[Halligalli (Gast)]

Ich habe es mal wie die Quantenphysiker gemacht: schauen ob eine Messung 
das Ausgangssignal verändert  :-) Also Monitor und Oszilloskop 
gleichzeitig angeschlossen!

Tatsächlich wurde der grüne Punkt rechts oben im schwarzen Tile auf 
einmal schwarz als die eine Prüfspitze am Pix-CLK des D/A-Latches hing 
und die andere am D/A-Blau-Ausgang triggerte.

Auch sah man am Oszilloskop dass die vertikale grüne Linie links vom 
schwarzen Tile physikalisch als grünes Pixel vorhanden war, also vom D/A 
ausgegeben wurde - es ist also kein Monitor-Fehler.

Vielleicht haben noch mehr (Takt-)Signale einen Schuss und müssen 
terminiert werden ...

[Halligalli (Gast)]

Ich habe alles serien-terminiert von dem ein etwas längerer Draht weg 
ging! Dabei habe ich an der Pix_CLK-Verteilung ein wenig mit den 
Widerstands-Werten herumprobiert. Es waren 3 Verteilerknoten zu 
terminieren - ich habe die Drähte eines Knotens also gemeinsam an je 
einen Widerstand angeschlossen. Knoten 1 hatte 6 Drähte und Knoten 2 und 
3 hatten jeweils 3 Drähte die abgingen. Knoten 1 und 2 pegelten sich bei 
22 Ohm ein - mit dem Wert war das Testbild am besten und stabilsten. Der 
Knoten 3 der unter anderem zu dem D/A-Latch geht zeigte die größte 
Reaktion auf Widerstands-Änderungen: mit 80 Ohm verbreiterte sich der 
linke grüne Streifen sogar auf 2 Pixel, auch der schwarze Bereich rechts 
vom blauen Pixel verbreiterte sich auf 2 Pixel Breite. Das beste 
Ergebnis gibt es wenn alle 3 Widerstände 22 Ohm haben - dann ist links 
ein grüner Streifen von 1 Pixel Breite und der schwarze Bereich rechts 
vom blauen Pixel ist auch nur 1 Pixel breit.

Es kann sein dass eine Gruppen-Terminierung eines ganzen Takt-Knotens 
nicht das Richtige ist und stattdessen die einzelnen Drähte (die ja 
verschieden lang sind) gesondert mit ausprobierten Widerständen 
terminiert werden müssen.

[Halligalli (Gast)]

Es hat sich herausgestellt dass Terminierung der Pix-CLK-Leitungen das 
Problem nicht behebt... es blieb mir nur noch alles nochmal mit dem 
Oszilloskop durchzumessen.

Dabei stellte sich heraus dass ein einzelnes Low-Signal am Ausgang des 
2-aus-8-Multiplexers nicht weiter-gelatcht wird. Auch wird ein längeres 
Low-Signal vorne um 1 beschnitten. Es war nicht genug Zeit zwischen den 
Pixel_CLK-Signalen und dem Multiplexen übrig. Als Lösung habe ich den 
Takt des Detail-RAMs an den nur einmal gepufferten Pix-CLK verdrahtet - 
so hat der 2-aus-8-Multiplexer etwas mehr Zeit und das Taktsignal ist 
auch nicht so asymmetrisch.

Ich war sehr erleichtert dass sowohl der grüne Pixel am linken 
Bildschirmrand als auch die verstümmelte diagonale Linie korrigiert 
wurden. Das Problem mit den flackernden einzelnen Halb-Pixeln habe ich 
auch durch Herumstöpseln an den Taktleitungen reduzieren können.

Als Nächstes steht dann der horizontale Scroll-Test an ...

[S. R. (svenska)]

Was machst du eigentlich, wenn das Teil funktioniert? Ich bin ziemlich 
beeindruckt, dass du es geschafft hast, aber was sind deine Pläne dafür?

Klebst du die Schaltung dann auf ein PCB, machst du eine 
museumstaugliche Lackschicht drüber oder rupfst du das auseinander und 
freust dich über das gewonnene Wissen?

[sid (Gast)]

Wahnsinn!
BenEater hatte vor einiger Zeit was ähnliches auf youtube gebastelt,
nur deutlichst weniger umfangreich, und schon da wurd mir schwummrig von 
den Jumperkabeln...
Das Dingen da macht mir regelrecht Angst :D

Aber bin ich der Einzige der an Hercules Grakas denkt wenn er das sieht?

https://upload.wikimedia.org/wikipedia/commons/6/6a/KL_Hercules_HGC.png

'sid

[Stefan F. (Gast)]

Halligalli schrieb:
> Ich war sehr erleichtert dass sowohl der grüne Pixel am linken
> Bildschirmrand als auch die verstümmelte diagonale Linie korrigiert
> wurden.

Das bin ich auch, ich freue mich für dich mit, dass du es doch noch ans 
Laufen gebracht hast. Dafür, dass das eigentlich ein völlig sinnfreies 
Projekt ist, gehst du sehr geduldig vor. Ich glaube, ich das schon 
längst wieder auseinander gerissen.

[Halligalli (Gast)]

S. R. schrieb:
> Was machst du eigentlich, wenn das Teil funktioniert? Ich bin ziemlich
> beeindruckt, dass du es geschafft hast, aber was sind deine Pläne dafür?

Dieser Aufbau ist nur ein Funktions-Bestätigungs-Prototyp. Er bestätigt 
die Logik-diskrete VGA-Signalerzeugung, die Tile-Engine (1.0) mitsamt 
der Zähler, deren Steuerteil sowie die Synthese mit der Hintergrundfarbe 
am Ausgang. Wie schon erwähnt wünsche ich mir einen gemeinsamen 
RAM-Puffer vor den RAMs der Pipeline, damit die CPU auch während des 
Renderns Tile-Daten übertragen kann - im derzeitigen Aufbau bleibt ihr 
dafür nur etwa 1(?)ms Zeit während V-Sync.

Scheinbar führt kein Weg an einer 4-Lagen-Platine vorbei, denn dieser 
Aufbau funktioniert nur mit Mühe und Not ... 2-Lagen-Layout wäre schon 
heftig :-)

Ich weiss noch nicht wie ich den RAM-Puffer testen soll (vielleicht 
modularisieren mit "Steck-Bus-Platinen") ... ausserdem habe ich gerade 
gesehen dass es ein Problem mit dem horizontalen Scrolling gibt: nach 
der ersten Tile-Zeile schiebt es jede Zeile um 1 Tile nach links 
(addiert sich über die ganzen Tile-Zeilen).

Der Aufbau ist hoffnungslos verstaubt - von der klebrigen Art ... 
Textilien im Bastelraum sind keine gute Idee ... hoffentlich schafft es 
noch ein paar Umbauten - und eine Tile-Engine wollte ich ja auch noch 
machen!

[Halligalli (Gast)]

Halligalli schrieb:
> und eine Tile-Engine wollte ich ja auch noch
> machen!

eine Sprite-Engine ...hüstel  :-)

[Halligalli (Gast)]

Der hoffentlich letzte Fehler ist lustig: beim Scrollen kommt es beim 
Übergang von Pixel-Position 6 auf 5 (bzw. 5 auf 6 in der anderen 
Richtung) zu einem Schlangen-Aufroll-Effekt wie im Spiel "Luxor" - die 
Tile-Zeilen rücken pro Zeile um 1 zusammen. Die restliche Strecke 
scrollt einwandfrei.

Hoffentlich finde ich etwas womit ich das Oszilloskop triggern kann  :-)

[dasrotemopped (Gast)]

die Komplexität der Schaltung hat jetzt einen Punkt erreicht, das selbst 
eine selbst entworfene Platine keine Lösung ist. Eine Platine kann nicht 
zum Experimentieren und Weiterentwickeln umgestrickt werden.
Als Lösung wäre die Übertragung der Schaltung nach VHDL und als Hardware 
ein x-beliebiges preiswertes FPGA Board. Das ist allerdings ein massiver 
Wechsel im Skill Level. Bist du bereit dazu ?

Kudos für das bisher erreichte !

Gruß,
dasrotemopped.

[Halligalli (Gast)]

dasrotemopped schrieb:
> die Komplexität der Schaltung hat jetzt einen Punkt erreicht, das selbst
> eine selbst entworfene Platine keine Lösung ist.

Schlimmer ist dass ich durch die lange Zeitspanne über die das Projekt 
läuft nicht mehr so genau weiss wie die Zähler-Steuerlogik funktioniert 
:-) Doch zum Glück habe ich alles genau aufgeschrieben bzw. gezeichnet.

Trotzdem graust es mir jedesmal diesen Ablaufplan anzuschauen - das 
kostet Hirnschmalz! Zu diesem Blatt und den Zählern gehören 10 Seiten 
Schaltpläne.

Ich habe das Gefühl dass ich kurz vor dem Ziel bin: eine funktionierende 
Tile-Engine, bereit für ein Demo-Video!

[Bernd (Gast)]

Halligalli schrieb:
> VHDL ist schwer - der Syntax scheint nicht viel mit anderen
> Programmiersprachen gemein zu haben und der kleinste Fehler führt zum
> Versagen.
VHDL ist von ADA abgeleitet, deshalb die ungewohnte Syntax. Viel 
wichtiger ist aber die eigene Denkweise: sieht aus wie Software, 
beschreibt aber Hardware (so ähnlich wie HTML das Aussehen einer 
Webseite beschreibt).

Einen 7400 kann man z.B. so beschreiben:

-- SN74LS00  4 NAND mit je 2 Eingängen
library ieee;
use ieee.std_logic_1164.all;

entity SN74LS00 is
    port (
        a1 : in  std_ulogic;
        b1 : in  std_ulogic;
        q1 : out std_ulogic;
        --
        a2 : in  std_ulogic;
        b2 : in  std_ulogic;
        q2 : out std_ulogic;
        --
        a3 : in  std_ulogic;
        b3 : in  std_ulogic;
        q3 : out std_ulogic;
        --
        a4 : in  std_ulogic;
        b4 : in  std_ulogic;
        q4 : out std_ulogic
      );
end entity SN74LS00;


architecture rtl of SN74LS00 is

begin
    
    q1 <= not (a1 and b1);
    q2 <= not (a2 and b2);
    q3 <= not (a3 and b3);
    q4 <= not (a4 and b4);

end architecture rtl;

Auf der übergeordneten Ebene macht man dann die Verdrahtung, wie auf 
Deinem Steckbrett:

library ieee;
use ieee.std_logic_1164.all;

entity steckbrett is
    port (
        takt   : in  std_ulogic;
        --
        vga_r  : out std_ulogic;
        vga_g  : out std_ulogic;
        vga_b  : out std_ulogic;
        vga_vs : out std_ulogic;
        vga_hs : out std_ulogic
      );
end entity steckbrett;


architecture verdrathung of steckbrett is

    signal roter_draht   : std_ulogic;
    signal gruener_draht : std_ulogic;
    signal blauer_draht  : std_ulogic;

begin

    U1: entity work.SN74LS00
    port map 
    (
        a1 => takt,          -- : in  std_ulogic;
        b1 => takt,          -- : in  std_ulogic;
        q1 => roter_draht,   -- : out std_ulogic;
        --
        a2 => roter_draht,   -- : in  std_ulogic;
        b2 => roter_draht,   -- : in  std_ulogic;
        q2 => gruener_draht, -- : out std_ulogic;
        --
        a3 => gruener_draht, -- : in  std_ulogic;
        b3 => gruener_draht, -- : in  std_ulogic;
        q3 => blauer_draht,  -- : out std_ulogic;
        --
        a4 => blauer_draht,  -- : in  std_ulogic;
        b4 => blauer_draht,  -- : in  std_ulogic;
        q4 => vga_r          -- : out std_ulogic
    );

    vga_g  <= roter_draht;
    vga_b  <= gruener_draht;
    vga_vs <= '1';
    vga_hs <= '0';

end architecture verdrathung;

Ein 7400 reicht für ein VGA-Bild natürlich nicht ganz aus, aber man kann 
das Prinzip Logikschaltkreis+Verdrahtung sehr gut mit VHDL abbilden.
Ich würde aber das Design auf einem höheren Level beschreiben, als mit 
der Nachbildung von 74xx-Bausteinen.

Prinzipiell kommt am Anfang nur ein Simulator zum Einsatz. Der prüft die 
korrekte Syntax und mit entsprechenden Stimuli (im einfachsten Fall nur 
der Takt) wird die Funktion der Schaltung nachgewiesen. Dafür braucht 
man auch (noch) keine Hardware.
Erst wenn die Simulation erfolgreich ist, geht man damit auf ein echtes 
System. Wenn man alles richtig gemacht hat, läuft das out-of-the-box.

Ja, die Lernkurve für VHDL (und die notwendigen Tools) ist steil, aber 
hier wäre der Aufwand m.E. gerechtfertigt gewesen.
In "FPGA, VHDL & Co." ist das SNR recht hoch und man hat quasi 
deutschsprachigen VHDL/FPGA-Support.

[dasrotemopped (Gast)]

Intel/Altera bietet es an, ohne VHDL Code aus einer Bibliothek 74xx 
Bausteine zu wählen, die man dann virtuell verschaltet in einem 
Schematic editor.
ftp://ftp.intel.com/pub/fpgaup/pub/Intel_Material/16.0/Tutorials/Schemat 
ic/Quartus_II_Introduction.pdf
Daraus macht dann Quartus die Binary für das FPGA. Als Startpunkt für 
das Projekt vielleicht am besten geeignet. Man hält sich das VHDL Coden 
erst mal vom Hals und bekommt schon mal "schnell" was zum Fliegen.
Ein DE0-nano wäre ein guter Startpunkt. Dann reicht auch die kostenlose 
Version von Quartus.

Gruß,
dasrotemopped.

[Halligalli (Gast)]

Sehr interessant! So kurz vor dem Ziel natürlich etwas zu spät :-)

Lust hätte ich ein bisschen - doch davor kommt ein Lehrbuch ...

[Thomas W. (diddl)]

Ja das wäre cool, ein DE0 wäre schnell besorgt und leistbar.


Interessierte könn(t)en dies mit machen und als VHDL Einführung sehen.

[Mampf F. (mampf)]

Bernd schrieb:
> Ich würde aber das Design auf einem höheren Level beschreiben, als mit
> der Nachbildung von 74xx-Bausteinen.

Jein, es kommt drauf an, was das Ziel schlussendlich ist.

Es gibt unendlich viele (geschätzt^^) Grafikkarten in VHDL/Verilog, aber 
wenige, die diskret mit 74(HC)xx aufgebaut sind.

Insofern würde ich, wäre ich der TE, die 74xx-Logik in VHDL nachbilden 
und dann das ganze, wenn es funktioniert, auf eine Platine mit eben 
diesen Gattern übertragen :)

[S. R. (svenska)]

Mampf F. schrieb:
> Insofern würde ich, wäre ich der TE, die 74xx-Logik in VHDL nachbilden
> und dann das ganze, wenn es funktioniert, auf eine Platine mit eben
> diesen Gattern übertragen :)

Ebenfalls. Im Gegensatz zu den ganzen VGA-Signalerzeugern, die 
eigentlich überall der "Einstieg FPGA" sind, wäre das nämlich was Neues.

[Tim S. (Firma: tsx89) (freak_ts)]

Eine "passive VGA Grafikkarte" ohne MCU/CPU - Falls es nicht schon 
gepostet wurde. (Nur so Nebenbei):

https://www.youtube.com/watch?v=l7rce6IQDWs

https://www.youtube.com/watch?v=uqY3FMuMuRo

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Sehr spannend diese Suche nach dem Bug, erinnert mich an die erste 
Inbetriebnahme des MIPS TTL Rechners.

Es wurde ja vorher schon Mahnend erwähnt vorher alles in VHDL zu testen 
;)
Dabei muss wirklich bis auf die 74xxx runtergegangen werden.
Alleine schon um Referenzsignale im VHDL Simulator zu sehen, die man dan 
per Oszi/LA mit der reellen HW vergleichen kann!

S. R. schrieb:
> Ebenfalls. Im Gegensatz zu den ganzen VGA-Signalerzeugern, die
> eigentlich überall der "Einstieg FPGA" sind, wäre das nämlich was Neues.

Lässte auch eine "Terminalkarte" gelten ;)?
Wir haben so eine für den MIPS TTL Rechner.
ASCI rein, BAS raus.
Die gibts als reale HW und als VHDL Testimplementierung.

[Halligalli (Gast)]

Ich hätte die Grafikkarte gerne Logik-diskret ... das strahlt irgendwie 
mehr Wohligkeit aus. Aber wenn es funktioniert lade ich die 
Dokumentation hoch, dann kann es falls gewünscht auf FPGA umgeschrieben 
werden.

Dieser hoffentlich letzte Fehler ist vermutlich nicht in der Logik des 
Steuerteils zu finden, da das Beschreiben des Pixel_X-Register-Latches 
mit einem Scroll-Wert zwischen 0 und 7 nichts direkt mit deren 
Steuer-Funktion zu tun hat. Es wird aber scheinbar (beim Überlauf des 
Pixel_Y-Zählers) bei jedem Tile-Zeilen-Wechsel ein extra-Puls auf den 
Tile-Zähler gegeben. Vielleicht EMI oder ein falsch gesteckter Draht.

Dass der Übergang zwischen dem Scroll-Positionswert 5 und 6 so einen 
Fehler verursacht ist extrem mysteriös - ich bin gespannt was bei der 
Fehlersuche herauskommt  :-)

[S. R. (svenska)]

Mw E. schrieb:
> Lässte auch eine "Terminalkarte" gelten ;)?

Aber natürlich doch. Ob da nun ein BAS- oder ein VGA-Signal rausfällt, 
ist ja für den Lernfortschritt unerheblich. :-)

Halligalli schrieb:
> Aber wenn es funktioniert lade ich die Dokumentation hoch,
> dann kann es falls gewünscht auf FPGA umgeschrieben werden.

VHDL heißt nicht FPGA.

Du kannst in den VHDL-Code auch reinschreiben, dass ein Signal eine 
gewisse Verzögerung (in ns) hat - das geht nicht durch die Synthese, 
aber für die Simulation ist das prima.

Normalerweise baut man eine FPGA-Schaltung nicht aus virtuellen 74xx 
zusammen. Aber mit einer entsprechenden Simulation kannst du den realen 
Aufbau abgleichen und Fehler frühzeitig finden.

Mw E. schrieb:
> Sehr spannend diese Suche nach dem Bug, erinnert mich an
> die erste Inbetriebnahme des MIPS TTL Rechners.

Bei meinem Z80 hab ich auch sehr lange auf die Schaltung starren müssen, 
bis ich begriffen habe, warum I/O nicht funktionierte...

[Bernd (Gast)]

Halligalli schrieb:
> Ich hätte die Grafikkarte gerne Logik-diskret ... das strahlt irgendwie
> mehr Wohligkeit aus. Aber wenn es funktioniert lade ich die
> Dokumentation hoch, dann kann es falls gewünscht auf FPGA umgeschrieben
> werden.
Ja, mach das mit der Doku mal.
Ein 8051 für FPGA findet sich auch noch. Da kann dann gleich Deine 
Testsoftware drauf laufen.

Vielleicht kannst Du schon mal eine Liste der verwendeten ICs angeben...

[Halligalli (Gast)]

S. R. schrieb:
> Bei meinem Z80 hab ich auch sehr lange auf die Schaltung starren müssen,
> bis ich begriffen habe, warum I/O nicht funktionierte...

Ich habe einmal genau auf einen herausgerissenen Steckdraht gestarrt :-)

Bernd schrieb:
> Vielleicht kannst Du schon mal eine Liste der verwendeten ICs angeben...

74als74
74als153
74als157
74als193
74als191
74als244
74als374
74hct21
74als164
74ls688
74als04
74als08
74als11
74als32

Ich habe übrigens eine Ahnung wo das Problem liegen könnte: da die 
Pipeline 5 Takte länger läuft wie die sichtbare Bildzeile, zählt auch 
der Pix-X-Zähler um 5 weiter. Wenn er aber gerade auf 5 steht gibt es 
scheinbar mit dem letzten Takt einen Überlauf und dadurch erhöht sich 
der Tile-Zähler um 1. Die Steuer-Logik sollte das eigentlich 
berücksichtigen - ich werde mich mal da wieder einarbeiten.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Den ganz kleinen Vogelschiss wie Gatter:
74hct21
74als04
74als08
74als11
74als32
Muss man dann nicht extra als 74er in VHDL anlegen, da reicht dann 
wirklich die Sprache selber.
Sonst wirds unübersichtlich.
Da reichts wenn die Signalnamen in VHDL denselben Namen haben wie im 
Schaltplan.

Ein 7474 wär dann aber schon eine VHDL Baugruppe wert.

Die 74er habe ich übigens aus dem Gatterschaltbild der Datenblätter in 
VHDL nachgebaut, damit sich z ein 74181 exakt so verhält wie sein HW 
Kumpel.
(Nur eben ohne Signalverzögerungen).
Aber Achtung! Manchmal ist da was stark vereinfacht oder es fehlen 
Verbinderknubbel in den Plänen.
Daher aich pro 74er IC eine VHDL testbench bauen um zu gucken ob die 
Waveforms so aussehen wie im Datenblatt.

Von deinen ICs haben wir nur den 74688 auch im MIPS TTL verbaut.
Also nur von dem kann ich dir mal "echten" VHDL Code zeigen.

[Bernd (Gast)]

Mw E. schrieb:
> Ein 7474 wär dann aber schon eine VHDL Baugruppe wert.

-- 2 positiv flanken-getriggerte D-Flip-Flop           SN74LS74N 

library ieee;
use ieee.std_logic_1164.all;

entity SN74LS74 is
    port (
        s_n : in  std_ulogic;
        clk : in  std_ulogic;
        d   : in  std_ulogic;
        r_n : in  std_ulogic;
        --
        q   : out std_ulogic;
        q_n : out std_ulogic
    );
end entity SN74LS74;

architecture rtl of SN74LS74 is

    signal ff : std_ulogic := 'L';

begin

    process( s_n, clk, r_n)
    begin
        if rising_edge( clk) then
            ff  <= d;
        end if;
        if s_n = '0' then
            ff  <= '1';
        end if;
        if r_n = '0' then
            ff  <= '0';
        end if;
    end process;
    
    q   <= ff;
    q_n <= not ff;

end architecture rtl;

Die Frage ist, ob man den Code auf Chipebene baut (wie beim SN74LS00 
oben) oder funktionsbezogen, wie hier.

[Halligalli (Gast)]

Verdammt ... das sieht aus als wäre es in chinesisch :-)

Ich muss die letzten Jahre mental gealtert sein denn ich kann keinen 
Draht zu der VHDL-Sprache aufbauen... wenn ich C++ anschaue ist es 
dasselbe...die automatische Intuition, die fehlendes Wissen ersetzt 
fehlt einfach.

[Dergute W. (derguteweka)]

Moin,

Halligalli schrieb:
> ich kann keinen
> Draht zu der VHDL-Sprache aufbauen... wenn ich C++ anschaue ist es
> dasselbe...

Dann nimm halt Verilog statt VDHL.

Gruss
WK

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Bernd schrieb:
> Die Frage ist, ob man den Code auf Chipebene baut (wie beim SN74LS00
> oben) oder funktionsbezogen, wie hier.

Die Mischung machts, beim 74er darf man dann schonmal ein VHDL FF bauen.
Bei den komplexen ICs eben nicht mehr um ein 1zu1 Verhalten zu bekommen 
was man vllt so nicht vorhersieht (Zähler zB).

Beim 244er darf man auch etwas Tricksen und mit einem when für Tristate 
arbeiten. Die bekannte 181 ALU sollt man dann schon auf Gatterebene 
nachbauen (Anhang)

Fürn 244er kann ich nix zeigen, aber fürn 245er:

entity IC74245 is
    generic ( width : integer := 8 );
   Port ( A : inout  STD_LOGIC_VECTOR (width-1 downto 0);
           B : inout  STD_LOGIC_VECTOR (width-1 downto 0);
           DIR : in  STD_LOGIC;
           nOE : in  STD_LOGIC);
end IC74245;

architecture Behavioral of IC74245 is

begin

  --tristate A to B
  B <= A when (DIR = '1' and nOE = '0') else (others => 'Z');
  
  --tristate B to A
  A <= B when (DIR = '0' and nOE = '0') else (others => 'Z');

end Behavioral;

[Stefan F. (Gast)]

Halligalli schrieb:
> Verdammt ... das sieht aus als wäre es in chinesisch :-)

Ich habe VHDL zwar noch nie gesehen, aber ich erkenne eine gewisse Logik 
in der Sprache. Ich rate mal:

> library ieee;
> use ieee.std_logic_1164.all;

Hier wird vermutlich eine Bibliothek eingebunden. DIe zweite Zeile gibt 
an, welche Teile davon verwendet werden.

> entity SN74LS74 is port (...) end entity SN74LS74;

Beschreibt vermutlich die Eingänge und Ausgänge des Logik Gatters.

> architecture rtl of SN74LS74 is ... end architecture rtl;

Beschreibt vermutlich, was in dem Objekt drin ist. ff ist der "Speicher" 
vom Flipflop, darunter kommt die funktionale Beschreibung, also wie es 
auf Eingangssignale reagieren soll.

> process( s_n, clk, r_n)

Das sind die Eingangssignale, die verarbeitet werden sollen.

> if rising_edge( clk) then
>    ff  <= d;
> end if;

Wenn am clk Eingang eine steigende Flanke stattfindet, dann soll das 
Flipflop den Wert vom Eingang d übernehmen.

> if s_n = '0' then
>    ff  <= '1';
> end if;

Wenn der s_n (/Set) Eingang auf Low ist, dann soll das Flipflop auf 1 
gesetzt werden. Und so weiter.

Hier wird die Eigenschaft eines Gatters vom 7474 in einer C ähnlichen 
Sprache beschrieben. Immer schön nach dem Prinzip: Ein 
Ereignis/Bedingung löst eine Reaktion aus. Ist das so richtig?

Frage dazu: Wir der Code von oben nach unten ausgeführt oder läuft das 
am Ende alles parallel ab, wie in echten Logikgattern?

[Bernd (Gast)]

Stefanus F. schrieb:
> Frage dazu: Wir der Code von oben nach unten ausgeführt oder läuft das
> am Ende alles parallel ab, wie in echten Logikgattern?
Es gibt keine CPU im FPGA, die das so ausführt.

Es wird alles auf die vorhandene Logik gemappt und läuft tatsächlich 
parallel.

Wenn man VHDL für FPGA macht, muß man die Logik so beschreiben, das sie 
auch gemappt werden kann. Laut Lothar Miller sind das nur 5% von dem, 
was VHDL kann.

Im Prinzip gibt es nur zwei wichtige Elemente im FPGA: LUT und FF
Die LUT (look up table) sind kleine 1-Bit RAM, die auf jede beliebige 
Logikfunktion (AND, OR, NAND, XOR, etc.pp.) programmiert werden können 
(Kombinatorik).
Die FF (flip flop) sind synchrone 1-Bit Speicher, im Prinzip wie ein 
74x74.
Damit wird sequentielle Logik abgebildet.
Zusätzlich gibt es noch jede Menge MUXe und transfer gates um alles 
richtig miteinander zu verschalten.

[Mampf F. (mampf)]

process( s_n, clk, r_n)
begin
  if rising_edge( clk) then
    ff  <= d;
  end if;
  if s_n = '0' then
    ff  <= '1';
  end if;
  if r_n = '0' then
    ff  <= '0';
  end if;
end process;

Ist das wirklich synthetisierbar?

ff ist ein Flip-Flop und gleichzeitig wird es auch noch als Latch 
verwendet ...

Vmtl sollte es so sein:

  if r_n = '0' then
    ff  <= '0';
  elsif s_n = '0' then
    ff  <= '1';
  else
    if rising_edge( clk) then
      ff  <= d;
    end if;
  end if;

[S. R. (svenska)]

Stefanus F. schrieb:
> Hier wird die Eigenschaft eines Gatters vom 7474 in
> einer C ähnlichen Sprache beschrieben.

Jaein, die Sprache ist definitiv nicht C-ähnlich.
Verilog ist sehr C-ähnlich, aber VHDL ist es nicht.

> Immer schön nach dem Prinzip: Ein Ereignis/Bedingung
> löst eine Reaktion aus. Ist das so richtig?

Im Prinzip ja, aber eigentlich nur für die Simulation. Dort wird ein 
Prozess immer dann ausgeführt, wenn sich eins der Signale in der Liste 
am Anfang (Sensitivliste) ändert.

Für die Synthese gilt das nicht, denn:

Stefanus F. schrieb:
> Frage dazu: Wir der Code von oben nach unten ausgeführt
> oder läuft das am Ende alles parallel ab, wie in echten Logikgattern?

Alle Prozesse (und alle Zuweisungen außerhalb von Prozessen) werden 
permanent gleichzeitig ausgeführt. In einem Prozess werden alle 
Zuweisungen an Signale gleichzeitig am Ende des Prozesses übernommen.

Das heißt, dass man die Kette "Ereignis->Reaktion" nur dann bekommt, 
wenn man den Inhalt von Prozessen effektiv in "if rising_edge(clk) then 
... end if" wickelt. Ohne Takt gibt es keine Zeit, ohne Zeit keine 
Ereignisse.

Und wenn man in einem Prozess die Sensitivliste falsch ist, stimmen 
Synthese und Simulation nicht mehr überein. Ist eine nette Fehlerquelle.

Die notwendige Denkweise für VHDL (bzw. Hardware) ist überhaupt eher 
seltsam. Ein Blockschaltbild ist da deutlich intuitiver.

Bernd schrieb:
> Wenn man VHDL für FPGA macht, muß man die Logik so beschreiben,
> das sie auch gemappt werden kann. Laut Lothar Miller sind das
> nur 5% von dem, was VHDL kann.

Richtig, VHDL ist im Prinzip eine vollwertige Programmiersprache.

Allerdings eine (aus meiner Sicht) nicht besonders gute, was aber vor 
allem daran liegt, dass die Standardbibliotheken (z.B. Dateizugriffe 
oder I/O) eher mager und sehr unhandlich sind.

Komplizierte Dinge (z.B. ROM-Inhalte aus Dateien, Testsuite-Vektoren, 
Headerfiles, ...) werden, soweit ich das einschätzen kann, eher extern 
generiert als in VHDL beschrieben.

[Halligalli (Gast)]

Ich habe den Fehler beim horizontalen Scrollen gefunden: TZ_320 - das 
Signal das den Pix_X-Zähler nach 320 Takten anhält - war auf 318 Takte 
verstellt weil ich vorher ein wenig herumprobiert hatte wegen den 
Streifen am linken Bildschirmrand. Dadurch erkannte die Steuerlogik 
immer eine 7 wenn der Pix-X-Wert 5 war. Jetzt scheint das horizontale 
Scrolling zu funktionieren - da muss ich später ein ausführlicheres 
Testprogramm schreiben das über den ganzen Bereich hin und her scrollt. 
Immerhin sind neben dem sichtbaren Bildbereich noch links und rechts je 
eine Einrückspalte. Ich habe in einem schwachen Moment ein 
Richtungs-Flag (im Pix_X-Register) eingebaut damit man in einem 
laufenden Bild gleichzeitig nach links und rechts scrollen kann  :-)

Leider zeigt das Zeilen-Interrupt-Testprogramm immer noch diese 
vertikalen Streifen - das muss ich untersuchen... grundsätzlich scheint 
der Zeilen-Interrupt ja zu funktionieren, da alle 
Scrolling-Testprogramme diesen benutzen damit sie nur während V-Sync in 
das RAM schreiben.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Herzlichen Glückwunsch zum Bug fund.
Haste die ganze Nacht durchgemacht oder das mal eben noch vorm Frühstück 
gefunden ;)?

[Halligalli (Gast)]

Mw E. schrieb:
> Haste die ganze Nacht durchgemacht oder das mal eben noch vorm Frühstück
> gefunden ;)?

Ich habe gestern noch gemessen und abends die Theorie zum Fehler gehabt. 
Leider waren meine Augen zu sehr mitgenommen so dass ich erst heute 
morgen die nötigen Drahtbrücken umstecken konnte. Ich habe so viele 
unnötige Oszilloskop-Messungen gemacht ... eine einzige an der richtigen 
Stelle hätte gereicht  :-)

[F. F. (foldi)]

Halligalli schrieb:
> Halligalli (Gast)
>

Anfangs, als du das bauen wolltest, dachte ich, wieder so ein Spinner.
Jetzt muss ich den Hut vor dir ziehen.
Chapeau!

[S. R. (svenska)]

Halligalli schrieb:
> Ich habe so viele unnötige Oszilloskop-Messungen gemacht ...
> eine einzige an der richtigen Stelle hätte gereicht  :-)

Hättest du bereits vorher gewusst, wo du messen musst und was du dort 
findest, hättest du dir die Messung auch ganz sparen können. :-)

Das ist leider immer so, wenn man eklige Probleme hat.

[Halligalli (Gast)]

Laut neuem Testprogramm scrollt es über die ganze Breite und zurück ... 
aber mir gefällt dieses Abdunkeln bei jedem Scroll-Schritt nicht. Ich 
vermute dass es an der Spannungs-Versorgung liegt, Elkos hier und da 
brachten aber nichts. Als ich mal mit einem besseren Multimeter die 
Versorgungsspannung gemessen habe, schwankte sie zwischen 5V und ein 
paar Zehntel weniger gemächlich hin und her. Das erklärt wohl auch die 
langsamen Helligkeits-Schwankungen der Anzeige. Vielleicht kommen auch 
die flackernden Pixel aus der Ecke.

Ich habe das Spannungsregler-Modul von ebay, das hat einen LMxxx mit 
1,5A und war für den Modellbau. Manchmal geht die LED gleich wieder aus 
beim Einschalten - da muss wohl etwas auslösen zB. Überstrom.

Ich brauche wohl eine stärkere und stabilere Spannungsversorgung ...

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Gegen das Abdunkeln sollts schon reichen wenn der R2R DAC getrennte 5V 
von der Logik bekommt.

[Halligalli (Gast)]

Mw E. schrieb:
> Gegen das Abdunkeln sollts schon reichen wenn der R2R DAC getrennte 5V
> von der Logik bekommt.

Ich habe 2 gleiche Schaltregler-Module bestellt, die bis 3A aushalten. 
Mal schauen ob das hilft. Macht es etwas aus wenn der 
D/A-Treiber-Baustein und der Rest der Schaltung nicht genau zeitgleich 
auf Betriebsspannung kommen ?

Bis die kommen schreibe ich ein neues Zeilen-Interrupt-Test-Programm ... 
das alte sieht ziemlich Fehler-trächtig aus - war ja auch eines der 
ersten Programme nach langer Verdrahtungsphase.

[Halligalli (Gast)]

Es scheint dass das Netzteil Schuld war am Einschalt-Versagen. Heute 
sind die neuen Schaltregler-Module gekommen und als ich eins probieren 
wollte flackerte die Ausgangs-LED sporadisch. Erst dachte ich der 
Baumarkt-Schnur-Schalter sei schuld, doch als ich das Netzteil direkt an 
den Spannungsregler anschloss flackerte die LED immer noch. Das Netzteil 
ist mir einmal runtergefallen - vielleicht liegt es daran :-)

Wo bestellt man am besten ein Steckernetzteil mit etwa 10V, vielleicht 
2-3A und wenig Ripple ? Mediamarkt und Co. dürften nichts haben ...

[Stefan F. (Gast)]

Halligalli schrieb:
> Wo bestellt man am besten ein Steckernetzteil mit etwa 10V, vielleicht
> 2-3A und wenig Ripple ?

Pollin. 19V Netzteile sind vermutlich billiger zu haben, falls deine 
Spannungswandler damit klar kommen.

[Halligalli (Gast)]

Ich habe doch ein Netzteil im Elektro-Markt bekommen - bis 12V und 2A.

Leider hat es das Problem nicht gelöst ...die Ausgangs-LEDs beider 
Spannungswandler flackern sporadisch und einmal ging die LED nicht 
wieder an! Dabei habe ich sogar den Ausgang mit 4x1kOhm parallel 
belastet.

Soll ich das wirklich an das Steckbrett anschliessen ? Oder gar 
reklamieren ? Sie waren in grauen ESD-Tüten eingeschweisst und kosteten 
je 6 Euro.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Was ist denn das fürn Wandler (ali oder ebaylink?).
Das sieht nach einem Testexemplar für meine DCDC Wandler Teststrecke 
aus.

Wenn jetzt 2 Wandlertypen solch ein Verhalten zeigen, dann zieht deine 
Schaltung wohl beim Einschalten so richtig Sääft.

Besorg dir doch mal direkt ein 5V 100W NT von Meanwell.
So teuer sind die nicht und dann an mehreren Punkten auf dem STeckbrett 
einspeisen.

[Stefan F. (Gast)]

Halligalli schrieb:
> Soll ich das wirklich an das Steckbrett anschliessen ? Oder gar
> reklamieren ?

Das meinst du jetzt mit "das"? Das neue Netzteil, das alte Netzteil, 
oder die Spannungswandler?

Reklamieren würde ich sie (was auch immer) jedenfalls erst, wenn ich 
sicher wäre, dass sie mangelhaft sind - also der Beschreibung des 
Händlers nicht entsprechend. Je weniger der Händler versprochen hat, 
umso sinnloser wird der Gedanke - insbesondere wenn kein technisches 
Datenblatt vom Produkt vorliegt.

Bei chinesischen Produkten kommt dazu, dass eine Rücksendung meist 
unwirtschaftlich ist. Betrachte es als Lehrgeld. Vielleicht findest du 
einen anderen Anwendungsfall, wo die Teile doch noch brauchbar sind.

Und jetzt kommt wieder meine relevante Lieblingsfrage: Hast du die 
Verteilung der Stromversorgung inzwischen in Ordnung gebracht? Oder 
glaubst du immer noch daran, dass dieser Punkt egal sei?

[Halligalli (Gast)]

Auf ebay heisst das Angebot:

"TPS40057 DC-DC Step down Spannungswandler Modul 055L wie LM2596S 35V/5A 
Arduino"

Es war am nächsten Tag im Briefkasten als kleiner Luftpolsterbrief. 
Diese deutschen Versender können ja auch von Chinesen mit Schrott 
beliefert worden sein ... wenn ich reklamiere kriege ich bestimmt neuen 
Schrott  :-) Auf ebay gibts die Module sogar im 10er-Pack...

Mw E. schrieb:
> Wenn jetzt 2 Wandlertypen solch ein Verhalten zeigen, dann zieht deine
> Schaltung wohl beim Einschalten so richtig Sääft.

Es waren nur vier 1k-Widerstände parallel angeschlossen am Modul - nicht 
das Steckbrett.

Stefanus F. schrieb:
> Und jetzt kommt wieder meine relevante Lieblingsfrage: Hast du die
> Verteilung der Stromversorgung inzwischen in Ordnung gebracht? Oder
> glaubst du immer noch daran, dass dieser Punkt egal sei?

Ich muss erst die Saft-Quelle in Ordnung bringen - vielleicht wird das 
Gesamtbild besser wenn die passt. Ich habe übrigens noch eine Bestellung 
laufen: so ein Schaltregler-Modul das die Spannung mit LED-Display 
anzeigt.

[Stefan F. (Gast)]

Halligalli schrieb:
> Ich muss erst die Saft-Quelle in Ordnung bringen

Ja mach das. Ich dachte du hattest die Probleme unter Vollast.

[Halligalli (Gast)]

Taugt der "Meanwell APV-25-5" für die Aufgabe ? Ich meine im Datenblatt 
steht 5% Ausgangsspannungs-Toleranz und 120mV Ripple. Ich würde da einen 
Schnurschalter in die Zuleitung anbringen.

Die Meanwells mit Metallgehäuse sind mir zu gefährlich  :-)

[Stefan F. (Gast)]

120mV Ripple ist für digitale Schaltungen in der Regel Ok.

[Dergute W. (derguteweka)]

Halligalli schrieb:
> Die Meanwells mit Metallgehäuse sind mir zu gefährlich  :-)

Vielleicht gibts die ja auch in Eiche rustikal oder Nussbaum? Dann 
passen sie auch besser zur Schrankwand.

SCNR,
WK

[Halligalli (Gast)]

Es gäbe da noch die IRM-45-5 mit doppelt so guten Werten, aber mit 
Netzspannung an den Schraubklemmen  :-(

[S. R. (svenska)]

Es gibt auch normale PC-Netzteile, die werfen hinreichend stabile 5V in 
definitiv ausreichender Leistung aus.

Ältere Netzteile brauchen dafür ein bisschen Last auf der 12V-Leitung, 
aber das ist auch kein großes Problem (alte Festplatte angeklemmt 
reicht).

Beachte, dass ein gutes Netzteil wenig bringt, wenn dir in deiner 
Schaltung durch die Verkabelung nicht nur die Spannung einbricht, 
sondern auch noch die Masse wegläuft. Eine zuverlässige Versorgung sehen 
die Chips in dem Fall nämlich nie, unabhängig vom Netzteil.

Den DAC (war das ein R2R-Netzwerk?) solltest du möglichst direkt an die 
Versorgung anklemmen, damit die Helligkeit unabhängig vom Rest der 
Schaltung stabil bleibt.

[Halligalli (Gast)]

Ich werde ein wenig Feldforschung betreiben: der LED-Meanwell-Trafo ist 
unterwegs.

Wenn das nichts hilft baue ich an den R2R-Treiber einen kleinen 
5V-Regler damit der seine eigene Spannungsversorgung hat.

Wenn das auch nichts bringt spanne ich sternförmig Masse-Drähte.

[Bernd (Gast)]

Halligalli schrieb:
> der LED-Meanwell-Trafo ist unterwegs.
Wieviel Leistung hat der? Und sicher, das der auf Spannung und nicht auf 
Strom regelt?

[Halligalli (Gast)]

Bernd schrieb:
> Wieviel Leistung hat der? Und sicher, das der auf Spannung und nicht auf
> Strom regelt?

Laut Datenblatt taugt er...

[Stefan F. (Gast)]

Note 2 und 6 würden mich interessieren, sowie die 1500ms Setup Zeit.

[Halligalli (Gast)]

Stefanus F. schrieb:
> Note 2 und 6 würden mich interessieren, sowie die 1500ms Setup Zeit.

Das Datenblatt gibts bei Reichelt. Denkst du es kommt erst nach 1,5 
Sekunden Spannung heraus ? Sind 30ms Anstiegszeit zu viel ?

[Stefan F. (Gast)]

Halligalli schrieb:
> Denkst du es kommt erst nach 1,5 Sekunden Spannung heraus ?

Ja, das liest sich so. Das ist extrem langsam. Kann gut sein, dass du 
deine Schaltung dafür anpassen musst.

> Sind 30ms Anstiegszeit zu viel ?

Das wäre ein Wert im üblichen Rahmen. Aber du hast da ein LED Netzteil 
gewählt, da ist die extreme Trägheit vielleicht Absicht.

[Halligalli (Gast)]

Es ist ja so dass der TFT-4:3-Monitor einige Zeit braucht um sich 
einzuschalten - da passiert sowieso erstmal nichts nach dem Einschalten. 
So eine verspätete Versorgungsspannung könnte dem R2R-D/A einen 
Vorsprung verschaffen damit der seine 5V früher bekommt.

Übrigens ist jetzt die Zeilenformatierung dieses Threads hinüber weil 
das letzte hochgeladene Bild Überbreite hatte...jetzt heisst es 
rauszoomen oder seitlich herumscrollen.

[Stefan F. (Gast)]

Das Langsame Hichfahren der Stromversorgung könnte dazu führen, dass 
vorhandene Reset-Schaltungen (R/C Glieder) entsprechend vergrößert 
werden müssen. Ein Arduino Modul wird damit wohl kaum zuverlässig 
starten - wenn überhaupt.

[Halligalli (Gast)]

Jetzt wirds lustig: der Händler der kleinen Schaltregler-Module von ebay 
hat mir geantwortet. 9V Versorgungsspannung seien die untere Grenze und 
20mA Last würden wahrscheinlich nicht genug sein für so ein 
Hochstrom-Modul.

Ich habe 12V draufgegeben und tatsächlich leuchtet die Ausgangs-LED 
schön durchgängig. Nur einmal ging sie kurz nach dem Einschalten kurz 
aus - vielleicht hatte die Ausgangsspannung zuviel Schwung bei den 
mickrigen 20mA Last.

Ich könnte morgen so ein Modul auf das Steckbrett montieren ...

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Also die 9Vmin standen nun doch wirklich in der Angebotsseite ;)

Jedenfalls hatte ich mir den mal bestellt für meine DCDC Wandler 
Teststrecke.
So übel ist das Teil garnicht:
http://www.fritzler-avr.de/gallery/main.php?cmd=album&var1=DCDC%2FTPS40057_5A/

Aber ein Langzeittest mit 4-5A fand noch nicht statt.
Laut Artikelseite sind die 5A nur kurzzeitig?
Bei den dicken FET und der Soule sollten die eigentlich dauerhaft 
machbar sein.

[Bernd (Gast)]

Hallo Halligalli!

Sach mal, Du hast doch 74ALSxx verbaut. Sind da auch genügend 
Abblockkondensatoren im Einsatz?
Auf den Bildern oben hat meine Zoomfunktion keine entdeckt...

Schau Dir mal die Versorgungsspannung von einem etwas weiter von der 
Einspeisung entfernten IC mit dem Oszi an.

[Halligalli (Gast)]

Sch... Internet  :-)  Zu schnell hat man irrtümlich jemanden verleumdet 
- dabei ist man praktisch nur eine email entfernt...

Bernd schrieb:
> Sind da auch genügend
> Abblockkondensatoren im Einsatz?

Jeder Baustein hat einen.

Bernd schrieb:
> Schau Dir mal die Versorgungsspannung von einem etwas weiter von der
> Einspeisung entfernten IC mit dem Oszi an.

Das klingt interessant - werde ich beim nächsten Messen machen!


Mir ist übrigens heute klar geworden, dass die Tile-Karte 4 Funktionen 
zu haben scheint: (1.) räumliche Position eines Tiles am Bildschirm 
angeben (2.) dem Tile einen Namen geben von "0" bis "255"  (3.) die 
Position des Teils im Tile-Detail-Speicher angeben von 0 bis 255  (4.) 
den oberen Adress-Teil bilden, den alle Pixel dieses Tiles haben. Die 
Punkte (2.) bis (4.) werden genialerweise gleichzeitig durch den 
gleichen einen Zahlenwert erfüllt, der in dem Tile-Karten-Speicher 
steht.

[Soul E. (Gast)]

Halligalli schrieb:

> Bernd schrieb:
>> Schau Dir mal die Versorgungsspannung von einem etwas weiter von der
>> Einspeisung entfernten IC mit dem Oszi an.
>
> Das klingt interessant - werde ich beim nächsten Messen machen!

Und vor allem die Masse. Eine Groundplane wirst Du auf Deinem Steckbrett 
kaum bauen können, aber ein möglichst engmaschiges Ground Mesh sollte 
drin sein. Damit kommst Du zumindest in die Nähe einer zweilagigen 
Leiterplatte.

[Stefan F. (Gast)]

Die Stromverteilung wird er wie angekündigt als letztes prüfen.

[Halligalli (Gast)]

soul e. schrieb:
> aber ein möglichst engmaschiges Ground Mesh sollte
> drin sein

Von fast jedem Baustein gehen schwarze Minus-Drähte nach oben und unten 
zu den beiden Masse-Leisten des Steckbretts. Es hat schon irgendwie 
einen Maschen-Charakter :-)

Stefanus F. schrieb:
> Die Stromverteilung wird er wie angekündigt als letztes prüfen.

Sobald der D/A-Wandler-Baustein seine eigene Spannungsversorgung hat, 
und ich das Ergebnis beobachtet habe.

[Soul E. (Gast)]

Halligalli schrieb:

> Von fast jedem Baustein gehen schwarze Minus-Drähte nach oben und unten
> zu den beiden Masse-Leisten des Steckbretts. Es hat schon irgendwie
> einen Maschen-Charakter :-)

Die Auflösung von 
https://www.mikrocontroller.net/attachment/422406/Aufbau_Z.jpg reicht 
nicht aus um das zu erkennen, aber wichtig ist die Massebänder 
sämtlicher Steckbretter an beiden Enden einmal waagerecht und einmal 
senkrecht durchzuverbinden. Dann hast Du ein Massegitter mit ca 8 x 20 
cm2 Maschenweite.

Halb so groß wäre besser, aber ich habe auch schon schlechtere 
Anbindungen auf (zweilagigen) Leiterplatten gesehen.

Dann jeder fünften Masche einen 10µF-Elko spendieren (bevorzugt da wo 
Zähler- und Speicherbausteine sitzen). Und die Einspeisung in der Mitte 
machen, aber das hast Du ja schon.

[Halligalli (Gast)]

So ...das Zeilen-Interrupt-Testprogramm funktioniert jetzt auch - es 
hatte einen logischen Programmierfehler bei einer Schleife, dadurch lief 
die wild durch :-)

Damit wären Y-Scrolling, X-Scrolling, Raster-Interrupt und 
Daten-Schreiben in die Speicher sowie Register getestet. Jetzt kommt 
wohl ein größeres Testprogramm das alles gleichzeitig enthält - sowie 
auch aussagekräftige komplexere Tile-Muster irgendwelcher Art ... mal 
schauen wie das so geht :-)

[Halligalli (Gast)]

Der Mini-5V-Linearregler war heute in der Post und ich habe ihn gleich 
auf das Steckbrett gebaut - somit hat der D/A-Puffer-Baustein seine 
eigene 5V-Spannungsversorgung.

Es scheint dass keine einzelnen flackernden Pixel mehr auftreten, aber 
das Problem des kurz abdunkelnden Bildschirms bei jedem Scroll-Schritt 
war noch da. Aber nur bei dem billigen, alten ebay-4:3-Monitor - der 
Monitor meines PC zeigte kein Abdunkeln nachdem ich ihn über den 
VGA-zu-HDMI-Konverter anschloss.

[Halligalli (Gast)]

Ich muss jetzt eine Weile Programmieren - wer weiss wie lange das dauert 
mit Fehlersuche und so  :-) Es braucht Unterprogramme für die jeweilige 
Scroll-Richtung. Hoffentlich ist das alles während einer V-Sync-Phase zu 
schaffen...

[Stefan F. (Gast)]

Vergiss bloß nicht, das alles weiterhin ordentlich zu dokumentieren, 
sonst blickst du in 2 Jahren selber nicht mehr durch.

[Christian B. (casandro)]

Kleiner Tipp, schau Dir mal das TV Typewriter Cookbook an:
https://www.tinaja.com/ebooks/tvtcb.pdf (von der Seite des Autors)

Der hat damals in den 1970gern sehr gut zusammengeschrieben wie man denn 
solche Graphiksubsysteme baut, ohne gleich große TTL-Gräber haben zu 
müssen.

[Stefan F. (Gast)]

Christian B. schrieb:
> Kleiner Tipp, schau Dir mal das TV Typewriter Cookbook an

In diesem Buch werden Spezialbausteine verwendet, was am Sinn dieses 
Projektes vorbei geht.

[Halligalli (Gast)]

Leute ich habe eine extreme Programmier-Blockade - und es sieht nicht 
kurzzeitig aus! Daher habe ich mich entschieden, die Dokumentation 
zusammenzutragen und hochzuladen. Vielleicht hat jemand Lust damit 
herumzuspielen.

Folgende, letzte zwei Punkte sind noch nicht getestet:

(1) Scrolling innerhalb einer Tile-Zeile mittels Rasterzeilen-Interrupt 
(testet die Steuer-Logik)
(2) Scrolling mittels Versetzens der Tile-Zähler-Start-Adresse (also 
wenn das Soft-Scrolling an der Begrenzung angekommen ist neue Tiles in 
Tile-Karte und Tile-Farb-Karte schreiben)

Viel Spass  :-)

[Halligalli (Gast)]

Und gleich einen Fehler entdeckt:

Im Bild "V-Sync-Schaltung" ist oben rechts im Eck das "H-Sync"-Signal 
negiert, also mit Strich darüber. Ich denke das ist falsch, denn der 
nachgeschaltete Inverter wird nicht umsonst da sein  :-)

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Das sind dann so die Fälle wo die Steckbrettrealität nochmal mit dem 
Schaltplan abgeglichen werden muss.
Kann ja sein, dass das Signal aus einem Encoder kommt, die ja meist low 
aktiv ausgeben.

In "16 Steuerpulse .. " kommt der HSYNC ohne Negierstrich, aber du hast 
da ein Signal drüber gezeichnet nachdem es sehr low aktiv aussieht ;)

Ah, seh grade, der HSYNC kommt aus einem FF, das Q und nQ hat.
-> Nachgucken und in den Schaltplänen grade ziehen ob nun negiert oder 
nicht oder beides.
(Dann wäre der negierer auchnoch wegzusparen)

[Halligalli (Gast)]

Mw E. schrieb:
> Ah, seh grade, der HSYNC kommt aus einem FF, das Q und nQ hat.
> -> Nachgucken und in den Schaltplänen grade ziehen ob nun negiert oder
> nicht oder beides.
> (Dann wäre der negierer auchnoch wegzusparen)

Ich wollte wohl am Anfang den Inverter sparen und den /Q des Flipflop 
abgreifen. Aber da war nach dem Sync-Teil am Puffer-Baustein auf dem 
Steckbrett kein Anschluss mehr frei um diesen /Q durchzuleiten. Also 
musste der Inverter her der dann den normalen H-Sync negierte.

Der Zähler benötigt ein (einmal) invertiertes H-Sync-Signal, denn er 
muss mit der vorderen Flanke von H-Sync zählen. Da bin ich mir zu 99% 
sicher  :-)

[Halligalli (Gast)]

Ich denke ich habe eine Ursache für meine Programmier-Blockade gefunden: 
Wegen längerem Besuch ist das Wohnzimmer nicht mehr so gut verfügbar. In 
meinem Bastel-/Schlaf-/PC-Raum ist kein Tisch frei. Ich habe die 
bisherigen Test-Programme am kleinen PC-Tisch geschrieben - vorher habe 
ich die Tastatur unter den Monitor schieben müssen ... heute habe ich 
ein Testmuster auf Papier gezeichnet, dass ich im Stehen an den 
Türrahmen  oder die Schrankwand hielt  :-) Dabei scheint es dass man 
jeden Gedanken und jeden Schritt eines Programmes aufzeichnen bzw. 
aufschreiben muss sonst wird das nichts.

Übrigens sind alle Schaltungen des Projektes an einem niedrigen 
Wohnzimmertisch entstanden ...

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Dein Rücken wird sich freuen ;)

Halligalli schrieb:
> Dabei scheint es dass man
> jeden Gedanken und jeden Schritt eines Programmes aufzeichnen bzw.
> aufschreiben muss sonst wird das nichts.

Das große Problem muss eben zerlegt werden sonst wird das nunmal nix.
Wobei ich dazu eher kein Papier nehme (seiden ich zeichne ein 
Zustandsdiagramm).

Was man will als C Kommentar hinschreiben und immer detallierter werden.
Also der anfängliche Kommentar ist das Hauptkapitel und es werden immer 
mehr Unterkapitel.
Am Ende kommt da Code bei raus ;)
Ansonsten zuerst den (Doxygen) Kommentar schreiben was die Funktion 
genau machen soll inkl der dazu benötigten Variablen.

[Halligalli (Gast)]

Mw E. schrieb:
> Das große Problem muss eben zerlegt werden sonst wird das nunmal nix.

Alles muss notiert werden, dazu  noch in der richtigen Reihenfolge ... 
ich denke das alternde Gehirn kann solche komplexen Projekte nicht mehr 
aus dem Gedächtnis stemmen  :-)


Ich habe übrigens einen Logik-Fehler in der Beschreibung der 
Zähler-Steuerung korrigiert im Liesmich - hier ist die korrigierte 
Version.

[Stefan F. (Gast)]

Du könntest einzelne Dateien viel besser updaten, indem du sie auf 
irgendeinen Webserver (oder bei GitHub) veröffentlichst.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Github ist inzwischen von Mickeysoft gekapert da sollte man kein 
geistiges Eigentum mehr hochladen.
Mein syrischer Arbeitskollege zB kann sich da nicht mehr einloggen ;)

[Stefan F. (Gast)]

Ich wurde vor einigen Jahren schon für immer bei OneDrive gesperrt. 
Begründung "vermutlich" Verstoß gegen die Nutzungsbedingungen. Mehr war 
aus denen nicht heraus zu bekommen.

Ich hatte ein paar Urlaubsfotos hochgeladen, um OneDrive zu testen.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Deine Nacktfotos am Strand wollten die wohl einfach nicht sehen ;)

[Stefan F. (Gast)]

Mw E. schrieb:
> Deine Nacktfotos am Strand wollten die wohl einfach nicht sehen ;)

Irgendwas in dieser Richtung muss es wohl gewesen sein. Da waren keine 
Nackfotos bei, allerdings hat mich Verwandter darauf hingewiesen, dass 
ein posierendes Kind schon zu viel sein kann, wenn der Badeanzug zu weit 
in die Poritze gerutscht ist.

Aber ich darf einem Hund den Kopf weg schießen und das bei Youtube 
hochladen. Muss man nicht verstehen.

Wie dem auch sei: Ich hatte darum gebeten, alles zu löschen und nochmal 
anfangen zu dürfen. Aber MS hat abgelehnt.

Da merkt man dann, von was für Diensten man sich besser nicht abhängig 
macht.

[Halligalli (Gast)]

Github scheint recht kompliziert - damit werde ich nie zurechtkommen. 
Aber vielleicht so eine normale Webseite wie bei den Bastel-Projekten 
früher. Immerhin kann man den Thread hier ziemlich schnell löschen  :-)

Ich habe mich übrigens in Richtung Klapp-Stehtisch umgesehen - 
vielleicht taugen die zum Programmieren. Ausgerechnet das beste Modell 
hatte 3-5 Wochen Lieferzeit...

[Stefan F. (Gast)]

Wie ist denn so der WAF (Wife Acdeptance Factor) bei deinem Projekt in 
der engen Wohnung?

[Halligalli (Gast)]

Stefanus F. schrieb:
> Wie ist denn so der WAF (Wife Acdeptance Factor) bei deinem Projekt in
> der engen Wohnung?

Du meinst den MAF (Mother Acceptance Factor) ? Kein Problem!  :-)


Übrigens riecht es nach Fehler in der Zähler-Steuerung bei P6 - es kann 
sein dass es "X=7_Q=falsch" heissen muss ... denn der Puls sollte 
vermutlich nur kommen wenn nicht schon durch den Zeilen-End-Pix_CLK ein 
Überlauf-Puls stattfand.

Ich finde keinen 120cm hohen Klapptisch ... scheinbar hat auch hier der 
Standard-Wahn zugeschlagen - die sind alle 110cm hoch. Da waren sogar 
einige mit 80cm Tischbreite und 22kg Gewicht ... Vielleicht finde ich 
was kleines an dem ich von meinem PC-Stuhl arbeiten kann.

[Harald (Gast)]

>Ich finde keinen 120cm hohen Klapptisch ...
Du könntest kurz das Hobby wechseln und einen bauen:
https://www.youtube.com/watch?v=WOC-U3UZi38

[Halligalli (Gast)]

Harald schrieb:
>>Ich finde keinen 120cm hohen Klapptisch ...
> Du könntest kurz das Hobby wechseln und einen bauen:
> Youtube-Video "Wenig Platz? Kleine Wohnung? | Der abklappbare Esstisch!
> | Lets Bastel"

Keine Chance ...hast du mal dem sein Werkzeug und die Halle gesehen ? 
Der hat sogar die Säge-Wand vom Baumarkt-Zuschnitt  :-) Ausserdem muss 
der Tisch bei mir in der Raum-Mitte stehen, auf einem Teppich.

[Halligalli (Gast)]

Ohmann...es wird immer kurioser: es scheint man braucht den 
"X=7_Q"-Zustand gar nicht auszuwerten, da der Tile-Zähler am Zeilenende 
auf jeden Fall auf die selbe Endposition kommt - beim Links-Scrollen auf 
die rechte Einrück-Spalte und beim Rechts-Scrollen eine Spalte links vor 
der rechten Einrück-Spalte.

Was habe ich mir nur dabei gedacht ? Vielleicht lief mal wieder der TV 
nebenbei  :-) Mir wäre es recht: ein Weglassen spart ein Flipflop und 
vielleicht etwas Logik.

[Stefan F. (Gast)]

Halligalli schrieb:
> Ohmann...es wird immer kurioser

Ich verstehe zwar nur Bahnhof, aber: Gute Besserung!

[Halligalli (Gast)]

Stefanus F. schrieb:
> Ich verstehe zwar nur Bahnhof, aber: Gute Besserung!

Also doch: ohne animiertem youtube-Video versteht sowieso niemand das 
Konzept... dann muss ich es wohl unbedingt zu Ende entwickeln und 
wenigstens als Schaltung mit Beispiel-Programmen hochladen sonst war es 
umsonst.

[Stefan F. (Gast)]

Naja, wenn nur ich nichts kappiere sagt das noch nicht viel über die 
Komplexität aus.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Man muss einfach drinnestecken sonst kapiert mans nicht.
Wenn ich dir die Rechenvorschriften der MulDiv Karte des MIPS TTL 
vorsage schweben da auch erstmal drei Fragezeichen über deiner Birne ;)

Deine Doku ist bisher der Schaltplan mit etwas Text zur Einleitung.
Das hier ist die Doku der MulDiv Karte: 
Beitrag "Re: Space Age 2 der 32Bit MIPS Rechner in TTL"
Irgendwo zwischen den 2 Extremen sollte sich deine Doku einpendeln.

Halligalli schrieb:
> dann muss ich es wohl unbedingt zu Ende entwickeln
Auf jedenfall!

[Stefan F. (Gast)]

Ja, bringe es zuende und konserviere dann den Aufbau so gut es geht. 
Darauf kannst du dann echt stolz sein und es noch deinen Enkeln zeigen.

[Halligalli (Gast)]

Mw E. schrieb:
> Halligalli schrieb:
>> dann muss ich es wohl unbedingt zu Ende entwickeln
> Auf jedenfall!

Das war natürlich sehr optimistisch gemeint ... das hier ist nur ein 
allererster Konzept-Prototyp, mit vermutlich komplett überflüssigem und 
zu komplexen Richtungs-Flag in der Zähler-Steuerung und einem fehlenden 
aber benötigten RAM-Puffer mit Autokopier-Funktion. Und selbst um diesen 
Prototypen zu testen fehlt noch recht viel Arbeit - ganz zu schweigen 
von Optimierungen und Platinen-Layout.

Aber ich bin jetzt um einiges schlauer als noch vor einem Jahr! Das war 
ja damals alles rein spekulativ...


Ich habe jetzt einen Klapptisch bestellt: für sage und schreibe 18 Euro 
habe ich etwas bei einem Extremsportler-Laden gefunden (wiegt nur 2 
Kilo) - mit den Abmessungen die ich brauche. Ich kloppe jetzt die 
Scroll-Test-Programme in das Ding damit es fertig wird  :-)

[Halligalli (Gast)]

Der neue Programmier-Tisch ist prima - da passen sechs DIN-A4-Seiten 
drauf. Ich habe gleich losgelegt und die ganze 3R3G2B-Palette anzeigen 
lassen. Es war trotzdem eine schwere Geburt, da ich das Programm 
bestimmt 5 mal ändern musste.

Ich hoffe man erkennt etwas, denn es kommt scheinbar zu starker 
Streifen-Bildung. Wenn man die Zeile (0-F) als High-Nibble und die 
Spalte (0-F) als Low-Nibble nimmt, kann man den Farb-Code einer Farbe 
erhalten. Die linke obere Ecke ist 00 und die rechte untere Ecke ist FF.

Das X=7_Q-Problem bin ich noch nicht angegangen - das störte jetzt auch 
nicht, da die Palette in horizontaler Scroll-Position "L7" ist und es da 
nicht stört. Erst bei den jetzt folgenden Scrolling-Test-Programmen 
werde ich mir das ansehen.

[Halligalli (Gast)]

Hmm...bei so vielen Schwarz-Tönen wäre es möglich, die Farb-Kombination 
"00" (also das dunkelste Schwarz) als Transparenz-Wunsch-Indikator zu 
benutzen. Dadurch könnte man sich das Transparenz-Flag in der 
Tile-Farben-Karte sparen.

Wenn man noch auf das Tiefen-Flag verzichtet, könnte man mit 4 Bit pro 
Tile in der Tile-Farben-Karte auskommen (bei 16 Farb-Paletten pro 
Bildschirm) - der C64 zB. hat da nur 4 Bit pro Tile. Natürlich ist das 
nur sinnvoll wenn man Speicher sparen will - und vielleicht spart es 
auch CPU-Rechenzeit (vielleicht hat der 6502 einen 
Nibble-Tausch-Befehl).

[Halligalli (Gast)]

Ich habe 2 Möglichkeiten gesehen:

1) Man opfert eine von vier Kombinationen des Pixel-Bit-Paares und 
reduziert somit die Farben-Anzahl des Tiles auf 3 (da ja die Kombination 
00 für Transparenz benutzt wird).

2) Man opfert eine von 16 Paletten und reduziert ihre Farb-Anzahl auf 3 
(Farbe 00 wird für Transparenz verwendet).

Leider habe ich keine Ahnung wie viele Paletten es mindestens braucht 
für ein halbwegs schönes buntes Bild. Es scheint aber eine ziemliche 
Entwicklungs-technische Herausforderung zu sein, im Paletten-Modus die 
Transparenz zu steuern. Vielleicht haben die 8-Bit-Geräte-Hersteller 
damals deswegen alle die Option (1) gewählt.

[Halligalli (Gast)]

Bei Möglichkeit (1) reduziert sich die Farb-Anzahl pro Palette 
automatisch auf 3 - damit hat auch jedes Tile maximal nur 3 Farben plus 
durchscheinendem Hintergrund.

Bei Möglichkeit (2) reduziert sich die Gesamt-Farb-Anzahl des 
Bildschirmes, da einige Paletten beschränkt werden - aber das Tile kann 
bis zu 4 Farben gleichzeitig haben (ohne Hintergrund, da voll 
ausgefüllt).

Wenn man System-Speicher sparen will (durch verkleinern der 
Tile-Farben-Karte), muss man also Verluste bei der Anzahl der 
darstellbaren Farben hinnehmen.

[Halligalli (Gast)]

Ich habe bei dem Paletten-Programm einen Ablaufplan für Faule verwendet 
:-)

Ich musste auch immer die längeren Speicher-Zugriffe aufteilen und in 
das V-Sync-Interrupt-Zeitfenster legen (zB. immer nur eine Bildzeile 
füllen pro V-Sync). Am Ende kam ein 300+ Byte-Assembler-Programm heraus. 
Ich hatte 3 bis 4 Schmierblätter mit denen ich die Schleifen aufgebaut 
habe. Diese 4er-Inkremente lassen sich übrigens gut mit UND-Maske und 
Rotier-Befehl durchführen.

[Halligalli (Gast)]

Ich habe ein Soft-Scrolling-Test-Programm zusammengepfuschelt, aber 
leider vergessen die gleichzeitig-nach-links-und-rechts-Funktion 
einzubauen.

Naja ...jetzt ist es auf youtube und ich finde nichts um es zu löschen 
:-)

https://www.youtube.com/watch?v=lUe9xbuXrH4

Ich habe an dem X=7_Latch-Signal nichts geändert, aber ich habe es 
überprüft und nachgemessen: es ist genau wie im Ablauf- und Schaltplan 
auf dem Steckbrett.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

So langsam wirds doch was!
Schickst du so selten einen Scrollbefehl raus oder braucht das einfach 
so lange?

[Halligalli (Gast)]

Mw E. schrieb:
> Schickst du so selten einen Scrollbefehl raus oder braucht das einfach
> so lange?

Das Programm wartet zwischen jedem Schritt eine Sekunde, damit man 
mitzählen kann.

Am rechten Bildschirmrand wird das letzte Pixel nicht ganz dargestellt, 
weil H-Blank zu schnell aktiv wird. Ausserdem habe ich wohl die Aufnahme 
zu schnell angehalten, denn es hätte noch einen Pixel nach rechts 
scrollen müssen am Ende. Es hat auch noch geflackert bei jedem Schritt 
weil der uralte Monitor bestimmt einen Schuss hat... und die Farbwahl 
für die Paletten war auch nicht gut - manche Farben sind scheinbar 
unbrauchbar...

[Halligalli (Gast)]

Ich habe mich schon tagelang gefragt warum das "X=7_Q" da ist und die 
Schaltung überhaupt funktioniert, da scheinbar ein Zähl-Puls für den 
Tile-Zähler fehlt.

Jetzt weiss ich es: das Laden des Pix-X-Zählers mittels "X_ODER" erzeugt 
bereits in 7 von 8 Fällen einen Zähl-Puls für den Tile-Zähler. Für den 
achten Fall (wenn der Pix-X-Zähler schon auf 7 steht) muss der Zähl-Puls 
für den Tile-Zähler von P6 extra erzeugt werden.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Irgendwann tritt bei jedem der Fall ein, dass er Teile seiner Schaltung 
selber reverse engineeren muss :)

Also warteste mit Absicht.
Kannst ja bei Gelegenheit mal ein Video mahen wo es shcnell scrollt 
damit es nicht nach Diashow aussieht.

[Halligalli (Gast)]

Ich frage mich gerade ob es nicht einfacher wäre auf das 
Echtzeit-Rendern zu verzichten und lieber auf einmal in einen Puffer zu 
rendern.

Wenn man zB. eine 80ns-CLK benutzen würde würde es wohl um die 6ms 
dauern um 70k+ Pixel in den Puffer zu rendern. Fragt sich nur welches 
Datenformat man benutzen soll: 1 Byte pro Pixel um die 256 Farben zu 
beschreiben - oder etwas Kompliziertes mit Paletten und einigen wenigen 
Bit pro Pixel ?

So ein Puffer wäre möglicherweise leichter mit Sprite-Daten zu 
beschreiben. Man könnte auch 240 Byte vorsehen um jede Bildzeile 
individuell scrollen zu lassen, und weitere 240 Byte um eine 
individuelle Hintergrundfarbe auszuwählen. Möglicherweise spart man sich 
mit Puffer-Rendern ein paar Speicher-Bausteine ein - bis auf den dicken 
für den Puffer selber  :-)

[S. R. (svenska)]

Halligalli schrieb:
> Ich frage mich gerade ob es nicht einfacher wäre auf das
> Echtzeit-Rendern zu verzichten und lieber auf einmal in
> einen Puffer zu rendern.

Du kannst zwei SRAMs nehmen: Aus dem einen wird dargestellt, ins andere 
wird geschrieben. Wenn fertig gerendert ist, wird umgeschaltet. Dann 
kannst du beliebig kompliziert rendern, aber ein Controller wäre 
sinnvoller.

Ist nicht der Sinn eines Tile-Renderers, dass er "live" rendert? Ob das 
Ziel nun ein SRAM ist (aus dem du dann darstellst) oder nicht, sollte 
auch egal sein.

Nee, wenn du in einen Backbuffer renderst, dann ist das nicht mehr das, 
was du ursprünglich wolltest, sondern eine primitive Form von dem, was 
man in Embedded-Chipsätzen als GPU findet.

Und den Renderer brauchst du trotzdem.

[Halligalli (Gast)]

S. R. schrieb:
> Ist nicht der Sinn eines Tile-Renderers, dass er "live" rendert? Ob das
> Ziel nun ein SRAM ist (aus dem du dann darstellst) oder nicht, sollte
> auch egal sein.
>
> Nee, wenn du in einen Backbuffer renderst, dann ist das nicht mehr das,
> was du ursprünglich wolltest, sondern eine primitive Form von dem, was
> man in Embedded-Chipsätzen als GPU findet.
>
> Und den Renderer brauchst du trotzdem.

Die Tile-Technik ist ja eigentlich nur eine Kompressions-Methode, um 
Speicher zu sparen und die CPU zu entlasten. Das Live-Rendern spart auch 
das viele RAM für den/die Puffer. Vielleicht waren auch die Bausteine zu 
langsam (1980 ?) um schnell einen Puffer voll zu rendern.

Früher wurde um jedes Byte geknausert - ich glaube die haben damals mit 
der Hand die Masken für die Chip-Produktion gezeichnet.

[S. R. (svenska)]

Halligalli schrieb:
> Die Tile-Technik ist ja eigentlich nur eine Kompressions-Methode,
> um Speicher zu sparen und die CPU zu entlasten.

Das ist doch dein Ziel, oder? :-)
Eine 8 Bit-CPU ist langsam und hat mit "viel Speicher" ihre Probleme.

Halligalli schrieb:
> Das Live-Rendern spart auch das viele RAM für den/die Puffer.

Als Nebeneffekt ist das Renderergebnis latenzfrei, immer aktuell und 
leider nicht unter Tearing. Bei einem Backbuffer ist das nicht der Fall. 
Außerdem ist ein Tile-Renderer hinreichend einfach aufgebaut, dass man 
den in relativ wenig Hardware gießen kann.

Halligalli schrieb:
> Vielleicht waren auch die Bausteine zu langsam (1980 ?)
> um schnell einen Puffer voll zu rendern.

Um mit einem Puffer auszukommen, müsstest du in den RAM-Baustein 
rendern, während du gleichzeitig aus dem RAM-Baustein ausliest. Du 
brauchst also einen zweiten Port (-> VRAM) oder doppelte Bandbreite.

Ein Tile-Renderer mit Backbuffer ist jedenfalls nicht so richtig 
sinnvoll. Wenn du den Weg gehen willst, dann gibt es bessere Ansätze für 
verschiedene Anwendungsfälle.

Du kannst z.B. eine Tabelle aus Zeichenoperationen im Speicher halten, 
die pro Frame komplett abgearbeitet wird. Die Framerate hängt dann von 
der Tabellenlänge und -komplexität ab.

Am Ende ist es deine Entscheidung. Ich bin jedenfalls überrascht, dass 
du es soweit gebracht hast - coole Sache. :-)

[Halligalli (Gast)]

Ich habe zwar fast ein bidirektional scrollendes Programm fertig, aber 
mir kommen immer mehr Zweifel... Ich habe Angst dass private Computer 
ohne Netzwerk nicht gerne gesehen werden und fühle mich fast schon als 
Staatsfeind  :-)

Die wollen tatsächlich alles vernetzen ... ich wollte mir eine kleine 
Audio-Anlage kaufen aber die haben alle Bluetooth. Bald werden wohl auch 
alle TV nur noch mit Netzwerk zu kaufen sein. Der Plan die Autos zu 
vernetzen steht ja schon fest. In die Wohnung können sie sowieso horchen 
über Router, DECT-Telefon, Handy, Tablet usw.

Vielleicht bleibt irgendwann nur noch das Buch als Freizeitbeschäftigung 
übrig ... vielleicht noch ein leises Musikinstrument lernen, zB. Kalimba 
:-)

[Stefan F. (Gast)]

Halligalli schrieb:
> Bald werden wohl auch
> alle TV nur noch mit Netzwerk zu kaufen sein.

Der Hersteller von meinem DVB-T2 Receiver hat bereits eine Ethernet 
Buchse eingebaut. Wenn ich da ein Kabel einstecke, holt sich das Gerät 
auch eine IP-Adresse via DHCP. Aber wozu Buchse da ist: Keine Ahnung! 
Weder im Menü noch in der Bedienungsanleitung ist dazu irgend etwas zu 
finden. Updates werden per USB installiert, das steht drin.

Ich habe sie sicherheitshalber mal angeschlossen, damit ich den 
Geheimdiensten nicht negativ auffalle.

.... nee, habe ich natürlich nicht.

[Dergute W. (derguteweka)]

Moin,

Stefanus F. schrieb:
> Der Hersteller von meinem DVB-T2 Receiver hat bereits eine Ethernet
> Buchse eingebaut.

Jo, meinen 20 Jahre alten dbox2 Receivern war das tatsaechlich auch 
schon der Fall...unfasslich ;-)

Halligalli schrieb:
> Ich habe Angst dass private Computer
> ohne Netzwerk nicht gerne gesehen werden und fühle mich fast schon als
> Staatsfeind  :-)

Yupp. So ist's. Dagegen hilft nur: Origami lernen; sich aus Alufolie 
einen Hut basteln und den aufsetzen.

SCNR,
WK

[Halligalli (Gast)]

Hmm... so ein über-300-Bausteine-Computer eines Einzelnen, der dann 
vielleicht von einigen wenigen Sadisten nachgebaut wird sollte ja keine 
Bedrohung darstellen.

Ich bastel einfach weiter...es gibt schlimmere Hobbys :-)

[Prisem (Gast)]

Dergute W. (derguteweka)
>Yupp. So ist's. Dagegen hilft nur: Origami lernen; sich aus Alufolie
>einen Hut basteln und den aufsetzen.

Immer diese Verschwörungstheorien!

https://www.heise.de/newsticker/meldung/BND-Ueberwachung-De-CIX-Betreiber-will-vors-Bundesverfassungsgericht-4062601.html

https://www.heise.de/newsticker/meldung/34C3-Details-zum-Intel-Management-Engine-Hack-3928301.html

[S. R. (svenska)]

Halligalli schrieb:
> Ich habe Angst dass private Computer ohne Netzwerk nicht gerne
> gesehen werden und fühle mich fast schon als Staatsfeind  :-)

Noch sind das eher die Firmen, die das mit Gewalt vorantreiben... die 
meisten Staaten selbst sind da (noch) nicht so stark dran interessiert. 
Kommt aber noch, wenn die ersten Privatfirmen behördliche Aufgaben 
übernehmen müssen, weil der Staat es nicht mehr schafft.

> ich wollte mir eine kleine Audio-Anlage kaufen aber die haben
> alle Bluetooth.

Kostet wenig, ist aber in bestimmten Situationen sehr praktisch und dank 
kurzer Reichweite auch recht sicher.

> Bald werden wohl auch alle TV nur noch mit Netzwerk zu kaufen sein.

Jeder SmartTV hat Netzwerkanschluss. Gibt es eigentlich noch Geräte ohne 
Smart-Funktion zu kaufen? Du bist zu spät. :-)

> Der Plan die Autos zu vernetzen steht ja schon fest.

Seit März 2018 ist jeder Neuwagen gesetzlich zur Vernetzung per 
SIM-Karte verpflichtet (eCall). Du bist zu spät. :-)

> In die Wohnung können sie sowieso horchen
> über Router, DECT-Telefon, Handy, Tablet usw.

Für den Staat ist das alles sehr hoher Aufwand. Die Hersteller haben da 
teilweise mehr Spielraum, z.B. kommen einige chinesische Router mit 
einem vorkonfiguriertem tcpdump. Bei den heutigen Geschwindigkeiten 
fällt das ja nicht mehr weiter auf. Wie auch immer: Du bist zu spät. :-)

> Vielleicht bleibt irgendwann nur noch das Buch
> als Freizeitbeschäftigung übrig ...

Die Begriffe "Bücherverbrennung" und "eBook" kennst du aber, oder? :-)

Sowas läuft übrigens schleichend und mit erstaunlich geringem 
Widerstand. Wenn du dich traust, dann empfehle ich diesen Artikel: 
https://de.wikipedia.org/wiki/B%C3%BCcherverluste_in_der_Sp%C3%A4tantike

Halligalli schrieb:
> Hmm... so ein über-300-Bausteine-Computer eines Einzelnen, der
> dann vielleicht von einigen wenigen Sadisten nachgebaut wird
> sollte ja keine Bedrohung darstellen.

Die Sadisten fummeln den dann in VHDL nach. :-)

[Halligalli (Gast)]

Hat da nicht jemand das NES mit einem FPGA nachgebaut ? Da muss man 
teilweise gar nicht auf Schaltungs-Ebene runtergehen habe ich gelesen 
... vielleicht definiert man nur irgendwelche Variablen und Formeln und 
die Entwicklungsumgebung macht den Rest  :-)

[Stefan F. (Gast)]

S. R. schrieb:
> Noch sind das eher die Firmen, die das mit Gewalt vorantreiben... die
> meisten Staaten selbst sind da (noch) nicht so stark dran interessiert.
> Kommt aber noch, wenn die ersten Privatfirmen behördliche Aufgaben
> übernehmen müssen, weil der Staat es nicht mehr schafft.

Wenn du in die USA einreist und von gar keinem sozialen Netzwerk einen 
Account angibst, bist du bereits verdächtig. Wenn du dann auch noch 
behauptest, keinen Google Account zu haben obwohl du ein Android Phone 
in der Tasche hast, musst du damit rechnen, eine Weile lang festgehalten 
zu werden.

[S. R. (svenska)]

Stefanus F. schrieb:
> S. R. schrieb:
>> ... die meisten Staaten ...
> Wenn du in die USA einreist und von gar keinem sozialen
> Netzwerk einen Account angibst, bist du bereits verdächtig.

Hast du da persönliche Erfahrung? Als ich das letzte Mal in den USA war, 
spielte das jedenfalls keine Rolle und Kollegen, die da von Berufs wegen 
öfter sind, haben das auch nicht erwähnt. In Russland musste ich am 
Flughafen nur zeigen, dass das Gerät tatsächlich zuckt (= Bildschirm 
einschalten).

Davon abgesehen: Ich schrieb "die meisten" Staaten, nicht "alle".

[Stefan F. (Gast)]

S. R. schrieb:
> Hast du da persönliche Erfahrung?

Nein, das kommt aus einem TV Bericht vom WDR.

[Halligalli (Gast)]

Ich habe ein Testprogramm zum bidirektionalen Soft-Scrolling 
fertig-gepfuschelt  :-)

https://www.youtube.com/watch?v=ervFAv5QaYg

Zwischen jedem vertikalen Schritt wartet das Programm 5 
V-Sync-Interrupte (steht auf dem Schmierblatt falsch...ist veraltet).

[S. R. (svenska)]

Halligalli schrieb:
> Ich habe ein Testprogramm zum bidirektionalen Soft-Scrolling
> fertig-gepfuschelt  :-)

Sieht schick aus.
Mir fehlte in dem Video nur die Schaltung selbst. :-D

[Halligalli (Gast)]

S. R. schrieb:
> Mir fehlte in dem Video nur die Schaltung selbst. :-D

Rechts unten im Eck sieht man die Zähler-Steuerlogik :-) Leider ist das 
Video sehr unscharf weil youtube erst bei mehreren Aufrufen die 
Auflösung erhöht. Das Original-Video ist total scharf.

[Halligalli (Gast)]

Leider muss ich gestehen, dass ich extreme Konzentrations- und 
Motivations-Schwierigkeiten habe  ... dabei hätte ich selber gerne ein 
letztes Demo-Programm geschrieben, welches über die 
Soft-Scrolling-Grenze geht und ganze Tiles nachlädt. Das Konzept ist in 
meinem Kopf, aber die detaillierten Einzelschritte wollen einfach nicht 
motiviert werden. Ich habe das Problem irgendwo im unteren Rücken 
lokalisiert - da kam früher voll die Energie raus!

Naja ... vielleicht später irgendwann - ich lasse den Steckbrett-Aufbau 
mal so. Vielleicht kann man ihn sogar an die Wand nageln als Kollage :-)

[Stefan F. (Gast)]

Ich würde das mit einer ordentlichen Portion Sprühlack überziehen.

[Fitzebutze (Gast)]

Stefan F. schrieb:
> Wenn du in die USA einreist und von gar keinem sozialen Netzwerk einen
> Account angibst, bist du bereits verdächtig. Wenn du dann auch noch
> behauptest, keinen Google Account zu haben obwohl du ein Android Phone
> in der Tasche hast, musst du damit rechnen, eine Weile lang festgehalten
> zu werden.

Ehm. So ein Quatsch. Ich weiss nicht, warum das immer wieder verbreitet 
wird. Eher noch relevant ist dein Palantir-Score. Worauf der beruht, hat 
wohl vor allem damit zu tun, mit wem du "befreundet" bist, aber wie 
dieses "Precrime"-Schema funktioniert, ist wohl Firmengeheimnis..

Zum Thema:

Halligalli schrieb:
> Hat da nicht jemand das NES mit einem FPGA nachgebaut ? Da muss man
> teilweise gar nicht auf Schaltungs-Ebene runtergehen habe ich gelesen
> ... vielleicht definiert man nur irgendwelche Variablen und Formeln und
> die Entwicklungsumgebung macht den Rest  :-)

Wenn dann nach diesem sicher sehr lehrreichen Ansatz mal die Luft raus 
ist, und du doch noch Lust hast, das ganze frisch aufzuziehen: Genau 
solche Sachen im FPGA nachzubauen macht doch einiges Spass, weil man 
deutlich schneller vom Fleck kommt.

Das Thema ist auch nicht ganz ohne Brisanz: Die RISC-V community ist 
tuechtig dabei, neue GPU-Konzepte bzw. Befehlssätze zu entwerfen (sowas 
wie Mali450/NEON-Extensions in OpenSource). Das ist zwar ne andere 
Nummer, aber kreativer Nachwuchs hat trotzdem Zukunftschancen. 
Vielleicht wirst du ja mit deinem angeworbenen Wissen richtig gut in der 
high level HDL.

Und was den Staatsfeind angeht: Kann dich beruhigen, wenn das so wäre, 
wäre die ganze RISC-V-Community Staatsfeinde. Die bauen nämlich alle 
ihre eigenen Computer.

[Der Philosoph (Gast)]

Extreme Konzentrations- und Motivations-Schwierigkeiten soso.

Vom Apple I-Platine nachbauen wird man noch lange kein Multimillionär. 
Der Zug ist schon längst abgefahren. Damit weiter zu machen grenzt an 
Größenwahn.

Ich würde eher sagen dass hier erkannt wurde, dass dieser Weg auf Dauer 
nicht das Richtige ist. Man möchte etwas erproben. Ist völlig klar... Es 
sieht zwar interessant aus wenn es nach den Fähigkeiten geht, aber wem 
nutzt das dann letztendlich? Erst mal muss der Sinn des Lebens 
verstanden werden und die Frage gestellt werden wofür Elektronik 
überhaupt gut ist?

Allein die Frage "Bauen oder nicht bauen?" zeugt von Verunsicherung und 
Unklarheit. Manche sehnen sich nach Retro, die anderen sind mit ganz 
anderen Problemen beschäftigt. Da driftet etwas auseinander. Kein Wunder 
dass jetzt die große Unlust kommt.

Tu dieses Projekt rein in ein Portfolio für die zukünftigen 
Überzeugungen.

Nein nicht später irgendwann weitermachen, sondern das Prinzip 
verstehen.

Die Lust kommt zurück wenn die elektronische Anwendung ganz andere 
Aufgaben bekommt.

Also: was macht die Welt, woran hängt die Gesellschaft und was ist jetzt 
völlig klar?

[Halligalli (Gast)]

Stefan F. schrieb:
> Ich würde das mit einer ordentlichen Portion Sprühlack überziehen.

Davor muss aber erst der klebrige Staub weg  :-)

Der Philosoph schrieb:
> Erst mal muss der Sinn des Lebens
> verstanden werden

Als ich 42 Jahre alt war habe ich da grausiges gesehen... ob die Zahl 
deswegen so speziell ist ?

Ich würde übrigens gerne wissen ob es möglich ist eine Sprite-Engine zu 
entwickeln. Bei den Vorgaben mit dem Zeilen-gedoppelten VGA-Format 
dürfte das nicht ganz einfach sein. Man müsste das irgendwie 
visualisieren - also wie sich die Sprites überschneiden, aus dem Rahmen 
herausragen, Prioritäten usw. Laut einer ominösen Text-Quelle wurden die 
Sprites früher kurz nach H-Sync vorgerendert ...

Der Philosoph schrieb:
> Tu dieses Projekt rein in ein Portfolio für die zukünftigen
> Überzeugungen.

Dieses Projekt hat einige Möglichkeiten aufgeworfen, die man verfolgen 
könnte - zB. die Transparenz-Option in der Farbpalette angeben oder auch 
einen Puffer vor die vier Speicher der Pipeline setzen. Auch steht das 
endgültige Konzept gar nicht fest, also wieviele Paletten es haben soll 
usw.

[Stefan F. (Gast)]

Halligalli schrieb:
> Ich würde übrigens gerne wissen ob es möglich ist eine Sprite-Engine zu
> entwickeln.

Ja sicher, hatten die Computer der 80er Jahre doch auch. Aber wozu soll 
das gut sein? Aktuelle Grafikkarten funktionieren aus gutem Grund ganz 
anders.

[Halligalli (Gast)]

Stefan F. schrieb:
> Halligalli schrieb:
>> Ich würde übrigens gerne wissen ob es möglich ist eine Sprite-Engine zu
>> entwickeln.
>
> Ja sicher, hatten die Computer der 80er Jahre doch auch. Aber wozu soll
> das gut sein? Aktuelle Grafikkarten funktionieren aus gutem Grund ganz
> anders.

Schon mal die aktuellen Grafikkarten programmiert ? Da holt man sich 
bestimmt einen Krampf  :-)  Und nach ein paar Jahren landen die auf dem 
Müll und werden vergessen ...

Ich hätte Lust mich in VHDL einzulesen ... dann muss man vielleicht 
nichts mehr auf Steckbrett verdrahten sondern kann es simulieren und auf 
Test-Platine löten.

[Mampf F. (mampf)]

Stefan F. schrieb:
> Halligalli schrieb:
>> Ich würde übrigens gerne wissen ob es möglich ist eine Sprite-Engine zu
>> entwickeln.
>
> Ja sicher, hatten die Computer der 80er Jahre doch auch. Aber wozu soll
> das gut sein? Aktuelle Grafikkarten funktionieren aus gutem Grund ganz
> anders.

Ich glaube Halligalli könnte an der Commander X16 Community auf Facebook 
[3] interessiert sein.

Dort wird ein neuer 8Bit-Computer entwickelt und zum Einsatz kommt eine 
eigens entwickelte Grafikkarte (in einem FPGA), die Sprites, Tiles, 
Scrolling, Planes und etliche Grafikmodis kann.

Besonders nett ist, dass es den X16-Emulator quelloffen gibt. Es gibt 
sogar eine Online-IDE zum ausprobieren des Computers [2].

Vielleicht wäre das ganz lehrreich, wie das mit den Sprites usw 
funktioniert :)


[1]: https://github.com/commanderx16/x16-emulator
[2]: https://x16.tmp2k.com/
[3]: https://www.facebook.com/groups/CommanderX16/

[Halligalli (Gast)]

Es scheint dass die CommanderX16-Leute alles geheimhalten - zumindest 
finde ich auf Github keine Schaltpläne oder Ähnliches.

Ich habe mir eine Sprite-Render-Lösung durch den Kopf gehen lassen...

Der Ausgang ist klar: Zugriff auf den Sprite-Detail-Speicher bei jedem 
Pixeltakt, um das Pixel-Bitpaar auszulesen und damit auf die 
Farb-Palette zuzugreifen.

Der Y-Zeilenzähler des Sprites wird bei jedem (zweiten) H-Sync 
weitergezählt, der X-Spaltenzähler bei jedem Pixeltakt - sofern die 
Zähler aktiviert wurden durch zB. Komparator-Erkennungen einer 
Übereinstimmung von Bildzeile/-Spalte.

Die 8 Sprites Sprites bekommen alle je einen internen Zeilen- und 
Spalten-Zähler (4 Bit wenn es 16x16-Pixel-Sprites sein sollen).

Jetzt kommt das grosse Problem: die Schaltung am Ausgang muss wissen, 
welches Sprite es zeichnen soll! Am besten als eine Zahl von 0 bis 7, 
damit es damit gleich auf den Sprite-Detail-Speicher zugreifen kann. Das 
klingt einfacher als gesagt: wie soll man möglichst schnell und 
effizient feststellen, welches Sprite an genau diesem Bild-Pixel evtl. 
Transparent ist und welches die höchste Priorität hat ?

Ich weiss das ein (Detail-) Speicher fortwährend vom Ausgang benutzt 
wird, um bei jedem Pixeltakt mit dem Bitpaar die Palette auszulesen und 
dann letztendlich die Pixelfarbe zu erzeugen. Und es gibt zu Beginn 
einer Bildzeile etwa 70 Pixeltakte, bevor das erste Pixel sichtbar wird 
- man könnte also in dieser Zeit zB. alle an der aktuellen Bildzeile 
beteiligten Sprite-Zeilen in einen extra-Speicher kopieren oder etwas 
damit logisch verknüpfen usw.

Insgesamt habe ich kein gutes Gefühl: es müssen entweder pro Pixeltakt 
acht Bitpaare auf Priorität überprüft werden (recht unmöglich ohne 8 
einzelne Speicher) oder man muss in den 70 Pixeltakten am Zeilenbeginn 
etwas unternehmen was dem Ausgang die Prioritäts-Zahl liefert (auch 
unwahrscheinlich)...

[Halligalli (Gast)]

Ich hatte gestern vor dem Einschlafen eine "Erleuchtung"  :-)

Es scheint dass die ganze 8-Bit-Grafik-Geschichte zwingend ein 
gestapeltes Aneinanderreihen von Speicherbereichen benötigt - und zwar 
so dass man mit einem/mehreren höherwertigen Adressbits solche 
Speicher-Blöcke "durchschalten" kann. Ich meine diese binären Grenzen, 
an denen sich immer etwas verdoppelt/halbiert.

Ich habe mich gewundert warum die C64-Sprites 24x21 Pixel haben - aber 
die vertikale Reduzierung auf 21 Pixel ist nötig damit die 
Sprite-Pixeldaten in einen 64-Byte-Block im Speicher passen (es sind 
aber nur 63 Bytes, ein Byte wird verworfen). Dieser 64-Byte-Block ist 
dann wiederum leicht durch Verändern höherwertiger Adress-Bits stapelbar 
Adressierungs-fähig da er an so einer binären Grenze liegt.

Beim NES mit seinen 8x16-Sprites dürfte es die selbe Geschichte sein, 
nur mussten sie da mehr Sprites ermöglichen weil diese 8x16 Pixel zu 
mickrig sind. Aber scheinbar werden doch nur 8 Sprites pro Bildzeile 
gleichzeitig gezeichnet ...

[Thomas W. (diddl)]

Sprites sind ein Relikt der 8 Bitter Ära.
Der Mangel an Ressourcen in der CPU sind so ausgeglichen worden.


Heute hat eine Grafikkarte nur noch möglichst viele Pixel (full HD) in 
möglichst vielen Farben (8x8x8 RGB).
Keine Paletten mehr, keine Charsets.
Der Rest, das rendern, wird in Software gemacht.
Zur Not bekommt die Grafikkarte einen eigenen Prozessor, oder hunderte 
davon.




Für den AVR im Arduino (ist ja auch ein 8 Bitter) hat jemand eine Open 
Source Schaltung gemacht:
- mehrere Planes (Background, foreground graphics)
- Auflösung 400x300 Pixel mit 512 Farben
- Farbauflösung 15 Bit
- Scrolling in Hardware (Pixelverschub)
- VGA Ausgang
- Textmode mit 256 Zeichen
- 256 Sprites 16x16 mit Kollisions Erkennung
- gleich noch eine Sound Ausgabe dabei


Die Hardware wurde aber nie aufgebaut sondern in einen FPGA gegossen.



Gameduino:
- https://excamera.com/sphinx/gameduino/index.html
- Poster: https://oe7twj.at/images/f/f3/GameDuino_Poster.pdf

[Halligalli (Gast)]

Der Gameduino ist der totale schaltungstechnische Overkill ... da müssen 
Profis am Werk gewesen sein. Ob sich das gut verkauft ? Man liest 
irgendwie nichts davon.

Aber programmieren möchte ich den trotzdem nicht ... vielleicht 
befriedigt es einen der C++-Jünger der Arduino-Fraktion :-)

Sieht auch irgendwie mehr nach 16-Bit-Ära aus, mit den vielen Sprites 
und Hintergründen ...

[Halligalli (Gast)]

Und lästere ja nicht über 8-Bit-Sprites! Wenn man als Kind damit 
aufgewachsen ist dann gefällt einem das  :-)

Stell dir einfach vor damals gab es nichts besseres ... es war auch 
bombastisch am Röhren-TV, und diese 8-Bit-Töne gaben einem den Rest!

[Thomas W. (diddl)]

Halligalli schrieb:
> Und lästere ja nicht über 8-Bit-Sprites! Wenn man als Kind damit
> aufgewachsen ist dann gefällt einem das  :-)

Nee ich lästere nicht, auch ich bin mit einem C64 aufgewachsen.


Ich sag nur, dass Sprites ein Relikt der 8-Bit Ära sind.
Es war die einzige sinnvolle Lösung für damalige Verhältnisse.

[Stefan F. (Gast)]

Halligalli schrieb:
> Und lästere ja nicht über 8-Bit-Sprites! Wenn man als Kind damit
> aufgewachsen ist dann gefällt einem das  :-)

Ähhhh, nein. Ich war auch nie ein Freund von den 4 blassen 
Mädchenfarben.

[Halligalli (Gast)]

Vermutlich wird die heutige Jugend niemals verstehen, wie es war ohne 
viele Medien aufzuwachsen. Wenn man dann in einem Atari-2600-Spiel einen 
(einfarbigen ?) Panzer oder Düsenflieger steuern konnte war das voll 
krass  :-)

Übrigens hatten wir kein Geld für solche Geräte - ich hatte das alles 
bei einem benachbarten Freund spielen dürfen. Erst viel später 
beschwatzte ich meine Mutter solange bis sie mir ein SNES kaufte  :-) 
Ich hatte aber irgendwann einen C64 mit dem ich versuchte ein wenig zu 
Programmieren - das führte aber zu nichts ohne richtige Ahnung. 
Irgendwann habe ich ihn wohl verkauft. Die Spiele waren auch kaum 
spielbar - Bards Tale, Ultima, SSI-Schinken waren alle zu schwer und 
klobig. Insgesamt habe ich sogut wie sämtliche guten C64-Spiele verpasst 
- hatte kaum Literatur und Internet gab es nicht. Auch wunderte es mich 
damals schon dass man ständig töten und sterben muss - und unfair waren 
die Spiele auch noch!

Oh ... und Pacman war echt viel zu schwer damals. War auch mein 
allererstes Videospiel. Anfangs wollte ich nicht und ich hatte Schmerzen 
vom gleichzeitig Steuerknüppel drücken und auf den Fernseher gucken. 
Doch danach kam so eine komische Sucht ;-)

[Halligalli (Gast)]

Sagt mal...hat jemand eine Idee für ein Karten-/Brettspiel ? Es muss 
nicht mal elektrisch sein, da man auch mit der Hand würfeln oder was 
drehen könnte. Auch Gewalt-reduzierter Inhalt wäre willkommen.

Hintergrund ist folgender: ich habe mir teuer eine PS4 1TB gekauft (weil 
ich Depp erst zuhause gemerkt habe habe dass es nicht die gewollte 
500GB-Version ist ... war Kartenzahlung und die Kartons standen 
nebeneinander im Regal). Ich fand auch einige brauchbare Spiele wie 
Risen 3.

Doch jetzt kommts: Mitten im Spiel schaut die Kamera nach unten weil 
"der Analog-Knüppel des teuren PS4-Controllers driftet" - selten so gut 
gelacht haha. Die PS4 hat tatsächlich keine Totzeit-Einstellung dafür. 
Das passiert bei jedem Spiel zufällig und macht das Spielen zur Qual!

Ich krieg langsam Paranoia, vor allem da seit Kurzem auch die Musik im 
PSN-Shop nicht mehr hörbar ist und soetwas wie ein Zeitlimit herrscht - 
da funktioniert einfach nichts mehr wie zB. youtube oder ein Download 
nachdem man eine längere Zeit gespielt hat.

[S. R. (svenska)]

Halligalli schrieb:
> Sagt mal...hat jemand eine Idee für ein Karten-/Brettspiel ?

Hängt davon ab, was du machen möchtest. Für "normale" Spiele wird einen 
Blick auf "Spiel des Jahres"-Spiele (auch die anderen Nominierungen), 
die sind eigentlich nie schlecht.

Soziale Kooperationsspiele wie Avalon/Mafia, Werwölfe, etc. machen nur 
Spaß, wenn alle mitmachen, hinreichend intelligent sind und sich dabei 
nicht betrinken. Außerdem brauchen sie etwas Erklärung und Einarbeitung.

[Halligalli (Gast)]

Eigentlich wollte ich ja den Thread aufgeben - aber mein schizoides 
Gehirn macht einfach weiter!

Ich hatte tatsächlich die Eingebung dass man zu Zeilenbeginn die 
beteiligten Sprite-Horizontal-Zeilen nicht als Bit-Paare speichern muss 
nach dem Auslesen. Es reicht wenn man sie als eine 0 (transparentes 
Pixel) oder als eine 1 (farbiges Pixel) speichert. Dadurch benötigt man 
nur 1 Bit pro Sprite-Pixel. Dadurch könnte man 8-Bit-Latches anstelle 
von SRAMs benutzen. Mit 8 Latches könnte man zu Zeilenbeginn die 
Transparenz-Information von 8 Sprites speichern (wenn die Sprites 8 
Pixel breit sind). Es wäre wohl auch möglich, mehr als 8 Sprites auf 
diese Weise vorzubehandeln - es hängt ab von der Anzahl Latches und der 
Zeit die man hat.

Es sieht nach Adress-Dekoder, Bit-Paar-Logik und Bus-Schlamassel aus, 
aber möglich wäre es wohl! Es ist auch faszinierend, dass alle 
benötigten Signale für die Abläufe irgendwo verfügbar wären. So stellen 
die X-/Y-Zähler innerhalb der Sprites die Adresswerte bereit, und die 
Flip-Flops der Zeilen-/Spalten-Komparatoren markieren die zu zeichnenden 
Sprites einer Zeile mit 1/0 an ihrem Ausgang.

[Halligalli (Gast)]

Mir kam neulich der Gedanke dass die Rasterstrahl-Technik am Aussterben 
sein könnte …

Wie ist es bei den aktuellen modernen HDMI-Fernsehern und -Monitoren ? 
Spricht man da noch von Rasterstrahl oder nur noch von Bildpuffer oder 
so etwas ?

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Das lebt alles noch!
Also bei DVI und HDMI, bei DP nicht mehr.
Bei DVI und HDMI gibts noch all den Krams wie austastlücken 
under/overscan.
Nur, dass der RGB Teil eben Digital übertragen wird und das Timing ist 
die Pixelclock.
(jetzt ganz grob beschrieben)

Bei Diesplayport ist der Bildtransfer Paketbasierend und es sind auch 
meherewre Monitore in Reihe schaltbar (Daisychaining).