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.