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
The Sacred Tech Scroll draft just got updated with details of the VB’s hardware timer. http://perfectkiosk.net/stsvb1.html#timer
In the Java program’s update, the bindings for the L and R buttons are “E” and “R” respectively.
Attached to this post is another classic feature-testing program called Timer Workshop:
The left D-pad moves the cursor around, the right D-pad’s up and down changes the current selection, and pressing A when “Write” is selected will write a value to TCR using the current Clock, Interrupt, Zero Clear and Enable settings. Changing the digits of Reload will immediately write to THR or TLR as appropriate.
As far as I can tell, I’ve worked out all of the errors in the previous implementation and the emulator now correctly simulates the timer. However, none of the broken games have magically fixed, so I won’t put out an update just for this small change.
If you want a quick laugh, go ahead and load Timer Workshop into the current build and watch it break. The moral of the story is that I need to make these “Workshop” programs before I declare something implemented. (-:
The Sacred Tech Scroll has been updated accordingly.
Attachments:
Got a new update attached to this post. It includes a few fixes to floating-point operations and VIP behavior that fix a few games like Bound High!, Galactic Pinball and Vertical Force.
The application was reorganized a bit. The Console window still pops up when you load a ROM, but the other windows are now accessed through a new Windows menu.
When you run the emulation, focus is now correctly given to the Console window, so you no longer have to click on it. A third anaglyph color mode has been added with full intensity red/blue like conventional VB emulators.
Breakpoints
Did you think the timer was kinda small for the last two weeks’ worth of work? It was! Truth to tell, I only did the timer when I did because it was small and I spent the last two weeks working on breakpoints.
It might not look like much, but the new Breakpoints window is one of the most significant features of the entire application. This tool allows you to stop emulation whenever something you’re interested in happens. This is big news for reverse engineering and debugging efforts.
The flexibility of this emulator’s breakpoint system is far and away above anything else I’ve seen (except for MHS). Let’s take a look!
Breakpoints can be configured to trigger on one or more of the following conditions:
• Read – An instruction attempts to read from the bus
• Write – An instruction attempts to write to the bus
• Execute – An instruction is about to execute
• Exception – An exception was raised
Crucially, all breakpoints are captured before their respective events are processed. For example, a write breakpoint will stop the program before the value gets written, letting you see what value is being replaced.
Exceptions include operations errors as well as all interrupts. For the most part, interrupts should be trapped with execute breakpoints on their handler addresses.
Addresses
The address field allows you to specify an arbitrary list of individual addresses and address ranges. All figures are expressed in hexadecimal as follows:
• A value by itself is an individual address.
• Two values separated by a hyphen is a range of addresses, with the start on the left and the end on the right.
• Multiple addresses/ranges can be provided simultaneously by separating them with commas.
For read and write breakpoints, the address specifies the bus address being accessed. For execute and exception breakpoints, the address specifies the address of the instruction to be executed or that raises the exception.
It’s totally valid to mix-and-match addresses and breakpoint types.
Conditions
The condition field is the big kahuna that sets this emulator apart from the rest. It’s a fully-featured expression evaluator that accepts a set of C-like operators in order to determine dynamically when a breakpoint should trigger. This gives breakpoints access to CPU registers, the contents of system memory and operands for the current instruction.
Earlier today, I was helping someone track down Wario’s animation data in Wario Land. We started by looking at object 2 (Wario’s eye), which has an address of [font=Courier New]0003E010[/font]. A write breakpoint on that address stopped the program in the function at [font=Courier New]FFFC1D0C[/font], which is a small function that copies data from a global variable into OAM. Armed with that knowledge, we figured out where object 2 came from by inspecting the CPU state, which allowed the guy to find the data he was looking for.
In the above screenshot, you see a sample breakpoint that stops on all function calls in Wario Land’s crt0. The condition expression is “[font=Courier New]inst == jal || inst == jmp && reg1 != 31[/font]”, which you can see is accessing instruction operands in order to stop on only specific instructions. It also supplies an address range.
The supported features in the condition are so expansive, in fact, that I can’t go over it all here in this forum post. So instead, an HTML file is attached to this post (and included in the .jar) that covers all the specs. I promise it won’t disappoint.
The expression evaluator was also exposed to the Goto prompt in the CPU window (Ctrl+G in the disassembler or hex editor).
Attachments:
No amazing, ground-breaking new developments this time, just a round of fun and profit.
New features:
• The game pad is now properly implemented and the tech scroll updated accordingly
• Added support for .isx debugger ROMs
• Added [font=Courier New]value[/font] breakpoint condition symbol for the actual value being read/written
• Added disassembler comment for when an exception/interrupt is raised
• Added disassembler comment for [font=Courier New]JMP [lp][/font] instructions
Bug fixes:
• Extended duration of [font=Courier New]DPBSY[/font] and [font=Courier New]XPBSY[/font], enabling Mario’s Tennis to function
• Corrected the operation of [font=Courier New]XB[/font], enabling Jack Bros. to function
• The disassembler now displays [font=Courier New]TRAP[/font], [font=Courier New]XB[/font] and [font=Courier New]XH[/font] incorrectly
• Step will now enter an exception handler without also executing its first instruction
• Step Over was previously broken, and was reworked to use a breakpoint
• Read and Write breakpoints now detect if any of the bytes being accessed are in the given ranges, not just the exact byte specified
• The Breakpoints window will no longer erroneously show a star next to Read, Write or Exception breakpoints that don’t match the current emulation state
Attachments:
Show of hands, who expected another “Workshop” test ROM? Ah good, everyone. Glad to see it.
Attached to this post is Bit String Workshop, useful for testing the bit string instructions in new and unusual ways.
The top section is the user-configurable part. Move the cursor around with the left D-pad and use up and down on the right D-pad to change values. When you press the Start button, the selected instruction with the current register settings and RAM contents will be invoked, displaying the result in the bottom section.
In the big list of bits, the bus address [font=Courier New]05000000[/font] is the location of what is visible on-screen. Each line is 32 bits–one full word–with the least-significant bit on the left.
When the Timer field is set to some non-zero value when Start is pressed, it is used as the counter value on the timer with a 20 µs tick interval. When the timer hits zero, it fires an interrupt that will abort any active bit string instruction, then return early so you can see the state of the registers when the interrupt was raised.
The reason there are six rows of bits for what is ostensibly a fairly simple procedure is because of a tricky buffering behavior the CPU exhibits when processing arithmetic strings. The screenshot shows the output that the hardware gives, and I wasn’t able to find any other emulator that produces the correct result. PVB gets to be the first. (-:
The tech scroll document has been updated accordingly.
Attachments:
You’re not wrong: the UI needs some work. Emulator operations are controlled with keyboard commands:
Emulation Commands
F5 – Run/Pause
F6 – Frame advance
F10 – Step Over
F11 – Step
When running, only the Pause command will be carried out.
Application Commands
Ctrl+3 – Cycles between color modes
Ctrl+B – In disassembler toggles the bytes column
Ctrl+G – In disassembler or hex editor prompts an address
Ctrl+P – In disassembler or hex editor seeks to PC
Controller Input
F – A button
D – B button
S – Start button
A – Select button
E – L button
R – R button
Up Arrow – Left D-pad up
Left Arrow – Left D-pad left
Down Arrow – Left D-pad down
Right Arrow – Left D-pad right
I – Right D-pad up
J – Right D-pad left
K – Right D-pad down
L – Right D-pad right
No build this week, but there’s plenty news about updates. Part of what’s taking so long is a management shuffle at work resulting in an unusually heavy workload, and part of it is… well, let’s find out!
For starters, the link implementation is all set up and works just fine. I was able to test it with a truly terrifying hack-n-slash second Console window:
The “Communication Workshop” program in the screenshot can be found attached to yonder post, but since I can probably count on one hand the number of people who can make effective use of it, there’s not much incentive for anyone to go grab it. But it does indeed work correctly, which is the important part.
As may be apparent, the main application window needs to be adjusted in order to properly present two linked simulations to the user. I decided to take the opportunity to redesign the main window entirely, fixing various usability problems along the way and introducing my vision of the final application UI.
__________
Many Hats
The next build introduces a new application paradigm: presentation is split into two modes depending on the user’s preferences. In Game Mode, the top-level window is only the menu bar and video display, and in Debug Mode, the MDI that has been used up until now will be used. Debug mode is toggled on and off in the File menu.
In Game Mode, the File menu has these options. Most should be pretty self-explanatory, though New Window will produce another top-level main window with all the same features. This is what will enable link play, as we’ll see in a bit.
In Debug Mode, the File menu becomes slightly different as it adds options for ROM file management as well as individual control over SRAM (in Game Mode, SRAM is automatic using the ROM filename). Modifications made to ROMs in the hex editor or, eventually, the assembler can be saved as new files for ease of development. ROMs and SRAM can also be resized.
The new Emulation menu brings options that were previously known only to the monks of the mountain who study such things. All of the old keyboard commands will continue to function, but now every command available becomes more accessible thanks to being visible on-screen. Step and Step Over are hidden in Game Mode, since they’re not useful there.
The Link sub-menu brings up a list of additional windows, allowing the user to select one to associate as a communication peer. This is where the New Window option from the File menu comes in handy.
All of the settings will actually be accessible from a single window, but the Settings menu has some common options to help the user get to where they need to go without excessive navigation of the menus. Input, Video and Audio all bring up a new Settings window, but they each automatically select the appropriate tab/page. The Settings item simply shows the Settings window in its most recent state.
Additional settings–such as localization/language, disassembler configuration and the eventual native implementation selector–will also be in the Settings window, but simply not have shortcuts in the Settings drop-down menu itself.
The Debug menu should be familiar, as it’s the same as the Window menu up until this point. The entire menu is hidden in Game mode.
__________
While most of the menu items are right-this-second unimplemented, I was still able to get a decent chunk done over the week despite the activity at work…
Anyone familiar with the source code layout will find that App has been broken free of its connotation with the main application interface, and a new class MainWindow was introduced. App functions mainly as a window manager, but also houses the global configuration accessible through the Settings menu.
The code that drives localization of on-screen control messages has also been updated to add some more flexibility that wasn’t there before. The new features will benefit messages that require substitutions, such as the main window title and the Breakpoints window error message. With the new improvements, 100% of the strings are now fully localized and can be swapped out with a new localization file at runtime. An associate of mine has agreed to do a Japanese translation when the time comes, so it won’t just be US English through the end of time.
What I’m currently working on involves input from the user. All of the keyboard bindings are about to be user-configurable, which includes things like “F5 to run/pause” and “D is the B Button”. It’s being set up to eventually support controller/joystick input as well, although that will require native modules to pull off.
