possible soc updates.


I said that the "pandora runs", which for the most part is opensource, which can be compiled to run on x86...while alot of x86 software packages are closed and only run on x86 hardware.
I guess this is where you completely stop making sense.

That Android software that's not compatible with the Intel translator is something "pandora runs" that an x86 device doesn't.

DraStic is something that "pandora runs" that an x86 device doesn't.


There's a fair amount of closed source software on Pandora. You said NO ARM software. Not little. No. Stop fucking around monstercameron.
that is a stretch, using a totally different operating system to try and disprove me, we are talking about the pandoras stock os and not android

you own the source to drastic, you can compile it to x86...

point me to a list of these arm native closed source software packages running on the pandora...

lastly chill out dude.
 
^ He could compile it to x86, but most likely it would require a significant amount of re-coding to run as well.. I know Exophase can respond better on this.. just needed to put that in.

 
 
^ He could compile it to x86, but most likely it would require a significant amount of re-coding to run as well.. I know Exophase can respond better on this.. just needed to put that in.
to recompile it may take alot of work but it is sure easier than reverse engineering/decompiling a close source software package.
 
Using certain hardware, even if it is inferior, just to be able to run some binaries that only work on that hardware? To me, that sounds as stupid than using a certain OS, even if it is inferior, just to be able to run some software that only works on that OS.

I could very well make Microbes and NubNub closed-source so they only run on ARM. Does that make ARM better and x86 worse? I don't think so.

You are making it sound like having lots of closed-source software is an advantage. To me it is a disadvantage. Please point me to any x86 software that given the source code cannot be made to work on ARM.

In the case of DraStic, it's different than most software because a significant part of his code is in the dynarec from the DS cpu instructions to ARMv7 instructions, which is of course quite ARM-specific stuff. I think he also has a dynarec to x86, but it is less optimized. If he would just recompile the Pandora version of DraStic for x86, it wouldn't work because while the emulator itself would run fine on x86 (as in: you could probably use the GUI and maybe even emulate a game with the dynarec disabled), the machine code it generates on the fly and tries to run would still be ARM code, which of course wouldn't work on x86.
 
Using certain hardware, even if it is inferior, just to be able to run some binaries that only work on that hardware? To me, that sounds as stupid than using a certain OS, even if it is inferior, just to be able to run some software that only works on that OS.
tell that to all the pros that use programs like final cut on mac, I dont think it is stupid at all, just as you "...could very well make Microbes and NubNub closed-source so they only run on ARM..." so have they on their respective platforms...

You are making it sound like having lots of closed-source software is an advantage. To me it is a disadvantage. Please point me to any x86 software that given the source code cannot be made to work on ARM.
missing the point, point is that there is software that will never natively run on arm, ever.

In the case of DraStic, it's different than most software because a significant part of his code is in the dynarec from the DS cpu instructions to ARMv7 instructions, which is of course quite ARM-specific stuff. I think he also has a dynarec to x86, but it is less optimized. If he would just recompile the Pandora version of DraStic for x86, it wouldn't work because while the emulator itself would run fine on x86 (as in: you could probably use the GUI and maybe even emulate a game with the dynarec disabled), the machine code it generates on the fly and tries to run would still be ARM code, which of course wouldn't work on x86.
I don't think I ever mentioned performance in my comments, my comments have been about compatibility and I don't think I misrepresented the effort it would take to port and optimize...only that you could.
 
Last edited by a moderator:
Just because you don't understand an argument doesn't mean it is wrong.
 
I'm not playing any more games with you monstercameron. Always the same old (wrong) claims and the same old arguments. If you're going to play nonsense with semantics at least actually be right. You said there was no software that could run on ARM and not x86. You're wrong. Period. You can't change this after the fact to say this only applied to Pandora's OS (as if Pandora's ability to run Android is merely a novelty, or would be even for a new device), you can't say that "software" actually meant packages - whatever that means - and you can't say that my closed source software doesn't count just because I could recompile it (as if) because the same thing applies to any piece of x86-only software you could mention.

People, you may think I'm losing my cool here but I'm not. I know what I'm typing and I have plenty of time to review before hitting enter so I'm not just fuming at the keys here - I'm sorry if some of you are offended by it but I want it to be totally clear what bullshit I'm not going to tolerate.
 
