This is a love-hate thing for me. While I love the idea of backwards compatibility with TI-84+'s, the Extra keyboard is EXTREMELY tacky. As a Student, I can't imagine carrying that around with the calculator itself. My bookbag is stuffed as is, accessories certainly don't help.

I think it would be pretty interesting if they made the keyboard double sided so that you could pop it out, flip it around and put it back in without having to worry about keeping track of the other piece.

I think the RAM and ROM are in the keyboard piece - this would make making it double-sided difficult.

wrong. the ram and rom are stored in the calculator itself. By bridging the fourth and ninth pins on the calculator, you can start it up into the nspire mode. By replacing the 84 keypad, you can use it as if it were the nspire keypad. Therefore, the rom and ram are inside the calculator itself

From another page at Nspire "The cost to attend is $225. Each participant will receive a TI-Nspire handheld, TI-Nspire ViewScreen™ panel and TI-Nspire computer software." !!! Is it me or could you just go to one of these (it says they're for teachers, but hey, you 'teach' yourself right?) and get one of these pre-release or do you think they just give the calc to you for the presentation then get it back?

Argh, it uses a different viewscreen? Argh.

Well, the screen is probably a different resolution...

It is - 320x240.

Adding viewscreen support is expensive as it is, why not go through a little extra trouble and make the NSpire also compatible with old viewscreens? If you "make it fit" with either clipping to a 96*64 region (with pan-and-scan) or by scaling the entire display to 96*64 (users choice) then I think this could be very useful.

Apparently, the calculators should be available by "Back-to-school 2007"

which is only one year after original scheduled release date!!!

sorry, 2008.
two years, BOO TI

Where did you see 2008? The site says 2007.

I think he's referring to the Mac version.

I am referring to the fact that the npsire will be available in retailers 2008, and online 2007. It was stated i believe in the FAQs.

So... just by switching the keyboard, it becomes an 84+? That's really awesome.

Does anyone know if the nspire is going to be programmer friendly? Because if it doesn't have a built-in programming language (like BASIC), I probably won't buy it.

The 84 module is definitely the 1337est part of the nSpire.

You misspelled "l4^^3". ;-)

Or make that "14^^3", my spelling wasn't 1337 enough. :-D

Anyone know if it will support a new type of basic programming or anything similar (VB, C++, Java :D)?

Also, will ASM be supported?

The only way I would buy one is if it had good basic programming. ASM support would be nice, but that can probably be hacked.

ASM support can always be hacked

Well.. its ARM and its not written in assembly itself. Think trying to hack ASM on a cell phone. It has TI-Basic though.

Whether its ARM or not doesn't matter. Every processor has some kind of assembly - ASM is only a representation for the binary that actually runs on a processor. Given enough time and creativity you can get assembly programs to run on a cell phone - how do you think people install Linux on their cell phones. Moreover, how do you think the cell phone's OS is programmed? In C, sure, but that compiles to assembly.

Never heard of ARM assembly?

Now, it might not be trivial to hack this machine. There are no "memory backups" (byte-for-byte memory dumps) or even low-level binary formats in use like in the good old ZShell and Fargo times, instead they use XML.

By the way, they might actually provide assembly support for these machines, though the prototypes don't have it, in fact they don't even have TI-BASIC programs, only functions (which, like on the 68k calculators, are forbidden from using most instructions, i.e. no Disp, no keyboard input etc.!). Programmability is supposedly "not decided yet" or "pending on technical difficulties" depending on who you ask. So it's probably premature to discuss hacking the machine.

XML??? Oh no, not another case of the horrible "Using XML in *anything* will make it better!" mindset...

Sadly, it's exactly that. I also think XML is way overrated and overused. Most uses of XML could be replaced with one of:
* HTML (not XHTML)
* INI ([Section] Key=Value) files
* compact binary data files
which are all better suited to the respective tasks they were designed for.

What's wrong with XHTML?

That there was nothing wrong with HTML 4 which merited changing from SGML to XML, that it requires redundant /> instead of > on tags where in HTML, the SGML DTD _knew_ there's no closing tag needed, that the error-handling mandated by the standard is draconian (a single error and the page won't parse at all! The only reason browsers accept broken XHTML is that it's actually being sent with an HTML MIMEtype, which is done because M$IE doesn't support XHTML at all) and that it feeds invalid HTML to older browsers (the /> stuff - well, if you take SGML pedantically, it IS valid SGML, but it should be interpreted as ">;", so the browser should display a ';' after every tag closed like that! The XML compatibility spec for HTML actually REQUIRES browsers to violate the SGML standard!).

Well, not really. Most browsers just ignore the '/'; I don't think I've ever seen a true valid SGML parser that supports autoclose shorthand.

SGML has a problem that XML doesn't - it depends on having a list of which tags need closing and which tags don't - and where tag closing is implied and where it isn't - which makes the parsing overly complex as well as make it hard for old parsers to understand new tags.

In SGML, <img> and <br> tags are never closed, <p> tags and <li> tags are closed either by the next <p>/<li>, by an explicit close, or by the closing of the parent tag or the opening of another block-level element. This adds complexity to the language. In XML, it's pretty straightforward: All tags should be explicitly closed.

The '/'s shouldn't be interpreted as '>;'. In true SGML, <p>Text.<br />More text.</p> would be interpreted as <p>Text.<br></>More text.</p>, which would be interpreted as <p>Text.<br></p>More text.<[invalid tag]> ('</>' means "close last open tag"), which would be rendered mostly the same way - not that any browser actually understands </> or any of the other SGML shorthands. It's true that it violates the SGML standard, but no browser in existence actually implements the part of the SGML standard it violates, so might as well upgrade. After all, no browser has had trouble with the large number of XHTML pages served using an HTML mimetype.

I agree that the rules for XHTML error handling are overly strict, but I like the syntax itself; it's much more consistent than HTML.

Well, the way I see it TI calcs are superior to HP and Casio calcs mostly because of the huge and active community. If it wasn't for the applications made by (mostly) DS, I'm not sure if I'd prefer a TI over an HP/Casio.
If the NSpire doesn't support assembly, or even if it merely doesn't allow community code to tie into the OS (like Apps on the 83+/84+ can do through hooks), I'm not overly optimistic about its chances of being the coolest calc out there...
Ofcourse, that's only my two cents.

Aaaaugh! Why are you asking for Visual Basic, Java, or C++? Those are probably the worst languages for calculator programming. Style issues aside, they're verbose out to Wazzu, and require lots of alphabetic typing. BrainFuck or Perl might be better.

Java or C++ wouldn't be bad, though I'd prefer to see Objective-C (a nice, loosely typed language). Perl or Python I could see (they might actually get me to learn Python).

Nobody really programs in brainfuck. Trust me.

Come to think of it, I'd rather program in binary than in brainfuck.

public void loadArray( URL file, Object drawable ) {
if(file == null) return;
this.file = file;
if(drawable != null) {
if(drawable instanceof Applet ) {
applet = (Applet)drawable;
} else if(drawable instanceof Graph2D) {
graph = (Graph2D)drawable;
graph.attachDataSet(ds);
}
}
this.start();
return;
}

You still want to write structured code on a calculator? It goes off the side of the screen! I even have trouble with one-space indents in Basic sometimes. Not that I've done much calculator programming recently. :\

As much as I'm horrified at myself for saying it, TI-Basic is well-suited to calculator programming. It would be hard to alter a structured language in the same direction while retaining programmer-compatibility.

>> As much as I'm horrified at myself for saying it, TI-Basic is well-suited to calculator programming. It would be hard to alter a structured language in the same direction while retaining programmer-compatibility.

I'm in complete agreement.

>> You still want to write structured code on a calculator? It goes off the side of the screen!

I write code that goes off the side of the screen on my computer. I've written several-hundred-character lines lots of times.

Example (Applescript):
...
if button returned of (display dialog "Empty the trash on " & (POSIX path of dropped_items) & "?" buttons {"No", "Yes"} default button "No") is "Yes" then
...
end if
...

That's not completely fair, since you embed a string in there. Doing that will make your lines as long as you want them; just embed a nicely verbose error message in the line that raises an exception.
I try to adhere to lines of at most 80 characters and succeed almost all of the time (without being hindered by it!). Oh, just for the record, that is in Object Pascal (usually Delphi, every once in a while FreePascal).

Dude, you've got to be kidding me.

I'm like 99% sure there was a featured grayscale platformer here on ticalc.org made with brainf**k...I think....

Find me a program written in brainfuck that is actually useable and isn't a proof-of-concept.

Wasn't there a Super Mario game written in it or something like that?

Either way, brainf**k generally has a much cleaner syntax and produces much more compact programs.

Um. Are you talking about the same brainf**k I'm thinking of? The one for which a simple division operation is:

,>,>++++++ [- <-------- <-------- >>]
<<[
>[->+>+<<]
>[-<<-
[>] >>> [<[>>> - <<<[-]] >>]<<]
>>>+
<<[-<<+>>]
<<<]
>[-]>>>> [-<<<<< +>>>>>]
<<<<++++++ [-<++++++++>]<.

and Hello World is

++++++++++
[>+++++++ >++++++++++ >+++ >+ <<<<-]
>++. >+. +++++++. . +++. >++.
<<+++++++++++++++. >. +++. ------. --------. >+.
>.

I'm pretty sure branf**k doesn't have clearer syntax, nor does it produce more compact programs.

Dude, brainf**k is called "brainf**k", because it's syntax f**ks with your brain.

Personally, I think I'd love to see Python programming on a graphing calculator or small handheld computer. It would be easier, more powerful, and more enjoyable than TI-BASIC for large projects, in my opinion.

Python could actually make a very good calculator scripting language, if it was done right. One of its good points is that unlike on-calc-compiled C, Java, or something similar, it needs very few extra characters (like {, }, [, ]...) so programs would be easier to work with on-calc and would use up less memory.

Well, since we already have multiple kinds of braces for lists, indices, matrices and grouping of mathematical expressions (at least the 8x already have (), [] and {}), there is no problem. Well, except typing on a non-qwerty keypad; you will need names of variables and keywords (depending on whether they are menu-accessable as on the 8x)... :(
Anyway, I'm not too worried about indenting, don't forget the resolution of these things is far better than on the 8x calcs.

C++ should be possible with the NSpire's specs, assuming we can run compiled software at all. (Of course, C++ programs will require more memory than C programs.) Java isn't that great an idea on such a device IMHO (sure, it should be possible to run J2ME or something similar on a device like that, but it's going to be way slower than native code), and let's not talk about VB!

Heh, VB on a TI-Nspire. Maybe a WYSIWYG environment for C/C++ could be created though, eh? (Maybe TIGCC 2.0 plugin ;) )

Why in the world would you want a WYSIWYG environment for programming?

So that while coding, What You See Is What You Get....

I was only kidding anyway ;)