[WIP] UltraPIF - Multi Region N64 PIF Replacement

  • Nintendo 64

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • [WIP] UltraPIF - Multi Region N64 PIF Replacement

    Hallo zusammen,

    wie ich bereits hier versprochen hatte, kommt nun der eigene Thread für mein Projekt. Mich würde sehr interessieren, wie viel Interesse eurerseits an dem Projekt besteht. Würdet ihr sowas haben wollen oder reichen euch die Regionfree Features vom Everdrive64 bzw. 64drive vollkommen aus?

    Ich habe schon lange überlegt, wann ich etwas über das Projekt veröffentlichen sollte. Sollte ich noch warten bis mehr funktioniert bzw. alles fertig ist? Das kann noch dauern. Diese Woche ergab sich mit der Diskussion im oben verlinkten Thread eine gute Gelegenheit. Somit könnten auch noch evtl. neue Ideen in die nächste Rev. einfließen.

    Worum geht es?
    Ich experimentiere und bastele schon länger mit dem N64. Vor einiger Zeit brachte mich @saturnu mit diesem Post auf die Idee, dass man ein N64 PIF Replacement bauen könnte. Damals war mir das ne Nummer zu groß, aber ich hab die Idee immer im Hinterkopf behalten und dann mal ein Breakoutboard für den PIF gebaut.



    Dann hab ich etwas experimentiert und mit Hilfe meines Nexys4DDR und etwas Suchen im Netz herausgefunden, wie die Kommunikation zwischen RCP und PIF abläuft. Der erste Prototyp mit Devboards war dann auch nicht mehr weit entfernt. Die PIF-ROMs konnten damit auch schnell ausgelesen werden. :whistling:



    Was könnte man nun damit machen?
    Zuerst einmal für alle, die jetzt nicht gleich wissen, was der PIF ist:
    Der PIF ist ein Chip im N64 und hat 4 Funktionen:
    • beinhaltet das MIPS-Boot-ROM
    • Bestandteil des Kopierschutzes (prüft CIC, im Fehlerfall wird die CPU mit zyklischen NMIs bespaßt und das war's dann)
    • Schnittstelle zu serieller Peripherie (Controller, EEPROM, RTC)
    • Reset-Management (Cold-Reset, Reset-Button)


    Möglicher Nutzen eines PIF-Replacements
    • Booten von PAL- und NTSC-Games
    • Einspielen eines Custom-Boot-ROMs
    • CIC in Backup-Units ist nicht mehr notwendig (Backup-Unit kann den gewünschten CIC auswählen)
    • EEPROM- und Controller-Pak-Savegames auf SD-Karte umleiten (geht nicht bei SRAM oder FlashRAM-Games)
    • Nutzung von USB-Gamepads
    • Wireless Controller durch Bluetooth
    • Remote-Reset per Controller
    • Emulation des RTCs (für Backup-Units die keinen RTC haben)
    • TV-Clock anpassbar durch programmierbaren Takt-Generator


    Umsetzung
    Die aktuelle Umsetzung besteht aus mehreren Teilen. Ein PIF-Interface-Board, mit FPGA und einen programmierbaren Taktgenerator wird auf eine Adapterplatinen mit Aufstecksockel gesteckt.



    Die Adapterplatine wird per Half-Cut-Vias auf die Pins des PIF gelötet. Dort befinden sich noch Lötpads für Video- und Audiotakt, ein "Controller 1"-Pin (später dazu mehr) und eine RGB-LED.




    Das Controller-Board mit MCU und den Nutzerschnittstellen wie µSD-Card, USB und Bluetooth 4.1. SD-Card und USB sind dabei über senkrecht aufgelötete Platinen zu den Kühlschlitzen des N64 geführt. Interface und Controller-Board sind über eine SPI-Schnittstelle per Flexkabel verbunden.


    Das RGB-LED-Board ist das I-Tüpfelchen und kann als Ersatz der N64 Power-LED eingebaut werden, um dem Nutzer Feedback zu geben oder einfach nur cool auszusehen.



    So ist alles Verbunden:



    Probleme / Fehler
    Diese Version ist die erste Rev., welche natürlich vor allem einem Zweck dient: Fails zu beseitigen. Davon gab es auch einige. (Lösungsansatz in Klammern)
    • Schwerwiegendstes Problem: Fehler in der Steckerbelegung zwischen Controller-Board und Interface-Board (gelöst in nächster Rev.)
    • USB-Platine ist nicht sehr stabil (nächste Rev. bekommt mehr Lötverbindungen)
    • SD-Card passt nicht ganz (entweder anpassen oder feilen)
    • Aufstecksockel ist sehr empfindlich (vorsichtiger sein)
    • Interface-Bord stößt an Elkos an (Adapterplatine dicker machen, bis Interface wenigstens gerade aufliegt)
    • Flexkabel ist etwas unflexibel, es muss um 90° geknickt werden, könnte dabei brechen (???)
    • Buchsen für Flexkabel sind hitzeempfindlich beim Löten (mehr Abstand zu Bauteilen in nächster Rev.)


    Weitere Hürden
    • die PIF-ROMs unterliegen evtl. Copyrights (eigenes N64-MIPS-Boot-Rom schreiben, das irgendwie anderes ist, als das jetzt :s000: )


    Getestete Features
    Trotz der Fehler konnte ich einige Features bereits testen und in den Prototyp implementieren.
    • Kommunikation mit RCP
    • SPI-Kommunikation zwischen MCU und FPGA
    • Bereitstellung eines austauschbarem PIF-ROMs, je nach CIC-Region
    • Boot des N64, Bereitstellung CIC-Seed, Prüfung der Checksum
    • Erzeugen des Video-Clocks mittels Taktgenerator / Switch je nach CIC-Region
    • Ansteuerung der SI-Peripherie des N64 (Controller inkl. ControllerPak / RumblePak, EEPROM, CIC)
    • Emulation ControllerPak und EEPROM im RAM des MCU
    • Benutzen eines USB-Controllers (Test mit Logitech Rumblepad 2)


    Noch offene Tests
    • Laden / Speichern ControllerPak + EEPROM auf SD-Card
    • Bluettooth
    • RTC-Emulation
    • ...


    Weitere Ideen
    Hier einige Ideen für die Zukunft. Ihr dürft gerne weitere Vorschläge äußern, um die Liste zu erweitern ^^

    Bluetooth-Controller
    Ich hatte letztes Jahr schon einmal mit einem Wireless Adapter für N64-Controller begonnen. Dieser müsste allerdings nochmal überarbeitet und fertiggestellt werden. Damit kann man einen N64-Controller ohne Modifikation verwenden. Allerdings braucht man pro Controller 2 Platinen (Controller-Adapter und Console-Adapter). Damit kommt man auf ca. 60 € je Controller. Das erschien mir etwas teuer. Mit dem UltraPIF braucht man nur noch je einen Controller-Adapter für knapp 20 €. Voraussetzung ist aber, dass das verwendete Bluetooth-Modul als Central gleichzeitig mit 4 Peripherials verbunden sein kann. Das habe ich noch nicht getestet. (Das RN4020, welches auch für den Wireless-Adapter verwendet hatte, konnte das leider nicht.)

    Controller-1-Pin
    Wenn man USB oder Bluetooth-Controller verwendet, können einige andere Mods (darunter auch das UltraHDMI), die das Signal des ersten Controllers benötigen, nicht mehr damit arbeiten. Meine Lösung: Ein extra Pin simuliert die Abfrage und Antwort des Controllers. Die Mods werden dann an dieses Lötpad angeschlossen.

    UltraPIF Light
    Wenn es mir gelingt, die minimale Funktionalität komplett in den FPGA zu bringen, wäre es möglich, die reine Multi-Region-Geschichte in das Interface-Board zu bringen und somit das Controller-Boards einzusparen. Manch einen reicht das bestimmt schon und das wäre dann auch recht günstig.

    Umschaltung Emulation ControllerPak / RumblePak
    Wenn das ControllerPak emuliert wird, muss es eine Möglichkeit geben, im Spiel auf das RumblePak umzuschalten.

    Interface für Everdrive64 / 64drive
    Das volle Potential könnte man vermutlich ausschöpfen, wenn man den UltraPIF zusammen mit einer Backup-Unit einsetzt. Dafür muss noch ein Interface entwickelt werden. Das ist rein Software und läuft über den PIF-RAM. Und natürlich müssen die anderen Programmierer Bock darauf haben, den UltraPIF zu supporten.

    Technische Details
    Hier ein paar Daten. Fragt, wenn ihr noch was wissen wollt.

    FPGA: Lattice MachXO2 LCMXO2-2000HC-4TG100C
    • läuft mit einer einzigen Spannung (3,3 V)
    • interner Flash (Config und Nutzerdaten)
    • interner Oszillator
    • 2112 LUTs
    • 74 kBits BRAM
    • TQFP100, 79 IOs
    • Hardended Control Functions (SPI, I2C, ...)


    Clockgen: SI5351A-B-GTR
    • 3 Ausgänge -> Video-Clock, Audio-Clock und bisher nicht benötigter FPGA-Clock
    • 2 PLLs, 3 "MultiSynth"
    • max. 200 MHz
    • I2C-Interface


    MCU: STM32F413RGT6
    • max. 100 MHz
    • 1 MByte Flash
    • 320 kByte SRAM
    • USB-Host / Device
    • SDIO
    • RTC


    Bluetooth: SPBTLE-RF
    • Bluetooth 4.1
    • Integrierter BT-Stack
    • SPI-Interface


    Ich bin mir noch nicht ganz sicher, in welcher Form ich das Projekt irgendwann anbieten könnte. Selber fertig Löten ist zu viel Arbeit. Also müsste man das irgendwo herstellen lassen oder als Bausatz liefern (es sind einige sehr kleine Sachen zu löten). Oder gar nur als Quellen zum Selbermachen.

    So, nun seid ihr gefragt. Interessiert euch der UltraPIF oder nicht? Habt ihr Vorschläge für Features? Würdet ihr sogar Teile mit entwickeln wollen? Ich hab z.B. kaum Ahnung von MIPS-Assembler und sehe daher noch keine Lösung, ein eigenes Bootrom zu schreiben. Hab ihr sonst noch Fragen/Anmerkungen/Kritik?

    Viele Grüße,
    jago85

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von jago85 ()

  • Hey Jago,

    erst einmal WOW und vielen Dank für diese bisherige Arbeit. Das sieht sehr gut und vielversprechend aus :thumbup:

    Ich denke, du kannst damit großes bewirken. Falls du dich noch an meine kryptischen Fragen aus dem anderen Beitrag erinnerst, darauf wollte ich hinaus:


    jago85 schrieb:

    Möglicher Nutzen eines PIF-Replacements


    Booten von PAL- und NTSC-Games

    Einspielen eines Custom-Boot-ROMs

    CIC in Backup-Units ist nicht mehr notwendig (Backup-Unit kann den gewünschten CIC auswählen)


    jago85 schrieb:

    UltraPIF Light
    Wenn es mir gelingt, die minimale Funktionalität komplett in den FPGA zu bringen, wäre es möglich, die reine Multi-Region-Geschichte in das Interface-Board zu bringen und somit das Controller-Boards einzusparen. Manch einen reicht das bestimmt schon und das wäre dann auch recht günstig.

    Und genau hier sehe ich das größte Potential. Die anderen Features sind zwar richtig genial, doch denke ich, dass der "Otto-Normal"-Spieler/Modder am liebsten ein ähnliches Paket, wie beim SNES haben möchte. Damit meine ich RGB und Regionenfreiheit!

    Zusammengefasst:
    Klasse Arbeit, ich verfolge das gern mit großem Interesse. Mach weiter so! :thumbup:

    LG Thara


    Ach ja (keine Sorge das ist Spinnerei/Zukunftsmusik):Vielleicht lässt sich irgendwann in Kooperation mit anderen schlauen Köpfen eine Regionfree-RGB_YPbPr-Ultra-Platine realisieren :whistling:
    The New Retro Discord - Ein Platz zum Quatschen + Support von Retromods, Konsolen uvm:
    discord.gg/TYRYdXsBxr
  • Ich denke auch, dass eine Lite-Version für viele ausreichen würde, inkl vernünftiger Takteinstellung.
    Bluetooth und USB-Gamepad sind sicherlich nice to have aber bzgl. der Zusatzfeatures ist wohl am interessantesten:
    - die MEMPAK-Simulation, da manche Spiele extrem viele Slots brauchen und auch für den Batterietausch. -war eines der ersten Features nach dem die Flashcartnutzer geschrien haben
    - die Möglichkeit Spielstände auf dem Computer zu sichern und 100% Saves zu importieren
    (- evtl. eine Transferpak-Simulation, da kaum einer für PKMS(2) 4 Transferpaks hat) klingt nach Firmwareupdate
    (- evtl. die Möglichkeit über SD/USB Gameboy-Spielstände ohne Flashcart direkt zu dumpen/schreiben mittels echtem Transferpak) klingt nach Firmwareupdate

    Die RTC ist eigentlich nur für Flashcartnutzer interessant und für das Dateisystem auf der SD-Karte.

    Was ich mir auch vorstellen könnte wäre ein 50/60Hz GND/VCC Pin um den MAV-NUS auf NTSC/MPAL(PAL zu stellen je nach Bedarf.
    Kann man sich ja sparen zu verbinden bei RGB-Mods.
    Circuit-Board Passwort-Gate - Februar 2014 - Ich war dabei
    Circuit-Board SessionID-Gate - August 2014 - Ich war dabei
  • Tja was könnte ich sinnvolles beitragen.

    Ich könnte das ED64 OS anpassen, um über den PIF-RAM das Ding zu Steuern.
    Vielleicht wäre auch eine Standalone Homebrew auf einer dieser Repo-Flashcarts interessant.
    Ich könnte auch eine passende BT-Android-APP programmieren oder einen USB-Desktop-Client.
    Ist natürlich alles nicht so einfach, solange es noch keine finale Hardware gibt.
    Circuit-Board Passwort-Gate - Februar 2014 - Ich war dabei
    Circuit-Board SessionID-Gate - August 2014 - Ich war dabei
  • Danke für die ersten Feedbacks. Freut mich sehr, dass es bisher so gut ankommt.


    tharathiel schrieb:

    Damit meine ich RGB und Regionenfreiheit!

    saturnu schrieb:

    Ich denke auch, dass eine Lite-Version für viele ausreichen würde, inkl vernünftiger Takteinstellung.
    Ok, das ist ein interessanter Punkt. Ich könnte mich auch erstmal darauf konzentrieren. Da wäre auch eine erste präsentierfähige Version eher in greifbarer Nähe als mit den ganzen Zusatzfeatures. Ich bin noch ganz zuversichtlich, dass das in den FPGA passen könnte. Dafür könnte man sogar die Rev.1 nehmen, weil die Probleme erst beim Stecker zum Controller-Board anfangen. Und wenn es wirklich nicht passt, kommt halt noch ein Board mit Spartan6 oder integriertem STM32.

    tharathiel schrieb:

    Ach ja (keine Sorge das ist Spinnerei/Zukunftsmusik):Vielleicht lässt sich irgendwann in Kooperation mit anderen schlauen Köpfen eine Regionfree-RGB_YPbPr-Ultra-Platine realisieren
    Und integrierter Backup-Unit :thumbup:

    saturnu schrieb:

    - die Möglichkeit Spielstände auf dem Computer zu sichern und 100% Saves zu importieren
    Gibt es eigentlich Tools, wo man sich den Inhalt von ControllerPaks neu zusammenstellen kann? Das ist doch ne Art einfaches Dateisystem. Hast doch bestimmt schon jemand erforscht oder? ^^

    saturnu schrieb:

    (- evtl. eine Transferpak-Simulation, da kaum einer für PKMS(2) 4 Transferpaks hat) klingt nach Firmwareupdate
    (- evtl. die Möglichkeit über SD/USB Gameboy-Spielstände ohne Flashcart direkt zu dumpen/schreiben mittels echtem Transferpak) klingt nach Firmwareupdate
    Klingt machbar. DIe Gameboy-ROMS und Savegames können auf der SD-Card liegen. Ich hab kein TransferPak. Aber das kann man mit im Hinterkopf behalten. Für das Dumpen ohne Flashcart frage ich mich nur gerade, wie man das triggert. Gut, man könnte das am Vorhandensein eines TransferPaks inkl. Game erkennen und anfangen zu dumpen.

    saturnu schrieb:

    Was ich mir auch vorstellen könnte wäre ein 50/60Hz GND/VCC Pin um den MAV-NUS auf NTSC/MPAL(PAL zu stellen je nach Bedarf.
    OK, das kannte ich noch nicht. Ich werde versuchen, noch ein Pad auf den Adapter zu bringen.

    productof76 schrieb:

    ...btw. es gibt ja die n64 wireless controller von 8-bitdo aber leider (noch) keinen passenden bluetooth-receiver für das n64.
    Wenn die Bluetooth 4.1 sind, ist es evtl. möglich. Ansonsten wahrscheinlich nicht.
  • jago85 schrieb:

    Gibt es eigentlich Tools, wo man sich den Inhalt von ControllerPaks neu zusammenstellen kann?
    Gibt's sogar online. ^^
    rawgit.com/bryc/mempak/master/index.html

    Offline fällt mir nur das nrage Controller-Plugin für Project64 ein, da gibt's in den Optionen dann eine Funktionalität MEMPAKs zu editieren. :s000:
    Circuit-Board Passwort-Gate - Februar 2014 - Ich war dabei
    Circuit-Board SessionID-Gate - August 2014 - Ich war dabei
  • saturnu schrieb:

    Ist natürlich alles nicht so einfach, solange es noch keine finale Hardware gibt.
    Das stimmt. Vielen Dank für das Angebot. Darauf komme ich gern zurück.

    saturnu schrieb:

    Ich könnte das ED64 OS anpassen, um über den PIF-RAM das Ding zu Steuern
    Das klingt nice. Da kannst ja mal überlegen, welche Befehle man braucht und wie die aussehen sollen. Die müssten sich ja irgendwie von den normalen Befehlen unterscheiden und möglichst nicht kollidieren. Entweder eine Magic Number am Anfang, die mit 0xfe anfängt oder letztes Byte mit einem Wert, der bisher keine Bedeutung hat.

    saturnu schrieb:

    Vielleicht wäre auch eine Standalone Homebrew auf einer dieser Repo-Flashcarts interessant.
    Das musst du mal genauer erklären ^^
  • Nuja, ich könnte mir vorstellen, so eine Interface Cartridge zu haben, mit der man z.B. einen Blick auf die SD-Karte werfen kann, die Uhrzeit einstellen, BT on/off, Firmwareversion überprüfen oder auch GB-Spiele dumpen.
    Wie du ja eben angemerkt hast, müsste man ja ansonsten alles über Tastenkombinationen triggern. ^^
    Eigentlich Sachen die man auch über USB machen könnte, allerdings hat nicht jeder in seinem Wohnzimmer gleich ein Notebook zur Hand.
    Circuit-Board Passwort-Gate - Februar 2014 - Ich war dabei
    Circuit-Board SessionID-Gate - August 2014 - Ich war dabei
  • Ich hätte grundsätzlich Interesse, auch wenn ich die meisten Funktionen gar nicht nutzen würde. Ich möchte einfach nur mit meiner Flashcard NTSC ROMs mit richtiger Audio-Geschwindigkeit spielen können.
  • gmipf schrieb:

    auch wenn ich die meisten Funktionen gar nicht nutzen würde
    Danke für dein Feedback. Ich beschäftige mich momentan damit, die Lite-Version nur mittels des kleinen FPGA auf dem PIF-Interface-Board umzusetzen. Das wird für Leute, die die Zusatzfeatures nicht brauchen deutlich günstiger sein.
  • schön und gut aber solange man dann nicht auch eine automatisierung der Quarze einbaut wird das nicht viel bringen wenn man ein spiel spielen will z.B. NTSC Spiel auf PAL gerät was mehr als 240p hat genau so anders herum wenn ein PAL Spiel mit mehr als 288p auf ein NTSC gerät läuft

    240/288P schaffen die zwar dann ohne mod aber alles dadrüber macht dann sonst Probleme im sinne das dann das Bild immer wieder Aussetzer hat oder gar kein bild mehr kommt

    Für ein richtigen Regionfree Mod müsste also wie erwähnt ein Quarz Switcher mit automatisiert werden
    Nintendo Switch Freundescode: SW-5492-6586-3115

    https://www.meine-dvd-collection.net/

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

  • Jab, genau deshalb ist auf dem Board ja der Clock Generator verbaut. Und je nachdem welche Region der CIC ausgibt, wird der Takt automatisch angepasst. Das könnte man noch per Schalter forcen oder bei Everdrive via Befehl vorgeben.
  • Für mich wäre noch Interessant PAL ROMs als NTSC in 60 Hz spielen zu können. Einige deutsche PAL ROMs, die keine 50Hz Anpassung haben, würde ich nämlich gerne in voller Geschwindigkeit spielen können. Ich denke aber dass irgendwie der ROM Header beim Starten geprüft und modifiziert werden müssen im RAM und dies somit zu kompliziert wäre wahrscheinlich.
  • Vielleicht wäre es auch möglich bei Spielen die Pal Balken haben diese auf Ntsc Auflösung zu forcen.
    Oder vielleicht sogar highres/lowres forcen, falls die Spiele sowas überhaupt mitmachen.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von F_L_a_S_H ()

  • Killertamagotchi schrieb:

    schön und gut aber solange man dann nicht auch eine automatisierung der Quarze einbaut wird das nicht viel bringen wenn man ein spiel spielen will z.B. NTSC Spiel auf PAL gerät was mehr als 240p hat genau so anders herum wenn ein PAL Spiel mit mehr als 288p auf ein NTSC gerät läuft


    [...]


    Für ein richtigen Regionfree Mod müsste also wie erwähnt ein Quarz Switcher mit automatisiert werden

    jago85 schrieb:

    Jab, genau deshalb ist auf dem Board ja der Clock Generator verbaut. Und je nachdem welche Region der CIC ausgibt, wird der Takt automatisch angepasst. Das könnte man noch per Schalter forcen oder bei Everdrive via Befehl vorgeben.

    Zu dem Thema möchte ich mal meine Erfahrung mit einwerfen. Ich hatte mich vor einiger Zeit damit beschäftigt, per DFO die Frequenz und den Multiplikator am MX8330 entsprechend nach 50Hz oder 60Hz Ausgabe umzuschalten.
    Ergebnis war, dass das N64 zu 90% abschmierte, sobald man umgeschaltet hat. Audio lief weiter, das Bild war weg.

    Das ganze war Microcontroller gesteuert. Wenn ich initial NTSC angenommen habe und ein PAL Spiel eingelegt habe, reichte das schon aus, dass das Bild schon gar nicht mehr erschien. Andersherum genauso.

    Gelandet bin ich daher bei einer Schalterlösung, wo man zwischen zwei Quarzen gewechselt hat (mit einsprecheder Beschaltung des Multiplikator-Auswahlpins am MX8330.
    Die Frequenz musste VOR dem einschalten der Konsole feststehen. Ein Wechsel im laufenden Betrieb kann zu Problemen führen.

    So zumindest meine Erfahrung.

    Killertamagotchi schrieb:

    240/288P schaffen die zwar dann ohne mod aber alles dadrüber macht dann sonst Probleme im sinne das dann das Bild immer wieder Aussetzer hat oder gar kein bild mehr kommt
    Magst du das mal erläutern!? ?(
    Ich selber habe noch nie Bildaussetzer gehabt, wenn ich n auf ner PAL Konsole n NTSC Spiel gespielt habe oder anders herum - weder in 240p/288p, noch in 480i/576i.
    Bevor ich meine japanische Konsole hatte, habe ich fast ausschließlich NTSC ROMs über das ED64 gezockt. Und auch in letzter Zeit habe ich viel zu Testzwecken ROMs der vermeitlich falschen Region gespielt - sowohl auf der japanischen als auch auf meiner PAL Konsole.


    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
  • @borti4938 Danke, für die Infos. Einige Sachen hab ich auch so festgestellt. Kann leider erst nach Feierabend vernünftig antworten. Weiß auch nicht, ob ich heute dazu komme.

    Mit welchem N64-Board hast du das getestet?

    Hast du den DFO als Quarz an den MX8330 geschaltet oder den MX8330 ersetzt?

    Kann sich das FSEL-Signal am MX8330 denn überhaupt ändern? Ich ging bisher davon aus, dass das je nach Region hart gesetzt ist und somit an FSO/5, was zum RCP und Videoencoder geht, bei einer normalen Konsole konstant ist und vom Spiel nicht beeinflusst werden kann. Bei NTSC-Konsolen sind das immer 17 * 4 * 3,579545 / 5 = 48,681812 MHz und bei PAL 14 * 4 * 4,43361875 / 5= 49,65653 MHz. Ich hab den Schaltplan jetzt nicht dabei, aber FSel ist glaub ich nicht am RCP. Das, was die Spiele umschalten, geht über die VI Register. Der MX bleibt dabei bei seiner Frequenz.
  • Ich habe in einer japanischen Konsole und in einer PAL Konsole getestet.

    Ich habe den Videoausgang genommen und dort detektiert, ob VSYNC 60Hz oder 50Hz hat. Damit habe ich
    a) OSCIN am MX8330 zwischen 4 x 3,579545 MHz und 4 x 4,43361875 MHz und
    b) FSEL am MX8330 zwischen 0 und 1 gewechselt.

    Es ging also darum, je nach VI Setting extern die passende Freqeunz FSO/5 und FSC noch einzustellen. Leider nicht ganz so geklappt, wie ich wollte.


    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
  • gmipf schrieb:

    Für mich wäre noch Interessant PAL ROMs als NTSC in 60 Hz spielen zu können.
    Also dafür müsste man wohl was am ROM ändern. Die PAL-Spiele erzeugen ihre Bildwiederholrate, wie @F_L_a_S_H schon geschrieben hat, durch bestimmte VI Settings. Das hängt nicht nur vom externen Takt ab. Bei den NTSC-Konsolen ist der externe Takt sogar ca. 2 % langsamer. Da würde ein PAL-Spiel eher langsamer laufen und der Audiotakt stimmt auch nicht. Ob man das mit wenigen Änderungen Patchen könnte - keine Ahnung. Mit dem UltraPIF Lite machst du nur eine Konsole zwischen NTSC und PAL umschaltbar. Und da macht es, denke ich, ohne Patches nur Sinn, die Region zu benutzen, zu der das Spiel gehört.

    borti4938 schrieb:

    Ergebnis war, dass das N64 zu 90% abschmierte, sobald man umgeschaltet hat. Audio lief weiter, das Bild war weg.
    Das war bei mir auch so. Im Betrieb umschalten ist nicht. Aber wenn man der PIF ist, kann man ein Reset triggern, nachdem man alles angepasst hat oder das System im Reset halten, während man etwas ändert.

    borti4938 schrieb:

    Wenn ich initial NTSC angenommen habe und ein PAL Spiel eingelegt habe
    Und wenn du die 4 x 3,579545 MHz angelegt hast und ein NTSC-Spiel hattest, läuft das?

    borti4938 schrieb:

    Gelandet bin ich daher bei einer Schalterlösung, wo man zwischen zwei Quarzen gewechselt hat
    OK, schon mal gut, dass das überhaupt funktioniert. Die Leitungen sollten ja eigentlich so kurz wie möglich sein.

    borti4938 schrieb:

    Ich habe den Videoausgang genommen und dort detektiert, ob VSYNC 60Hz oder 50Hz hat. Damit habe ich
    a) OSCIN am MX8330 zwischen 4 x 3,579545 MHz und 4 x 4,43361875 MHz und
    b) FSEL am MX8330 zwischen 0 und 1 gewechselt.
    OK, verstehe. Also ich habe auch erst versucht, den MX anzusteuern. Aber ich glaube der mag den Taktgenerator nicht und rastet nicht ein. Der will ja eigentlich nen Quarz sehen und im Datenblatt steht auch nicht, dass man den mit einem externen Takt betreiben kann. Deswegen war ich etwas verwundert, dass da bei dir überhaupt was ging. Bei mir kam nur Murks aus dem MX mit externen Takt.

    Daher lasse ich den MX8330 einfach ganz weg. Bei Konsolen mit MX8350 müsste man die entsprechenden Pins anheben. Du müsstest also FSO/5 und FSC erzeugen, wobei du FSC oft nichts brauchst. Kannst du ja mal probieren, wenn du Lust hast. Wenn du deinen Takt angepasst hast, kannst du mal versuchen, PIF_EN (Pin 8) kurz auf Low zu ziehen. Hab das grad paar mal gemacht, aber ohne Clock Umschaltung, weil ich die grad nicht dran habe. Das N64 mach jedes Mal einen Neustart. Evtl. kannst du mit deinem MCU ja auch noch COLD_RESET (Pin 6) auf low ziehen. Ich sehe gerade, wenn am EN auf low zieht, geht COLD_RESSET mit auf low.

    borti4938 schrieb:

    Magst du das mal erläutern!?
    Ich selber habe noch nie Bildaussetzer gehabt
    Ich konnte da auch nicht ganz folgen. Wenn ichs verstehe, kann ich es gern mal ausprobieren. Ich sollte vielleicht dazu sagen, das ich eigentlich immer mit einem N64 mit RGB-Mod teste. Den normalen Composite hab ich deaktiviert. Ich weiß also nicht, ob es da Probleme geben könnte. Kommt sicher auch auf den TV an.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von jago85 ()

  • jago85 schrieb:

    Das war bei mir auch so. Im Betrieb umschalten ist nicht. Aber wenn man der PIF ist, kann man ein Reset triggern, nachdem man alles angepasst hat oder das System im Reset halten, während man etwas ändert.

    [...]

    Wenn du deinen Takt angepasst hast, kannst du mal versuchen, PIF_EN (Pin 8 ) kurz auf Low zu ziehen. Hab das grad paar mal gemacht, aber ohne Clock Umschaltung, weil ich die grad nicht dran habe. Das N64 mach jedes Mal einen Neustart. Evtl. kannst du mit deinem MCU ja auch noch COLD_RESET (Pin 6) auf low ziehen. Ich sehe gerade, wenn am EN auf low zieht, geht COLD_RESSET mit auf low.
    Idee hat ein Problem: man kriegt beim Everdrive 64 dann keine ROM mehr gestartet, wenn der Takt dazu umgeschaltet werden muss. Mit einem Reset kommst du ins Menü zurück.

    jago85 schrieb:

    OK, schon mal gut, dass das überhaupt funktioniert. Die Leitungen sollten ja eigentlich so kurz wie möglich sein.
    Quarzschaltung ist digital umgeschaltet, sodass du Quarze direkt am MX platziert werden konnten. ;)

    jago85 schrieb:

    OK, verstehe. Also ich habe auch erst versucht, den MX anzusteuern. Aber ich glaube der mag den Taktgenerator nicht und rastet nicht ein. Der will ja eigentlich nen Quarz sehen und im Datenblatt steht auch nicht, dass man den mit einem externen Takt betreiben kann. Deswegen war ich etwas verwundert, dass da bei dir überhaupt was ging. Bei mir kam nur Murks aus dem MX mit externen Takt.
    Du muss beide Pins zu OSCIN und OSCOUT anheben ODER die Kapazitäten, die noch daran hängen, anheben. Den 'originalen' Quarz zu entfernen reicht da nicht. Dann geht das auch über den MX8330.


    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
  • borti4938 schrieb:

    man kriegt beim Everdrive 64 dann keine ROM mehr gestartet
    Hm, schade. Gibt es da eine Option, nicht ins Menü sondern ins Spiel zu resetten? Oder setzt das COLD_RESET auch das ED komplett zurück und überschreibt die Option? (Ich hab leider kein ED.) Mit originalen Carts müsste es aber gehen.

    Ich nehme mal an, wenn das ED neu startet, erkennt deine Schaltung wieder 50 Hz und schaltet zurück auf PAL.

    Ich denke aber, dass so eine Funktion ins ED implementiert werden könnte.

    borti4938 schrieb:

    Quarzschaltung ist digital umgeschaltet, sodass du Quarze direkt am MX platziert werden konnten.
    Sehr schön :thumbsup:

    borti4938 schrieb:

    Du muss beide Pins zu OSCIN und OSCOUT anheben ODER die Kapazitäten, die noch daran hängen, anheben. Den 'originalen' Quarz zu entfernen reicht da nicht. Dann geht das auch über den MX8330.
    Danke für die Info. Ich hatte tatsächlich nur den Quarz entfernt. Werd ich bei Gelegenheit mal testen, wobei ich das eigentlich nicht mehr brauche. Wäre jedoch eleganter, bei allen Revisionen nur einen Takt vom UltraPIF zu ziehen, der auch noch eine niedrigere Frequenz hat. Ich frag mich aber, wieso das dann bei dir nicht lief.
  • Bei den Flashcarts/Copiers ist es ja so, dass es eine ganze Menge verschiedenster Modelle gibt.

    64drive
    64drive II
    ED64v1 (ED64 plus)
    ED64v2
    ED64v2.5
    ED64v3
    Neo Myth 64
    Dr. V64
    Dr. V64 Jr.
    CD64
    Mr. Backup Z64
    Wildcard 64
    usw.

    Theoretisch passiert auch gar nicht so viel, falls man ein PAL N64 mit ED64 resettet und z.B. in 60Hz anstatt 50Hz startet.
    Dann wird bei manchen Versionen der Flashcart der Speicher auf die SD-Karte geschrieben und man kann nun NTSC-Spiele starten, bis man wieder zu PAL-Spielen wechselt.
    Wenn ich mich richtig erinnere gibt’s beim ED64 sogar ein Register-Setting, welches verhindert, dass nach einem Reset wieder der Bootloader gemappt wird.
    Dies wäre dann allerdings auch nicht universell für alle Flashcarts/Copier möglich.

    Kurz gesagt, wenn das N64 den Wechsel -on the Fly- nicht übersteht - kommt man ja eh nicht um den Reset herum.
    Circuit-Board Passwort-Gate - Februar 2014 - Ich war dabei
    Circuit-Board SessionID-Gate - August 2014 - Ich war dabei
  • saturnu schrieb:

    Bei den Flashcarts/Copiers ist es ja so, dass es eine ganze Menge verschiedenster Modelle gibt.
    Wenn ein oder zwei davon was von mir supporten würden, wäre das ja schon ne feine Sache. ^^

    Für die anderen kann man ja die manuelle Vorgabe nutzen.

    saturnu schrieb:

    Theoretisch passiert auch gar nicht so viel, falls man ein PAL N64 mit ED64 resettet und z.B. in 60Hz anstatt 50Hz startet.
    Solange das ED64 nach dem Reset aufgrund des PAL PIFROMs nicht wieder auf 50 Hz geht, würde das ja klappen.
  • Es stimmt, dass das Menu wieder in 50Hz läuft nach einem Reset in einem 60Hz Spiel (auf einer PAL-Konsole).
    Kann man denn nicht auch einfach gleichzeitig das PIF-ROM tauschen?
    Dann würde die PIF-Simulation beim erneuten Start eines Roms, nichts im TyType-Register verstellen müssen.

    Ich könnte mich anbieten das ED64-Menu so zu verändern, dass falls eine Hz-Änderung ansteht, es diese durchführt und nach dem Reset gleich das Spiel startet.
    Der Nutzer sollte dann gar nichts davon sehen. Spürbar wäre nur eine geringe Verzögerung, falls man die Region wechselt.


    Interessant wäre evtl. auch ein PIF-RAM-Interface, damit man dem UltraPIF direkt instruieren kann welches PIF-ROM geladen werden soll.
    Es gibt ja neben PAL und NTSC auch noch PAL-M am N64. (und eine Flashcart hat ja evtl. nur einen festen CIC)

    PAL-M unterscheidet sich ja nur durch die VI-Settings und nicht durch einen eigenen CIC, wie will man so die Spiele richtig erkennen seitens des PIF.
    Generell ist ja auch die Annahme nicht korrekt, dass ein NTSC Spiel die Konsole auf jeden Fall auf 60Hz einstellt.
    Es ist durchaus möglich, dass ein NTSC-Spiel dank PAL-TypType-Setting auf 50Hz anläuft, um z.B. eine saubere Regionsfehlermeldung darzustellen.

    Kurz und knapp, man muss den UltraCIC manchmal auf ein PIF-Rom pinnen können.
    Noch besser sogar auch via PIF-RAM, damit man das leichter bei einer Flashcart automatisieren kann.
    Circuit-Board Passwort-Gate - Februar 2014 - Ich war dabei
    Circuit-Board SessionID-Gate - August 2014 - Ich war dabei
  • Interessantes Projekt. Irgendwie finde ich die Idee die microSD Karte durch eines der Lüftungsschlitze zugänglich zu machen mega genial.
    Bin sehr gespannt wie sich das entwickelt. Tolle Arbeit @jago85
    Interesse hätte ich auf jeden fall daran.
    [+ ..]