Daedalus R12 preview! Super Smash Bros., GoldenEye, and Mario 64 progress

We’re at the wake of N64 emulator for PSP”>Daedalus R11’s release and now we’re already getting updates on StrmnNrmn‘s progress on R12! His Nintendo64 emulator for the PSP is getting quite an exposure under a PSPUpdates limelight, and we’re sure most of you guys are curious as to how emulation development is going for him.

Especially if those updates concern some of the N64’s best games ever, we can’t just pass this up. Besides, to paraphrase what some of the comments say: “what’s an N64 emulatorz if you can’t run teh ultimatez nintendo sixty phoar gamez perfectly?” Pardon the l337 speak, but they do have a point. GoldenEye and Super Smash Bros. are what a lot of us have been waiting for (to run perfectly) on the PSP. StrmnNrmn updated his blog with three new posts, each one tackling a different thing.

Let’s start with the good news: Progress on R12 and working on Super Smash Bros. He’s already been able to fix four or five different pressure points which caused some considerable bugs in running SSB on the emulator. The screens above (R11 on the left, R12 on the right) show how the graphical textures vastly improved because of these tweaks. And yes, that’s R12 you’re seeing right before you! *gawks at screens*

Moving on, he’s also posted updates on why GoldenEye and Mario 64 doesn’t seem to work properly in the existing R11. The problem of GoldenEye seems to hinge on the fact that the game “executes code from virtual memory.” That poses a problem on PSP emulation because it’s slow and that “the rom (all 12 MiB for GoldenEye) must be permanently loaded into memory, and there just isn’t enough memory left to do this anymore.” His solutions (with the first one being the easiest, the third being the most stable):

• Permenantly disable dynarec for Goldeneye, and reuse the dynarec buffers (6MiB) the expansion pak (unneeded anyway, 4MiB) and anything else I can scavenge, to fit the rom in a contiguous block in memory.
• Investigate a way of getting the memory-mapping hack to work with rom caching.
• Re-examine how I handle TLB miss exceptions for instruction fetches, and implement them correctly.

On to Mario 64 though, it’s pretty simple. While some people have pointed out that he should fix Mario 64 on R11 (because apparently, it got busted due to some tiny change in its alpha threshold) and release some form of R11b, the HUD issue shouldn’t be that significant. To quote his own words:

Mario is just as playable in R10. I’d rather release R12 a little early to fix this than mess around releasing an R11b version or whatnot. We’ll see how things go with the SSB work.

Glad to see this guy taking development seriously. If he does intend to “release R12 a little early,” then by god!, we’re bound to be on his heels for it!

We’re at the wake of N64 emulator for PSP”>Daedalus R11’s release and now we’re already getting updates on StrmnNrmn‘s progress on R12! His Nintendo64 emulator for the PSP is getting quite an exposure under a PSPUpdates limelight, and we’re sure most of you guys are curious as to how emulation development is going for him.

Especially if those updates concern some of the N64’s best games ever, we can’t just pass this up. Besides, to paraphrase what some of the comments say: “what’s an N64 emulatorz if you can’t run teh ultimatez nintendo sixty phoar gamez perfectly?” Pardon the l337 speak, but they do have a point. GoldenEye and Super Smash Bros. are what a lot of us have been waiting for (to run perfectly) on the PSP. StrmnNrmn updated his blog with three new posts, each one tackling a different thing.

Let’s start with the good news: Progress on R12 and working on Super Smash Bros. He’s already been able to fix four or five different pressure points which caused some considerable bugs in running SSB on the emulator. The screens above (R11 on the left, R12 on the right) show how the graphical textures vastly improved because of these tweaks. And yes, that’s R12 you’re seeing right before you! *gawks at screens*

Moving on, he’s also posted updates on why GoldenEye and Mario 64 doesn’t seem to work properly in the existing R11. The problem of GoldenEye seems to hinge on the fact that the game “executes code from virtual memory.” That poses a problem on PSP emulation because it’s slow and that “the rom (all 12 MiB for GoldenEye) must be permanently loaded into memory, and there just isn’t enough memory left to do this anymore.” His solutions (with the first one being the easiest, the third being the most stable):

• Permenantly disable dynarec for Goldeneye, and reuse the dynarec buffers (6MiB) the expansion pak (unneeded anyway, 4MiB) and anything else I can scavenge, to fit the rom in a contiguous block in memory.
• Investigate a way of getting the memory-mapping hack to work with rom caching.
• Re-examine how I handle TLB miss exceptions for instruction fetches, and implement them correctly.

On to Mario 64 though, it’s pretty simple. While some people have pointed out that he should fix Mario 64 on R11 (because apparently, it got busted due to some tiny change in its alpha threshold) and release some form of R11b, the HUD issue shouldn’t be that significant. To quote his own words:

Mario is just as playable in R10. I’d rather release R12 a little early to fix this than mess around releasing an R11b version or whatnot. We’ll see how things go with the SSB work.

Glad to see this guy taking development seriously. If he does intend to “release R12 a little early,” then by god!, we’re bound to be on his heels for it!