A quick rundown of the project goals (not including potential 3DS goals):

Desktop Application & Emluation Core
The foremost goal is to produce a high-quality Virtual Boy emulator application for use on desktop systems. Most emulators these days target Windows, but if you’re lucky you might find one that runs on other systems. In the interest of making it as accessible as possible, I’ve selected Java as the basis for the front-end because of the features and performance it provides.

A portable C implementation of the emulation core is also a major aspect of the project. The idea is for it to be only the code essential for simulating a virtual Virtual Boy, without any dependence on specific I/O or even the standard C runtime. It will be nothing but pure C code and consequently can be incorporated into nearly any C project with minimal overhead. The core will support function callbacks so the encapsulating project can extend its functionality (add cheats, etc.).

Java supports native code, so if available, the C core on whatever applicable platform can be used by the Java application, producing a happy marriage between the two branches of the project. If a native core is not available on the current platform, then a Java implementation will be used instead.

Good Debugger
A pet peeve of mine is the lackluster quality of debuggers in emulators. Most have RAM viewer, some have a disassembler with a few basic functions, and even fewer support meaningful breakpoints. As a game hacker and modder, I find myself wanting more than having, so being able to build a debugger of my own will enable me to get all of the functionality I need to reverse engineer games.

In particular–and I find this very confusing–emulators seem to lack memory access breakpoints: read and write by address. Supplying break configuration on access along with conditions (break only when reading a certain value, etc.) is probably the #1 most useful tool when reverse engineering, and emulators tend to lack this. Other oddball debugging features include the ability to break when a certain pixel pattern is stored in video memory, and automatically index function addresses at runtime to make a map of a ROM’s programming.

TAS Features
While the features in question have a breadth of applications, perhaps the best-known is the “tool-assisted speedrun”, where controller inputs are managed at a granular level to produce videos of game play featuring things no human could do. This gives the player control over the input state at each point of time (generally one frame) during the execution of a game, able to seek forwards and backwards one moment at a time in order to fine-tune the outcome.

A part of this initiative is an expanded movie format–a file that stores an initial system state and a list of inputs. This is common in emulators, and is the ultimate goal of a TAS. I’m considering the notion of a movie file that keeps track of all branching input paths over the course of a project, perhaps allowing multiple streams to be previewed side-by-side in order to better gauge various input strategies.

Cheats, Multiplayer, VBDB, etc.
Other knickknacks can be incorporated as they become applicable. I’m mainly bringing it up because the scope of the project can grow as the community’s needs change.

The code will be written in C in a way that the emulator can also be compiled for use on other systems. But the main target is the Nintendo 3DS family.

The project in its current state is primarily targeting the desktop, but if funded, 3DS will be given the same priority. I feel that it’s very important to clarify that this is not merely software for 3DS, but a Virtual Boy emulator with multiple targets.

This Virtual Boy emulator will offer the barebones required for simulating a Virtual Boy.

This refers to the C implementation of the emulation core. Applications using the core can become much more than “barebones” in functionality.

Current emulator cores plus Retroarch need much more performance to run the games in a acceptable speed than the 3DS can offer.

I’ve been wondering about this, since I haven’t seen it in action. Just how badly do VB games run on 3DS with current software options?

The development time was estimated with approx 4 month for the emulator core. […] The scope of this project is clear and we can estimate the needed development time quite good.

Regrettably, this isn’t the case, and I don’t know where the four-month figure came from. I have a few general features in mind for the desktop application, but there’s still a lot of research and experimentation that needs to be done before I can make an educated guess at how long it will take to implement.

Additionally, I’m working on a new draft of the “Sacred Tech Scroll” document to hopefully pin down all the specifics of the hardware once and for all. The idea is that since I’ll need to know specifics to make an accurate emulator, I may as well write those specifics down somewhere.

(2P Link Cable support at one point???)

