New core/version 0.3

News from administrators.
Locked
User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

New core/version 0.3

Post by MarathonMan » Thu May 08, 2014 11:34 am

http://git.cen64.com

Still lots of work to do before it's done, but opening it up to the public.

Should compile cleanly on MSVC now. Might have some glfw linker errors, though...

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core/version 0.3

Post by Snowstorm64 » Thu May 08, 2014 2:59 pm

I see, all games don't boot right now, and the VI/s seems to be very low comparing to the stable version. Maybe I did something wrong or is there still a lot of work to finish the new CEN64's architecture? Anyway, keep up the hard work ;)
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Thu May 08, 2014 4:20 pm

No caches, FPU, most of CP0, RSP, or RDP!

So yes, only very primitive ROMs boot as of right now.

As for the performance issues, make sure tell CMake to do a release build.

cmake -i <path/to/cmakelists>
and specify Release for build type.

Should get considerably faster.

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core/version 0.3

Post by Snowstorm64 » Fri May 09, 2014 9:03 am

Now it's much better, 60-75 VI/s. I hope it keeps these values when everything is implemented! :P
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
Nacho
Posts: 66
Joined: Thu Nov 07, 2013 9:25 am

Re: New core/version 0.3

Post by Nacho » Fri May 09, 2014 5:10 pm

Could you tell us a few working roms, so we can test?
Testing CEN64 on: Intel Core i5 520M 2.4 GHz. SSE2 SSE3 SSE4.1 SSE4.2 SSSE3, but no AVX. Ubuntu Linux

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core/version 0.3

Post by Snowstorm64 » Sat May 10, 2014 5:48 am

I tried some ROM. Right now, none of them is working. Wave Race is the only game that managed to give us the N64 logo. In all other cases they caused black screen, but also crash, corrupted screen or bus write/read errors.
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
Sintendo
Posts: 25
Joined: Thu Oct 31, 2013 9:11 am

Re: New core/version 0.3

Post by Sintendo » Sat May 10, 2014 6:10 am

What are the significant differences in this new version? It doesn't seem to use your ECG idea you were talking about a while ago yet.

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: New core/version 0.3

Post by beannaich » Sat May 10, 2014 11:04 am

Now that it compiles in MSVC I can build it as a static library and link it to a GTK front end :)

EDIT: God bless you for dropping the sub-module structure of the previous iteration!
EDIT2: Can't compile due to an undefined "GL_UNSIGNED_SHORT_5_5_5_1", I have the latest Nvidia drivers..

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Sat May 10, 2014 1:25 pm

Could you tell us a few working roms, so we can test?
I tried some ROM. Right now, none of them is working. Wave Race is the only game that managed to give us the N64 logo. In all other cases they caused black screen, but also crash, corrupted screen or bus write/read errors.
The fact that Wave Racer even displayed the N64 logo is quite remarkable to me.

Without any CP1 (FPU), cache, TLB, etc. emulation, I would expect all commercial ROMs to fail. Nearly all commercial ROMs require at least some CP1 emulation.

The ROMs that I'm currently testing with are PD: oman's pong, rotate, dextrose demos, etc. Even some of those (i.e., rotate) have distortions that appear because of unemulated components.
What are the significant differences in this new version? It doesn't seem to use your ECG idea you were talking about a while ago yet.
To effectively use ECG, I need to figure out how to add multi-threading. My original idea was to put each component in it's own thread (and use one thread for simple devices -- like PIF, AI, etc). In this way, ECG could have simple generated code for each thread. Each instruction could have had a check to see if there were delays, and execute it again or perform nothing that cycle as required, etc. -- elegant, simple, and fast.

But, since I haven't figured out a way to multi-thread without enormous synchronization penalties, I don't know how to effectively use ECG as each component needs to have it's own dynarec buffers. And, unfortunately, since it's a simulator, I need to cycle over every component in round-robin fashion. Which means I need to constantly jump from dynarec buffer to dynarec buffer, which is prohibitively expensive because it's all just indirect function calls.

tl;dr: ECG requires multi-threading to be used efficiently, and I haven't figured out how to multi-thread efficiently.

As for the differences: design; both from a performance and correctness/ease-of-use standpoint. I didn't have any prior N64 or MIPS experience when writing the first iteration, so decisions earlier on impacted the design in a negative way later on. The new design is also more correct (more delays are implemented). and is easier to logically verify for correctness.

