Looking for N64 schematics/pinouts

[marshallh]

Check your PMs, I have a solution.

Last year when destop and I were kicking this around, we figured it'd be easiest to start with implementing the R4300 on an fpga, and wiring the I/O to the pads on the original N64 PCB. This way you'd be able to debug one thing at a time. There are also HDL R4300 cores to start from.

I hope you're going the Altera route Even though Xilinx has better demo boards, the Altera software is enough better, IMHO.

Is it safe to say all the parts numbered "BU....." are all Rohm products? I've wondered that for some time.

[OzOnE]

Right...

I think I have the files sorted now, but there may be a problem opening the files with the freeware version of Eagle as I think I've reached the board size limit.

I've managed to add the audio and video DAC now though. The problem is that I think I've reached the "board size" limit of the freeware version of Eagle, so you may need a "full" (hint) version of Eagle to be able to change the diagrams without problems.

Otherwise, if you try to move components around, Eagle might say something like "All your schematics are belong to us."! If you've never heard of the "All your base" phenomenon, look here...

http://uk.youtube.com/watch?v=qItugh-fFgg

So, here's the fixed zip. I've used 20-1-09 as the date so it doesn't get confused with the old file. Please ignore the old file completely....

http://www.mediafire.com/?sharekey=6695 ... f6e8ebb871

@marshallh / all...

Yep, still here. The last time I spoke to you was when I started on the FPGA stuff, and I've been coding away / pulling my hair out ever since!

I did give thought to using the original N64 chips to debug things, but I think it would make the code far more complex than it needs to be. The thing is, the R4300 uses the "MIPS interface" protocol to communicate with the RCP - this is quite a complex protocol, and it would be easier to connect the CPU and RCP directly inside the FPGA code.

I'm aiming for 100% "functionally accurate", but not for 100% "physically accurate", since I also want to use DDR RAM anyway and get rid of the RDRAM. Certain features will be put in place to allow for easier expandability of the design (like hi-res textures etc.)

Actually, the biggest hurdle I'm having atm is how to connect the different blocks together. The original RCP has an internal high-speed bus, so it requires some sort of bus arbiter block to allow the processing blocks and CPU to share the same bus.

Until I can visualize a way of putting this together, I can't really proceed with things like the RSP and CPU cores....

I've used the Plasma MIPS core from opencores.org as a basis for the RSP, but I still haven't added the vector registers due to the above issues. Also, due to the way the Plasma core is coded (many separate "modules"), it would be easier to start from scratch and translate the MESS C++ RSP code into Verilog. The R4300 might as well be translated in this way too.

