VBA-M

galamonth · Post by **galamonth** » Fri Nov 02, 2007 10:32 am

The current official site for VBA-M is: http://vba-m.com/
-------------------------------------------
MOD EDIT: For those of you who don't know know what VBA-M is, it is a fork of whatever was last in development for VBA which was written by Costis.

Spacy, mudlord, and DJRobX are mainly responsible for this fork, with contributions by Nach and Jonas Quinn.

The emu is being rewritten for better portability, and as such will be using QT for the GUI and have rewritten Direct3D to use filters with a shader compatible video card (SM2 minimum I presume) and have rewritten OpenGL, added OpenAL as an option, and possibly DirectDraw for those those older systems. This emu also includes a revised sound core.

There isn't an official version yet, but this project is very promising.

http://vba-m.ngemu.com/ - Website

http://vbam.svn.sourceforge.net/viewvc/vbam/ - SVN

http://vba-m.ngemu.com/forum/forumdisplay.php?fid=2 - Forum

http://vba-m.ngemu.com/vbam/ - Where to get their stuff
vbacompiles/ - Windows binaries based off SVN
vbacompiles/msvc2008/ - Windows binaries based off SVN compiled with MSVC2008 (most active/latest), includes required downloads/files to run it
vbacompilesx86-64/ - 64-bit Windows binaries based off SVN
vbafiles/ - filters
vbaotherbuilds/ - other builds, including the QT versions

---------------------
Mudlord and djrobx have been merging the features from various vba build into one and seems they having sucess whit it! or at least is what i did understand on the ngemu forums.

Isn't that great news? Check it out!

http://www.djrobx.com/misc/VBAM-alpha-build13.zip

Post by **Nach** » Fri Nov 02, 2007 11:42 am

galamonth wrote:Mudlord and djrobx have been merging the features from various vba build into one and seems they having sucess whit it! or at least is what i did understand on the ngemu forums.

Isn't that great news? Check it out!

http://www.djrobx.com/misc/VBAM-alpha-build13.zip

And WTH is the source?

And is there any info about this?

