nesdev.com

Controller Test Program



There was talk about hooking up a NES multitap (Four Score or NES Satellite) to a Famicom by modding the controller ports, and I was experimenting with reading these multitaps, so I whipped together a test program for it. There are other test ROMs for the Four Score but this is AFAIK the only one that tests both Famicom expansion controllers and NES multitaps at the same time (as well as the controller II microphone). I made a ROM cartridge version as well as an FDS disk version (both included in archive) so that it can be used to test controllers with just an FDSStick or similar device which makes it easy to boot the game without a built-in menu that requires a working controller. Other than that, this is just another controller test program.

It checks for the NES multitap signature, and if no NES multitap is detected it greys out those button indicator lamps and ignores NES multitap input (or else trash data would be displayed in the indicator lamps when no NES multitap is connected).
As for now, it does not test those HORI multitaps that allows 4 expansion controllers in the Famicom's expansion port, because I have no idea how those works and I haven't found any technical info on it.

The program works on hardware as far as I can tell, but since I don't have a NES or Four Score, I have only tested that in emulators. Also emulators tends not to allow connecting expansion controllers and a Four Score at the same time, so I haven't tested that part at all. If anyone happens to have such a setup that allows testing all these features, please tell me if it works.

Suggestions, critics or other comments are welcome.


Update
Four Score confirmed to work on hardware.
To do:
-Fix the bug that hinders the SELECT state from updating while B-button on the same controller is held.
-Add Hori 4-player adapter support.

I have an NES and a Four Score, which work in my own test program. I can probably run yours this evening.

I haven't made an FDS version of my own test because I lack a Famicom and FDS with which to test it. But I'm interested in doing so. Is it easy to port NROM cart programs to FDS?

_________________
Pin Eight | Twitter | GitHub | Patreon

All the technical information we've been able to find about it (Hori's Multitap) requires access to a signal that's simply not possible via the FC expansion port—namely, player 1 serial input—so I have no idea how they work.

There's also HAL's JoyPair. It appears to have been designed to let someone plug two single player #3 peripheral (i.e. the JoyBall) into both ports and be able to use them as players #3 and #4. I assume Hori's Twin Adapter is identical.

I just tested it on my NES Four Score. The only odd thing I found is that the displayed state of the Select button on any controller doesn't change while the B button on the same controller is held.

In theory, you'd be able to do eight controllers on one AV Famicom. You'd need one Four Score plugged into the front port and one Four Score plugged into the expansion port through an adapter from 2 NES controllers to 1 JoyPair/Twin Adapter-type thing that has NES controller receptacles. But I'm not certain that the Famicom's power regulator is up to it.

_________________
Pin Eight | Twitter | GitHub | Patreon

Was there a commercial product that converted from a NES-style joypad port to a DA15 ? If not, I don't see any reason to use that protocol... We may as well pick something easier to build, such as extending the Famicom 4-player protocol to the other bits of $4017.

NROM is easy because you only need one disk side so you can just copy your code with very few changes. It's mostly about making the disk and file headers which are explained in the wiki. The wiki is a bit lacking in the FDS department, but I think Rainwarrior did some improvements lately. For the actual main program, the only changes I know that you need to make from an NROM are the following:

1) Three NMI vectors are needed, although you only need to use one handler.

2) Part of stack is used by the BIOS and the last 11 zero page registers are BIOS variables. These can't be touched when clearing RAM or things will break (not sure about the stack pointer though). The first 16 zero page registers are also used as temporary variables. As I understand it they can be cleared and used as you please, but if BIOS calls are used, they may be used by those as well.

3) Mirroring at boot is set to horizontal by the BIOS. You need to change this at $4025 if you want vertical. It's normally changed by ANDing the BIOS variable $FA, which contains the value last written to $4025, then writing it to $4025 (or maybe there is a BIOS call for it not mentioned in the wiki).

4) Interrupt handlers needs to push processor status to stack besides the accumulator and index registers.

Then it's just the problem of linking the files into a disk. The program file should load to $6000 and the vectors needs to be placed so they land at $DFF6. I couldn't solve this using normal asm6 directives, so I instead assembled each disk file separately and had a header source file that includes the assembled disk files as binaries and then assembled the header last. If anyone has a better idea I'm willing to hear it, but from what I can tell it looks like other people did something similar. For ca65 it seems simpler as it uses a linker normally. Rainwarrior's example shows how to do that (even how to skip the KYODAKU-file).