Lastly, the new design has far fewer indirect branches. I've done a lot of clever tricks such as combining several MIPS instructions into one indirect function call in order to reduce the probability that a frontend stall will result on the host machine. This function, for example, is responsible for executing one of four MIPS instructions:

Code: Select all

//
// BGEZ
// BGEZL
// BLTZ
// BLTZL
//
void VR4300_BGEZ_BGEZL_BLTZ_BLTZL(
  struct vr4300 *vr4300, uint64_t rs, uint64_t unused(rt)) {
  struct vr4300_icrf_latch *icrf_latch = &vr4300->pipeline.icrf_latch;
  struct vr4300_rfex_latch *rfex_latch = &vr4300->pipeline.rfex_latch;

  uint32_t iw = rfex_latch->iw;
  uint32_t mask = vr4300_branch_lut[iw >> 17 & 0x1];
  uint64_t offset = (uint64_t) ((int16_t) iw) << 2;

  bool is_ge = iw >> 16 & 0x1;
  bool cmp = (int64_t) rs < 0;

  if (cmp == is_ge) {
    rfex_latch->iw_mask = mask;
    return;
  }

  icrf_latch->pc = rfex_latch->common.pc + (offset + 4); 
}
EDIT: God bless you for dropping the sub-module structure of the previous iteration!
EDIT2: Can't compile due to an undefined "GL_UNSIGNED_SHORT_5_5_5_1", I have the latest Nvidia drivers...
Everyone seemed vehemently opposed to the submodules, so I dropped them. :(

For the GL_UNSIGNED_SHORT_5_5_5_1 issue, it should be in the Microsoft GL headers. Can you try adding this:

#ifdef _WIN32
#define GL_UNSIGNED_SHORT_5_5_5_1 0x8034
#endif

to vi/controller.c and report back?

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: New core/version 0.3

Post by beannaich » Sat May 10, 2014 2:08 pm

MarathonMan wrote:Everyone seemed vehemently opposed to the submodules, so I dropped them. :(
They were unnecessary in my view. In theory it would be nice to instantly update to a different module if someone develops a better 'x' but in practice it never happened.
MarathonMan wrote: For the GL_UNSIGNED_SHORT_5_5_5_1 issue, it should be in the Microsoft GL headers. Can you try adding this:

#ifdef _WIN32
#define GL_UNSIGNED_SHORT_5_5_5_1 0x8034
#endif

to vi/controller.c and report back?
Of course, this fixes the compiler complaining. Is there any game that is working that uses the 5/5/5/1 scheme? I'll be able to test and see if glTexImage2D accepts it on my end. Also, I notice you're using CMake now, but I had to do some 'fun' things to get CEN64 to compile in visual studio. Would you like the solution/project files I made as well?

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Sat May 10, 2014 2:38 pm

beannaich wrote:Of course, this fixes the compiler complaining. Is there any game that is working that uses the 5/5/5/1 scheme? I'll be able to test and see if glTexImage2D accepts it on my end.
Any ROM using 16-bit output (as opposed to 32-bit). I used the same fix the prior version...
beannaich wrote:Also, I notice you're using CMake now, but I had to do some 'fun' things to get CEN64 to compile in visual studio. Would you like the solution/project files I made as well?
Can you explain what, in words, you did to the project/solution files? I'm no MSVC whiz by any means, so I'd have to hunt around if you gave me the project/solution files. But if you told me that you had to pass special compiler flags or something, I can incorporate that into the CMake system without issue.

Also, I'll probably moving away from GLFW in favor of a simple WinMain stub (at least on Windows). I'd also like to bind natively to X11/Wayland on Linux. Mac users are going to have to deal with GLFW, though, unless somebody has some time to burn. :P

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: New core/version 0.3

Post by beannaich » Sat May 10, 2014 3:06 pm

MarathonMan wrote:Any ROM using 16-bit output (as opposed to 32-bit). I used the same fix the prior version...
I'll take a look and edit this post when I get results.
MarathonMan wrote:Can you explain what, in words, you did to the project/solution files? I'm no MSVC whiz by any means, so I'd have to hunt around if you gave me the project/solution files. But if you told me that you had to pass special compiler flags or something, I can incorporate that into the CMake system without issue.
Really it was more to do with GL[FW]. I couldn't find any GL.lib file that it was expecting, but replacing that with 'opengl32.lib' worked fine. I was also having trouble with object names colliding in the output folder, but after re-generating my cmake solutions that seems to have gone away (Although I solved that issue by appending the relative file path to the output object name).

Perhaps I'm mistaken, am I supposed to have GL.lib? Because I certainly didn't.

Note for other windows developers:
CMake expects your GLFW path to be either in your path variable, or in the standard VC++ include directories. I got around this by making a system variable (C_PATH) and putting that in my build settings:

GL (include) -> $(C_PATH)\include\GL\
glfw.lib -> $(C_PATH)\lib\glfw.lib

Having a specific system variable for this is nice, because you can have your own folder in an easily accessible place to dump 3rd party libraries and headers into. And you don't have to deal with the stupid PATH variable that everyone likes to attach their crap to.

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Sat May 10, 2014 3:17 pm

beannaich wrote:Perhaps I'm mistaken, am I supposed to have GL.lib? Because I certainly didn't.
No, that's a Linux-specific thing. We have libGL.so instead of opengl32.lib. I know how to fix that, though.
beannaich wrote:Note for other windows developers:
CMake expects your GLFW path to be either in your path variable, or in the standard VC++ include directories. I got around this by making a system variable (C_PATH) and putting that in my build settings:

GL (include) -> $(C_PATH)\include\GL\
glfw.lib -> $(C_PATH)\lib\glfw.lib
OK, I'll tell CMake to hunt around for the directory with the GL headers too.

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: New core/version 0.3

Post by beannaich » Sun May 11, 2014 10:59 am

MarathonMan wrote:No, that's a Linux-specific thing. We have libGL.so instead of opengl32.lib. I know how to fix that, though.
Oh, alright then.
MarathonMan wrote:OK, I'll tell CMake to hunt around for the directory with the GL headers too.
Cool, I'll start researching the N64 and helping out when I can :)

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core/version 0.3

Post by Snowstorm64 » Mon May 12, 2014 12:00 pm

MarathonMan wrote: Also, I'll probably moving away from GLFW in favor of a simple WinMain stub (at least on Windows). I'd also like to bind natively to X11/Wayland on Linux. Mac users are going to have to deal with GLFW, though, unless somebody has some time to burn. :P
Why would you like to drop GLFW in favour of platform-specific API? I don't understand, that would mean a lot of works to do and you'd need to maintain all that code.
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Mon May 12, 2014 9:02 pm

Snowstorm64 wrote:
MarathonMan wrote:Why would you like to drop GLFW in favour of platform-specific API? I don't understand, that would mean a lot of works to do and you'd need to maintain all that code.
While I agree that it's more work, GLFW isn't all that great. Relevant bits of most of the API's (at least Windows, X11, etc.) haven't changed at all over the last decade.

I already have Windows and X11 stubs from old projects, and can just leave GLFW for those confound to the realm of Steve Jobs.

Plus, I don't see GLFW supporting Wayland anytime soon, and I'm planning to migrate soon. :D

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core/version 0.3

Post by Snowstorm64 » Tue May 13, 2014 10:01 am

Well, I'm okay with this, but...I forgot to ask you how you are going to handle CEN64's input (this is the hardest part to do, IMHO), now that GLFW is likely to be gone soon. Xinput for Windows, and udev(?) for Linux? I also hope that force feedback will be finally implemented, without GLFW. :D
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Mon May 19, 2014 9:29 am

Windows and Linux should clean checkout, build, and run (on os-interface branch).

I've switched Windows over to a pure C WinAPI, while the Unix backend is using X11 (+xf86) and pthreads.

EDIT: Problems fixed. Will merge into master shortly.

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core/version 0.3

Post by Snowstorm64 » Fri May 23, 2014 7:25 am

There is something wrong with latest commit, when I fire up CEN64, the screen resolution changes to something like 600x480 and it remains so even after I close CEN64.
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Fri May 23, 2014 9:07 am

Snowstorm64 wrote:There is something wrong with latest commit, when I fire up CEN64, the screen resolution changes to something like 600x480 and it remains so even after I close CEN64.
Whoops... fixed.

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core/version 0.3

Post by Snowstorm64 » Wed Jun 25, 2014 6:40 am

Hi MarathonMan, when do you plan to implement more DCACHE operations? I wanted to test the newest commits, but several ROMs still don't boot due to these DCACHE things...Or did I done something wrong?
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Wed Jun 25, 2014 9:03 am

The DCACHE messages that spew out are probably safe to ignore for now.

The reason why most ROMs won't boot is still CP1 (FPU). I started looking into carting over some code from the old core, but found a bug in the core that need to be fixed first.

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core/version 0.3

Post by Snowstorm64 » Thu Jun 26, 2014 4:18 pm

Oh, I understand now. Once we get rid of the FPU issue, could ROMs be bootable and playable? Or there are still more things to do at this point?
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Thu Jun 26, 2014 7:13 pm

RSP/RDP/etc. will have to be integrated, but the API for them is largely unchanged so that shouldn't take but an hour or so to merge.

Other than that, should be all set for at least a handful of commercial ROMs.

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core/version 0.3

Post by Snowstorm64 » Fri Jun 27, 2014 4:41 pm

Good. Finally a bright light comes for real, after... nearly two decades(?), in the poor, miserable N64 emulation scene, now that we have CEN64, Iconoclast's RSP & Software Video plugins and Gonetz's new GlideN64...Fun and exciting times are expecting us! :D
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
iwasaperson
Posts: 49
Joined: Tue Apr 22, 2014 12:50 am

Re: New core/version 0.3

Post by iwasaperson » Fri Jun 27, 2014 5:54 pm

It keeps crashing when I build on Windows (using CodeBlocks w/ GCC after cmake) and it shows a blank screen on Linux (using cmake & make)
I'm trying to do a release build.

I'm going to try again in Windows, but I have no idea why it's failing in Linux.

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Fri Jun 27, 2014 7:34 pm

What ROMs are you trying? As mentioned above, few work with the new core.

User avatar
iwasaperson
Posts: 49
Joined: Tue Apr 22, 2014 12:50 am

Re: New core/version 0.3

Post by iwasaperson » Sat Jun 28, 2014 12:06 am

MarathonMan wrote:What ROMs are you trying? As mentioned above, few work with the new core.
Super Mario 64 and Ocarina of Time.

EDIT: Actually, scratch that. I think it's because I'm running in VirtualBox.

"libGL error: failed to load driver: vboxvideo"

User avatar
The Extremist
Posts: 29
Joined: Sun Nov 03, 2013 6:11 pm
Location: Canadian Prairie

Re: New core/version 0.3

Post by The Extremist » Sun Jun 29, 2014 8:08 pm

Snowstorm64 wrote:and Gonetz's new GlideN64...Fun and exciting times are expecting us! :D
Speaking of that, I found this article on how the screen is drawn quite interesting. :)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Tue Jul 01, 2014 9:57 pm

Found a long standing bug I've been hunting down. :D

I can finally continue working on the FPU without worrying.

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: New core/version 0.3

Post by beannaich » Tue Jul 01, 2014 11:21 pm

MarathonMan wrote:Found a long standing bug I've been hunting down. :D

I can finally continue working on the FPU without worrying.
Reading the commit message about 'extra operations in consumers', do you think that was the cause of the odd vertical line pattern on the pre-rendered scenes in OoT? I guess only time will tell :-)

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core/version 0.3

