Daedalus R10 release date and plan of action

A couple of weeks ago, homebrew developer StrmnNrmn released a new version of Daedalus, his Nintendo 64 (N64) emulator for the PSP. But we guess we don’t have to remind you about that as who would’ve missed that release? The homebrew developer even asked you what improvements you’d like to see in Daedalus R10.

StrmnNrmn just announced that he has finished collating all your responses and is now ready to work on the next version. He mentioned that most users commented that speed of this homebrew emulator should be improved as well as compatibility and save game support. The coder would like to assure everyone that all suggestions have been taken into consideration.

Lastly, here’s the plan of action StrmnNrmn wants to take for the new release: He promised that Daedalus R10 should be ready before March ends.

Daedalus R10 Plan of Action

• In many games, a lot of the time spent executing dynamically recompiled code is doing things which can potentially be emulated at a high level. For instance, over 5% of the time spent executing dynarec code in Mario64 is just converting matrices from floating point to fixed point format. Another 4-5% of the time is spent in a loop invalidating areas of the data cache (which is irrelevant in an emulator.)
• Some of the most expensive fragments are those which branch to themselves (i.e. those doing many loops). I can optimise for this to avoid loading and flushing cached registers on each iteration through the loop.
• I can implement a frameskip option (I had intended to implement this for R9, but forgot!)
• I can make use of the Media Engine (as Exophase suggested in conversation, as the ME can’t access VRAM, it might make more sense to execute Audio and Display Lists on the main CPU, and run the N64 CPU emulation on the PSP ME)
• There are certain situations where I fail to create fragments in the dynamic recompiler – for instance if the code being recompiled writes to a hardware register, this triggers an interrupt and causes fragment generation to be aborted. I should be able to deal with situations such as this more gracefully.

See the rest after the jump!

A couple of weeks ago, homebrew developer StrmnNrmn released a new version of Daedalus, his Nintendo 64 (N64) emulator for the PSP. But we guess we don’t have to remind you about that as who would’ve missed that release? The homebrew developer even asked you what improvements you’d like to see in Daedalus R10.

StrmnNrmn just announced that he has finished collating all your responses and is now ready to work on the next version. He mentioned that most users commented that speed of this homebrew emulator should be improved as well as compatibility and save game support. The coder would like to assure everyone that all suggestions have been taken into consideration.

Lastly, here’s the plan of action StrmnNrmn wants to take for the new release: He promised that Daedalus R10 should be ready before March ends.

Daedalus R10 Plan of Action

• In many games, a lot of the time spent executing dynamically recompiled code is doing things which can potentially be emulated at a high level. For instance, over 5% of the time spent executing dynarec code in Mario64 is just converting matrices from floating point to fixed point format. Another 4-5% of the time is spent in a loop invalidating areas of the data cache (which is irrelevant in an emulator.)
• Some of the most expensive fragments are those which branch to themselves (i.e. those doing many loops). I can optimise for this to avoid loading and flushing cached registers on each iteration through the loop.
• I can implement a frameskip option (I had intended to implement this for R9, but forgot!)
• I can make use of the Media Engine (as Exophase suggested in conversation, as the ME can’t access VRAM, it might make more sense to execute Audio and Display Lists on the main CPU, and run the N64 CPU emulation on the PSP ME)
• There are certain situations where I fail to create fragments in the dynamic recompiler – for instance if the code being recompiled writes to a hardware register, this triggers an interrupt and causes fragment generation to be aborted. I should be able to deal with situations such as this more gracefully.
• The fragment generator can do a lot more to improve register caching, and eliminating redundant 64-bit operations.
• There are many situations where N64 roms busy wait. I detect very simple occurrences of this, but not all of them. If I manually identify more complex examples I can have the fragment generator optimise them away.
• Some roms are causing the dynarec fragment cache to be repeatedly dumped and recreated (I think Banjo Kazooie is one example of this). Fixing this may just involve tweaking a couple of magic numbers.
• I currently optimise memory accesses under the assumption that most accesses are in the range 0x80000000 – 0x80800000, which is incorrect in the case of roms that make heavy use of virtual memory, or access RAM through the mirrored range at 0xa0000000. I can improve the trace recorder to collect information on which range a memory access fell in, and generate code to speculatively optimise for this.
• Now that the dynarec engine is producing much better code, the cost of display list processing is becoming more significant, and may finally be worth profiling and optimising.