YINLIPS G18


BAF, I'm not sure why you're being secretive or somewhat quiet about giving us more DETAILED info on the Yinlips ANDROID hand-held console?

I'm not secretive, I just don't have much time to test it :D


I'm discovering Android, so it takes a bit of time to handle it.


I installed Gmail and the Android Market on it, I just have a few problems to install some emulators.


I'll just say that this console seems to be a fearsome competitor for the Caanoo (emulation speaking).


EDIT :


and you can buy it from here too : http://www.isharegif...mp4-p-1573.html


or write to yinlips, they send some + EMS : yinlips@yinlips.com but you have to pay with T/T or Western Union.
Thank you for that and apologies for making false accusations.

Thank you and thank you Qbert a.k.a. George Costanza. :)


250px-George-costanza.jpg
 
the guy who "ported" mupen to webos using ari's dynarec, took on quite a nice chump of change from donations
Donations are optional, I'm not sure if your over estimating WebOS's popularity or peoples generosity but the actual number of donations is in single figures.

Releasing sources isn't going to help with upstream. Nobody is motivated to compare the source line by line to see if they made any improvements. People are supposed to send patches upstream. Paul is doing a nice job (albeit very slow) with his Android port. Although he intended to create a commericial frontend, I'm not sure if he abandoned his plans.


In my opinion this isn't "off topic". This chinese Android handheld is using a N64 emulator based on Mupen64Plus and Ari64's dynarec.
Ari64's work isn't integrated in the official mupen64plus and I'm not the best person for that job. The bits of work I have been doing on rice aren't complete so I haven't been in contact with the developers yet, it does work with desktop gl so it should be possible barring support for old hardware. As updates are sporadic I don't think keeping everything central is that critical but it would be nice to have things in once place.


I'm open to any questions, it would be interesting to see rice on the pandora I actually preordered in September 2008 but cancelled after 20 months.


Sorry for the Off Topic.
 
Last edited by a moderator:
Releasing sources isn't going to help with upstream. Nobody is motivated to compare the source line by line to see if they made any improvements. People are supposed to send patches upstream. Paul is doing a nice job (albeit very slow) with his Android port.
So everyone here knows where I stand on this OT discussion.. I have every intention of contributing back to the original projects I borrowed code from (that's actually the main reason I started my project in the first place - to contribute to the N64 emulation effort). It will of course be easier for me to contribute to the original Mupen64Plus project than to Ari64's Pandora port, simply because I don't actually own a Pandora. If someone is willing to collaborate and test for me, I'll be happy to upgrade the Pandora port to 1.99.4 (will require some additional work by another developer to create a new GUI, as mentioned above).

Although he intended to create a commericial frontend, I'm not sure if he abandoned his plans.
That is still the plan at some point, and is perfectly legal as long as it is distributed separately (unlike Yongzh's method of doing things) and isn't derived from any code licensed by the GPL. The whole purpose of the new Mupen64Plus 2.0 API was to make the emulator modular in order to allow this, so I don't see why anyone would have a problem with it.

The current video plugin for the OpenPandora port of Mupen64Plus is a fork of glN64 which should have been replaced by arachnoid, a C++ port of glN64, due to licensing issues.
This information is actually incomplete. I've done some intensive research into the history of glN64 and its forks to try and prove that Orkin intended it to be distributed under the GPL (and couldn't find any). The only licensing issue with glN64 itself is that Orkin never specified how it was licensed at all (which means at some point in the future he might be able to legally ask for royalties if anyone made money off of his code commercially). However, Orkin has historically been pro open-source, so I seriously doubt there is any risk here. Nobody has been able to contact him for years (he seems to have dropped off the face of the earth). As for Arachnoid, there is no evidence anywhere that I could find that Orkin actually gave Kristofer permission to distribute the source code under the GPL. I think it is far more likely that he simply slapped the GPL on his code since glN64 was open-source and didn't have a license attached to it (or because he borrowed a small amount of code from other GPL-licensed projects, like Rice video). I personally believe there is just as much a risk of Orkin calling foul on folks using Arachnoid code as there is for those using Lachlan's gles2n64 branch. At the end of the day, Orkin made his code free and public and didn't place any restrictions on it, expressed or implied. I think he would have a seriously hard time winning a law suit against another developer for stealing his intellectual property, even if that was his intention.
 
Last edited by a moderator:
FPse 0.10.54, GBCoid 1.8.3, Gensoid 2.4.3, Nesoid 2.3.1, Tiger Arcade 3.0.3, Gameboid 2.4.7, N64oid 1.1.4, SNESoid 2.2.3

Oh yes, my guess was right. All oid and Tiger Emulators on these device where released for free on SlideMe Market. The N64oid version is an old one, that was released from yongzh for free after he went to the alternative market.


The actual one is a paid app.


Would be interesting, if the actual version, which supports analog input over USB-gamepads and the iControlpad, recognizes the analog stick correctly.


FPse is simply stolen and a paid app.
 
Last edited by a moderator:
Thanks for enlightening me. If it becomes too much off topic, a moderator can always split this discussion or merge it with another topic.

The current video plugin for the OpenPandora port of Mupen64Plus is a fork of glN64 which should have been replaced by arachnoid, a C++ port of glN64, due to licensing issues.
This information is actually incomplete. I've done some intensive research into the history of glN64 and its forks to try and prove that Orkin intended it to be distributed under the GPL (and couldn't find any). The only licensing issue with glN64 itself is that Orkin never specified how it was licensed at all (which means at some point in the future he might be able to legally ask for royalties if anyone made money off of his code commercially). However, Orkin has historically been pro open-source, so I seriously doubt there is any risk here. Nobody has been able to contact him for years (he seems to have dropped off the face of the earth). As for Arachnoid, there is no evidence anywhere that I could find that Orkin actually gave Kristofer permission to distribute the source code under the GPL. I think it is far more likely that he simply slapped the GPL on his code since glN64 was open-source and didn't have a license attached to it (or because he borrowed a small amount of code from other GPL-licensed projects, like Rice video). I personally believe there is just as much a risk of Orkin calling foul on folks using Arachnoid code as there is for those using Lachlan's gles2n64 branch. At the end of the day, Orkin made his code free and public and didn't place any restrictions on it, expressed or implied. I think he would have a seriously hard time winning a law suit against another developer for stealing his intellectual property, even if that was his intention.
It's about the burden of proof. Since every file included in the Arachnoid sources includes a GPL header it shows we dealt in good faith by assuming it was GPL software. With glN64 it is your responsibility to show that you are allowed to distribute the (modified) binaries and source. This legal clearance is needed to be able to include software in Linux distributions or repositories.
 
