Universal wireless controller for SNES, Saturn, N64, etc....

Started by micro, February 15, 2011, 03:06:53 AM

Previous topic - Next topic

DNSDies

So, it's no longer using an ATTiny2313 for the transmitter and ATMega8 for the receiver?

Did the value of the resistors and capacitors, or their placement change?

I can see from his previous pics he's still using the same NRF wireless module, just with a psuedo-SMD quick solder pad.

The only real difference I see that can't be ported over to the hobbyist-friendly 1.1 design is:
1) integrated Li-Po charge circuit
2) Software Power on/off
3) Possibly a different microcontroller? I can't read the markings on the pics he posted in the V2 thread.

I don't care that much about the lower power draw.
even at 5ma, a 230mah lipo will last over 25-30 hours between charges.

That's ludicrous.

I'd prefer to make it possible for an amateur hobbyist to make their own with cheap and easy to use through-hole components, and use a single separate charger to keep costs down if you end up doing this on like EVERY console you own.

I've got a NES, SNES, Genesis/SCD, Saturn, Dreamcast, Atari 2600, and a TG16 I'd like to make wireless controllers for, but I don't want to have to buy a custom PCB with pre-soldered SMD components to do it.

micro

I'm sorry, but I definitely won't release a new v1x version with the new RF protocol. That's for sure...

I think I already said that I won't work on the old v1 code any more. That includes support for new systems as well as other new features. I just released smaller fixes like adding a pull-up which I forgot to implement in the first place.

You're right, I'm using a different microcontroller with v2: Atmega48A on both receiver and transmitter. But that's not the actual show stopper. It's the old code itself which is written in assembly language. And who wants to work with that mess? I don't, that's for sure! That's the reason why I've rewritten the whole code from scratch in c for v2. Compatibility with v1 wasn't on my list.
Even if it wasn't for the different programming language and different microcontrollers the new RF protocol still wouldn't work on the v1 hardware setup because it needs a 16 MHz clock on the receiver.

The hobbyist-friendly v1 (as you put it) will always be available. It won't fade away just because I'm working on v2 atm. So I don't quite understand your problem...

ours1011

Quote from: micro on August 16, 2013, 03:28:13 AM
Ok, then. On your receiver, please add a 10 kOhm between "VCC" and "P/S" (pin 4 and 20 on the Atmega8)
It seems on some PAL SNES consoles that pull-up resistor is required.

Let's hope this fixes your wireless controller, but there are still 100 other ways to fuck up ;P
Hi micro !

I finally had the time to come back to this project, and I can tell that adding the 10k pull up resistor between Vcc and P/S on the receiver is working !

But I still have a problem, on the transmitter side this time ...
I don't have anything that comes out of the ATtiny2313 on pin 6 (0v instead of snes pad Vcc)

micro

Haha, one year later....  ;D

Are you sure VCC for the SNES controller is 0 V? The SNES controller is only powered once per frame for acquisition of the controller button states. With your multimeter you'll measure the RMS and it shouldn't be exactly 0 V but something like 0.1 V or 0.05 V.

ours1011

Yeah, better late than never :)

I had some time consuming projects to do since last year ... ^^

If I remember correctly I had 0.06V. But nothing more seemed to happen.
I tried to flash the ATtiny again (with v1.2) and did some shit with the fuses. I swapped them and since now I'm unable to reprogram it.

An other one is making it's way to my mailbox, I'll keep you noticed :)

ours1011

I've got my new ATtiny2313 and this one is working :)

The flash was correct with v1.2, so I re flashed the ATmega8 too with v1.2
Th receiver is still working fine.

I now have 0.033V at pin6 of the ATtiny2313 and it still doesn't work... !

I've checked, the 0.033V are in the controller too (I still have the 2m of cable attached)
The RF module has it's 3.3V so it isn't fried this time.

I'm going to double check all the connections, as I don't know what is going wrong.


ours1011

Everything is (was) working fine.

I just forgot to put Pin2 of the atmega8 on the receiver to gnd to behave as controller 1 ... !

jacobsson

#368
@micro

Hi buddy!
I'm on the project of building the DIY "V1" SNES Controller (yes, it's a 3rd party controller).
I was thinking also adding a USB (female) interface to the receiver, I've seen some "SNES to USB" tutorials so I guess it should be pretty straight forward?
I've programmed the Attiny2313A and Atmega8 so now I'm test-assembling the controller with the largest components:

It closes up pretty well like this too.

The 750mA GBA battery should give me a pretty good amount of hours! =)

ours1011

Quote from: ours1011 on August 25, 2014, 07:14:33 AM
Everything is (was) working fine.

I just forgot to put Pin2 of the atmega8 on the receiver to gnd to behave as controller 1 ... !
Now that everything is working, a SMD version of it is on it's way :D
I'll keep you updated !

jss_josafa

Micro Hello, I wonder if this project v1.1 is compatible with NTSC SNES control?

jflatle1

I'm hoping this thread is still somewhat alive. I've attempted to make the N64 controller but when I plug it in it says no controller found. When burnign the fuses on my MCU using avrdude it would say that EE fuse was updated instead of High, but when I went back to verify it would say the High fuse was set correctly. Hoping someone might see an issue with my set up, thanks!

https://plus.google.com/+JohnFlatley1/posts/6FeD1RQ4Sv3

flagoss

Quote from: jss_josafa on September 13, 2014, 01:55:46 AM
Micro Hello, I wonder if this project v1.1 is compatible with NTSC SNES control?

I can confirm that it works perfectly with a NTSC SNES

micro

Quote from: jflatle1 on March 26, 2015, 09:14:50 AM
I'm hoping this thread is still somewhat alive. I've attempted to make the N64 controller but when I plug it in it says no controller found. When burnign the fuses on my MCU using avrdude it would say that EE fuse was updated instead of High, but when I went back to verify it would say the High fuse was set correctly. Hoping someone might see an issue with my set up, thanks!

https://plus.google.com/+JohnFlatley1/posts/6FeD1RQ4Sv3

So if you read the fuses now, they have the correct values?

jflatle1

@Micro - yes, here is the output from AVR dude for the ATtiny2313 AND ATMEGA8

avrdude -c usbtiny -p attiny2313 -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e910a
avrdude: reading lfuse memory:

Reading | ################################################## | 100% 0.00s

avrdude: writing output file "<stdout>"
0xdf
avrdude: reading hfuse memory:

Reading | ################################################## | 100% 0.00s

avrdude: writing output file "<stdout>"
0xdf
avrdude: reading efuse memory:

Reading | ################################################## | 100% 0.00s

avrdude: writing output file "<stdout>"
0xff

avrdude: safemode: Fuses OK (H:FF, E:DF, L:DF)

avrdude done.  Thank you.

###################
###################

avrdude -c usbtiny -p atmega8  -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9307
avrdude: reading lfuse memory:

Reading | ################################################## | 100% 0.00s

avrdude: writing output file "<stdout>"
0xee
avrdude: reading hfuse memory:

Reading | ################################################## | 100% 0.00s

avrdude: writing output file "<stdout>"
0xdf
"efuse" memory type not defined for part "ATmega8"

avrdude: safemode: Fuses OK (H:FF, E:DF, L:EE)

avrdude done.  Thank you.


micro

We should focus on the receiving circuit only at this point. As long as the N64 can't detect the controller, the whole thing won't work - obviously. :)

Here are some things you could try:

1) Temporarily remove the 16 MHz crystal. Try to read the fuses with AVRdude. AVRdude should give an error, it shouldn't even be able to detect the microcontroller type with the crystal removed. If that's the case - good! Insert the 16 MHz crystal back to the breadboard.
But if you don't get any errors though, then the fuses are not set correctly

2) Temporarily remove the NRF module from the receiving circuit. Maybe it's broken or you've messed up the wires. Even without the NRF module the N64 should detect the receiver as a valid controller.

3) I had a look at your pics again. It's a little bit messy, I can't make out the whole thing. But I'm wondering where's your data wire that should connect to the Atmega8's pin 4? It seems you've connected GND and VCC from the controller cable but I can't see data...?

jflatle1

Quote from: micro on March 30, 2015, 05:31:32 AM
We should focus on the receiving circuit only at this point. As long as the N64 can't detect the controller, the whole thing won't work - obviously. :)