Post by Snowstorm64 » Wed Jul 02, 2014 6:37 am

Also, could it have caused that animation delay in the OoT's Intro? Anyway, awesome news! :D
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Wed Jul 02, 2014 9:36 am

I'm not sure... this is one part of the core that was completely redesigned, to the point where it doesn't look much like the old one at all.

In the old core, I had a set of read/write functions for every type of data access on the sending and receiving end for every component attached to the bus. The idea was to use specialized code paths for everything in order to reduce the amount of execution overhead. But it turned out to be 'too much of a good thing'.

Now, accesses are strictly be 32-bit. Oddly-aligned or -sized accesses are completed with a mask and shifts. The upside to this is that the host CPU no longer has to predict or cache the instructions for every single type of access (which, just to name the loads... LBU, LB, LHU, LH, LW, LWU, LD, LWL/R, LDL/R, LWC0/1, LDC0/1). Each access takes the same path in the memory system, and only incurs a slight static overhead vs. what specialized code paths could offer.

User avatar
iwasaperson
Posts: 49
Joined: Tue Apr 22, 2014 12:50 am

Re: New core/version 0.3

Post by iwasaperson » Wed Jul 02, 2014 10:59 pm

Installed native Linux. Now it runs, but there is no picture. I really want to see it since it's reporting ~56 VI/s.
Tried with Majora's Mask, Super Mario 64, and Ocarina of Time.

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Wed Jul 02, 2014 11:15 pm

