R3Ddragon 3DS

r3Ddragon

A WIP Virtual Boy emulator for the 3DS based on Reality Boy / Red Dragon. You can see the current progress [here](https://github.com/mrdanielps/r3Ddragon/wiki/Current-progress) and a video of it working

There's an experimental dynarec implemented but it still needs optimizing.

Usage

You can place place ROMs in /vb/.

If it doesn't exist, `rd_config.ini` will be created. Some relevant options you can change are:

_maxcycles_: A lower value will improve compatibility, but it will run slower.
_frmskip_: Number of frames to skip before drawing.
_debug_: If set to 1, prints debug info.
_sound_: Enables sound.
_dynarec_: If set to 0, tries to load the dynarec cache from a file instead of recompiling.

The 3dsx will only work on exploitable system versions (<=11.2) after running [fasthax](https://github.com/nedwill/fasthax/releases).

FAQs

Why would you make a Virtual Boy emulator? Nobody asked for it.

The 3DS is the perfect system to faithfully emulate the Virtual Boy. They have similar screen resolutions, the

3D effect is better and it's actually portable.

OK, but wasn't the Virtual Boy, like, the worst console ever?

There were many reasons why it was commercial failure. That doesn't mean the console is bad, or the games aren't worth playing. It's definitely received way more hate than it deserved.

Plus, it has a nice homebrew scene with gems such as Hyper Fighting, Snatcher and many more.

Do I need a new 3DS to run this?

Unfortunately, yes. The old 3DS is too slow to run it at a playable speed. That might change in the future, but it's unlikely.

Where can I download it?

You can find the latest release [here](https://github.com/mrdanielps/r3Ddragon/releases).

Current Progress

Update 9/9/2015: I have some good news for 9.3+ N3DS users. I've been working on making the dynarec generated code relocatable. Without going into details, this means that you can generate it once, bundle it with the executable and run it on newer systems (where we can't set executable memory on the fly) in a similar fashion to a static recompiler. It's much less convenient than the normal dynarec, but it makes it possible for ninjhax2/ironhax/tubehax users to play VirtualBoy games at a decent framerate.

Update 18/7/2015: Since the last update I optimized it a bunch and now it runs at 15-50 fps, depending on the complexity of the ROM and the amount of frameskip. I also got Mario's Tennis booting up, but it's not showing any graphics in-game.

On another note, I was looking forward to Ninjhax 2.0 to make it playable on N3DS, but HB_ReprotectMemory isn't available. It's a bummer because Mednafen VB got a 3X speed boost (from 8 to 25 fps) and the dynarec could benefit a lot from it.

Update 25/3/2015: I decided to look at how other emulators implemented their recompilers and got some ideas on what I should do next. I've been experimenting with some of the stuff and I feel like I'm going to have to make some big changes to the dynarec before anything else. The thing is, that will break everything and bring new issues that will have to be fixed, and that sounds boring. Like, super boring. I was going to be busy for the next few weeks anyway with exams and a project, so I guess I'll be more motivated when I come back.

Update 1/2/2015: I've pushed my changes to the dynarec branch. Don't expect anything too efficient for now, but it seems about twice as fast as the interpreter in the Reality Boy Demo (which is the only working ROM at the moment).

Update 29/1/2015: I've been working on the dynamic recompiler and after a lot of painful debugging it managed to run a homebrew demo. Nothing else works, mainly because almost half of the instructions aren't implemented. It only works on 3dmoo at the moment and it might need some changes before it runs on a real 3DS, but it's a good start. With CPU emulation not being that big of a bottleneck, the next step would be to rewrite the display functions to use hardware rendering, but that probably won't be happening until the dynarec works well enough.

Update 10/1/2015: I continued working on the assembly interpreter up to the point where it follows the same path as the old core (but it doesn't output any graphics) and the speed increase is minimal (about 3 fps from what I've tested), although it could still be optimized a little bit more. I don't think it's worth it to continue at this point, so I should start thinking on that dynarec...

Update 27/12/2014: After spending several days rewriting most of the interpreter core in assembly I noticed it wasn't giving that much of a speed boost (although I'm not sure yet because it's not working properly), so I wondered if it was worth it to continue with it or whether I should start thinking of writing a dynamic recompiler. If I do, that will probably take a lot of time (and I'm going to be busy these days). Besides, my 3DS just broke and if I take it to repair I won't be getting it back until at least mid-January.

Original text:

Thanks to some awesome people at GBAtemp, r3Ddragon has been tested on real 3DSs and it managed to run some homebrew, although there are some issues that need to be fixed.

Commercial roms seem to work. Teleroboxer loads the menu but crashes when starting a game (there's a memory read/write error that shouldn't be too hard to debug once I actually get some free time...)

The framerate is too low to be playable and it still needs to be optimized a lot.

Now works on Ninjhax.

If you want to try it out, you might want to change some configuration options in vb_set.c:

Changing DSPMODE to DM_3D (or adjusting the slider in the menu) enables 3D (but runs slower).
Changing FRMSKIP enables frameskip.
Setting PALMODE to PAL_RED (or pressing L/R in the menu) enables the red palette (for those who like to play golf in red fields. Just like in real life, right?)

Screenshots

Building

Once you have [ctrulib installed](http://3dbrew.org/wiki/Setting_up_Development_Environment), you can choose between four different make targets:

**`make release`** adds `-O3` to CFLAGS. It's meant to be run on an actual 3DS and will output basic debug info to stdout only if enabled in `rd_config.ini`.
**`make testing`** adds `-O3` to CFLAGS. It's meant to be run on an emulator (citra or 3dmoo). It will output basic debug info to the terminal.
**`make debug`** adds `-g -O0` to CFLAGS. It builds without optimizations so it can be debugged with gdb.
**`make slowdebug`** adds `-g -O0` to CFLAGS. It will output a lot of debug information, which will slow emulation down but might be helpful to debug game-specific issues.

For easier debugging, you can build it for arm-linux (tested on a Raspberry Pi) with `make -f Makefile.linux` or for android using `ndk-build`.

License

Some of the code is distributed under the MIT License (check source files for that) but, since this is a port of Reality Boy, here is (part of) the original readme:

This Reality Boy emulator is copyright (C) David Tucker 1997-2008, all rights reserved. You may use this code as long as you make no money from the use of this code and you acknowledge the original author (Me). I reserve the right to dictate who can use this code and how (Just so you don't do something stupid with it). Most Importantly, this code is swap ware. If you use It send along your new program (with code) or some other interesting tidbits you wrote, that I might be interested in. This code is in beta, there are bugs! I am not responsible for any damage done to your computer, reputation, ego, dog, or family life due to the use of this code. All source is provided as is, I make no guaranties, and am not responsible for anything you do with the code (legal or otherwise). Virtual Boy is a trademark of Nintendo, and V810 is a trademark of NEC. I am in no way affiliated with either party and all information contained hear was found freely through public domain sources.

Acknowledgments:

Frostgiant, Parasyte, and DogP (and the rest of people that have contributed to the VB sceen in the last five years) - Their work on Red_Dragon has been a real inspiration. Its amazing how far they have gone with so little to start with.

Bob VanderClay - most of the original code is based off of his VB disassembler.

Ben Haynor - Provided me with a much better understanding of the VB internals.

Joseph LoCicero, Dave Shadoff - I stole the jump table ideas from their tg16 disassembler, thanks guys.

Neill Corlett - took many ideas (and some code) from his Starscream CPU core

Kevin Banks - for donating a very nice pair of Frenzle 3D viewers, and being an all around great guy.

Megan Tucker - For putting up with my tinkering all night, and resisting the urge to toss all my video games out the window.

v810 is a trademark of NEC co. Virtual Boy is a trade mark of Nintendo Reality Boy is in no way affiliated with either of these parties

Credits

Everyone mentioned in the license. Without Reality Boy and Red Dragon it wouldn't have been possible.
smealum and contributors - ctrulib.
Vappy, Team Fail, HtheB, hippy dave and kane159 on GBAtemp - early testing.
benhoyt - inih.
Myria - libkhax
thunderstruck - CIA banner sound (taken from Fishbone).
nop90 - Reality Boy backports and fixes.
danielps - 3DS port and V810 dynarec.

Changelog:

Removed libhax. Homebrew launcher users will have to run a kernel exploit (like fasthax) first.
Added settings for frameskip, maxcycles, sound and debug output.
Implemented floating point instructions.

Known Issues:

Low compatibility.
Glitchy graphics on some commercial games.
Frame limiting is broken when frameskip is enabled.
Some menu options aren't implemented.
To change ROMs you have to exit first (touchscreen->File->Exit).