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 is a work post.
I am having a blast. At first, the plan was to take the existing Java code and move it over into a new project, passing it through a mental filter to make sure everything is looking good. But then I started optimizing and refactoring and improving and… Well, the scope grew a bit larger than what I intended for the week.
Instead, I’m gonna add one more week for the same basic goals from last week. This isn’t the same as a missed deadline: what I’m doing is absolutely productive and under control. It’s just more in-depth than I originally thought I was going to do. But it’s all for the better.
As for what I’ve been up to…
• New Java base – I started a brand-new Java project from scratch, with the intention of reviewing the old files as I moved them over. I ended up doing it all again from the ground up. Once the improvements started becoming apparent, it suddenly became a lot of fun and I kept going with it. The new code is as good as it’s ever been.
• Emulation core – The Java application communicates with an emulation core context that this time is implemented as an interface rather than an abstract class. There’s a static factory method that will produce a valid emulation state for the application to work with. For now, it’s only backed by the generic Java implementation of the emulation core, but the final product will also have native modules on supported systems.
• Bus and CPU access – The emulation context interface supplies methods for accessing data from the simulated Virtual Boy state. You can read and write CPU registers as well as memory from the bus in any applicable format. Internal memory buffers and component functionality are automatically routed trough a simple mapping routine that ties the whole thing together.
• Debug accesses – The application is allowed to do things that the emulated program is not, and these are handled through special debug accesses. Any reads or writes that would have no effect on the hardware can have an effect when used in a debugging context. For example: storing new values in ECR, writing to ROM, and reading from the VSU are all possible as debug accesses.
• New disassembly – While implementing a new instruction decoder, I took a minimalist approach and used a simple, generic field for instruction operands. This necessitated gutting and rebuilding the disassembler class, which also saw the benefits of knowing what-all needed to get done. The implementations of both classes are far leaner and more concise than ever before, and I’m very pleased with it.
Going forward, I’m going to start up a new GUI project to get the Debugger and Memory windows up and running again. From the user’s perspective, it should look more or less like it did before, but the improvements on the back-end will make it so much more convenient and efficient as additional features are implemented.
Attachments:
This is a work post.
Down to the wire! And that’s just how I like it. Normally I try to have my weekly duties done by end of day on Friday, but obviously this is end of day on Sunday, which is not Friday. When I got the GUI stuff caught back up to the point where I had it in the old project, I went on an improvement spree and made everything about a… a jillion times better than it was. I’m happy to report that everything I wasn’t completely happy with in the old code is no longer a problem in the new code.
Attached to this post is the .jar file of the current build (with the source code inside it). As expected, it looks about the same as the original build, but I can assure you that behind the scenes it’s vastly different and vastly superior.
There is also an image attached to this post. I will be referring to it henceforth…
File Menu
When you start the program, you’ll just get a big gray box and a menu bar. There are two options under File: Load ROM and Exit, and they do about what you’d expect. You can select any Virtual Boy ROM file, and it will attempt to detect incorrect files.
Once a ROM is loaded, the meat and potatoes of the user interface are displayed. There are four main panels, described below.
Disassembler – Upper left
The disassembler pane displays the game program from the perspective of the CPU, where each line is one instruction. A translation module in the project converts the machine code to human-readable assembly for your human viewing pleasure. There are literally dozens of configuration options in this module (debugger/Disassembler.java), but for the moment none of them can be configured with the front-end. The settings provided will display instructions using standard V810 conventions.
The hilighted line is the current value of the CPU’s program counter, which represents the instruction that will be executed next.
The Up and Down arrow keys will scroll the contents of the display one line at a time, and Page Up and Page Down will do so one “screen” at a time (the number of fully-visible lines). Additionally, the mouse scroll wheel can be used to navigate in this manner.
In contrast to most debuggers, there is no scroll bar in the disassembler. A scroll bar that covers an entire 32-bit memory range really isn’t usable, since even small movements can skip hundreds of megabytes at a time. I decided to leave it out, since I can’t find a good reason to put one in there.
In order to seek to a particular address, Ctrl+G will bring up a Goto prompt. By typing an address into this box and clicking Ok, the output of the disassembler will be repositioned to include the address you entered.
You can seek to the value of the program counter with Ctrl+P.
The second column of output is the binary data that contains the instructions’ bits, and for most purposes isn’t all that useful. You can toggle whether this bytes column is shown with Ctrl+H.
The F11 key is Single Step, which executes the instruction at PC, the hilighted line. Most CPU instructions are implemented and fully-functional, with the exception of floating-point and bit string instructions, as they require additional research before being implemented.
The F10 key is Step Over, which attempts to execute until the instruction immediately following the current instruction is reached. This is useful for skipping over function calls as well as breaking out of loops like the one very early on in the crt0 routine. In order to prevent endless loops from hanging the application, a limit of 20 megacycles is placed on this command, which will make it stop automatically after executing one second’s worth of CPU cycles.
Hex Editor – Lower left
The Hex Editor pane displays memory values on the bus as the CPU would see them if it were to perform a read operation. This is useful for examining and editing the memory in use by the simulated Virtual Boy software.
By default, no byte is selected for editing. In this state, the Up and Down arrow keys will scroll the contents of the display one line at a time. Page Up and Page Down will always scroll by one “screen” of lines. The mouse scroll wheel can also be used to navigate.
By clicking any byte value with the mouse, it will be selected for editing. In this state, the arrow keys will move the cursor around as expected. At this point, typing any hex digit will begin composing a new byte value at the selected address. After the first digit is typed, the temporary staged value is only that low digit, but by typing a second digit, a full 8-bit value is written into memory and the cursor is advanced to the next byte. In order to commit an edit after only one digit, press the Enter key.
To de-select the selected byte value and return to the default state, press the Escape key.
Ctrl+G will present a Goto prompt where you can type an exact address to seek to. In addition to navigating to that location, the byte at the specified address will be selected for editing.
Registers – Right-hand side
Both of the right-hand panes are for CPU registers. The top pane contains the special “system regsiters”, while the bottom pane contains the usual “program registers”. Any register with a “+” next to its name can be expanded by clicking on it, revealing additional controls.
The value of each register, shown next to its name, is displayed in a flat text box and can be edited directly with the keyboard by clicking it and typing into it. The new value is stored into the register either when the text box loses focus or the Enter key is pressed. Although any value can be entered, certain bits of certain registers cannot be written and this will be reflected in the value that is immediately displayed after editing.
Certain system registers represent multiple values that are packed into a 32-bit unit. By expanding these registers, the individual fields can be inspected and edited. The I field in PSW, and both fields in ECR, are text boxes that can be typed in. The remaining fields are 1-bit flags that are controlled via text boxes.
Although TKCW has bit fields that are displayed in the expanded controls, the register is in fact read-only and the expansion controls cannot be interacted with.
All program registers have options for representing the value in different presentation formats. The available formats are Hex, Signed decimal, Unsigned decimal and Float. When a particular format is active on a program register, the value displayed is in that format and any values entered with the keyboard will be processed as that format.
Debug Writes
Like I mentioned in last week’s report, I set up the new back-end to support “debug” accesses for read and write operations. This is useful for the person doing the debugging, as it allows for test situations that aren’t technically possible within the simulated software.
The debug accesses in use by the debugger are as follows:
• ECR is read-only to emulated software, but can be changed in the debugger.
• System register 31 provides the absolute value of the most recent value written to it, but the debugger can store any value.
• Editing ROM data in the hex editor will update the backing memory, even though the simulated software cannot write to it.
Known Issues
What appears to be a long-standing bug in Java is creating a layout error intermittently with no known cause. If, after you select a ROM to load, the window goes white or otherwise doesn’t display correctly, you’ll need to close the program and try again. Hopefully I can find out how to work around this issue, or maybe someone else can help track it down. Or maybe my RAM is going bad and that has something to do with it…
Attachments:
Hey, some actual feedback and discussion… I don’t know what to do! (-:
Before anyone gets disappointed on Friday, it’s looking like this week will only have documentation to serve up. Between researching specs across multiple sources, formatting and rewriting a document and producing testing software, it’s taking longer than I would have liked. But it’s gotta be done, and I need to make sure that everything in the Tech Scroll is 100% accurate.
As of the time of this post, I’ve put all my current additions to the Tech Scroll up on the project page. You can review it here:
http://perfectkiosk.net/stsvb1.html
A fair chunk of the VIP stuff is in there now, so if anyone in the know could take a look at it and let me know what you think, that’d be swell.
DaVince wrote:
I’ll try to spread the word around as well. 🙂
Excellent, and thanks! This is gonna be the key to the project’s ongoing success.
Yeti_dude wrote:
How many iterations of the graphics code have you managed in the past? You know it always takes a few whacks at it.
That’d be approximately zero. However, compared to CPU operations, the VIP is soooooo simple. Just configure some structs in memory and draw a picture with them. It’ll take a fair amount of planning to do it right, but I don’t see spending more than maybe a day on that.
Yeti_dude wrote:
As you’re rewriting the VIP portion of the tech scroll, make sure to switch over to KR155E and community’s terminology.
Once again, I really want to stress that this isn’t “the community’s” terminology, but Nintendo’s, and that’s the only reason I’m using it. I don’t like certain things about it (use of the word “world” makes no sense, something named DPSTTS surely isn’t called “Display Control Read Register”, etc.), but it all needs to be as official as possible to be done correctly.
Yeti_dude wrote:
[Regarding the VIP debugger window] Guy, you can do it! This would be a huge boon to VBDE and it’s sprite engine.
Could you elaborate on why you feel this would be so helpful? I’m interested to know the thought processes of other developers. I’ve generally been able to visualize my graphics when doing my own software, but I’m not the best case study.
Yeti_dude wrote:
I know it’s blasphemy, but it wouldn’t even be the end of the world if the column table wasn’t fully emulated. Like, what good is it anyways?
For the sake of accuracy I’d like to implement it eventually, but it’s a rare case a game system being able to modify not just pixel colors, but pixel dimensions as well. I’m not especially worried about it right now, since I don’t know of any software that ever changes the column widths.
Yeti_dude wrote:
Let’s see if you can get graphics emulated within a week AND then a home-brew demo! Next step looks like VSU, and then busses?
The software I’m using to research the VIP is extremely basic and not worthy of release. It’s literally just this:
Enough to get the information I need, but not fancy by any stretch of the imagination. The only reason VSU Workshop and CPU Workshop came into being was because I needed comprehensive control over those subsystems and it made sense to make them presentable. So I’m sorry to say, no VIP Workshop this time. (-:
The memory bus was the first thing I implemented, since the CPU requires it for fetching instructions and loads/stores. The source file vue/JavaVUE.java contains generic implementations for read and write methods, which the CPU module uses during its internal operations. Those methods are responsible for routing accesses to the appropriate hardware components, and adding, for instance, VIP support is a simple matter of just putting a line in there to tell it where to forward the access request.
Next step is probably going to be the game pad. I’d like to see things operating sooner than later. (-:
Yeti_dude wrote:
What if the PC emulator could make copies of raw rom & ram data: graphics, instructions, registers and interrupt routines? Let the user edit the code or graphics and then save out a usable home-brew resource.
I’ve considered a “Save ROM” command since the debugger window will eventually have assembler functionality, but beyond that it’s a tricky matter to automatically re-pack things like graphics data back into a ROM image. But don’t let the dream die here! Keep the ideas coming, because this is a community effort after all!
Attachments:
This is a work post.
Here comes Tenerence Love with an R&D break! Progress on the VIP debugger window is going great, but before I go any further on it, I need to get all my ducks in a row or else face the reality of a bogged-down, ham-fisted kludge of an implementation. And no one wants that.
Progress So Far
The interface for the Characters tab is all done and lookin’ snazzy:
On the right is a list of all 2,048 character patterns currently in CHR RAM. They can be displayed at a configurable scale and palette.
One character is always the focus of attention, which is displayed with jumbo proportions in the top-left corner. It has an index and an address, as well as an address mirror that you can read about here. All three of those controls can be edited by the user in order to select the character they’re most interested in. You can also just click on it in the list on the right if you can find it.
The Scale slider affects the size of the list of characters over on the right-hand side. In the image, they’re being displayed with a scale of 3×.
One of nine palettes can be selected, which is applied to every character in the window. The four BG palettes, four OBJ palettes and a generic palette can be used. The generic palette is a conventional red gradient that is useful for identifying the exact pixel values as well as previewing patterns while the brightness settings are all black (which is the case in Wario Land’s startup screen). The exact colors being displayed for each pixel value are shown as large squares below the palette combo box.
You’ll notice one of the shades of red is selected and that there is a smiley face inside the “O” of “IMPORTANT”. That’s because this interface allows the user to modify the contents of character memory visually at runtime.
Keen observers will note that the black pixels in the output are not fully black: they are a wee bit translucent to let the background window color show through a little bit. This is because black is a valid color for palette entries, so it’s necessary to be able to distinguish between black pixels and empty pixels. I tried drawing no color at all for empty pixels, but red on light gray looks very very bad.
The Hold-Up
So if things are going so swimmingly, what’s the problem? Well, there’s no problem. Yet. And I would like that there never is one, so I need to do some research to determine a satisfactory solution to the upcoming design challenge…
Java has a feature-rich 2D graphics infrastructure that offers hardware acceleration for things such as drawing and filling paths with textures and gradients, or painting image contents, all of which can be transformed and displayed at arbitrary scales and orientations. However, all that fanciness is not well-suited for the type of graphics work being done here, where volatile pixel patterns are used to construct larger images.
Ideally, when drawing images in Java, the contents of the images need to be static so that the JVM can cache them efficiently in order to make the most effective use of the hardware. If the images keeps changing, which is the case for characters in Virtual Boy video memory, that cached data is quickly invalidated and more time winds up getting spent on the caching process than the drawing process by the time it’s all said and done. That’s the problem: the usual Java approach won’t work here.
Granted, the official JVM is also very smart and should be able to optimize image memory performance based on how it’s being used. I don’t know for sure if that’s the case, but even if it is, there are still challenges going forward with regards to composing larger images with character data. Background maps and worlds (namely affine worlds) need to be able to sample from character memory arbitrarily, putting me in a situation where all of the rendering gets done in software in the end regardless. And while that is an option, I’d like to come up with a way to solve both problems with one… stone.
What I would like to do is fairly simple in OpenGL:
• Supply the rendering system with one image containing all character patterns in a 2bpp format
• Sample from any location of any character with or without flipping
• Apply a 4-color palette to the character samples
• Apply transformations to source coordinates in order to sample from normal, H-bias or affine backgrounds
From what I’ve seen so far, this should be doable in Java, although it requires me implementing my own Raster objects among other things. I don’t know how long I’ll spend working on this (shouldn’t be more than a couple days), but I can’t progress with the VIP debugger until I sort it all out.
Stay tuned! This thing keeps on getting better.
