This is a work post.

Truth be told, I started working on this project about a week before the 3DS thing came up. The two ideas merged together to form into what we have today. What this means for us is that we’re not starting from square one–we’ve already got some progress to go off of.

In this post, we’ll take a look at the current state of the project as of the start of the initiative.

Where We’re At

Attached to this post is a ZIP file containing a JAR file containing the source code of the current build of the emulator. And the JAR file itself is the current build of the emulator. If you have a Java Runtime Environment installed (Linux users will want OpenJDK), you can try it out! If you don’t have a Java Runtime Environment installed and have interest in this project, you might consider installing it. The desktop application will only be available on the Java platform.

When you load it up, you’ll have an empty window with a File menu, which you can use to load a Virtual Boy ROM. Once you select something, you’ll be presented with a Debugger window and a Memory window. The Debugger is the main attraction today, but if you want to navigate around the Memory window you can use Ctrl+G to go to any address you please.

The Debugger window looks like this:

On the left is the disassembler, and on the right are the registers. You can navigate around the disassembler with the arrow keys, Page Up/Page Down and the mouse wheel, or use Ctrl+G to go to a specific address.

Program execution is managed with the following keys:

• F11 – Single Step (aka Step Into). Executes the current instruction.

• F10 – Step Over. Attempts to execute until the following instruction is reached, which works as a traditional Step Over but is also useful for breaking out of the warm-up loop at the beginning of the crt0 routine. If one frame’s worth of CPU cycles is processed without reaching the target instruction, it will stop in order to prevent running endlessly.

The top panel of registers is for system registers, and the bottom panel is for program registers (aka general registers). All those numbers are in fact text boxes, allowing the user to change their values directly (no pop-up window). I couldn’t think of a cleaner way to present the 46 registers on the CPU, but if anyone has a better idea, now’s a great time to try something out.

See those + signs next to several of the registers in the image? You can click on those to “expand” the corresponding register for more options:

For system registers, this gives controls for configuring the individual bit-packed fields within the 32-bit value. PSW is demonstrated here, where there are check boxes for all of the flags and a text field for “I”, the interrupt masking level.

All program registers can be displayed with one of four presentation formats, depending on what you’re debugging. “Signed” and “Unsigned” are decimal representations.

Most instructions are implemented, but not bit string or floating-point instructions, since they will be miniature projects in and of themselves. There are also no implementations for hardware components, meaning interrupts will never occur. This means most games will eventually enter an endless loop waiting for a global variable to be changed that will never change.

Technical Stuff

Why Java? Because it’s available on most operating systems and the geniuses who maintain it have done all of the heavy lifting for things like localization, networking, GUI stuff, etc. I’ve been around the block two or three times looking for solutions to the cross-platform problem and Java is the best one I’ve come across.

Naturally, Java isn’t going to be the language used in the 3DS build, so how pray tell will this work? The answer isn’t ideal, but it gets the job done: there will be two implementations of the emulation core. One in Java, and the other in C.

The emulation core is a module that handles only the bare minimum necessary to manage a simulated Virtual Boy. It’s pure program code: it relies on the encapsulating application for things like timing, user input and presenting output. A C core will be used by the 3DS build, and the Java application will use… well, that’s where it gets interesting.

At the heart of the Java application is a class that represents the emulation core. It’s currently an abstract class, but I’m thinking of turning it into an interface… In either case, it doesn’t contain any actual program code of its own, but acts as a sort of stand-in template for other classes to implement. It looks like a duck and quacks like a duck, but it’s just the hollow shell of a duck.

Classes that implement the methods of this core interface are the meat of the internal engine. Currently I’ve set up a class that provides a generic Java implementation of the emulation core. In the future, at least one more implementation will be provided that makes use of the C version of the emulation core, which will offer improved efficiency and performance.

Java can use C code through the Java Native Interface (JNI), which loads shared object/DLL files at runtime. The drawback is that we need to produce those library files for every single operating system that we want native support for. Fortunately, those systems that don’t receive native libraries will be able to fall back on the Java implementation instead, and everything will still work just fine.

When it’s all said and done, the C emulation core module itself will be one of the products of the initiative. Other development teams the world over will be able to use it to easily integrate Virtual Boy emulation into their projects.