Bauen oder nicht bauen ?

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