slaeshjag
¯\_(ツ)_/¯
^ Which has happened here too. We no longer have coins for the decimals.
How to calculate a price for the Pyra
- Thread starter EvilDragon
- Start date
I still have, somewhere, a few 1 kopek-coins from a visit to Estonia in the spring of -92 (after breaking out of the USSR, but before getting their own currency). Back then, one swedish Krona (roughly £ 0.10 or $0.15) would buy 20 rubles, and one rubel = 100 kopek, so that is the lowest value coin I've ever used. It is also the thinnest and most flimsily made - it's like someone cut a circle in copper foil, and then dropped an embossing stamp clumsily somwhat on top of it.
Thank you ED for this. While I'm still not sure if I'll be able to purchase it, at least now I know why the price is "so high". You have about 300EUR for the unit itself, the rest is all indirect costs, which is totally understandable for a product that will sell on small quantities.
Just for the sake of it, how much would it cost if you were to buy everything from china (this is not what I/we want, just curiosity)?
Edit: You should post the final price according to estimated total sales or sales/month, check the neo900 page, the price drops if there's more people preordering (it didn't work very well)
Just for the sake of it, how much would it cost if you were to buy everything from china (this is not what I/we want, just curiosity)?
Edit: You should post the final price according to estimated total sales or sales/month, check the neo900 page, the price drops if there's more people preordering (it didn't work very well)
Last edited by a moderator:
bzar
A Commando
Do you mean list price or after all the hassle and redoing?
Original parts (not badly cloned ICs) won't be cheaper from China, as distributors often buy them directly from the manufacturer anyways.
What would safe costs is manual labour - but then again, you'd have relatively high shipping costs for a low amount of units, so it wouldn't get much cheaper.
The reason smartphone manufacturers are so cheap is because the often produce stuff in-house (like molds, cases, chips, etc.).
If you're doing everying through third-party companies, this will increase the price as well, as they need to make pay taxes, rent, wages, etc. and want to make profit as well.
So any additional company in a production setup increases the costs quite a bit.
What would safe costs is manual labour - but then again, you'd have relatively high shipping costs for a low amount of units, so it wouldn't get much cheaper.
The reason smartphone manufacturers are so cheap is because the often produce stuff in-house (like molds, cases, chips, etc.).
If you're doing everying through third-party companies, this will increase the price as well, as they need to make pay taxes, rent, wages, etc. and want to make profit as well.
So any additional company in a production setup increases the costs quite a bit.
Caine
Hardcore Member
Seems my 600 ~ 750 Euro estimate wasn't that far off. Good to see it on the bottom end of the range.
Thank you for the more than interesting breakdown Michael.
The price is good. I'll gladly pay 600,- for such a device.
Thank you for the more than interesting breakdown Michael.
The price is good. I'll gladly pay 600,- for such a device.
Don't forget we're planning to do upgradeable modules.
It might very well be we can offer future processor, RAM and storage updates for 100 - 150 EUR.
So you don't need to buy the full device again, but simply buy a new module for the next generation.
It might very well be we can offer future processor, RAM and storage updates for 100 - 150 EUR.
So you don't need to buy the full device again, but simply buy a new module for the next generation.
Caine
Hardcore Member
I'm loving this idea Michael. The Pyra gets better with every post you make
slaeshjag
¯\_(ツ)_/¯
And to think that very concept was shot down by ED as pointless and undesirable just months ago...
This is the best thing ever. I recently wondered why the upgradeable ARM laptop has not arrived yet. I was thinking about a "dumb" notebook with only an HDMI in and a USB port. Very much like the Motorola Atrix LapDock.
And now you come around the corner and do something very similar.
Sure, it probably won't be able to work as a generic HDMI screen with USB input, but it's pretty damn close to what I had in mind.
And now you come around the corner and do something very similar.
Sure, it probably won't be able to work as a generic HDMI screen with USB input, but it's pretty damn close to what I had in mind.
sebt3
homebrew player (P. & C.)
I dont. One of the nicest thing for the pandora at start was that it was a uniq plateform.Test once work on all pandora. Nowadays, the 1st question a dev have to ask support wise is : which pandora model...I'm loving this idea Michael. The Pyra gets better with every post you make
This is going one step further
ptitSeb
Serial Porter
Yep, I agree. It's certaining appeling to have many choice as a marketing side, but for dev., that's the beggining of the Nightmare (plateform fragmentation).I dont. One of the nicest thing for the pandora at start was that it was a uniq plateform.I'm loving this idea Michael. The Pyra gets better with every post you make
Test once work on all pandora. Nowadays, the 1st question a dev have to ask support wise is : which pandora model...
This is going one step further
Caine
Hardcore Member
I don't know. We manage on the PC fairly well. Yes, optimizations might be slightly harder. On the other side people are discussing platform agnostic PNDs (PC/Pandora/Pyra) how would this be different?
Over time we will have different devices anyway, some software will get ported some won't.
sebt3
homebrew player (P. & C.)
I dont know. Who'se that "we" ? Did you support software for the x86 world ?
It's not a matter of optimisation but support. I only have a rebirth. Most my 3D PNDs have issues on a 1ghz depending on the drivers they use. How the hell should I support this ? I dont have the device to test myself. Then come the timing problems etc etc...In the x86 world, the dev could just said : i dont support your GPU. Get a supported one (still very common reply). I cant see myself replying : get a rebirth, your 1ghz stinks...
Day dreaming never made things happen. The only project going this way is the PUR project from Cloudef. I doubt there will be ever a x86 target for this PUR thingy.If he manage to build PND for pandora and one for pyra at the same time, it would be already very nice
I doubt fragmentation is a good thing for a niche market like this one
Last edited by a moderator:
Caine
Hardcore Member
Yes I do. I do agree that more platforms is more work, but how much diversity do we expect?
Then don't support it. If it is open source some other people might pick it up, if it is not then maybe someone else will fill in the gap.
Maybe that is where we differ
Our developer force is spread thin, that's certainly true. There is some validity to your point.
Not really - I said it doesn't work with existing modules and will be hard to do with your own module due to size restrictions.And to think that very concept was shot down by ED as pointless and undesirable just months ago...
But it could work now.
It's not like we're going to release new CPU modules each few months.
It took us a year to get and decide on a current SoC and development will take a lot longer as well.
I expect a new CPU module each few years, instead of a completely new device.
bzar
A Commando
I think this may be something we should take into consideration in the PND changes. If the underlying hardware may change (for example DSP may or may not be there etc) it may be necessary to include several builds of an application to a single PND.
SNESFAN
Retro game fanatic
So with the modularity in mind, could a lesson from android be taken? Android excels at being mostly hardware agnostic (screen size & specific architecture aside from general arm-v7 compatible doesn't really matter)
Would making the SDK for the Pyra focus more on stuff like SDL and API's for the hardware that will remain static, display resolution, button mapping, led's and hardware buttons, etc and stuff like the GPU/CPU have a HAL that will guarantee compatibility in the future? Redesign the PND system to have flags for different hardware setups. These are taken directly from android as it's used today. This sounds more like OS development guys' problem, but I think it would make game and program developers lives insanely easier in the future.
Would making the SDK for the Pyra focus more on stuff like SDL and API's for the hardware that will remain static, display resolution, button mapping, led's and hardware buttons, etc and stuff like the GPU/CPU have a HAL that will guarantee compatibility in the future? Redesign the PND system to have flags for different hardware setups. These are taken directly from android as it's used today. This sounds more like OS development guys' problem, but I think it would make game and program developers lives insanely easier in the future.
Last edited by a moderator:
Hồng Thất Công
Đả Cẩu Bổng Pháp
Shut up and take my money!
K
klapse
Guest
I am going to disagree with B-zaR and SNESFAN here.
If there are multiple Pyra SoCs, most developers won't have access to all of them. For example, a developer will be able to provide an OMAP build, but not an x86 build of a PND.
The only realistic solution to binary-incompatible versions of the Pyra would be to set-op seperate PND repositories for each, so that different people can be maintainers of different package versions.
If there are multiple Pyra SoCs, most developers won't have access to all of them. For example, a developer will be able to provide an OMAP build, but not an x86 build of a PND.
The only realistic solution to binary-incompatible versions of the Pyra would be to set-op seperate PND repositories for each, so that different people can be maintainers of different package versions.
