Video Display Controller MC6847

[LotadaC]

Hi Uni,

Rechnerisch scheinen die Werte zu passen (6MHz?) - der Timer würde dann nach ca 2,3ms innerhalb des Fensters alles zurückrufen. Dein Oszillogramm scheint das ja auch zu bestätigen.

'n Steckbrett ist sicher nicht die Optimale Umgebung für Hochfrequenz-Schaltungen...

Hst Du mal versucht:

• den zufälligen Inhalt des externen Speichers darstellen zu lassen, also ohne mit dem Controller irgendwas zu machen (und ohne /FS auf /MS zu koppeln)?
• dasselbe mit Kopplung?
• dasselbe, mit IRQs am AVR, aber ohne Daten in den Speicher zu schreiben (sollte eigentlich kein Unterschied sein)?
• einmal Daten in den Speicher zu schreiben, und danach nichts mehr?
• die einmal geschriebenen Daten im nächsten Fenster zurückzulesen, und Korrektheit/Fehler via LED/UART etc signalisieren

DAU-Frage: hast Du beim Abschalten des externen Speicherinterfaces des AVR auch den Output des Adresslatches auf tristate geschaltet? Mit LE (Flanke?) wird der digitale Zustand der Eingänge und den Puffer übernommen, mit /OE landet der Pufferinhalt auf den Speicher-Adressleitungen.
Schaltest Du das Interface ab, gehen die AVR-Pins wieder Tristate (wenn DDRxn=0 und PORTxn=0), die Leitung zum Latch ist dann aber 'ne Antenne, der macht daraus also entweder 'ne 0 oder 'ne 1. Wenn der Output des Latches also enabled bleibt, wird das empfangene Rauschen (?) weiterhin auf den Speicheradressbus gelegt...

 

[dino03]

Hi,

DAU-Frage: hast Du beim Abschalten des externen Speicherinterfaces des AVR auch den Output des Adresslatches auf tristate geschaltet? Mit LE (Flanke?) wird der digitale Zustand der Eingänge und den Puffer übernommen, mit /OE landet der Pufferinhalt auf den Speicher-Adressleitungen.
Schaltest Du das Interface ab, gehen die AVR-Pins wieder Tristate (wenn DDRxn=0 und PORTxn=0), die Leitung zum Latch ist dann aber 'ne Antenne, der macht daraus also entweder 'ne 0 oder 'ne 1. Wenn der Output des Latches also enabled bleibt, wird das empfangene Rauschen (?) weiterhin auf den Speicheradressbus gelegt...

nen paar 100k PullDowns sollten die "Antenne" eigentlich vernichten. Am besten mit PullUps/PullDowns (47k-100k) einen gewünschten stabilen Zustand herstellen für den Fall das alle Treiberbausteine im hochohmigen Zustand sind.

Gruß
Dino

 

[unilein]

Rechnerisch scheinen die Werte zu passen (6MHz?) - der Timer würde dann nach ca 2,3ms innerhalb des Fensters alles zurückrufen. Dein Oszillogramm scheint das ja auch zu bestätigen.

Ja, 6 MHz. AVR-Studio erzählt mir das, wenn ich die Fuses auslese. Aber selbst wenn der AVR schneller laufen würde, wäre das ja egal. Ich hätte trotzdem nur 2,3 ms Zeit. Nur halt mehr Leistung in diesem Fenster. Für meine Tests genügt das aber erstmal.

'n Steckbrett ist sicher nicht die Optimale Umgebung für Hochfrequenz-Schaltungen...

Da gebe ich Dir vollkommen Recht. Ein großer Teil der Bildstörungen kommt sicher auch daher. Die Störungen sind mir aber auch erstmal egal. Viel wichtiger wäre es, mein "Hello World" auf den Schirm zu zaubern.

Hast Du mal versucht:

• den zufälligen Inhalt des externen Speichers darstellen zu lassen, also ohne mit dem Controller irgendwas zu machen (und ohne /FS auf /MS zu koppeln)?

Ja habe ich. Das Bild ist immer erfüllt von EINEM EINZIGEN Zeichen. Meistens ein "@".

dasselbe mit Kopplung?

• dasselbe, mit IRQs am AVR, aber ohne Daten in den Speicher zu schreiben (sollte eigentlich kein Unterschied sein)?
• einmal Daten in den Speicher zu schreiben, und danach nichts mehr?

