HD Homebrew Project Developement (Old Thread)

[Polo35]

@ rodogg - here's my makeshift tutorial on using Polo35's mc emulator (gui version.) Its kinda rough but it does the trick.

http://sksapps.info/forums/showthread.php?t=4397

Great.

Thanks for making it.

Why do you want to load FAKEBOOT during IOP update process?

It was just a mistake, i copy mcs2eosd code with fakeboot loading without thinking of his fonctionality.
When making test, i found prog wasn't able to reset iop properly, and found that fakeboot was responsible.

Conserning img file loading, no progress, i can't load imgirx with "SifIopReset(NULL,0)", and modules loading don't work after load_async when i use "rom0:UDNL rom0:EELOADCNF" instead of NULL for IopReset arg.

That's why i try to use xsio2man, xmcman, xmcserv, xpadman instead of updating iop with an img file, and that work fine.

Best regards

Polo

[romz]

Conserning img file loading, no progress, i can't load imgirx with "SifIopReset(NULL,0)", and modules loading don't work after load_async when i use "rom0:UDNL rom0:EELOADCNF" instead of NULL for IopReset arg.

There are two possible reasons:
1) sbv_patch_enable_lmb() call is used after the IOP update while there is no need to use it with a IOPRP image
2) PS2SDK libraries don't know of IOP update (which is equal to IOP reset for EE side) while they use internal counter to detect IOP reset calls

That's why i try to use xsio2man, xmcman, xmcserv, xpadman instead of updating iop with an img file, and that work fine.

That's a good idea since there will be no need to mess with any external modules and to reset IOP just for the memory card dumping. However ... it's better to learn the IOP update trick since it can be very useful. It's essential to replace CDVDMAN/CDVDFSV modules and there is a possibility to use it to install the emulator without FAKEBOOT module (there will be no need to know path to the certain IOPRP-image for the certain game).

[ffgriever]

I've been playing today with mass: and host: (just for fun ) support for mc emulator. While it works with some games, with most it just hangs (BSOD, like in ffx) or there are weird issues (like in ffxii).

I'll use examples.

