PlayStation Development Network

---

Update: Ver. 1.1 - Added support for Caetla ECMEM EXEs.

---

PS2 has uLaunchELF and PS1 now has a MCLaunch

This application allows you to launch PS-X EXE from a Memory Card.
You can use included utility "exe2card" to convert a PS-X EXE to a executable "save".
EXEs up to 112 KB are supported and multiple EXEs can be placed on the same card if there is space of course.

Anyway, here are some screens:

good job, sounds great for didactic purposes.
Mind sharing sources?

While the source is nothing spectacular I think it's too early to release it, might do it in the future.

Basically launching is done like this:
Read Memory Card directory and get save names.
Check if the save is executable by looking for "PS-X EXE" product code.
List EXEs and wait for the user to confirm which EXE he wants to launch.
Read a complete save to the buffer, get OrgAddress, initial PC and ExeSize (minus the 2048 header).
Transfer headerless EXE to the OrgAddress.
Cleanly exit the launcher (StopCallbacks), reset stack to default and jump to EXEs Initial PC.

I don't use BIOS routines to launch the EXE but it still works as expected.
BIOS is probably doing the same thing anyway...

Great work shendo.

Is this in any way compatible with the same feature in caetla and the tools?

Thanks. It's probably not compatible (not unless it's format is the same by luck).

I never knew caetla had that feature (I dont have a cart so I never used it).
If you can post a Memory Card with the save or forward me to utility which makes
it I could look at that and make it compatible.

Its ECMEM.COM, its part of the caetla pc side tools. You use that program to make an image then upload it to the memory card using the MCUP.COM tool. I havent used it in a while but you ran your apps through the memory card manager. You can also provide a BMP file to use as an icon.
I asked a question a bit ago in another thread about low level SIO access. I had an idea that if we could somehow write an SPI library we could then access an SD card in SPI mode through the memory card slot. Then a utility like the one you have written could be used to run code from an SD Card

SPI would also allow use of GPIO expanders, ethernet and more, opening up hardware possibilities for the likes of LCD screens. Slowly I know, but still fun . I have had a look at stuff but think its beyond me at the moment.

Thanks for the info. I added support for ECMEM converted EXEs.

They did a few things differently though.
For some reason save title is set to gibberish (when viewed in BIOS MC manager)
and they stored the EXE name to a directory name instead in save title and stripped .EXE extension.

Anyway it was not a big problem to add it, just had to account for different offsets.

Damn, it is awesome tool.

Glad you got it working , and thanks for adding the feature and the shoutout in your app. Great work

I've been using MCLaunch to test a few things on a chipped PSOne, which works great. However, I'm unable to get things to work on a chipped PS2. MCLaunch seems to work fine. It boots, finds files on the memory card and begins loading. After a while the screen then turns black and nothing happends. I have no idea if it's a problem with MCLaunch or my little tests.

Has anyone else successfully used MCLaunch with a PS2?

AmiDog wrote:I've been using MCLaunch to test a few things on a chipped PSOne, which works great. However, I'm unable to get things to work on a chipped PS2. MCLaunch seems to work fine. It boots, finds files on the memory card and begins loading. After a while the screen then turns black and nothing happends. I have no idea if it's a problem with MCLaunch or my little tests.

Has anyone else successfully used MCLaunch with a PS2?

I've personally never tried it (though it does sound very cool), but that blanking of the screen sounds like something is crashing it. I'm not sure how you would debug PSX games on a PS2 to be honest, but Shendo would need to look into it as he never released the source. I'll send him a PM for you now so this doesn't hang unanswered/unresolved.

Unfortunately I don't have the time to tackle this issue but I'm willing to publish the source.
Hope it helps.

Line 161, "int WaitMemCardHardEvent()" s interesting. It's an infinite loop with no way to break out apart from a Memory Card detect or fail situation. That might be the cause of the black screen, but in any case, the GPU should not clear itself. As a test, I can display a white screen instead of a black screen, but it would be easier if I could debug somehow on a PS2. I'll have to ask some PS2 guys when I have time, or figure it out myself later.

Beautiful code however. Well commented and structured. Well done

