…well at least this is something I would like to write.
But maybe I have your attention now 😉

A few people here know me. I am a very long time member of PlanetVB. I contributed a lot to the VB scene.
Many times without asking for anything in return.
The Virtual Boy always fascinated me, even with its flaws and problems. There are several real nice games on it and you can not find or play them on any other system.
And this brings me to the point of this topic.

The Virtual Boy and some of its games deserve to be played by a wider audience. There is also a lot of very cool homebrew by now. The sad thing is, because it is Virtual Boy not many can enjoy it in full and propably never will.
The System itself costs now quite a lot and lets not even talk about some games.
Also if you have a VB, chances are high that your system suffers from the display problems. This is fixable but it is not very easy to do. The usual new “retro fan” won’t bother.

There are emulators out there but with none you can enjoy the games and its 3D without hazzle.

The way I see it, we need to do something about it.
The only system which can bring the VB games to a real wide audience and also features the 3D without any problems is the (New) 3DS.

The Nintendo 3DS is out there now for a very long time. When this system came out, I did MPO files of Teleroboxer to show how well it would look like on it.
Now after many years, the 3DS and the New3DS is fully hacked and homebrew is possible without big problems. There is even a quite good working 3DS Emulator called Citra out there which should make development easier.

Unfortunately there is still no usable VB Emulator for the 3DS and this I do not understand at all!
For me a proper VB emu on 3DS was a inevitability from day 1.

The only VB emulator on the 3DS is Mednafen trough RetroArch.
On a limited system like the 3DS this makes no sense.
We really need a dedicated VB Emulator.
It should be possible to use sourcecode of available VB emulators for this but it needs 3ds spcific optimation.

I am not sure if the 3DS can be used but the New 3DS should be usable. There we have all the buttons needed, there is 3D, the screen offers high enough resolution so that no scaling shit is needed and there is Head Tracking. In theory all is there to offer a second best thing after the VB.

3D Pictures of 3DS Games on the VB is a cool idea but we should also do the other way around. Seeing all the effort with the VB homebrew I would say we have all the recources to pull this off.
What we are waiting for? A wider audience can only be good for the community.
We are also in luck because there are only a handfull of games to take care about. This should not take ages. What do you think? Also I am sure there are people on GBATemp who are willing to contribute to this project in several ways if done right.

If we look into this, I think we should first determine if the New 3DS is capable to emulate the VB at full speed or close to it and go from there.

PS: with a wider audience and more interest in the VB several things could happen:
Unreleased games surface (Dragon Hopper)
Or Nintendo finally stops ditching the VB and brings official VB Virtual Console Content which could lead in Dragon Hopper or others. When it came to emulation stuff, Nintendo always did it after the Internet community was first.

whats about Virtual 3DS or VB3DS? this project looks interesting yeah ive been wishing to see a VB emulator that works on the 3ds is it only going to work with the new 3ds though?

How long has it been out? I used to have one on my N3DS but it had poor compatibility and ran slow. I would love a new one that works better. I wish we could get one to work with the 3D on the 3DS

You can do it Guy! I’m still patiently waiting for the VB Tech Scroll. I feel like a robust emulator and debugger are some of the last few pieces for VB home-brew. Think about what’s out there now: VBDE, Home made carts, Link Cables. People complain about the current emulators not always mimicking the hardware well enough. Add a capable emulator and debugger and suddenly its much easier to do everything!

Well there are now good emulators for Desktop Systems. Mednafen is surely good. But most desktop systems have horse power so the emulator can do his work.
The 3DS (N3DS) on the other hand is not very powerful and it makes certainly no sense at all to run a Desktop Emulator on it with RetroArch on top. That is just overkill.
That is why I came up with the idea to start this thread and see what can be done.
And from what I can see, a 3DS VB Emu is long overdue 🙂

@Stereo Boy
Hehehe Stereo Boy is actually cool.
But I also really like VUE3DS_red-mirror.png from your earlier post. It is short, nice and clean. It reflects the VB colors and also would fit quite well on a VB game case ^^

Guy Perfect schrieb:

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.

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.

@GuyPerfect
Thank you for all the answers 🙂
Now I understand better.
This C code you are doing, will it still be ARM specific or is this also up to the person who is using it?

