[SDL] Porting SDL to new hardware

[Antonio SJ Musumeci]

I'm pretty sure it's supported on Xbox already... and I'm sure it's
supported on Xbox Linux in some respect. As with PS3 Linux.

Though the Xbox port I dont believe is in the main branch.

On Fri, 27 Apr 2007 14:00:49 -0300
Danilo Vargas <zweifel at gmail.com> wrote:

> is there any chance that SDL can support XBOX, playstation 3 and
> others, just like it supports dreamcast?
> 
> On 4/27/07, Ryan C. Gordon <icculus at icculus.org> wrote:
> >
> >
> > >> 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.
> >
> >
> > _______________________________________________
> > SDL mailing list
> > SDL at lists.libsdl.org
> > http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
> >