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

[Tinnus]

Well, the guy who originally changed that in LJP had a Zire 31.

Anyway, I think I'll just add KeySetMask to the code then, later someone with a Zire 31 could complain

[Zer0linK]

its a shame that my zire31 is dead.


tinnus could you specify wich numbers are wich screen modes?

[Tinnus]

I did, read the post where I posted the second link And the other a little below where you can clearly see which are the lines.

[Zer0linK]

screen modes on tungsten T:

double: works but no changes ( like you said)
fullscreen/aspect: works
fullscreen/stretch: works
fullscreen/stretch/fixoverscan: works

with screen modes on, fps goes down to about 33

PD.: I may be testing filters in a while.

[tgwaste]

we really need some filter tests... to see if im crazy or not

like mode 3 filter 6

[Tinnus]

Zer0link: you mean 33 FPS with filtering in "0"? Hmm since you said it was 37 in 1x mode, that doesn't seem so bad, especially considering that' the generic-C-unoptimized version

I'll add the assembly 1.25x blitter from LJP later, that should really speed things up

[Zer0linK]

yes, no filtering in that tests.

[_Em]

320
480
0
0
NES/Roms/kirbyadv.nes
NES/Saves/
0
4
5
1
1

Device: Palm T|X
Processor Speed: 585MHz

HQ2x seems to work well, as does 4-fullscreen/stretch/fixoverscan. I got 17-20fps.

I've got a few suggestions:
1) how about changing the Palm/ folder name to LJX instead of Little John? It's easier to type on a Palm and makes for a more compact string/path.
2) the SRAM file saved into the Little John folder instead of NES/Saves.
3) Block comments: in the emudata.dat file, can you put # or // at the end of a line and ignore anything beyond that? That way, we can comment each line in the config file, which would make editing it MUCH easier.
4) editing emudata.dat seems to cause the reset issue. Are you handling both CR and LF when parsing it? After making an edit to the file using Resco Explorer, I get a reset each time I launch.

[tgwaste]

em said:

320
480
0
0
NES/Roms/kirbyadv.nes
NES/Saves/
0
4
5
1
1

Device: Palm T|X
Processor Speed: 585MHz

HQ2x seems to work well, as does 4-fullscreen/stretch/fixoverscan. I got 17-20fps.

I've got a few suggestions:
1) how about changing the Palm/ folder name to LJX instead of Little John? It's easier to type on a Palm and makes for a more compact string/path.
2) the SRAM file saved into the Little John folder instead of NES/Saves.
3) Block comments: in the emudata.dat file, can you put # or // at the end of a line and ignore anything beyond that? That way, we can comment each line in the config file, which would make editing it MUCH easier.
4) editing emudata.dat seems to cause the reset issue. Are you handling both CR and LF when parsing it? After making an edit to the file using Resco Explorer, I get a reset each time I launch.

comments: 1 -> 3 I heavily agree with!

I think #4 is why im having the problem I am infact using resco to edit the .dat file. so we just need to ignore CR/LF (and #) and were set.

[countbuggula]

tgwaste said:

comments: 1 -> 3 I heavily agree with!

I think #4 is why im having the problem I am infact using resco to edit the .dat file. so we just need to ignore CR/LF (and #) and were set.

Ah, that's probably what's causing the reset on mine too! I'll put back the unmodified file and try with mario3 to see if it works.

[countbuggula]

Yay! It works with the unmodified emudata.dat file. No more crashes!

I guess I'll have to try the other screen modes when I can get home and have access to my card reader, since I obviously can't edit with Resco Explorer.

[_Em]

Try editing with Tejpwriter instead; it handles CR/LF line endings properly.

[Tinnus]

em said:

320
480

This will not make it use the entire screen (yet)

HQ2x seems to work well, as does 4-fullscreen/stretch/fixoverscan. I got 17-20fps.

HQ2X is too slow. Have you tried LQ2X?

1) how about changing the Palm/ folder name to LJX instead of Little John? It's easier to type on a Palm and makes for a more compact string/path.

Maybe, but I don't know if LJX will be the final name

2) the SRAM file saved into the Little John folder instead of NES/Saves.

I'll look into that.

3) Block comments: in the emudata.dat file, can you put # or // at the end of a line and ignore anything beyond that? That way, we can comment each line in the config file, which would make editing it MUCH easier.

No. It's not meant to be edited directly, and moreover I'm probably switching to .ini files anyway.

4) editing emudata.dat seems to cause the reset issue. Are you handling both CR and LF when parsing it? After making an edit to the file using Resco Explorer, I get a reset each time I launch.

I'm going to check that out as well, was giving me a hard time before already...

Thanks again!

[_Em]

Any chance you can move to an XML file? This would make it much more user-readable, and would also be more portable between versions/platforms. Support for binary XML would be an added bonus

[countbuggula]

em said:

Try editing with Tejpwriter instead; it handles CR/LF line endings properly.

Thanks! I tried that and it worked for me.

Here's my preliminary results (I'll try and test more from home later)

Treo 755
UDMH enabled (probably don't need it though)
Lightspeed set at 234-585
castlevania3

Screen Mode, Filtering:
0,0 - 58 FPS
2,0 - 58 FPS (pixels)
2,1 - 44 FPS
2,2 - 35 (nice)
2,3 - 27 (nice)
2,4 - 31 (nice)
2,5 - 29 (nice)
2,6 - 36 (nice)
2,7 - 44 (ugly)
2,8 - 42 (mediocre)
2,9 - 56 (nice)

[Tinnus]

em said:

Any chance you can move to an XML file? This would make it much more user-readable, and would also be more portable between versions/platforms. Support for binary XML would be an added bonus

Let me say it again--it's *NOT* meant to be user-readable. This emudata.dat file is only meant to act as a bridge between the launcher and the emulator, so XML is to much of an overhead, moreover I don't need that much flexibility hierarchy-wise.

What we have at the moment is just the emulator side, and because of that we are forces to edit those files by hand; but this shouldn't be the case at all in the final versions.

Moreover, as I said I'm switching to INI since there's libiniparser, which is extremely lightweight, easy to use, and still INI has good features that make it robust, and if we ever have to edit it there will be "config = value" settings, and support for comments as well

[samphex]

I know this is extremely off topic but ljx sounds cool. It could be Little John eXtreme or something lke that.
lol

[_Em]

Welcome (late) to the party

[tgwaste]

hehehe

[icefire]

It also froze 4 me on zod and zire 72, after 45 sec or so.

the 5-way didn't work on zire w/ default settings, but i didn't have time for tellkeys

on the zod, the tellkeys gave two numbers, one for a sec and then another one. I only used the first number. btw the first number and the seccond were different for each button.

About the launcher i would make: I cant figure out how to open vfs files and edit them, might try more soon.

[Tinnus]

BTW, for the PalmOS version I'm probably going to put the emudata.dat stuff in a feature pointer (RAM) instead of a file (once there's a launcher), since that's a good way to not have problems with different volumes, and additionally I don't need write-enabled space on a card to do it Although for most systems a file's still probably the easiest way.

edit: also, can anyone confirm that it does NOT freeze after a minute or so? Is anyone willing to play some Mario for 10 minutes?

Maybe it's freezing just because of the key mask thing, it's putting all the key presses into an event queue which I'm not handling, and then the queue just gets full and screws everything else up.

(BTW, I've masked keys already for next version)

[icefire]

it froze when i pressed function on my zodiac, and on the borrowed zire 72 after a unknown amount of time (i think around 2 minutes?)

edit: CardTXT also works for EmuData.dat

I also like the INI idea, but not the ram file. If ljp.ini was a normal ini, something that i wanted, then it would be easier.

Some people like to mess with ini settings :-)

edit2: how would the roms work without a card on a palm? PDB-roms?

[Tinnus]

No, I'm seriously thinking about dropping the work needed to support card-less people. A card is so cheap now, that I can see no reason not to have one, except if you have a Z22. But then again, you should have gotten a Zire 31 in the first place, heh.

Now about you not liking the RAM thing, I'll say it again. THIS IS FOR THE TEMPORARY INFORMATION TRANSFER BETWEEN THE LAUNCHER AND EMULATOR! *Not* permanent settings. Those will also be .ini but will be stored in the card permanently.

[Zer0linK]

I just played super mario with fullscreen/aspect for over ten minutes , no crashes.

BTW, I can edit emudata with resco explorer.

and, if the permanent settings are stored in a .ini file, that also should be only problem of the launcher. am i right?

[Zer0linK]

testing filtering on my tungsten T:
(all in screen mode fullscreen/aspect)

1: 15 FPS
2: 13 FPS
3: 9 FPS
4: 10 FPS
5: 9 FPS
6: 15 FPS
7: 20 FPS
8: 20 FPS
9: 16 FPS

[Tinnus]

zerolink said:

and, if the permanent settings are stored in a .ini file, that also should be only problem of the launcher. am i right?

Yes. What matters to the emulator side is it receiving the data *for that emulation go*. Although the emulator framework may change settings in-game, and those will be written back to emudata.dat (or feature mamory) and the launcher should save them back for that particular game.

[icefire]

Now it get it. So the default settings are an ini, but the settings from the launcher are a ram file?

[semi]

tinnus said:

metaview said:

Well, I thought we talked about KeySetMask...

Ah, sorry I thought you were talking about why it crashes, heh.

Anyway, I don't have a clue why it's this way, but it seems KeySetMask, in the Zire 31, also masks KeyCurrentState in addition to events.

semi and Zer0LinK: could you test the different screen modes? Just semi: could you try without overclocking, just to be sure?

Thanks for the feedback

Ok, I'll try that later, just got back from work and getting a day off tomorrow to test it.

[semi]

Just finished some tests, here are the results Tinnus
and please note that the FPS I put here are the lowest to highest I see in the whole game, which includes start menu's FPS.

Also, I tried the LQ2X on a (0-2-6) setting with CPU running at 400Mhz (which is my NX80V's maximum) and I get only around 32~36FPS, even less than the (0-2-9) setting, so I've given up testing the LQ2X settings, I don't know if I want to try other filtering settings though... maybe when I get the free time.

Note that I've put how many times I get a unit-freeze during the game on the results below, I don't know exactly the cause, it could be overclocking, but then again, like I said before, on LJP, any emulator with any games, I hardly get ANY freeze, very rare (note that I always have LJP running at 400Mhz), even when I play movies on TCPMP (again, 400Mhz), I rarely get any freeze, so I don't know what's really going on, or how it is different from LJP.

Game:Excitebike (E).NES (1st level, no opponents, solo run)
SONY Clie NX80V @200mhz
=========================
Line7(Framskip), Line8 (Screen Mode), Line9 (Filtering)

(0-0-0) 43~46FPS
(10-0-0) 58FPS
(0-2-0) 36~42FPS
(10-2-0) 58~61FPS (With noticeable screen skip-lag, playable)
(0-2-9) 21~23FPS
(10-2-9) 58-61FPS (With noticeable screen skip-lag, playable)


SONY Clie NX80V @300mhz
=========================
Line7(Framskip), Line8 (Screen Mode), Line9 (Filtering)

(0-0-0) 58FPS
(10-0-0) 58FPS
(0-2-0) 58FPS (5~10s froze *2)
(10-2-0) 58FPS
(0-2-9) 30FPS
(10-2-9) 58~61FPS (With noticeable screen skip-lag, playable)


SONY Clie NX80V @400mhz
=========================
Line7(Framskip), Line8 (Screen Mode), Line9 (Filtering)

(0-0-0) 58FPS (3s froze *2)
(10-0-0) 58FPS
(0-2-0) 58FPS
(10-2-0) 58FPS
(0-2-9) 39~47FPS
(10-2-9) 58FPS (With hardly noticeable screen skip-lag)

[Tinnus]

icefire said:

Now it get it. So the default settings are an ini, but the settings from the launcher are a ram file?

At the moment the data from the launcher to the emulator is in .ini format, and will be for most platforms. But for PalmOS, maybe I will change it to use a feature pointer instead because this is more fail-proof for multiple cards and stuff like that.