Last edited by a moderator:
I'm not playing any more games with you monstercameron. Always the same old (wrong) claims and the same old arguments. If you're going to play nonsense with semantics at least actually be right. You said there was no software that could run on ARM and not x86. You're wrong. Period. You can't change this after the fact to say this only applied to Pandora's OS (as if Pandora's ability to run Android is merely a novelty, or would be even for a new device), you can't say that "software" actually meant packages - whatever that means - and you can't say that my closed source software doesn't count just because I could recompile it (as if) because the same thing applies to any piece of x86-only software you could mention.


People, you may think I'm losing my cool here but I'm not. I know what I'm typing and I have plenty of time to review before hitting enter so I'm not just fuming at the keys here - I'm sorry if some of you are offended by it but I want it to be totally clear what bullshit I'm not going to tolerate.
dont mangle my words [curse word censored out],

there is no arm exclusive software that the pandora runs that doesnt run on x86 while there are plenty of software packages that only run on x86.
those are the words that started this, read the [curse word censored out] thing bro...

arm exclusive software that the pandora runs

i didnt mention android [which runs on x86 and arm native can run through intels translator] so stop jumping through hoops to disprove me.

you can't say that my closed source software doesn't count just because I could recompile it (as if) because the same thing applies to any piece of x86-only software you could mention
can your code run on x86 or not? can you get access to the source for max payne or grand theft auto or microsoft word?

everytime I think I can tolerate you, you show me how much of a [curse word censored out] you are...

Please mind your language. Personal attacks are not tolerated here.
 
Last edited by a moderator:
You are making it sound like having lots of closed-source software is an advantage. To me it is a disadvantage. Please point me to any x86 software that given the source code cannot be made to work on ARM.
missing the point, point is that there is software that will never natively run on arm, ever.
I wouldn't be so sure about that. "Never ever" is a pretty big statement. While it seems likely that x86 will remain a dominant platform in the future, it's not impossible that at least on the mobile market, x86 becomes irrelevant in a few years. If that happens, I don't see why the big software houses wouldn't at some point compile their stuff for ARM.

Or do you have examples of software that will never ever run on ARM even if ARM would be the only architecture left in the world?
 
You are making it sound like having lots of closed-source software is an advantage. To me it is a disadvantage. Please point me to any x86 software that given the source code cannot be made to work on ARM.
missing the point, point is that there is software that will never natively run on arm, ever.
I wouldn't be so sure about that. "Never ever" is a pretty big statement. While it seems likely that x86 will remain a dominant platform in the future, it's not impossible that at least on the mobile market, x86 becomes irrelevant in a few years. If that happens, I don't see why the big software houses wouldn't at some point compile their stuff for ARM.

Or do you have examples of software that will never ever run on ARM even if ARM would be the only architecture left in the world?
software that is no longer supported, like older games, abandoned projects or software from bankrupt vendors...
 
point me to a list of these arm native closed source software packages running on the pandora...
GINGE - http://repo.openpandora.org/?page=detail&app=package.ginge.notaz - absolutely no way to run that on x86 without emulating ARM CPU

M-HT's statically recompiled games  - http://repo.openpandora.org/?page=all&search=M-HT - can't be used on x86. Sure the originals are x86 DOS games, but you can no longer run them on modern x86s without emulation (in a practical way), and here they run without emulation.

open source, but not really useful on x86:

apkenv - no use of it on x86 at all, at least for things it's currently compatible with

PCSX ReARMed - portions of it, like double resolution renderer don't even have C version of the code. The non-ARM build of ReARMed misses lots of features and needs something like 10x+ processing power to run.

PicoDrive, GPFCE, pandora's SDL, ALSA optimization and others - same as above, you can recompile them but lose a lot of benefit

And what do we have on x86 that potential x86 pandora would run?

There are heaps of software for windows, but it doesn't count because pandora wouldn't be using windows anyway.

ok there is wine, but I can't think of anything I would want to run through wine on a portable device except a few games. Also wine is relying on full OpenGL that x86 SoCs likely won't even have, like it is now with ARM SoCs. It also relies on nvidia heavily, there are lots of problems with wine on AMD graphics hardware, so I really doubt some mobile x86 SoC would work well in reality with wine.

Then we have steam Linux, but again you have the OpenGL problem, same as above.

What else is there?

I guess you'll argue that you would install windows on x86 pandora and run your glorious closed source software, but the thing is, pandora wouldn't come with windows, it's against the fundamental idea of the whole thing. It is even unclear how well those mobile x86 SoCs can run desktop OSes or if they can even run them at all, they'll most likely be tuned for Android and/or win-rt.

software that is no longer supported, like older games, abandoned projects or software from bankrupt vendors...
The thing you're missing that those often don't even run on x86 itself any more in a practical way (see DOS).
 
Last edited by a moderator:
You are making it sound like having lots of closed-source software is an advantage. To me it is a disadvantage. Please point me to any x86 software that given the source code cannot be made to work on ARM.
missing the point, point is that there is software that will never natively run on arm, ever.
I wouldn't be so sure about that. "Never ever" is a pretty big statement. While it seems likely that x86 will remain a dominant platform in the future, it's not impossible that at least on the mobile market, x86 becomes irrelevant in a few years. If that happens, I don't see why the big software houses wouldn't at some point compile their stuff for ARM.

Or do you have examples of software that will never ever run on ARM even if ARM would be the only architecture left in the world?
software that is no longer supported, like older games, abandoned projects or software from bankrupt vendors...
Legacy stuff will work well enough through emulation at some point in time. Also there is always a chance that it gets open sourced when the original vendor is no longer interested in it.
 
Right, well I won't address your attacks, and hopefully won't need to explain to the readers the difference between asking you to stop fucking around and you calling me a sack of shit, etc.

dont mangle my words asshole, 

there is no arm exclusive software that the pandora runs that doesnt run on x86 while there are plenty of software packages that only run on x86.
those are the words that started this, read the fucking thing bro...
Man, I guess I must be stupid or something, because no matter how much I read it I can't understand the difference between you saying "there is no ARM exclusive software that the Pandora runs that doesn't run on x86" and "there is no software that could run on ARM and not x86."
Note that you said ARM exclusive, not Pandora exclusive. Any software that has an ARM binary available and no x86 binary available is ARM exclusive. Although there is also Pandora exclusive sofdtwar that won't run on x86.

i didnt mention android [which runs on x86 and arm native can run through intels translator] so stop jumping through hoops to disprove me.
There is ARM exclusive software that Android runs that doesn't run on x86 devices (Intel's translation layer doesn't have 100% compatibility, Intel themselves admit this - the last public number isn't even especially close, it's about 90%). Pandora runs Android. Therefore, this constitutes as ARM exclusive software that Pandora runs and an x86 device won't.
Really not seeing the argument here.

can your code run on x86 or not? can you get access to the source for max payne or grand theft auto or microsoft word?
It doesn't matter what I can access, it matters what YOU and everyone else can access. As far as you're concerned I'm no different than the authors of Max Payne, Grand Theft Auto, or Microsoft Word. Maybe if those authors entered the conversation you'd address them the same way?
 
Last edited by a moderator:
point me to a list of these arm native closed source software packages running on the pandora...
GINGE - http://repo.openpandora.org/?page=detail&app=package.ginge.notaz - absolutely no way to run that on x86 without emulating ARM CPU

M-HT's statically recompiled games  - http://repo.openpandora.org/?page=all&search=M-HT - can't be used on x86. Sure the originals are x86 DOS games, but you can no longer run them on modern x86s without emulation (in a practical way), and here they run without emulation.

open source, but not really useful on x86:

apkenv - no use of it on x86 at all, at least for things it's currently compatible with

PCSX ReARMed - portions of it, like double resolution renderer don't even have C version of the code. The non-ARM build of ReARMed misses lots of features and needs something like 10x+ processing power to run.

PicoDrive, GPFCE, pandora's SDL, ALSA optimization and others - same as above, you can recompile them but lose a lot of benefit

And what do we have on x86 that potential x86 pandora would run?

There are heaps of software for windows, but it doesn't count because pandora wouldn't be using windows anyway.

ok there is wine, but I can't think of anything I would want to run through wine on a portable device except a few games. Also wine is relying on full OpenGL that x86 SoCs likely won't even have, like it is now with ARM SoCs. It also relies on nvidia heavily, there are lots of problems with wine on AMD graphics hardware, so I really doubt some mobile x86 SoC would work well in reality with wine.

Then we have steam Linux, but again you have the OpenGL problem, same as above.

What else is there?

