Support and General Use > Plugins/Viewers
NES plugin - a proposal
Multimedia Mike:
Hi!
Multimedia Mike here. I used to be the maintainer of the TuxNES project that has been discussed here. I haven't actively worked on it since 2001, having moved onto open source multimedia hacking (including a little project you may have heard of called FFmpeg). However, I am still interested in NES emulation on every system that ever will exist.
Plus, I just got my first iPod (video/5.5gen/80GB) 2 weeks ago.
I'm flattered for my little old project that you all are interested in porting TuxNES. However, I should warn you that it is designed to run on x86 machines by dynamically translating NES 6502 CPU instructions -> x86 instructions. Porting to another arch is non-trivial for this reason. There was some experimental work on getting a more general-purpose C core into the program (primary impetus was to make it work on a Sega Dreamcast). I think some of that work may have made it into the SF CVS tree, but I'm not sure of its state.
FCE Ultra is what I use these days if I'm not using my actual top-loading model NES. As you have observed, it's quite large. But hey, any codebase is. I'm not sure how it's being maintained these days. AFAIK, the original author abandoned it and development has splintered into a few factions.
Another option that flies under the radar, but you are encouraged to investigate (because it was written by a NES hacker who really knows his stuff): nofrendo ( http://www.baisoku.org/ ). All C. All GPL. Disregard the adjective on his page about the emulator's quality; he's quite the perfectionist. He also has shatbox on his site, but that has a ton of x86 assember.
ComposerDude:
Thanks, Mike. I'll have a look at nofrendo over the weekend (kind of like what I did last weekend with TuxNES :D) and see what it holds.
Llorean: As for that suggestion, that could be something we could do. I'm guessing that it may take more of going back to my book of C. :) As for rad skills, most of what I did was back in 2000 with my dad teaching me perl and then C... considering that it was my dad doing the teaching, it's taking time to unrust. But I'll get there.
Llorean:
Well, my suggestion is more "take the route that turns out easiest for you, but don't overlook mixing and matching code when doing so." Of course people can follow up and improve the code later. :)
Multimedia Mike:
So you want to port a NES emulator? Here are some things to think about:
What do you envision for the control scheme? How will the user input up, down, left, right, select, start, B, and of course, A?
Your first goal should be to get a simple game up and running with just graphics; leave sound for later. When I say 'simple', I mean "Super Mario Bros." Technically, it's the simplest type of NES game because it has no special mapper hardware.
NES Emulation 101: Load the .nes file into the appropriate (emulated) memory areas (main memory and video memory). Initialize the CPU state. Load the 6502 CPU reset vector into the program counter. Emulate the CPU for a number of machine cycles equivalent to the time it takes to draw a scanline. Draw one scanline based on the state of the PPU registers and memory. When you have drawn 240 scanlines, draw the completed image on the screen. Repeat the process 60 times per second. There are more details, but this is the basic idea.
When all of that is working, hook up more memory mappers modules to support more complex games. Start with mapper #1. Then #3. Then #2 (Mike Tyson's Punch-Out!!). Then, as many more as you can.
Then get the sound working.
I hope this provides a basic roadmap.
Llorean:
For a reference, we do have a Gameboy emulator up and running on most of our hardware, so in terms of controls they can simply be treated as equivalent.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version