Anybody have any reccomendations for 1.2.3 mods that I should get?

Optifine and Rei's minimap, along with the Water Shader and GLSL mods if your graphics card can handle them. That's the true Minecraft experience.

EDIT: edited in the GLSL mod suggestion

But now me and quibigo have no more chance to return to 666 respect

It seems that the source includes x86 assembly code, so that would have to be rewritten for the target processor (whether it be ARM or SuperH)

Not only does some of the code appear to be horribly outdated 16 bit x86, it's important rendering code that's fairly hardware dependent and according to the readme, very unoptimized for a modern CPU. It'd take a heck of a lot of work to get that code to run well on a calculator, even if you somehow managed to compile it.

EDIT:

I know almost nothing about the Prizm, but from common knowledge, a program like ndless would have to be made to run wolfenstein on the prizm. Also, if not a direct port, a raycaster would have to be made for the prizm, which if it there is already one, someone would have to program wolfenstein. Also, I don't think think that it would run very fast, but I don't own a prizm, so feel free to downrate my post if I am wrong.

It would be nice for prizm users to have something like ndless on their prizms. Maybe you or another prizm programmer can see what needs to be done to run c on the prizm. I might eventually buy a prizm since TI is being stupid with the nspire again.

Unlike the Nspire, the Prizm runs C without Ndless. It took less than a month for us to figure out the file format necessary and get a proper compiler working. That said, the Prizm doesn't have a full standard library and there's a good chance the source would require more support.

Sorry, I've been working on another more important project lately. This one has kind of stalled in the meantime.

1) I already released an ASM arbitrary precision math library with the basic functions awhile back, so...
2) I would like this
3) Meh, I'm fine with the font personally
4) The vast majority of people don't know the difference between Log() and Log_n(). Using Log_N() instead of the standard Log() would be confusing and strange to most users. I personally think it's better to keep it the way it is (and have an option to choose?)
5) It's already allowed though. All we really need is proper documentation.

I was going over some security stuff and I remembered how computationally expensive it was to sign large quantities of data with public key algorithms. It got me thinking about how the Nspire would have to sign an entire OS if it didn't use hash of sorts and...

That bytecode would be more suitable for a register based VM, which is what I highly recommend unless you have a specific reason for choosing stack based (like portability to very memory limited systems).

The source will be interpreted directly for difficulty purposes (Creating a virtual machine etc.).
EDIT: Meaning creating bytecode would be too hard.

Creating bytecode is largely the same process as interpretation at the simplest level... If you want to apply optimizations to the bytecode, that's different and can be much more complicated, but just mapping language to bytecode should be relatively simple with a solid language/bytecode design. I've found it's a good sanity check for a language that it is easy to generate a bytecode based on code in that language. If it's not easy, then the language is too complex. Let's take a while loop as an example:

While(A>0){
B=B+1;
C=C+2;
};
Let's try parsing this to bytecode:

TEST_GREATER(A,0); // Tests if arg1 is greater than arg2 and returns 1 if it is, 0 otherwise.
IF_NOT_GOTO(ANS,+6); // If Not(ANS) is true, then GOTO the opcode 10 commands after this one (code after the while loop)
INC(B,1); // Increment B and store result in ANS
SETVAR(B,ANS); // Store the incremented value of B to the variable B, overwriting the old value
INC(C,2);
SETVAR(C,ANS);
GOTO(-6); // GOTO the opcode 6 opcodes before this one (The condition test)
As you can see, generating a bytecode is basically equivalent to making the interpreter understand the code at all. One reason why bytecodes are so often used is that it's a lot faster to parse the one or two bytes that make up a typical opcode than it is to parse a potentially multi-lined script over and over again, when the work really only needs to be done once.

If the above bytecode looks like Assembly, that's because that's exactly what you're generating! Assembly code for a virtual machine.