Announcement: Cycle-accurate N64 development underway.

[Nintendo Maniac]

To nab a PIF legally you need either some uncommon hardware or a method of slowing down the console and stepping through instructions. Decapping is lethal to the chip but would work too.

It's that involved? Then how the heck does seemingly so many people on here have said PIF?

 

[Zuzma]

We stole the pif rom from the internets navy, yar har har. : 3

 

[MarathonMan]

I compiled without the "MMAP_ROM_IMAGE" flag because it would not compile otherwise.

Could you perhaps take a peak at the current master branch? I've fixed up the entire build system to be Windows-friendly, but I seem to get the dreaded "this program has stopped working" error when it starts.

It looks like it could be glfw related; I'm not sure. It seems to die around initializing the VIF.

 

[Nintendo Maniac]

...wait a minute, is "pifdata.bin" the same thing? Cause that's what MESS uses, and there's WAY more information on the internet for that.


EDIT: Darn, I don't think it is the same thing... I keep getting "cen64.exe has stopped working" whenever I try to launch Mario Kart 64 in z64 format.

Here's the hash of my pifdata.bin, can anyone confirm/deny if it's the correct file?

MD5: 4921d5f2165dee6e2496f4388c4c81da
SHA-1: 9174eadc0f0ea2654c95fd941406ab46b9dc9bdd

 

[MarathonMan]

...wait a minute, is "pifdata.bin" the same thing? Cause that's what MESS uses, and there's WAY more information on the internet for that.


EDIT: Darn, I don't think it is the same thing... I keep getting "cen64.exe has stopped working" whenever I try to launch Mario Kart 64 in z64 format.

Here's the hash of my pifdata.bin, can anyone confirm/deny if it's the correct file?

MD5: 4921d5f2165dee6e2496f4388c4c81da
SHA-1: 9174eadc0f0ea2654c95fd941406ab46b9dc9bdd

$ md5sum .../n64/cen64/data/pifrom.bin
4921d5f2165dee6e2496f4388c4c81da .../n64/cen64/data/pifrom.bin

 

[Nintendo Maniac]

Ah ha, it IS the same file!

...so why doesn't it work?

In other news, may I suggest renaming it to "pifdata.bin" in CEN64? This would then be consistent with MESS and then people (like me) wouldn't think that it's a different file. Heck I was reading "pifrom" as 'pi-from' until people like zoinkity started calling it just by "PIF", and even then I didn't quite know why he was calling the 'PiFrom' that until some googling for 'PIF N64' made be realize that pifrom = PifRom (not PiFrom!) = MESS's pifdata.bin


EDIT: My PC hardware/software:
Windows 7 SP1 x64
Phenom II 920
integrated Radeon HD 4200 w/ Catalyst 13.1

EDIT 2: Just plugged in my discrete Geforce 8800GS w/ drivers v285.62 but I just get the same result.

EDIT 3: For lulz I tried it on my XP SP3 partition and it didn't even work at all, it says it's not a valid Win32 application. I'm assuming it's a 64bit executable?

 

[ShadowFX]

Confirmed, my pifdata file has MD5: 4921d5f2165dee6e2496f4388c4c81da
Will test some more later.

 

[MarathonMan]

I ironed out all the issues with Windows builds. It's now completely scripted to the point where you should be able to checkout and build CEN64 even if you have no prior programming experience.

If some of you were unable to load CEN64 before, it was because my build optimizations are highly aggressive and target the host processor as best as possible. If you try to give someone else a binary, it's likely that the binary won't work on their system if their system is older.

I also patched the Windows ROM loading process, so there shouldn't be any more ROM load problems.

Anyways, to build:

