What useful permanent peripherals via the expansion port?

Since Myask pointed out this really should be a separate thread ...

The question posed by B00daW becomes "what useful aftermarket things could go along with the audio jumper and be useful?"

* I guess there's actually use in adding a microphone jack, given existing Famicom software that expects to be able to read [$4016]&4 ... Unfortunately this pin is on the opposite side of the one needed for just the audio jumper.

Beyond that, there's a vague restriction of "things that are can be interfaced using SPI or I²C", but that's about it.

Here's all the random things I can think of:

* Serial EEPROM: Probably not very useful. Most modern homebrew is on parallel NOR flash, and often can self-write, so access to a large amount of extra NV memory (but only for people that added this peripheral) in the console isn't clearly beneficial anymore. (There's actually a vague precedent for this: the Famicom peripherals "Battle Box" and "Turbo File" are battery-backed serial memories that connect to the Famicom's expansion port)

* Multiband (AM/FM/SW/LW/Weather) radio IC such as Si4734/Si4736: Don't see how it could be generally useful. Listening to radio on your NES is an amusing gimmick... and having it in the expansion port means that we can use "which stations in the area" exist as a random number seed, I guess.
More nearly useful: FM radio IC with RDS (such as Si4731/4739): the contents of RDS (at least in the US) is mostly crap, but it's likely that at least one station in any major market includes RTCC data. Maybe good for a slight bit of augmented reality.

* An actual RTCC: We could probably come up with some way that this'd be useful rather than annoying. (While Animal Crossing's rate limiting was arguably ok, requiring that you play at multiple different real-world times-of-day isn't really)

* A GPS: Less creepy than modern smartphones, since it can't communicate to anything outside, but ... even assuming you can get a lock indoors where you're playing, I don't see how this would be generally applicable to multiple games.

* Generic I²C I/O expander connected to some sound IC like the SN76489. Self explanatory...

* serial ethernet interface (e.g. ENC28J60): Well ... uh, yes, it could technically work. The low bandwidth and lack of work RAM inside the NES would make it difficult to use.

* extra software-controlled LEDs.
* measuring random things (accelerometer, magnetometer, gyroscope, light level, temperature): really?

The expansion port has been used to tweet, with the help of a middleman circuit interpreting.

looking at pinouts you could by putting some extra control logic on the cart, map some address lines into the EXP lines, and then put some expansion chips into the expansion . Maybe some Maths chips, C/VIAS, extra sound chip for the chip tunes makers. Maybe some GPIO for debugging assistance for devs.

Such things to add into NES expansion port might be: microphone input, support for expansion audio, Famicom expansion port. Those should be the only "permanent" stuff, although other stuff might also be provided if they can be switched off when not in use (if anything useful can be thought of, and so far there does not seem to be, as far as I can tell?).

I think RTCC would primarily be useful for simulation, virtual pets, interactive aquariums, doll houses. Especially combined with flash memory. It could be anything from something like the sims to tamagotchi to maintaining a mars colony or managing a hotel or a gene lab.

And of course for save data, sorting jobs, etc.

The RTCC certainly has past history. NDS, Gamecube, and Wii games have access to one.

But the ways I've seen it used?
* Animal Crossing uses time-of-day to gate certain things (NPC location, capture-able things). This is good for being immersive, but absolutely awful for either encouraging cheesing (changing) the RTCC, or breaking the game player's real-world schedule.
* Animal Crossing uses day-of-year for easter egg content
* Sword and Sworcery makes you wait up to a month (until the next full moon)
* Netflix somehow uses it because it stops working if the time is more than an hour wrong. (Either something about stream encryption or something about streaming rates)
* A bunch of games use "at least N real-world hours must have passed in order for Next Thing"

So... I have to admit that it's probably the only obvious choice, but that it's not for games that are For Me.

