Copy Link
Add to Bookmark
Report

Interfacing a PC and a Nintendo 64

Nintendo64's profile picture
Published in 
N64 various
 · 6 Oct 2019

After my first splurge with the N64 I needed to take a long break. After several months I finally came back to work. My final goal, which I regretfully never fully reached, was to interface a PC and a Nintendo 64. However, the reason I never reached my goal was more a lack of time than a conceptual flaw.

The N64's cartridge reader has 48 pins. Therefore I went down to the local parts store and purchased a SCSI ribbon cable. Simple to work with, and it has 50 pins. Next I needed a component I could connect to a cartridge so I could split the signal to the PC. I ordered a 50 pin 2.64 inch socket connector from Newark Electronics.. I split the SCSI cable in half, then soldered one end of the two cables together. Next I soldered the combined end to the socket connector. I used male header and heat shrink wrap to make sure my connections were good, and tested them along the way with a voltmeter.

One end of the SCSI cable I plugged into the N64 (which had its socket connector removed), and the other end I used to test the signals on the N64's bus with an oscilloscope. If you follow my steps, you'll need to remove the paneling on top of the Nintendo 64 to get to the socket connector. Before you attempt to use your N64 make sure to screw the paneling back on after you remove the socket connector. The Nintendo 64 loses its' ability to diffuse heat without the paneling.

Now that I could play Mario Cart while watching it all go by on an oscilloscope I needed a way to interface it to a PC. I called Newark Electronics again and ordered a ISA prototype card. This, regretfully, is where I ran out of time. The interface card comes with a chart for where the pins are mapped on your motherboard's bus. After investing a decent amount of time in research you should be able to figure the hardware aspect out.

The last major difficulty is the device driver. I was working under FreeBSD this time around. I developed a scanner and parser for a mach N64 language I created. I'm not aware of all the N64's opcodes, so I emulated them. My code could easily be edited to include the real binaries. After my scanner and parser was working I started developing bus/driver emulation code. It's a bit buggy, but all the concepts are there. I use signals between the two process to communicate. Again, it would only take some research to adapt my code into a real device driver.

My Workspace is a snapshot of what my work bench looked like... I'll admit it's a bit messy. I was short for space! Oscilloscope findings is a table of the pin-outs for the N64 cartridge reader. The ISA Prototype Card is a brief look at that card. My code describes the included files, the scanner, parser, bus, and driver code. Porting Linux is a page describing how it is possible to port linux to the N64.

My Workspace

Interfacing a PC and a Nintendo 64
Pin it

It may be a bit messy, but it was an effective place to work. This is about all the room I had to work in.

Oscilliscope Findings


Using the data from when I traced the pins on the cartridge reader, I compared it to my findings using an oscilloscope. The scope I was using could only go up to 20 Mhz, while the N64 bus is functioning at 93.75. Therefore I can only speculate about many of the data lines, and their functions. Data - Low/High means that that data line stays Low/High while it is idle. Low means it might be data, or Vss. High is Data or Vcc.

 
Pin # Leads to: Oscilloscope Reading:
1 Vss Low
2 Vss Low
3 RCP Pin 58 Low
4 RCP Pin 54 Low
5 RCP Pin 52 Data - Low
6 Vss Data - Low
7 RCP Pin 50 Data - Low
8 RCP Pin 46 Data - Low
9 Vcc Data - Low
10 RCP Pin 44 Data - Low
11 RCP Pin 40 Low
12 RCP Pin 38 Low
13 Vss Data - Low
14 Vcc (12V from SW1 Pin 7) Data - Low
15 RCP Pin 34 High
16 RCP Pin 32 Low
17 Vcc High
18 U6 Pin 5 High
19 U6 Pin 1 Data - High
20 R4300i Pin 110 (ColdReset*) Data - High
21 Vss Data - Low
22 Vss Data - Low
23 Vss Data - Low
24 R21 to Vss (200 Ohms) Data - High
25 Vcc (12V from SW1 Pin 7) Vcc - 12V
26 Vcc (12V from SW1 Pin 7) Vcc - 12V
27 Vss Data - Low
28 RCP Pin 57 Data - Low
29 RCP Pin 53 Data - Low
30 RCP Pin 51 Data - Low
31 Vss Data - High
32 RCP Pin 47 Data - High
33 RCP Pin 45 Data - High
34 Vcc Data - High
35 RCP Pin 41 Sync
36 RCP Pin 39 Data - Low
37 RCP Pin 35 Data - High
38 Vcc (12V from SW1 Pin 7) Data - High (I/O?)
39 Vcc (12V from SW1 Pin 7) Data - High
40 RCP Pin 33 Data/Sync/I/O?
41 RCP Pin 31 Low
42 Vcc Low
43 U6 Pin 3 Low
44 R4300i Pin 57 (JTCK) Low
45 U6 Pin 7 Low
46 U4 Pin 14 Low
47 Vss Low
48 Vss Low