Here are some things you could try:

1) Temporarily remove the 16 MHz crystal. Try to read the fuses with AVRdude. AVRdude should give an error, it shouldn't even be able to detect the microcontroller type with the crystal removed. If that's the case - good! Insert the 16 MHz crystal back to the breadboard.
But if you don't get any errors though, then the fuses are not set correctly
We're good here, didnt detect the microcontroller:
avrdude -c usbtiny -p atmega8  -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h

avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.
Quote
2) Temporarily remove the NRF module from the receiving circuit. Maybe it's broken or you've messed up the wires. Even without the NRF module the N64 should detect the receiver as a valid controller.

Removed it, but mario tennis is still not recognizing the controller. Tried mario kart 64 and blitz as well with the same result.
Quote
3) I had a look at your pics again. It's a little bit messy, I can't make out the whole thing. But I'm wondering where's your data wire that should connect to the Atmega8's pin 4? It seems you've connected GND and VCC from the controller cable but I can't see data...?

Sorry about that, I stripped off some more of the cord so hopefully you can see it better now in the picture. I added LEDs to each rail to make sure it was getting power and they are. Attached a new photo

micro

Well, your setup looks ok to me!

I don't know why it's not working. You could/should add a 100nF capacitor close to the pins 7+8 of the ATmega8. If it's still not working you could try to add an pull-up resistor (let's say 1kOhm) between 3.3V and pin 4 (data wire) of the Atmega8.

Also consider to try out a different crystal.

One last thing: The N64 cord you're using, is it from a genuine Nintendo 64 controller? (3rd party extension cables sometimes got a different color coding for 3.3V, gnd & data.)

jflatle1

Good news: I moved the 100nF capacitor closer to pins 7 & 8 and my N64 recognized the controller.

Bad news: Still couldn't get the controller to work so I took a voltmeter to see if the wireless component was getting power and somehow shorted the whole system. Literally the whole N64 system and now it won't even turn on... I didn't even know that was possible. So looks like I need to invest in a new one and I'm guessing all my receiver components are fried as well...

micro

That's bad!

If you're lucky you just killed a fuse inside the power supply unit.

jflatle1

Looks like I am lucky and it was the power supply. I tried plugging the receiver back in and the system recognized it as a controller. Does that mean that my microcontroller is okay? I'm still not able to get the controller to work, are there any other debugging techniques I can use?

IonBlade

I'm planning on building a set of N64 wireless controllers, and have a few questions:

1) Putting together the parts list in the US, I can't seem to find the exact 16 MHz crystal used in the receiver.  The closest I've found is http://www.digikey.com/product-detail/en/ECS-160-20-4/X176-ND/83017, which has a 20pF load capacitance rather than the 32 in the original parts list.

From the very little I understand about circuits from doing some Googling tonight, if the load capacitance is too low, then the clock can run slightly fast, and that in some circuits that's no big deal, while in others, it's a problem.  Does anyone know a 20pF crystal like linked above will work in the receiver without any issues?

2)  I live in an apartment with *tons* of competition in the 2.4GHz range (my laptop picks up 20-30 2.4 GHz APs).  Anyone else in this situation, and how have the controllers worked for you?  Should I be looking at getting some of the wireless modules with antennae available on eBay, or are the antennae built into the PCBs like used in the guide good enough in congested areas?

3) There were a couple of posts midway through this thread that indicated the mod might only be compatible with certain revisions of N64 controllers, but I didn't see much more discussion about that.  Was that ever validated?  I couldn't quite tell from the pics what the reported "good" PCB's revision data was to check mine.

lord_bahamut06

#382
Hello everyone! I am attempting this project, but am completely new to micro-controllers. I have a few question regarding programming the ATTiny and ATMega.

I have a USBASP programmer, with a 10 pin layout. Im assuming that the MOSI, MISO, RESET, and SCK connect directly to the corresponding pin on the chip, but my first question involves the power (+5v)? and GND. Should i connect the power directly to the chip? or do i need something in between to regulate? i apologize if the schematic covers this. i dont have anyone that knows how to do this, and am trying to accomplish it alone, which is turning out to be difficult. also, do i connect the GND directly to the chips GND? Do i need to connect all of the GNDs from the programming cable to the chip/breadboard? 

