NES DLC idea

[Nioreh]

Well bad news for the Zapper . I can confirm that it really doesn't work on anything but CRT TV screens. I bought an original zapper and wrote a small test application. I've been roaming my home pointing the zapper at anything that shines to see if something would register . It doesn't even register light bulbs as wikipedia claims. The only thing that seemed to register as a light was my fluorescent lights if I pointed at them from just the right angle.

[zzo38]

Just make a clone device which is compatible with the Famicom data recorder. I think that would work best.

[infiniteneslives]

With the zapper effectively shut down there really isn't much point to dink around with old technology unless you're just using old tech for the sake of using old tech. The options that'd work best and are most cost effective are going to be something like controller serial cable or other high speed interface through the cart or EXP connector.

I had an idea awhile back that I'd like to make good on that uses a AVR micro controller to program SPI memory via USB. Ideally the mapper could read back the SPI memory in bytes vice bits. You could even cut cost with Jim's Cool open CIC and dual purpose the AVR as both a CIC and USB interface for reprogramming (prob not at the same time though). That'd keep everything contained within the cart and not require additional devices to be owned/purchased by the user, it'd only cost a $1-2 dollars more in hardware. Plus you wouldn't have the connector acquisition and host PC interface issues of controller and EXP methods.

[lidnariq]

I have to agree with infiniteneslives; once you're building any hardware, you should use something that's less obnoxious (and higher bandwidth) than the data recorder.

If compactflash weren't horribly moribund I'd vote for it because it combines "minimal support hardware" with "ubiquitous", but we're close to ten years too late. SD would be good but requires much more support hardware. I agree that the next best combination of "cheap" and "easy for the end user" is most likely some high speed PC interface, especially if it's either combinable with the CIC or the mapper hardware.

[Shiru]

Thought to mention an option available on the Famicom only - the microphone in the second controller. I have an universal TV remote that supports upgrading the firmware by putting it against speakers while a special audio file is played, it could be something similar.

[tokumaru]

Thought to mention an option available on the Famicom only - the microphone in the second controller.

I suggested something like this (using the mic for data input) a while ago, but there wasn't much interest.

I still don't know how the microphone is connected on the Famicom, and whether it's possible to make one for the NES that doesn't requite opening the case and soldering stuff there.

[lidnariq]

Thought to mention an option available on the Famicom only - the microphone in the second controller.

I suggested something like this (using the mic for data input) a while ago, but there wasn't much interest.

There's this penchant here for thinking that we are sort of obliged to aim for things that work on as many different variants of the NES as possible; a restriction like "famicom only" or "family basic keyboard on famicom only" is a mess.

I still don't know how the microphone is connected on the Famicom

Looking at the pictures that rainwarrior provided in this thread, it's close to this:

sch.png (1.36 KiB) Viewed 1784 times

and whether it's possible to make one for the NES that doesn't requite opening the case and soldering stuff there.

Unfortunately not.

[Sik]

Silly question: what are 2P Start and Select mapped to and what is the microphone mapped to? I wouldn't be surprised if the microphone overlaps at least the bits of one of those buttons - in which case you're pretty much looking at just making a replacement controller. The microphone doesn't seem very reliable anyway...

And yeah, if you want to make something that's bound to work everywhere, hardware on the cartridge is the only option (you can't rely on the I/O ports since they differ between the NES and the Famicom, the lightguns don't work, etc.), or if you're transferring small amounts of data, passwords =P

[Dwedit]

Microphone is not in the same set of bits when reading joypad data. It is in a separate bit of register 4016. (see http://wiki.nesdev.com/w/index.php/Cont ... _registers )

The only thing Microphone intersects is the Service button on a VS machine.

[zzo38]

I think is best do something working in different kind of hardware, such as NES, Famicom, AV Famicom, emulator, etc. Data recorder already exists and there is a diagram in wiki to use in NES expansion port too. However, it could also be done multiple working by software instead of hardware, so you could support other methods (such as CIC, but I think top-loaders don't support CIC?) in the same software, and use whatever is available.

Other emulators and hardware clones may have their own support for things, but you may not necessarily consider them important. Famicom-XE (not exist yet) would support: cartridge (except CIC, since it is 60-pins), data recorder, NES joypad ports, Famicom expansion ports, microphone. A clone device I have (but I have no cartridges) has only a cartridge slot and player 2 port, and the player 1 buttons are built-in to the console. However, I do not know how accurate it is.

You could possible make the device, which emulates the data recorder, and can connected to NES expansion port and Famicom expansion port. Therefore, you can make it to copy file to computer to store the same format as emulator on computer which emulates data recorder.

Some software would be such way that it intends to require the keyboard; in that such way, can use with data recorder (or clone keyboard with built-in data-recorder if it follows the Famicom keyboard protocol), but not all of software on NES/Famicom would be the one which uses keyboard.

[infiniteneslives]

(such as CIC, but I think top-loaders don't support CIC?)

It supports it just fine, (it doesn't care whether it's there or not). My suggestion doesn't rely on the CIC, so the AVR mcu would only have one thing to do vice two.

No need to argue though One can make whatever one pleases. If something were to actually materialize the users will ultimately be the ones to decide if it's a 'good solution' or not.