VBA Next

Libretro Cores
#1

[h]VBA Next[/h]

What is VBA Next?

Fork of VBA-M, heavily modified.

How to compile the library (for libsnes)


git clone https://github.com/libretro/vba-next
make -f Makefile.libretro

Screenshots

#2

Hi, my GBA romset has each of the roms numbered in the titles of the zip file, making finding games a right pain in the arse as they do not appear alphabetically in the folder. Will a future release be able to readthe rom name and exclude these numbers. The thoughts of renaming files manually is enough to give me a headache!

#4

Mind your own business then.

#6

It is the correct thread for questions on VBA Next, this is why it was created.

#7

Writing a script to rename them all to the proper names wouldn’t be hard, so long as the order they are numbered in is a standard ordering.

Just need a script that does “ren %1 %2” and reads from a list, or use Excel or similar to make the script, assuming you have the list.

#8

This will not be happening. Reading ROM headers is very core-dependent and in the case of GBA you can simply rename them anyway. The fact they’re inside ZIP files complicates things further.

This sounds like something a frontend should do.

#9

Charco, how about scanning your roms with a No-Intro datfile? PM me for details as I don’t think this belongs here.

#10

Thanks guys, I’ve since found a romset that has the roms named correctly.

#11

I never saw this information in the documentation and searching never turned up anything useful. To convert your VBA/VBA-Link/VBA-M/other VBA flavor saves to those compatible with Retroarch follow the steps below.

  1. Create a copy of your save game. You don’t want to lose all that play time just because you made a mistake.
  2. Open your game with your flavor of VBA then load your save.
  3. In the VBA menu, go to Options > Emulator > Save Type (this is using the current version of VBA-M, other flavors may be different). Make note of the current settings and change your save type to SRAM and Flash 128 KB
  4. Go back to your game and save it through the game’s menu (not through making a savestate)
  5. Navigate to your save file which is by default in the same folder as the rom. The file size will be 128 KB.
  6. Change the file extension from .sav (.sa1 or .sa2 on VBA link) to .srm. 5a) Back in VBA, change the save type back to what it was before (I believe the default is Automatic and Flash 64 KB) if you are going to convert another game, otherwise you will get errors when trying to load your next save file. You may need to exit then re-open VBA for the change to take place. This used to be step 3a If you do this step before changing the file name it will automatically change the save type, resulting in a file that won’t work.
  7. Open the rom in Retroarch. The save game should be available to be loaded and retroarch will automatically add it’s magic stuff to the file, changing the size to 136 KB.

I have not yet attempted to revert a retroarch save back to a VBA save but I would imagine the process would simply be in reverse, except the changes made to the save file by retroarch may need to be removed with a hex editor.

I hope this helps someone else as much as it did me. I love retroarch but dreaded losing several 100+ hour saves. :slight_smile:

To the devs and all that contribute, THANK YOU! :smiley:

#12

@fuidama Thanks for posting. I’m sure others will find this useful :slight_smile:

#13

Is it possible to emulate 2 player GBA games that used a link cable? Would be great to have local 2 player on the tv.

#14

Any luck on converting from retroarch back to PC?

#15

Apologies for the wall of text, I have a short answer in my second paragraph.

I’ve been very happy with Retroarch and have not had a need to try to revert back. However, you’ve raised my curiosity and I have gotten it working. However, it is NOWHERE near as easy to convert from a Retroarch save back to a VBA save. This is not exactly Retroarch’s fault either. VBA will allow you to save in any save format you want, but will only open the save file in the format that it detects the game should be. For example, I am playing Final Tactics Advance, VBA detects that it’s save format should be Flash + Flash 64 KB. So what it expects is a 64KB save file in a specifc “Flash” format, no matter what. So when we feed it a 136KB “SRAM” file it just chops off everything after the first 64KB and throws a “corrupted save memory” error when the format isn’t correct. Since the save data is in a different format with most of the useful information past that 64KB mark, most of the actual save information is lost and all that is left is an unusable file full of useless garbage data. For this reason if you are going to try to convert back to VBA, MAKE SURE TO CREATE READ-ONLY BACKUPS OF YOUR ORIGINAL SAVES BEFORE YOU DO ANYTHING.

In short for those that are more familiar with hex editing, for Flash+Flash 64 KB games (Which seem to be the most common, I didn’t see any that were different in the ROMs I tried), in your Retroarch SRAM file copy the data from the lines C6F0 through FFF0 and paste it at 86F0 through BFF0. Zero the data from lines C6F0 through FFF0, and it may be overkill but remove all the data after line FFF0. Save the resulting file as a .sav, and it should work with VBA. Flash start: 86F0 Flash end: BFF0 SRAM start: C6F0 SRAM end: FFF0

