SNES support

[Soundtoxin]

Is the SNES supported in HayBox yet? I recently ran into a USB-C to SNES cable on Handheld Legend and it says it's compatible with the Frame1 and B0XX.

https://handheldlegend.com/products/retrosix-usb-c-to-snes-cable-for-super-gamepad

I'm thinking of ordering one, but I was worried it might not do anything yet with HayBox firmware.

[JonnyHaystack]

Pretty sure he just means it's electrically compatible with that hardware because they all use the same USB C pins for the USB C to GC/N64 cables. None of those controllers actually have SNES support in their firmware, so unless this cable is actually an active converter it definitely won't work on any of the B0XX style controllers without custom firmware that doesn't yet exist. Maybe ask Mitch for more info.

[Soundtoxin]

So you're saying none of the listed rectangle controllers currently support the SNES as far as you're aware, but HayBox or other firmwares could in theory add support at some point and then it would work? If so, please consider this issue a feature request.

What you said about the pins used being the same between them makes sense. I think the cable is primarily for use with their new OpenController kit, I just thought it was interesting it listed some rectangles as being compatible as well. It's priced pretty much the same as their USB-C to GC cable ($1 more), so it's probably just a simple passive cable. They do note "This cable only works with controllers designed for this cable. This will not connect a standard incompatible devices to Super Nintendo." which sounds like it's not doing any extra magic.

I don't know who Mitch is or how I'd contact them, but I think you've given me pretty good info already. Thanks.

[JonnyHaystack]

Yes, that's correct.

Mitch = Mitch Cairns aka NiceMitch, he's one of the guys behind HHL who works on these kinds of products. I don't know how exactly their business is run but he has his own Discord https://discord.gg/eCcegPqK he'd be able to give you better information about that particular product than I can.

To me it seems a bit misleading to advertise it as compatible with controllers that have no firmware support for it.

As for adding SNES support as a feature in HayBox: I would love to, but I would really need access to at least a SNES and SNES controller in order to be able to work on that.

[JonnyHaystack]

FYI this feature (and also NES support) is coming in HayBox 3.0 and you can try it (and many other features) on the configurator branch which is where my active development is happening.

[Soundtoxin]

I recently got the SNES and NES USB-C adapters, so I wanted to build the configurator branch to try them out. I got a build failure, unfortunately. Here's the end of the output.

Compiling .pio\build\pico\src\HAL\pico\src\display\InputDisplay.cpp.o
HAL\pico\src\display\ConfigMenu.cpp: In constructor 'ConfigMenu::ConfigMenu(Config&, CommunicationBackend**, size_t)':
HAL\pico\src\display\ConfigMenu.cpp:156:5: error: C99 designator 'text' outside aggregate initializer
  156 |     };
      |     ^
HAL\pico\src\display\ConfigMenu.cpp:156:5: error: C99 designator 'text' outside aggregate initializer
HAL\pico\src\display\ConfigMenu.cpp:156:5: error: C99 designator 'text' outside aggregate initializer
HAL\pico\src\display\ConfigMenu.cpp:156:5: error: C99 designator 'text' outside aggregate initializer
HAL\pico\src\display\ConfigMenu.cpp:156:5: error: C99 designator 'text' outside aggregate initializer
HAL\pico\src\display\ConfigMenu.cpp:156:5: error: C99 designator 'text' outside aggregate initializer
HAL\pico\src\display\ConfigMenu.cpp:156:5: error: C99 designator 'text' outside aggregate initializer
In file included from c:\users\user\.platformio\packages\framework-arduinopico\arduinocore-api\api\Interrupts.h:8,
                 from c:\users\user\.platformio\packages\framework-arduinopico\arduinocore-api\api\arduinoapi.h:29,
                 from C:\Users\User\.platformio\packages\framework-arduinopico\cores\rp2040/api/ArduinoAPI.h:2,
                 from C:\Users\User\.platformio\packages\framework-arduinopico\cores\rp2040/Arduino.h:28,
                 from HAL\pico\include/stdlib.hpp:4,
                 from include/core/state.hpp:4,
                 from include/core/socd.hpp:4,
                 from include/core/InputMode.hpp:4,
                 from include/core/ControllerMode.hpp:4,
                 from include/core/CommunicationBackend.hpp:4,
                 from include/comms/IntegratedDisplay.hpp:4,
                 from HAL\pico\include/display/ConfigMenu.hpp:4,
                 from HAL\pico\src\display\ConfigMenu.cpp:1:
