What's new

Announcement: Cycle-accurate N64 development underway.

Hacktarux

Emulator Developer
Moderator
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.

Yep, but read again.... we hit the watch point during the execution of the ipl after resetting the n64, so we can copy it before it is masked.

As i said, i do not believe their file has been extracted from decapping work, and as far as i know, only the ntsc pif has been decapped.
 
OP
MarathonMan

MarathonMan

Emulator Developer
Yep, but read again.... we hit the watch point during the execution of the ipl after resetting the n64, so we can copy it before it is masked.

As i said, i do not believe their file has been extracted from decapping work, and as far as i know, only the ntsc pif has been decapped.

Interesting way of doing it, especially since docs say:

Code:
Initialize the values of these registers in software since these values are undefined 
on reset.
 

Nintendo Maniac

New member
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.
Non open-source programs on PortableApps such as Google Chrome download data from Google's servers during the installation... I don't see what the issue is here...



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.
...huh? First you seem to think I'm crazy for calling PJ64 portable, then you seem to agree with me that it IS portable? Uh... nevertheless I've copied PJ64 (versions newer than 1.6) between two completely different Win7 and XP PCs and it worked just fine. If that's not the definition of portable, then I don't know what is.



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...
I already said I was googling "mingw64 update system path". It never crossed my mind that 'updating your system path' was a standard Windows thing and not a mingw64 thing. It was like 4am last night, gimme a break. >_>


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/

etc...
You said GIT was not needed, so I downloaded the files manually. In that case I had no readme and nobody said I had to rename any files until STOLEN_TEXTURES came along. Speaking of which, what happened to his post? I was going to use his instructions...

In the mean time I'll try installing GIT and following rogerhanin2002's instructions...

And for anyone who cares, the cen64.exe that rogerhanin2002 posted gives me the exact same result as before - "cen64.exe has stopped working"
 
OP
MarathonMan

MarathonMan

Emulator Developer
Non open-source programs on PortableApps such as Google Chrome download data from Google's servers during the installation... I don't see what the issue is here...

...huh? First you seem to think I'm crazy for calling PJ64 portable, then you seem to agree with me that it IS portable? Uh... nevertheless I've copied PJ64 (versions newer than 1.6) between two completely different Win7 and XP PCs and it worked just fine. If that's not the definition of portable, then I don't know what is.

Typical Windows user mentality. You define portable as portable for your environment, and your environment only. Hence the facetious remark regarding portable from Windows 98 to Windows ME. CEN64 can run anywhere, so long as you build it for yourself.

I could strip out optimizations in the Makefile and permit CEN64 to yield "portable" (as you call it) builds, but I'm not interested in doing that because I don't want to be responsible for distributing binaries to begin with. And I want the extra optimizations.

You said GIT was not needed, so I downloaded the files manually. In that case I had no readme...

Also false. It's on the same page you downloaded everything from, with fancy markup and all: https://github.com/tj90241/cen64

And for anyone who cares, the cen64.exe that rogerhanin2002 posted gives me the exact same result as before - "cen64.exe has stopped working"

He might have a different processor than you.
 

Nintendo Maniac

New member
Typical Windows user mentality.
...please don't make such an assumption.

You define portable as portable for your environment, and your environment only. Hence the facetious remark regarding portable from Windows 98 to Windows ME. CEN64 can run anywhere, so long as you build it for yourself.

I could strip out optimizations in the Makefile and permit CEN64 to yield "portable" (as you call it) builds, but I'm not interested in doing that because I don't want to be responsible for distributing binaries to begin with. And I want the extra optimizations.
...oh, you mean cross-platform. Cross-platform != portable:
http://en.wikipedia.org/wiki/Cross-platform
http://en.wikipedia.org/wiki/Portable_application (yes it has a header saying it might be original research, but bear with me)
Nevertheless, a portable application CAN be a cross-platform one as well, it would just have multiple executable files for the associated OSes and/or platforms.

Also, I never realized in the first place that you're using a similar end-user application philosophy to Mupen64plus (the compile requirement, no distributed binaries, primarily Linux focused, etc). I always associated this more with bsnes, hence several of my comments regarding installers, portable-ness, and the like.


