F-Zero X (usa) controller 1 stops responding. N64Digital

[kimbapslice]

build-202012142305

USB64 + microsoft adapter + xbox360 controller/ps3+8bitdo/wired xbox360, n64digital 1.50.1/1.30.1 stable, 4MB RAM/jumper, just does not want to work with F-Zero X (usa). Game says either there's no controller or it would stop reading inputs after 20 seconds of the race. I can continue to navigate n64digital menu however. A stock n64 will work with the usb64.

Tested with original FZero X cart and everdrive 64. All other games seem to work perfectly.

So I connected 2 wireless xbox360 and started a 2 player vs in fzero x
Second controller continues to respond while controller 1 "stops" responding in game
but controller 1 can still bring up n64digital menu and soft reset shortcuts work.

Also, stock n64 controller works fine in all instances.

I am not sure if this is an N64Digital firmware issue, n64digital install issue, or USB64 firmware related. Thanks!

[Ryzee119]

Do you know if it works without the microsoft adaptor?
I have had issues mixing the wireless adaptor with other controllers before.

[kimbapslice]

I have tried with a wired xbox 360 controller and an 8bitdo adapter with ps3 sixaxis controller. Same result

[Ryzee119]

Unfortunately I dont have a n64digital to repeat the same environment. I played it for a while 3 player with no issues.

You could try this firmware. Ive just disabled the internal pullups incase the n64digital has pullups enabled aswell which maybe be pulling too strong.

Program it with Teensy Loader

firmware_nopullup.zip

[kimbapslice]

The no pullup firmware did not make a difference. The controller port 1 becomes in active "in-game" immediately or after about 20 to 30 seconds. Even plugging in an official n64 controller into port one does not make it active in game again. However, N64Digital menu navigation is still possible and USB64 still can read controller 1 inputs.

Only for Fzero X so far that I can tell. My n64 is ntsc/usa cpu-04. Teensy 4.1 with 16MB RAM.

[kimbapslice]

Sometimes, I would see an error on the lcd screen for example:
"[N64] ERROR: Address CRC Error c00d"
"[N64] ERROR: Address CRC Error 8000"
"[N64] ERROR: Address CRC Error c019"
"[N64] ERROR: Address CRC Error e00d"

I am not sure what those errors indicate or if that's from soft resetting via the N64digital back into everdrive menu. Again, I have tested this with official Fzero x cartridge as well.

[Ryzee119]

Thanks for further testing. It seems like the n64digital is adding some extra capacitance/noise or something to the line. Assuming the n64digital is just passively listening.

Those errors means its reading incorrect data on the bus than expected. Address CRC mismatch (normally caused by noise).

Hopefully i can grab a n64digital in the next batch.

Make sure your grounds are solid.

[kimbapslice]

Thank you Ryzee119. One other user today was able to replicate the fzero controller issue on discord.

[mathieulh]

I can reproduce this on all versions of F-Zero GX, including the 64DD expansion versions.

I am using a n64digital and the Xbox 360 wireless receiver.

The n64digital menu still works even though the game itself stops registering inputs.

This issue does not occur if I use an OEM N64 controller (on the same n64digital setup)

[Ryzee119]

Unfortunately i was still unable to secure a n64digital to investigate this. Its certainly a weird issue.

Does the issue occur if only player 1 is connected? (N64 controller cables physically disconnected on the other ports?)

I have UltraHDMI without issues but UltraHDMI OSD only passively listens for button presses (with the downside of being unable to detect button presses if the game isnt actively checking controllers like on loading screens etc)

usb64 relies on the fact that the PI can only poll one controller at a time so I can easily emulate multiple controllers 'at once'.

If n64digital polls controllers itself (does anyone know if this happens?) it will break alot of things potentially as it may be in the middle of handling another controller. At this point its the only thing I can think of. It passively listens like ultraHDMI, confirmed with PixelFX team. This is a weird one!

F-Zero GX may just be suseptible to it and wont recover automatically like other games. Most games may not care about of a few corrupt packets.

[mathieulh]

The N64digital behaves exactly like the ultrahdmi and only passively listens to inputs. The inputs aren't recognized while games aren't actively checking for controllers.

I can verify that this issue still occurs if only controller 1 is connected.
This seems to be a usb64 issue. I can leave all other controller ports connected to usb64 and connect a OEM controller to controller 1 and the issue does not occur.

[Ryzee119]

Hopefully ive secured a N64 Digital to investigate/fix this issue.

I put my scope on the joybus lines while playing FZero and there's not much happening that should be a challenge for usb64.
You could try the latest FW which has a few fixes but nothing that Im confident would fix this issue, but hopefully I get my unit in a few weeks to work this out.

[mathieulh]

