Testing controllers, demo code, and documentation

Topics regarding the Uzebox hardware/AVCore/BaseBoard (i.e: PCB, resistors, connectors, part list, schematics, hardware issues, etc.) should go here.
User avatar
arclight
Posts: 7
Joined: Sun Jun 07, 2009 1:33 am
Location: Chicagoland
Contact:

Testing controllers, demo code, and documentation

Post by arclight »

What's the best way to test if the (F)uzebox can read the controller?

I'm testing my Fuzebox after final assembly and I am wondering how to test if my controller works. I'm not convinced there's a problem since I don't know what I should expect out of the preloaded demo code. I have a couple thoughts on this probable non-issue.

I'm in the process of setting up a software development environment but it's not quite there yet; I'm not in the position to build or upload anything yet. Besides, I'd rather confirm all the hardware is working before I start mucking around with software. So my first question is whether I should expect to see the display change when I plug in controller #1 and start pressing buttons?

I want to give big props to Ladyada for probably the best assembly instructions I've seen thus far, explaining each subsystem being built and giving tips on testing (power conditioning, audio, video, ...). I found I had accidentally skipped the 75-ohm resistors which explained my lack of video halfway through. D'oh.

Sadly, there was no final test to verify the controllers were working and not being familiar with the default demo code, it wasn't clear how to test the system without reviewing the demo source (no idea where that is), uploading my own test code, or digging out a logic probe or voltmeter to see what was going on. This last suggestion is not so useful since it presumes one knows how the system should be acting. Measuring blind doesn't seem effective, though one could dig out the schematic and play analyst for a while.

Anyway, I've been really happy with the way this project has worked out so don't take this as a complaint. This testing issue falls somewhere between hardware, software, documentation, and stupid n00b tricks. Hopefully we can tease out some more documentation or code from this and add it to the wiki, etc.
User avatar
Jhysaun
Posts: 214
Joined: Tue Nov 04, 2008 12:32 am

Re: Testing controllers, demo code, and documentation

Post by Jhysaun »

In the Fuzebox Demo, when you push a button, a letter will appear.

U for up
D for down
L for Left
R for right