c:\users\user\.platformio\packages\framework-arduinopico\arduinocore-api\api\Common.h: In instantiation of 'decltype (((b < a) ? b :  a)) min(const T&, const L&) [with T = unsigned int; L = int; decltype (((b < a) ? b :  a)) = unsigned int]':
HAL\pico\src\display\ConfigMenu.cpp:193:80:   required from here
c:\users\user\.platformio\packages\framework-arduinopico\arduinocore-api\api\Common.h:130:15: warning: comparison of integer expressions of different signedness: 'const int' and 'const unsigned int' [-Wsign-compare]
  130 |     return (b < a) ? b : a;
      |            ~~~^~~~
*** [.pio\build\pico\src\HAL\pico\src\display\ConfigMenu.cpp.o] Error 1
================================================================== [FAILED] Took 106.63 seconds ==================================================================

Environment    Status    Duration
-------------  --------  ------------
pico           FAILED    00:01:46.628
============================================================== 1 failed, 0 succeeded in 00:01:46.628 ==============================================================
 *  The terminal process "C:\Users\User\.platformio\penv\Scripts\platformio.exe 'run', '--environment', 'pico'" terminated with exit code: 1. 

[garciaErick]

did you try the configuator branch? this has been open for a while

[Soundtoxin]

Did anything change since then that would lead to it building properly now? I can try it again later.

[JonnyHaystack]

It always built fine, you must've had something wrong with your local development environment. Bear in mind it's pinning to a specific arduino-pico version so you can't have multiple editors with different HayBox versions open as they will fight each other trying to download the specific arduino-pico version they depend on (PlatformIO unfortunately doesn't support having multiple versions of the same platform installed in parallel...)

[Soundtoxin]