The latest firmware still has the same issue.

There is another bug where if you drift on rough terrain the controller will keep vibrating until the track is over.

[networkfusion]

The N64 digital uses JoyBus for Game ID detection. It is likely this is causing un-intended side effects. If using an ED64 V3 or lower, you could try my unofficial OS https://github.com/N64-tools/ED64-UnofficialOS-binaries which allows you to "disable" the joybus send, or even use an older ED64 OS menu version on an X7 or X5 pre N64Digital support..

For further investigation, this is the code used to send the game id: https://gitlab.com/pixelfx-public/n64-game-id

[mathieulh]

The N64 digital uses JoyBus for Game ID detection. It is likely this is causing un-intended side effects. If using an ED64 V3 or lower, you could try my unofficial OS https://github.com/N64-tools/ED64-UnofficialOS-binaries which allows you to "disable" the joybus send, or even use an older firmware on an X7 or X5 pre N64Digital support.

For further investigation, this is the code used to send the game id: https://gitlab.com/pixelfx-public/n64-game-id

Unfortunately I am using an x7 everdrive so I can't test this.

[networkfusion]

The N64 digital uses JoyBus for Game ID detection. It is likely this is causing un-intended side effects. If using an ED64 V3 or lower, you could try my unofficial OS https://github.com/N64-tools/ED64-UnofficialOS-binaries which allows you to "disable" the joybus send, or even use an older firmware on an X7 or X5 pre N64Digital support.
For further investigation, this is the code used to send the game id: https://gitlab.com/pixelfx-public/n64-game-id

Unfortunately I am using an x7 everdrive so I can't test this.

I updated the comment... or even use an older ED64 OS menu version on an X7 or X5 pre N64Digital support.

[Ryzee119]

@networkfusion nice thanks!

Didnt know about this. That would certainly explain the issue.

Can everyone confirm they're using an everdrive x5/x7?

If thats it, it doesn't seem too hard to fix

[kimbapslice]

@networkfusion Ok, I just tested your V2.12.10.Preview-2 build on an ED64 v2.00, n64digital 1.6.6, latest usb64 build-202110290732. With and without the n64digital option in the ED64 menu turned on/off, the controller stops responding still after some time in Fzero x.

I couldn't find the joybus option or did I misinterpret what you meant. Sorry I do not have a x-series cart to test.

[networkfusion]

No miss interpretation. If the N64 Digital option was off in my unofficial menu, it means that the joybus commands were not sent from the ED64 Cart. So... it possibily becomes a noise issue 😓

[Ryzee119]

I thought I managed to secure a n64Digital but still waiting for the next batch now :(

[networkfusion]

I thought I managed to secure a n64Digital but still waiting for the next batch now :(

Once we get the F7 series working, and I can find a soldering iron, I can definely add some input here...

[kimbapslice]

With your version networkfusion, all of the games I tried show the gameid name in the n64digital menu correctly. FZero X (USA) does not pass the gameid - it's just blank. I actually used a retrode and ripped the rom of my original cart md5 verified 753437d0d8ada1d12f3f9cf0f0a5171f and the gameid was still blank.

Running the original fzero x cart and just leaving it on the main game menu, after a few seconds would display "no controller". Anyway, not a big issue, and just this one game to my experience.

I hope Ryzee119 will be able to get a n64digital soon, but it's like catching a unicorn at the moment.

[SubElement]

Unsure if this helps in any way, but I just tried this with Nintendo Switch Online N64 Controller + 8bitdo Adapter and barring a separate button mapping issue this is working totally fine for me on my N64 with an N64 Digital.

Let me know if I can help further with testing.

[nmcgill]

I experienced this as well in F-Zero, one difference here is I am using UltraHDMI. Here is my setup:

UltraHDMI HW1 (firmware v1.10)
8bitdo Adapter (firmware v2.03)
Nintendo Switch Online N64 Controller (using usb64 firmware provided in another issue)
EverDrive 64 V3

I haven't gone further in to debugging yet. Edit: Also have not found 100% reproducible steps

[darthcloud]

@Ryzee119 A similar issue with N64 Digital/F-Zero with BlueRetro was reported to be fixed when I changed the data line GPIO config from open-drain to push-pull (regular) if that help. Not sure if it applies to USB64.

[Ryzee119]

@darthcloud hey thanks for the idea. Love your work with blueretro too :D

If someone wants to try this is let me know if it fixes the issue that would be great!
firmware-pp.zip
@kimbapslice

[kimbapslice]

@darthcloud hey thanks for the idea. Love your work with blueretro too :D

If someone wants to try this is let me know if it fixes the issue that would be great! firmware-pp.zip @kimbapslice

I just tested this version with my official xbox 360 wireless controller and microsoft adapter. I noticed that the rumble would be hit and miss and sometimes would constantly rumble (stuck) and then no rumble no matter what. Then about 1 minute into the race it would rumble constantly and then the in-game control would become unresponsive. I was still able to get into the n64digital menu and navigate it.

[Ryzee119]

@kimbapslice damn thank for trying. Im still trying to get ahold of one.
My attack plan would be to trying an external pullup resistor on the data lines (maybe 2k or so?) and also get a oscillope on the lines to see whats going on.
I could experiment with software based glitch filtering but would be hard without being able to replicate the issue locally.

[kimbapslice]

@kimbapslice damn thank for trying. Im still trying to get ahold of one. My attack plan would be to trying an external pullup resistor on the data lines (maybe 2k or so?) and also get a oscillope on the lines to see whats going on. I could experiment with software based glitch filtering but would be hard without being able to replicate the issue locally.

No worries, there are lots of games to play :) Thanks for your continuous work to resolve the issue!

[Ryzee119]

I got one :) and I am able to repeat the issue.

