Results 1 to 8 of 8
  1. #1

    Default Win32 PS2 Dev. Intro

    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/playsta...ingw-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 in the GSHI.org Downloads section.

    The above also includes many libraries for extra functionality and support, 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, placing it on a USB flash drive or memory card and booting it via FMCB, VAST, or another such memory card boot solution, 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/10...TOKEN=97636525
    http://en.wikibooks.org/wiki/MIPS_Assembly
    http://dkrizanc.web.wesleyan.edu/cou.../mips-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).

    - An issue you may encounter when attempting to compile old source that utilizes gsKit is indicated by this error:

    example.c:344: too few arguments to function `dmaKit_init'
    make[1]: *** [example.o] Error 1

    Generally, this error can be fixed by finding and changing the following:

    dmaKit_init(D_CTRL_RELE_OFF,D_CTRL_MFD_OFF, D_CTRL_STS_UNSPEC, D_CTRL_STD_OFF, D_CTRL_RCYC_8);

    ...to the following:

    dmaKit_init(D_CTRL_RELE_OFF,D_CTRL_MFD_OFF, D_CTRL_STS_UNSPEC,
    D_CTRL_STD_OFF, D_CTRL_RCYC_8, 1 << DMA_CHANNEL_GIF);

    (the above solution was provided by cosmito [previously known as ptek], referencing the gsKit example in bigtex.c)


    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...

    ...use FMCB (Free Memory Card Boot), or purchase a Memor32 memory card, and download the Memento firmware. Personally, I dislike the fact that, in order to boot discs with Memento, 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 file names 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).

    cosmito (previously known as 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).

    ______________________________________________


    I've also made a useful Google search sub-engine, that searches only within PS2Dev.org - as PS2Dev.org's forum search function isn't that great. Here you are:

    http://www.google.com/coop/cse?cx=00...81:h-k31ipwaaa


    Another useful link is Jimparis's mirror of the PS2Dev.org SVN: http://psp.jim.sh/svn/

    Keep in mind that this is merely an HTTP mirror; it's not a real SVN repository, but a browseable image of what the real one (svn://svn.ps2dev.org) contains, as the real one's HTTP functionality has been gone for some time.
    I may be lazy, but I can...zzzZZZzzzZZZzzzZZZ...

  2. #2
    Join Date
    Dec 2008
    Posts
    1

    Default

    Thanks Lazy, excellent work.
    Everything it's o.k. and Compile, let's to fun

  3. #3

    Default

    I'm glad you like it. I hope a lot more people are enjoying the little things I've put together, and just not taking the time to say so, heh.
    I may be lazy, but I can...zzzZZZzzzZZZzzzZZZ...

  4. #4
    Join Date
    Sep 2009
    Posts
    13

    Default

    Sorry for the big bump, but I have a question with this.

    I'm using windows 7, and I'm not sure exactly how to do the cd part in msys.

    Downloaded ps2sdk onto my desktop, so its not in the same place as where you specified in the tutorial.

    I'm not to exactly sure how to get to it, I tried going from C:\Users and down to \Desktop\ps2sdk\samples\graph and it still didn't work.

    So, any suggestions?

  5. #5

    Default

    You can use the command "ls" (LS) to list the contents of a directory. That will show you what subdirectories are available, and you can figure out where you are. Honestly, it would be easier to simply move the PS2SDK to C:\, and this will also help you to avoid issues with paths over 255 characters long.
    I may be lazy, but I can...zzzZZZzzzZZZzzzZZZ...

  6. #6
    byebyebye Guest

    Question Ugh.. EE threading problem...

    This is an issue that I've run into with the win32 ps2 dev. kit...
    I'm running winodws 7 and everything seems to be running fine. Everything compiles(Except, I think I get the odd error with c++ but I use C anyway), error free. The environment(msys/MinGW) runs fine.

    When it comes time to run the compiled source on the ps2 though, I end up with a problem. Threads don't work. I have not tried the IOP threading since I would rather just worry about the EE environment for the time being. I've tried both sources that I quickly wrote myself as well as pre-made projects(SMS, FMCB 1.7).
    Everything that was already compiled works fine(SMS already had a compiled copy in the bin folder that was working, same with fmcb), but when I compile it, it compiles error free(Not even 1 error.....) yet the threads don't even begin to work.

    The whole reason that I tried compiling SMS and FMCB was so that I could see if it was something that I was doing wrong or what but it's doing it with everything.. ~~ Help please! ~~

    Edit: Sorry for the bump.
    Last edited by byebyebye; 12-21-2010 at 01:01:02 PM.

  7. #7
    Join Date
    Sep 2006
    Location
    Germany
    Posts
    616

    Default

    Though the PS2SDK in the Win32 devkit is quite outdated, threading should still work.

    I suggest to post the non-working code.

  8. #8
    byebyebye Guest

    Default

    Quote Originally Posted by misfire View Post
    I suggest to post the non-working code.
    As I said, I compiled a (before hand) working compilation of SMS.. It's the one that comes in the dev kit or in it's package of compilable sources..

    My compiled code is as follows though(Bfeore any comments are made... Yes, I know it's poorly formatted...)
    everything compiles fine, imported kernel and debug headers and both of the libraries that go along-side them.
    Code:
    long MainThreadPriority=0x1;
    int iFaceThreadID;
    extern void* _gp;
    char *iFaceMsg=NULL;
    
    int iFace(void* param){
      init_scr();
      while(1) if(iFaceMsg!=NULL) scr_printf("%s", iFaceMsg);
    }
    int main(int argc, char **argv) {
      ee_thread_t   lThread;
    
      lThread.stack_size       = sizeof ( s_Stack );
      lThread.stack            = s_Stack;
      lThread.gp_reg           = &_gp;
      lThread.initial_priority = MainThreadPriority+1;
      lThread.func             = iFace;
      StartThread(iFaceThreadID = CreateThread(&lThread), NULL);
    
      iFaceMsg="Loading modules...";
    }
    Edit:
    If you have a (non-svn) link to the newest sdk - Even if I've gotta do repairs, IDC - please can you pass it on so I can update..

    Edit 2:
    I forgot to mention that the system that I am using is the ps2 slimline (old I think) the bios dump - when used in pcsx2 - reports as a jap version.. But I don't see how this is relevant to the issue I'm having as the source codes worked on it when they were pre-compiled..
    Last edited by byebyebye; 12-21-2010 at 11:13:30 PM.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Fixed, Pre-Built, Win32 PS2SDK :)
    By Lazy Bastard in forum Research & Development
    Replies: 111
    Last Post: 10-15-2011, 04:52:21 PM
  2. irxtool - Win32 port and more
    By misfire in forum Research & Development
    Replies: 4
    Last Post: 10-13-2008, 08:56:49 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •