Fourth LJX PalmOS POC (Feb 11 update on pg. 3)

[Tinnus]

New version coming soon, with faster filters and .ini configurations

[icefire]

YAY for LJX!

Does it support Zodiac :-)?

[semi]

tinnus said:

New version coming soon, with faster filters and .ini configurations

Wow! that's fast! you rule Tinnus, can't wait to see how the faster filters would work out

[Tinnus]

icefire said:

YAY for LJX!

Does it support Zodiac :-)?

Yes

I'm still trying to add something you guys would like before releasing it

[Tinnus]

OK, I didn't quite manage to get sound working unfortunately, but here's a new version anyway

www.little-john.net/files/lj-palm-poc3.zip

Changelog:
- Uses .ini files now, new emudata.ini provided. Must be in the same place as the old .dat file - /PALM/Programs/Little John (no, I've not changed it (yet?)
- Changed the way screen modes are handled. Now you can choose between normal, double (not available for NES), full aspect and full stretch. A new configuration in the

[countbuggula]

Works great so far! Haven't done any speed testing yet, but I played around with some of the settings and haven't had any problems so far.

Does vsync work on a Palm? It doesn't seem to make any difference enabled or not (I still see screen tearing). Thanks for changing it (even temporarily) to use an ini file! Resco has no problem with it.

[Tinnus]

Vsync doesn't do anything in PalmOS

[countbuggula]

Ok, thanks. I didn't think it would, but had to try when I saw the option in the ini.

[icefire]

Works on the Zodiac.
With full screen, it rocks! If just for the cool factor of LJX, im using it instead of LJP!

Go Tinnus!

PS: The ini settings are much better.

[samphex]

Wait so you think the nes of ljx is better than ljp's nes? that means we are progressing . Only several more consoles to go!

[contradude]

hey icefire, my zodiac is currently out of commission because my mac is down and I can't sync to it but do you think the rendering in ljx is better, worse, or about the same as ljp?

[Tinnus]

I don't use the Zodiac stuff yet, so it's slower adn there's no hardware smoothing filter. Also, there's still some stuff to be optimized for everyone (all Palm devices)

[icefire]

No, all i meant is that i think it is cool to be able to use ljx at all...

btw, i set the rom path to /nesem/mario3.nes and it worked the same.

Tinnus: where is the hardware filter fit in the ini file? the filters section is all full... In one called hwsmoothing=1 or something?

[notans]

E2: mikepout.zip
fps: 50-65
Glitches= top of glass joe's head lags
Filter= Default

Z31: megaman.zip
Fatal exception (did set res to 160x160)
after that would say Please wait... and return to the main screen

Edit: there was no sound

[Tinnus]

icefire: As I said, it's not implemented yet, but when so it will be filter #10 (actually it's already coded in the configuration, just not implemented).

[icefire]

No, im just an idiot for thinking that inis can only accept 0-9.

[Tinnus]

Do I hear "new version"?

www.little-john.net/files/lj-palm-poc4.zip

Changelog:
- SMS/GG module! Yay! Now we can finally play Sonic. Now, what happens here is the following: we now have 2 INIs, emudata.ini.sms and emudata.ini.nes. Originally it would only be one INI at a time, but to ease me and you testing I made each module load from a different INI file. They're still regular INIs, just renamed BTW, you can still keep your old emudata.ini for NES with your controls/settings, but it shouldn't hurt to get this one just so I know what settings you're probably running at (if anything, just copy over the key codes).
- Usage: Copy the 2 PRCs to your RAM/NVFS/Card/HD/CFlash/Stick/whatever and the 2 INIs to /PALM/Programs/Little John/ . Put your roms, preferably in Little John/NES/Roms/ and Little John/SMS/Roms/ or just put the full path like "/NesEm/mario.nes". A "full path" is something that starts with a slash ("/").
- You can pretty much use the same INI for both SMS and GG, the keys are basically the same with changed names (pause/start).

- New BIG feature: will let you find out.

- Note: I left some debug messages popping up before the game begins. If you get a crash while loading, try to see what the last message(s) was(were) and tell me along with the report. Note that you will probably need UDMH for anything below T|T3 or the new Treos, and that includes the NVFS folks like TX and LD, since I've not yet implemented the UDMH stuff

Most likely is a crash in NES after "pat-to-pix" and a number like "0x12345678". If that number is 0x00000000, it means you're out of memory and have to do the usual stuff.