and so on. (or some letters, I don't have it to check it right now.)

Simply put, if you push buttons and letters appear. Its working.

>J
Lerc wrote:I intend to use my powerful skills of procrastination to ensure that when I get to making things, the chips will be available.
User avatar
arclight
Posts: 7
Joined: Sun Jun 07, 2009 1:33 am
Location: Chicagoland
Contact:

Re: Testing controllers, demo code, and documentation

Post by arclight »

Thanks - I had the feeling that was what was supposed to happen; I suspect something's messed up on the board now. :/

When I fire the thing up with controller #1 plugged in, I get "Player 1: UDLRABXYSLSR". When I unplug the controller, it changes to just "Player 1:"

There's no change if I press any buttons and nothing happens if I put the controller in the #2 port. If I move my finger along the back of the controller #1 port (along the solder joints) it's as if all the buttons are pressed - I don't get an individual 'U' or 'A' or 'X'. It's "UDLRABXYSLSR" or nothing. I guess the next step is to look for solder traces between connection points. I don't remember if this was happening when I did the initial video test; I was more focused on getting the rest of it assembled and didn't have enough info to know to watch for this behavior.
Last edited by arclight on Sun Jun 07, 2009 5:45 pm, edited 1 time in total.
User avatar
steve.chamberlin
Posts: 73
Joined: Wed May 13, 2009 3:33 pm
Location: Bay Area, CA
Contact:

Re: Testing controllers, demo code, and documentation

Post by steve.chamberlin »

My guess is that you've accidentally swapped some of the four controller-related wires, either at the microcontroller end, or at the SNES connector end.
User avatar
arclight
Posts: 7
Joined: Sun Jun 07, 2009 1:33 am
Location: Chicagoland
Contact:

Re: Testing controllers, demo code, and documentation

Post by arclight »

The Fuzebox doesn't have a lot of wiring that can get crossed but I picked around the board with a multimeter and a magnifier for a while. Again, nothing looked unusual.

I popped open the SNES controller and recognized the silver dimples under the left and right buttons as the same from my poor old abused Atari controllers back in the day. One of the squiggly copper contacts (for the conductive rubber used for the rest of the buttons) looked like it had a run in with a soldering gun - it looked like some of the copper had been soldered together to repair it; I don't think it was shorting but it was hard to debug without a few extra hands. The internal soldering looked kinda messy (i.e. worse than mine) but you get what you pay for. I found the epoxy blob that probably covered the dual 4021 parallel-to-serial converters (or modern equivalent) plus a couple resistors.

I had hoped that I could just do a little continuity testing and see if the controller was wonky but the epoxied-over IC killed that idea. I went to Google Engineering School(*) to get the backstory on the controller pinouts. I found a few interesting links at http://www.gamesx.com/controldata/nessnes.htm and http://www.gamesx.com/controldata/snesdat.htm and figured if I was going to fail at debugging, I'd fail big.

I broke out my brand new logic analyzer from Saleae (http://www.saleae.com/logic/). I won't lie - I haven't used a scope or a logic analyzer since the late 80's in a horrible physics lab that seemed to focus on measuring stray 60Hz noise for three hours a night on equipment salvaged from downed airliners. About all I remembered was that you sync with the clock and maybe you'll see something before you gnaw your arm off from frustration. But I digress.

Knowing pins 1 & 7 (from flat to round end) are+5V and ground respectively, I can confirm those by multimeter. Pin 7 gets a ground probe. Pins 4, 5, and 6 get data probes. Pin 6 is clock, so I set that to trigger on high. Then I flail wildly with the data acquisition rate and number of samples, then fiddle with the time base until I start seeing pulses or I decide that alcoholism is a more satisfying hobby.

As it turns out, by pretending I knew what I was doing, I got some nice traces off the analyzer. I've posted them at http://www.flickr.com/photos/31076985@N ... 406496590/

If my I understand the SNES pinout web pages above, there are 12 clock pulses after the data latch pulses. Technically there are 16 but in 13-16, the data line is always high so those pulses are apparently unused and in this system, omitted. I see the same 60Hz latch rate and 12us pulse width and it matches up with the timing documented so I'm pretty sure I'm seeing more than the 60Hz noise from my college days.

Assuming that I've done the unthinkable and actually am reading good signals off the controller port, I should see some differences when a controller is plugged in vs when it isn't. Testing port 1 with no controller , I get a latch pulse followed by 12 clock pulses and nothing on the data line. That's expected. It doesn't mean the board is working, just that it's not failing by putting spurious signals on the serial line when there's no controller plugged in. So I've eliminated one failure mode on one port. w00t.

Plugging in the controller, I see the same response on the latch and clock lines (no surprise) but a data pulse with the latch pulse, followed by data pulses on clock pulses 1, 6, 7, 8, an 12. That apparently corresponds to simultaneous button presses on B, Down, Left, and Right joypad, and Right trigger. As I recall that sequence causes Zelda to ditch Link to become a pole dancer(**). Anyway, that behavior is pretty odd since no buttons were pressed on the controller, at least not by me. And I don't own a cat.

I did those tests a few times until I was certain they were repeatable. Then I moved the probes to controller port 2 and repeated the tests. Surprise of surprises, I get the same behavior. See the Flickr link for the set of four traces.

My temporary verdict is that the controller is pooched; I don't have another controller handy so further debugging will have to wait until I can get one.

Apologies for the length and weirdness of this post but I wanted to show a potential debugging method for others that have the same issue and to ask for feedback. I am far more of a book engineer than a bench engineer(***) so I'm always looking for tips on hardware construction and debugging. :geek:

Thanks for your help; let me know what you think.

(*) Accredited only in the Bahamas.(**)
(**) I am totally making this up.
(***) My day job involves coding, some database work, and the occasional analysis of radioactive sludge, reactor coolant flow, cable fires in power plants, and other crazy crap like that. And no, I'm not making that up.
User avatar
Jhysaun
Posts: 214
Joined: Tue Nov 04, 2008 12:32 am

Re: Testing controllers, demo code, and documentation

Post by Jhysaun »

That was an interesting post. Anyway, you seem to know more about hardware than I do, but I agree that the controller sounds dead. You could try sending it back to ladyada, but the controllers she has are cheap knock-off's(I think the word on her site, and the box is "compatible" ;) ) I would try getting an official SNES controller off of ebay or amazon.


.J
Lerc wrote:I intend to use my powerful skills of procrastination to ensure that when I get to making things, the chips will be available.
User avatar
steve.chamberlin
Posts: 73
Joined: Wed May 13, 2009 3:33 pm
Location: Bay Area, CA
Contact:

Re: Testing controllers, demo code, and documentation

Post by steve.chamberlin »

Hmm, from those images, it looks like there's some badness on your data line. Shouldn't those data pulses last for one entire clock cycle, until the rising edge of the next clock? The logic analyzer shows data pulses that are much shorter.

Also, I think the controller is wired so that 0 means a pressed button, and 1 means not pressed. So your controller is actually indicating seven button presses, not five.

Sanity check: try wiring your data line directly to ground, and make sure the Uzebox reports all buttons are pressed, then try wiring it directly to +5, and make sure the Uzebox reports no buttons are pressed.
User avatar
arclight
Posts: 7
Joined: Sun Jun 07, 2009 1:33 am
Location: Chicagoland
Contact:

Re: Testing controllers, demo code, and documentation

Post by arclight »

More fun: I opened the controller again to poke around inside and a few of the wires broke off the board. I spent 20 minutes or so trying to strip and resolder them. I don't know what the conductor is made of but it appears to be four gossamer strands of carbonized horsehair. Painful to work with. I put it back together and ran the logic analyzer again; a few snapshots show the data pulses all over the place now. I'm going to scare up another controller and see what happens.

In the meantime, I think I'm going to solder a few leads to the V+, GND, and data line on the spare NES traces on the board and try the all-on/all=off test. There's not much else I can do unless the magical SNES controller fairy slides one under my door tonight.

And Jyysaun, really, I don't know hardware that well. I've just been lugging around my old copy of The Art of Electronics for ~22 years completely out of spite. It's a horrible textbook, but apparently a fabulous bench reference, and I vowed I'd eventually make good use of it. It's been sinking in, very very slowly...
User avatar
Jhysaun
Posts: 214
Joined: Tue Nov 04, 2008 12:32 am

Re: Testing controllers, demo code, and documentation

Post by Jhysaun »

But relative to me, you're a f'in genius. :D
Lerc wrote:I intend to use my powerful skills of procrastination to ensure that when I get to making things, the chips will be available.
User avatar
arclight
Posts: 7
Joined: Sun Jun 07, 2009 1:33 am
Location: Chicagoland
Contact:

Re: Testing controllers, demo code, and documentation

Post by arclight »

Jhysaun wrote:But relative to me, you're a f'in genius. :D
Everyone starts at the beginning. :)

I did a little more testing with a 330-ohm resistor - I could reliably turn on or turn off the letters if I tied the data line to ground or V+ respectively. Also confirming that I got the signal reversed on the logic probe - low=on, high=off.

Today has been kinda frustrating, but on the upside I learned a lot and the project has not suffered the fate of many before it - starting on fire and/or getting thrown against a wall. If success was guaranteed it wouldn't be interesting. Anyway, thanks again. I'll post an update when I find a working/different controller.
Post Reply