FFX - just hangs, dos not show a thing. To debug it, I had to load ps2ip, dev9, ps2smap and modified (stripped of anything unneded) version of ps2link module (net is the only way for me to see iop printfs, because I don't have usb cable). The results might be different, because I had to load few additional modules to be able to read this, but it seems ffx can't load iopsound module (-400 in a loop) - so there is probably not enough iop memory (but whether the problem remains the same when I don't load those additional modules to see this, I don't know). The usb/host writing/reading works fine (I've put for tests loop thread that writes come data into files every few seconds).

FFXII - game starts, seems the emulator recognizes virtual card image, but on slot choice I don't see any cards. (I can see my real card if I delete the images - no virtualisation occurs). If I enable virtual card for one slot, the real card in the other is still unaccessible. As above, I loaded few additional modules to be able to read messages using ps2client. It seems that emulator starts fine but then weird problem appears. There is a function hookSio2man51. It checks for control code and sends the data to "real" function or to the virtualised one. But in this case, it never receives 0x81. It receives only 0x01 in a loop (forever) - no other functions are called (I've placed some printfs in every one). Is 0x01 code related to pad (pad ready?)? I don't think, it's a memory problem, because I can load additional modules (almost 120kB) - using full ps2link module.

MOTOGP4 (PAL) works fine with both (just example).

The size of the irxs (in both usb and host case) are not a problem (in both caes, they're smaller than dev9+atad+hdd+pfs for hdd emulation) - ps2ip+host+dev9 for host: and usbd+usbhdfsd for mass:. So it's probably some huge buffers problems (I'll have to check it, once I'' have some more time).

Sorry, maybe it's dumb, but I don't know ps2 very much.

Next thing. Is there a way to change default stack size for iop programs (at compile time? or maybe before execution?)? I know, that for nix-like systems, it's the environment that controls main threads (and default) stack size. Why do I need it? The usb mass driver gives me stack overflows when opening/writing files from within iop. The stack has to be at least 0x0800 (2K). There is an easy walkaround - I just rename start to startThreaded and write new start function, which only creates new thread (with greater stack size) and waits for this thread to return (and returns a value based on the value returned by the thread). While it works, it's still a walkaround.

thanks.

[romz]

I've been playing today with mass: and host: (just for fun ) support for mc emulator. While it works with some games, with most it just hangs (BSOD, like in ffx) or there are weird issues (like in ffxii).

I'll use examples.

FFX - just hangs, dos not show a thing. To debug it, I had to load ps2ip, dev9, ps2smap and modified (stripped of anything unneded) version of ps2link module (net is the only way for me to see iop printfs, because I don't have usb cable). The results might be different, because I had to load few additional modules to be able to read this, but it seems ffx can't load iopsound module (-400 in a loop) - so there is probably not enough iop memory (but whether the problem remains the same when I don't load those additional modules to see this, I don't know). The usb/host writing/reading works fine (I've put for tests loop thread that writes come data into files every few seconds).

"-400" is the KE_NO_MEMORY error code. The game needs more memory on IOP.

FFXII - game starts, seems the emulator recognizes virtual card image, but on slot choice I don't see any cards. (I can see my real card if I delete the images - no virtualisation occurs). If I enable virtual card for one slot, the real card in the other is still unaccessible. As above, I loaded few additional modules to be able to read messages using ps2client. It seems that emulator starts fine but then weird problem appears. There is a function hookSio2man51. It checks for control code and sends the data to "real" function or to the virtualised one. But in this case, it never receives 0x81. It receives only 0x01 in a loop (forever) - no other functions are called (I've placed some printfs in every one). Is 0x01 code related to pad (pad ready?)? I don't think, it's a memory problem, because I can load additional modules (almost 120kB) - using full ps2link module.

AFAIR, 0x01 code is for PADs. Does FF XII work with HDD version (I don't have FF XII) ?

Next thing. Is there a way to change default stack size for iop programs (at compile time? or maybe before execution?)? I know, that for nix-like systems, it's the environment that controls main threads (and default) stack size. Why do I need it? The usb mass driver gives me stack overflows when opening/writing files from within iop. The stack has to be at least 0x0800 (2K). There is an easy walkaround - I just rename start to startThreaded and write new start function, which only creates new thread (with greater stack size) and waits for this thread to return (and returns a value based on the value returned by the thread). While it works, it's still a walkaround.

You can specify stack size for threads while there is no need to change default stack size for resident modules (in this case) since they return control to MODLOAD on termination.

[ffgriever]

"-400" is the KE_NO_MEMORY error code. The game needs more memory on IOP.

Thanks, that's what I thought (so although the modules itself are smaller, they consume more memory - got to check this later for possible mem optimisations - just two files opened, no need for big buffers).

AFAIR, 0x01 code is for PADs. Does FF XII work with HDD version (I don't have FF XII) ?

Yes, FFXII works fine with hdd... And I believe the 0x01 is sent continuously because game asks whether the pad is present. Don't know why there is no MC communication though.

You can specify stack size for threads while there is no need to change default stack size for resident modules (in this case) since they return control to MODLOAD on termination.

Not exactly. The mchdd_configure function is called from within main thread, and it contains open functions (O_RDWR, no stack overflows with O_RDONLY) - so I had to call it as thread or from within thread with at least 2K stack.

[romz]

Yes, FFXII works fine with hdd... And I believe the 0x01 is sent continuously because game asks whether the pad is present. Don't know why there is no MC communication though.

It looks like a hidden "NULL-pointer" / "Stack Overflow" problem. Btw, you can't catch memory card commands with hookSio2man51 when MCMAN module is in use. That hook is for MC2_D, MC2_S1 and other similar modules.

Not exactly. The mchdd_configure function is called from within main thread, and it contains open functions (O_RDWR, no stack overflows with O_RDONLY) - so I had to call it as thread or from within thread with at least 2K stack.

I believe it's better to modify FS-driver since it apparently causes troubles like "stack overflow".

[ffgriever]

It looks like a hidden "NULL-pointer" / "Stack Overflow" problem. Btw, you can't catch memory card commands with hookSio2man51 when MCMAN module is in use. That hook is for MC2_D, MC2_S1 and other similar modules.

Sorry, my bad... I thought ffxii uses those, but now I remember it loads mcman and mcserv. Nevertheless, hookSio2man25 remains silent (I didn't noticed any printfs I placed there).

I believe it's better to modify FS-driver since it apparently causes troubles like "stack overflow".

Sure it's better, but current walkaround is just simpler.

[romz]

New MCSIOEMU is out:
www.cdvdmania.com.ru/misc/mcsioemu_05.zip

Changelog for version 0.5:

1. New options:
   "-stack=" to set stack size for power-off thread (default: 0x1000)
   "-thpri=" to set thread priority for power-off thread (default: 0x10)
   
2. MCSIOEMU banner:
   mcsioemu.irx prints banner on startup.
   
3. New spare buffer clean-up on reading:
   ECC buffer will be filled with proper values depending on memory card flags
   
4. Separate spare buffers:
   each virtual card has its own buffer for ECC
   
5. Dynamic I/O buffer allocation:
   mcsioemu allocates memory for I/O buffer with AllocSysMemory using the biggest page size
   
6. DEV9 shutdown via "hdd" device:
   mcsioemu call devctl("hdd:", HDIOC_DEV9OFF, ...) to provide compatibility with old DEV9&HDD modules (including homebrew modules)
   
7. Hook for mcman_63 & mcman_68:
   mcsioemu blocks calls to sceMcReadFast & sceMcWriteFast routines to protect a real memory card

Though mcsioemu hooks sceMcWriteFast routine I can't guarantee it's absolutely safe to insert a real memory card to a virtualized slot with new games. I don't know if SCE didn't invent sceMcWriteFast and sceMcReadFast counterparts for libmc2 library. Btw, I foresee a solution sceMcWriteFast / sceMcReadFast problem that can make those calls compatible with the emulator.

This version has a bug so it can't really hook sceMcReadFast & sceMcWriteFast calls.

[ffgriever]

I was able to make usb driver (usbd) and mass driver (usbhdfsd) less memory-hungry. Now the mcemu can work with usb mass and it works fine with all the games that can be run using hdd version (still too much mem usage to run games like ffx-2). I have hdd in my ps2, so it's not really very helpful for me, but people without hdds can make use of it.

So if anyone is interested, just let me know (it's based on mcemuirx 0.5).

[barf]

i am interested for usb support

Somebody already said that, this is a dev thread,
if you want USB support please add it, please do not spam this thread.

or make a poll instead, after you see a release that does not support whatever you want.