Support and General Use > Plugins/Viewers
NES plugin - a proposal
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: ---arm-elf-gcc -O2 -c -Wa,-a,-ad K6502.c > K6502.lst
--- End code ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version