This is a work post.
I am having a blast. At first, the plan was to take the existing Java code and move it over into a new project, passing it through a mental filter to make sure everything is looking good. But then I started optimizing and refactoring and improving and… Well, the scope grew a bit larger than what I intended for the week.
Instead, I’m gonna add one more week for the same basic goals from last week. This isn’t the same as a missed deadline: what I’m doing is absolutely productive and under control. It’s just more in-depth than I originally thought I was going to do. But it’s all for the better.
As for what I’ve been up to…
• New Java base – I started a brand-new Java project from scratch, with the intention of reviewing the old files as I moved them over. I ended up doing it all again from the ground up. Once the improvements started becoming apparent, it suddenly became a lot of fun and I kept going with it. The new code is as good as it’s ever been.
• Emulation core – The Java application communicates with an emulation core context that this time is implemented as an interface rather than an abstract class. There’s a static factory method that will produce a valid emulation state for the application to work with. For now, it’s only backed by the generic Java implementation of the emulation core, but the final product will also have native modules on supported systems.
• Bus and CPU access – The emulation context interface supplies methods for accessing data from the simulated Virtual Boy state. You can read and write CPU registers as well as memory from the bus in any applicable format. Internal memory buffers and component functionality are automatically routed trough a simple mapping routine that ties the whole thing together.
• Debug accesses – The application is allowed to do things that the emulated program is not, and these are handled through special debug accesses. Any reads or writes that would have no effect on the hardware can have an effect when used in a debugging context. For example: storing new values in ECR, writing to ROM, and reading from the VSU are all possible as debug accesses.
• New disassembly – While implementing a new instruction decoder, I took a minimalist approach and used a simple, generic field for instruction operands. This necessitated gutting and rebuilding the disassembler class, which also saw the benefits of knowing what-all needed to get done. The implementations of both classes are far leaner and more concise than ever before, and I’m very pleased with it.
Going forward, I’m going to start up a new GUI project to get the Debugger and Memory windows up and running again. From the user’s perspective, it should look more or less like it did before, but the improvements on the back-end will make it so much more convenient and efficient as additional features are implemented.
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.
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:
I have such a Hello World program that I use for personal development, but it’s written against a devkit that isn’t public and never got finalized, so sending it to you won’t be too helpful… What you want to do is get a compiler set up so you can turn C source files into Virtual Boy ROMs. From there, I can assist in getting a Hello World program up and running.
Take a look at the Sacred Tech Scroll, which is a fairly accurate account of the system from the CPU’s perspective. What you ultimately want to do is store some kind of font graphics into character memory, arrange them on a background segment for the message you want to display, then set up a window containing that segment as its background. It sounds a bit complicated, but I’d be happy to walk you through it when the time comes.
I’ve attached the font I most commonly use for these programs.
Attachments:
No, I removed it because it turns out that Patreon is not at all adequate as a donation platform. And that’s ironic, since half of YouTube apparently runs on it. It’s actually a subscription platform, and they do not facilitate one-time payments in any way. The proverbial last straw was when the first donator tried to donate and couldn’t because he didn’t have a credit card associated with his PayPal account, and Patreon requires payment methods to support recurring payments (and PayPal requires a credit card for those).
So instead, I’m just getting PayPal set up. I was on the phone with them a handful of times yesterday to figure out what went wrong with an ancient account and finally got that closed, freeing up my bank account to be used once again. As soon as their transactions are processed, I should be able to finalize it.
Fire-WSP: I sent you a file on Discord. Not sure if you regularly check Discord, but check Discord. (-: