Tiroth
Member
Registered: Sep 1999
Location: Urbana IL
Posts: 144 |
Most of this has been discussed elsewhere, but...
DragonBallEZ is a 32 bit architecture. It can address 2^32 bits of memory space, or 512MB. However, the DRAM controller built into the Palms can address only 8MB. The way you get around this limitation is through paging.
<technical>
You can access 8MB of memory at a time as an offset from a 32 bit base pointer. This means there is a page switch when you want to access data outside of the 8MB window, since your offset is limited. This incurs a small performance hit, since you need to add some extra code to do this. However, you have to be careful not to cause lots of page swapping; ie sorting across 8MB boundaries using naive algorithms. If you do, your overhead becomes higher than your useful work, and you are basically thrashing.
</technical>
What this means is the storage options are essentially unlimited. Otherwise the 8MB addon wouldn't really do any good! It does imply, though, that work done with extrememly large databases and files (>8MB) will need to have code written with the page swapping limitation in mind. Otherwise this code will perform poorly.
As far as springboards like the Innogear mp3 player, the memory on the springboard does NOT need to be visible to the Visor. In all likelyhood there are two completely seperate memories, processors, and buses. The DragonBallEZ does NOT have the floating point power to decode realtime high bitrate mp3 files. The innogear is essentially just getting control data from the Visor and outputting the song info, control states, etc. This just requires a small memory-mapped I/O window, or something similar, to allow data to be exchanged.
|