sam fisher said:
Epicentre, it's just a MMSP2+ as the base. They have hyped it up to sound around the level of the i.mx31 but I think that the freescale SoC is just too expensive to use.
"Epicentre"?
I researched into the MMSP2+ quite some time ago. Unfortunately it is a very primitive chip, and its inclusion in such a device would be a critical error. MagicEyes' demonstration of their inability to adhere to ARM reference standard typically cripples their designs. As a prime example, lack of direct memory access between CPU/Blitter/RAM in the MMSP2, resulting in comparatively poor blitting performance, a proprietary and limited multiprocessor interface, lack of implementation of a secondary memory mapper unit, etc. The MMSP2+ is also built with a primitive 130nm process that results in inefficient operation and inordinately heavy power consumption.
In addition, this model shows many of the design compromises of the MMSP2. Example: The coprocessor is a ARM946E-S part, which is scaled-down CPU much like the ARM940T. Again, it lacks an MMU which will make multiprocessor apps cumbersome and difficult to develop. Neither CPU contains an FPU, further limiting the capabilities of a device utilizing this architecture. The problems will be compounded if the system utilizes a shared memory bank for both CPUs, and the 2D/3D accelerator blocks such as the GP2X, resulting in wasted CPU time shuffling data about the varying components. This issue could be circumvented with full DMA access from all components to Main RAM, however I strongly doubt MagicEyes has implemented this. The previous iteration of the hardware, MMSP2, did not even implement DMA access between the SD card interface and Main RAM, resulting in the CPU slowing to 1% of its usual performance when any media was accessed.
While the MMSP2+ is a superior part to the MMSP2, its use would cripple the potential of the device and ensure a short lifespan.
KeyBoard Epicenter:
(sorry, couldn't resist)
The MMSP2+ has two separate 16-bit DDR RAM interfaces, each with their own control, data and address lines. Now, I only have the same datasheet available online that you do, but what I hope to be true is that each physical interface can be mapped/controlled separately by each CPU core. This could mean much faster graphics and sound processing by separating tasks within the cores (lets hope they have fixed all of their DMA issues).
I do agree with everything else you have said and people should realize, that while possibly over critical for the forum it is posted in, the facts are true. Still, with this new setup, this chip should offer so much better performance than the MMSP2. I never bothered with the GP2X because it was a very limited device, but this "new" chip should be much more promising.
My other concern is the bandwidth needed to update an 800x480x32b display. That is usually a bottleneck with these fully integrated SOC's. With 3D processing enabled, one of the RAM banks (64MB) could be completely tied up in the video subsystem (frame buffer, texture data, Z buffer?) and code could run very slowly if placed here (which would then make one of the cores perform very badly as far as computational throughput goes). Since I have no experience using the chip, I look forward to hearing from someone like Squidge who has written code for it. I can't wait until the developers feel free to talk about the design.