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
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:
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:
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:
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:
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!”
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).
