A Nintendo NES powered robot.

Similar projects worth following
The goal of this project is to build and program a Nintendo NES to drive motors and servos. We want to build it so that the NES can power our bot without any internal modification. The plan is to use the expansion port connector on the bottom of the NES.

We are going to strive to use the NES processor as much as possible, and not rely on a microcontroller to do all the heavy lifting. This means that the program must be executed from a real cartridge, just like it would back in the day. 

Some of the expansion pins are mapped to the directly to the cartridge. Since the NES CPU has very little periphals, we could place any needed peripherals (for example, a timer) in the cartridge itself.

Right now, we are programming the cartridge using Atmel EEPROM chips and a hand modified cartridge.

NES-NEEPROM-256 rev 1-0-0.PDF

A cartridge converted to use two AT28C256 EEPROMs

Adobe Portable Document Format - 455.93 kB - 09/13/2017 at 16:06


  • 1 × NES Frontloader

  • Getting back on track

    Nick Overacker10/08/2017 at 18:14 1 comment

    I have had a busy start to my senior year, and am still trying to get on top of everything. But, I believe I will be ready to give a fun demonstration during the weekly Mercury Robotics meeting on Wednesday. Here's the gist of it.

    NES Expansion Port PinoutTaken from the NesDev wiki

    The NES has a 48-pin expansion port on the bottom side, hidden behind a plastic panel. Of these, only a few are directly controllable by software. Therefore, in order to have fine control over a large number of peripherals, it will be necessary to add a little bit of external logic.

    To this end, we have mapped the address bits 14-12 to the EXP pins, giving us access to a total of four address bits (A15 is already on the expansion port). This allows us to implement peripherals as memory-mapped IO, specifically mapped to $DXXX in our case. That is, any time the NES executes a read instruction at an address whose most significant nibble is 0xD, the external logic will wake up and execute some instruction based on the state of the signals OUT2 and OUT1.

    I'll follow up with a video if this test works, but here's the snippet of FPGA code that I am loading to a DE0-Nano for the external logic. My first attempts used an Arduino, but it was ultimately too slow for this application.

    library ieee;
    use ieee.std_logic_1164.all;
    -- Mercury Robotics NESbot test
    -- This pairs with the NESbot demo code
    -- mapping directional buttons to an RC controller.
    -- Peripherals mapped to  $D000
    -- Controls use D2 and D1.
    entity exp_to_rc is
      port (
        addrClk    : in  std_logic;                        -- GPIO_00
        addr       : in  std_logic_vector (15 downto 12);  -- GPIO_01,03,05,07
        contrOut   : in  std_logic_vector (2  downto 1);   -- GPIO_02,04
        goForward  : out std_logic;                        -- GPIO_10
        goBackward : out std_logic;                        -- GPIO_11
        goLeft     : out std_logic;                        -- GPIO_13
        goRight    : out std_logic;                        -- GPIO_15
        fpgaSelect : out std_logic                         -- LED_0
    end exp_to_rc;
    architecture rtl of exp_to_rc is
      signal TEMP_goForward  : std_logic := '0';
      signal TEMP_goBackward : std_logic := '0';
      signal TEMP_goLeft     : std_logic := '0';
      signal TEMP_goRight    : std_logic := '0';
      signal TEMP_fpgaSelect : std_logic;
      signal clk             : std_logic;
      fpgaSelect      <= TEMP_fpgaSelect;
      TEMP_fpgaSelect <= addrClk and addr(15) and addr(14)
                         and not addr(13) and addr(12);    -- 0b1101 = 0xD
      clk             <= TEMP_fpgaSelect and addrClk;
      goForward       <= TEMP_goForward;
      goBackward      <= TEMP_goBackward;
      goLeft          <= TEMP_goLeft;
      goRight         <= TEMP_goRight;
      process(clk) begin
        if rising_edge(clk) then
          TEMP_goForward  <= TEMP_goForward  xor (    contrOut(2)     nor contrOut(1));
          TEMP_goBackward <= TEMP_goBackward xor (not contrOut(2)     and contrOut(1));
          TEMP_goLeft     <= TEMP_goLeft     xor (    contrOut(2) and not contrOut(1));
          TEMP_goRight    <= TEMP_goRight    xor (    contrOut(2)     and contrOut(1));
        end if;
      end process;
    end rtl;

  • New schematics coming soon...

    Matthew09/13/2017 at 01:40 0 comments

    One of the things I've had to do while working on this project is to draw out a schematic for my cartridge. There is one schematic in particular which shows up a lot. It is a scanned document from 1992. I've already found several problems with it while diagnosing my newly installed NESRGB board. A lot of times, either the pin number or name is wrong. I've also found errors with the reset circuitry, so I don't trust this document 100%.

    Anyway, one the problems I've had is a mix up between PPU pin A13 and A13_N (NOT A13). So, I finally decided to just trace it from the NES motherboard:

    • PPU_A13 goes to pin 65 on the motherboard, which then goes to the enable pin of the ROM
    • PPU_A13_N goes to pin 58. On the cartridge it is usually jumpered to pin 57

    I think eventually I will just start a project redrawing the entire NES schematic...

  • Resurrecting NES Hardware

    Matthew08/09/2017 at 23:20 0 comments

    Since this is my first post, I will do an introduction.

    Hello, I'm Matthew. I am an electrical engineering graduate and 1/3 of the robot team. I have a knack for fixing things, but I don't like just hacking things together. I'm the kind of guy who would design a PCB for a mod rather than leave wires loose inside. I programmed the PWM for my LEDs to have a curve because the brightness of an LED is non-linear to our eyes. It didn't matter if no one else noticed it. I had to do it because it just didn't look right. I'm the guy at your workplace with the obnoxiously loud mechanical keyboard.

    I've worked on robotics teams before. I consider myself an expert C programmer, but I run the other way when it comes to assembly language. Whereas Nick, other the hand, takes pleasure in diving head first into the 6502 instruction set. So, when he talked about making an NES robot and using the original CPU I was on-board immediately. I hope to learn some 6502 assembly from him during this project.

    For this project I'll be working on electrical design as well as anything necessary to makes things go smoothly. Whether that be building a programmer, drawing up schematics, hacking cartridges to accept newer EEPROM chips, or even fixing Nick's oscilloscope.

    I'll be putting up schematics on the Github page soon of the EEPROM cartridge that we're currently using. In my research, I've found a lot of pinouts and diagrams which were just ASCII drawings. I want to eventually redraw some of these NES schematics to make them look a little more professional. 

    I got another NES from eBay yesterday for my own personal use. When I took a look inside, I noticed something wrong with it. So for the end of this post, I will leave you with a link to my PSA about putting the cartridge tray back together properly.

  • $8000 | Androids dream of whatever you want

    Nick Overacker08/07/2017 at 01:17 1 comment

    Saluete and はじめまして, and also a "hello" for good measure. My name is Nick; I am a computer engineering student with a fetish for languages, both the natural and computer kinds. I like traveling, bit-banging, bending the universe to my indomitable will, and kind of medium-shortish walks on the beach. I'm also bad at self-introductions, so I'll stop there.

    Let me tell you a little about this project. We (Matthew, Fernando, and I) are returning contestants in the OSU Mercury Robotics Challenge. We have all participated several times in the past, but this is the first time we are pooling our talent together as a team. We have all had our experience with the basic process of designing and building a robot from scratch; it's a challenge, but it's the same challenge we have already solved repeatedly. We want to do something new.

    A couple years ago, I found Jon Erickson's Hacking: The Art of Exploitation at my local bookstore, and I also read Kevin Mitnick's Ghost in the Wires. These awakened an already barely-latent fascination for using devices in ways that their designers had never even dreamed of. It wasn't long before my mind turned to my dust-covered NES; I opened the case and was surprised to discover that there was a hidden expansion port underneath it. I knew then that my next robot was going to be built with the Nintendo Entertainment System.

    I took a one-year hiatus from engineering as an exchange student in Japan, then assembled a team as soon as I returned. We are now starting to gain some momentum, and the way forward is getting clearer every week.

    Expect more updates as we continue to make breakthroughs. We will share our work here, and finalized designs will be available for all to see. This will be a non-destructive console mod; the robot's program will run exactly like a regular game cartridge. The only direct rework necessary will be to break the cover from the expansion header underneath the console.

    That's all for now. We are happy to answer questions and take suggestions!

View all 4 project logs

Enjoy this project?



Dr. Cockroach wrote 10/09/2017 at 11:53 point

Now this I can get into... My wife has a couple Nintendo 64 units and always wondered what if.... I might just have another future project :-)

  Are you sure? yes | no

davedarko wrote 10/08/2017 at 21:32 point

Huge fan of this idea! Pretty awesome!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates