Cen64:Cycle-accurate N64 emulator





Announcement: Cycle-accurate N64 development underway


I’d like to inform the community that I have been developing a cycle-accurate emulator for the N64 (not to steal from Hackturax’s fire)! The project is currently in infant stages, and nameless, but has several goals:

1) Accuracy.
The community has yet to see a cycle-accurate emulator for the N64, nevermind one that runs at acceptable speed. Because accuracy is my first and foremost concern with this project, I am opening it up to the community for all eyes to see, effective immediately. Technical (read: technical) bug reports or inaccuracies in hardware emulation are welcome and extremely appreciated.

Another reason that I wish to open this project to the community is to improve emulation quality and knowledge base of the N64 in general. Much of the documentation that I have found this far would cease to exist if it were not for the community’s efforts in gathering resources solely for this truly one-of-a-kind console. My hope is that I’ll be able to give back to the community in the same way that I have benefited from it since the earliest HLEs.

2) Design.
In lockstep with accuracy, design is another major tenet of this project. I absolutely refuse to include hacky workarounds in something as complex as a cycle-accurate simulator for a minor performance gain. The goal is to write an emulator with a clear-cut, well thought-out design that in and of itself serves as documentation for the platform and developers of future projects.

Moreover, I plan to avoid any GNU-specific extensions or third-party libraries as much as possible. My hope is that the emulator will be completely cross-platform and cross-architecture (yes, I’m looking at you, ARM). I also hope to write the code in a manner so that it is amenable to multi-threading (but delay it until after the simulator is in a more developed state and requires a performance boost to run at full speed).

3) Performance.
I am, in the true sense, a systems programmer. I will fight for every little last bit of performance, even if it means increased development time. See below for an idea of how much time I invested into writing the TLB module.


“Yeah, this is great and all, but what have you done thus far?”

I’ve actually been working on this project for a few weeks now. About a month or so ago, I began collecting documentation and information on the N64. For a few weeks, my only goal was to absorb as much information about the N64 as I possibly could.

A few weeks ago, I began focusing on the VR4300’s MMU/TLB (and, to a lesser extent, the ICache/DCache). At this point in time, I have more or less finalized most of the TLB and have been working to document the sources and perform and final tweaks to the code before making an initial release to the public.

I am currently able to simulate, under worst case, the TLB at full speed on “old” commodity hardware (Intel Core 2 Duo P8600, 2.4GHz, 4GB RAM). To be exact, the TLB code is capable of executing ~93,750,000 lookups (1 lookup/pcycle) across a TLB full of global entries in less than a second on the aforementioned hardware configuration. Best case (few global entries, well-distributed number of ASID-specific entries) drops that to about half of that time. This is possible as the code was written such that L1 cache misses are practically non-existent, branch mispredictions are low, and IPC very high (currently running in the range of 2.5IPC). My hopes are that when it comes time to develop the pipeline, I’ll be able to do play some clever tricks that will result in only having do a TLB lookup every handful of pcycles (while still maintaining 100% accuracy!).

I’m not sure if the idea has rubbed off or not yet, but my goal is more or less to write a simulator that is not only entirely accurate and well-thought out, but is able to run at full-speed on C2D (or maybe i5/i7 at a maximum). At this point in time, I’m not sure if it’s an attainable or realistic goal, but it is my hope nonetheless.

Comments, suggestions, and flame-war type message are welcome. 
(Also, if possible, a subforum would also be greatly appreciated! )


EDIT: [4/2/13]: Open-sourced the project.

Decided to license as BSD 3-clause. Do whatever you want with the source.

For updates, follow me on github and star the sources.

There are several (err, seven?) plugins; I’ll be working on pushing them up to github and update both this post and the first post accordingly. None of them will be of much use until I upload the framework that ties all the plugins together (which will likely be done last to make sure everything checks out).

** Primary Module **
Framework: http://github.com/tj90241/cen64

** Submodules **
AUDIO: http://github.com/tj90241/cen64-audio
BUS: http://github.com/tj90241/cen64-bus
PIF: http://github.com/tj90241/cen64-pif
PI: http://github.com/tj90241/cen64-rom
RDP: http://github.com/tj90241/cen64-rdp
RDRAM: http://github.com/tj90241/cen64-rdram
RSP: http://github.com/tj90241/cen64-rsp
VI: http://github.com/tj90241/cen64-video
VR4300: http://github.com/tj90241/cen64-vr4300

To acquire:
Clone the framework: (git clone git://github.com/tj90241/cen64.git)
Pull in the modules: (git submodule init && git submodule update)




%d 博主赞过: