DFO: Dual Frequency Oscillator

xadox · 4. Januar 2016, 10:39

Danke borti!
Am Ende stelle ich mir die Frage, hat man durch den DFO einen Vorteil gegenüber der herkömmlichen Lösung?
Bei einer PSX hat man ja durchaus das Problem, das eine Handvoll Spiele ohne einen echten Takt nicht sauber laufen.

rama · 4. Januar 2016, 11:59

Ich hoffe, meinen DFO mit einem raspberry pi programmieren zu können.
Dann sehe ich den als Experimentierquarz, zum Beispiel um exakt 60Hz aus einer Konsole zu bekommen (für TFT Displays).
Außerdem gibt es halt nirgends die dringend benötigten 53.69 Quarze / Oszillatoren

niopio · 4. Januar 2016, 12:14

Wo krieg ich das für mein Mega Drive II?

xadox · 4. Januar 2016, 12:34

niopio schrieb:

Wo krieg ich das für mein Mega Drive II?

An sich steht alles im ersten Post.
Zusammengefasst Die Platine kannst du hier ordern:
oshpark.com/profiles/micro

Die Einzelteile größtenteils bei Mouser:
mouser.com/ProjectManager/Proj….aspx?AccessID=f6f43aace7

niopio · 4. Januar 2016, 17:41

Danke, beim zweiten mal durcharbeiten wurde mir die Problematik auch erst so richtigcklar. Ich muss das nicht nur soebsg einbauen und zusammenbauen, sonderncauch sourcen.

Danke noch mal für die Links, Platinen sind mal allesamt bestellt.

ikari_01 · 12. Januar 2016, 15:59

EULE

micro · 12. Januar 2016, 18:14

Haha, endlich spricht's mal einer an! ::mrgreen::

rama · 27. Januar 2016, 17:15

Der DFO in der 5V DIP 14 Version funktioniert wunderbar in einer PAL Playstation SCPH-1002.
Ich nutze in als zweiten Taktgeber neben dem bereits installierten PAL Oszillator, also bei 53,69Mhz.

Damit kann ich bereits bestätigen, das sich ein DFO wunderbar auch als Composite Video Taktquelle eignet.
(In der PSX teilt die GPU im NTSC Modus den Takt durch 15, um 3.58Mhz Color Burst zu erzeugen.)
Einige Stimmen sagen ja, das die programmierbaren Chips dafür zu ungenau sind oder zu stark driften.
Das Bild ist super stabil und ich sehe absolut keine Probleme

Auch war es kein Problem, den für 5V ausgelegten DFO mit den 3.5V der PSX zu betreiben.
Das Taktsignal kommt bereits passend aus dem DFO. Es wird kein 220Ohm Widerstand mehr benötigt.

mi213 · 21. Februar 2016, 21:47

~~Hat noch jemand zufällig einen DFO für mich bzw für meine MegaDrive 2 über?~~
Meine MD2 verhält sich auch sehr unschön in Kombination mit dem Framemeister.

Sollte niemand einen über haben und ich mir die Bauteile selber ordern muss, wärest du @micro bereit mir den Programmer aus zu borgen damit ich mir den nicht extra zusammen bauen muss?

micro · 22. Februar 2016, 13:39

Momentan würde ich meinen Programmer lieber nicht verleihen, aber du kannst mir gerne deinen DFO zum Programmieren zuschicken. Wenn du die 3 Pins (noch) nicht einlötest, ist das Ding ja recht flach und das Porto fällt auch geringer aus.

Ansonsten müsste ArcadeTV auch noch einen Programmer haben...

ArcadeTV · 22. Februar 2016, 13:49

Check!

mi213 · 22. Februar 2016, 15:31

Super, danke @micro und @ArcadeTV für das Angebot. Würde dann gerne eines der beiden Angebote annehmen. :thumbsup:

Habe mir gestern schon bei OSHPark drei PCBs von der 5V Variante geordert. Bauteile sind auch so gut wie geordert. Melde mich dann aber noch mal bei euch sobald alles da ist.