Download and unpack all the relevant files (this kind of sucks without git; I apologize), install the tools (see below), and double click the windows/release.cmd file (or release/debug.cmd file if you're adventurous). This will compile CEN64 will all of the optimizations, bells, and whistles that I've intended to pass on at the current point in time. The README on github should be clear -- it's really an easy process.

-----

Installing the tools:

Do these next steps only once. After you install these things, you can just download CEN64 from github as often as you'd like and rebuild.

Download the latest version mingw64 (x64), here: http://sourceforge.net/projects/mingwbuilds/files/latest/download
After installation, update your system path so that it includes the mingw64\bin directory (Google if you don't know how).

Obtain GLFW2 libraries and headers, here:
http://sourceforge.net/projects/glfw/files/glfw/2.7.9/glfw-2.7.9.bin.WIN64.zip/download
Copy the "include" directory and "lib-mingw/libglfw.a" file into the top-level (i.e., CEN64) directory. Nothing more, nothing less.

Each time you want to build, just double-click on a script in the "windows" directory.

 

[Nintendo Maniac]

it's likely that the binary won't work on their system if their system is older.

Insert image macro here!
*upgrades from Athlon 64 x2 4800+ to Phenom II x4 920*
*PC gets called "old" two days later*


Anyway, if it's optimized on compile, I supposed this would be one of the rare cases where a program really should use an installer and essentially compile it during installation.

By comparison, some other programs that use an installer are relatively small and simple yet said application is completely portable... *cough*post-v1.6-Project64*cough*


EDIT:

update your system path so that it includes the mingw64\bin directory (Google if you don't know how).

This is too ambiguous for me to be able to use Google for help. "update your system path"? My system path is C:\Windows\system or alternatively C:\Windows\system32 - just like every other Windows installation. I can't google how to do something if I don't even know what it is I'm supposed to google for.

"What choo talkin 'bout Willis?"

 

[Durza007]

I ironed out all the issues with Windows builds. It's now completely scripted to the point where you should be able to checkout and build CEN64 even if you have no prior programming experience.

If some of you were unable to load CEN64 before, it was because my build optimizations are highly aggressive and target the host processor as best as possible. If you try to give someone else a binary, it's likely that the binary won't work on their system if their system is older.

I also patched the Windows ROM loading process, so there shouldn't be any more ROM load problems.

Anyways, to build:

Download and unpack all the relevant files (this kind of sucks without git; I apologize), install the tools (see below), and double click the windows/release.cmd file (or release/debug.cmd file if you're adventurous). This will compile CEN64 will all of the optimizations, bells, and whistles that I've intended to pass on at the current point in time. The README on github should be clear -- it's really an easy process.

-----

Installing the tools:

Do these next steps only once. After you install these things, you can just download CEN64 from github as often as you'd like and rebuild.

Download the latest version mingw64 (x64), here: http://sourceforge.net/projects/mingwbuilds/files/latest/download
After installation, update your system path so that it includes the mingw64\bin directory (Google if you don't know how).

Obtain GLFW2 libraries and headers, here:
http://sourceforge.net/projects/glfw/files/glfw/2.7.9/glfw-2.7.9.bin.WIN64.zip/download
Copy the "include" directory and "lib-mingw/libglfw.a" file into the top-level (i.e., CEN64) directory. Nothing more, nothing less.

Each time you want to build, just double-click on a script in the "windows" directory.

I tried running the the script and I got:

/usr/bin/sh: -c: line 1: syntax error: unexpected end of file
mingw32-make: *** [Objects\CEN64.o] Error 1

There could be some problems with my mingw install so I tried running the installer you linked. It failed immediately with the
message "Cannot download repository.txt". I guess they might have some temporary server problems or something.
Anyway, I will keep trying to figure out whats wrong.

EDIT: Well this is awkward. I hadn't update the submodules in git properly =P. It's seems to be working now.

EDIT:
This is too ambiguous for me to be able to use Google for help. "update your system path"? My system path is C:\Windows\system or alternatively C:\Windows\system32 - just like every other Windows installation. I can't google how to do something if I don't even know what it is I'm supposed to google for.

"What choo talkin 'bout Willis?"

If you google "update system path" you will get a full page of results explaining how it works. Here's a good guide: http://www.computerhope.com/issues/ch000549.htm

 

[Nintendo Maniac]

Ah, see? I didn't know THAT'S what was supposed to be changed, hence my issue with not knowing what to google for. I tried googling 'mingw64 update system path' but that got me into way more CMD-heavy stuff than I could ever understand. (my brain doesn't do abstract well at all)

EDIT: Well it started to compile, but I got an error:

 

[Nintendo Maniac]

When all the zips have finished downloaded, extract them all. We will move the contents into C:\cen64-master

Ah, this part was not stated! I had everything downloaded, but I had them in the same folder that cen64-master was in!

EDIT: >_> Spoke too soon. I see you also have to rename the folders to remove the "cen64-" prefix and the "-master" suffix. I'll try that now...

EDIT 2: Gah... it seemed like it started compiling, but then I got a bunch of warnings and errors... I'm too tired to deal with this now, so tomorrow I'll start over using STOLEN_TEXTURES's compile instructions, since it seems like MarathonMan left out some very crucial steps.

EDIT 3: STOLEN_TEXTURES, it's release.cmd - it's not a .BAT file.

 

[rogerhanin2002]

sorry to say that but all instructions to compile are here.
the problematic procedure is perhaps get file from git repository.
the simpliest method (for me) is to install "GIT"
add the git\bin directory to your environement PATH
and follow instructions from first post.
then install mingw with installer (just change to "x64" if supported)
add the mingw\bin directory to your environement PATH
then install glfw like explained by MM, but don't forget the "glfw.h" in root of cen64 directory.

and finally run script release.cmd

if you have error like : syntax error: unexpected end of file
mingw32-make: *** [Objects\CEN64.o] Error 1
it a problem with the environement PATH, if needed del the git\bin directory from PATH

et voila

et encore mille Merci pour tout ton travail MarathonMan.

PS: bonus attachement.

 

[DETOMINE]

This thread is already 66 pages long...
Don't you guys think cen64 should have a subforum?
I think we need a (sticky) thread about how to compile and a (sticky) thread about the progress.
:/

 

[Zuzma]

I think I'll wait till MM fixes more problems with the emulator to try it again. I did build the linux version myself awhile back though just never bothered to post about it. Plus I was messing with mupen64plus in a futile effort to get perfect dark running. Really nice emulator over all though. Probably the best HLE one out there.

 

[MarathonMan]

Anyway, if it's optimized on compile, I supposed this would be one of the rare cases where a program really should use an installer and essentially compile it during installation.

An installer that downloads an entire set of build tools, and a library/header file, and compiles an application? Maybe for an enterprise product; not an open-source application that's hardly been out for a year with one primary contributor.[/QUOTE]

By comparison, some other programs that use an installer are relatively small and simple yet said application is completely portable... *cough*post-v1.6-Project64*cough*

PJ64, portable? You're kidding, right...? Portable from Windows 98 to Windows ME, maybe. PJ64's installer is simply because it all it has to do is copy binary image and some associated files. Of course it's simple.

EDIT:
This is too ambiguous for me to be able to use Google for help. "update your system path"? My system path is C:\Windows\system or alternatively C:\Windows\system32 - just like every other Windows installation. I can't google how to do something if I don't even know what it is I'm supposed to google for.

http://lmgtfy.com/?q=how+to+set+system+path+on+windows

The exact phase "update your system path" even works on Google, com'on, man...

Also recommend: http://www.agoogleaday.com

Ah, this part was not stated! I had everything downloaded, but I had them in the same folder that cen64-master was in!

From the README:

Using git:

'git submodule init'
'git submodule update'
Manual method:

Extract a libaudio plugin to audio/
Extract a libbus plugin to bus/
Extract a libpif plugin to pif/
Extract a librdp plugin to rdp/
Extract a librdram plugin to rdram/
Extract a librom plugin to rom/
Extract a librsp plugin to rsp/
Extract a libvideo plugin to video/
Extract a libvr4300 plugin to vr4300/

 

[Hacktarux]

The pif has been decapped but i don't think there was anything extracted from it. There is also another rom in that chip that would be absolutely required to cycle emulate the n64 but nobody successfully extracted it yet as far as i know: this is the rom run by the 4-bits pif processor.

In case someone is interested, the only way i know to dump the pif rom is to build a test rom that does the following:
- put a watch point using the appropriate watch register in cop0 in an adresse read during pif rom execution.
- copy the pif rom in a part of rdram not used by boot code within the code called by the watch point
- print on screen content of the part of the rdram where the pif has been copied

When you run it on the n64, it installs the watch point and you only have to reset the machine so that in its second run it goes to the watch point handler. And the best part: copy manually all values printed on screen (or find a better idea to achieve this).

For the record, the rom is different on us and european machines. Maybe australian and japanese n64 are also different ? And the biggest challenge.... finding a way to get the pif rom inside aleck64 hardware....

 

[Fanatic 64]

...What about connecting the N64 to a capture card, and writing a program on the PC to automatically recognize and copy the values displayed in each frame? That way you could do it faster and relatively error-free (assuming the picture quality and characters are clear enough). Of course I don't know anything about programing, so I may just be talking off my ass.

 

[Remote]

This is like 50 shades of nintendo

 

[MarathonMan]

The pif has been decapped but i don't think there was anything extracted from it. There is also another rom in that chip that would be absolutely required to cycle emulate the n64 but nobody successfully extracted it yet as far as i know: this is the rom run by the 4-bits pif processor.

In case someone is interested, the only way i know to dump the pif rom is to build a test rom that does the following:
- put a watch point using the appropriate watch register in cop0 in an adresse read during pif rom execution.
- copy the pif rom in a part of rdram not used by boot code within the code called by the watch point
- print on screen content of the part of the rdram where the pif has been copied

When you run it on the n64, it installs the watch point and you only have to reset the machine so that in its second run it goes to the watch point handler. And the best part: copy manually all values printed on screen (or find a better idea to achieve this).

For the record, the rom is different on us and european machines. Maybe australian and japanese n64 are also different ? And the biggest challenge.... finding a way to get the pif rom inside aleck64 hardware....

I thought the PIF returned invalid data when you tried to read from it (after the IPL finished execution)?

Anyways, the MAME team et others have been decapping the CICs for awhile now. The mask ROMs have been dumped, but nobody's been able to identify the exact 4-bit microcontroller.