Here is a little bit more information, in case you need it to answer my questions. I am using a breadboard to program the ATTiny first. i do not have a pcb board built to reroute the wiring from the cable (10-pin), but am attempting to connect the programmer cable directly to the breadboard via wires for the time being. This will most likely change in the future, but for now, i dont want to solder and make anything permanent until i fully understand exactly what im doing. I see the + and - on the breadboard, and know how the lines run, but am unsure how to connect them to the programmer/chip. The programmer is USB, and powered, with a jumper set for 5v. If i understand the instructions properly, i should be able to power the chip using the programmer, or if i chose, another method (though im assuming using the programmer would be easier.)

Thank you in advance!

*Edit*- I figured this out, but have another question. I loaded the hex file onto the microcontroller, then changed the low fuse, and then when attempting to change the high fuse, it returned an error. Im assuming  that means that i need to introduce the crystal into the loop somewhere. Where would this be?

Alcahest

Still waiting for Micro to release DIY kits for SFC pads/receiver!

In the meantime, a company has come with this somewhat related product:
http://www.8bitdo.com/sfc30/

Seems nicely done, but of course doesn't come with a BT receiver that connects to SFC :S

flagoss

Quote from: Alcahest on May 15, 2015, 07:42:51 AM
Still waiting for Micro to release DIY kits for SFC pads/receiver!

In the meantime, a company has come with this somewhat related product:
http://www.8bitdo.com/sfc30/

Seems nicely done, but of course doesn't come with a BT receiver that connects to SFC :S

Oh !! I dream of a blutooth receiver for the SNES or SFC !! That would be awsome.

IonBlade

Quote from: lord_bahamut06 on May 12, 2015, 08:42:00 AM
I loaded the hex file onto the microcontroller, then changed the low fuse, and then when attempting to change the high fuse, it returned an error. Im assuming  that means that i need to introduce the crystal into the loop somewhere. Where would this be?

Just finished that myself, and learned the lesson to burn the flash first, then the high fuse, then program the low fuse last.  You're correct that if you program the low fuse at the same time as the high (or before), the chip expects an external clock signal immediately, and doesn't finish setting the high fuse. 

For the Tiny2313, hook up pins 4 and 5 as shown in the diagram in the TX schematic (4 should be connected to one leg of the 8m crystal and one leg of a 22p capacitor, 5 should be connected to the other leg of the crystal and one leg of another 22p capacitor.  The remaining leg of both caps should be connected to ground). 

For the Mega8, hook up pins 9 and 10 as shown in the RX schematics (same as above, but using pins 9 and 10 instead, and using a 16m crystal).

Once you hook up the crystal on pins 4/5 (2313) or 9/10 (Mega8), the chip should start responding to the programmer again and you'll be able to flash the high fuse.

lord_bahamut06

Quote from: IonBlade on May 17, 2015, 05:19:36 PM
Quote from: lord_bahamut06 on May 12, 2015, 08:42:00 AM
I loaded the hex file onto the microcontroller, then changed the low fuse, and then when attempting to change the high fuse, it returned an error. Im assuming  that means that i need to introduce the crystal into the loop somewhere. Where would this be?

Just finished that myself, and learned the lesson to burn the flash first, then the high fuse, then program the low fuse last.  You're correct that if you program the low fuse at the same time as the high (or before), the chip expects an external clock signal immediately, and doesn't finish setting the high fuse. 

For the Tiny2313, hook up pins 4 and 5 as shown in the diagram in the TX schematic (4 should be connected to one leg of the 8m crystal and one leg of a 22p capacitor, 5 should be connected to the other leg of the crystal and one leg of another 22p capacitor.  The remaining leg of both caps should be connected to ground). 

For the Mega8, hook up pins 9 and 10 as shown in the RX schematics (same as above, but using pins 9 and 10 instead, and using a 16m crystal).

Once you hook up the crystal on pins 4/5 (2313) or 9/10 (Mega8), the chip should start responding to the programmer again and you'll be able to flash the high fuse.

Thank You! I have the crystals ordered, and should be able to finish this as soon as they arrive!