Eigentlich habe ich sogar mit diesen Dingen angefangen. Die Routine, die den Speicher löscht und "Hello World" schreibt, habe ich erst zum Schluß rein gepackt.

• die einmal geschriebenen Daten im nächsten Fenster zurückzulesen, und Korrektheit/Fehler via LED/UART etc signalisieren

Das habe ich noch nicht getan. Ist aber eine gute Idee. Vielleicht wäre es dann eine gute Idee, den Test in C zu programmieren. Zumindest hätte ich da schon eine passende Sammlung an Schnipseln um mal eben eine Testumgebung zu bauen.

DAU-Frage: hast Du beim Abschalten des externen Speicherinterfaces des AVR auch den Output des Adresslatches auf tristate geschaltet? Mit LE (Flanke?) wird der digitale Zustand der Eingänge und den Puffer übernommen, mit /OE landet der Pufferinhalt auf den Speicher-Adressleitungen.
Schaltest Du das Interface ab, gehen die AVR-Pins wieder Tristate (wenn DDRxn=0 und PORTxn=0), die Leitung zum Latch ist dann aber 'ne Antenne, der macht daraus also entweder 'ne 0 oder 'ne 1. Wenn der Output des Latches also enabled bleibt, wird das empfangene Rauschen (?) weiterhin auf den Speicheradressbus gelegt...

Ich lege beim Abschalten des Interfaces /OE auf High. Da Port C des AVR ja nach dem Abschalten wieder ein "normaler" Port ist, muss ich aber vielleicht noch dafür sorgen, dass ich mindestens Pin 30 (ALE) auf Low lege. So wäre der Latch komplett abgekoppelt.

Ich habe mir trotzdem einen Logic Analyzer bestellt.....

To be continued...

 

[LotadaC]

Laut Deinem Schaltplan ist OE von U3 fest auf Gnd verdrahtet, also gibt der immer irgendwas auf den Bus. Unabhängig von LE, und auch wenn der AVR tristate schaltet.

 

[unilein]

Laut Deinem Schaltplan ist OE von U3 fest auf Gnd verdrahtet, also gibt der immer irgendwas auf den Bus. Unabhängig von LE, und auch wenn der AVR tristate schaltet.

Stimmt... Da ist ein Fehler.
Wenn ich /OE über den Inverter mit /FS auf High lege, müsste es passen, oder?

Übrigens hae ich gerade noch einmal ins Datenblatt des MC6847 geschaut. Meine Interpretation von Figure 8 ist, dass ich nicht, wie zunächst angenommen 2,4 ms habe, um den Speicher zu nutzen sondern
2,4 µS. Das wäre dann um den Faktor 1000 weniger. So werden dann aus 14.000 Takte plötzlich 14.

Oder Interpretiere ich falsch?

1 Takt des AVR = 1 µS (= 1 millionstel Sekunde)

Laut Figure 8 im Datenblatt löst /FS nach ca. der Hälfte von 4,8 Takten aus.

Gruß
Uni

 

[LotadaC]

...Wenn ich /OE über den Inverter mit /FS auf High lege, müsste es passen, oder?...

Mit dem Ausgang /FS signalisiert der VDG, daß er selbst gerade nicht auf den SRAM zugreifen muß.
Wenn /FS low ist, kann der AVR den SRAM nutzen/füllen. Dazu müssen die Adressausgänge des VDG tristate gezwungen werden, durch einen low-Pegel am /MS-Eingang.
Also /FS->/MS.
Der AVR soll das Fenster erkennen, über einen externen Interrupt (Eingang). Dieser schlägt auf die fallende /FS-Flanke an, also auch /FS->INT0.
Der AVR bedient die unteren 8 Adressleitungen über einen Puffer/Latch. Dessen Ausgänge sind tristate genau dann wenn sein /OE-Eingang High ist. Ein low am /OE enabled die Ausgänge, also auch /FS->/OE des Latches.

Du verbindest also den /FS des VDG mit dem /MS des VDG, dem INT0 des AVR und /OE von U3.
Wenn der VDG das Fenster erreicht, wechselt /FS von high nach low, dabei wird /MS low (Adressausgänge des VDG gehen tristate), /OE von U3 low (Adresslatch wird aktiv) und der IRQ beim AVR ausgelöst. Ich hätte übrigens /OE und /MS über seperate AVR-Pins angesteuert, aber eigentlich sollte es auch so gehen. Der AVR legt auch ausserhalb des Fensters WE und OE der SRAM fest, das Output soll immer enabled sein, Input immer disabled.
Das muß ja nur einmal eingestellt werden (in den PORT-Bits) - schaltest Du das Interface an, übernimmt dieses die Kontrolle über die Pins, PORT greift nicht mehr - schaltest Du das Interface ab, gibt dieses die Kontrolle zurück an das PORTregister, wo ja noch der korrekte Wert steht.

Den Sinn von U7 versteh ich nicht.

...Übrigens hae ich gerade noch einmal ins Datenblatt des MC6847 geschaut. Meine Interpretation von Figure 8 ist, dass ich nicht, wie zunächst angenommen 2,4 ms habe, um den Speicher zu nutzen sondern
2,4 µS...

Hmm... daunter steht in der Note t_WFS=32*(277,5*1/f), wobei f=3,579545 MHz sein sollte (S.5, S.13).
Also 32*(277,5/3579,545kHz)=2,48.../kHz=2,48ms

Du scheinst einen schnelleren Takt am VDG zu haben, ob das zulässig ist, weiß ich nicht... dann ist das Fenster natürlich schmaler...
Die Taktzeit des AVR hängt von dessen Taktquelle ab, und einem ggf gewähltem MainClockPrescaler (zB mit CKDIV8 oder so).

Ein direkt mit 20MHz betakteter AVR benötigt also für jeden Takt 1/20MHz=50ns, ein mit 1MHz betakteter 1/1MHz=1µs...

 

[dino03]

Hi,

Hmm... daunter steht in der Note t_WFS=32*(277,5*1/f), wobei f=3,579545 MHz sein sollte (S.5, S.13).
Also 32*(277,5/3579,545kHz)=2,48.../kHz=2,48ms

Du scheinst einen schnelleren Takt am VDG zu haben, ob das zulässig ist, weiß ich nicht... dann ist das Fenster natürlich schmaler...

die alten ICs hatten meißt innen drin eine feste Takterzeugung. Es wurden dann je nachdem ob man PAL oder NTSC machen wollte ein anderer Quarz verwendet. Von den Quarzfrequenzen durfte man auch nicht abweichen wenn man was sehen wollte sonst kann sich der Fernseher logischerweise nicht auf das Videosignal aufsynchronisieren.

Gruß
Dino

 

[unilein]

Hi,



die alten ICs hatten meißt innen drin eine feste Takterzeugung. Es wurden dann je nachdem ob man PAL oder NTSC machen wollte ein anderer Quarz verwendet. Von den Quarzfrequenzen durfte man auch nicht abweichen wenn man was sehen wollte sonst kann sich der Fernseher logischerweise nicht auf das Videosignal aufsynchronisieren.

Gruß
Dino

Ich verwende natürlich exakt 3,579545 MHz. Mein Bildschirm ist ein kleiner TFT-Monitor auf dem KFZ-Bereich, der sowohl PAL als auch NTSC darstellen kann.

