Jump to content
Visual Boy Advance-M


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About JRMoore

  • Rank
  • Birthday 01/09/1986
  1. As far as I know running the MFC version of VBA-M under Wine works really well. Anyway, the thing you're having with OpenGL probably has to do with the fact that you're in a 64-bit Linux using the 32-bit binary, you'd need 32-bit libs for that to work. You can always build the emulator yourself: http://vba-m.com/forum/how-build-vba-svn-code-linux-t-527.html
  2. Impressive... even Agner Fog is involved!!! What a difference in the VIA Nano tests... I know there are some switches to add alternative paths or to target an specific Intel processor family. /Qax adds a processor specific auto-dispatched code path in addition to the default one (so you're already knowing the dispatcher will be in the executable if you use this one). /Qx overrides the /arch switch targeting an Intel processor family and the executable should only be used on those (e.g. /QxSSE3_ATOM generates code to be used in an Atom processor). The Parallel Studio provides a compiler too through the Parallel Composer which is the C/C++ compiler from Intel as generally released. The the latest version includes the v12 compiler (not available as of now, the latest standalone C/C++ compiler from Intel is v11); but there's already a post by Agner where he tells they haven't changed a thing in the new compiler [1]. If you ever need to use the Intel compiler in page 130+ of Agner's optimizing C++ (at the time of writing, works with v12 compiler) there's a way to override the dispatcher detection [2]. Thank you for pointing that out! [1]: http://www.agner.org/optimize/blog/read.php?i=49#127 [2]: http://www.agner.org/optimize/optimizing_cpp.pdf -------- EDIT: For completeness I made a question to Agner regarding the use of the Intel Compiler without the switches /Qx or /Qax [3]. Basically, if only /arch was used during compilation there's no dispatcher and the code generated will run fine in non-Intel processors. Unless special libraries are used by the project like MKL, TBB, ... (not the case in VBAM). [3]: http://www.agner.org/optimize/blog/read.php?i=49#134
  3. That may be, It was the same with VS2008 as the runtime and standard C++ library were included too (no dependency on msvcr90.dll, msvcp90.dll or mfc90.dll) but runtime and MFC in VS2010 are slightly bigger (same as the other three but 100 instead of 90). I know some people for small programs link against the system CRT dynamically (no version number in the files) because it's already loaded and shared in memory so they get lower disk footprint, memory usage and startup. But if I recall correctly that's not possible in Visual Studio, nor desirable either for a big program. Those files are meant to be used for system components, they are not as complete/efficient as the ones provided with newer versions of VS.
  4. Yes, GCC in no option in this project and I was aware of that problem with Intel compilers (at least years ago it was crazy, I don't know how if behaves now). I only have access to the new Parallel Studio through my employers and was doing some tests. The important bit is that the binaries are being built with the runtime within the executable of VBAM, so there's no need for end users to install the VC runtime. If you changed the runtime library to multi-threaded DLL (/MD switch) and set MFC to use the DLL too, VBAM would be depend on msvcrXX, msvcpXX and mfcXX (so the redistributable package would be needed). Although the executable would be smaller, you'd lose the portability it now has. EDIT: The binary I posted above is not tied to any Intel processor. Optimizations and alternative paths for Intel specific processors were not selected.
  5. Hello Squall Leonhart, about the VC++ 2010 runtime I don't think it will be necessary even building with VS2010. Right now the project files are set to use the /MT switch which creates executables linked to the static version of the runtime (multi-threaded, the single threaded version is long dead). I've just checked the latest executable build with Dependency Walker and there's no dependency on the C runtime. The only remarkable one would be the updated DirectX runtime (you can remove zlib from the readme file too as you're linking statically against it). I've just compiled SVN959 using the compiler provided in the Intel Parallel Studio 2011 through Visual Studio 2010 (changing some settings), the only dependency not included in Windows (7 in my case) is D3DX9_43.DLL; I've attached to this post a binary using SSE instructions. I'm using up to SSSE3 instructions for me, If you need a binary using a specific instruction set (e.g. SSE2 to allow the use of XMM registers) just tell me and I'll generate the binaries. Kind regards.
  6. I have made a guide covering it more or less and posted it in the Emuforums forum. I'll post it here too: This is a guide for people who would like to build VBA-M from its development source code in Linux and use it either through the SDL or the GTK+ interfaces. First of all, dependencies. As far as I know you'll need the following programs and libraries: cmake subversion sdl libpng zlib sfml mesa cairo libxv gtkglext gtkglextmm gtkmm glibmm glademm A minimum development environment is assumed (e.g. C/C++ compiler, the make utility, ...). The ones marked in red indicate that development packages of them are needed as well (e.g. mesa-dev). Now, once all of that is installed create a directory named VBA-M (for example) where ever you wish to build it. Open a terminal window and navigate to the directory you just created. Now follow this steps: 1. Get the source code, check out the trunk branch: [user@machine VBA-M]# svn co https://vbam.svn.sourceforge.net/svnroot/vbam/trunk . *Note the dot in the end of the last line, it's necessary too. 2. Generate the makefile: [user@machine VBA-M]# cmake . -DCMAKE_INSTALL_PREFIX=/usr 3. Build and install VBA-M: [user@machine VBA-M]# make && sudo make install 4. Run VBA-M: gvbam for the GTK+ interface and vbam for the SDL one. NOTES: 1. When looking for the dependencies, some of them might be available in your distribution with "lib" prefixing them (e.g.: libgtkmm instead of gtkmm) or not available at all (you'd need to get and build them yourself). 2. In the second phase CMake may warn about things not found, if that's the case verify you have installed all the dependencies as well as their development packages. E.g.: gtkmm-dev or something like that. 3. In that phase too, you may specify a different dir for CMAKE_INSTALL_PREFIX, the one I posted should make VBA-M available for system-wide. 4. In the third phase, make install have to be called as root or with administrative privileges as it will write to /etc (unless you changed the directories through additional options). E.g.: I've put sudo there because it's common to have that installed and configured. 5. There are more options to be used when generating the build script: disabling one of the interfaces, using some assembly parts, ... This "walk-through" is kind of generic. If you wish to know more take a look at CMakeLists.txt.
  7. JRMoore

    RRX implementation in x86 assembly.

    Hello, looking at the code I think I don't understand how RRX is implemented in x86 assembly. The code right now is the following: #define RRX_OFFSET \ __asm { \ __asm bt dword ptr C_FLAG, 0 \ __asm rcr offset, 1 \ } The bit test sets the carry flag, but I don't see it using the offset to get the LSB, instead it seems to be 0ing the carry flag, so the operation is a plain RCR. Can somebody explain this to me? Thank you very much. I'll be answering my own question, it's well implemented; I just needed to read some more documentation. Both rotate through carry right (RCR) and rotate right with extend (RRX) allow a 33-bit rotation by using both the offset (in this case) and the carry flag. In RCR the carry flag goes to the bit 31 and the bit 0 goes to the carry flag, which is essentially the same as the RRX does. The bit test op is needed to zero the carry flag in case it was set to 1 from a previous operation. Kind regards.