Controller Support: Brawler 64 Wireless

[bryanparadis]

Looks like the Brawler 64 Wireless on N64 isn't responding with data. Looks to be detected though. There are notes in Raphnet v3 about it specifically. They set a delay between 0x00/init/capabilities request and 0x400300/polling/short polling/status request of 1.25ms,1.5ms and 2.5ms based on configurable poll interval.

raphnet/gc_n64_usb-v3@e5f6c6e

/* The brawler 64 wireless gamepad does not like when the get caps command is followed
	 * too closely by the get status command. Without a long pause between the two commands,
	 * it just returns an all zeros. */
	if (g_eeprom_data.cfg.poll_interval[0] >= 4) {
		_delay_ms(2.5);
	} else if (g_eeprom_data.cfg.poll_interval[0] >= 3) {
		_delay_ms(1.5);
	} else if (g_eeprom_data.cfg.poll_interval[0] >= 2) {
		_delay_ms(1.25); // does not work at 1ms
	}

Also elsewhere on the web related to Raphnet there is this information:

The total latency is therefore 1ms + [configured poll interval]. This results in a minimum total latency of 3ms, and of 6ms by default. (For an adapter with a minimum poll interval of 2ms). Some 3rd party N64 and Gamecube controllers are known to misbehave when the poll interval is set too low (because consoles typically polls at 16ms intervals). This is why the default is higher at 5ms rather than the minimum value.

Looks like it's possible that polling is happening too fast for some third party N64 controllers. Raphnet seems to think that 5ms is the safest poll rate. N64 is 16ms. I guess I could measure the loop and see.

[bryanparadis]

Made build with a 1.25ms delay between 0x00 and 0x400300 but it didn't seem to work. I made a second build with 2.5ms instead to see if that fixed this issue. If not it's likely we are just pulling too fast. Adding a delay(30ms) to the loop to see if the controller starts responding would be my first bet. Then lower and see how far it can go.

[bryanparadis]

Bought a Brawler64 Wireless and detection was working ok but polling speed was too fast. Delaying by another 250us/0.25ms allows the controller to work perfectly.

I was wondering if there were multiple revisions so I emailed Retrofighters to see if they know. I also asked the original problem reporter in Misteraddons Discord if they can test the build I created.

[bryanparadis]

Retrofighters said that there is only one revision of the Brawler64 Wireless out there. So the 250us additional delay should fix it for all users. I will put up a pull request. As of yet nobody else has confirmed the fix to work.

[bryanparadis]

2500us or 2.5ms minimum poll time required it looks like unfortunately.

[bryanparadis]

Confirmed stable at 2500us by multiple users. Created a custom build for them. Something might need to be done to offer some kind of profile with compat? A build flag that produces such a version maybe?

[bryanparadis]

Looks likely that the Retrofighters BattleGC Wireless also has the same issue:

ianstalk
Today at 7:01 AM
Got my Retro Fighters battlerGC yesteray. Tried hooking up the 2.4 GHz GC receiver to my Reflex Adapt out of curiosity; it works but but it drops every few seconds. I assume it's probably trying to draw more voltage than the RA is able to supply?

As well as the Retrofighters Defender:

#45

[misteraddons]

New pre-release firmware to test N64 compatibility timing improvements is available: https://github.com/misteraddons/Reflex-Adapt/releases/tag/v2.01-vb-nso-abfix-pre6\n\nThis build includes a longer N64 init-to-first-poll settle delay (2.5ms) plus hardened N64 polling cadence. Please test whether this improves behavior with your controller/receiver and report back.

[misteraddons]

Updated prerelease firmware link (supersedes earlier prerelease links): https://github.com/misteraddons/Reflex-Adapt/releases/tag/v2.01-vb-nso-abfix-pre7

N64 path in this build includes the previous 2.5ms timing change plus additional transient polling/disconnect hardening. Please test and share results.