On the lower left side you see a red dot. This dot displays if DualStrike is connect (dance naked around your dual strike pcb… eh press select while plugging in). It gets green if it`s connected.
Click Arrow Up : Current Settings from Arcade Stick will be loaded and displayed. You`re ready to start to make your own settings.
Click Arrow Down : Save your settings to your Arcade Stick.
Furthermore you can save your arcade stick setting in a file. We thought it might cool to send your setting to your friend or something like this. Yes, the file can be loaded again ;))
Green Reload Icon set back to the delivered default settings if you messed up something and you want a quick revocer.
Greate to hear you like the source I imagine it should work in a VM, just try it. But as you’re working on Mac: Could you try to compile the hid-programmer (it’s in the configuration editor package under “HID_Programmer”)? I’m greatly interesterd if it works on Mac and if we could ship a Mac executable (are there big differences between the versions?).
when dualstrike is connected (green dot) the program should automatically load the current settings… people are going to press load button anyways? might as well do it automatically
the app should allow the user to update their firmware with one click of a button… idealy a user can download a one file firmware package, use the utility to browse to the file and click a button to update… or maybe to do download of latest firmware and flash in one click… nice for new users not to have to deal with a bunch of directories and files…
is it necessary to have 2 tabs at this point?
increase the size of that listbox for s3/s4 function… no need for scroll bars since the list is small…
You might connect the device after you’ve changed the configuration the way you wanted - then it is overwritten without a question. When the program would ask it might become annoying very fast.
The device connected might be incompatible (for compatibility with the bootloader the hid-programmer reacts to the same IDs), the user should know but the program might not. For performance reasons the connection status check isn’t too deep, but the load/save actions check for configuration device and version compatibility.
If there are incompatibility issues the first thing the user upon opening gets is an error message.
I think it is good style for programs not to do too much without user interaction.
For now we decided against integrating firmware update, as it is a once-in-a-while job and brings more complexity and dependencies. And we can’t set the Dual Strike to firmware update mode, the user has to - but he might think the configuration editor does everything once the DS is in configuration update mode.
We don’t have a domain for the Dual Strike, so it would be an error-prone setup to have some auto-update mechanism - auto-update would be a nice feature but it is quite complex to do it right. Also atm a firmware update requires just a download, unpacking a file and double-clicking on one file - not too complicated.
Nah, not really,but: It started out as a proof of concept, but I really like the distinction now, as the things on the second tab will only be changed if the stick setup was changed or a firmware with a new configuration format was installed. Is it a pain, now? I prefer smaller Windows over bigger ones
OK, agreed. I’m thinking that I should make the default limits changable in the configuration definition file…?
Interface enable and disable would take care of that… disable by default, enable it when the device has been connected… disable when it has been disconnected…
Ok… but the user runs the program with the intention to configure masterstrike… so the connection check has to be done anyways, whether its on connection or on update… the user has to wait for that anyways
I figure if there is an incompatability, they should know right away before changing settings and pressing upload only to find that it did not work
Not a pain… but i agree that a program should allow for minimum interaction which is the main reason behind the suggestions
One less tab, and a few less clicks would mean less questions from users like me who do not like to read instructions
For those who are interested, I just successfully updated my Dual Strike to 2.0.0 using WinXP running inside VirtualBox on my OSX 10.6
I also flashed my edited firmware (for Jab+Start=Home) and that works, too. It does do Jab+Start for Home now, but it still sends the Jab signal. I’m pretty sure it’s because the Select+Start bit in ps3.c has an if bit (if Select+Start then Home, otherwise if Select then Select, otherwise if Start then Start), so I’m going to try rearranging the Jab bits which should sort it out. Still, I’m very happy with my silly non-programmer self for getting this far!
Also, configuration editor worked fine as well.
The way I did it was to manually add USB filters for the Dual Strike’s different modes into VirtualBox. There are three I’m aware of so far (normal controller mode, firmware flash mode and PC configuration mode) and I had to add each for them to work properly on the XP virtual machine. Even if you could probably hand over the Dual Strike to the VM each time you changed the mode, I felt safer about forcing VirtualBox to only use it in XP mode and not share it with OSX to minimise any issues.
I’m going to try that now. I think I need to install libusb first (when trying make, it mentioned usb.h is missing).
Sorry, I don’t get it :wtf: What’s interface enable/disable?
I suppose you mean Dualstrike The connection check is a process that is run every second, so it shouldn’t have to download and parse an EEPROM file - with the Atmega168 of the DSV2 it would take considerable time.
I mean something like this: user opens the configuration editor, but has another device still connected he doesn’t want to program, as he intends to plug in the other device before programming. Another use-case for not wanting to download the configuration is if you just want to load your configuration file (containing a button mapping or so) and save it to the device - first loading the device would make it longer.
On the other side now all the user has to do to get the current configuration is one click - I think that’s worth it. But we could set up a kind of user experience questionnaire to find out what is wanted.
It’s just a matter of deleting lines 75-80 in configuration.xml and update lines 23-25 accordingly… you can play around with it…
It just occured to me that the firmware update didn’t include the a firmware image for the ATmega168 DSs like the V2… but now the archive is updated… (dual_strike_update_168.bat)
By the way: in the afternoon I get a wisdom tooth extracted - let’s see when I get to look in here the next time…
disable the interface… lock the radio buttons and drop down boxes and buttons until the connection has been checked… re-enable it once a connection has been made and verified… i’m guessing its possible for the app to monitor USB and wait to see if dualstrike has been plugged in before verifying?
But thats exactly my point… a lot of people wont read a FAQ or instructions (or edit xml, or edit code, or fill out a questionaire, or read through the thread, etc)… most will just plug it in and expect it to work… so at the very least, it should be intuitive for someone to use without reading any instructions whatsoever… for example, maybe when the application launches, make a dialogue box that says “please hold select while plugging in dualstrike. then click OK once this is done” and then load the application… maybe instead of a up and down arrow, make the buttons large with text that says"get config from masterstrike" and “save config to dualstrike”… for the inverted trigger options, most people will have no idea what this is… maybe an extra text that says this does not need to change for TE stick owners… the application was made precisely to allow people not to have to deal with reading how to config dualstrike the old way right? i deal with a lot of users at my work who do not read or have trouble with instructions… so i’m used to having to make things completely beginner friendly
I’m wiring up my Dual Strike to my 360 MS official common ground wired controller PCB right now and am wondering how the inverted triggers are dealt with:
The point on the controller PCB where the triggers are has three solder pads - top, middle and bottom.
Currently, a wire from the top pad runs to one leg of the relevant button on the arcade stick, and the middle pad (with the controller oriented in the proper direction with the USB cable upwards) goes to the other leg of the button. There is a ~4KOhm resistor between the middle and bottom pads.
I’m assuming one of the wires goes to S3 and the other goes to pin 13 (HK)? I’m only interested in RT, I have no need for LT at all (yet, but I imagine LT is dealt with by S4).
I’m wondering if it matters which wire goes to 13 and which to S3. I wouldn’t want to start short-circuiting my Dual Strike, seeing as neither of the legs from my RT-wired button go directly to ground like the others do.
I think I found a bug in the configurator.
I’m talking with Gummowned trying to get my stick to work lol, but this is a kind of unrelated issue.
I think it has something to do with the reading of the board’s data.
I set the s3 and s4 to trigger inversion, but when the configurator loads it, it shows Joystick Switch Emulation.
It happens when I set it manually through the hardware option and through the configurator, so I’m guessing its a read issue.
It’s the late wired version, the early wired one has the matrix ground. I currently have just one ground point wired to all the buttons/directions just like on my PS2 padhack and it works fine.
That’s strange. It works fine for me. I set it to trigger inversion in the config program itself and it still shows up as that now…
I confirm this, it was an issue with the decoding of the configuration bits for choices - I fixed it and updated the DS FW 2.0.0 configuration editor archive. Thanks for pointing that one out!
I for myself wouldn’t want to have such a behaviour…
I think we have quite different views for what such a program should do. What you propose is more of a Wizard-like interface. But that should be doable with limited effort, now that I’ve written the infrastructure.
What I aimed at was a flexible configuration editor that isn’t just aimed at the Dual Strike, but to be usable for arbitrary USB-devices. The UI philosophy is aimed at users who do minimal program exploration (looking at the menu, waiting for the tooltip if a function is unclear) than at someone who uses a computer for the first time. A wizard would require much more project-specific customizations and thus either lost-flexibility or else much increased complexity in the program.
For the more instructions thing: There are tooltips on every control element. In an early prototype we had buttons with text instead of upload/download buttons, but settled for a nicer looking and more compact toolbar. The icons used in the toolbar are the same as in the menu, so finding out the meaning without using the tooltip shouldn’t be hard anyways.
All in all I think someone (maybe me when I got the time, but there is an exam coming and there are some things in the pipeline) should make a Wizard-like Dual Strike configurator, if there is enough user demand.
A model 24 is common ground for sure… you can go to gamestop or any used game store and ask to see a used wireless 360 controller… open the battery compartment in the back and look for the xxxxxxx-024 on the label just above the barcode… i recall finding that a model 56 was also common ground, but dont take my word for that…
It seems that the Dual Strike SMD board I have is having some passthrough trouble.
I’m gonna meet with Gummowned to see if we can fix it, but in the meantime, I’m going to move my wiring over to imp/cthulhu.
Also, I think i might have found an error. My Dual Strike only seems to go into passthrough mode when I hold LP and not any of the other buttons.
I dunno if this might because of the passthrough not working, or because of something else.
Sorry for this - at some stage it was planned to integrate more working mode into this firmware, but due to the EEPROM (i.e. configuration) programming there is not enough space in the ATmega8s (the microcontroller of DS V1 and SMD) - but the behavior wasn’t reset in accordance with the readme. It is fixed now, I also ran into a problem which caused a pass-through device not to work after entering the programming mode.
My apologies for these bugs
Here are the links:
[LIST]
[]Firmware Update 2.0.1
[]Firmware Source 2.0.1
[/LIST]
My DS SMD passthrough wasn’t even working with the old Firmware (1.2) and wouldn’t work even with programming mode, so I think my specific DS issue is board related, but I’m glad I could be of help with your bug/readme fixing!
I had a similar problem, which I solved by using a shorter USB cable - my TE’s USB cable I first used was extremely bent when I first modded it, so I suppose some wires were broken/damaged. Maybe you have the same issue…