The ISA Prototype Card

Interfacing a PC and a Nintendo 64
Pin it

This is what the card I ordered looked like. One side is Vcc, the other Vss. The charts which came with it are extremely useful, as they describe which pin is for which IRQ, and so on.

My Code


 
Created: 5/7/98
By: Alex Reeder
Implementing the grammar defined in grammar.txt, parser.c takes an input
file written in N64 Speak and converts it into N64 Native. The N64 Native
code is then executed via the device driver.
Using output from my parser (~odo/c/cs71) driver places it into shared
memory. bus then takes the data from shared memory and writes it out to
a file. The two programs communicate via signals - SIGUSR1. By one
program reading the data in and putting and raising registers, the other
reading which register it is, then getting the data, I simulate a device
driver.
Here's the interaction between the two processes:

_bus_ _driver_
------------------------------------------------------------------------------
Wait for SIGUSR1 from driver. Run init for shmget and
shmat. Send kill(pid,SIGUSR1)
to bus, driver's ready.
------------------------------------------------------------------------------
Got SIGUSR1 from driver, write Wait for SIGUSR1 from bus.
my pid, and send SIGUSR1 to
driver. Set waitdata.
------------------------------------------------------------------------------
Wait for SIGUSR1, and loop Raise the first line, send
until SHUTDOWN line is raised some data, issue SIGUSR2
by driver. Write data out file. until finished, then raise
SHUTDOWN.
------------------------------------------------------------------------------
File Names: grammar.txt - The N64 Speak grammar specifications.
parser.c - The parser.

parserv.c - A verbose parser which prints out the grammar tree as it parses.

parser.h - The include file for parser.c If one wishes to add opcodes you can just #define them, and add a line of code or two in parser.c . It also makes looking at valid commands simplier. Changing the binary value only requires editing the #define as well. The include file for driver.c The same used by parser.c ... driver.c uses to make sense from the input data from the input file.The include file for driver.c The same used by parser.c ... driver.c uses to make sense from the input data from the input file.

input - An example input file.

output - An example of what output looks like.

project.txt - A log of my work on the device driver through 5/7/98.

driver.c - The device driver.

bus.c - The N64 bus emulator.

shared.h - Locations of files, such as the pid files, input file, and definitions for registers in binary.

driverinput - An example input file.

Porting Linux to the N64


Porting linux to it shouldn't be impossible, even if it is difficult. The N64's controller architecture at least allows for the possibility of alternative devices (I have read somwhere that it used a microcontroller, which communicated with the console, allowing for virtually unlimited buttons,etc.) If so, both a a keyboard and a mouse could be converted, with only moderate difficulty.
Burning linux boot code to ROM, and inserting it in a cart would take care of the boot process. Or one could use the interface between a PC and their N64 to do this as well, just have the computer listening, and give the same responces as a cartridge.

This leaves only the question of storage to be answered. Using the interface again, your storage problem is the size of your hard disk. To run Linux from your PC you'd need to have a 100 Mhz bus, since the N64's is traveling along at 93.75 Mhz. In addition to the boot code, OS code could be put on the cartridge since it can hold 64 MEGS.

This is the next big project I'm probably going to work on when I take my next look at the N64.

← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT