You are not logged in.
Lost Password?

All Posts (Guy Perfect)




#1
Re: PVB Emulator
Posted on: 9/9 16:58
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
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 AudioSystem.getSourceDataLine(), 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 getLongFramePosition() and available(). 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 available() 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 available() 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 write() 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 write(), 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!
Top

Topic | Forum


#2
Re: PVB Emulator
Posted on: 5/3 17:09
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
Thank the stars, that's music to my ears. tl;dw: Nintendo mentioned during an investors meeting that they have nothing coming down the pipe for 3DS in 2019. It's about frickin' time.
Top

Topic | Forum


#3
Re: Spectre VR Dev Thread
Posted on: 4/23 2:10
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
Quote:

blitter wrote:
Disassembling and making sense out of optimized, unsymbolicated assembly is not for the faint of heart and definitely not a task for a beginner.

While it's true that someone who is just getting into programming may not be well-equipped for the task, the process in general is not as hard as you might think. With the right resources, I'm faithful that SpectreVR (the user) can pull off this Spectre VR (the game) project.

Quote:

blitter wrote:
If your goal is to make a version of Spectre on the Virtual Boy, very little of the Mac code will help you anyway. Here are a few major points about the Mac version that will not transfer over:

Only a cross-section of the game's code is necessary for a faithful port: the fundamental game engine and general rendering logic. The nitty-gritties about how the game communicates I/O with the OS or interacts with the windowing system aren't all that important when porting the game to any target, let alone Virtual Boy. As long as one knows what the game wants to do, the rest can be handled by a purpose-built implementation.

Also, between those Inside Macintosh books and Macintosh Programmer's Workshop--both of which are available online--we still have access to information regarding the old system API.
Top

Topic | Forum


#4
Re: What all is being worked on?
Posted on: 4/7 7:38
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
I've got a little somethin' in the works...

Attach file:



png  WhatCouldThisBe.png (120.09 KB)
3060_5ca98ccb78b1b.png 1170X790 px
Top

Topic | Forum


#5
Re: PVB Emulator
Posted on: 4/6 23:21
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
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.
Edited by Guy Perfect on 2019/4/8 17:00
Top

Topic | Forum


#6
Re: PVB Emulator & Fundraiser
Posted on: 4/4 5:58
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
I spent the last week working on my Wario Land project, which has had a fantastic start, but this isn't the thread for that. The reason I'm posting right now is because tonight, out of curiosity, I decided to do a little research into the JNI to see what I would need to do in order to get the native emulation core set up. I figured it would be some involved process with headers and libraries every which way, but that's not the case. In fact, working with the JNI is easy. Really easy.

It's so easy, in fact, that I've decided to turn my immediate attention toward getting that native implementation set up posthaste. There's a little bit of added work in getting the code moved over from Java, but the vast majority is done as the Java implementation in and of itself, so it shouldn't take more than a handful of days. I'll keep you posted.
Top

Topic | Forum


#7
Re: PVB Emulator & Fundraiser
Posted on: 4/1 17:39
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
Quote:

trailboss wrote:
Ha, I know how this story ends just from experience. Jokes aside, a place to formally submit bugs would be nice

Hasn't failed me yet. Just look at this great emulator we have already!

Bug reports go in this thread. Don't worry, I'll see them! You have bugs to report, don't you?

Quote:

Raverrevolution wrote:
How do I load this up in my 3DS?

You don't, just yet. The most recent development finished up the hardware functions in a Java implementation, which is designed to run on a workstation. The next phase (after filling out those greyed-out menus) is to port the implementation to C so it can be built as a native library, then use that on 3DS.

