Daedalus News - Media Engine

[wraggster]

StrmnNrmn has posted another update about his work on his N64 Emu for PSP:

Earlier I discussed my plans for getting Daedalus's audio processing working on the PSP's Media Engine.

As I mentioned in that post, it's not just a case of changing some compiler setting to get this working. I've not spent much time investigating the ME so I may be wrong on a few of these points, but here are the current issues that I think need solving.

Firstly in order to access the ME I need to be running in kernel mode. This requires either running Daedalus in kernel mode, or (preferably) creating a kernel mode PRX that encapsulates the required functionality. I think kernel mode rules out anyone running with v1.50 firmware (hence my earlier post - please respond to the poll if you haven't already done so!) Maybe one of the more savvy psp developers out there can correct me on this? If no-one is using v1.50 any more then maybe it isn't even an issue.

Another problem is that although the ME is essentially the same processor as the main core, it has a different memory map. This means that things like the VRAM is invisible to the ME, so any code ported to run on the ME would have to be written to operate on main memory. This isn't an issue for Daedalus's audio list processing, but it would cause problems if I wanted to move display list processing to the ME too.

Touching on the memory map issue, another problem is the lack of cache coherency between the two cores. I need to be careful when accessing the same areas of memory with both cores to correctly flush and invalidate the data caches. Ideally any shared memory should be kept to a minimum, but this is easier said than done when porting existing code, rather than writing new code.

For a similar reason, any code which needs to run on the ME should avoid making any calls to the runtime library, including doing any system memory allocation. System calls are also ruled out. This is fairly easy to guarantee if you're writing new code, but again, it's a lot harder if you're porting existing code.

I think that's most of the issues from the hardware side. There are also a number of issues to be solved to do with the way that Daedalus handles audio and display list processing.

On the N64, the audio and display lists are processed asynchronously by the RSP coprocessor. In Daedalus, I can identify when these tasks are queued up for the RSP, intercept them, and process them synchronously (using high-level emulation rather than simulating the RSP execution directly).

The key thing here is that as far as the emulated N64 is concerned, audio and display list processing currently happens instantaneously. As soon as it kicks off the RSP it gets a interrupt to inform it that processing has completed. The whole process is very deterministic and I'm worried that by processing these display lists asynchronously on the ME that a number of intermittent and hard-to-debug issues will crop up. On the other hand, processing these tasks asynchronously is much closer to the behaviour of a real N64, which may fix some timing-related issues. It will also allow Daedalus to exploit the inherent parallelism that N64 roms were designed to take advantage of.

My current plan for ME audio support in R14 is:





Create a kernel mode PRX and get Daedalus successfully loading and invoking functions (under all supported firmwares). I've just about done this.

Add the code to support initialising and running code on the ME to the PRX. Test invoking user mode functions from the main EBOOT.PBP. I'll probably be using J.F.'s great sample code as a reference for this. Thanks J.F.!

Rewrite the audio list processing code so that it can be invoked synchronously or asynchronously as required (via some kind of configuration option). When running asynchronously it can just be run from a separate high-priority thread to start with. I can use this to test for various synchronisation issues without going through the pain of trying to do this on the ME first.

Audit the audio list processing code to minimise any memory accesses or ensure that they are correctly synchronised with the main core/thread. Any crt or system calls need to be eliminated or abstracted away (e.g. printfs NOP when compiled to run on the ME).

Invoke audio list processing code from the ME.

Cross fingers.



So, that's the plan; I'll keep you updated on my progress. If anyone has any experience doing this kind of thing on the ME it would be great to hear your thoughts.

-StrmnNrmn

[Baboon]

Now this is great news!

If the Media Engine is used on Daedalus then this emulator will really start to take off. To eventually have decent sound will be fantastic!

[Buddy4point0]

i cant wait! being able to play n64 with sound will be great! i can see a very good future for this emulator

[paintball1119]

I think kernel mode rules out anyone running with v1.50 firmware

1.5 can run kernal mode just fine, snes 9x with the ME runs on 1.5 so i think you don't need to make the prx

[darkness angel 777]

finally maybe we'll get good sound.I was wondering when he would get to the sound.

[xg917]

the only thing that media engine will do is help sound not affect the framerate?

no offence but i kinda think this is lame because it only brings down the framerate by a few frames per second and from what ive heard, the sound quality wouldnt make a difference if its being used on the ME or main CPU. i kinda think its a waste of time. id much rather find a way to increase speed for the emulator so that the game itself runs fast, if a game reaches full speed then sound will not be choppy the way we hear it at the moment.

big ups to strmnnrmn though

[Axelius]

Ehm, no offence, but in most games the sound enabled/disabled makes the difference between playable and not playable framerate. I mean some games run quite good with sound disabled, but get rather slow with sound enabled.

[Strongbadunit2]

The quality won't be any different but the fps with the sound will be faster...

The faster he moves it to the ME the better because as the code grows it will become harder to switch it to the ME because there will be more variables that the ME will effect.

I'm no expert on the Media Engine but it does make sense to me that getting the hardest thing out of the way as soon as possible is not only beneficial to stopping people from getting pissy but also is a big step for setting up R15..

R14 will most likely be a release to stop ranting about the ME and also to do some stuff to make it look nicer such as thumbnails & icons..(other little bug fixes)

R15 on the other hand will most likely be purely about speed!!:thumbup: Because thats just about all there is left to do after R14

[Safari Al]

Yes! finally sound is given a chance :thumbup:

[Sterist]

1.5 can run kernal mode just fine, snes 9x with the ME runs on 1.5 so i think you don't need to make the prx

umm....lets leave that for the people who know what they're talkin about
==============

now, could someone plz clarify exactly what kind of performance boost this will yield? from how i see it, this will relieve the CPU of audio, but that isn't necesarily a speed boost is it? (while audio is 'on' compared to 'off' from R13)