(and I bet they didn't include anything from my VBA builds)

Post by **Agozer** » Fri Nov 02, 2007 12:01 pm

Mudlord's alpha build seems to perform a lot more poorly than kode54's build does. Just my observation or then there are some settings that I've overlooked.

I'll stick with kode's build.

Post by **Nach** » Fri Nov 02, 2007 12:33 pm

I found the source and joined https://vbam.bountysource.com/

I'm wondering what the heck they did to it though, half the files are gone. Would also be nice to talk to the developers, but no e-mail addresses, and NGemu forms don't allow registering with anything but ISP/School/Work e-mail accounts.

mudlord · Post by **mudlord** » Sat Nov 03, 2007 4:25 am

Mudlord's alpha build seems to perform a lot more poorly than kode54's build does. Just my observation or hen there are some settings that I've overlooked.

In recent SVN code, there has been improvements to the core in regards to VBA linking, which helps it perform better somewhat. Granted, optimization will be a priority, when all the core is settled out first. DJRobX is currently going through the GUI and D3D engines, while I am handling OpenGL and the implementation of the different cores. Currently I am implementing re-recording support and a updated GB emulation core which is from nitsuja's release.

I'm wondering what the heck they did to it though, half the files are gone.

Please explain. Currently I and DJRobX use VC2005 only to compile.

Would also be nice to talk to the developers, but no e-mail addresses

mudlord88 AT gmail DOT com

(and I bet they didn't include anything from my VBA builds)

And where's the sources to your builds? We have been having severe trouble locating sources.

OmegaX · Post by **OmegaX** » Sat Nov 03, 2007 5:05 am

Hi mudlord, since you are replying here I would like to ask you what is the address of the SVN source code, because at https://vbam.bountysource.com/ I can't seem to find a link.
Also are you planing on supporting the Linux build of vba too? there are lots of patches over latest SVN at vba's sourceforge page and they are mostly for the SDL version (I personally have used the ones that let you compile with newer gcc and give openGL support). SDL version has better performance for me than GTK after I applied the OpenGL patch, but it hangs on exit due to an error on the sound core and the patch that supposedly fixes that error makes emulation slow down a lot.
Sorry for the long explanation but I thought it can be helpful if you ever consider incorporating those changes to your build, VBA really needs an up-to-date Linux build that has been neglected for so long.

mudlord · Post by **mudlord** » Sat Nov 03, 2007 6:47 am

Hi mudlord, since you are replying here I would like to ask you what is the address of the SVN source code, because at https://vbam.bountysource.com/ I can't seem to find a link.

http://svn.bountysource.com/vbam

Also are you planing on supporting the Linux build of vba too? there are lots of patches over latest SVN at vba's sourceforge page and they are mostly for the SDL version (I personally have used the ones that let you compile with newer gcc and give openGL support). SDL version has better performance for me than GTK after I applied the OpenGL patch, but it hangs on exit due to an error on the sound core and the patch that supposedly fixes that error makes emulation slow down a lot.

At this stage, no. I do not have access to a Linux installation to make this possible.
In the future, though, Linux support might be present.

DancemasterGlenn · Post by **DancemasterGlenn** » Sat Nov 03, 2007 9:13 pm

mudlord wrote:At this stage, no. I do not have access to a Linux installation to make this possible.
In the future, though, Linux support might be present.

I'll keep my fingers crossed!

Post by **Nach** » Sun Nov 04, 2007 12:57 am

mudlord wrote:
I'm wondering what the heck they did to it though, half the files are gone.
Please explain.

Half the source from the official VBA is gone, not present, not there, deleted, unavailable.

I'd consider joining the project, but if it's about making VBA less usable, I don't care.

mudlord wrote:
Would also be nice to talk to the developers, but no e-mail addresses
mudlord88 AT gmail DOT com

I found your AIM account, any chance you can go on it?

mudlord wrote:
(and I bet they didn't include anything from my VBA builds)
And where's the sources to your builds? We have been having severe trouble locating sources.

All there is is source:
http://nsrt.edgeemu.com/vba-nach.tar.bz2

mudlord · Post by **mudlord** » Sun Nov 04, 2007 2:09 am

I found your AIM account, any chance you can go on it?

Yes

Half the source from the official VBA is gone, not present, not there, deleted, unavailable.

I'd consider joining the project, but if it's about making VBA less usable, I don't care.

You mean the Linux support right? The files can easily be reintroduced to the SVN tree, if people complain about a lack of Linux support. (even though I have my reasons to oppose it, so I'd be doing something against my will, but meh). As for the removed files, they can be added back in, if deemed prudent.

Thankyou for supplying your source though.

Tallgeese · Post by **Tallgeese** » Sun Nov 04, 2007 3:45 am

What are your reasons for disabling Linux support, if I may ask? I truly don't care as I like whta you're doing and am on Windows, I'm just curious. Shouldn't do something against your will.

mudlord · Post by **mudlord** » Sun Nov 04, 2007 6:19 am

Well, at the time, me and DJRobX tried to have a unified base for the source code for Windows. So we tried to make it as clean as possible and in the process, the makefiles for Linux and other things were taken out.

The other developers and I are looking to redo the mods, but on a more updated base, which will have Linux support. So Linux support will come back, I just don't know yet as there is still a lot of things to implement still.

Tallgeese · Post by **Tallgeese** » Sun Nov 04, 2007 7:19 am

That seems pretty upstanding to me... *Shrug*

mudlord · Post by **mudlord** » Sun Nov 04, 2007 9:29 pm

Yeah, we are still trying to lay down the base, so to speak. Then cross-platform support will definately follow, once this "base" is sorted out.

As for the speed problems, DJRobX managed to profile the emulator, and they seem to be related to the implementation of kode54's sound updates:

DJRobX from NGEmu wrote:Regarding code optimizations. I ran a profiler on the code and I'm 99% sure I see why our version is slower than the standard 1.7 versions: Kode54's sound updates. The VBA code adds sound to its buffers one byte at a time. The filtration functions were then bolted onto that function. The filtration functions were written with "higher level" C++ mentality (layers of classes and overriden functions). There is also some sort of dynamic "sample rate" adjustment in there that deals with floating point numbers.

Given the massive number of times the function gets called those layers slow things down quite a bit even when sound filtering is off. The layers themsleves are fine but I think the function should be getting called in chunks at the output phase. Some of the code is directly tied into the core too, I'm not sure of the reasoning behind that.

I have to study the code a bit more to figure out what's going on and find a more efficient way of doing it.

Tallgeese · Post by **Tallgeese** » Wed Nov 07, 2007 10:55 pm

Interesting. I'll be glad when hat's sorted out, my comp chokes somewhat on this, ahahha.

mudlord · Post by **mudlord** » Thu Nov 08, 2007 1:49 am

Yeah, we apologise for the problems so far.

DJRobX has got the new 1.8.0 core in, suffice to say, theres some speed issues with that too. They will get ironed out in time, and I got some renderer updates I want to make too....

Tallgeese · Post by **Tallgeese** » Thu Nov 08, 2007 1:58 am

You don't need to apologize!

It is a shame about the VBALink author disappearing and not providing his source, as the link code seems to just not work properly when you hit connect (yes, I am that guy on ngemu saying the same thing).

DancemasterGlenn · Post by **DancemasterGlenn** » Thu Nov 08, 2007 4:21 am

I'm definitely pumped that this will at least eventually come to linux. Good luck with this project, I'll be keeping an eye on it.

Post by **Nach** » Wed Nov 14, 2007 7:53 pm

And we have lift off:

Speed is fine. It can probably run faster though if GBA.cpp didn't use up all the memory in a system and take 8 days to compile when optimizations are on.

DataPath · Post by **DataPath** » Thu Nov 15, 2007 12:51 am

Nach wrote:And we have lift off:

Speed is fine. It can probably run faster though if GBA.cpp didn't use up all the memory in a system and take 8 days to compile when optimizations are on.

I've had success compiling with -Os.

Post by **Nach** » Thu Nov 15, 2007 1:04 am

DataPath wrote: I've had success compiling with -Os.

And you probably used close to a GB of RAM in the process.

DataPath · Post by **DataPath** » Thu Nov 15, 2007 2:01 am

Nach wrote:
DataPath wrote: I've had success compiling with -Os.
And you probably used close to a GB of RAM in the process.

It compiled quickly and simply on a machine with 512MB of RAM. Using -O2, or even -O1, it would go crazy, take forever, and thrash. -O0 worked for me sometimes, -Os worked every time.

Post by **Nach** » Thu Nov 15, 2007 2:30 am

DataPath wrote:
Nach wrote:
DataPath wrote: I've had success compiling with -Os.
And you probably used close to a GB of RAM in the process.
It compiled quickly and simply on a machine with 512MB of RAM. Using -O2, or even -O1, it would go crazy, take forever, and thrash. -O0 worked for me sometimes, -Os worked every time.

You're using an older GCC aren't you?

mudlord · Post by **mudlord** » Thu Nov 15, 2007 3:39 am

And we have lift off

And we also have a MacOSX port done. Plus, Nach added 64-bit support to the Linux version, too.

DataPath · Post by **DataPath** » Thu Nov 15, 2007 5:36 am

Nach wrote:
DataPath wrote:
Nach wrote:
DataPath wrote: I've had success compiling with -Os.
And you probably used close to a GB of RAM in the process.
It compiled quickly and simply on a machine with 512MB of RAM. Using -O2, or even -O1, it would go crazy, take forever, and thrash. -O0 worked for me sometimes, -Os worked every time.
You're using an older GCC aren't you?

I dunno - is 4.1 older? I think that's what Feisty Fawn used. I'm on gutsy now, but haven't tried compiling it lately.

edit: I guess in the interest of full disclosure, I wasn't referring to compiling VBAM, but rather, VBA 1.7.2 source.

VBAM svn trunk builds as-is for me just fine with the default optimization flags on my Gutsy machine, but this system also has 1GB of RAM.