Someone brought up the problem that the existing NES emulator runs at a miserable speed(6 fps?) on the 360 but that's not as big an issue as you would think. Realizing that the 360 has incredible specs in comparison to the ancient computers that ran NESticle with no problems, it shows the importance of optimization. If someone took the time to optimize all the code in said emulator then I think it would probably be able to work at decent speeds. Also, consider that the PSP with all its various emulators(SNES, PSX, PSP) runs a 333mhz processor while the Zune boasts a 532mhz processor with a supposedly more efficient processor structure (ARMS (Zune's) vs. MIPS (PSP)) and it makes the Zune seem rather impressive. A couple things the PSP has over the Zune however would be the size of the memory, the Zune having maybe 16mb(?) and the PSP having 32+mb as well as the dedicated GPU. I think that if someone did a bit of optimizing, you could easily pull that 6fps to NES emulator. In fact, GBA and SNES emulators probably wouldn't be that much of a stretch although either one would be a helluva lot of work. One last thing on it, I'm not sure how efficient XNA and C# really are, but I doubt they are inefficient enough that they would keep you from getting a desirable FPS after enough work it.
Also, someone was asking how they would go about storing the ROM's on their Zune. There are two ways I see this working:
A.) You make the ROM an asset and it gets stuck on the Zune when you deploy the game. However, this means that you have to redeploy anytime you would want to add or remove games from it. Basically, you would have to embed the ROM's in the emulator. And when/if Microsoft sets us up to compile the games then just hand a single file over to a non-developer to stick on their Zune, if you wanted to let users choose which games they wanted on their Zune, they would have to compile their emulator with every possible combination of games and this would obviously not be fun.
B.) You might could actually just change the ROM's into MP3's/JPEG's/WMV's so you could store them independently. You would have to write a small program to add a header to the beginning of the ROM and do any other preparations to fool the Zune software into thinking that it actually is a song/picture/video, and have your emulator strip this from the beginning of the file and shove the ROM into the memory for later. This however would require that you actually have access to the raw data from a song/picture/video and I'm not sure that XNA supports that.
Someone brought up that you would have to draw each pixel as a texture and SimReality corrected them mentioning that you could just edit the pixeldata of a single texture and draw it each frame. That would work, but I think there are better ways. If I understand it correctly, the NES draws two scrolling backgrounds then draws everything else as sprites. I would think that you could make textures out of the backgrounds using SourceRectangles to scroll through them and set the sprites up as custom-made classes with multiple frames made of Texture2D's that you cycle through and draw where you need to. Since you don't have to loop through the 61440 pixels every time you draw, I would think that this is possibly quicker and more efficient and would lead to a healthier fps.
A good place to start for anyone actually considering writing their own Zune-specific emulator would be writing an emulator for a simpler console, like the CHIP-8. Although the CHIP-8 does have a bunch more buttons than the Zune. But most of the games written for it don't make use of more than 4 or 5.
Again, sorry for the way too big post. =P Here are some links to help make research easier.
More NES technical documents than you will ever need:
http://nesdev.parodius.com/
A thread on ZuneScene(*gasp*) on the Zune processor:
http://www.zunescene.mobi/forums/ind...7597.msg453588