Project: N64 controller to SNES adapter; GOT IT WORKING!!

[declan]

That's right, I'm doing it again!
I'm wasting my time on another useless project.

Though this time i do have a few reasons:
1. I'm really keen to teach myself to program in asm (AVR asm that is), in order to interface serial protcols.
2. Because (after an extesive google search), noone else has ever attempted (or bothered) to do this.

So my progress:

Well i've got the hardware all finished. There's nothing really special about it. Just an Atmega8 microcontroller, its crystal, a voltage regulator circuit to drop the snes +5V down to the N64 +3.3V and last (but not least) a 1K pullup resistor on the N64 data line.

As for the firmware. I've got the AVR (the microcontroller i'm useing) to tell the snes, all the buttons are "0".
I've also got the AVR to send out the comand word to the N64 controller, and of couse, the controller responds.
There are still bugs though (as you might of guessed).
I can get the circuit to send out the status of about half the buttons, but they're in the wrong order. I'm currently in the process of eleiminating these last bugs.

Will post pics of the adapter soon. And will upload videos, when i get it working.

So, questions, coments or sugestions

[Rashidi]

something like this: (?)

• N64 Controler <----> Translator <----> SNES

[declan]

You bet!

Let me explain.

To the N64 controller.... my adapter is emulating an N64 console

To the SNES console.... my adapter is emulating a SNES contorller

So everybody is happy

[declan]

And now for some pics
First, here's my schematic:
http://i296.photobucket.com/albums/mm17 ... _SCH01.jpg
http://i296.photobucket.com/albums/mm17 ... _VRSCH.jpg


And a photo taken while debugging my progam:

As you can see, i'm using a very tired old CRO.... gets the job done though.

Pictures of the actual PCB:




I still have the ISP (In System Programming) wires attached, and some wires to "listen" to the clock, latch & data signals with the scope.

[Mark57Raider]

Oh that looks kinda cool, I know I don't have the smarts to do that. I just use my super nintendo controller for zsnes and playstation controller for nintendo 64 and playstation on the comp. That does however seem economically wasteful.

[declan]

Yeah, it is a bit stupid, i know.

But i wanted to get some experience, interfaceing serial protocols, using asm.

I chose this project because the snes uses such a slow protocol, about 12ms between latch pulses, and at 16 MHz, thats alot of clock cycles to play around with!! Ideal for a noob like me

[Mark57Raider]

So do you have an actual Super Nintendo controller you can plug that up to?

Or I guess that is for mapping the N64 Controller for super and N64.....

[declan]

I used a SNES controller extension cable to get the SNES plug, and an N64 controller exension cable for the N64 socket.

But now that i think about it.... I could recode the program, so i can have a switch attached to the circuit, and could make the adapter emulate a SNES mouse if desired.

The analog stick (which is curently unused in my adapter) would be perfect for that.

But unfortunatly, i had a lot of difficulty, getting the AVR to interpret the analoge data.

Yes i know.... its just two bytes of data, for the "X" and "Y" axis respectivly, and use 2's compliment so show a negative value.

So in theory, I could just test the MSB (most significant bit) of each byte to deduce if the byte is +ive or -ive, and if negative, use the "neg" instuction to convert to an equivilent positive value..[/rant]

But the code became too combersome when i tried map the analog stick to SNES's D-pad. I just wanted a nice easy "noob's" code..... for a noob!

[PHoNyMiKe]

I got an ATTiny261 hooked up to read a snes controller, shows data on a 2 line LCD too. here's my assembly code to read a snes controller, it has a cheap 'single click' routine so you don't have to poll as much.

[declan]

Did you use AVR studio to compile that PHoNyMiKe?

Your code looks heaps tidy, compared to mine.

How did you keep in sync with the snes?

I'm testing the latch and clock signals, using the plain old "sbis" and "sbic" instructions.

Code: Select all

LatchWait1:
 sbis 0x13, 5    ; Has latch started?
 rjmp LatchWait1 ; Not yet, keep waiting
 sbi 0x12, 0     ; Start snes data high
LatchWait2:
 sbic 0x13, 5    ; Has latch finished?
 rjmp LatchWait2 ; Not yet, keep waiting
 out 0x12, snes1 ; Output "B" data

[declan]

DAM!!!

Can't find these last pesky buggs....

I can get the n64 controller to return button status, and the on the snes side, I can get it to hold the data line high (or 0x0000) for the duration of the latch/clock cycles.

But when a button is pressed on the n64 controller; most of the buttons respond, but COMPLETELY SCRAMBLED

Code: Select all

My desired button mapping:
n64           snes
====          ====
A             B
B             Y
Z             Select
Start         Start
D-U           Up
D-D           Down
D-L           Left
D-R           Right
L             L
R             R  
C-D           A
C-L           X

The curent mapping:
n64           snes
====          ====
A             -
B             B
Z             Y
Start         B,Y
D-U           Select
D-D           B, Select
D-L           Y, Select
D-R           B, Y, Select
L             X
R             A, X  
C-D           -
C-L           A

Just look what happens when D-pad Right is pressed!

EDIT:
Not a single button does as it is intended!!

[Mark57Raider]

So why don't you just use the emulator to directly match your input buttons? zsnes, project 64, epsxe, vba, gens or whatever. It looks cool, but it seems like a waste.

[paulguy]

Cos he's hooking it up to a SNES and wouldn't even be able to map all the buttons anyway.

[declan]

It looks cool, but it seems like a waste.

As i mention earlier, there will be no real benifit for anybody if i can get this thing to work.

I would like to do this sort of thing (progrmming on a hardware level) when i leave school. So wanted to get a "head start"

So chose (what i though would be) a fairly simple sirial protocol conversion.

====

I'm starting to think a may have fried my Atmega8 in an earlier experiment.
I have now tested about 40 codes!

I might try and rebuild the circuit. I have heaps of atmega8s and pcbs, just need to pick up a LM1117 and few other goodies from futurlec.

[PHoNyMiKe]

the snes controller uses a serial interface. clock, data, and latch. the clock starts off high, the latch starts high. when the latch goes low, the snes controller has the value for B on the data line. if the data line shows 0, then the button is pressed, 1 for not pressed. then the clock goes low, then high, then the data line can be read for Y etc. read 16 bits.

the n64 controller uses a bi directional single data line, based on timing. there's 3 wires, power, ground, and data. the n64 outputs a signal (high or low) for like 160 microseconds or something, then the controller responds, high or low for however many microseconds. unlike the snes controller, where you toggle the clock line for erach bit, the n64 just blindly shoots data for a certain amount of time. google snes controller protocol and likewise for the n64. you can use avr studio simulator to get the timings right for the n64, you can restart the clock cycle counter and stuff to get exactly 160 microseconds or whatever timing the n64 uses.

[declan]

I under stand the snes and n64 controller protocols.

Before i shift out the data to the snes, i await the latch pulse (active high) then i shift the bits out through PD0, keeping in sync with the clock pulses (active low). After the 16th clock cycle, i drive the snes data line low again.

To request data from the n64 controller is a litte more difficult.... because the n64 controller uses 3.3V for logic 1, i have to change the pin direction of the atmega8, by "cbi" and "sbi"ing the DDRC.

To send a logic 1, i set the pin as "input NO PULLUP" and for a 0, "output low".

By carfully constructing timming loops, i was able get my comand word (0x01) to within 4 us in length to the one used by actual n64 console.

The asyncronous bits are 4us each in lenght, the comand word is 8 bits with a high stop bit (so 9 bits really). So the comand word should be 36 us.

My synthesised comand word is about 40 us long. But its not so critical, because the controller will use the "high low" pulses between each bit to keep in sync, thats how i'm keeping i sync with data coming back from the controller as well

[PHoNyMiKe]

