Planet Virtual Boy

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?