forums.ps2dev.org

Exactly what is Cause: 0x10000014?

Is there a place that has a list of causes?

(If figure if I can find the line and the cause I can fix the issue.)

knew it was something simple. It still takes 2 tries to compile but it is compiling at least.

I've got what is probably a stupid issue but it is bugging me none the less. I can successfully compile this as a C file but not as C++ First let me start with the code: main.cpp: (compiles as main.c) #include <pspsdk.h> #include <pspkernel.h> #define VERS 0 #define REVS 55 PSP_MODULE_INFO&#40;&...

Going back to dcache_wbinv_all Wouldn't: 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 cycle...

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

So then I could set up my app which is running my own code to pause the code I'm running on intercepting a Standby Callback. Then on the next one resume it.

OSLib uses the ME when you call oslInitAudioME, but it doesn't use the MediaEngine.prx Chilly Willy wrote. So, I decided to look at the source for OSLib and was able to call this function from a user mode Eboot without MediaEngine.prx or any other prx's just what OSLib adds in to the Eboot. #include...

Well, I don't plan on sleeping the thread in the final version. This is just a basic test.

I have a quick question. I'm likely doing something stupid and not realizing it. Like this I can hit Home and exit fine: //************************************************************************************* // Sets up the CPU Frequency //************************************************************...

That's where it get's complicated as it not like just loading a png due to the different endian they hove to be loaded convert then pushed to the texel memory. Not sure where they are loaded, but they are converted in ImageConvert.cpp (Trying to find the issue with CI4 textures leaving spots right n...

Well you already know this texture compression code so you can likely implement it faster than I could. (Some games need it.) Also, I have howard0su's ME related code if you wan to play with it with the -n64 branch. Edit: Also with texture compression we can store the textures for future use longer ...

You are loading psp-gdb with your *.elf file as the command line switch correct? Example:(myapp is the name of your app) In psplink the command is: debug myapp.prx Then start psp-gdb like this: psp-gdb myapp.elf then in psp-gdb: target remote:10001 then: c Your app should now be running.... Not sure...

Well Daedalus is running out of Texel memory so this seems to be the way to go. Since we using complex texture formats. I guess the best method would be DXT5. By the way I've set this up as a Visual Studio Express solution for anyone that want to play with it. @J.F. Any chance you plan on doing more...

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...

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

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.

In DX64 the BSOD's are created by the exception handler, but I personally make sure I can recreate the error then I use psp-gdb to find the code which is causing the error. I've found both to be a very useful tools.

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?

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 w...

Thx, I can use this to test for leaks... by checking after each ROM is run and then storing the free amount in a global and then checking the difference. By looking at the difference it should give my the size lost which would tell me at least partially where the leak is. As well as how much I have ...

The current build includes the latest SVN and now is updated to include even more devpaks (38 in total):

Thought it already included the latest SVN.(Being it hasn't been updated in ages.) If I'm wrong about that, what's been changed recently?

Any place we can see the change log at?

Then you have endian issues like we do with DX64 and Strmnnrmn porting it to a big endian system and the fact we're emulating a big endian system(the N64) that has a few endianess quirks on a little endian system(PSP) that also has it's own quirks. In the end it all makes for a wonderful mess... Goo...

Here is the ME code we use for DX64 along with the Demo Code above in a nice neat VSExpress compatible package for those using MinPSPw. http://www.sendspace.com/file/wmmo8o BTW: The Demo and the MediaEnginePRX are just set up as different Projects in the Same solution with the only alterations being...

Thx, that's exactly what I needed. Also if you did post it before, thx for the repost. I was lazy and didn't read all 5 pages of this topic.

A few quick questions: 1. Is the current version of your code still "MediaEnginePRX-v1.0a"? 2. This is what we are using in DX64 correct? 3. Is there some short example code for using the MediaEngine? (I'm looking for something other than DX64 as I'm currently tearing it apart to be rebuil...

I know I'm running out of memory and suspect it is due to a leak. I post a new thread about it now that I have more information on the subject.

Need a PSP Debugging tool for memory leaks or least memory profiling to see if I have a leak (so I can know how much I'm actually using) . Any suggestions? As you know here I work on DaedalusX64. I'm running into bad_alloc crashes after loading several titles in a row and after playing 1 game for ex...

Hello, I'm just wondering what was causing the issue as I've seen this on other PSP homebrew, but then all I ever see is I fixed it and no explanation as to what happened.

Turns out it is in a combination of the combiner and the renderer.