I read the n64 protocol on some page, the dude said to never drive the line high. if your atmega8 is running at 5 volts, you should be able to put an 85 ohm resistor on the data wire for the n64 to drop the voltage down to 3.3 volts at 20ma should be enough. I would try having the wire go to the resistor, then to an output port (be careful, I saw not to drive it high, don't know why). then have the wire go directly to another port, this time an input. that way in the code you could treat the single data wire as two separate data lines, and not have to switch the direction of the port every time. again, output goes through an 85 (or slightly more) ohm resistor to the wire, and an input goes directly to the wire. every time your code sets an output bit, the mega8 will read an input as well, but just ignore the input while sending.

[declan]

He said to not drive the line high because most PICs and AVRs run on 5V, so driving the line high in using the internal pullup or sending a 1 from a 5V microcontrolller could potentialy damage the controller.

I thought about using a 3.3V zener diode, but it was cheaper to alter the code.

I ended up using the same tecnique as Raphaël Assénat used on his n64 to Gamecube adapter, (Gamecube uses 3.3V for logic 1, just like the N64)

On the gamecube side, the data signal is held at 3.43 volts via a pullup resistor inside the Gamecube. When someone (gamecube or controller) wishes to set the signal to 0, it just has to pull the signal to ground. Otherwise, it just leave-it as-is. I acheive this by playing with the Atmega8 pin direction. To send a 0, I configure it as output-low. Otherwise, I configure it as input-no_pullup. Activating the internal pullup or sending a 1 in output mode must not be done since this would put 5 volts on the data line. Who knows if this could damage the console port? (In fact, I have a cheap wireless controller which drives the bus with 5 volts! Nothing seems to have been damaged though...)

The N64 version uses the same technique to control the controller's data line. The only difference is that we have to provide the 3.43 volts pullup resistor. (From the controller's point of view, we're the console!)

Here's the link to Raph's page
http://raphnet.net/electronique/x2wii/index_en.php

EDIT:
Hers's another page (on liquidninjas) with more info

[declan]

I think i may be getting to the bottom of the scramble bug!!

I have been using two registers (r19 & r20) to hold the bits to be shifted out to the snes.

To add the value of a bit to either of the registers i was using the "sbr" instruction.... the Atmega8 data sheet states that this instruction is to "set bit in register" as oposed to the "sbi" instruction which "sets bit in I/O register"

After some test codes in AVR studio, i found that:

Code: Select all

sbr snes1, 1

Infact does not set bit 1, in the snes1 register!! it adds 1 to the register, effectivly setting bit 0!!!!!!!!

FIX

to set bit 0

Code: Select all

sbr snes1, 1

to set bit 4

Code: Select all

sbr snes1, 16

etc.

so maybe the ATMEL team got it ass wrong when writting the data sheet (?)

======

Gonna go start recoding....

Wish me luck!

[grinvader]

so maybe the ATMEL team got it ass wrong when writting the data sheet (?)

If you think about it, it's the only way to allow multiple bit setting per instruction.

Code: Select all

sbr reg, 01001010b

would set bits 1, 3 and 6 at the same time. You couldn't do that with your previous assumption.

[declan]

True.

Now when i think about it, it makes a lot of sence to do that.

That's not a bad idea grin; sbr reg, 0bxxxxxxxx

I didn't think of using binary.... much easier than using decimel (which i used)

[declan]

EXCITING UPDATE:

I have changed the values the section of code that collects data from the n64 controller.

When i reprogramed the adapter, i imediately tested it useing my 4 snes controller to usb adapter. It tested out PERFECTLY!!!!

But whe tested on the snes.... it did absolutely nothing,
I think maybe the snes clock and latch signals are too weak and the AVR can't pickthem up (?)

So my fix for this is: Have the Clock and Latch signals fed into two separate buffers before the pins on the AVR.

I will construct the buffers, using a PNP transistor, 1k resistor (this value may need to be lowered if the signals are not strong enough to even drive the buffer), and a 2.2k pullup resistor.

Until then.... its time to post a video!!!!!

Though, because the adapter doesn't work on a real snes (:(), i will film me playing on an emulator, (ZSNES or SNES9X).

But what game will i play :/

Any sugestions??

[adventure_of_link]

Make a n64 to USB adaptoid next.

Or at least a n64 to USB converter.

[PHoNyMiKe]

nice job man.

sbr r19, 0xFF (I read it as set byte in register, can be 0x00-0xFF)
sbi PORTB, 2 (set bit2 in IO, can only set a single bit, value must be 0-7)
ldi r16, 0xFF
out PORTB, r16 (to set a byte in the IO)

I use bit defines, just keep in mind they are bits, and can be converted to bytes:
.equ jabba 0
.equ hut 1
sbr r16, (1<<jabba) + (1<<hut) (bit defines are basically left shifts)
sbi PORTB, jabba
sbi PORTB, hut

[declan]

Make a n64 to USB adaptoid next.

Or at least a n64 to USB converter.

I would like too, but some one has beaten me to it ,and the USB protocol is too complex for a n00b like me

nice job man.

Cheers buddy

I am going to post a video soon, so does any body have a request for a game??

If not, i will just have to play Yoshi's Island