Designing a NES compatible console - nesdev designs, part 2.

You can talk about almost anything that you want to on this board.

Moderator: Moderators

User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Designing a NES compatible console - nesdev designs, part 2.

Post by FrankenGraphics »

We've had the NesDev designs a console thread, where many cool ideas were presented, and we've had the latest thread on the homebrew scene, which is largely, as the article discusses, about why NES is the predominant homebrew platform for games. I've grown determined that if we would design a console, it would have to be backwards compatible with the NES, for reasons mentioned in those threads.

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by tepples »

FrankenGraphics wrote: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.
Would Castlevania III: Dracula's Curse, Laser Invasion, and six Koei war sims (source: non-Japan MMC5 games in NesCartDB) be "a few obscure wierdo games"? Or were you asking for something like "Super Cars, Virgin's Aladdin, and STREEMERZ break, and Puzznic would need additional testing" (source: "Games using unofficial opcodes" on the wiki)?
FrankenGraphics wrote:1.5) The experience should be recognizable as something NES-like. Think (loosely about) Shovel Knight.
If Shovel Knight is a target, then 7.16 MHz (3 master clocks per pixel) with a 336x224 pixel active area needs to be an option, so that games can be optimized for anamorphic widescreen play while retaining a pan-and-scan mode for 4:3 sets. This means the high bit of X coordinates will need to go somewhere.
FrankenGraphics wrote: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.
"Impremented"? Found the Japanese :p

If we're going FDS, why not just go Namco 163? It's the same thing, just with more channels and without a hardware pitch envelope. Load the appropriate waveforms, and it can replicate the capability of the FT community's favored VRC6.
FrankenGraphics wrote:3.2a) There's two roads here: In a physical NES you could theoretically daisy-chain one PPU to another.
[...]
3.2b) The other road would be layering different PPU instances externally via another block.
In either case, you'd need to hook up some sort of video memory to this second PPU.
FrankenGraphics wrote:is there a market-available microprocessor that's 100% backwards compatible with the 6502?
Western Design Center still sells the 65C02 and 65816, as well as versions of both with a few integrated MMIO peripherals. These wouldn't run games using most unofficial instructions, though games using $89 (NOP #ii on 6502, BIT #ii on 65C02 and 65816) might squeak by. There may be problems with a few page crossing penalty edge cases.
FrankenGraphics wrote:5.1) For CIRAM, No reason not to go for 8kB, right?
That depends on how many PPUs. One PPU can address 4 KiB at once, but you might want two 4 KiB banks for the playfield and status bar. And you might want CHR RAM for the second PPU, or both if you want to attempt support for single-chip games.
FrankenGraphics wrote: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?
NES and Super NES controller ports have the same protocol, and there are pin adapters for both. The biggest problem would be in sourcing receptacles for these.
FrankenGraphics wrote:6.3) How to support light gun games in this era?
We can answer that for sure in 2026 when the Wii Remote patents expire.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by FrankenGraphics »

