snes controller trouble

byte vortex · 2006-12-12 19:21

i have a dilema here i hope you guys can help

I did a project for class with the propeller chip that requires it to mimic the super nintendo systems controller and i have the
problem with the data transmission because it·is way too fast for·spin to·handle·so i downloaded the SPI demo that was
posted here but i have trouble modifying it to make the shiftout routine·from being a master to a slave and·the shiftin routine because
it seem that·anytime i use both of them in the chip i don't see the clock·and instead of the number inputted all i see·a 1·i am also have
trouble with the fact there is a latch involed too and i have seen very little assembler. so do you think you can help me with this with
the deadline for my project is coming up fast.
·····

Mike Green · 2006-12-12 19:34

I don't know if anyone here can help, but you will have to post more information. At the very least, you'll need to post your schematic or at least a complete description of the connections from your Propeller chip to the Super Nintendo controller as well as the SPIN/assembly code involved (as an attachment please ... not cut and pasted into the message). Most of the people here are hobbyists and help others because that's what people do.

Martin Hebel · 2006-12-12 21:55

Mike,
This is one of my student's, and I haven't dealt with Assembler much, and wasn't able to help him get this going.

All he really needs is Beau's SPI Engine Library to act as a SPI slave instead of a master. I tried modifying the Clock routine in it to wait for a pin state instead of generating a clock pulse, but it didn't seem to work right.

Also. the NES sends a Latch pulse to the controller before doing a shift to latch in the all the button states, but it might be a bit much to add right now without more details os states and such.

If someone could look at the Clock: routine in the SPI engine and give us help how to wait for pulse, it would be appreciated.

Thanks,
Martin

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
StampPlot - Graphical Data Acquisition and Control
AppBee -·2.4GHz Wireless Adapters & transceivers·for the BASIC Stamp & Other controllers·

byte vortex · 2006-12-12 22:10

I am new to the fourms so you will have to bear with me here.

i've attached what i have·done and the information i used.

Mike Green · 2006-12-12 23:17

If someone else doesn't get to this sooner, I'll have a look later this evening (I'm away from home).
Mike

AndreL · 2006-12-13 01:02

FYI - you can run the nes controller read at a bit an hour if you want or you can push it to 5-10 mhz at mhz, that's it. So speed is irrelevant on reading it.

Andre'

Martin Hebel · 2006-12-13 01:37

Andre', he's trying to get the prop to act as the controller, so the NES is acting as master and clocking a bit every 16us if I remember correctly, so speed is an issue (which I found out after I agreed to project). He's trying to develop his own controller with macros action.

Thanks though,
Martin

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
StampPlot - Graphical Data Acquisition and Control
AppBee -·2.4GHz Wireless Adapters & transceivers·for the BASIC Stamp & Other controllers·

Mike Green · 2006-12-13 05:58

Looking at the code, one thing confuses me ... There looks like two copies of the SPI Engine, one called "Controller Engine" and the other called "SPI Engine". Both are referenced in "Controller", one as SPI, the other as SYS. In "The_System", you reference "sys.shiftin". I wonder whether that should be "spi.shiftin", then you could eliminate the OBJ definition for SYS. Could the two engines be interfering with each other?

There is an error in "Controller Engine" just before Clock_ret. You do a

     waitpeq  t2,     #0
     waitpeq  t2,     #t2

This should be either

     waitpeq  t2,     #0
     waitpne  t2,     #0

or

     waitpeq  t2,     #0
     waitpeq  t2,     t2

I think you're making the same mistake in Latch.
I hope this helps. Mike

Martin Hebel · 2006-12-13 13:53

Thanks Mike,
In trying to test it, the normal SPI engine was taking the place of the SNES by shifting data in. The controller engine would be the slave to it. Interfering? maybe. One thing confused me was that when called from the same cog, the correct value was being passed between the two (which I didn't think it was ready for, and I didn't see any external indication of the clock actually working). When called from in different cogs it didn't work.

Wierd thing is when testing SPI_Demo, I could see clock signals going. When the same code is used in the end_test program, I saw no indication. The master should be clocking regardless of how screwed up the slave is. I looked to see if the slave was setting the output high preventing the master from controlling it, but couldn't see it.

Thanks for the code correction, of course it's not a literal.

We didn't delve too deep in pASM, but thought we might be able to tweak the SPI engine enough.

-Martin

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
StampPlot - Graphical Data Acquisition and Control
AppBee -·2.4GHz Wireless Adapters & transceivers·for the BASIC Stamp & Other controllers·

Mike Green · 2006-12-13 14:24

Ah! I get it. You're trying to use one cog as a substitute for hardware for debugging purposes. That's a great idea. I'll take another look at it tomorrow. See if making the corrections makes any difference.

AndreL · 2006-12-15 09:05

Ah, I see. One suggestion is that you are trying this stuff at full speed, just simulate the nes as the master with some dips and debounce or something, to get the logic working, then speed it up, when you are happy its working then hook up the nes master. Trying to debug and work at full speed is two things at once, one too many.

Andre'

snes controller trouble

Comments