I'm curious what would happen if you run your program during PPT (if Ndless works in PPT), I would test it myself but I have a touchpad cas... so no Ndless.

I think you cannot run Ndless while in PTT, because you cannot access the /phoenix/documents folder.

But if we find a way, yes it would be very interesting.

Here's a video showing the program working (when it works, which is quite rare for now):

Hi!


I'd like to make a Ndless program able to control the LED present on the following models:
* TI-Nspire ClickPad
* TI-Nspire TouchPad
* TI-Nspire CAS TouchPad
(the TI-Nspire CAS ClickPad doesn't have that LED but has the circuit -> you might make a hole and solder it)

There are many uses for that LED.
It could be used in games as a won/lost or hit/missed indicator.
You might use it to indicate your mood of the day: red for "mad: don't speak to me today", yellow for "I'm in love", for example...
We might use it to communicate short answers: yes/no, little number...
We could also use it to communicate fully by using some king of Morse code.


The LED is documented on HackSpire and it looks quite easy:

90110000 - LED

    * 90110B00 (R/W): Control register
          o Bit 0: Set this bit to enable green light blink data. If green blink data iteration is not on, the green light state is read from bit 0 of green blink data.
          o Bit 1: Set this bit and bit 6 to enable green blink data iteration.
          o Bit 2: Set this bit to force green light off. Overrides bit 4.
          o Bit 3: Set this bit to force red light off. Overrides bits 5 and 13.
          o Bit 4: Set this bit to force green light on.
          o Bit 5: Set this bit to force red light on.
          o Bit 6: See this bit and bit 1 to enable green blink data iteration. Reset before modifying green blink data or delay.
          o Bit 9: Set this bit to enable red light blink data. If red blink data iteration is not on, the red light state is read from bit 0 of red blink data.
          o Bit 10: Set this bit and bit 12 to enable red blink data iteration.
          o Bit 12: Set this bit and bit 10 to enable red blink data iteration. Reset before modifying red blink data or delay.
          o Bit 13: Forces red light on if bit 4 is 0, or red light off if bit 4 is 1. (?)
    * 90110B04 (R/W): Green blink data. 32 bits of on and off state, represented by 1 and 0. Iteration is done from bit 31 to bit 0 repeatedly.
    * 90110B08 (R/W): Green blink delay (negative). OS sets this to -2048.
    * 90110B0C (R/W): Red blink data. 32 bits of on and off state, represented by 1 and 0. Iteration is done from bit 31 to bit 0 repeatedly.
    * 90110B10 (R/W): Red blink delay (negative). OS sets this to -2048.

Note: If red and green lights are on at the same time, the color becomes yellow.

I've made a simple program.

#include <os.h>
#include "console.h"
#include "screen.h"
#include "charmap.h"
#define LED_MODE_ADDR 0x90110B00

int getMem(int addr)
{ return *(volatile unsigned*) addr;
}

void setMem(int addr, int val)
{ *(volatile unsigned*) addr = val;
}

int main(int argc, char* argv[])
{ int mode_orig = getMem(LED_MODE_ADDR);
int mode_base = mode_orig&~0b01011001111111; //turn OFF + disable blink / iteration / force on-off
clrScr();
int mode_curr=mode_base;
int mode_last=mode_orig;
while(!isKeyPressed(KEY_NSPIRE_ESC))
{ mode_curr=mode_base;
if(isKeyPressed(KEY_NSPIRE_R) || isKeyPressed(KEY_NSPIRE_J) || isKeyPressed(KEY_NSPIRE_Y))
mode_curr |= 0b100000; // force RED on
if(isKeyPressed(KEY_NSPIRE_V) || isKeyPressed(KEY_NSPIRE_G) || isKeyPressed(KEY_NSPIRE_J) || isKeyPressed(KEY_NSPIRE_Y))
mode_curr |= 0b010000; // force GREEN on
if(mode_curr!=mode_last)
{ setMem(LED_MODE_ADDR,mode_curr);
mode_last = mode_curr;

disp("Written LED mode: ",0);
dispi(mode_curr,0);
displn("",0);

disp("Current LED mode: ",0);
dispi(getMem(LED_MODE_ADDR),0);
displn("",0);
}
}
setMem(LED_MODE_ADDR,mode_orig); // reset
return 0;
}
You need to press some keys to turn on the red or green colors.


And I'm getting very strange behaviours.

I've tested on 3 TI-Nspire ClickPad and 1 Ti-Nspire TouchPad.
On 2 of them, it worked the 1st time, but that's all... It never worked again!!!
On the 2 others, it never worked.

The LED just remains off...

Strangely, I've experienced many reboots, either when entering the program, either after exiting the program...
Very strange as I don't use any other pointer than the 0x90110B00 address. And it did reboot before I added the debug display.


Here's a sample log of the debug informations displayed on the screen (when it doesn't reboot):

Written LED mode: 0 // 1st loop
Current LED mode: 5699
Written LED mode: 32 // press 'R' key
Current LED mode: 5699
Written LED mode: 0 // release 'R' key
Current LED mode: 5699