That’s one of the fundamental hardware functions. The hardware emulation will be implemented before any fancy application features. So “at one point” will be “from the outset” (-:
__________

With regards to 3DS software design, I think it’s too early to be finalizing anything. For instance, how will cheat codes be accessed, or network settings for multiplayer? An image or two might be good as a visual aid, but I feel that there’s going to be a lot more going into it than what has been discussed thus far.

The easiest way is to just duplicate the file back-to-back. That is, the data from your 128k file will appear twice in the 256k file.

astro187 wrote:
I’d support this, depending on the duration of the project and the probability of success.

This will easily be the biggest issue, since I can’t demonstrate my capabilities or work ethic without already having results handy. If anything, my previous involvement with my emulator projects–and subsequent abandonment–won’t be filling any investors with confidence.

All anyone has to go on is my word, and in the end it will be a matter of whether or not I’m considered trustworthy. For this reason, I don’t recommend a formal crowdfunding effort.

I’ll still be working on the project as time allows, so its future isn’t dependent on having internet people give me money. I was just putting the idea out there because it’s a genuine possibility. (-:

If there’s interest in crowdfunding me, it’ll be around $500/mo USD. But it’d have to be quick because I don’t want to have to turn down any job offers on the premise of “I think some people will give me money.” (-:

Fire-WSP wrote:
What do you think should we already start with the Frontend thingy?

There’s still a ways to go on the emulator. I don’t know how long the project will take, since I don’t know from day to day how much I’ll be able to work on it. Though seeing how I’m between jobs, there’s always the possibility that STEREO BOY can pay my bills for a couple months and I can genuinely work on the project full-time!

… Actually, that’s a real possibility… How rich is STEREO BOY?

Fire-WSP wrote:
This C code you are doing, will it still be ARM specific or is this also up to the person who is using it?

The notion of CPU-specific C code doesn’t apply, since C was designed for writing programs in an implementation-independent way. In order to run C code on ARM, it simply needs to be compiled for ARM. It can be compiled for other CPUs as well, such as x86-64 and our good friend V810. The C code itself never changes in this case: it is only compiled differently depending on the target CPU.

The C code I’ll prepare for the desktop application will also work without changes on 3DS. I don’t know what kind of performance it would have, but it should be one of the best options since it doesn’t do anything other than the barebones required for simulating a Virtual Boy.

Fire-WSP wrote:
As a coding noob I need to ask, why another debugger?

The short answer is that existing debuggers for… well, most emulators… suck real-life balls, not just virtual ones. I wanted something with features I could use to do reverse engineering, not just the barebones “hey look a debugger” features emulators tend to have (if any at all). I have many things in mind such as automatic function isolation and character dot pattern breakpoints among others.

Fire-WSP wrote:
Is this because it needs to be ARM specific for the 3DS?

Naw, I just needed a way to see what the emulator sees to make sure it’s working correctly.

Fire-WSP wrote:
Also why do you want to mix Java with C?

C is better for low-level things such as a portable emulation core, whereas Java is better for high-level things like cross-platform GUI support, Unicode, SSL and a whole host of other things. Neither is fully sufficient on its own, but I want to leverage the strengths of both in the same project.

Fire-WSP wrote:
For testing will citra do for a while?

For the time being I won’t be doing any 3DS development. However, the C library is entirely C code (doesn’t even use the standard runtime library), so anyone can easily plug it into a 3DS project and hopefully have a little Virtual Boy up and running in no time.

Fire-WSP wrote:
Are you planning to do this project on your own or do you plan to turn it into a open source/community project?

It’ll be open source when it’s released, and if anyone’s interested in development in the mean time we can work something out. In the past, it’s come down to a matter of people wanting to help out but not having the corresponding skill set, so I just started up this new iteration of the project without announcing it.

Fire-WSP wrote:
Sorry lots of qustions

Questions are the bridge to knowledge! Never apologize for seeking more knowledge.

Don’t count me out just yet. A couple weeks ago I finally came up with a satisfactory way of mixing Java with C and started poking around with a new implementation. Over the course of about four or five afternoons I have what I think it is a nice debugger interface, and the CPU is fully implemented (save for a few instruction classes that will be mini-projects in and of themselves).

Last week I was preparing for a CompTIA Nework+ certification, which I earned on Thursday, so between spats of looking for a new job this week, I might have some time to poke around some more. Free time isn’t as abundant as it once was. (-:

Attachments:

1. 

   notbad.png
   

Virtual Boy has 64KB of RAM and SNES has 128KB of RAM. Even without the color and sound limitations, that poses a major issue. Stuff would have to be done inside the cartridge.

Made a birthday gift for a friend. I knew for months I wanted it to be music, but just in the last week or so decided it should be a chiptune.

So behold, my second-ever chiptune! It’s attached to this post.

It’s inspired by the old 8-bit Mega Man games, set to a stage that’s up above the clouds illuminated by the moon. I’ve attached an image as well to get you in the mood. (-:

Attachments:

1. 

   maxresdefault-22.jpg
   

1. between-moon-and-sky-bzeep-man-stage.mp3

Don’t underestimate the impact of network latency. Games intended for internet use need to be designed for it.

You’ll find such numbers on many items, such as the bottoms of aluminum beverage cans. I’d be willing to bet that the stamped numbers on Nintendo game cartridges indicate the production line on which the cartridge was manufactured.

Flash Boy is responsible for the ROM padding business: its internal 2 MiB flash memory necessitates having ROM data written in such a way that it won’t malfunction when running on the hardware. Having said that, it isn’t strictly necessary, but the flashing software requires it last I checked.

HorvatM’s post is accurate with regards to CPU to cartridge address translations. What you need to know is this:

• Virtual Boy has a 27-bit bus. The upper 5 bits are discarded for all memory accesses. The initial state of the CPU on reset places its program counter at 0xFFFFFFF0, which gets masked off to produce the effective bus address of 0x07FFFFF0.
• Addresses in the 0x07—— range are mapped to cartridge ROM. This gives 24 bits of addresses for program data. Similarly to the system bus, any cartridge with less than 16 MiB of ROM typically reduces size by eliminating upper bits, hence the power-of-two convention.
• Flash Boy and Flash Boy Plus have 2 MiB of flash memory, which is 21 bits. Therefore, from the CPU’s perspective, everything in the cartridge ROM memory range produces mirrors of 0x07000000 through 0x071FFFFF.

Padding of ROMs comes into play only when flashing ROMs that are less than 2 MiB in size to a Flash Boy. The end of the flash memory is required to contain the ROM header, which contains the code to execute on reset. However, most new software gets compiled in such a way that the program’s origin is at the beginning of the cartridge ROM space. Since you can’t write a ROM to both the beginning and the end of the FlashBoy memory chip, the ROM is padded to produce a new ROM with all the data aligned.

… or that’s the idea. Thing is, you can write it to both the beginning and the end: you just need to write multiple copies. Masking of higher bits for smaller ROMs can be simulated by repeating the ROM until all 2 MiB are filled. While the memory being accessed isn’t literally the same inside the cartridge, the bytes being returned certainly are, so it’s as though the ROM chip has only the number of bits required by the ROM data.

The oven trick makes no changes to the structure or adhesive of the connection in question. If it worked for you, then I’d put all my eggs in the “it’s only a matter of time” basket.

Besides, if it did work consistently, people would be doing that instead of finding people to solder the displays for them. An isolated incident of it apparently working isn’t a strong enough data point for me to retract my warning.

ROM validation would be done via MD5 as usual, but would also cross-check the other information such as internal title, developer ID and file size. On that note, do we have solid data on the size of the memory chips used in games with save data?

No bites on the box art? I could have sworn someone on the forums had a project going on that dealt with them, but I can’t remember what it was…

Never bake your Virtual Boy displays, as it will not correct the problem. It’s one of those urban legends like bats having poor eyesight or Albert Einstein saying something about trying the same thing over and over.

The means by which the ribbon was originally attached to the display boards was with a silicone adhesive that was chemically cured. In the unlikely event you could reactivate this chemical process by getting it hot enough, the natural temperature resistance of silicone means you’d have to get it well above the temperature required to melt the plastic enclosure and components on the circuit board.

The oven method will not solve the problem, but can give you a new problem by permanently damaging the display. I need to get in touch with Krisse to get a PSA about this pinned on the forum…

Unless you’re handy with adhesives yourself, your best bet to correct the problem is either going to be to have the ribbon stripped of its protective coating and soldered directly to the display board, or remove the cable entirely and wire the display board directly to the motherboard.

Instructions

Once the CPU is initialized on reset, it can start processing program instructions. If you’ve ever taken a computer science course, you’ll be told that the most general form of CPU operations involves four stages: fetch, decode, execute and store. This general approach is also valid when implementing an emulator.

I don’t have solid data on certain parts of the CPU’s internals, so timing will not be 100% accurate. In particular, specifics of the pipeline, instruction cache, read/write buffers and exact operation of certain instructions aren’t available. All of these things will have to be emulated in a fairly rudimentary way until such a time that more information becomes available.

Some instruction sets can be a real pain to decode, but Virtual Boy’s is fairly simple and consistent. An instruction’s opcode can be determined by reading the first 6 bits, for both 16- and 32-bit instructions. Decoding and executing can subsequently be handled very efficiently by using that opcode as an index into an array of function pointers.

Just prior to executing an instruction is another good place for an application hook. If the decoded instruction is also passed to the application, intelligent handling of runtime situations becomes possible in addition to simple execute breakpoints. One of the things I really want to see is a mechanism that automatically records function addresses every time the emulated program calls a function…

Promises I haven’t technically failed to deliver on:

Emulator
Emulators for video game systems are a dime a dozen, but more often than not have quite limited features when it comes to doing pretty much anything other than playing games. Since I want to completely master Virtual Boy, I decided it was high time to make an emulator the way I like, with all the development and TAS features I could dream up.

The project comes in two pieces: a portable core library and a cross-platform GUI application. The emulation core, to be written in C, will be available for anyone to use in their own projects. It doesn’t make use of any system calls–it’s just pure C code for emulating a Virtual Boy. The GUI application is a graphical program that uses the C core to do the dirty work.

Development Tools
I haven’t seen dasi in like a year and a half, but he did the hard work on getting a new Virtual Boy devkit put together. devkitV810 isn’t publicly released yet, but it’s pretty slick and has good support for things like interrupts. I myself have been working on a Virtual Boy development library for it that exposes all of the system features to C programs.

Audio Library and Music Composer
Since audio is a trickier topic to tackle for developers than graphics or timing, I wanted to give PVB a way to work with it and not have to worry about the nitty-gritties. An extension of that project is a music engine and a composer application to make the music for it.

The Sacred Tech Scroll, Version 1.0
Long ago I published a document detailing the inner workings of the Virtual Boy. It was incomplete and contained many errors. A new draft of the document is in the works that is being revised as research into the hardware progresses. A full release of the document will contain anything learned during emulator development.
__________

Unsurprisingly, all of these projects hinge on the emulator–even the devkit, which can’t be complete until the hardware is fully researched. So, naturally, the emulator is going to be my main priority unless someone needs my help with something.

In a move that surprises absolutely nobody (except maybe that one guy), I decided to gut the program architecture and redo it with a different approach… again. Having said that, I feel like I’ve thoroughly exhausted any feasible consideration and this will be the final rework. Feel free to point me to this post in the future if such a time should come when I redo it again. (-:

We’ve been over the fact that the emulation core must be a self-contained C library. This is one of the project goals and is a concrete requirement. We’ve also been over the fact that Java is about as good as it gets when it comes to cross-platform GUI support, as well as things like networking, compression, etc. The technical challenge that I’ve brushed up against time and time again is that there’s no “perfect” way for the emulation core in C and emulator GUI in Java to interact with each other.

So I did some research…

• I can’t really do the GUI/network/etc. stuff in C because the project needs to be cross-platform. I’d be replicating what Java already does, so why not leave that stuff to the pros?
• I can’t really do the emulation core in Java because it’s an unnecessary workload and there’s no conventional way to test and debug the C version. Perhaps a Java-only project could spin up at some point…
• JNI isn’t designed to be used by rapid, trivial methods like the kind required by the emulator. Using it would introduce so much overhead that performance would be greatly impacted.
• Shared memory may be the most efficient form of IPC, but it relies on system calls and therefore doesn’t solve the problem of C and Java communicating in the first place.

Other than shared memory, inter-process communication is typically done with either sockets or pipes. Both are fully adequate for this purpose, although Sockets are perhaps overkill. Since pipes have built-in synchronization in the form of blocking when no data is available, and since the additional overhead of sockets makes them a bit slower than pipes in practice, pipes is the natural choice.

Anyone with a programming background will be familiar with the “standard input and output streams” used to communicate with the console. These are pipes, and it’s trivially easy for a Java program to launch a native binary and attach to its standard I/O streams. A request-response implementation can be set up where the C program waits for Java to ask for something, and then Java waits for it to finish. This is very nearly like a call to native code from the Java program.

Initial experiments have been extremely promising. An unexpected benefit to using pipes like this is that all components of the application can be made with absolutely no system calls–standard I/O is an intrinsic part of C. At some point we’ll probably want controller support, and then we’ll have to worry about system calls, but in the short term, it’s looking extra beautiful. <3