NES plugin - a proposal

[stateq2]

No problem  This project has a lot of potential, and I really want to see it get finished

[miles_power]

wow that would be awsome!!!!!! please do !!!!  

[LambdaCalculus]

A huge thank-you to markun for directing our attention to ArchOpen's aoNES emulator in the wiki:

THANK YOU AND PRAISE "BOB"!!

[ComposerDude]

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

[LambdaCalculus]

I think ArchOpen is GPL... I'll look into aoNES, though.

[stateq2]

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  I hope the similarities will make things easier for us.

source

Code: [Select]

svn co https://archopen.svn.sourceforge.net/svnroot/archopen archopen

[linuxstb]

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

[LambdaCalculus]

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?

[stateq2]

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?

[Llorean]

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.

[ComposerDude]

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

[stateq2]

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.

[LambdaCalculus]

That's why C is best for this project.

[stateq2]

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.

[ComposerDude]

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?