[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, 7 months ago by Guy Perfect.

Man, let me tell you, I have no idea what is being described because I’m not a programmer, but I absolutely love these technical updates.

It’s like you’re creating the Rosetta stone so the entire world can enjoy these games that we all love on a more easily accessible device that seems like the most natural solution.

I cannot wait for the one day to actually see this work as it should. I’m also confused at why Nintendo never did this themselves a long time ago.

I cannot thank you enough Guy!

Very nice progress here.
Also thank you to that guy who donated a huge sume to keep it running for a few month.
The Patreon also looks quite okay so far.
But it will still going slow there until there is something playble on screen.
People from GBATemp for example are mostly not very interested in deep technicial information. They only want to knew as much as what is needed to hack your system to play emulators or roms. They don’t care about Worlds or VIP functions.
Most of them were babys or not born when the VB was available.
So they only act upon sensation and on what they can see and touch.
It will propably take a bit more time before patreon brings in money more frequently.

This is a work post.

That pesky Worlds tab is finally done. After over 9000 revisions to the underlying code of the VIP window, all tabs are now simplified and playing nice with one another. And worlds are implemented.

By this point I’ve kinda forgotten exactly what I need to say about it… The Objects and Worlds tabs are now present, which do a simple anaglyph output for the time being. The default colors are red and blue, but you can toggle between the perception-calibrated colors sets with Ctrl+3.

The Framebuffer and Registers tabs remain, but I need to sit down and figure out what comes next. I’ve been fighting with Java’s middle-of-the-road graphics support for so long that my train of thought derailed a couple weeks ago and never got back on track. O-:

The current build is attached to this post, and the Sacred Tech Scroll has been updated on the project page with the latest revisions.

Attachments:

1. 

   worldstab.png
   

1. pvbemu_20180609.jar

I’m assuming this is Mario Kart Virtual Cup? That picture shows a very nice Mode-7 graphic of a Mario Kart racetrack to my eyes. And that perspective projection makes it look nice!

Has anyone experienced the generic colors not working in all but the Characters tab? I’m having this issue. Not even Ctrl+3 is changing the color palette.

Attachments:

1. 

   bandicam-2018-06-09-20-45-02-313.jpg
   

2. 

   bandicam-2018-06-09-20-43-41-649.jpg
   

3. 

   bandicam-2018-06-09-20-44-18-681.jpg
   

That’s actually the F Zero homebrew. Interesting project, but halted unfortunately 🙁

Oh, thanks! I was wrong!

I’m also experiencing another problem.

When the emu starts, the anaglyph colors initialize to red and blue. Pressing Ctrl+3 makes it green and magenta. Do it again and red and cyan. Do it once more and it’s back to green and magenta. There’s no way to get the red/blue one back. Note that the colors blue and cyan are different.

StinkerB06 wrote:
Has anyone experienced the generic colors not working in all but the Characters tab? I’m having this issue. Not even Ctrl+3 is changing the color palette.

If the program initializes the palettes to black, they’ll be drawn as black even when using the generic color scheme. All the generic palette does is use a pre-defined set of brightness levels instead of the current brightness settings in the VIP. As such, black is black no matter what. (-:

speedyink wrote:
That’s actually the F Zero homebrew. Interesting project, but halted unfortunately 🙁

It ain’t dead, though. I’m curious to try offloading some of the image processing to the CPU and see if I can boost the performance without affecting the output. But that’s for another day.

StinkerB06 wrote:
When the emu starts, the anaglyph colors initialize to red and blue. Pressing Ctrl+3 makes it green and magenta. Do it again and red and cyan. Do it once more and it’s back to green and magenta. There’s no way to get the red/blue one back. Note that the colors blue and cyan are different.

That’s correct. The red/blue set is just the default, and it’s not changed until Ctrl+3 is used. The final application will allow the anaglyph colors to be fully configurable, but I highly discourage use of straight-up #ff0000/#0000ff for reasons discussed earlier.

I simply can’t wait for this to happen.

Attachments:

1. 

   bandicam-2018-06-13-02-34-21-551.jpg
   

Splatoon 2: Octo Expansion came out of nowhere and took my attention for a week, but I’m back on the Registers tab and things are going swimmingly. Expect the VIP window to be mostly done this week, save for the Framebuffer tab that will be coming later.

Don’t grow too attached to the current GUI (CPU window included), because it is subject to change eventually. With each new piece that goes into the interface, I come up with ideas and learn things about how different pieces interact. Eventually I’m going to gut the whole thing and rebuild it (bigger, faster, stronger, etc.), but not right now. There are two reasons for this: 1) I could spend all my time making things perfect and then never really moving the ball forward and 2) after more GUI elements go in, I may find myself in a position where I just have to rewrite it all again anyway.

