SDL on Palm OS

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.

Thanks,

Dominique.
http://www.DelphiGamer.com := for all you Object Pascal game development
needs;

I doubt it’ll ever happen. PalmOS is very, very, VERY different from
desktop OSes.

I think focus should be made on more PC-like PDAs (PocketPC and Linux),
for example on iPAQs and the new Sharp Zaurus*

-bill!

  • I’m not biased! :wink: Really!On Mon, Dec 17, 2001 at 08:01:10PM +0000, Dominique Louis wrote:

Hi All,
How is the port of SDL to Palm OS going? I could not find a URL if
one does exist.

  • William Kendrick on Mon, Dec 17, 2001:

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.

M. R.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011217/aa5521ac/attachment.pgp

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.

MadsOn Mon, 17 Dec 2001, M. R. Brown wrote:


Mads Bondo Dydensborg. @Mads_Bondo_Dydensbor
You know you’re a Linux geek when…

When you hear the words 'Fresh meat' you think of software.

                                                 - segfault
  • Mads Bondo Dydensborg on Mon, Dec 17, 2001:

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.

And this is important … why?

M. R.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011217/35c8be28/attachment.pgp

The OS is different, it is not a matter of screen size.

There are no such thing as a malloc, for instance.

This is simply not true.
http://www.palmos.com/dev/tech/docs/palmos/MemoryManager.html#938867

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:


David MacCormack
@David_MacCormack

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.

There are no such thing as a malloc, for instance. Applications are (more
or less) assumed to run in place. And so forth.

And this is important … why?

[icculus at gemini ~/projects/SDL12]$ grep -r “malloc” src |wc -l
424

–ryan.

  • Ryan C. Gordon on Mon, Dec 17, 2001:

There are no such thing as a malloc, for instance. Applications are (more
or less) assumed to run in place. And so forth.

And this is important … why?

[icculus at gemini ~/projects/SDL12]$ grep -r “malloc” src |wc -l
424

According to the link that David MacCormack was so kind enough to provide
us ignorant folk
(http://www.palmos.com/dev/tech/docs/palmos/MemoryManager.html):–
MemPtrNew http://www.palmos.com/dev/tech/docs/palmos/images/top.gif
Purpose

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.

and,

MemPtrFree http://www.palmos.com/dev/tech/docs/palmos/images/top.gif
Purpose

Macro to dispose of a chunk.
Prototype

Err MemPtrFree (MemPtr p)
Parameters
-> p Pointer to a chunk.
Result
0 If no error or memErrInvalidParam (invalid parameter).
Comments

Call this routine to dispose of a nonmovable chunk.

Are those what you would call drop-in replacements for malloc() and free()?

M. R.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011217/3b5a15a0/attachment.pgp

The OS is different, it is not a matter of screen size.

There are no such thing as a malloc, for instance.

This is simply not true.
http://www.palmos.com/dev/tech/docs/palmos/MemoryManager.html#938867

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… :slight_smile:

MemPtr MemPtrNew (UInt32 size)

MemPtrFree http://www.palmos.com/dev/tech/docs/palmos/images/top.gif
Purpose

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.

MadsOn Mon, 17 Dec 2001, M. R. Brown wrote:


Mads Bondo Dydensborg. @Mads_Bondo_Dydensbor
You know you’re a Linux geek when…

You feel an undefined sense of shame when the advice you give on
Windows 9X works.

                                                 - segfault

Es schrieb “M. R. Brown”:

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

The OS is different, it is not a matter of screen size.

There are no such thing as a malloc, for instance.

This is simply not true.
http://www.palmos.com/dev/tech/docs/palmos/MemoryManager.html#938867

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:

/* Memory allocation */

extern void *malloc (size_t __size);
extern void free (void *__ptr);
extern void *calloc (size_t __nmemb, size_t __memb_size);
extern void *realloc (void *__ptr, size_t __size);

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:

On Mon, 17 Dec 2001, David MacCormack wrote:

On Mon, 17 Dec 2001, Mads Bondo Dydensborg wrote:


David MacCormack
@David_MacCormack

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:

/* Memory allocation */

extern void *malloc (size_t __size);
extern void free (void *__ptr);
extern void *calloc (size_t __nmemb, size_t __memb_size);
extern void *realloc (void *__ptr, size_t __size);

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

#define malloc(size) MemPtrNew(size ? size : 1)
#define free(ptr) if (ptr) MemPtrFree(ptr)

and so forth.

Anyway, I’ll move from the off-topic and start working on how to make use
of the Palm’s screen, touchpad, and event interfaces.

M. R.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20011218/ec087825/attachment.pgp