(Reference: http://www.trapzz.com/?p=14 )

Little Computer People (an early "sim human" game) got around the lack of a clock by asking you to sign in with the current time/date when you started the program.

To the original question though, for "communicate to an external device" purposes it normally seems easiest to do it through the controller port, or directly to the cartridge, which kind of rules out a lot of expansion port options very quickly? E.g. Miracle Piano connected MIDI to the controller port. MIDINES connected MIDI to the cartridge. (FDS is another one that connects to the cartridge.) So even if you need higher bandwidth, building a connection on the cartridge itself might be easier than going through the expansion port?

Does that leave much at all besides the audio expansion and PPU-overlay ideas? I'm trying to think of anything applicable. What does the expansion port have that the cartridge or controller ports don't already?

I'm wondering if you could make some sort of "debugger" device that's some combination of game-genie style cartridge pass-through, plus an additional listener through the expansion port if there's extra information to be gained there.

Anything using the cartridge port can't run on a PowerPak or EverDrive, and anything using the controller port can't run with two players or a Gotcha!-style controller+Zapper setup.

Very little. As far as I can tell:
Unlike the cartridge, it can be shared between multiple games.
Unlike the controller ports, it provides a wider bus, and can be used at the same time as the controller ports.
(Unlike both, it won't work on NES2s)

Hence the question: Are there any peripherals, useful to a game developer, that would take advantage of both of these differences? An I²C or SPI peripheral could be connected almost-directly to the NES/Famicom expansion ports without changes, just due to the extra OUT lines available.

... Maybe I put this in the wrong forum?

Ah, yes the PowerPak is SOL but the EverDrive actually does have a USB option on it, though it costs slightly extra.

If you want to support 2 players I guess you could build a multi-tap device into whatever controller port dongle you're already making for the project, though I could see how that's getting to the point where it might just be less annoying to build an expansion port device instead.

Oh, that reminds me of yet another option. The CopyNES is another I/O port that some people have installed. (Did it end up being part of the HD-NES?)

Admittedly probably less attractive than most other options, but it's come in handy for me more than once for this kind of purpose.

Any expansion port expansion also has the plus of expanding every mapper type out there with functionality, however little functionality that might be. In other words, a dev wouldn't ncessarily have to choose (this traditional mapper does this but that other mapper has this new thing). It's always going to be a minus having to have the thing, though.

Memblers shipped me an controller port to USB cable for flashing carts via a modified game genie. It made me think maybe a regular PC could act as a middleman for networked gaming.

I guess RTCC would work "best" in the following types of interactivity:

-Change of scenery, perhaps dialogue details, not gameplay (change palettes, tiles, depending on ToD/Time-of-year).
-Make the player come back for more at a later time, but at the same time, maybe avoid "make the player wait" features. Do they overlap? Oh yes. But logging in each month to get a new cosmetic options unlocked in a town store isn't too bad.
-Any feature in a game where you can't really fail in a critical sense but play to see/find out what happens.
-Just to know when you last played.

Extra controller ports [be they Famicom-compatible or no] are the main other thing, really…

Full blown theremin controller for a new series of games: Awkward Pong, Awkward Arkanoid, Awkward Golf.

But there was already an official one of those? no, u-force was IR.

In a way it would be realistic for the purpose of golf/minigolf: If you don't control your breathing, your swing will risk being off.

A ribbon controller could actually be a relatively interesting peripheral. More easily precise than a theremin, but unlike a potentiometer (arkanoid controller), you can make direct jumps with your fingers. The slew rate would be controllable in software rather than capped by the inertia/travel of the pot. You could layer it with a pressure sensor. But what sort of game would benefit from it? My first thought is some sort of player-controlled-scrolling sniper game.

Would some kind of IRQ be of any use? Or is that too much easier to just build into the cartridge?


I'm reminded that the RetroAVS has a scoreboard feature built into it, so that's maybe an example of a permanent extension already in use.

Maybe an expansion port adapter could connect to lots of stuff, but if there were to be one "pack in" device that comes with it I can't see it being anything other than an ethernet adapter of some sort. Aside from the RetroAVS' scoreboard, there have been other instances like the ConnectedNES demonstration, the ENIO, etc.

If it had a cable that plugged into the expansion adapter it could be easily swapped for something else, if there was some other device people wanted to use, but that's really the only thing I've noticed multiple people wanting to do. It also kind of covers the requests for real time clock, additional storage, etc.

Maybe just thinking about what pins on the expansion port only have a single feature, and which have many... some of the audio and joystick ports seem like they only really have one allocation to me:

• Audio expansion: already a given.
• Famicom microphone: though personally I don't think there's much interesting use of it in games it's probably a marketable hardware feature.
• Famicom multitap: more obscure than the microphpone (and I can't remember if the "multitap" famicom games even work properly).

Aside from the CPU data pins, and the remaining EXP pins, there's still a few joystick ones left too. I guess you could make a connector that takes these out to the "prime" device, which might be ethernet (or ethernet + keyboard like the ENIO was trying to do), and any other new peripherals might just swap cables to replace it, or it could even be a breakout box device that you can plug more things into? Depends on how fancy you want it.

The problem of ethernet and/or keyboard is doable through a controller port of course, but after tepples mentioned second-controller conflicts I started to think of how attractive a "permanently attached" device that is otherwise out of the way could be. A nice package of wifi NES + expansion audio + demo software all in one box? If it had a Famicom expansion port alternative version even the RetroAVS could use it, maybe?

It'd be a great theme for an NESDev compo too. (A compo cart bundle with very viable self-flashing DLC?? Or even just WRAM you could download "NESDev BASIC" programs to? This is almost PICO-8 territory.)


Sorry if that's getting out of the way of the original question but I'm beginning to really see the appeal of this.

That's exactly the kind of musing I was hoping to elicit.

Actually it's making me think that an "NESDev BASIC" might be a fun project for me to enter in the next compo, whether or not there can be hardware support (easy to add incrementally later on).

I guess the most compatible thing would be just using controller 2 D3/D4, allowing connection via NES or Famicom expansion ports or directly through NES controller 2 port. Bandwidth wouldn't be optimal, but should be enough to fill up a 16k block in a few seconds anyway?

Doing that wouldn't make the expansion adapter so "essential" but it could still help get the foot in the door. The expansion port adapter itself would probably be a low cost part in this equation anyway, but a good piggyback.

A 2D ribbon controller is called a "graphics tablet", and something like Videomation would benefit. So would Thwaite or Operation Wolf or anything else that's point and click. Heck, so would Marble Madness, using the tablet as a trackpad to replace the arcade game's trackball.

Re rainwarriors' idea: Something like a game patcher for homebrew could definitely have some value. Throw a patch at an app icon, and done.

Would a screenshot extractor be possible w/o too much hardware?


Re: Tepples: Right! Then there's shadowgate, maniac mansion, etc (provided an adapter is hacked in), + that game m-tee has shown teasers of. It'd also work well for my little submarine periscope project.

On the subject of peripherals, how about an endless rotary encoder? It measuring change cw/ccw rather than a position should make it straightforward to interface. Any game or app that could benefit from precise movement or adjustment could also benefit from it. For games like marble madness, a graphics tablet/trackpad/trackball is better, but pinching an encoder knob would be more precise for 1d-aiming/adjusting/positioning/steering/delta-velocity types of games.

Do you really need the expansion port for these kinds of controllers? Using the built-in controller ports you have access to $4016 and $4017 D0, D3 & D4. That gives you 24-bits of serial data for eight reads.
The SNES Mouse only uses one data line, so a trackball and a rotary dial should act similarly. A graphics tablet only needs to give 8-bits of data for X and Y.

Rotary Encoder
Arkanoid
Arkanoid II

Rotary Encoder and Joystick
Guerrilla War
Heavy Barrel
Ikari Warriors
Ikari Warriors II
Ikari III

Trackball
Blades of Steel
Cabal
Marble Madness
Millipede
Rampart

Mouse
Deja Vu
Maniac Mansion (most PC versions)
Shadowgate
Uninvited

Steering Yoke + Shifter + Pedals
Spy Hunter

Steering Wheel + Pedals
Danny Sullivan's Indy Heat
Final Lap
Hard Drivin' Prototype
Ironman Ivan Stewart's Super Off Road

Throttle Lever
After Burner II

Analog Joystick
After Burner II
John Elway's Quarterback

In fact, given that PC trackballs appear to the computer as a mouse, an NES trackball could use exactly the same protocol as the Super NES Mouse.


Smash TV and other twin-stick shooters could be adapted to work the same way.


If Millipede can be adapted to use a mouse, trackball, or trackpad, so can any shmup. (Touhou Project anyone?) Many games using a trackball or mouse would work well with an analog joystick as well. Blades of Steel, for instance, could use the control scheme of Wayne Gretzky's 3D Hockey.

If you mean through an ethernet device, sure you could dump the current CHR / nametables / OAM / palettes over that (~10k of data) and send it wherever it needs to go to be re-synthesized (emulated) into a screenshot, or you could even convert it to a BMP or something right on the NES if you wanted, and send that, though it would be a lot more data.

If you mean capturing the video signal via the pin on the expansion port, I think you could do that too, but it would basically be the same as just connecting the regular video output cable to a capture device?

All raster effects would be lost though, so I can't see this being particularly useful.

There's really no reason you couldn't dump information about raster effects as well. This isn't an actual PPU capture. You can send whatever information you think is necessary to re-synthesize the "screenshot" on the other end.

I'm reminded of an older thread where an "NES video codec" was being proposed as a way to compactly store NES video information. (An idea I liked, but didn't think would fly.)

As for the utility of it, the current generation of consoles all have a screenshot button right on the controller. People do seem to like posting screenshots to the internet.

Yeah, since each game is aware of how it generates its images, it's possible to have custom screenshot routines that send whatever information might be necessary to reconstruct everything (like a log of changes with pixel coordinates). I was just pointing out that a generic solution wouldn't work for all cases.

Trackballs and mouse are largely interchangeable, but trackballs have the additional property of being able to spin. But, since the mass, intertia and friction will be different between manufacturers and even models, it is precarious to make software which is overly dependent on this feature. It can be done, but risk being inconsistent. Unless it's a limited run cabinet/kiosk, which is what i sometimes do, but touch screens have largely replaced trackballs in this field as they're a more direct medium for info/experience/browsing type of apps and come cheap. Else the "spin" could be used to move quickly through a large assortment of items in this field; something the swipe has replaced.

If one can accept that results regarding free spin will vary in a more or less decentralized production model of a new controller including a trackball, it'd be a fun thing to take advantage of. I've experienced something similar live on an old soviet arcade machine where the steering wheel of a racer game was very heavy and freespinning, meaning the spin had some force/weight to it. It really enhanced the fun beyond the software's simple premise: avoid smashing into other things until the stage is clear.

Trackball HW (on Mouser, for example) often come with an optional encoder-to-usb-mouse pcb, complete with pins for normally up to three switches (read as mouse buttons).

If human interaction peripherals don't require the expansion port, though, maybe a branch is in order, if there's enough interest to continue the subtopic.


You might want subpixel precision, though.

Good point. This inertial behavior is also familiar to users of Android and iOS, who expect scrolling to slow gradually after lifting a moving finger. I guess this makes a trackpad a better match to a trackball than a mouse is in some ways.

Here's something "useful" for the video out pin and/or separate graphics elements as raw data:

Send it to a touch screen built into a hand control (with a headphone output). NES U. I don't know if i'm serious or joking.
Maybe homebrew could exploit this to upload a map/menu to one nametable and have a game screen on another. A small memory onboard could be used to configure it to either mirror the video out or sent graphics data.

While i'm at it:
-Include a gyroscope (or other controller elements) for some mario kart wii action in your 2d racer.
-RFID/NFC reader/writer to store/read game data for the compleete "U" experience. Trade them at school

^^^boo. If we're gonna do that, bar/dotcode instead, be an e-Reader.

It's of some use; it lowers per-unit cart cost by putting it in the expander
You have A15 on the expansion connector, so you could practically just run traces A0-8 and R/W to EXP lines, and have the expansion device (the 16XDD) decode what ports do what.

Actually, that brings up a novel, but silly use of one EXP pin: giving A15 proper to the cartridge. This would also serve as a way to hard-require the device's installation for playing a game.

Like this? Not to be confused with the Virtual Boy - but it will hurt your eyes all the same if you do

like the Barcode Boy or the GBA e-Reader…though I suspect having an insert+remove-style would be better for a home-console.

Magnetic strip reader! card-chip reader! Credit-card requiring home arcade games!


vvv Yeah, or that; forgot as-unfamiliar what the NES version was.

Or the Datach...

Except nowadays the e-Reader is so forgotten that people think it means an electronic device to display downloaded books.