Announcement: Cycle-accurate N64 development underway.

[Nintendo Maniac]

For an interpreter, this thing is screaming.

Define "screaming". Is it like running F-Zero GX at 90fps/150% on a 4.5GHz Sandy/Ivy Bridge?

 

[MarathonMan]

Define "screaming". Is it like running F-Zero GX at 90fps/150% on a 4.5GHz Sandy/Ivy Bridge?

Simulating a RSP with no stalls at 100MHz on a 4.5GHz Sandy. I don't have the VR4300 or devices emulated anywhere near enough to run ROMs.

 

[Guru64]

I don't have the VR4300 or devices emulated anywhere near enough to run ROMs.

Let alone Gamecube games.

 

[Fanatic 64]

Let alone Gamecube games.

What?

If this is a reference to Dolphin, I think you should know Dolphin cannot emulate the N64 at all, what it can emulate is an emulator made by Nintendo to run N64 games on the Wii (aka. Virtual Console).

And this emulator is not meant to compete at all with something like Dolphin, it is meant to be specifically a cycle-accurate N64 emulator.

 

[MarathonMan]

Getting bored with implementing RSP instructions (aka writing SSE). Going to fill in the rest of the RSP with stubs that just alert me when unimplemented functions get called and jump back over to the VR4300/PIF for awhile. I think there's enough functionality in the RSP to get basic (read: very, very basic) homebrew to boot... would be nice to get something out on the screen, even if it's a static picture with rotating sprites.

 

[Guru64]

What?

If this is a reference to Dolphin, I think you should know Dolphin cannot emulate the N64 at all, what it can emulate is an emulator made by Nintendo to run N64 games on the Wii (aka. Virtual Console).

And this emulator is not meant to compete at all with something like Dolphin, it is meant to be specifically a cycle-accurate N64 emulator.

It was a reference to Nintendo Maniac's post. F-Zero GX is not a Nintendo 64 game.

 

[Fanatic 64]

Getting bored with implementing RSP instructions (aka writing SSE). Going to fill in the rest of the RSP with stubs that just alert me when unimplemented functions get called and jump back over to the VR4300/PIF for awhile. I think there's enough functionality in the RSP to get basic (read: very, very basic) homebrew to boot... would be nice to get something out on the screen, even if it's a static picture with rotating sprites.

Well, you can always go work on something else and then go back to the RSP. I suppose it would be a significant achievement if you could actually run something and get output to the screen (trough I imagine you would need a Reality Drawing Processor emulator and either a software rasterizer, DirectDraw/Direct3D or OpenGL output method).

 

[MarathonMan]

Well, you can always go work on something else and then go back to the RSP. I suppose it would be a significant achievement if you could actually run something and get output to the screen (trough I imagine you would need a Reality Drawing Processor emulator and either a software rasterizer, DirectDraw/Direct3D or OpenGL output method).

Right... of course. I'm just saying that if I run homebrew pong, I doubt it'll use the clipping instructions of the RSP or really complex features of the VR4300. I'm really anxious to get to the RDP.

 

[Nintendo Maniac]

It was a reference to Nintendo Maniac's post. F-Zero GX is not a Nintendo 64 game.

Of course it isn't, but running it at 90fps/150% on a 4.5GHz Sandy/Ivy surely counts as "screaming", no?

 

[olivieryuyu]

Right... of course. I'm just saying that if I run homebrew pong, I doubt it'll use the clipping instructions of the RSP or really complex features of the VR4300. I'm really anxious to get to the RDP.

why not using Angrylion work? he works on the RDP on a LLE level for years now ...

 

[MarathonMan]

why not using Angrylion work? he works on the RDP on a LLE level for years now ...

1) Not cycle accurate; just pixel-accurate.
2) I genuinely enjoy reserve engineering; for me, this is how I relax in my spare time. I'm really interested in graphics, so I'd like to write my own anywho.

 

[XICO2KX]

I genuinely enjoy reserve engineering; for me, this is how I relax in my spare time. I'm really interested in graphics, so I'd like to write my own anywho.

The honest words revealing the inner motivation behind a great mind! :arabia:
I bet this is going to be the best N64 emulator of all times! :satisfied

 

[MarathonMan]

Started melding everything into a master binary. Made a couple "plugin" folders, and all is well...

...@purple:~/Projects/cen64$ ./cen64 data/pifrom.bin data/zelda.rom 10
[PIF]: "Initializing PIF."
[RDRAM]: "Initializing RDRAM."
[XBUS]: "Initializing XBUS."
[RSP]: "Initializing CPU."
[RSP]: "Initializing COP2."
[VR4300]: "Initializing CPU."
[VR4300]: "Initializing COP0."
[VR4300]: "Handling fault: RST"
[VR4300]: "Unimplemented function: LUI."
[VR4300]: "Unimplemented function: MTC0."
[VR4300]: "Unimplemented function: LUI."
[VR4300]: "Unimplemented function: ORI."
[VR4300]: "Unimplemented function: MTC0."
[VR4300]: "Unimplemented function: LUI."
[VR4300]: "Unimplemented function: LW."

I ended up scrapping a large part of the "old" VR4300 core that I had written after all I learned with the RSP core. The VR4300 core should be much faster now (>25%), and is much more elegant to look at as well. As soon as I merge the execution functions from the old VR4300 core into the new one, and rewrite the old VR4300 MemoryFunctions to communicate with the new XBus plugin, things should start fitting together (hopefully).

 

[DETOMINE]

The VR4300 core should be much faster now (>25%)

Each time I read you, you have made a core 25% faster than the previous one . At this rate, I even have the hope that it will run on my computer .

Seriously I can't wait to see the first demo.

It's so good to see the N64 emulation scene alive (with your project, the new PJ64 2.0, mupen64plus, and new video plugins...).

 

[MarathonMan]

Okay, so, I'm not sure who's a developer here, but here's my overall "design approach" after kicking my feet around last night:

It basically boils down to: modularizing everything. And I mean everything. Every possible aspect that is "pluggable" shall be provided by a plugin. Therefore, my initial prototype actually has... 9 plugins (AIF, PIF, SIF, RDRAM, RDP, RSP, VIF, VR4300/MIF, XBUS). The reasoning behind this scheme gets a little technical, but...

(1) Let's suppose the VR4300 wants to tell the RSP that he should start executing. With multithreading, this is fundamentally difficult because if you write the command directly into the RSP's buffers from another thread (in this case, the VR4300's), you could suffer from a race condition and, well, things begin breaking. Thus, instead, everyone writes and reads from a common arbitration layer (XBUS) in the same manner that a real console would. Later on down the road, XBUS will basically be the holy grail to multi-threading support; every single component can run in it's own thread and the commands will get serialized in XBUS. Granted, I'm making this seem much, much, much less complex than the problem actually it, but at least it looks purrty from the outside.

(2) It hides complexity from each plugin, and thus encourages new developers to jump on board. If you're writing a VR4300 plugin, you have enough to worry about. If you need to read from address 0x1FC00000, you don't want to have to place the burden on yourself to look at which device that maps to (PIF ROM). Instead of forcing the burden of redirection on the VR4300 component, the VR4300 simply says "hey, XBUS, read from address 0x1FC00000, will ya?". The XBUS is responsible for talking to the appropriate device, and determining both the data returned/sent via the access, AND the amount of time that the access took (since, say, RDRAM writes/reads are far slower than I/O mapped register writes/reads). Later on, it'll also delay sending the results until they're "really" available in a multi-threaded environment.

There's a slight overhead associated with this flexibility (nothing comes for free), but the complexity (from a developer standpoint) is literally halved. Also, generally, when an external access has to be made, the component that makes the command is going to have to stall regardless... so even with code that generates a lot of off-chip accesses shouldn't suffer from poor performance.

This, of course, will all be hidden from the user as I prefer static library plugins over dynamic ones.

EDIT: I also figured out a method to finally fix the overhead of synchronization of multiple cores. I don't want to detail too much yet until I get a working implementation, but basically, cores run in a "detached", unsynchronized mode as long as possible. They only sync under a specific condition that must be met in order to guarantee correctness.

 

[Nintendo Maniac]

Since each plugin is in it's own module, and there are 9 modules, wouldn't this mean that AMD's "MOAR CORES!" would actually be useful in emulation for once?

 

[squall_leonhart]

Since each plugin is in it's own module, and there are 9 modules, wouldn't this mean that AMD's "MOAR CORES!" would actually be useful in emulation for once?

no.

 

[Nintendo Maniac]

no.

Ehh... I'd prefer to hear from MarathonMan before making any concrete conclusion.

And as a reference, I'm only running a 2.5GHz Brisbane.

 

[MarathonMan]

Since each plugin is in it's own module, and there are 9 modules, wouldn't this mean that AMD's "MOAR CORES!" would actually be useful in emulation for once?

^^ squall's answer ^^

No need to run the things like the controller interface in their own core; you'll just increase contention and deteriorate performance. Some plugins will share a core, while others won't. It'll scale fairly well up for 2-4 cores, though.

 

[Nintendo Maniac]

4 cores could technically still be viewed as following AMD's "MOAR CORES!" strategy since they're planning on having quad-core parts in Kabini, and not to mention starting with Richland that all non-jaguar-based APUs will be quad-core parts.