Rodimus Primal
New member
Wow it really is coming along. I like the name too! CEN64.
Announcement: Cycle-accurate N64 development underway.
- Thread starter MarathonMan
- Start date
Bighead
Oversized Cranium
I never thought I would be excited to see pong... great work MarathonMan! I have to admire your skill and dedication, and I am really looking forward to this.
I've been following this thread since the beginning, and it seems you hit quite a few milestones on the performance side of things. At this point, do you have a rough idea of what the system requirements for "full speed" may be once its capable of playing commercial games? I'm guessing it will vary game to game, I'm just curious on a rough estimate.
I've been following this thread since the beginning, and it seems you hit quite a few milestones on the performance side of things. At this point, do you have a rough idea of what the system requirements for "full speed" may be once its capable of playing commercial games? I'm guessing it will vary game to game, I'm just curious on a rough estimate.
OP
MarathonMan
Emulator Developer
- Thread Starter
- #323
Thanks for the kind words!
I have a rig similar to your sig; that should be more than adequate. The simulator has a near-linear speedup with frequency (# of cores, etc. don't matter as much as most programs IMO).
I have a bug that's preventing me from building a 'release' / optimized build at the moment... I'm fearing that one of the commits that was necessary to properly implement the precise interruptions is going to slow things down somewhat, but I haven't had the time to find the bug and inspect that.
OP
MarathonMan
Emulator Developer
- Thread Starter
- #324
Got a small bit of time to work on it earlier tonight --
The good news:
I have release builds working again.
The bad news:
Performance regressions up the wazoo. At this rate, I'm thinking a ~3GHz+ processor will be the minimum requirements. That being said, I also cleaned up some careless things I've done over the last few weeks and doubled performance since getting release builds working. And I still haven't emulated the cache, forcing me to go all the way through the emulated bus/RDRAM once (or twice, on data accesses) per-cycle. So who knows.
The good news:
I have release builds working again.
The bad news:
Performance regressions up the wazoo. At this rate, I'm thinking a ~3GHz+ processor will be the minimum requirements. That being said, I also cleaned up some careless things I've done over the last few weeks and doubled performance since getting release builds working. And I still haven't emulated the cache, forcing me to go all the way through the emulated bus/RDRAM once (or twice, on data accesses) per-cycle. So who knows.
F
Fanatic 64
Guest
Isn't there any way to fix the performance bugs?
OP
MarathonMan
Emulator Developer
- Thread Starter
- #326
Yes... with inspection and time. :teehee:
That being said, I'm running into things that I never even thought about from a standpoint six months ago. I can only optimize so much, you know?
mrmudlord
New member
Meh, performance isnt the problem.
3Ghz Ivy Bridges are no problem at all. The issue should be accuracy. Since everyone cares about that, who gives a toss about speed? Byuu clearly doesn't give a damn, nor do mamedev. So neither should you.
Don't forget, there is also the pixel/cycle exact RDP too to emulate.
3Ghz Ivy Bridges are no problem at all. The issue should be accuracy. Since everyone cares about that, who gives a toss about speed? Byuu clearly doesn't give a damn, nor do mamedev. So neither should you.
Don't forget, there is also the pixel/cycle exact RDP too to emulate.
OP
MarathonMan
Emulator Developer
- Thread Starter
- #329
I can imagine... if I can get a full-blown N64 simulator (with a 93.75MHz chip) to achieve the same performance as a system with a 16.xxMHz chip, I'll call it a win in my book. Anything else is just icing on the cake.
Since you can get 3-4Ghz Sandy Bridge systems for cheap at every corner I don't think performance is such a great issue. In a year or so probably every $300 notebook will have that kind of power.
Would be more than great if we finally had an emulator that can run homebrew code flawlessly. All current emulators already fail at some of the official SDK's examples.
Great progress so far MarathonMan and certainly a very interesting read :satisfied
Would be more than great if we finally had an emulator that can run homebrew code flawlessly. All current emulators already fail at some of the official SDK's examples.
Great progress so far MarathonMan and certainly a very interesting read :satisfied
OP
MarathonMan
Emulator Developer
- Thread Starter
- #332
Been debating on it... not too enthusiastic about it at the moment. Rest assured, if you can understand C, you will understand this... it's very clean code for the most part. There's really only a couple things that get hairy, and they're well-documented.
Have been improving the performance and found/fixed another bug that could crop up in the future... still need to implement the VR4300 ICache. When I bypass reading from the bus, simulation speeds up twofold or something ridiculous.
been lurking in this thread for a few months and I gotta say, this project is REALLY getting my hopes up for the future of N64 emulation!
a question though, I know you were talking about it earlier, but how much multi-core use is this thing currently utilizing? and how much do you intend to? I've got an ivybridge i7 (4 cores, 8 threads, 3.4-3.9 GHz) and it would be a pity if it could only utilize a single core/thread
also. I know you're kinda iffy on using OGL acceleration for graphics except as a possible option, but what about using OpenCL acceleration for computation? most gamers still have a pretty hefty second processor (or pair... or 4) in their machine and it would be a pity to waste it... hell... even the intel onboard gpus are nothing to sneeze at.
I'll understand PERFECTLY WELL if you don't, since learning new libraries is often about as fun as pulling teeth, but since performance may still be an issue...
a question though, I know you were talking about it earlier, but how much multi-core use is this thing currently utilizing? and how much do you intend to? I've got an ivybridge i7 (4 cores, 8 threads, 3.4-3.9 GHz) and it would be a pity if it could only utilize a single core/thread
also. I know you're kinda iffy on using OGL acceleration for graphics except as a possible option, but what about using OpenCL acceleration for computation? most gamers still have a pretty hefty second processor (or pair... or 4) in their machine and it would be a pity to waste it... hell... even the intel onboard gpus are nothing to sneeze at.
I'll understand PERFECTLY WELL if you don't, since learning new libraries is often about as fun as pulling teeth, but since performance may still be an issue...
OP
MarathonMan
Emulator Developer
- Thread Starter
- #334
I'm currently only doing single-threaded. Multi-threaded simulation is hard. I work on a research-level simulator project in graduate school, and I've never seen it properly done.
Basically, there's two conflicting problems at hand: modern processors have a prohibitively high synchronization cost, yet any processor (or thread-able subsystem) can send any other subsystem at message at any given cycle. The problem is essentially this: imagine you have a room full of people. Each person can tell any other person in the room to do a command, and it must be obeyed immediately. The obvious solution is to go round-robin around the room from person to person, one at a time, and have them list out their commands to everyone else. However, this is inherently "single-threaded"; there's only one possible order that you can go in at any given time. Essentially, when multi-threading, you lose the guarantee that commands can be deliver instantly (since the one person listing commands might tell a different set of people some commands before telling you your commands, which takes time). You need to somehow support the fact that someone else in the room said that you need to do command X ... five seconds ago. I've been thinking about assumptions that I can place on the problem and restrictions that I can make to make it more doable, but there's no guarantees that it will work at the moment.
OpenCL isn't really an option, because the latency to send a batch of commands is incredibly high. I need to execute commands at ~62.5 million times per second, whereas sending a batch of commands to OpenCL has a latency of >>> (1/62.5 million).
Last edited:
OP
MarathonMan
Emulator Developer
- Thread Starter
- #336
Implemented another handful of instructions and whatnot. Trying to see if I can implement enough FPU support today to get LaC's fire demo running.
chiburunga
New member
MarathonMan, you are the man... please dont leave this project never... you are our hope in n64 emulation!
OP
MarathonMan
Emulator Developer
- Thread Starter
- #338
Err... most of the work has already been cut out for me. I'm just refining it at best.
LaC/marshallh/oman/Dr. Decap/etc. etc. (don't mean to cut the list short, but there have been so many contributors) are the ones who have spent all the time researching what Nintendo never wanted us to know.
That being said, I do plan to see this project through.
MarathonMan, a cycle accurate N64 emulator is something I'm really interested in being able to use. Obviously it will probably be a long while before it is usable, both development-wise and I would guess consumer hardware-wise as well, but I honestly cannot wait for neither of those to be a barrier to N64 emulation.
Good luck with the development of the emulator. I'll be following this thread closely to stay up-to-date on your progress.
Good luck with the development of the emulator. I'll be following this thread closely to stay up-to-date on your progress.
OP
MarathonMan
Emulator Developer
- Thread Starter
- #340
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
RDRAM: http://github.com/tj90241/cen64-rdram
RDP: http://github.com/tj90241/cen64-rdp
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!
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
RDRAM: http://github.com/tj90241/cen64-rdram
RDP: http://github.com/tj90241/cen64-rdp
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: