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
Although the outward functionality appears to be relatively the same, reworking the application UI to accommodate linked pairs of emulation windows was a lot of intricate work. But it’s done now!
Attached to this post is a new build: (See following post)
New Features
• The main application window has been redesigned
• The communication port is now implemented
Code Changes
• Unmapped reads in the [font=Courier New]0x02000000-0x02FFFFFF[/font] range will now be zeroes
• The localization driver was updated to support substitutions
• A new class MainWindow was created for representing the application interface
• Multiple windows can now be instantiated and linked
• Global input commands are now implemented and are configurable
• The Config class and its new helper classes are in a new “config” package
Bug Fixes
• Writes to DPSTTS were forwarding to DPCTRL, which I don’t think is correct
• Simultaneous Left/Right and Up/Down are disabled by default, correcting a crash in Wario Land
__________
To use the new communication feature:
• Create an additional emulator window with File → New Window
• Associate communication peers through Emulation → Link
• Use the emulator windows as you normally would
When only one emulator window exists, the Link sub-menu will not be available. When multiple windows exist, the Link sub-window will display a list of all current windows, allowing the user to select one to associate as a communication peer. If the window is already linked, a Disconnect option is also available in the Link sub-menu.
Communication Workshop has been attached to this post to help with testing.
I did a lot of experimentation with boosting performance when linking simulations, but the unfortunate fact of the matter is that the only way to keep linked instances synchronized is to process them one cycle at a time. I thought maybe checking if both simulations were in halt status I could boost performance by skipping to the next interrupt, but communications don’t always raise interrupts, and there’s no way to predict ahead of time when the software is going to trigger a communication event…
… So long story short, linking in the current Java implementation is slow. Hopefully the eventual native implementation can handle linking at full speed.
Each emulation window animates frames in its own thread as a consequence of how timers work. However, linked frames will only use the animation thread from whichever window initiated simulation processing. I’m pretty sure I got all the logic correct, but since thread locks are rather intermingled under a variety of circumstances, it’s possible there might be some combination of circumstances that could cause the application to deadlock.
The following describes the general contract of the linking behavior:
• Unlinked windows operate in their own threads
• When paused windows are linked, the one that invokes the Run command controls both
• When running windows are linked, the one that invokes the Link command controls both
• When a running and paused window are linked, the paused window is activated and the one that invokes the Link command controls both
• When running linked windows are disconnected, the “slave” window resumes control of itself
• Closing a linked window invokes the Disconnect command
• The following commands will only apply to the linked window that invokes them: Reset, Frame Advance, Step Over, and any user-defined breakpoints
Keep an eye out for any reproducible problems that might occur with thread management, and please report any problems in a reply. I did my best to make sure it works correctly, but this is a bit of an atypical method of threading windows and I don’t want to say with absolute certainty that it can’t break.
__________
Besides the link feature, the main window was redesigned and all of the old features remain implemented. However, the only new feature that was implemented is the Game/Debug Mode setup, with additional menu options to be implemented later. One thing to keep in mind with regards to window modes:
• In Game Mode, emulation will always begin when a ROM is loaded
• In Debug Mode, emulation will always be paused when a ROM is loaded
This should be most useful to the most users and might wind up in the Settings window depending on what I decide on the matter.
Ctrl+3 still cycles anaglyph colors, but it is a temporary command that will be removed once the Video Settings interface is implemented, which will allow the user to configure whatever colors they wish.
The debugger interfaces still do not contain any safeguards while the simulation is running, and should not be used unless the simulation is paused. This is also temporary, as I didn’t want to delay this build any longer than necessary.
Step, Step Over and Frame Advance can now be used while the simulation is running. All three will cause emulation to pause after they complete.
Attachments:
Whoooo boy, that was… that was an experience.
I spent literally every waking hour the last two and a half days working on setting up the native module stuff, and it has been very successful. However, as you can see by the lack of anything to download attached to this post, it hasn’t been “ready for prime time” successful. Very, very nearly, but not quite.
When I finally got everything put together and flipped the audio on… the exact same stuttering and slow-down occurred that was present in the Java implementation. This of course made me suspicious, as having identical performance in the native module is preposterous. But my earlier troubleshooting involved disabling audio rendering in the Java code in exchange for some supplied zeroes, and the speed went back up. I reasoned the audio processing itself was to blame…
After the curiosity with the native audio, I switched back over to the Java implementation and merely disabled sending the rendered audio to the speakers. That also ran full-speed. In fact, it stayed full-speed while logging audio to a file, despite being the Java code. So it’s not the processing overhead at all! My best guess is that the earlier test “worked” because the initial contents of the buffer was zeroes and I was writing zeroes into it. Java may have found a way to make that work.
As far as what this means for getting good, full-speed audio output in Java, that one’s got me a bit worried. VSU Workshop manages to run all six channels full-speed in the Java code, and the native implementation has more than enough muscle to get the job done, so exactly what Java is doing or how to make it do what I want is a mystery.
Truth be told, Java Sound isn’t designed to be used as a timing source like the emulator requires. It doesn’t actually provide any means to determine how much audio has finished playing or any mechanism for signalling the application when a buffer has finished. What I’ve been doing so far is a not-exactly-documented use of SourceDataLine.available(), and it’s obviously causing problems. That was my best effort, though, and I’m inclined to think that perhaps Java Sound isn’t going to be a good option.
__________
In other news, porting the Java code over to C was pretty much as smooth as I was expecting it to be, with two exceptions: the VIP rendering code and pretty much everything to do with breakpoints.
The VIP code is a couple of monstrous functions with many variables that were designed to produce the images as efficiently as possible, which they do rather well for the most part. Porting those to C proved to be a bit troublesome, as I did a lot of sign extensions with Java’s shift operators (behavior that is guaranteed in Java but not necessarily in C) and a few other Java-centric design choices. After converting to C with the associated adjustments, there are some bugs in the rendering code that I’m not happy with. I’ll either have to try again or write new rendering code to make sure it works in both languages.
The breakpoints library is another matter altogether. Unlike the emulation core, I didn’t take care to design breakpoints in a way that would easily adapt to C. The native version of breakpoints that I came up with has some drastic differences and what code did make it over is ugly as heck after the needed modifications, and I’m overall disappointed with the whole thing. They function well enough to get games running (at full speed, naturally), but beyond that I want to toss them in the garbage.
There’s a mounting pile of other considerations that would require extensive refactoring to incorporate new things I’ve learned along the way. At this point the prospect of a total project do-over seems very appealing, but I haven’t decided what I want to do going forward.
