HD Homebrew Project Developement

[Polo35]

Originally Posted by ffgriever

---Mcemu & uLE---

I'm not sure it's a good idea to have mcemu working under uLe.
User can allready access to vmc through vmcfs driver.
So, i think i have to find best place for mcemu EE core, but no matter of uLE here.

Originally Posted by ffgriever

Hard to believe, but I found, that I'm getting the best results if everything is placed just under 1MB, with stack starting just before application and temporary buffers starting at 0x88000.

Thanks for the info, i'll try with such settings.

Originally Posted by ffgriever

In case of mcemu it's a little bit harder, because you have more modules taking the EE RAM. Do you use two separate EE cores with embedded usb modules in one and hdd modules in second one? I think it's the best choice, as that would save a lot of memory (some games are using some of the mem below 1MB, thus can cause some nasty problems ). You of course need them with your app, as the game running might overwrite them (and you'll need them after every of the iop resets).

I use same process as HD_Gui v1.07, which is to send only needed modules to iop and pass the iop address to mcemu EE core when loading it.
Then mcemu copy modules to EE before reseting iop.

With this process, only needed modules are resident in EE core.

If usb is use only usbd, usbhdfsd and mcsioemu modules are copied to ee->iop->ee.
If hdd is use only dev9, atad, hdd, pfs and mcsioemu modules are copied to ee->iop->ee.

The only point i can modify is when copying modules from iop to ee in mcemu.
For the moment memory is allocated using malloc, so they are place in temporary buffer.
Here i can specify an address by memcopying them in a safer place.

Originally Posted by ffgriever

I don't know what you mean by zoneloader method, as I have never checked its sources.

Fusion released some time ago source of ZoneLoader.
There is some interesting stuff in there.
Search with google and you will see. ( You maybe can found source here if i remember. 'psx-scene' )


Here the fonction i use:

u32 New_SifSetDma(SifDmaTransfer_t *sdd, s32 len)
{

 if((sdd->attr == 0x44) && (sdd->size==0x68))
 {
  SifCmdResetData *reset_pkt = (SifCmdResetData*)sdd->src;
  if((reset_pkt->chdr.psize == 0x68) && (reset_pkt->chdr.fcode == 0x80000003))
  {
   return New_Reset_Iop(reset_pkt->arg, reset_pkt->flag);
  }
 }

 DIntr();
 ee_kmode_enter();
 u32 ret = Old_SifSetDma(sdd, len);
 ee_kmode_exit();
 EIntr();

 return ret;
}

u32 Hook_SifSetDma(SifDmaTransfer_t *sdd, s32 len)
{
 __asm__(
  "la $v1, New_SifSetDma\n\t"
  "sw $v1, 8($sp)\n\t"
  "jr $ra\n\t"
  "nop\n\t"
 );
 return 1;
}

Originally Posted by ffgriever

But I can tell you how I do it:

Thanks again for your help.

Originally Posted by ffgriever

No, I mean changing only the stack pointer.

OK.

Because with my own 'IRG', i use some code from 'Artemis Project' and it save stack in 14 registers before testing pad, like this:

 addiu $sp, $sp, -240
 sq $ra, 0($sp)
 sq $s0, 16($sp)
 sq $s1, 32($sp)
 sq $s2, 48($sp)
 sq $s3, 64($sp)
 sq $s4, 80($sp)
 sq $s5, 96($sp)
 sq $s6, 112($sp)
 sq $s7, 128($sp)
 sq $a0, 144($sp)
 sq $a1, 160($sp)
 sq $a2, 176($sp)
 sq $v0, 192($sp)
 sq $v1, 208($sp)

Originally Posted by ffgriever

--EESYNC---

It's largely easier to write a 70 line module then writing a module which hook fonctions.

I use eesync source code you release some time ago, but port it to ps2sdk.
Thought only loadcore20 was not define.


Best regards

Polo

[ffgriever]

Originally Posted by Polo35

Fusion released some time ago source of ZoneLoader.
There is some interesting stuff in there.
Search with google and you will see. ( You maybe can found source here if i remember. 'psx-scene' )


Here the fonction i use:
[...]

Well, so it's definitely the same method... just used a little bit differently. This exact method will give problems with some homebrew apps though (checking the exact size, while they can be different)... but since the mcemu is not meant for homebrew apps, it doesn't matter at all.

Because with my own 'IRG', i use some code from 'Artemis Project' and it save stack in 14 registers before testing pad, like this:
[...]

Sorry, but this code doesn't save stack in registers, but saves registers on stack (and then most likely restores them after the check procedure is done - context switching most likely)... I would do (and I did) it more carefully, so that no such actions would be needed. I will take a look at artemis project .

I use eesync source code you release some time ago, but port it to ps2sdk.
Thought only loadcore20 was not define.

It was written and compiled under ps2sdk... It required no porting . I defined loadcore20 import myself in loadcore.h.

[slicer74]

Is there a way to increase speed access to the usb ?

[dlanor]

Originally Posted by Polo35

I need your opinion.

In dump/flash function HD_Gui can use image files with or without ECC datas.
But PCSX2 can only use image with ECC, and mcsioemu module only without ECC.
Thought, i can implement ECC handling to our module.

I think it's not a good thing to allow 2 form for our vmc file.

I agree that our PS2 VMC implementation only should have one form, and if this differs from PCSX2 the natural solution would be to make a separate PC program for conversion from the PCSX2 form to the form we use on a real PS2. Since PCSX2 is a PC application, it is only natural to let the same PC handle any conversion needs.

So do you think it's better:

1: To keep Romz format ( with .mci file ) and emulate completely ECC data in flash/dump modules ?

2: To use pcsx2 format and implement ECC calculation into mcsioemu module ?

That depends mainly on two things:

1: Is it possible for any PS2 application to access the ECC data of a real memory card in any way whatever, or is this hidden from physical access by the PS2, accessible only internally to chips on the memory card.

2: How much impact does the ECC calculation have, both on the runtime delays and on the development effort.

Point 1 may force us to implement ECC, since we must have full compatibility access-wise. So any kind of access that a PS2 program can make on a physical MC should also be emulated for VMC files. But if it is impossible for a PS2 program to access the ECC data (which I don't really know), then and only then can we ignore ECC in our implementation.

Point 2 only applies if point 1 does not force us to implement ECC for basic compatibility to real MCs. In that case we might still want to go for PCSX2 compatibility, but IMO that should then only be done if it will not slow down the emulation by any major factor. And even then it might not be worthwhile, if it would demand too much development effort, better spent on other projects. PCSX2 compatibility can always be handled by a separate conversion utility on the PC, as mentioned above.

In any case that need some work.
With first choise, i need to remove some options in HD_Gui, and some code in dump/flash modules. And someone can maybe wrote a little win prog to convert our vmc file to pcsx2 format.

That is the choice I prefer, unless real memory cards allow access to ECC data, which I doubt.

With second choise i need to add ECC handling to mcsioemu module.

For me it's easier to let pcsx2 out of HD_Gui dev, but i think users prefer choise 1.

Users often 'think' that they'd prefer something until they've had a chance to compare it to something better.

Leaving out the ECC stuff (if not really needed) will make the development faster, and I'm sure all users want to get the new emulator sooner if possible. And an implementation without ECC calculations will also be much faster for all sector access, and I'm sure all users would want higher speed too.

The only 'crux' of this matter is whether or not the ECC data of a real PS2 memory card can be accessed by a running PS2 program or not. Because if that can be done, then we too need to emulate it.

Last point, i got a 'Combo button trick' working with some game, ( And only if Ps2 is booted with FMCB ) using some code from 'Artemis Project', but that's not reliable, so no way to include it in v1.8.

If you do include it in some future version you'll also need to make its activation optional, since it is bound to cause conflict with some games, no matter how 'exotic' button combinations you choose. There will always be some games that need to have it completely disabled.

Best regards: dlanor

[PALGamer]

Originally Posted by dlanor

1: Is it possible for any PS2 application to access the ECC data of a real memory card in any way whatever, or is this hidden from physical access by the PS2, accessible only internally to chips on the memory card.

If I remembered correctly, if u want to be able to 'flash' the vmc image to an actual mc using hd-homebrewproject (used @ the very beginning of FMCB) it would have to have ECC, making it incompatible with PCSX2 formats, and the other way around..

[dlanor]

Originally Posted by PALGamer

If I remembered correctly, if u want to be able to 'flash' the vmc image to an actual mc using hd-homebrewproject (used @ the very beginning of FMCB) it would have to have ECC, making it incompatible with PCSX2 formats, and the other way around..

I think you have misunderstood a few things:

It is PCSX2 which demands the presence of ECC data, not our VMC stuff.
My question only concerned whether or not a real PS2 MC allows direct access to the ECC bits, because it is only then that we have any reason to emulate similar access. Without that need there is no reason for us to implement ECC at all.

And it is the HD Project program that Polo35 is redesigning,
So the needs of the old version for various operations are no longer relevant.

A new version without ECC would naturally be able to store contents from a VMC file onto a real MC regardless of ECC usage, though I'm not sure about the precise low-level methods it would for this.

Best regards: dlanor

[Polo35]

Originally Posted by ffgriever

Well, so it's definitely the same method... just used a little bit differently. This exact method will give problems with some homebrew apps though (checking the exact size, while they can be different)... but since the mcemu is not meant for homebrew apps, it doesn't matter at all.

It's the same method, ( patching stack pointer ) but in my code, calling 'Old_SifSet...' in kernel mode crash ps2 after some call.
So, your method is better at this point.

Originally Posted by ffgriever

Sorry, but this code doesn't save stack in registers, but saves registers on stack

OUPS.
Seem that I have to learn asm basis.

Best regards

Polo

[Polo35]

Originally Posted by slicer74

Is there a way to increase speed access to the usb ?

Yep.

ffgriever told me how to do this, and it's implemented in my version.
A new option allow to set a 'CacheSize' value between 1 and 10.

I use a correspondence table to set cachesize in usb or hdd modules.

This option increase save/load speed, but decrease game compatibility.
Loadmodule return -400, ( no more memory ) in some game.


Best regards

Polo

[Polo35]

Concerning ECC datas.


Old Mcdump and Mcsioemu modules just ignore them.

Jimmikaelkael add some code in mcdump to read them from memorycard. ( pcsx2 compatibility )

Mcflash can build those datas before flashing a page if the vmc file don't contain them.


Conclusion:
None of the 3 vmc modules need ECC to work properly.
So if we don't care of PCSX2 compatibility, we can let mcsioemu as is, ( maybe add a delayed io thread like cdvdemu does ??? ) and remove unneeded code in mcdump/mcflash modules.


Best regards

Polo

[Polo35]

Hey.


Lot of things to say.


First of all MC emulation don't work ... for only one of my fifty games.


'Mcemu' game loader is ready.

IOP update procedure is now working well with double iop reset games.
Syscall functions stay hooked in game. ( ffgriever )


I compressed and modified hdd and pfs modules to make them smaller and compatible with replacement modules from games.
Only one partition can be mounted, and two opened files are allowed for two virtual memorycard.
They now use a cachesize value patched directly in each modules before loading them. ( ffgriever )

( Same thing is use for Usbhdfsd module. )

This allow to modify speed of read/write/seek file operations.
But this can cause 'out of memory' error in some memory hungry games if this value is too high.


I added a new configuration entry for setting this value.


I wrote a atadev9 module to replace atad and dev9 modules. It's directly based on cdvdemu atad/dev9 support.
It's of course compatible with games.


I revert HD Gui to non Xmodules use.
Sio2man/mcman/mcserv/padman modules are loaded at gui startup.
Xmodules are loaded only when mcdump or mcflash operations are done.


I now use vmcfs module to create a vmc file, instead of a mcsioemu modified version.
Thought i had to remove some bug in vmcfs format function.


I added an other new configuration entry which save individual vmc game settings when starting a game with 'mc emulation'.
Startup file path, cachesize, and vmc file path are stored in configuration.


There are now four possibilities when loading a game:

- 1 - Cross button start a game with last saved settings. If no settings where found HD Gui open a 'mc emulation' option menu to set cachesize and vmc file path for this game.
- 2 - Circle button open directly the 'mc emulation' option menu to modify options for this game.
- 3 - Square buton start the game with default settings. Those set in HD Gui option menu.
- 4 - Triangle exit menu.



Seem everythings work well.


But i really don't like my gui anymore.

So i'd like to make sme little modification before releasing it.


Maybe next week because my wife want me to be in charge of our child this weekend.


@Dlanor: I tried to load uLE and HD Gui with Pcsx2 but they hang at first main function loop.
Thought uLE 4.16 work fine.

I take a look to modification since this version but don't see what's wrong.
Do you have an idea on what can be the problem ?

I really want to make HD Gui working with Pcsx2 to make gui modification at work.


Anyway HD Gui V1.08 release date is near.

And with this new EE core i hope 'cdvd emulation' can soon see the light.


Best regards

Polo

[bootsector]

Originally Posted by Polo35

...And with this new EE core i hope 'cdvd emulation' can soon see the light...

Can't wait to see HDLoader's retirement!

Keep up the great work, Polo!

[nogardeht]

Yeah me too...
I hope it'll be really really great.
Thanks Polo35!!!

[dangwoot]

polo's the man ^_^
hooray samurai warriors on hdd here i come!

[amp2006]

Good work Polo keept it update ..

lol @ dangwoot

[zin0099]

question cuss i'm lost? hd project is it hd loader/hd advance but better?