DSi NWRAM Support

[DesperateProgrammer]

I added the support of the new shared WRAM in the DSi.

The support is quarded by the define DSI_NEWWRAM. For the VS Project this define is set, for all other builds this is not set and thus disabled. Please add this define to the build-scripts, when the commit is approved and shall be included in the project.

The code takes care of the NWRAM priority as the hardware:
NWRAM Set A < NWRAM Set B < NWRAM Set C < OldWRAM
This is different than no$gba but consistent with hardware. No$gba places internal arm7 wram infront of the NWRAM.

The following edge-cases are NOT consistent with hardware:

• non-mapped parts of a NWRAM set are fall-through in and outside the NWRAM configured window. On Hardware it is a all-zero non writeable memory inside of the window and only fall-through outside.
• the implementation does not allow to map NWRAM in the memory region at 0x04.... so it does not interfere with the HW Registers

Test .NDS:
nwramTest.zip

Results:

Compare no$gba:

[zeromus]

Not sure how I feel about adding pieces of DSI emulation that will just sit incomplete and bitrot. Isn't this like 1/1000th of the work it takes to get DSI stuff booting?

[DesperateProgrammer]

I am a bit baffled and confused by this response.

But let's first try fact based argument:

• The DSi does not require all features to be used to allow DSi enhanced programs. It is more a per-component based approach, where each component can be enabled/required while the others are still in NDS mode. The supplied example shows that. It is a DSi enhanced .NDS that works on NDS & DSi Hardware and uses the component if provided.
• Desmume alreay started implementing parts of the DSi hardware. And tbh in a very hacky and dirty way: See arm9 access to SCFG_A9ROM.
• The component is complete in itself. It works even in most edge effects and in all cases that are in the wild.

Then there are the social elements of these words you have chosen:
Please note, that I am in no way a newcomer to desmume development. My code is in this project since yopyop OSed it due to the changed law in france. I may have been absent for a long time, but this is not how we participated and worked together back in the time. If we'd discouraged incomplete emulation or even incomplete features (which this is not) we wouldn't have this discussion. I was mainly involved in the 2d engine and it was a very iteratively improving process, or none at all.

I was always a fan of cooperating and returning, which I do with this PR and those intended to follow, but I am in no way required to do so.

So please, teke it or leave it, but this above is an offending, lazy formulated comment.

[zeromus]

When desmume was being iteratively improved, things were different. It was a sleek schooner with a crack crew. Now it's a barnacled shipwreck. Each improvement is a new layer of crust that weights it further into the seafloor.
I gave you write access so you can push commits yourself besides just merging your own PRs. There is nobody available to take responsibility for your commits but yourself.

[RokkumanX]

It's a barnacled shipwreck that I and many others came to love over the years!

Good and decent Nintendo DS emulators doesn't grow on trees and thankfully DeSmuME plays all the games I have pretty much perfectly which I'm really grateful for because there is not much else worth using at the moment.

Also, I don't see the need to down talk on the project all the time, like it's a pain in the ass.
The project is not doomed or going down sinking into the ocean, it still have potential being a great Nintendo DS emulator.

If you, the author behind the project is incapable of loving or taking care of the project, how are you expecting future DeSmuME users to love it and having a great time time with it.