Media Engine?

[Kreationz]

Well for one thing you can quiet two of the warnings by changing:

mei->func = func;
to
mei->func = (int (*)(int))func;

In both BeginME and CallME

The only other warnings are due to imports creating implicit functions for the 371 syscalls.

Also has anyone had any luck with standby mode when dealing with the ME?

[Gaby_64]

whats the diffrence from the 371 syscals and the normal ones?

[J.F.]

whats the diffrence from the 371 syscals and the normal ones?

Just the NIDs. The MediaEngine PRX was written when 3.71 was the latest out, and it didn't have the NID resolver. So it included special code to run on 3.5x and earlier, and on 3.71. The NID resolver lets it run on all the newer firmwares.

[Kreationz]

So is there a way to use the NID resolver to eliminate the need for the 371 Syscalls? Are they even needed anymore? I'm just doing some code clean-up on DX64. I'm preparing to finish Howard0su's CPU on ME work.

Any recent developments in working with the ME I should be aware of?

[J.F.]

So is there a way to use the NID resolver to eliminate the need for the 371 Syscalls? Are they even needed anymore? I'm just doing some code clean-up on DX64. I'm preparing to finish Howard0su's CPU on ME work.

Any recent developments in working with the ME I should be aware of?

The 3.71 M33 CFW doesn't have a NID resolver, so if you drop the 3.71 code, you lose 3.71 compatibility. Period. Nothing to be done except bug D_A for an update to 3.71 M33 that supports the NID resolver. ;)

I've been a bit lazy on the PSP front, working on the Genesis/CD/32X recently. So no, there hasn't been any update on the ME front lately.

[Kreationz]

Well, I'll leave it in for compatibility sake. I'll just finish fixing the warning by properly declaring the functions. Working on Dev mode warnings at the moment.

[Torch]

whats the diffrence from the 371 syscals and the normal ones?

Don't the syscalls' NIDs stay the same seeing that they're meant to be used by games/user mode??

Only the direct kernel exports NIDs are randomized.

[J.F.]

whats the diffrence from the 371 syscals and the normal ones?

Don't the syscalls' NIDs stay the same seeing that they're meant to be used by games/user mode??

Only the direct kernel exports NIDs are randomized.

Yes, but the ME calls are kernel level. That's why the ME lib is kernel level.

[Bluddy]

Sorry for bumping this, but I'm really interested to know if anyone has any idea why standby won't work with ME access. This is probably the one major barrier preventing ME code from being used in more homebrew (the other is kernel mode, yes). Since the ME looks like just another MIPS core, can't we just put it in the same state that the main CPU goes into? Does anybody know what that is ie. what register values are placed where, when the CPU goes into standby? Can we try duplicate it on the ME and see if it helps?

Sorry if I'm asking beginner type questions.

[Kreationz]

Also, can standby even be induced from software when not using the ME?

[Art]

Also, can standby even be induced from software when not using the ME?

Yes, Suspend and Standby are in the power lib.

[Kreationz]

Ok, then my next question is can the ME be properly shut down so that we can induce standby afterward? Or possibly have it shut down/resume we leave the section of code that needs it? (In this case shutting it down while in the emulator's menus) So that standby/resume can work from there? or changes in CPU speed can work from there?

[J.F.]

I tried a variety of things to shut down the ME, but nothing ever worked. Once the ME was activated, nothing short of exiting the app would shut it done. This area needs more disassembly of the ME libs.

[Kreationz]

Sorry to resurrect this topic again, but what about unloading the prx? or does it just stop any new ME functions from being called?

[Kreationz]

Going back to dcache_wbinv_all
Wouldn't:

Code: Select all

void dcache_wbinv_all()
{
   int i;
   for&#40;i = 0; i < 8192; i += 64&#41;
   &#123;
      __builtin_allegrex_cache&#40;0x14, i&#41;;
      __builtin_allegrex_cache&#40;0x14, i&#41;;
   &#125;
&#125;

Use a few less cycles than:

Code: Select all

void dcache_wbinv_all()
{
   int i;
   for&#40;i = 0; i < 16384; i += 64&#41;
   &#123;
      __builtin_allegrex_cache&#40;0x14, i&#41;;
   &#125;
&#125;

So the prefered function would be the first one or would the differences be optimized away by the compiler?

[hlide]

Going back to dcache_wbinv_all
Wouldn't:

Code: Select all

void dcache_wbinv_all()
{
   int i;
   for&#40;i = 0; i < 8192; i += 64&#41;
   &#123;
      __builtin_allegrex_cache&#40;0x14, i&#41;;
      __builtin_allegrex_cache&#40;0x14, i&#41;;
   &#125;
&#125;

Use a few less cycles than:

Code: Select all

void dcache_wbinv_all()
{
   int i;
   for&#40;i = 0; i < 16384; i += 64&#41;
   &#123;
      __builtin_allegrex_cache&#40;0x14, i&#41;;
   &#125;
&#125;

So the prefered function would be the first one or would the differences be optimized away by the compiler?

in term of memory access ORDER, the first is not the same as the second and since you're using a builtin function the compiler won't try to optimize away the second builtin function.

the second line won't be executed until the first finishes and they take a lot of cycle compared with those of loop because they can be executed (probably) in parallel to the builtin function.