Improve Joybus Extension enumeration handling

[NewGBAXL]

The N64's Joybus protocol inherently allows for the game to request specific Extension Paks to be inserted on demand, by writing the ID of the Pak to 0x8000 on the bus, or the bank number, such as 0x00, for the Controller Pak. Writing 0xFE to it requests shutdown to the current pak, and is not just limited to the Transfer Pak.

The "proper" approach to swap paks mid-game is to just write the desired pak id via joybus in between menus, and provide a UI screen to facilitate that, if it needs to be swapped. This allows the pak itself to swap what it is, if supported on the hardware.

libdragon's approach does not currently allow for this. It instead checks to see if it can switch to a Controller Pak, if so, it's a Controller Pak. Else try to see if it can switch to a Rumble Pak. And so on. Meaning, if the pak can swap between CPak and RPak, for example, libdragon would first see it works as a CPak, stop there, and not even bother checking if it is an RPak.

Instead, if saving the game, it should attempt to swap to CPak, and do its job; if rumbling, swap to RPak if not already, and attempt to do that, etc. There is no reason to have an enum for which pak is currently inserted, and by having it, auto-swapping would be unintentionally broken.

I am currently testing auto-swapping on a modified version of Gopher64, and have tested 140+ games, 70% have worked successfully and completely, 15% are having issues potentially due to my implementation (working on fixing), and the remaining 15% have a polling system similar to libdragon's and is unfixable.

Would love to work with y'all to get this cleaned up and better support this feature :)

[rasky]

Thanks for the discussion.

You seem certain of the fact that joybus was designed in a way to allow the application to "request" a certain pak. Where you are getting this information from? Is it an hypothesis you are making? Do you have any sources?

Similarly, what are your sources on the fact that 0xFE would be a "turn off" command valid for all paks and not just transfer paks? For instance first party rumble paks and controller paks don't react to it, as far as I'm aware.

Now, irrespective of what the original designers of the protocol thought, there is no first party or third party pak (that I know of) that can simulate two different kind of paks at the same time, and allow to switch between them via the joybus probe command, which is your main suggestion here. I think the only pak that I am aware can do both rumble and controller is some 8BitDo gadget but the change is made mechanically with a switch (as far as I know).

I don't think libultra also supports for this feature; I don't know if there's any game supporting for instance both rumble and controller pak that first does a write/read probe hoping the switch can be made automatically and only later fallbacks to asking the user to switch manually.

I think it would be useful if you provided more context on your requests, given that libdragon is targeted at working with existing commercial or homebrew hardware.

[NewGBAXL]

The idea that the application can request specific paks is purely observation of the protocol. The protocol could easily just read off of 0x8000 to get the current pak, but instead it writes the requested pak id first. Whether or not this was the original intent of the SDK devs, I cannot say, but from observation, both of the protocol and testing games in-action, all findings heavily support this.

I'm aware the 0xFE as a turn-off command is also a bold claim, but have observed it used in both the Rumble Pak and Snap Station initialization commands, the former of which was released before the Transfer Pak. For example, for Rumble Pak, the N64 writes 0xFE (power off), then writes 0x80 (request rumble), then reads hoping for 0x80 back. For Snap Station, similarly, the N64 writes 0xFE (power off), then writes 0x85 (request SS), then reads hoping for 0x85 back. Original RPak hardware does not need to handle the 0xFE command as it does not have anything it needs to switch to, but libultra sends it anyway.

The CPak2040 is capable of auto-pak switching, albeit the current codebase lacks it. I have test code somewhat implemented for it, but still need to pick up the hardware to test and fix bugs. Supporting and encouraging this functionality would boost support for other aftermarket hardware and emulators; it has to start somewhere. It does not break existing hardware.

libultra does support this feature, I have tested many many games that switch without a user prompt for switching, and while some still use a user prompt, they nonetheless still switch properly. I've attached a video of WinBack switching on demand. Any game that does not have an enum for which pak is inserted implicitly supports this feature.

2026-06-11.11-39-49.mp4

[NewGBAXL]

Here's some example proposals,

• joypad_get_rumble_supported() can just poll the pak id 0x80 directly from joybus
• joypad_get_accessory_type(joypad_port_t port) should be removed altogether
• identify_accessory(int controller) can be removed as well
• tpak_init(int controller) can also just poll the pak id 0x84 directly from joybus
• the existing cpak check to see if the cpak can be written to is fine, but could be optionally changed to simply check bank 0 against the known checksum, instead of doing a r/w test. Current implementation is fine tho. Might need to be moved to a new init function.

Finally, a new function could be created to replace joypad_get_accessory_type(), dubbing it "joypad_request_accessory_type(joypad_port_t port, u8 type)". If type is 0x00, runs the longer controller pak check, if 0x80+, write 0xFE, write the type, and check if the same type is read back.

Need to verify this, but is the Controller Pak r/w test currently done every second?

[rasky]

I'll wait for Meeq to chime in on this topic, as he is more knowledgeable than me on joybus.