jss_josafa

Quote from: flagoss on March 27, 2015, 12:19:46 AM
Quote from: jss_josafa on September 13, 2014, 01:55:46 AM
Micro Hello, I wonder if this project v1.1 is compatible with NTSC SNES control?

I can confirm that it works perfectly with a NTSC SNES

:D. Thank you friend!
if not too uncomfortable, could let me know if you need to use the crystals to control SNES?

ekalebaugh

Hello micro and others. I just finished making a pair of NES controllers following your project. Everything was successful and i have two working remotes and receivers. I'm having an issue with range and/or packet loss on the nrf modules. I have perhaps a maximum range of 20 ft from the console before I lose all apparent communication with the receiver. From just inside of that to about maybe 5-10 ft away depending on the angle I have spotty interaction with it, meaning what looks like packet loss. Some button presses will go through, some will lag maybe a .5 second behind and many others simply never seem to reach the receiver. I didn't think RF would be too affected by a couch arm being in between transmitter and receiver, but that also seems to present a problem. Does this sound familiar to anyone? Something to just live with or do the modules need to be replaced? This was my first time working with MCUs and doing even this much circuit layout and soldering, but I'm fairly sure that if they work sometimes, then it's more of a hardware issue than something that I may have done wrong. That might be my ego talking though. I laid the innards out in the controller very similar to was Snoop did, if that has anything to do with the communication. Any help you guys can give this poor disappointed soul will be well appreciated. Thanks!

gorgyrip

Hi,
I have a question about the charger.
Is it ok if I set the max1811 to 500maH by connecting SELI to vcc?
I'm using a ds lite battery (1000maH) and a nokia battery (860maH).

lord_bahamut06

I also have a question about the max 1811. The "en"  on the specs enables the circuit. Should I just connect that to the incoming power as well as the "in"  pin?

And as much as I can tell, as long as your battery is rated higher than 500 mah, it should be able to charge on 500mah. I'm no expert though, obviously, and would defer to the more knowlagable members.

gorgyrip

Quote from: lord_bahamut06 on August 03, 2015, 07:29:00 PM
I also have a question about the max 1811. The "en"  on the specs enables the circuit. Should I just connect that to the incoming power as well as the "in"  pin?

And as much as I can tell, as long as your battery is rated higher than 500 mah, it should be able to charge on 500mah. I'm no expert though, obviously, and would defer to the more knowlagable members.

The EN and IN pins are connected to the 5v coming from the USB.
I've also connected SELI and SELV to vcc.
But i don't know. I did some tests. Maybe my batteries aren't too good.
Nokia bl-4c 860maH:
-charging time about one hour and 10-20 minutes.
-i connected the battery to a ds lite with maximum brightness and max sound. And with zelda inserted in demo mode. It lasted one hour and 40 minutes.

After that i charged the battery using the ds lite. It took 2 hours and 20 minutes.  Later i started the console and the battery discharged in 2 hours and 30 minutes.

SO HWY max1811 isn't charging the battery properly?
PS: the caps i used for the charger are 4.7uf electrolytic and the resistor for the led is 1k.

If i set the IC to 100maH, the battery charges normaly and it lasts as it should.

Any ideas why it isn't charging ok if i set the IC at 500mah?
Also, should the voltage drop on the battery if i cut the 5v power?

jss_josafa

Hello guys! I would like to take one more question.
To save the file .hex can use the G540 universal programmer?
it is usb, did the recording for it, then I do not know if the problem would not work it.
Thanks in advance. 

lord_bahamut06

Quote from: gorgyrip on August 03, 2015, 09:00:10 PM
Quote from: lord_bahamut06 on August 03, 2015, 07:29:00 PM
I also have a question about the max 1811. The "en"  on the specs enables the circuit. Should I just connect that to the incoming power as well as the "in"  pin?

And as much as I can tell, as long as your battery is rated higher than 500 mah, it should be able to charge on 500mah. I'm no expert though, obviously, and would defer to the more knowlagable members.

