forums.ps2dev.org

I'm spanking brand new to the world of PS2 Homebrewing (and games deving in general), so I'm hoping to get some questions answered without inciting too much flaming.

1) What programming languages to you people feel are necessary to have a good grip on making homebrew titles for a PS2? What programs are not essential but will enhance my work?

2) Is this similar to (not literally) actually developing a game for the PS2 in the way say, Naughty Dog would (once again not literally as ND would, but I'm using them as an example)?

3) Though in some guide one of the options for loading a program/code/etc. is using a ModChip...that is illegal right?

4) How will I have to adapt your advice/tutorials/work for my PS2 which is PAL (Model SCPH 30003)?

5) To be honest, to me, this is like giving me a hammer, some sheets of metal and then asking me to build a Ferrari...so is there any specific documentation that can help pass these hurdles to a point where I appreciate and understand most of what is going on here?

Thanks a lot.
I hope I can contribute some great stuff to this awesome site!

[EDIT]

6) What do I have to know for graphics/sound programming for PS2 homebrewing (and in general)?

1. C. mips ASM helps a lot though.

2. Our toolchain and ps2sdk are quite similar to what sony provides to official developers.

3. Depends where you live.

4. PAL vs NTSC makes virtually no difference to how you do things, other than making them fit the screen. Actually, most homebrew is designed to have the same copy work with both NTSC and PAL screens.

5. Uh...

Aah nice thanks a lot man!

So C, MIPS, and ASM it is.

Erm...what are MIPS and ASM?



I'm planning on making my PS2 controller work on my PC. Anything to help me here?

[EDIT]

Doh! Most important question:
Do I have to use Linux or can I use Windows (XP) to get my work done?

Not mips and asm... MIPS ASM. Mips is an architecture (like x86 (your PC), or ARM), ASM is an abbrevation for assembly.
So MIPS ASM is the assembly language for mips CPUs.

No, you don't have to use linux, but you'll have to install cygwin (cygwin is a POSIX (unix-like) environment for windows)

Thanks again...

Now where to actually begin everything...???

Drakonite wrote:...but you'll have to install cygwin...

you dont have to if you use loser's win32 installer. it's a bit little easier than doing it with cygwin. and faster since its already compiled.

PrinceMajinVejita wrote:Now where to actually begin everything...???

hmm, thats a good one.
i would say, when you have installed the toolchain. why not try the hello world example in the ps2sdk/samples directory :) (type "make" in the commandline")

Saotome wrote:

Drakonite wrote:...but you'll have to install cygwin...

you dont have to if you use loser's win32 installer. it's a bit little easier than doing it with cygwin. and faster since its already compiled.

It still uses the cygwin dlls.. but meh. I highly recommend a full cygwin setup as some of the tools will help with ps2dev quite a bit and I think some of the ps2dev tools don't have straight win32 versions.
Choice is yours though.

Saotome wrote:

Drakonite wrote:...but you'll have to install cygwin...

you dont have to if you use loser's win32 installer. it's a bit little easier than doing it with cygwin. and faster since its already compiled.

PrinceMajinVejita wrote:Now where to actually begin everything...???

hmm, thats a good one.
i would say, when you have installed the toolchain. why not try the hello world example in the ps2sdk/samples directory :) (type "make" in the commandline")

Aah, you've just underlined the main problem. I don't know how to do any of that stuff. That's the reason why I'm here! To Learn about it all and then contribute to the best of my abilities!

Think of me a complete n00b. No experience. No nothin'. Well my experience is only limited to being really good at playing the PS2 games, but that's all. So I need to know things that start with the basic-est of the basics.

Thanks greatly.

Aah, you've just underlined the main problem. I don't know how to do any of that stuff. That's the reason why I'm here!

i already thought so ;) , thats why i suggested the win32 toolchain installer. all you have to do is unpack the zip, start the setup.exe, write you code (or try the hello.c example), type 'make' in commandline, start you elf-file with inlink or something like that.

if you dont have any loader installed yet, look here

If you don't know anything about programming I very sincerely recommend you start by learning how to program on a PC, write a few small demos, and maybe then attack the PS2.

Drakonite wrote:4. PAL vs NTSC makes virtually no difference to how you do things, other than making them fit the screen. Actually, most homebrew is designed to have the same copy work with both NTSC and PAL screens.

I'm afraid you're dead wrong here. PAL and NTSC make very large differences, not because of the framebuffer size, but because of the vsync timing.

For example, if you have the program:
If we assume here that it waits for vsync to flip, which is very common, then printf("The ball is here!\n"); will only be executed once per frame, that is at 50Hz minus any performance decrease due to whatever to the EE itself.

This is a less of a big deal in simple demos, but for things which have interactive input like games, as well as things which might have some sort of AI running, or background logic, and ESPECIALLY games with online play, this can become a serious issue.

One example, is if you have an NTSC and PAL game playing on line with each other, it's very diffiult to keep them in sync due to this timing difference and how it effects your code.

Even if you are running multiple EE threads, the fact that it waits on something effects the load on the EE at particular times, and this is something you have to work around.

Just some food for thought.

If you're tying important timing things like networking to the vsync, you're a scrub. :)

Well they are indirectly tied at some point anyway because the rate you process/feed frames to the GS changes, and as a result of that latency and EE load changes.

If you don't believe me take it from Sony, this is why they do not recommend alloing cross-region (NTSC to PAL) games playing online with each other.

I was assuming he only meant the differences between the explinations we give for things and how it could be different for a PAL. I just meant to give a general idea of the only differences... Timing is trivial typically.. and I guess I just forgot ;)

Seeing as many console games have a hard time keeping a steady framerate I don't think ntsc/pal timing differences are the main reason Sony does not recommend it.

The ps2 has separate timing hardware for a reason, eh? :)