Seems like its just some high frequency noise. The act of me simply putting my oscillope probes on the joybus fixes it. I may be able to fix in software by tweaking the slew rates, or worst case adding a small capacitance on the data lines (~10pF or so) but will investigate

[Ryzee119]

Unfortunately the GPIO is already set at the most forgiving slew rates and drive strengths.
I was able to fix it by adding a 10pF cap between Player 1 data line and gnd

OR

[kimbapslice]

Looks like a clean fix with the capacitor route. I will try it when I get back home. Thank you and congrats on finally getting a n64digital :)

[Ryzee119]

Although it appears to only be visible in Fzero, This cap is probably a good idea for any game..
I think its just most noticable as this game just gives up if it misses a few packets, other games must keep retrying so its less noticable.
It must be that PIF wire flapping in the breeze as part of the n64digital picking up some noise. Why it doesnt happen with UltraHDMI, im not sure (maybe the UltraHDMI FPGA has higher internal capacitance?)

[nmcgill]

I've experienced this issue before using UltraHDMI (only once and haven't repeated it since). Would the additional capacitor be recommended in this case as well?

…

On Sat, Jul 30, 2022, 11:53 PM kimbapslice ***@***.***> wrote: Looks like a clean fix with the capacitor route. I will try it when I get back home. Thank you and congrats on finally getting a n64digital :) — Reply to this email directly, view it on GitHub <#42 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANN5AYZ753TV6LT6NJUACDVWX2D5ANCNFSM5AWR2P3A> . You are receiving this because you commented.Message ID: ***@***.***>

[Ryzee119]

I've experienced this issue before using UltraHDMI (only once and haven't repeated it since). Would the additional capacitor be recommended in this case as well?

I may have just gotten lucky with my UltraHDMI and noise issues. I would recommend this cap for UltraHDMI too.

[darthcloud]

@Ryzee119 nice solution, technically much better than what I did, I'll try to see if same fix work for BR.

[mathieulh]

I did the fix adding 0402 (it's very tiny, but that's what I had on hands) 10 pf 50V capacitors between the data and GND pins of the usb64 board on each of the 4 controllers? (I mean, why should we only fix controller1? It's likely noise tolerance isn't that good to begin with even without the PIF wire or this issue wouldn't have happened to begin with) and it works great. I could finally finish a cup in F-Zero X.

I would suggest you add this fix as part of the original wiring instructions.

[Ryzee119]

Thanks for testing! Having this cap for all for controllers certainly wouldn't hurt.
I'll update the breakout PCB and the relevant readme sections to capture this asap

[kimbapslice]

I have added a 10pF capacitor (ceramic, yellow) from ground to pin 36 on teensy board but it still shows "No controller" after I leave the game on idle for a while. USB64 firmware from October 29th, 2021, n64digital firmware 2.0.0 (beta). I was able to finish a race, but main screen idle still an issue. So weird.

[Ryzee119]

The 10pf isn't an exact science. Although I found 1nF too big.
If you have any other values handy you could try 100pF or something.
You could also try adding another 10pf in parallel with the existing to get 20pF

[kimbapslice]

Ryzee, I removed the 10pF and soldered on the 100pF and so far it is working great!

[Ryzee119]

Ive updated the relevant HW documentation in commit f60e9b8.

Also for better visibilty ive created a new pinned issue highlighting the fix we have found. #59.

I will close this here, but we can continue to discuss here and we can reopen if needed.

[darthcloud]

For BlueRetro adding a 10pF or 100pF had no effect, what did the trick was adding a buffer gate (See darthcloud/BlueRetro#264 (comment))

Maybe that might help USB64 as well if the cap don't work.