Skip to main content

Volunteer needed to port phoneME Advanced to Garnet OS / Palm OS 5.x

198 replies [Last post]
Anonymous

Hi all,

We need volunteers from the open source community to help port phoneME
Advanced to Garnet OS / Palm OS 5.x. Currently, there is no one
assigned to this task.

See Eric Bresie's request for enhancement:

https://phoneme.dev.java.net/issues/show_bug.cgi?id=40

Once we have the volunteers, I can cover the steps for the porting work
to whomever will be working on this project and help guide the effort.

Please let me know if you are interested in this porting work and would
like to help our open source project. Since, we are an open source
project, we are relying on the developer community to step up and do the
work when there is demand for changes to the project, and not rely on
Sun for 100% of the work needed.

Thanks,

Hinkmond

[email.eml]
---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
fcassia_at_gmail
Offline
Joined: 2004-10-11
Points: 0

"Have you tried superwaba from Brazil?"

Yes, it sucks.

" It is a Java like language"

You said it "java-like". The goal here is to create a 100% compatible build of Sun's PhoneME project that compiles on Palm OS. So that PalmOS devices are able to run any Java ME application UNMODIFIED, without recompiling, and also without having to use the dated IBM J9 Java VM which is no longer supported.

"that works cross platform palm os and windows mobile devices. Why are you reinventing the wheel here?"
Because of the above. If you have nothing to contribute please go back to the Superwava forums.

FC

fcassia_at_gmail
Offline
Joined: 2004-10-11
Points: 0

Donald Kirker from OpenMobl FINALLY posted his changes to LibC to compile on Palm OS. He used those changes to build several open source components which are part of his "UniverseCore" web browser

Find LibC over here
http://universecore.svn.sourceforge.net/viewvc/universecore/trunk/libarmc/

Hope this helps

FC

ebresie
Offline
Joined: 2003-08-06
Points: 0

I tried compiling it and seem to want some additional libraries based on Code warrior (the Palm version is no longer available). Did anyone get this going?

wuenlee
Offline
Joined: 2004-05-27
Points: 0

You are right, Codewarrior is no longer for sale, but the updates are still available on the FreeScale.com site.

http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=01272600617...

Look for the file "CW_PalmOS_9.3_Update.exe" and see if it includes the required headers.

Also, I believe a full version is available "as is" at MaxPDA.com (have not checked it, but a friend need some header files and got it from it):

http://down.maxpda.com/download/software-181.html

I believe you have to scroll down and click on server 1 or server 2. If too slow try the other. Like I said I didn't test it. Use at your own risk and scan with antivirus.

Freescale is of no help they say its no longer for sale.

bye

ebresie
Offline
Joined: 2003-08-06
Points: 0

> On a side note, I found a "PalmDOS" type program
> which is somewhat dated, but maybe it will help on
> the Command Prompt / Consoles issue we discussed
> previously. At the very least, the code may be good
> to look at for the StdIOProvided sample code.
>
> See
>
> http://break.org/gisle/PalmOS/>

Another possible helpful alternative:

VFSDOS http://pages.total.net/~hkonstas/vfsdos.html

ebresie
Offline
Joined: 2003-08-06
Points: 0

One more item of interest. Checkout this thread relating to prc-tools related status of the moment. It has some interesting tidbits of information...

http://sourceforge.net/mailarchive/forum.php?thread_name=113b56700806110...

Eric

ebresie
Offline
Joined: 2003-08-06
Points: 0

Another resource of interest Palm FAQ:

http://flippinbits.com/twiki/index.php?page=palm-pda-faq

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Another resource of interest Palm FAQ:
>
> http://flippinbits.com/twiki/index.php?page=palm-pda-faq
>

Hi Eric,

Is the above URL correct? I get a page with only this message (no FAQ):

---

Palm PDA FAQ

Gotta love spam maniacs. The PalmDevFAQ has been migrated over to this
platform. Likely with mostly dead links. I will be working on these over
time to iron out the bugs.

If you have something to change or to add to the PalmDevFAQ, please
submit it using the 'Contact Us' page above.

Thanks,

The Management
---

Hinkmkond

[att1.html]

ebresie
Offline
Joined: 2003-08-06
Points: 0

Yeah...I thought that initally...Go to the "Palm PDA FAQ" item on the upper right. Mouse over it, and subcategories of FAQs will show up which you can select from.

On a side note, I found a "PalmDOS" type program which is somewhat dated, but maybe it will help on the Command Prompt / Consoles issue we discussed previously. At the very least, the code may be good to look at for the StdIOProvided sample code.

