Hacking Gamecube to Classic Controller Converter 2 questions

[bootsector]

Added analog shoulder (L/R) buttons support on the Wii RetroPad Adapter:

https://gitorious.org/wii-retropad-...mmit/025af6050d16089a4caf7a51be90396b775213cb

Classic Controller emulation is now able to inform the analog shoulder button values (was fixed to 0 in previous versions). Also changed the NGC controller polling routine so it maps its analog values to the CC values (a simple division by 8 should also do it).

I will be able to test it by this weekend.

Edit: Just tested with WiiuseJ under Windows and GC shoulder buttons analog values are being mapped correctly to the Classic Controller!

bootsector

 

[gummowned]

Can you two check over the analog sticks. In the wpa I built, the gc pad right analog stick doesn't seem to be registering properly. The corners don't get recognized. Also when I use a ps1 pad, the left analog will keep registering a down input every few seconds even when nothing is pressed on the pad. I've tried with 3 different ps1 pads and it still happens.

I did lower the ANALOG_NEUTRAL_RADIUS value in wpa.cpp and that did help me out with the gc pad issue I was having.

 

[bootsector]

Can you two check over the analog sticks. In the wpa I built, the gc pad right analog stick doesn't seem to be registering properly. The corners don't get recognized. Also when I use a ps1 pad, the left analog will keep registering a down input every few seconds even when nothing is pressed on the pad. I've tried with 3 different ps1 pads and it still happens.

I did lower the ANALOG_NEUTRAL_RADIUS value in wpa.cpp and that did help me out with the gc pad issue I was having.

For the GC right analog stick, please try it with the most recent code, I think I've just fixed it:

https://gitorious.org/wii-retropad-...mmit/958969626af182ea1eb54e3b733652103cd5d7b2

As for the PS1 pads, experiment different values for both CTRL_CLK and CTRL_BYTE_DELAY from PS2Pad.h. The current default values were tested against several original analog and digital PS1 pads and also several original and chinese knock-offs PS2 pads and they seem to work great.

bootsector

 

[bootsector]

Just out of curiosity, does anyone here has a Wii U and also a Wii RetroPad Adapter? I would love to hear reports on how it behaves on the Wii U!

 

[gummowned]

Just out of curiosity, does anyone here has a Wii U and also a Wii RetroPad Adapter? I would love to hear reports on how it behaves on the Wii U!

I have a Wii U and is what I've been using to test with. It will work on the home screen but I don't have any Wii U games that supports the CC.

 

[qwertymodo]

I have a WiiU, but I left my breadboarded WRA back on campus. I head back on Saturday, and I'll play around with it then, but only on vWii VC/homebrew. I also don't have any CC-compatible WiiU games.

 

[bootsector]

I was getting random start/home button presses when I tested a new Japanese GC pad with the WRA. I realized that function calls was introducing undesired delays. I think I have it fixed now:

https://gitorious.org/wii-retropad-...mmit/6e861a39d1963d6aad2533419778d9012a0fa393

 

[qwertymodo]

I just got myself a Bus Pirate, so when I get back on campus with the rest of my gear, I should be able to sniff out the I2C communication and see if I can figure out the ID bug. Other than that, it's looking pretty good.

 

[wiiluver135]

so...how is the progress coming and when can we see a release to buy?

 

[qwertymodo]

so...how is the progress coming and when can we see a release to buy?

I'm not sure if I posted this earlier or not, so I'll just lay out the timeline here. I'm back on campus, with access to all of my equipment, including my shiny new soldering station and handy new Bus Pirate. I ordered plastic enclosures for the PCB's (so there will be a small plastic box in the middle of the cable, but hopefully it's small enough to not be annoying), and I am currently waiting for them to arrive. They just cleared customs, and should get here sometime next week. Once I have them in hand, I will be able to finalize the PCB outlines (the PCB design is already finished, I just need to make sure that the outline of the board fits nicely with the inner dimensions of the enclosure). Once that's done, I'll send off the PCB designs to have them manufactured. This usually takes several weeks, especially factoring in economy shipping from China. During this time, I'l be ordering the rest of the parts, which should arrive much sooner than the PCB's. I'll also be working with my breadboarded prototype to try to figure out the one bug that's still annoying me (the ID bug), seeing as how bootsector has already added analog trigger support with the info I provided. I'm also going to look into something interesting I found on raphnet.net about joystick calibration that might make the left joystick "feel" better, but we'll see.

So basically, right now I'm just waiting on parts. My first run will probably be 20 or 30 units, and if they sell, I'll order more. The one issue I have right now is that it's a pretty big chunk of change I have to sink in to this up front, and I already have a large amount of my disposable income tied up in other electronic projects that I'm trying to sell as well (if anyone wants an N64 memory card that doesn't require a battery and won't ever lose your saves, or an SNES controller modded either as a classic controller or USB controller, with optional internal flash memory, hit me up... </shameless plug>). So hopefully, I'll have enough in my next paycheck to place all of the orders and get this show on the road.

 

[bootsector]

Good news! It looks like I've now perfected N64 and GC pad support. I was getting weird random buttons presses when using any GC pad. It takes some time to start happening, and it's random. GC pad driver disables global interrupts several times per second, and that was messing up with the I2C driver (mainly inside the set_button_data method). From my tests, it seems perfect now! I would like to hear the reports from people who are able to update their WRAs with the latest code from gitorious.

@qwertymodo:

I really hope you can identify and fix the old IOS reboot identification issue. I suspect old IOSes extension detection during reboot is very primitive (maybe a single polling at early stage, where the AVR I2C hardware might not be initialized yet?). I used to have a Saleae protocol analyzer here (I've used it a lot to perfect Android support, since most of the chinese knock off CCs aren't supported by the Android driver), but a friend has borrowed it from me.

Anyways, newest VC games don't seem to suffer with this problem (it happens with Ocarina of Time, Super Mario 64, but it doesn't happen with SMB3, for example). It also doesn't happen with any homebrew nor Wii games that I've tested so far, which is a good thing!

