I noticed a thread on TI-Bank where someone said his TI-Nspire CAS drained a set of batteries by 50% in one day while testing out some programs... Power consumption is a very annoying thing in that you can't ignore it even though it's practically impossible to measure it effectively

I suspect that it's mainly the Nspire's 90MHz CPU that can be a power hog, so it's important to make sure we idle it properly when nothing is happening. The way to do this is with the wait-for-interrupt instruction (mcr p15, 0, SBZ, c7, c0, 4), which is executed by the idle() function in libndls. However, this instruction is only useful if the interrupt that wakes the CPU up is acknowledged. Otherwise, next time around, the interrupt controller is already asserting to the CPU that an interrupt is pending, so the instruction just returns immediately.

Presently, Ndless programs run with the CPSR I bit set on the CPU, so the OS's IRQ handler is not run, and IRQs never get acknowledged unless a program does so explicitly. I think libndls should have a delay routine that keeps the CPU idle by acknowledging timer interrupts as they come, something like this:

// Idle for n/100 seconds
void delay(int n) {
int irq_mask = *(volatile int *)0xDC000008;
*(volatile int *)0xDC00000C = ~(1 << 19); // Disable all IRQs except timer
for (; n; n--) {
asm ("mcr p15, 0, %0, c7, c0, 4" : : "r" (0)); // Wait for an interrupt to occur
*(volatile int *)0x900A0020 = 1; // Acknowledge timer interrupt at source
*(volatile int *)0xDC000028; // Make interrupt controller stop asserting nIRQ if there aren't any active IRQs left
}
*(volatile int *)0xDC000008 = irq_mask; // Re-enable disabled IRQs
return 0;
}


Here's a new version. With touchpad support (I can finally play it on my own calculator ) and source code included.

I think what you're looking for is augment(myArray,{666}).
A way to do it "in-place" is 666→myArray[7]. This might be faster, but I haven't tested.

Thanks for pointing out the directory problem.  I hate using hex for that kind of thing, I always make a mistake like that.
As for virtual pages, it sounds like a great idea to start.  However, it would get pretty inefficient, pretty fast.  Imagine you're several GCs into the usage of the filesystem.  The virtual pages end up completely different then the normal ones.  When looking for file entries, or reading from a stream, crossing page boundaries becomes very slow - you'd have to swap through every physical page until you find the virtual one you need.

Could you keep a copy of the virtual->physical mapping as a table in RAM? With a 1-byte entry per 64kB sector, it should only take 32 bytes.

Let's try to guess what the remainging free space (with no user documents in memory) will be.
4Mb on the basic TI-Nspire, and 6Mb on the CAS TI-Nspire ? We wouldn't be able to play nDoom any more!
They've finally found out how to prevent students from using Ndless and playing games: after the "no programming", comes the "no memory"!

Using a modified nspire_emu, modified boot2, and modified OS, I got a screenshot of what it would look like if the TI-Nspire had 128MB of flash, like the CX, instead of just 32MB. If we take TI's claim that the CX has 100MB of storage available, this suggests that OS 3.0 is no more than 3.7MB larger than 2.1. (Note it could be smaller than that, since the 100MB figure might just be rounded down, so don't get outraged just yet.)

bsl: How do you launch the Datalight command shell? I looked, but I never found any way to call it, besides running an Ndless program of course (which can't be done without USB)

TI just said you couldn't use the TI-84+ keypad - maybe they'll make the emulator accessible with the normal TI-Nspire CX keypad. It has more keys than the TI-84+, so they would just have to make a simple key mapping.