iwasaperson wrote:Installed native Linux. Now it runs, but there is no picture. I really want to see it since it's reporting ~56 VI/s.
Tried with Majora's Mask, Super Mario 64, and Ocarina of Time.
If you want commercial ROMs to run (of which, all three of those do), you'll have to run using the old core:
https://github.com/tj90241/cen64

Make sure you checkout the next-version branch, which corresponds to v0.2. Precompiled binaries for windows are available under the 'Downloads' section of the forums. Debian-based derivatives of Linux should build the old core cleanly with a minimal set of packages installed (build-essential, libglfw-dev, libopenal-dev, ???).

The new core found on git.cen64.com is a complete from-scratch rewrite that I started after ~1.5 years of the "old" CEN64 core. I'm just starting to get FPU support into the new core now... maybe I'll be able to run commercial ROMs on the new core in the coming week(s).

Code: Select all

Unimplemented DCACHE operation: 4
Unimplemented instruction: TLBWI [0x42000002] @ 0xFFFFFFFF802031F8
Unimplemented instruction: CP1_CVT_S [0x46800020] @ 0xFFFFFFFF802001A4

User avatar
iwasaperson
Posts: 49
Joined: Tue Apr 22, 2014 12:50 am

Re: New core/version 0.3

Post by iwasaperson » Thu Jul 03, 2014 1:58 pm

Sorry. I didn't realize just how early in development the new core is.

User avatar
Narann
Posts: 154
Joined: Mon Jun 16, 2014 4:25 pm
Contact:

Re: New core/version 0.3

Post by Narann » Thu Jul 03, 2014 5:30 pm

Hi MarathonMan, what did you pushed to restart the code from scratch? I'm just curious. :)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Fri Jul 04, 2014 2:18 pm

Narann wrote:Hi MarathonMan, what did you pushed to restart the code from scratch? I'm just curious. :)
Accuracy and design, mostly. I had not former experience in developing an emulator and made some poor choices early on that hurt me later.

Some preliminary CP1 support working now... tests done using krom's CP1 test ROMs... thanks, kromy!
Attachments
cp1cvt.png
cp1cvt.png (21.89 KiB) Viewed 22035 times

User avatar
Narann
Posts: 154
Joined: Mon Jun 16, 2014 4:25 pm
Contact:

Re: New core/version 0.3

Post by Narann » Fri Jul 04, 2014 3:09 pm

Thanks for the answer! :)

I didn't know such "accuracy testing roms" exists. Cool!

Keep the good work, it worth it thrust me. :)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Sat Jul 05, 2014 8:53 am

LaC's fire ROM.

The "flickering" issue that always occurred in the old CEN64 is now absent! :D
Attachments
lac-fire.png
lac-fire.png (7.49 KiB) Viewed 21977 times

User avatar
juef
Posts: 31
Joined: Sun Oct 27, 2013 10:19 pm

Re: New core/version 0.3

Post by juef » Sat Jul 05, 2014 9:35 am

Wow, things are progressing quite nicely! :D

beannaich
Posts: 149
Joined: Mon Oct 21, 2013 2:43 pm

Re: New core/version 0.3

Post by beannaich » Sat Jul 05, 2014 9:39 am

Very nice :)

Any of marshallh's ROMs booting? If I remember right, he put a lot of emulator checks in his stuff so it only runs on hardware.

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core/version 0.3

Post by Snowstorm64 » Sat Jul 05, 2014 9:43 am

True, this "flickering" thing is now gone. Now it does work perfectly. But, this new core is slower than the old core....I guess it is lacking optimizations because all the work was focused only in the rewriting of the core?
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Sat Jul 05, 2014 9:51 am

