Announcement: Cycle-accurate N64 development underway.

[MarathonMan]

I just had a thought. Since this doesn't have a GUI let alone an actual true full-on emulation core yet, would it not be optimal to leverage RetroArch so that development can focus mainly on actual cycle accuracy emulation?

Not interested in flumbing around with third-party libraries, sorry.

That being said, everything I write is in ANSI C (+standard integer types; you can either use C99/C11 or typedef them in the common header -- already did the latter for MSVC). It literally compiles on _anything_ and is written very cleanly, so anyone with familiarity with the framework shouldn't have any difficulty porting it.

 

[weinerschnitzel]

Not interested in flumbing around with third-party libraries, sorry.

That being said, everything I write is in ANSI C (+standard integer types; you can either use C99/C11 or typedef them in the common header -- already did the latter for MSVC). It literally compiles on _anything_ and is written very cleanly, so anyone with familiarity with the framework shouldn't have any difficulty porting it.

<3 I patiently await your finished project.

I'm not so sure if the current platforms RetroArch boasts will be able to handle cycle accurate low level N64 emulation. But it could eliminate the dependency for a "3DArch" that would heavily utilize DirectX or OpenGL for hardware accelerated graphics... if we're talking libretro n64 emu.

 

[Nintendo Maniac]

RetroArch currently can run the bsnes accuracy profile, and this N64 emulator project will use software rasterization, so surely it'd be possible, no?

 

[Fanatic 64]

I see you really want this emulator to became a RetroArch module...

 

[Nintendo Maniac]

I just don't want it locked to PCs and/or the x86 architecture is all, and RetroArch provides an easy way to get it on other platforms. And since this is to be cycle-accurate, I wouldn't expect another emulator to do a better job at accuracy any time soon, so planning for "future proofing" may be wise.

 

[Fanatic 64]

I just don't want it locked to PCs and/or the x86 architecture is all, and RetroArch provides an easy way to get it on other platforms. And since this is to be cycle-accurate, I wouldn't expect another emulator to do a better job at accuracy any time soon, so planning for "future proofing" may be wise.

MarathonMan already said: "everything I write is in ANSI C (+standard integer types; you can either use C99/C11 or typedef them in the common header -- already did the latter for MSVC). It literally compiles on _anything_ and is written very cleanly, so anyone with familiarity with the framework shouldn't have any difficulty porting it", which means it isn't locked to pretty much anything.

 

[Nintendo Maniac]

But I'm afraid that people won't port it to things like future consoles because they'll be too concerned with performance, regardless of whether an older emulator can even RUN the game. Heck, even WITH RetroArch nobody seems concerned with porting bsnes to anything other than PC, most likely because Snes9x is seen as good enough.

 

[Fanatic 64]

But I'm afraid that people won't port it to things like future consoles because they'll be too concerned with performance, regardless of whether an older emulator can even RUN the game. Heck, even WITH RetroArch nobody seems concerned with porting bsnes to anything other than PC, most likely because Snes9x is seen as good enough.

Personally I've always seen emulators on other videogame consoles as something rather trivial. And RetroArch is pretty much just a collection of emulators under the same program, isn't like it does anything outstanding for portability or much less performance.

 

[Nintendo Maniac]

It was my impression that RetroArch lib files, if designed correctly, can automatically work on any platform that RetroArch is ported to.

 

[Fanatic 64]

It was my impression that RetroArch lib files, if designed correctly, can automatically work on any platform that RetroArch is ported to.

This emulator will be able to work on any platform, even ones not supported by RetroArch, with minimal to no effort, just by compiling and running it.

 

[Nintendo Maniac]

This emulator will be able to work on any platform, even ones not supported by RetroArch, with minimal to no effort, just by compiling and running it.

It's not minimal to no effort if you have to code a UI...hence RetroArch.

 

[Fanatic 64]

It's not minimal to no effort if you have to code a UI...hence RetroArch.

RetroArch has no UI, just a frontend that has to be ported separately.

And if you want SO badly this emulator to became a RetroArch module, then you'll have to port it yourself, since MarathonMan already stated his not making it such.

 

[Nintendo Maniac]

RetroArch has no UI, just a frontend that has to be ported separately.

There however, is pre-existing interest in creating a UI for ports of the RetroArch frontend specifically because it brings multiple quality emulators with it.

And if you want SO badly this emulator to became a RetroArch module, then you'll have to port it yourself, since MarathonMan already stated his not making it such.

...you seem to be misinterpreting my posts as wishing/begging/pleading/etc. for this to become a RetroArch module.

After MarathonMan stated he wasn't going to, all subsequent posts were purely about the benefits of such an approach, not why I feel this project should actually actively pursue such a thing. If this is not how I came off in my posts, then I apologize - text is poor at conveying the correct feeling and emotion behind one's ideas.

 

[Fanatic 64]

...you seem to be misinterpreting my posts as wishing/begging/pleading/etc. for this to become a RetroArch module.

After MarathonMan stated he wasn't going to, all subsequent posts were purely about the benefits of such an approach, not why I feel this project should actually actively pursue such a thing.

...then we are going off-topic. We should keep this discussion somewhere else (trough personally I think I'm done with it, all I want to discuss is about this project, not something unrelated to it).

 

[Nintendo Maniac]

...then we are going off-topic. We should keep this discussion somewhere else (trough personally I think I'm done with it, all I want to discuss is about this project, not something unrelated to it).

Same here, I didn't really want to keep discussing this and I was concerned about off-topic-ness as well, but the conversation kept going so...

 

[MarathonMan]

It was my impression that RetroArch lib files, if designed correctly, can automatically work on any platform that RetroArch is ported to.

They'd have to be recompiled for the target architecture, but assuming the interface is the same, then yes, they're portable.

 

[MarathonMan]

Found out that I wasn't stalling in a couple of conditions when I should have, did a full analysis of the RSP, and ... rewrote librsp. :yucky:

I didn't want to, but I dug myself into a hole. On the upside, I've more or less finished the rewrite and got a major performance boost. I pushed the instruction decoding out of the IF stage (and into RD), which assisted the compiler in register allocation significantly. Don't ask why I didn't do that in the first place. I also missed a really easy optimization that reduced the execution time of many of the functional units. Lastly, I rewrote the decoder and other mechanisms in a manner that is amenable to dynamic recompilation for down the road. I'd say it was time well spent.

Now for a battery of regression testing, and hopefully implementing most, if not all, of the vector computational instructions this weekend.

Thinking about open-sourcing under the MAME license, too.

Wow, that was a lot of random thoughts.

 

[MarathonMan]

More good news...

None of the current emulators make effective use of SSE. I figured out how to map most (if not all) of the RSP's vector functions directly to x86 SSE.

I have a feeling that my cycle-accurate core is faster than PJ64's intepreted core, and continually nearing the recompiler core. Whenever/if I implement dynarec, the performance should be comparable.

 

[Nintendo Maniac]

Now, is said SSE optional? Cause you obviously don't want it on ARM and/or PowerPC since SSE is x86-exclusive (though ARM does have NEON).

 

[Zuzma]

More good news...

None of the current emulators make effective use of SSE. I figured out how to map most (if not all) of the RSP's vector functions directly to x86 SSE.

I have a feeling that my cycle-accurate core is faster than PJ64's intepreted core, and continually nearing the recompiler core. Whenever/if I implement dynarec, the performance should be comparable.

That sounds like ps2 emulator level stuff. Pretty sure they have some kind of dynamic recompiler for the systems vector unit. Also sure it's fast now but would hooking it up to the main CPU and RCP slow it down somewhat or are you not worried about that?