See

http://break.org/gisle/PalmOS/>
http://break.org/gisle/PalmOS/binaries/PalmDOS0_7.zip
http://break.org/gisle/PalmOS/binaries/PalmDOSv07src.zip

Eric

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Yeah...I thought that initally...Go to the "Palm PDA FAQ" item on the upper right. Mouse over it, and subcategories of FAQs will show up which you can select from.
>

I see now. Wow, talk about non-intuitive user interface! :-) Thanks
for the hint.

Hinkmond

> On a side note, I found a "PalmDOS" type program which is somewhat dated, but maybe it will help on the Command Prompt / Consoles issue we discussed previously. At the very least, the code may be good to look at for the StdIOProvided sample code.
>
> See
>
> http://break.org/gisle/PalmOS/>
> http://break.org/gisle/PalmOS/binaries/PalmDOS0_7.zip
> http://break.org/gisle/PalmOS/binaries/PalmDOSv07src.zip
>

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

ebresie
Offline
Joined: 2003-08-06
Points: 0

Not sure if this would be of any help either, but this was an interesting article:

http://tamspalm.blogspot.com/2004/12/multitasking-with-non-cobalt-palmos...

Eric

nileshpereira
Offline
Joined: 2003-08-22
Points: 0

I think I've found the best resource on arm-palmos programming - http://news.palmos.com/read/. There's a wealth of information in this list's archives, and it's semi-active as well, unlike the palm/access forums. On that list I think we will find the last active arm-palmos experts, since access has long moved to ALP.

Maybe someone can try to recruit some volunteers from there?

d_bleyl
Offline
Joined: 2003-07-15
Points: 0

Sorry to repeat the question, but has anyone made any progress porting the pth_mctx.c to work with the m68k-palmos/include/setjmp.h subset? It appears to have most of what is necessary.

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Sorry to repeat the question, but has anyone made any progress porting the pth_mctx.c to work with the m68k-palmos/include/setjmp.h subset? It appears to have most of what is necessary.
> [Message sent by forum member 'd_bleyl' (d_bleyl)]
>

Hi d_bleyl,

Have you tried using it? What can you tell us about it? How would you
integrate it with the phoneME Advanced build. I think everyone might be
busy with other investigations currently.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

d_bleyl
Offline
Joined: 2003-07-15
Points: 0

I started down this road, but haven't made much progress.

Reading the paper on the Pth site, http://www.gnu.org/software/pth/rse-pmt.ps, it seems like we just need to wrap the jmpbuf structure with an mctx_t struct, and implement mctx_create.

Based on the paper, manual and comments on a blog about implementing threads on PalmOS using setjmp/longjmp (sjlj) (posted above), there should be a way for us to do this without much additional support, in theory.

What seems to be missing is the 'secret sauce', I can't help but think that someone has implemented this for Palm already. What should make it easier is that fact that we aren't trying to implement a portable threading library - we just need one (or two) implementations, so the warnings about the difficulties of choosing a portable solution shouldn't necessarily apply to us in this case.

I've dusted off my copy of [u]Programming with POSIX Threads[/u] and am working through the examples as a refresher, and I've just received about 5 or so Palm programming books from Amazon, so aside from reading the Pth source, and playing with setjump.h on my Palm, I haven't made much progress.

One of the problems I'm having on Ubuntu is that I haven't gotten arm to work well. I've had to patch a bunch of C files to get it to start working, and I'm a little concerned about the PNO/Armlet interface. It seems like the official documentation is cautious about when we need to use arm. The link ebreise just posted gives me a little confidence because the folks that weighed in seem to be Palm heavy-hitters, and they seem to advocate targeting arm.

Regarding your previous post whether it is worth the effort, I would say, I've learned a lot. I'm not banking on my T|X to be my next big embedded Java environment, but the challenge is definitely fun.

ebresie
Offline
Joined: 2003-08-06
Points: 0

> One of the problems I'm having on Ubuntu is that I
> haven't gotten arm to work well. I've had to patch a
> bunch of C files to get it to start working, and I'm
> a little concerned about the PNO/Armlet interface.

What did you patch?

Eric

d_bleyl
Offline
Joined: 2003-07-15
Points: 0

Some c header files that were using an older syntax. When I finally got the right version, I realized my source samples weren't written for arm.

ebresie
Offline
Joined: 2003-08-06
Points: 0

Not sure of it's of use but I stumbled across something that may be of use...although it is a little dated..

http://www.deepnettech.com/old/coordtask.html

Eric

nileshpereira
Offline
Joined: 2003-08-22
Points: 0

