See Code Run. Run, Code, Run.
The first two modules of this project are going to be the memory controller and the instruction implementation. That is, the bus emulator and the CPU emulator. Both of those things consist primarily of logic and data, and not so much in the things-you-can-see category. So how do we even know that we did it right? Well, you’re gonna need some kind of output for debugging your own programs. Some may call this a test program, but I’m partial to referring to it as the driver (not to be confused with a device driver). We need a program to drive the code we write so we can make sure we did it right.
As corrections often need to be made, you could say that after you write code, you have to right code… And that process is called debugging. Not to toot my own horn, but I rarely make logic or implementation errors: most of my problems are either spelling things wrong, making syntax errors or using the wrong variable names (especially after renaming a variable). Still, that’s something that will be caught during debugging, even if the code happens to run without crashing.
This particular project presents a somewhat more challenging environment than a typical closed-shop development run. Where in a production environment you can hack together the sloppiest, ugliest, most unholy assortment of lines of code imaginable in order to verify your code is working, that really won’t fly here where we’re putting the project up on a pedestal for presentation to the general public. We’re going to have to debug in style.
So the way I see it, if we’re going through the effort to make our driver program for debugging fancy, why not actually make the debugger that will be in use by the finished product? You know, that disassembler and hex editor and video memory viewer and stuff. Those can be what we make to verify that our emulator is working correctly!
Again, the first two modules of this project are going to be the memory controller and the CPU. The memory controller is simple enough that it can be verified algorithmically: a few simple test cases of reads and writes is all it will take to ensure it’s working correctly, and no human actually has to inspect it for that to happen. I’m comfortable testing the memory controller with a few lines of code. The CPU, on the other hand, has a lot going on. It has a bunch of state information, and the program that it’s running needs to be seen to make sure execution is flowing properly. This looks like a job for *da dada DAAAAAAH!* the disassembler!
The disassembler is a GUI component, meaning before we can begin this I’m going to have to do some research on SDL. |-: Gimme a couple of days to look into it, I promise it’ll be worth it.
Following is an image mockup I made a couple years ago when I first got into Virtual Boy. Like, when I first got into Virtual Boy. What started out as a feasibility case study for porting Mega Man 9 to NES evolved into a actual consideration for Virtual Boy emulation. This was before I joined Planet Virtual Boy, and in fact was long enough ago that Photobucket hadn’t started putting unique suffixes on filenames:
Forgive the red and black. That was totally tongue-in-cheek. Still, the general layout I have in mind is… well, pretty self-explanatory. That’s what I’d like to see in the disassembler, give or take a few things.
When the memory controller loads the ROM file, and the CPU begins doing its thing, the disassembler will display the machine instructions, the CPU monitor will show the status flags, and the controls will allow one instruction to be executed at a time, verifying whether things work properly. And that, I think, would make for a very handsome first step towards a full-fledged emulator.
This is a first draft. Please feel free to pitch in any ideas or suggestions you may have.
Attachments:
Okie dokie, I think we’re about ready to get this thing started now. I’ve got my serpentine Pokémon team trained up (you’re invited to participate), Drake Von Vladstone was pogo’d back to the grave, and the Snowmads have been forced to retreat. Once the crispy snacks arrive in the mail, I’ll be able to save Eagleland from a villain attacking from the future.
Yes, I do have a 3DS and a Wii U. What gave it away?
The Source of This Madness
I’ve set up a Dropbox folder for the project right now. If we can get something better set up at some point, that would be swell, but for now this does the job. I’m calling it “pvbe”, short for “Planet Virtual Boy Emulator”, and in the future we can come up with a catchy product name. (-:
Within there are two child folders: “repository” and “archives”. The repository folder contains all of the code, assets and tools used in the project. For now, it’s just a .c file and a couple of compile scripts.
The archives folder contains only .zip files named chronologically. They’re all-in-one copies of the entire repository folder. That’s just for the sake of backup in case something goes horribly wrong and we can roll it back. Rudimentary version control.
The program itself does this:
Just a spinning box, and it’s not even red-on-black! But it is a cross-platform OpenGL window, which is the key point of interest. With this, we can get started on the emulator proper.
Regarding SDL
I’m trying to get in touch with the SDL guys to see what their intentions were with regards to distributing SDL with software. The way it looks right now is that SDL itself needs to be installed as a runtime requirement, then software that uses it… uses it. I was never one too fond of third-party distributables just for running simple programs, but I trust these guys, it’s not a huge installation, and it’s not .NET or Java. All-in-all, I’d be okay requiring the user to install SDL before running the emulator.
SDL was designed in such a way that new features can be introduced without breaking compatibility with older software. Combine this with its, like, 4MB of runtime binaries and it really doesn’t sound too bad to me.
Now let’s get this show on the road!
Attachments:
[size=16px]Do Over #1!
Told ya the first draft wasn’t worth beans. (-: Let’s try this again, with pictures. I’m going to reiterate what I already said, but it should be better this time.
Also, I’ll be rewriting the code I wrote accordingly.
*Ahem*
The Memory Controller
Real Virtual Boy units have a memory bus with 32-bits of accessible memory addresses. The bus is split into 8 sections, each of which represents a different hardware component. Addresses are actually 27 bits wide, and anything from bits 27 to 31 are simply masked off and produce mirrors of the 27-bit memory range. The uppermost three bits, bits 24, 25 and 26, represent which of the 8 bus sections that the address belongs to:
0 = VIP (video)
1 = VSU (audio)
2 = Hardware Control
3 = (Not used)
4 = Cartridge Expansion (currently not used)
5 = System RAM
6 = Cartridge RAM
7 = Cartridge ROM
In the emulator project, the job of the memory controller module is to mimic the behavior of the memory bus. Any time something needs to access system memory or components from the CPU’s perspective, it needs to go through the memory controller. Since the CPU isn’t the only thing that might need to do this–debuggers and cheat engines need it as well–a common library-level API should be set up to handle routing of access requests.
Unlike last time, let’s try a diagram to demonstrate what’s going on!
Wow, that was way easier than last time!
Access Types
Virtual Boy effectively has 8 different ways to access memory:
* 8-bit signed read
* 8-bit unsigned read
* 16-bit signed read
* 16-bit unsigned read
* 32-bit read
* 8-bit write
* 16-bit write
* 32-bit write
The reason for signed and unsigned reads should be self-explanatory: since the CPU registers are 32 bits, smaller data types need to be made big enough to fit. An unsigned read fills in the extra bits with zeroes, whereas a signed read makes a copy of the highest bit and propagates it all the way to the left.
For the sake of simplicity, let’s pretend we’re reading an 8-bit value into a 16-bit register.
Bit pattern: 11010010
I trust you know how binary works. Thus, you should see how this bit pattern can represent the decimal number 210. Extending with zeroes to form 16 bits gives us 0000000011010010 = 210.
Signed, on the other hand, works on a principle called two’s complemet. If you have bits 11111111 and try to add 1, you get 00000000 because the value is only 8 bits, right? Well, in the same way, 00000000 minus 1 is 11111111. As it turns out, using two’s complement in this way means that both signed and unsigned operations are identical from the CPU’s perspective.
The leftmost bit, though, the 2^7 digit… Since that’s a 1 in this example, if we propagate that to the left when extending to 16 bits, we get 1111111111010010 = -46.
Since 32-bit reads don’t need extension, there is no differentiation between signed and unsigned.
Since writing values may reduce the number of bits, there’s no need to distinguish between signed and unsigned there either.
The Doing Over
In the previous draft, I said that debug-reads weren’t necessary because the only place that would matter is the waveform memory, which could have *urk* hard-coded handling in the hex editor. Well, I forgot about something: CPU cycle counts. The V810 bus takes a different number of cycles for load/store operations depending on how many of the same operation happened consecutively in previous instructions. Not to mention the fact that different hardware components operate at different speeds (VIP memory is slower than cartridge RAM). So not only am I going back on what I said about debug-reads, but we’ll also need debug-writes so debugger features don’t screw up the cycle counts of the emulated CPU.
Additionally, I went over all that to-do regarding making the memory controller hijackable. Well, I’m going back on that as well! The reason this time is because it’s totally redundant. If you want to intercept, say, an unsigned 8-bit read, then just hijack the IN.B instruction in the CPU module. That’s the only instruction capable of performing that kind of read, and hijacking that won’t cause debuggers to hijack themselves when they use the library-level memory API.
To accommodate CPU cycles, all memory controller read/write functions will return an integer representing the number of cycles taken. Read functions will now have an additional parameter for passing a reference to the variable where the loaded data should be put. So without any further ado, let’s talk about that!
Building a Bridge
When the CPU or debugger or whatever calls a library-level API function to access memory, the memory controller needs to route the request depending on the address to the appropriate emulation core module according to the corresponding bus section (numbered 0 through 7 from earlier). Further, since we don’t want to preclude any expansions to the emulation core later on (such as if we implement something for the cartridge expansion area), we’ll want the exact bus section handlers to be dynamic.
This can be accomplished with function pointers. Function pointers are variables that represent functions by way of storing the addresses in memory where those functions are located. A function can be called indirectly by using a pointer to it in the same way it can be called directly by name.
The memory controller needs to have 8 groups of 8 handlers: one for each bus section, and one for each access type. Initially, the handlers will point to dummy functions that don’t do anything. As emulation core modules come along, they can register themselves with the memory controller to support additional bus sections.
The Code
Once again, the code is located here:
https://www.dropbox.com/sh/3w3ql9ybasien76/AADcp_lpfgKOmoliAsnJYV09a
I’ve modified a few things from last time:
* Files were reorganized again. Now, all the emulation core code is in a libvue subdirectory, which contains src and include.
* The memory controller hijacking feature was removed.
* All memory accesses now return int: the number of cycles taken.
* Read functions now pass a variable by reference to store the loaded value.
* All memory access functions now have a “debug” parameter that signals a debug access.
* The memory controller function pointer table’s subscripts were reversed. They are now [access][bus], as that results in faster code once compiled (details are available on request).
* Memory access functions were renamed as “vueMemRead*” and “vueMemWrite*” to enforce a consistent naming convention across the API.
* The code was updated and compiles correctly.
