Cen64是一个2012年公开的N64模拟器，至今尚未发表。有点意思的是Cen64是目前唯一还活着的试图实现时钟级精确（Cycle-accurate）的N64模拟器。丑话说在前面，由于时钟级精确的另一面就是巨大的硬件资源的消耗，以N64硬件的复杂性，Cen64即使最终完成也可能成为史上最慢的N64模拟器。
作者最近更新了在emutalk的官方帖子，将计划改为开源。不管怎么说，让我们关注一下。
Cycle-accurate的字面翻译是周期精确，指仿真器可以模拟出特定微构架硬件在每一个独立时钟周期内的所有动作，这个时钟周期是根据硬件的晶振频率设置，以赫兹来计数。和时钟级精确相对的是指令级精确，绝大多数模拟器能够达到指令级精确就已经可以完全实用，所以时钟级精确对于我们普通用户完全就是多余…呵呵。
目前我所知道的时钟级精确模拟器有喜闻乐见的SFC模拟器higan，SMS模拟器twoMbit，新登场的MD模拟器Exodus，还有一个RetroCopy…是的，你没看错，就是那个拥有3D界面的超2B多机种模拟器。MAME/MESS由于太过复杂，目前只能在一部分驱动中实现时钟级精确。
Announcement: Cycle-accurate N64 development underway
Hi,
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)
Enjoy!