DFO: Dual Frequency Oscillator

    • Tutorial
    • DFO: Dual Frequency Oscillator

      Ihr lieben CiBo-Schlümpfe, der Vollständigkeit halber sei dieses Projekt von mir auch auf dem Circuit-Board vertreten. Vielleicht kann's ja einer brauchen. :)

      DFO - dual frequency oscillator



      Um was geht's? Was ist das?
      Beim DFO (dual frequency oscillator) handelt es sich um eine Oszillatorschaltung. Es wird also ein Taktsignal erzeugt und ausgegeben. Die Schaltung basiert auf dem CDCE913-Taktgenerator-IC von Texas Instruments. Das besondere ist, dass der DFO programmierbar ist. Die Frequenz des ausgegebenen Taktsignals kann dabei (beinahe) jeden Wert im Bereich von 80 kHz bis 230 Mhz betragen.
      Der Clou bei der ganzen Sache ist außerdem der S0-Eingang des DFOs. Je nach angelegtem Pegel an S0, lässt sich zwischen zwei verschiedenen Frequenzen umschalten.

      Für was braucht man sowas?
      Meine Motivation für die Entwicklung des DFOs war, dass mein PAL Megadrive 2 im 60 Hz-Modus Probleme mit dem XRGB-Mini Framemeister bereitet hat. Der Grund: In Pal MD-Konsolen sind Oszillatoren mit einer Frequenz von 53.203425 MHz verbaut, in NTSC-Konsolen aber welche mit 53.693175 MHz. Die resultierende Bildrate eines PAL-MDs im 60 Hz-Modus weicht deshalb geringfügig von der einer echten NTSC-MD-Konsole ab. Diese Abweichung reicht, um den Framemeister aus dem Tritt zu bringen.
      Die erste Idee war es, einfach einen NTSC-Oszillator mit 53.693175 MHz einzubauen. Wie ich allerdings feststellen musste, gibt es keine Oszillatoren oder Quarze mit dieser Frequenz mehr zu kaufen. Einzig auf Aliexpress wurde ich fündig, aber es gab da keine gescheiten Specs geschweige denn ein vernünftiges Datenblatt.
      Aus diesem Grund habe ich den DFO entwickelt. Der 50/60 Hz Schalter im Megadrive 2 ist nun auch mit dem S0-Eingang des DFOs verbunden. Der DFO versorgt je nach gewähltem Modus das Megadrive der passenden Frequenz. Die Bildprobleme mit dem Framemeister sind dadurch passé.

      Ein weiteres Einsatzgebiet des DFOs wäre bspw. Overclocking. Eingebaut in eine Konsole oder in ein FX-SNES-Modul ließe sich der DFO mit der maximal möglichen Frequenz programmieren. Durch Anlegen von 5V oder Masse am S0-Eingang des DFOs ließe sich dann zwischen normalen und übertaktetem Betriebsmodus hin- und herschalten.

      Welche Versionen des DFOs gibt es?
      Ich habe drei verschiedene DFO-Versionen im Angebot. Die Designs sind bei Oshpark gehostet und können direkt dort geordert werden (zu einem sehr attraktiven Preis): oshpark.com/profiles/micro
      Ich selbst kann und werde keine fertig zusammengebaute DFOs anbieten, bitte keine Anfragen diesbezüglich. Selbst ist der Mann/Frau! ^^

      1.) DIL14-Version


      DIe DIL14-Version des DFOs hat das gleiche Pinout und auch in etwa die gleichen Abmessungen wie traditionelle Oszillatoren im DIL14-Metallgehäuse:



      Die Versorgungsspannung darf bis zu 5 V betragen (maximal 5.5V), daher kann die DIL14-Version des DFOs direkt im Megadrive als Oszillator-Ersatz verbaut werden.

      Bauteile & Bestückungsplan:
      Spoiler anzeigen



      AnzahlBeschreibungmouser.com Artikelnr.
      1xCDCE913 clock generation IC595-CDCE913PWR
      1xbuffer/level shifter595-SN74LV1T126DBVR
      1x3.3V LDO595-TPS78233DDCR
      1x1.8V LDO595-TPS78218DDCT
      1x27 MHz crystal717-9B-27.000MAAJ-B
      3x1 uF capacitor81-GRM188R61E105KA12
      1x2.2 uF capacitor81-GRM188R61E225KA2D
      1x18 Ohm resistor71-CRCW0603-18-E3
      1x10 kOhm resistor71-CRCW0603-10K-E3
      1x22 kOhm resistor71-CRCW0603-22K-E3
      1xPräzisionsstiftleisteAW 122/20 (Reichelt)



      2.) 5 V-SMD-Version


      Die 5 V-SMD-Version basiert auf der gleichen Schaltung wie die DIL14-Version. Sie ist ebenfalls mit bis zu 5 V zu versorgen (maximal 5.5 V). Allerdings ist die Unterseite eben, da auf der Oberseite ausschließlich SMD-Bauteile zum Einsatz kommen. Das Pinout ist auch anders: Auf der linken Seite befinden sich die Eingänge (Spannungsversorgung & S0 zum Umschalten der Frequenz), auf der rechten Seite das ausgegebene Taktsignal.
      Mögliche Einsatzgebiete: Konsolen, die ein Taktsignal mit einem Vpp-Wert von bis zu 5V erwarten (SNES vllt?). Diese DFO-Version muss aber nicht mit 5 V betrieben werden, sie funktioniert auch bspw. mit einer Versorgungsspannung von 3.3 V.


      Bauteile & Bestückungsplan:
      Spoiler anzeigen



      AnzahlBeschreibungmouser.com Artikelnr.
      1xCDCE913 clock generation IC595-CDCE913PWR
      1xbuffer/level shifter595-SN74LV1T126DBVR
      1x3.3V LDO595-TPS78233DDCR
      1x1.8V LDO595-TPS78218DDCT
      1x27 MHz SMD crystal717-9C-27.000MAAJ-T
      5x1 uF capacitor81-GRM188R61E105KA12
      1x18 Ohm resistor71-CRCW0603-18-E3
      1x10 kOhm resistor71-CRCW0603-10K-E3
      1x22 kOhm resistor71-CRCW0603-22K-E3



      3.) 3.3 V-SMD-Version


      Ist im Vorfeld bekannt, dass der DFO in einer 3.3 V-Umgebung eingesetzt werden soll (maximal 3.6 V!), so ist die 3.3 V-SMD-Version zu empfehlen. Sieht zwar der 5 V-SMD-Version sehr ähnlich, benötigt aber einige Bauteile weniger und ist deswegen einfacher und billiger zu bauen.
      Einsatzgebiete: PSX und Neogeo MVS MV-1C bspw.

      Bauteile & Bestückungsplan:
      Spoiler anzeigen



      AnzahlBeschreibungmouser.com Artikelnr.
      1xCDCE913 clock generation IC595-CDCE913PWR
      1x1.8V LDO595-TPS78218DDCT
      1x27 MHz SMD crystal717-9C-27.000MAAJ-T
      3x1 uF capacitor81-GRM188R61E105KA12
      1x18 Ohm resistor71-CRCW0603-18-E3
      2x10 kOhm resistor71-CRCW0603-10K-E3



      So, das war's für heute. Der Rest kommt noch! (Programmiergerät, Programmiertsoftware etc.)
    • CDCE9XX Programmer Hardware



      Wie der Name schon sagt, ist das das Programmiergerät, mit dem die CDCE9XX-ICs von TI programmiert werden können. Dazu gehört natürlich der CDCE913 auf den verschiedenen DFO-Versionen, aber auch die "dickeren" ICs (CDCE925, CDCE937, CDCE949) können damit programmiert werden.

      Konzept



      Wie obiges Bild verdeutlicht, ist der CDCE9XX Programmer das Verbindungsstück zwischen dem DFO und einem PC, auf welchem eine grafische Benutzeroberfläche für das Ansprechen des Programmers läuft (dazu später mehr). Der CDCE9XX Programmer wird mittels eines Mini-USB-Kabels mit dem PC verbunden. Die Verbindung zum DFO erfolgt über 4 Strippen (GND, V_Target aka VCC, SDA & SCL).

      Platine & Bestückung



      Die Platine des CDCE9XX Programmers ist ebenfalls auf oshpark zu ordern: oshpark.com/profiles/micro

      Liste der benötigten Bauteile:
      Spoiler anzeigen

      AnzahlBeschreibungmouser.com Artikelnr.
      1xFT232RL USB UART interface IC895-FT232RL
      1xATMEGA48A microcontroller556-ATMEGA48A-AU
      1xMini USB socket587-690-005-299-143
      1xSliding switch688-SSSS810701
      1xPin header855-M22-2010405
      1x8 MHz crystal774-ATS080B
      3x100 nF capacitor80-C0805C104K5R
      1x4.7 uF capacitor581-08053D475K
      2x18 pF capacitor77-VJ0805A180GXJCBC
      1x330 Ohm resistor71-CRCW0805-330-E3
      2x10 kOhm resistor71-CRCW0805J-10K-E3
      2x4.7 kOhm resistor71-CRCW0805-4.7K-E3
      1xLED720-LSR976-NR-1



      Tipp für das Bestücken: Unbedingt die Mini-USB-Buchse vor dem FT232RL bestücken, sonst wird's wirklich haarig! ;)

      Die Platine hat am oberen Ende einen kleinen Zipfel, den man bei Bedarf abdremeln kann und mittels Flachbandkabel oder Litze verlängern kann, wie ich das auf dem Bild ganz oben gemacht habe. Das ist zwar kein Muss, aber es erhöht die Flexibilität.

      In der Liste der Bauteile ist eine Stiftleiste mit 2 mm Rastermaß vorgesehen, die dann in den extra-Zipfel gelötet wird und die Verbindung zum DFO herstellt. Momentan stecke ich die Stiftleiste immer in den DFO, verkante sie für einen guten Kontakt und lasse den Finger so lange drauf bis der Programmiervorgang abgeschlossen ist:



      Man kann aber auch eine passende Buchsenleiste in den DFO einlöten, dann braucht man den Finger nicht drauf halten. Denkbar wäre auch das Einlöten von passenden Pogo-Pins in den Extra-Zipfel, da gibt es viele Möglichkeiten eine Verbindung zum DFO zu realisieren...

      Firmware für den Programmer

      Damit der CDCE9XX Programmer wie gewünscht funktioniert, muss erst der darauf befindliche Mikrocontroller des Typs ATmega48A mit der passenden Firmware geflasht werden.

      Firmware: mediafire.com/download/tn6kw1g…E9XX_PROGRAMMER_FW_v1.zip
      Source: mediafire.com/download/n6yon47…MMER_FW_v1_SOURCECODE.zip

      In der Ecke rechts-unten auf der Programmer-Platine befindet sich die sechspolige AVR-ISP-Schnittstelle ("ISP"). Das Pinout enstpricht dem gängigen Standard. Pin 1 ist der, welcher mit dem Quadrat umrandet ist. (Wer hätte es gedacht? ::mrgreen:: )

      Auf das Flashen an sich möchte ich an dieser Stelle gar nicht eingehen, da es hier im Board schon einige Male behandelt wurde und sich der tatsächliche Flash-Vorgang unterscheiden kann, je nach dem welcher AVR-ISP-Programmer dafür genutzt wird. Bei Fragen/Problemen einfach hier melden, kein Ding!
      (Haben wir mittlerweile eigentlich ein AVR Flash Tutorial? Ich dachte @sanni hätte diesbzgl. mal etwas zusammengeschrieben.)

      Alternative zum Programmer

      Es gibt eine Alternative zum oben beschriebenen Programmer, die ich zwar selbst noch nicht ausprobiert habe, ich euch aber nicht vorenthalten möchte. User @Unseen, der mittlerweile ja auch hier im CiBo sein Unwesen treibt, hat ein Skript erstellt, mit dem sich die CDCE9XX-ICs mittels eines Raspberry PIs programmieren lassen.

      Bisher wird allerdings nur der CDCE925 unterstützt, der in der allerersten DFO-Version eingesetzt wurde. Aber wer weiß, vllt. bohrt Unseen das Ding ja noch auf... :)

      Link auf GitHub: github.com/ikorb/cdceprog
      Dateien

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von micro ()

    • Grafische Benutzeroberfläche zur Programmierung des DFOs
      Für das Ansprechen des o.g. CDCE9XX-Programmers und somit der Programmierung des DFOs gibt es eine eigene grafische Benutzeroberfläche (GUI):



      Download: mediafire.com/download/dx4k1yt…X_Programmer_GUI_v1.1.zip
      Voraussetzung: Windows PC mit .NET Framework 4.5

      Anzeige- & Bedienelemente

      Gehen wir einfach von oben nach unten durch...

      1.) "Programmer"-Info-Fenster

      Hier wird signalisiert, ob ein an den PC angeschlossener CDCE9X-Programmer erkannt wurde. Es wird auch die Firmware-Version des Programmers angezeigt. (Momentan ist die v1 Firmware aktuell.)
      Wird ein angeschlossener Programmer nicht erkannt, so clickt einfach auf den "Refresh"-Button. Wird der CDCE9XX-Programmer trotzdem immer noch nicht erkannt, so ist die Wahrscheinlichkeit hoch, dass der CDCE9XX-Programmer an sich nicht ok ist (Fehler bei Bestückung, nicht mit der Firmware geflasht, etc.)

      2.) "CDCE9XX Configuration"-Fenster

      Hier sollt ihr die für eure Anwendung passende .hex-Konfigurationsdatei laden. Dazu clickt ihr auf den "Load Configuration File"-Button und wählt eine passende .hex-Datei aus. Ich stelle vorgefertigte .hex-Dateien zur Verfügung, siehe folgender Post! Es steht euch natürlich auch frei, eigene Konfigurationsdateien zu erstellen. ;)


      Nach dem Laden der .hex-Datei wird der erkannte CDCE9XX Device Type angezeigt (bei den DFOs ist dies stets der CDCE913). Außerdem werden auch alle in der .hex-Datei enthaltenen Registerwerte angezeigt.
      Weiter unten befinden sich 3 Checkboxes, über die sich Spezial-Optionen aktivieren bzw. deaktivieren lassen. Habt ihr keine Ahnung, dann belasst ihr es besser bei den Default-Einstellungen. Hier werden die Funktionen erklärt:
      Spoiler anzeigen

      a) "Write Registers into EEPROM" (Default: aktiviert)
      Legt fest, ob die Registerwerte, mit denen ihr den DFO programmiert, im EEPROM gespeichert werden sollen. Normalerweise will man genau das. Anderenfalls ist die Konfiguration nach dem Entfernen der Versorgungsspannung futsch...

      b) "Preserve Factory-Set I2C Receiver Adress" (Default: aktiviert)

      Ist diese Option aktiviert, so wird verhindert, dass der DFO mit einer anderen I2C-Adresse als der werkseitigen programmiert wird.

      c) "Use Custom I2C Reciever Adress" (Default: deaktiviert)
      Wurde die werkseitig eingestellte Standard-I2C-Adresse des DFOs in der Vergangenheit abgeändert, so könnt ihr hier die 2 niederwertigsten Adressbits selbst nach Gusto einstellen, um überhaupt den DFO mit der abgeänderten I2C-Adresse ansprechen zu können.


      3.) "Program CDCE913"-Button

      Damit programmiert ihr den DFO. :)
      Der Button ist nur verfügbar, wenn der CECE9XX-Programmer erkannt wurde und ihr eine gültige .hex-Konfigurationsdatei geladen habt. (Anderenfalls ist der Button ausgegraut.)

      Nach Drücken des Buttons bekommt ihr eine Rückmeldung, ob der Programmiervorgang erfolgreich ausgeführt wurde (wollen wir hoffen) oder ob ein Fehler aufgetreten ist. Mögliche Fehler wären bspw:

      - I2C Error
      Falsche I2C-Adresse? Haben die 4 Strippen vom Programmer zum DFO (GND, V_Target, SDA, SCL) keinen gescheiten Kontakt?

      - Verification Error
      Zurückgelesene Registerwerte des DFO entsprechen nicht den geschriebenen.

      - FTDI Error
      Programmer während dem Programmiervorgang aus der USB-Buchse gezogen?
      Dateien

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von micro ()

    • .hex-Konfigurationsdateien

      Wie aus den vorherigen Posts hervorgeht, muss der DFO mit einer .hex-Konfigurationsdatei programmiert werden. Diese Datei bestimmt die Frequenz des ausgebenen Taktsignals des DFOs am Ende.

      Ihr könnt eure eigenen Konfigurationsdateien mit dem ClockPro-Programm von Texas Instruments erstellen oder ihr nehmt einfach meine vorgefertigten Beispieldateien :)


      Vorgefertigte Konfigurationsdateien

      Ich biete hier vorgefertigte Konfigurationsdateien an, deren Funktionalität geprüft und bestätigt ist.

      1.) MD_PSX_15xNTSC_12xPAL.HEX

      Download: MD_PSX_15xNTSC_12xPAL.zip

      S0 = high => 53.693175 MHz (=15x NTSC subcarrier)
      S1 = low => 53.203425 MHz (=12x PAL subcarrier)

      Geeignet für:

      - Megadrive 1/2 (DIL14-Version des DFOs empfohlen)
      Spoiler anzeigen

      Getestet im Megadrive 2, sollte auch im MD1 funktionieren. Der S0-Eingang des DFOs muss mit dem 50/60Hz-Schalter verbunden werden.
      Foto vom Einbau einer älteren Version des DFOs im MD2:


      - Playstation (3.3V-SMD-Version des DFOs empfohlen)
      Spoiler anzeigen


      Getestet in einer SCPH-7500; *sollte* auch in einer SCPH-9000 und SCPH-101 (aka PSOne) funktionieren. Versorgungsspannung für den DFO soll 3.5V betragen. (Nachmessen!)

      Der S0-Eingang vom DFO wird mit Pin 13 des Video-DACs (IC502) verbunden ("NTSC/PAL"):





      Das ursprüngliche Taktsignal wird einfach unterbrochen, indem der 220 Ohm-Widerstand auf dem PSX-Mainboard entfernt wird. Jetzt kann das Taktsignal des DFOs eingespeist werden, nehmt dazu das markierte Testpad. Lötet aber zwischen DFO-Taktausgang und diesem Testpad noch einen 220 Ohm-Widerstand in Reihe ein. (Alternativ: Bestückt die 3.3V-SMD-DFO-Platine gleich mit einem 220 anstatt 18 Ohm-Widerstand.)





      2.) SAT_4xNTSC_4xPAL

      Download: SAT_4xNTSC_4xPAL.zip

      S0 = high => 14.31818 MHz (=4x NTSC subcarrier)
      S1 = low => 17.734475 MHz (=4x PAL subcarrier)

      Geeignet für PAL und NTSC Saturn-Konsolen (5V-SMD-Version des DFOs empfohlen)
      Spoiler anzeigen

      Getestet in einem weißem jap. Saturn (VA SG)

      - Der 50/60 Hz Mod sollte so realisiert worden sein, dass Pin 79 von IC14 nicht angehoben wurde. Pin 79 von IC14 und Pin 1 von IC20 sollten also miteinander verbunden sein. Der 50/60 Hz-Schalter wird mit diesen beiden Pins verbunden und auch der S0-Eingang des DFOs wird mit dem selben 50/60 Hz-Schalter verbunden.
      - Beim Umschalten von 50 auf 60 Hz und umgekehrt stürzt der Saturn wahrscheinlich ab. Also am besten nicht während des Spiels kurz vorm Endgegner umschalten. ;)
      - Versorgung des DFOs mit 5V Betriebsspannung


      - Auf dem Saturn-Mainboard ist das original X1-Schwingquarz zu entfernen sowie die beiden Kondensatoren C23 und C24.
      - Clock-Ausgang des DFOs wird mit wie auf dem Bild oben zu sehen eingespeist (beide Punkte sind gleichwertig, würde aber den linken empfehlen, da größer)


      Hier sieht man die weiße Strippe, über die bei meinem Saturn das Taktsignal vom DFO in den Saturn eingespeist wird. (Kupferlackdraht ignorieren)


      - Eingebauter DFO: Direkt über dem IC20 ist eine gute Stelle den DFO zu platzieren. Nicht vergessen, die Unterseite des DFOs zu isolieren.
      - 5V kann am nicht-bestückten Kondensator CE7 abgegriffen werden, siehe Bild.

      Was bringt's am Framemeister?

      Vorher:


      Nachher:




      Anleitung für einen VA SD PAL Saturn (2. Modell) - THX to @maki9000

      maki9000 schrieb:

      Laut segaretro.org/Sega_Saturn/Hardware_revisions und nfggames.com/forum2/index.php?topic=5744.msg43145#msg43145 ist der VA SD PAL identisch zum VA3 PAL oder VA5 PAL)

      Fun Fact: Durch den DFO wird der RegionSwitch einfacher bei diesem Modell vom Schwierigkeitsgrad her.
      Konkret heisst das, dass man keine Pins mehr anheben muss :)

      Bei diesem DFO Mod geht es darum, die Masterclock umzuschalten auf die jeweilige Grundfrequenz (PAL/NTSC) beim schalten von 50/60Hz.
      D.h. dieser Mod wird nur durch den Hz Pin des RegionSwitches gesteuert.

      JP1

      JP1 ist hard-kodiert auf 0V bei den PAL Modellen, dazu ist im VA5 noch ein Pull-Down Widerstand verbaut worden anstatt einem Jumper, der Pull-Down sollte raus sonst wird es schwieriger das Signal auf 5V zu treiben.


      Also raus mit dem Pull-Down



      VDP2 IC14 Pin 79

      Dieser Pin sollte bereits im Auslieferungszustand mit JP1 kurzgeschlossen sein, das sollte man prüfen sonst ist das hier wohl die falsche Anleitung!
      Diesen Pin auch mit dem RegionSwitch Hz Pin verbinden.



      Den Quartz ersetzen

      5V DIL DFO wird so programmiert:
      S0 = 0V -> 17.734475 MHz PAL
      S0 = 5V -> 14.31818 MHz NTSC

      Der Code ist aus dem DFO Thread hier "SAT_4xNTSC_4xPAL": DFO: Dual Frequency Oscillator

      Der original PLL 315-5746 mit seinem Quartz:


      Den Quartz und die beiden Kondensatoren entfernen, die Brücke zwischen JP20/JP21 und GND entfernen.


      Einen der gelben Punkt mit dem DFO S0 Pin und dem "Hz" Pin des RegionSwitches verbinden ("Hz" wurde vorher ja schon mit dem JP1/IC14 Pin 79 verbunden).
      Die rot markierte Brücke trennen.

      Alle diese Pins:
      • IC20 Pin 1
      • IC14 Pin 79
      • DFO S0
      • RegionSwitch Hz Pin
      sollten danach verbunden sein und vom RegionSwitch Hz Pin getrieben werden!

      Hz Pin 5V -> 60Hz NTSC
      Hz Pin 0V -> 50Hz PAL

      Fertig :)



      Wichtig:
      Falls der RegionSwitch IC nicht in der Lage ist, durch den "Hz" Pin alle diese anderen Signale zuverlässig zu treiben, kann es zu instabilitäten kommen.
      Manchmal sieht man, dass eine zusätzliche Treiberschaltung aus Transistoren empfohlen bzw. verbaut wird.
      Ich hab bis jetzt keine Probleme, aber das sollte man im Auge behalten.
      Haltet die Drähte so kurz wie möglich und achtet auf saubere Lötstellen mit hoffentlich geringem Übergangswiderstand.



      3.) SAT_4xNTSC_PAL_CORRECTION

      Download: SAT_4xNTSC_PAL_CORRECTION.zip

      S0 = high => 14.31818 MHz (=4x NTSC subcarrier)
      S1 = low => 14.22148... MHz

      Geeignet für NTSC-Saturn-Konsolen (5V-SMD-Version des DFOs empfohlen)
      Spoiler anzeigen
      - Das Ergebnis ist das gleiche wie bei der Variante unter 2)
      - Geeignet für 50/60 Hz-Mods, bei denen Pin 79 von IC14 angehoben wurde. Pin 1 von IC20 bleibt im Original-Zustand, d.h. bei NTSC Konsolen fest auf 5V gelegt.
      - Der 50/60 Hz-Schalter wird daher nur mit dem angehobenen Pin 79 von IC14 und dem S0-Eingang des DFOs verbunden.
      - Im 50 Hz Modus erzeugt der DFO eine "krumme" Frequenz, so dass die Bildrate für 476i und 288p wieder korrekt ist.


      4.) DFO_for_NeoGeo (THX to @mi213 & @borti4938)

      Download: DFO for NeoGeo.rar

      S0 = high (3.3V nicht 5V!) => originale 24.00 MHz (= originale refresh rate von 59.18Hz)
      S1 = low => 24.3059 MHz (= refresh rate von 59.94 Hz)

      Getestet mit einem MV-1C mit der 3.3V-Version des DFOs (SMD-Version empfohlen; eventuell liegen auch bei anderen MVS-Versionen 3.3V am Ostillator an?)
      Spoiler anzeigen

      - Hier eine passen Einbaustelle
      - Man bekommt die 3.3V vom Spannungswandler direkt daneben
      - Der DFO gibt bei S0 high 24MHz aus und bei S0 low (oder nicht verbunden; Pull-Down ist auf dem DFO) ~24.3059 aus.






      Eigene Konfigurationsdatei mit ClockPro erstellen

      Mit dem Software-Tool ClockPro von Texas Instruments könnt ihr eure eigenen .hex-Dateien erstellen mit den Frequenzen, die ihr für eure Anwendung benötigt. Für die meisten Leute wird dies wohl nicht von Belang sein, deshalb versteckt sich der ganze Kram im Spoiler für eine bessere Übersicht im Thread.

      Spoiler anzeigen
      Startet ClockPro und ihr werdet mit einem Wizard-Fenster begrüßt. Belasst fIN auf 27 MHz und Anzahl der Taktausgänge auf 1. Gebt nun für Y1 eure gewünschte Frequenz ein. Diese darf zwischen 80 kHz und 230 MHz liegen. Es sollte die Frequenz des Taktsignals sein, das ausgegeben wird, wenn der S0-Eingang des DFOs high ist.



      Zu Demonstrationszwecken basteln wir uns jetzt die Beispielkonfigurationsdatei von oben für's Megadrive & PSX nach. Wir geben also für Y1 53.693175 (MHz) ein. Clickt auf "Generate Setup" oben rechts.



      ClockPro wird euch nun als geeigneten IC den CDCE913 vorschlagen. Das ist gut, denn das ist auch der verbaute IC auf dem DFO. :)
      Clickt auf "View Setup".



      Uff, ganz schon unübersichtlich, was? ^^
      Zunächst gilt es zu beachten, das die hier gezeigten Einstellungen für den Fall gelten, dass der S0-Eingang des DFOs auf einem High-Pegel gehalten wird. (siehe "Control Line Selection" -> S0 =1)

      Oben rechts sehen wir die Frequenz des ausgegebenen Taktsignals Y1. Das ist die resultierende Frequenz. Diese weicht etwas von der Soll-Frequenz, die wir zuvor in die Maske des Wizards eingeben haben ab. Die Abweichung von der Soll-Frequenz wird von ClockPro berechnet und angezeigt, man kann sie aber auch von Hand selbst berechnen nach der der oben aufgezeichneten Formel.

      Die Einheit der Abweichung ist ppm (parts per million), was einfach 10-6 entspricht. (So wie Prozent 10-2 und Promille 10-3 entsprechen.)
      Ich würde sagen, dass wir mit einer Abweichung von unter 1 ppm sehr gut leben können. Es gilt nämlich zu beachten, dass Quarzkristalle und auch Quarzoszillatoren eine wesentlich höhere Abweichung haben. Gewöhnlich sind 50 bis 100 ppm Standard. Das für den DFO eingesetzte Schwingquarz gehört mit 30 ppm definitiv zu den genaueren Quarzen...



      1.) Als erstes stellen wir die "Crystal Load" auf 18 pF ein. Dieser Wert ist immer einzustellen ungeachtet der Anwendung.
      2.) Die ungenutzten Taktausgänge Y2 und Y3 werden auf GND disabled. Dazu einfach so lange mit der Maus auf das türkise Dreieck klicken bis das oben gezeigte Symbol erscheint.



      Jetzt wollen wir uns mal genauer anschauen, wie die resultierende Frequenz zustande kommt.
      Der ClockPro-Wizard hat für die PLL eine Frequenz von 161.XXX MHz festgelegt. Dieses PLL-Taktsignal geht dann durch den Taktteiler "PDiv1". Der Wert des Taktteilers beträgt 3. Teilt ihr die 161.XXX durch 3, so kommt dann tatsächlich die Frequenz von 53.69XXX zustande, die an Y1 ausgegeben wird.

      Es gilt zu beachten, dass wir zwei verschiedene PLL-Frequenzen festlegen können, zwischen denen wir im Betrieb mit S0 umschalten können. Der Wert des Taktteilers "PDiv1" allerdings kann sich während des Betriebs nicht ändern, der bleibt auf 3.
      Daraus ergibt sich sofort der Wert für die PLL-Frequenz bei S0 = low, also wenn wir eine Ausgangsfrequenz von 53.203425 MHz erhalten wollen. Die PLL-Frequenz ist einfach dreimal so hoch!
      => 53.203425 MHz x 3 = 159.610275 MHz

      Also lasst uns diese Frequenz für s0 = low eintragen! :)



      1.) Stellt dazu als erstes die "Control Line Selection" von "S0 = 1" auf "S0 = 0"
      2.) Von "PLL1_0" auf "PLL1_1" stellen
      3.) In das Feld jetzt die zuvor berechnete Frequenz von 159.610275 MHz eintragen
      4.) Die Ausgangstreiber wieder genau so einstellen wie zuvor bei S0 = 1, d.h. das türkise Dreieck für Y1 und disabled auf GND für Y2 & Y3.

      Man muss feststellen, dass die eingegebene Frequenz nicht genau übernommen werden kann. Statt 159.610275 MHz steht da jetzt 159.61004784689 MHz. Die resultierende Frequenz ist deshalb auch nicht genau die gewünschte. Es ergibt sich eine Abweichung von 1,42 ppm (nachrechnen!). Das ist ca. 10 mal mehr als bei S0 = 1!

      Verbesserung 1:

      Durch Benutzung eines Taktteilerwertes von 4 anstatt 3 lässt sich die Abweichung deutlich verringern. Dafür müssen natürlich auch andere PLL-Frequenzen eingetragen werden. (Einfach jeweils die gewünschte Ausgangs-Frequenz mit 4 multiplizieren und eintragen.)




      Es ergibt sich nun für die zweite Frequenz (wenn S0 = low) mit 0.166 ppm eine wesentlich geringere Abweichung.


      Verbesserung 2:




      Indem wir jetzt den Taktteiler von 4 auf 2 verringern, müssen wir jeweils andere Frequenzen für die PLL eintragen. Die Berechnung erfolgt wie gehabt, einfach jeweils die gewünschte Frequenz mit 2 Multiplizieren und eintragen. Die Abweichung verändert sich in diesem fall nicht, sie bleibt gering (0.127 bzw. 0.166 ppm).
      Der Vorteil der nun halbierten PLL-Frequenz ist ein geringerer Stromverbrauch. :)

      Seid ihr mit den Einstellungen zufrieden, clickt auf File -> Save Hex Intel File. Jetzt könnt ihr den DFO wie oben beschrieben mit der soeben erhaltenen .hex-Datei programmieren.

      Wie ihr seht gibt es beim Erstellen der Konfigurationsdatei einige Freiheitsgrade. Es lohnt sich auf jeden Fall ein bisschen rumzuspielen und auch die Abweichungen zu berechnen und zu vergleichen.

      Dieser Beitrag wurde bereits 16 mal editiert, zuletzt von n00b ()

    • Wie DFO in unbekannte Konsole einbauen?

      Beim Megadrive 1/2 gestaltet sich der Einbau des DFOs sehr einfach. Einfach den alten Quarzoszillator ausbauen und den DFO (idealerweise in der DIL14-Version) einsetzen - fertig. Die allermeisten Konsolen haben allerdings gar keinen Oszillator als eigenes Bauteil verbaut. Stattdessen wird meistens ein Schwingquarz verwendet und eine Oszillatorschaltung darauf aufgebaut.

      Am Beispiel des Saturns soll hier nun gezeigt werden, wie man solche Oszillatorschaltungen analysiert, um den DFO einbauen zu können.
      Spoiler anzeigen

      Das hier ist die Taktgeneratorschaltung des Saturns im ursprünglichen Zustand. Sehr gut zu sehen ist das Schwingquarz X1. Links daneben befinden sich zwei Kondensatoren des gleichen Typs, die jeweils zwischen einem Quarz-Pin und Masse liegen. Außerdem ist das Quarz an IC20 rechts daneben angebunden.


      Auf der Unterseite des Mainboards sind weitere zur Oszillatorschaltung gehörende Bauteile vorhanden, die zwischen Quarz und IC20 liegen. Für unsere Absichten sind sie aber nicht relevant. Vereinfacht sieht die Schaltung so aus:


      Es muss jetzt rausgefunden werden, welche der beiden Pins von IC20 Takteingang und Taktausgang ist. Gewöhnlich wird das Eingangssignals einer Quarz-Oszillator-Schaltung invertiert und wieder auf den Quarz ausgegeben. Der DFO muss dann später an den Takteingang angeschlossen werden.


      Zunächst entlöten wir das Schwingquarz X1. Die beiden Kondensatoren C23 und C24 werden ebenfalls ausgebaut. (Das Entfernen dieser kapazitiven Last sorgt später für steilere Flanken unseres eingespeisten DFO-Taktsignals.)


      Auf diesem Bild ist ein Tastkopf zu sehen, der temporär an die Saturn-Masse angelötet wurde. Am Tastkopf wurde ein 10 kOhm-Widerstand eingeklemmt.
      Was wir damit machen: Wir schließen damit ein Pin des Quarzes über den 10 kOhm-"Angstwiderstand" gegen Masse kurz und schauen uns die Spannung am anderen Quarz-Pin an.

      Achtung: Operation am offenen Herzen! Damit das auch wirklich funktioniert muss der Saturn natürlich eingeschaltet sein. Also Netzteil + Isolation anbringen und darauf achten, dass man nirgends hängen bleibt! ;)


      Bingo, gleich auf Anhieb den Eingangs-Pin gefunden! (Der untere). Wir geben 0 V auf den Eingangsspin (unten) und IC20 invertiert diese Spannung und gibt sie am oberen Ausgangsspin wieder aus. Wer auf Nummer sicher gehen will, kann hier jetzt statt 0 V eben 5 V in den Eingang unten einspeisen und wird dann am Ausgang oben entsprechend 0 V messen.


      Versucht man 0 V in den oberen Pin einzuspeisen, so sieht man, dass das eben nicht der richtige Eingangsspin sein kann, weil er die 0 V nicht zu 5 V invertiert werden. Stattdessen misst man ca. 2 V.


      Zusammenfassung der Erkenntnisse:

      1) Es wurde herausgefunden, dass der untere Pin der Takteingang ist, in den wir unseren DFO-Takt einspeisen müssen.
      2) Weiterhin ist nun bekannt, mit welcher Spannung die Oszillatorschaltung des Saturns arbeitet, nämlich mit 5 V. Dies bedeutet wir können/sollen die 5 V-Version des DFOs verwenden und können diese auch mit 5 V betreiben. Hätten wir beim Anlegen von 0 V an den Takteingang allerdings nur eine Ausgangsspannung von 3.3 V gemessen, dann dürften wir den DFO auch nur mit max. 3.3 V Versorgungsspannung betreiben.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von micro ()

    • Ein schönes Teil. Es gibt etliche Konsolen, wo das praktikabel Einbaubar ist :) Der große Reiz ist natürlich die platzsparende Größe und die Verfügbarkeit des Quarzes. EIn weiterer Vorteil - ohne jetzt ins Datenblatt geschaut zu haben (Bemerkung im Spoiler beachten) - ist, dass der Switch zwischen den Frequenzen glitchfree ist. Das ist ja bei der einfachen Schaltung mit 74HCU04 und NAND-Gates nicht der Fall (hatte bisher nur eine Anwendung, wo das störte).
      Man muss überlegen, ob einem der höhere Preis das wert ist: ich sage ja und nein - kommt halt drauf an :)

      Tolle Arbeit @micro :D

      Spoiler anzeigen
      Bemerkung:

      Ich habe noch nicht ins Datenblatt geschaut. Deswegen ist das n Vermutung - ich wäre aber von TI enttäuscht, wenn gegenteiliges der Fall ist. Bitte korrigieren, wenn ich mich irre!!!
      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.

      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub
    • micro schrieb:

      Bisher wird allerdings nur der CDCE925 unterstützt, der in der allerersten DFO-Version eingesetzt wurde. Aber wer weiß, vllt. bohrt Unseen das Ding ja noch auf... :)
      Platinen und Bauteile liegen hier schon, mal schauen wann ich zum Löten und der Softwareanpassung komme. Eigentlich wäre es ja schön, wenn das Script die Parameter der PLL selbst berechnen könnte...

      Mit der 925er-Version hängt sich übrigens mein Saturn beim Umschalten zwischen PAL und NTSC gelegentlich auf - entweder gibts da ein Glitch-Problem oder die nachfolgende PLL auf der Saturn-Platine mag den Frequenzwechsel nicht.
    • Danke Jungs!

      xadox schrieb:

      Meinem PAL MD1 werde ich das wohl spendieren. Kann sowas ggf. auch in einer PAL PS1 betrieben?
      Ja genau, funzt auch in der PS1, habe ich selbst im Betrieb. Das löst dann wieder mal ein paar Probleme mit dem Framemeister. Außerdem wird dadurch die Anti-PAL-Protection von Konami in den ganzen Bemani-Games ausgehebelt. :D


      borti4938 schrieb:

      Ein schönes Teil. Es gibt etliche Konsolen, wo das praktikabel Einbaubar ist :) Der große Reiz ist natürlich die platzsparende Größe und die Verfügbarkeit des Quarzes. EIn weiterer Vorteil - ohne jetzt ins Datenblatt geschaut zu haben (Bemerkung im Spoiler beachten) - ist, dass der Switch zwischen den Frequenzen glitchfree ist.
      Ja, das Umschalten funktioniert glitchfree, hab das selbst mal am Oszi beobachtet. Die Frequenz des Taktsignals wird dann mit dem Umschalten hoch- bzw. runtergefahren bis die eingestellte Frequenz erreicht wird.

      borti4938 schrieb:

      Man muss überlegen, ob einem der höhere Preis das wert ist: ich sage ja und nein - kommt halt drauf an
      Im Falle des MD stellt sich die Frage halt nicht, weil einfach keine passenden Oszillatoren oder auch nur Quarzkristalle verfügbar sind bei den großen Distributoren.


      sanni schrieb:

      Kann man die anderen beiden Outputs des Clock Generators auch verwenden oder sind die Pins auf der Platine auf GND oder so gelegt?
      Die beiden anderen Taktausgänge werden bei den DFOs nicht genutzt und liegen brach.

      sanni schrieb:

      Wollte mir eigentlich den hier mal kaufen, so für allgemeine Bastelprojekte: learn.adafruit.com/adafruit-si…nerator-breakout/overview
      Das scheint ein ähnlicher Baustein zu sein. 8$ für ein komplettes Board, das ist schon ein guter Preis. Du musst halt aber auch bedenken, dass du das Ding irgendwie programmieren musst.

      sanni schrieb:

      Aber die Option ohne Umlöten zwischen zwei Frequenzen umzuschalten ist schon sehr dufte.
      Word! :thumbsup: Es ist aber zu bedenken, dass du mit dem CDCE913 im DFO nicht beliebig umschalten kannst. Also die "Grundfrequenz" darf schon beliebig zwischen 80 kHz und 230 MHz liegen. Aber die beiden Frequenzen, zwischen denen du mit S0 umschalten kannst, können nur maximal um den Faktor 2,5 auseinander liegen. Du wirst damit also nicht zwischen sagen wir 1 MHz und 100 MHz umschalten können. (Für den geplanten Einsatzzweck ist dies aber nicht von Nachteil, weil hier die Frequenzen eh sehr nah beieinander liegen.)

      Unseen schrieb:

      Platinen und Bauteile liegen hier schon, mal schauen wann ich zum Löten und der Softwareanpassung komme. Eigentlich wäre es ja schön, wenn das Script die Parameter der PLL selbst berechnen könnte...
      Ja, daran hatte ich auch schon gedacht, die Parameter in meiner Software selbst zu berechnen. Wenn du dein Skript um die anderen CDCE9XX-ICs erweiterst, solltest du unbedingt auf einen Bug von Clockpro achten: Dies betrifft den CDCE913 und den CDCE937. Wenn du den ClockPro-Wizard ausführst und eine .hex Datei erstellst, dann setzt das dämliche ClockPro die beiden A0 und A1 Adressbits auf 0 => Die werkseitig eingestellte I2C Adresse vom CDCE913 und 937 endet aber mit einer 1 => Nach dem Programmieren kann der IC dann nicht mehr unter der Standard-Adresse angesprochen werden!
      Habe extra deswegen meine Programmiersoftware anpassen/erweitern müssen, dass standardmäßig die werksseitige I2C Adresse bewahrt wird, egal was in der .hex steht...

      Unseen schrieb:

      Mit der 925er-Version hängt sich übrigens mein Saturn beim Umschalten zwischen PAL und NTSC gelegentlich auf - entweder gibts da ein Glitch-Problem oder die nachfolgende PLL auf der Saturn-Platine mag den Frequenzwechsel nicht.
      Gut zu wissen! Ich werde den Saturn-Umbau selbst in Kürze vornehmen und hier dokumentieren. Wie gesagt, in der aktuellen DFO Version sollte es keine Glitch-Probleme geben, die Frequenz fährt sanft hoch (oder runter). Schaumermal! :)

      Im MVS und im MD2 habe ich den alten DFO drin, aber da wird eigentlich nie umgeschalten, wenn dann nur per Hand. Bei der PSX konnte ich bisher noch keinerlei Probleme mit dem alten DFO feststellen...
    • micro schrieb:

      (... )Nach dem Programmieren kann der IC dann nicht mehr unter der Standard-Adresse angesprochen werden!
      Ah, guter Tip.

      Im MVS und im MD2 habe ich den alten DFO drin, aber da wird eigentlich nie umgeschalten, wenn dann nur per Hand.
      Im MD2 habe ich damit auch keine Probleme, aber da wird der Takt AFAIK nur runtergeteilt und nicht noch eine PLL hinterhergeschickt. Wenn es mit dem 913er-DFO das gleiche Problem gibt werde ich wohl mal das Scope dranhängen und notfalls schauen, ob ich den Saturn-eigenen PLL-Chip umgehen kann.
    • Puh! Es hat jetzt zwar ne ganze Weile gedauert, aber ich bin jetzt alles losgeworden, was ich loswerden wollte. :)
      Beispielkonfigurations-Hex-Dateien sind auch online ebenso wie eine Einführung in ClockPro zur Erstellung eigener Konfigurationsdateien.

      @Unseen: Habe den DFO mittlerweile auch in den Saturn eingebaut und kann bestätigen, dass sich die Konsole beim Umschalten oft aufhängt. Ich hatte jetzt ziemlich viel ausprobiert, z.B. DFO zeitverzögert nach 50/60 Hz umschalten, DFO mit 3.3 V betreiben etc. Ändert leider aber nichts... Es ist auch nicht so, dass der Saturn nur beim Hoch- oder Runterfahren der Frequenz hängenbleibt. Das scheint recht random zu sein, bei mir klappt's in 50% der Fälle nicht.

      Die komplette Umgehung des Saturn-PLL-Clock-ICs ist sicherlich möglich, für mich aber absolut Overkill. Ich betreibe den Saturn eh fast die ganze Zeit nur im 60 Hz-Modus. Nun funzt er auch auf 50 Hz ohne Probleme am Framemeister. Dass ich nicht während des Betriebs umschalten kann, ist für mich absolut zu verschmerzen. ^^
    • Ich hatte heute das PAL-Megadrive 1 von @retroman auf dem Tisch. Wie einige vllt. wissen, hat er bereits einen längeren Leidensweg hinter sich. Und zwar macht das MD1 an seinem TV Probleme, im 60 Hz-Modus hat er ein Wackeln der oberen Bildzeilen, im 50 Hz Modus ist soweit alles in Ordnung. Wer möchte, kann hier mehr über die Geschichte nachlesen:

      Sega Mega Drive: Wackelbild im oberen Bildbereich bei 60HZ ...
      Mega Drive 1 per Scart RGB an Samsung TV - Scheinbar kein Csync möglich

      Es ist durchaus denkbar, dass das Wackelproblem im 60 Hz-Modus auf de PAL-Oszillator zurückzuführen ist und ein DFO hier Abhilfe schaffen kann. Deshalb habe ich dem Megadrive einen DFO verpasst, Bilder befinden sich im Spoiler. Ob das Wackelproblem dadurch wirklich passé ist, wissen wir natürlich erst, wenn retroman seine Konsole wieder hat.
      Spoiler anzeigen



      Das MD1 in seiner vollen Pracht. Es wurde hier ein switchless Mod verbaut.


      Zu sehen ist hier der original PAL-Oszillator mit 53.203xxx MHz. Direkt darüber befindet sich der PIC mit dem Switchless-Code. Praktisch!


      Entfernt man noch ein paar weitere Schrauben, kann man das Mainboard umdrehen. Wir sehen hier die 4 Pins des Oszillators, die entlötet werden müssen.


      Nach getaner Entlöt-Arbeit sehen wir hier den ausgelöteten Oszillator.


      DFO einsetzen, von hinten festlöten, die Pins auf der Unterseite etwas kürzen. Der gelbe Draht ist das 50/60 Hz-Signal, welches mit dem S0-Pad des DFOs verbunden wird.
      Ich kenne mich mit den switchless Mods NULL aus, aber wenn ich mir die Pins des PICs anschaue und dem Diagramm von @n00b vergleiche, dann komme ich zum Ergebnis, dass es sich hier um einen PIC mit d4s' Code handelt. Deshalb ist das 50/60 Hz Signal an Pin9 abzugreifen. Dazu musste ich ein wenig der protective Heißkleber-Wurst abknibblen - kein Problem.


      Das war das 60 Hz-Bild am Framemeister vor dem Einbau. Wir sehen, dass die Framerate 59.37 Hz betrug. Auch schön zu sehen, dass der Framemeister die Helligkeit/den Schwarzwert verrafft, wenn das Bild die "falsche" Framerate hat. Aus schwarz wird grau, generell ist das gesamte Bild einen Tacken zu hell.


      Nach erfolgtem DFO-Einbau beträgt die Framerate nun 59.91 Hz, was auch genau der einer echten NTSC-Konsole entspricht. Das Bild ist von der Helligkeit nun viel besser. Schwarz ist schwarz und nicht mehr grau. (Wohlgemerkt ohne irgendwas am RGB-Kabel gemacht zu haben, die RGB-Spannungspegel sind selbstverständlich immer noch die gleichen.)


      Tja, mal schauen was die Konsole nun an retromans TV treibt. Toi, toi, toi! :D
    • Wenn das Problem sich damit (endlich) lösen lässt, wäre ein Einbau-TUT sicherlich ganz praktisch, da hier ja doch einige unterwegs sind, die nur noch "moderne" Flats besitzen. :)

      Und ja - es ist der Code von d4s auf dem PIC. ;)
    • Und es wackelt nichts mehr!;)

      Nach ersten kurzen Tests kann ich sagen: Das Wackeln bei 60hz ist verschwunden!
      Da wackelt nichts mehr, das Bild steht endlich still wie es sein sollte!
      Ich habe ja fast nicht mehr daran geglaubt, dass es bei dem launischen, neueren Samsung LCD-TV möglich ist, mit einem Sega Mega Drive bei 60hz kein wackelndes Bild zu haben.
      Ist es aber! Dank DF0 und vor allem micro!
      Nochmal tausend Dank! für die ganze Arbeit und Dein entgegenkommen micro!
      Ohne micro und sein DFO, hätte ich das Wackelproblem des pal mega drive bei 60hz wohl nicht lösen können.
      Natürlich mache ich noch ausführlichere Tests, aber wenn einmal nichts mehr wackelt, wackelt wohl auch später nichts mehr und das ist für mich die Hauptsache!
      Wie micro bereits angeschnitten und verlinkt hat, habe ich wegen dem Wackelproblem schon so eine Art Leidensgeschichte hinter mir und bin jetzt erstmal heilfroh und erleichtert. Auch bei noob bedanke ich mich für seine Bemühungen Hilfestellung!
      Ich denke, ich kann jetzt auch davon ausgehen, dass das Genesis, also die u-s-Version des Mega Drives, das ich extra wegen dem Wackelproblem bestellt habe, auch nicht wackelt.
      Jetzt kann ich auch endlich über einen rgb-bypass beim Mega Drive nachdenken, um die störenden Streifen weg zu bekommen; )
      Nach meinen bisherigen Beobachtungen kann ich den DF0 nur wärmstens empfehlen.
      Kommt natürlich auch auf die jeweilige Problemstellung an, klar, bei mir scheint es aber wohl ein voller Erfolg zu sein!


      Randbemerkung:

      composite sync vs csync:

      Etwas hat sich jedoch geändert:
      Benutze ich ein Scart-RGB-Kabel mit composite-sync, habe ich jetzt ein leichtes Flimmern bei 50hz im Bild was vorher nicht war.
      Bei 60hz ist dagegen alles ok.
      Nutze ich dagegen ein Scart-RGB-Kabel mit csync ist alles einwandfrei, sowohl bei 50hz als auch bei 60hz -nach meinen bisherigen Beobachtungen.
      Diese Ausfallerscheinung kann aber auch dem wohl etwas launischen Samsung LCD-TV geschuldet sein.
      An einem anderen LCD-TV, kann es sich wieder komplett anders verhalten.
      Da die genannte Ausfallerscheinung mit einem csync-Kabel nicht mehr auftritt, stört es mich nicht sonderlich.
      Ich erwähne es auch nur der Vollständigkeit halber.
      Vielleicht ist diese Beobachtung ja für den ein oder anderen von Nutzen.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von retroman ()

    • Hallo ChinFu,

      ich meinte natürlich Composite Video.
      Sorry, bin da noch nicht so versiert und bis vor kurzem wusste ich auch noch gar nichts darüber.
      Also das erwähnte Flimmern tritt bei Composite-Video auf und wie gesagt nur bei 50hz.
      Bei csync ist es nicht vorhanden.
    • Beobachtungen nach intensiveren Tests:

      Es tut mir wirklich sehr leid, dass ich schlechte Nachrichten zu verkünden habe.
      Besonders nach dem ich gestern wirklich super happy und euphorisch war, nach dem nach kurzen Einschalten des Mega Drive gesehen habe, das endlich
      das Bildwackeln verschwunden war.

      Ich habe das Mega Drive jetzt mal intensiver getestet und musste leider feststellen, das nach 15 bis 30 Minuten, je nach Spiel verhält es sich scheinbar unterschiedlich, das Bild einfriert.
      Es friert einfach ein und nichts bewegt sich mehr auf dem Bildschirm.
      Der Sound läuft manchmal normal weiter, ein anderes mal wiederholt er sich abgehackt in einer Art Endlosschleife.
      Das Problem tritt sowohl bei 50 als auch bei 60hz auf.

      Nach dem ich die restliche Infrastruktur wie Netzteil, Modul usw. ausgeschlossen habe und es da mit einem anderen Mega Drive keine Probleme gab,
      liegt es wohl an besagten Mega Drive - Nach bisherigen Kenntnisstand, weitere Tests folgen.
      Ich hatte dieses Mega Drive auch noch nie länger in Benutzung, sondern nur einen sporadischen Funktionstest damit gemacht.
      Danach wurde es erst mit dem switchless 60hz-Mod versehen und dann hat es ja wie gesagt den DFO spendiert bekommen.

      Erst nach dem ich gestern gesehen habe, dass da nichts mehr wackelt, hatte ich richtig Lust zu Spielen und hatte das Gerät längere Zeit in Betrieb und da hat sich dann das genannte Problem gezeigt. Es muss also keinesfalls am DfO liegen.
      Woran es allerdings genau liegt, kann ich leider nicht sagen.
      Das ist der aktuelle Stand der Dinge und wie gesagt sorry für die schlechten Nachrichten, ich würde lieber was anderes schreiben.
      Besonders nach all der Mühe die sich micro gegeben hat.
      Echt schade;(
    • Autsch, das darf nicht sein! :(
      Sorry, das tut mir wirklich leid!

      Ich hatte in Betracht gezogen einen Sockel zu verbauen (+Steckverbinder für die gelbe 50/60 Hz-Strippe). Ich hab mich aber doch dagegen entschieden, weil es mir nicht sicher genug schien. Der DFO hat nämlich nur 3 Beinchen, nicht dass er auf dem Postweg aus dem Sockel fliegt. Den DFO habe ich deswegen sicher eingelötet.
      Wäre er gesockelt, dann könntest du einfach mal den original Oszillator einstecken (den ich mangels Sockel aber eh hier behalten habe) und schauen, ob das Problem weg ist.

      Zum DFO selbst: Das war einer der ersten Exemplare. Der CDCE913 auf dem DFO wurde leider anfangs mit einer falschen Konfiguration programmiert. Hab's zwar rückgängig gemacht, aber ich konnte einen höheren Stromverbrauch feststellen. (ca. 30-40 mA statt normalerweise 12-14 mA.) Vor dem Einbau habe ich einen neuen CDCE913 in den DFO reingelötet. Stromverbrauch war danach normal. Der DFO sollte damit eigentlich in Ordnung sein.

      Was da jetzt das genau Problem ist, kann ich dir auch nicht sagen. Ein Wabern im 50 Hz Modus mit dem DFO wäre mir jedenfalls auch nicht aufgefallen...

      Das tut mir jetzt wirklich leid... Du kannst es mir natürlich gerne noch mal zuschicken oder ich geb dir Bescheid, wenn ich mal wieder in MA bin. Dann könnte ich nochmal genau nachschauen bzw. im schlimmsten Fall den alten Oszillator wieder einbauen.

      Ich muss auch gestehen, dass ich dein MD keine 30 bis 60 min laufen ließ, sondern vllt. 10 Minuten max. Mein MD2 jedenfalls läuft mit dem DFO stundenlang ohne jegliche Probleme...
    • Hallo micro,

      keine Panik! Das ist doch überhaupt nicht Deine Schuld und ich sehe es auch nicht so!
      Ganz im Gegenteil, Du hast Dein Bestes versucht und warst sehr bemüht mir bei meinem Problem zu helfen!
      Es muss ja auch wie gesagt gar nicht am DFO liegen.
      Da ich dieses Mega Drive selbst nie länger am Stück in Betrieb hatte, kann es auch gut sein, das es an dem Mega Drive selbst liegt.
      Das ist ja auch schon alt und hat deshalb bestimmt einen gewissen Verschleiß hinter sich.
      Ich muss mir da eher die Schuld wegen meiner unzuverlässigen Testmethode geben.
      Es ist halt scheinbar nicht damit getan, nur einen kurzen Funktionstest bei solch alten Geräten zu machen, sondern man sollte um wirklich auf Nummer sicher zu gehen das alles ok, das Gerät schon ein paar Stunden laufen lassen, was ich ja nicht getan habe.
      Da ich jetzt für diese Problematik sensibilisiert bin, werde ich es in Zukunft berücksichtigen.
      Da war wohl eher ich etwas zu schludrig;)
      Also wie gesagt keine Bange, dank DFO kann ich jetzt zumindest mit großer Wahrscheinlichkeit davon ausgehen, das die bestellte U.S-Konsole am besagtem TV ebenfalls kein Wackelbild hat.
      Ich sehe es deshalb eher gelassen;)
      Vielleicht lässt sich der Fehler ja auch noch finden und beheben und auch wenn nicht, ist es wie gesagt kein Beinbruch.
      Ich finde ich den DFO nämlich durchaus interessant weil er bei mir das Wackelproblem gelöst hat und es wäre natürlich gut zu Wissen, ob ein Mega Drive 1 damit generell harmoniert.
      Deshalb könnte es gut sein, dass ich Dein Angebot wahrnehme und Dir die Konsole nochmal zuschicke.
      Wenn ich mich dafür entscheiden sollte, schreibe ich Dir aber vorher noch Mal eine pm.
      Also alles kein Weltuntergang;)
    • Kurzes Update:

      Das besagte Mega Drive hatte wohl einen wie auch immer gearteten Schaden.
      Der DfO wurde dann in ein Mega Drive eingebaut, das ich vorher ausgiebig getestet habe und siehe da, keine Probleme mehr, es läuft stabil!;)
      Nochmal vielen Dank an micro und n00b!
    • Moin,

      ich habe heute mal den DFO in ein 1Chip-SNES eingebaut. Genutzt wird er, um am S-CPUN Pin 9 zw. ~17.734MHZ (PAL, S0 = '1') und ~21.477MHz (NTSC, S0='0') umzuschalten. Klappt wunderbar - die Schätzung des Masterclocks über das sd2snes (keine Ahnung, wie genau die ist) passt ;)

      Hier einmal n kleines Bild der Installation (der interessante Part). S0 ist mit S-CPUN Pin 111 verbunden.



      Wer aufmerksam ist, weiß, dass am S-RGB Pin 9 auch zw. PAL- und NTSC-Encoding umgeschaltet wird. Die Umschaltelogik ist aber invertiert zu der, die am S-CPUN Pin 111 genutzt wird. Genau aus dem Grund habe ich auf dem Multinorm-Board am 74HC27 Pin 8 dafür vorgesehen, dass dort das entsprechende Signal ausgegenen wird. Ein Pad habe ich dafür nicht - ein verstecktes Feature also ;)



      Zu guter Letzt: das hex-file für den CDCE913 habe ich angehängt ;)

      danke an @micro für das Projekt :D
      Dateien
      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.

      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub