I was thinking before that a JRE for the 83+ would be cool... A converter would also be about as effective since who would really want to javac on a calc? :D

Anyone interested in an 83+ version of something similar to this?

I don't think that Java will appear soon if at all on z80 calcs (83 series for example) We don't even have a c, pascal, or any other not object oriented compiler. The only compiler we have is tipower gold (link), which had object orientation but that has been removed because it wasn't useful. It is a really nice compiler but it doesn't even come close to supporting everything c or java supports.

Thus I think you will have to wait untill there is at least one compiler ti power gold or otherwise, that supports everything that c (or pascal) has before we will see java.

is there a c coder for the 83? i tryed searching for one but couldn't find one

You might be able to get SDCC to work. (See link) I have not tried it, but it looks like it is better than Small-C. I personally like z80 asm. When I want to write in C(++), I just write a program for my computer.
I like assembly on my calculator, because I feel like I living those early days of computers that I never knew. You know, the days when a few bytes or clock cycles actually meant something.

MWM

I've tried SDCC. It looks very comprehensive in the functions and in the support it has, and it seems to optimize decently too.

The one problem I have is that it uses the IY register (which the TI-OS uses) as a scratch register for addressing purposes, instead of (for example) saving and using HL. I've looked through and modified the source trying to change it, but so far I've gotten nothing. Have you tried changing it at all?

Fortunately, it uses IY in relatively few places (such as in _strtok.c and a few others in the device function library), so you could just change those each time you compile.

I'll probably email the developers of SDCC to ask them how to change its register allocation.

I use IY in my assembly programming as a scratch register all of the time. I just save its value in ram, and restore it whenever I need a ROM call. Do you suppose this would be practical for the compiler?

MWM

It might be practical, but I would have no clue how to tell it to do that.

By the way, the fastest and smallest way to save a register pair (like IY) is to PUSH it onto the stack.

Yes, I know. However, in this particular program that I was making, it worked better to save it to a set memory location, to be recalled those few times that I needed it.

MWM

Oops...I forgot something.

I actually modified the startup code (crt0.s or something like that) to PUSH IY before it calls main and POP IY after main returns. This lets TI-OS continue working after the program ends, but it means the program can't call a lot of TI-OS routines.

After a lot of hand massaging and tweaking, I finally got a program to run on the TI-86 (basically a "hello world" type program). I used some utilities I wrote (originally for another assembler), such as an Intel Hex-to-binary converter and a program variable maker.

You mean like a program for my TRS-80 or my Nokia cellphone (note that both use Zilog z80 processors)

You can try z88dk: http://www.z88dk.org .

Wow, I've never actually looked at that before. It looks pretty good, and it's free software too!

I'm a gonna try that out sometime.

This is actually kind of funny. I got beat to the punch, in a way. I am now in the process of writing a Java-type language for the 83+ (to kind of replace TI-Power GOLD, which _is_ TI-83+ compatible). The language is being designed to pretty much to "work" on the TI-83+ though it is meant for the coming TI-84+'s speed and memory size.

If you are curious about my progress, I now have a working imbedded assembler, and am in the process of trying to make the language as flexible as possible (expandable, etc.)

Because it is a z80 processor though, I'm pretty sure that most multiplication and division will be function calls (for both speed and memory), though bit-shifting won't need that. (ie dividing or multiplying by powers of 2)

Haha...

javac(program)
*compiles*
java(program)
*runs*

Hey I just noticed: On the file information page, it says it can't open the ZIP file. Is it just unable to open it on the server, or is it possibly a corrupt file? (I'd check for myself but I'm busy and have no real use for it at the moment.)

If the Zip file was not completely constructed, then the data was corrupted, and the file might not be completely there. If you only have part of a file, you can't use it fully. It's like haveing few pages missing in your programming guide. If those are important pages, then you're doomed. If those cover topics that you really need to know, but you don't have it, then you won't be able to use that book completely to your advantage.

I know how ZIPs work... I was just stating perhaps the file was corrupted since the zipviewer couldn't open it.

I opened it in Winzip and all of the files looked fine.

OK, maybe it's just compressed at 'Best' or something and the script doesn't like it.

I believe the problem is that the .zip file is too large. I have had problems with this on other files as well. They usually still work when you download the file.

Some clarifications for those who haven't followed the previous versions:
* This is _not_ a Java bytecode compiler and interpreter/VM, it is a Java->C converter. This means it generates fast programs, however you don't get Java benefits such as array overflow checking (unless you are willing to wait for it to be implemented in GCC and carrying over to TIGCC - overflow checking is not impossible in C) or defined overflow behavior (Java uses signed integers only, but makes wrapping overflow mandatory; C uses both signed and unsigned integers, and makes wrapping overflow mandatory for unsigned integers only, whereas overflowing behavior is completely undefined for signed integers).
* Unfortunately, it is shipped with some horrible-looking non-native dialog classes just like the original...

Ooh, I see. Java->C. Well, that would fix the "Java is slow" problem.

Really? Java only uses signed ints? Hmm... now I wish I had paid better attention in my Java class.

no pun intended.

What!? Java doesn't only used ints... it has plenty of primitive data types: char, int, long, short, double, float, ...

Or did you mean the only kind if ints that it use are singed? If that is the case, I didn't know that either.

Can you do something like in the line below? I know you can do that for TIGCC:

unsigned int bob=3;

In Java no. In Moka, you could using C interoperability. But, it is not the 'right' thing, unleast it is the only 'friendly' way to do something (compare accessing directly the attributes of an object).