You see?
I'm checking the LED mode just after writing it.
And it's allways 5699!
My values aren't written, or are modified immediatly...

How is this possible? I thought interrupts were disabled while running a Ndless program...


The fact that it worked 2 times (with dozens of tries) this evening, proves that this address is read/write, as stated on HackSpire.

But there seems to be some kind of checking/protection, whose reliability is strong, but not 100%.


Can you help me?
Do you have any idea what is going on?
Do you see some stupid things in my code?

Thanks.


Please find attached the last binary.

If you want to modify & recompile, you just have to get "screen.*", "console.*" and "charmap.h" files in the mViewer archive, and use them with the code above.
http://ti.bank.free.fr/index.php?mod=archives&ac=voir&id=2014

But I'm not even sure the Prizm is going to have a SD slot...

Here is mviewer2 beta build 2.


Clearing code (when zooming out) has been optimized in order to clear only a box (although you'll probably won't notice any speed improvement, as I have to wait for the screen...).

I've added the parsing image progress in the top right hand corner, as you've asked for.


Remaining minor bugs:
* strange zoom in some situations
* the contrast delay is causing problems when in 31 gray levels mode
* when going back to the 16 gray levels mode, display mode is not reset to RGB: you may end in BGR mode and so get a slightly darker image, until the next time you press 'C'


You may get a new release before the end of the week.


Todo list:
* develop a "safest" way of waiting for the screen
* test 31 gray levels mode, by changing the screen base pointer, instead of switching between RGB and BGR.
* test modes with more than 31 gray levels
* change internal data from 16-bits to indexed 8-bits
* include PNG support
* include JPEG support
* include GIF support
* iinclude PDF support

Here is my latest build of mviewer2.
It's not an alpha version any more: i've promoted it to a beta now!


* All graphic functions are now supporting both the standard 4-bits mode (16 grayscale), and the super 16-bits mode (31 grayscale).

* The 31 grayscale mode delay has been set to 40 (40ms very approximatively). This seems to produce the best display on both tested Nspire (a basic and a CAS ClickPad), because the screen must be done refreshing the previous "action".

* No data copy any more to refresh the screen. I'm using 2 identical buffers: onscreen and offscreen. I update the screen when needed just by setting the SCREEN_BASE_ADDR to the start of the offscreen buffer. The 2 buffers roles are switched this way: onscreen is becoming offscreen, and offscreen is becoming onscreen.

* New emergency key to immediatly turn the screen off, if you were about to be caught viewing something forbidden.

* The '"non-centered zoom" bug has been fixed. There is another minor zoom bug.


The 31 grayscale mode doesn't allways give you a better image. It depends upon the image. Images with areas including very similar adjacent grey levels are going to be wonderfull. You'll have the impression of not being able to count the grey levels in those areas any more.

In 31 grayscale mode, if you look carefully you'll guess which are the new 15 levels. Their display is not perfect. This seems to be related to the way the screen refreshes itself.


Here are the keys not mentionned in the readme from the stable link:
- 'C': switch between 16 grayscale mode and 31 grayscale mode
- 'Home' and 'Menu': increase or decrease the 31 grayscale mode delay (if you've got a "bad" display with the default delay - might be removed in the future, depending upon the tests results)
- 'Ctrl': turn the screen on/off




Future tests:
------------

The 31 grayscale mode is obtained by switching the color encoding from RGB to BGR alternatively.
The 2 different gray levels are stored in the R and B bits and then mixed on the screen, producing a new gray level.
There is another way to produce the new grey levels.
It is to have 2 screen buffers containing the different grey levels, and to change the SCREEN_BASE_ADDRESS alternatively between the starts of those buffers.
I wonder if this method would produce better/worse results...

By combining both methods, we could get (in theory) something like 48/64/... grayscale levels. I wonder how it would look like.
64 levels will be hard (propably impossible), because the total refreshing cycle would need something like 120ms. And the human eye is able to detect a 120ms delay.
With a 80ms delay, 48 levels is "limit" but might give something interesting.


Future features:
----------------
* If the tests are good (but don't be too optimistic), more grayscale levels.
* Going back to 8-bit data to spare some more memory.
* Supporting other image files: PNG/JPG/GIF.

It's similar.

I'm flashing between 2 consecutive gray values among the 16 standard ones, in order to get 15 intermediate grey values.

I just hide the 2nde value for each pixel in the blue color bits, and then alternatively swith between RGB and BGR color modes.
So nothing is copied or calculated.

Yes, you're right.

What?!?  Does that same link on TI-Bank work for the latest version?

It's just worked for the 1st time a hour ago.
This special version is not pubic for now.
It needs some more testing/debugging.
The internal buffered data was changed from a 4-bits to 16-bits.


But when I release it, the same link is going to work. And you'going to be informed first! :p

And it should even be faster. the screen refresh code is now only copying the screen content 1 time instead of 2, although it still uses buffering.


Guess what... the Nspire is wonderfull!!!
(why did we have to wait 4 years for that?... silly TI!!!)