It’s finally happening for real this time! Working behind the scenes with some community members, I decided to take an honest swing at an in-house PVB emulator at a full-time capacity. This will be my actual day job. So for the first time in history, I’m going to put my skills to work and produce some actual results. (-:
This community has always been amazing, and I have a good feeling about the emulator initiative going forward. The official project page can be found here:
http://perfectkiosk.net/
__________
So why should you care? Aren’t there Virtual Boy emulators out there already? Let’s see what the project page has to say…
The initiative has four primary objectives:
Nintendo 3DS Emulator
I’m sure most of us thought about Virtual Boy when we first heard about the Nintendo 3DS. A custom emulator specifically designed to run on 3DS can take full advantage of the system’s power and capabilities, giving us true stereo Virtual Boy on the go.
Reverse Engineering
Any time we want to learn about how a game works or make changes to it, we need the right tools to dig in and take a look around. A cross-platform desktop application is just the ticket for providing the user with the right kit to expose all the deepest secrets buried within Virtual Boy software.
TAS
The tool-assisted speedrun is a cornerstone of video game culture, and like reverse engineering, we need the right tools at our disposal in order to get the job done right. The aforementioned desktop application pulls double duty by bringing TAS-focused utilities to the party.
Documentation
Comprehensive documentation of the Virtual Boy’s internals will come from emulator research, and it’s a perfect way for homebrew authors and modders to learn about the system’s features. Those who remember the Sacred Tech Scroll document I wrote can look forward to a brand new version of it.
For further reading of what exactly is planned, refer to the technical document trail on the project page.
__________
How exactly are we gonna pull this off? Glad you asked…
I have enough money in savings to begin work immediately (2018-04-18), but within a few weeks, I’m going to need to rely on financial support from the gaming community. We’ll be reaching out to other sites to gather support, since this undertaking spans a broader scope than what solely applies to Planet Virtual Boy.
A conservative estimate of my monthly expenses comes out to around $500 USD, and with enough interest, I’ll be able to keep this up full-time. By “full-time”, what I mean is 40 productive hours every single week, with status reports and a detailed outline of the development requirements. Planet Virtual Boy has its own developer working for it to make this dream come true. (-:
Donations are managed through a Patreon page:
https://patreon.com/GuyPerfect
__________
For now, this thread will be the place to be notified of progress and for general discussion of the initiative. Thanks again for being such a great community, and for giving me a chance to do what I really love. <3
Special thanks to Fire-WSP, STEREO BOY and KR155E for their assistance in getting the ball rolling.
--Guy Perfect
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.
Attachments:
This is a work post.
Attached to this post is a preliminary CPU Workshop ROM that has been tested on the hardware. It provides binary-level control over the instructions being tested and accounts for most scenarios regarding CPU behavior. A few things to keep in mind:
• Instructions that disrupt program flow will be ignored when attempting to test them. These include [font=Courier New]JAL[/font], [font=Courier New]JMP[/font], [font=Courier New]JR[/font], [font=Courier New]RETI[/font], [font=Courier New]SEI[/font] and any form of [font=Courier New]Bcond[/font] that isn’t [font=Courier New]NOP[/font].
• Despite the above precaution, [font=Courier New]LDSR[/font] into [font=Courier New]PSW[/font] can still crash the program, so be careful with it.
• Exceptions are handled, so testing things like division by zero, invalid opcodes or the [font=Courier New]TRAP[/font] instruction work just fine.
The program is arranged with a sort of tab strip at the top, with four distinct views. Use the L and R buttons to switch between them.
Instruction
The primary dialog that allows you to configure an instruction to test. When the Test command is invoked, the instruction will be tested in the context of a function call with the following arguments:
• r6 = Specified by user
• r7 = Specified by user
• r9 = 32 bytes of scratch memory available to the user
The values of r6 and r7, as well as the bits of the instruction to test, can be configured. The left D-Pad moves the cursor to select individual digits, then Up and Down on the right D-Pad will change the digit.
Moving the cursor down below the “Bits” field will select the Test command. Press the A button to perform a test, but bear in mind that the test is performed in the background and you will not see any effects until you look at the other menus.
A disassembly is provided as a courtesy to help make sure the instruction that’s going to be tested aligns with the instruction you intend to test. The program requires you to have a good working knowledge of V810 instruction formats. For more information, refer to the Sacred Tech Scroll’s list of instructions by mnemonic.
The left 16 digits of the Bits field are used for 16-bit instructions, and all 32 are used in order for 32-bit instructions. If a 16-bit instruction is specified, the second 16 bits are ignored during the test, so you don’t need to configure them.
System, Program
Displays two snapshots of system registers and program registers, respectively. These views are for display only and have no functionality.
For each register, there are two values shown: the top one is the register’s value before the test, and the bottom one is the register’s value after the test.
All system register indexes from 0 to 31 are displayed. This seems unnecessary at first, but it was discovered that system registers 29, 30 and 31 do in fact exist.
Misc.
Displays additional information regarding the test.
The bit-packed fields in system register PSW are decoded for easier assessment of the status flags.
There are 32 bytes of scratch memory available for testing read/write instructions with, pointed to by r9. The “before” and “after” states of these bytes are displayed here.
