One of those pesky Bliss-box 4-play users

Hey all,

I’m checking in regarding solutions for using the Bliss-box 4-Play all-in-one USB adapter with Retroarch. Back in the 1.3.6 days, I was using per-core configs to ensure that each core had the correct input scheme for the original system controller. The only real pain in the butt at that time was the N64 controller.

However, now that I’ve joined the new 1.4.1 world order, per core configs have been removed, with no tenable solution for the 4-play evident. From what I have gathered, the only solution that exists at this moment is one that was posted in December, which is apparently limited to only one player.

I’ve heard talk of a retroarch dev getting a hold of a 4-play adapter, with the intent to figure out a solution that would avoid all the random hacking required in the past, but that was a “possible” new year thing as of December, and now that we’re in February I wanted to figure out what I ought to be doing if I want to play some good ole fashioned vidya games with friends.

Should I just downgrade to a version that allows me per-core configs? Should I be patient? Should I pray to some sort of deity?

Last I heard, the bliss box guy did a bunch of testing and was able to get it working with linuxraw, udev and sdl2. I think you can use the sdl2 joypad driver and autoconfig profile on Windows (assuming that’s what you’re using).

I wrote a guide a bit ago on how to set it up with the new system.

As for multi controllers you have to use a custom firmware for the 4play which gives each port a diffrent id. http://atarigalore.wixsite.com/4play Download the file on the left called custom flasher.

Then make an auto config profile for each port base on a ps1/2 pad in rotate button mode

Not sure if the recent changes invalidates anything here, but I did a lot of work on enabling full N64 compatibility between the 4-play and Retroarch. There is a heavily documented config file available here: http://www.hyperspin-fe.com/forums/topic/13345-retroarch-blissbox-4-play-and-n64-control-mapping/

There had been some mention of more native support of the 4-play within RA back in December, I assume so that we wouldn’t have to fight with the double-abstraction of controllers between the 4-play and the Retropad. Supposedly the RA devs were having a device shipped to them for further investigation. Is any progress being made there?

AFAIK, we never received any hardware and there’s been no action on our end beyond committing the autoconfig profiles that (I forget his name; the firmware guy) developed.

For anyone who cannot access the link I referred to earlier, the following is the config file I created to allow the Mupen64 core to work with a real N64 controller connected via the 4-Play. Note that this config is valid for up to 4 players.

###############################################################################
# RetroArch input mapping file for using real N64 controllers in
# Mupen64Plus with a BlissBox 4-Play adapter.
# 
# The default input mapping for the Mupen64 core assumes the player is using 
# an XBOX or PS Dualshock-style controller.  Because these controllers do not 
# have enough face buttons to emulate the N64 C-buttons in addition to A & B, 
# the core provides 2 ways to send C-button input:
# 1) Retropad right analog stick
# 2) Retropad Y => C-Left, X => C-Up
#    Holding R2 overrides Retropad A & B to map B => C-Down and A => C-Right
#
# When attempting to use a real N64 controller, the R2 button override
# functionality isn't needed.  In fact, it greatly confuses the configuration.
# There are also a few additional tweaks required to improve usability.
# So this input file overrides the 'default' 4-Play input assignments 
# settings to support a real N64 controller layout without any additional
# remapping at the RA core level.
#
# Consider 'default' 4-Play input settings to be those set by 
# retroarch-joyconfig when using a BlissBox 4-Play with a PS2-DualShock 
# controller.  The following changes were applied to that config to make 
# everything play nicely together:
#
# 1) Limited C-Button input to only the right analog stick by disabling the
#    the Retropad buttons that are normally mapped to C-button functions:
#        - Retropad inputs X, Y, and R2 mapped to "nul"
# 2) Assign Retropad's right-analog inputs to the 4-Play's N64 
#    C-button assignments:
#        - Remove the default Retropad right analog inputs by 
#		   mapping to "nul"
#        - Assign Retropad right analog inputs to the real N64
#          C-button inputs
# 3) Swap the position of the A & B buttons to match the real N64 layout
# 4) Z-Trigger assignment changed from 4-Play's SELECT to L2
# 5) Disable remaining buttons that don't exist on a real N64 controller:
#        - Retropad inputs SELECT, L3, R3 mapped to "nul"
#
# In order to effectively use this configuration, you should NOT have any
# core input remapping files enabled.  Check the following settings:
#     auto_remaps_enable = "false"
#     input_remap_binds_enable = "false"
#     input_remapping_path = ""
#
# These settings can be applied by merging them into your retroarch.cfg
# file, or the per-core config if applicable.  If you do this, you need to
# disable the joypad autoconfig functionality, since the autoconfig settings
# are higher priority and will override settings included in the master
# .cfg file.  You can disable the autoconfig by changing the following
# setting:
#     input_autodetect_enable = "false"
#
# This config can also be applied through the core-specific configs.  Simply
# add these settings to "<RA_Config_Dir>\Mupen64Plus\Mupen64Plus.cfg".  RA
# will automatically look for this file and override the main .cfg settings
# with anything in there.  If you use this method, you still need to disable
# the joypad autoconfig settings as mentioned above.
#
# The final method for applying these settings is to use the append config 
# functionality from the command line: "--appendconfig file1.cfg,file2.cfg"
# Just pass the file containing these settings to that option.  If you use 
# this approach, you DO NOT need to disable the joypad autoconfig.  The
# appendconfig setting has the highest precendece, and will override all 
# other configuration settings used by RetroArch. 
###############################################################################
input_player1_b_btn = "0"
input_player1_y_btn = "nul"
input_player1_select_btn = "nul"
input_player1_start_btn = "5"
input_player1_up_btn = "10"
input_player1_down_btn = "11"
input_player1_left_btn = "12"
input_player1_right_btn = "13"
input_player1_a_btn = "1"
input_player1_x_btn = "nul"
input_player1_l_btn = "6"
input_player1_r_btn = "7"
input_player1_l2_btn = "4"
input_player1_r2_btn = "nul"
input_player1_l3_btn = "nul"
input_player1_r3_btn = "nul"
input_player1_l_x_plus_axis = "+0"
input_player1_l_x_minus_axis = "-0"
input_player1_l_y_plus_axis = "+1"
input_player1_l_y_minus_axis = "-1"
input_player1_r_x_plus_btn = "9"
input_player1_r_x_minus_btn = "2"
input_player1_r_y_plus_btn = "8"
input_player1_r_y_minus_btn = "3"
input_player1_r_x_plus_axis = "nul"
input_player1_r_x_minus_axis = "nul"
input_player1_r_y_plus_axis = "nul"
input_player1_r_y_minus_axis = "nul"
input_player2_b_btn = "0"
input_player2_y_btn = "nul"
input_player2_select_btn = "nul"
input_player2_start_btn = "5"
input_player2_up_btn = "10"
input_player2_down_btn = "11"
input_player2_left_btn = "12"
input_player2_right_btn = "13"
input_player2_a_btn = "1"
input_player2_x_btn = "nul"
input_player2_l_btn = "6"
input_player2_r_btn = "7"
input_player2_l2_btn = "4"
input_player2_r2_btn = "nul"
input_player2_l3_btn = "nul"
input_player2_r3_btn = "nul"
input_player2_l_x_plus_axis = "+0"
input_player2_l_x_minus_axis = "-0"
input_player2_l_y_plus_axis = "+1"
input_player2_l_y_minus_axis = "-1"
input_player2_r_x_plus_btn = "9"
input_player2_r_x_minus_btn = "2"
input_player2_r_y_plus_btn = "8"
input_player2_r_y_minus_btn = "3"
input_player2_r_x_plus_axis = "nul"
input_player2_r_x_minus_axis = "nul"
input_player2_r_y_plus_axis = "nul"
input_player2_r_y_minus_axis = "nul"
input_player3_b_btn = "0"
input_player3_y_btn = "nul"
input_player3_select_btn = "nul"
input_player3_start_btn = "5"
input_player3_up_btn = "10"
input_player3_down_btn = "11"
input_player3_left_btn = "12"
input_player3_right_btn = "13"
input_player3_a_btn = "1"
input_player3_x_btn = "nul"
input_player3_l_btn = "6"
input_player3_r_btn = "7"
input_player3_l2_btn = "4"
input_player3_r2_btn = "nul"
input_player3_l3_btn = "nul"
input_player3_r3_btn = "nul"
input_player3_l_x_plus_axis = "+0"
input_player3_l_x_minus_axis = "-0"
input_player3_l_y_plus_axis = "+1"
input_player3_l_y_minus_axis = "-1"
input_player3_r_x_plus_btn = "9"
input_player3_r_x_minus_btn = "2"
input_player3_r_y_plus_btn = "8"
input_player3_r_y_minus_btn = "3"
input_player3_r_x_plus_axis = "nul"
input_player3_r_x_minus_axis = "nul"
input_player3_r_y_plus_axis = "nul"
input_player3_r_y_minus_axis = "nul"
input_player4_b_btn = "0"
input_player4_y_btn = "nul"
input_player4_select_btn = "nul"
input_player4_start_btn = "5"
input_player4_up_btn = "10"
input_player4_down_btn = "11"
input_player4_left_btn = "12"
input_player4_right_btn = "13"
input_player4_a_btn = "1"
input_player4_x_btn = "nul"
input_player4_l_btn = "6"
input_player4_r_btn = "7"
input_player4_l2_btn = "4"
input_player4_r2_btn = "nul"
input_player4_l3_btn = "nul"
input_player4_r3_btn = "nul"
input_player4_l_x_plus_axis = "+0"
input_player4_l_x_minus_axis = "-0"
input_player4_l_y_plus_axis = "+1"
input_player4_l_y_minus_axis = "-1"
input_player4_r_x_plus_btn = "9"
input_player4_r_x_minus_btn = "2"
input_player4_r_y_plus_btn = "8"
input_player4_r_y_minus_btn = "3"
input_player4_r_x_plus_axis = "nul"
input_player4_r_x_minus_axis = "nul"
input_player4_r_y_plus_axis = "nul"
input_player4_r_y_minus_axis = "nul"

