I wanted to use the ME to do IDCT, but got an 8002013C err

[realjoeeye1]

Sys:401M33
I tried to use the ME, but got the 8002013C error code. I checked the .prx file, which used functions in sysreg.prx, but there is no such a file in my flash0, and maybe it need the kernel mode.

How can I use the ME on PSP with 4.01M33? Please help.

THX.

[J.F.]

Do a search on ME for old threads. I posted both a prx and an example of using it.

[realjoeeye1]

I saw your posts,J.F. but the download link of your sample code may be broken or I'm banned to download it.
I read many posts, and made a prx to use the kernel mode. But the functions in the prx don't work. No error code received but the functions just not work like they are not be called.

[J.F.]

http://www.mediafire.com/download.php?ahbmqxooqwq

Try that. It works fine on my slim in 4.01 M33-2. It has the clock setting code disabled. You can't change the cpu clock while the ME is running. The code there shows how to init the ME, start running code, set flags, and cleanup.

[realjoeeye1]

Many thanks!!

[realjoeeye1]

Is the "|0x40000000" opration means the ME has another address to access the memory? Are the "|0x40000000" address on ME and the original address on SC pointing to a same place?

[hlide]

nope it means we want to read/write into uncached segment as both processors cannot share the contents of their respective caches. The "|0x40000000" operation gives the same result in both processors : bypass the cache update, don't read/write in the cache even if there may be a hit but directly in main ram, vram or scratchpad.

[J.F.]

nope it means we want to read/write into uncached segment as both processors cannot share the contents of their respective caches. The "|0x40000000" operation gives the same result in both processors : bypass the cache update, don't read/write in the cache even if there may be a hit but directly in main ram, vram or scratchpad.

Yeah, just remember that the ME cannot access vram or scratchpad. It DOES have it's own ram it can access (2MB at addr 0). Given the Slim PSP doubled the vram, I wonder if the ME edram was doubled as well... one of these days, one of us should do a mem test on the ME edram to see how big it is on the Slim.

Anywho, you'll notice my example sets the framebuffer in system memory so that the ME can do the color cycles. That's because the ME can't access vram, so trying to do color cycle in vram from the ME would be useless.

[hlide]

yeak, just forgot vram and scratchpad is specific to main processor :).

[realjoeeye1]

I've not used ME to access the VRAM. When load my prx, it received an error code:800200d9, like there was not enough memory to allocate. I used PSP_HEAP_SIZE_KB(10*1024) both in prx and eboot.pbp, it doesn't work.

[realjoeeye1]

I've tried J.F.'s sample code, the EBOOT.pbp already compiled did not work, it received an 80020001 error code loading the .prx. But when I recompiled it, it works well! Maybe I have to rewrite my codes based on J.F.'s MediaEngine.prx.

[realjoeeye1]

I'm not sure what the sigmask and sigset exactly mean, can J.F. give a simple explanation?

[J.F.]

I'm not sure what the sigmask and sigset exactly mean, can J.F. give a simple explanation?

It's an idea from the Amiga. Each bit is a signal. You can alter any number of bits by setting the bit number of the flag to be altered in sigmask. The value for the flag is determined by setting the same bit number in the sigset. So if you wanted to set flags 1 and 4, and clear flags 0, 2, and 3, you'd use a sigmask of 0x0000001f and sigset of 0x00000012.

What I really want to do here sometime before the year is over is rewrite the ME library so that the ME is running something akin to exec.library.

[J.F.]

I've tried J.F.'s sample code, the EBOOT.pbp already compiled did not work, it received an 80020001 error code loading the .prx. But when I recompiled it, it works well! Maybe I have to rewrite my codes based on J.F.'s MediaEngine.prx.

You probably forgot the mediaengine prx when you copied the EBOOT. If you made a directory in GAME4XX and copied the EBOOT and mediaengine prx lib, it should work. It certainly does on my Slim.

