A few days ago a friend in my math class introduced me to the game Core Wars, and I immediately decided to port it to the calculator!  Core Wars is a two player competitive game, featuring a unique type of gameplay.  The two contestants must each write a program in Redcode, which is the programming language of the Core.  Each program is then inserted into a section of memory called the Core.  If either program stops executing, that player loses.  Of course it is simple to make a program that never terminates when left on its own, the tricky part is that both programs live in the same memory (the Core) and so can influence each other.  The programs must try to find their opposing program and sabotage and destroy it in order to halt it's execution.  It's the greatest battle of a programmers ingenuity, as they pit their own programs to destroy others in The Core!

Redcode:
   The programming language of The Core is called RedCode, and is like a simplified version of assembly.  There are only 18 possible instructions, but many different modifiers that make each instruction powerful.  The instructions are formatted in a very specific way that is consistant for all instructions:

NAME A B
NAME is the name of the instruction.  The name also indicates the type of instruction, and what it does.  The A and B field both hold numbers, and in general data passes from the A field into the B field.  The instructions are specifically:

DAT: If any process tries to execute a DAT command, that process is killed.  A and B field can be used to hold data.
MOV: Moves data from A into B
ADD: Adds A to B and stores the result into B
SUB: Subtracts A from B and stores the result into B
MUL: Multiplies A and B and stores the result into B
DIV: Divides B by A and stores the result into B
MOD: Divides B by A and stores the remainder into B
JMP: Moves program execution to location A (B is ignored)
JMZ: Jumps to location A if B is zero
JMN: Humps to location A if B is not zero
DJN: Decreases B and jumps to A if B is not zero
SPL: Starts a new process at location A
SEQ: Skips the next instruction if A and B are equal
SNE: Skips the next instruction if A and B are not equal
SLT: Skips the next instruction if A is less than B
NOP: Does nothing, guess you could use this to hold data as well.
There is more than these instructions, and A/B than is just told here, and there are some good tutorials that I will LINK to in order to help keep this post shorter, and to probably help better explain as well. 

One element I do want to cover though is the SPL instruction.  It says that it creates another process at location A, but what does that mean?  Processes in Redcode are handled a very specific way.  If you have two processes, each process will run twice as slow as if you only had one process.  In other words, creating new processes does not give you any more computing power.  If you had 3 processes and your opponent only has 1, then execution might look something like this:

Player 1 Process 1
Player 2 Process 1
Player 1 Process 2
Player 2 Process 1
Player 1 Process 3
Player 2 Process 1
As you can see, Player 2 was able to execute 3 instructions in his one process, while each of your processes were only able to execute a single instruction.

Conclusion/Plans:
  Now the game hasn't been completed yet, but I do have the majority of the instructions implemented, as well as an assembler and a working interpreter.  I will be updating the tutorial part of this thread as time goes on, but in the meantime feel free to visit This tutorial as well.  The syntax is slightly different since we don't have access to the same characters as they do, but I will be posting more on syntax in the future.  For now I will leave you with this screenie of what the game screen will look like!  It features the two program's names, as well as showing how many processes they currently have.  The square in the center is a visual representation of the Core, and shows how the programs move through and modify memory.  The two other squares are each programs private memory areas.

Update!  Both the assembler and the interpreter are complete!  Every command is functional and tested (hopefully) and programs can now compete successfully Now all that is left to do is to set up the UI, and start having wars!

It's not played over the link port, so that would be a bit weird methinks The programmers write their programs separately, and then only need to get them onto the same calculator in order to run the competition.  I do hope that we can set up a competition though

this is brilliant!
i can't wait to test it out against you folks

Progress is still chugging along!  I found a bug or two in the interpreter involving post-incrementing on the A operator, and I'm working on fixing that now, as well as getting the UI up to speed.  Memkit is really helping a lot, and the UI should be finished relatively soon.  I will be adding options to provide different core sizes, as well as running multiple games back to back.

It would probably just be easier to send the program using the built in TiOS interface.  You would still be connecting via linkport, but you could disconnect as soon as the program was transferred.  No reason to force the users to be connected through the entire game when they only have to be connected to send the program, especially when it would add a whole bunch of unnecessary linking code.

Each pixel is a single instruction.  If the instruction is a DAT instruction the pixel is white, and black otherwise. 

Very soon!  I'm currently working on getting all of the UI elements coded, and after that is done there should be many screenshots to be had ^^