Animated shot here (linked because it's about 5MB)
Firefox recommended for fullspeed, since I actually got it over 10fps this time using camstudio

Looks nice! How is the color pallet being handled?

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

Or you could just multiply by .1666 and call it good .  I assume you are doing somthing similar to that with 3/16 = .1875?

Ohhhhh i see now.  Well, it seems to work pretty good!!  I think i may have to stop reading this thread for a while for the better of my health

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.

Nice work!

Quote from: calc84maniac on December 01, 2009, 03:22:03 pm

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: calc84maniac on December 07, 2009, 10:02:20 pm

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.

Yeah, my color conversion is pretty much just a placeholder for now. By the way, is the emulator's speed accurate? I mean, I added a delay loop of "loop subs r8,r8,#1 \ bne loop" when r8 contained 400,000, and that was for each of 60 frames. That loop should be 4 cycles per iteration, right? That adds up to delays of more than 90MHz, which doesn't add up.

Edit:
Oh, and I did use self-modifying code for a bit, but it was pretty unnecessary (hence why I didn't get it in translated mode sooner)

By the way, is the emulator's speed accurate? I mean, I added a delay loop of "loop subs r8,r8,#1 \ bne loop" when r8 contained 400,000, and that was for each of 60 frames. That loop should be 4 cycles per iteration, right? That adds up to delays of more than 90MHz, which doesn't add up.

It's not accurate. Right now, it just assumes all instructions are one cycle, or 1/90 microseconds. If your computer is not fast, it can lag, however. A tight loop like that is very likely to lag; I would recommend adding a few dozen repetitions of a simple instruction like "mov r0,r0" which nspire_emu can execute very fast.

This kind of "busy-wait" loop is a bad way to do timing in general (wastes energy, doesn't take into account time taken up by other code) but I can certainly understand if you're not willing to write code to deal with timer interrupts yet, considering that future updates to nspire_emu would almost surely break it.

Edit:
Oh, and I did use self-modifying code for a bit, but it was pretty unnecessary (hence why I didn't get it in translated mode sooner)

I checked the ARM manual; it says self-modifying code "cannot be relied on without the use instructions to ensure synchronization".

EDIT: I've released a new version that puts graphics and keys in the same window, so it should be possible for you to record gameplay with CalcCapture now.