So for now, it’s business as usual, with the functional-yet-lackluster GUI that will be replaced one day. (-:

any new updates Guy?

Still alive! Sorry about that. I said “expect something this week” and now it’s two weeks later. My bad. (-:

While yes, progress has been made on the project, it was on the back-end and the VIP window isn’t complete yet. I reworked most of the VIP I/O interface to correct for an oversight where I was treating all memory accesses as though only the emulated CPU could do it. Since the debugger is allowed to do “debug” accesses, it meant allowing for certain impossible things such as writing only the upper byte of an I/O register, etc. That’s all sorted out now, and the Registers tab is looking amazing.

So what was I doing for two weeks? The short answer is Something Came Up™. It was a time-sensitive affair not related to Virtual Boy that I was hoping would be resolved in just a handful of days, but I don’t want to sink any more time into it. Virtual Boy needs me! It’s a bit frustrating because the other thing is nearly fulfilled and yet I have to leave it in the hands of the others involved. Oh well, that’s how things are, and VB needs more love, so VB gets more love.

We now return to our regularly scheduled development. The support for this project is always well appreciated and I’m looking forward to charging back into it. <3

OMG!!! Post a picture of it please!

Excited for updates on this project!

Yeah. I’ve also thought about what the future tabs may look like.

I’m as excited as you guys are! A lot has been going on, but since none of it is visible on the front-end and I’m not quite finished with what I ultimately decided to do, I can’t really post about it yet… So thank you, everyone, for your patience. I realize it’s probably felt like a blank wall in this thread lately, but it’s totally worth the wait. <3

My OCD got the better of me with regards to the mechanics of the VIP window and I found myself unable to allow it to slip through in a "good enough" state that I wasn't exactly happy with. After all, that's how we get shoddy, bloated, over-par software: we make compromises early on under the assumption that it will be "improved later on", and then ultimately "later" never comes around. I don't want that to happen. Not to my project, and not to Virtual Boy. I want it done well, and I can do it well.

How this mess got started in the first place was an unfortunate assumption. When I first designed the VIP window, I started with the Character tab and figured I could set up a simple little mechanism to decode character memory into pixel patterns. Then I did the BG Maps tab and recognized that I needed to rely on the functionality of the Characters tab, also requiring additional palettes and mirroring capabilities. Then I worked on the Worlds tab and found the need to rely in turn on the functionality of the BG Maps tab, and so-forth. What started as a “simple quick thing” wound up becoming the cornerstone of the entire UI, and I wound up gluing more and more onto an abomination instead of building a lean machine from the outset. Right now, finally, I bit the bullet and decided to build that darn lean machine.

It caught me off-guard because in software design, it becomes second-nature to design code in such a way that it is what they call loosely coupled. What this generally means is that all code that pertains to a certain concept should be as self-contained as possible, with only minimal interfacing with other modules. This is almost universally the best way to set it up, since it means modules can be hot-swapped with others in the event of–for example–new development, but it isn’t always possible. In the case of the VIP window, I went into it thinking each tab would be loosely coupled from the others, and designed them to be self-contained independently from one another. Once I began implementing them, however, I found that they were intrinsically linked because later tabs relied on the features of earlier tabs–resulting in a tightly-coupled situation. It was a mesh of contradicting design philosophies, and while the outward appearance was satisfying, the backing code left a lot to be desired.

The plan is once again to have the VIP window done “this week”, but I realize I’ve said that before… But so help me if it doesn’t come to pass, because it’s sooo close to a reality that I can taste it. I’m extremely eager to sink my teeth into actual VIP implementation in the emulation core and finally see programs running on their own, and this is the final task between this moment and that one.

Great to hear from you again, Guy!

Yay, an update! Boo, it’s not the VIP window. (-:

After my previous message, wherein I described that the philosophy of “fix it later” is generally fruitless, I considered the other parts of the UI that I wasn’t happy with. Then I donned my canvas gloves, overalls, safety glasses and respirator, then grabbed a hammer and went to town. The implication is essentially rebuilding all the UI stuff, but that’s not so bad because the design is already done and I can copy/paste work from the previous round so I don’t have to actually do it all over.

So here’s what I’ve done so far!

The software now supports localization. Previously, display text such as “An error occurred while reading the file.” was hard-coded into the source and only supported… you know… my localization. Now, all localized strings are loaded from text files bundled with the software. This means the application can now be translated into pretty much any language according to the user’s preferences, and people who want to get involved will be able to provide those translations to the project.

Debugging displays will now only update when the state they’re displaying changes. The old setup I used was just a simple “refresh” command that regenerated output any time anything changed in the emulation state. This applied to everything, from the disassembler to the hex editor to each of the individual VIP tabs. In the grand scheme of things this doesn’t have a huge performance impact, but I never did like how it would draw all those pictures when you used the hex editor to change a value that wasn’t even in video memory…

Global UI settings are now managed centrally. This sounds super-obvious, but at the time I was so bent on getting debugging features implemented that I let “do it correctly” take a back seat… Basically this means any configuration settings (back-end) are now all accessed in the same way from every part of the application. In particular, this applies to text elements. Things that depend on global fonts are now registered with the configuration object, and any time the font(s) change(s), all appropriate controls are updated as well. Additionally, all controls that depend on localized strings will be automatically updated whenever the locale is changed.

Right this minute I’m doing a bit of analysis on the disassembler to see if it should be done differently from what I had before. I’ll probably wind up using the previous code, then move onto the other UI components. Finally I feel good about everything.

Reads promising 🙂

I am so excited about that and hope it will be a success!! This would be my no. 1 reason to buy a 3DS 🙂

Do you guys know if this pjoject is also promoted on social media (facebook, youtube) so that Guy Perfect may get more supporters and of course money for this project via patreon membership?

How is it looking on the VB Emulator front?
I got the feeling everthing has slowed down quite a bit. 🙁

BigDen schrieb:
I am so excited about that and hope it will be a success!! This would be my no. 1 reason to buy a 3DS 🙂

Do you guys know if this pjoject is also promoted on social media (facebook, youtube) so that Guy Perfect may get more supporters and of course money for this project via patreon membership?

Like I said before, the 500USD and more would be already together if the poeple would have something to play with.
That planned debugging features are spot on, no question about that but right now it is just to much theory and has very little use for the usual gamer. But those are who will pay.

We need to be realistic here. The debugger material will be used by maybe 100 people in the next 3 years. It is Virtual Boy afterall.
The Nintendo 3DS is nearing its end of lifespan. People will start to loose interest in that platform at one point. This could render the 3DS VB Emu idea quite useless. Of course there will be a 3DS homebrew scene going on after the 3DS death but the usual gamer has long moved on to try the newest hacks on the switch or the next HyperGameboy.

Also I read your posts here very carefully and what I learned is that you do the usual Coder thing. You code a thing and smash it down again just to code it again in the hopes to make it better.
That is not a bad thing but that can get a bad thing if you repeat that to much. I know very well that coders are never satisfied with their own code. After a week they always find something to trash it again. I have seen it many many times and in the commercial sector somebody will step in at one point and say it is good enough because otherwise you step on the same spot forever and nothing moves on. The project is now like 4 month in and is is still about Debugger Windows.

I really would suggest to alter the roadmap a bit and focus first on things which brings you the needed support and cash.