Unfortunately, all the old code you find out there is m68K-palmos code, which is not going to be of much
use beyond implementing the CDC GUI. All the heavy lifting of the CVM will only be possible using
arm-palmos code, of which there is precious little information. None of the toolchains like Palm's
SDK or Prc-Tools work out of the box and create working arm-palmos code, as they haven't been updated
for many years. Even worse is that there is no way to test the arm-palmos code except on the device,
as the Palm Simulator is only able to execute m68k-palmos code. Infact, I think the only way to get
working arm-palmos code is to build Prc-Tools from scratch and apply your own patches onto it, which is
what Tom Borris has done for his SDL port.

My current status is that using the out of the box Prc-Tools, I have been able to compile and build the
ANSI C part of the SDL library, and the protothreads threading library for arm-palmos. I suspect however,
that to get it to actually run, I'm going to need to get instructions from Tom on how to build Prc-Tools
from scratch and apply his patches.

ebresie
Offline
Joined: 2003-08-06
Points: 0

> Protothreads (http://www.sics.se/~adam/pt/) are
> probably the easiest threading library to get working
> - I've already been able to compile it for PalmOS.
> But it's probably not sophisticated enough to build a
> CDC VM with unfortunately, since it doesn't support
> stack-switching. Can someone who has experience
> porting the CVM let us know for sure that it is not
> adequate? Thanks!

Are you planning on using the graham-pt.h extention that "allow a protothread to sleep (PT_SLEEP() and PT_WAKE()) and to be killed (PT_KILL()). Also, a test if a protothread is blocked (PT_ISBLOCKED()) "?

FYI...the protothreading is BSD licensed...

Eric
Eric

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
>> Unfortunately, it looks like Sun still doesn't "get"
>> open source. Sad really, since even though they've
>> open sourced all their software, they still treat
>> them like proprietary projects.
>>
>
>
> Nope...Sun is a business that has to cover there based to avoid any possible legal issue. I don't think there are here, but IANAL.
>

Eric is correct. GPL has a strange gray area around the meaning of
"derivative work":

http://library.findlaw.com/2003/Jun/16/132811.html

"Thus, the court recognized the important issue that will need to be
resolved in a case interpreting the GPL: whether a program linked to
GPL’d software can be considered a derivative work of that software. The
court also raised the question of whether subsequent shipping of source
code can cure a breach of the GPL without permission to continue
shipment from either the author or subsequent distributor of the software."

It's a reality, even with the GPLv2 and Sun's full understanding of open
source and what it all means, that companies like Sun must protect
ourselves from possible legal issues around the issue of incorrect
interpretations of "derivative works".

So, the easiest course of action is to upload the code diffs to your own
public Web or FTP site and not host other project's code at this project
(phoneME), since even though you might have an e-mail stating that
SDLPalmOS is GPL, our Sun lawyers would have to review that and render
an official opinion. That part is not as easy as for you to upload the
code in question to a public Web site that you or SDLPalmOS controls.

Thanks for your understanding,

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

fcassia_at_gmail
Offline
Joined: 2004-10-11
Points: 0

> This is a GPL open source project and as you know, any mods you
> make to this project (phoneME) are fine to upload and share to our
> project site on java.net.
>
> However, the ANSI C code changes are mods you are
> making to another project (not phoneME) which is someone else's source
> code. So, if you had said you wanted to share your owb source code,
> that would be different and would be OK for you to share with us
> since it would be your own source code which you have control over in
> how it is used (and in turn linked, combined, and built).

It is perfectly OK to merge content from two GPL projects, I think . So Java is GPL, SDL is GPL, what is the big deal here??. If this in turns allows Sun to build Java on the PalmOS platform and saves work, why not do it and incorporate that Ansi C GPL work into the GPL Java ME tree?. I think a simple statements like "Palm OS port contains code from the SDL GPL project (c) such and such" woudl be OK.

After all, isn't this what the GPL is supposed to encourage, code re-use, branching and make porting easier?

> However, since the ANSI C lib source code was not
> written by you, there
> are licensing terms on how that code is used. If you
> combine it with
> phoneME, you are creating a "derivative work" and
> would be exposing that
> specific ANSI C lib source code that is not yours to
> the viral GPL rules

Again, if that code is GPL what is the problem?.

> by making it available to build and link with
> phoneME. (But, of course
> I'm not a lawyer, yadda, yadda, yadda) ;-)

I have asked the FSF about this.... so we can stop assuming stuff and scaring developers from re-using code that is out there.

> . It's like if you went to the Linux kernel.org site and found Microsoft Windows source
> code uploaded there.

With all due respect, this is a stupid example. Microsoft windows is proprietary software.
What the heck does it have to do with combining two GPL projects?. SDL for PalmOS shows in sourceforge as having a GPL license. Why don't we ask Tom Borris whom did the port if we have his permission to reuse his work?.

Sheesh...
FC

nileshpereira
Offline
Joined: 2003-08-22
Points: 0

Unfortunately, it looks like Sun still doesn't "get" open source. Sad really, since even though they've open sourced all their software, they still treat them like proprietary projects.

Once I get threading working, I'm going to upload the code to sourceforge and end my contribution there.

ebresie
Offline
Joined: 2003-08-06
Points: 0

> Unfortunately, it looks like Sun still doesn't "get"
> open source. Sad really, since even though they've
> open sourced all their software, they still treat
> them like proprietary projects.

Nope...Sun is a business that has to cover there based to avoid any possible legal issue. I don't think there are here, but IANAL.

> Once I get threading working, I'm going to upload the
> code to sourceforge and end my contribution there.

On a side note, I dropped an email to the developer of the SDL Palm port and received the following:

> Hi Eric,
>
> I want to continue my work on SDL for PalmOS in a few weeks. Because of some
> private troubles, there was no time to work on this project.
>
> You can use every code you want from this project. Everything is under GPL or other
> Open Source License.
>
> If you have some questions about limitations or problems with the toolchain, just ask.
>
> Regards,
>
> Tom

Perhaps the solution is to identify and shortcomings on the SDL for PalmOS, help resolve it (get threading working), provided it back to their codebase, then use it here..

Eric

Gary

Just an opinion, but it would seem to me that
making changes to the SDL port and putting the changes back
to the SDL port would benefit others, as well as the Java port, that
would be layered on top of it.

Most of the other phoneme platform ports may a clear distinction about the
porting code that is layered on the platform libraries/kernel and the
capabilities that come from the underlying tool chain.

Having an ANSI C library and native platform threads are
typically provided in the platform libraries, not in the Java
porting layer.

phonemeadvanced@mobileandembedded.org wrote:
>> Unfortunately, it looks like Sun still doesn't "get"
>> open source. Sad really, since even though they've
>> open sourced all their software, they still treat
>> them like proprietary projects.
>>
>
>
> Nope...Sun is a business that has to cover there based to avoid any possible legal issue. I don't think there are here, but IANAL.
>
>
>> Once I get threading working, I'm going to upload the
>> code to sourceforge and end my contribution there.
>>
>
> On a side note, I dropped an email to the developer of the SDL Palm port and received the following:
>
>
>> Hi Eric,
>>
>> I want to continue my work on SDL for PalmOS in a few weeks. Because of some
>> private troubles, there was no time to work on this project.
>>
>> You can use every code you want from this project. Everything is under GPL or other
>> Open Source License.
>>
>> If you have some questions about limitations or problems with the toolchain, just ask.
>>
>> Regards,
>>
>> Tom
>>
>
> Perhaps the solution is to identify and shortcomings on the SDL for PalmOS, help resolve it (get threading working), provided it back to their codebase, then use it here..
>
> Eric
> [Message sent by forum member 'ebresie' (ebresie)]
>
> http://forums.java.net/jive/thread.jspa?messageID=286202
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail: advanced-help@phoneme.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

xyzzy (Dean)

phonemeadvanced@mobileandembedded.org wrote:
> Hinkmond,
> Yes, GNU Pth looks cool. But still have questions:
> First, it depends on ANSI C. Here's a list of its required ANSI C header files:
> /* mandatory system headers */
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> Besides this, Pth is a non-preemptive Pthread implementation, I don't know if such a cooperative threading library can meet pMEA's requirement?
>
> M@x
> [Message sent by forum member 'max_mu' (max_mu)]

There is no requirement for preemptive threads in the spec, and we
have added hooks recently that should help here, such as CVMthreadSchedHook().

If someone decided to use something like Green Threads from JDK 1.3 or
PersonalJava, then using setjmp/longjmp gets you pretty far when it
comes to switching to a new thread. Synchronization "monitors" were
also implemented that perform priority inheritance. The toughest part
is always getting user-level threads to play nice with the native OS.
That means adding locks around things like "malloc" so they are
thread-safe. Even more difficult is being able to cause a thread to
sleep and switch context when a blocking operation needs to be performed
(socket read for example).

Dean

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

max_mu
Offline
Joined: 2006-11-15
Points: 0

Dean,
Sounds promising! Is CVMthreadSchedHook() a chance to do thread yield?

M@x

xyzzy (Dean)

Yes, that's exactly what it is.

Dean

phonemeadvanced@mobileandembedded.org wrote:
> Dean,
> Sounds promising! Is CVMthreadSchedHook() a chance to do thread yield?
>
> M@x
> [Message sent by forum member 'max_mu' (max_mu)]
>
> http://forums.java.net/jive/thread.jspa?messageID=285532

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

max_mu
Offline
Joined: 2006-11-15
Points: 0

Dean,
Well, non-preemptive threading is no longer a fatal problem now. But we still have to resolve GNU Pth's ANSI C and Syscall dependancy. According to the information from its homepage, Pth is designed to be easy-porting to Unix-like systems, but PalmOS is definitely not.

M@x

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Dean,
> Well, non-preemptive threading is no longer a fatal problem now. But we still have to resolve GNU Pth's ANSI C and Syscall dependancy. According to the information from its homepage, Pth is designed to be easy-porting to Unix-like systems, but PalmOS is definitely not.
>

Yes, as mentioned to Nilesh, the bigger issue of GNU Pth needing ANSI C
and Syscall is the bigger problem now.

Do you think there is any hope if you added more functionality to PalmOS
that it could ever run GNU Pth? Or, will it be too much? (Turning
PalmOS into UNIX is probably non-trivial, I would think).

Another thread: When is ACCESS Linux supposed to be available on Palm
devices? Is that an option to wait for?

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

nileshpereira
Offline
Joined: 2003-08-22
Points: 0

Hi Hinkmond,

Has anyone been able to determine which would be less work? Porting pMEA by making use of the undocumented PalmOS features like SysTaskCreate for multi-threading? Or by porting the GNU ANSI-C and Pth libraries to PalmOS? I'm guessing that since pMEA is designed to be ported to ANSI-C/POSIX systems, it's the latter...

Regards,
-Nilesh

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Hi Hinkmond,
>
> Has anyone been able to determine which would be less work? Porting pMEA by making use of the undocumented PalmOS features like SysTaskCreate for multi-threading? Or by porting the GNU ANSI-C and Pth libraries to PalmOS? I'm guessing that since pMEA is designed to be ported to ANSI-C/POSIX systems, it's the latter...
>

Good question. Since there are so many dependencies from pMEA to full
ANSI C stdio and stdlib, I would guess you're right and porting GNU ANSI
C and Pth libs to PalmOS would be the shorter path.

Eric, Dean, and Max, please correct me if you feel otherwise.

The trouble with Pth as Max pointed out, is that it needs ANSI C,
syscall and a UNIX-like system. So, I don't know if that's a
showstopper right there, since the porting of full ANSI C to PalmOS is
not well-known at this point, and especially since PalmOS is not a
"UNIX-like system".

If anyone finds out more, please let us know.

Thanks,
Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

nileshpereira
Offline
Joined: 2003-08-22
Points: 0

The SDL for PalmOS project at http://sourceforge.net/projects/sdlpalmos/ has an implementation of ANSI-C that I think we can use! Download SDLforPalmOS_Beta1_src.zip from http://downloads.sourceforge.net/sdlpalmos/SDLforPalmOS_Beta1_src.zip?mo... and have a look at libarmc. I have a good feeling about this :)

d_bleyl
Offline
Joined: 2003-07-15
Points: 0

This looks very exciting - unfortunately, from /SDL/src/thread/palm/SDL_systhread.c:
[i]

int SDL_SYS_CreateThread(SDL_Thread *thread, void *args)
{
[b]SDL_SetError("Threads are not supported on this platform");[/b]
return(-1);
}[/i]

Ouch.

How far has everyone gotten with the Pth?

From the docs and src, it looks like you can port it with just setjump, longjump, jmp_buf and with or without signal.h. And it just so happens that prc-tools contains:

/usr/m68k-palmos/include/[b]setjmp.h[/b] (and stdio.h among other things).

I've written some tests to verify that these functions work on my palm device, but I still need to find out why signal.h has been removed from the latest prc-tools. Check out Pth's pth_mctx.c (near the bottom/doesn't require signals.h):
[i]/*
* VARIANT X: JMP_BUF FIDDLING FOR ONE [b]MORE ESOTERIC OS[/b]
* Add the jmp_buf fiddling for your esoteric OS here...
*
#elif PTH_MCTX_MTH(sjlj) && PTH_MCTX_DSP(sjljeso)
intern int
pth_mctx_set(pth_mctx_t *mctx, void (*func)(void),
char *sk_addr_lo, char *sk_addr_hi)
{
pth_mctx_save(mctx);
sigemptyset(&mctx->sigs);
mctx->error = 0;
...start hacking here...
mctx->.... = func;
mctx->.... = sk_addr_hi;
mctx->.... = sk_addr_lo;
return TRUE;
}
*/[/i]

The palm jmp_buf (called jmpbuf) clearly marks the stack pointer, frame pointer, program counter and registers in setjmp.h. So far, this seems doable. If you've read the Pth paper and porting guide, this should start to make sense. Hats off to jslee06 for finding this lib.

Obviously, I'm using the m68k stuff, but has anyone successfully generated a PNO/Armlet on Ubuntu for their device?

[i][btw: if you need or want additional references for Palm OS, used books are dirt cheap due to the flux state of the OS - I just picked up 4 @ $0.82 each on amazon][/i]

nileshpereira
Offline
Joined: 2003-08-22
Points: 0

Well, I was able to extract and build the ANSI-C library from SDLforPalmOS.

Now we need to build GNU Pth for PalmOS using this library. I think Pth has a drop in replacement pthread.h

Hinkmond, is there somewhere I can upload our new ANSI-C library?

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Well, I was able to extract and build the ANSI-C library from SDLforPalmOS.
>
> Now we need to build GNU Pth for PalmOS using this library. I think Pth has a drop in replacement pthread.h
>
> Hinkmond, is there somewhere I can upload our new ANSI-C library?

Hi Nilesh,

What type of license is on this new ANSI C library? I don't think it
would be allowed as code you should upload to our java.net site if you
do not own the rights to that code.

You might have to find another place to upload it like your yahoo briefcase:

http://briefcase.yahoo.com/bc//home

(And make the file(s) public there)

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

nileshpereira
Offline
Joined: 2003-08-22
Points: 0

Hi Hinkmond

The ANSI C library is extracted from SDL for PalmOS from http://sourceforge.net/projects/sdlpalmos/. SDL for PalmOS has a GPL license, and is itself derived from uClib (LGPL) and GLIBC (GPL).

I will be also using Peal (BSD) from http://www.sealiesoftware.com/peal/, and GNU Pth (LGPL) from http://www.gnu.org/software/pth/.

I thought that this was an open source project... so I'm really confused by your statement. As long as the libraries have a compatible license, why do we care about the ownership?

If you're looking for us to do a "clean room" implementation of ANSI-C and threads on ARM PalmOS (as that's the only code we can have ownership of), then I'm sorry, you can count me out.

Regards,
-Nilesh

P.S. Yahoo briefcase can only be publicly shared for premium users

> Hi Nilesh,
>
> What type of license is on this new ANSI C library?
> I don't think it
> ould be allowed as code you should upload to our
> java.net site if you
> do not own the rights to that code.
>
> You might have to find another place to upload it
> like your yahoo briefcase:
>
> http://briefcase.yahoo.com/bc//home
>
> (And make the file(s) public there)
>
>
> Hinkmond
>
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail:
> advanced-help@phoneme.dev.java.net

Hinkmond Wong

Hi Nilesh,

phonemeadvanced@mobileandembedded.org wrote:
> The ANSI C library is extracted from SDL for PalmOS from http://sourceforge.net/projects/sdlpalmos/. SDL for PalmOS has a GPL license, and is itself derived from uClib (LGPL) and GLIBC (GPL).
>
> I will be also using Peal (BSD) from http://www.sealiesoftware.com/peal/, and GNU Pth (LGPL) from http://www.gnu.org/software/pth/.
>

Sounds good.

> I thought that this was an open source project... so I'm really confused by your statement. As long as the libraries have a compatible license, why do we care about the ownership?
>
> If you're looking for us to do a "clean room" implementation of ANSI-C and threads on ARM PalmOS (as that's the only code we can have ownership of), then I'm sorry, you can count me out.,
>

No, I'm not saying you need to "clean room" implement the ANSI C and
threads libs. Not at all. Sorry for the misunderstanding. This is a
GPL open source project and as you know, any mods you make to this
project (phoneME) are fine to upload and share to our project site on
java.net.

However, the ANSI C code changes are mods you are making to another
project (not phoneME) which is someone else's source code. So, if you
had said you wanted to share your owb source code, that would be
different and would be OK for you to share with us since it would be
your own source code which you have control over in how it is used (and
in turn linked, combined, and built).

However, since the ANSI C lib source code was not written by you, there
are licensing terms on how that code is used. If you combine it with
phoneME, you are creating a "derivative work" and would be exposing that
specific ANSI C lib source code that is not yours to the viral GPL rules
by making it available to build and link with phoneME. (But, of course
I'm not a lawyer, yadda, yadda, yadda) ;-)

So, it would be better if you could find a place to upload it without
any ties to java.net or phoneME. Is there a public FTP site you have
access to? Or better yet, does
http://sourceforge.net/projects/sdlpalmos/ have a place for you to
upload your diffs somewhere there? That would be ideal.

Thanks,
Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

nileshpereira
Offline
Joined: 2003-08-22
Points: 0

But... phoneME is already GPL, so I still don't understand.
Anyway, for the ANSI C lib I was just getting rid of the SDL dependency.
More importantly, with GNU Pth, now I'm tripping over the syscall dependencies...

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> But... phoneME is already GPL, so I still don't understand.
> Anyway, for the ANSI C lib I was just getting rid of the SDL dependency.

Yes, it's not phoneME source code that's the issue. It's that we don't
want to condone the creation of a "derivative work" of someone else's
code (that you don't own), namely the sdlpalmos ANSI C source code (even
though you modified it) by hosting that code specifically at our site.

That would expose their project to own licensing terms, namely the viral
GPL (by having you contribute some other project's modified source code
to us by uploading their modified code to our project site). To say it
differently, since we are the phoneME project (not the sdlpalmos
project), it would not be right for us to host sdlpalmos based code
modifications at our site. It's like if you went to the Linux
kernel.org site and found Microsoft Windows source code uploaded there.

> More importantly, with GNU Pth, now I'm tripping over the syscall dependencies...

Yes, this is the more important issue. I thought Eric mentioned there
might be a PalmOS port of Pth somewhere in their distribution. See:

http://forums.java.net/jive/thread.jspa?messageID=286117#286117

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

ebresie
Offline
Joined: 2003-08-06
Points: 0

Just an aside...I tried to consolidate as much as I can on the Wiki.

See http://wiki.java.net/bin/view/Mobileandembedded/PhoneMEAdvancedPlatforms...

I looked a little at pth and it did appear to support a pthread compatability option. I poked around some and actually found reference to palmos in one of the included files, but I suspect there is a good chance it was a copy and past from some other area. Still looking.

I started looking at thread_md.h some and find a few outstanding headers included, such as pthread.h and semaphore.h. Noticed a few other items in the src/shared/porting/javavm/include/thread.h which also may help some.

But alas, I am still not a Palm developer expert...that's one of the reasons I've been a little quite..tried to read up on it though.

Eric

ebresie
Offline
Joined: 2003-08-06
Points: 0

> I looked a little at pth and it did appear to support a pthread compatability option.
> I poked around some and actually found reference to palmos in one of the
> included files, but I suspect there is a good chance it was a copy and past
> from some other area. Still looking.

Just for reference, the file I saw reference to palmos was the config.sub file for the pth work.

As I'm not all that familiar with the inner workings of configure and its files...I'm not sure if that means a palmos port per say...but there you go..

Eric

nileshpereira
Offline
Joined: 2003-08-22
Points: 0

Every config.sub has a reference to palmos, and every other os/architecture known to man. It means nothing unfortunately as there are no other references to palmos in libpth.

I'm having a problem running SDLforPalmOS on my LifeDrive. Can someone try to run any of the examples/games on their device? I've spoken to Tom, and he said that there are device specific issues that need to be fixed. I've been able to compile and link my own HelloWorld example, and a very simple multithreaded example using protothreads, but I need a compatible device to test it on. So please let me know if you're able to run any of the examples at http://sourceforge.net/project/showfiles.php?group_id=212180. Thanks!

Protothreads (http://www.sics.se/~adam/pt/) are probably the easiest threading library to get working - I've already been able to compile it for PalmOS. But it's probably not sophisticated enough to build a CDC VM with unfortunately, since it doesn't support stack-switching. Can someone who has experience porting the CVM let us know for sure that it is not adequate? Thanks!

ebresie
Offline
Joined: 2003-08-06
Points: 0

> I'm having a problem running SDLforPalmOS on my
> LifeDrive. Can someone try to run any of the
> examples/games on their device? I've spoken to Tom,
> and he said that there are device specific issues
> that need to be fixed. I've been able to compile and
> link my own HelloWorld example, and a very simple
> multithreaded example using protothreads, but I need
> a compatible device to test it on. So please let me
> know if you're able to run any of the examples at
> http://sourceforge.net/project/showfiles.php?group_id=
> 212180. Thanks!

Downloaded the pre-compiled version of the examples.

I was able to get the Madbomber and Dodgin Diamnds example programs working on my Treo 680. (Had to make sure and have the data files in the correct directory on the SD card).

However, Madbomber did appear to try accessing a file named .madbomber which I suspect could be a filename issue (may not be able to have a "." in the filename) which caused an error.

I did noticed one of the readme.palmos files indicates:

"The game doesn't work on Tungsten E because of limited space on dynamic heap."

Crossfire reset my Treo 680.

Eric

nileshpereira
Offline
Joined: 2003-08-22
Points: 0

Okay, count me in to help with the porting. I have installed the Garnet OS Development Suite (which includes Cygwin), and the GCC-based Garnet OS Native Object Toolkit. I have also downloaded the phoneME source.

I'm trying to figure out conceptually what needs to be done. I'm guessing we need to compile the CVM into an ARM-Native binary and the J2ME class library into a Palm Database. Inorder to run on Garnet OS, we would need to create a 68K launcher that would call the ARM-Native code. Unfortunately, the Palm Simulator does not run ARM-Native code, so we would have to test it as a Windows DLL. Once we have the CVM working, we would start porting stuff like the GUI, etc. Is my understanding correct?

If we're building the CVM as an ARM-Native binary, shouldn't we have full multi-threading and ANSI-C support? It's probably just undocumented...

> Hi Nilesh,
>
> Sorry. So far there is no port available of pMEA to
> PalmOS because of
> lack of multithreading and no ANSI standard utilities
> support on PalmOS.
>
> So, until the volunteer developers can figure out a
> workaround, this is
> where we are at the moment.
>
> You might want to go back and read through the forum
> thread to see if
> you can help with suggested workarounds to the
> hurdles we currently have.
>
>
> Thanks,
>
> Hinkmond
>
>
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail:
> advanced-help@phoneme.dev.java.net

Hinkmond Wong

phonemeadvanced@mobileandembedded.org wrote:
> Okay, count me in to help with the porting. I have installed the Garnet OS Development Suite (which includes Cygwin), and the GCC-based Garnet OS Native Object Toolkit. I have also downloaded the phoneME source.
>
> I'm trying to figure out conceptually what needs to be done. I'm guessing we need to compile the CVM into an ARM-Native binary and the J2ME class library into a Palm Database. Inorder to run on Garnet OS, we would need to create a 68K launcher that would call the ARM-Native code. Unfortunately, the Palm Simulator does not run ARM-Native code, so we would have to test it as a Windows DLL. Once we have the CVM working, we would start porting stuff like the GUI, etc. Is my understanding correct?
>
> If we're building the CVM as an ARM-Native binary, shouldn't we have full multi-threading and ANSI-C support? It's probably just undocumented...
>

Hi Nilesh,

Glad you can help! You have summarized the steps needed very nicely
above. And, you have hit upon the first hurdle that is the current
problem in trying to get to step 1: Get headless CVM working.

There is no direct support of a full multithreading library for PalmOS
and there is no full ANSI C support.

There has be discussion whether GNU Pth would be a good addition to
solve the missing multithreading issue, and Eric B. posted a link to
some additional tools that map the ANSI standard C functions to PalmOS:

See:

http://www.gnu.org/software/pth/

and

http://tangentsoft.net/palmfaq/articles/stdlib.html

So, maybe you can help investigate how to use the above info to get the
CVM building using them to fill in the missing multithreading support
and ANSI C support that is required.

Thanks,
Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net

nileshpereira
Offline
Joined: 2003-08-22
Points: 0

I was able to build and run the tests successfully for the VC8 version.
I copied over the linux-arm directories to palmos-arm and tried to build and got the following error:
e:/Projects/palm/phoneme_advanced_mr2/cdc/src/palmos/javavm/include/threads_md.h
:39:21: pthread.h: No such file or directory
Does this mean I've caught up with everyone else?

max_mu
Offline
Joined: 2006-11-15
Points: 0

Yep ;-)

ebresie
Offline
Joined: 2003-08-06
Points: 0

Did you use the 0.0.1 bundle I submitted previously or started over?

Eric

max_mu
Offline
Joined: 2006-11-15
Points: 0

Hinkmond,
Is pMEF's Green Thread model efficient enough for pMEA? I remember that I asked similiar question in J1. I don't know how many native functions has to be rewritten if adpot pMEF Green Thread, since there'll be no blocking native function supporting, but use SNI instead.

BTW, does anyone knows other threading libraries available on PalmOS?

M@x