Also, as it relates to some form of native support in RA, there was mention in a few places:

and

Did that never happen? That would be a shame.

I have not heard back from the team yet but I think we are still on track.

Thanks for chiming in ulao!

What do you mean on track? With another solution? With getting the adapters to the retroarch people? I’m just trying to figure out if I should spend the time setting up nonekiller001’s idea or if I should wait.

I got some email from a misterB asking “Did that never happen? That would be a shame.” about a twitter post I made. So maybe this was an automated response? I’m not sure what these email are in relation so but the tweet MisterB was referring to, was about the RArch team . They are working towards a permanent solution. None of the solution are really good imo, I’d wait for the official word from RA. 1.6 (the firmware that works on emulation station) will be out this month. That is the version the RA team will use as a basis. So I’d hold off for a bit.

ulao - Not sure if the email you received was based on the Twitter reference or something else in these forums, but either way, glad to see you chiming in!

I was responding the post earlier in this thread where HunterK mentioned:

AFAIK, we never received any hardware and there’s been no action on our end beyond committing the autoconfig profiles that (I forget his name; the firmware guy) developed.

Since this is the RetroArch forum, and HunterK is one of the key guys on the RA team, I was pointing out the disconnect between your statement and his, so I was curious if the 4-Play ever got in the hands of the RA team.

Maybe it’s me that is confused - I know there is the recent 4-Play firmware fix that addressed the Linux compatibility with EmuStation/RetroPie (and somewhat by extension, RetroArch). But I didn’t think that was the end-state for improved compatibility. I was under the impression that there was more work coming to allow a more native integration of the 4-Play directly into RA? Of course I’ve been following little bits of info across multiple sites, so maybe I’m completely misinterpreting things…

Hi figure I’d just reply directly to the post here. Tthe unit was sent to Maastricht and I corresponded with a Daniel De Matteis <libretro [at][ g m a i l [dot] com> Being this is in the Netherlands it may be tied up in customs.

So, yes we are on hold till he receives the device. He seemed like a very well mannered and honest guy IMO so I trust he will let me know when it arrives. It was sent mid Dec, so it really should have been there by now. I find that sort of thing takes 1 month on average. If it was kicked back or required a tariff/custom fee and not paid they ship it back to me. That normally is a 3 month round trip. Being I have no choice but to ship USPS, nothing can be tracked outside the US. The alternative is $120 via UPS. If you want to start a bounty for that let me know :wink:

Sorry for the long winded reply but I wanted to cover all basses here.

No worries, I’ll follow up with Twinaphex and see if he ever received it. You can definitely trust him :slight_smile:

Just a quick thing for the community here, 1.56 will have support for SDL. the issues was dual devices. Turned out sdl on linux (not windows) crashes when is sees dual devices and FFB. As a result we removed mouse support and are now depending on analogs to convey that data. The mouse support was only good for emus like jnes that needed to read the mouse (arkanoid). You can always get a joy to mouse if needed. 1.56 will have that removed so emulation station will work. There are a slew of new features like being able to save your modes (i.e button rotate) to eeprom. This is great for RA guys because you may want a feature permanently on a given port. Beta testing is just about up and should be available soon. Twinaphex will want to base his experimentation off of this version. He can contact me for a beta release at any time.

Hi all, just want to check in as I have not heard back from Daniel De Matteis. I have sent 3 emails with no response. If anyone here is in communicate with him, please have him contact me so we can make progress on support for the 4-play in retroArch.

Though for clarification and this thread the item did arrive.

Hey, sorry about that. He said to email him one more time at [email protected] and he’ll be sure to respond.

The 4-play has just got better. Introducing the all new 2.0 API system.

Why does that sound like a Verizon commercial?

Any ways, this is just the command line video blogs but a full GUI is in the works. Although most of you will want the command line interface because you can communicate with the Bliss-Box via bat files. So while we are hopefully waiting on the retroarch dev team to find a solution (yes the adapter is in his hands) we have one that will do just fine for now.

This first video is just a show off of what to expect. The second is something many of you will love and have asked for, for some time. but RA could send their logo to the LCD now :wink: Or maybe a game icon.

Ah, that’s very cool! The CLI mapping sounds like it will be a big help.

nice! I gald so hear a gui remapper is in the works. Will the remappings be stored on the 4play per controller type or is a general remap for all the controllers.

You can set each mapping to a port, 2.0 will have unique ID’s like the 4-play fix. And each port will shows as player 1 ,2 ,3 or 4. The tool will let you pick what port goes to what player. When setting a new mapping you can leave the port blank (default to port 1) or specify a port. This remapping is good till reset. Swapping to a new controller will not removing the mapping. Saving the mapping to eeprom is still in debate. Thus far that may cause too much confusion, so on reset the mapping is back to default. Though, with the idea of a bat file, you can set the port on each usb mount. You can also use mapping lables. In the command line tool there is a 360 and ps3 mapping. So you just do “set mapping ps3” and the controller now follows the ps3 layout.