blargg wrote:If people made games for purchase on it, it seems that it wouldn't be a NES, just a NES-like platform. The game would have to work properly on your emulator, since that's what people are paying to play it on, so any differences from NES would have to be accommodated by the games.
Using an existing well-tested emulator core in NDK would help, as long as the emulator is at least as accurate as a common famiclone. I imagine the idea is that some games will be made available on Ouya and on an NES cartridge, and someone who owns both an Ouya and an NES might play the free demo on the Ouya Store and decide to buy it on cartridge.
And you could't fix emulator bugs since it would break previous games (unless you are able to tie each game to a specific emulator version).
Hence the different IOS binaries in the Wii system software and the emulator binaries in Virtual Console.
Simple approaches would be to change the memory map, e.g. RAM in a different place, PPU/APU registers elsewhere.
Hence the palette rearrangement in the 2C04 and the swapping of addresses of PPUCTRL/PPUMASK in the 2C05. "RAM in a different place" wouldn't work because the 6502-derived core in all 2A0x family CPUs depends on having the direct page at $0000-$00FF and the stack at $0100-$01FF.
Of course this whole plan would need to be modified if the Ouya Store distribution agreement has a non-compete clause like that of the App Store and Google Play Store that prohibits applications from acting as app stores themselves. In such a case, you'd need to distribute your emulator as a tool to package a single ROM, much like Virtual Console for Wii and Macifom for iOS.