LJP-Lite in development now!

[haisook]

By Sega SMS, do you mean Sega Game Gear as well? Because I regularly play the latter. I hope so..

[haisook]

Not a single update in more than 4 months, I think this project is dead, sadly.
RIP LJP-lite.

[janisl]

thats too bad! Ive been following its development from the start

[luckyluke]

Well for my part:

I've replaced my Centro with an Android OS phone now. So don't except me coding for Palm OS any longer. With WebOS Palm decided to bury this great OS. Anyway I think that this decision was really wise since Palm OS was simple to old fashioned compared to other operating systems.

[palmdoogie]

Hey, what happened to my post that had screenshots of LJP-Lite showing the simplified UI and the new beltbar? Did the post get lost in a server crash, or did they get pulled due to some violation of terms?

[palmdoogie]

Wow, So I stumbled upon my archive of LJP-Lite Development code on one of my VirtualBox HD images, and lo and behold, after 3.5 years, It still compiles! After doing a TON if Diffing between the various versions, I think I remember what I was working on last AND I found some of the screenshots that I had originally posted here that had somehow disappeared. Instead of asking if anyone is still interested in this dinosaur, I thought I'd just post the pics and see if I get a reaction.

[palmdoogie]

Looks like I was farther along than I remembered! The only major task I see left is to finish incorporating the LJP Beltbar into the MAME module and a small number of clean up tasks including figuring out how to pull the MAME codebase into the main LJP Project. For now, I still have to compile the MAME module in a separate project directory with it's own .mcp file as there are some dependency conflicts with the LJP source base.

[palmdoogie]

Oh, also as evident from the pic above, I need to change the white background of the MAME icon from white to transparent mask. Hopefully GraphicConverter will be able to do the trick!

[tesla75]

Wow, nice. I actually just came here recently to download the sourcecode and look through it since I am finally able to code half decently. I also wanted to make a point to my friends that a palm pilot from 2004 could run emulators as well as their android phones now which they claimed is only possible to run smoothly with at least a 1Ghz processor. I used this app so much as a kid and was always impressed by how well it worked.

[palmdoogie]

I haven't really kept track, but I believe mine (LJP-Lite) Was branched off of either LJP 1.01 or 1.0rc7. I recall that one of the newer versions ran really slow on a Tungsten T2 for some random reason that I never figured out.

I've made quite a bit of progress since I last posted. I've managed to get the LJP-MAME Module to be part of the LJP-Lite master project. I had to rename some files to eliminate conflicts and I've started finding shared code between the LJP Console PNOs and the MAME PNO. One of the first things I notices was that the both used slightly different versions of ZLIB. I managed to get MAME to like the newer version that the console PNOs were using. Then I started to figure out how to combine and eliminate some of the static libraries. What I'm working on right now is eliminating the MSL_C_PNO library from the MAME module by using existing functions shaed by the console modules. I have it down to the memory *alloc and mem* functions and file I/O. FOr some reason, when I try to use the console versions, MAME craps out. I may need to add some temporary debug code to see what's going on.

Once I finish merging shared functions, I'll get back to the mostly final task in the MAME module which is incorporating the BeltBar. There won't be Save or Load for MAME, though as the version of Pmame I used, didn't have that working yet. But the BeltBar display with battery, FPS, and Clock along with Reset and Exit will be implemented. I may need to add a new beltbat resource graphic with the load and save greyed out for MAME.

The main task involved in the above functionality is bringing the full implementation of the PNOBridge as the consoles use it. MAME decided to use alot of native PNO calls for screen size and other parameters that are passed into the console modules from the 68K side via the pnobridge struct. The beltbar relies on these for getting environment parameters as well as the raw VRAM address.

I have some of the beltbar kludged in and noticed something funny. My BeltBar draw routines for the consoles seem to treat the screen as 160x160 doubled for beltbar drawing (The battery icon for instance). WHen I use the same code to draw the battery in MAME, it is half the size and in the middle of the screen. For some reason, the same commands executed within the MAME environment act on a full 320x320 resolution. Maybe when I pull the pnobridge stuff in it will behave like the console modules do.

