StrmnNrmn Shares Dynamic Recompilation Progress
With only 24MB user memory plus 2MB vram to work with, the PSP must have been a difficult challenge for someone wishing to port an N64 emulator to the system. StrmnNrmn succeeded in doing it with his Daedalus N64 emulator, and he goes on to tell how he’s done this amazing feat.
According to StrmnNrmn, the memory problem was solved when he added the ROM streaming code, which reduced the memory usage for an 8MB ROM image down to around 2MB. As he went on to explain, “Larger roms only use fractionally more ram (i.e. a few 100KB or so), so I’ve managed to free up around another 6MB to use for textures, audio and most importantly the dynarec engine.”
However, constrained memory was not the only problem. There were also issues with speed. Running at 4-5fps max, the Daedalus developer admits that the emulator is ‘unusably slow’. With the dynamic recompiler, he assures that there will be improvement – although ‘it’s too early for [him] to tell how much of an improvement it’s going to bring on the PSP in the long run’.
In his blog, StrmnNrmn gave a progress report on the N64 emulator’s new dynarec engine: “I’m at the state where I’m successfully capturing ‘hot-traces’ from the rom as it runs. In order to work the bugs out of the system, I’m then simulating the execution of these traces to see whether everything is working as expected. It also lets me collect a few stats like how many instructions will end up being executed through the native fragment cache rather than being interpreted, and roughly how much memory is going to be consumed.”
And the results are looking good, he says. Although not running a native code yet, “the emulator runs almost as quickly with the ‘simulated’ dynarec enabled as it does running entirely through the interpreter.” Though it may seem like a regression rather than a progression, StrmnNrmn made it plain that this is a significant improvement: it indicates that the dynarec engine won’t take up much CPU load. This may actually mean that running on a native code, ‘the dynarec engine will only be using a fractional part of the CPU’.
There were other significant results. Daedalus developer wrote, “…you don’t actually need to recompile much code to get a sizable portion of the rom executing natively. In my tests with Mario, typically around 90% of the instructions executed are going through the fragment cache rather than the interpreter. Importantly this is with only around 64,000 instructions in 700-1000 fragments. I think this will mean I’ll be able to get away with a 1-2MB code buffer on the PSP.”
StrmnNrmn is currently “ironing out a couple of bugs with the fragment ‘simulator’” but has promised to work on generating native code once the problems have been fixed. Kudos, StrmnNrmn and more power to your Daedalus updates.
With only 24MB user memory plus 2MB vram to work with, the PSP must have been a difficult challenge for someone wishing to port an N64 emulator to the system. StrmnNrmn succeeded in doing it with his Daedalus N64 emulator, and he goes on to tell how he’s done this amazing feat.
According to StrmnNrmn, the memory problem was solved when he added the ROM streaming code, which reduced the memory usage for an 8MB ROM image down to around 2MB. As he went on to explain, “Larger roms only use fractionally more ram (i.e. a few 100KB or so), so I’ve managed to free up around another 6MB to use for textures, audio and most importantly the dynarec engine.”
However, constrained memory was not the only problem. There were also issues with speed. Running at 4-5fps max, the Daedalus developer admits that the emulator is ‘unusably slow’. With the dynamic recompiler, he assures that there will be improvement – although ‘it’s too early for [him] to tell how much of an improvement it’s going to bring on the PSP in the long run’.
In his blog, StrmnNrmn gave a progress report on the N64 emulator’s new dynarec engine: “I’m at the state where I’m successfully capturing ‘hot-traces’ from the rom as it runs. In order to work the bugs out of the system, I’m then simulating the execution of these traces to see whether everything is working as expected. It also lets me collect a few stats like how many instructions will end up being executed through the native fragment cache rather than being interpreted, and roughly how much memory is going to be consumed.”
And the results are looking good, he says. Although not running a native code yet, “the emulator runs almost as quickly with the ‘simulated’ dynarec enabled as it does running entirely through the interpreter.” Though it may seem like a regression rather than a progression, StrmnNrmn made it plain that this is a significant improvement: it indicates that the dynarec engine won’t take up much CPU load. This may actually mean that running on a native code, ‘the dynarec engine will only be using a fractional part of the CPU’.
There were other significant results. Daedalus developer wrote, “…you don’t actually need to recompile much code to get a sizable portion of the rom executing natively. In my tests with Mario, typically around 90% of the instructions executed are going through the fragment cache rather than the interpreter. Importantly this is with only around 64,000 instructions in 700-1000 fragments. I think this will mean I’ll be able to get away with a 1-2MB code buffer on the PSP.”
StrmnNrmn is currently “ironing out a couple of bugs with the fragment ‘simulator’” but has promised to work on generating native code once the problems have been fixed. Kudos, StrmnNrmn and more power to your Daedalus updates.