Intel X5-Z8300


I guess it's a moot point talking about what SOC could be used in a future upgrade SOC board , as that's years away.   By then we wouldn't be considering this SOC , you can safely bet on that.

On a different note, the other month I bought an 8" tablet with the Z3735F SOC in it.  It dual boots Window 8.1 (Real not RT) and Android 4.4. It also has 2GB memory, 32GB storage, IPS 720p screen, uSD slot etc.   All  for the princely sum of $84 which included delivery from china to Australia.   First of , that price is ridiculous and I didn't expect really anything near good.  What I got was a total surprise.  The thing is awesome.  The Windows games  that it could play, was beyond surprising. And the speed it runs at was also very surprising.   Absolutely ridiculous what you can get these days for not much.   The only thing I could fault it on was its cameras which are rubbish.  The Z8000's are the successor to these and the others of its gen, I can only imagine what they could do, so I'll be looking to see what tablets come out with it.  Update: Looks like tablets with the X5-Z8500 are already hitting the market ->http://liliputing.com/2015/08/teclast-x98-pro-9-7-inch-windows-10-tablet-with-cherry-trail.html
 
Last edited by a moderator:
With the reality of what sourcing SoCs has become for a project like this choosing an Atom SoC is a possibility that ED is going may have to be open to down the road. As they say, beggars can't be choosers. I doubt there will be a viable solution from TI next time around and I feel like OMAP5 is already a less than ideal option.

My big misgiving isn't really because I think Atom SoCs are going to be worse, on the contrary they have a lot of potential to be very competitive, but there's going to be a big software compatibility headache. I mean, there are going to be headaches with any new SoC but the different ISA will pose a larger one.
 
Yes, but linux x86 software isn't usually designed to be 'portable' i.e. to reside on a temporarily mounted FS. Also, a number of games we have on Pandora as PNDs only really exist as source code releases on other platforms - binary packaging of games outside of Steam etc. is kind of patchy on x86.

Actually, perhaps Linux Steam creates portable installs of games, I don't know.  I doubt it installs them to /usr/bin and /usr/share etc. though, so perhaps it does.  Still, x86 Linux means you compile a lot of your own games if you don't like Steam.  Although you might get access to the prebuilt binary games that exist for x86 Linux, like the HumbleIndieBundle games and anything bought on GoG, although fulfilling dependencies to get and keeping those running can be a potential crapshoot.
 
At least on my system, steam installs games in $HOME/.local/share/Steam with a link at $HOME/.steam/steam
 
 
Last edited by a moderator:
Levi said:
Yes, but linux x86 software isn't usually designed to be 'portable' i.e. to reside on a temporarily mounted FS. ...

...

those running can be a potential crapshoot.
Click to expand...
+what we've learned from the Pandora:

Prebuilt binaries created for keyboard+mouse combo simply Do Not Work That Well.

Ultima Underworlds, System Shock 1 - both theoretically playable on the Pandora as far as speed goes... But not really because even the slow going hack-hack-hack realtime action in UW1 is impossible with nubs. Would be fine with a proper engine port.

Same even with some point'n click adventures in which you need to react quickly!

This is an issue for many, many games upto the Age Of The XBox controller
 
I keep forgetting about how Steam plays into this, despite the fact that these days I've been able to run most games I'm interested in on my Linux desktop.

I would argue that Linux Steam compatibility on Pyra or a similar device would be an absolutely huge advantage.
 
Levi said:
Yes, but linux x86 software isn't usually designed to be 'portable' i.e. to reside on a temporarily mounted FS.
Click to expand...
Why not? When you run make/make install, you can override the path it gets "installed" into. Put that under "/mnt/packager" or something, then just mount your .PyraBox file there, and it'll run as though it's installed.
Also, then, does the source code explicitly seperate "ARM" and "x86" architectures so that the ARM ones can be 'portable'? And if it does, well, just remove the #IF so it compiles the x86 as portable too?