I'm using Altera Quartus as I also don't get on with the Xilinx ISE software (many people don't?). I don't think the Xilinx software is massively different, but the Altera software just appears a bit less fussy when compiling (Xilinx will often complain about every single error, while Quartus will still let me compile - although it still has tons of warnings.)

All I've managed so far is to decode the triangle commands and output the pixel coordinates. I have added the color combiner and texture unit, but it all needs some major testing.

I've also modded the MESS source slightly so it will dump the pixel coords from actual games so I can compare them to the Verilog simulation. At this stage, it's getting VERY difficult to test the texture unit stuff because I only have the basic RDP block done, and I need to dump the TMEM contents from a specific point in a real game to attempt to test the Verilog code.

If this sounds complicated, then keep in mind that I'm learning C++, Verilog, emulation etc. as I go along! It's already been a huge educational experience, but when things go wrong it's not much fun. I'm determined not to give up though.

All I'm looking forward to atm is actually seeing some polygons being drawn on a real monitor on a real FPGA. It should then be possible to stream the RDP command output from MESS into the FPGA via USB so the Verilog code can be debugged / improved until it displays the same thing that MESS does.

Incidentally, I've done a bit of tweaking to the MESS source in an attempt to implement some of the things which Mooglyguy has mentioned in his blog. I don't have the problem with the transparent "boxes" around sprites any more (eg. in Mario Kart), so that's good.

OzOnE.

[Link83]

Wow, really great info their OzOne - im amazed

I have a few quick ideas I would love to ask you if you dont mind:-

-Do you think it would be at all possible to trick the RCP into 60hz instead of 50hz for those PAL games that were poorly optomized? I believe the hertz was set in software but the RCP is what actually controlled it?

-Probably not possible this, but could the RCP theoretically have the 'trilinear filtering' feature disabled - so giving a clearer (if blockier) picture?

-Im wondering if it would be possible to bypass the PIF-NUS lockout chip in some way? (I realise you cant just disable it)...Perhaps by connecting the 'reset signal' input to the 'cold reset' output?

Have you by any chance read all the Nintendo patents sheets? Im guessing you might have done as you have labelled the video data lines as 'SRGB' on the RCP (Although I think in the patents its implied that the SRGB lines start at 'SRGB6' at the top and work their way down to 'SRGB0' at the bottom? I know its not really important though)

Oh, and please dont think im criticizing or anything (I realise you have only just added it) but the audio DAC should be upside-down, as this is how it is in the actual N64! If you look at the audio data lines on your schematic you'll see what I mean

[OzOnE]

Hi,

I'm sure that most of this would be possible, but that's assuming we ever get this thing running. The more I look into this, the more doubtful I am that I'll ever personally get it running actual games. If we had some more code gurus on the case, I think it would make things a lot easier.

I've never quite understood the whole PAL / NTSC thing in games. I think the issue is mainly machine-dependant.

I think it comes down to the fact that NTSC games on certain machines generally run at a lower resolution. This is a lighter load for the graphics processor, so the game can also usually run at 60Hz without too much performance penalty.

On many machines, a lot of the timings for sound generation and in-game animations are governed by the video refresh rate. So, when the games were run at 50Hz PAL instead of 60Hz NTSC, the code often needs to be changed to take the speed difference into account.

This is all an educated guess and it really depends on the machine. Modern PCs can of course run at all sorts of refresh rates without affecting the underlying animation or sound. The problem is that you need a very fast graphics card to be able to output a full frame on every vsync at all times. The problem obviously gets worse with higher monitor refresh rates and more complex graphics.

AFAIK, disabling "wait for vsync" in a PC game just means that if the graphics card can't keep up with the monitor refresh rate, it will just display the partially-drawn frames. This is where the "tearing" comes from. Personally, I can't stand seeing tearing in ANY game and especially not in video - it's basically a way of "cheating" when the graphics card is too slow, and it looks like crap.

On most consoles, they're always "set" (often by design) to display a full frame on every vsync. If the graphics chip can't keep up, they usually display the same frame more than once. This does stop the "tearing" issue, but on some machines, it can slow the whole game right down on complex scenes (if the machine doesn't allow the rendering of the previous frame to be aborted).

Yes, it would be possible in theory to disable any of the graphics options on the N64 FPGA design. (Again, this is assuming it ever gets finished.) From what I've seen in the MESS source, the N64 only does a basic form of bilinear filtering where it only averages the two adjacent pixels on the same line. AFAIK, a true bilinear filter is supposed to average a surrounding "block" of pixels??

I think this is why the textures on the N64 are also pre-filtered. This is to reduce any aliasing effects when the textures are filtered using the N64's rubbish bilinear "duff beer lite" filtering. All of this could be improved on the FPGA design (again, in theory).

I don't think it's possible to completely bypass the lockout chip on an N64. From what I've been told and have read, the RCP requires the code inside PIF to actually boot from - the PIF contains a boot rom which is mapped into the cartridge space when the console is first switched on; the RSP (also inside the RCP) then executes the PIF security code...

The security code will only enable the main CPU and allow the cartridge space to be accessed when the PIF code authenticates correctly with the lockout chip's key code. Even if you bypassed the reset signals on a real N64, I think the RCP blocks access between the CPU and cartridge port until lockout authentication is successful.

So, until recently, nobody had deciphered the PIF bus protocol, or had access to the PIF rom. But the PIF rom is now on the Web, and is actually necessary for running the N64 emulation under MESS. I haven't looked into this further yet, but MESS obviously uses the PIF rom for something.

Please don't take all of the above as gospel as my understanding of this is a tad limited.

OzOnE

[OzOnE]

Hi,

I just saw the thread about adding a DVI or VGA output to the N64. I'd thought I'd post here instead so I can give a quick update about the FPGA stuff...

In theory it's possible to add a VGA output to a standard N64, but would be far more work and would probably cost more than it's worth. Using a scan doubler (VGA box) is much simpler. Also, if your N64 doesn't have RGB output you won't be getting the best quality on the monitor. It should be fairly good with the s-video output and a scan doubler though. If you're looking for the best quality, keep in mind that the N64 only outputs 21-bit colour, so will always be slightly limited in the "smoothness" of colour output.

I'm still making some progress with the N64 FPGA project, but progress will be VERY SLOW, and might take YEARS to get anything working. But, if it does work, there are almost unlimited possibilites for enhancing it....

At the moment, I just need a new FPGA board to test the basic RDP code out. It's actually very difficult to find a suitable FPGA board for this and some of them are so overpriced, it's not even funny. The very best one I've seen is the one being made on FPGA Arcade....

http://www.fpgaarcade.com/

This has plently of RAM (32MBytes of DDR) and both DVI and VGA (DVI-A) outputs. I've e-mailed them to find out roughly how much this board would cost, but I haven't heard back yet. I don't want to buy a different board until I get a reply back from them because their board is the best one I've seen.

I'm dying to just see some polygons being rendered on a real monitor. I can then start getting the texture stuff working. The CPU and RSP still aren't anywhere near finished yet, but if I can get an FPGA board with USB on it, I should be able to modify the MESS source so that it "redirects" all the RDP commands to the FPGA (instead of emulating it on the PC)....

This will allow debugging of the RDP core until it's as accurate as possible. Then coding the CPU and RSP stuff can begin.

I've researched a lot about "bus arbitration" which will be required to join all the different blocks together to make a complete N64 design. It doesn't look quite as impossible as I first thought, but will still be a huge challenge.

I did ask the FPGA Arcade guys if they could test my RDP code, but there's actually not much point unless I can get hold of my own board so I can start debugging things. It's really just to be able to see something working rather than in simulation as this graphics rendering stuff fascinates me.

Bye for now,
OzOnE.

[OzOnE]

Hi all,

I'm still working on this stuff and I'm getting closer to trying to add an FPGA to a real N64 so I can send RDP commands directly to the RCP. I've only got as far as removing the CPU from the board as I've been concentrating more on trying to understand the MESS code recently. I'm trying to figure out the best FPGA board to buy and how I'm going to solder the wires to the N64 while keeping them as short as possible.

I've also managed to implement quite a few of Mooglyguy's fixes for N64 emulation under MESS (taken from his blogs). I don't think I'll ever manage to implement "coverage" as it's too complex, but hopefully Mooglyguy will be able to release his code soon. If anyone wants my crappy version of the source code, I don't think it would be a problem to attach it here. The only noticable differences atm are that it fills in the gaps between polygons and stops the horizonal "spike" issue to a large extent. It do get rid of the black "blocks" around sprites though (eg. around the sparkly stars on the Mario title screen). It also fixes the problem in certain games like Mario Kart, where there is an invisible block surrounding karts which blocks your view of the kart in front.

Most of these fixes are a bit of a kludge and are probably not the proper way of doing it, but it works (I'm still learning C++ and the N64 architecture).

Anyway, back on topic - I wanted to show what the N64 PCB looks like with the CPU removed. I'm starting to double-check the pinouts of the schematic now that I can see what's under all the pins. So far, I've highlighted the VCC (3.3V) planes / pins in RED and attached that pic too...

OzOnE.

EDIT: Sorry, I forgot a few things... You can see my awful jumper pak soldering in the first photo too. I had to solder most of the ground pins first, the insulate the bottom row with tape, then solder the signal pins afterwards. It does work believe it or not. I also have the two 36Mbit RDRAM chips soldered on board, so it has the full 8MB of RAM at all times.

On a side thought, I had a major idea the other night - what do you guys think about an N64 with proper stereoscopic 3D?!! The idea is to use two RCP chips (one for each eye). One RCP would work as normal (eg. for the left eye), and the other one would be sent RDP commands directly from an FPGA. If I can figure out where the Mario microcode stores it's projection coordinates, it should be possible to tweak them "on the fly" so that the second RCP chip displays an image which is "shifted" slightly to the right: this shifted image will effectively produce the correct output for the right eye.

I'm not sure if it would work to only use one RCP chip to display both left and right images because it would probably be way too slow. With two chips, it could still display at 60Hz (or 50Hz), so 30Hz (or 25Hz) for each eye. This would then be synced to some 3D shutter glasses to get proper stereoscopic 3D from games! I just need to play around with the MESS N64 emulator first to see if this is feasible. I just need to hunt down those coordinates.

Oh, and if you're wondering about the power and flexibility of FPGA chips (in the right hands, ie. probably not mine), check this beauty out. Simply amazing....

http://home.comcast.net/~olimar/DS/jumbotron/

OzOnE.

[marshallh]

Cool work so far.
I have some things that may help with stereoscopic 3D. You will want to trap the matrix load instructions in the RSP, and trap matrix loads that have the projection matrix flag set. Then you can grab the position data out of the matrix, copy it over to your other RCP core and render to either another RDRAM setup and video DAC, or an arbitrary framebuffer address outside of the normal 8MB ram.

99% of games are going to use this format of instructions for positioning the camera. The memory values may differ depending on the microcode. So, it may not be feasible. But what do I know

Code: Select all

		// Set up projection matrix //
		guPerspective(&(generate->proj), &pnorm, 59, 1.3333333, 50.0, 5000.0, 1.0);
		gSPPerspNormalize(gdl_end++, pnorm);

		guLookAt(&(generate->view),
					camera.mov[0]  , camera.mov[1]  , camera.mov[2] ,  // eye
					camera_pdest[0], camera_pdest[1], camera_pdest[2], // at
					0.0, 1.0, 0.0);	

		gSPMatrix(gdl_end++, OS_K0_TO_PHYSICAL(&(generate->proj)),
					G_MTX_PROJECTION | G_MTX_LOAD | G_MTX_NOPUSH);
		gSPMatrix(gdl_end++, OS_K0_TO_PHYSICAL(&(generate->view)),
					G_MTX_PROJECTION | G_MTX_MUL | G_MTX_NOPUSH);

[OzOnE]

The memory values may differ depending on the microcode. So, it may not be feasible. But what do I know

...Quite a lot by the looks of it.

You've said exactly what I'm looking to do, but I don't even know how the usual emulator graphics plugins read the display lists. I can see where the code parses the commands (eg. in the Z64 source etc.), but I need to find where the display lists are "cached" in RSP DMEM, or where they are stored in RDRAM in the first place.

I'm trying to figure out how to trap the "LookAt" stuff to change it on the fly, or to at least set it to a set value to see what happens. I have no idea about how the matrix transformations work, but if the source coordinates are fairly simple (x,y,z,w or something), it should be possible. Obviously I can only emulate this at first, but that'll be fun too.

I've been looking at the Z64 source code, as it's similar to MESS, but it renders via the PC gfx card. I don't know how on Earth I'm going to trap the display list stuff in the MESS code as it's all low-level? I don't even have Visual Studio installed atm, so I'm compiling MESS using GCC (again, I'm not very experienced, and even getting MESS to compile took me about three days.)

Was that code from OpenGL, or from an emulator?

Atm, if I could just find where the display list is stored in RSP DMEM, then find where the projection coords are, I can start setting values to see if I've hit the correct one. After that, I can find which part of the ucode reads (or writes) the transformed coords so I can trap them. Have you ever seen a full disassembly of the Mario ucode with full comments, or just a basic ucode memory map??

Please help, I'd love to see this working. In theory, it would actually be easier than trying to implement the whole N64. I think that will take years (for me anyway), so at least the 3D thing will be cool to play with in the mean time.

OzOnE.

[OzOnE]

@marshall: I forgot to ask - as you've built many projects and can handle the PCB and USB stuff etc., do you have any ideas on what cool things could be done with the original N64 chipset? ie. what sort of project would you like to see, or would be interested in building? btw, did you say you use Olimex for prototype PCB's?

@all: I knew the N64 is obviously very complex and there's hardly any documentation out there for it, but I think I've hit a brick wall with this stuff atm. I mainly just need to get hold of a decent FPGA board with a VGA output and some DDR / SDRAM - I've e-mailed the FPGAarcade dudes, but had no reply for weeks now? I'm now wondering if this project is worth it as I'm rapidly loosing motivation unfortunately....

Is anyone still particularly interested in a new (smaller) N64 PCB, or are ideas like the 3D glasses thing really worth looking into? I'm just trying to find the next route to go down - I'm not sure I'll ever complete the N64-on-a-chip project with my lack of knowledge, so I'm looking for something a bit more realistic. If I just hooked up a cheap FPGA board to the RCP, at least I could achieve something cool in the short run.


OzOnE.

[jleemero]

I'd love to see either really.
A new, smaller N64 would be wonderful.

But adding Stereoscopic 3D to an N64? That would be absolutely incredible!
It can already be done with emulators now, actually. By far my favorite way to play Ocarina of Time
Adding this kind of thing to an actual N64 would be phenomenal!

[OzOnE]

Ok, I'll keep plodding on with the PCB thing. I'm just working out how to connect my (old) FPGA to the N64. It won't be easy, but there are only 45 signal wires needed (not too bad).

How do you use an emulator in stereoscopic mode? I have the ELSA Revelator 3D glasses, but 3D support sucks now that I have an ATI graphics card. It worked great on the nVidia card though.

Incidently, I signed a petition years ago to try to get ATI to put stereo 3D support into their drivers....

http://www.petitiononline.com/ati3d/petition.html

I haven't found any software which works properly with my glasses - Do any emulators support stereo 3D directly? I wouldn't have thought it to be too difficult for the experienced coders to add stereo support; it just needs to output a slightly shifted view on each alternate frame.

Of course the other problem is that I don't have a CRT monitor now either - 3D glasses don't work too well on most TFT's. I could hunt down an nVidia card and try it on the projector though.

OzOnE.
btw, I wonder what Positron (thread starter) had in mind for the N64 schematics? I can't help thinking I've hijacked this thread.

[jleemero]

I've had good experience with the iZ3D drivers, but I don't know how their ATI support is.

[OzOnE]

I've tried the iZ3D drivers before, but they only support red / blue glasses (which are crappy imho), iZ3D monitors, or 3D DLP (which is not standard). Ideally, I need it to output the separate images on each alternate frame like the nVidia driver does. I can then sync my glasses to the monitor VSYNC.

I'm not sure why they didn't include this in the iZ3D driver as it appears to work fine with Project 64 etc. If it had a standard left / right image output it would be a great solution.

[jleemero]

I've tried the iZ3D drivers before, but they only support red / blue glasses (which are crappy imho), iZ3D monitors, or 3D DLP (which is not standard). Ideally, I need it to output the separate images on each alternate frame like the nVidia driver does. I can then sync my glasses to the monitor VSYNC.

I'm not sure why they didn't include this in the iZ3D driver as it appears to work fine with Project 64 etc. If it had a standard left / right image output it would be a great solution.

Actually, they've since upgraded.
There are many, many options now:
# 3D DLP
# Anaglyph Output
# Dual Output
# Interlaced Output
# Shutter Output
# Stereo Mirror Output (my personal favorite)
# VR920 Output

[OzOnE]

Ohhhhh, I see - all this time I didn't realize you MUST choose Full Installation when installing the iz3D drivers! It would have been nice if they'd mentioned that properly.

Fantastic now though, there are loads of options (I'm using the latest beta). It looks like the driver might even work directly with my ELSA glasses. The LCD panels might need to be rotated though, as my monitor looks completely black through the glasses (glasses turned off). I'll check out the forums too...

http://forum.iz3d.com/viewforum.php?f=23

http://www.mtbs3d.com/phpBB/viewtopic.php?f=30&t=1898

Thanks again jleemero! I can't wait to try Mario 64 in stereo 3D!

OzOnE.
btw, sorry if this is a bit off-topic.