Rockbox

As you might have noticed the rockboy emulator is pretty slow, especially with color games. The Nes games will be even slower as they are higher resolution and use more processing power. The Snes games will be _very_ (ie not even close to playable) slow on our currently supported targets.

I dunno. I’d still be willing to try it. Rockboy was pretty craptastic when I got it with the December release. However, I just upgraded to the latest version, and (maybe it’s just me), but the framerate is higher and animation smoother. it’ll take a while to get it up to speed, but I’d download it in a heartbeat, regardless of the quality. (Tales of Phantasia on
do have to agree it’ll be really hard to get to a playable speed...

what if rockboy was modded to play nes games?

gameboy and NES are two entirely differnt machines, and btw there is one person that has started gathering resources in the wiki relating to a potential NES emulator

Actually I don’t see why it would run slow? iPod Linux has NES at 100%! SNES would probaly go around 60-70% under my guess?

Wasn’t the NES less powerful than the Gameboy Color? I mean, there’s a NES emulator for the
problem would be displaying the graphics on the smaller devices, and the coding of the actual emulator.

The sprites are a higher resolution for the NES (I think), and also the GBC is a gaming system. Most MP3‘s that are Rockboxed aren’t ment for gaming, so a NES emulator that runs well would be difficult.

A NES emulator for the GBC? will wonders ever cease? =D

Brarei, the reason iDarcnes in Ipodlinux works so well is because they’re using a part of the ipod (forgot which one, lol :B) to make it run so fast sometimes the sound can’t keep up. Something you really need to keep in mind with Rockbox and Ipod Linux; Ipod Linux is only for Ipods. the reason it’s (for lack of a better word) better than Rockbox is that they’re only working with Ipods, and take advantage of every little part to have excellent performance in programs Rockbox has trouble keeping up with (but at least our Doom has sound >:3 muahaha). Rockbox, on the other hand, is for many different MP3‘s, and many different functions. that’s why Rockboy is slow on the H10, but perfect on the Gigabeat. it’s the different systems that make Coding a new program for rockbox in general so difficult.

What I’m saying, Brarei, is to not make too many similarities with Ipodlinux. I like IPL, but it is MUCH different from Rockbox, and you need to keep that in mind when making a technilogical statement or question with
is Rockbox and IPL is IPL. done

ahem... getting back on subject...

The graphics and coding difficulty are a given when it comes to anything emulation-related. it’s not unique to the nes .

one more thing to think about, Michael. When you aren’t playing a Nes emulator on your GBC, play a GBC game. then play that GBC game on an ipod or whatever. notice the difference? As I just said with Brarei, most of the systems that run Rockbox can’t run emulators at full speed. and since the GBC is slow, then doesn’t that mean the NES’ll be slow?

The NES emulator won’t be perfect, but I still can’t wait to try it.

Jake (Zombieplasticclock),

It’s not accurate to say that IPL is better because they are only focused on developing for ipods, and hence take advantage of “every little part”.

IMO, the relevant differences are not technical, they are:

1) IPL has active developers with an interest in gaming and emulators. Rockbox doesn’t.

2) IPL is split into a distinct kernel and userland, which means they can port non-GPL‘d software (such as DarcNES and MAME) to the ipod. Rockbox’s all-in-one nature won’t allow that, and unfortunately very few emulators are GPL‘d.

Warning: Undefined array key "useheading" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parser/xhtml.php on line 1099 Warning: Undefined array key "target" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parser/xhtml.php on line 557 Warning: Trying to access array offset on value of type null in /home/rockbox/flyspray/plugins/dokuwiki/inc/parser/xhtml.php on line 557

I’m currently working on a infoNES port. http://www.geocities.com/tm_lockheart

MikeT, I think it would be a good idea to put your work in progress emulator and any info in a page in the rockbox wiki so that it would be easier for others to help out and follow the development.

Geocities is overloaded, so I’m uploading the plugin here.

The emulator unexpectedly works on my H100 (gray scale) and after a one-liner on my F40 too (and sims). I couldn’t find a way to change the button configuration on the code and as you say it is slow on H100 too. On F40 it is quite playable.

Good work, though the zip file contains a lot of duplicate
would suggest to you to open a new task (patch, not on feature request) and make an svn diff of your work so that it will be more easy to compile.

Well it is quite awesome, thanks! :)

Hey, I guess this is a patch now!

I really need to get sound working. This is my first try at a diff so I hope I go it right

I’ve modified the way the button definitions are handled to make it easier to support all the targets. I’m attaching two files - a new nes_rockbox.h which includes the target-specific button definitions, and an updated version of InfoNES_System_Rockbox.c which uses these new defines.

The nes_rockbox.h only includes defines for the H10 (the same as the original patch) and the Gigabeat (just an initial attempt - maybe they need changing). Maybe others could add definitions for their devices.

Note that the NES needs 8 buttons - the four directions, A, B, select and start. So for example the ipods will probably need the same approach as rockboy - using the wheel as a touchpad to generate 8 different button locations.

Removed unneeded files, minor changes. For some reason the buttons don’t work correctly on my simulator but okay on my player.

Any chance of this patch working on the Sansa e260? If it already does, where would I place the files?

infonessx.diff seems to just hard-lock my gigabeat. It flashes a loading splash, then the player is unusable without toggling the battery switch.

Amazing, I can play Contra at what seems like almost full speed on my gigabeat. With some button map changes, I’ll be able to actually play NES games.

in quite a few roms when i try to load then i receive

then have to do a hard reboot. i dont believe its a problem with the roms as i can run them on fine on znes. also any .snes games wont show up at
believe the viewer needs to turned into a port of znes just like rockboy is a port of
has most if not all the features that i think we would require. Game specific button mapping, grayscale support, full stereo sound, frame skip, save/load, emulation speed etc and it is very fast it doesn’t look like that much of a resource hog but it might be a bit of a pain to port but theres Snes9x aswell which is very port friendly apparently.

Hey, can you tell which of the uploaded files I do need? I tried only infonesx.diff, where I added the keys for the e200 series, but it’s not responding to the keys(neither sim nor build)

Anyone had any luck building this for an iPod video 5.5? It builds with some warnings but I haven’t been able to get my .nes files show up in the file browser yet. What am i missing?

I’ve have only been working with rockbox for a few days, but I’ve been building and tweaking plugin code. I had been looking at the other NES port thread and playing with FCEU code, but this one looks promising.

Is SNES9x GPL? or FCEU? remember that the source code needs to be open GPL in order to be put into Rockbox.

oh, and 5.5g version, por favor? that’ll be so awesome =D

SNES9x is gpl so is znes

Looks like on my 5.5g iPod the final blt of the frame buffer to the lcd is a major bottleneck. On that platform if I undefine the current copy code and use the 1:1 pixel copy with no scaling, I get maybe a 2x speed improvement. The 5.5’s native resolution is 320×240, which is perfect for iNes, but it’ still 2x too slow. There are 2-3 function calls and 2 bounds checks per pixel with the current method. I might look at the rockboy code for a faster way. I’m not familiar with how the lcd framebuffer works in rockbox, but I can see that rockboy appears to bypass the drawing api and even use assembly on some platforms. This would be a major speedup. Is there a better place to discuss technical issues of the ines port? Anyone know asm for iPod?

Warning: Undefined array key "useheading" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parser/xhtml.php on line 1099 Warning: Undefined array key "target" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parser/xhtml.php on line 557 Warning: Trying to access array offset on value of type null in /home/rockbox/flyspray/plugins/dokuwiki/inc/parser/xhtml.php on line 557

So.... InfoNes is not iNES. iNES is another emulator that is not GPL. Wikipedia says it’s proprietary license. This page: http://fms.komkon.org/EMUL8/ says it is not GPL and is INCOMPATIBLE with the GPL. You might want to eventually change the name of the plugin, since I’d been searching for iNES all day and discovered I had the wrong one.

I tweaked the InfoNES_LoadFrame function to access the frame buffer directly on my ipod and it runs faster now. Still not fast enough... I also tweaked a few inner loops in the InfoNes line rendering code, but no major speed gains there. Once I get a bit more, I’ll try to put together a patch.

