Pyra Hardware specifications

[Binky]

I don't want to start such a war, but the fact that CISC systems are more faster in therms of calculations follows logic..... The only reason why RISC is used is the licence, welcome in the world of economics....  A few month a go I red that the AMD/Intel x86 systems are more power efficient because they are calculating much faster as there ARM counterparts, so they can compensate the bigger power drain....

x86 systems (and CISC in general) do more in every clock cycle than RISC. However, ARM is a clean, simpler architecture, less encumbered by historical considerations than x86.

In addition, the focus with x86 has, until recently, been raw computing power - leading to such horrors as the pentium D.

ARM has seen far more use in low-power, portable and embedded devices, and is designed with those in mind.

It takes less energy to perform an operation on an ARM processor than an x86, but you have to do more of them for any given calculation.

Since a computer does little mechanical or chemical work, efficiency doesn't really make sense. What you can talk about though is the energy required to perform a given calculation.

A good SOC will have a low energy:computations ratio across a whole range of CPU loads.

 

[_wb_]

Is the distinction between RISC and CISC even still relevant today? I mean, isn't a modern x86 basically a RISC processor with a decoder that supports some syntactic sugar for macro-instructions that do things like combining arithmetic and memory operations into one instruction?

For me, the instruction set is not important -- I don't write assembly, I don't write compiler backends, I'm not particularly interested in running legacy closed-source software natively. What counts is performance, performance per Watt, and performance per $.

 

[Binky]

Is the distinction between RISC and CISC even still relevant today?

Its important if people are going to start talking about performance per nominal clock cycle.

Other things being equivalent, a dual-core x86 CPU with 3.6GHz written on the front is more than three times better than a dual-core ARM SOC labelled 1.2GHz

(until you have electrical power limitations, or thermal issues, or pre-compiled software)

 

[_wb_]

Is the distinction between RISC and CISC even still relevant today?

Its important if people are going to start talking about performance per nominal clock cycle.

Other things being equivalent, a dual-core x86 CPU with 3.6GHz written on the front is more than three times better than a dual-core ARM SOC labelled 1.2GHz

(until you have electrical power limitations, or thermal issues, or pre-compiled software)

Well that depends on cycles per instruction and pipelining and so on. A CPU typically does not execute exactly one instruction per clock cycle. It can be more than one, and it can be less than one. More complicated instructions can take more cycles.

The Pandora's Cortex-A8 gets 2 DMIPS/MHz, a Cortex-A9 gets 2.5, a Cortex-A15 gets 3.5 to 4 DMIPS/MHz.

In the x86 world: an Atom Z3370 (Bay Trail) gets about 2.55 DMIPS/MHz (if this source is correct), a Core i7 4770k gets 8.0, a Core 2 Extreme  QX9770 got 4.6, a Pentium III got 3.0, a Pentium got 1.88, a i486DX2 got 0.388, the 8088 got 0.075 (0.75 MIPS at 10MHz) while the Commodore 64's MOS 6502 got 0.43 (0.43 MIPS at 1MHz).

So you can't just say that in general, x86 always delivers more punch per MHz. Often it does, but not necessarily.  The differences between different contemporary models of x86 processors (e.g. cheapest Atom vs most expensive i7) are larger than the differences between cutting-edge mobile x86 and cutting-edge mobile ARM.

 

[Binky]

Gah. This is ridiculous.

I'm using lame simplifications to justify lame simplifications used to argue against blatantly wrong simplistic statements - and now everyone else is unnecessarily correcting those simplifications.

Maybe we should get back to the topic in the thread title?

 

[Marijus_Pikelis]

This is simply amazing. Dreamcast in fullspeed? It's one of the best consoles ever in my opinion for what it was and how short of a lifespan it had. Shenmue on the go is a dream come true. Finally, Pyra pretty much does all what I always dreamed of.

I really have to thank my friend for letting me know about Pandora back in 2008, but issues, production delays and no flawless Dreamcast emulation had me waiting, therefore I was following the development, but never joined the boards, until now that I decided to do so. And Pyra seems to improve in many areas. I believe in this project and EvilDragon, because he's such a cool and nice guy.

 

[Grench]

• Storage
  - 2x SDXC (external) [4]
  
  
  - 1x MicroSDHC (internal)
  
  
  - 1x NAND (internal, size currently unkown)
  
  
  Note: internal storage units can only be used exclusivly => either a MicroSDCard is useable or the NAND
  

Has there been any news or decisions on the NAND part chosen or the size or speed?

Looking through the SoC specs, it's theoretically possible for the NAND to be 40% faster than the microSD slot.  However there are microSD cards out now that could nearly max out the theoretical limits of the microSD side.

128GB 95MB/sec card for $120.

http://www.amazon.com/Lexar-High-Performance-microSDXC-Memory-LSDMI128BBNL633R/dp/B00O1M21H8

16GB 95MB/sec card for $20.

http://www.amazon.com/Lexar-High-Performance-MicroSDHC-Memory-LSDMI16GBBNL633R/dp/B00IF4OC1G

So I'm curious about the planned NAND.  Will it be faster than the microSD port speed?

 

[Silent-Hunter]

Well I plan to use a MicroSD card regardless.

 

[fusion_power]

I thought the internal Micro SD IS the "NAND".   h34r:

 

[TrashyMG]

I thought the internal Micro SD IS the "NAND".   h34r:

Last I knew GTA04 said that you will be able to toggle via a switch to use the MicroSD or the internal eMMC NAND. But not both at the same time.

 

[Silent-Hunter]

That sounds like a good idea to me. But how will you copy the eMMC to the MicroSd then?

 

[slaeshjag]

By using it in an µSD->fullSD adapter in one of the external slots?

 

[Silent-Hunter]

Good point.

 

[rygD]

I thought the internal Micro SD IS the "NAND".   h34r:

Last I knew GTA04 said that you will be able to toggle via a switch to use the MicroSD or the internal eMMC NAND. But not both at the same time.

I must have missed this.  Can you point us toward this statement?  I thought it was still undecided and we were only going to get one or the other on the board, not have a choice.  Maybe I should pay attention.

 

[TrashyMG]

Not the only mention of it, but this is the first one I found.

If we use the OMAP5, you can then either use the eMMC together with both full sized SD Card slots or the MicroSD Slot with both full sized SD Card slots.

If a future SoC supports more MMC devices, you will be able to use all the devices at the same time.  

This should be a solution perfect for everyone. You can either boot from eMMC, the internal MicroSD Card or the Full Sized SD Card slot (like on the Pandora).  

And in case your eMMC breaks (never seen that on the Pandora, but you never know), then simply put a MicroSD Card in and switch to that slot.  

I hope you're happy with that solution

 
http://boards.openpandora.org/topic/15747-news-from-the-embedded-world//URL]

 

[rygD]

Thanks a bunch.

 

[DrHAX]

Could this also mean  you could experiment with different OS's by flashing them to the mirco-sd card?

 

[Silent-Hunter]

Probably!

 

[Lao Rebel]

i would like an ethernet port please!!!

 

[TrashyMG]

i would like an ethernet port please!!!

Design is final...


wait for the docking port.