rama · 22. Februar 2016, 16:24

Gibt es eigentlich schon die Möglichkeit, den CDCE913 mit einem Raspberry Pi zu programmieren?
Cdceprog unterstützt ja nur den CDCE925, bisher.
Welche Anpassungen wären nötig? Vielleicht bekommen wir das ja hin

Nopileus · 5. März 2016, 20:41

Tolles Projekt und super dokumentiert micro, hat richtig Spass gemacht.

Als erstes SMD stück vielleicht nicht ganz optimal aber trotzdem hat alles auf Anhieb funktioniert, heute ging der erste DFO in eine SCPH-7502.
Mangels Scartkabel kann ich das Ergebnis leider noch nicht hundertprozentig testen (Framemeister mag kein PAL60 auf s-video/composite), aber sowohl PAL als auch NTSC Spiele laufen noch.

Für das NTPL/S0 Signal habe ich auch gleich noch einen angenehm erreichbaren Testpunkt gefunden und ganz zufällig passt alles sogar unter das RF-shield. (beide Bleche großzügig von innen isoliert)

Bilder vom Einbau und den Lötpunkten die ich benutzt habe sind hier zu sehen imgur.com/a/u1YbL
Der Modchip der zu sehen ist war schon in der Konsole und ist nicht meine Arbeit.

Einen zweiten DFO werde ich wahrscheinlich in meinem Saturn verbauen,
der Sinn dahinter ist wohl Fragwürdig da es schon eine japanische Konsole ist aber wenn ich schon ein regionsfreies BIOS und auto 50/60hz via Rhea einbaue dann kann der DFO auch nicht schaden.

PS: Meinen Programmer zeige ich euch lieber nicht, da ich den Schalter nicht in Europa gefunden habe musste ich improvisieren.

Edit:
Mein Saturn habe ich nun auch mit einem DFO ausgestattet, leider nur mit teilweisem Erfolg.
480i und 240p modi funktionieren genau wie zuvor, 288p ebenfalls ohne Probleme.

576i macht allerdings Probleme, das Sync Signal scheint dem Framemeister nicht zu schmecken weshalb das Bild reisst und flackert.
Ton läuft sauber und Status zeigt 50.00hz an, die sichtbaren Teile des Bildes haben die richtigen Farben.
Konsole ist ein NTSC-J VA1 board, IC14 pin79 angehoben und mit Schalter verbunden. DFO hat das "SAT_4xNTSC_PAL_CORRECTION" hex.

Wenn mir micro oder jemand anders dazu etwas input geben kann wäre das klasse.

Edit 2:
Problem gelöst!

Ein NTSC Saturn gibt auf Pin 1 Csync aus, mein SCART Kabel hat dies auch genutzt. Allerdings ist dieses Csync signal mit TTL Level was für normale 75ohm terminierte Eingänge untauglich ist.
Die Lösung ist es einfach einen 470ohm Widerstand in reihe mit dem Sync Signal zu löten, im SCART Stecker ist in okay aber direkt in der Konsole ist wohl noch besser. Das gleiche gilt wohl bei Master System und Mega Drive.
Mit Kabeln die composite video oder luma als sync benutzen tritt dieses Problem nicht auf!

Das Saturn gibt nun alle Modi perfekt aus und der Framemeister kann damit umgehen. Noch einmal vielen Dank micro für die tolle Aufbereitung des Projekts.

GBM · 2. Juni 2016, 23:50

Hat hier jemand schon einen DFO in ein N64 eingebaut? Würde mich interessieren so eine Mod durchzuführen und habe zufällig bemerkt, dass ja folgender Download für den Saturn auch für den N64 gehen müsste (wenn man MPAL vernachlässigt):

micro schrieb:

2.) SAT_4xNTSC_4xPAL

Download: mediafire.com/download/pzgipkd508mdgd6/SAT_4xNTSC_4xPAL.HEX

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

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

saturnu schrieb:

Um das N64 komplett zwischen PAL/NTSC wechseln zu lassen braucht man wohl auch noch
einen anderen Crystal am MX8350

OSC1 IN - Pin 13
NTSC 14.31818 MHz
PAL 17.734475 MHz
MPAL 14.302446 MHz

NTSC/PAL Select - Pin 7 -> High=NTSC/MPAL Low=PAL

VCLK - Pin 3 -> RCP11/MAV20

Quelle: N64 PAL/NTSC-Switch möglich?

Wobei wahrscheinlich die 3,3V Variante ausreicht oder? Hätte sonst noch jemand vielleicht Interesse an einer Sammelbestellung?

saturnu · 3. Juni 2016, 00:31

Ich würde an deiner Stelle auch die 3,3v Variante nehmen, dann kann man S0 vom DFO auch gleich mit Pin 7 vom MX8350 verbinden, damit der RCLK auch immer brav bei 250Mhz liegt für den RAMBUS.

borti4938 · 3. Juni 2016, 07:33

@ArcadeTV dürfte noch 5V Dinger sowie den Programmer zu liegen haben. Nur leider ist der im Nirvana verschwunden...

micro schrieb:

Diese DFO-Version muss aber nicht mit 5 V betrieben werden, sie funktioniert auch bspw. mit einer Versorgungsspannung von 3.3 V.

Ansonsten @GBM
Wenn du vor hast, dir welche zu bestellen, dann melde dich mal bei mir. Hätte auch Interesse. Habe seit Ewigkeiten da n Idee zu liegen.

GBM · 4. Juni 2016, 17:02

saturnu schrieb:

Ich würde an deiner Stelle auch die 3,3v Variante nehmen, dann kann man S0 vom DFO auch gleich mit Pin 7 vom MX8350 verbinden, damit der RCLK auch immer brav bei 250Mhz liegt für den RAMBUS.

Ich habe den MX8330 bei mir verbaut. Aber laut diesem Datenblatt könnte ich hier ja genauso PIN 7 für S0 abgreifen oder? High und low werden ja ohnehin softwareseitig bestimmt.

Edit: Folgendermaßen sollte das dann aussehen:

FSO also bei PAL: FSEL=1 --> 4*17*4,43361875=75,37151875*4 MHz --> DFO: 4,43361875

FSO also bei NTSC: FSEL=0 --> 4*14*5,38367985=75,3715179*4 MHz--> DFO: 5,38367985

Also S0 (Multiplikator 17 bei PAL) und S1 (Multiplikator 14 bei NTSC) sind damit invertiert im Vergleich zum Saturn oder?

saturnu · 4. Juni 2016, 18:04

FSEL ist ein Input Pin, da gibt's nichts abzugreifen, das ist einfach je nach Region fix durch die Leiterbahnen vom Mainboard vorgegeben.^^
Also muss hier mal wieder der Pin vorsichtig angehoben werden.
Ich vermute du bist gedanklich gerade in der verkehrten Richtung unterwegs.

GBM · 4. Juni 2016, 18:14

Also du sagst, dass FSEL dadurch dauerhaft auf 1 (high) ist? Wodurch kommt dann der Wechsel zwischen 50hz und 61hz zustande, der per Software festgelegt werden kann?

saturnu · 4. Juni 2016, 19:15

Entweder dauerhaft high oder low, je nach Mainboard und Region.

Das ist nur sowas wie der Basistakt für das RCP Videointerface, dort wird dann nochmals multipliziert, je nach Registersettings.
Da man normalerweise sowieso nur "passende Spiele" starten kann, stimmt der Basistakt dann ja auch zu den Registersettings.
Es wird eh bei NTSC sowie PAL irgendwas um die 50Mhz vom MX generiert und nicht einmal 50 und einmal 60 direkt für den DAC und RCP.

NTSC = 48.681812 MHz
PAL = 49.65653 MHz
MPAL = 48.628316 MHz

Komischerweise wird auch das sound signal via PAL-/NTSC-Takt getaktet, keine Ahnung warum man das nicht hat einfach fix über den BUS-Takt getaktet hat.

