Looking for N64 schematics/pinouts
Moderator: Moderators
I haven't measured the current draw tbh. I'd imagine it's exactly the same as with the expansion pack installed.
Please don't hold your hopes up about the FPGA stuff. This project would be a fairly huge task for an experienced FPGA / C++ programmer, and I am definitely niether. This is mainly an educational effort, but it would be nice to recreate at least SOME working parts of the N64.
There are quite a few MIPS cores freely available for FPGA's, and the RSP is a variation of the R4000 series CPU. It has many of the standard FPU maths opcodes "removed", but it also has a lot of even more complex vector opcodes added instead (for calculating the polygons etc.)
I'm only starting to get my head around all of this and I've never programmed any games before (apart from on the ZX Spectrum!), so please don't expect any results at all in the near future unless a more experienced coder gets involved.
I might try to e-mail Mooglyguy soon, as he is working on the MESS low-level emulation stuff which ties in with the FPGA stuff nicely. Basically, I just need to port the MESS C++ code into Verilog or VHDL but I don't have the software or the skills for that task.
At the moment I'm trying to work out how the vector unit would physically be put together so I can re-create it on the FPGA. So far, this involves using...
32 x 128-bit x 3-way muxes,
8 x 16-bit x 8-way muxes,
16 x 16-bit adders,
16 x 16-bit multipliers,
8 x 48-bit accumulators,
And that's just a tiny fraction of what's needed for the vector unit alone. This doesn't include any of the control signals or scaler unit or IMEM / DMEM, and none of the RSP opcodes are written yet.
I've got a bit of a headache now, so I think I'll have a sleepy. lol
OzOnE.
Please don't hold your hopes up about the FPGA stuff. This project would be a fairly huge task for an experienced FPGA / C++ programmer, and I am definitely niether. This is mainly an educational effort, but it would be nice to recreate at least SOME working parts of the N64.
There are quite a few MIPS cores freely available for FPGA's, and the RSP is a variation of the R4000 series CPU. It has many of the standard FPU maths opcodes "removed", but it also has a lot of even more complex vector opcodes added instead (for calculating the polygons etc.)
I'm only starting to get my head around all of this and I've never programmed any games before (apart from on the ZX Spectrum!), so please don't expect any results at all in the near future unless a more experienced coder gets involved.
I might try to e-mail Mooglyguy soon, as he is working on the MESS low-level emulation stuff which ties in with the FPGA stuff nicely. Basically, I just need to port the MESS C++ code into Verilog or VHDL but I don't have the software or the skills for that task.
At the moment I'm trying to work out how the vector unit would physically be put together so I can re-create it on the FPGA. So far, this involves using...
32 x 128-bit x 3-way muxes,
8 x 16-bit x 8-way muxes,
16 x 16-bit adders,
16 x 16-bit multipliers,
8 x 48-bit accumulators,
And that's just a tiny fraction of what's needed for the vector unit alone. This doesn't include any of the control signals or scaler unit or IMEM / DMEM, and none of the RSP opcodes are written yet.
I've got a bit of a headache now, so I think I'll have a sleepy. lol
OzOnE.
Actually, it only took about a week to get that N64 diagram drawn up as I realized I had most of the pinouts and datasheets already. It was only a few weeks back that I decided to work out the RCP pinouts, and I now see that Destop was also working on it (which is great news).
The good thing is that Destop's diagram matches mine pretty much exactly, so the N64 diagram is almost complete. There may be some routing issues though as we don't know quite how sensitive some of the signals are. I want it to be 100% before I even think about getting a real PCB made.
Note: To avoid confusion - there are two separate projects here.... The N64 PCB "re-engineering" project is just a new PCB layout for the N64, but it would still require the original chips to be removed from a donor N64! (It would still be possible to add an FPGA to this PCB though. This would allow for things like loading r*ms directly from a CF card etc.)
The idea of the second project is to completely re-create the N64 inside an FPGA design. This would mean that pretty much everything would fit into one chip. All it would need is a chunk of DDR RAM, video / audio DACs, and controller ports etc. (The CF card thing would apply to this project as well.)
So, I've been side-tracked by the FPGA stuff now. This would be the ultimate goal as there are so many enhancements you can do with the design once it's up and running (like higher resolutions and high-res textures.) Hopefully one day it will be 99.99% accurate to a real N64, so it won't have the glitches that some high-level emulators can experience.
@Kyo: I'm currently off work atm. I was working at a busy PC shop doing sales / repairs / phone support (all at the same time), but I had to give it up mainly due to the stress! I wish I could do more of the electronics and programming side of things as a career, but I'm self-taught, and I don't have the "official" qualifications.
That is unless anyone could offer me this type of job in the UK?!
OzOnE.
EDIT: Oh, I did try to take a photo of the jumper pack / Rambus soldering but I have one of those awful fixed-focus Aiptek cameras, so you couldn't see anything. The jumper pack soldering is kind of messy (I'm using separate strands of tinned copper wire!), but the Rambus soldering looks like new. That's the beauty of hot-air soldering and flux cleaner!
Crikey, I do type a lot.
The good thing is that Destop's diagram matches mine pretty much exactly, so the N64 diagram is almost complete. There may be some routing issues though as we don't know quite how sensitive some of the signals are. I want it to be 100% before I even think about getting a real PCB made.
Note: To avoid confusion - there are two separate projects here.... The N64 PCB "re-engineering" project is just a new PCB layout for the N64, but it would still require the original chips to be removed from a donor N64! (It would still be possible to add an FPGA to this PCB though. This would allow for things like loading r*ms directly from a CF card etc.)
The idea of the second project is to completely re-create the N64 inside an FPGA design. This would mean that pretty much everything would fit into one chip. All it would need is a chunk of DDR RAM, video / audio DACs, and controller ports etc. (The CF card thing would apply to this project as well.)
So, I've been side-tracked by the FPGA stuff now. This would be the ultimate goal as there are so many enhancements you can do with the design once it's up and running (like higher resolutions and high-res textures.) Hopefully one day it will be 99.99% accurate to a real N64, so it won't have the glitches that some high-level emulators can experience.
@Kyo: I'm currently off work atm. I was working at a busy PC shop doing sales / repairs / phone support (all at the same time), but I had to give it up mainly due to the stress! I wish I could do more of the electronics and programming side of things as a career, but I'm self-taught, and I don't have the "official" qualifications.
That is unless anyone could offer me this type of job in the UK?!
OzOnE.
EDIT: Oh, I did try to take a photo of the jumper pack / Rambus soldering but I have one of those awful fixed-focus Aiptek cameras, so you couldn't see anything. The jumper pack soldering is kind of messy (I'm using separate strands of tinned copper wire!), but the Rambus soldering looks like new. That's the beauty of hot-air soldering and flux cleaner!
Crikey, I do type a lot.
The re-engineering project is what I'm interested in. If you ever get a board made, any chance I could buy one? (And maybe for a bit more, you could put the chips on for me? My soldering skills are definitely not up to that task. 
) I'd rather not go with ROMs, I prefer original hardware. But an N64-OAC? That's pretty hardcore. What kind of heating issues would that have?
And It's fine that you type a lot. You have a lot to say.
) I'd rather not go with ROMs, I prefer original hardware. But an N64-OAC? That's pretty hardcore. What kind of heating issues would that have?And It's fine that you type a lot. You have a lot to say.
-
evilteddy
- Portablizer
- Posts: 423
- Joined: Tue Mar 25, 2008 2:11 am
- 360 GamerTag: Kirren of Smeg
- Steam ID: kizzinator
- Location: Newcastle, Australia
I think it would be fun if you made the PCB file available. Then we could add our own traces for buttons and have all the mushy contacts and controller circuitry on the same board. It would be a fairly easy addition that I'm sure most of us could do and it would remove the need for a separate controller board and allow us to place mushy contact buttons to our own criteria. It would be like a real portable console motherboard with everything on the one board. Circuitry in the centre buttons on the side (please note I have only seen the insides of an openpandora, ds and original gameboy so I assume this is the case in most handhelds).
I was thinking that it would be fun to be able to move the components around on the board after getting the schematic so that we could customise the board for each portable. Eg move the cart slot around depending upon which way it loads (bottom or top) and putting the CPUs and RAM in places of high air flow to keep them cool. Unfortunately that would throw the timing off, which as we know from relocating jumper and expansion packs is pretty sensitive.
One last thing, Mario is right, we come to a forum to read other peoples ideas and see them develop. A good topic like Bacteria's build logs are always great to read. Your posts are no different. Don't shorten up on our behalf, as far as I'm concerned the more information, the better.
I was thinking that it would be fun to be able to move the components around on the board after getting the schematic so that we could customise the board for each portable. Eg move the cart slot around depending upon which way it loads (bottom or top) and putting the CPUs and RAM in places of high air flow to keep them cool. Unfortunately that would throw the timing off, which as we know from relocating jumper and expansion packs is pretty sensitive.
One last thing, Mario is right, we come to a forum to read other peoples ideas and see them develop. A good topic like Bacteria's build logs are always great to read. Your posts are no different. Don't shorten up on our behalf, as far as I'm concerned the more information, the better.
-
palmertech
- Senior Member
- Posts: 3225
- Joined: Sat Feb 02, 2008 1:40 am
- Location: California, land of the homeless and hippies
-
palmertech
- Senior Member
- Posts: 3225
- Joined: Sat Feb 02, 2008 1:40 am
- Location: California, land of the homeless and hippies
HELLO!
I actually read this whole tread just now, and it seems that this project very similar to some things Ive been meaning to mess around with for years.
I am also interested in the board-redesign process, I have some experience making boards, and I have some donor hardware that I want to bake the chips off of just for fun anyways. Could you please send me the shematic/PCB files you have already? I am very interested in this and I could help with the design and testing.
The FPGA stuff interests me immensely as well. I think it is too great of a task to recreate the entire N64 in an FPGA (think how poorly some emulators work). However, I think it would be an amazing idea to put all of the video/audio/controller stuff into an FPGA, and then put that onto a redesigned 4-layer board, with the original CPUs and RAM. I think it could be made to be incredibly small without the hassle of trying to make a vector processor in an FPGA. It would also allow me to use a smaller and cheaper FPGA.
I want to make this my final project for school. I dont know if it will fly though, Ill have to wait till summer to find out.
So could you please send me all the information you are willing to share? If you have MSN pm me your email k?
I actually read this whole tread just now, and it seems that this project very similar to some things Ive been meaning to mess around with for years.
I am also interested in the board-redesign process, I have some experience making boards, and I have some donor hardware that I want to bake the chips off of just for fun anyways. Could you please send me the shematic/PCB files you have already? I am very interested in this and I could help with the design and testing.
The FPGA stuff interests me immensely as well. I think it is too great of a task to recreate the entire N64 in an FPGA (think how poorly some emulators work). However, I think it would be an amazing idea to put all of the video/audio/controller stuff into an FPGA, and then put that onto a redesigned 4-layer board, with the original CPUs and RAM. I think it could be made to be incredibly small without the hassle of trying to make a vector processor in an FPGA. It would also allow me to use a smaller and cheaper FPGA.
I want to make this my final project for school. I dont know if it will fly though, Ill have to wait till summer to find out.
So could you please send me all the information you are willing to share? If you have MSN pm me your email k?
"Linux is only free if your time is worthless"
May I ask how you managed to work out the pinout for the RCP-NUS, and has it been posted anywhere? (Unless I have missed it in this thread - I can only seem to find the smaller N64 schematic picture) Some fantastic info you posted by the wayOzOnE wrote: In the course of trying to get the V64 stuff working, I collected quite a lot of data on the N64, and recently went as far as figuring out the pinout of the RCP (I'd never seen this pinout anywhere else).
Well Im starting to draw my schematic and I have more than half of the pins mapped out.
I mean its easy since half of them are power, and the other half are busses that are identified in the pinout of the other chip. It doesnt take an expert to determine that the "sysad18" line from the CPU probably goes to the 18th address line on the RCP.
So I wonder if he just meant that... Or if he has some insider information. Theres a few pins on there that do things I dont understand yet but Im not really interested in fully understanding it right now anyhow.
I mean its easy since half of them are power, and the other half are busses that are identified in the pinout of the other chip. It doesnt take an expert to determine that the "sysad18" line from the CPU probably goes to the 18th address line on the RCP.
So I wonder if he just meant that... Or if he has some insider information. Theres a few pins on there that do things I dont understand yet but Im not really interested in fully understanding it right now anyhow.
"Linux is only free if your time is worthless"
Hi,
I haven't looked into the schematic stuff since I started on the FPGA design. I've attached the most recent schematic / board files if anyone wants to finish it off?
It still needs the voltage regulator stuff and the video /audio DACs etc. These parts will probably need to be designed from scratch, so you'll need to find a part with the correct package size and pin spacing, then create a new symbol and "device" library for them. The audio DAC is just an SO-8 package, so that won't take long to make. I might look into this stuff later.
The biggest issue will be the routing of the PCB tracks / layers (Eagle doesn't calculate the track "timings" / capacitance AFAIK) - there are some very high speed signals on the N64 board (RAMBUS etc.) so I'm not sure how to go about routing the new board properly so that everything will run correctly. It might work OK if it just has a giant ground plane around all the signals and if the track routing is kept tidy.
The attached files should open with the freeware version of Cadsoft Eagle, which can be downloaded here....
http://www.cadsoft.de/download.htm
The "Nintendo 64.lbr" file from the zip should be copied into your Eagle library folder before opening the schematic / board files... eg. The default location of this folder for the freeware Eagle 5.4.0 would be...
C:\Program Files\EAGLE-5.4.0\lbr
Please note: The design currently has two RAMBUS chips on board (the full 8MB). So, if this design is ever finalized, you need to either use the chips from two official Nintendo (single chip) 4MB expansion paks, or the design can easily be changed to use just one 4MB chip to save space / power (it would be like a standard 4MB N64, but without the huge jumper pak).
Also, the pinouts and chips on this design correspond to my European PAL N64 !!! The pinouts of the video DAC and other chips is completely different on N64's from other Countries !!! (although, it would be easy enough to change the design for these chips).
The N64 has custom names printed on most of the chips, so determining the pinouts of the chips often had to be done using "equivalent" datasheets and is NOT a straightforward process...
eg. the N64's RAMBUS chips have custom names, so I had to find a datasheet which corresponded as closely as possible to the original board layout. It wasn't easy, but I found that the Oki MD5764802 datasheet was a good match, and made sense with the physical testing of the actual N64 chips.
Determining the RCP pinouts was a LONG process of using the datasheets from as many sources as possible to cross-reference the pinouts. Most of the pins connect directly the the CPU, and I already had the datasheets for the NEC R4300i CPU (which is the equivalent of the N64 CPU - also made by NEC). There were only one or two pins which didn't appear to correspond to the datasheet, but that's where the voltmeter comes in...
You have to use the voltmeter to check which pins of the CPU connect to the RCP and which pins connect to power rails such as GND / 3.3v / 5v / 12v etc. Some of the pins connect directly to GND or 3.3v compared to what the datasheet says (again, "equivalents"), so a lot of double-checking was needed to be absolutely sure.
The same process was then applied to all the other components...
The audio DAC datasheet is the Rohm BU9480F. The video DAC pinouts were mainly taken from sites such as gamesx, or from Destop's site. As it happens, Destop had also been working on the pinouts way before I started, so the schematics could be compared, and quite a few bugs were fixed.
So, there's a fair bit of work to do before sending off for a real PCB to be made, but I'll take a look at finishing the last few chips anyway.
With all the FPGA work, I now have a very good understanding of how the N64 and RCP work. If there are any specific questions on the chip signals etc, I should be able to help.
The FPGA stuff is coming along (SLOWLY)... The RDP block is now capable of processing "triangle" commands, and drawing the pixels of the polygons. I can't test this on a real chip atm, as I need a decent FPGA board with video output and some framebuffer RAM.
Almost all of the FPGA Verilog code has been translated from the MESS C++ source. Mooglyguy has been working on maintaining the N64 part of the MESS source, and his blog has been an invaluable resource. I've only recently begun to understand what on Earth he was talking about!
...
http://moogle-tech.com/blog/?m=200804
The challenge is that the FPGA design needs to resemble the physical design on the N64 more closely than an emulator does (obviously). These are many processes which are done in parallel on the N64 where an emulator almost everything a-step-at-a-time. So, I've had to try and visualize how the real N64 is put together, then translate that into Verilog code using the MESS source for reference.
Again, don't hold you breathe on this. The RDP needs to be finished, then the CPU and RSP blocks need to be coded. Then there's the the issue of the RAM interface (I want to use DDR instead of RAMBUS). If it ever runs, it would then need some serious debugging. The only ray of sunshine is that whatever is fixed in MESS source can be applied to the FPGA design.
OzOnE.
Here's the link to the schematic files (unfinished)....
http://www.mediafire.com/?sharekey=6695 ... f6e8ebb871
I haven't looked into the schematic stuff since I started on the FPGA design. I've attached the most recent schematic / board files if anyone wants to finish it off?
It still needs the voltage regulator stuff and the video /audio DACs etc. These parts will probably need to be designed from scratch, so you'll need to find a part with the correct package size and pin spacing, then create a new symbol and "device" library for them. The audio DAC is just an SO-8 package, so that won't take long to make. I might look into this stuff later.
The biggest issue will be the routing of the PCB tracks / layers (Eagle doesn't calculate the track "timings" / capacitance AFAIK) - there are some very high speed signals on the N64 board (RAMBUS etc.) so I'm not sure how to go about routing the new board properly so that everything will run correctly. It might work OK if it just has a giant ground plane around all the signals and if the track routing is kept tidy.
The attached files should open with the freeware version of Cadsoft Eagle, which can be downloaded here....
http://www.cadsoft.de/download.htm
The "Nintendo 64.lbr" file from the zip should be copied into your Eagle library folder before opening the schematic / board files... eg. The default location of this folder for the freeware Eagle 5.4.0 would be...
C:\Program Files\EAGLE-5.4.0\lbr
Please note: The design currently has two RAMBUS chips on board (the full 8MB). So, if this design is ever finalized, you need to either use the chips from two official Nintendo (single chip) 4MB expansion paks, or the design can easily be changed to use just one 4MB chip to save space / power (it would be like a standard 4MB N64, but without the huge jumper pak).
Also, the pinouts and chips on this design correspond to my European PAL N64 !!! The pinouts of the video DAC and other chips is completely different on N64's from other Countries !!! (although, it would be easy enough to change the design for these chips).
The N64 has custom names printed on most of the chips, so determining the pinouts of the chips often had to be done using "equivalent" datasheets and is NOT a straightforward process...
eg. the N64's RAMBUS chips have custom names, so I had to find a datasheet which corresponded as closely as possible to the original board layout. It wasn't easy, but I found that the Oki MD5764802 datasheet was a good match, and made sense with the physical testing of the actual N64 chips.
Determining the RCP pinouts was a LONG process of using the datasheets from as many sources as possible to cross-reference the pinouts. Most of the pins connect directly the the CPU, and I already had the datasheets for the NEC R4300i CPU (which is the equivalent of the N64 CPU - also made by NEC). There were only one or two pins which didn't appear to correspond to the datasheet, but that's where the voltmeter comes in...
You have to use the voltmeter to check which pins of the CPU connect to the RCP and which pins connect to power rails such as GND / 3.3v / 5v / 12v etc. Some of the pins connect directly to GND or 3.3v compared to what the datasheet says (again, "equivalents"), so a lot of double-checking was needed to be absolutely sure.
The same process was then applied to all the other components...
The audio DAC datasheet is the Rohm BU9480F. The video DAC pinouts were mainly taken from sites such as gamesx, or from Destop's site. As it happens, Destop had also been working on the pinouts way before I started, so the schematics could be compared, and quite a few bugs were fixed.
So, there's a fair bit of work to do before sending off for a real PCB to be made, but I'll take a look at finishing the last few chips anyway.
With all the FPGA work, I now have a very good understanding of how the N64 and RCP work. If there are any specific questions on the chip signals etc, I should be able to help.
The FPGA stuff is coming along (SLOWLY)... The RDP block is now capable of processing "triangle" commands, and drawing the pixels of the polygons. I can't test this on a real chip atm, as I need a decent FPGA board with video output and some framebuffer RAM.
Almost all of the FPGA Verilog code has been translated from the MESS C++ source. Mooglyguy has been working on maintaining the N64 part of the MESS source, and his blog has been an invaluable resource. I've only recently begun to understand what on Earth he was talking about!
...http://moogle-tech.com/blog/?m=200804
The challenge is that the FPGA design needs to resemble the physical design on the N64 more closely than an emulator does (obviously). These are many processes which are done in parallel on the N64 where an emulator almost everything a-step-at-a-time. So, I've had to try and visualize how the real N64 is put together, then translate that into Verilog code using the MESS source for reference.
Again, don't hold you breathe on this. The RDP needs to be finished, then the CPU and RSP blocks need to be coded. Then there's the the issue of the RAM interface (I want to use DDR instead of RAMBUS). If it ever runs, it would then need some serious debugging. The only ray of sunshine is that whatever is fixed in MESS source can be applied to the FPGA design.
OzOnE.
Here's the link to the schematic files (unfinished)....
http://www.mediafire.com/?sharekey=6695 ... f6e8ebb871
Ooops...
Apologies, but I attached the wrong file in the zip. It was supposed to contain the .brd file, not the .dsn file! I'm just adding the audio DAC too, so I'll attach the new file when I'm finished.
As a side note, there might be some problems with opening the files using the latest version of Eagle. It might start saying "file corrupted or opened with an illegal version". I get this all the time, and I'm not even using a cracked version. I am using version 4.13 though, so it seems to cause problems if the files are opened with different versions?
I'll just finish this first, then attach the new files. We'll have to sort the other issues as they happen.
OzOnE.
Apologies, but I attached the wrong file in the zip. It was supposed to contain the .brd file, not the .dsn file! I'm just adding the audio DAC too, so I'll attach the new file when I'm finished.
As a side note, there might be some problems with opening the files using the latest version of Eagle. It might start saying "file corrupted or opened with an illegal version". I get this all the time, and I'm not even using a cracked version. I am using version 4.13 though, so it seems to cause problems if the files are opened with different versions?
I'll just finish this first, then attach the new files. We'll have to sort the other issues as they happen.
OzOnE.