It is currently Sun Oct 22, 2017 1:29 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Mon Aug 25, 2014 11:44 am 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
This was just a dumb idea I had while I was at work. Let's say you could hypothetically add a rumble motor to an NES controller (somehow); this would require the ability for the CPU to send data to the controller, but the controller port obviously wasn't designed with this in mind. An interface for the special rumble-supporting controller would also need to be compatible with a standard controller.

The main hurdle is the fact that the only data line you have direct control over is the strobe signal, which goes to both controllers simultaneously. Happily, you can send a CLK pulse to each controller separately, so the idea I had was this:

  • Set strobe to 1 and then read from the port of the desired controller. A normal controller doesn't care about this and doesn't send anything useful. The rumble controller will see this and switch into a "receive mode".
  • Send data 1 bit at a time by placing a bit on the strobe line and then reading from the recipient controller's port. Reading from the port will send a CLK pulse to that controller, and the controller will accept the bit (placed on the strobe line) into a shift register.
  • Terminate the data packet by making two 1->0 transitions on the strobe line without sending any CLK pulses (so write 1-0-1-0 to the strobe). The controller accepts the transmitted data and then goes back into the standard mode of reporting button presses.

The controller not being addressed (be it a standard controller or a rumble controller) will simply see a bunch of strobes, which won't affect its operation; the controller being addressed sees the activity on the strobe line plus all the CLK pulses, and a standard controller wouldn't care about this either.

My original idea was to send a 2-bit packet to drive two rumble motors, but this can be used to just send data in general. If you wanted to control LEDs on the controller, or some kind of expansion port on the controller, or whatever.

You can send data to both controllers simultaneously by interleaving the bits of both packets and alternating between reading 4016/4017 on each bit. This would be insufficient to accidentally trigger the 1-0-1-0 termination sequence, so you'd be good to go.


Top
 Profile  
 
PostPosted: Mon Aug 25, 2014 12:27 pm 
Offline
User avatar

Joined: Sun Jan 02, 2011 11:50 am
Posts: 522
Even better: Implement this idea with a flash cart (powerpak) and have "plug-ins" for different games with checks against certain memory locations and send appropriate rumble commands.


Top
 Profile  
 
PostPosted: Mon Aug 25, 2014 12:55 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
Perhaps it might be useful to phrase this in terms of recovering a standard SPI chip select signal from clock and strobe signals. Clock on a port while strobe is set would then assert select, and two negative edges on the strobe ("MOSI" in SPI lingo) without any clock would deassert it.


Top
 Profile  
 
PostPosted: Mon Aug 25, 2014 6:22 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
Aren't there unused pins on the controller connection?
Are there ways for them to be accessed in a stock NES?


Top
 Profile  
 
PostPosted: Mon Aug 25, 2014 6:49 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5730
Location: Canada
The other pins aren't connected to any outputs coming from the NES.


Last edited by rainwarrior on Mon Aug 25, 2014 10:42 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Aug 25, 2014 9:27 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
Nope, the strobe and the CLK are the only two things the CPU can use for sending data to the controller. Everything else was routed to the expansion port on the bottom of the NES.