I'd have been working on 3DS before now, but Nintendo for some unknown reason refuses to let the silly thing die. I don't want to risk getting a homebrew solution set up just to have a firmware update blow it out of the water. And as of the time of this post, Nintendo released a game for 3DS (Kirby's Extra Epic Yarn) a mere 24 days ago, meaning they're not ready to take their eyes off of it just yet.

Let's hope Kirby is the end of 3DS. I'm really itching to sink my teeth in.
Top

Topic | Forum


#8
Re: PVB Emulator & Fundraiser
Posted on: 3/29 17:10
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
Quote:

VmprHntrD wrote:
It's a nice try at an emulator definitely, guess it's just java being java perhaps holding things back some due to how it works.

Fortunately, I was thinking ahead when I wrote the Java implementation of the emulator core. I did it in such a way that converting it to C would require minimal modification, so for the most part it'll just be a copy/paste job and changing some data types... and turning all of the comments into /* C style */... I even plan to make functions with names like Integer_compareUnsigned() and Float_intBitsToFloat() just to keep the two code bases that much more parallel.

The JNI module that will expose the C implementation to the emulator application only needs to implement the methods declared in the VUE interface, which itself isn't a huge deal. It'll be a lot of busy work getting the ~236 KiB of Java source code moved over to C, but it's nothing that requires anything resembling expertise.

Plus, it'll give me a chance to review every line of code just in case I think of something along the way that could improve it.

Quote:

trailboss wrote:
Do you plan on getting this up on Github? I think that would be a great place to host builds/report issues/make pull requests.

My opinion of Github aside, I haven't been bothering with version control so far since I'm the only one working on the project. And even if one or two other people do get involved (which doesn't seem likely), I'll still probably not elect to set up a repository for it. And the source files are all in those .jar files, so it's not a matter of making them available.

In short, using version control at this time would just be giving myself more work without adding anything of value. (-:
Top

Topic | Forum


#9
Re: PVB Emulator & Fundraiser
Posted on: 3/28 17:20
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
Quote:

VmprHntrD wrote:
I'd hate to think what machine you'd need to get this to run right with the audio on.

The JVM is able to get short burts out--longer than the 1/50 second rendering interval--so I know it's not a limitation of CPU power at the lowest level. The native implementation written in C should shine a better light on this, since it doesn't have any of the sandboxing overhead that the managed Java code has to deal with.

Quote:

VmprHntrD wrote:
Also are some games implemented and others not on this?

The emulation core in its current state isn't 100% compatible with the commercial library. Red Alarm in particular is mostly supported, but stopped booting after I adjusted the number of CPU cycles taken by a store operation. I don't know what the game is doing that it would even be aware of how long a store takes, but getting the game up and running will require some investigation in the debugger. It's a great example of why the CPU and breakpoint features are so important to have!

If anyone is technically inclined and would be able to help look into Red Alarm specifically, that would be greatly appreciated.

Quote:

VmprHntrD wrote:
And thirdly the menu is grayed out I noticed for configuring the emulator settings for audio, visual, inputs.

Anything greyed out (except for the Link menu when only one window is active) isn't implemented yet, so that's not an error. If you want something specific to help with testing, let me know and I'll make a point to get it set up for you.

Quote:

Fire-WSP wrote:
And you entirely missing the point. There is and was interest in the Emulator but as I said from the beginning, the people today do not care so much about the next PC emulator or debugger. That is only us here who care about such stuff mostly.

Every part of the project is important, which is a much broader scope than running the core on 3DS. The documentation and Java implementation account for some 80% of the project goals, and they've taken a fair amount of time and effort to get to their current state. The CPU and breakpoint debuggers in particular have been instrumental for research and bug-hunting, so it's not like any development time has been spent on frivolous things.

The remaining 20% is still on the way, but it's abundantly clear that I'd be doing it mostly for myself. The invitation still stands that if someone needs something implemented I'd be happy to work on it, and the source code for every build released has been bundled inside of every .jar file.

Quote:

Fire-WSP wrote:
[...] I have to say Bye Bye 3DS VB Emulator.
Reading the last post this will never happen anymore.
Shame.

[...]

So okay, who is next in line for doing finally the right thing???

Overlooking the part where I said exactly the opposite, is this really the tone you want to convey?
Top

Topic | Forum


#10
Re: PVB Emulator & Fundraiser
Posted on: 3/28 0:44
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
With the entire emulation core implemented, with the experience of producing the emulator of my dreams, and with a sigh of relief, I'm finally freed up to do other things. I won't be abandoning this project--far from it--but as of this latest update, it is no longer my primary spare-time focus. I'll still work on it from time to time when other things don't have my attention, but since interest in this project is very low, there are other things I want to be doing that I've been putting off.

The remaining window menus will be implemented in the coming weeks, but I won't be sticking too strongly to my Wednesday update schedule like I have been for the past couple of months. If someone is keenly interested in something that can't be clicked on, I'd be happy to prioritize it to make it available, but if it's just a matter of "it's not done yet", then I'll get to it when I get to it. (-:

As for what I will be doing, there's 1) a long-neglected project with some other PVB members I'd like to get the ball rolling on, 2) something I want to do with Wario Land and 3) something related to NES that I'd like to keep a complete secret until the time comes.

For those who have stuck with me through all of this, thank you for your patience and thank you for your financial support. Planet Virtual Boy's emulator is becoming something great and that means the world to me.
Top

Topic | Forum