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.
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:
Möglicher Nutzen eines PIF-Replacements
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)
Weitere Hürden
Getestete Features
Trotz der Fehler konnte ich einige Features bereits testen und in den Prototyp implementieren.
Noch offene Tests
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
Clockgen: SI5351A-B-GTR
MCU: STM32F413RGT6
Bluetooth: SPBTLE-RF
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
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.
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 )
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 ()