tepples wrote: Would Castlevania III: Dracula's Curse, Laser Invasion, and six Koei war sims (source: non-Japan MMC5 games in NesCartDB) be "a few obscure wierdo games"? Or were you asking for something like "Super Cars, Virgin's Aladdin, and STREEMERZ break, and Puzznic would need additional testing" (source: "Games using unofficial opcodes" on the wiki)?
I was thinking about the latter. I don't think it's a too large sacrifice if some games would break because of illegal opcodes not being handled correctly anymore.
If Shovel Knight is a target, then 7.16 MHz (3 master clocks per pixel) with a 336x224 pixel active area needs to be an option, so that games can be optimized for anamorphic widescreen play while retaining a pan-and-scan mode for 4:3 sets. This means the high bit of X coordinates will need to go somewhere.
I didn't think of SK as a literal target set of features, but it almost sounds like an option.
If we're going FDS, why not just go Namco 163? It's the same thing, just with more channels and without a hardware pitch envelope. Load the appropriate waveforms, and it can replicate the capability of the FT community's favored VRC6.
If that's more flexible, that sounds better (in a double sense). Just about anything hardware accelerated is a welcome bonus, but if we're going with a stronger CPU at a programmable frequency, it matters even less.
Edit: Actually, say we locked in on Namco 163 as the internal expansion, we could practically begin to make "n+" soundtracks this very day (as opposed to a cloned 2A03/07) with existing software (even though FamiTracker doesn't have a full implementation at this point). That's a plus. A slight minus would be implementing a low pass filter to cancel the multichannel noise. While it's a super simple electric device, it'll be varyingly supported in emulators. Not a big problem, but it's there.
Western Design Center still sells the 65C02 and 65816, as well as versions of both with a few integrated MMIO peripherals. These wouldn't run games using most unofficial instructions, though games using $89 (NOP #ii on 6502, BIT #ii on 65C02 and 65816) might squeak by. There may be problems with a few page crossing penalty edge cases.
Nice! So, it needs to be tested to verify the exact compability rate, but sounds acceptable from that standpoint, i think. The improved address range means we could map "n+" extras more liberally, like as much internal RAM we would need.
NES and Super NES controller ports have the same protocol, and there are pin adapters for both. The biggest problem would be in sourcing receptacles for these.
The alternative would be switching to a standard with available parts, which would require modifications/adapters to existing nes/snes controllers, but make it easier to manufacture new controllers fit for the task. I don't know if the gain equates the mess, though.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Designing a NES compatible console - nesdev designs, par

Post by psycopathicteen »

If we're using an RGB palette, which NES palette should we use?
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by FrankenGraphics »

I think Video Output is a whole category in itself.

8.1) Should we assume one video out standard or several? Which one/s? Having multiple options would add to the unit production price. Things to consider/balance: The aim to make the experience nes-like vs modern conditions. A compromise could be one output, and expansion pins for those wanting to tinker an expansion. There's also the option to omit the row of expansion pins and leave their solder holes unpopulated to cut costs even further (hardware like that tends to build up on the price per unit), assuming the average builder or buyer will be satisfied with just the one option.

8.2) A maxim could be one unit, all regions. Then we would need the selection of master palette to be programmable to some extent.
Many emulators already kind of cover this feature via preferences, which would at least be enough when developing test suites, demos, games and other software. Unless animated changes to the master palette becomes a feature. :shock:

And Regions could also be a distinct category:

9.1) Three options for setting default region: A) Jumpers on the PCB (no switch saves money), or B) programmable via a "system cartridge/ROM", or C) an onboard BIOS of sorts. Proposed interface: Power on without cartridge. Possibly hold down start on controller, else console behaves like a NES with no CIC. I'm leaning towards (B) because it's the simplest solution requiring the least additions. Providers could program the unit prior to shipping according to wishes, and users could run the system software off any cart providing the necessary means, such as a downloadable free ROM running on powerpak/everdrive and the like, or via included settings in an "n+" game.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by FrankenGraphics »

The more i look at N163, the more certain i become it's the right choice for an internal "ext audio".

Wavetable synthesis is easily the most flexible form of synthesis on the table without using a sampler. With it, we can at least to some extent mimic subractive, additive and FM synthesis. It would cover most needs that VRC6 (like tepples said), VRC7 (partly), MMC5 and sunsoft 5b pulses, FDS sound would. It also goes beyond the sound capabilities of those devices in some areas.

What's omitted would be full-blown FM capabilities and the extra DCM of the MMC5.

Note that the wavetable of the N163 has a granularity up to 256 samples per cycle. Currently, the FamiTracker engine (and probably any emulator not updated post-discovery) only offers a wave size of 32, which currently limits its capabilities to simulate other forms of synthesis by some. So there's additional untapped potential.

Any other thoughts?
User avatar
GradualGames
Posts: 1106
Joined: Sun Nov 09, 2008 9:18 pm
Location: Pennsylvania, USA
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by GradualGames »

Wonder if somebody could just ask bunnyboy to add extended features to the AVS? (after raising funds perhaps) After all it took him years of research and perfection to get it to work with the NES library. Adding NEW features that would only work with new homebrews games, I imagine, would be perhaps easier (though in the realm of electronics design, I know nothing)
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by FrankenGraphics »

Maybe one thing won't exclude the other - i mean, once the specifications have been chiseled out sufficiently, nothing's to stop anyone (be it the community, a person or a business) from doing a crowdfunding campaign to make the thing real. In that respect, bunnyboy would be halfway (so to speak) there thanks to prior work, should he be interested.

I also suppose that at some point, the standard/specification will need to be informed by actual tests and experiments which will require labour put into practical hardware-, software-, and assets design. The hardware bit will introduce costs above the time spent, which could be reason for a fundraiser.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by FrankenGraphics »

How's this for a first-draft roadmap? Envisioned as a community project with lots of room for individual projects for anyone interested enough, over a couple of/maybe several years:

-Establish what blocks to reuse, and what (if any) that must be new.
-Some time later, have at least an emulator or fork of emulator run a conceptual emulation, with a few rudimentary demos.
-Maybe involve the compo to some extent at this point.For example, "n+" features could be rewarded by a "best n+ prototype" award judged separately. Games that are both legit NES roms and have "n+" features don't get points for the latter in the ordinary competition. It's just a special award.
-Findings, notes and experiences from experimenting with practical "n+" software (and hardware) implementations will inform the final design of the new console. Having experimented means you have more to say about how the details should work, which is kind of rewarding in itself.
-Rince and repeat until we reach a point where it's time to get into the actual EE part of the project.
-Hardware buffs can more or less take it from there if they're interested.
-A compo where entries whose "n+" features are actually legit for cart inclusion is held somewhere beyond this point. This to incite development and give the console a good starting field upon release.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Designing a NES compatible console - nesdev designs, par

Post by tokumaru »

One thing that's much needed (sorry if it's already been brought up, I'm out and couldn't read everything) is DMA to VRAM, specially if the dual/triple PPU design is used. With the current architecture, we barely have enough time to pull off fast movement/animations, if we have twice or 3 times the amount of updates to make, the good old unrolled PLA/STA loop just won't cut it.

Another concern is the attribute tables, that even DMA can't help if you need to update columns, due to the lack of an "increment by 8" mode in the PPU. For this reason, a new attribute table layout a la MMC5's ExGraphics would not only improve the visuals but also simplify and speed up scrolling (as long as there's a DMA feature).
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by TmEE »

The CPU will definitely have to be at least twice the speed to get anywhere, there's lot more housework to do with all the extra hardware and you are gonna have less CPU time left for the game.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Designing a NES compatible console - nesdev designs, par

Post by tokumaru »

DMA, increased CPU speed, extra VRAM... This sounds kinda like how the GBC improved the original GB. Can we draw some inspiration from how Nintendo upgraded that system while maintaining compatibility with older games?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by tepples »

You're trying to launch a new famiclone console, and what you've described so far is an NES with two PPUs, a Namco WSG-inspired wavetable synth, and Super NES controller ports. Thus it is to the NES as the SuperGrafx is to the PC Engine.

Anyone considering an N+ game would have to answer a question: "Why not just make a Super NES game? It'll work on all the Super NES and FC Twin consoles out there, which is far greater than the N+ install base." The traditional answer to that is that people expect a Super NES game to look no less graphically complex than the Super NES launch titles, such as Super Mario World, whereas an NES game's art style can be anywhere between Donkey Kong and Bucky O'Hare.

So N+ games would have to fit into a narrow gap: projects that are too complex for the NES, less complex than SMW, and appealing to those few people who have purchased an N+ console. Like Metanet's N+, I assume.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by Dwedit »

You still won't beat an Allwinner system-on-a-chip running a NES emulator.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Designing a NES compatible console - nesdev designs, par

Post by FrankenGraphics »

There's a bit more appeal to that than filling the gap between nes and snes. First off, the message is the medium - meaning in this case, the format of the medium will be embedded in every expression done with it. It will be a decidedly NES-like expression. SNES looks, sounds, plays different. And is expected to, as you mention. Secondly, the scope of a project is also very NES-like. That's the real meat on the hook. You can make a game just like you would a NES game, but more conveniently so because you can use the extra resources if that's a quicker way to completion. Or, you could complement your code with richer assets. Or, you could just make a NES ROM that plays normalt on the NES but adds footsteps to the walking cycle without cutting music on the "n+" (just an example). It would, simply put, make homebrew more convenient for those who want to keep the scope similar, give more ways to reach your goal, which should especially be attractive for beginner-brewers (just consider what extra cycles would do on the actual nes), or, you could team up and make full use of everything - if that's your thing.

The install base will be small; especially on physical units. But so would any community developed 'retro' console. I think a nes compatible one would be more rational.

Oh, and "n+" is of course just a placeholder name for the standard.
Post Reply