Media Engine?

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Kreationz
Posts: 52
Joined: Sun May 18, 2008 11:01 am

Post by 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?
User avatar
Gaby_64
Posts: 33
Joined: Fri Dec 19, 2008 4:04 am

Post by Gaby_64 »

whats the diffrence from the 371 syscals and the normal ones?
<a><img></a>
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

Gaby_64 wrote: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
Posts: 52
Joined: Sun May 18, 2008 11:01 am

Post by 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.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

Kreationz wrote: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
Posts: 52
Joined: Sun May 18, 2008 11:01 am

Post by 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.
User avatar
Torch
Posts: 825
Joined: Wed May 28, 2008 2:50 am

Post by Torch »

Gaby_64 wrote: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.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

Torch wrote:
Gaby_64 wrote: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
Posts: 11
Joined: Sun Apr 22, 2007 9:37 pm

Post by 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
Posts: 52
Joined: Sun May 18, 2008 11:01 am

Standby

Post by Kreationz »

Also, can standby even be induced from software when not using the ME?
Art
Posts: 642
Joined: Wed Nov 09, 2005 8:01 am

Re: Standby

Post by Art »

Kreationz wrote:Also, can standby even be induced from software when not using the ME?
Yes, Suspend and Standby are in the power lib.
If not actually, then potentially.
Kreationz
Posts: 52
Joined: Sun May 18, 2008 11:01 am

Post by 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.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by 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
Posts: 52
Joined: Sun May 18, 2008 11:01 am

Post by 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
Posts: 52
Joined: Sun May 18, 2008 11:01 am

Post by Kreationz »

Going back to dcache_wbinv_all
Wouldn't:

Code: Select all

void dcache_wbinv_all&#40;&#41;
&#123;
   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&#40;&#41;
&#123;
   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
Posts: 739
Joined: Sun Sep 10, 2006 2:31 am

Post by hlide »

Kreationz wrote:Going back to dcache_wbinv_all
Wouldn't:

Code: Select all

void dcache_wbinv_all&#40;&#41;
&#123;
   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&#40;&#41;
&#123;
   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.
Post Reply