BTW how do you like the new beltbar icons and battery fuel gauge? The outline of the battery gauge changes color as the battery runs low, from Blue to Green to Yellow to Red. There's also a different color if it's charging, but I forget offhand...

OK. Thats all for now, but I'll keep you all posted. Welcome back!

[palmdoogie]

If there's anyone on this board who is familiar with the LJP Code, can you answer a question for me?

What's the deal with the stack that is allocated in PNOmain.c? There is a chunk of memory allocated, swapped, and filled with garbage data(for the purpose of determining how much was used after execution). The pointer to the stack is: my_stack. But no where else in the entire code base is that pointer ever used. Is this stale code or does it have some other purpose or some sneaky way it is being accessed? I'm going to comment it off and see what happens for now, but I'm just curious as to it's orgin.

In the meantime, I've made a lot of progress under the hood in getting the MAME module to look more like the other console modules. I had forgotten how much hacking I originally did to shoehorn it in there, including making a separate custom PNOMAMEmain.c for the ARMlet as well as a bunch of different handling in LJPMain.c on the host side. Among other things, the passing of data and functions between the consoles and the original PMAME was quite different. The LJP Modules use a small handful of FTR pointers to pass simple parameters to the PNO while also utilizing a "Bridge" data structure and passing a pointer to it in the PNO call. PMAME on the other hand, made heavy use of FTR calls and instead of passing a pointer to a bridge data structure, it passed a Tapwave Glue pointer in order to access Tapwave functions in the 68K domain. I'm not sure why this was done as I see Tapwave function calls being made directly from many of the LJP Console PNOs. Why you would ever want to call them in the 68K domain is beyond me. The point is Moot for LJP-Lite, however, as I have stripped all Tapwave native functions from it. You can still run it on a Zodiac and take advantage of the larger screen to some extent, but Tapwave only features are not being implemented in LJP-Lite. I may add some back in in he future if it helps speed up the execution(read: rendering) on a Zodiac, but for now I wanted to distill the code down to it's simplest form.

Once I finish making MAME work with a common PNOmain function, the only major feature left is to cleanup the BeltBar implementation on MAME, and then squash a handful of bugs. Also, NES has a memory leak I need to track down. Surprisingly, none of the other modules seem to leak.

One more thing. The more I test this, the more I realize that the Atari VCS module is a huge turd! It is not at all up to the quality of the other modules. Many games don't run properly. Some don't render correctly. The audio is crap. It's just BAD. Now that I am understanding how the generic emulator engines have been threaded into the PALM OS specific user interfaces, I may just try and get a high quality Atari Emulator in to replace the existing VHS emulator. Of course, for me, the only logical choice is "Stella", which seems to be an extremely mature and robust Atari emulator. I hope that it won't be too difficult to make it work with LJP. At the same time, I hope it's not TOO easy, either, cause I want a new challenge

[palmdoogie]

Wow! Things are coming together fast, now! I've got the MAME Module to share the PNOMain.c routines albeit with a little #ifndef-ing to exclude stuff that MAME doesn't use yet. I also have the beltbar mostly working in MAME, but the only functions so far are reset and exit. I don't think the MAME source I was working off of had save/restore, so I'll have to gray those buttons out or something.

I came across another strange difference. LJP consoles use 68K Host Callbacks to do all of the sound stream creation, deletion, starting, stopping; while MAME calls the functions from within the PNO. Am I missing something here? Does that mean that the LJP Consoles are executing emulated 68K code for sound stream management? It's not clear if any of those functions actually affect the sound rendering, so maybe it's not a big deal to have them run in 68K code if they just manage pointers and registers. Having them reside in the Launcher Host prevents having to replicate them in the PNOs which would make each module larger in size. I'll probably take a shot at having the MAME module utilize the callbacks just to keep things uniform.

Also, I downloaded the source code to Stella, the excellent ATARI VCS emulator, but was surprised to see that it is written in C++ and utlizes SDL. I can probably replace all of the SDL stuff with whatever UI and rendering routines that I'll need to make for the Palm Port, but it would be better if there was a version in the past written in straight C. I'll hunt through the sourceforge archive. I probably don't need the latest version as versions that I ran close to 10 years ago performed great with all the carts that I had. Later improvements including OPenGL rendering won't be needed (or possible) on the Palm. I guess I'll start with seeing if I can get the core engine to compile in a separate project in CW first, then start adding the Palm hooks, and then the LJP stuff.

In the meantime, I think I'm just about ready to call LJP-Lite a Beta! Not sure where to host it though as the original little-john.net appears to be in limbo, with a solitaire game and the word "Patience" at the top suggesting that something new might be coming? I'll figure out somewhere to post it, eventually. The more clamoring I get from anyone here, the more likely I am to set up a place to host the download, so clamor away

[fireproof710]

Hey guys,

New to the forum, but not new to finding uses for old palm devices

When I was in college, I had a palm Centro. I had LJP on it and I played SNES like champ between classes. Since college, I still enjoy the occasional bout of Nintendo-nostalgia, but no longer have the Centro. I had been using a Lifedrive, but couldn't get SNES working. It would always crash from memory issues. Yesterday, whilst perusing in my local Salvation Army, I scored a nice condition Palm TX for $7 that's right $7. Hard to believe that these suckers were as expensive as they were, and now you can practically give them away.

So I can't get LJP to work on the TX and it's sad to see that a lot of the old websites that hosted palm apps are going the way of the dinosaur. LJP 1.0RC doesn't work on the TX and I was wondering if you might (via media fire or some other means) send me a beta version to test out?

Also, if anybody by some off chance knows where I can download the app "Files" which was developed by PalmOne, I would be ecstatic. The life drive came bundled with it, but I can't copy it to the TX 'cause it's locked. I tried FileZ, but it won't seem to let me move whole folders around and ITS DRIVING ME NUTS.

[palmdoogie]

Mar 27, 2014 16:39:03 GMT 1 @coder12 said:

Not sure what's going on with the LJP page—if you need a place to host it, I can give you server access and an ftp account on my server. It's great to see your developments!

Thanks! Maybe that would be a good place to post it. Just let me know in a PM. You could just make a guest access dropbox even. I'll start with just depositing the latest binaries. I intend to make the source available later, but I want to clean up a few more things first.

[palmdoogie]

Apr 1, 2014 12:33:32 GMT 1 fireproof710 said:

Hey guys,

New to the forum, but not new to finding uses for old palm devices

When I was in college, I had a palm Centro. I had LJP on it and I played SNES like champ between classes. Since college, I still enjoy the occasional bout of Nintendo-nostalgia, but no longer have the Centro. I had been using a Lifedrive, but couldn't get SNES working. It would always crash from memory issues. Yesterday, whilst perusing in my local Salvation Army, I scored a nice condition Palm TX for $7 that's right $7. Hard to believe that these suckers were as expensive as they were, and now you can practically give them away.

So I can't get LJP to work on the TX and it's sad to see that a lot of the old websites that hosted palm apps are going the way of the dinosaur. LJP 1.0RC doesn't work on the TX and I was wondering if you might (via media fire or some other means) send me a beta version to test out?

Also, if anybody by some off chance knows where I can download the app "Files" which was developed by PalmOne, I would be ecstatic. The life drive came bundled with it, but I can't copy it to the TX 'cause it's locked. I tried FileZ, but it won't seem to let me move whole folders around and ITS DRIVING ME NUTS.

No idea on where to get FileZ, but I gotta believe a google search should turn up something. I considered picking up a Tungsten T5 or a TX to play with, but ultimately decided against it. You may be disappointed to know that SNES was one of the modules I pulled out of my "Lite" version of LJP as my initial desire was for this to be run on units like the T|1 and T|2, on which the SNES ran far too slowly.