What would the world and his dog think if P2 used an x86 SOC? (but not mini SD) ;)

[monstercameron]

what is to stop you from building a database of all the programs that would work?


what is wrong with tweaking?


why limit yourself to things specifically tailored to a device when you can explore the app ecosystem, like apple v. android.

i hope you do realize your questioning comes up as very rude and immature.
Ed is agruing that pandora being a very personal system to him, he'd not willingly say goodbye to everything pandora was.


Asking for ed to build a database that has everything is like asking a man to collect each piece of different snow flakes.


Even those mega global companies can't do that, then how could ed?


We have built a decent sized database over the years for arm, why would we toss it away for no other reason than chasing the trend blindly?


There is no driving force to make p2 x86. arm is still going strong and the community is better than ever. Switching to x86 now is like giving up a nicely paying job in the off chance a better one would be at the corner.


It's not even classified as gamble because there is no big reward waiting ahead for the potential risk ed's taking.

how so? I don't get it challenging someones assertion is rude and immature, then there are so many rude immature folks on these forums.

 

[MrConfusion]

Unfortunately, the intention failed from the get go.

Problem is most people associate x86 with "Windows compatible", which is, of course, not true.


People who are not devs probably don't understand the dev viewpoints... yet people still want to participate .

Also, the views were already summarized well by _wb_  and others (even in my own rambling first post to this thread).