Snowstorm64 wrote:True, this "flickering" thing is now gone. Now it does work perfectly. But, this new core is slower than the old core....I guess it is lacking optimizations because all the work was focused only in the rewriting of the core?
I thought it was slower too, but the VI/s output (currently disabled... oops) indicates otherwise.

I'll have to try the ROM on my actual console when I get the chance. MAME plays the fire demo very fast, as did the "old" core if you actually got it to run at 60 VI/s.

However, I stumbled upon this:
http://www.youtube.com/watch?v=GorA2bDiH5c

So... we'll see. :D

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: New core/version 0.3

Post by Snowstorm64 » Sat Jul 05, 2014 10:42 am

That's interesting, I confronted that video and LaC's fire demo on this PC, and looks like both are running more or less at same speed. And if Hacktarux's statement, on the fact that the demo, or better, the video was running at full speed, is true, then the old core was emulating inaccurately the demo, aside from that bug.
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
Narann
Posts: 154
Joined: Mon Jun 16, 2014 4:25 pm
Contact:

Re: New core/version 0.3

Post by Narann » Sat Jul 05, 2014 9:55 pm

I think more we will see accuracy on the N64 scene, more their will be a need to have videos with this kind of roms running on real hardware + a timewatch to help everybody to check.

Great work! Things are coming smoothly. :D

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Sun Jul 06, 2014 9:53 am

beannaich wrote:Any of marshallh's ROMs booting? If I remember right, he put a lot of emulator checks in his stuff so it only runs on hardware.
The MGC demo with the ROM checks requires RSP/RDP support.
Narann wrote:I think more we will see accuracy on the N64 scene, more their will be a need to have videos with this kind of roms running on real hardware.
videos => capture cards!

krom
Posts: 72
Joined: Sat Oct 05, 2013 2:19 am

Re: New core/version 0.3

Post by krom » Sun Jul 06, 2014 1:01 pm

Great Work MarathonMan, Fire Demo is looking really great =D
Narann wrote:I didn't know such "accuracy testing roms" exists. Cool!
Hi Narann, I created these CP1/FPU test ROM's especially for cen64, so they are quite new =D

User avatar
Narann
Posts: 154
Joined: Mon Jun 16, 2014 4:25 pm
Contact:

Re: New core/version 0.3

Post by Narann » Sun Jul 06, 2014 3:02 pm

MarathonMan wrote:videos => capture cards!
Maybe, I would say we need to capture them with a hand started time watch to be sure about timing accuracy. :D
If we capture them with a capture cards, you lost the timewatch that. A capture cart is maybe not such time accurate. :D
krom wrote:Hi Narann, I created these CP1/FPU test ROM's especially for cen64, so they are quite new =D
So the N64 scene is also here! Great to hear! :)
I guess such roms are brilliant for accuracy emulator. :)

And while I'm here, just a humble question: Why did you create this forum? Maybe you don't know it (or don't care) but the N64 scene is spreaded (unfortunately) and there is not a big community (I guess emutalk and PJ64 forums are the "biggest" one). So it could have been great to stay on emutalk no? :) No offense here, I just want to understand. :)

User avatar
MarathonMan
Site Admin
Posts: 692
Joined: Fri Oct 04, 2013 4:49 pm

Re: New core/version 0.3

Post by MarathonMan » Mon Jul 07, 2014 9:37 am

It'd probably be best served in another topic, but:
  • IMO CEN64 is really the only (publicly released) emulator focused on cycle-accuracy. Emulators aren't cutting it anymore and we have the computing horsepower! Even Nintendo's own "official" emulators in the VC/Wii Store have some timing issues: http://www.youtube.com/watch?v=koi9B3VRfqo
  • At the time this website was created (coming up on one year ago in a few months), I wasn't a moderator or anything at emutalk -- just had a 100+ page thread. It seemed kind of unwieldy, there were a lot of repeat questions, what have you.
  • I have a lot of plans for CEN64 that will require my own hosting space. Automating builds every time a git push occurs (and making the binaries public), adding discussion topics for hardware/FPGA-based implementations of CEN64, etc.
Ultimately, a supreme goal of this website would be to attract a developer community. I've gotten a lot of various patches from krom and others, but I've always wanted to create a "dream team" similar to the PJ64 1.6-era.

Locked

Who is online

Users browsing this forum: No registered users and 0 guests