Where's the rule where BuilderBoy can't participate? He'll make my entry look like  a quadratic solver.

No don't worry BuilderBoy is making a quadratic solver. A quadratic solver platformer using grayscale and cellular automata

It should also check to see if a topic is locked or not too. But I would think that it should allow different sections to be randomized in because I might not want to see a random topic in the pixel art sub forum for example

Well if you were someone like Mkrakoplaz who had 40+ ratings before he reached 40 posts then that should be allowed for IRC. But I didn't reach 40 respect until I was around 600 or so posts. But actually if someone already has maybe 5 or so respect then omnom permissions seem like they should be granted. The only exception would be if a bot posted another blue lobster recipe causing it to go on Omnom.

Yes everything else on Omnimaga changes size based off window dimensions so it is important that omnomIRC takes that into account. And I don't mind really if the picture is centered or on the left. Both look as if they could be correct. And with IE, I kinda saw it coming

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.

I guess I'll just have to wait for the final release, but this is looking awesome. It really is the graphical touches that make any game much more amazing.

I did get a response and Renesas asked me to contact a sales rep for more information. I wonder what would happen if I asked to purchase a 7305. I also found this other file that listed about a hundred semiconductor, networking, ram, flash, etc... businesses including Renesas. I can't help but suspect that these businesses contributed in some way to the Prizm hardware. I'll get more info on that later