100-pin connector to FPGA/SOC, can I auto-detect if attached to NES, SNES, Genesis, N64, GB, GBA?

Question

If I have a 100-pin connector that may be connected to any of several known devices (NES, SNES, Gameboy, and so forth), can the device somehow auto-detect which device it's connected to?

For some of these, it may be possible to send a reset signal, or set an NMI address and trigger an IRQ, allowing simple brute force.

Answer 1

It's not impossible in theory. The Retrode cartridge dumper uses plug-in adapters that mostly connect to the Genesis cartridge port and, from what I remember of those, they're passive adapters. However, since the Retrode is reassigning pins of ports intended to receive cartridges directly, it doesn't have the free pins to do voltage assignment via hard-wired jumpers, so you have to set a 5V/3.3V switch on the PCB accessible inside the SNES cartridge slot.

Likewise, the BlissBox controller adapter uses passive adapter tails (controller connector one one end, repurposed HDMI connector on the other) which are probed to identify what the controller is.

I see the following downsides to autodetection though:

1. You're going to need dedicated physical adapters anyway, since it's not just a matter of "use a narrower edge-card connector and make sure it's plugged into the right subset of the socket. (Even for the non-portable ones which use a traditional/classic edge-card connector, not all cartridges use the same pin pitch and PCB thickness, let alone putting all the connections you need in the centre where a single shorter physical connector could be carefully aligned to match.

2. If you're building physical adapters anyway and you've got 100 pins, why not just make the smarts in the wiring of the adaptor, even if you don't use an EEPROM. (ie. Lay out the adapter PCB to always route pin X to reset, pin Y to NMI if it exists, etc. Tie pin Z to either the 5V rail or the 3.3V rail to select signal levels like with the jumper on many TTL Serial adapters. etc.)

3. Probing time is noticeable and reduces user experience in many use-cases... hence the reason to consider some sort of PROM (eg. EEPROM) if you don't have enough pins to use only the simpler pin-assignment-and-hard-wired jumpering approach to auto-configuration.

Answer 2

You have several solutions:

Pin probing

For each possible connected device, read all pins to detect voltage levels, input/output pins, clocks, etc. and build a "signature map" for each device. Once the detection is reduced to one only element, try to send some signals to known pins to confirm your guess.

Pros:

• You can use the full 100 lines of your connector.
• You can build simple adapters with simple pin-PCB and wires.

Cons:

• You can damage the connected device, since you will never be sure that a detection didn't failed because of a grounded wire and/or a bad soldering.
• Get the "signature map" of a device can be a real pain, and you'll need hardware and/or tests to get the correct values.
• You may have difficulties to adapt the generic program to this guess.

Smart connector

Keep 2 or 3 lines (according to technology used) on your connector to wire a small EEPROM. When building the adapter for a given device, you program the EEPROM with an internal code, and, better, the full mapping of the 98 lines: input, output, type, voltage, name, ... and you can read this EEPROM from the connector each time it's used. You can even set the EEPROM as read-only by not exposing the write pin directly, and keep a small "JTAG-like" interface on the side of the connector to allow programming it.

Pros:

• No possibility of bad detection: one side of the connector is for FPGA/SoC, the second is 100% specific to the attached device.
• No need to guess anything, you near only copy the pinout to the EEPROM and that's all - your program can adapt dynamically to it. EEPROM can even code a revision number if needed.
• Principle can work for other non-game devices.
• If EEPROM is big enough (they aren't so expensive), it can even contains the required FPGA/SoC microcode for the given device, so you'll only need a bootstrap on it.

Cons:

• Cost more, because of EEPROM, a sub-connector (even if it's a simple HE10), and surely a case - maybe 3D-printed however.
• More complex to start, but the more devices you allow, the easier it will be.