Inzwischen habe ich den Grund für die Bildstörungen gefunden. Das Latch am AVR hat geflattert. Nun wird /OE des Latch korrekt bedient und schon ist das Bild ruhig.
Dennoch habe ich nur einen Bildschirm voller @'s. Das Thema packe ich aber als nächstes an. Ich muss auch mein Programm nochmal prüfen. Ich fand zum Beispiel
heraus, dass ich zwar 64KB am AVR hatte, jedoch das XRAM-Interface auf 8KB eingestellt war (Homer würde d'Oh!! sagen), weil ich zuvor mal mit 8 KB experimentiert hatte.

Morgen kommt mein Logic-Analyzer. Da werde ich schon sehr bald mehr über mein Signal-Chaos wissen.

Gruß
Uni

 

[LotadaC]

Du hast also erstmal 'n stabiles Bild. Die "@" sind laut Zeichentabelle im Datenblatt des VDG (Figure 20) "Nullen" (0x00), der VDG bekommt also bei jeder gewählten Adresse 0x00 über seine Datenleitungen. Ob diese Nullen aber aus dem SRAM kommen, weiß ich nicht.

Was soll der Bus Transciever am Dateneingang des VDG? und warum ein bidirektionaler? Für den VDG ist das immer ein Eingang. Ausserhalb des Fensters muß der VDG immer die Daten auf dem Bus bestimmen (sonst haste Störungen), im Fenster interessieren ihn die Daten auf dem Bus nicht. Lediglich bei Verwendung eines externen Charakter-ROMs muß dieses statt des SRAM die Daten bereitstellen (genau genommen wird das ROM dazwischengeschaltet).

Nimm mal U7 raus.

Man könnte auch mal folgendes versuchen:

/MS wird dauerhaft low gehalten (also die Adressausgänge des VDG immer tristate).
Unabhängig davon verwendest Du /FS weiterhin wie gehabt zur Fensterdetektion, ebenso den Timer.
Der /OE des Adresslatches am AVR bleibt auch ununterbrochen low (also dessen Output enabled).

Der AVR hat also immer Kontrolle über den Adressbus.
Im Fenster schreibst Du jetzt irgendein Byte (verschieden 0x00, also zB 0x3F) an irgendeine Adresse in den externen SRAM ( also zB Adresse 0b1000000000000000). Beim Verlassen des Fensters bleibt der Output des Latches nach dem Abschalten des Speicherinterfaces aktiv, außerdem legst Du jetzt dasselbe High-Byte auf PORTC (Ausgang und PORTC=0b10000000).
Ausserhalb des Fensters würde jetzt also weiterhin die Adresse des beschriebenen Bytes im externen SRAM auf dem Adressbus liegen, der VDG also dessen Inhalt auf dem Datenbus sehen (egal welche Adresse er auf den Adressbus legen würde - seine Adressausgänge sind ja Tristate). Folglich sollte ausserhalb des Fensters das Bild jetzt lauter 0x3F-Zeichen (Fragezeichen) enthalten.

Der AVR besitzt ja einen UART - Du könntest also auch von dort Bytes empfangen, und diese statt des einmal festgelegten Zeichens (0x3F) ausgeben lassen. Dann kannste die 64 Zeichen (0x00..0x3F) des internen Vorrates testen. Wenn Bit6 des Datenbusses jetzt (wie in Figure17a) auf INV des VDG gelegt wird, wären die nächsten 64 Zeichen (0x40..0x7F) dann dieselben nur invertiert.

 

[unilein]

Nur ein kurzes Feedback...

Leider fehlt mir momentan ein wenig die Zeit um das Projekt mit der nötigen Konzentration weiter zu verfolgen. Aber ich werde es definitiv zu Ende bringen!
Seht es mir also nach, wenn sich die Dinge hier mit der Geschwindigkeit einer Lavalampe verändern... ;-)


So... Nun aber kurz zum Projekt. Ich hatte ja zuletzt ein stabiles Bild mit "@". Sobald ich aber /MS bediente, oder Daten vom AVR in den Speicher schreiben wollte, waren extreme Störungen die Folge. Eine Störungsquelle habe ich inzwischen beseitigen können. Ich hatte ein paar Pins des MC6847 nicht mit einem sauberen Signal versehen. Diese hingen flatternd in der Luft. Nachdem ich diese ordentlich auf LOW gelegt hatte, waren die Störungen weitestgehend weg.

Die nun noch auftretenden Störungen sind also ein reines Timing-Problem beim Zugriff auf den Speicher durch den AVR. Das sollte aber mit sauberer Programmierung in den Griff zu kriegen sein.

Schlimmer ist allerdings, dass der MC6847 offensichtlich schwer beleidigt auf den Speicherzugriff durch den AVR reagiert. Trotz abgeschaltetem Memory-Interface des Atmega 162 bekommt der MC6847 "wilde Adressen" und chaotische Datenbytes präsentiert. Diese führen meiner meinung nach dazu, dass der Adressbereich des MC6847 "hüpft" und das Datenbyte, welches zuletzt vom AVR in den Speicher geschrieben wurde vom MC6847 übernommen wird. Diese Problematik wurde im Thread weiter oben bereits angemerkt. Daten- und Adressbus des AVR müssen "clean" sein, wenn der MC6847 sein Werk tut. Außerdem muss das Latch auf Tristate.

Ich neige dazu, nun auch den Datenbus des MC6847 abzukoppeln, wenn der AVR Daten schreibt. So bekommt der nichts mehr mit. Die Idee ist aber bislang nur in meinem Kopf und nicht umgesetzt.

Ansonsten funktioniert der Speicherzugriff vom MC6847 perfekt. Das habe ich inzwischen mit einem Logic-Analyzer überprüft.

Weitere Infos folgen....


Uni

 

[LotadaC]

Hmm...
kannst Du mal nochmal den jetzt aktuellen Schaltplan einstellen, und ggf das Programm?

Wenn das XMEM-Interface aktiviert wird, übernimmt dieses die Kontrolle über die dort genutzten Beine (Adress-, Datenleitungen, WR, RE, ALE), DDR und PORT-Register werden dann wirkungslos. Wird es deaktiviert, greifen PORT und DDR wieder. Du kannst also vorher die benötigten Beine Tristate schalten (bzw da default, so lassen).
ABER:
Den Latch mußt Du auf Tristate schalten, Außerdem mußt Du den RE für den VDG bedienen.
Die Adressleitungen, die der VDG nicht nutzt mußt Du auch ausserhalb des Fensters bedienen (also Ausgang und Pegel) - im Fenster soll das XMEM-Interface da die Kontrolle übernehmen, aber ausserhalb des Fensters bist Du zuständig.
mit dem LA hast Du sicher schon einiges durchgetestet Reihenfolge sollte sein:
-Fensterkontrolle: /FS auf den Interrupt, in der ISR einen ungenutzten Kontrollerpin setzen lassen und den Timer fürs Ende des Fensters nutzen (Pin dort wieder löschen), Pin und /FS mit dem LA loggen. Der bedient den RE des Speichers, der VDG die Adressen. Dargestellt wird dann der zufällige Inhalt des Speichers beim Start. Bild stabil? (also erstmal ohne XMEM-Interface)
-jetzt den Datenbus an den Controller (bleibt aber erstmal Tristate) -> Bild stabil?
-im Fenster mal irgendwelche Daten auf den Bus legen (also Ausgang (DDR) und zB 0x55 in das PORT), kurz vor Fensterende wieder Tristate. Bild stabil?
-das Latch an die beiden Busse, dauerhaft auf Tristate, ebenso die Datenleitungen im Controller wieder dauerhaft tristate. Bild stabil?
-dasselbe mal mit dem anderen Zustand am ALE des Latches (ausserhalb des Fensters). Bild stabil?
-jetzt im Fenster wieder mit den Datenleitungen "spielen"
-und jetzt auch mit den Adressen.
-RE, WR und ALE miteinbeziehen (ggf mit einigen NOPs)
-jetzt im Fenster das XMEM aktivieren, aber erstmal nichts schreiben.
-lesen
-schreiben

 

[DJLinux]

Hallo Uni und auch LotadaC,

gibt es etwas neues von MC6847 Front ?

Ich frage weil ich in ca. 14 Tagen (wenn ich etwas mehr Zeit habe) auch mit dem VDG etwas auf die Beine stellen möchte.

Ich habe kürzlich einen TSR-80 MC-10 Emulator programmiert weil dieses "Gerät" vor 32 Jahren meine Einstiegsdroge in die "IT-Gosse" war.

Dann vor kurzen zu meinem 50'ten Geburtstag habe ich mir aus nostalgischer Motivation mir einen echten MC-10 ersteigert. (und läuft das alte "Schätzgen")

Nun habe ich unterer anderem einen MC6803 und den besagten/betagten MC6847 aus China bekommen.

Da es dem VDG egal ist ob er auf fallender oder steigender Taktflanke aktive sein soll kann man schon auf diese einfache Diffrenzierung Buskollisionen vermeiden.

Dem AVR oder einer anderen CPU kann man während der V-Sync und H-Blank Phase noch einige extra Takte mehr gönnen (Alleinherrschaft über BUS / RAM und ggf. ROM).

Die ASCII und Grafik Modies kann man sogar auf Zeichenebene umschalten also Text und Grafik gemeinsam auf einen Screen.

Zum eingebautem Character-ROM kann man natürlich auch seine eigenen Pixel-Patterns anzeigen lassen.

Aber das kennt Ihr sicherlich vom PDF her schon alles selbst.

Werde in zwei Wochen mal meine ersten Schaltungsversuche posten. (erst auf dem Breadboard)

Ich hoffe Uni ist dann noch am Ball und der MC6847 ist noch nicht abgeraucht.