Thanks for the sources. Had a quick look but didn't see anything obvious. These lines are rather interesting though:

char *ProgramPointer;

if(RunExeFlag) goto *ProgramPointer;

Didn't know you could do it like that. (I'm using function pointers to handle similar situations.)

I made a few tests yesterday, starting with the smallest assembly program possible which just rendered a single primitive. That worked. I then began extending it, made it larger by inserting lots of nops etc. And then I started copying various pieces of code from the tests which failed. The first piece of code which failed was checking bits in the GPU status register. I didn't have time to figure out exactly why it failed.

So, MCLaunch is probably working correct.

I did test a few simple exes from the Hitmen website, and they also failed. Maybe the PS2 isn't all that PS1 compatible if you don't play by the book. I.e. if you don't use the official SDK and/or the BIOS much but rather poke around at will...

edit: Or maybe the BIOS included in the PS2 is very different from a real PS1 one, making stuff fail which relies on things being at specific places.

I can confirm that it wasn't a problem with MCLaunch. After spending way too much time trying to locate the offending piece of code, one of the problems turned out to be code like this:

#define GPU_DATA_ADDR (0x1f801810)
#define GPU_CONTROL_ADDR (0x1f801814)
#define GPU_DATA *((volatile u32 *)GPU_DATA_ADDR)
#define GPU_CONTROL *((volatile u32 *)GPU_CONTROL_ADDR)

...

gpu_wait();
GPU_CONTROL = 0x01000000;
GPU_DATA = ...
GPU_DATA = ...

...

Notice the control write above? I have no idea why I put it there in the first place, it's been there for years. But what it should do is tell the GPU to stop rendering and clear the command buffer. But since I first wait for the GPU to be finished, it really shouldn't do anything at all. This works on every PS1 I've tested, from the very first SCPH-1002 to the very latest PSone, as well as on any emulator. On the PS2 however, the primitive following the control write will not be rendered *. This is why I always ended up with a black screen, since code like that was used in the functions I use to print characters to the screen... After removing the useless control write, I no longer get black screens

edit:

*) I don't know if that's actually the case, or if it's an issue with the busy-flags in the GPU status register or something else. But in any case, nothing got rendered.

It would be nice to know exactly where in the code it was failing on the PS2. I'm sure something isn't being handled correctly as all PSX games used the standard libs, and none ever did something like this.

I'm going to create a few tests to be sure. However, just had a look at the Blade Lib, and it does something similar to what I was doing:

#define gp0 (*(vptr)0x1f801810)
#define gp1 (*(vptr)0x1f801814)

void GP_SendGPU0(u_long gpu_primitive)
{
gp0 = gpu_primitive;
}

...

gp1 = 0x01000000; // reset the command queue
GP_SendGPU0(0xa0000000); // send 'send image' primitive

...

Maybe that's where I got the idea from.

edit: libpsx (bITmASTERs psx library) also does this:

li t4,0x1f800000
li t0,0x01000000
li t1,0xa0000000
sw t0,GPU1(t4)
sw t1,GPU0(t4)

If someone manages to get this running on a ps2 could it potentially be used as part of a softmod to get ps1 games running from usb? For e.g having a ps1 mem card in a ps2 with a modified save that is in fact a game id executable that points to the real game image file on usb. Is such a thing technically feasible? It would be better than using cdrs on a ps2 or emulators.

Emulation has already been achieved for this purpose, but I hear ya. Compatibility is very spotty. There's the official $ony pop station emu for ps2 which got leaked ages ago which has a higher compatibility rate than ps2psxe, but its technically illegal to possess or use (copy written closed source $ony code that was never officially released), but from what I've read that has its drawbacks as well. I use ps2psxe myself as my ps2 has no optical drive at all (lol). Took the damn thing out when It croaked. I have a phat ps2 so between the internal HDD and usb , i got allmy ps2 games and homebrew covered, but I digress....

I don't think an automated softmod would work in ps1 mode on the ps2 though as memlaunch still needs to be loaded via CDR to access the ps-exe files in the first place which would require either the swap trick/boot disc or modchip to get it to run. Correct me if I'm wrong, but I don't believe there's anyway to exploit a psx memcard to automatically run code at bootup.