For everyone else, I will assume the Windows operating system. 0) Create a backup of any save file you will be working on, setting it as read-only may also help protect it from any accidents. Since VBA will instantly “chop” files it tries to load, any mistakes can be very bad if you don’t have backups or a “testing” folder.

  1. Download HexEdit ( http://www.catch22.net/software/hexedit ), it’s an open source hex editor that will let you see the data in a file in both hex and ascii. In my testing, WinMerge was invaluable in showing the differences between two files as it gives a visual pattern on the side that lets you see what is different in each, however it shouldn’t actually be needed unless my process doesn’t work and you need to do some investigating on your own. 2) Open hex edit and drag your .srm file into the window. The screen will fill with a lot of data. The left area lists the line number. In a typical .srm it should start at 00000000 and end at 00021FF0. The middle area will display the hexadecimal data. This is the raw data stored in the file. The right area will display an ascii representation of the hexadecimal data. In most cases this will just look like garbage but can be helpful in spotting data or changes.
  2. Click in front of the first hexadecimal number on the line 0000C6F0. The very bottom left corner of the window should read “Cursor: 0000C6F0”.
  3. Select Edit > Select Range…
  4. Type 10000 in the selection box, select “Selection End”, and press OK.
  5. You should now have everything between 0000C6F0 and 00010000 selected. Copy the selected range.
  6. Delete the selected range. Everything between 0000C6F0 and 00010000 should now display nothing but “0000”'s for hex and “…”'s for ascii. The changes will be displayed in red.
  7. Scroll up to line 000086F0 and click before the first hexadecimal character. The cursor at the bottom of the window should read “Cursor: 000086F0”
  8. Paste the copied data. The data from before should now fill the lines 000086F0 through 0000BFF0 and will be colored red to distinguish the change.
  9. Save the file in the same place as the rom, with the same name as the rom, with an extension of .sav. If you already have a file by that name, make sure it is not a working one or that you are saving it to the correct location. You should be left with a 136KB .sav file (don’t worry, VBA should fix that).
  10. Open VBA and select Options > Emulator > Save Type > and ensure “Automatic” and “Flash 64 KB” are both selected (I’m using VBA-M other flavors may be different).
  11. Open your ROM and the save you had in Retwoarch should now be working in VBA. VBA should automatically chop the file and all that extra data down to 64KB.

That’s the skinny of it. I’m not a programmer so I’m not exactly sure what all the extra data in the file does or what the specific differences are between the different save formats. I know just enough to be dangerous and have an attention span just long enough to recognize patterns. A better person than I might be able to create a way to convert the files automatically.

If anyone else tries this, let me know if it works/helps.

Lastly, would anyone know what’s with the extra 8KB of extra “FFFF” data Retroarch tacks on to the end of it’s SRM files? I’m just curious :slight_smile:

#16

Have you tried running them through gbaconv?

It should be able to convert save between VBA and VBA-Next back and fourth.

Saving is a mess when it comes to GBA emulation, sadly.

#17

I didn’t know this existed. Peeking at the code this does seem to be related to save data conversion. Unfortunately, I don’t know how to compile from source; like I said, I’m not a programmer. Would anyone be able to send me windows binary, or if it is built-in some instructions on commands to pass retroarch? Though, it does state on github “broken right now on retro_run” and was last touched in 2012.

#18

I’ve used it a few months ago and it worked for me. Link As always, be sure to make a backup of your saves beforehand.

I think the main reason it’s not mentioned anywhere is because it doesn’t come with any sort of interface. You’ll need to drag your save onto it and it should be converted into a sav/srm file.

#19

Very much appreciated Oggom! I gave it a try with a few of my saves and worked flawlessly converting .sav to .srm and back. Each was playable after each conversion. MUCH easier than the methods I used in my previous posts. I hope this utility gets more attention in the future :slight_smile:

#20

Is there any chance we could get the VBA-M “Interframe Blending” (None, Motion Blur, Smart) feature as a core option for VBA-Next? I understand that there’s already a motion blur shader, but VBA-Next in particular is especially useful on platforms like Wii which don’t have support for RetroArch shaders.

Interframe blending is important on the GBA because developers frequently used the high response time of the LCD display to do things like fake transparency (e.g. F-Zero series’ minimap) or for cheap scaling (e.g. Classic NES series) by simply flickering a graphic/line from frame-to-frame to get an effective blending technique which goes over pretty poorly on (relatively) low-latency displays like TV.

Nintendo’s Game Boy Player implemented a similar filter option; when “Screen Filter” is set to “Sharp”, the result is similar to RetroArch, with transparent/scaled objects flickering somewhat unpleasantly. Switching to either “Normal” or “Soft” significantly reduces the flickering, resulting in an persistent effect much closer to what the developers intended.

I’m not sure how CPU-intensive the effect is (and I understand that the GameCube is doing nine-tenths of nothing during GBP playback, with plenty of headroom for fancy effects), so it’s possible that it would impact performance too much to be useful in RetroArch on some platforms. I understand if that’s the case and nobody wants to implement this for that reason; otherwise, I think it could greatly improve the GBA experience for any game which took advantage of this GBA “feature”.

#21

Frame blending on CPU is pretty intensive, at least for a Wii, ok, maybe not that much for a 240x160 frame, but ye.

#22

Oh well, understood. Thanks for the consideration.