?

sorry, I’m a little lost, is this the NES emulator everyone’s talking about, or an Snes Emulator?

by the way Criznach, I think SNES9x and Znes would be hard to port, since they’re higher-end SNES emulators. a low-tech SNES emulator that’s GPL‘ed would be good

sorry I can’t help with Development. My computer has no internet, and I don’t think people’ll be kosher with me downloading VMware everywhere

The last patch is only a NES sim. No actual target could emulate SNES anyway.

This is NES only. I just stumbled into this thread from the other NES emu thread. And it is looking like InfoNES is GPL2, but I’m still not sure. The license is in the source tree, and the readme.html contains the string “GPL2”, but it’s in japanese.

Is there any plan of updating this one? It’s pretty bugged.

While this might be very interesting to many of you this tracker page is only for technical feedback on the patch and development. Other comments and discussion belongs in the forums and irc.

I dunno. Maybe we can get the author of the port to join the thread. I've updated just enough to get it running on my iPod, but there are some issues with some of the games that are also present in the Win32 port. And the controls are screwy on ipod. I'm working on that now.

Discussion thread started here: http://forums.rockbox.org/index.php?topic=13157.0

Here's a patch containing the work I've done so far. This includes: Optimized 1:1 lcd copy for displays as large as or larger than NES frame buffer. Changed the #ifdefs around frame buffer copy to toggle 1:1 code when appropriate Optimized sprite to scanline copy (minimal gain, I suspect). Forced backlight on. Wrapped non-simulator-compatible code in #ifdefs. Grafted some ipod scroll wheel code from rockboy, toggled on with platform #ifdefs. Added rb->yield() to InfoNes_DrawLine that gets executed each frame.

And what's about the Sansa scrollwheel? Nice work anyway, I hope to see more updates.

I didn't do anything specific to the sansa. I may have one available to play with (If my girlfriend will let me :)).

