Bauen oder nicht bauen ?

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

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.

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.

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

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

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

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

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.

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

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.

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.

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

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

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

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

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 ?

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.

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.

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

Wir haben euch alle verstanden.

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

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

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

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

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

Das Projekt gefällt mir immer besser :)

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

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

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

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.

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.

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

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

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.

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

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.

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.

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

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?

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

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/

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

Sieht absolut genial aus.

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

Wofür ist denn jetzt der 8051?

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

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.

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

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

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

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

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

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 ?

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?

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

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.

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.

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.

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.

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

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.

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

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.

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

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

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.

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.

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.

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)

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

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

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?

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

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.

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

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!

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.

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

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.

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

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

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.

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

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!

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

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.

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

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.

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.

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

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!

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

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.

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

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

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.

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 schrieb:
> und eine Tile-Engine wollte ich ja auch noch
> machen!

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

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

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.

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!

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:

1

-- SN74LS00  4 NAND mit je 2 Eingängen

2

library ieee;

3

use ieee.std_logic_1164.all;

4

5

entity SN74LS00 is

6

    port (

7

        a1 : in  std_ulogic;

8

        b1 : in  std_ulogic;

9

        q1 : out std_ulogic;

10

        --

11

        a2 : in  std_ulogic;

12

        b2 : in  std_ulogic;

13

        q2 : out std_ulogic;

14

        --

15

        a3 : in  std_ulogic;

16

        b3 : in  std_ulogic;

17

        q3 : out std_ulogic;

18

        --

19

        a4 : in  std_ulogic;

20

        b4 : in  std_ulogic;

21

        q4 : out std_ulogic

22

      );

23

end entity SN74LS00;

24

25

26

architecture rtl of SN74LS00 is

27

28

begin

29

30

    q1 <= not (a1 and b1);

31

    q2 <= not (a2 and b2);

32

    q3 <= not (a3 and b3);

33

    q4 <= not (a4 and b4);

34

35

end architecture rtl;

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

1

library ieee;

2

use ieee.std_logic_1164.all;

3

4

entity steckbrett is

5

    port (

6

        takt   : in  std_ulogic;

7

        --

8

        vga_r  : out std_ulogic;

9

        vga_g  : out std_ulogic;

10

        vga_b  : out std_ulogic;

11

        vga_vs : out std_ulogic;

12

        vga_hs : out std_ulogic

13

      );

14

end entity steckbrett;

15

16

17

architecture verdrathung of steckbrett is

18

19

    signal roter_draht   : std_ulogic;

20

    signal gruener_draht : std_ulogic;

21

    signal blauer_draht  : std_ulogic;

22

23

begin

24

25

    U1: entity work.SN74LS00

26

    port map 

27

    (

28

        a1 => takt,          -- : in  std_ulogic;

29

        b1 => takt,          -- : in  std_ulogic;

30

        q1 => roter_draht,   -- : out std_ulogic;

31

        --

32

        a2 => roter_draht,   -- : in  std_ulogic;

33

        b2 => roter_draht,   -- : in  std_ulogic;

34

        q2 => gruener_draht, -- : out std_ulogic;

35

        --

36

        a3 => gruener_draht, -- : in  std_ulogic;

37

        b3 => gruener_draht, -- : in  std_ulogic;

38

        q3 => blauer_draht,  -- : out std_ulogic;

39

        --

40

        a4 => blauer_draht,  -- : in  std_ulogic;

41

        b4 => blauer_draht,  -- : in  std_ulogic;

42

        q4 => vga_r          -- : out std_ulogic

43

    );

44

45

    vga_g  <= roter_draht;

46

    vga_b  <= gruener_draht;

47

    vga_vs <= '1';

48

    vga_hs <= '0';

49

50

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.

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.

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

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

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

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

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. schrieb:
> Ein 7474 wär dann aber schon eine VHDL Baugruppe wert.

1

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

2

3

library ieee;

4

use ieee.std_logic_1164.all;

5

6

entity SN74LS74 is

7

    port (

8

        s_n : in  std_ulogic;

9

        clk : in  std_ulogic;

10

        d   : in  std_ulogic;

11

        r_n : in  std_ulogic;

12

        --

13

        q   : out std_ulogic;

14

        q_n : out std_ulogic

15

    );

16

end entity SN74LS74;

17

18

architecture rtl of SN74LS74 is

19

20

    signal ff : std_ulogic := 'L';

21

22

begin

23

24

    process( s_n, clk, r_n)

25

    begin

26

        if rising_edge( clk) then

27

            ff  <= d;

28

        end if;

29

        if s_n = '0' then

30

            ff  <= '1';

31

        end if;

32

        if r_n = '0' then

33

            ff  <= '0';

34

        end if;

35

    end process;

36

37

    q   <= ff;

38

    q_n <= not ff;

39

40

end architecture rtl;

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

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.

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?

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.