(this thing is a 2MB allocation in the NES PPU code ;D It used to be in feature RAM in LJP but I've not bothered since eventually it will work like UDMH and all RAM will be the same)

Now, the technically impaired, just go play, er test, and let me tech-babble a bit.

-------------- Begin Low-Level Programmer Talk --------------

So, peal + arm-palmos-gcc uses R9 and R10 to store some magic values so we can have globals. CodeWarrior used to do this as well. That's cool and all, unless we want to, for example, use some assembly code (in the case of some CPU cores, for example), OR do something useful with sound streams.

What happens here is that the sound stream callback runs in another thread+context, and so R9 and R10 are completely different and useless, so you can't see anything outside the callback or call any functions. Cool uh? Only darn thing you have is that userdata pointer.

OK, no more!

yoyo/skeezix created some magic back in the day for use with CW. That was, save R9 and R10 from the original thread to a static struct, and pass its address as userdata to the thread. In the thread, push R9 and R10, restore them from the struct (which address is in userdata), TA-DA! use globals, fill buffer, pop R9 and R10.

Now, that solution worked well for CW, but gcc's asm syntax is a bit different. Moreover, I wanted a bigger level of control so pushing and popping weren't that good an option. After bang'ing the head a bit, here's the final code that copy-paste-works for having your context back in ARM native callbacks using peal+prc-tools:

//that's a global somewhere
static volatile struct
{
UInt32 r9, r10;
UInt32 r9_saved, r10_saved;
} reg_sys;

(...)

//creating sound stream -- note the userdata and the '1' for ARM native callback...
SndStreamCreate(&snd_stream_ref, sndOutput, rate, format, channels, MySoundCallback, ®_sys, buffersize, 1);

//this goes somewhere before you start the sound stream... saving R9 and R10
asm volatile(
"str r9, [%0]\n"
"str r10, [%0, #4]\n"
: : "r"(®_sys));

(...)

//and this is the sound callback function.
Err MySoundCallback(void *userDataP, SndStreamRef stream, void *bufferP, UInt32 frameCount)
{
asm volatile(
"str r9, [%0, #8]\n"
"str r10, [%0, #12]\n"
"ldr r9, [%0]\n"
"ldr r10, [%0, #4]\n"
: : "r"(userDataP)); //userDataP = ®_sys

//just do your stuff filling the buffer

asm volatile(
"ldr r9, [%0, #8]\n"
"ldr r10, [%0, #12]\n"
: : "r"(userDataP)); //userDataP = ®_sys
}

Cool eh? The SDL port I got used to do something very ugly. It used a pointer to a 68k callback, gotten after the PNO was loaded, then in 68k it used PealCallback to call back to the ARM function which would then do the thing.

I prefer my way though! And best, it works while I couldn't get the other one to

[Tinnus]

Stretching the image in the Zodiac is very likely to be very overkill, yes (unless using the HW scaler, of course, which I didn't implement yet ;D )

But it should be playable enough on scren mode 2 with auto FS.

Unfortunately I couldn't get any of the ASM code for NES to work yet

[tgwaste]

hi,

nes

so trying screenmode 2 with frameskip 0 and no filters with sound on I get about 47 - 51 fps which is just a tad sluggish. I get lightning fast on LJP with the equivalent settings. Are there some optimizations still left to come maybe? Maybe the fix over scan (which is awesome btw) is making things slightly slower?

sms/gg

works good, tested sonic(sms) and megaman(gg) and both work great. i get about 58 - 63 fps during game play. using fs 0 sm 2 fltr 0
will not play .zip'd games


i also noticed that there are two volume settings in these .inis.. whats the other for?


the .ini was a good idea. being able to edit using resco and launch using the same is very convenient.

[Tinnus]

tgwaste: LJP is using an assembly function for scaling 1.25x the image. LJX didn't quite incorporate thsi yet, so is using a C function (that scales to any size) to scale something like 1.3x

Yes .zips won't work due to the way it uses the file extension to gues if the cart's SMS or GG. I'm gonna work around that.

The "volume" setting that's just above the ROM filename is for file volume (card number) but it's not used at the moment either.

[icefire]

I actually like LJX's GG and SMS way better than LJPs -- more stable, but a bit slower.

[Tinnus]

Certainly it's a lot more stable And slower because I don't use any of the ASM or Zodiac-specific stuff.

[icefire]

But still playable.
Are savestates implemented?

[Tinnus]

Should work, although they save to the wrong place. Just bind some useful keycode to "quicksave" and "quickload" at the bottom of the INI. (they use the same format as the emulated keys)

[tgwaste]

you should get the treo keyboard secret from metaview and pop that in

[Tinnus]

One of these days, yes. There's a list of stuff to add to the PalmOS framework yet

[icefire]

Are the screen places implemented? Like bottom right, upper left, etc?

[Tinnus]

Screen buttons? No. I don't check pen events whatsoever for anything yet.

[icefire]

Two things:

1) For UDMH-ness, you could look at lukas-grundmann.de1.cc/MoreHeapHack/ for inspiration. It is a clone (but in Palm Pascal, but still worth looking at?)

2) I think
LJX needs it's own forum. Can someone find yoyo and have him make one? or should it go somewhere else? or should it just stay in the LJP forum?

[samphex]

it should l stay in ljx. but if things are going to be completly different i guess a subforum should be made(look here forums.explosm.net/forumdisplay.php?f=49 it has another forum on top)