I figured this would be a good place to ask about this. I'm interested in console development and the PS1 and perhaps the PS2. I'm interested in these consoles as they aren't quite as limited as older systems and can be programmed with C and such. So I'm just wondering what some of you would have to say as advice. And I mean for either PS1 or PS2. Obviously the PS2 will have more muscle to it, but what about ease of development? I'm used to working on the PC. I've primarily used MS Visual C++ 6.0 and the Allegro library for development. Will it be difficult to setup a PS1 and/or PS2 enviroment to start making things? From what I briefly read in the forums, it sounds like PS1 has some functions in the BIOS and you have to link them in your executable or something like that, but it handles everything you could need it seems. I'm not sure about PS2. I would guess it'd be easiest to develop having official libraries and tools? Basically I'm just looking for what's up with everything. Developing for the PC is easy and has virtually unlimited resources, but it's not as fun as developing for a console.
If I remember correctly, the PS1 BIOS contains routines for accessing devices like the CDROM drive+file system, Pad and Memory Cards. There are special addresses (0xA0, 0xB0) that, when called with a constant loaded into a CPU register, dispatch to the corresponding BIOS routine. The more interesting devices (GPU/Graphics, SPU/Sound, MDEC/MPEG decompression) have to be accesses by means of memory-mapped I/O or DMA transfers. Official dev kits have everything you need to program these consoles, including compiler/linker/debugger, libraries for all hardware devices, as well as documentation. I'm also quite sure there was an active hobbiest scene; just try a search for "ps1 homebrew" or something like that, you should find (unofficial) compilers, libraries and hardware documentation. Maybe another member can post some more information, as I haven't done much with the PS1 (in terms of programming ). The PS2 is a different beast. Besides some other specialized hardware (IPU/Image Processing, SPU/Sound), it has two processors: the so-called Emotion Engine (or EE for short) executes the game's logic and sends data to the graphics chip (GS/Graphics Synthesizer), the second CPU (I/O Processor, IOP) implements access to all other hardware devices (CD/DVD drive, USB/Firewire, Pad, Memory Card, Hard Drive). The EE loads device drivers onto the IOP, either pre-defined (CDVD, Pad, MC, file systems for DVD/HDD, ...) or custom ones; both CPU communicate by means of a RPC-style interface. Graphics commands are assembled by the EE, then sent to the GS by means of a DMA transfer. In addition to its main CPU core, the EE also contains two (independent) vector processors that can both perform 4 floating-point operations in parallel. Both vector units (VUs) have there own local data and instruction memory. VU0 has a coprocessor connection to the EE core, so it can execute specific instructions directly; VU1 does not have such a connection, so it can only execute specific microcode programs that have been sent to it (but VU0 can operate in this mode, too). However, VU1 has more local memory and a direct connection to the graphic interface. The PS2 Linux Kit that was sold a while ago contained quite a lot of hardware documentation, including a User Manual for the EE, VU and GS. However, no documentation of the IOP or the device drivers was included. The homebrew scene for the PS2 is quite active today, and they also have (unofficial) development tools and libraries for both EE and IOP (http://www.ps2dev.org). The tool chain is based on two older GCC releases (one for the EE, another one for the IOP) and a set of patches, but you can use a script from the site to install them easily; however, you need a Linux system (or a VM :icon_bigg) for this, as the GCC included in current Cygwin releases cannot compile the old sources.
If your not used to command line tools, makefiles and such it might be a bit to get used to in the beginning. Also iirc. the PSX only have API for reading sectors from the discs and nothing for reading a filesystem, so just doing fopen() wont work (from what I remember). You also have the memory limits to think of when coding for these platforms, no 2GB of memory or virtual memory to rely on. Other than that, good luck and happy coding :thumbsup:
Well, the command line is no problem, but makefiles and such I've never liked. Wouldn't one of the libraries have file access functions? It'd be awfully strange if every developer had to code their own file access routines based off reading sectors. The limited memory is certainly interesting when you're used to have unlimited memory. Same for processing power. But it's alot less limited than say NES or SNES. Just in general everything I've read suggests that the PS1 is pretty easy to develop for. PS2 ofcourse interests me since it has even more processing and memory to offer.
PS1 game discs have a file system, as the BIOS needs to read some configuration files to be able to start the game. Just insert any PS1 disc into your computer's drive, you will find at least two files: SYSTEM.CNF specifies some parameters, the most important being "BOOT=xxx"; "xxx" is the name of the game's executable, and it is the second file the must be present on the disc. However, just like babu said, the PlayStation does not require games to use the file system for their data files, too; they can use direct sector reads. When you examine such a disc on your computer, the overall sum of all file sizes will be much smaller than the used area on the disc, as the game's data simply is not indexed in the file system. However, I have just looked at some games, and they contain a file system with almost all files stored in a regular directory structure; therefore, I assume regular file access routines to be able to read them ;-).
Maybe I just had to old SDK/manual then? As I remeber that being one of the things I found annoying about coding for it. And of course it has a filesystem, it uses standard ISO 9660 iirc. But I just can't remember there being a API for reading it in the SDK.
Unfortunately, I don't have an SDK, so I cannot comment on it. However, the BIOS has to be able to read a standard ISO file system, even if it is just to read SYSTEM.CNF and the game's main executable. A quick Google search for 'playstation system calls' leads to http://www.geocities.co.jp/Playtown/2004/psx/syscallj.htm; as it is in japanese, I cannot read it, but it at least suggests that a regular open call (syscall 0xa0/0) should be able to open files on the CDROM. As I wrote, I have seen games (FF6, Suikoden) that store their data in regular files indexed in the ISO FS, and I suspect the developer's wouldn't do this if there were no easy way of reading the files again:love:.
Have you considered developing for the PSP? It has an amazing homebrew SDK and does not require any dev hardware to develop/debug.
Yes I have considered it and even done some of it. However since I barely use my PSP and find most PSP users to be selfish warezing assholes, I'm not exactly interested in developing things for the PSP. Besides part of the point would be to develop on a retro system which PSP doesn't quality for. PS2 only recently I think, entered the retro side of the line. But PS1 I think would be fun to play around with.
You can use Blade's or Rob Withey's PSX libs with MIPS GCC compiler to produce PSX executables. Blade's libs come with documentation and examples so it's really easy to start off. You can also test your programs on PC instantly as ePSXe supports launching of PSX executables, just make a .bat and enter this: "ePSXe dir\ePSXe.exe -nogui appname.psx" You can download libs from http://hitmen.c02.at/html/psx_sources.html Also note that in order to run PSX EXE on a real machine it needs to be multiple length of 2048 bytes, use a program called EXEFIXUP to fix your EXEs to required size.
There is, but it sucks so most people didn't use it. Sony provided a new library for doing that one as well, that wasn't so limited. But not many people used that one either. Including graphics in your code is probably the easiest way to start.
