NES plugin - a proposal

[LambdaCalculus]

Llorean, you get first dibs at playing the NES plugin!   Thanks!

[ComposerDude]

Indeed, Llorean.

From the movie Happy Feet:

Ramón(Llorean): I right now take a moment for myself. Bow down, bow down.
[All Amigos bow to him]
Raul(Us): You the man, you the man.

ttfn,
ComposerDude

[ComposerDude]

FCEU might be a dammed encyclopedia, but it's commented relatively well. I think that if we spend our time reading our code books and reading the source of both TuxNES and FCEU, we will find exactly what we're looking for.

More specifically, we'll want to get rid of anything that is:
1. Not easily portable (I'll contact FCEU devs again)
2. Excess Features (Cheats, extra palettes, etc.)
3. Non-rockbox compatible (assembler, you know...)

Another thing to look into: can we use dynamic-recompile, or must we use interpretive? D-C is alot faster than interpret. How similar are most of rockboxes target cpu's? This would ease porting a D-C method if they were mostly alike.

'God bless us, every one!' - Tiny Tim, Dickens' A Christmas Carol
ComposerDude

[Multimedia Mike]

A huge caveat with dynamic recompilation: It falls over when it hits self-modifying code. Even The Legend of Zelda used this. That's why TuxNES had to include at least a minimal interpretive engine in addition to the dynrec core.

You might suspect it would be tricky to run self-modifying code when the program lives in ROM. But some programmers were apparently so keen on the technique that they would copy data down to the work RAM and branch execution there.

[ComposerDude]

Okay, this may or may not sound uneducated. But why couldn't an emulator simply be written to represent the original hardware to the rom, and pipeline output for whatever the rom calls, while doing the same for input, etc. etc. and so forth.

My understanding is that, yes, hardware would still be emulated like anything else, so to speak, but that instead of handling everything itself, it would pas things along to the host system.

Somebody correct me if I'm wrong. Why hasn't this been done?

Peace out,
ComposerDude

[Multimedia Mike]

I think you're more educated that you recognize, since you described the essential operation of an emulator. However, the ROM call thing is a bit advanced for this discussion; the NES doesn't have ROM calls.

Represent the original hardware-- example: The NES game program is going to write 2 consecutive values to a particular register mapped to a memory location (0x4016) to indicate that it wants to read the state of the controller #1 buttons. Then, the program will read that location 8 times to get 8 button states. So the emulator needs to notice the register write and be prepared to tell the program, via the next 8 reads from location 0x4016, what the controller button states are, abstracted to the iPod controls in this case.

Or perhaps I don't understand your question? Are you envisioning that the NES has a set of ROM BIOS calls like a PC? E.g., the BIOS call to switch video modes in MS-DOS. I ask for clarification because that's not how the NES works.

[ComposerDude]

Oops. I was envisioning something like BIOS calls. I think I may have gotten a few things mixed up after reading about the Famicon Disk System and its operation with the NES/Famicon. Thanks for clearing up my confusion before going down a rabbit trail.

[Multimedia Mike]

Yes, I see that the relevant TWiki page now mentions FDS stuff and how emulating it requires a BIOS image. The NES and SNES are somewhat unique among consoles for not using a BIOS. When you power on the system, the CPU loads the reset vector from the end of the cartridge ROM and it's off and running.

Are you really thinking about emulating the FDS? I would consider that to be somewhat outside the scope of this project. Your speculation about simulating the net effect of BIOS calls vs. using the official BIOS has some foundation in theory. However, things probably don't work out so sanely in practice. It would not be surprising to learn that particular BIOS calls leave registers in certain states that, while not documented, are still needed for one game or another to operate correctly. There's an interesting quirk about reading NES controllers along those same lines (hardware idiosyncrasies that programmers decided to count on).

[ComposerDude]

I have spent a few hours looking into the possibility of emulating the FDS since LambdaCalculus379 mentioned it much earlier in the thread. Honestly, the only thing of interest to me for the FDS would be the Japanese release of Super Mario 2. Since it requires the use of the original system BIOS, we cannot include that with the emulator; and the rarity of the bios-rom would almost ensure that we would have to implement it somehow in order to avoid 'bug reports' of the plugin not working.

Considering the overall rarity of the FDS itself outside of Japan, it is probably not expedient to support it. I DID notice that FCEU does. TuxNES does not appear to have even anticipated support for FDS. Am I correct in that assumption?

Either way, ANY less coding is more time spent towards writing a mature emu plugin.
ComposerDude

[Multimedia Mike]

Considering the overall rarity of the FDS itself outside of Japan, it is probably not expedient to support it. I DID notice that FCEU does. TuxNES does not appear to have even anticipated support for FDS. Am I correct in that assumption?

I can guarantee that I personally have never cared about FDS emulation. I scarcely understand what the thing is. I don't remember it ever coming up on the TuxNES discussion list.

Another problem inherent in TuxNES was the fact that certain architectural limitations prevented it from supporting certain games. Most notably -- and I never quite got over this -- was Castlevania III: Dracula's Curse, one of my favorite NES titles.

[LambdaCalculus]

Actually, there aren't many emulators for other platforms that offer FDS support, and it is related to what ComposerDude had said: the rarity of a dumped FDS BIOS in the wild.

While it would be nice to have FDS support, it's also moot since most of the FDS games 1) have cartridge versions as well, and 2) are difficult to maintain, since the FDS images usually write data back to themselves in the same vein as the real disks do.

If we support it, then we'll have people running up and down all over the boards screaming about how we "ruined their ROMs", especially if they save state or disrupt the process of writing a save game. So in the end, we can lose FDS support.

[ComposerDude]

Multimedia Mike: When it comes to the architecture of TuxNES, are you talking about it's accuracy in NES hardware emulation, or the implementation of mapper support?

I was also reading about 6502 emu in FCEU. Apparently, xodnizel tried to implement some calls from the original NES processor into his code by way of guesswork. From my research, simply emulating the 6502 is enough for accurate amulation. Would you agree, or perhaps it is related to your comment about TuxNES architecture being limited?

LambdaCalculus379: There is now a place for rejected findings on the wiki !

[Multimedia Mike]

Multimedia Mike: When it comes to the architecture of TuxNES, are you talking about it's accuracy in NES hardware emulation, or the implementation of mapper support?

Whirlwind explanation: The 6502 has a 16-bit address space, i.e., 0x0000..0xFFFF. The program ROM in a cartridge is wired to the top half of that address space (0x8000..0xFFFF). Different mappers allow games to swap ROM banks that are addressed in those ranges. Many of the mappers achieve this by having registers mapped in that upper half of the memory range. TuxNES' architecture assumes that this is the case and only memory writes to the top half of the address space are checked to see if they could be mapper writes. Dracula's Curse's mapper (MMC5, iNES mapper #5) has its registers mapped down in the 0x5xxx range somewhere.

That's the problem. Dracula's Curse is the only known American NES game to use this mapper, so it's not a huge problem, even though it is a very cool game.

I was also reading about 6502 emu in FCEU. Apparently, xodnizel tried to implement some calls from the original NES processor into his code by way of guesswork. From my research, simply emulating the 6502 is enough for accurate amulation. Would you agree, or perhaps it is related to your comment about TuxNES architecture being limited?

I would like to know what he was trying to achieve by calling his code from the NES processor. But, yes, emulating the 6502 custom CPU in the NES, as well as emulating Nintendo's custom picture processing unit (PPU) is all that is needed for accurate emulation. Note that emulating the latter device is usually easier said than done.  

The sound hardware, as I recall, is a component of the custom 6502 CPU. You can safely ignore audio support in the first revision.

For fun: Here is a gallery of ROM images that I once scanned: http://multimedia.cx/nesgallery/
The pictures illustrate that most NES ROMs consist of a PRG ROM (code that maps to the CPU address space) and a CHR ROM (characters/graphics that map to the PPU address space). Some carts (notice the AOROM used in Rare, Ltd. games) have RAM instead of ROM wired to the PPU address space. In that case, the main game program sends data over to the RAM.

[Multimedia Mike]

If we support it, then we'll have people running up and down all over the boards screaming about how we "ruined their ROMs", especially if they save state or disrupt the process of writing a save game. So in the end, we can lose FDS support.

Still, is the emulator slated to support saved games and saved states? For save games -- i.e., battery-backed games -- the .nes format specifies in the header that a game has a battery-backed RAM area. This is always wired in the 0x6xxx address range. Hence, the emulator just needs to allow a game to read and write into that area and then save/load it on shutdown/startup. Saved states are a little more complicated since you essentially need to capture the entire machine state and dump it to a file.

[ComposerDude]

At this point, I expect to support save game, but save state is probably one of the unnecessaries of getting a working emu up and running. We need the basics to start out with, as you've advised: input to the game, and output to the screen and audio.

Once we have that covered, the next thing to work on would be the ability to to do speed configuration. Some targets won't run at full speed with Rockboy, and one thing that's helped it so far has been this feature. Anything else (save states, cheats, extra pallettes, and the like) will be slated for the once-upon-a-time-in-a-galaxy-far,-far-away treatment.

Another observation: porting the code from FCEU for the 6502 could solve the mapper problem you talked about in TuxNES.

As always,
ComposerDude...
I think.