darthcloud
Gitches on Nintendo 64 with N64 Digital while using Controller/Rumble Pak / F-Zero
I’ve enabled the controller pak manager through the web interface and formatted it but a number of games prompt that there is a problem with the pak on launch. One example is Tony Hawk Pro Skater 1. As a separate issue, F-Zero does not detect the blueretro device as a controller.
Console is modded with N64 digital and using latest version of the blueretro firmware. Unrelated, but with two NSO 64 controllers the number returned from the controller test tool for the right axis seems to be a bit higher than the benchmark. What setting in the advanced config should I adjust? Two different NSO 64 controllers return different values on the test tool, so there must be some variance at the factory with those sticks.
Try to format via a laptop if you used a phone, or just let tony hawk format it when prompted.
If detection fail you can simply press reset on console, some games give up too fast.
Play with the LX, RX maximum value in web config to fine tune joystick.
IMHO this is a waste of time, that test tool make people paranoid. Most games are programmed with a good play room.
Thanks for replying! I've tried the suggestions but F-Zero does not work at all with a blueretro device and Tony Hawk will not recognize the controller pak. Testing a random sample of other controller pak games shows a major issue with the current integration. I've also experienced odd rumble behavior. On Goldeney 007, the rumble will not work correctly when firing. It gives a brief rumble and then stops when firing, when it should continue to rumble when firing. This is a great product, and hopefully you'll be able to circle back around to the N64 to finish polishing the feature set. Thank you!
You might have some build related issues because I personally got none of those issues.
Sound like your data line is glitching somehow.
This was confirmed from others using the adapter purchased from Tindie so it is likely the build. I’ll follow up with the seller.
If you can ask others to report feedback in this GitHub issues.
Everyone with issue should list the following information if possible:
- N64 motherboard revision
- List of internal mods installed
- Other external peripheral used
It could be problem with the dongle itself but it could also be some interoperability issue with some motherboard or some other mods.
I had mempak issues myself before, but they were resolved when I used a PC instead of a phone to change the config. These issues occured both on my adaptor as well as on an ESP32 Devkit which I used to compare functionality. Regarding the other issues, both with a ESP32 Devkit as well as my own Adaptors I had sporadic rumble issues, close to the ones that you described. Nothing gamebreaking though, the core functionality always worked. To be honest I always accepted it as minor issues in a great open source project, maybe depending on different controllers, console revisions and mods used. In the issues section on GitHub there are also several topics related to these small issues, so I did not look more into it and accepted it as small software bugs that don't really affect me.
Now of course I don't want to blame you @darthcloud for anything in your amazing project and I want to offer the most for everyone who bought my Adaptor, so I will look further into it.
Because I just moved last week, it will take more time than usual, I barely even have a TV set up at the moment, and my N64 consoles as well as the Adaptors are still in boxes.
I will try to get to it this weekend.
@bixxewoscht Anything is possible off course but the N64 is the original system BlueRetro was developed for and that I actually use myself a lot. I gone though GoldenEye a few time ever the last 3 years and never noticed any rumble issues. The way it is implemented makes the interface very robust as it is using the ESP RMT peripheral, (so no software bit bang). What you guys describe should not happen at all.
I'm using my own BlueRetro Devkit when playing but I did test with a few clone ESP-DevKit-C in December and this spring and didn't got any controller pak error myself. Controller pak was tested by going through Turok 1 and Tony Hawk 1.
The issue sound like the data line is glitching.
My own board got ESD protection on each line using a TPD6F002DSVR chip. This got an equivalent resistance of 100ohm. No idea if this help or not.
Maybe ship me one of your dongle for me to test.
I play with early N64 rev mostly but got a few more now that I could try on too. I got no mod in my console.
@Taurus1100 / @Taurus1099 I got your adapter today and made some quick test and it look to be working fine for me.
See video: https://youtu.be/IBnAhmHv9O8
I tested with your F-Zero X and TH1 cartridge with a NUS-CPU-04 and NUS-CPU-08-01 motherboards. Both work fine.
I got others N64 mobo in storage will dig them this weekend and report back.
Meanwhile can you confirm which mobo your N64 got? Did you install any mods? Are you using an original AC adapter?
Thanks for taking a look. My console revision is NUS-CPU-08-01 (modded with N64 Digital) and I'm using the original power supply. I also tested with an additional power supply and no change. When you are able to do further testing, are you able to get into a game on F-Zero? I've seen the game respond to controller inputs for 10-15 seconds but eventually it stops completely. The N64 Digital menu is still accessible however. Also, any issues with the rumble in Goldeneye?
I think its likely the N64 digital that interferes with the pad data lines. I can test more this weekend but its likely all fine.
I don't know much about N64 digital but I think you could remove the one connection for pad and it would likely work fine. But you would lose the OSD access.
Must be related to the N64 Digital. I noticed a similar issue on another open source project:
https://github.com/Ryzee119/usb64/issues/42
Edit: Tested using the second controller port and rumble/memory pak work great. Issues are limited to the first port only, so it must be something with the ability to pull up the OSD.
I tested with my N64 with N64 Digital and had the same issue with F-Zero. Could not test with my stock N64 yet. But in my other tests I remember there were no issues with the game on a stock N64.
Thank you both for investigating further.
This is untested but it change the data line from open-drain, to push-pull. Maybe that will help if the issue is on the TX side.
Everything is now working perfectly! The added ability to get vibration feedback on switching between rumble/memory pak is very helpful. Is there any functionality lost by changing the data line? Tagging bixxewoscht to let him know this looks to be resolved.
Hi @darthcloud, I'm the guy that slid into your DM's. Similar to the above user, I can confirm that the new firmware fixes all of the issues I was having. I played with it for quite a while today and exercised all of the main functionality and everything worked great. Thaks for finding a workaround so quickly... I was excited, then super bummed, and now excited again... this is a really neat implementation and will be my goto N64 setup going forward!
Just in case it is useful info for future reference, when I was having problems it was the following setup: NUS-CPU-08-01 with N64Digital mod stock PSU Switch Pro controller v1.5.1 of your firmware @bixxewoscht receiver
What was happening (this was only for P1 on my modded system; P2 worked fine and my stock NUS-CPU-08-01 worked fine) Controller pak emualation wasn't working at all (games either wouldn't recognize it or would report it corrupted) Every few seconds an uncommanded controller input [Dpad down + Dpad right + main joystick (1,-1)] would register
I can confirm this firmware seems to resolve the issues I was having on my n64digital console as well, both with F-Zero X and overall memory pak issues.
I got an N64 digital this week and was finally able to investigate first hand.
I wasn't really a fan of the workaround I made to fix it, the N64 SI is means to have device with open drain IO. So switching to push-pull is not really ideal IMHO.
This is really an issue caused by the N64 Digital mode and I think the fix should be an HW on it.
To fix it I added a 74AHCT125N buffer between the the PIF pin 16 and the N64D ribbon COM pad
This did the trick F-Zero X menu doesn't glitch with BlueRetro and the N64D OSD still work as before.
1 gate SMD variant:
4 gate DIP variant:
The best would be to design a ribbon with a pad for the tiny 1 gate variant 74AHCT1G125W5-7
Will you please leave the software fix in place for those of us without skills to mod our systems? I would have to pay for this work to be done :-(
Problem is this fix doesn't work for everybody, and it actually break it for some people without a N64D.
Old FW stay available so you can keep what you currently have, and if any major update occur I can always post a special version in this thread
Quick update PixelFX designed a small flex to fix this issue. I tested it and it work great.
I'll update this issue once info on how to get it is available.
@darthcloud Is this fix the same for both HW1 and HW2? ie for both external and internal (with detection) installs?
@darthcloud If I'm reading correctly, you prefer Dan's flex cable fix to your 74AHCT125N buffer method for electrical reasons?
Flex available here: https://www.pixelfx.co/n64digital-controller-flex-w-buffer.html
Hello there, is there also a fix planned for UltraHDMI users? I updated to the latest firmware and now the system does not detect the controller at all anymore
Yikes! I have just ordered one of the dev kit chip to do an internal install on my UltraHDMI modded N64. Has anyone reported a similar issue bundled with that mod? If so, a new flex cable will have to be developed, and as nice as Marshal is, he's only one guy and has a busy life. The chances of him developing one is slim, unless someone else steps in and develops one of their own. But again, has anyone with a UltraHDMI mod had this problem? Should this deveate into a different thread?
