Nice project, BlakPilar. Have you considered using a bytecode parser as the base of your compiler? TI-BASIC is very close to bytecode with the pre-tokenized functions, so it'd probably save a lot of work.

Request: Full math support. I know it's kind of obvious, but sometimes it annoys me to waste time writing simple functions (that take a long time to execute on-calc) in PC math languages that could be done very quickly in TI-BASIC.

Also, the ability to call external programs would be nice.

Actually, all of the normal primes would be prime according to that definition, since no other number evenly divides them. I'm not sure where Xeda's going with that, though, since integer factorization is only NP-complete if the numbers are prime relative to the set of natural numbers.

Yeah, that might be a better choice. Get a life, don't waste your time doing useless autistic things on your calculator. Get to know people, talk to girls, drink, smoke pot, stay intelligent, etc. Go enjoy life.

1) Google the word "Autism."

2) Remember that all forums are inherently totalitarian and we will have no problems banning you if you continue breaking the rules.

Yeah, it's just hard to keep track of your typing when the page scrolls every ten three seconds.

It should be. Telnet basically allows you to implement the raw underlying IRC protocol.

Hello everyone, I'm SitarKnight, I joined this community after seeing some videos of the TI-Nspire and TI-84 Plus playing games. One of the things that really got my attention was the video of the gameplay for Desolate. It totally inspired me to wanna go out and buy a calculator (which I don't yet have) and learn how to make my own games. (which I know nothing about and would appreciate some help on the matter)
I don't really have any background with programming, but I'm willing to learn. Any advice would be highly appreciated:) Thank you for reading.

What calculator you should get depends on what you want to do.

If you want a large base of existing software to learn from and play with, the 84+ series is your best bet. It has a lot of existing stuff like Axe, many active developers, and it's fully hacked as well as extraordinarily well documented.

If you want a lot of memory as well as a good BASIC, then the 89's and other 68K calculators are nice. However, they have almost no developers remaining and finding help may be difficult.

If you want the best hardware, the Nspire series has it. However, it's very difficult to ensure future compatibility and TI tends to block exploits, meaning that running code is often difficult.

If you want the platform with the most potential*, the Prizm is the way to go. You can program for it in a number of languages, it has a useful (if slow) implementation of BASIC, and the hardware is far better than the 84+ series. It even has a high resolution color screen, so that you can draw those pretty images that the 84+ can't. The main problem is that the Prizm is so new that a lot of programming tools and documentation don't exist yet.

There's also the HP calculators, which are insanely good at math, but tend to be rather user unfriendly and lack almost any sort of community.

*I'll admit to being a bit biased

You shouldn't have to overclock the Prizm to get a high framerate. At 58 Mhz a framerate of over 30 hz should be possible. What method are you using to draw the video. A slowdown will occur if you use pixel on commands instead of using the VRAM as a buffer. Also if you did any compression that would contribute to the slow down.

A framerate of 20Hz is the maximum I would expect with the OS screendraw routines.

The Khavi project is once more active, since I now have a reasonable way to debug the program.  Because writing an interpreter framework capable of interpreting serious language bytecodes like Java and Lua is a monumental task, there's obviously a lot of stuff that has to go together for it to work properly.

Uncompleted features:

• Full multi-threading support
• Privileges
• Shell dependencies/interfaces
• Interpreter run-time libraries
• Native interfaces and external libaries
• Boot code
• Memory management (distinct from garbage collection)
• Garbage collection

The Languages:

• Java bytecode:
  
  Currently being written and debugged.
  
  Khavi will accept both specially prepared .sh3 files containing Java bytecode and normal .class files when it opens a file. However, it does not accept .jar files, mostly because I don't have enough information on them to write a parser capable of handling arbitrary files. If anyone would like to point me to some decent documentation for them, I'd be happy to consider adding support for the filetype.
   
  
  Quote from: Hello world

  getstatic java/lang/System/out Ljava/io/PrintStream;
  ldc "Hello, world"
  invokevirtual java/io/PrintStream/println (Ljava/lang/String;)V
  return
  

  
  
• Lua bytecode:
  Currently being written and debugged.
  
  Please note that the following is Lua bytecode. You can still write in Lua as long as you compile the code ahead of time. I currently use Lua for Windows as my compiler and have found it to be an excellent development environment. Khavi does not and will not interpret standard Lua files (.lua). These contain plaintext representations of the lua and are beyond the scope of the Khavi framework. In the future, extensions may be made to allow their use, but they will not be part of the interpreter itself.
   
  
  Quote from: Hello world

  getglobal     ; print
  loadk          ; "Hello World\n"
  call
  return
  sizek (2)
  const type 4
  string size (6)
  "print\0"
  const type 4
  string size (13)
  "Hello World\n\0"
  

  
  
• Brainf*ck:
  Currently being debugged.
  
  This is in here mostly as a joke and because I like the language. It also has the honor of being the first 3rd party interpreted language on the Prizm.
   
  
  Quote from: Hello world

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

  
  
• Khavi Scripting Language (KSL):
  Incomplete. The interpreter has only been partially written.
  
  Khavi scripting language will be used in the native interfaces, while booting the VM, in thread management, in shell interfaces, debugging Khavi, etc... Basically, it's a language designed to be insanely fast to interpret, use as little memory as possible, and still remain editable on-calc. As the following example demonstrates, I don't expect anyone to actually want to learn it...
   
  
  Quote from: Potential Hello World syntax

  |0000|0001#02|0603^%48656C6C6F20776F726C640D00

  
  

Technical information:

The Khavi framework is designed to assume as little as possible about the underlying code as possible. At present, the only assumption it makes is that it is parsing an underlying bytecode.

Also, here's a simplified graph of Khavi's control flow and general structure.



Latest release:

Sorry, no releases are publicly available at this time.