Der Vorteil war halt, dass man nur einen RCP produzieren musste und evtl. auch nur ein Spiel welches auf beiden Regionen richtig laufen kann.
Die Spiele konnten sogar die selbe PCB haben und es mussten nur unterschiedliche CIC bestückst werden.
Die PAL, NTSC und MPAL N64 unterscheiden sich nur am Mainboard, den ein bis zwei Crystals und am PIF und DAC.

Leider haben sich nicht alle Hersteller daran gehalten und es gibt Spiele welche eben das Videointerface fix konfigurieren anstatt auf die Konsolenregion zu reagieren.
Wodurch dieser Mod überhaupt erst "nötig" wird.

GBM · 4. Juni 2016, 20:04

Danke, das erklärt einiges.
Sonst noch eine Idee wo man das Signal für S0 herbekommen könnte (MAV-NUS PIN 23 hast du ja schon erwähnt)? Direkt vom RCP/VDC-NUS? Borti hat noch vorgeschlagen dieses vom C-Videosignal (über VSYNC) abzugreifen, dies ist aber auch nur über weitere Microcontroller möglich.

borti4938 · 4. Juni 2016, 20:46

Eine Idee: github.com/mrehkopf/32x-autohz

Zweite Idee: github.com/borti4938/n64rgb/blob/master/n64rgb.v#L66
vmode über einen freigelgten Pin am CPLD invertiert ausgeben lassen (man kann bspw. auf CLAMP, VSYNC oder HSYNC verzichten, wenn es nicht benötigt wird)

Ansonsten zitiere ich mal aus der PN, die ich gerade @GBM geschrieben habe:

borti4938 schrieb:

so - gerade mal geschaut. Ich habe auf einem japanischen Board geschaut, das Prinzip sollte aber identisch sein.

Ich habe zwei MX8330 - U7 und U15.

Der obere (U7) ist für CPU/Video zuständig, der untere (U15) für RAMBUS.
X1 und X2 sind die Quarze - wir wollen X1 verändern (bei U7)
die beiden Pin 7 sind untereinander verbunden. Und beide gehen dann über einen ~50k Widerstand (R36) an Pin 8 des PIF-NUS
Ist der Aufbau soweit bei dir identisch??? Wenn ja, ...

Mit dem DFO soll X1 ersetzt werden
SO kann nicht über Pin 7 des MX8330 gesteuert werden, weil dieser IMMER bei dir auf GND liegen wird (PIF(P)-NUS -> initialisiert IMMER per PAL) / bei mir auf Vcc (PIF-NUS -> initialisiert NTSC)
Pin 7 des oberen MX8330 muss angehoben werden, X1 entfernt werden
Pin 7 muss mit S0 verbunden werden und beide mit dem PIC 12F629 (siehe oben)
CLK vom DFO muss mit Pin 6 des MX8330 verbunden werden

saturnu · 4. Juni 2016, 22:44

GBM schrieb:

herbekommen könnte (MAV-NUS PIN 23 hast du ja schon erwähnt)

Das ist auch nur ein Input Pin, da der MAV-NUS ein universell konfigurierbarer DAC ist.

Zu @borti4938s Idee über den VSYNC bzw. das Videosignal die Erkennung zu machen, würde ich evtl. In die Überlegung einschließen danach einen PIF-Reset durchzuführen.
Ich könnte mir vorstellen, dass evtl. der RCP oder die CPU glitcht, wenn zwischendurch kurz der Takt resettet, da er 5ms braucht um sich zu stabilisieren.
Kommt aber wahrscheinlich einmal auf ein Versuch an.

Die Frage ist auch wann macht man das, da es schon einen kleinen Moment dauert bis ein Bild ausgegeben wird, so gesehen ist ein Microcontroller gar nicht die schlechteste Variante.

-> Hm Reset, wäre jetzt auch nicht so toll, wenn man im Flashcart Menü ist bei 50Hz, ein 60Hz Spiel startet und dann einen Reset durchführt.

