PS2 and Lua
PS2 and Lua
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.
-
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
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
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)
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)
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.
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.
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.
My testing function is simply
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
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);
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);
-
Guest
This is always the problem with using bytecode based virtual machinespixel 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.
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