Grüße DJ

 

[LotadaC]

Unilein scheint derzeit zwar im Forum mitzulesen, aber seit ca. 2 Monaten seinerseits nichts zu schreiben. Wird also aus irgendwelchen Gründen für's Hobby grad nicht viel Zeit haben (@Dino: Pollins Resterampe hat immer noch keinen Zeit-Restposten im Angebot - oder ich hab den verpaßt).

ICH beschäftige mich hier mit dem ganzen Kram mangels Hardware (und Zeit) ja nur in der Theorie, kann also nur auf Unis Erfolge und Misserfolge reagieren (und mehr oder weniger hilfreiche Vorschläge unterbreiten) - die Arbeit hat ER (und das Risiko auch).

Aber ich werde dann natürlich auch interessiert bei Deiner Sache mitlesen...

 

[unilein]

Hallo zusammen,

was LotadaC sagt stimmt. Zurzeit bin ich nur aktiver Mitleser. Aus zeitlichen Gründen. Aber als ich den Beitrag von DJLinux sah, wollte ich mich doch mal melden.
Es freut mich, dass es noch mehr Hobbyisten gibt, die sich mit dem MC6847 auseinandersetzen

Meine Schaltung steckt seit den genannten 2 Monaten auf meinem Breadboard und verstaubt. Seit meinem letzten Beitrag hier kein Fortschritt mehr. Allerdings wird
sich das sicher bald ändern. Denn das Jahr geht zu Ende und mein Urlaub naht. Spätestens dann werde ich mich wieder mit meinem Experiment auseinandersetzen.
(Und am Ende wird es funktionieren! Ein anderes Ergebnis kann ich leider nicht zulassen ;-) )

Mein MC6847 ist jedenfalls noch nicht abgeraucht. Und außerdem habe ich noch 4 davon.... Da kann ich also Gas geben...

Grüße, Uni

 

[DJLinux]

Kann schon mal etwas Pflichtlektüre lecture # 18 beisteuern.

MC6847 Farbdarstellung direkt auf Monitor (kein UHF-TV) etc.

Grüße DJ.

 

[DJLinux]

Noch etwas gefunden lecture # 17 auch für Leute ohne MC6847 nützlich.

Grüße DJ.

 

[DJLinux]

Hallo @LotadaC Ich kenne mich mit 0 und 1 sehr gut aus aber von dem analogen "Kram" weiss ich "noch" nicht viel.

In lecture # 18 Seite 4 "Color Output"
ist die Rede von einem älteren Baustein den datasheet AM25LS32 mit 4 Komperatoren den man schwer oder garnicht mehr bekommt welcher Baustein mit Komperatoren wäre vergleichbar ?

Danke DJ.

 

[dino03]

In lecture # 18 Seite 4 "Color Output"
ist die Rede von einem älteren Baustein den datasheet AM25LS32 mit 4 Komperatoren den man schwer oder garnicht mehr bekommt welcher Baustein mit Komperatoren wäre vergleichbar ?

in dem Datenblatt steht was wichtiges dazu drin. Steht unter "General Description". Der AM25LS32 ist ein 4fach Line-Receiver für RS-422 / RS-423 Verbindungen. Also sowas serielles mit symmetrischer Übertragung vergleichbar mir RS485. Such einfach mal bei den MAX-Typen von Maxim/Intersil. Da sollte neben den ganzen RS232-Treibern hoffentlich was brauchbares dabei sein. Sonst gibts auch von anderen Herstellern noch einiges zu finden.

Gruß
Dino

 

[DJLinux]

Hallo Dino danke für den Hinweis.

Kaum zu glauben aber war, ich schaue in dem Verzeichnis auf meiner HD wo ich "nur" Datenblätter gespeichert habe
von Bausteinen die sich in meinem Besitz befinden und "Buuuum" da steht dort tatsächlich AM25LS32_pollin_ramsch.pdf zuletzt geändert 2009.
Einige Kisten durchgewühlt und siehe dar 5 Stück sind vorhanden.

Ich denke die stammen aus einer Pollin "IC-Überraschungs-Tüte" für ich 1,50 €.

Jetzt fehlt zu meinen Glück nur noch ein passender Quarzoszillator mit 3,579545 MHz.


Grüße DJ

 

[unilein]

So etwas hätte ich da...