I can confirm that "infonesx.diff" (http://www.rockbox.org/tracker/task/2911?getfile=14834) is not working on the Gigabeat. When it compiles, a whole slew of warnings fly across the screen. Any idea what's wrong? Anything I can do to help/bug test? If it makes a difference, I was using "Legend of Zelda, The (U)(PRGO)" from the GoodNES set 2.01 (pretty sure it's that one). Good luck and I look forward to improvements.

It compiles and works I was able to run a bunch of mario games and contra on my gigabeat no problem, with only changing the keymaps. Maybe it's because I'm using an older SVN source. It does give off a ton of warnings, but works fine for the most part.

Fixed color for RGB565SWAPPED targets. Added save/load for small amount of roms. Other small changes.

i cant get the patch to work.

Can I get some assistance for compiling this in Ubuntu?

Here's a massaged version that at least compiles on r19289, although with plenty of warnings. As I have neither any hardware that this is expected to run on, nor any NES roms to try, this is as far as I go.

I would like a snes or even a nes emulator for rockbox on my sansa e260 however i don't understand where to put the files and how to make them run under rockbox so if anyone wants to guide me through it it would be greatly appreciated. thanks in advance. hope to try it soon!!!

Paul, you need too set up a dev enviroment on your computer, download main source, add the file to there respective places, and compile it... see http://www.rockbox.org/twiki/bin/view/Main/SimpleGuideToCompiling

I get this error when compiling with r19868 and the latest infones patch: /files/src/rockbox-svn/apps/plugins/infones/InfoNES_System_Rockbox.c:118: error: conflicting types for ‘plugin_start’ /files/src/rockbox-svn/apps/plugin.h:854: error: previous declaration of ‘plugin_start’ was here make: *** [/files/src/rockbox-svn/build-dir/apps/plugins/infones/InfoNES_System_Rockbox.o] Error 1 Also has anybody thought about porting Mednafen ? It's a GPL multi-system emulator that supports the Atari Lynx, GameBoy (Color), GameBoy Advance, NES, PC Engine(TurboGrafx 16), SuperGrafx, Neo Geo Pocket (Color), PC-FX, and WonderSwan (Color).Many of these systems should be fast enough to run on most targets, and the code is much more up to date than infones or gnuboy.

i get the same error as well for r20322.

For those with therecent plugin_start issue, I have corrected this much. I'm a bit green to this though and don't have the required files available for a patch file. But basically you go down to line 117 in InfoNES_System_Rockbox.c and remove 'const struct plugin_api* api' leaving just const void* paramter in the parenthesis. Then higher up in the file where plugin_api was already declared (should be line 16), change *rb to *api to line up with the calls in the rest of the file to *api as it was in the plugin_start function. With that, the InfoNES_System_Rockbox.c file compiles cleanly now. Though now there's a tone of 'undefined reference' errors in K6502.c that are beyond my comprehension.

Ok ive tried what you said and InfoNES_System_Rockbox.c compiles now. but there is still a make error with LD and infones.rock

Here. Basically the most recent posted patch file with the mentioned lines modified to fix the plugin_start error. Outside of the K6502.c 'undefined reference' errors on the final LD infones.rock during compilation and the swath of warnings earlier on, the rest of it seems to work with the latest SVN (r20528 as of this post)

Ok that patch works expect the very last part the SUBDIRS file errors when patched but thats easily done manually. also the final LD on the infones.rock errors and make stops running so i dont think it creates the infones.rock file thats needed. I cant find it on my sansa.

Just out of curiosity, what's holding this patch back from being included in the regular rockbox builds?

@Jeffrey Roberts: Probably because it is still terribly messy and doesn't really compile for everyone and doesn't do so cleanly (ie: without warnings) for those it does. It still needs tons of work to get it into a 'stable' state before I think any developer would even look twice at it for inclusion.

And it never did reach a playable level for me on the ipod video 5.5... It might get there if it could take advantage of the ipod's second processor core, but when I was working on it the kernel didn't support it.

I'm using "gigabeat F" series. I receive the error message "incompatible model". How do I work around?

Cleaning up the patch?

No... How do we do that?

This is my attempt at cleaning up the patch. Here's what I've done: * fixed the K6502.c LD errors ("static void" > "extern void" in K6502.h was probably correct code-wise, but it messed up the build, so I reverted it.) * several code corrections to fix warnings... the rest of the warnings I couldn't fix, I hid (-w in the Makefile). It's cheating, yeah, but I'm too lazy to do the right thing and actually fix them. * Added keymaps for all the targets I could find (stolen from rockboy). Unfortunately I don't have any of those players so I didn't bother testing them. (even in the simulator) * Fixed the menu code to reflect the new menu API, and added a video mode menu (to scale, stretch, and halve the screen [size]). * Several other things I don't remember. Now it compiles and works on my Sansa. It's still slow! I attempted to add an ARM-optimized 6502 core, but it looks like just as much work as porting a whole new C++ emulator (i.e. FCEUX).

It came up with the error.　What is the answer to this problem?

Is that with my patch or the previous one? In the latter case, the solution is to use my patch. I fixed all the build errors I found (notice I didn't say "warnings"...) It looks like it's a problem with the older patch - or maybe the problem is from over-editing it. Judging from the comment lines I removed from InfoNES_System_Rockbox.c in my patch, I can tell from your screenshot that you aren't using my patch - in mine, it doesn't have 988 lines. You shouldn't have any trouble with my patch.

Tanzola's patch is come up with the error.　What for?

I'm not having any patching errors, but when I go to compile, I get a slew of "'for' loop initial declaration used outside c99 mode" errors. I'm lost. D:

Jeff: when I was messing around with the mappers, I noticed some of them weren't included, so I uncommented the #includes. It made a mess, so I reverted it, but somehow the patch retained the bad edit. Here's a new one, it should be fixed... Sorry about that! If more errors come up, let me know. Roger: The old patch is conflicting with the new one. You need to start with a clean Rockbox build environment. (If you don't want to do that, try reversing the patch. Or you could delete apps/plugins/infones and edit SUBDIRS and viewers.config by hand. THEN try my patch.)

Gilberto, nice work. Compiles and "runs" on my Fuze. Controls don't seem to respond, though (apart from the power switch bringing up the menu.) Still though, it's really cool seeing the intro to Super Mario Bros. 3 running on my MP3 player.

I deleted all files (Rockbox source , infones) and downloaded it again. I edited SUBDIRS by hand. But came up with the error. What's wrong with my way?

Roger: I can't tell from your screenshot. It might be caused by your compiler (Cygwin/MinGW) differing from plain GCC or something like that. If you have a Linux LiveCD/installation/VM, try with that. If that doesn't work, post your InfoNES_System_Rockbox.c here for me to compare it with mine. Jeffrey: I don't have a Fuze; I just copied the keymaps from Rockboy. Take a look at the lines below "#elif CONFIG_KEYPAD == SANSA_FUZE_PAD" in keymaps.h if you don't know what the mappings are. If none of the buttons respond (Scrolling back should be the Start button), try changing them around. If it still doesn't work, I probably need to do some Fuze-specific stuff.

After a bit more testing, it seems that the scroll wheel doesn't respond when I load infones. The wheel light doesn't even respond. The keymaps file looks alright to me; I think the problem might be a bit deeper than that. I tried loading a game that didn't require the start button (in this case, Kirby's Adventure). It didn't take long before I was actually playing the game. (setting the frameskip to two yielded pretty close to full speed!) I'm assuming that the sound is disabled for a reason. When I go to enable it, I get a "*PANIC* Unaligned pointer!" error, followed by a reboot.

I have tried unsuccessfully to compile by Ubuntu. It was produced the same results. I uploaded the InfoNES_System_Rockbox.c file.

After a little inspection, I figured out what was preventing the scrollwheel from responding on the Fuze. All the changes are in keymaps.h and InfoNES_System_Rockbox.c.

Also, for those who might be doubting the playability, see here: http://twitpic.com/cmarb Apart from a few graphical glitches (typically when the screen was scrolling vertically, entering pipes, etc..., all stuff I've seen in less-advanced NES emulators on the PC) and the lack of sound, the game was completely playable. The frameskip was a bit annoying at times, but that's relatively minor and in my opinion to be expected.

Roger: From inspecting your file, it looks like you have the old file combined with the new file. Starting near the middle (Line 966 to be exact, which is supposed to be the end of the file) you have the contents of the old version of InfoNES_System_Rockbox.c. How that got there, I don't know, but here's how to fix it: Delete every line after (but not including) line 966. Jeff: I'm glad you worked that out. I had a similar problem with my Sansa e200 scrollwheel, which I fixed by duplicating some code from Rockboy. I guess it's the same for the Fuze. As for sound, it's really distorted on my e200, but it works. I don't know what triggered your sound panic, but my uneducated guess would be that it's Fuze/sAMSa specific. On my 80Mhz e200v1, SMB3 is quite a bit slow even with a frameskip of 6 and sound off. I'm sure having a 250Mhz (max?) Fuze makes a difference. Oh well. I might eventually decide to do a port of FCE Ultra/FCEUX or maybe Mednafen if I can somehow get around the fact that they are all written in C++.

Compiles and "runs" on my Gigabeat ! I deleted every line after (but not including) line 966. I'm sorry to put you to so much trouble. Thanks so much!

Gilberto: I'll take a look at the sound code later on and see if anything strikes me as odd. Hopefully even with my limited programming experience I'll be able to spot if something's not quite right. Also, if you were to port FCEU(X) or Mednafen... I'd be very grateful. And willing to help out in whatever limited capacity I can. :D

Hey Gilberto (and whoever else may be interested in working on this project): I came across this in my internet travels today: http://www.zdziarski.com/projects/nescore/ It's essentially an updated, optimized version of InfoNES, and the author claims "If you are using InfoNES in your project, it should be very simple to switch to NESCore." Rather than start a new port, I'm thinking it may be a good idea to at least attempt updating the existing plugin with this core. I'd attempt it myself, but my programming knowledge is rather limited... but I'm learning!

I just decided I would start porting Mednafen because I'm fed up with InfoNES's terrible speed (and I want a GB[A]/SMS/GG/$CONSOLE. emulator too :). Before you get too excited, let me tell you I don't have much (read: any) experience converting C++ to C. That will probably be the most tedious step besides porting the core, video, sound, and input code. Here's pretty much all I know about converting the code so far: I need to convert classes to structures and remove all object-oriented features. I'm still learning how to do those things. There are automated tools to do this, but none of them do the whole job, and that approach doesn't have many advantages over doing everything by hand. Hence, I've decided to do all the converting by hand. I'm still hungry for knowledge on the subject. Since this task is for an NES emulator in general and not specific to InfoNES, I'm posting my work here instead of opening up a new task. *****WARNING!!! THIS DOES NOT COMPILE AT ALL!!!***** My changes to the vanilla Mednafen 0.8.C sources: * thanks to my mass renamer, I renamed any .cpp files to .c. I also moved around some docs. * removed problematic emulator source code - namely, anything related to CDROM or netplay. I also removed the wswan, ngp, lynx, pcfx, and pce emulator files because they use CDROM and netplay code. * made a template mednafen_rockbox.c out of InfoNES_System_Rockbox.c for Rockbox-specific stuff * made mednafen.make, Makefile, and SOURCES since configure script isn't allowed/needed for inclusion with Rockbox and doesn't work * edited some files to convert classes to structures and remove references to std::vector/std::string, etc. NOTE: I haven't done this with all the needed files. I still need a little help with the first couple of steps. If anyone has experience with converting C++ to C, please contact me! After I get through the conversion to C, the other steps will be likely be much easier - except maybe the SDL audio and video. In the meantime, I'm starting to take the first/next step-and-a-half or whatever you want to call it... (To start working on this, just put the mednafen folder in apps/plugins and add "mednafen" to SUBDIRS.)

Jeff, I didn't notice your post before I posted mine! I tried to download the NESCore sources, and apparently the site is having problems. I can't really do anything without them. If you have NESCore-1.2.0.tar.gz, please post it here. My Mednafen port might not get very far if I can get NESCore working... ;)

Never mind, I found a mirror. Now I'm working on integrating it!

Oh, awesome, you did see my post. Keep us posted on the progress.

EDIT: Patch removed due to licensing issues. --- I finally got it to compile! Unfortunately, the solution was temporarily increasing the plugin buffer size (a big no-no) because I couldn't find a proper solution. And I'm still stuck trying to adapt the video stuff. Anyway, I forked/renamed the emulator since it only has a couple lines of InfoNES code now - all the rest is either stuff I've written or from NESCore. I decided to rename it to BoNES for a couple of reasons: 1: You can pronounce it "Bo-Ness", "Bonus", or "Bones" (as in skeleton) 2: I felt like it, and 3: I got BOred coming up with a name. If you don't like it, suggest a better one. Here's what I have so far. Unfortunately, it's severely lacking without video...

You could grab the audio buffer. If games are to be played with sound, music playback won't be needed anyway (doom and rockbox do that too).

I figured out why it wouldn't display any video. It was because I messed up stuff in the core I shouldn't have... I'm still working on some finishing touches so I don't have to post a whole new patch for minor fixes. It'll [hopefully] be finished by tomorrow.

So much for "tomorrow"... I should have been more clear about it, but the video still isn't working. It displays a picture now, but it's not pretty. It looks like a TV screen trying to display a nonexistent signal. Other than that, menu and input work, but sound still doesn't - I'm trying to fix the video first. When I'm done with sound and video, I'll fix the savestate code and clean up.

The latest patch doesn't compile for my 5G The error is in the image.

Gman: The latest patch is my unfinished attempt at coding an emulator using NESCore. Even if you manage to compile it, video output still won't work. You should use "infones-fuzescrollwheel.patch" until I'm finished with it, at which point I'll post another patch. You got a build error because I didn't double check the keymap code I stole from Rockboy to make sure color iPods (and possibly some other targets) work! That'll be fixed with my next patch.

Wow. I just realized the iPod Video keymap is the same as the 4G... Anyway, It looks like you added HAVE_SCROLLWHEEL (which is only for Sansa e200/Fuze - it might do something weird to your iPod) to input.h. That's the source of your problem.

I didn't add any thing but I knew it was the keymap. I'll just wait for the next version ;)

CC apps/plugins/infones/InfoNES_System_Rockbox.c In file included from /home/calvin/Desktop/rockbox-20090817/rockbox-21932/apps/plugins/infones/InfoNES_System_Rockbox.c:27: /home/calvin/Desktop/rockbox-20090817/rockbox-21932/apps/plugins/infones/keymaps.h:28:1: error: unterminated #else /home/calvin/Desktop/rockbox-20090817/rockbox-21932/apps/plugins/infones/keymaps.h:1:1: error: unterminated #ifndef make: *** [/home/calvin/Desktop/rockbox-20090817/rockbox-21932/fuze/apps/plugins/infones/InfoNES_System_Rockbox.o] Error 1 I'm REALLY bad at C, does anyone know how to fix this? I cant figure out how(where) to terminate these.

Calvin, go to the end of keymaps.h and make a new line that says "#endif" (without the quotes) and save the file.

( [Calvin] Actually, you might need two #endifs, each on their own line. ) Status update* on BoNES - I'm going to do a maximum of 10 code changes to fix the video output before I post the next patch. As much as I don't want to flood this task with unnecessary non-working patches, I'm nearing the end of my patience in fixing this problem, and letting others see my code will likely make this much easier. I'll be back soon! * not much of an update

Thank you, Gilberto. I will try that tomorrow.

Thank you, Gilberto. I will try that tomorrow.

Yep, it worked. Thanks!

On top of not being able to make BoNES output video, I just realized that the 6502 emulator NESCore uses is released under a "no commercial redistribution" license, which is incompatible with the GPL! (In my attempt to clean up the source, I removed the license header without looking at it - one of the dumbest things to do!) Now that I think about it, NESCore was able to include it because NESCore is LGPL, not GPL. To sum it up, I'm not sure about the legal status of my BoNES patch. The license reads: "You are not allowed to distribute this software commercially. Please, notify me, if you make any changes to this file." Well, back to the drawing board...

The licenses on NESCore are inconsistent. You should contact the author/maintainer and ask him to clarify why the licenses on the source code are not consistent with the license he has chosen to distribute it under. Without clarification you cannot use that code, and you definitely should not be distributing it with the licenses in the source code files changed.

Looking at this more carefully there is no way NESCore is (L)GPL licensed. From the author of the actual CPU emulator: "The above license terms are incompatible with GPL. Thus, you should avoid making the source code from this page and any derived code part of a GPLed project." So he clearly does not allow you to use this with rockbox.

I stupidly forgot to research further what emulation core NESCore used... M6502 is not GPL-compatible. I will not duplicate my mistakes. Sorry, this all my fault; I made some very stupid assumptions, and I can miss some pretty obvious things in case you haven't noticed.

BoNES is now a pile of bones O_o (I couldn't resist...) As far as I'm concerned, my coding is suspended until I have some common sense knocked into me (or maybe until I find a GPLv2-licensed app to port that's more useful than a NES emulator...)

I decided I'd try to port Nofrendo since the TuxNES people were apparently considering it. Nofrendo is licensed under the LGPLv2 and AFAIK it doesn't include GPL-incompatible code. (If it did, I'm sure the TuxNES devs would have pointed that out already.) I got it to compile and run on my Sansa, but all it does right now is blank the screen because I haven't started the Rockbox video code (or much of anything else, for that matter). This is only for developers right now - there's no point in downloading it unless you can help in some way. (Also, if you get "region PLUGIN_RAM full" errors compiling this, it's because I still have my plugin buffer size increased, and I didn't try compiling without it.) I know, more useless stuff... Tough luck. :P

Sorry for TL;DR, but I see many people are working on this, so all I can say is GOOD LUCK ON THIS. If this bug tracker were somthing like the wine appDB one, i'd vote for this. Cheers.

Why is a task closure requested on this?? I am just wondering ^^ Have A Good Day.

It seems that interest has waned on this patch. Also, it’s terribly out of date at this point, and no one has picked up the slack of fixing it up to keep it compiling on the current SVN trunk.