Ich will auch nochmals anmerken, dass dieser Mod nur mit Dual-PIF oder Flashcart sinnvoll ist.

GBM · 4. Juni 2016, 23:08

saturnu schrieb:

-> Hm Reset, wäre jetzt auch nicht so toll, wenn man im Flashcart Menü ist bei 50Hz, ein 60Hz Spiel startet und dann einen Reset durchführt.

Ist vielleicht etwas OT, aber gibts einen bestimmten Grund warum man eigentlich (reale) Auflösung und Videomodus nicht für das Flashcartmenü einstellen kann? CIC-bedingt? Sicherheitsmaßnahme gegen falsche Darstellung?

saturnu · 4. Juni 2016, 23:20

Die Menüs richten sich alle ganz normal nach dem osTvType Register 0x80000300 und Stellen dann das VI-Register auf die entsprechende Region ein (erstmal low res).
Bei ED64 z.B. kann man ja auch noch auf die High Res Variante umstellen (PAL oder NTSC).
Theoretisch könnte man auch irgendwie NTSC-Einstellungen auf der PAL Konsole vornehmen, nur würden dann einige Fernseher (beim N64 ohne RGB Mod) den verdienten Urlaub antreten, also ja - Sicherheitsmaßnahme könnte man sagen.

GBM · 4. Juni 2016, 23:43

saturnu schrieb:

Bei ED64 z.B. kann man ja auch noch auf die High Res Variante umstellen (PAL oder NTSC).

Wobei selbst bei low-res nur zwischen 480i und 576i unterschieden wird. "Echtes" 288p/240p bekommt man nicht. Schade eigentlich, vor allem weil es immer zum nervigen Auflösungswechsel kommt.

saturnu · 5. Juni 2016, 01:21

Achwas, 480i und 576i ist doch high-res.
640x480 sind die high-res und die low-res Einstellungen beim ED64 Menü sind 320*240 also 240p.
Was du jetzt genau mit echten und unechten Auflösungen meinst, weiß ich nicht.

Das sprengt hier aber langsam wirklich den Rahmen des DFO-Threads. :s000:

GBM · 5. Juni 2016, 11:40

saturnu schrieb:

Achwas, 480i und 576i ist doch high-res.
640x480 sind die high-res und die low-res Einstellungen beim ED64 Menü sind 320*240 also 240p.
Was du jetzt genau mit echten und unechten Auflösungen meinst, weiß ich nicht.

Das sprengt hier aber langsam wirklich den Rahmen des DFO-Threads.

Naja es ist insofern für den DFO relevant, als dass, falls es Probleme beim Videomodewechsel bei RESET geben sollte, diese mit einem Update der ED64-Firmware behoben werden könnten.
Was ich meinte ist: Das Menü erscheint (zumindest mit Expansion-Pak) IMMER in 480i (auf einer NTSC-Konsole) und 576i (auf einer PAL-Konsole), egal ob 640*480 oder 320*240 gewählt wurden. Lediglich die Darstellung der Schrift ist in höherer/niedrigerer Auflösung, die Bildschirmauflösung bleibt immer 480i/576i. Deswegen wäre es gut, wenn man tatsächlich zwischen den Auflösungen wählen könnte.

borti4938 · 6. Juni 2016, 09:36

saturnu schrieb:

Ich könnte mir vorstellen, dass evtl. der RCP oder die CPU glitcht, wenn zwischendurch kurz der Takt resettet, da er 5ms braucht um sich zu stabilisieren.
Kommt aber wahrscheinlich einmal auf ein Versuch an.

Ja - Versuch macht klug

das SNES macht das Umschalten auch ganz gut mit (siehe oben)...

Ansonsten könnte man auch die herkömmliche Variante mit einem 74HCU04 und NAND-Gates nehmen. Da hat man keine Einschwingzeit, dafür aber einen kurzen Glitch (eine Takt lang eine unbekannte Periode) beim Umschalten des Taktes, was man theoretisch auch noch mit etwas Zusatzlogik rauskriegen würde.

Ähnliche Themen