Support and General Use > Plugins/Viewers
NES plugin - a proposal
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 ;D!
Multimedia Mike:
--- Quote from: ComposerDude on August 05, 2007, 12:29:08 PM ---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?
--- End quote ---
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.
--- Quote from: ComposerDude on August 05, 2007, 12:29:08 PM ---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?
--- End quote ---
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. :D
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:
--- Quote from: LambdaCalculus379 on August 05, 2007, 11:53:01 AM ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version