The Famicom is a different story; the expansion port (which you'd plug the controller into anyway) has extra lines the CPU can use to send data, but it'd probably work in a similar way to the strobe/CLK method I described, since packet transfers boil down to preparing a bit of data on one line and sending a pulse down the other when it's ready.


Top
 Profile  
 
PostPosted: Mon Aug 25, 2014 9:43 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
Myask wrote:
Aren't there unused pins on the controller connection?

The NES controller has two more slave-to-master pins, used by the Zapper, Power Pad, and Arkanoid controller. There is only one master-to-slave data pin (the "strobe"), whose voltage is the same on both ports. This means device selection for receiving rumble data has to be handled with just that single strobe signal and each side's clock. But this protocol is a clever way of producing a select signal. In fact, I think it could be used for general SDIO, allowing the NES to control all sorts of peripherals. Or to communicate with a slave Game Boy over Game Link. Or with appropriate level translation, it could be used with PlayStation controllers.


Top
 Profile  
 
PostPosted: Tue Aug 26, 2014 11:41 am 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
So the cool thing with this protocol is the fact that it doesn't interfere with the operation of standard controllers. That means the rumble device can just be something you clip onto the controller, and it can have its own plug that plugs into the NES controller port, with the plug having a passthrough port that the controller itself plugs into. The rumble device can just listen for the protocol and act on the signals accordingly while the standard controller just does its thing like nothing's different.

In other words, no need to mutilate NES controllers.


Top
 Profile  
 
PostPosted: Tue Aug 26, 2014 1:23 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
Drag wrote:
Nope, the strobe and the CLK are the only two things the CPU can use for sending data to the controller. Everything else was routed to the expansion port on the bottom of the NES.
And supposing one made an expansion device to help handle this?


Top
 Profile  
 
PostPosted: Tue Aug 26, 2014 6:58 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
I'm not sure what advantage that'd have over just using strobe/clk the way I described in my first post. You'd gain two more CPU->Peripheral lines, but what would that change?


Top
 Profile  
 
PostPosted: Mon Sep 01, 2014 12:45 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
I'm having a hard time figuring out if there's a way to mitigate the DPCM bug while trying to communicate to the controller. If the DPCM read occurs when you're trying to read from the controller port (to send a bit), the bit will be sent twice, and there's no way to know that it happened.

Just as a quick idea, I was thinking of switching the role of the strobe and clk lines, where a clk pulse while strobe is 1 changes the bit-to-be-sent from 0 to 1, and a falling edge on strobe commits the bit. Then a clk pulse while strobe is 0 terminates the packet. That way, multiple clks would be redunant, avoiding the DPCM bug.


Top
 Profile  
 
PostPosted: Mon Sep 01, 2014 1:33 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6294
Location: Seattle
If you are communicating with a microcontroller, rather than a shift register, the microcontroller can just reject bits that occur on successive M2 cycles.


Top
 Profile  
 
PostPosted: Mon Sep 01, 2014 1:54 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3470
Location: Indianapolis
The glitched clocks seemed to be a shorter pulse, I hadn't tested the idea, but I was thinking that measuring the pulse-width might work. A bit-banged synchronous protocol I figured would be best (because why not transfer multiple bits at a time), it would trigger an interrupt on CLK, then check the CLK state after a certain time, before proceeding to the next bit(s).


Top
 Profile  
 
PostPosted: Tue Sep 02, 2014 1:58 am 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
@lidnariq: M2 does not appear on the controller ports; in fact, there's absolutely no CPU clock or anything of the sort, just the port read CLK.

@memblers: I thought about measuring the CLK pulse too, and/or seeing if two CLK pulses were impossibly close together (like, quicker than if the CPU were actually executing two $4016 reads in software), but there's nothing reliable to compare the timing against.

If what wikipedia is telling me about bit-banging is what you're referring to, then it's pretty much what I was suggesting before. The only difference now is that the two lines are swapped, so the software manually sends a "clock" signal down the strobe line, and one or more pulses on the CLK line (between strobe-clocks) signifies a 1 bit instead of a 0, so the sequence now is:

  1. Set strobe to 1 and read $4016 to begin a packet transfer on the controller 1 port.
  2. Set strobe to 0 then 1.
  3. To send a "0" bit, skip to the next step. To send a "1" bit, read $4016 (to send a CLK pulse) and then continue to next step.
  4. Set strobe to 0 to send the current bit.
  5. If there's still more bits to send, set strobe to 1 and go to step 3.
  6. While strobe is 0, read $4016 to terminate the packet. (Coincidentally, this also returns the first button state)

The reason I thought about this method instead is because the effect of a DPCM conflict is that one CLK pulse turns into two. So, by rendering multiple successive CLK pulses meaningless, it mitigates DPCM conflicts.


Top
 Profile  
 
PostPosted: Tue Sep 02, 2014 7:56 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19115
Location: NE Indiana, USA (NTSC)
Drag wrote:
there's nothing reliable to compare the timing against.

There's always the option of comparing it to your microcontroller's internal clock, or using some sort of RC circuit with a specific time constant to stretch the clock pulses.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: romibraman and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group