I just thought of a fun idea, a take on the modern DLC or user created content and NES games.
What some space was set aside in battery backed RAM for additional downloadable content, say extra levels and stuff. Then you could make your players download the extra material by for example pointing a Zapper at a youtube-video just flickering white for 1s and black for 0s with some kind of sync signal at the beginning of the video.
OK, sure - 1KB of data would make you point the zapper at the screen for 4 minutes at 30fps, but it would be a fun experiment. Plus it would be a really seizure inducing video
But you could put a nice tune to it to make it more fun to sit there with your zapper.
I am not a big fan of DLC in modern games, but it would be cool to let other people make puzzles for a puzzle game or levels for other types of games. User created stuff can often be as good as the original content. You could easily ship a level editor and have it generate a video file to upload.
I haven't figured out any other good ways to get the data from the internet into a NES cart using stuff people usually have at home. Perhaps the mic on the Famicom would work.
What do you think? Am I crazy? Would this type of thing even work?
I think it is a clever and interesting idea, but I have concerns about LCD displays that aren't too good in changing between black and white fast.
I guess that's true, but they should be able to handle 30fps ok, even the worst monitors.
I do wish someone would make a ram cart plus transfer cable for controller port 2, but maybe there's no point if it takes like 5 minutes to transfer a 256kb rom to the cart. And I'm pretty sure someone (Blargg?) made a boot loader for such a thing.
I don't think the Zapper would work at all. I seem to remember it relying on the 15.7 kHz horizontal scan frequency of a CRT SDTV.
As for blargg's bootloader, thefox mentioned it in
this post. But then you'd have to build a bunch of cables and include one with each copy of the game.
tepples wrote:
I don't think the Zapper would work at all. I seem to remember it relying on the 15.7 kHz horizontal scan frequency of a CRT SDTV.
As for blargg's bootloader, thefox mentioned it in
this post. But then you'd have to build a bunch of cables and include one with each copy of the game.
OK, I don't really know much about how the zapper works. I thought you could just read it at any time and check wether or not it detected light. If it relies on timing of the composite signal, then I guess the idea will have to be reimagined in some other way. I'll try and read up on how it works.
Isn't it basically just a photosensor directly connected to a port, and only software is the thing that relies on specific TV timings to determine the hit position? In this case it should work just fine to detect black/white changes, as position does not matter there.
I thought it was a photosensor connected through a resonator. But then I haven't done much testing with light sources other than a CRT SDTV.
I never messed with the original Zapper as well, only fixed tons of clones for Famiclones, they had broken cords/plugs for the most part. In those, there was no resonator, just a sensor, transistor, and a couple resistors. In the past I have heard many times that people were able to fake hit detection by pointing the sensor on a light bulb.
From what I can gather from the wiki, one can read the zapper at any time and see if bit 3 is set or not. The implementation of hit detection in games seem to vary from timed code to simply checking if you hit anything white during the entire frame. So it looks like it should work. I will probably do some tests with this, I just need to get a working zapper.
When you fire the zapper in most games you can see white target boxes which flash on the screen briefly. Games may check to first make sure the zapper sees no light, then light for a particularly frame. If you only detected hits if the zapper saw light, you could point the zapper at a traditional light bulb and just pull the trigger. I have heard that flicker light, perhaps a florescent light could unreliably register false hits.
That's an interesting way to try to download data. But I don't think the light from a modern digital TV (LCD and Plasma) works with the zapper. The light from a CRT is more intense. Newer lightguns actually have more complex logic behind how they function. The NES Zapper is pretty simple.
How could a light not work with a photosensor? Even if it is too dim (lower contrast ratios are there indeed), just put the Zapper closer to the screen.
All the complex stuff in modern light guns is there only to provide a good precision, which is not needed in this case at all.
Should be easy to test on hardware, provided you've got a zapper and some dev cart (e.g. PowerPak).
The test I imagine is: each, say, 30 vblanks, toogle the display from all black to all white and vice-versa. Continuously poll the "detection" bit, as soon as it is set, output a loud beep, otherwise silence. The slowly flashing screen is to verify that the "beeper" code works reliably when the zapper points the TV, then after we can see if it beeps when the zapper points a bright light source.
The Zapper contains a 16kHz resonator of some sort, equivalent to the exact same parts used by your infrared remotes, just using a photodiode that's sensitive to visible light instead of infrared.
It is very unlikely that it will work with an non-CRT-SDTV, although given how most NES games used the zapper, it should be possible to modify one to work with a modern TV.
That's interesting. I found
Zapper schematics, and it is way more complex than the one found in clones, it has a demodulating IC or something (no resonators are seen, though). Sega Master System also had very complex schematics with six transistors. The clones had only R2, R4 and Q1 from the Zapper schematics, with photosensor connected to the base of the transistor.
Shiru wrote:
That's interesting. I found
Zapper schematics, and it is way more complex than the one found in clones, it has a demodulating IC or something (no resonators are seen, though). Sega Master System also had very complex schematics with six transistors. The clones had only R2, R4 and Q1 from the Zapper schematics, with photosensor connected to the base of the transistor.
Yeah, ok, "resonator" is a bit of a misnomer; it's a demodulator comparable to the ones mentioned
for LIRC's homebrew IR receivers
What I've been calling a "resonator" is in that IC, and it's underclocked from the
typical 35.75 or 37.92 kHz. Essentially what the photodiode picks up is a stream of scanline height values,
pulse position modulated with a 50 or 60.1 Hz carrier, and further
amplitude shift keyed with a 15.7 kHz carrier. The IC decodes the ASK, and software such as the "zapkernels" in Zap Ruder decodes the PPM.
The zapper either sees white or black, it'd be a trivial test I'm surprised no one (including myself) has actually done it yet... There might be an additional limit based on how fast these monitors can switch black/white but that issue would only slow the transfer rate.
MottZilla wrote:
That's an interesting way to try to download data. But I don't think the light from a modern digital TV (LCD and Plasma) works with the zapper. The light from a CRT is more intense. Newer lightguns actually have more complex logic behind how they function. The NES Zapper is pretty simple.
The reason games don't work on LCD/plasmas is due to timing delay these displays have from what I understand. The delay wouldn't affect a download because it'd be synced up from the source. In fact I'd bet you could even make a homebrew that'd work with a LCD/plasma TV if you 'calibrated' your sensing code to the delay that exists on that specific TV in the beginning of the game.
Well that's true, digital display are delayed versus good old analog CRTs. But the qualities of the light matter too.
MottZilla wrote:
Well that's true, digital display are delayed versus good old analog CRTs. But the qualities of the light matter too.
Yes but we're only talking about a threshold of intensity here really. Blacks are certainly more dark on LED/plasma TVs compared to CRT. If whites are as bright/brighter then you we should be good.
And for the speed thing... LEDs switch on and off *DRASTICALLY* faster than phosphor gains/loses it's light. I don't know about plasma but phosphor is still damn slow, and PC are usually LED anyways. The argument of speed doesn't really make much sense to me anymore assuming you can get a video frame rate close 60hz or as fast monitor refresh (>=60Hz).
The so called 'LED displays' in modern TVs and computer monitors are still the same LCD displays with the same old technology limitations (switch delays), only with LED backlight, which is constantly turned on.
Well remember how people complain about eye strain when staring at a CRT for a long time but not so much compared to LCDs? I'm sure more light beams out of a CRT than a LCD. How bright does the light going into the barrel of the zapper have to be to register properly? More importantly, is anyone going to try this data transfer out? I don't know that a youtube video would work since video encoding and performance issues could disrupt your perfect video that you planned.
People complained about CRT TVs because there was 50/60 Hz flicker, quite noticeable. There is no flicker at LCDs.
As we see brightness/contrast ratio/colors on a LCD display very close to a CRT, wavelengths, spectrum, and amount of energy in the light is roughly the same.
YouTube encoding certainly will hurt the video, though, that's for sure, as it can't properly display videos with high framerate. I uploaded a number of 60 FPS videos at YouTube that were perfectly smooth, and they all look jerky after upload.
Youtube encoding is 30fps max, but that's ok. I don't think the encoding should hurt a video just switching from all black to all white and back. That should be very easy to compress.
Well, you're also lucky if you can get YouTube to play back at a reliable 30fps. It is generally a bit unstable and will skip frames here and there.
Sounds like you guys are reinventing ROB!
Yeah, the encoding will hurt the video - even if what you upload is correct it will get hurt by the reencoding YouTube does. There's also the framerate issue, not only YouTube would need to have perfect vsync, but also the refresh rate of the monitor needs to be a multiple of 30Hz or it won't work (for 60Hz that'd be OK, but what about 85Hz?). Not to mention, such a video would be a massive cause of seizures and there are chances Google may decide to take down such videos for that reason.
Entering passwords seems a better idea at this rate XD
Sik wrote:
Yeah, the encoding will hurt the video - even if what you upload is correct it will get hurt by the reencoding YouTube does. There's also the framerate issue, not only YouTube would need to have perfect vsync, but also the refresh rate of the monitor needs to be a multiple of 30Hz or it won't work (for 60Hz that'd be OK, but what about 85Hz?). Not to mention, such a video would be a massive cause of seizures and there are chances Google may decide to take down such videos for that reason.
Entering passwords seems a better idea at this rate XD
I guess you could easily tell the difference between the length of one frame over two frames. No need for perfect sync.
The problem is worse than that; video in browsers is not generally vsynched at all. In addition there is no way to guarantee that every frame is displayed, let alone every second frame (skips often come in bursts). YouTube is like the UDP of video.
Also it's kind of useless unless the video encoding can even DO alternating single-colour frames. I haven't tried that kinda thing, but am not sure if it would turn out properly at all with normal video encoding algorithms.
Skipped frames would be an issue. I will do some tests. I guess one could also release extra content as a small video file for download on a website using a codec that would work better and let the user play it in a nice vsynced environment like VLC. You could even release it as a little app that flickers the data over to the zapper. Youtube was an example just because it would be a nice easy way to upload stuff.
I think it'd be more reliable to do it the old-fashioned 8-bit computer way of using cassette tapes. If you need sample code to read/write cassette tape data, Excite Bike and Wrecking Crew have it built-in (look at the load/save options in edit mode, on the NES version). The DLC can be read off of the tape and stored on battery-backed RAM inside the cart for convenience.
You could also use the FDS, but you have to deal with load times. That and I don't think anyone makes FDS disks anymore, let alone devices to write to them.
We should definitely make our own Tape Deck interface. It's the future of whatever it is we are doing... They still make Cassette tapes right?
Anyway I think you'd need an actual computer program to run to display your encoded video stream of data. To reduce the possibility of performance/frame rate issues. But in the end a serial cable of some kind is probably better.
The nice thing about an audio format like the
Family Basic Data Recorder is that you can also use MP3s. However, that's only useful to people with the original keyboard. And once you're building new hardware, you may as well use a design like blargg's asynchronous serial interface or byuu's SPI interface.
MottZilla wrote:
They still make Cassette tapes right?
Yeah, they're being quite profitable for TDK actually. They went the way of vinyl, a small niche market but with a strong demand. Especially for good quality ones.
How does the tape deck on the Famicom work though? Because if it takes an audio-in line from a generic tape player you don't even need tapes at all, you could just connect anything that makes sound to it.
The beauty of the original idea is that it is plain simple - just use existing hardware, point the gun at TV. Tape interfaces aren't available on the stock consoles, so it is not interesting anymore, you could just add a SD, USB, Ethernet or whatever interface as well.
Well, this is an idea for a cartridge that you can download content to. With this in mind, specialized hardware might be acceptable as long as it's part of the cartridge or comes with it.
Connecting a stereo mini or RCA cable directly to the cart might be acceptable. Turning the audio signal into some pollable registers on the cartridge probably wouldn't take too much hardware. Alternatively you could package with a controller port to USB connector, or something like that.
Sik wrote:
How does the tape deck on the Famicom work though? Because if it takes an audio-in line from a generic tape player you don't even need tapes at all, you could just connect anything that makes sound to it.
Two mono 3.5mm jacks, so yes, you can use things other than the tape deck. But as Shiru and I pointed out, the number of people with Famicoms and Family Basic Keyboards is miniscule and once you're building any hardware, you may as well use something with better bandwidth.
If you're going to put hardware in the cartridge, you may as well use a cheap PIC and use the extra pins for mapper control.
There's just one really obvious with the whole zapper approach. Load time. Let's say you're using something like Run Length Limited, and letting each frame stay on the screen for two frames, for about 6 bits transferred every 16 frames.
To transfer 8192 bytes would take 48 minutes at that speed. If you were using the highest possible speed (one bit per frame), it would still take 18 minutes.
Still acceptable for an extra level in Battle City or Lode Runner, though. In fact, the concept could be extended even further - a save feature through a VCR. To save data, a game plays the blinking sequence that could be recorded on a VCR, and to load, you playback the recording reading it with Zapper. Even more fun than a mile long password.
I like the idea, but the problem I see with using the Zapper to transfer data is that from what I understand, (probably already mentioned) that it's only going to work with a 15khz H refresh rate monitor (CRT TV and not much else). Sounds like it's not a problem for some of the Famiclone lightguns though.
I wonder if the Zapper VCR saving idea would work, that would be cool.
BTW, this really should've been on the nesdev main page:
by sepi, this was confirmed to work with Excitebike, etc. recording to a PC soundcard (not sure if he tried tape).
Just to add to the 15kHz evidence:
Quote:
The phototransistor serves to detect the light from a target on the television screen to convert it to an electric signal, the output from said phototransistor being amplified by the transistor, and only the detection signal which corresponds to the horizontal oscillation frequency in the television synchronizing signal is extracted by the filter formed of the capacitor and coil, the other frequency components being attenuated.
That's from Nintendo's patent, “Video Target Control and Sensing Circuit for Photosensitive Gun.” And they anticipated players cheating by firing at light bulbs:
Quote:
The light from this white picture is detected by a phototransistor, whose detection signal, when extracted by a filter, is used as a detection signal from the target. Thus, there is no danger of mistaking the light from an illuminator for the light from the target.
Smart.
noattack wrote:
And they anticipated players cheating by firing at light bulbs
Even if they didn't, this is simple enough to prevent in software: show a black screen before displaying white targets. If the gun is detecting light while the black screen is on, it's obviously not pointed at the screen.
Or even quicker, as I discovered during the development of Zap Ruder: If the gun is registering light near the end of vblank, then there are two possibilities. Either it's pointed at a light source other than the TV, or it's not plugged in.
tokumaru wrote:
noattack wrote:
And they anticipated players cheating by firing at light bulbs
Even if they didn't, this is simple enough to prevent in software: show a black screen before displaying white targets. If the gun is detecting light while the black screen is on, it's obviously not pointed at the screen.
Which is the method used by Duck Hunt, if I recall correctly. Looks like the programmers were completely unaware of this feature. Then again, is this circuit in all the guns or only the Zapper? Maybe the Famicom gun doesn't have it...
Now, even if we solved all those issues... what about the player having to aim the gun at the screen for all this time? Relax for a split second and you completely broke the transmission. Also I assume this is for LCD screens and the like? Because with a CRT the read needs to happen in the very moment the beam appears in the gun's sight.
Shiru wrote:
Still acceptable for an extra level in Battle City or Lode Runner, though.
Calculated this for Battle City: 676 bits (13×13×4-bit). At 60FPS (the maximum, and assuming a perfect transmission), that'd mean around 11.27 seconds. At 30FPS (the original proposed framerate) it'd be 22.53 seconds. And this is not making room for parity bits and such.
Considering how bad your average human is at keeping the arm in the exact same position for long periods of time (you're bound to at least wobble the arm a bit, which can screw things badly)... yeah, it's probably still not acceptable. It'd be very prone to errors still.
EDIT: and since we're also mentioning how if you're making hardware you may as well provide your own way to do it... we could go the extra mile and say we don't even need to do that. Just use a flashcart and replace the ROM whenever you want to add new stuff. Then you could add the DLC through some program with a computer or something.
Sik wrote:
Also I assume this is for LCD screens and the like?
It's still unclear whether the zapper can see light from modern displays.
Quote:
Because with a CRT the read needs to happen in the very moment the beam appears in the gun's sight.
Why? I don't see why timing is critical for this at all. AFAIK, timing is only critical with the zapper if you're trying to detect the (approximate) coordinates the zapper is aimed at (useful for locating in game objects, but pointless for reading bits into the console).
Quote:
Considering how bad your average human is at keeping the arm in the exact same position for long periods of time (you're bound to at least wobble the arm a bit
Personally, I'd just put the zapper on a table or any other surface pointed at the TV.
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.
Just make a clone device which is compatible with the Famicom data recorder. I think that would work best.
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.
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.
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.
Shiru wrote:
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.
tokumaru wrote:
Shiru wrote:
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.
Quote:
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:
Attachment:
sch.png [ 1.36 KiB | Viewed 1369 times ]
Quote:
and whether it's possible to make one for the NES that doesn't requite opening the case and soldering stuff there.
Unfortunately not.
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
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.
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.
zzo38 wrote:
(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.