 |
forums.ps2dev.org
Homebrew PS2, PSP & PS3 Development Discussions
|
| View previous topic :: View next topic |
| Author |
Message |
KaylaKaze
Joined: 05 May 2004
Posts: 75
Location: NC, USA
|
 Posted: Fri Jun 25, 2004 1:23 pm Post subject: 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. |
|
| Back to top |
|
 |
Guest
|
| Posted: Fri Jun 25, 2004 4:35 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
pixel
Joined: 30 Jan 2004
Posts: 791
|
| Posted: Fri Jun 25, 2004 7:55 pm Post subject: |
|
|
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)
_________________
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. |
|
| Back to top |
|
|
KaylaKaze
Joined: 05 May 2004
Posts: 75
Location: NC, USA
|
| Posted: Fri Jun 25, 2004 10:54 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
KaylaKaze
Joined: 05 May 2004
Posts: 75
Location: NC, USA
|
| Posted: Sat Jun 26, 2004 2:56 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
mrbrown
Joined: 17 Jan 2004
Posts: 1536
|
| Posted: Sat Jun 26, 2004 3:12 am Post subject: |
|
|
| iomanX.irx should handle all that. As long as it's loaded before fileXio you should be able to access all device from fileXio. |
|
| Back to top |
|
|
KaylaKaze
Joined: 05 May 2004
Posts: 75
Location: NC, USA
|
| Posted: Sat Jun 26, 2004 4:42 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
KaylaKaze
Joined: 05 May 2004
Posts: 75
Location: NC, USA
|
| Posted: Sat Jun 26, 2004 5:31 am Post subject: |
|
|
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. |
|
| Back to top |
|
|
mrbrown
Joined: 17 Jan 2004
Posts: 1536
|
| Posted: Sat Jun 26, 2004 7:42 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
KaylaKaze
Joined: 05 May 2004
Posts: 75
Location: NC, USA
|
| Posted: Sat Jun 26, 2004 1:42 pm Post subject: |
|
|
My testing function is simply
| Code: |
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: |
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);
|
|
|
| Back to top |
|
|
mrbrown
Joined: 17 Jan 2004
Posts: 1536
|
| Posted: Sat Jun 26, 2004 8:00 pm Post subject: |
|
|
| I'm not sure what the problem could be ... perhaps adresd could provide some insight? |
|
| Back to top |
|
|
Guest
|
| Posted: Sun Jun 27, 2004 8:15 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
