Menu
What's new
By:
Filters

Announcement: Cycle-accurate N64 development underway.

OP
MarathonMan

MarathonMan

Emulator Developer
angrylion said:
<snip>
Click to expand...

Honestly, I'm just trying to give credit where credit is due. :(

If you are not happy with the credits as they appear at the top of the forked RDP source code, please PM me with any revisions that you would like to see and I will immediately commit changes after hearing your grievance. As per my response to JD/MooglyGuy, I understand the frustrations in not being credited appropriately and it is not my intention to discredit anyone's works. I'm a newer member on the scene who has not followed the past of N64 emulation in the depth that others have.

All I want is some accurate N64 emulation. :D
 
Z

Zuzma

New member
What happened to the forums on cen64.com MarathonMan? It just goes to your hosted git account now. :(
 
Last edited:
Z

Zuzma

New member
Looks like it's working now, thanks for the help though guys! Either MarathonMan fixed it or whatever problem I was having before is magically gone (I like those).
 
Last edited:
OP
MarathonMan

MarathonMan

Emulator Developer
Zuzma said:
Looks like it's working now, thanks for the help though guys! Either MarathonMan fixed it or whatever problem I was having before is magically gone (I like those).
Click to expand...

Heh, you probably caught it as I was messing with the server to get the git interface up and going.
 
Z

Zuzma

New member
I'm just glad you didn't nuke it because of something like it not being active enough. At least that's what my worst case scenario train of thought came up with. ;o
 
OP
MarathonMan

MarathonMan

Emulator Developer
For anyone not following the forums on cen64.com, I've gotten the new core stable enough to boot ROMs.

http://git.cen64.com/?p=cen64.git;a=summary

I'm currently trying to remove GLFW (and replace it with WinAPI, X11, etc. backends) as I'll have more control over how the application works and a more optimized binary.

Among other things, the new core:
- Is more verifiable (in terms of correctness)
- Is faster (so far, and likely staying that way)
- Is smaller
- Builds with GCC, Clang, and MSVC on Windows, Linux, (and Mac?)

Unfortunately, I haven't added FPU, TLB, RSP, RDP, etc. support back in yet, so it's still in a rather infantile state and can't boot a majority of ROMs. But, hopefully that'll change soon. :)
 
OP
MarathonMan

MarathonMan

Emulator Developer
_Zack_ said:
Awesome! Thanks for the updates :>
Click to expand...

No problem. Bump:

As of this weekend, CP1 support is starting to make it's way in the revised core. LaC's fire demo now works. It also fixes the old "flicker" bug that was always present in the old core, and runs at a very comparable speed to what hackturax's demo on youtube shows... looks like the rewrite was worth it!
 
OP
MarathonMan

MarathonMan

Emulator Developer
NES_player4LIFE said:
Sooo, whats going on? Do you have any new developments?
:icecream:
Click to expand...

The new core/rewriter is mostly complete.

- SSE2 is now the "minimum requirement", giving CEN64 the ability to run on ALL x86_64 machines.
- At the same time, CEN64 has been optimized all the way up to machines supporting the AVX instruction set.

- The rewrite has significant performance gains on Haswell. On i5 45xx and i7 47xx, most public domain ROMs run at full speed, which was not possible with the old core. There are also performance gains to be had on older architectures, as well... just not as great in size.

I have been carrying the approaches I used for optimization over to the RSP, which is also showing massive performance gains. Unfortunately, it is still missing a few instructions at the current time so most commercial ROMs still do not run. Hopefully in a few weeks, I'll have that taken care of.
 
S

suspendedhatch

New member
Finally registered here just to say that I've been following this since the beginning and I'm greatly looking forward to this project's realization.

Thank you!
 
F

Falkoner

New member
I've looked around for a bit and I can't seem to find an answer to the question I have. I'd like to know if CEN64 will work with plugins outside the set being developed specifically for CEN64, more specifically, if it'll work with NRage's Controller Plugin(for Gameboy Pack emulation) and GLideN64, which should soon become to de-facto video plugin.

I'm mostly interested because of the extra features both plugins allow, such as better internal resolution, HD texture packs, widescreen hack, etc., and I'd assume that letting GLideN64 handle the graphics would greatly accelerate the emulation.

The issue is that at this point almost none of the emulators have perfect core emulation, and that would be the big difference between CEN64 and simply using Angrylion's pixel-perfect video plugin with any other emulator, because the core wouldn't have errors.

So yeah, any way plugins will be supported for CEN64, or are they already?
 
OP
MarathonMan

MarathonMan

Emulator Developer
Falkoner said:
I've looked around for a bit and I can't seem to find an answer to the question I have. I'd like to know if CEN64 will work with plugins outside the set being developed specifically for CEN64, more specifically, if it'll work with NRage's Controller Plugin(for Gameboy Pack emulation) and GLideN64, which should soon become to de-facto video plugin.

I'm mostly interested because of the extra features both plugins allow, such as better internal resolution, HD texture packs, widescreen hack, etc., and I'd assume that letting GLideN64 handle the graphics would greatly accelerate the emulation.

The issue is that at this point almost none of the emulators have perfect core emulation, and that would be the big difference between CEN64 and simply using Angrylion's pixel-perfect video plugin with any other emulator, because the core wouldn't have errors.

So yeah, any way plugins will be supported for CEN64, or are they already?
Click to expand...

CEN64 is currently using angrylion's mylittle-nocomment plugin (with VI filters stripped and altered to work with CEN64). While CEN64 doesn't support the zilmar-plugin spec out of the box, it's usually a very minimal amount of code games to get things into gears. That being said, I don't have any plans to support GLideN64 or any of those plugins; I'm not personally interested in the HLE approach.

Most other plugins, for example NRage, don't really make sense in the context of CEN64 as CEN64 is platform and architecture agonstic. As PJ64 is 32-bit and Windows x86 only, a large portion of of plugins are strictly tied to that environment, which is a no-go for CEN64 (which currently supports Windows/Linux/Mac). No worries though -- there are plans for all kinds of controller support to come.

Also, 64DD support on the way. RTC clock quasi-works and the IPL attempts to load 64DD ROMs once I flag a disk present bit. Thanks to OzOnE and LuigiBlood for all their reverse-engineering support. Without them, this feat would not be possible.
 

Attachments

  • ddipl.png
    ddipl.png
    29.7 KB · Views: 1,028
F

Falkoner

New member
MarathonMan said:
CEN64 is currently using angrylion's mylittle-nocomment plugin (with VI filters stripped and altered to work with CEN64). While CEN64 doesn't support the zilmar-plugin spec out of the box, it's usually a very minimal amount of code games to get things into gears. That being said, I don't have any plans to support GLideN64 or any of those plugins; I'm not personally interested in the HLE approach.

Most other plugins, for example NRage, don't really make sense in the context of CEN64 as CEN64 is platform and architecture agonstic. As PJ64 is 32-bit and Windows x86 only, a large portion of of plugins are strictly tied to that environment, which is a no-go for CEN64 (which currently supports Windows/Linux/Mac). No worries though -- there are plans for all kinds of controller support to come.
Click to expand...

Ah, yes, of course zilmar spec won't be supported, Windows-only is lame, I suppose I was more interested in knowing whether the plugins that work with Mupen64Plus will also work with CEN64.

Just as an interesting side-question, if you were to estimate in a percentage, what percent of the current CPU usage do you think is being generated by the software-based video rendering?
 
OP
MarathonMan

MarathonMan

Emulator Developer
Falkoner said:
What percent of the current CPU usage do you think is being generated by the software-based video rendering?
Click to expand...

I profiled the other day; very little. Probably around the order of 10%, or less. angrylion's plugin is ridiculously optimized it seems. I might be able to take it a bit further with some SSE-fu, but I won't even bother with it until I get the RSP/VR4300 down to something reasonable.

The main deadweights are the interpreted, cycle-accurate RSP and VR4300 cores. They're coming in at a hefty 30+% utilization each.
 
Last edited:
You must log in or register to reply here.

Top