[Guy Perfect]

You’re not wrong: the UI needs some work. Emulator operations are controlled with keyboard commands:

Emulation Commands
F5 – Run/Pause
F6 – Frame advance
F10 – Step Over
F11 – Step

When running, only the Pause command will be carried out.

Application Commands
Ctrl+3 – Cycles between color modes
Ctrl+B – In disassembler toggles the bytes column
Ctrl+G – In disassembler or hex editor prompts an address
Ctrl+P – In disassembler or hex editor seeks to PC

Controller Input
F – A button
D – B button
S – Start button
A – Select button
E – L button
R – R button
Up Arrow – Left D-pad up
Left Arrow – Left D-pad left
Down Arrow – Left D-pad down
Right Arrow – Left D-pad right
I – Right D-pad up
J – Right D-pad left
K – Right D-pad down
L – Right D-pad right

• This reply was modified 5 years, 2 months ago by Guy Perfect.

Show of hands, who expected another “Workshop” test ROM? Ah good, everyone. Glad to see it.

Attached to this post is Bit String Workshop, useful for testing the bit string instructions in new and unusual ways.

The top section is the user-configurable part. Move the cursor around with the left D-pad and use up and down on the right D-pad to change values. When you press the Start button, the selected instruction with the current register settings and RAM contents will be invoked, displaying the result in the bottom section.

In the big list of bits, the bus address [font=Courier New]05000000[/font] is the location of what is visible on-screen. Each line is 32 bits–one full word–with the least-significant bit on the left.

When the Timer field is set to some non-zero value when Start is pressed, it is used as the counter value on the timer with a 20 µs tick interval. When the timer hits zero, it fires an interrupt that will abort any active bit string instruction, then return early so you can see the state of the registers when the interrupt was raised.

The reason there are six rows of bits for what is ostensibly a fairly simple procedure is because of a tricky buffering behavior the CPU exhibits when processing arithmetic strings. The screenshot shows the output that the hardware gives, and I wasn’t able to find any other emulator that produces the correct result. PVB gets to be the first. (-:

The tech scroll document has been updated accordingly.

Attachments:

1. 

   bitstringworkshop.png
   

1. bitstring_workshop.vb

VmprHntrD wrote:
So I’m seeing the jar file, and I just realized this for windows is Java based right?

.jar is a self-contained Java program, though it doesn’t necessarily need to be used with Windows. Since Java is available for so many operating systems, the idea is that a .jar should be useful just about anywhere.

VmprHntrD wrote:
Historically Java has been a big bullseye for virus makers and other trolls. Has it become more secure to feel safer installing that again to take part in using this program or in the future will it use something other than java?

Any malware will attempt to target as large a user base as possible, so the most popular platforms tend to get targeted. This includes Microsoft Windows, Apple iOS and to an extent Java. However, the vast majority of Java malware has targeted people running Java as a web browser plugin, whereas this emulator project is designed to work as a standalone application.

It’s absolutely possible for a .jar itself to be malicious, so if you’re not comfortable taking that risk, then you shouldn’t. An alternative would be to set up a bare-bones virtual machine running something like Linux where you can load up the Java software in a safe, sandboxed environment.

VmprHntrD wrote:
This looks like a fantastic program, wholly not the pain in the ass mess that is mednafen.

I appreciate the sentiment. (-:

Mednafen does work well enough as an emulator, so I try to refrain from unnecessarily bashing it, but nonetheless it is one of my go-to examples of difficult user interface design. One of my major goals for the PVB emulator was to make sure all of its features were easy to use, even without reading a manual, so it means a lot that you took notice of that.

Go for it. Don’t worry about extra work, I do that to myself all the time. (-:

I posted a padded ROM in the release thread: link to post

Attached is the ROM padded to 2MiB for those having difficulty getting it padded.

Attachments:

1. innsmouth.mansion.english.2mib.zip

No amazing, ground-breaking new developments this time, just a round of fun and profit.

New features:
• The game pad is now properly implemented and the tech scroll updated accordingly
• Added support for .isx debugger ROMs
• Added [font=Courier New]value[/font] breakpoint condition symbol for the actual value being read/written
• Added disassembler comment for when an exception/interrupt is raised
• Added disassembler comment for [font=Courier New]JMP [lp][/font] instructions

Bug fixes:
• Extended duration of [font=Courier New]DPBSY[/font] and [font=Courier New]XPBSY[/font], enabling Mario’s Tennis to function
• Corrected the operation of [font=Courier New]XB[/font], enabling Jack Bros. to function
• The disassembler now displays [font=Courier New]TRAP[/font], [font=Courier New]XB[/font] and [font=Courier New]XH[/font] incorrectly
• Step will now enter an exception handler without also executing its first instruction
• Step Over was previously broken, and was reworked to use a breakpoint
• Read and Write breakpoints now detect if any of the bytes being accessed are in the given ranges, not just the exact byte specified
• The Breakpoints window will no longer erroneously show a star next to Read, Write or Exception breakpoints that don’t match the current emulation state

Attachments:

1. 

   nowwithisx.png
   

1. pvbemu_20190227.jar

Got a new update attached to this post. It includes a few fixes to floating-point operations and VIP behavior that fix a few games like Bound High!, Galactic Pinball and Vertical Force.

The application was reorganized a bit. The Console window still pops up when you load a ROM, but the other windows are now accessed through a new Windows menu.

When you run the emulation, focus is now correctly given to the Console window, so you no longer have to click on it. A third anaglyph color mode has been added with full intensity red/blue like conventional VB emulators.

Breakpoints

Did you think the timer was kinda small for the last two weeks’ worth of work? It was! Truth to tell, I only did the timer when I did because it was small and I spent the last two weeks working on breakpoints.

It might not look like much, but the new Breakpoints window is one of the most significant features of the entire application. This tool allows you to stop emulation whenever something you’re interested in happens. This is big news for reverse engineering and debugging efforts.

The flexibility of this emulator’s breakpoint system is far and away above anything else I’ve seen (except for MHS). Let’s take a look!

Breakpoints can be configured to trigger on one or more of the following conditions:

• Read – An instruction attempts to read from the bus
• Write – An instruction attempts to write to the bus
• Execute – An instruction is about to execute
• Exception – An exception was raised

Crucially, all breakpoints are captured before their respective events are processed. For example, a write breakpoint will stop the program before the value gets written, letting you see what value is being replaced.

Exceptions include operations errors as well as all interrupts. For the most part, interrupts should be trapped with execute breakpoints on their handler addresses.

Addresses

The address field allows you to specify an arbitrary list of individual addresses and address ranges. All figures are expressed in hexadecimal as follows:

• A value by itself is an individual address.
• Two values separated by a hyphen is a range of addresses, with the start on the left and the end on the right.
• Multiple addresses/ranges can be provided simultaneously by separating them with commas.

For read and write breakpoints, the address specifies the bus address being accessed. For execute and exception breakpoints, the address specifies the address of the instruction to be executed or that raises the exception.

It’s totally valid to mix-and-match addresses and breakpoint types.

Conditions

The condition field is the big kahuna that sets this emulator apart from the rest. It’s a fully-featured expression evaluator that accepts a set of C-like operators in order to determine dynamically when a breakpoint should trigger. This gives breakpoints access to CPU registers, the contents of system memory and operands for the current instruction.

Earlier today, I was helping someone track down Wario’s animation data in Wario Land. We started by looking at object 2 (Wario’s eye), which has an address of [font=Courier New]0003E010[/font]. A write breakpoint on that address stopped the program in the function at [font=Courier New]FFFC1D0C[/font], which is a small function that copies data from a global variable into OAM. Armed with that knowledge, we figured out where object 2 came from by inspecting the CPU state, which allowed the guy to find the data he was looking for.

In the above screenshot, you see a sample breakpoint that stops on all function calls in Wario Land’s crt0. The condition expression is “[font=Courier New]inst == jal || inst == jmp && reg1 != 31[/font]”, which you can see is accessing instruction operands in order to stop on only specific instructions. It also supplies an address range.

The supported features in the condition are so expansive, in fact, that I can’t go over it all here in this forum post. So instead, an HTML file is attached to this post (and included in the .jar) that covers all the specs. I promise it won’t disappoint.

The expression evaluator was also exposed to the Goto prompt in the CPU window (Ctrl+G in the disassembler or hex editor).

Attachments:

1. 

   breakpoints.png
   

1. pvbemu_20190220.jar
2. expressions.html

Attached to this post is another classic feature-testing program called Timer Workshop:

The left D-pad moves the cursor around, the right D-pad’s up and down changes the current selection, and pressing A when “Write” is selected will write a value to TCR using the current Clock, Interrupt, Zero Clear and Enable settings. Changing the digits of Reload will immediately write to THR or TLR as appropriate.

As far as I can tell, I’ve worked out all of the errors in the previous implementation and the emulator now correctly simulates the timer. However, none of the broken games have magically fixed, so I won’t put out an update just for this small change.

If you want a quick laugh, go ahead and load Timer Workshop into the current build and watch it break. The moral of the story is that I need to make these “Workshop” programs before I declare something implemented. (-:

The Sacred Tech Scroll has been updated accordingly.

Attachments:

1. 

   timerworkshop.png
   

1. timer_workshop.vb

SpectreVR wrote:
I wish to “Learn to code”.

Well, that’ll be the first challenge, because you’ll need to understand programming concepts before digging into someone else’s compiled software. Do you have any programming experience, or will this be your first exposure to it?

SpectreVR wrote:
I’m interested in the Mac version specifically because it appears to have superior sound and graphics. Even if the virtual boy is incapable of doing all of it, I’d rather use the best version as my reference.

If it were up to me, I’d take a look at all three of the classic Macintosh games and see what comes out. There was also a short-lived iOS version called Spectre 3D, but it’s not on the App Store anymore and it won’t even let me install it on my phone from my purchase history…

Once upon a time I had the games up and running in a Mac emulator called Basilisk II with System 7.5.1 on it that I’m pretty sure I just downloaded from the Apple website. Can’t remember where I found the games themselves, but I still have them in my archives if I need to dig them out.

The SNES version is sort of a dumbed-down implementation of the game and I don’t think it’s all that interesting. However, it does have various new sorts of obstacles and stage features that would be worth incorporating into a port of the Mac-style games.

Both Battlezone and Spectre–the actual games–could be reverse-engineered and ported to Virtual Boy, but that’s a process that takes a bit of time. I’m actually doing exactly just that very process with Wario Land, so it’s absolutely possible.

I don’t have a vacant project slot to volunteer for this myself, but if anyone is feeling motivated to take it on, I’d be happy to teach them how the process works and hopefully get the ball rolling on it.

Dreammary wrote:
I honestly feel like games shouldn’t have left the cartoon stage, I don’t like playing realistic games.

As the wise Yoda (probably, maybe) once said, “Broaden your horizons you must!”

StinkerB06 wrote:
There’s just one thing missing here in this update: a column table tab.

Any ideas for how that might be visualized?

StinkerB06 wrote:
For instance, the Wario Land game’s intro cutscene actually uses a fade effect on the sides via the column table.

While testing Wario Land in the emulator, the column table didn’t appear to be updated during the intro cutscene, which seems wrong. The result is a very dark cutscene, which makes sense because the brightness is turned down for the column multiplier to take effect, but it never seems to be written.

I may have screwed something up, but it should be a simple matter of store instructions, so I can’t quite pin down what’s (not) going on.

StinkerB06 wrote:
The Sacred Tech Scroll draft just got updated with details of the VB’s hardware timer. http://perfectkiosk.net/stsvb1.html#timer

Jumping the gun a bit are we? Feel free to post the next software update so I can take a break. (-:

The Next Software Update

… is attached to this post. I adjusted the focus when running the emulated program, so the keyboard keys should correctly apply without intervention.

I also implemented the timer into the emulation core… I think. Everything looks like it checks out, and the timer itself is fairly simple, but I haven’t had a chance to fully test it. I was hoping Galactic Pinball would start working magically once it was implemented, but something else is causing that game to hang on the title screen.

If anyone has a simple test ROM handy that just does timer functions, see if it works correctly in this build of the emulator. Otherwise I’ll draft one up for next week to verify that everything is working as intended.

Attachments:

1. pvbemu_20190213.jar

MESHUGGAH wrote:
Is it possible for a game to poll the controller multiple time within a single frame (x02000010, 0x02000014, 0x02000028)?

Yes, the game pad component operates independently from the video component, so input can be processed multiple times per display frame. I don’t know if any commercial games do this, though; honestly haven’t checked. If I had to place a wager, though, I would guess that all commercial games process input once per frame.

MESHUGGAH wrote:
Does it have a “cart lock”, a plastic piece preventing cart swapping while the console is powered on?

There’s nothing preventing the cartridge from being removed while powered on, but I don’t know whether or not the hardware will issue a reset interrupt when inserted. Even if it doesn’t, the open bus behavior (zeroes gives you [font=Monospace]MOV r0, r0[/font], ones gives you [font=Monospace]OUT.W lp, -1[lp][/font]) will send the current program position rocketing out of the solar system, making it impossible to reliably time the insertion correctly.

[Guy Perfect]

Apologies for the delay. Had something happen that amounts to little more than “a long story” at the end of the day, so I won’t go into details. I feel terrible about the long absence, but I feel great about what I have to show you today…

Who wants to play some Virtual Boy games? That’s a thing now!

The current build is attached to this post, compiled for Java 8.

The Overhaul

Since our last episode, the entire user interface has been redone from the ground up–including the CPU and VIP windows. There’s not much to say for the most part, as it looks and feels the way it always did, but under the hood there’s a lot less duplication of code going around, and component layouts in general have been simplified. Performance is up, stress is down.

Also, the hex editor will honor Scroll Lock when you have a byte selected. Just putting that out there.

All English-language text in the UI now comes from a localization text file that can be swapped out for any other set of localized strings when the time comes to translate to other languages, even at run-time–all controls will be updated to the new text when changing localizations. Right now the only one available is the provided US English, but the groundwork has been done whenever more languages are added.

The much-maligned VIP window overhaul was every bit as horrible as I feared it would be. I went through about a dozen different iterations of it until finally settling on the one that I… well, disliked the least. It’s maybe not the most amazing approach possible, but it’s functional–and best of all, it only ever accesses the data it needs right then and there. It won’t decode anything from VIP memory unless it immediately needs it, and this counts for drawing the displays.

While the VIP window is implemented and functional, the backing code is in a bit of a state of limbo between two different implementations. It’s not broken, and is nonetheless clean and organized, but I still wouldn’t say it’s in a “done” state. One of these days, but for now I’m gonna leave it and move on.

VIP

The Registers tab is the ol’ classic “throw everything at the user” style of interface design. Normally I discourage too many controls on a form, but in this specific case, I feel it’s appropriate:

In the emulation context, the VIP is now implemented to the extent I intended to implement it. The code that renders images into the frame buffers is as optimal as I could make it, though it really does showcase the need for a native-backed implementation in the future. Nonetheless, it’s all lean and mean, and runs reasonably smoothly on my sorta-nifty computer.

Console

Hey, this is new! It comes in red/cyan and green/magenta flavors with use of Ctrl+3:

To run the program, press the F5 key. Or F8, or Pause. They all do the same thing. Press it again to pause the program.

Controls are quote-unquote “supported”, and you’ll have to click in the middle of the Console window after the program starts running before they’ll register. The following keys map to controller buttons:

• F = A
• D = B
• S = Start
• A = Select
• Up = Left Up
• Left = Left Left
• Right = Left Right
• Down = Left Down
• I = Right Up
• J = Right Left
• K = Right Right
• L = Right Down

While running, the debugger interfaces will not be updated. Once the program is paused, the debugger will reflect the new state. At the moment, debugger controls remain active even during active emulation, so you probably shouldn’t go changing settings in there manually. I mean, you could do it, but I can’t promise nothing ugly will happen.

Granted, the thing runs a bit slowly in the Java implementation, but the important part is that it works. At long last, it plays games!

Unimplemented Things

The following system features remain unimplemented and may cause issues when attempting to run Virtual Boy software in the emulator:

• Audio
• Game Pad (the current controls support is a dirty hack)
• Timer
• Wait Controller
• Link port
• Bit string CPU instructions
• Floating-point CPU instructions

On the other hand, interrupts and exceptions are implemented, and the VIP module takes full advantage of that. Homebrew games that use VIP interrupts ought to work just fine (provided they don’t use any other interrupts).

• This reply was modified 5 years, 3 months ago by Guy Perfect.

Attachments:

1. 

   allinone.png
   

2. 

   vipregisters.png
   

3. 

   greenmagenta-1.png
   

1. pvbemu_20190206.jar

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

It fortunately hasn’t slowed a great deal, but the things I’ve been working on over the past six weeks or so don’t “look” like anything on the front-end, and presenting it here wouldn’t look like a step forward. Every post would be “it looks exactly the same, but it’s better, I promise.”
I’ve incorporated several features that were originally slated for “eventually”, but as the UI was being pieced together, it became quite clear that “eventually” needs to become “ahead of time”, so a lot of planning and preemptive implementation has taken place to ensure the rest of the pieces have a place to fall.

Fire-WSP wrote:
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.

On the contrary, I’m generally pleased with the code I produce, taking the time to simplify the algorithms and carefully document the source. The work I’ve already presented demonstrates that. Over the course of a project like this, certain requirements present themselves after implementation has already begun, necessitating revisions or else those requirements will have to be omitted.

I will say that I made an error by misjudging the task of constructing the UI I envisioned in my head, especially considering the unexpected limitations Java has imposed. I was strongly confident with my designs for the emulation core–code that has remained brilliant since I started work on it–and basically assumed the UI would follow suit. Although I do have the UI under control, it has certainly taken longer than I would have liked and I want to extend my gratitude for everyone being patient while I work with it.

Ernest Hemingway is said to have put it best: “The first draft of anything is shit.” No one wants to read the first draft of a book, or the first rehearsal take of a song, or the first storyboard of a film. Revisions are a regular part of the creative process, so it should come as no surprise that they’re happening with this project as well.

Fire-WSP wrote:
The project is now like 4 month in and is is still about Debugger Windows.

A common misconception regarding software development is that if it looks done it is done, and conversely if it doesn’t look done it isn’t done. I ask that you refrain from making that assumption here. The debugger windows are critically important, not just for the development and reverse engineering side of things, but also because they greatly aid in testing and debugging the emulation core.

One of my earliest attempts at emulation years ago had CPU instructions all neatly implemented, but when it came time to test it and make sure everything was working correctly, I couldn’t. There was no debugging output, so I was somewhat powerless to verify whether my code was as correct as I thought it was. With this project, I can see what the CPU sees: I know what instruction comes next, I know what’s in each register and I know the contents of RAM. The same goes for the VIP and ultimately the other hardware components as well.

Without some sort of debugging interface, the emulator itself couldn’t be debugged. Since the project calls for a debugging interface as it is, it makes sense to focus on that concurrently with development of the emulation core. Every piece of the machine is connected, and each piece supports the others.

STEREO BOY wrote:
Do you think, you could set limits to your heart bleed for this project to push it further?

I don’t know that I’d call it perfectionism. Certain things are, such as retooling something to eliminate senseless duplication, but other things aren’t. Consider the following features:

• Supports multiple languages
• Performant and responsive
• Accessible
• Consistent with system/user settings
• Minimal duplication (-:

These are all somewhat abstract things, except maybe the language one which is easy to visualize. They’re all requirements for the application, but when I started, they were all in that “eventually” category. For example, every time I hard-coded some English-language message, I thought to myself “I really shouldn’t be doing it this way”, and I knew that each one I did would make more work for myself down the road.

I wanted to focus on “results”, and kept letting these things slip by. They ultimately caught up with me, and the excessive duplication of the VIP window was what sent me over the edge. If this was ever going to be anything more than a big steaming pile of first draft, something needed to be done. At first, that was going to be tidying up the VIP window. Then it became the other things.

All of that restructuring is done now. I’m putting the UI back together now, setting it up so the user experience is more or less the way it was before. It looks exactly the same, but it’s better, I promise.

And hey, if you need some hype, I’m proud to announce that the hex editor now honors Scroll Lock! Yeah, if that doesn’t get you fired up, nothing will.

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.

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.

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

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. (-:

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.