It'd be interrupt based simply because there's no need to test for it within every thread and the thread manager in the interrupt table is the only code that's *always* executed. The thing about some interpreted languages is that the specifications sometimes force threads to be lockable, which means break code would otherwise have to run in every thread or risk being possible to disable.

Will this provide options for compressing code?  Java code can be extremely large, and the amount of memory a JVM takes up to implement all features is enormous and time consuming.  How does multithreading work with Khavi?  Up to what Java version will it support?  Will it support Java-based things such as Jruby, Groovy and *groan* Jython?  Will it only be an interpreter, or will it also have some sort of an IDE built in so you can write code on calc (because I personally dislike using a computer to code calculator stuff).  Will it have a terminal similar to one in something like Netbeans and Eclipse with full interaction, or just bare bones?  What's the time table for release, and what's the current progress?  What languages will be supported out of the box without further configurations?  How will the speed compare with Prizm C, or on-comp Java?  How will GC be administered, if it will be administered?  How will objects be treated in memory, and how will memory be allocated for them?  Will Java programs be able to access low-level things such as individual bytes in memory, or just the higher level stuff?  How many libraries will work for this -- most (if not all) graphics libraries for Java are platform-dependent.

Just a few things I thought of asking

Okay I'll take as many questions as I can
1. I've been wanting to implement zip, tar.gz, and tar.qz file systems on my shell system so that when Khavi is launched the code is temporarily extracted to be ran.
2. The amount of memory taken is based off the size of java code ran and however well the JVM is coded. Because this is low level coded the size will be much smaller then on your comp
3. Multi threading is handled using the WDT which is a countdown timer and generates an interrupt when it reaches 0. Upon reaching an interrupt the code jumps to an interrupt handler where a new thread is ran.
4. I doubt it will be any particular version as features from 6 may be included while features from 2 may still be missing.
5. Size is a little big for those programs, but it might be small enough to fit one of them. The only issue is that some of the libs are in native machine code so an SH3 port would be required.
6. Yes an editor could be made as a separate program, but you would still have to transfer the source to your computer for compilation.
7. It will probably just use my shell's default terminal, but that could be expanded for more features.
8. Time table, I wouldn't be the one to ask, but I'd say that it would never be done as more features could be added, optimizations to be made, and newer versions of java to support.
9. The progress so far is that the class loader Khavi is made so that now all the core Java features can now be made. This being the routines for the bytecode interpreter.
10. As in languages if you mean spoken languages then that would be English for now or if you mean prog languages then that would be Java, but Lua for Khavi is also in the works.
11. Well on comp Java is probably faster than Prizm C but because Java is the fastest interpreted language imho it should be up there. I would mention that floating point math will cause slowdowns as there is no fpu, but everything else will be fast because the Super H is well optimized for stack oriented languages such as Java. It will become even faster once JIT is supported.
12. I believe Qwerty is writing some fast routines to handle GC the same way any other JVM would, but the coder still shouldn't abuse that feature as the Prizm is still a low power device
13. Well in java bytecode objects don't exist. It's just standard data types. The objects are all handled by the java compiler which already exists.
14. Memory will be allocated by a new set of advanced malloc calls that would allow significantly more memory to be allocated than the default Casio one.
15. I'm not entirely sure what you mean by accessing individual bytes. If you mean being able to read any location in memory via a pointer then this would be allowed contrary to the on comp JVM as there are no security checks other than array bounds.
16. Any library that runs off pure bytecode can be ran while everything that uses native code will have to be ported. And I was planning an OpenGL port as I've been reading the book Real Time Rendering which discusses how to make a port.

interesting seems as if you're got more of the specifics down already, nice job!

just wondering, how many bytes would you estimate be open for developers to use?  How many does the VM take up?

I believe Qwerty planned 128 kb of data with code size limited at the size of your flash chip being limited to 16 Mb + any compression techniques used. I do have several ideas though for acquiring more space in ram to possibly as high as 1 MB. The VM size I'd have no idea and we won't know till it is finished.

Sorry to hear you'll be gone, I hope you don't have too much stuff to do

Glad to see the speed will be similar to z80 ASM speed. Hopefully some good stuff can be done in this.

Cool to hear there is some progress

Will this ever run *.jar files? It would be hard, as Prizm has no QWERTY keyboard, not all the QWERTY keyboard keys are on the Prizm, and it has no mouse. (There goes Logisim :'()

http://en.wikipedia.org/wiki/JAR_file
Basically just zip'd .class files and stuff. There's the META-INF folder, which I'm sure is also well-documented.