[SDL] Porting SDL to new hardware

[Ryan C. Gordon]

>> sorry i dont have the answer to your question, but i though sdl was on
>> everything.  what hardware did you want to port to ?
> 
> I have an embedded processor I need to get it working on.

First things first: SDL probably expects to have at least a 32-bit 
linear address space. I don't know if it would survive on something like 
the old MS-DOS 16-bit segmented nastiness, but no one has ever tried to 
my knowledge. The library is 32 and 64-bit clean for sure, though...I 
just wanted to throw that out there, in case "embedded" means "really 
really underpowered."

If your platform is running some sort of Unix system (embedded Linux is 
getting popular nowadays), then chances are you can just push SDL 
through a cross compiler and it'll work out of the box...there are C 
fallbacks for everything that has CPU-specific assembly code, so you 
should be able to at least bootstrap it, presuming that there's a video 
API that already works with the system (like the fbcon driver in Linux, 
etc).

If not, you can disable entire subsystems you don't need (like the 
joysticks, CD-ROM, etc) so they won't get compiled in at all. In these 
cases, you just don't need to worry about them.

If there isn't a video driver for your platform, you can take a look at 
the large variety of targets in the src/video directory. If there isn't 
one that will work on your platform, then one will probably work _like_ 
your platform and thus be a decent starting point.

At the most basic level, you need to supply a framebuffer where the 
application can write pixels and tell SDL what format you expect those 
pixels to be in, and be able to move data from there to the screen on 
request...if there's a discrepancy, SDL can convert between the 
application and your video target, so both deal with the data format 
that they expect. This, of course, adds a performance hit, but even on 
embedded systems where you'd want to avoid this, it's great when 
bootstrapping a new target, since you can just use all the test programs 
in the test/ directory and not think much about it.

You might want to look at the src/video/dummy directory. This is a 
skeleton example (it just lies and says there's a video target 
available...this was for disabling video without the application knowing 
it, but it can serve as a decent skeleton source tree for a new 
target...you'll want to look at other targets too, since there are some 
nuances that the dummy driver ignores.

After you get video displaying at all, you'll probably want to look at 
the blitters in src/video/SDL_blit* ...there are MMX, Altivec. etc 
optimized code to move and convert pixels, but you might get a good 
boost at writing customized code for your CPU arch here. If you are on 
an x86 chip, you're probably already good to go here (MMX, 3DNow, SSE, 
and some generic hand-tuned optimizations are all represented already).

Good luck. If this works out, please send patches so we can include them 
in mainline SDL.  :)

--ryan.