Page 1 of 1
PS2 and Lua
Posted: Fri Jun 25, 2004 1:23 pm
by KaylaKaze
I've compiled the Lua library with the ps2 compilers but I'm wondering if it'll work. How compatible with ANSI C is the ps2? I mean, am I going to have to chage around time commands and file commands inside the Lua code in order to make them work on the ps2? I know it's POSSIBLE to use Lua on the ps2 'cause it's been used for some commercial games. I'm just wondering if anyone's tried it with the hombrew setup. I could code my own scripting language specificly for ps2 development but I'd rather use Lua since it's getting to be a standard in development.
Posted: Fri Jun 25, 2004 4:35 pm
by Guest
As far as I know, all compilers used in homebrew and linux
development are the GNU compilers. As such, they are as
ANSI compliant as you are likely to need for LUA, which
itself is likely developed using GCC.
Does this answer your question ?
One thing to consider...is that common system calls that
exist in UNIX systems to manage things such as FileI/O,
network I/O, and such don't actually exist, because there
is no real underlying operating system aside from the Sony
BIOS calls. Some File I/O and networking, console graphics,
etc... exist as part of the PS2 SDK. Check that out to see
if it can meet your needs. Likely you have a porting effort
ahead of you.
Gorim
Posted: Fri Jun 25, 2004 7:55 pm
by pixel
The only "big" issue with LUA in PS2, is the Lua_Number format. It is double by default, which isn't a good idea to use on the PS2. So, when using float here, you'll render the bytecode incompatible with a PC-lua which still uses double as numbers. And you'll then have to build a custom LUA on the PC side (that is, you have to change Lua_Number format) in order to generate compatible bytecode.
I also suggest you to do some modifications in the core, by taking off the compiler and the parser (if you are going to use byte code only), as stated here:
http://www.lua.org/notes/ltn002.html (this is for Lua4, but should be easily adapted for Lua5)
Posted: Fri Jun 25, 2004 10:54 pm
by KaylaKaze
Thanks for the info. It was mainly the file calls I was most concerned with, like the lua_loadfile (or whatever that command is) (that and timing) as I want to use it primarily for game design. The number format problem is a little troubling, but I don't mind having to use a PS2 only compiler.
Posted: Sat Jun 26, 2004 2:56 am
by KaylaKaze
Well, it's fortunate that Lua is designed to be easily portable. The config file has the option to easily switch the number type it uses. I'm also looking at things like the Lua io library and it seems like once I learn the actual Lua API better, it should be easy to port those over to fileio commands. Speaking of which, has fio and fileXio been integrated yet so that you can use only fileXioOpen or fioOpen (or whatever command) to access CD, MC, and HDD instead of having to figure out which is being accessed and switch commands based on that? I still have to learn to use the SDK instead of the separate releases of the core libs.
Posted: Sat Jun 26, 2004 3:12 am
by mrbrown
iomanX.irx should handle all that. As long as it's loaded before fileXio you should be able to access all device from fileXio.
Posted: Sat Jun 26, 2004 4:42 am
by KaylaKaze
Is that new 'cause when I was doing work with ps2mnu-k using the newest ps2lib and ps2drv, I couldn't access the MC with fileXio and ioman is loaded before fileXio.
Posted: Sat Jun 26, 2004 5:31 am
by KaylaKaze
Maybe the problem is using LibHDD instead of the HDD code in the ps2sdk.
Screw it. It's too much work. I'll just check the filename to see what command it should use.
Posted: Sat Jun 26, 2004 7:42 am
by mrbrown
It's my understanding that fileXio depends on iomanX, where the IOP kernel will refuse to load fileXio unless iomanX has been loaded first. And in the last released version of ps2drv, the functionality is in place where iomanX maps to both ioman and iomanX devices. If there's a specific problem then post the source and we'll see what's broken.
Posted: Sat Jun 26, 2004 1:42 pm
by KaylaKaze
My testing function is simply
Code: Select all
int Xio=1;
int ret=fileXioOpen("mc0:/gamelist.log", O_RDONLY, fileMode);
if (ret<0)
{
dbgprintf("Error opening file (fileXio)\n");
Xio=0;
ret=fioOpen("mc0:/gamelist.log",O_RDONLY);
if (ret<0)
{
dbgprintf("Error opening file (fio)\n");
return 1;
}
}
u8 temp[100];
if (Xio)
{
fileXioRead(ret, temp, 100);
fileXioClose(ret);
}
else
{
fioRead(ret, temp, 100);
fioClose(ret);
}
temp[99]='\0';
dbgprintf("%s\n",temp);
And it always prints the first error and not the second. fileXio works fine for pfs reads though. From looking at the dirtest sample in $(PS2DRV)/ee/samples/directorysample it looks like you have to switch to fileio for MC and HOST functions. Maybe there's something wrong in the module load function.
Code: Select all
scr_printf("Loading SIO2MAN\n");
SifLoadModule("rom0:SIO2MAN", 0, NULL);
scr_printf("Loading MCMAN\n");
SifLoadModule("rom0:MCMAN", 0, NULL);
scr_printf("Loading MCSERV\n");
SifLoadModule("rom0:MCSERV", 0, NULL);
scr_printf("Loading PADMAN\n");
ret = SifLoadModule("rom0:PADMAN", 0, NULL);
if (ret < 0)
{
scr_printf("Failed to load PAD module");
while(1);
}
scr_printf("Loading poweroff.irx %i bytes\n", size_poweroff_irx);
SifExecModuleBuffer(&poweroff_irx, size_poweroff_irx, 0, NULL, &ret);
scr_printf("Loading iomanx.irx %i bytes\n", size_iomanx_irx);
SifExecModuleBuffer(&iomanx_irx, size_iomanx_irx, 0, NULL, &ret);
scr_printf("Loading filexio.irx %i bytes\n", size_filexio_irx);
SifExecModuleBuffer(&filexio_irx, size_filexio_irx, 0, NULL, &ret);
scr_printf("Loading ps2dev9.irx %i bytes\n", size_ps2dev9_irx);
SifExecModuleBuffer(&ps2dev9_irx, size_ps2dev9_irx, 0, NULL, &ret);
scr_printf("Loading ps2atad.irx %i bytes\n", size_ps2atad_irx);
SifExecModuleBuffer(&ps2atad_irx, size_ps2atad_irx, 0, NULL, ret);
scr_printf("Loading ps2hdd.irx %i bytes\n", size_ps2hdd_irx);
SifExecModuleBuffer(&ps2hdd_irx, size_ps2hdd_irx, izeof(hddarg), hddarg, &ret);
scr_printf("Loading ps2fs.irx %i bytes\n", size_ps2fs_irx);
SifExecModuleBuffer(&ps2fs_irx, size_ps2fs_irx, sizeof(pfsarg), pfsarg, &ret);
scr_printf("Loading cdvd.irx %i bytes\n", size_cdvd_irx);
SifExecModuleBuffer(&cdvd_irx, size_cdvd_irx, 0, NULL, &ret);
Posted: Sat Jun 26, 2004 8:00 pm
by mrbrown
I'm not sure what the problem could be ... perhaps adresd could provide some insight?
Posted: Sun Jun 27, 2004 8:15 pm
by Guest
pixel wrote:The only "big" issue with LUA in PS2, is the Lua_Number format. It is double by default, which isn't a good idea to use on the PS2. So, when using float here, you'll render the bytecode incompatible with a PC-lua which still uses double as numbers. And you'll then have to build a custom LUA on the PC side (that is, you have to change Lua_Number format) in order to generate compatible bytecode.
This is always the problem with using bytecode based virtual machines
on the PS2 where double is the default (or only) type of float.
One is left with three choices in this situation:
1. GCC *should* be able to generate double fp operations in software. This
would ensure compatibility with existing softwares that rely on this.
Unfortunately, this has the least performance situation.
2. One could modify the Lua code to store numbers as doubles in the
bytecodes, but convert between REAL/DOUBLE during operations.
This has some performance hit, and any application that relies much
on the additional precision of a double would not behave the entirely
the same.
3. One could convert entirely to real-based operations. This provides the
best speed, but at the cost of compatibility.
#1 is an option if double precision could be done relatively speedily
in software. Most software implementations are blazingly slow. I have
look at writing an optimized library for the PS2 that uses EE multimedia
and core specific instructions to speed up double precision operations
but I have gotten spread thin on homebrew projects. :) It seems it
*could* be useful, so maybe I will spend more time on it.
Gorim