Now when the retrogaming market has crashed, Famicoms are quite cheap again. The FDS RAM-Adapter and FDSStick are also cheap. Maybe it's good timing to get one and add expansion audio capabilities to Pently and keyboard and microphone testing to Allpads.


I see, I don't even know what games are using these 4 controller multitaps.
JoyPair and Twin Adapter sounds like adapters that uses the standard way for connecting external controllers (which is what my program tests). Just like those controllers that has a 15 pin port for forwarding the connection to $4017 D1 so another controller can be daisy chained.

Thanks for testing!
Oh you are right! That's a bug I missed. Strange, I thought I had tried all possible and impossible kinds of button combinations already.
Now this is puzzling, B is processed right before SELECT but there is nothing different in how these buttons are processed from how any of the others are. Each button indicator lamp is a unique sprite entry in OAM, and should not be affected by each other.

I always asumed the four score just used the data lines for controllers 3 and 4 that are already present in the plugs for controllers 1 and 2. Is this not the case?

The NES controller connector has D0, D3, and D4 lines. D1 and D2 are not present. Standard controllers use D0, as does the Four Score. Zapper, Power Pad, and Arkanoid controller use D3 and D4. Software compatibility wasn't an issue in the design of the protocol because Famicom software expecting D1 would have to be modified anyway.

_________________
Pin Eight | Twitter | GitHub | Patreon

Hmm... with D1 and D2, are you talking about the lines used by the hardwired player 1 and 2 controllers of the famicom? Because I'm pretty sure those are the same as used by controller 1 and 2 for the NES, as the NES version of Solstice can only be played using the hardwired controller 1 when played on a famicom. I think this might actually be the case with a lot of western developed games for this reason. Japanese games on the other hand would often accept both controller 1 and 3 as the same, so that you could use an external controller for player 1 on a famicom.

I made an adapter some years ago for using NES controllers on my famicom through the DB15 port using this schematic:



The schematic is confusing and I don't fully remember how I connected it all, but it works. Using the adapter, I am able to play most games as player 1 and 2 with an NES controller. Solstice is one of the few that will only accept the hardwired controller 1 as input. I think maybe Maniac Mansion also did not accept anything but controller 1.

So controller 1 and 2 on the NES must be the same as on the famicom if I am not completely missing something.

EDIT: NVM, I don't think I know what I'm talking about. All these data lines and different controller ports make a bird's nest of my mind. I'm probably misunderstanding and you guys probably grasp this waaaay better than me.

No...

He's talking about the other bits read from $4016 and $4017, see more: nesdevwiki:Standard controller

I am told that many 1-or-2-player games intentionally treated player 3 as a copy of player 1 and player 4 as a copy of player 2, because the hard-wired controllers in the original Famicom had the unfortunate habit of breaking. So that's why – in fact, the only reason why – games seem to work via controllers in the expansion port.

For the player 1 / player 2 standard 8-button controllers, the NES and Famicom use the exact same convention and read the data from the exact same bit.

Must be about the early square button controllers. Round button controllers are as sturdy as NES controllers and don't break even after years of use. The square button controllers on the other hand, the A and B buttons are square and made of rubber (like START and SELECT or buttons on many Game & Watch systems) so they are easily worn down, and since they aren't round, the corners may get stuck if pressed down hard. These controllers were eventually replaced with the new round button controllers when Famicoms were sent in for repairs, which is probably part of the reason they are rare nowdays even on older Famicoms. But yeah since most launch games do support external controllers, I think the expansion port was designed to be able to use extra controllers from start, as that is the only way to easily connect controllers.

The pink and purple (called DATA(1) and DATA(2)) lines is where the controller sends its button data to the Famicom or NES. In the normal port on both Famicom and NES, they go to the input for $4016 D0 and $4017 D0 respectively. In my controller program that is con I and con II. When you hook up to the 15-pin expansion port with an adapter like that they instead go to $4016 D1 and $4017 D1 respectively. That's the con III and con IV. The Four Score uses $4016 D0 and $4017 D0 for all controllers (con 1 and 3 in $4016 D0 and con 2 and 4 in $4017 D0) sequentially. so instead of reading D0 eight times for the eight buttons you simply read it 16 times so you get eight buttons for two controllers per port. These are the greyed out con III and con IV in my program (con I and II in a Four Score acts no different from the two built-in ports).

Nintendo should have included the D1 pin in the NES controller ports. That way the Four Score could have been made to naturally work with 3- and 4-player Famicom games without them having to invent a new protocol and reprogram the games.

Here is an (incomplete) list of games that uses two controllers but don't read D1 (external controllers) and merge them with D0 (internal controllers).