What tools are needed to compile LJP sources?

[palmdoogie]

Hello All,

What development environment can I use to compile the LJP sources? Is CodeWarrior the only way? I'd like to make a "Lite" version of LJP that can actually compile using Onboard-C, but I believe I'd need to start by compiling the full LJP sources and start boiling down the source code until I get something much more compact. I'm new to Palm Development, but I'm pretty good at modifying code once I get a baseline to compile. Any help out there? Anyone else interested in an LJP Lite version? I'm thinking of reducing it down to NES, SMS, and GB only and stripping out alot of the filters. I also may later try to add in the emulator called "miniVMac". I just did an OS-X compile of that emulator and was shocked that it fits in a 100K application! With code that efficient, it could very well run on some of the 300+MHz ARM based units. Thanks in advance for any help

[luckyluke]

Hi,

Since when Onboard C can generate ARM binaries? Have I missed something in this direction? As far as I know Onboard C only can compile C in 68k code and not ARM.

In its current form the LJP sources need Code Warrior to be compiled. Everything is put into CW project files. I think that it would be some hard but possible job to move the targets and similair information to normal make files. Then it might be possible to compile the important parts of LJP with the prc tools.

On my Centro LJP already runs well enough! I simply don´t install the modules for the systems I don´t need (anything except GB and SNES). I like the amount of filters and the most are running pretty well for me. I think that in this area LJP is the best smartphone/handheld emulator I know.

I would suggest that you shouldn´t waste your time on Palm OS development! In my eyes it´s a operating system with no future. Palm has put a end to the area of Palm OS with their new WebOS. Of course several Palm OS applications will still survive for years from now running on simulators and emulators but the most Palm OS developers will concentrate on other systems. To code on a project like LJP seriously you have to learn much about Palm OS development first.

So far much greetings,
Lukas

[palmdoogie]

Apr 19, 2009 17:12:32 GMT 1 luckyluke said:

Hi,

Since when Onboard C can generate ARM binaries? Have I missed something in this direction? As far as I know Onboard C only can compile C in 68k code and not ARM.

In its current form the LJP sources need Code Warrior to be compiled. Everything is put into CW project files. I think that it would be some hard but possible job to move the targets and similair information to normal make files. Then it might be possible to compile the important parts of LJP with the prc tools.

On my Centro LJP already runs well enough! I simply don´t install the modules for the systems I don´t need (anything except GB and SNES). I like the amount of filters and the most are running pretty well for me. I think that in this area LJP is the best smartphone/handheld emulator I know.

I would suggest that you shouldn´t waste your time on Palm OS development! In my eyes it´s a operating system with no future. Palm has put a end to the area of Palm OS with their new WebOS. Of course several Palm OS applications will still survive for years from now running on simulators and emulators but the most Palm OS developers will concentrate on over systems. To code on a project like LJP seriously you have to learn much about Palm OS development first.

So far much greetings,
Lukas

Hello Lukas,

Thanks for the response and info. The reason I want to build a Lite version is for all of us T|T and T|T2 owners who are on the edge of performance and Dynamic Heap storage. Also, I'd like to try and figure out what happened on the T2 from RC7 to RC7c to cause the 10x slowdown and back out that change. I'm really a Hardware design person, but I'm quite good at "boiling down" other people's code into bare essentials. For instance, since the SNES and Genesis don't run with any reasonable performance, I'd take support out for those in the Lite version. More so than just not installing the module, I'd remove support for them completely, thus making it much easier to debug the T2 slowdown. I also have a hardware experiment I'm going to try which is to transplant a T3 logic board into an original T|T case. Call me crazy, but I love the older circular directional pad and aesthetically, I like the color of the original T|T case. It looks more like "Tungsten" to me than the silver case. I definitely am not getting into the business of Palm development, but it would be fun to write a few gadgets for it before moving on to iPhone/iPod development.

