The purpose of this thread is to discuss that particular outlook; narrowing down the options to a new console that can chew old nes games.
To get things started, this is a rudimentary treatise i came up at downtime during work. The working name is "N+" throughout the document:
1) Chief goals (as i imagine them):
1.1) Establish a standard for the production and emulation of a nesdev-designed console that is close to 100% backwards compatibility with the current software library for the NES. If there's a few obscure wierdo games that won't make it, though, it's not much of a problem.
1.2) Emulation should be relatively easy/effortless; mainly or wholly building on device blocks already present in NES emulation.
1.3) FPGA Programming should at least to some extent be repeatable, that is, reusing blocks, to lessen the burden.
1.4) The standard should be open to anyone who wants to pursue coming up with a working physical unit.
1.5) The experience should be recognizable as something NES-like. Think (loosely about) Shovel Knight.
2) Audio:
2.1) For maximum compability with games; old, new, future, famicom and nes, the ext. audio line will be bridged. HOWEVER,
2.2) if no cartridge makes the connection complete, it will be pulled to an internal extra APU; let's call it APU2.
2.3) The design of APU2 should, for the ease of emulation and (possibly) FPGA programming, either be (A) a full clone of the original APU (APU1), or (B) a well-known, documented and impremented audio device such as the Famicom Disk System Wavetable synth.
2.4) "N+" games may use this extra built-in audio, or its own device, like any ”expansion sound” game does today, ensuring maximum forward-compability aswell. Looking at recent development, expansion audio will become more common in NES homebrewing.
2.5) The fact that there's an internal ”expansion audio” device means that future homebrew using the extended capabilities of ”N+” don't have to have an expensive synth device onboard to have impressive sound features. It will keep production costs down for anyone not wanting a specific synth.
3) Picture Processing
3.1) The design assumes cloned instances of the original PPU, again for the ease of emulation and FPGA programming, rather than designing a whole new PPU/GPU.
3.2a) There's two roads here: In a physical NES you could theoretically daisy-chain one PPU to another. The picture of the one ”plugged in” would be rendered as background using the subpalettes of the other PPU:s background layer. This would yield more layers, but not more simultaneous subpalettes, and it would consequently also greatly lessen the versatility of the daisychained PPU:s sprites.
3.2b) The other road would be layering different PPU instances externally via another block. We would gain full control of each PPU:s full colour capability (including individual emphasis bit settings, allowing a more nuanced and wider total master palette), and possibly even control over blending modes, ordering, and opacity.
3.3) Depending on cost and FPGA limits, the number of PPU instancesin the design might vary. My suggestion is two or three. Just two will yield some great rewards, but you cannot facilitate all of them at the same time without sacrifices. Three covers about all bases i can think of*. More layers will likely result in diminishing returns per PPU.
4) CPU:
4.1) Could be FPGA emulated, but is there a market-available microprocessor that's 100% backwards compatible with the 6502? That would save logic on the FPGA and save time developing it, at the cost of one extra unit.
4.2) Unless it somehow breaks compatibility, let's have decimal mode.
4.3) Programmable frequency (adjust to regions and possibly new modes)
5) Memory:
5.1) For CIRAM, No reason not to go for 8kB, right?
5.2) Internal ExRAM: A register could be set to enable internal ExRAM for the PPU:s. This way, individual carts won't need to have this capability in themselves.
6)Peripheral support and ports:
6.1) 2 controller ports are minimum, 4 are preferrable.
6.2) How to make the console "controller with more buttons" ready?
6.3) How to support light gun games in this era?
6.4) Console to console connection for local multiplayer gaming?
7) Software Standards:
7.1) Software should be categorized for users, perhaps as follows:
a)NES software (works on both, but no additional features on ”N+”)
b)NES/N+ software (works on both, but with additional features on ”N+”)
c)N+ (is using features of the ”N+” so extensively/intricately it's no longer compatible with the NES)
7.2) The golden mark for nesdev homebrewers would probably be ”NES/N+” as that's how you get most to use your software while being able to add extras if you want to, but you're free to do N+ only.
Notes:
*Some practical PPU configurations, using 2 vs 3 instances:
Imagine a layer system where the top is shown front-most.
PPU1 BG
PPU1 Sprites
-----------------------
PPU2 Sprites
PPU2 BG
= Double the scanline tolerance and max sprite count. Concealing foreground, walk-in-front-of background Simple.
PPU1 Sprites
PPU2 BG
------------------
PPU 1 Sprites
PPU 2 BG
or
PPU1 Sprites
PPU1 BG
------------------
PPU2 BG
PPU2 Sprites
= Normal gameplay on PPU1, Added background sceneries and sprite effects in the rear of things.
Those are the basic options. Either double sprite count/scanline tolerance on what is percieved as the same plane, OR amazing sceneries. You might be able to hack around this limitation, with some pain and limits. With 3 PPU:s, however:
PPU1 BG
PPU1 Sprites
-----------------
PPU2 Sprites
PPU2 BG
-----------------
PPU3 BG
PPU3 Sprites
(For example)
= Double sprite count/scanline tolerance on what is percieved as the same plane, AND amazing sceneries without hassle.