Close
0%
0%

Wreck it Ralph Raspberry Pi project.

Wreck it Ralph, making the magic happen for real.

Similar projects worth following
This project is too build a video game system where characters can actually more from machine to machine in real time, as in the Disney movie Wreck it Ralph. I thought that this was a very interesting idea, so I wanted to know what it would take to do so, and make it happen.

In the Disney movie "Wreck it Ralph", arcade characters sort of had a "Toy Story" spin on them, where they basically were alive in a way, having their own identity/personality/free will when the games were in idle. One additional thing to this was that they could move from their primary game into others, via a surge protector their arcade machine was connected to.

As a computer programmer of many years, I knew this was silly, programs don't work that way. But it got me thinking, what would it take to pull this off? To actually move an entity, as a whole, from one program to another in real time, without interrupting the normal operation of the independent OSs, and not just a simple, hide the character in one machine, and show it in another type cheat?

The idea of the application is to allow characters to move from machine to machine, copying their GFX, SFX, and machine code to a central device, once there, all it's data is deleted from the original machine's memory. This central device will then move the data to the next machine.

I chose a baremetal environment for the project as I wanted the quickest boot time, plus I have the most control over instruction/memory layout.

Challenges of using a Linux based kernel is that boot time is slower, not a real time OS, memory management is a pain and too slow.

The Kernels start at address 0x8000, where the stack, exception/interrupt vectors are set up, and other special CPU stuff like the MMU/VFP/NEON. The ARM architecture is very good for relative based code/data offsets, so moving binaries around across systems only has an issue with the MMU, which I'm only using the supervisor mode, with no read/write/execute restrictions.

Each OS/game at it's core must be

capable of sending information about it's environment, whether it's a side-scroller, top down view, FPS, 2D/3D type views. Also gravity, physics, life/score/time/spawn systems and human interface devices information.

While each entity also must be capable of interacting in all of these environments. For example, a Pac-Man character in a side scroller must only move left and right, and must not move up and down, unless the physics/level rules dictate other wise.

Each game must have a special zone where entities may leave or enter the system. Upon doing so, all pointers, code, graphics, palettes, SFX associated with that entity, will be copied to the central system. Upon upload verification, all of this data is deleted, relinquishing the human interface devices, and the kernel will no longer make calls to the entities' now missing sub routines. Each system must not know that a entity is missing by a simple marked flag in memory, but only by the lack of feedback from the entities' interactions with the environment.

Each entity will occupy a slot in the the system it resides in, this slot retrieves data from it's particular human interface device data from the environment and the kernel will make calls to the entities' sub routines via pointers.

All systems are connected to one another via I2C. If a system is powered off and a visiting entity is present, then it will cease to exist until it's original system is restarted. This poses an issue of character duplication, a solution to this could be to keep character data external to the kernel, upon initial startup, it will be copied into ram, then deleted from storage. Doing an APB upon boot could also fix the issue, but this falls away from what goes on in the movie.

Right now the project uses 2 Raspberry Pi Bs, and one Raspberry Pi B+2 as the central hub. All 3 are connected to 17" monitors, I have a wide variety of controllers to use. I use 3 ATX power supplies, one for each monitor, and RPI.

My plan is to have Fix it Felix Jr., a central hub program, and PacMan or Donkey Kong running on the 3 systems.

Using multiple Raspberry Pi Zeros would make this quite a simple task as some of the GPIOs can be stacked together via headers. 5V, GND, I2C lines, or use a parallel bus.

  • 1 × Raspberry PI B + 2
  • 2 × Raspberry PI B
  • 3 × 17" LCD monitors
  • 3 × ATX power supplies.
  • 2 × NES controllers

View all 11 components

  • Pac-Man YouTube video.

    tehaxor6903/24/2016 at 22:33 0 comments

    Here is a video of the Pac-Man game in action. Still needs some more work done.

  • More PacMan and memory mapping.

    tehaxor6903/24/2016 at 16:10 0 comments

    Testing how the PacMan program behaves without PacMan around.

    Making use of the memory mapping was a fairly simple way of moving around machine code without complications.

    CHAR0-CHAR3 is where I put the moveable characters.

    MEMORY {
        CPU_0C    : ORIGIN = 0x08000, LENGTH = 0x008000
        CPU_0D    : ORIGIN = 0x10000, LENGTH = 0x008000
        
        DATA    : ORIGIN = 0x18000, LENGTH = 0x800000
        
        CHAR0    : ORIGIN = 0x880000, LENGTH = 0x010000
        CHAR1    : ORIGIN = 0x890000, LENGTH = 0x010000
        CHAR2    : ORIGIN = 0x8A0000, LENGTH = 0x010000
        CHAR3    : ORIGIN = 0x8B0000, LENGTH = 0x010000
    }
    
    
    SECTIONS {
        .CPU0_C : {
            *(.init)
            *(.CPU0_ASM_)
            *(.CPU0_C_)
        } > CPU_0C
    ...

  • Relocatable Code and RPI 3.

    tehaxor6903/19/2016 at 03:15 0 comments

    Testing dynamically relocatable assembly subroutines for characters, works on local machine, remote machines are next to test.

    Recently obtained a RPI 3, testing to see if it can be a suitable central hub, Aarch32 mode may differ enough to cause compatibility issues.

  • I2C works.

    tehaxor6902/21/2016 at 23:05 0 comments

    The Raspberry Pi has a independent Master I2C device, and a independent Slave I2C device. It is interesting that a Raspberry Pi can talk with itself, due to the fact that both units are separate from each other.

    Data transmissions are limited to 400,000Hz, which is very slow for multi megabyte entities to be transferred quickly. I'm trying to keep the transfer times below 5 seconds, that limits the data to about 128Kb per entity/character. Now I need to test with live subroutines.

    I might end up using a 10 pin(8 Bit) parallel bus to speed up the transfers.

    Poling the NES/SNES controllers takes up way to many CPU cycles, so I've decided to use interrupts for them, the ARM timer works pretty well for this, the BSC~I2C Master/Slave units both generate their own interrupts. This is really only an issue with the 2835 chip, the 2836 is a quad core, so one core can poll everything over and over again, without much of an issue of waisted CPU cycles.

  • Title screens ready.

    tehaxor6902/13/2016 at 04:14 0 comments

    Got the frame buffers up and running on all systems. Programmed a simple title screen for Fix It Felix Jr. and Pac-Man.

View all 5 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

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