As for the Windows part: To build a PC you need more than just a X86 SOC? (Or at least you used to... stuff like BIOS etc. I haven't really had any need for years and years to follow this area though, so it is possible everything now has a FreeAndOpen option)

Users who have no dev experience should really take part in this discussion not from the standpoint that you would then automatically be able to boot Windows 8, but rather from the standpoint that an x86 Pandora would look and feel like exactly the current Pandora, only its running on X86?

I don't see any point in a Pandora running Windows. Really, none at all. Get the old Vaio UMPC for that (and see how terrible usability was even with that!!!).

I do see a point in making X86 code run faster within emulations, when it can run natively, because I would be a heavy user of that feature. But  then again I don't know whether more speed in that area is even needed. For example, DOSBox, quite often MUNT is relatively speaking the biggest CPU hog these days for me, not the game itself... I suspect the next ARM chip in P2 will take the Pandora to the realm where CPU emulation is not the bottleneck, but for PC rather we'll be wondering how to simulate 3dfx hardware?

 

[Klumpen]

I want a Mini-SD slot in the P2.

 

[Linux-SWAT]

Nah !

I want a real one !

 

[Binky]

If the Pandora's Successor were to be focused around Linux, FOSS and all that, then architecture doesn't make much difference - you trade the existing pnd library for the larger x86 repos out there. New devs can easily compile to either.

If the PS were focussed around Android, then ARM is probably better, since a good number of apps depend on low-level, ARM-specific stuff.

If the PS were built around Windows, you alienate the entire userbase, and risk all software being as bad as the wifi/nub/battery control firmware.

Installing Windows (if it didn't ship with it) on a weird, non-standard, non-official device probably requires expertise generally only found in Linux users.

In all three cases, power consumption and efficiency are vital and we are yet to see convincing data to show that x86 is as good or better than ARM in this regard.

 

[Linux-SWAT]

Don't you see Intel benchmarks ? You'll be surprised to see that they show Intel is better !

 

[notaz]

From the point of view of devs, it does not matter what the architecture is, unless they are coding in assembly. We have compilers that produce machine code for us, changing the platform is basically just changing the target parameters of gcc. So it doesn't matter.

Unless you want to do coding in assembly. Then of course the architecture matters, and it matters a lot. And then x86 is an ugly beast (cf. notaz' post) while ARM is quite nice to work with.

It's not only assembly, somebody will also have to bring the kernel and drivers up on that thing. Surely Intel will provide something for the base SoC, but some custom stuff will need to be done too. While working with kernel you sometimes need to dig into low level architecture things. The same is also true when you need to do some more serious debugging on userspace too, when you can't get usable stacktrace and so on.

So in other words it's important for firmware development too. Maybe it all doesn't matter though, ED could get some company to do it for him when I retire.

I do see a point in making X86 code run faster within emulations, when it can run natively, because I would be a heavy user of that feature.

That's not really true, unless the CPU supports virtualization and you use it for that, and for things like wine. Things like dosbox have to emulate everything the same way it has to do on ARM.

 

[_jr_]

A P2 without notaz isn't a P2. I wouldn't want such a thing.

 

[EssoAir]

I dont like Windows its self, but I do like the software available for it

 

[sebt3]

it sad to see 4 pages of reply from non-dev on a thread that was targetting dev' only.

Is there something not clear enough for you in the topic title ?

So far we've only see Notaz repling here

I bet no other dev will reply because of all the drama in this thread

 

[MrConfusion]

I do see a point in making X86 code run faster within emulations, when it can run natively, because I would be a heavy user of that feature.

That's not really true, unless the CPU supports virtualization and you use it for that, and for things like wine. Things like dosbox have to emulate everything the same way it has to do on ARM.

Wine, QEMU if it supports the KQEMU stuff still (don't know if it does, haven't followed QEMU for a while...)... and that's all folks, yes...

Virtualization is not strictly neccessary, VMWare was running VM binaries native whenever it was able to do so from the start, and back then the virtualization extensions did not yet exist. So, in theory DOSBox could probably be tuned similarly, but it would be an immense amount of work for fairly little benefit... especially considering the "target speed" for emulation, which is sufficient without this trickery.

Also, Linux already had DOSEmu, which I used successfully already way back in 90something to run Ultima VII at practically native speed in Linux (with Roland LAPC-1 support even, because dosemu had interrupts and I/O ports!! yay!! But no DMA, so no SB :-(). Natively, but not stable, though :-D.

However, I'd like to point out that I'm not for x86 SOC. My real gut feeling is this discussion is redundant, because Intel fails to deliver again and the CPU you're talking about is yet another failed attempt. But even it if weren't, I'd still prefer ARM. Why? Well, I don't code these days I've switched jobs from active coding, don't have enough free time and suffer from RSI, so I can't label myself a developer in any sense of the word these days. But if I were one, ARM would be the hip thing. And if people asked me how I'd like to tackle the problem of increasing x86 emu speed, I'd find it a lot more fun to see what I could do with something like a fairly generic DSP instead of brute force X86 CPU power... That's where the developer fun factor comes in and unfortunately people who don't code, will just never get it :-(.

 

[Binky]

it sad to see 4 pages of reply from non-dev on a thread that was targetting dev' only.


Is there something not clear enough for you in the topic title ?


So far we've only see Notaz repling here


I bet no other dev will reply because of all the drama in this thread

Of course the PNDs on the repo would not work with x86 - they contain binaries for ARM.

But it wouldn't be a huge problem to have a new repo for a Pandora successor.

Most Pandora devs code in programming languages (not assembler), or port programs coded in programming languages. Switching to x86 is not a lot of effort, it's basically just a recompile. Unless you do assembler optimization: that includes a lot of notaz' and Exophase's work - their NEON optimized emulators would need a complete rewrite if the target platform is no longer ARM.

Performance, cost, power consumption (perf/Watt), availability of FOSS drivers, availability of the SoC (in low quantities): those are important to me. If Bay Trail can be competitive in all of those, then why not have it. But I need to see solid benchmark data on performance and power consumption first.

 

[CrazyIvan]

The general idea behind all these pages of text is that people here need some specific data about power consumption and performance of atom SoC from independent testers (preferably forum members) that can't be obtained until atom phones hit the market and that won't happen until at least the next spring (2014) because atom SoCs for phones which can be used for a pocket-sized device (SoCs that were announced some time ago are for tablets with tablet-level power consumption (2 to 4 w) ) will be available (probably) at the beginning of the next year.

So until then the discussion of a theoretical possibility of putting atom inside a pandora successor is pointless unless someone working at intel decides to share some data and testing SoCs with ED.

But the prospects of scouting a good ARM SoC are pretty grim - as far as I understood from another pandora 2 SoC thread, Samsung doesn't want to sell SoCs in small quantities and Qualcomm thinks the same. With MediaTek's non-existent linux support the only good alternative is some Allwinnner SoC which is used by Vivaldi (KDE Plasma Active tablet) developers.

So if Intel decides to sell atom SoCs in low volume it could be a great option for P2 but there is no information about that and until that is known there is nothing to discuss

And please don't discuss microservers here, pandora is a portable linux gaming machine and as such it needs a GPU that works good under linux and it shouldn't be a nightmare to add support for periphery devices like wi-fi, nubs and probably some gps/accelerometers/whatever and actively maintain it

 

[God Ginrai]

I want a Mini-SD slot in the P2.

 This is completely unrelated to the topic. Besides, SD is better. You can always adapt up to it from Mini and Micro SD. You can't adapt down from an SD card to a Mini SD.

Well, in my opinion, backwards compatibility is a very important thing.

Being able to use the current PNDs would be awesome.

There would be NO fullspeed NDS Emulator (unless someone codes one for x86), and if you just have a random x86 OS on there, it wouldn't be anything special.

It would just be "another PC", in my opinion.

Yes, you'd have sooo many games, but you would have no idea how well they would run. You need to tweak the settings, configure inputs, etc. for most games.

 QFT

It's the same thread over and over and over... Mods, this is boring, and it wastes disk space.

 That's a pretty cheeky statement from the guy who has made multiple posts about a completely offtopic subject. At least these "same things" people are saying are related to x86 and ARM.

it sad to see 4 pages of reply from non-dev on a thread that was targetting dev' only.

Is there something not clear enough for you in the topic title ?

So far we've only see Notaz repling here

I bet no other dev will reply because of all the drama in this thread

In my defense... I am a dev. I just haven't done anything for the Pandora. (I've been meaning to change that, tho')

-God Ginrai

 

[Grench]

Well, in my opinion, backwards compatibility is a very important thing.

Being able to use the current PNDs would be awesome.

There would be NO fullspeed NDS Emulator (unless someone codes one for x86), and if you just have a random x86 OS on there, it wouldn't be anything special.

It would just be "another PC", in my opinion.

Yes, you'd have sooo many games, but you would have no idea how well they would run. You need to tweak the settings, configure inputs, etc. for most games.

That's exactly why I never hopped from C64 and Amiga to video game consoles.

I want to start a game and play. Not tweak settings, configure stuff, etc.

That's why I stopped playing games on the PC back then.

On the Pandora, I know when I download a PND, it will work.

Even if we use another ARM CPU - it would likely be several generations removed from the one used in the Pandora.  Multiple cores, different I/O paths, different I/O hardware, different video capabilities and resolutions.  Wouldn't we still need to rebuild most of the PND files to take that into account?  I.e. would it really be 100% backwards compatible?

No fullspeed NDS emulator...  I don't use NDS, though I think Exophase's work making that happen was amazing.  I understand that this emulator addresses the Pandora at a hardware level to make it work.  Would that necessarily translate directly to a current generation ARM platform?  Regardless of the SoC used, the hardware will/should be capable of performing several multiples faster than the existing Pandora.  Anything that was heavily configured for the current Pandora, though, would likely have to be updated/modified/changed to reflect whatever the new hardware is, right?

Would it really just be, "another PC"?  Starting with the interests of a gaming community to get solid working controls, extending hardware to fit general computer users, having great headphone audio hardware, building it with Linux in mind - and shipping with Linux.  The Pandora wasn't just a gaming handheld - it wasn't a business PC or a media player either.  It was/is a magical combination of the three.  If a Pandora successor follows those same principles, X86 or ARM shouldn't matter in how that community blending works.

Tweaking settings - and having that all pre-done in a PND for the end user.  Nothing in the CPU architecture dictates that having the PND system would have to change.  Having a pre-compiled, pre-tweaked PND version specific to our hardware of emulators and home brew games doesn't have to end.

There has been great work done with the existing Pandora to extend it to Ubuntu, Debian, Slackware, Android, even Windows - there is clearly interest in alternative operating systems beyond Angstrom.  With the advancements in hardware, do you really see a need to ship a future handheld with something other than a fully loaded mainstream OS release?

"I want to start a game and play.  Not tweak settings, configure stuff, etc."  

The PND system has been great for this - each program pre-set specifically for the hardware.  I don't see any reason for that to change.  In fact, I could see having PND files that are just the configuration settings for commercial games & engines - which we already have a parallel to with things like Quake - the PND includes the system compatibility settings and in current case an ARM executable, but the actual package files have to be copied in by the end user.

Picture a steam.pnd - initiates a download of the Steam setup and installation engine.  Use Steam to download half-life/etc.  Then a 2nd PND file halflife.pnd that you can use to launch half life with controls and video all configured for the console.  The PND simply overrides the stock .cfg file and launches the game using the proper settings for the unit.

Yes, if the end user wants a program that doesn't have a PND yet, they will need to tweak settings and controls - and they'll have a reason to capture those settings and create a launcher PND to distribute their controls and settings to other users.  In this case the PND won't include the source software - but would instead be a very fancy program launcher icon.

X86 has a lot of baggage associated with it.  It may not be the right solution for the next generation of Pandora-esque device.  I suspect, though, that a lot of the reasons stated not to use something like the new Z3770 are centered around issues that will exist, to some degree or another, no matter which SoC the new platform is based on.

This article does a nice job of comparing the Z3770 to other relatively recent SoC options.

http://us.hardware.info/reviews/4792/intel-atom-z3770-lbay-trailr-review-strong-competition-for-arm

I'm not saying that it's the SoC we have to use - just that it seems to meet all of the criteria as I understand them.  Please explore it seriously as an option among many?

Thank you.

 

[Binky]

I want a Mini-SD slot in the P2.

 
This is completely unrelated to the topic. Besides, SD is better. You can always adapt up to it from Mini and Micro SD. You can't adapt down from an SD card to a Mini SD.

It's an old joke.

Craig (and a few others) were going on about how full-size-SDXC was old-fashioned, a waste of space, and generally rubbish, so the P2 should be like most smartphones and only have one micro-SDXC slot.

Others claimed that full-size cards were more convenient, faster, more reliable, cheaper, higher capacity, and so fantastic in every possibly way that the P2 should have three fullSDXC slots.

Linux-SWAT thought this was silly, and started saying the miniSD was the best (when it blatantly isn't) for comic effect.

Now whenever anyone starts making repeated, unrealistic suggestions (x86_64 is a good choice for a pocket computer) he talks of miniSD to remind us of the ridiculousness of the debate.

 

[sebt3]

would it really be 100% backwards compatible?

Let's say 99.9%. I only know one PND that use x11 drectly and not sdl, that would be the only culprit I know.

Would that necessarily translate directly to a current generation ARM platform?

Drastic run on the most recent soc under android, so no code change requiered... So yup...
the rest is just bs, boring stuff

 

[God Ginrai]

 

[Linux-SWAT]

Mini-SD is totally on-topic as it's handled by the SoC.

 

[monstercameron]

I feel like this is the only reason you want x86. Steam is great, but do we really need it? Not to mention, there's no way that Valve is going to stay away from mobile for long. I wouldn't be surprised if the Steam android app started getting games in the near future. Another question is, has anyone even thought about the possibility that we could approach Valve to get Steam on ARM? What if EvilDragon went up to Valve and said "Hey Valve, I'm making a gaming handheld. I want Steam on it. We're planning to encourage indies to develop for our system, and we believe that Steam may help to do so." I'm not saying that Valve would agree, but it's certainly an idea to consider. Imagine if we had Steam on the system not because we went x86, but because Valve was supporting our console. The ramifications would be huge

 
seriously.