The EN and IN pins are connected to the 5v coming from the USB.
I've also connected SELI and SELV to vcc.
But i don't know. I did some tests. Maybe my batteries aren't too good.
Nokia bl-4c 860maH:
-charging time about one hour and 10-20 minutes.
-i connected the battery to a ds lite with maximum brightness and max sound. And with zelda inserted in demo mode. It lasted one hour and 40 minutes.

After that i charged the battery using the ds lite. It took 2 hours and 20 minutes.  Later i started the console and the battery discharged in 2 hours and 30 minutes.

Thanks! Im just waiting on usb breakout boards, then i should have some working transmitters! :)

gorgyrip

If i turn on the snes controller without a console and a receiver, the power consumation will be the same like when you are playing? Or it will be in some kind of sleep mode?

jaskamakkara

micro, if I replace the normal power LED that goes into the controller with an RGB or dual-coloured LED, is it possible to have the LED display a different colour depending on which channel is selected?  My hope is to make it so that the receiver will have a similar LED that changes colour based on the channel chosen (very easy modification to the design, simply make the channel switch 2P2T and wire the LED with +3V onto one pole and Pin 2 of the AtMega with GND on the other), and the user can visually see which controller is connected to which port.

In other words; when the channels are selected on the controller, do certain pins on the ATTiny simply swap between high / low? With that info I could maybe just wire the LED legs onto those pins for the desired effect.

Thanks

micro

I'm sorry guys, but I'm afraid you're on your own!

@jaskamakkara: I think you would need to dig into the asm source code and make an output pin toggle between low and high depending on the selected channel. I definitely won't do it...

@gorgygrip:
power consumption
When the controller is turned on but you don't play the power consumption will be lower BUT the led is still on on it does consume about 1mA which is about 50% of the general power consumption.

battery charging
Well setting the voltage to 4.2V is ok I guess. But I wouldn't crank up the charging current to 500 mA. Even when the LED on the charger turns off the charging process isn't finished. The IC charges the battery with the CC-CV method. That means constant current - constant voltage. In the 1st phase the battery willbe charged with a constant current (say 100 mA). The battery voltage will rise from 3.6 V to 4.2 V. Now the LED should turn off and  the charge IC stops pumping 100 mA into the battery. Instead it will hold the battery's voltage at 4.2 V and the charge current will slowly decrease. Eventually the charge current will be 0 mA (or close to 0 mA at least) and the battery will be as full as it gets. :)

@ekalebaugh:
I think there's nothing you can do. That's just the type of problems that can occur depending on your WiFi situation in your home. The rf protocol used is not very robust. That's why I'm working on v2 of the mod which is much, much more reliable.

I really don't recommend doing this mod anymore!



jaskamakkara

Quote from: micro on September 13, 2015, 02:59:19 AM
@jaskamakkara: I think you would need to dig into the asm source code and make an output pin toggle between low and high depending on the selected channel. I definitely won't do it...

...That's why I'm working on v2 of the mod which is much, much more reliable.

OK, thanks micro I'll take a look at the v2 :-)

Diminuendo

Quote from: micro on September 13, 2015, 02:59:19 AM
I really don't recommend doing this mod anymore!

Is there anywhere we can download the v2 stuff to make our own?

sideskroll

Hello @micro and @everyone else.
First of all, let me tell you that I find what you did here FASCINATING. I wind up here cause I was looking at how to fix some crappy third party wireless controllers I have...
Anyway, I have a question for you that I would really appreciate if you could help me with.
Like I said I have a couple of crappy chines clones (these to be precise: https://www.impulso.com.pe/detalle.php?product_id=944) which are actually PS3 clones with everything and triggers instead of L-R2 buttons etc but for PS2. and I was wondering if it might be possible to somehow "transplant" the wireless properties to a couple of original wired SONY controllers I have.
They have integrated li-po (I think) batteries, charging ports and automatically turn off after 5 minutes of inactivity.
Anyway, would that be possible? I'm talking about keeping the recievers but transplanting the transmitters, batteries and charging ports to original DUALSHOCK 2 controllers.
Would you know what or how should I approach this? Is it even possible?
Any help would be immensely appreciated since these are my 3rd and 4th controller which stop working (mainly the analog sticks) cause like I said, they're Chinese cheap crap. you can even tell by the materials used...
Anyway, thanks to anyone who might try to help.