Levi said:
Also, a number of games we have on Pandora as PNDs only really exist as source code releases on other platforms - binary packaging of games outside of Steam etc. is kind of patchy on x86
Click to expand...
But if the source is available, what's the problem? Binaries can be built. You'd just need somebody like ptitSeb to come along and compile everything and package it up.
 
Well, the argument as I was responding to it was that x86 would get us more software because we wouldn't have to rely on a few porters to port all our games for us.  I guess that's not a valid assumption, but on all the x86 linuxes I've used to date, the availability of games on the official repositories is kind of lacking.  If the community here got behind the x86 board, then we might well be able to replicate something like the Pandora's PND (or the Pyra's DBP) files on that architecture.

That would be a necessary step as I see it though.  Without some sort of PND system, stuff you build on Linux isn't automatically portable - you can build it to alternate locations, but loading runtime libs it's built that aren't in /usr/lib or /lib will require some hacking of the source code, as Pandora devs do to get code to run from inside a PND.  Or perhaps users could just set some environment variables, I dunno (it's not something I've needed to do so far).

But I guess x86 with a decent GPU would mean porters don't need to hack in glshim and do quite so much work to make certain things run well on constrained hardware.  But that's one thing I like about the Pandora and this scene; devs have to squeeze every last cycle out of things to get them to run.  That sort of effort impresses me.
 
Adding multi-arch support to dbp (multiple achitectures in the same package) would be no more than an afternoon of work, and could probably be done without breaking anything old. If anything would actually use it on x86 is a completely different question…
 
Last edited by a moderator:
For what it's worth I do seem to recall that several months ago someone came to the forums to get more info on the PND system because they wanted to use it on x86 as portable software platform.  I don't know if they ever reported back on their progress with that,  but it does show that there is interest in such a thing in the wider community of Linux users.   Portable software does have it's niche,  so perhaps if we were using such a system on x86 there would be some crossover.

-Neelix
 
If it means that one could buy an hypothetical x86 PCB for the Pyra, and keep all of his software without the need to redownload them all, then that would be great, just in case.

I suppose the kernel can't be made the same way, but it would still be great if you just had to recover your files after a clean install.
 
Why do we need ED's support? after the hardware plans are made public everyone can make a new pcb. If ED is not too much into money this would be in his mind I guess.
 
Urben said:
Why do we need ED's support? after the hardware plans are made public everyone can make a new pcb. If ED is not too much into money this would be in his mind I guess.
Click to expand...
It takes a platform to take off, not just a design. A bunch of new PCBs being released is going to work badly if all of them need unique software (and at the very least they'd need a new kernel) If a third party made a new PCB then ED would really need to endorse it for it to have any hope of taking off without having horribly fragmented supported.
 
That being said, there's no reason someone with the desire, knowledge, money, and the access to resources can't start producing one with ED's official blessing, except that the intersection of those four requirements is going to be very narrow.
 
I know it is unlikely, but knocking on someone's else door other than ED's might result in very in more Pyra products and therefor more users.
 
Kev2442 said:
If it means that one could buy an hypothetical x86 PCB for the Pyra, and keep all of his software without the need to redownload them all, then that would be great, just in case.

I suppose the kernel can't be made the same way, but it would still be great if you just had to recover your files after a clean install.
Click to expand...
I'd be generally against loading the packages with foreign builds I don't plan to use; especially ginormous x86 binaries added to my svelte ARM builds.  But that doesn't mean DBPs shouldn't be able to contain different builds at the same time.
 
x86 builds would probably not inflate the package size much for most packages (usually the data is the big space hog in large packages.) It would however be a burden for all maintainers involved to build for platforms that nobody uses, so it makes no sense to start making such builds if the dbp system isn't used on other platforms. So it would still need a re-download if anybody would decide to make multiarch packages, but at least they can be shared between platforms without becoming a complete mess to manage manually.
 
You must log in or register to reply here.
Back
Top