Jump to content
Visual Boy Advance-M

Tantric

Members
  • Content Count

    0
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Tantric

  • Rank
    Newbie
  • Birthday 06/13/1984
  1. Tantric

    Merge changes from VBA GX

    Just a heads up, you might want to take a peek at the changes that have been made to the VBA-M core in VBA GX. Some of what's been worked on is: rotation/tilt sensors (using the wiimote!), solar sensors, rumble, RTC, custom Game Boy mono palette support. Obviously you can just pull what you want and implement it however you want, I just wanted to give you the heads up that the code was there. See the commits here, from March-May: http://code.google.com/p/vba-wii/source/browse/#svn/trunk/source/vba
  2. Tantric

    VBA-M [svn 854 MFC] info and download

    Actually, there's a "Delete" button, if you click on a file and then look up at the top where the Search bar is. You can use that if you accidentally upload the wrong file or something - but only before 50 downloads. Was just trying to be helpful. =)
  3. Tantric

    VBA-M [svn 854 MFC] info and download

    You should be aware that Google Code doesn't let you delete a file after 50 downloads. It's then there forever. So it's not the best idea to name a file "VisualBoyAdvance.7z", since you won't be able to replace that later with the "latest" version. Just so you know.
  4. Tantric

    Mother 3 audio issue

    Great, thanks, that answers it well enough for me =)
  5. Tantric

    Mother 3 audio issue

    I've had an issue reported to me for VBA GX (all core code is VBA-M). It's also been reported to happen in VBA-M. Basically the audio speeds up dramatically when selecting some menu items in Mother 3. The issue details are here, with a save file. I have no idea what the problem might be, but definitely the root of the problem is somewhere in VBA-M's sound emulation. Any help you guys can provide me (either fixing something in VBA-M, or any thoughts on what's happening and on what I should check in my port) is appreciated!
  6. Tantric

    VBA Emulater for Wii problem

    This is a known problem with the current version, I've fixed it for the next version. You'll have to wait until I release an update. Until then, you can still use SRAM saves. This issue has already been posted to the VBA GX site. If you have other problems, please check there at the open issues to see if your issue has already been posted.
  7. Tantric

    PPC core fix

    It's hard to tell, but I think every little bit helps. VBA-Wii is actually running decently - games like Minish Cap run without frameskip, games like SMB3 run at frameskip 1 or 2 (totally unnoticeable). The only exception is stuff like Mode 7 - the intro for FFIV runs well at *cough* frameskip 15 *cough*. GBA-thumb is the only part that's been PPC-activated, I think activating more would help more...
  8. Tantric

    PPC core fix

    Problem: After activating the PPC core, GBA-thumb.cpp wouldn't compile for me using gcc stating: unsupported relocation against xer. Fix: replace two lines that have 'mtspr xer' with 'mtspr 1'. This doc explains it: http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.aixassem/doc/alangref/mtspr.htm mtspr - move to special purpose register xer - register at 1 Works quite happily now! Now if only someone would update the GBA-arm.cpp PPC code...
  9. Tantric

    reading/writing save states

    Actually you do make a good point (I think). This is something to avoid. This can be a problem for big endian vs little endian architecture. I actually don't use any of this code to avoid running into such problems =) Here's a post I happened across just yesterday: http://www.tehskeen.com/forums/showthread.php?p=43389 See shagkur's response.
  10. Tantric

    Memory-based Patch support

    For use in the Wii port, I've converted the IPS/UPS/PPF Patch.cpp file into a memory-based version. I'm posting this work here in case you wish to use it. The easiest way I found to do this was to create memory based duplicates of the standard C file functions (fopen/fread/etc). I thought this might be advantageous to VBA-M to use, allowing for easier portability and making it so that you don't have to modify the core files to support differences in ports. In my implementation I do my file loading before tapping into the Patch.cpp functions. I'm including a basic framework for memory based file replacements (these are intended to mimic the behavior of the std c library file functions - write functions aren't there, but would be easy enough to add), and an updated Patch.cpp that uses these functions. A working implementation is also on the VBA-M Wii SVN. Similar ideas are in the memgzio from VBA and also the FCEUFILE structure that FCE Ultra uses. Feel free to use any of my code if you want.
  11. Tantric

    free(pix) in GB.cpp/GBA.cpp causes crash

    Yes, I spoke too soon. It had to do with the way I was allocating this memory, nothing's wrong in VBA-M. Just ignore me!
  12. Just a heads up I had to comment out free(pix); in GB.cpp. It was either doing it there, or the one in GBA.cpp - but having both causes my Wii port to crash on free(pix) when switching from one engine (game system) to the other. This variable overlaps between the GBA and GB cores - it's the only one that does like this. Renaming pix for the GB core - gbPix or something -would permanently solve this issue and would probably be safer for memory allocation.
  13. Tantric

    Memory-based battery/state saves

    Yes, just a pointer to the ROM would be great too. The memory-based idea actually applies to anything/everything that uses file IO - another thing is IPS. It really is very simple to change, just that it has to be done everywhere all at once.
  14. I'd like to see memory-based versions of emuReadBattery/emuWriteBattery included. Mem based saves can be very important for porting to different platforms - for VBA Wii I need it for saving via network, for example. This would be the same idea as emuReadMemState/emuWriteMemState vs emuReadState/emuWriteState. Actually what I'd really suggest (for ease of your code maintenance) is to scrap the file-dependent functions for states/batteries and replace them with memory versions only. The file I/O can be handled in the specific port code before/after using the "emu" functions. Switching from file IO to memory IO is extremely simple. I've actually already written memory-based battery functions for the VBA-M Wii port but I'd love to see this in the VBA-M code itself - it would make updating my port easier.
  15. Tantric

    SDL system10frames improvement

    So I've been working on the Wii VBA port for a few revisions now, and I've been using the SDL system10frames as template. Well, it sucks. Frames either overskip or underskip, so there's speedups and slowdowns in gameplay and sound. Not an issue I'm sure with a new desktop computer, but for something with less horsepower, it's no good! I've written my own little system10frames, with a usleep to handle timing. It's incredibly basic, but it eliminated the problems I was having completely. Perhaps you guys can improve it further (or suggest further improvements to me), I know I'll be playing with it some more. Source code on Google Code.
×