Planet Virtual Boy

This is a work post.

Welcome to Guy Perfect Hour, where Guy Perfect talks to himself! Today on Guy Perfect Hour, we're going to begin proper development on the emulator's code base using the document we prepared earlier.


To Do - Week of April 23, 2018

This week's goal is to start from scratch and produce the program code necessary to get back to where the most recent emulator build is. Why do that? Starting things from scratch multiple times helps me hone in on the best way to do it, and last time I did this I felt pretty good about how it went together.

• Establish an infrastructure for the Java emulation core.

Yes, the 3DS thing will be running on the C emulation core, but I'm going to focus on the Java code first. The reason for this is because it's easier to develop/test and if the module's structure needs to be changed, it's easier to do that to only one module than two parallel modules.

Once the emulation implementation is up and running in Java, it will be a rather short task to move it over to C. Then the fun begins.

• Implement CPU operations.

All CPU operations except the instruction cache and floating-point instructions are targeted for this week. The instruction cache doesn't affect a program's execution, and I'm not aware of any commercial games that use floating-point instructions, so this should be sufficient to get existing software simulated.

The CPU accounts for something like 60%-70% of the entire emulation core.

• Implement disassembler, register list and memory controls for the GUI.

The GUI controls are all linked into the same debugger context, even if they're not presented in the same window. Redoing them from scratch using what I learned before will make better versions of everything.

Quote:
Great show!

Sounds like a solid plan. Keep fighting the good fight!

Quote:

Splatoon 2 updates are traditionally dropped on Fridays, and the big honkin' version 3.0.0 was announced for April. Since there was only one Friday left in April (today), I was thinking I could get my emulator stuff done by the end of the week, then do some Splatoon 2 stuff over the weekend.

But then they pushed the update on Tuesday night.

I'm one of the principal content managers at Inkipedia, the resident Splatoon wiki, and I had to shift my priorities a bit during the week to make sure everything got done properly. Website traffic jumped from around 7,000 visitors to 12,000 on Wednesday, and that's a lot of people wanting to learn about new game features. In particular, I'm the one with all the fancy programs and tools to collect and process game information, so my attention was in high demand. (-:

For more information on the update, check out the Version 3.0.0 page.

Basically what this means is my weekend got pushed up three days. Instead, I'll work through the weekend on the emulator thing and post my status on Sunday.

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.

Sounds like you're covering some serious ground. Keep it up, man, it's awesome!

Backed! Congrats and thanks for taking this project on. I had a lot of hope placed in Red Dragon but that never took off like we all hoped. PVB Emu sounds killer!

Quote:
Awesome! Thanks again for everyone who has pitched in. For the month of April, we raised $137.34. Although I can't live off of that, it's still a great start considering all anyone had to go on was me saying "gimme moneys" and they believed in me. So all-in-all, this is a big win!

We should be playing games by the end of May, and hopefully be playing them on 3DS sometime in June. Expect it to get really interesting really quickly.

This is a work post.

Down to the wire! And that's just how I like it. Normally I try to have my weekly duties done by end of day on Friday, but obviously this is end of day on Sunday, which is not Friday. When I got the GUI stuff caught back up to the point where I had it in the old project, I went on an improvement spree and made everything about a... a jillion times better than it was. I'm happy to report that everything I wasn't completely happy with in the old code is no longer a problem in the new code.

Attached to this post is the .jar file of the current build (with the source code inside it). As expected, it looks about the same as the original build, but I can assure you that behind the scenes it's vastly different and vastly superior.

There is also an image attached to this post. I will be referring to it henceforth...


File Menu

When you start the program, you'll just get a big gray box and a menu bar. There are two options under File: Load ROM and Exit, and they do about what you'd expect. You can select any Virtual Boy ROM file, and it will attempt to detect incorrect files.

Once a ROM is loaded, the meat and potatoes of the user interface are displayed. There are four main panels, described below.


Disassembler - Upper left

The disassembler pane displays the game program from the perspective of the CPU, where each line is one instruction. A translation module in the project converts the machine code to human-readable assembly for your human viewing pleasure. There are literally dozens of configuration options in this module (debugger/Disassembler.java), but for the moment none of them can be configured with the front-end. The settings provided will display instructions using standard V810 conventions.

The hilighted line is the current value of the CPU's program counter, which represents the instruction that will be executed next.

The Up and Down arrow keys will scroll the contents of the display one line at a time, and Page Up and Page Down will do so one "screen" at a time (the number of fully-visible lines). Additionally, the mouse scroll wheel can be used to navigate in this manner.

In contrast to most debuggers, there is no scroll bar in the disassembler. A scroll bar that covers an entire 32-bit memory range really isn't usable, since even small movements can skip hundreds of megabytes at a time. I decided to leave it out, since I can't find a good reason to put one in there.

In order to seek to a particular address, Ctrl+G will bring up a Goto prompt. By typing an address into this box and clicking Ok, the output of the disassembler will be repositioned to include the address you entered.

You can seek to the value of the program counter with Ctrl+P.

The second column of output is the binary data that contains the instructions' bits, and for most purposes isn't all that useful. You can toggle whether this bytes column is shown with Ctrl+H.

The F11 key is Single Step, which executes the instruction at PC, the hilighted line. Most CPU instructions are implemented and fully-functional, with the exception of floating-point and bit string instructions, as they require additional research before being implemented.

The F10 key is Step Over, which attempts to execute until the instruction immediately following the current instruction is reached. This is useful for skipping over function calls as well as breaking out of loops like the one very early on in the crt0 routine. In order to prevent endless loops from hanging the application, a limit of 20 megacycles is placed on this command, which will make it stop automatically after executing one second's worth of CPU cycles.


Hex Editor - Lower left

The Hex Editor pane displays memory values on the bus as the CPU would see them if it were to perform a read operation. This is useful for examining and editing the memory in use by the simulated Virtual Boy software.

By default, no byte is selected for editing. In this state, the Up and Down arrow keys will scroll the contents of the display one line at a time. Page Up and Page Down will always scroll by one "screen" of lines. The mouse scroll wheel can also be used to navigate.

By clicking any byte value with the mouse, it will be selected for editing. In this state, the arrow keys will move the cursor around as expected. At this point, typing any hex digit will begin composing a new byte value at the selected address. After the first digit is typed, the temporary staged value is only that low digit, but by typing a second digit, a full 8-bit value is written into memory and the cursor is advanced to the next byte. In order to commit an edit after only one digit, press the Enter key.

To de-select the selected byte value and return to the default state, press the Escape key.

Ctrl+G will present a Goto prompt where you can type an exact address to seek to. In addition to navigating to that location, the byte at the specified address will be selected for editing.


Registers - Right-hand side

Both of the right-hand panes are for CPU registers. The top pane contains the special "system regsiters", while the bottom pane contains the usual "program registers". Any register with a "+" next to its name can be expanded by clicking on it, revealing additional controls.

The value of each register, shown next to its name, is displayed in a flat text box and can be edited directly with the keyboard by clicking it and typing into it. The new value is stored into the register either when the text box loses focus or the Enter key is pressed. Although any value can be entered, certain bits of certain registers cannot be written and this will be reflected in the value that is immediately displayed after editing.

Certain system registers represent multiple values that are packed into a 32-bit unit. By expanding these registers, the individual fields can be inspected and edited. The I field in PSW, and both fields in ECR, are text boxes that can be typed in. The remaining fields are 1-bit flags that are controlled via text boxes.

Although TKCW has bit fields that are displayed in the expanded controls, the register is in fact read-only and the expansion controls cannot be interacted with.

All program registers have options for representing the value in different presentation formats. The available formats are Hex, Signed decimal, Unsigned decimal and Float. When a particular format is active on a program register, the value displayed is in that format and any values entered with the keyboard will be processed as that format.


Debug Writes

Like I mentioned in last week's report, I set up the new back-end to support "debug" accesses for read and write operations. This is useful for the person doing the debugging, as it allows for test situations that aren't technically possible within the simulated software.

The debug accesses in use by the debugger are as follows:

• ECR is read-only to emulated software, but can be changed in the debugger.
• System register 31 provides the absolute value of the most recent value written to it, but the debugger can store any value.
• Editing ROM data in the hex editor will update the backing memory, even though the simulated software cannot write to it.


Known Issues

What appears to be a long-standing bug in Java is creating a layout error intermittently with no known cause. If, after you select a ROM to load, the window goes white or otherwise doesn't display correctly, you'll need to close the program and try again. Hopefully I can find out how to work around this issue, or maybe someone else can help track it down. Or maybe my RAM is going bad and that has something to do with it...

Wow this is awesome! Thanks for doing this!! Ok random question, but is emulating the virtual boy pushing the 3ds hardware to it's limits? I've heard that the old 3ds can have a hard time emulating the SNES.. And from what I understand the VB is either as powerful or slightly more powerful than the SNES, right?

I know the New 3ds can handle super Nintendo with no problem (I have 2 new 3ds and have done it myself).

So would an emulator such as this have a harder time running on the o3ds?