Hi All,
How is the port of SDL to Palm OS going? I could not find a URL if
one does exist.
I am downloading the PocketStudio IDE which uses an Object Pascal
compiler and I was thinking of testing my Object Pascal headers with it,
if a Palm OS version of SDL is available.
I doubt it’ll ever happen. PalmOS is very, very, VERY different from
desktop OSes.
I’m not trying to start anything, but why not? SDL is modular enough that
you can pick and choose which bits you want to port. There’s a lot of
stuff out there that is very “different” from PCs, but they still have
input and output interfaces. Should we ignore those just because they can’t
do 640x480x32 or don’t keyboard input?
I think focus should be made on more PC-like PDAs (PocketPC and Linux),
for example on iPAQs and the new Sharp Zaurus*
PCs suck, and anything that looks too much like 'em ;P.
I’m not trying to start anything, but why not? SDL is modular enough that
you can pick and choose which bits you want to port. There’s a lot of
stuff out there that is very “different” from PCs, but they still have
input and output interfaces. Should we ignore those just because they can’t
do 640x480x32 or don’t keyboard input?
The OS is different, it is not a matter of screen size.
There are no such thing as a malloc, for instance. Applications are (more
or less) assumed to run in place. And so forth.
I’m not trying to start anything, but why not? SDL is modular enough that
you can pick and choose which bits you want to port. There’s a lot of
stuff out there that is very “different” from PCs, but they still have
input and output interfaces. Should we ignore those just because they can’t
do 640x480x32 or don’t keyboard input?
The OS is different, it is not a matter of screen size.
The point I was trying to make was that just because a platform doesn’t
conform to our ideals of a “true SDL target” it shouldn’t be ignored or
brushed off as not worthy. The screen resolution question was
illustrative, not meant to be taken literally. People seem to forget that
SDL is small and broken up into (pretty much) seperate sections. Obviously
a Palm port couldn’t support the CD-ROM functionality of SDL, but doesn’t
the display and touchpanel count for something?
There are no such thing as a malloc, for instance. Applications are (more
or less) assumed to run in place. And so forth.
Applications are (more
or less) assumed to run in place. And so forth.
Mads
As to not stray off-topic I’m just gonna say this… check the archives.
A port has been attempted before, IIRC, though I think the author stopped
working on it.
DaveOn Mon, 17 Dec 2001, Mads Bondo Dydensborg wrote:
In the land of Redmond, where the Windows lie.
One OS to rule them all, One OS to find them,
One OS to bring them all and in the darkness bind them.
In the land of Redmond, where the Windows lie.
Allocate a new nonmovable chunk in the dynamic heap.
Prototype
MemPtr MemPtrNew (UInt32 size)
Parameters
-> size The desired size of the chunk.
Result
Returns pointer to the new chunk, or 0 if unsuccessful.
Comments
This routine allocates a nonmovable chunk in the dynamic heap and returns a
pointer to the chunk. Applications can use it when allocating dynamic
memory.
In Palm OS 3.5, the dynamic heap is sized based on the amount of memory
available, and is generally larger than before.
As I meant it, it is. There are no “malloc” call. There are of course
memory management stuff, but I was trying to make the point that it is
quite different from most other platforms - ie, pointers need to be locked
(whatever) to ensure they are safe to use, and so forth.
IIRC you need about 4 calls in place of malloc/free.
MadsOn Mon, 17 Dec 2001, David MacCormack wrote:
On Mon, 17 Dec 2001, Mads Bondo Dydensborg wrote:
–
Mads Bondo Dydensborg. @Mads_Bondo_Dydensbor
Any attempt to brew coffee with a teapot should result in the error
code “418 I’m a teapot”. The resulting entity body MAY be short and
stout.
- rfc2324. Go look it up…
Are those what you would call drop-in replacements for malloc() and free()?
IIRC no, you still need to lock memory to actually ensure that your memory
"stays in place" and so forth. Its been a while since I last did Palm OS
work, and I was not trying to suggest that it is impossible, just that I
would expect it to require a number of changes to things we would take for
granted on most platforms.
Call this routine to dispose of a nonmovable chunk.
–
Are those what you would call drop-in replacements for malloc() and free()?
IIRC, most of the “memory” on a palm device happens to be flash ram which is not
the same as SRAM or DRAM. You can allocate a memory chunk and get a pointer to
it, fine, and you can read from the address of this memory chunk quite quickly,
but to WRITE to this memory chunk is excpetionally SLOW. Each palm however has
some volatile SRAM for the programs - its where the returnstack gets placed, so
that each process thread can run at good speed. This returnstack is very very
small, so do not try to mess around with alloca() or with large auto-varfields
in a C program.
Now, everyone wants to think over what an SDL implementation on a palm would
look like - how do you think a surface-copy can be made a quick operation on
this platform? The answer is, that it can not be made quick. As it was already
pointed out, the memchunk allocators should not be interpreted as malloc()-like
but more as mmap()-like operations - you allocate some size of memory (usually
a named portion) and you can later lock it into a specific address (so no one
can reorganize the flash memory during your read/write ops (sort of defragment)).
If you can recode your programs to work on virtual files, it would be easy to
put it onto a palm, but I guess most SDL programs will like to make a hundred
calls to malloc and have the pointers stored into some struct-member, making
linkedlists and linkednodes of data trees. This is all the other way as if
creating a file and making the changes in mmap’ed portions of it, closing the
handle afterwards so that the datachunk is frozen when the program exits.
hope that I am not all that wrong about the topic, cheers, guido
As I meant it, it is. There are no “malloc” call. There are of course
memory management stuff, but I was trying to make the point that it is
quite different from most other platforms - ie, pointers need to be locked
(whatever) to ensure they are safe to use, and so forth.
IIRC you need about 4 calls in place of malloc/free.
Mads
Once again, this is simply not true! I don’t want to sound like a jerk but
you really should look things up before “informing” people. The palmos
gcc toolchain’s stdlib.h (a.k.a prc-tools) has, and I quote:
I’m not trying to argue the merit of a Palm OS port… that’s an entirely
different can of beans. But you keep stating “facts” that are complete
nonsense.
DaveOn Tue, 18 Dec 2001, Mads Bondo Dydensborg wrote:
In the land of Redmond, where the Windows lie.
One OS to rule them all, One OS to find them,
One OS to bring them all and in the darkness bind them.
In the land of Redmond, where the Windows lie.
I’m not trying to argue the merit of a Palm OS port… that’s an entirely
different can of beans. But you keep stating “facts” that are complete
nonsense.
Please take this discussion offline.
Thanks,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
As I meant it, it is. There are no “malloc” call. There are of course
memory management stuff, but I was trying to make the point that it is
quite different from most other platforms - ie, pointers need to be locked
(whatever) to ensure they are safe to use, and so forth.
MemHandleXXX() for movable chunks, MemPtrXXX() for non-movable chunks. You
were correct in that you want to lock movable chunks before you use them.
Locking is irrelevant when working with non-movable chunks (that’s why the
MemPtrXXX() calls are drop-in replacements for malloc() and friends).
Yes, ideally you would want to use the locking mechanism so that the Memory
Manager can defragment the dynamic heap as necessary. Whether this is
needed for an SDL implementation, I don’t know. I’m still tallying up the
sizes of SDL’s internal malloc’s.
David MacCormack on Tue, Dec 18, 2001:
Once again, this is simply not true! I don’t want to sound like a jerk but
you really should look things up before “informing” people. The palmos
gcc toolchain’s stdlib.h (a.k.a prc-tools) has, and I quote:
Not only that, but if you look at prc-tools/libc/malloc.c you’ll find
wrappers around the Memory Manager calls. Just one more level of
indirection. You could even get nasty and