Rockbox Technical Forums
Support and General Use => Plugins/Viewers => Topic started by: ComposerDude on July 29, 2007, 01:53:22 PM
-
This is a thread for the express purpose of discussing a port of an NES emulator to Rockbox. If anyone has any ideas, suggestions, or general comments that have to do with positive reinforcement of such a project you are welcome to do so.
Currently I am looking at porting TuxNES (http://tuxnes.sourceforge.net/). This emulator was written expressly in C, and so it should make it easier to port. The TuxNES project is an older project, but it was a relatively stable emulator. Last release was in 2001, making it quite dated compared to active projects.
I have only just started the process of examining the code as of July 29. If there are any programmers interested, I would appreciate your posts and assistance, as I am only an amateur programmer.
Thanks, ComposerDude
EDIT: If anyone could provide information on FCE Ultra, i would appreciate it. I chose TuxNES for it's native code on Linux. Both are written in C.
EDIT: As of August 3, 2007 developement status will be posted to the Wiki. Please check for progress under Status (http://www.rockbox.org/twiki/bin/view/Main/PluginTuxNES#Status).
-
Try porting this one. http://www.dridus.com/~nyef/darcnes/
iPod Linux succesfully ported this to the iPod at 95~100% and also supports Gamegear and Genesis. Good Luck! ;D
-
darcnes isn't released under a GPL-compatible license (the readme states a "no commercial use" clause), so it wouldn't be possible to incorporate this into Rockbox.
EDIT: In fact, the readme for darcnes (and the source files) don't state any kind of license at all - apart from "People wishing to maintain a port for another system should contact me beforehand in order to learn the ground rules (and to make sure that no one else is already maintaining a port for that system)."
-
Thanks linuxstb. You saved me some valuable hours of research looking into its license. I am only interested in GPL'ed code... again, tuxnes seems to be the most portable of my two choices, the other choice being FCE Ultra. I was reading the rockboy source, and it has only one processor thread...
The hard part of these first two days is taking my limited knowledge and trying to apply it to tuxNES. The code seems a bit of a mess, and i'm pulling out my C programming books tomorrow eve after work. Maybe that will help.
ANY interested programmers would be welcome to help me on this venture. Has anyone tried this before?
-
Then how did iPodLinux port it. ???
-
Why not ask them ?
-
It would be better to port iDarcNES thus it runs at 100% on iPod Linux. I'll post the source if you change your mind. ;D
iPod Linux Page-http://ipodlinux.org/Idarcnes
iPod Linux iDarcNES-http://www.ipodlinux.org/forums/viewtopic.php?t=18245
Source Code-http://scs.ryerson.ca/~sriddle/darcnes.src.tar.gz
Thanks
-
We CANNOT, as it is NOT GPL LICENSED. Please, understand that this is a very strict line that will not be crossed as the terms of the software license don't allow it.
-
brarei200: As far as I have seen, DarcNES is not GPL compatible. The GPL requires that any derivative works remain under the GPL. Since DarcNES would be relying on GPL'ed code to run, Rockbox (a GPL licensed work) would not be able to package it officially, and I would have my doubts as to wether or not it would be an acceptable practice for it to rely on GPL (Closed-source can use LGPL stuff, but not GPL). Hence, unless the author of DarcNES were to release it under the GPL, It will NEVER BE PORTED to Rockbox.
I'll stick with TuxNES til that happens.
Peace out, ComposerDude
-
brare1200: FCE Ultra, on the other hand, IS GPL licensed.
A lot of people have to understand that not just any old emulator can be ported over. GPL software is rather strict about that.
Here's Wikipedia's entry on FCE Ultra, along with a link to the main page:
http://en.wikipedia.org/wiki/FCE_Ultra
Here's FCE Ultra's page:
http://fceultra.sourceforge.net/
-
Alright just have good luck porting TuxNES. ;D
-
brarei200: As far as I have seen, DarcNES is not GPL compatible. The GPL requires that any derivative works remain under the GPL. Since DarcNES would be relying on GPL'ed code to run, Rockbox (a GPL licensed work) would not be able to package it officially, and I would have my doubts as to wether or not it would be an acceptable practice for it to rely on GPL (Closed-source can use LGPL stuff, but not GPL). Hence, unless the author of DarcNES were to release it under the GPL, It will NEVER BE PORTED to Rockbox.
I'll stick with TuxNES til that happens.
Peace out, ComposerDude
That's also the reason that iDarcNES is not part of the SVN distribution of IPL. If I understand correctly, it was ported by users and is distributed as a separate binary. I believe that this is how IPL gets around the GPL issue.
-
Nestopia is GPL'd and is currently the best NES emulator available (and is still in development):
http://en.wikipedia.org/wiki/Nestopia
Perhaps that should be ported instead.
-
What language is it coded in? If it's C, then that should make it easier to port over.
-
But it's written in C++ - which makes porting it to Rockbox even more of a pain in the ass than porting TuxNES.
Also it was originally written for Windows, which means we'd be porting the port to Linux (since linux is closer to Rockbox than windows is API wise), which means there'd be more room for problems.
To be honest, I'd stick with TuxNES.
-
Also it was originally written for Windows, which means we'd be porting the port to Linux (since linux is closer to Rockbox than windows is API wise), which means there'd be more room for problems.
There's already a Linux port of Nestopia -
http://rbelmont.mameworld.info/?page_id=200
-
Like GodEater said before, it's written in C++, and is going to be a big pain in the ass to port over.
And while I agree that Nestopia is an excellent emulator, it's not a feasable project to port over.
FCE Ultra is GPL'd, is cross-platform, has some excellent mapper support, and (I believe) meets the prerequisite of being written in C. (I have to check again at home, however.)
-
Yes FCE Ultra is written in C. I've emailed the developers with some questions about it's portability and how native it is for windows (since it was originally written for DOS and Windows). For now i'll continue examining TuxNES, and hopefully over the next couple of weeks actually decide which emulator to use.
-
I was sitting here getting a head-ache from all the code when I had a moment of feature brilliancy... I know, get it working and then do features, but hey! I wondered about this for Rockboy, too.
Since Rockboy is a one-cpu-thread operation (I'm assuming here :)), couldn't it be default no-sound and continue to music playback? I thought it would be great, and it came to me while playing Jewels on my H320 and listening to Ben Folds. I know there are plenty of games that I wouldn't mind hearing my mp3s while I played 'em.
Anybody?
-
There are three resources large plugins like Rockboy need which conflict with music playback (the Gigabeat is an exception):
1) IRAM - this is the fast internal ram. 48KB of this is available to either plugins or codecs, but not both at the same time. (plugins and codecs on the Gigabeat don't use IRAM)
2) RAM - plugins normally only have 512KB of RAM. If they need more, then need to stop audio playback and grab the main audio buffer (around 29MB).
3) CPU - Rockboy is already too slow on all targets apart from the Gigabeat, and it would be even slower if music was being decoded at the same time.
So the short answer is no - you can't play Rockboy and listen to music at the same time.
-
Though this can partially be resolved on the iPods by making use of both cores, but this first means clearing up the remaining dual core issues for music playback. Otherwise there's a decent chance how you decided to divvy up threads between the cores in Rockboy would not align with choices made for normal playback.
-
Out of curiosity, do most plugins take advantage of the complete set of hardware available to them, or are they ported once and then simply maintained? I would imagine that if I were to port TuxNES to rockbox, that I would simply maintain and continue to bugfix at that point. However, in order for the port to actually avail themselves of available hardware, there would need to be different versions...
That sounds foolish, though, because that is exactly why there are different ports of Rockbox to their supported players. Then, the question really is:
Does Rockbox take advantage of every available bit of hardware on their respective ports yet?
-
Depends on the target. Most of the time, there's not much hardware to take advantage of beyond processor, sound hardware, input, screen, etc. I mean most MP3 players have the same requirements so are built with semi-similar ideals in mind.
The biggest things not taken advantage of are USB hardware on PortalPlayer targets, and the second core the PP targets offer, as well as the USB On the Go capabilities of some other players, I'd say.
-
Good Luck! Keep us informed on how it goes. (I hope this is as fast as iDarcNES)
-
Good Luck! Keep us informed on how it goes. (I hope this is as fast as iDarcNES)
With my little experience, this project will only go as fast as there are people to assist. But I am working on it daily... thanks, brarei200 :)
-
Yup... ;D
-
I hope you get somewhere, having another emulator in my Gigabeat will almost completely cure boredom. :D
-
Have you decided on using TuxNES then? I told my brother about this porting attempt. He's got most of his experience in C++, but he said he would check out the source and take a look to see if it's something he could help out with.
-
Chronon: Yes, I'm going ahead with TuxNES. FCE Ultra is really massive! My friends here at college advised against trying to port FCEU.
I've started reading the code and and re-reading my C book. So far, it's been hard, but last night I ran across http://fms.komkon.org/EMUL8/NES.html , and found it really helping in finding my way around the emulator code.
tata for now!
ComposerDude
-
Okay. I emailed him with some info. . . Hopefully more people take interest.
-
Took a look at the TuxNES source last night... you were right, ComposerDude. It's nice and lightweight, so porting it over should be easier. FCE Ultra practically looks like a damn encyclopedia in comparison.
The only thing we may have to improve upon in TuxNES would have to be its mapper support. I'm going to do a little more research in that area to see what I can come up with.
-
Thanks, LambdaCalculus379, I really appreciate it! ;D Seeing as how it hasn't been touched since 2001, mapper support hasn't really matured as it has in active projects. I've been spending more time familiarizing myself with NES architecture, since that is something I want to be strong in the plugin.
Believe it or not, I would like to see this project have strong emulation and find the best way possible to go about doing it. Rockboy has alot on the idea already, and I think that as we figure this out we may want to come as close as we can in many respects to Rockboy's code. that way, if there are improvements to how TuxNES handles on the firmware, we could possibly patch Rockboy too.
Especially with all the buzz that's been going around because of speed issues and whatnot.
Til then, hang ten,
ComposerDude
-
Anytime, dude! :)
I was thinking... want to at least get a wiki page up and running so we can document our findings?
-
Sorry, I'm tired, and at work (not a good combination! ;D), but what shall we label it? I'll make it after I get off work.
Yes, it would be a great idea.
ComposerDude
-
Hmmm... good question! I figure since there's Rockboy and RockDoom, we can just keep with the pattern and call the plugin RockNES or something similar.
I'm going to go and get some mapper info during the weekend if I have a little time. I was thinking of looking up information about the Famicom Disk System (http://en.wikipedia.org/wiki/Famicom_Disk_System) as well, but at the same time, I don't know if the FDS would be a feasable choice to add to the emulator due to a couple of technical reasons.
Just for the record, my coding skills are still building. I'm pretty good with scripting, but I'm still trying to take in C. So for now, I'm going to do my part by helping to gather any and all information I can.
(Funny how I can learn LISP faster than C... ;))
Let me know when you get the initial wiki page up, ComposerDude!
-
So is this going to be abel to run of 5g apple ipods
-
It's hard to say what the performance requirements are going to be when it's not running on anything yet.
-
We haven't even written one line of code and have absolutely no idea how the performance will be. I mean, for Eris's sake, we haven't even gotten the wiki page up yet!
Right now, ComposerDude and I are trying to focus on gathering information and documents... NOTHING ELSE YET. This is Step 1: "Gather Information". A plugin being worked on by a couple of guys who have minimal to moderate knowledge of C will be guaranteed to have a few roadblocks while we learn.
To repeat: PLEASE DO NOT ASK FOR PROGRESS INFO! We're just getting our notes together and we're waiting for the pot of coffee to finish brewing!
-
I'd recommend simply calling the plugin TuxNES rather than RockNES. As a way to give original credit (it's nice to do so.) You'll notice that technically the Doom plugin is simply called "Doom". All these "RockBlah" just makes the list more confusing as a large cluster of things are hidden among the Rs. It *might* even be better to call it NES, though I don't know.
-
I'd recommend simply calling the plugin TuxNES rather than RockNES. As a way to give original credit (it's nice to do so.)
As a Free Software advocate, I agree. We should keep the name as TuxNES.
Richard Stallman would be so proud of you, man. :)
-
So, yeah. There's already a RockNES out there, anyways.
Besides... Llorean is right... and RockNES is a windows thing...
Windows on Rockbox again. No way are we ever doing that! :P
PluginTuxNES... Gathering information for the future of amateur C programming!
I'm full of it.
ComposerDude, out.
-
D'oh! I forgot that there was another RockNES out there! And it's for Windows... YUCK!
Now I see what Llorean meant. And it's settled: TuxNES it is!
-
Honestly, I just meant that I'm tired of RockBlah and BlahBox named plugins. ;)
If there's ever a cleanup for putting them in folders, or even if there's ever simply a cleanup, I'm going to push to have them renamed (or simply rename them, and weather any flames that come my way).
-
Honestly, I just meant that I'm tired of RockBlah and BlahBox named plugins. ;)
Dude, you don't have to worry about it. It's understandable.
It was also when ComposerDude pointed out that there already is another emulator named RockNES out there, that I realized that calling this one RockNES will just cause mass confusion. At least using TuxNES is far less confusing.
Besides, it's named for a cute penguin; what couldn't be cooler? Â ;)
I think you're doing one hell of a job here on the forums, Llorean. Keep on Rocking!
-
I'm pretty sure I have at least a 51% approval rating still. I know there are a few people who think I'm a bit overzealous. It's really tempting to run a poll and find out, but that would be off topic.
As to the plugin, have you contacted the TuxNES authors? I know they haven't maintained it in a while, but they might be able to point you at areas of interest (performance bogs, etc) that might help you concentrate on important bits during porting.
-
ComposerDude said he was taking care of that. But I'm going to contact them anyway just to make sure.
What I'm going to do for the plugin is gather mapper support to see if we can build on the somewhat lacking mapper support in TuxNES.
-
Developer contact hasn't been established with TuxNES. Thankfully, it is a sourceforge project, so it should minimize any confusion involved in getting in touch with the original dev.
-
Another possibility is to look for an open source emulator for an embedded target (an NES emulator for PocketPC or Palm for example). Even if it's not from the same codebase, it's possible you could get some tips from the people who've worked on them in regards to what parts of NES emulation provided the greatest difficulty in limited environments.
-
Okay... So has anyone told Llorean that he has a view of himself that's way too low? His suggestion to get in touch with the Devs at TuxNES brought me to Mike Melanson, one of the devs at FFMpeg. TuxNES was his back in 2001.
He replied very quickly and helpfully (response time: 9 min.!) with this:
You may wish to check into the FCEUltra emulator or other open source
options as their CPU cores tend to be a bit more portable.
Good luck. And don't hesitate to consult me further on this project. I
still love NES hacking.
I'm replying to him right now. ;D
-
Conclusive proof that my sole job here isn't simply to discourage people. :)
Maybe you can adopt code from both projects, anything you can make portable out of TuxNES, then deal with the more complicated code only when it's actually the easier solution?
-
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.
-
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.
-
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. :)
-
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.
-
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.
-
My guess is that along the road somewhere (such as at the time that the emulator is down to barebones!) we can actually adapt some of rockboy's code to suit our needs.
-
The control code may be the best adaptation, for one. Since the NES and the Game Boy have the same control scheme, we can adjust it to fit the NES plugin, and use the same schemes that Rockboy uses now.
I won't be able to get to my PC for much more of the evening, but to ComposerDude, Llorean, and Multimedia Mike: keep me up to speed with what's going on. I'm going to do some research on the NES mapper sets and start reading my C books again.
-
LambdaCalculus379: TWiki page is up and ready for input. I'm going to gather what I've got so far and get it on the page tomorrow.
As for all of the help I've seen come together in less than a week...
Thanks,
ComposerDude
-
ComposerDude: Added my name to the wiki page. I'll put my findings up as I find them as well.
-
While I'm not getting directly involved (I never do ;)) I'll be watching and I'm around to help direct you to resources we've got here at Rockbox.
-
Llorean, you get first dibs at playing the NES plugin! ;D Thanks!
-
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
-
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
-
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.
-
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
-
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.
-
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.
-
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).
-
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
-
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.
-
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.
-
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: 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. :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.
-
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.
-
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.
-
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.
Actually, I think the NES port of Romance of the Three Kingdoms II also uses the MMC5, if I remember correctly. The MMC5 didn't gain too much widespread useage, as you said. But I think there's a tiny handful of later NES games that made use of it.
Actually, on that subject: wasn't there some emulator out there that printed the mapper information onscreen when you load a ROM? Or am I crazy?
-
Actually, on that subject: wasn't there some emulator out there that printed the mapper information onscreen when you load a ROM? Or am I crazy?
There are probably emulators that print the data on screen. Looking over the options for TuxNES, -H or --show-header show the header bytes for diagnostics, and it's easy to find the mappers in there. It occurred to me that someone has probably compiled a collection of games and the mapper they used. I google for "nes mapper list" and what appears, but a forgotten document I put up on tuxnes.sf.net: http://tuxnes.sourceforge.net/nesmapper.txt
This list shows 11 games that use MMC5.
-
Ooh, perfect! If it's okay, I'm going to post this onto the wiki later on!
-
Ooh, perfect! If it's okay, I'm going to post this onto the wiki later on!
I hope you're not waiting for my permission; that data isn't exactly mine to begin with. I posted that document in 1999. More searching reveals that no one ever endeavored to update that list. So it might be the most authoritative compilation out there.
-
I was about to until I saw your reply. I at least downloaded the list and I'm going over it with a fine-tooth comb for the moment.
I actually have noticed that some of the mapper info/data is a bit outdated. For example, the game Fire Emblem is said to be using a mapper known as MMC4, and from what I have gleamed from my research, is about the only known game to use this mapper. It's listed as MMC2 on this list.
Also, there's one other game that'll be a major pain in the keister: Konami's Lagrange Point, since it contains Konami's VRC7 chip, as well as a Yamaha YM2413 FM chip onboard for enhanced music. A problem, to be sure.
Other than that, it's a very good starting point for mapper information, but we'll all need to keep hunting down those last few games that aren't listed on here.
-
I actually have noticed that some of the mapper info/data is a bit outdated. For example, the game Fire Emblem is said to be using a mapper known as MMC4, and from what I have gleamed from my research, is about the only known game to use this mapper. It's listed as MMC2 on this list.
There was only one game to use MMC2-- (Mike Tyson's) Punch-Out!!. I remember that the programming specs for MMC4 were practically identical to MMC2. According to the TuxNES feature list ( http://tuxnes.sourceforge.net/features.php ), another game called Family War also used MMC4. Perusing the TuxNES source, it looks like the same code handled both MMC2 and MMC4.
There is precedent for this type of hardware redundancy. Look up Startropics 1 & 2. They are both listed as MMC3 games. As you can see from the actual hardware ( http://multimedia.cx/nesgallery/hkrom.jpg ), it is actually MMC6B, which seems to function, for all intents and purposes, as MMC3.
Also, there's one other game that'll be a major pain in the keister: Konami's Lagrange Point, since it contains Konami's VRC7 chip, as well as a Yamaha YM2413 FM chip onboard for enhanced music. A problem, to be sure.
Other than that, it's a very good starting point for mapper information, but we'll all need to keep hunting down those last few games that aren't listed on here.
I urge you to keep your eyes on the prize here. If you want to impress people with the ability to play NES games on an iPod, stick to the biggies: SMB1/2/3, Mega Man 1..6, Ninja Gaiden 1/2/3, Castlevania 1 & 2 (leave 3 for later), and those types of games. Japan-only NES games are famous for using all manner of odd mappers. Focus on those later. Much later.
But for the technically curious, check out the mapper database ( http://www.tripoint.org/kevtris/mappers/mappers.html ) at Kevtris' site (arguably the hardest of the hardcore NES hackers).
-
Very good insight, Mike. Back to the books I go... :)
And I'm bookmarking Kevtris' site as well. This guy's got a LOT of serious info on hand!
-
GodEater on Rockboy:
Most of the current devs wish we'd never implemented it in the first place to be honest, and those that like it in a "it makes Rockbox look cool" kind of way still have no plans to work on it's code. So the only way it's going to get changed is if the people who actually use it make those changes themselves.
Since I'm attempting porting another emulator to Rockbox, and I DO use Rockboy on a regular basis, I have a couple of questions:
MultimediaMike: Seeing some similarity betwixt the NES and the Gameboy, might it be good practice for me to attempt some work patching Rockboy before writing a full-scale port?
Llorean or other devs: Is there any one person regularly commiting to Rockboy? Would the devs appreciate some more time spent on it on by someone with interest?
Another small announcement is that I have school starting in about 2 weeks. It's a Computer and Information Systems major, so time could get scarce for me. Thankfully, I haven't committed to any dates as to WHEN the NES plugin will be ready. Like I like to say, that's kind of a 'once upon a time in a galaxy far, far away' for me. Slowly, but surely, fellow travelers :).
ComposerDude
-
The devs always love anyone willing to spend time working on any part of the code. Rockboy is a thorn more or less because "nobody is interested in maintaining it, as the core functionality is often both more interesting and more important, but users are more interested in games as often as not" so it generates a high support load that often must be answered with "Nobody is working on it right now." So, yeah, if someone did any work, it'd be great. I believe kkurbjun (Karl Kurbjun) is the developer who's done the most work on it in the semi-recent past, but I wouldn't qualify it as regularly committing necessarily.
-
MultimediaMike: Seeing some similarity betwixt the NES and the Gameboy, might it be good practice for me to attempt some work patching Rockboy before writing a full-scale port?
If you've never writing any code using the Rockbox API, it will probably be helpful to take a look at other plugins. You may want to see how Rockboy implements its own malloc and how it uses the audio buffer to store the ROM. A lot of Rockboy is very similar to gnuboy, hence it being a port. Give a look to rockboy.c, sys_rockbox.c, and rbsound.c to see the custom rewritten code for Rockbox.
In regards to submitting patches for Rockboy, it's always welcome! I think the only ones that have done any work on Rockboy in the past year or so have been Karl Kurbjun and myself. I believe Karl understands the core emulation a bit better than me; I've only done things like custom palettes, RTC support, and adapting the scaling code to work on smaller screened targets (e.g. H10, Nano). Recently I've rewritten the LCD code to be more unified between color and greyscale targets and added greyscale iPod support (FS#7546, (http://www.rockbox.org/tracker/task/7546) testers are needed!)
If you're looking to work on Rockboy, you could attempt to port iBoy's COP support or their custom dynamic translator and assembler cpu core. Additionally, any speed optimizations would be nice and I'm sure there are plenty of useful options and features that we are missing.
I'm glad to see someone is taking a serious interest in porting an NES emulator to Rockbox! I believe I'd be willing to help out where I can assuming I find time away from my current project (shh... it's a secret ;) ) Good luck with porting and feel free to visit in IRC.
-
I think that it's also appropriate to announce that I will also be rather busy during the fall preparing for school as well, so I'll try to get to working on TuxNES when I can at least get some free time. Between this and working for a bunch of bland "Normals", my time's kind of short. I found a good amount of useful information regarding the NES, but alas, dear friends, for I am fated to become a slave of that dreaded monster we call "Real Life".
But I know that "Bob" will give me the Slack I need to forge ahead! I found my dad's old copy of the timeless classic, "The C Programming Language", and I've been studying it when I have free time.
More info about this most Holy of Scriptures for hackers can be found here:
http://en.wikipedia.org/wiki/The_C_Programming_Language
ComposerDude: If you can find a copy of this book, by all means, pick it up! My C knowledge is actually digging its way back out of my subconscious thanks to it!
-
And I thought it had more to do with subgenius than subconscious! But still, I have an edition from '88 that I've been borrowing from one of my professors. Mr. Calculus, NesDevWiki is a treasure trove! Already any sinking feelings about researching sound and etc and graphics and etc are being lifted like a haze on a hot humid summer day (Stinky, but the light is welcome :))
-
MultimediaMike: Seeing some similarity betwixt the NES and the Gameboy, might it be good practice for me to attempt some work patching Rockboy before writing a full-scale port?
Err, similar in what ways? The NES and the Gameboy have the same control schemes and the similarities generally end there. Different CPUs. Different PPUs. Different audio capabilities. Different memory mapping schemes.
I think what you were driving at, though, was that programming RockBox emulators for each will require C coding. In that respect, fixing Rockboy will provide some training in the domain.
-
NesDevWiki is a treasure trove!
My thoughts exactly! I was floored when I first navigated to the site!
At least with this information, we should be well to do to get something started up!
-
NesDevWiki is a treasure trove!
My thoughts exactly! I was floored when I first navigated to the site!
At least with this information, we should be well to do to get something started up!
Indeed! This is the first I have seen of the site (I've been out of the scene for awhile). So you may wish to take my earlier advice with a grain of salt w.r.t. targeting Super Mario Bros. first. From http://nesdevwiki.org/wiki/index.php/Emulator_Tests#Hard-To-Emulate_Games
Among the most popular NROM games, which are generally the first targets against which an emulator author tests his or her work, Super Mario Bros. is probably the hardest to emulate.
-
Funny that one would think a game as simple as Super Mario Bros. would be so profoundly complex to emulate.
To everyone who thinks that we can pull an emulator out of our butts: do you see what Multimedia Mike just wrote? There is a LOT of a work that must be put into an emulator to get it to accurately emulate the device in question. Don't go assuming that "oh, it's an NES, that should be easy" is the truth.
ComposerDude, Multimedia Mike, and myself are researching as much as we can and should. This is going to take some time, and I know I said it before, but just to remind the kiddies:
Good cooking takes time. If you are made to wait, it is to serve you better, and to please you. --Menu of Restaurant Antoine, New Orleans
-
LambdaCalculus379: I found a nice little list of the technical specs for the NES which should be helpful in using keywords in our search for relevant documantation. The hardware specs have been written to the wiki, fellow travellers.
Hope springs from well waters of ... something. anyway.
ComposerDude
-
I just added a direct link to the main page of the NesDevWiki. Maybe a few of the devs would be interested?
Shall I put on a fresh pot of coffee while we continue to research the NES, ComposerDude? :)
-
Oh, yes! Do please, LambdaCalculus379.
-
Some register address information posted to the wiki, along with more CPU information.
And here's a cup of coffee for that long night of research.
While I'm at it, I went over my notes again, and have come to the conclusion that certain periphrials like the NES Zapper and the Power Pad will not be easy to implement on a DAP, so we can let those fall to the bit bucket.
Multimedia Mike brought up a very good point earlier about mapper support. We should start with the more popular ones (MMC1/2/3), before worrying about the more complex ones (MMC5/VRC6/et. al.).
[attachment deleted by admin for age]
-
Indeed, Mr. Calculus. I was looking over FCEU code, and nofrendo. nofrendo seems to have some mapper support issues that would make it more difficult to implement into our code. I think our best bet would to be to go with porting the mapper support from FCEU. I am still trying to figure out what to do about our 6502 emulation. Both FCEU and nofrendo have their merits and are commented relatively nicely. FCEU has some 'extra' stuff in it's code that may or may not effect how easily we can port it. At this point, here is my road map to success (Self-help books suck :)):
1. Port 6502 code into TuxNES and fix dependencies until it runs.
2. Remove all unnecessary code/features.
3. Port or add mapper support.
4. Optimise code.
5. Begin porting and optimising for Rockbox.
6. Cosider maybe succombing to the teeming masses with features and more mappers. Maybe (Mua-ha-ha!)
I see at least a year ahead of me. (Imagines grey hairs and shudders)
I think I'll go now.
ComposerDude
-
ddi you start porting it yet. Or still talking about porting it. Just wondering. i might know someone you knows this stuff and might help you. i doubt it though. he's really busy latly. thanks
-
brarei200, I posted this request several times during this thread, and I just posted it at the beginning of this page. But since you obviously didn't read it, I'll remind you again:
Please do NOT ask about the porting progress. In case you also haven't read, ComposerDude and I are still students, and we're going to be rather swamped in the coming weeks. We're going to work on this in our SPARE TIME.
Please do not ask again unless you're either a developer, or willing to help us along.
-
brarei200: For you, and anyone else interested in progress, please check our wiki page (http://www.rockbox.org/twiki/bin/view/Main/PluginTuxNES). We welcome any technical help and discussion on the forum, and probably positive reinforcement, but as far as progress goes, the wiki is a sure deal. Thanks, brarei200.
LambdaCalculus379: I'm betting our research is over, man. What do you think? I think we should note something on the wiki, or maybe do more C reading...
-
Thanks. I am as to a student! I'm just asking if you started. I wanted to know because my cousin wants to help!! Im not telling him the site now cuz of you!! jk he's not interested lol
-
I'm also a student, and I'm very interested in this project. I'm a senior computer science major, and I have a pretty good background in programming (C, Unix, etc). The more people we have helping w/ the research/implementation, the faster it will develop...and I've been wanting to get into emulation development, so this seem like a good occasion. I'll be looking into this and helping as much as I can.
-
ComposerDude: Still reading my C books. I have the source for TuxNES, Rockbox, FCE Ultra, and Nofrendo in my laptop, and I'm reading through them when I have some chances during lunch breaks or spare time. It's a bit of a slow process since I haven't done anything C related in nearly 15 years.
If you want to share a little information with me, feel free to PM me.
-
I've been looking at the tuxnes source (0.70), and it looks like the biggest tasks are the recompiler (table.x86, x86.S), and definitely the graphics and input parts (x11.c). This is obviously speculation though.
-
Thanks. I am as to a student! I'm just asking if you started. I wanted to know because my cousin wants to help!!
How is that not asking for progress?
Im not telling him the site now cuz of you!! jk he's not interested lol
Please follow our posting guidelines, which require the use of proper English.
-
stateq2: Thanks alot for any help you have! If you've read the whole thread (haha!) you've seen that both LambdaCalculus379 and I are refamiliarizing ourselves with C. Hence, advanced help would be appreciated :D. It has actually taken me weeks to figure out what we're actually doing, and most of what we've done so far has been posted to the PluginTuxNES (http://www.rockbox.org/twiki/bin/view/Main/PluginTuxNES) wiki. If you could hop on to IRC and ask for write permission to Twiki, we would love to read what you've got!
Again, thanks man.
ComposerDude
-
No problem :) This project has a lot of potential, and I really want to see it get finished :)
-
wow that would be awsome!!!!!! please do !!!! ^-^
-
A huge thank-you to markun for directing our attention to ArchOpen's aoNES emulator in the wiki:
THANK YOU AND PRAISE "BOB"!!
-
I know that aoNES is open source, but I'd like to find out what license it's under... I've searched the site twice now, and I can't find license info.
If we can truly use it, aoNES should be a huge help. And I think thats an under statement.
ComposerDude :D
-
I think ArchOpen is GPL... I'll look into aoNES, though.
-
I think ArchOpen is GPL... I'll look into aoNES, though.
Most likely it is, considering that aoNES is basically a plugin that comes with ArchOpen, which is GPL. Actually, by looking at the source for a few minutes, ArchOpen seems like a scaled down Rockbox. Even the directory structure in the source is similar :D I hope the similarities will make things easier for us.
source
svn co https://archopen.svn.sourceforge.net/svnroot/archopen archopen
-
The legal status of aones seems very unclear to me.
Whilst archopen is indeed GPL'd, aones is "a port of LittleJohnGP written by yoyo for the GP32".
LittleJohnGP - http://www.ljgp32.fr.st/ - doesn't have any explicit license that I can see (just an "all rights reserved" line in some of the source files).
However, according to its website, LittleJohnGP is itself based on other projects:
NoFrendo - LGPL
nester - GPL
Nestopia - GPL
So it seems that LittleJohnGP _should_ be GPL'd - assuming it's using code from those projects, and not just taking inspiration and ideas from them. However, without an explicit license from the author of LittleJohnGP, I don't think aones should have been using the code, and hence I don't think Rockbox should.
(IANAL...)
-
This was the same thing that prevented us from picking DarcNES previously. But that's all for the better anyway, since TuxNES is easier to work with in a way.
We could contact the author of LittleJohnGP to ask him if his own project is GPL or not, but I don't know if he's still around or not, besides that I don't have a GP32 and don't follow the GP32 homebrew scene closely.
Couldn't we at least examine the code to aoNES to get an idea of how to write for embedded targets? Or is that a rubbish idea?
-
Ok, I looked at the aoNES source, and it seems like it won't really give us any advantages over using TuxNES, considering aoNES uses ARM assembly with the cpu code, and we can't really do anything with that...I could be wrong though. Also, the mapping code is seems cluttered compared to TuxNES. What do you guys think?
-
Please, "w/" is also included in the whole "use real words" guidelines. It's really not that much work to type out a few extra characters, and it makes life easier for everyone who doesn't speak English, or has to rely on alternate methods.
-
Hello, world!
Okay, thoughts on aoNES (I'm really busy this week, guys, sorry!):
TuxNES has some nice advantages, such as what stateq2 said.
On IRC I have been advised to avoid assembly at all cost.
License has to be clear. I'm kind of picky when it comes to open source.
Considering tuxnes advantages, it will make it easier for us to port fceu code and nofrendo code over for us.
The most effecient way can often be the easiest.
I'm out like a light!
ComposerDude
ZOOM!!
-
Llorean:
Sorry about that. I need to break that habit :)
ComposerDude:
Thanks for clearing that up. I was thinking that we needed to stay away from assembly, because Rockbox is compiled for targets of varying CPU architectures, and now I'm sure ;) I'm going to do a little more research tonight.
-
That's why C is best for this project.
-
I started hacking at the TuxNES source, and everything seemed to be going smoothly, until I reached the dynamic recompiler and linker parts. The use of x86 assembly to link the C code and 6502 assembly is really giving me a headache.
I've spent most of the day trying to get a hold on it, but it seems like a really big task to convert in a timely manner.
As Multimedia Mike said earlier, perhaps we should consider nofrendo. It's written completely in C, so we can hopefully spend less time hacking at the cpu stuff, and devote more time worrying about the graphics output.
-
I personally think you're right, stateq2. How much work would it be to simply port the cpu core of either FCEU or nofrendo? I haven't started hacking, but from reading the code of these three sources, porting mapper support from FCEU should minimize the the mapper support problems within TuxNES, and likewise nofrendo's 'elegant' cpu would minimize assembly cares, and xodnizel's 250A code in FCEU would enhance game support alongside of mapper issues.
Have you looked at xodnizel's implementation in FCEU?
-
FCEU seems like a good choice, even though it's massive. Since it's based on nofrendo, there shouldn't really be many disadvantages over nofrendo, except I think that the comments in the CPU portions of nofrendo seem more informative.
Overall though, FCEU should be fine. We are going to cut out a large portion that is unnecessary to us anyway.
I'm going to be busy this week (moving into the dorm, registration, etc), so I won't be able to get much done, but once I get settled I'll jump right back in :)
-
stateq2: it's about the same thing for me this week.
As for fceu, the actual core is not as massive as the rest of the emulator. it is probably easier just to port the cpu code than to try to port the whole of the emulator.
peace out,
ComposerDude
-
I honestly think that this is the best way to go right now. A few components from each emulator will help us out immensely.
ComposerDude: Keep in contact with me when you can. I'm going to keep going through the code for TuxNES and FCEU to see what can go and what can stay.
-
hi, i was just wondering when exactly the first beta of an actual nes emulator for rockbox to come out? thanks a lot for taking your time for making rockbox even better!
-
Allow me to repeat myself:
Good cooking takes time. If you are made to wait, it is to serve you better, and to please you. --Menu of Restaurant Antoine, New Orleans
-
Do you need any help.. with this. I don't no C though :( So anything i can help with
-
So, It's almost like I've been dead for over a month to the whole community ovr here. Gosh, I haven't really made any real progress with the emulator yet, either.
But, hey, I thought I'd at least let people know that in the midst of school and all the work involved with my lab job and a friends nervous breakdown, I'm still trying to work on TuxNES for the Rockbox.
At this point, I've kind of stalled everything but work and school, so I guess I'm not actively developing anything and have nothing but research to show for my work. In any case, I'm still very interested and devoted to making this port happen, so eventually I'll come back and in a very genius like way, get to say "Hey, we've made much progress!!!" ;D
Any of you guys, stateq2 and/or LambdaCalculus379, made any progress yet? (I've done very little coding on the sources, so there's nothing substantial to offer you)
Peace be with y'all,
ComposerDude
-
Welcome back, fellow traveller!
I'm in the same boat as you. I've had to focus on work and personal life for now, and I have very little to offer right now. I'm also trying to get some work done on researching the Dell Digital Jukebox for a possible port.
I really want to see this port happen, too. But seeing as how real life is overshadowing me, progress will be slow.
-
I thought you guys should know that MikeT has started on a port of InfoNES (GPL) up here (http://www.rockbox.org/tracker/task/2911). Interesting stuff starts about 2/3 down the page, as it was a "please make a NES emulator" thread that he hijacked.
-
The InfoNES port mentioned above is actually running on several platforms and might be worth a look. I think InfoNES is GPL, but I don't read Japanese. Can anyone confirm? It's running slowly on my ipod 5.5g, but I'm looking at some quick ipod-specific loop optimizations to see if I can put a dent in the speed problem. It requires a couple of tweaks to build for ipod, and a couple of others to run on the sim, but nothing too bad... I was going to look into doing some profiling tonight, but I'm kinda new to rockbox dev, so I don't expect instant success.
-
I think InfoNES is GPL, but I don't read Japanese.
Neither do I, but I made the (relatively safe, I think) assumption that docs/GPL2 wasn't just for show (going by the source archives at what appears to be the official site (http://www.geocities.co.jp/SiliconValley/5604/infones/)). ;)
-
If it isn't GPL, it's not going to be allowed into the source. I hope everyone's clear on that.
ComposerDude and I made the choice of TuxNES and FCE Ultra because those are definitely GPL, and it's stated about as obvious as a monsoon that they are. Plus, TuxNES is lightweight, clean, nicely commented, and the code is easy to go through. FCE Ultra will fill in the blanks for TuxNES by offering mapping and sound support.
I've done a little bit of work trying to code TuxNES for Rockbox, but so far there's nothing to show that's worthwhile; I can just make a black screen, and that's it.
Back to XEmacs I go...
-
Yeah I know about the GPL thing. I'm 99% sure it's GPL'd. There is a file docs/GPL2 (obviously containing the text of the GPL v2) in the tarball. It could be some cruel japanese practical joke though.
vi > emacs :D
Though I prefer kate...
-
It could be some cruel japanese practical joke though.
You know Richard Stallman doesn't joke about the GPL. He has the katana to prove it. ;)
vi > emacs :D
Though I prefer kate...
My laptop, my choice of distro (Kubuntu), and my choice of text edior. ;)
More work on the plugin to be done, it seems...
-
I think the essence of what is being done is not in a spirit of competition, but the core of all things open source is a spirit of choice; the choice of licensure, the choice of method, the choice of product, the choice to do better. What we're working on here I think has less to do with must we do it, but can we do it, and can it be done to the best of what we are able.
InfoNES, being japanese... hahaha. I'm kidding about that.
The purpose of this project isn't "I want another emulator." I started asking about this because I wanted to work on my coding skills, I wanted to relieve the core devs of some of the flack from people wanting to game, and I wanted to offer something that may add back into rockbox dev someday.
And then interest peaked, and people came together to make this 'we', because those who are interested are that way mainly because of the goals of Rockbox. Making a better sounding DAP.
Enjoy your coffee, fellow travellers, and peace out.
ComposerDude
-
Enjoy your coffee, fellow travellers, and peace out.
ComposerDude
I'm cool with that. I'm totally new to rockbox but not c/c++ and oldschool development. So this caught my eye as both a way to get involved in some rockbox coding, and another cool thing that rockbox can do.
I think as far as getting something to the community to use, the InfoNes port is pretty far along. The games that i've tried have the same quirks that they do on the windows port, but may run a bit slower even with frame skip turned on.
If you or anyone else want to continue to work on FCEU or TuxNes for Rockbox, I'd be interested in that too. I looked at FCEU for several evenings and even created a stripped down makefile, started looking at platform problems, etc. But the next day I discovered an already running InfoNes port and haven't touched it again. :) That doesn't mean I won't ever again!
I guess I'm still kinda distracted by all the shiny bells and whistles of rockbox.
-
Yeah, I'm not dead yet either :) I have had to do just about the same things you have, ComposerDude (school, work, etc).
Anyway, I haven't made much progress with the plugin, but once I get started, I really think that progress will come rapidly. Free time is rare when trying desperately to raise your GPA ;) However, I will start working on it during the weekends.
So, in summary, I'm still VERY interested in seeing project get finished properly (GPL code), so I'm going to work on it every free chance I get.
-
Oh, GPA's...
Definitely feel you there. Thankfully, I had viral pneumonia, so they excused the poor GPA from last semester.
Finding time to work on anything else is a miracle.
-
I'm sticking by this project, no matter what. Lack of time be damned, I'll work on it in whatever spurts of time I can get!
-
Are you guys looking more at an interpretive core, like FCEU, or a dynamic compilation core like TuxNES? The dynamic compilation core might be hell to implement across multiple targets. I've been digging into the source for InfoNES and FCEU and looking at their approaches. One potential bottleneck for both seems to be memory reads and writes. Any thoughts on how to optimize that in an interpretive core? The read/write functions in InfoNES are inlined, but they are quite large, and I'm not sure they're really being inlined without looking at a disassembly.
Later,
Chris.
-
criznach, that's an excellent point to make. I want to ask ComposerDude as well, but since we're taking portions of each emulator and combining them into our own TuxNES plugin, we're thinking that we may have to consider more which core to use.
If you go back through this thread a little bit, we've been discussing this at length for some time. Even the original developer for TuxNES has come in to join on the fun, and gave us his sage-like advice on writing an emulator.
Would you like to join in on the fun as well? :)
-
Yeah, sounds good. I'm interested in both projects. I'm interested in InfoNES right now because it's already running on my player, but it seems to me that any chosen platform is going to have special optimizing needs on the rockbox. InfoNES is only playable on my 5.5g ipod with a frame skip setting of 2 and sound turned off. It's not playable at all on a sansa.
Regarding the memory read/write functions... I think with any interpreted core emulator, this is going to be one of the most critical point on rockbox's limited hardware. Profiling in Visual Studio shows that after drawing only 4,080 scanlines, the byte-reading function was called 6,034,397 times.
I'm not sure I got the correct compiler flags for this, but I created an assembly/c listing from GCC with this command:
arm-elf-gcc -O2 -c -Wa,-a,-ad K6502.c > K6502.lst
And the output shows that calls to the memory read functions are not inlined. x86 uses a call instruction and ARM uses a BL instruction. BL looks more efficient than an x86 call, but I need to look into it. The -02 flag is optimization level 2, so I suspect that the complier had decided that the function is too big to be inlined all over the place. I've tried this with and without the debug flags and the code in question is still a subroutine. So there's probably room for improvement.
So yeah... I'm down with a little NES tinkering. I did at one point start trying to build FCEU's source for rockbox. I didn't get very far, but that was one night's work.
-
One word: assembly.
This seems to be the main thing as far as using an interpretive core and memory hurdles. It's the reason we probably shouldn't go witha dynamic recompiler, and a good reason to stick with interpretive; however, to handle the read-write better, the only solution I have yet seen used handles it with assembly code.
I am so out of time it isn't even funny, but has anyone seen how Rockboy handles the bump in the road?
Peace out,
ComposerDude
-
Rockboy has some code to determine if the memory access is in a location that can be directly read or written to based on a lookup. See fastmem.c and mem.c. I am not sure how the nintendo handles memory though so I do not know what, if any benefit you would get from implementing a scheme like rockboy.
-
InfoNES uses an inlined function call for every read or write which uses a switch statement depending on the bank that the address falls into. This function is supposed to be inlined, but I've confirmed that it isn't on x86 and ARM by looking at the assembly code. If it's a mapper read/write, the appropriate function is called.
FCEU uses an inlined function that finds a function pointer in a lookup table containing (I think) every address in the 64k address space.
The problem with InfoNES's solution is that the function isn't inlined on x86 or ARM so it's being called a zillion times per scanline with function call overhead. The problem with FCEU is that the call after the function pointer lookup can't be inlined, just the function that does the lookup. So it's calling a zillion functions too.
An intermediate solution might be to write a tight and small inline function that determines if a bank is directly read/writeable and do so, otherwise, use a function lookup table like fceu. A global lookup table rather than a switch statement would make the compiler more likely to inline it.
I looked briefly at rockboy, and I should look some more.
Chris.
-
Hey, fellow travelers,
I just thought I'd journey back to Rockbox forums, since it has been months since I posted... I have had very little time to even look at TuxNES or FCEU or InfoNES... has anyone made anymore progress with a plugin? Anyone at this thread or at MikeT's port?
-
Hey ComposerDude, welcome back!
Unfortunately, I also had to put this aside for a while. Lots of things in life to take care of, and little time to really dig deep on anything.
I haven't forgotten about it, and still want to see it happen. We're going to now have to pick up where we last left off.
-
I'm on spring break, and was having a MegaMan contest with a friend here on campus. I figured I had some time to get back to it for a few days.
Peace out,
ComposerDude
-
this project has piqued my interest, but i'm not sure how much help i could provide as a low-level java programmer who's never worked on a real project. i'm usually pretty good with theoretical programming, but i'm sure a lot of what you guys are working on are beyond the level i'm used to (and did i mention that i'm a java programmer?). I could probably learn the basics of C, but again, not sure how much of a help i'd actually be with a lack of experience in things aside from more basic programs.
-
Hey all. I'm new to the scene but I have just spent over 6 hours going through this entire thread and looking up other stuff. I am deeply interested in the development scene and wish to expand my reach. I have a lot of experience with programming even some c but for robots, not hand held devices. I setup a working enviorment earlier today so I'm ready to get my hands dirty. Do not expect much from me as I have just entered the scene but I do learn very fast and have one resource that I have more of then I know what to do with. Time. I will dedicate as much time as possible to rockbox dev. I would like to join this project and be a main contributor but I am far from that so I will start on simpler things. While there is interest there needs to be more people pushing this project forward.
On that note. Is there anyplace you guys recommend to get me a fast start? I am already shuffling through the forums trying to get as much info as I can but if there is any place in particular would you kindly let me know.
On another note. Why make this a plugin? It would be in the rockbox enviorment and that might make a few things easier but what if this was made a standalone project? Rather then run through rockbox run it on its own from the bootloader? Make it run in its own enviorment and rockbox independant? It just an idea so please dont kill me. I have much programming to do!
One last thing, I swear. Having the game full screen on a player is nice, but performance suffers. In that case, what about a scaling option, not just bigger, but smaller? You might think, oh who wants to play on a smaller screen, but if you gain performance why not? I haven't tried the latest build yet but I know the one i tried had fullscreen on or of but what about intermediate or negative scaling? Just another idea...