Also false. It's on the same page you downloaded everything from, with fancy markup and all: https://github.com/tj90241/cen64
Again, I blame 4am for not having the sense to scroll down. Can't I just retract much of what I said last night? :p



He might have a different processor than you.
Well yeah, but I didn't find that out until I tried running the EXE no?
 
Last edited:
F

Fanatic 64

Guest
I will sit back, get my popcorn and watch how this conflict unfolds.

(...trough, Nintendo Maniac does seem to have Windows mentality. Wanting binaries, bashing Linux and what to say about the ReactOS banner, a product based on Microsoft® Windows®. (Don't take it bad trough, I perfectly understand and suffer from the same problem, I just show more discretion about it...))
 

Nintendo Maniac

New member
watch how this conflict unfolds.
Conflict unfolds? I was trying to point out my own faults and wrong-doings while explaining what it was that was going through my head in an attempt to bring resolution to both sides and have this simmer down to where we can move on. Are you saying that I've failed? *sigh* oy vey... Maybe I should just disable topic email notification and just make myself "forget" about CEN64 for a month or so under the guise (to myself) of the topic being inactive (since in the past I have randomly stopped getting notification) - I think I might just do that.


Regarding being a "typical Windows user", I have a dedicated Parted Magic 256MB flash drive, have Linux on my DS via homebrew, and have way too many Linux distros burned to CDs than I can count (way more than those for ReactOS!) from before I got CD-RW discs. (from memory I can think of Gentoo, SlackWare, Damn Small Linux, Puppy Linux, Knoppix, Linux Mint, Ubuntu, Kubuntu, Xubuntu, and Lubuntu)

The ReactOS banner is largely because I think it just needs more publicity, since it has problems with a lack of developers and/or development time - Linux has more than enough of both.
 
Last edited:

gokuss4

Meh...
...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.

If by capture card, you mean one that takes video, then no. A capture card only captures the video output.

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

Would it be possible to hook up the N64 to some kind of external microcontroller, and make a program for the microcontroller to automatically print the values to a file onto your PC through a serial interface?
 

zoinkity

New member
The problem is there's more than one way to add an entry into the system path, and these methods vary with different versions of windows.

I had a PAL and NTSC PIF dumped by someone who dumps arcade cabinet ROM chips. For the most part, it was because they had the equipment and are much better with a soldering iron. (Basically they remove the chip and attach it to a little piece of hardware I don't presume to understand ;*) There's more than one PIF rom though. There's a minimum of three--one for each region--and it's been long suspected that later version consoles were altered slightly to initialize ram at bootup. So really there are 4~6+. Mine are both earlier consoles, but the PIF roms are significantly different in structure despite being identical in function.


Instruction stepping should be viable as well, similar to the method used to capture the GB bootroms. Amusingly, if N64 hacking had really taken off we would have had the stupid things years ago, since they're embedded in the Pokémon Stadium series games ;*)


I'll have to compile my own copy, without git, and not from my home PC. Only problem with open source (or Linux for that matter) is the assumption of direct, and often fast, internet connections. That said, getting frustrated at a couple issues building something is much better than not being able to build it at all ;*)
 
Last edited:
F

Fanatic 64

Guest
If by capture card, you mean one that takes video, then no. A capture card only captures the video output.
If you paid more attention you would actually understand what I mean. My idea was basically doing what Hacktarux proposed, but instead of having a human manually copy all the values, record a video with the screen output, and make a program that recognizes the values on-screen and copies them to a file, generating the "dump" of the ROM.

And a bit unrelated, but if the actual PIF hasn't been dumped, then what exactly does the pifdata.bin file do?
 

Zuzma

New member
You could write something to capture frames from the video at certain intervals based on how fast the application flips through the pages of displayed memory then have some kind of ocr (optical screen reader) software turn them into a plain text document. Or I dunno, I'm probably just talking out of my ass.
 
F

Fanatic 64

Guest
You could write something to capture frames from the video at certain intervals based on how fast the application flips through the pages of displayed memory then have some kind of ocr (optical screen reader) software turn them into a plain text document. Or I dunno, I'm probably just talking out of my ass.
This is exactly what I proposed.
 
OP
MarathonMan

MarathonMan

Emulator Developer
And a bit unrelated, but if the actual PIF hasn't been dumped, then what exactly does the pifdata.bin file do?

It has been dumped, and that's precisely what the file is. It contains the IPL (initial program load) that the MIPS VR4300 processor starts executing after PIF releases NMI. The IPL in the PIFROM that gets executed by the VR4300 does additional security checksums and things, copies the first bit of cart data to RDRAM, and initializes whatever else is required.
 
F

Fanatic 64

Guest
It has been dumped, and that's precisely what the file is. It contains the IPL (initial program load) that the MIPS VR4300 processor starts executing after PIF releases NMI. The IPL in the PIFROM that gets executed by the VR4300 does additional security checksums and things, copies the first bit of cart data to RDRAM, and initializes whatever else is required.
Then what's the file Hacktarux says hasn't been dumped?
 

Hacktarux

Emulator Developer
Moderator
Hey, it seems that my little bit of information confused you. Sorry, i did not go to details. Here is a better explanation.
The pif chip is actually made up of these parts:
- a 4 bits processor
- ram
- some rom executed by the 4 bits process (lets call it rom1)
- some rom read by the r4300 called the ipl and that can only be read during boot process

rom1 has not been dumped as far as i know
4 bits processor has not been clearly identified and nobody emulate it in any emulator yet

the ipl has been "dumped". I dumped mine using the method i described. The trick is to get some custom code running during boot process. I believe the rom used by mame has been dumped using a similar method but i am not sure. Anyway, the file found on internet as pifdata.bin is the ntsc pif and as i said other ones are not as easily available. And the hardest one to dump is the aleck64 one as there is no v64jr or other easy way to run code on it.
 

Zuzma

New member
At least in n64.zip there's three files.

normpnt.rom
normslp.rom
pifdata.bin

What exactly are those ones with the rom extension for? They're both 128 bytes. I'm assuming they have nothing to do with the undumped rom you're talking about. It wouldn't surprise me honestly if whatever that 4-bit processor you're talking about was used in something else nintendo made. I THINK some hand held games and calculators used stuff like that.
 
Last edited:
OP
MarathonMan

MarathonMan

Emulator Developer
At least in n64.zip there's three files.

normpnt.rom
normslp.rom
pifdata.bin

What exactly are those ones with the rom extension for? They're both 128 bytes. I'm assuming they have nothing to do with the undumped rom you're talking about.

They're the point/slope ROMs for the RDP. The RDP's drawing algorithm is quite "different" shall we say. A forum user posted some really nice details on it here:

http://www.emutalk.net/threads/53938-N64-tech-documentation/page2

The 4-bit microprocessors were exclusively used in the CICs and PIF. The one in the PIF is also responsible for interfacing with serial devices, whereas the ones in the CICs are exclusively for security checks (I think).
 

Reznor007

New member
And the hardest one to dump is the aleck64 one as there is no v64jr or other easy way to run code on it.

You could probably just remove it from the Aleck64 PCB and install it on a N64. Same for the one on a Magical Tetris arcade PCB, since it's slightly different than Aleck64.

When I used to work at an arcade we had a Magical Tetris PCB kit to install into a spare cabinet, but before putting it out for use, I played around with it for a bit. I removed the CIC chip and the Tetris ROM chip from the PCB, and installed a CIC and ROM chip from a Wayne Gretzkey hockey cart. The PCB booted up and began playing the attract mode sounds from Gretzkey, but the screen was just white/gray, and controls didn't seem to respond. I didn't have an N64 there to test the Tetris ROM on a real N64 though. Wish I had more time with it. The ROM and CIC chip on the PCB are identical to the ones in N64 carts though. The PCB also had 4 3pin connectors that are probably the N64 controller ports, but I didn't have time to wire up an adapter to see if the game would respond to those.
 

Top