Nice work!

Edit:
Actually, I was able to get the Nspire emulator running in translated mode now since I changed a certain part of my code, and it runs... really fast. I don't think there should be any worries

The translator should work with anything, unless you either repeatedly store to memory that was previously used as code (which will slow it way down, since it wipes all translations on this kind of store - this could be improved), or store to memory that is ahead in the current basic block of code (very perverse thing to do in my opinion, I've seen it fail on real CPUs before ). If anything else broke it, I would like to hear about it...

Quote from: Builderboy on December 07, 2009, 10:00:11 pm

Any reason you are using 16ths and 8ths instead of just 1/6th for all?

Because that would require division. Eww.

The truly correct way to do grayscaling is more complicated even than that:

• Perform gamma expansion on all three channels. Gamma expansion is the non-linear relationship from video input signals (R', G', B') to the amount of energy emitted by the display (R, G, B). On a typical CRT monitor, this can be approximated with the power law x = x' ^ 2.2. (The Game Boy Color uses an LCD instead, so I don't know what the equation for it is.)
• Calculate the luminance. This is a weighted average of all three channels, which takes into account that the human eye is more sensitive to green light than red, and more sensitive to red than blue. The traditional formula is Y = 0.299R + 0.587G + 0.114B, but it really depends on the color space used on that particular display. (Not everyone agrees on just what "red", "green", and "blue" are.)
• Perform gamma compression, the inverse of gamma expansion.

Some people forget the gamma operations, which results in saturated colors ending up too dark.

I've thought about this subject a bit and I don't think a C compiler for Z80 would really be practical. The Z80 architecture is badly suited for C (or any other compiled language, really) for several reasons:

• in C, the normal way to pass arguments to a function is on the stack. On most modern processors, you have a stack-relative addressing mode, so this is fine. Z80 has no easy way to access elements of the stack below the topmost, so the only sensible way to pass things into a function is through registers. But the question of which registers are best to use is dependent on the function itself, and to some extent its callers. C requires standardized calling conventions in order to be able to have separate compilation of multiple source files; a compiler can't generate the code to call an external function if it doesn't know how that function expects its arguments passed.
• Register allocation on the Z80 is a very complicated problem. On most processors, registers have few if any differences between them - if it works on "R0", it works on "R7". On the Z80, every register has its own special purposes, so deciding what to put where becomes more complicated.
• When C programmers want an integer, they usually just type "int". This poses a problem for the Z80, since "int" has to be at least 16 bits long. On today's processors, 8-bit, 16-bit, and 32-bit operations are all the same speed, but on the Z80 anything bigger than 8-bit takes up more time and space.
• Also, in C integer types are signed unless you explicitly say "unsigned". More often than not, it doesn't matter whether a variable is signed or unsigned so programmers just use signed integers to save typing. Unsigned comparisons can be done easily on the Z80 (just use the carry flag), but signed comparisons require that the sign flag and parity/overflow flag be XORed together. Modern processors have conditional jump instructions that do just that; the Z80 doesn't.

I strongly doubt that a C compiler could ever produce Z80 code anywhere near as well as a person writing assembly could. As a result, C games would require a lot more memory, which is in short supply on the Z8-based calculators.

TI calculators do have degree-minute-second conversion, which can be used as if it were hour-minute-second. For example, suppose you want to add the times 1:23:45 and 3:45:01, type 1