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!

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...

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.

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

Quote:

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.

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.

__________________"If you are good enough at English to apologize, then there is no need to." - A good friend of mine
Discovered something about the X-Fi2 you think others may not know? Post it here so others can learn about it!
Have a question about X-Fi2 apps? Consult the FAQ before creating a thread about it.Like my work? Tell your friends. Don't like it? Tell me so I can improve. ^.^

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

Quote:

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?

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.

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".

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

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.