September 13th, 2012, 03:20
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:
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.
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).
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 **
** Submodules **
Clone the framework: (git clone git://github.com/tj90241/cen64.git)
Pull in the modules: (git submodule init && git submodule update)
Last edited by MarathonMan; April 28th, 2013 at 20:52.
September 13th, 2012, 17:57
Can you provide a link to your work (binary? source?)?
Maybe you should join your effort with Hacktarux, or at last share documentations/demos.
It seems promising, I just hope it will go further :p
September 14th, 2012, 01:48
Will you add real time support for games like doubutsu no mori? And a fix for the black box framebuffer glitch?
September 14th, 2012, 03:17
Here are the repositories:
Originally Posted by DETOMINE
VR4300 Simulator: https://github.com/tstache1/vr4300
CEN64 Emulator: https://github.com/tstache1/cen64
I haven't pushed the tlb branch yet, which is where most of the work is right now... getting it photo ready, should have it up in the next day or so hopefully.
I'm not sure I would work fully with Hackturax, as I have always wanted to work on a large project by myself, but I would be more than willing to assist with code and/or share findings with him.
Demos probably won't come for awhile. I plan on finishing most of the CPU before I begin working on the RDP/RSP (and even the RDP will take some time, as I plan to do software rasterizing).
Last edited by MarathonMan; October 10th, 2012 at 16:06.
September 14th, 2012, 03:18
The idea is that, with cycle-accurate simulators, you don't need to "add" support for anything... everything just works out of the box.
Originally Posted by Darkzack235
However, I'm light years away from finishing for the time being.
September 14th, 2012, 03:48
Not a troll, but angrylion already did a dot accurate RDP software rasterizer...
September 14th, 2012, 03:54
I'm well aware; I have a clone of every open-source N64 emulator out there stored locally on my machine!
Originally Posted by mrmudlord
I'm not doing it to compete with anyone, nor do I necessarily think that mine will be better. I simply do what I do for the sake of enjoyment... to me, this is fun.
September 14th, 2012, 04:13
Question: Do you have a N64 devkit or suitable flash hardware for research?
Doubt you will just make a emulator just based on illegal and leaked SGI documentation for missing RSP/R4300i instructions, as well as proper RDP behaviour.
September 14th, 2012, 04:36
Not yet. Don't see the need for one until the project is more developed.
Originally Posted by mrmudlord
October 7th, 2012, 23:00
<shameful self bump>
Big checkpoint: Able to simulate a handful of instructions (from adds to loads and branches) at a full 93.75MHz on my 4.5GHz i7.
Implementation is single-threaded. The cost of atomic operations on x86 made locking every cycle a lost cause, even on the machine mentioned above.
So far, it's written in ANSI C and should be completely portable across all platforms and architectures. (Technically, it's C99 as it needs stdint.h to guarantee sign-extended 32 and 64-bit types, but other than that... ANSI C).
Future goal is to bring the requirements down to more-sane levels so people other than enthusiasts are able to run it!