Behind JEMBlazer: Java on the GameBoy Advance

JEMBlazer is basically Java on a cartridge. Specifically, "JEMBlazer" is a
brand name for a family line of cartridges that add Java capabilities to
various devices. This family uses the JEM Java processor hardware technology
developed by aJile Systems, the company also behind the JEMBlazer. The first
released JEMBlazer product is the JFlame, a devkit that allows Java apps to be
developed for, or ported to, the GameBoy Advance. The JFlame development kit
sells for $199, the cartridge itself for much less. Mike Masters and Kurt Mahan
are the principal hardware and software engineers of the JEMBlazer JFlame.

Mike Masters, 42, is an electrical engineer in Cedar Rapids, Iowa. He describes his role as "responsible for the hardware design of the cartridges and supporting the software team."

Kurt Mahan, 37, is a software engineer in Salt Lake City, Utah. He says of his work, "I handle the software and write the drivers for the hardware guys."

Mike and Kurt recently agreed to an interview about their work on
JEMBlazer.

O'Reilly Network: Besides the fact that your company, aJile
Systems, develops processor technology for Java-enabled devices, what's the
motivation behind JEMBlazer? Does aJile Systems see a significant market for
this product? What uses does your company see for it?

Mike Masters: There are many examples of aJile technology
used in traditional embedded systems: Sun's eGas and automation demonstrations,
and products like the JStik. The JEMBlazer cartridge is a demonstration of the
aJile complete Java solution applied to the handset environment. Using the
aJ-100 and a few components, the aJile Java runtime system and desktop, and a
few lines of GBA client code, the GBA system becomes a standard Java platform.

We do feel there is an exciting market for the JEMBlazer by enabling Java
games on the most popular gaming device ever made. This will bring together the
vast Java developer community with the widest game playing audience.

Kurt Mahan: Doing the JEMBlazer allowed us to show how
flexible the aJile processors are. In a very short amount of time, Mike had a
hardware prototype built, and with a little bit of software, we were running Java
games on the GBA hardware.

ORN: How does JEMBlazer work? It's essentially Java on a
cartridge, right?

MM: The aJile processor in the cartridge runs the Java
application and uses the GBA as an I/O system (copies screen updates to the
display and passes on key-press events). The communication channel between the
GBA processor and the cartridge is a straightforward shared-memory architecture
and some messaging flags.

KM: The software has two pieces: the native client piece
running on the GBA (written in C and assembly) and the Java piece running on
the aJ100 in the cartridge.

Periodically, the GBA client "wakes up" and performs a couple of tasks. It
updates any hardware tasks on the GBA, such as music playback. It scans the
shared memory area for tasks from the cartridge, such as updating the screen.
Finally, it scans the keypad, and if there are changes, it notifies the
cartridge.

On the cartridge side, the aJ-100 is running and handling all of the Virtual
Machine tasks. When the screen is "repainted," or other interaction is required
with the GBA, the shared memory area is updated and flags are set, notifying the
GBA client that it has work to do. When the GBA client has messages to send
back to the cartridge, an interrupt is generated, telling the aJ-100 to do work.

ORN: Java games and apps made under JEMBlazer can only be
played on GameBoy Advances that have a JEMBlazer cartridge, correct?
Otherwise, is it possible to use JEMBlazer to develop a program that could be
put onto its own cartridge?

KM: The JEMBlazer will execute Java games and apps that
also run on the J2ME Wireless Toolkit. (Note: apps that have been written to
depend on numeric keypad have not been addressed yet.) JEMBlazer can also
be used to run dedicated, or "standalone," Java apps.

You can create games that will "run anywhere" if you follow the standard
Java rules. These include "don't code to specific screen sizes" and "only use
the profile APIs." If you do choose to assume the screen size of the
JEMBlazer (240x160), and/or you use the aJile-specific APIs for handling
multiplayer or other tasks, you will be locked into the JEMBlazer/aJile
solution. This is the same as if you use the DoCoMo- or Nokia-specific
APIs.

ORN: What are JEMBlazer's main features — the ones
that would most interest a Java developer?

KM: It is difficult to speak for others, but some of the
features that make this platform great for Java developers are:

Consistent screen size. All of the GBA devices have a screen resolution of
240x160.

Consistent input device designed for gaming. There aren't variations in
the keypads.

Fast graphics performance.

ORN: What strengths does Java bring to the GameBoy Advance?
Wouldn't it be more advantageous to just code games and other programs for the
device without Java?

MM: Game development using the traditional GBA game
development process has obviously been very successful. The JEMBlazer cartridge is not
intended as a replacement platform for those developing GBA games. It is
intended to open up the GBA user base to those already developing Java games
for other devices. It's amazing to see the variety of games and applications
that were quickly ported to the GBA via a JEMBlazer cartridge.

KM: To bring a GBA game "to the masses," you must write the
game and then burn it into a cartridge to distribute it. There are, of course,
ways to buy "flashlinker" cartridges, or to download small games over a special
parallel port cable. The JEMBlazer allows anyone with Java experience to create
fun games. Distributing your games is as easy as running them through our web
site to convert them. The user just downloads them from the net and puts them
onto their JemBlazer using the USB cable.

ORN: How much of JEMBlazer's development involves coding,
versus hardware/processor design?

MM: The overall hardware design is fairly straightforward.
The main challenges are judging the design decisions necessary to hit our
desired cost points and form factor.

KM: The software challenges are in putting together a
compliant Java platform (MIDP/CLDC). We've become very adept at isolating
hardware-specific operations to a handful of classes. The differences between
our GBA-based platform and our more complex devices is fairly small. I'd guess
there are less than 10 class files that are different between our wireless
reference design and the JEMBlazer. Thank you, Java.

For the development of JEMBlazer, what have been the inherent technical
challenges in bringing Java to the GameBoy Advance?

MM: The main challenge was in understanding the GameBoy
interface and fitting everything into a small enough package.

KM: From the software side, it was pretty easy. Once Mike
had designed the hardware interface, the software was straightforward to put
together to utilize it.

When I originally put our low-level graphics and event systems together, I
made sure that they would be adaptable to different environments. Setting up
the JEMBlazer environment required creating the low-level Java drivers and
writing the GBA client; everything else just worked. Getting a working screen
display with key events took under a day.

The hardest part was shifting back and writing C code for the client. There
are no "native" methods on our processor. Everything is written in Java, so at
aJile it is very infrequent to need to write anything in C or assembly. On
another note, it is unfortunate that Sun uses as much C as it does in their
Java implementations. In MIDP especially, the entire menuing/pop-up system is
written in C, which means that at aJile I have to rewrite it in Java. Probably
the funniest thing that Sun does is use native methods/C to get around the
class/method scoping rules. I can only hope that Sun eventually decides that
Java means less C.

ORN: What were the changes, additions, or adjustments that
had to be made to Java (J2ME) for JEMBlazer?

KM: For the most part, J2ME fits quite well on the
JEMBlazer/GBA. There are a few issues that are problematic. The JEMBlazer is
not considered a "connected" device, but the MIDP profile assumes that it is. I
have a number of nitpicks with the J2ME/MIDP profiles, but for the most part
it integrates quite well.

ORN: Is there anything interesting about the GameBoy
Advance hardware that you discovered during the development of JEMBlazer?

MM: I've gained an appreciation for Nintendo in the
handheld gaming market. They know their target market extremely well.
Everything about the GBA hardware (cost, size, power) is optimized to appeal to
the heart of the handheld gaming market. Some have tried with a more capable
platform, others with a cheaper platform. So far, competitors have had very
little success in denting Nintendo.

KM: The GBA is a great piece of hardware for writing
graphical games. Rather than use layer upon layer of APIs, you work directly
with the hardware. This lets you get the performance you need. The hardware is
very straightforward to work with.

ORN: What suggestions do you have for those who are
interested in developing Java games or apps for JEMBlazer?

MM: To a large extent, the games have already been
developed for other mobile Java devices. We're here to help them distribute the
games to GBA users.

KM: The advice I have applies to any kind of mobile Java
development (or any Java development).

In a limited (processor/memory) environment, you have to think about what
you are doing. Objects have a cost in both memory and [compile] time. So, if
you can, it is best to pre-allocate your objects and then reuse them. The other
big mistake that I've seen people make is that they make assumptions about how
threading works. Sun has left a couple of holes in their threading
specification; if people want to give time to other threads at the same or
lower priority, they shouldn't assume that the underlying operating system will
ignore the priorities and just run threads. You should consider
Thread.sleep() or Thread.yield().

ORN: For you personally as developers, what have been the
technical things you've learned while working on JEMBlazer?

KM: For me, the JEMBlazer hasn't been as much of a learning
experience as a fun experience. The technology that we used to create
the JEMBlazer system is very straightforward. From the software perspective,
most of the work was creating drivers to utilize the JEMBlazer hardware. This
project reminded me how much fun it is to work on platforms like this. It is
always fun to work with our processor and with new hardware, which is the
reason I came to aJile three years ago. I'm probably strange that way -- a
software guy who likes to cause Mike grief by pretending to understand
hardware.

MM: It's only grief because Kurt shows me what works, what
doesn't work, and usually why something doesn't work. My grief is certainly
less than Kurt's after I break the top-of-tree with my code edits.