darthcloud
BlueRetro on Neo Geo interferes with Unibios by "pressing" buttons early in boot.
BlueRetro firmware version
1.9.1
BlueRetro firmware specification
HW1
BlueRetro firmware variant
System specific
BlueRetro hardware type
External adapter dongle (1 port only)
Manufacturer
HumbleBazooka
System used
SNK NeoGeo AES
Bluetooth controller brand & name
Problem happens even if no controller is paired.
What is problem? (only list ONE problem per report)
In early boot, at system power up, it seems like the BlueRetro device is pulling some of the controller pins to ground (i.e. as if buttons were pressed on a physical controller). This is happening even without any controller paired.
The problem is that it interferes with the UniBIOS [a popular Neo Geo alternative Bios) (which can have settings mode be triggered by pressing button combinations early in boot): sometimes (maybe depending on specific timing), the Unbios setting menu gets triggered.
What did you expect to happen?
Instead, I would expect all of the output lines of the BlueRetro to stay in Hi-Z (not simulating any button press) until a controller is paired and buttons are actually pressed.
Attach files like logs or Bluetooth traces here
No response
For good measure I tried both the "push pull mode" (Parallel_1P_PP system in Global Config) and "open drain mode" (Parallel_1P_OD system in Global config) but this does not seem to make a difference.
I got an AES as well with unibios v4.0 and I do not have that issue using HB adapter.
Quite often problem with BlueRetro and NeoGeo can be resolve by getting a more modern power supply. What you describe sound like that kind of problem.
Quite strange. I test my adapters with an AES (5v model), MV1C, and MV1B each with unibios and I haven't noticed this behavior. I think Jacques suggestion that it could be power related is a solid suggestion and new PSU or maybe servicing of your Neo Geo might be needed.
Thanks for the quick reply, all! I am testing this on a MV-1C I consolized (I put AES because there was no better choice in the form). My PSU is regulated and high quality, but I will test with a 5V/5A PSU later just in case. I am curious what you are seeing if you do the following:
- Go into the hardware test menu. From there go to the I/O test
- Plug the BlueRetro in port 2 while the I/O test screen is showing I am seeing: at the time where I plug it, all of the "buttons" being pressed (which appear as "red 1s" in the I/O test") What I am expecting (what happens if plugging another controller, including the Brooks Bluetooth adapter): none of the buttons get pressed.
For the test above, some additional information:
- If you don't have the Jamma "test" button wired, you can also press "B + C + D" at boot during the Unibios Splash screen to access the hardware test menu
- Instead of unplugging BlueRetro, you can use the "reset" button. The same will happen and it will send button presses to the Neo Geo
I actually use the same hardware IO for testing all Neo BT adapters before they leave my shop. What you've described about plugging in the adapter and seeing all buttons press momentarily is normal as the ESP32 powers up and toggles GPIOs. If I'm remembering correctly, the "soft reboot" shouldn't toggle power on the MV1C, and that's really the only way you'd see the Neo BT toggle all GPIOs again but I think that's getting away from the actual issue. What kind of MV1C are you using. That might help narrow things down further.
So it seems like we're seeing the same thing. The timing is just slightly different on my side, where all button pressing momentarily sometimes happens while the Unibios Splash screen is up (but relatively rarely).
It happens consistently when I use the reset button though, since that just triggers the select + start shortcut which pops up the menu. Do you see the same thing, with the reset button being pressed triggering all buttons on the I/O test menu ?
I am not familiar yet with the ESP32. I'm a little surprised that it would pull all of the pins to ground as a part of its normal startup sequence. It seems like this could be problematic for some use cases (aren't these tri-state pins that could be configured as input?). Are we really sure that it's not a piece of code that does this early by mistake?
The pin are not wired to the esp32 they go through a level shifter.
They are wired to the OE pin of the level shifter. So while the system is in a transitional state while the esp32 boot the OE line wont be driven since most ESP32 pin will be high impedance.
It really depends on what the behaviour of the level shifter used is when its OE pin is floating.
It would have been a good practice to out a pullup resistor I guess on the OE line.
Ohh I see, that makes sense, thank you very much for the explanation. Should we close this as Won't Fix or keep open for an eventual board revision?
I updated the schematics were the OD configuration was used to add pull-up resistor on the ESP side to avoid transient on the level shifter at power on.