Atari Now Runs Java, Thankfully Doesn’t Require Constant Updates

Java Grinder is a tool that compiles Java programs to run on platforms like microcontrollers and consoles, by outputting native assembly code and using APIs to work with custom hardware like bespoke graphics and sound chips. Amongst other hardware, Java Grinder supports the Commodore 64, which uses a variant of the 6502 CPU. [Michael Kohn] realized the Atari 2600 shares this processor, and figured he’d get started on making Java Grinder work with the Atari by expanding on the C64 work done by [Joe Davisson]. Together, they brought Java to the Atari 2600 and made a game along the way.

According to [Michael], parts of the project were easy, as some Java routines compile down into as little as 1 or 2 instructions on the 6502. Other parts were harder, like dealing with the graphics subsystem, and modifying Java Grinder to output 8-bit bytecode to fit into the Atari’s tiny 4K ROM limit. Even with this tweak, they still couldn’t fit in a game and title screen. In the end they relied on bank switching to get the job done. [Joe]’s game is pretty solid fare for the Atari 2600 — blocky graphics and bleepy sounds — and they’ve uploaded it to the page so you can try it yourself in an emulator.

At the end of the day, porting Java code to a system with 128 bytes of RAM probably isn’t going to be particularly useful. However, as a coding exercise and learning experience, there’s a lot of value here in terms of building your skills as a coder. Other such experiments have shown us Java running on other unexpected devices, like the Sega Genesis or the MSP430. Video after the break.

24 thoughts on “Atari Now Runs Java, Thankfully Doesn’t Require Constant Updates

  1. I’m surprised this is possible with the 2600. I have never programmed one, but my understanding is that due to the severe lack of RAM, there is no framebuffer, and the game must generate each scanline, in turn, just in time to be displayed, AKA “racing the beam.” Doing so requires really tight control of cycle counts that would be difficult to manage from anything but assembly.

    All the same, very cool

    1. There are BASIC compiler for Atari. Look up batari BASIC.

      But coding for 2600 is still a pain in the butt, more so with modern TV being very picky about video standard. Some modern TV can’t do 240p at all and early video games including Atari and NES were designed for 240p only (not a full 525 lines per frame). Older TV were fine with few lines variation.

      1. On the Atari vertical timing is purely in software. That’s why PAL and NTSC versions needed different code, or else the wrong type would make the screen roll endlessly. It has to send all 525 / 625 lines, or else a TV wouldn’t accept it. It’s not 240p, it’s 480i, like standard TV used to be. Just the same set of 240 lines repeated twice. I imagine it’s the same for the NES. There’s only 240 lines you can program for, but the TV output signal is standard.

  2. It does use assembly for some things, like the rendering kernels. You basically create API calls for whatever assembly routines you need to run. The game logic itself uses the bytecode compiler. Java is used as the “higher-level” language, but as they say.. “some assembly required”.

    1. The article does point that out, that it produces native assembly.

      This confusion is caused by Sun’s ingenious idea to call the language Java, the bytecode Java, and the virtual machine Java Virtual Machine. Grinder translates / compiles the compiled Java bytecode, but doesn’t implement the virtual machine. So there’s no garbage collection, either, come to think of it. Which is fortunate cos I dunno how much RAM you’d need to manage garbage collecting 128 bytes of RAM.

      The whole thing made more sense when it was still called OAK, I hear.

  3. Java is *garbage collecting* much *GC* faster tha*GC*n C/ASM. Every *GC**GC* thing should *GC**GC**GC* be written in java for *GC**GC**GC* maximum *GC* *GC* sp*GC**GC*eed.

  4. This is pretty neat. The Atari 2600 coder in me is a bit skeptical of the huge size (the game looks like something that could fit in 2k or even 1k) but this could definitely be an option for those who want to play with an object oriented language on the platform. Much like batari BASIC, people will likely stick to the pre-made kernels. Personally I find writing new kernels and demos much more fun :)

    1. Bespoke is the past tense of bespeak. Bespeak means to ask for in advance. It was commonly (but not exclusively) used for clothing. In any event languages change and evolve…we need to evolve with them or run the risk of sounding like a crotchety old man.

          1. Is Java hipster cos it’s become retro? Surely it’s not new enough any more for the other kind of hipster appeal. More importantly, what do Apple think about it?

          2. Incidentally it’s some time around now, that Java’s launch is closer in time to the Atari 2600, than it is to the present day. When was it, about 1994? 2600 was 1977 (a good year for many things), and now is 2017.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

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