Well, with rule 4 I think that Nspire fails because it does have wireless communication. But then again, it would be pretty obvious if you have the huge wifi adapter sticking out on top.
Don't forget ndless 3.1. I am replying to the first post in this thread. They did a great job, and ndless running nDoom was showed on TCAP last week.
qazz42 wrote:
Well, with rule 4 I think that Nspire fails because it does have wireless communication. But then again, it would be pretty obvious if you have the huge wifi adapter sticking out on top.
Well, that's why it's a separate module, and such an obvious one at that. If I ever design my own calculator, I've debated whether I would have a removable wireless module and forgo the QWERTY keyboard, but I've almost decided it's not worth it. aeTIos, ah yes, I saw a video of that somewhere, I think; do you have a link to the Youtube video? KermMartian wrote:
qazz42 wrote:
Well, with rule 4 I think that Nspire fails because it does have wireless communication. But then again, it would be pretty obvious if you have the huge wifi adapter sticking out on top.
Well, that's why it's a separate module, and such an obvious one at that. If I ever design my own calculator, I've debated whether I would have a removable wireless module and forgo the QWERTY keyboard, but I've almost decided it's not worth it. aeTIos, ah yes, I saw a video of that somewhere, I think; do you have a link to the Youtube video?hmm, perhaps you could have it so that a LED light starts blinking if you enable wifi, although TI tried something like that, and look where that got them
Indeed, the trick is to have the CPU have no control whatsoever over the LED for it to be effective. Anyway, we're getting off-topic. Let's get back to the Nspire vs. the Prizm.
So Kerm, what do you think of the new Ndless for the CX? Doesn't it really improve matters?
Also, the Prizm doesn't support 83/+/84/+ grade ASM. Only C. And programming for the CX has been improving.
(note: I didn't read all the posts before this. I do not have that kind of time because I'm working on the Casio Prizm Online Training Course right now.)
Also, the Prizm doesn't support 83/+/84/+ grade ASM. Only C. And programming for the CX has been improving.
(note: I didn't read all the posts before this. I do not have that kind of time because I'm working on the Casio Prizm Online Training Course right now.)
CalebHansberry wrote:
Also, the Prizm doesn't support 83/+/84/+ grade ASM. Only C.
Correct me if I'm misunderstanding, but are you claiming that the Prizm only supports C programming? If so, that's pretty patently false.
C seemes to be the only one anyone mentions for it. Is there a more powerful language for it than C? I am mainly saying that it doesn't support Assembly.
If a platform supports C, it supports assembly. It's a matter of bloat, really. C is a high level language, at least compared to assembly, and with that abstraction comes that bloat. The C is translated down to machine code in the end. The reason why people don't often use C for the TI calculators is that they just can't really handle the wasted space. The prizm can though, and C is many times easier to work with than assembly, so it's the preferred choice.
Every device with a processor supports assembly. We have members who have written programs in pure SH3 asm. There just isn't much point when you have a good C compiler.
Obviously, when you write a program in C, it compiles into ASM. My idea of it was this: that you could program in any language, but they would all be compiled into ASM, so it seems to me that programming in ASM would give you more options than programming in a language that then compiles into ASM.
CalebHansberry wrote:
Obviously, when you write a program in C, it compiles into ASM. My idea of it was this: that you could program in any language, but they would all be compiled into ASM, so it seems to me that programming in ASM would give you more options than programming in a language that then compiles into ASM.
Not really. A good programming languages can abstract away all the underlying details on the assumption that you don't want to know them, but if you explicitly ask it to let you access them, it will happily let you. Thus, you can write C programs that never worry about memory at all, but you can also directly manipulate memory and addresses from C programs if you'd like. Hell, you can write the majority of your program in C so that you don't have to remember the callee-save/caller-save function details of your architecture and all that jazz, then a few small chunks in inline ASM where you really need direct access to the processor or hardware. Quote:
So Kerm, what do you think of the new Ndless for the CX? Doesn't it really improve matters?
Ndless for the CX makes a difference between "no access to native code" and "some access to native code", which is an important step... but by no means enough.
Compared to the programmability of e.g. TI-Z80, TI-68k, Casio Prizm, HP-49G+/50G+ platforms, the programmability of the Nspire platforms sucks, and will always suck, unless TI makes a very, very unlikely U-turn.
The next OS version for the Nspire series is supposed to be released for or around the T3 conference (like last year), i.e. in less than two weeks. IOW, native code programming will disappear, once again, from the latest OS version for the Nspire series.
We can hope that it won't disappear, and we'll highly rejoice if it doesn't - but it is simply unreasonable to assume that it won't disappear.
Quote:
The reason why people don't often use C for the TI calculators is that they just can't really handle the wasted space.
That's true for TI-Z80 calculators, because the Z80 ISA isn't designed for C programming and has few registers. C compilers targetting the Z80 usually generate code that makes Z80 ASM programmers puke.
However, for TI-68k and Nspire calculators, a large majority of programs are written in C
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Might I say that no one has even mentioned Prizm BASIC? I know it's not Lua par, but it's a lot better start than the Nspire's original BASIC... people say to "let the Nspire mature", but forget how long it's been in production now, >5 years? The prizm hasn't been out for even two years yet, so I think we have a lot more to see come from it than the Nspire at this point. Comparing the Prizm hacking/development timeline to the Nspire one since ~2007, it's been opened up for C development twice as fast, and from Casio's sentiment it's almost entirely likely it'll at least stay the way it is now.
Alright, if y'all think C beats ASM, I'll give it to you. I just want to avoid a cultish devotion to either side. What I do not want is to be classified as a Nspire fan.
I think the only point in using assembly is when there is no good alternative, or if you just really really like handwriting the whole thing manually because then you are not bound to any mechanism and you can optimize down to the metal.
However, there is no one language that is "best" for everything, or even "best" for low-level programming. For example, though I do agree with Kerm that C is THE best language for low-level control in general, I'm designing OPIA because I feel that I can provide "better than C" for a raw z80 platform by customizing the language to be so (e.g. providing all the mechanisms necessary for full computational power, but no more than that; and then restricting code to that model. ... None of these mechanisms stray from how it would best "done" in z80 assembly)
However, there is no one language that is "best" for everything, or even "best" for low-level programming. For example, though I do agree with Kerm that C is THE best language for low-level control in general, I'm designing OPIA because I feel that I can provide "better than C" for a raw z80 platform by customizing the language to be so (e.g. providing all the mechanisms necessary for full computational power, but no more than that; and then restricting code to that model. ... None of these mechanisms stray from how it would best "done" in z80 assembly)
Another important area for assembly is where you need extremely accurate timing, like emulation.
I'm an nspire fan in that I have one but to be fair, it was before the prizm was even announced, and after ndless 1.1
I'm an nspire fan in that I have one but to be fair, it was before the prizm was even announced, and after ndless 1.1
Important status update: unsurprisingly, but sadly, the head of TI's education division has made it quite clear to Adriweb, who discussed with her face to face, that the next OS version for the Nspire, will block Ndless (in its current form).
* Adriweb's original report from TI's T3 event, containing a summary of the statements of the head of TI's education division, written in French, is: http://tiplanet.org/forum/viewtopic.php?t=8856 .
* for an English-speaking news, see http://ourl.ca/15405 , critor's take on the event.
* in http://tiplanet.org/forum/viewtopic.php?t=8857 , I've publicly released the large blurbs of informative text I spent huge amounts of time writing to top-level TI executives, in a direct communication. That was two months ago, before the first Ndless 3.1 public beta.
Not that we had any serious hope of convincing TI how they could make a win-win situation out of the current lose-lose situation, but at least, we'll have tried to take advantage of our direct contact with high-level executives at TI, for the sake of both the open development community and TI
(said direct contact was kindly made possible last year, by a former TI consultant, after the release of OSLauncher and critor's tutorial)
* Adriweb's original report from TI's T3 event, containing a summary of the statements of the head of TI's education division, written in French, is: http://tiplanet.org/forum/viewtopic.php?t=8856 .
* for an English-speaking news, see http://ourl.ca/15405 , critor's take on the event.
* in http://tiplanet.org/forum/viewtopic.php?t=8857 , I've publicly released the large blurbs of informative text I spent huge amounts of time writing to top-level TI executives, in a direct communication. That was two months ago, before the first Ndless 3.1 public beta.
Not that we had any serious hope of convincing TI how they could make a win-win situation out of the current lose-lose situation, but at least, we'll have tried to take advantage of our direct contact with high-level executives at TI, for the sake of both the open development community and TI
(said direct contact was kindly made possible last year, by a former TI consultant, after the release of OSLauncher and critor's tutorial)
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
» Go to Registration page
» Go to Registration page
» Goto page Previous 1, 2, 3 ... 16, 17, 18, 19 Next
» View previous topic :: View next topic
» View previous topic :: View next topic
Page 17 of 19
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement