forums.ps2dev.org

[FeedBucket]

Hi,

I've built a working port of the Doom engine. It works swimmingly over ps2link if you wrap everything up into a single elf with romfs. Significantly less so with bare host/network based IO.

Obviously I can't (and won't) distribute this bundled with the game data -- IP still remains protected property of the original developers -- but forcing users to use ps2link is suboptimal on pretty much every level. I'd like for people to be able to use it and actually enjoy it too.

What alternative methods of data access can I employ to make this palatable for the less masochistic/technically inclined? I'm thinking something like polling alternate devices containing the data but I'm honestly not sure where to look to start with that.

Thanks for any insight.

[cheriff]

I'd say you ask your users to keep the WADs in a certain location on a USB stick/drive. Then you simply bundle the open version of usbd.irx and attempt to open "mass:somefile.wad"

Otherwise you're dependant on either HDD, CD, MC or host - which would require either modchips, ps2link, or excessive messing about to get the files onto HDD/MC in the first place.

Which pretty much leaves usb by elimination :)
_________________
Damn, I need a decent signature!

[ragnarok2040]

You could use freedoom's iwad to distribute with your port, the downloads page has a list of compatible ports (if the port of the port that you used supports it) http://freedoom.sourceforge.net/. It can also be used with mods with pwads and whatnot.

You can load IOP drivers which the ps2 kernel can use, so you can use standard C file functions or fio or fileXio (I believe) and access mass:, mc0:, mc1:, hdd0: etc. without much hassle. You should note which devices need to be initialized prior to accessing, like the memory cards. The best place to look for examples on this, based on my experience, is ps2sdk's samples/rpc/memorycard, ulaunchelf's source @ ps2-scene.org's forums. Its makefile also contains an example of how to add external .irx files to a project. dlanor's InfoNES port is another good example for adding an irx module to a project as it includes only one.

To work with usb drives, you load and run usbd.irx, then usbhdfsd.irx. From what I remember, that's it, you should be able to access the mass: filesystem after that. Usbhdfsd is located as a separate project in the ps2dev subversion repository. I believe it works with usb connected hard drives, too, based on what I've read. That should work with pretty much anyone with a ps2 or pstwo and a usb drive of some sort.

That should get you somewhat started in the right direction so you can sort out what it is you need to do.

[ps2devman]

the pong starter kit reads a text line in file config.dat (it assumes file is on the cd-r from where ps2link boots, it's a file used by ps2link to know what static ip address to use).

just suggest people to burn a cd-r with your .elf at root and all the files you need beside it.

study the .cnf file of ps2link iso image to see how to call your .elf right at boot time


Create imagen.bin with cdgenps2 :
- drag'n drop files in this order :
SYSTEM.CNF
DOOM.ELF
<wads here>
DUMMY (any big file)
- click IMG to save imagen.bin and imagen.cue

Start Alcohol 120% :
-Select DAO/SAO mode and x16 speed
-Select imagen.cue
-Burn a CD-R

[FeedBucket]

Very cool. I didn't realize that adding the modules was pretty much all you had to do to make the devices accessible. After looking at some examples, though, I'm now confused about the usage of fio functions (ie fioOpen) vs the regular open/close/etc. Is the former necessary for ps2 device access? And then where do things like fopen fall?

I've now got config data reading and writing on mc0 and data reading off of mass. It crashes a few seconds in though; might be the media -- this USB drive has been slowly dying for the past year and a half. I'll investigate some more and play with reading CDs this weekend.

Thanks for the help.

[ragnarok2040]

From my understanding, the fio* functions are the functions residing inside of the PS2's BIOS itself (from embedded IOP modules inside the BIOS that every PS2 has) and the fopen/fclose/etc. functions are wrapped around the fio* functions for a standard C library implementation for file routines (for porting applications that use functions like fopen/fclose without much change). You can use both to access PS2 devices. The fopen functions uses the standard FILE struct, and the fio* functions use an integer as a file descriptor.

You can look at PS2SDK's source inside the ee/kernel folder to examine sources to the standard C library file functions (fopen/fclose/etc.). There's one or two that are empty functions, like remove() last time I looked, that might return a success even though nothing happens.

Oh yeah, and if you use fioRemove(), make sure to do a fioRmdir on the same file afterwards, there's a bug where fioRemove() immediately creates a directory of the same name as the file removed.

I'm not too clear on the fileXio functions, which are an updated set of file handling routines, lol. I have read that they're included in all PS2 BIOSes except for first run Japanese PS2s. I've pretty much just steered clear of them since everything I wanted was already supported with the older versions.

[BlackShark]

eh, what a coincidence, I happen to be working on A Doom port as well, its a modded version of DoomPSP .5 plus, Do you know if the source requires the SDL library?
_________________
Programmer van der C

[FeedBucket]

I haven't looked at the PSP source and it really depends on what branch it's based on. Wouldn't be surprised if it did though.

Mine's based on lsdldoom with some small bits of prboom -- yes, SDL based and it now needs SDL_mixer too. I had to change some conflicting names to get it to compile and then rewrite good chunks of the sound and input handling to get it to work right.