bootsector

 

[bezem]

I love watching the progress in this thread and look forward to getting 2-4 adapters. I'd also be interested in an SNES CC and N64 memory card depending on cost and my available funds. Priority (for me atleast) would be the adapter for GC controllers.

 

[gummowned]

I just realized I have 30 atmega168a-au chips just laying around that I could use for this project. They were left overs from making ps3 usb controller boards for arcade sticks. I ran out of the un-assembled pcbs for it and never made any more, but I still have some assembled boards that are dead/defective that I could reuse.

 

[qwertymodo]

Ok, so I've figured out something that may help with the ID bug. The Wiimote maintains power to the extension device throughout an IOS reload. This leads me to believe that the code responsible for setting up the "old" vs "new" encryption settings only works on initial powerup, and doesn't properly switch between modes once the "new" mode has been set (i.e. by newer versions of IOS such as the system menu IOS). My guess would be that the culprit is WMExtension::receive_bytes(), though I need to sort through it a bit to see if I can understand what's going wrong.

Edit: I've confirmed my suspicions by externally powering the microcontroller and then unplugging/re-plugging it in to the wiimote, and it doesn't work (it just stays at the You need the Classic Controller screen) until I power cycle the microcontroller. Still trying to actually *find* the bug, but at least I understand it a bit better.

 

[qwertymodo]

Ok, so here's the issue. This conditional statement is never resolving to true (WMExtension.cpp, line 148):

// Wii is probably trying to setup old encryption mode
if(addr == 0x40 && d == 0x00) {
    old_crypt_key_received = 1;
}

This is frustrating, because I can almost guarantee that the problematic titles are using "the old way" of IDing extensions, which should trigger that conditional block >.< It looks like the Bus Pirate isn't going to be up to the job of sniffing the Wiimote communications, as the current I2C sniffer only works up to 100KHz, and the Wiimote is communicating at 400KHz. More poking around in the dark it is then...

 

[bootsector]

Fixed. It looks like 0xAA is 0x55 in Wiimote encrypted form (I'm lazy to calculate this):

https://gitorious.org/wii-retropad-...mmit/213a0ead7cf65e33d93cd55cccecf81408730690

Got my Saleae back. I2C data attached to this thread.

Thanks qwertymodo for the motivation to revisit this.

bootsector

 

[qwertymodo]

Sweet, that did it

 

[gummowned]

You ever consider using the wii plus adapter as a casing? I managed to fit the board inside and reuse the female socket to plug the gc cord into. I had to modify the socket a little bit, but it wasn't anything too crazy.

 

[qwertymodo]

Sure, it can be done, no it's not something I'd want to do for 30 of them to sell. Also, the GC is the one controller that would work for, seeing as how the electrical contact portion of the connector is identical between GC controllers and wiimote extensions.

 

[qwertymodo]

Well, it's not a GC adapter, but I did get in my SNES adapter PCB's today. I didn't have any Atmega 328's, so I tried to use an Atmega8-16 instead. It has the same pinout and it compiled fine (after some optimizations to save space), but it's not working Oh well, I took pictures because it still turned out awesome.

You can see I removed the cable header and mounted the board in its place:

Nice and clean on the front side of the PCB:

Here you can see it sits nice and flush against the controller board:

Clean and unobtrusive:

The controller closes back up nicely with absolutely no modifications to the shell:

I'm going to have to play around with it a bit more to see if I can figure out what's wrong with it, but for now, I'm still quite pleased with how it turned out

bootsector, do you have any idea why the Atmega8-16 wouldn't work besides the limited Flash space? I managed to cut down the size by about 60% by commenting out the switch statement in loop() and just pointing it at snes_loop() regardless, which caused the compiler to drop the code for all of the other controllers and shrink the binary enough to fit in 8Kb.