Zen X-Fi2 Lua Programming Wiki

[ThievingSix]

Now that we have a nice pretty section thanks to EnzoTen I'll kick it off.

I've been working on indexing and figuring out all the functions available to use for application creation(and maybe more !).

Here(http://en.wikipedia.org/wiki/User:Thieving6/X-FI_2_Lua) you will find many things. A full function list, examples(soon to come), tutorials(soon to come), and more.

You might notice a 1.1 Whats needed section that lists some things that need more information on. If you have something to add, please do! I only ask you to follow the format already shown so I don't have to follow up. Once the Whats needed section is done I have planned the creation of a virtual test ground for testing lua scripts on your PC. This way you don't have be going back and forth to your player.

I encourage everyone to try and develop applications! Not only will it broaden your view and make your player special, you'll probably make something someone else is interested in!

[CrowdAds]

[Jan_DK]

I was looking at the PSP lua wiki.

http://forums.qj.net/psp-development...-snippets.html

Wauw alot of nice functions in that thing.

[Theodore]

I think a sticky thread would be useful to hold the things that aren't included in the official API documentation from Creative.

I'll contribute this one for now: Despite the explicit statement in the API doc that color.new just takes R, G, B, you can call color.new(r, g, b, a) where a is the alpha channel.

A dump of the screen, image, text, etc. tables shows some methods not included in the docs too (I'm sure some of these have been mentioned, but it would be good to collect them.):

screen:
.clear

image:
.create
.width
.setbg
.height
.setresource
.fill

os: (all but os.sleep are in the Lua docs)
.exit
.setlocale
.date
.difftime
.remove
.time
.clock
.ostime
.rename
.sleep

[ThievingSix]

Too late: http://en.wikipedia.org/wiki/User:Thieving6/X-FI_2_Lua

In the very beginning when there were only 2 of us here, Zap dumped the tables and we worked on the wiki.

[bzdbbb]

Good idea Theodore - but the wiki already did it. I merged the threads and stickied it

[Theodore]

Anybody want to move this to it's own wiki (e.g. on wikia) rather than squatting on Thieving6's Wikipedia user space?

[ThievingSix]

I don't use wiki on anything else. So it really doesn't matter.

[ZaPx64]

Completed os.ostime(). Maybe this helps with an eggtimer app. I remember somebody else having a problem with the timer...

[ThievingSix]

So if what you wrote is correct, we have millisecond timing?!?! Although I'm curious of why one would be second timing and the other millisecond timing.

[ZaPx64]

Ya that's true. Try this app on your Zen and on the simulator:

screen.clear();

b = color.new(0, 0, 0);

text.size(30);
text.color(color.new(255, 0, 0));

while true do

    screen.fillrect(0, 0, 400, 240, b);

    text.draw(0, 0, tostring(os.ostime()));
    screen.update();
    
    if control.read() == 1 then
        if control.isButton() == 1 and button.home() == 1 and button.click() == 1 then break; end;
    end;
    
end;

I have no Idea why the timings are different, but I think that's another point for the firmware wishes-list

[cilmaviel]

for some reason os.ostime() doesn't show any data on my screen unless i concatenate it with text.
anyway i though this would be as good a place to post this as any. thanks to ZaPx64, this works great for limiting the frame rate in action games for better performance.
just add it to a draw screen function...

oldtime = os.ostime()
function drawscreen()
    newtime = os.ostime()
    if (newtime - oldtime) > 36 then
        oldtime = os.ostime()
        screen.fillrect(0,370,240,30,bg)
        arrows:draw(0,370)
        text.draw(0,375,page .. " / 10 ","center")
        screen.drawline(0,369,240,369,k)
        screen.update()
    end
end

this was taken from postit. just change 36 to the number of milliseconds before you want the screen to update. (for those that are not good at math, ms = 1000/fps).i suggest trying 25 fps for more action games (for those that don't know, 30 if the max).
this might also help with crashing to a scandisk. i haven't had that kind of crash on any of the apps i tested this with.

[Tetrajak]

Instead of creating a new thread, I figured I'd post my findings here, as it bares some relevance to the wiki.

I have been looking into the shell that the X-Fi2 has, and what functions are present in it. I have been doing this because it would be very desirable (for a number of reasons) to have the ability to list directories and files on the player, for such things as easy loading and saving of files. I think I have discovered why we cannot do this.

The firmware of the X-Fi2 runs on an operating system called Nucleus RTOS (Real-Time Operating System). Nucleus runs on a shell called POSIX (or Korn, they're the same thing really). You can think of POSIX like a kind of DOS, but not entirely. POSIX lacks a directory listing command (such as DOS's "dir"), and this hinders higher level code.

To explain a bit further; any higher level coding language relies on the other languages that it is built on. In this case, Lua is based on C, and C relies on the shell of the device that it's running on for it's functions. POSIX lacks a directory listing function, thus C on the X-Fi2 lacks a directory listing function, thus Lua on the X-Fi2 lacks a directory listing function.

For Lua, this means things like io.popen don't work, and can't work at all. Thus, sadly, some file operations can never be used. Nucleus is supposed to run on purpose built devices that are not PC's.

However convenient this theory is, I suppose it doesn't explain why the player can read files from the MicroSD drive (when it doesn't know what's on there) when the shell doesn't have a "dir" function. Perhaps the MicroSD drive is different and has one? I'm unsure.

[ThievingSix]

It has something to do with the "rebuilding" I assume. Does the MicroSD have a "rebuilding" feature like the player?

[Habhome]

No rebuilding as the player does, but it prompts you to "build the library" every time you've restarted your player and try to access files on it.

[Tetrajak]

Originally Posted by ThievingSix

It has something to do with the "rebuilding" I assume. Does the MicroSD have a "rebuilding" feature like the player?

Originally Posted by Habhome

No rebuilding as the player does, but it prompts you to "build the library" every time you've restarted your player and try to access files on it.

Habhome answers ThievingSix's question as I would, as for why this happens and what it does, I presume that if the MicroSD drive doesn't have a "dir" function then it uses a brute force method to test the existance of each possible filename. This seems a little far fetched though as brute force guessing takes a long time on a small processor. However, if it weren't referencing each folder individually, and instead scanned the entire flash memory for files, then it would take considerably less time.

All that's needed is a method in the shell that searches the partition table for files and their locations on the disk. Unless of course I'm completely off and flash media don't have partition tables, instead using something else or not at all?

[ZaPx64]

The file system on my Zen is FAT32 and it does have partition tables because it wouldn't work without them. Finding the files via Bruteforce would not work because FAT32 supports file names with a total lenght of 255 characters. Nucleus comes with several distrubutions which possibly support "dir" functions.

[Tetrajak]

Originally Posted by ZaPx64

The file system on my Zen is FAT32 and it does have partition tables because it wouldn't work without them. Finding the files via Bruteforce would not work because FAT32 supports file names with a total lenght of 255 characters. Nucleus comes with several distrubutions which possibly support "dir" functions.

Well, if you can find one for us, that'd be awesome. I know under some shells (like BASH) there are small spelling variation in the functions, such as "dirs".

[ZaPx64]

Why do you focus on the shell? I think LUA does not rely on any shell commands nor does C.
I think the shell might not have any dir functions anyway, but that is not important for LUA then. The most convenient thought is that creative disabled these functions for security reasons.
That's just my two cents

[Tetrajak]

Originally Posted by ZaPx64

Why do you focus on the shell? I think LUA does not rely on any shell commands nor does C.
I think the shell might not have any dir functions anyway, but that is not important for LUA then. The most convenient thought is that creative disabled these functions for security reasons.
That's just my two cents

The Lua documentation at Lua.org states that the return of several os functions rely on the shell that it's running on, such as os.execute. One would presume this rings true for similar C functions as well.

[ZaPx64]

Originally Posted by Tetrajak

The Lua documentation at Lua.org states that the return of several os functions rely on the shell that it's running on, such as os.execute. One would presume this rings true for similar C functions as well.

Well, that is of course true.
But according to my findings here (http://anythingbutipod.com/forum/sho...1&postcount=14) Zen runs a UNIX based OS (look at cpath in package table) so I still think dir-browsing is disabled for security reasons.
How did you find out about that RTOS?