n64dev / cen64 Goto Github PK

The JPEG μcode appears to be broken.

The MAME RDP aliases pointers (for RDRAM) from the uint32_t that CEN64 uses throughput to uint8_t and uint16_t.

Relevant files should be compiled with -fno-strict-aliasing...

a minor issue but FMVs appear in a bar on the screen

Alright, so I tried the latest builds available on the cen64.com website because I figured they would be more reliable then if I tried to compile them myself.

When I launch the debugger, it works fine. The debugger comes up.

When I launch the other builds (all 64-bit by the way), I get an error message typical of having outdated runtimes.

cen64-win64-[cpu instruction]-latest.exe - Application Error

The application was unable to start correctly (0xc000007b). Click OK to close the application.

OK

I had to put the OpenAL32.dll in the directory to get it to get this far, could I have a different version then I am supposed to have?

I don't know, I've tried everything I can think of.

Any ideas would be great.

After installing the latest OpenAL installer, now it just doesn't open. Any thoughts? I have tried running from a command prompt as well as just running the executable...

I am running 64-bit Windows 7 Ultimate SP1 (fully updated).

This may be worth mentioning, I have all the Visual C++ runtimes installed (32-bit and 64-bit).

cen64 compiled with: SSSE3
Your CPU supports: SSE4.1
I compiled it on Linux 4.14.15-1-ARCH
with gcc (GCC) 7.2.1 20180116

mkdir build
cmake ..
make
./cen64

model name : Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm pti retpoline tpr_shadow vnmi flexpriority ept vpid dtherm ida

There seems to be 4 controllers connected by default. I'm not sure if this is intentional or not, but it should at least be configurable.

(The above screenshot is for showing that a controller is connected to each of the 4 ports. The text happens to indicate that an error has occurred, but that is the correct behavior.)

When trying to start most roms I encounter Unknown CIC type; is this a byte-swapped ROM?. What does this mean? These roms start correctly for other n64 emulators. Are there any other details I can provide to help debug this? Potentially .z64 roms work more often than .n64 or .v64.

For example these start.

Kirby 64.v64
Legend of Zelda, The - Majora's Mask (U) [!].z64
Ogre Battle 64 - Person of Lordly Caliber (J) (V1.1) [!].z64

These don't start

Super Smash Bros. (USA).n64
Starfox 64.v64
Zelda OoT 64.v64

Using NTSC USA 8.7 final ROM. Perfect Dark does not detect the expansion pak, and thus the single-player campaign is missing.

This is a known bug.

#n64dev discuss.

Curious.. No compiling from your source ? Can't find it.

This has been bugging me and my mild OCD for a while. It is an emulator! Be proud it is so great as such! I think some people are put off by simulator as it sounds fake or something.

Not just in the text files either. Also check CEN64.com, git.CEN64.com, GitHub, and any other sites or places CEN64 is mentioned that the contributors own.

Should be an easy fix, it just requires a full clear for each frame.

I followed the readme as closely as possible, didn't change any of mingw's install options, and placed libglfw.a in the root of the git tree as instructed. include/GL/glfw.h is also in its correct spot, as far as I can tell.

Here is the build output:
https://gist.github.com/thedax/1d4fdfe2f8be2894d09b

Did I miss something?

In Majora's Mask (USA version), if you start a new game, you immediately die after the initial cutscene, which should not happen.
After death, you respawn. Your sword and shield are missing (they should be there), and you have three ocarinas as your C-buttons (you should have nothing in those slots.)
I'm also pretty sure three hearts should be displayed in the top-left of the screen, but no hearts are displayed in this scene.

Here is a screenshot of the bug in action (after you've died/respawned).

This bug occurred on Linux 64-bit, specifically the debian testing branch.
System is a AMD Threadripper 1950X with RX 580 GPU, using mesa open-source drivers (version 17.3.1, latest release at the time of writing.)

As an extra note that may be more difficult to investigate/confirm: It's hard to tell with the audio somewhat choppy, but I also think the echo effect in Skull Kid's laugh during the initial cutscene may not be reproduced correctly, either. (Reminds me of an old citra bug when playing Majora's Mask 3D earlier on in citra's development.)

welcome.z64 is a ROM which displays a short, live-action video. cen64 can run this ROM, but the video output is wrong. The display is filled with block of primary colors:

The picture should look something like this (taken from the source video):

During compilation, I get a no such file error for tlb.h

D:/Downloads/cen64-angrylion/vr4300/cp0.h:14:21: fatal error: tlb/tlb.h: No such file or directory
 #include "tlb/tlb.h"
                     ^
compilation terminated.
mingw32-make.exe[2]: *** [CMakeFiles/cen64.dir/ai/controller.c.obj] Error 1
mingw32-make.exe[1]: *** [CMakeFiles/cen64.dir/all] Error 2
mingw32-make.exe: *** [all] Error 2
CMakeFiles\cen64.dir\build.make:87: recipe for target 'CMakeFiles/cen64.dir/ai/controller.c.obj' failed
mingw32-make.exe[2]: Leaving directory 'D:/Downloads/cen64-angrylion/mingw-build'
CMakeFiles\Makefile2:66: recipe for target 'CMakeFiles/cen64.dir/all' failed
mingw32-make.exe[1]: Leaving directory 'D:/Downloads/cen64-angrylion/mingw-build'
D:/Downloads/cen64-angrylion/mingw-build/Makefile:82: recipe for target 'all' failed

That's because "tlb/tlb.h" is in directory arch/x86_64.

Clicking the X on the window does not make cen64 quit when using the multithreading branch.

I'm not sure if you already know this or not but with the current master (commit 98d3ae9) built on Linux, playing any game with an unmodified MAME-compatible PIF ROM (pifdata.bin, sha1sum 9174eadc0f0ea2654c95fd941406ab46b9dc9bdd) results in

Unimplemented instruction: INVALID [0x00000000] @ 0x00000000

being printed repeatedly to the terminal, with games not booting.

Byte-swapping the PIF ROM gets rid of the errors, but games still won't boot.

I tested this with both Super Mario 64 and Ocarina of Time, both byte-swapped and not; cen64 rejected the byte-swapped versions, so that part still works...

This is Ubuntu GNOME 15.10 64-bit on an AMD A6-6310 APU with AMD Radeon R4 Graphics CPU and mesa for graphics. Build was done with mkdir _build; cd _build; cmake ..; make. Execution was done by cding into the directory with the ROMs and running cen64 via absolute path.

Thanks.

According to loganmc10, it's caused by unaligned PI DMA access, see here for more details. Although the case is for Project64 and mupen64plus, it may be relevant for CEN64 too, as you can see in the image attached here above.

I opened cen64-Qt and go to preferences>ROM Directories and find rom files in ROM folder. And it didn't showing up on cen64-Qt's list so I have to click OPEN ROM and find it and it's running ok. Why are ROMS not on cen64-Qt list ?

I'm interested in implementing a debugger, although I'm not 100% sure what that'd entail. I see the QT skeleton for a debugger UI. I don't really care what the UI (or cli) is. The first thing I'd like to be able to do is to set breakpoints and inspect registers/variables/etc.

I'm going to start looking into this, but any pointers are very much appreciated :)

During the opening sequence of a new game in Paper Mario, Mario's textures looks glitched.

Not too many frames later and the game experiences a TLB exception it can't handle. Fortunately, the game appears to have a nice built-in error screen with some useful info.

Most commonly, the PC is 802dcf0c, but not always. The culprit instruction at 802dcf0c was lw v0, 0x0(s1). Looking at the value of s1 in other N64 emulators, I never see anything outside of the 0x803XXXXX range.

I compiled the nu5 example from the development kit. It works on hardware with an Everdrive but if I try to run it in Cen64 I get the unknown CIC type error. The output of the compilation is a .n64 file but I checked and it's not actually byte-swapped. Would it be a legal issue to upload the rom here?

When attempting to open CEN64 with openAL32.dll from the CEN64 website downloaded, CEN64 still does not open.

Can have multiple TLB entries that map to the same address, only one being valid. Right now, we return the first one we find (valid or not) during lookup.

mkdir build
cd build
cmake ../
make

from /home/linaro/Desktop/cen64/ai/controller.c:18:
/home/linaro/Desktop/cen64/vr4300/cp0.h:14:21: fatal error: tlb/tlb.h: No such file or directory
 #include "tlb/tlb.h"

I checked, and arch/arm/tlb folder and files are missing

The PAL version of GoldenEye does not respond to controller input. Changing the PIF boot ROM to the PAL version does not change anything. I haven't tried many other games, but at least PAL Super Mario 64 seems to work correctly.

It just sits at a white screen.

It may be related to this issue:

mupen64plus/mupen64plus-core#221

(this game doesn't work in mupen64plus either, but works in Project64 and 1964)

Hey,

I'm developing a small game and I use rand() to initialize the start position of my game.

And I always get the same sequence returned by rand(), I'm currently using srand(timer_ticks() & 0x7FFFFFFF); in my main. BUT even if I do srand(1234); compile the rom and then change the code to srand(5678); and compile again, both roms produce the exact same output for rand()

This implies that my seed is not the issue, but rather than rand doesn't work at all here.

OS: Slackware-current
gcc-5.3.0-i586-3

To see if issue #41 was restricted to x86_64 or not I tried to build cen64 again in a clean Slackware64-current chroot, the issue persisted. So I tried again in a Slackware-current chroot (x86) and ran into a new issue...

Build.

mkdir -p build
cd build
  cmake \
    -DCMAKE_C_FLAGS:STRING="-O2 -march=i486 -mtune=i686" \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DCMAKE_BUILD_TYPE=Release ..
  make
  make install DESTDIR=$PKG
cd ..

Error.
Full log - http://pastebin.com/JgwG1qu1

CMakeFiles/cen64.dir/build.make:254: recipe for target 'CMakeFiles/cen64.dir/bus/controller.c.o' failed
make[2]: *** [CMakeFiles/cen64.dir/bus/controller.c.o] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/cen64.dir/all' failed
make[1]: *** [CMakeFiles/cen64.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

Don't know if this is the place to report an issue or not, but Banjo Kazooie plays the opening sound and the screen is supposed to open from the center, but it just stays this way. No logs or anything.

Is there a way to debug or find out further info about CEN64 and this game?

Hey, I'm not sure if you want these kinds of reports at the moment due to this emulator appearing to be relatively early in development, but so far this has been the only game I've tried that hasn't been able to start.
The emulator just shows a black screen without any audio with every version of cen64 I've tried (including the latest commit).

In the angrylion-rdp-sse branch, Mario's power meter looks wrong: the bottom half is incorrectly shown as a copy of the top half. git bisect fingered 72ce1e0 as the guilty commit.

I just built the project with GCC, all worked fine, and I got my CEN64 binary. However, if I run $ make CC=clang then the build fails during linking, with complaints about unresolved references. I tried attaching the build log as a file, but apparently you can only do that if you have write access to the repo. So here is a link instead. This was with the HEAD of the angrylion-rdp branch.

Everytime I try to load a ROM I get the following error.

Compiled error: Expected '(' on line 1 in /home/abc/pif/pifdata.bin

I've never used this emulator before. Is there something wrong with my settings? I do have the pifdata.bin file as well as the 64ddipl.bin file. I'm on Arch Linux 64bit using the latest git build.

I'm using the latest version of clang shipped by Apple for Mac OS X 10.8.3 (Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)). Here is the error I'm getting:

Building: libvideo
Compiling: video/Controller.c
clang: warning: unknown warning option '-Wunsafe-loop-optimizations'; did you mean '-Wout-of-line-declaration'?
clang: warning: argument unused during compilation: '-fwhole-program'
clang: warning: argument unused during compilation: '-fuse-linker-plugin'
clang: warning: argument unused during compilation: '-funsafe-loop-optimizations'
warning: unknown warning option '-Wunsafe-loop-optimizations'; did you mean '-Wout-of-line-declaration'? [-Wunknown-warning-option]
Controller.c:92:12: error: use of undeclared identifier 'GL_TEXTURE_RECTANGLE'
glEnable(GL_TEXTURE_RECTANGLE);
^
Controller.c:94:17: error: use of undeclared identifier 'GL_TEXTURE_RECTANGLE'
glBindTexture(GL_TEXTURE_RECTANGLE, controller->frameTexture);
^
1 warning and 2 errors generated.
make[1]: *** [Objects/Controller.o] Error 1
make: *** [libvideo] Error 2

Also, I noticed that GLFW needed to be installed to compile, you might include that in your compilation instructions.

Thanks!

When -novideo or -headless options are used, the cen64_gl_window_thread() call is not made, so device->running = false occurs in cen64.c after only about 200 cycles are processed in device_run().

OS: Slackware64-current
gcc-5.3.0_multilib-x86_64-3alien

I am building cen64 like this.

mkdir -p build
cd build
  cmake \
    -DCMAKE_C_FLAGS:STRING="-O2 -fPIC" \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DCMAKE_BUILD_TYPE=Release ..
  make
  make install DESTDIR=$PKG
cd ..

The error.
Full log - http://pastebin.com/8XrySxm2

collect2: error: ld returned 1 exit status
CMakeFiles/cen64.dir/build.make:1761: recipe for target 'cen64' failed
make[2]: *** [cen64] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/cen64.dir/all' failed
make[1]: *** [CMakeFiles/cen64.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2

OS: Linux Sabayon, X64

When I try to make, I get the following output: (I always use -j4. It makes Make make faster 😄)

$ make -j4
[  1%] Linking C executable cen64
CMakeFiles/cen64.dir/pi/is_viewer.c.o: In function `is_viewer_init':
/home/user/misc/Other/Other/cen64/pi/is_viewer.c:21: undefined reference to `libiconv_open'
CMakeFiles/cen64.dir/pi/is_viewer.c.o: In function `write_is_viewer':
/home/user/misc/Other/Other/cen64/pi/is_viewer.c:62: undefined reference to `libiconv'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/cen64.dir/build.make:1814: cen64] Error 1
make[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/cen64.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

lui $0x8000, $at
sw $zero, -0x4($at)

Will result in $zero -> 0xFFFF_FFFF_7FFF_FFFF right now.

Make sure this is happening.

I have heard from a few people that when they try the supposed NTSC or PAL PIFROM dumps they don't work, only producing a black screen that goes nowhere (with any ROM).

I have tried as well, but CEN64 barely runs on my system anyway...

I would link to the dumps, but I think that may be frowned upon. 👎

They are put together and called pifrom.zip. Here are the hashes of the files:

NTSC PIFROM (file name is pifntsc.raw):
CRC32: 68DC7BF8
MD5: F92D467ABAFA081CEAD170918FD32883
SHA-1: 3A23E4CCCCA2CAD62A83EEA8519C7184FE1F7BE2

PAL PIFROM (file name is pifpal.raw):
CRC32: 2AE77E68
MD5: 2B6EEC586FAA43F3462333B844834554
SHA-1: 46CAE59D31F9298B93F3380879454FCEF54EE6CC

The zip file has these hashes:
CRC32: D0C2D468
MD5: BACE7A31EADDECCB0345500291379720
SHA-1: 75209ED921D62F01FBE0C29B32280BF0BF476C1D

Both the two dumps listed here and the dump of the Japanese PIFROM are 4096 bytes.

Looking at the PAL PIFROM dump in a hex editor, it looks very similar to the Japanese PIFROM.

The NTSC PIFROM looks very different, though. Does anybody know anything about either of these two dumps, or anything else about what I am experiencing? Something seems off...

Anyway, any information or assistance would be much appreciated.

Hi! As much as I love the accuracy of cen64, it's really hard to play N64 games seriously without an analog stick.
The file in os/common/input.c shows how cen64 does input, and it seems pretty straightforward. The common strategy for gamepad input is using sdl2, but because the project doesn't currently require SDL2 it might seem like a bit of a waste to only include it for gamepad input. What do you think?

@sp1187 found this - looks like I broke it in 888d4d.

Is there any reason older SIMD extensions are preferred to newer ones?

Currently:

    if (${CEN64_ARCH_SUPPORT} MATCHES "SSE2")
        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -msse2")
    elseif (${CEN64_ARCH_SUPPORT} MATCHES "SSSE3")
        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mssse3")
    elseif (${CEN64_ARCH_SUPPORT} MATCHES "SSE3")
        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -msse3")
    elseif (${CEN64_ARCH_SUPPORT} MATCHES "SSE4.1")
        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -msse4")
    elseif (${CEN64_ARCH_SUPPORT} MATCHES "AVX")
        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mavx")
    endif ()

As opposed to:

    if (${CEN64_ARCH_SUPPORT} MATCHES "AVX")
        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mavx")
    elseif (${CEN64_ARCH_SUPPORT} MATCHES "SSE4.1")
        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -msse4")
    elseif (${CEN64_ARCH_SUPPORT} MATCHES "SSSE3")
        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mssse3")
    elseif (${CEN64_ARCH_SUPPORT} MATCHES "SSE3")
        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -msse3")
    elseif (${CEN64_ARCH_SUPPORT} MATCHES "SSSE2")
        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -msse2")
    endif ()

If -noaudio flag used, OpenAL is not initialized (as expected), but later on ai_dma() will still make OpenAL library calls for buffer manipulation. I'll submit a PR, just using this issue to track.

it seems I'm no longer able to launch the latest build bot windows build through the command line or front end. I'm going to test on ubuntu later.

Hi,

I am wondering if you have considered porting your cen64 emulator over to the libretro api before? It may be more work at first, but eventually would free up your time from working on any interface and frontends to being able to dedicate your time to solely to working on the core emulator. Additionally it could make it easier for any libretro developers to contribute to cen64 or vica versa and would attract potentially far more users / bug testers.

https://github.com/libretro

Thanks for considering at least. :)

I have a five-year old CPU that supports up to SSE3 and i'm using Debian GNU/Linux sid. However, with this actual source code I cannot build CEN64, because gcc prints this error:

In file included from TCLod.c:17:0:
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/smmintrin.h:31:3: error: #error "SSE4.1 instruction set not enabled"
 # error "SSE4.1 instruction set not enabled"
   ^
TCLod.c: In function ‘tclod_1cycle_current_simple’:
TCLod.c:57:3: error: unknown type name ‘__m128i’
   __m128i stw;
   ^
TCLod.c:58:3: error: unknown type name ‘__m128i’
   __m128i dincstw;
   ^
TCLod.c:59:3: error: unknown type name ‘__m128i’
   __m128i nextstw;
   ^
TCLod.c:60:3: error: unknown type name ‘__m128i’
   __m128i farstw;
   ^
TCLod.c:62:3: warning: implicit declaration of function ‘_mm_load_si128’ [-Wimplicit-function-declaration]
   stw = _mm_load_si128((__m128i*) spanptr);
   ^
TCLod.c:62:25: error: ‘__m128i’ undeclared (first use in this function)
   stw = _mm_load_si128((__m128i*) spanptr);
                         ^
TCLod.c:62:25: note: each undeclared identifier is reported only once for each function it appears in
TCLod.c:62:33: error: expected expression before ‘)’ token
   stw = _mm_load_si128((__m128i*) spanptr);
                                 ^
TCLod.c:63:37: error: expected expression before ‘)’ token
   dincstw = _mm_load_si128((__m128i*) dincs);
                                     ^
TCLod.c:72:7: warning: implicit declaration of function ‘_mm_add_epi32’ [-Wimplicit-function-declaration]
       nextstw = _mm_add_epi32(stw, dincstw);
       ^
TCLod.c:73:7: warning: implicit declaration of function ‘_mm_srai_epi32’ [-Wimplicit-function-declaration]
       nextstw = _mm_srai_epi32(nextstw, 16);
       ^
TCLod.c:77:9: warning: implicit declaration of function ‘_mm_slli_epi32’ [-Wimplicit-function-declaration]
         farstw = _mm_slli_epi32(dincstw, 1);
         ^
TCLod.c:83:9: warning: implicit declaration of function ‘_mm_sub_epi32’ [-Wimplicit-function-declaration]
         farstw = _mm_sub_epi32(stw, dincstw);
         ^
TCLod.c:89:15: error: expected ‘;’ before ‘temp’
       __m128i temp = _mm_loadu_si128((__m128i*) &span[nextscan].s);
               ^
TCLod.c:91:32: error: ‘temp’ undeclared (first use in this function)
       nextstw = _mm_srai_epi32(temp, 16);
                                ^
TCLod.c:106:3: warning: implicit declaration of function ‘_mm_store_si128’ [-Wimplicit-function-declaration]
   _mm_store_si128((__m128i*) nextstwtemp, nextstw);
   ^
TCLod.c:106:28: error: expected expression before ‘)’ token
   _mm_store_si128((__m128i*) nextstwtemp, nextstw);
                            ^
TCLod.c:107:28: error: expected expression before ‘)’ token
   _mm_store_si128((__m128i*) farstwtemp, farstw);
                            ^
make[1]: *** [Objects/TCLod.o] Error 1
make: *** [librdp] Error 2

Looks like the culprit is rdp/TCLod.c, because there aren't conditions to define if the CPU supports SSE4.1 or not.

#include <smmintrin.h>

I tried to replace smmintrin.h into tmmintrin.h, and CEN64's compilation completes successfully.

I am on Fedora 23 x64 with an Intel Sandybridge. I tried building from SS2 to AVX with same results. I just get a black screen and a lot of these :

./cen64 pifdata.bin Super\ Mario\ 64\ \(U\)\ \[\!\].z64 
Unimplemented instruction: INVALID [0x00000000] @ 0x00000000
Unimplemented instruction: INVALID [0x00000000] @ 0x00000000
Unimplemented instruction: INVALID [0x00000000] @ 0x00000000
Unimplemented instruction: INVALID [0x00000000] @ 0x00000000
Unimplemented instruction: INVALID [0x00000000] @ 0x00000000
Unimplemented instruction: INVALID [0x00000000] @ 0x00000000
Unimplemented instruction: INVALID [0x00000000] @ 0x00000000
Unimplemented instruction: INVALID [0x00000000] @ 0x00000000