I guess you'll argue that you would install windows on x86 pandora and run your glorious closed source software, but the thing is, pandora wouldn't come with windows, it's against the fundamental idea of the whole thing. It is even unclear how well those mobile x86 SoCs can run desktop OSes or if they can even run them at all, they'll most likely be tuned for Android and/or win-rt.

software that is no longer supported, like older games, abandoned projects or software from bankrupt vendors...
The thing you're missing that those often don't even run on x86 itself any more in a practical way (see DOS).
ok, there are a handful of pandora os apps that will never run on x86, I was wrong.

I can think of many I would want.

maybe atoms wont have opengl but amd parts do, also baytrail is yet to be determined

steam works fine on amd fglrx drivers, so amd parts should be fine and intel hd graphics too

no where in this thread did I say I would install windows on it, but if this device is about freedom, why should a user excercise it?

they runn them just fine.
 
Right, well I won't address your attacks, and hopefully won't need to explain to the readers the difference between asking you to stop fucking around and you calling me a sack of shit, etc.

dont mangle my words asshole, 

there is no arm exclusive software that the pandora runs that doesnt run on x86 while there are plenty of software packages that only run on x86.
those are the words that started this, read the fucking thing bro...
Man, I guess I must be stupid or something, because no matter how much I read it I can't understand the difference between you saying "there is no ARM exclusive software that the Pandora runs that doesn't run on x86" and "there is no software that could run on ARM and not x86."

Note that you said ARM exclusive, not Pandora exclusive. Any software that has an ARM binary available and no x86 binary available is ARM exclusive. Although there is also Pandora exclusive sofdtwar that won't run on x86.

i didnt mention android [which runs on x86 and arm native can run through intels translator] so stop jumping through hoops to disprove me.
There is ARM exclusive software that Android runs that doesn't run on x86 devices (Intel's translation layer doesn't have 100% compatibility, Intel themselves admit this - the last public number isn't even especially close, it's about 90%). Pandora runs Android. Therefore, this constitutes as ARM exclusive software that Pandora runs and an x86 device won't.


Really not seeing the argument here.



 


can your code run on x86 or not? can you get access to the source for max payne or grand theft auto or microsoft word?
It doesn't matter what I can access, it matters what YOU and everyone else can access. As far as you're concerned I'm no different than the authors of Max Payne, Grand Theft Auto, or Microsoft Word. Maybe if those authors entered the conversation you'd address them the same way?
  • i've come see how your are

  • you claim 90% and you say that breaks my argument but with the assumption that the pandora has 100% compatibility..you may have had to jump through hoops[even though android is its own thing] but who is to say that the 10% incompatible with intels solution isn't the same of the pandora, if we are stretching.

  • lastly the whole conversation is based around bringing legacy pandora soft to x86, we are talking about software that runs on the pandora, does your sw run on the pandora? does it run on x86? but does max payne run on the pandora? does ms word? stop bullshitting, just because it is your code you would with hold it from the pandora community if the hardware were to change that you didn't agree to? then that makes you worst that those corporate assholes that this community hates.
 
You need ONE piece of ARM exclusive software that can run on Pandora and not x86 devices for your claim to be wrong.

One.

That's not jumping through hoops. I guarantee you that software exists and you can find it in Android's library. I will bet you any amount of money you want that this is true. It doesn't matter if there's also software that can run on x86 and not ARM - even on x86 Android devices and not Pandora. That doesn't change that your claim is wrong.

As far as I'm concerned counting Intel's solution is cheating the argument anyway, since it's no different than a proper WINE implementation would be for ARM devices. Of course, such a proper implementation doesn't exist yet.

I won't bother porting DraStic to x86 if desmume ends up running better than it, because performance is the only thing the emulator has going for it. This may or may not be the case, I really don't know. And I may or may not be compelled to spend another several hundred hours writing x86 optimized code, I don't know that either. But either way, I don't have to explain the technical merit to you and frankly I don't care what you think of me over what I do or don't do. But no, I won't boycott x86 devices because I hate x86 or whatever else you think.
 
Last edited by a moderator:
You need ONE piece of ARM exclusive software that can run on Pandora and not x86 devices for your claim to be wrong.


One.


That's not jumping through hoops. I guarantee you that software exists and you can find it in Android's library. I will bet you any amount of money you want that this is true. It doesn't matter if there's also software that can run on x86 and not ARM - even on x86 Android devices and not Pandora. That doesn't change that your claim is wrong.


