[Guy Perfect]

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 topic was modified 5 years ago by Guy Perfect.

Wow, this emulator has already sailed up there to be the very best one available for us developers! Thanks Guy Perfect!

Mednafen has a weird bug with bitstrings copied to one of the frame buffers, but this one works spot on!

I love the VIP window, and if I could make one request it would be to have it update continuously while a game is running as well.
I realize this could potentially be thousands of times per frame, but doing it just once at the end of each frame would be enough. VisualBoy Advance has this feature for GBA for example, and it helps for studying how different games pull off animations under the hood.

Please continue working on this project, much appreciated!

Also, my red/blue glasses doesn’t quite match any of the presets, so prioritizing the color settings dialog would be cool too 😉

I was messing around with Red Alarm a bit, and it turns out the game IS actually running, it just doesn’t draw anything to the console before reaching the title screen. If you press A a couple of times in the dark, and F5 in and out of the debugger, you can see the framebuffers gets updated with all the precaution graphics, but not the console itself. Of course the CPU window also highlight alot of exceptions all the time…

It’s actually kind of playable after that 🙂

Attachments:

1. 

   red_alarm.png
   

DanB wrote:
I was messing around with Red Alarm a bit, and it turns out the game IS actually running, it just doesn’t draw anything to the console before reaching the title screen. If you press A a couple of times in the dark, and F5 in and out of the debugger, you can see the framebuffers gets updated with all the precaution graphics, but not the console itself. Of course the CPU window also highlight alot of exceptions all the time…

It’s actually kind of playable after that 🙂

Question: Does Red Alarm put graphics data in any of the other tabs besides the framebuffers’ tab?

StinkerB06 wrote:

Question: Does Red Alarm put graphics data in any of the other tabs besides the framebuffers’ tab?

Yes, all of them are loaded correctly.

Hi projesct is dead ? I want so much this emulator !

To the future researcher looking for answers: I revisited the audio thing for an unrelated project and took the time to work through it and find a passable solution. Java is not set up for this.

Audio output in Java is most easily accomplished via [font=Courier New]AudioSystem.getSourceDataLine()[/font], which in turn directly provides a line object and methods for sending output to the speakers. For most applications, this is how you’ll want to manage audio.

SourceDataLine has some methods for tracking playback status, namely [font=Courier New]getLongFramePosition()[/font] and [font=Courier New]available()[/font]. Although the frame position is useful for determining approximately how much data has been consumed, it does not reliably reflect how many resources are currently available to the line. And while [font=Courier New]available()[/font] does give the number of bytes that can be written without blocking, it is likewise not reliable due to an unintuitive behavior of the implementation. If there are n bytes available and you write some number of bytes m, it would be reasonable to expect that the next call to [font=Courier New]available()[/font] would give either n – m or a slightly larger number depending on playback, but that’s not always the case for whatever reason.

Ultimately, there is no way to monitor the state of resources within a SourceDataLine during playback. The emulator depends on the opposite being the case, and consequently falters pretty spectacularly.

Further experiments and profiling of Java’s audio behaviors have turned up a best-case scenario, which is still not completely satisfactory, but if it’s the best-case, it won’t get any better, right? The solution is two-fold:

1) In order to minimize the opportunities for stuttering during playback, data should be fed to the SourceDataLine object in its own thread, where it can block on a call to [font=Courier New]write()[/font] and likewise block when retrieving sample buffers via something like a BlockingQueue. This ensures data will always be made available to the SourceDataLine with minimal latency.

2) The amount of data written at once to a SourceDataLine should be as large as possible. SourceDataLine appears to introduce some overhead and begins to stutter if the data buffers are too small, and the garbage collector can potentially interrupt the software while it’s attempting to have samples ready in time. Bear in mind that the thread scheduler may give the thread something like 15ms at a time to execute. By minimizing the number of calls to [font=Courier New]write()[/font], overhead is kept low and garbage collection has less of an opportunity to interrupt playback.

The concern now lies in the fact that the actual delay between an action occurring on-screen and the audio for that action coming from the speakers should ideally be as short as possible, and that contrasts with Java’s approach to audio. I was able to set up a mechanism that initializes audio output with a configurable initial delay built of empty samples, and writes to the output line in buffers with a configurable length. On my personal rig the optimal setup is something around a 0.15s initial delay and a 0.1s block size, although once in a great while a very short, single stutter does occur. Eventually the JVM profiler seems to get the hang of it, so any window of interruptions in playback should be short-lived.

According to my time log, I spent 30.847 hours working on this problem. It was not a simple problem!

Hey is this still going? i cant find a download.

From what I can tell this is vaporware. I doubt there will ever be a release.

This still in the works?

The PVBEmu project has been rebooted some weeks ago and can now be found here: http://git.virtual-boy.com/PVB/pvbemu

You can get the builds from last year’s version here: https://www.virtual-boy.com/tools/pvb-emulator/

Oooh I saw the chat on the discord, didn’t realize there was an updated build of it on git, that’s great.

So what’s the status on this now? Almost done? Still in the works?