Behind JEMBlazer: Java on the GameBoy Advanceby Howard Wen
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.
Return to ONJava.com.