What's new

Announcement: Cycle-accurate N64 development underway.

MarathonMan

Emulator Developer
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. :n64:
(Also, if possible, a subforum would also be greatly appreciated! :saint:)

--------------------------------------------------------------------------------

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!
 
Last edited:

DETOMINE

New member
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
 
OP
MarathonMan

MarathonMan

Emulator Developer
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

Here are the repositories:
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:
OP
MarathonMan

MarathonMan

Emulator Developer
Will you add real time support for games like doubutsu no mori? And a fix for the black box framebuffer glitch?

The idea is that, with cycle-accurate simulators, you don't need to "add" support for anything... everything just works out of the box.

However, I'm light years away from finishing for the time being. :happy:
 
OP
MarathonMan

MarathonMan

Emulator Developer
Not a troll, but angrylion already did a dot accurate RDP software rasterizer...

I'm well aware; I have a clone of every open-source N64 emulator out there stored locally on my machine!

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.
 

mrmudlord

New member
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.
 
OP
MarathonMan

MarathonMan

Emulator Developer
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.

Not yet. Don't see the need for one until the project is more developed.
 
OP
MarathonMan

MarathonMan

Emulator Developer
<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).

</bump>

Future goal is to bring the requirements down to more-sane levels so people other than enthusiasts are able to run it!
 

Remote

Active member
Moderator
Maybe post some code and show us what instructions you have simulated, what you have left to add etc (to maybe lessen the need for self bumps) ;)
 
OP
MarathonMan

MarathonMan

Emulator Developer
Maybe post some code and show us what instructions you have simulated, what you have left to add etc (to maybe lessen the need for self bumps) ;)

https://github.com/tstache1/vr4300

Interfaces and overall structure is absurdly unstable.

Insns: ADDIU, ANDI, BEQ, BEQL, BNE, BENL, ORI, LUI, LW, XORI.

Most of the execution unit itself is (obviously) unimplemented. I only implemented enough instructions to get an idea of 'how fast' the pipeline currently is (where the aforementioned testing essentially dumbed down to a LW/ANDI/BEQL loop).

I spent the last week or two trying to see if it was actually possible to simulate the pipeline at full speed (which I fully believe it is). Most of the focus right now is getting the interfaces up to speed. I hope to get an actual, clean cache/memory interface up within the next week or so (not the shoddy excuse of an inline half-arsed lookup that's currenlty in place). After that, I'll move on to implementing most of the pipeline and actually get something going.

EDIT: There are a couple design issues with the code that I'm currently aware of and intend battling in the future. Most of these are due to my initial hope that everything couple be threaded and not have horrendous performance on 32-bit architectures, but I've had to toss out those interests in order to get decent performance (i.e., 32-bit TLB lookup and write entry interfaces probably need to be nixed and replaced with a sole 64-bit version).

I've only been working on this project for a little over a month now, so if it looks infantile, that would be why :p.
 
Last edited:
OP
MarathonMan

MarathonMan

Emulator Developer
Bump.

https://github.com/tstache1/cen64
https://github.com/tstache1/vr4300

Lots more progress. Made an actual emulator repository (right now, will likely only compile on Linux machines, though).

* Currently wads all the way through IPLROM and loads the first few pages of cartridge ROM into memory and begins executing it.

* Lots of performance improvements. Even a lowly C2Q at 2.0GHz is almost able to handle the grunt for the time being. I shocked myself with the performance of this thing (considering caches are currently disabled and there are no delays currently in place for memory accesses -- both of which will improve performance substantially). I do expect it to get worse... but only because cycle-accurate emulation on a processor of this calibre would be unreal.
 

DETOMINE

New member
I have to admit that I totally don't understand what you're doing (i.e. the code), but I'm still impressed :teehee:
 
Last edited:

Remote

Active member
Moderator
You posted a lot of code, I was thinking more that you post maybe a loop where you write some short comments on what you are doing and what registers you are simulating/emulating to get interest brewing. Keep ut the work and maybe post a short todo list where you can show what you want to do in the closest future and when you reach a goal you can check/update your list.
 
OP
MarathonMan

MarathonMan

Emulator Developer
You posted a lot of code, I was thinking more that you post maybe a loop where you write some short comments on what you are doing and what registers you are simulating/emulating to get interest brewing. Keep ut the work and maybe post a short todo list where you can show what you want to do in the closest future and when you reach a goal you can check/update your list.

Probably a good idea :p

What the VR4300 core currently lacks:
* TLB interface, instruction and data caches.
* Several instructions/opcodes.
* Interlock/fault handlers.
* COP0/COP1 (MMU/FPU).
* SysAD synchronization.
* Proper memory access delays.
* Various other doodads.

What the VR4300 core currently has:
* Basic pipeline structure, register file, fault queue.
* 25% of the execution unit implemented.
* Memory load/store interface.
* Virtual address resolver.

Basically, I've implemented enough to get the VR4300 to boot the PIF ROM in it's entirety. In addition, I have _just_ enough of the actual console components (audio, video, PIF, etc.) to get the VR4300 to pass all the initialization phases of the PIF ROM. Correct me if I'm wrong, but MESS is the only other emulator that I'm aware of that currently uses the PIF ROM to boot (not that it's super important or anything).

What's up next?
* More work on the VR4300 core: more instructions!
* Something to show that this project isn't vaporware (perhaps an incredibly anemic video controller or something).
* Move on to VR4300 caches, performance improvements, etc.
* Then focus on the rest of the components (video, audio, etc.)

As always, the first and foremost goal is accuracy, with performance and design closely following. Each component of the system is an entirely separate entity (library) that gets linked together in the final executable.
 

Top