NES plugin - a proposal

[criznach]

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.

[stateq2]

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.

[ComposerDude]

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.

[LambdaCalculus]

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!

[criznach]

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.

[LambdaCalculus]

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?

[criznach]

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:

Code: [Select]

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.

[ComposerDude]

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

[kkurbjun]

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.

[criznach]

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.

[ComposerDude]

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?

[LambdaCalculus]

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.

[ComposerDude]

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

[grossaffe]

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.

[otakus]

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...