Now, the GP2x has for all intents and purposes 2 blocks of memory. The lower 32meg is totally under Linux's control, its where all your malloc/new'd memory comes from, start poking around here and watch your application go crashy pretty damned quickly.
Then, there is an upper 32meg of ram, which is totally uncontrolled by linux, which isnt even cached on the first processor and is only accessed via physical or mapped memory addresses. The space does have some useage made of it however, the two framebuffers live up there, as does a 1meg block for the mpeg decoding control software. However, as far as I know, aside from maybe a few other hardcoded memory addresses the rest is free of the taking.
Now, all the hardware stuff needs its memory addresses in physical locations, I'm sure you can see where I'm going with this; upper ram is the logical location to store textures and sounds and anything else which is purely writen to and not read from (this ram is slow on the main processor).
This means that a storage system of some sort needs to be invented, so that I can store information in that ram, track it and have the processor be able to grab its address and send it where it needs to go.
An important consideration with this is key in what I said about the ram being slow on the main processor. This is because the main processor's cache isnt setup to deal with this ram, however the GP2x has a second processor, which is normally switched off and only used for mpeg decoding control. It's caches are only 1/4 the size of the main cores however once we inject our code to run on it we can setup the caches to work with the higher ram, thus affording us some level of speed up (4K data is still 4K data after all).
This useage of the 2nd processor is also an important consideration in the design of the storage system. The final result needs to be that the primary game code can issue API calls which result in the 2nd processor doing what is required, be it setting up the hardware blitter, playing sounds or whatever.
Right now, I'm considering the OpenGL way of doing things. On the primary CPU you make an API call to setup a texture or sound and a handle is returned to you, you can then upload data to this handle.
Then, when drawing or adding a sound to play back you specifiy this handle as the current one to work with, much like binding a texture in OpenGL.
Its not going to be completely like that, if you recall a while ago I came up with an idea for a RLE map system, so there would be API calls which would allow you to pass an array of data across for that purpose.
All this requires ram useage however, so I need a decent scheme and storage system to allow for quick binding and access of the relivent data. It also needs to take into account the 1meg memory hole where the hardware decoder software lives in higher ram.
Right now, I'm not really sure how I'm going todo this, while the primary CPU's interface can be done in C++ the second CPU looks like it needs to be an assembly job. I'm kinda looking forward to that, I've not done any hardcore assembly in years, however it does mean that going in I'm going to need a VERY clear plan as to what I want todo and how I want todo it.
Fortunatly, I dont have any college tomorrow, so as long as my throat has cleared up I should have a fair chunk of day to work on this... lets hope I do instead of getting sucked into DoD:S or Darwina again [wink]
