Tossing my two cents.

I'm a relatively new guy in the calculator community, but I've read and experienced enough of TI's actions to not give the slightest damn about morality as far as they're concerned. Sucking TI's big corporate dick hoping they'll change their ways is ridiculous (does not apply to people like adriweb who have contacts), they won't change for an insignificant minority, that's how business works (and I fully understand them), deal with it.

Let's be honest, if I had a non-CAS calculator, I'd work on getting a CAS OS installed on it, would spare me a few bucks. If it was possible to control the LEDs, I'd probably write a PTT simulator just for the heck of it (not sure if I'd cheat with it though, it's not like I can't walk to class with PTT already activated, documents stuffed on it and pretend I just put it on). It would be a nice big "fuck you" to TI, and through my cynical eyes I'd probably enjoy the eventual aftermath. Either you bend down and adapt, or then you go against the flow, relish the advantages, and deal with the consequences.

In other news, I think changing the theme to a lighter, more modern and less "intimidating" one would encourage others to participate (no offence to whoever made the theme, just my view). I'm pretty positive there's a great deal of psychology involved, and many might have the tendency to go away or just quickly pass by if it looks too much like a concentration camp of weird and sweaty basement dwellers (yeah, you'll have to get used with my way of expressing myself). Think what you think, but that was what made me doubtful before I joined the party.

I've now added hardware 8 bpp on both TC (i.e. Touchpad/Clickpad) and CX models. In fact I restructured the code and there are now 5 different bpp modes: CX SW16 HW16, CX SW8 HW16, CX SW8 HW8, TC SW8 HW8, TC SW8 HW4 (where SWx HWy is software x bpp, hardware y bpp display).

I'm considering implementing double buffering and wondering if it's worth the trouble (in TC models it's unnecessary, no tearing thanks to the slow and shitty LCD). Also I need to fix some mouse issues and do some further fine-tuning before 0.2.0.

You'd have to fill the palette RAM with 256 grayscale color values

Oh of course, I was thinking about that.

each from 15 (black) to 0 (white)

So there after all is only 16 colors available? My main reason to even try to switch to 8 bpp is for some extra shades of gray, the speed increase is negligible.

AFAICT (from watching DummyOS changing colors smoothly enough), the grayscale screen can do 256 shades of gray... or at least, it can do more than 16 shades

If that's true, I might be more inclined to try 8 bpp out.

The normal 320 x 240 x 4 bpp screen area is stored in SRAM, but the 320 x 240 x 8 bpp area cannot be stored there, it needs to be stored in SDRAM. Upon exit, one has to make sure that the memory is freed and the screen base address pointer is restored, otherwise funny stuff will occur.
And reading from display memory stored in SDRAM might have some unwanted effects (-> critor ?).

If I have some documentation and facts I can rely on, it should be very possible to implement. SDRAM should never be read anyway, in nSDL's case all reads go through the buffer. I could just write some experimental code through a bunch of #if's like I've been doing until now and add a static library to the list (libSDL-TC8.a or something) for those who want to try it out. It might very well be that the advantages of having a 8 bpp display outweight the disadvantages of the rare occasion when the calculator explodes because of access violations.

The case for hardware 8 bpp mode, on Clickpad & Touchpad, would be to reduce the risk that Clickpad & Touchpad users are left in the cold for SDL-based programs.

How so left in the cold?

Just to give you a quick heads up, the next version--0.2.0--and rather major step, will have numerous changes. Among those will be mouse support, 8 BPP support for CX (thanks to atiatini for the idea; makes it possible to port 8 BPP programs for the CX), many font-related changes (if you're the observing type you can notice one thing on the screenshot below) and a lot of under-the-hood modifications (performance, stability, etc.). Also a few surprises. Quick screenshot to show 16 BPP and palettized 8 BPP on CX (actually it's just an excuse to give the thread some color):

I managed to get the mouse to work, at least to some degree. Some very weird bug shuts down the program at seemingly random moments, as you can see:



EDIT: After numerous tests it seems that it crashes (or whatever happens) if the mouse goes to the y-coordinate 9. I see no logical explanation for this bug.

The source code of Newlib's sqrt is this one:

http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libm/math/w_sqrt.c?annotate=1.1.1.1&cvsroot=src

_LIB_VERSION refers to the global variable __fdlib_version, I'm not sure why but it seems to require relocation, which cannot be provided by Ndless.
It actually doesn't work well without nSDL, it's just that the random access to memory falls to a valid address (but still not __fdlib_version).
I'm afraid we cannot trust any Newlib function without a full-featured relocator.

Can't Newlib "just" be recompiled with some nl_relocdata hacking meanwhile?

binutils: 2.21
gcc:      4.6.2
newlib:   1.19.0
gdb:      7.3.1

BTW, atiatini, meanwhile you could use the fast inverse square root function (used in Quake for example):

float inv_sqrt(float x) {
   union {
      float x;
      int i;
   } u = {x};
   u.i = 0x5f3759df - (u.i >> 1);
   return u.x * (1.5f - (0.5f * x * u.x * u.x));
}

It's quite "hackish", but just do 1/inv_sqrt() and you have an accurate and a very fast approximation of the square root.