Let's suppose I have three keytars, such as this model. I want to hook them up to the NES (Nintendo Entertainment System) in some fashion. The NES has a controller port I can use that is wired like this. So, basically, a serial port with three input pins and one output pin. (Many devices use just one input pin.)

There are two ways to hook up the keytar to a device: a MIDI cable or USB. Keep in mind I want to hook up three keytars, not just one, so making a cable that connects MIDI to the NES controller port will not be enough on its own.

Here is one solution I thought of, but I can't help but think it's overkill: the keytars plug into a USB hub, which plugs into an Arduino USB Host Shield. The Arduino's output pins are then connected to the NES controller port. I have not programmed an Arduino before, so I'm making a bit of a wild guess about its suitability to this problem. I am a bit intimidated by the prospect of having to write a USB driver for the keytar if none exists (and I'm guessing none exists), although on the upside the main data stream would probably still be standard MIDI messages. (EDIT: since the keytar's USB is class-compliant MIDI, an Arduino driver might exist already or be easy enough to write...)

There's another minor consideration: there is an issue that the NES has when reading the controller port. The system has a notorious bug that, under certain circumstances (which will definitely apply here), sometimes causes the controller port to be read twice during one read instruction. This causes one bit of input to be lost, since the device thinks there were two reads (and therefore sent two bits), but the NES program only received one. While I think it'd be possible to compensate for this on the NES end, I think I'd much prefer to compensate for it on the device end, since I believe it would be much easier to handle. I believe that the device can compensate by requiring a certain number of clocks to elapse before it will send the next bit. This sounds like a task the Arduino would be good at.

Before anyone brings it up: I am aware there already exists a product called MidiNES that does something similar. I have determined that MidiNES does not suit my needs; for one, it cannot be used with programmable software (since it uses the cartridge slot), and for another, I don't want to be dependent on a tool that might not be easily replaced if it stops working and its maker has gone out of business.

So, that's my situation. How would you approach this problem?


closed as off-topic by Leon Heller, Daniel Grillo, Andy aka, placeholder, Keelan Nov 28 '14 at 20:01

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions on the use of electronic devices are off-topic as this site is intended specifically for questions on electronics design." – Leon Heller, Daniel Grillo, Andy aka, placeholder, Keelan
If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ Looks like this might be a suitable MIDI driver for the Arduino: github.com/YuuichiAkagawa/USBH_MIDI \$\endgroup\$ – Kef Schecter Nov 28 '14 at 12:53
  • 1
    \$\begingroup\$ I just noticed this question got put on hold, but I'm not sure how this isn't an electronics design question. From my perspective, I am designing a system for how to make three devices talk with another device. It is a high level of design, but it is still design, is it not? \$\endgroup\$ – Kef Schecter Nov 28 '14 at 21:31
  • \$\begingroup\$ I'm having a hard time imagining a more appropriate place for this question than here. It isn't an NES question because it doesn't have much to do with the NES except that happens to be the device I'm trying to interface with. It isn't really a MIDI question because of all the other stuff the question involves. It isn't an Arduino question because the solution doesn't necessarily require an Arduino. If it's not an electronics design question, what is it? \$\endgroup\$ – Kef Schecter Nov 29 '14 at 0:04
  • \$\begingroup\$ Also, to quote electronics.stackexchange.com/help/on-topic: "if your question generally covers ... a communication scheme ... and it is not about a shopping or buying recommendation, consumer electronics ... programming software for a PC, then you're in the right place to ask your question!" Well, my question is about a communication scheme, is it not? And it's not really about shopping, not about consumer electronics (aside from the particular devices that happen to be involved), and certainly not about programming PC software. \$\endgroup\$ – Kef Schecter Nov 29 '14 at 0:08

The NES controller contains a CD4021 shift register. This acts as a parallel-to-serial converter, with the parallel inputs connected to the buttons. You could use a CD4021, but connect the parallel inputs to output bits from the Arduino. This will relieve the Arduino of the high-speed clocked part of the problem.

If you cannot modify the keytars, then you are limited to either a MIDI (async serial) or USB host interface. You will, as you suggest, need a USB host shield or a MIDI shield. MIDI sounds a bit simpler to work with, given that it's basically a stream of serial data.

I can't comment on the bug that you mention (not an expert on the NES at that level).

I think your approach is along the right lines. Maybe start by getting the keytar-to-Arduino side of it working first. Also try out a CD4021 shift register and some buttons, i.e. build your own NES controller from scratch.


Not the answer you're looking for? Browse other questions tagged or ask your own question.