[realjoeeye1]

Yes, I'm sure I've put the mediaengine.prx to the same folder with the EBOOT.PBP. It didn't work on the old EBOOT.PBP, and work fine on the new EBOOT.PBP that I compiled.

Thanks!

[realjoeeye1]

I'm not sure what the sigmask and sigset exactly mean, can J.F. give a simple explanation?

It's an idea from the Amiga. Each bit is a signal. You can alter any number of bits by setting the bit number of the flag to be altered in sigmask. The value for the flag is determined by setting the same bit number in the sigset. So if you wanted to set flags 1 and 4, and clear flags 0, 2, and 3, you'd use a sigmask of 0x0000001f and sigset of 0x00000012.

What I really want to do here sometime before the year is over is rewrite the ME library so that the ME is running something akin to exec.library.

I know it, I just thought that you had already defined the functions of these flags, now I realize those are for me or someone who use the struct to define our own meanings.

[realjoeeye1]

nope it means we want to read/write into uncached segment as both processors cannot share the contents of their respective caches. The "|0x40000000" operation gives the same result in both processors : bypass the cache update, don't read/write in the cache even if there may be a hit but directly in main ram, vram or scratchpad.

Are the adresses with and without "|0x40000000" point to the same physical memory block? like:

int *a,*b;
a=0x0000 FFFF;
b=0x4000 FFFF;
*a=100 get a same result as *b=100? just *b=100 does not use cache of the core?

[J.F.]

I just thought that you had already defined the functions of these flags, now I realize those are for me or someone who use the struct to define our own meanings.

Yes, and you can also extend the structure if you want, putting your own stuff in it.

@realjoeeye1 - They are the same address, but you may or may not get the same values depending on whether or not you have flushed the cache, and do so after writing through the cached pointer. For example, if you write through the cached pointer, the data is in the cache, not the memory, so reading through the uncached pointer will return the PREVIOUS data, not the data you just wrote.

[realjoeeye1]

I just thought that you had already defined the functions of these flags, now I realize those are for me or someone who use the struct to define our own meanings.

Yes, and you can also extend the structure if you want, putting your own stuff in it.

@realjoeeye1 - They are the same address, but you may or may not get the same values depending on whether or not you have flushed the cache, and do so after writing through the cached pointer. For example, if you write through the cached pointer, the data is in the cache, not the memory, so reading through the uncached pointer will return the PREVIOUS data, not the data you just wrote.

Now I clearly understand that!

Thanks!

[J.F.]

No problem. With modern CPUs doing bus snooping, many people haven't learned those old-school cache coherency lessons. :)

[realjoeeye1]

I used the ME to IDCT a 8X8 short block, but it doesn't work correctly.

Codes:


static int idct_me(int start_block)
{
idct_start((short*)(int(&dct_recon[start_block][0][0])|0x40000000));
return 0;
}
static void idct(int start_block)
{
int err;
err=BeginME(mei, (int)idct_me, start_block, 0, 0, 0, 0);
/* if (err < 0)
printf(" failed! Error calling BeginME. %d\n",err);
else
printf("BeginMe OK. %d\n",err);
sceKernelDelayThread(300000); */
}

idct_start() is a function to do the IDCT, it can do that correctly on th SC. But when I used ME as above code, I got an incorrect result, and sometimes PSP crashed.

[J.F.]

Using caches:
SC: store data to input array, then flush dcache
ME: invalidate input array (not flush!), then process data, then flush dcache for output array
SC: invalidate dcache for output array (not flush!), then read results

When you use BeginME(), remember that the data won't be valid until the ME is done. There's a function to check if the ME is done, and one to wait for the ME to finish.

If you don't want to mess with the caches, always use the uncached pointer EVERYWHERE for EVERYTHING. Also, flush/invalidate the dcache for the arrays BEFORE messing with them to make sure that you're using the contents of memory instead of the cache.