I'm normally a GNU/Linux + vim kinda guy. It didn't seem like I'd be able to get vscode or platformio working on Guix System easily, so I was using a spare Windows machine for this. I've never used vscode or platformio prior to this and I have to say, I am not at all a fan. I seem to be getting a failure of the same sort as last time. I did a git pull from a terminal, closed the terminal, opened vscode, made sure configurator branch and pico environment were selected, then hit build. Following the readme, I feel like I did everything right... At this point using a different computer/OS seems like the easiest way forward. I have an Arch server I can ssh into. That means no vscode (don't wanna use X11 forwarding), but maybe I could get the platformio CLI working there. The readme makes it sound like that should work, though doesn't go into detail. I also have a Steam Deck, dunno if I can get all the needed deps to build on there or not, lol. I'll see what I can figure out, but any pointers would be appreciated also. Sorry to leave this issue open so long, didn't realize before that it was blocked on me. I also start to feel like HayBox is abandoned half the time since releases aren't very frequent (compared to GP2040-CE, for example), but I do see now there have been some commits lately.

Ideally would like to sort this issue out first, then I was thinking I'd dig out the N64 to see how bad the Smash 64 layout was again and if I'd change anything besides the jump button to sort out that other issue.

[JonnyHaystack]

@Soundtoxin

I'm normally a GNU/Linux + vim kinda guy.

Same :slightly_smiling_face: the README is only aimed towards Windows users because that is the majority of my user base.

It didn't seem like I'd be able to get vscode or platformio working on Guix System easily, so I was using a spare Windows machine for this.

Why not? VS Code really isn't needed, you can just use the CLI. PlatformIO is written in Python so you can just install it with pip (or better pipx). See https://docs.platformio.org/en/latest/core/installation/methods/pypi.html

I have an Arch server I can ssh into. That means no vscode (don't wanna use X11 forwarding), but maybe I could get the platformio CLI working there. The readme makes it sound like that should work, though doesn't go into detail.

As mentioned above, the instructions are mainly geared towards Windows users. I generally expect most Linux users who know what a CLI is to be able to read/find documentation on their own if they want to try using the PlatformIO CLI. PlatformIO's own documentation tells you everything you need for that.

By the way if you aren't planning on making any changes you could also just grab a development build from CI pipeline https://github.com/JonnyHaystack/HayBox/actions/workflows/build.yml

The README also has details about using the GitHub Actions CI to build, or using GitHub Codespaces, both of which have no dependencies on you installing anything locally, and should give a completely reproducible build environment.

I also start to feel like HayBox is abandoned half the time since releases aren't very frequent (compared to GP2040-CE, for example), but I do see now there have been some commits lately.

If you look at the configurator branch you'll see I have been pushing a lot of commits there regularly all the way since last August. This will probably not be merged until around when the Glyph ships, as I have always stated - Limit Labs sponsored this work and I need to be sure all their requirements are met as well as the general public's before I'm comfortable putting the configurator functionality in a stable release.

[Soundtoxin]

Okay, been at this a couple hours now, here was roughly my journey, just for fun and in case it helps anyone else in the future.

installed platformio-git from aur referred to some docs here: https://docs.platformio.org/en/latest/core/index.html made sure ~/.local/bin was part of $PATH and made some symlinks according to "install shell commands" page git clone 'https://github.com/JonnyHaystack/HayBox/' git checkout configurator cd HayBox pio run -e pico failed installed raspberry-pico-sdk-git from AUR pio run -e pico failed pipx install grpc failed, says please install official package with pip install grpcio pip install grpcio failed because externally-managed-environment, recommends using pacman or pipx (lol) installed grpc-cli with pacman failed, output looks the same as the start, mentioning Protocol Buffers and gRPC installed python-grpcio failed installed python-grpcio-tools (also pulled in python-protobuf) pio run -e pico still complains about externally-managed-environment after trying to install Protocol Buffers deps but the grpc error is gone and the build seems to succeed uf2 file at ~/Downloads/HayBox/.pio/build/pico/firmware.uf2

also tried building on my Steam Deck kind of in parallel as I was getting annoyed at the rough experience on the Arch server, there it went like this: flatpak install com.visualstudio.code get platformio extension git clone HayBox / checkout configurator from a terminal again open folder in vscode and choose HayBox select pico environment build actually succeeded on the first try somehow builds from both machines had a matching sha256sum also

So I then copied the .uf2 to my local PC and flashed it to the controller as normal. Controller wasn't bricked, so that's good.

@JonnyHaystack I'm trying to test on SNES now, but so far no signs of life. Also it kinda seems like hot-plugging is probably a no-no and kills/freezes the console. Is there some button hold or something I need for SNES mode? And what will the default layout be like? More like Melee Mode or FGC Mode? I didn't see anything about the SNES in the README yet.

edit: I see here that in theory there is autodetection https://github.com/JonnyHaystack/HayBox/commit/f423ab466bcfe61d247c3ea1938325ea0ed30c6c

[Soundtoxin]

Is there anything simple that's exclusive to the configurator branch I can make sure works / is there just as a sanity check that I'm running the right firmware? I believe I did everything right, and my inputs still did nothing on my SNES, but I don't have a screen or a web configurator like with GP2040-CE on this controller so I'm a bit more "in the dark". I don't think I have a way to just check what firmware is already on there. Controller still works on a PC.

My tests were trying to move around the built-in menu of a cheap aliexpress flashcart, trying to do something in a Street Fighter game loaded up on said flashcart (navigated to with separate controller), and I also tried some real carts I had like Panel de Pon (SFC) and Super Mario All Stars (SNES). One thing I noticed is these games weren't even booting consistently when I only had my Open-Frame1 plugged in. I have actually extensively cleaned these games in the last year or two and never have any problems usually, so it's not oxidized or dirty pins. What seemed to be the problem is these games won't boot if it thinks there's no controller plugged in. Everything was fine once I plugged in a normal controller. My cheap flashcart booted either way most of the time, but I think real games might need to detect a controller or you just get a black screen. I tried looking that up to see if it was true, but wasn't finding verification on it, oddly.

I tried both the left analog stick buttons and dpad buttons (mod x + mod y + c buttons) figuring I might be in something like Melee mode and wasn't sure what the controls would be. Nothing I hit did anything. I later searched around the repo for SNES stuff and I think it looked like both left analog stick (value of 128 in each direction) and dpad are both bound to SNES dpad anyway.

Since I've got a probably-working build environment or two set up now it should be faster to try new builds if we need to test various changes. I just unboxed my USB-C to SNES adapter during the earlier testing since I had nothing to use it with before now, so it should be in good shape.

Will reply to some stuff I skipped over earlier while I'm here as well...

It didn't seem like I'd be able to get vscode or platformio working on Guix System easily, so I was using a spare Windows machine for this.

Why not? VS Code really isn't needed, you can just use the CLI. PlatformIO is written in Python so you can just install it with pip (or better pipx). See https://docs.platformio.org/en/latest/core/installation/methods/pypi.html

Long story short, Guix System, like NixOS before it, doesn't adhere to the Filesystem Hierarchy Standard, so things not packaged specifically for Guix often don't work because they can't find other dependencies and stuff on the system where they expect them to be. I haven't yet got a good feel for packaging stuff, so I tend to avoid running unpackaged things on here. I have attempted to use pip in the past when working with QMK for my keyboard, but it was a bit broken from what I remember so I ended up building the firmware on another machine and then flashing the file locally with dfu-programmer. Admittedly I didn't try to get it working this time, but it didn't seem worth the hassle if I could find an easier/faster way.

By the way if you aren't planning on making any changes you could also just grab a development build from CI pipeline https://github.com/JonnyHaystack/HayBox/actions/workflows/build.yml

This is cool and would've certainly saved me some time before, but it's probably good I figured out how to get my own build env set up anyway. I did grab some pico firmware from there and it matched the sha256 of the two I built, so I'm probably all good there.

If you look at the configurator branch you'll see I have been pushing a lot of commits there regularly all the way since last August. This will probably not be merged until around when the Glyph ships, as I have always stated - Limit Labs sponsored this work and I need to be sure all their requirements are met as well as the general public's before I'm comfortable putting the configurator functionality in a stable release.

Indeed, sorry if what I said came off harshly, didn't mean to belittle your work. Also wasn't aware to what degree the Glyph stuff was involved with you. When I first heard about the controller I had heard something like it was using a fork of HayBox, so I wasn't even sure if they talked to you. Glad to hear things are being worked on cooperatively and going into upstream HayBox. NES and SNES support is pretty exciting. I always liked the idea of these controllers being kind of universal "everything" controllers you can just plug into whatever.

I was feeling kinda rushed/stressed to build the firmware and test stuff after the sudden comments on two of my issues, so apologies if I'm a bit overly excited now. Will wait on your suggestions for the next steps. Can do additional testing/building as needed.

[JonnyHaystack]

Ah right, sorry I forgot to mention the standard GCC USB C pinout is not enough on the hardware side. NES/SNES controller protocol uses 3 GPIO pins - latch, clock, and data. The original controllers were essentially just shift registers. You also need a circuit with a level shifter and schottky diode because NES/SNES use 5V logic whereas GC/N64 use 3.3V. If you're in Crane's discord you can search for the diagram/explanation he made.

Come to think of it the NES/SNES backends are also not enabled in the default pico device config so you'd actually have to make a customised one - you can use Glyph config.cpp as a reference. Sorry about that, I've been developing primarily for the Glyph for so long now that I kinda forgot about all these differences.

To be honest it's kinda false advertising for HHL to say their cable is compatible with B0XX, Frame1, etc because even if their firmware could support it, the hardware simply does not without significant modification. FWIW though, it will work out of the box on the Glyph.

I was feeling kinda rushed/stressed to build the firmware and test stuff after the sudden comments on two of my issues, so apologies if I'm a bit overly excited now. Will wait on your suggestions for the next steps. Can do additional testing/building as needed.

No worries. I wouldn't stress too much about testing this functionality as it has already been tested on the Glyph by several people.

[Soundtoxin]

Oof. That is a bummer. There's a schottky diode in the Open-Frame1 before the USB-C port, but I take it this is an additional required one. I do not use Discord. Kinda sounds like I'm out of my depth here, so I guess close this issue at your leisure then. I wasn't planning to buy a Glyph due to the price (I built 5 OF1s for less than the cost of 1 Glyph) but hopefully one of the DIY controllers will achieve feature parity at some point.