Hi,
Recently I've stumbled upon a Mario Paint game, but I do not have a mouse. I'm wondering if anyone have seen the project to connect the ordinary PS/2 mouse to the SNES.
If not, I was thinking of making a PIC or Atmel based adapter, but haven't looked deep into the protocol.
Do you have any tips for me?
Just buy a mouse. They're not expensive.
The SNES Mouse protocol is documented in both the
NesDevWiki and in the
Super Famicom Wiki. NoCash also has a
writeup.
lidnariq wrote:
The SNES Mouse protocol is documented in both the
NesDevWiki and in the
Super Famicom Wiki. NoCash also has a
writeup.
Thanks a bunch. It seems doable. Just repeated serial writes to the controller port.
I'd like to achieve it myself for the sake of learning. Just buying the mouse will take the fun out
A PS/2 <> SNES mouse adapter would definitely sell, if you were interested in such a thing. Laser mouse Mario Paint sounds awesome.
I'll recommend you use the Teensy++ as the bridge. You can buy SNES extension cables to cannibalize. Throw on a PS/2 <> USB adapter on the end and you'll have a nice USB <> SNES cable.
I've used the Teensy++ for SNES controller <> PC TTY (serial) transfer.
I have an Arduino waiting for an interesting project, and also a bunch of spare PIC18F microcontrollers lying around, which are more than powerful enough for the task. I can gut an old controller for the connector.
Sounds like a neat project for the vacation
I didn't know/think about whether there was demand. :( Sounds like you've got dibs on the project, though, shiny.
I'm actually looking into doing a bluetooth mod for the SNES for wireless controllers, and if I manage to get it working, one of my goals is to support bluetooth mice as well. However, the project is likely going to be a slow one (I have started it, but I'd like to keep enough of it undone to propose it as a senior project). The protocol is almost as straightforward as that of the plain controller, so good luck
And if you want to test your adapter on an NES game, you can always try Thwaite, the only NES game I know of that supports a Super NES Mouse.
Being able to play Chinhai with a mouse that's actually good? Yes, yes, 1000 times yes!
I've actually wondered this for a while now: does the SNES controller port put out enough juice to drive an optical mouse?
Eyedunno wrote:
Being able to play Chinhai with a mouse that's actually good? Yes, yes, 1000 times yes!
I've actually wondered this for a while now: does the SNES controller port put out enough juice to drive an optical mouse?
I plan on building a custom adapter, based on a microcontroller, which might even require it's own power source, or piggyback some from the snes. We'll see.
For now I have played a bit with the arduino, trying to implement the controller protocol. Timings are still a bit off, but some initial groundwork is done, and I've managed to wiggle the car a bit in F-Zero
.
tepples wrote:
And if you want to test your adapter on an NES game, you can always try Thwaite, the only NES game I know of that supports a Super NES Mouse.
I'll keep that in mind, thanks
.
Eyedunno wrote:
I've actually wondered this for a while now: does the SNES controller port put out enough juice to drive an optical mouse?
My verdict is yes it can. It's kind of hard to prove, but I did some testing a while back. One thing to know is that the controller power is the same 5v supply that powers the entire NES. So there are no specific controller current limits of concern really, just that of the overall NES power supply. I think it's around 1A regulator IIRC, and the NES only consumes a few hundred mA. Carts consume varying amounts by themselves. But a mouse that only draws 100ma or so should be fine. The largest peripheral I found was the advantage that consumed around 16ma, if that tells you anything.
I keep missing the timing. Whenever I try to send one button press to the snes it registers as at least 2-3 keypresses.
I might try changing the output pin on the arduino, and if that fails I'll try with two arduinos to be able to debug the communication on the other side.
Are you using the atmega's SPI hardware? high-level Arduino code won't be able to keep up with the fast bit serial read needed for controller port stuff.
Yeah lidnariq is right. That's the downfall of arduino often times. I was able to get an atmega to emulate the controller's shift register but I did that in assembly. I've had success in programming timing sensitive things in C but made use of the IDE's cycle counter. I don't think such high level tools are available to arduino...
Thanks for clarifying my suspicions. I guess I'll go the barebone PIC18F route then.
The alternative would be to put a shift register in between the arduino and NES as a buffer. It would take up atleast 8 pins on the arduino, but then you'd only have to keep the most recent data on the input pins of the SR that way the arduino wouldn't have to keep up with the NES.
EDIT: if your running on a SNES you'd actually need 16 pins...
I've been playing around with a PIC24FJ64GB002 I picked up as a free sample (yay for getting free stuff as a student), and one of the really cool things about it is the fact that it's the only microcontroller I've ever seen that supports USB host/OTG in a DIP package. It runs at 3.6V max, but it does have 5V-tolerant I/O's, and it even has a high-accuracy internal oscillator that allows it to run in USB mode without an external crystal. So far, I've only played around with device-mode, but next up, I plan to try out the official USB mouse host-mode demo. If I can get that working, implementing the SNES side should be a piece of cake. So, I may have a rough working demo of USB-to-SNES mouse here in the next week or so...
3gengames wrote:
Just buy a mouse. They're not expensive.
The supply is dwindling. It's like buying a donor cart: some people have objections.
And yes, you'll probably need an SPI slave port on whatever MCU you choose. The mouse's report is 32 bits, and an external shift register probably won't be enough. You'll also need to support toggling the reported sensitivity, as mouse detection in commercial Super NES games relies on being able to cycle the mouse through sensitivity 0, 1, and 2.
Dude, you're quoting a post from 2012.
I'm aware of that. I know not everybody agrees on when to necro vs. when to create a duplicate topic. But someone in #nesdev brought up the topic this evening, and I decided to add new 2014 thoughts to the 2012 proposal. Or in your opinion should topics that peter out signify "The community has already discussed and rejected this proposal with prejudice"?
In my opinion, if you're doing it on purpose you should explicitly state so, otherwise it looks like you're trying to continue a dead conversation instead of just trying to add information.
You don't really need hardware SPI, you just need to be using pin change interrupts instead of polling. 16MHz is plenty fast enough to implement an ISR-based shift register in software, especially since the AVR architecture is almost entirely single-clock instructions. Besides, if you do use the AVR's hardware SPI, you'll have to do some behind-the-back trickery to do a multi-byte transfer with only a single latch pulse.
Yeah, some other advantages of doing the shift register in software is that you can you could send 2 or 3 bits at a time to the NES, and could ignore the extra clocks caused by DPCM use.
Ignoring dirty clock signal when used with the NES is valuable. Sending 2 or 3 bits at once less so, as it would break compatibility with existing games like Mario Paint.
tepples wrote:
Ignoring dirty clock signal when used with the NES is valuable. Sending 2 or 3 bits at once less so, as it would break compatibility with existing games like Mario Paint.
Not if those bits were sent using the extra pins which are normally unused.
In order for a signal sent on one of the otherwise unused pins to be useful, the program running on the host has to expect the signal to be present on one of those pins. Existing games that use the Super NES Mouse do not; they just sample 32 bits off D0. Perhaps the microcontroller could have a second mode to emulate the Arkanoid paddle, which does put data on those pins.
tepples wrote:
In order for a signal sent on one of the otherwise unused pins to be useful, the program running on the host has to expect the signal to be present on one of those pins. Existing games that use the Super NES Mouse do not; they just sample 32 bits off D0. Perhaps the microcontroller could have a second mode to emulate the Arkanoid paddle, which does put data on those pins.
Yeah, I was thinking for homebrew applications. Obviously, in order to maintain compatibility with existing titles you'd still need to send the expected data over the primary data line, but you can do whatever you want with the other two lines if you're writing your own software on the console side.
tpw_rules in #nesdev wants to make this MCU but first needs to buy a PowerPak or other way of running code on an NES.
If this goes through, I propose an extension to the Super NES Mouse protocol that reflects the middle button in the bit that's normally used for B (SNES) or A (NES) and the scroll wheel in the bits for Up/Down.
I spent some time planning this months ago, and ... never finished writing the microcode. Oh well. Anyway, once I got as far as thinking that I wanted to add support for the middle mouse button, I figured I may as well add support for all the other frequently present mouse buttons and map both axes of scroll wheel and all five buttons to things in the first (normally all 0s) byte of report on the SNES mouse.
Of course, this is putting the cart before the horse; once you implement the basic translation, adding extra buttons to the translation is straightforward.
Stupid question, what's actually the full protocol? (just the format of what gets sent in the packets returned by the mouse) Wondering about whether the extensions would make sense in the places they're suggested.
But yeah, I see no reason why not to map the extra buttons. What would it be in total, five buttons and two scroll wheels? (anything more than that is really non-standard so I'd say to not bother with it) For the record, you could map both scroll wheels to the D-pad in that case, and maybe the two extra buttons to L and R.
L and R unfortunately map to the mouse's speed report. But the entire first byte is normally all 0s: the only question is whether any existing software cares or if it all ignores it.
http://wiki.nesdev.com/w/index.php/Mouse ;
http://wiki.superfamicom.org/snes/show/ ... lers#mouse ;
http://problemkaputt.de/fullsnes.htm#sn ... uttonmouse
Squeeeak! (That's mouse language for "bump".)
tpw_rules asked me to post this pic of work in progress. "There's a lot more work to do. It isn't stable and seems to fall out of sync for a while, it doesn't do any sort of scaling, and there's no keyboard code whatsoever. It's more like 40% than 90% done."
A PC mouse being used to control Mario Paint (click to zoom)
^ ^ ^ ^ ^ Wow look at you!!
Quote:
A circuit for using a PS2 mouse on a Super Nintendo (for games that support the official mouse).
Based on the popular PIC 16F628
http://dabit.es/proyectos/?activo=3http://dabit.es/proyectos/PICSNES/1/PICSNES.htmhttp://dabit.es/proyectos/PICSNES/2/PICSNES.htm
I found this years ago , maybe it can be useful ,(It is in spanish).
Hey, sorry for the bump, but I just wanted to put this here in case anyone else read this and was looking for an available solution (I couldn't find another one.)
Here it is:
https://github.com/cooprocks123e/ps2tosnesThat is code designed for Arduino that acts as a bridge between a PS/2 mouse and a SNES. It runs great on my Arduino Duemilanove. Feel free to do whatever you want with it.
