Java Byte Code, Ahead Of Time Compilers, And A TI-99

Java famously runs on billions of devices, including workstations, desktops, tablets, supercomputers, and jewelry. Yes, jewelry. Look it up. [Michael] realized Java doesn’t run on Commodore 64s, TI-99s, and a whole bunch of other platforms. Not anymore.

Last year, [Michael] wrote Java Grinder, a Java byte-code compiler that compiles classes into assembly language instead of being part of a JVM. This effectively turns Java from a Just In Time compiled language to a normally compiled language, like C. He wrote this for the 6502/6510, the MSP430, and a Z80. The CPU in the TI-99/4A is a weird beast, though, and finally [Michael] turned this Java Grinder on that CPU, the TMS9900.

While most of the development was accomplished with the MESS emulator, [Michael] did manage to run Java on real hardware. His friend gave him a TI-99/4A a few years ago with a few cartridges. Cracking those cartridges open revealed one PCB that would hold an EEPROM. Writing his Java byte-code-derived assembly to a 28c64 EEPROM, he had a cartridge that would run compiled Java.

Right now, the demo is pretty simple with low-resolution graphics beeps and bloops of music, and generally not what you would expect from a TI/99. This is mostly due to the fact that the API for the TI-99 is extremely simple. You can check out the results of that programming endeavor below.

30 thoughts on “Java Byte Code, Ahead Of Time Compilers, And A TI-99

        1. Too right, the art of typing ‘ARV Java’ into Google is a lost one indeed.

          Now kneel before me, you smelly uneducated Google-poor peasant. And make sure you’re downwind of me, what the hell have you been mucking out anyway?.

  1. Am I the only developer out there that doesn’t care that much about Java? I get that it’s a useful hammer but that’s what it is, a hammer. When the object mentality pisses me off enough, I switch to a different language like C or drop down to something like ASM when the hardware is too small for all the extra crap Java piles on. Use a hammer when the job calls for a hammer, use another tool if the job call for it.

    To that end, next time he might want to use something other than a hammer to open a sealed cartridge. Dremel, a small saw, a hot X-Acto blade even. I even used a dentist tool to scrape out bad glue between two plastic halves. Not saying he should *save* the plastic if that isn’t what he wanted, but he could’ve handled it better to avoid damaging the PCB he was trying to use.

        1. The Commodore Amiga was a 32bit multimedia computer. Hardly comparable to the C=64 or the TI99/4A.
          Most commercial software for the C=64 was written in C and compiled, however, the compilers were not run on C=64 hardware.
          They weren’t publicly available either. Each Software House wrote their own compilers and kept them in-house.

    1. >Am I the only developer out there that doesn’t care that much about Java?

      “developer” is a broad term. Some developers are working with targets that have kilobytes of memory, some are working with systems that have tens of gigabytes of memory, tens of processors. Some developers like to have support for highly concurrent applications built into the language/runtime they are using.

      >When the object mentality pisses me off enough,
      >I switch to a different language like C or drop down to something like ASM

      If you look at any reasonably big C code base it will look a bit OO (passing around structures of function pointers etc).

      >when the hardware is too small for all the extra crap Java piles on.

      There are JVMs for small platforms. There are multiple versions of the Java standard library that target different sizes of system. In this instance it a compiler that compiles Java (the language) to machine code. So there is no reason for “extra crap” to be piled on.

      >Use a hammer when the job calls for a hammer, use another tool if the job call for it.

      “I’ve never done anything outside of the scope that I presently work/tinker in therefor everything I don’t use/understand is crap”.

  2. No this is way cool! For java he does need to fix his garbage collector though. This reminds me of an example open source thingy I did way back (more than a decade ago, so please forgive the old website and also the docs that never got finished ;)) http://freecode.com/projects/wsbasic. Anyway more recently I found a little spare time for wash (with that shellshock horror we heard about in bash felt like time to make that bash alternative, again then bills came, my son was born also, so just not enough free time to spend on it). For those interested you can find wash here: https://github.com/w-A-L-L-e/wash.

  3. Ah Java, the toy programming language used by beginners and mediocre programmers who still can’t grok the concepts of memory management, determinism, pointers, and all the “hard” stuff that comes with programming.

    Java: write once, wait 20 mins for the virtual machine to finish it’s garbage collection, and then wait for your java engine to request an update.

    If java had real garbage collection, it would garbage collect itself.

      1. Where to begin. Write once, ensure all 30 or different versions of the JRE are up to date.

        Write again, using older JRE.

        Write again, rewrite unsupported methods.

        Get lots of compliants , program is slow.

        Compare to C implementation, program IS slow.

        Test on low-spec machine, C version runs faster.

        Deal with non-determinism.

        Rewrite in C, link statically, finished.

  4. I noticed this on [Michael]’s project page:

    “I’ve also been asked a couple times about a C generator instead of assembly, which to me is kind of odd. Why not just write the code in C and not add another layer?”

    Hmm. While you’re at it, why not just write everything for the target machine’s assembler opcodes, and skip Java and Java Grinder too? They’re just more layers. ;)

    The reason why a C generator is useful is because the C output can theoretically be compiled on *any* target CPU. [Michael] has certainly supported an impressive number of CPUs, but I’m sure each one takes significant work to fully support and optimize the output for. If I want to convert Java to run on PIC32 (MIPS), I probably can’t yet with Java Grinder, because MIPS support isn’t finished; but I could take C generator output and get it working today, even if it’s not well-optimized. And what if I want support for MuP21, xCORE, Propeller? No support planned for these, and I doubt [Michael] wants to spend the rest of his days adding support for every possible architecture someone might wish to use.

    “Either way I decided to drop it in quickly anyway just to see what the generated code looks like. It should be working properly except arrays.”

    That’s a pretty severe limitation. Maybe it’s been fixed in the year since that was posted, but if so [Michael] didn’t mention it. If he doesn’t understand or agree with the usefulness of a C generator, maybe he didn’t bother. If this were my project, I’d prioritize the C generator above all generators.

    1. Having an intermediate is a great idea, and is what Microsoft did with .Net. Since any .Net language compiles to Intermediate Language and then is JIT compiled to the target machine when it’s loaded, given N languages and M machines, you only need N + M compilers rather than N*M.

  5. Java is faster than C. So why doesn’t java run inside a java interpreter written in java , running on a java written in java. The more recursion, the more speed you get!

    Sure, your micro would take weeks to boot, but WOW! once it boots, and runs the garbage collection, and actually gets to running your program, WOW , the speed!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.