I fully understand the problem finding persons with the right skill set. This is also why I wrote earlier, that for the UI part, we won’t need necessarily a high skilled coder. The emulator code behind is another story. We all count on you! 😀

In general, the UI part is something we could do already.

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.

That sounds great! It will be very interesting to see how this works out!

Guy Perfect schrieb:
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.

Sounds very interesting.
Looking forward to the first version 🙂
But when it comes to the system documentary all needed infos should be available right?
Or are there still things unknown about the VUE in generell?

So far I didn’t wanted to open a thread on GBA Temp about this and wait for moe infos and so on. What do you think should we already start with the Frontend thingy?

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?

Guy Perfect schrieb:
… Actually, that’s a real possibility… How rich is STEREO BOY?

Good question! 😀
Okay who is rich here? XD

Guy Perfect schrieb:
… Actually, that’s a real possibility… How rich is STEREO BOY?

Me? Why me? 😉
Well … I once was rich! But then I bought a Hyper Fighting CIB for an outrageous price … do you accept Hyper Fighting as payment?
I don’t think I can afford payin’ a full time coder, but I definatly would fund this project. How about we as a community to crowdfund you?

Attachments:

1. 

   rich-boy.png
   

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.” (-:

I’d support this, depending on the duration of the project and the probability of success. I suspect others would too, tough it may be a tougher sell since good PC based emulators are out there. Having something that the New 3DS could run would definitely be something I would back though. Maybe do a Patreon?

Guy Perfect wrote:
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.” (-:

Guy Perfect wrote:
it’ll be around $500/mo USD.

OK, cool. This is just about the rent for my flat. So I’ll just move under the next bridge for the project duration! :thumpup: 😀

astro187 schrieb:
Maybe do a Patreon?

Kickstarter would be more appropriate for this I think, as we want to fund a certain project.

As far as I understand the difference, You wouldn’t be paid monthly, but tell a price for the final “product”. This price would be collected by the funders until it’s achieved, then you can start the project.

To fund this project with Kickstarter or patreon will only work if people are aware. I think a good idea would be to write a proper but short summary of the project.
What is the aim, what are the features and what are the benefits. Maybe a short description about the coder so the people are confident.
With that we should go on GBATemp and test the grounds.
In the starting thread we should point out that basically everything is ready to get starting but the funds are needed and we are planning to go on KS or Patreon.

Normaly it is always so that certain project want to achive something but do not have the proper people. If Guy Perfect is willing to dig into it we have this person and can present a whole case. That should trigger more people. Also because it makes the project foreseeable. Many people (also on GBATemp) like to have fast results and the usual “spare time” emulator is not offering this.

There is or was this Glide64 project for a proper N64 GFX emu plugin. A coder was doing it full time because he was able to collect enough monthly funds for this. This is actually a good role model. I think it took not very long to get all the funds for them.

Also this thread on GBA Temp could us also give an answer what the people prefer, KS or patreon.
Also with KS I dont think that anybody here wants to to any physical rewards for this. So we need to come up with some interesting digital rewards.

Personaly I think patreon is better because the aim is a steady income for the coder for the duration of the project. With KS you need to wait and with luck you got one big sum. This creates probems like tax shit and I think you need to be a company on KS.

Kickstarter would be good for the Visual Compendium but then again even this could be done with patreon.

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. (-:

Okay, I was checking a few things.
Several emualtion project were already successfull in funding the way we have in mind.
GLideN64 is a good example. they even fund single features.
They are using indigogo and patreon.

I have started to formulate a forum post for GBATemp with all the infos I got here from this thread. I have attached the text here. Can you guys plese check it. It is open for discussion.
Since it mostly concerns GuyPerfect, please have a look and also correct/add if possible.

I also updated the Frontend Mockups which should appear in the thread. They include now also 2 Screnshots and a Video.
There are 3 sections, JP, US and Homebrew:

Attachments:

1. 

   vue_jp.png
   

2. 

   vue_us.png
   

3. 

   vue_hb.png
   

1. forumpost.txt

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.

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.

[Guy Perfect]

I set up a Patreon page, available immediately: [redacted].

Where do we want to go from here? Main page of PVB? Set up a comprehensive thread and solicit interest from other communities?

• This reply was modified 6 years ago by Guy Perfect.
• This reply was modified 6 years ago by Guy Perfect.