Win32 PS2 Dev. Intro
Posted: Wed Jul 23, 2008 11:42 pm
Win32 PS2 Dev. Intro
By Lazy Bastard of GSHI.org ([email protected])
Introduction
While, as a relative beginner myself, I'm in no position to write an introduction to PS2 development, I'll do so anyway ;)
However, rather than simply lay out some facts, let us address the problems potential developers are hindered by. Please understand that I mean no disrespect to the, often genius, people who have written guides before me. Also, please hate me as little as possible if this guide is verbose...
Purpose
First of all, from what I gather, and judging by my personal experience, ~90% of those who aspire to develop for the PS2 are either scared away by, or simply fail to properly compile, the PS2 toolchain.
In addition, despite the various, "step-by-step" guides to beginning PS2 development, there really isn't one good guide to getting started that encompasses all aspects properly. There are several guides, which together may give you 80% of what you need to know, at best, and an equal number of guides that will either steer you completely wrong, pump you full of extraneous information, or contain nothing more than a history of the PS2, and a link to PS2Dev.org. Mind you, PS2Dev.org is a great place, and almost all the useful guides I refer to above can be found therein, but a simple link to a giant repository of vastly varied information and a thriving forum will not suffice as a guide. Furthermore, to compound the frustration of beginning developers, many of the tutorials at PS2Dev.org, and anywhere else on the net, are now outdated, and the examples will no longer compile with the new toolchain. However, I digress, and I've started this guide off much in the same way as some before me: with useless information. Heh.
So, with my deepest apologies, before I talk about anything useful at all, let's examine the problem, so that anyone reading this that has written, is writing, or will write a PS2 dev. guide may follow what I mean.
The primary problem in most guides is simply that the writer assumes a certain level of technical expertise, above that of the average computer user. While I realize that a degree of programming experience is desired of a beginning PS2 developer, specifically that of C (some ASM basics are also desirable), there's no reason why someone can't start programming for the first time for the PS2, rather than another platform. Additionally, the vast majority of people are Windows OS users, who know little or nothing about *nix operating systems, Cygwin, MinGW, or even basic use of the command line. Rather than telling these users to go spend considerable time learning Unix-based OS concepts, followed by learning computer science basics, followed by mastering C, followed by mastering MIPS IV Assembly of all things, followed by the minutia of specific applications that may be used in PS2 development, the goal of a guide should be to break down the setup process into the smallest possible steps, assuming as little as possible about the knowledge and experience of the beginner, and allow and encourage the beginner to learn the details before, during, and after the process of programming.
The Current Predicament
When someone starts out, he/she is generally urged to use either Linux, or Cygwin. For Windows users, rather than choosing, installing (or using a virtualized environment), configuring, and mastering Linux, it's generally advised to use Cygwin. However, for some time now, the PS2 toolchain has not compiled properly under Cygwin, perhaps partly due to updates to the toolchain, but primarily due to updates in Cygwin. One may try to downgrade his/her Cygwin install, but this is dodgy as well. Thus, Windows users are pressed to use MinGW.
Shall We Begin?
Lukasz was gracious enough to write up a guide to installing PS2SDK via MinGW, which I believe is currently the closest to a complete beginner's guide. His original guide can currently be found here (and, I hope he doesn't mind that I've used his guide as a base):
http://lukasz.dk/programming/playstatio ... -tutorial/
However, it would seem that following the above guide will no longer result in a properly-built toolchain. Thus, with some work, and considerable help from several people in the PS2 dev scene (including Lukasz himself), I've created a pre-built SDK, which can be found here: http://gshi.org/downloads/GSHI_PS2SDK.zip
The above also includes gsKit, SDL, and SDL-Mixer (and PS2-Packer Lite, though that's of little consequence), as mentioned in the ReadMe.txt included. Follow the instructions included in the archive. So, assuming you now have a proper development environment, let's test it out, and see if our assumption is correct (heh).
Testing the Toolchain
Run msys, and type the following:
cd ..
Then
cd local/ps2dev/ps2sdk/samples/graph
Then
make
If all goes well, you should compile graph.elf. You could run this ELF by using an emulator, such as PCSX2, burning it to a CD or DVD and running it on a modded PS2 or via use of a swap method, or remotely from a PC using one of several apps. We'll go into the details of these choices a little later.
Learning
OK, so you now have a working, (somewhat) verified build of your new development environment. It's time to play with some code. If you like, browse to the Samples directory mentioned above (Go to My Computer, your primary HDD [probably C:\], msys, local, ps2dev, ps2sdk, samples), enter one of the sample source directories, open any files with the .c extension, then the makefile, and take a brief look around. Don't worry if it's all gibberish to you right now; you can pick things up as you go along.
Now we'll take a look at a few pieces of reference. Don't despair; I'm not about to cut you all loose to read several books worth of complex information. I just want you to have some reference, to read at your own leisure, as the desire and need for knowledge increase. We'll continue with the guide after I've lain out a few choice sources of info.
Currently, a couple of good (free) sources of information for beginning programming with C are:
http://www.cprogramming.com/tutorial.html#ctutorial
http://www.cyberdiem.com/vin/tutorials.html
A couple of good (free) sources of information for beginning users of Unix-esque systems (such as msys) are:
http://www.indiana.edu/~uitspubs/b017/
http://www.computerhope.com/unix.htm
If you'd like some MIPS ASM reference, check out:
http://www.idt.com/products/files/10715 ... N=97636525
http://en.wikibooks.org/wiki/MIPS_Assembly
http://dkrizanc.web.wesleyan.edu/course ... s-spim.pdf
http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/
...but pay special attention to MIPS IV (the primary processor of the PS2, the Emotion Engine, is an r5900L, series IV processor).
In any case, I don't expect anyone to play with ASM straight-off.
Some basic things to know when compiling source code:
- Unix is case-sensitive; capitalization is imperative in ELF compilation. If the makefile specifies "main.c", "MAIN.C" will not work.
- As you compile source, you may notice warnings. Most likely, you may ignore these (at least, when you're first compiling the source of others, especially old source with deprecated functions and commands), but if you run into errors, and your ELF, ERL, IRX, or whatever doesn't properly build thereafter, (and I hate to speak badly of something then do it right afterward, but...) drop by forums.ps2dev.org, or GSHI.org/vB, and ask someone for help. Or, if you prefer, send me an email, though I'm not the sage I masquerade as ;) If your question/comment is valid, I'll probably add it to this guide, along with as proper an answer as I can provide (I swear, I didn't intend for that to rhyme).
- A common error in a makefile, especially one which you "created" by copying and pasting the contents of something on the web to a text editor, then saving it as a makefile is "missing separator in line *" (* being whatever actual line number the error refers to). This error is usually caused by the makefile containing spaces at the beginnings of lines, rather than tabs. Try simply replacing all spaces at the beginning of each indented line with a tab.
- If you attempt to compile something, but you receive an error, and, after fixing the issue, you'd like to try to compile it again, type "make clean" for a fresh start; assuming the makefile includes make clean (which most should), this will remove all generated files (.o files, etc), and restore the source directory to its original, pristine state (it will, of course, not undo any work you've done on the original source files).
Running Your Executables
In order for you to know for sure that anything you write is compiling properly, you’ll need a way to run your ELFs. As noted before, there are several ways of doing so, and you may decide to use more than one, depending on the circumstance. Let us go into the details of each of these…
Using PCSX2 (PS2 emulator)
One quick way to test an ELF is to run it via an emulator (a piece of software that runs on a computer, and acts as if it were the real console), notably PCSX2, at this point the most advanced PS2 emu around. Currently, you can find a copy here: http://www.pcsx2.net/downloads.php
In order for the emulator to work properly, you’ll need a BIOS dump (a copy of the PS2’s built-in Input/Output System). You can currently find a tool to dump your own BIOS here: http://ps2dev.org/ps2/Tools/Misc_tools/Bios_dump_util
…or you could search the web a little, and find one someone else has uploaded. I’d include a link to one, but that would be legally questionable, if not outright illegal. If you already own a real PS2, downloading a copy of the same BIOS you already have shouldn’t be a problem, but otherwise, do so at your own risk.
Next, you’ll need to configure PCSX2 properly. First, you’ll be running PCSX2t.exe, rather than the default PCSX2.exe. PCSX2t.exe was designed for greater compatibility with homebrew and such, but at a cost: performance. For the most part, short of writing graphics-intensive games and such, you’ll never notice a performance difference, and without using PCSX2t.exe, many homebrew ELFs simply won’t run. Anyway, run PCSX2t.exe, go to Config, and choose Configure. For Graphics, choose GSdx9 (MSVC 14.00) 0.9.0. Sound should only have one plugin, so we can ignore that. For both controllers, choose whichever you like, depending on whether you have a PC gamepad, or if you’ll be using the keyboard for emulation. For CDVDROM, choose CDVDnull Driver 0.6.0. For Dev9, USB, and Firewire, there should only be one choice each, so ignore them. And for BIOS, choose the BIOS you dug up. After clicking OK, go to Config, choose Controllers, and set up which buttons/keys should correspond to which PS2 buttons. After clicking OK, you’re ready to start running ELFs. Simply Click File, choose Open ELF, browse to the ELF you’d like to run, and run it.
Burning to a disc, and running your ELF on a PS2
You may desire to burn your ELF to a CD or DVD, and play it on a real PS2 (in fact, you probably will). If this is the case, there are a few things you should know. First off, you’ll need a way to bypass the PS2’s copy protection scheme. You won’t simply be able to burn your disc, and play it on a PS2, as it will be recognized as an invalid disc. Hence, you'll need to either...
...purchase a set of swap discs (such as Swap Magic), with either a slide tool, flip top cover, or Magic Switch, depending on your model of PS2. There are also exploits that allow the use of some cheat system discs, such as Action Replay, to be used as swap discs. The newer Swap Magic versions (3.0 and above, at least) have the added bonus of allowing you to boot ELFs from a USB flash drive.
...use the Independence Exploit. This will require a way to write to a memory card in the first place (which means you'll need a swap method, or adapter from USB to memory card), or at least knowing someone who can do so for you. This exploit does not work with newer, "Slim" PS2 models, as the buffer overflow issue that allowed it was corrected.
...purchase a modded PS2, have your PS2 modded, or mod your PS2 yourself. I would highly recommend one of the first two if you're going to go this route, as many a PS2 have been destroyed by those with minimal soldering experience, but it's all up to you, I suppose.
...or...
...purchase a Memor32 memory card, and download the Memento firmware. Personally, I dislike the fact that, in order to boot discs, you'll have to create modified (patched) disc images that will work specifically with Memento, then burn them, but at least you can directly run ELFs from either memory cards, or USB drives.
Having decided on and established a way to boot your own discs, let me walk you through a few things concerning the PS2 and its behavior with discs.
First, you'll need a SYSTEM.CNF to initialize your ELF. This is the first thing that the PS2 will look for after it's decided your disc is valid, and is the file that will tell the PS2 what to do next. You can either create a SYSTEM.CNF manually in a text editor, then save it as SYSTEM.CNF (I'll give an example below), or you can use something like PS2Tools to generate one for you (PS2Tools can easily be found with a bit of Googling).
The file system that's used in PS2 discs is ISO9660. In accordance with ISO9660, ELF filenames must be in caps (and referenced as such in their SYSTEM.CNFs) to initialize properly on disc - ISO9660 further dictates that files referenced on cdrom should be referenced as such: cdrom0:\FILE.EXT;1
...hence, when creating an NTSC disc for test1.elf, you'll need to rename test1.elf to TEST1.ELF, and create your SYSTEM.CNF as such:
BOOT2 = cdrom0:\TEST1.ELF;1
VER = 1.0
VMODE = NTSC
In case you're not familiar with terms like NTSC and PAL, you may want to use our old friend Google to read up a bit on video modes. For now, suffice it to say, if you're in the US or Japan, you'll probably be using NTSC, and if you're in Europe, you'll probably be using PAL.
Next, assuming you don't go the Memor32 route (if you do, you'll be given instructions on disc creation and patching), you'll need to burn your PS2 disc in a very precise manner. For a CDR (which is what I'd recommend using, if only for the difference in price to DVDR), you'll need to burn in Mode 2/XA, Form 1, ISO9660. Personally, I use Nero for this, but several other burning apps will allow you to set these options.
Moving on, I should mention the factor of wear and tear. You see, if you only burn an ELF and a SYSTEM.CNF, you're using a very small amount of disc space (a few MB, at most), and all of your data will be burned to the innermost portion of the disc. I'm not sure why exactly (though it likely has something to do with the difference in rotation speed between inner and outer portions of the disc), but forcing your PS2 to read entirely from the innermost portion of the disc is apparently quite hard on the LASER assembly, and will eventually shorten the life of your PS2 considerably. To avoid this excess wear, it would be wise to force your files a little more toward the middle of the disc, in one of two ways.
The first way (the "easy" way) is to include a dummy file or two, with a name alphanumerically before all of your other files (so if you have 1.ELF and SYSTEM.CNF, you'll want something like 0.DUMMY; if you have ELF.ELF and SYSTEM.CNF, you'll want something like DUM.DUMMY, and so on). This way, the dummy file will be written to disc first, and all other files will be written afterward, and a little closer to the middle of the disc. There are quite a few applications that will help you create dummy files of whatever size you like (this all depends on the size of your files, and how far out you'd like to push them); I usually use BigByte, by Skrommel (Google around for it). Keep in mind that you usually have about 700 MB on a CDR, and your goal should be to push your files out to about the 300MB mark, assuming you don't have more than 400MB to burn.
The second way (the "hard" way, I suppose) is to use something like cdgenPS2, which will not only allow you to create a disc image for PS2 (which you can burn with any program that can burn disc images), but will also allow you to force your files out to a certain LBA (Logical Block Address, which, in the case of Mode 2/XA, Form 1, ISO9660, is the same as PSN, or Physical Sector Number). This will allow you to push your files out toward the middle of the disc without the need for such crude things as dummy files, and is thus definitely my preferred method. The difficulty here is determining at what LBA you'd like to start burning your files - there are about 350,000 LBA/PSN on a normal, 700MB CDR, though burning at half of that won't really put you at the halfway mark, since there are more addresses/sectors toward the outer edge than there are toward the inner edge. But, in any case, it doesn't need to be perfect, and anything but the far inner portion of the disc is better than...er...the far inner portion of the disc :)
Running your executables via ethernet or USB connection
There are several programs (PS2Link, InLink, PukkLink, NapLink, and possibly others) that will allow you to connect to your PS2, either via ethernet connection, or USB connection, and run your executables from your PC. However, all of these will still require a way to run the PS2-side application (the server), which will connect with your PC-side application (the client), which means you'll still need either a modchip, a swap disc, or something like Memor32. However, the primary advantage to these applications is that, after running an executable, you can (generally) terminate the executable, and run another one, without having to restart your PS2 over and over. Rather than rewrite, or steal verbatim, the guides to these various utilities, I'll simply refer you to Google, in search of the above-mentioned apps.
And that's about it
And, um...that's about it, for now :) If you have any questions, feel free to drop by http://forums.PS2Dev.org, or http://GSHI.org/vb, or to email me. I'll probably write several addendums to this guide, and go a little more into actual programming, though there's already quite a bit of source around the 'net, and I've already thrown out several links to learning C and MIPS ASM. You can also go to the Video Game & Utility Development forum at http://GSHI.org/vb , and grab a copy of the compilable source package I've made, for further examples of PS2 source. Well, until next time...
- Lazy Bastard
Thanks go out to:
Lukasz Bruun, for answering several questions, for throwing me a bone in compiling some old sources, for all his work in helping beginners, and for writing the guide that allowed me to set up a MinGW environment for PS2SDK (and a Cygwin one, before that).
ptek, for answering several questions about romfs, and PS2 dev in general. He's also been quite helpful to beginners.
ps2devman, for answering several gsKit questions, and for, as the previous two people, being quite helpful to beginners.
Oopo, for making himself available for questions (even though I haven't asked him anything yet).
Oobles, for PS2Dev.org.
GSHI.org, for being my favorite (virtual) place in the world :)
Many people I've likely forgotten (I'll add those as I remember them)
And the entire PS2Dev scene (and the VG scene in general).
By Lazy Bastard of GSHI.org ([email protected])
Introduction
While, as a relative beginner myself, I'm in no position to write an introduction to PS2 development, I'll do so anyway ;)
However, rather than simply lay out some facts, let us address the problems potential developers are hindered by. Please understand that I mean no disrespect to the, often genius, people who have written guides before me. Also, please hate me as little as possible if this guide is verbose...
Purpose
First of all, from what I gather, and judging by my personal experience, ~90% of those who aspire to develop for the PS2 are either scared away by, or simply fail to properly compile, the PS2 toolchain.
In addition, despite the various, "step-by-step" guides to beginning PS2 development, there really isn't one good guide to getting started that encompasses all aspects properly. There are several guides, which together may give you 80% of what you need to know, at best, and an equal number of guides that will either steer you completely wrong, pump you full of extraneous information, or contain nothing more than a history of the PS2, and a link to PS2Dev.org. Mind you, PS2Dev.org is a great place, and almost all the useful guides I refer to above can be found therein, but a simple link to a giant repository of vastly varied information and a thriving forum will not suffice as a guide. Furthermore, to compound the frustration of beginning developers, many of the tutorials at PS2Dev.org, and anywhere else on the net, are now outdated, and the examples will no longer compile with the new toolchain. However, I digress, and I've started this guide off much in the same way as some before me: with useless information. Heh.
So, with my deepest apologies, before I talk about anything useful at all, let's examine the problem, so that anyone reading this that has written, is writing, or will write a PS2 dev. guide may follow what I mean.
The primary problem in most guides is simply that the writer assumes a certain level of technical expertise, above that of the average computer user. While I realize that a degree of programming experience is desired of a beginning PS2 developer, specifically that of C (some ASM basics are also desirable), there's no reason why someone can't start programming for the first time for the PS2, rather than another platform. Additionally, the vast majority of people are Windows OS users, who know little or nothing about *nix operating systems, Cygwin, MinGW, or even basic use of the command line. Rather than telling these users to go spend considerable time learning Unix-based OS concepts, followed by learning computer science basics, followed by mastering C, followed by mastering MIPS IV Assembly of all things, followed by the minutia of specific applications that may be used in PS2 development, the goal of a guide should be to break down the setup process into the smallest possible steps, assuming as little as possible about the knowledge and experience of the beginner, and allow and encourage the beginner to learn the details before, during, and after the process of programming.
The Current Predicament
When someone starts out, he/she is generally urged to use either Linux, or Cygwin. For Windows users, rather than choosing, installing (or using a virtualized environment), configuring, and mastering Linux, it's generally advised to use Cygwin. However, for some time now, the PS2 toolchain has not compiled properly under Cygwin, perhaps partly due to updates to the toolchain, but primarily due to updates in Cygwin. One may try to downgrade his/her Cygwin install, but this is dodgy as well. Thus, Windows users are pressed to use MinGW.
Shall We Begin?
Lukasz was gracious enough to write up a guide to installing PS2SDK via MinGW, which I believe is currently the closest to a complete beginner's guide. His original guide can currently be found here (and, I hope he doesn't mind that I've used his guide as a base):
http://lukasz.dk/programming/playstatio ... -tutorial/
However, it would seem that following the above guide will no longer result in a properly-built toolchain. Thus, with some work, and considerable help from several people in the PS2 dev scene (including Lukasz himself), I've created a pre-built SDK, which can be found here: http://gshi.org/downloads/GSHI_PS2SDK.zip
The above also includes gsKit, SDL, and SDL-Mixer (and PS2-Packer Lite, though that's of little consequence), as mentioned in the ReadMe.txt included. Follow the instructions included in the archive. So, assuming you now have a proper development environment, let's test it out, and see if our assumption is correct (heh).
Testing the Toolchain
Run msys, and type the following:
cd ..
Then
cd local/ps2dev/ps2sdk/samples/graph
Then
make
If all goes well, you should compile graph.elf. You could run this ELF by using an emulator, such as PCSX2, burning it to a CD or DVD and running it on a modded PS2 or via use of a swap method, or remotely from a PC using one of several apps. We'll go into the details of these choices a little later.
Learning
OK, so you now have a working, (somewhat) verified build of your new development environment. It's time to play with some code. If you like, browse to the Samples directory mentioned above (Go to My Computer, your primary HDD [probably C:\], msys, local, ps2dev, ps2sdk, samples), enter one of the sample source directories, open any files with the .c extension, then the makefile, and take a brief look around. Don't worry if it's all gibberish to you right now; you can pick things up as you go along.
Now we'll take a look at a few pieces of reference. Don't despair; I'm not about to cut you all loose to read several books worth of complex information. I just want you to have some reference, to read at your own leisure, as the desire and need for knowledge increase. We'll continue with the guide after I've lain out a few choice sources of info.
Currently, a couple of good (free) sources of information for beginning programming with C are:
http://www.cprogramming.com/tutorial.html#ctutorial
http://www.cyberdiem.com/vin/tutorials.html
A couple of good (free) sources of information for beginning users of Unix-esque systems (such as msys) are:
http://www.indiana.edu/~uitspubs/b017/
http://www.computerhope.com/unix.htm
If you'd like some MIPS ASM reference, check out:
http://www.idt.com/products/files/10715 ... N=97636525
http://en.wikibooks.org/wiki/MIPS_Assembly
http://dkrizanc.web.wesleyan.edu/course ... s-spim.pdf
http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/
...but pay special attention to MIPS IV (the primary processor of the PS2, the Emotion Engine, is an r5900L, series IV processor).
In any case, I don't expect anyone to play with ASM straight-off.
Some basic things to know when compiling source code:
- Unix is case-sensitive; capitalization is imperative in ELF compilation. If the makefile specifies "main.c", "MAIN.C" will not work.
- As you compile source, you may notice warnings. Most likely, you may ignore these (at least, when you're first compiling the source of others, especially old source with deprecated functions and commands), but if you run into errors, and your ELF, ERL, IRX, or whatever doesn't properly build thereafter, (and I hate to speak badly of something then do it right afterward, but...) drop by forums.ps2dev.org, or GSHI.org/vB, and ask someone for help. Or, if you prefer, send me an email, though I'm not the sage I masquerade as ;) If your question/comment is valid, I'll probably add it to this guide, along with as proper an answer as I can provide (I swear, I didn't intend for that to rhyme).
- A common error in a makefile, especially one which you "created" by copying and pasting the contents of something on the web to a text editor, then saving it as a makefile is "missing separator in line *" (* being whatever actual line number the error refers to). This error is usually caused by the makefile containing spaces at the beginnings of lines, rather than tabs. Try simply replacing all spaces at the beginning of each indented line with a tab.
- If you attempt to compile something, but you receive an error, and, after fixing the issue, you'd like to try to compile it again, type "make clean" for a fresh start; assuming the makefile includes make clean (which most should), this will remove all generated files (.o files, etc), and restore the source directory to its original, pristine state (it will, of course, not undo any work you've done on the original source files).
Running Your Executables
In order for you to know for sure that anything you write is compiling properly, you’ll need a way to run your ELFs. As noted before, there are several ways of doing so, and you may decide to use more than one, depending on the circumstance. Let us go into the details of each of these…
Using PCSX2 (PS2 emulator)
One quick way to test an ELF is to run it via an emulator (a piece of software that runs on a computer, and acts as if it were the real console), notably PCSX2, at this point the most advanced PS2 emu around. Currently, you can find a copy here: http://www.pcsx2.net/downloads.php
In order for the emulator to work properly, you’ll need a BIOS dump (a copy of the PS2’s built-in Input/Output System). You can currently find a tool to dump your own BIOS here: http://ps2dev.org/ps2/Tools/Misc_tools/Bios_dump_util
…or you could search the web a little, and find one someone else has uploaded. I’d include a link to one, but that would be legally questionable, if not outright illegal. If you already own a real PS2, downloading a copy of the same BIOS you already have shouldn’t be a problem, but otherwise, do so at your own risk.
Next, you’ll need to configure PCSX2 properly. First, you’ll be running PCSX2t.exe, rather than the default PCSX2.exe. PCSX2t.exe was designed for greater compatibility with homebrew and such, but at a cost: performance. For the most part, short of writing graphics-intensive games and such, you’ll never notice a performance difference, and without using PCSX2t.exe, many homebrew ELFs simply won’t run. Anyway, run PCSX2t.exe, go to Config, and choose Configure. For Graphics, choose GSdx9 (MSVC 14.00) 0.9.0. Sound should only have one plugin, so we can ignore that. For both controllers, choose whichever you like, depending on whether you have a PC gamepad, or if you’ll be using the keyboard for emulation. For CDVDROM, choose CDVDnull Driver 0.6.0. For Dev9, USB, and Firewire, there should only be one choice each, so ignore them. And for BIOS, choose the BIOS you dug up. After clicking OK, go to Config, choose Controllers, and set up which buttons/keys should correspond to which PS2 buttons. After clicking OK, you’re ready to start running ELFs. Simply Click File, choose Open ELF, browse to the ELF you’d like to run, and run it.
Burning to a disc, and running your ELF on a PS2
You may desire to burn your ELF to a CD or DVD, and play it on a real PS2 (in fact, you probably will). If this is the case, there are a few things you should know. First off, you’ll need a way to bypass the PS2’s copy protection scheme. You won’t simply be able to burn your disc, and play it on a PS2, as it will be recognized as an invalid disc. Hence, you'll need to either...
...purchase a set of swap discs (such as Swap Magic), with either a slide tool, flip top cover, or Magic Switch, depending on your model of PS2. There are also exploits that allow the use of some cheat system discs, such as Action Replay, to be used as swap discs. The newer Swap Magic versions (3.0 and above, at least) have the added bonus of allowing you to boot ELFs from a USB flash drive.
...use the Independence Exploit. This will require a way to write to a memory card in the first place (which means you'll need a swap method, or adapter from USB to memory card), or at least knowing someone who can do so for you. This exploit does not work with newer, "Slim" PS2 models, as the buffer overflow issue that allowed it was corrected.
...purchase a modded PS2, have your PS2 modded, or mod your PS2 yourself. I would highly recommend one of the first two if you're going to go this route, as many a PS2 have been destroyed by those with minimal soldering experience, but it's all up to you, I suppose.
...or...
...purchase a Memor32 memory card, and download the Memento firmware. Personally, I dislike the fact that, in order to boot discs, you'll have to create modified (patched) disc images that will work specifically with Memento, then burn them, but at least you can directly run ELFs from either memory cards, or USB drives.
Having decided on and established a way to boot your own discs, let me walk you through a few things concerning the PS2 and its behavior with discs.
First, you'll need a SYSTEM.CNF to initialize your ELF. This is the first thing that the PS2 will look for after it's decided your disc is valid, and is the file that will tell the PS2 what to do next. You can either create a SYSTEM.CNF manually in a text editor, then save it as SYSTEM.CNF (I'll give an example below), or you can use something like PS2Tools to generate one for you (PS2Tools can easily be found with a bit of Googling).
The file system that's used in PS2 discs is ISO9660. In accordance with ISO9660, ELF filenames must be in caps (and referenced as such in their SYSTEM.CNFs) to initialize properly on disc - ISO9660 further dictates that files referenced on cdrom should be referenced as such: cdrom0:\FILE.EXT;1
...hence, when creating an NTSC disc for test1.elf, you'll need to rename test1.elf to TEST1.ELF, and create your SYSTEM.CNF as such:
BOOT2 = cdrom0:\TEST1.ELF;1
VER = 1.0
VMODE = NTSC
In case you're not familiar with terms like NTSC and PAL, you may want to use our old friend Google to read up a bit on video modes. For now, suffice it to say, if you're in the US or Japan, you'll probably be using NTSC, and if you're in Europe, you'll probably be using PAL.
Next, assuming you don't go the Memor32 route (if you do, you'll be given instructions on disc creation and patching), you'll need to burn your PS2 disc in a very precise manner. For a CDR (which is what I'd recommend using, if only for the difference in price to DVDR), you'll need to burn in Mode 2/XA, Form 1, ISO9660. Personally, I use Nero for this, but several other burning apps will allow you to set these options.
Moving on, I should mention the factor of wear and tear. You see, if you only burn an ELF and a SYSTEM.CNF, you're using a very small amount of disc space (a few MB, at most), and all of your data will be burned to the innermost portion of the disc. I'm not sure why exactly (though it likely has something to do with the difference in rotation speed between inner and outer portions of the disc), but forcing your PS2 to read entirely from the innermost portion of the disc is apparently quite hard on the LASER assembly, and will eventually shorten the life of your PS2 considerably. To avoid this excess wear, it would be wise to force your files a little more toward the middle of the disc, in one of two ways.
The first way (the "easy" way) is to include a dummy file or two, with a name alphanumerically before all of your other files (so if you have 1.ELF and SYSTEM.CNF, you'll want something like 0.DUMMY; if you have ELF.ELF and SYSTEM.CNF, you'll want something like DUM.DUMMY, and so on). This way, the dummy file will be written to disc first, and all other files will be written afterward, and a little closer to the middle of the disc. There are quite a few applications that will help you create dummy files of whatever size you like (this all depends on the size of your files, and how far out you'd like to push them); I usually use BigByte, by Skrommel (Google around for it). Keep in mind that you usually have about 700 MB on a CDR, and your goal should be to push your files out to about the 300MB mark, assuming you don't have more than 400MB to burn.
The second way (the "hard" way, I suppose) is to use something like cdgenPS2, which will not only allow you to create a disc image for PS2 (which you can burn with any program that can burn disc images), but will also allow you to force your files out to a certain LBA (Logical Block Address, which, in the case of Mode 2/XA, Form 1, ISO9660, is the same as PSN, or Physical Sector Number). This will allow you to push your files out toward the middle of the disc without the need for such crude things as dummy files, and is thus definitely my preferred method. The difficulty here is determining at what LBA you'd like to start burning your files - there are about 350,000 LBA/PSN on a normal, 700MB CDR, though burning at half of that won't really put you at the halfway mark, since there are more addresses/sectors toward the outer edge than there are toward the inner edge. But, in any case, it doesn't need to be perfect, and anything but the far inner portion of the disc is better than...er...the far inner portion of the disc :)
Running your executables via ethernet or USB connection
There are several programs (PS2Link, InLink, PukkLink, NapLink, and possibly others) that will allow you to connect to your PS2, either via ethernet connection, or USB connection, and run your executables from your PC. However, all of these will still require a way to run the PS2-side application (the server), which will connect with your PC-side application (the client), which means you'll still need either a modchip, a swap disc, or something like Memor32. However, the primary advantage to these applications is that, after running an executable, you can (generally) terminate the executable, and run another one, without having to restart your PS2 over and over. Rather than rewrite, or steal verbatim, the guides to these various utilities, I'll simply refer you to Google, in search of the above-mentioned apps.
And that's about it
And, um...that's about it, for now :) If you have any questions, feel free to drop by http://forums.PS2Dev.org, or http://GSHI.org/vb, or to email me. I'll probably write several addendums to this guide, and go a little more into actual programming, though there's already quite a bit of source around the 'net, and I've already thrown out several links to learning C and MIPS ASM. You can also go to the Video Game & Utility Development forum at http://GSHI.org/vb , and grab a copy of the compilable source package I've made, for further examples of PS2 source. Well, until next time...
- Lazy Bastard
Thanks go out to:
Lukasz Bruun, for answering several questions, for throwing me a bone in compiling some old sources, for all his work in helping beginners, and for writing the guide that allowed me to set up a MinGW environment for PS2SDK (and a Cygwin one, before that).
ptek, for answering several questions about romfs, and PS2 dev in general. He's also been quite helpful to beginners.
ps2devman, for answering several gsKit questions, and for, as the previous two people, being quite helpful to beginners.
Oopo, for making himself available for questions (even though I haven't asked him anything yet).
Oobles, for PS2Dev.org.
GSHI.org, for being my favorite (virtual) place in the world :)
Many people I've likely forgotten (I'll add those as I remember them)
And the entire PS2Dev scene (and the VG scene in general).