Worum geht es?

Was könnte man nun damit machen?

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)



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

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



die PIF-ROMs unterliegen evtl. Copyrights (eigenes N64-MIPS-Boot-Rom schreiben, das irgendwie anderes ist, als das jetzt )



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)



Laden / Speichern ControllerPak + EEPROM auf SD-Card



Bluettooth



RTC-Emulation



...



Weitere Ideen

Technische Details

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, ...)



3 Ausgänge -> Video-Clock, Audio-Clock und bisher nicht benötigter FPGA-Clock



2 PLLs, 3 "MultiSynth"



max. 200 MHz



I2C-Interface



max. 100 MHz



1 MByte Flash



320 kByte SRAM



USB-Host / Device



SDIO



RTC



Bluetooth 4.1



Integrierter BT-Stack



SPI-Interface



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.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.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:Möglicher Nutzen eines PIF-ReplacementsDie 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: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)Trotz der Fehler konnte ich einige Features bereits testen und in den Prototyp implementieren.Noch offene TestsHier einige Ideen für die Zukunft. Ihr dürft gerne weitere Vorschläge äußern, um die Liste zu erweiternIch 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-ControllerModifikation 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.)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.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.Wenn das ControllerPak emuliert wird, muss es eine Möglichkeit geben, im Spiel auf das RumblePak umzuschalten.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.Hier ein paar Daten. Fragt, wenn ihr noch was wissen wollt.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