So, to get further clarification on my question, which version of Code Warrior for Palm would I need to build the latest released sources(1.01)? I can get revision 6 pretty cheap on eBay, but I'm pretty sure there's no ARM support in that version. Do I need version 9 or would 8 be able to build the LJP ARM binaries? How about PRC-Tools? Has anyone built the LJP sources with that IDE? There's a Mac OS-X port I downloaded and would love to try, but I'm not sure how to convert the CW project into a PRC-Tools equivalent Project File or Makefile.

By the way, I did come across an ARM assembler for OnboardC, but I 'm sure I will need to boil down the code into a much more compact form before even attempting compilation there.

Again, thanks for the info and any help would be much appreciated

[Tinnus]

I'm pretty sure removing support for Genesis and SNES won't help you get any extra performance OR find any problems easier...

But yes, the way the code is now, as is, I'm pretty sure will have a hell of a time to work without CodeWarrior. It's much MUCH more problematic than just converting the project because some of the code expects the compiler to do some things and the module loader is heavily based on CW libraries. Especially I'm sure none of the ASM code will work (that includes much of the NES emulator). You might be able to (with a lot of work) get it to work by rewriting the module loader altogether with PEAL (or whatever tha name was, can't remember, although LJX uses it ) though.

[palmdoogie]

Hello, Thanks for the info Tinnus. So, I actually obtained CodeWarrior 9.0 and applied the updates to 9.3(manually because the auto updater seems to not work, apparently because the server doesn't exist anymore). I also updated the Palm SDK to 5.0R3 and re-ran the Build All in between each step. I also located the Tapwave 1.1 SDK even though I'm not trying to build a Zodiac version at this point. I am now at the point where I get missing file errors on either MSL_C_PNO.a or MSL_C++_PNO.a which appear to be some missing libraries. I managed to locate them zipped in some other Palm program's source code(I'm assuming they're the same library). And I'm about to try again, however, I really am not sure how I am supposed to go about building the project(I'm trying RC2, RC7, and 1.01) Can I just use the "master make" button at the top toolbar? or do I have to use the side menu and build the various pieces one by one? If so, what order do I do these in? Any help on getting one of these to simply build in their stock form should set me on my way. I really just want to use this "LJP-Lite" exercise to get familiar with building sources and making slight mods to make things more efficient for My TT series units as well as learn how these emulators work on the way. I have changed my plans to simply making LJP-Lite only support the modules that run suitably on a TT and TT2 and have scrapped plans on porting to another IDE for the time being. Again, any help just getting the CW project to build would be greatly appreciated at this point. Thanks

[palmdoogie]

Got a little further in my compile - I fixed the Tapwave SDK messages by installing the SDK(of course). I'm assuming the MSL_Cx_PNO.a issues will go away as those files are in the Tapwave SDK although I may have to re-point to them. Now I'm having the "Error ; expected PINS_TRAP..." issue in PenInputMgr.h. Anyone know how to get past this one? Thanks

[palmdoogie]

Finally got 1.0RC2 Sources to build Thought I'd share the recipe here as best as I can remember it:

1. Stock install of CW 9.0

2. Update to 9.2

3. Update to 9.3

4. Then run the recommended Build-All project for the headers and libs

5. This installation will have the 5.0R2 version of the Palm SDK

6. Get the 5.0R3 Palm SDK - It will not install into the CW9 hierarchy properly - Just install it to a standalone folder. The most important pieces are (PALM OS Support) and (CW for PALM OS Support)

7. Do not follow the readme instructions as they are confusing.

8. Move the old PALM OS Support to a safe location (There is at least one runtime lib that is not in the new one(I forget) that you will need.

9. Place the new PALM OS Support folder in the CW root directory.

10. Optionally you can replace the CW for PALMOS support folder in it's entirety, but there must not have been significant changes as I didn't need to.

11. Get the Tapwave 1.1 SDK and install it "along side" of the directory with the LJP source.

12. Now, you should not have the ....PINS_TRAP error I was getting. One or more of the modules require moving PALM OS Support System path to the top of the list to work in the access path settings.

13. My last hurdle was some issue with the paths not allowing the LJP Multiple (basically the launcher code) from building because the equivalent command line extraction of the access paths was too long for windoze. Here's the crazy way I got around that:

13a Remove the Tapwave SDK path completely from the system access path.

13b Built LJP-Multiple - You will get errors on the Tapwave SDK stuff it couldn't find, but it does something useful.

13c Now add the Tapwave SDK back into the paths at the end - Try using absolute path.

13d Now build again and Voila! It builds! (At least it did for me )

Not too bad for a Hardware Designer, huh?

Now on to The RC7 (in a folder labeled rc3(1) for some reason) and the 1.01 Sources. There are new problems here. I started by trying to build the Empty PNO(LJP-Empty) Here, for some reason, I had to manually add the MSL_C_PNO.a lib even though the C++ one was OK. Then I was getting some error on ARM division (_s32_div_f and _u32_div_f). Here's a crazy one - I'm surprised I actually figured this one out, since I really have almost nil experience building CW projects - I stumbled on the object files on the web for the _x32_div_f ARM functions. Intuited that the appeared to belong to the ARMLet runtime library. Put them into the sources folder, and rebuilt that runtime library. Then The LJP-Empty PNO Builds! I' still getting errors on the real PNOs, but I'm working on that now. I hope archiving this info helps others out who may be having issues. I had a hard time finding Google references to these issues. I suspect the maintainers of this code had many layers of CW installs with various bits and pieces from older CW versions and SDKs which is why the downloaded sources don't compile simply by clicking Build on a clean install of CW. Once I get RC7 and 1.01 to build, I can move on to figuring out why the 10X slowdown happened on Post RC7c as well as building my "LJP-Lite" version for us T|T and T|T2 owners

[_Em]

Wow!!! Great summary; thanks for posting You've got further than I ever did... I only ever got as far as the MSL_C issue before I figured my time was better spent elsewhere

[luckyluke]

Congratulations.

If you want to build LJP 1.2 with wiimote support also I can inform you where I moved which SDK. I made all paths relative to the LJP project directory and the Codewarrior directory so that I can move this directories around without having to change the paths set in the LJP project again and again.

With moving the Codewarrior directory around some enviroment variables (with which Windows remembers paths global) get invalid but where a tools in the Codewarrior install directory to correct them quickly again. I was pretty surprised that CW is so "portable".

IIRC, the MSL_C issue occured sometimes for me and I fixed it by removing the affected files from the project and then add the again.

To make this clear. Even if I warned you not to start I´m very happy about everyone actually starting with developing and improving the LJP project!

[palmdoogie]

Well, I'm not sure most people would agree that I am improving it, I'm plan on just making a "Lite" version that doesn't include the emulators which don't run well on the older units(Like SNES and GEN on the T|T and T|T2), as well as stripping out a bunch of the filters that don't seem to do much good on the PALM screens other than to make them look fuzzy. So far, the only filters I've found worth keeping are the LQ2X and HQ2X for gameboy and I'll probably only keep the LQ2X since I couldn't see too much difference between the two when playing Super Mario Land. Another of my goals for LJP-Lite is to make the now reduced options all fit on one screen like a simple checkbox to turn filtering on/off. Some settings will be fixed - Like 1.25x Size with maybe just a checkbox to enable/disable the toolbar. If PALM has any notion of Tabs in its UI, I'd love to change the emulator selection from the pulldown menu to a tab selection. I plan to only keep the four mainstream emulators which appear to work well on the older units - NES, Gameboy, SegaMaster System, and VCS. If I manage to boil down the code to having minimal dependancies on the Metrowerks Standard Libs, I'd love to port this to PRC-Tools for OS-X, provided I can find a substitute function for the MSL calls. One step at a time. For me this is a fun exercise to get the ins and outs of complex interdependent software projects prior to possibly porting this stuff over to the iPhone where it might live on further

By the way, I now have gotten to the point where I can get the RC7 sources to build into the proper pieces, but they don't all run correctly when I install them. NES and GB think there are no ROMS, SMS runs, but without sound, and VCS appears to work fine(as fine as it worked before at least). I'd like to figure out where I went wrong, but I moved onto the 1.01 sources to see if I can get them building. The Problem I have in 1.01 has to do with CW thinking alot of the MSL functions are being redefined with different datatypes for one of the arguments. The functions are ones like memcmp and such and the issue seems to do with the size_t typedef changing during the build. Sometimes it is "unsigned int" and sometimes it is "long". Funny, If I change size_t.h to force the size_t typedef to be one, the redeclare error complains about the other type and vice versa. I'm not sure how that is happening, but I think I am being led astray. I may go back to figuring out why my RC7 binaries are broken and fix that, then introduce the 1.01 changes incrementally into the RC7 project. I had planned on doing that anyway to figure out why all of the builds after RC7b run S-L-O-W on a Tungsten T2, even though they run fine on the TT1(See my other topic)...

[palmdoogie]

Update: Got RC7 to build binaries that work now. I did a clean install and started from scratch on both the CW tools and the SDK/Sources. I must have gotten a "bad build" before as now all of the modules work as expected. I verified that this version still runs at the proper speed on my T2 as well. So now I have to figure out how to get the 1.0.1 sources to build. I'm getting a lot of

Error : identifier 'memset(void *, int, unsigned int) redeclared
was declared as : 'void * (void *, int, unsigned int)'
now declared as : 'void * (void *, int, unsigned long)'
...
...
cstring line 33 L memset(void *, int, size_t);

I'm getting pretty much the same error for MemCmp, memcpy, StrLen, StrNCpy, StrCompare, StrChr, calloc, alloc, realloc,...

I have no idea whats going on here, but I'm going to compare sources and paths for one of the modules between RC7 and 1.01 to see if I can catch what happened...

[palmdoogie]

Another breakthrough! The Redelared errors I was receiving above was due to some zlib related headers that were in the TG16 directory! Since I don't want TG16 support in LJP-Lite, I removed the Files and target from the CW project and deleted the LJP-TG16 source directory(important, since it was still finding the header file there). Now I got the ZLIB.prc to build and I'm pretty sure this will clear up all of the modules. The filters library already builds with no issues, so all that is left is the LJP-multiple(Launcher) code! Yay

[palmdoogie]

Okay, I got the 1.01 sources to build. One final step before I embark on my LJP-Lite efforts. I'm going to merge in the 1.01 sources incrementally into the RC7 tree and figure out which portion is causing the slowdown on the Tungsten T2...

[countbuggula]

While you're doing that you could also look into figuring out what causes certain SNES games like Super Mario Kart to stop working post RC7.

[_Em]

Heh... great minds think alike I happen to know that Henk did an SNES core upgrade that broke those games; he was never able to figure out why, as that core runs them just fine on other platforms.

[palmdoogie]

If someone can get me the sources for 1.2, I can try to revert the SNES module

[palmdoogie]

I've now officially started development of LJP-Lite I'll be starting a new topic for this project...

[countbuggula]

May 7, 2009 3:01:28 GMT 1 palmdoogie said:

If someone can get me the sources for 1.2, I can try to revert the SNES module

I can't find a link to the source anywhere, so I emailed Metaview asking for a copy. Hopefully the address I had is still current.

[metaview]

It is Nice avatar, btw.

[countbuggula]

May 7, 2009 21:23:13 GMT 1 metaview said:

It is Nice avatar, btw.

Hey, thanks. It's one of my wife's painted miniatures - she does amazing stuff.