Last edited by a moderator:
So everyone here knows where I stand on this OT discussion..
Well I guess DaMummy was upset with the way Yongzh was handling this in the past, you're doing fine there.

If someone is willing to collaborate and test for me, I'll be happy to upgrade the Pandora port to 1.99.4 (will require some additional work by another developer to create a new GUI, as mentioned above).
If you can keep your code buildable for ARM Linux (cli version would be fine), somebody could probably take it from there, or at least slap a launcher on it.
 
Yeah, picklelauncher would be fine. I think Gruso was already working on some N64 Theme for it.
 
Anyone know if it can be overclocked at all? I imagine the N64 emulator runs a lot of games painfully slow at 800MHz.
 
Wait! N64 emu without a second analogue stick?

N64 only had one analog stick...


Sure, you can map the C-buttons to another analog stick, but they weren't used that heavily in games to begin with. So keeping them to touch icons is probably okay.
 
Try playing Smash Bros 64 without an actual C button. A touchscreen would be horrible for this.
 
Try playing Smash Bros 64 without an actual C button. A touchscreen would be horrible for this.

So for some consoles there just isn't going to be a silver bullet configuration and you're going to have to fall back on per-game. Maybe a good alternative is to have shoulder + face activate C, although I don't know if the emulator allows these kinds of configurations. If it doesn't that could be a goal for a different version.


Are the two bottom buttons programmable?


Anyway... I'm still really curious what the dpad is like. If the dpad is good, or at least "good enough" this looks like a really killer handheld. If the dpad sucks then it's not really worth an awful lot as a gaming device, although it'd still beat the pants off of an iPod Touch in a lot of metrics. I'd like to say the videos provide some indication of what the dpad's like but I'm seeing a lot of finger lifting in them. I don't know if this is how they normally do it or if it's non-ideal because they're filming it, but this usage obscures whether or not the dpad is conjoined and how it responds to rocking motions.
 
Last edited by a moderator:
Back
Top