JCAP Log #3: Propeller 1
The Propeller 1 (officially known as the P8X32A) is an impressive 32-bit 8-core RISC microcontroller programmed using either a high-level proprietary language called Spin, or a form of assembly called PASM. A wide array of standard programming languages are also able to be compiled for the Propeller, most notably C and BASIC. Several other projects using the Propeller as a foundation for a video game system (such as the HYDRA Game Development Kit) have showcased the microcontroller's abilities and proven make it a perfect fit for this project.
The P8X32A works by implementing a round-robin exlusive resource access methodology via a rotating "hub", which switches shared resource access between each of the 8 individual processors, called "cogs":
Propeller 1 Block Diagram
Each cog operates independently of the rest, meaning different code can execute on different cogs in parallel. They can "communicate" by accessing the shared memory in the hub, and storing/loading data during their memory access window. This is the only period of time where they have access to the hub, and each cog has this access for 2 cog clock cycles (or 1 hub clock cycle, as the hub runs half as fast as the cogs) every 16 clocks. Calling a hub access instruction causes the cog to wait for its access window before proceeding, with each hub access instruction taking 8 clock cycles on the cog. This means that code can be organized in such a way to optimize hub access.
Round-Robin Hub Access
Once the first hub access instruction is executed, the cog is "synced" with its hub access window. If each access takes 8 clock cycles, and the window occurs every 16 clock cycles, then 8 clock cycles remain for other instructions before the next window. Since most non-hub-access instructions take 4 clock cycles, you could execute two of these between each hub access instruction, and each access instruction will be called right when the access window is open. This means the cog doesn't have to stall to wait for its window; a relatively paltry performance gain, but makes the execution of instructions much more deterministic.
Best/Worst-Case Hub Access Waveforms
PASM code is loaded into a cog via the Spin cognew function with an argument pointing to the starting address of the code. With a 32-bit architecture, the memory space is divided into 32-bit longs, 16-bit s, and 8-bit bytes. Each cog has 2K of RAM: 496 general purpose registers (for storing executable instruction code for example) and 16 special purpose registers (the control registers for the counters, video generator, GPIO pins, and other features). With each instruction being one long long, you can load a maximum of 496 instructions into a cog, minus however much cog RAM you declare for variables. This does constrain the size of your code somewhat, but for most applications, almost 500 lines of code is more than sufficient. Additionally, specialized compilers have been developed to create a "large memory model" or LMM on the Propeller 1, allowing single programs to span several cogs seamlessly.
Cog Memory Space
The hub has 64K of memory, divided into 32K of RAM and 32K of ROM.
The most significant benefit and primary reason for using the Propeller as the backbone for JCAP is its implementation of video generation hardware within each Cog. This reduces development time, and introduces a level of security and confidence in the hardware concerning the ablity to generate a VGA and/or composite TV video signal:
Video Generator Output Schematic
In order to develop the drivers for the low-level subsystems such as video, sound, and input, the Propeller's RISC assembly language PASM will be used as finer and more deterministic control is needed over the microcontroller. The game logic itself will be developed with C (Spin is also an option, however C is a more ubiquitously known language). The game logic will be connected to the PASM subsystems via simple Spin connective tissue which for the most part simply instantiates variables and loads PASM routines into the Cogs. This paradigm may be refactored to eliminate the need for Spin entirely down the road, however that's a bridge to cross when we get there, and optimization should never precede functionality.