| View previous topic :: View next topic |
| Author |
Message |
Kreationz
Joined: 18 May 2008
Posts: 53
|
 Posted: Sat Jul 04, 2009 5:46 pm Post subject: |
 |
|
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? |
|
| Back to top |
|
 |
Gaby_64
Joined: 19 Dec 2008
Posts: 33
|
| Posted: Sun Jul 05, 2009 10:08 am Post subject: |
|
|
whats the diffrence from the 371 syscals and the normal ones?
_________________
<a><img></a> |
|
| Back to top |
|
|
J.F.
Joined: 22 Feb 2004
Posts: 2906
|
| Posted: Sun Jul 05, 2009 2:58 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Kreationz
Joined: 18 May 2008
Posts: 53
|
| Posted: Tue Jul 07, 2009 9:21 am Post subject: |
|
|
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? |
|
| Back to top |
|
|
J.F.
Joined: 22 Feb 2004
Posts: 2906
|
| Posted: Tue Jul 07, 2009 11:21 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Kreationz
Joined: 18 May 2008
Posts: 53
|
| Posted: Wed Jul 08, 2009 5:03 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Torch
Joined: 28 May 2008
Posts: 842
|
| Posted: Thu Jul 09, 2009 12:26 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
J.F.
Joined: 22 Feb 2004
Posts: 2906
|
| Posted: Thu Jul 09, 2009 12:36 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Bluddy
Joined: 22 Apr 2007
Posts: 17
|
| Posted: Sun Aug 02, 2009 6:23 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
Kreationz
Joined: 18 May 2008
Posts: 53
|
| Posted: Sun Aug 23, 2009 11:19 am Post subject: Standby |
|
|
| Also, can standby even be induced from software when not using the ME? |
|
| Back to top |
|
|
Art
Joined: 09 Nov 2005
Posts: 647
|
| Posted: Sun Aug 23, 2009 9:04 pm Post subject: Re: Standby |
|
|
| 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. |
|
| Back to top |
|
|
Kreationz
Joined: 18 May 2008
Posts: 53
|
| Posted: Wed Sep 30, 2009 5:09 am Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
J.F.
Joined: 22 Feb 2004
Posts: 2906
|
| Posted: Thu Oct 01, 2009 3:02 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Kreationz
Joined: 18 May 2008
Posts: 53
|
| Posted: Fri Dec 25, 2009 12:57 pm Post subject: |
|
|
| Sorry to resurrect this topic again, but what about unloading the prx? or does it just stop any new ME functions from being called? |
|
| Back to top |
|
|
Kreationz
Joined: 18 May 2008
Posts: 53
|
| Posted: Sun Jan 03, 2010 6:19 am Post subject: |
|
|
Going back to dcache_wbinv_all
Wouldn't:
| Code: | void dcache_wbinv_all()
{
int i;
for(i = 0; i < 8192; i += 64)
{
__builtin_allegrex_cache(0x14, i);
__builtin_allegrex_cache(0x14, i);
}
}
|
Use a few less cycles than:
| Code: |
void dcache_wbinv_all()
{
int i;
for(i = 0; i < 16384; i += 64)
{
__builtin_allegrex_cache(0x14, i);
}
} |
So the prefered function would be the first one or would the differences be optimized away by the compiler? |
|
| Back to top |
|
|
hlide
Joined: 10 Sep 2006
Posts: 750
|
| Posted: Sun Jan 03, 2010 8:07 am Post subject: |
|
|
| Kreationz wrote: | Going back to dcache_wbinv_all
Wouldn't:
| Code: | void dcache_wbinv_all()
{
int i;
for(i = 0; i < 8192; i += 64)
{
__builtin_allegrex_cache(0x14, i);
__builtin_allegrex_cache(0x14, i);
}
}
|
Use a few less cycles than:
| Code: |
void dcache_wbinv_all()
{
int i;
for(i = 0; i < 16384; i += 64)
{
__builtin_allegrex_cache(0x14, i);
}
} |
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. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