As far as I'm concerned counting Intel's solution is cheating the argument anyway, since it's no different than a proper WINE implementation would be for ARM devices. Of course, such a proper implementation doesn't exist yet.


I won't bother porting DraStic to x86 if desmume ends up running better than it, because performance is the only thing the emulator has going for it. This may or may not be the case, I really don't know. And I may or may not be compelled to spend another several hundred hours writing x86 optimized code, I don't know that either. But either way, I don't have to explain the technical merit to you and frankly I don't care what you think of me over what I do or don't do. But no, I won't boycott x86 devices because I hate x86 or whatever else you think.
notaz already showed me a  ginge so I guess I was wrong, but this has yet to be proven

There's a fair amount of closed source software on Pandora. You said NO ARM software. Not little. No. Stop fucking around monstercameron.
good for you bro...you must be super flexible with all that stretching...still bringing up android...smh...stretch some more.
 
Last edited by a moderator:
Legacy stuff will work well enough through emulation at some point in time. Also there is always a chance that it gets open sourced when the original vendor is no longer interested in it.
Quick admin request - I noted that you censored out the inappropriate name calling and foul language from Monstercameron's posts.  Please be even handed and do the same to Exophase's last 2 pages of responses.  Thank you.

Back on topic...

There is one big reason for us to consider an X86 processor over an ARM processor - IF the power and performance are 'equal' and heat dissipation can be handled - which is also a potential issue on some ARM SoC instances.  (Note - equal is a near impossible and hypothetical to define 'equal' in this case.)

There ARE some big cases where closed source software is getting released under X86 Linux but not ARM - and much of it is right up our alley.  Linux gaming on X86 IS becoming a reality.  We would be rather foolish to ignore it.

The steam store for Linux now has 12 pages of X86 Linux items at 25 items per page.

http://store.steampowered.com/search/?os=linux#sort_by=&sort_order=ASC&os=linux&page=1

Yes, a good number of those are add-on packs to other titles listed.

Also of note:  http://www.gamesonlinux.com/

These are beyond and in addition to one of my favorite games of all time, Neverwinter Nights.

http://news.softpedia.com/news/HOWTO-Play-Neverwinter-Nights-on-Linux-39615.shtml

In a hypothetical world where TWO otherwise identical devices were created where they were exactly like the existing Pandora in all ways but CPU, one with the ARM CPU from the Galaxy S4 and one with an X86 dual core or more CPU with at least Core 2 duo performance per core and half the battery life and 25% more expensive, I would buy the X86.  And I have absolutely no intentions of running Windows anything on it.

P4 2ghz:  http://www.cpubenchmark.net/cpu.php?cpu=Intel+Pentium+4+2.00GHz = 160 from 54.3W

Core 2 duo:  http://www.cpubenchmark.net/cpu.php?cpu=Intel+Core2+Duo+E4300+%40+1.80GHz = 1060 from 65W

Atom D525:  http://www.cpubenchmark.net/cpu.php?cpu=Intel+Atom+D525+%40+1.80GHz = 694 from 13W

Atom D2700:  http://www.cpubenchmark.net/cpu_lookup.php?cpu=Intel+Atom+D2700+%40+2.13GHz = 841 from 10W

Atom N2600:  http://www.cpubenchmark.net/cpu.php?cpu=Intel+Atom+N2600+%40+1.60GHz&id=613 = 532 from 3.5W

Now, yes most of those have thermal envelopes outside of handheld capabilities.  The D2700 still required 10W and was at a 32nm process. However that N2600 also at 32nm only required 3.5W dissipation.  There still aren't a lot of specs on the next round at 22nm.  Supposedly they're looking at double performance per thermal - which is where I get to my theory:

Theory:  The 22nm Atom should be able to be roughly on-par with a Core 2 duo machine inside of a 3.5W envelope.  There will be a challenge to dissipate 3.5W on a Pandora-type device without resorting to a fan.  I think it might be able to be done using some structural ingenuity to let the heat out the center of the bottom and the leading edge of the device using a heat spreader and passive aluminum to air radiators.

Your opinions likely vary from that, but that does not make my opinion or choice invalid.  The real world could trump me once real numbers start flowing out.
 
Last edited by a moderator:
Back
Top