Stop Using VBA! (For playtesting)

Wait. Duckstation? I’ve been using Beetle PSX HW this whole time because it’s the least terrible but it runs horrifically on lower spec systems. What is Duckstation

It’s based that’s what :sunglasses:

it works just get good lmao

This is like unironically a bad idea, who cares if the emu is more widely used? It’s not like mgba is some like deep dark secret artifact you have to dig deep into the dark web to get in order to play FE hack number 685. It’s free lmao, already known to be more accurate and most importantly actually alive active and not dead since like 2007 which is huge and an underrated attribute. What is inaccurate has a higher potential to become more accurate without resulting to some obscure ass build.
That mindset is why communities exist where you need to download the 3rd fork of version 0.43096 alpha build of the crustiest emulator from 1792 to play hacks that fall apart when you run them anyway.

The debugging thing is valid tho.
I mean idk, the very notion that the chance of a one-sided compatibility bug is low undermines either side on this vs debate. you’re still more likely to cause one on vba tho

I’m not here to seriously butt in on this, frankly I couldn’t be assed to go back and forth on it y’all do y’all. I don’t even hack.
mgba is pretty epic tho yes I am biased

also vba has shitass visual options and if you post a maximized stretched resolution bilinear filtered screencap from it you’ve given me license to bully you

also mgba has real rewind for casual play

1 Like

WWIII has been started in the comments

mGBA vs VBA

Only one can win… or can peacefully coexist… fuck it, I choose war :smiling_imp:

Probably, VBA and mGBA are almost the same as an emulator.
Because if there is a problem as an emulator, the game will not work.
If the game works and can be played, then it is correct as an emulator.

On top of that, if there is a problem, I think it is undefined behavior.
In other words, when there is a bug in the code of your game, and it refers to memory that should not be referred to, or when it executes a strange undefined instruction, this is the behavior.

The mGBA aims to make this undefined behavior as close as possible to the actual game console,
The no$gba debugger, which aims to stop for debugger (although sometimes the debugger hangs because it cannot be stopped),
And the VBA that is neither of those.

In terms of test play, It best when the undefined behavior is stopped like the no$gba debugger.
The sooner it stops, the better, because if it doesn’t, you won’t know there is a bug.

The earlier the timing of the stop, the better.
For example, if it is stopped after the stack is exhausted, it cannot be debugged.
In this sense, I think no$gba debugger is superior.

I also appreciate the fact that it has the most decent debugger function among the three.
Compared to VBA and mGBA, which can set break points but have questionable continue behavior, the no$gba debugger works well.

However, when viewed as an emulator for playing games, the no$gba debugger is the worst.
This emulator is focused on debugging games, and I don’t think it thinks much about playing games.
And it is not open source.

This undefined behavior issue has been a popular topic in browsers.
As I’m sure you all know, it’s the IE vs mozilla(netscape) vs others war.
//In the end, KDE’s browser (Konqueror/KHTML), which was a weak force among others, became WebKit with the support of apple, and then became chrome by google, and won the world.

Browsers don’t work by magic, they work by code that interprets HTML, css, and javascript.
There is code written to interpret them, but undefined behaviors, such as “does it work if the value that is expected to be an integer is negative?” and other undefined behaviors caused a lot of trouble.

Of course, It’s your wrong HTML is bad, but from the user’s point of view, it’s not.
From the user’s point of view, it doesn’t matter if the code is right or wrong, they just want to see the website.
I think this is the same with emulators.
Since it is an emulator, it may be better to be faithful to the actual device, but the users don’t care about that, they just want to play the game.

6 Likes

Wait wait wait let’s talk about this. No$GBA? Have you used No$? It’s a necessary evil for wizardry, but it just… crashes sometimes. It’s poorly optimized. Its filter is bizarre. It doesn’t even handle blending properly. Its speedup is mediocre. Its error checking even considers vanilla code as undefined behavior. Furthermore, why would you have someone playtest on No$? It’s a development tool.

From a wizard’s perspective, whatever emulator you use (as long as it’s decent) doesn’t matter. If your decent emulator is having a problem with something that another emulator ignores, there’s likely a problem you need to address. I have never had someone report a bug on VBA that I wasn’t able to track down on mGBA.

https://www.duckstation.org/
https://www.duckstation.org/9k.png
The best PS1 emulator out there is what it is. Gotta download it via GitHub.
I tried it out with Medievil and Parasite Eve, and enhancements you can do can make numerous PS1 games look like PS2 games

Here’s a video showing what is possible if you’re interested.
Not gonna talk much more about this tho, don’t wanna derail the thread

most of vba’s problems stem from this part
image

When it encounters an invalid opcode, VBA will skip over it rather than crash. In practice, this means that something that is actually broken will work on VBA but not anywhere else. This leads to bugs being missed for longer than they otherwise would if tested with any other emulator. I am of the opinion that aiming for compatibility with real hardware is ideal since if it does work on a real GBA any emulator-specific issues are definitely the fault of the emulator and subsequently Not My Problem. In terms of emulator accuracy, mGBA is currently the most accurate emulator and has a dev that is present and works to improve accuracy all the time. In this vein, the GBA Test Suite was created to test emulator accuracy; on real hardware, every test it contains passes successfully, and the linked thread contains results on various versions of various emulators. Notably, there is no 100% accurate emulator, but mGBA is consistently the most accurate in almost every test (no$ beats it out in 2 tests very slightly, but no$ also crashes on other tests and is overall less accurate). As such, since flashing a ROM to a cart every time you want to test something is particularly tedious and expensive, mGBA is the best option for testing in terms of compatibility. And if you really don’t want to fix your hack that only works on VBA, mGBA has a VBA-mode setting that makes it inaccurately emulate things as VBA does :^P

15 Likes

The main advantage of mGBA over others is the stable support to GDB so that it can be intergrated into various of IDE seamlessly. Another advantage of mGBA is the cross platform support, so that developers on Mac or Linux can also use it.
NO$GBA focuses more on assembly level instead of source level. And it is closed source so others cannot contribute to it. If it is supported by a company/organization, I will be more confident on it. However it is individual so it will die like old VBA sooner or later.

I have confirmed that gdb continue works with the new version of mGBA.
Before you know it, it works properly.

However, I couldn’t set the break point well.
How do you set it up?

(gdb) target remote 127.0.0.1:2345
Remote debugging using 127.0.0.1:2345
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x000001f4 in ?? ()

We are Connected mGBA gdb server!

(gdb) bt
#0  0x000001f4 in ?? ()
#1  0x000000a4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

umm…

(gdb) break 0x8023F21
No symbol table is loaded.  Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (0x8023F21) pending.

I want to set a breakpoint on 8023F20 SupplyUsability.
For the time being, I specified 0x8023F21.

(gdb) info b
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   <PENDING>  0x8023F21

I confirmed that it was set.

(gdb) c
Continuing.

continue the game.
However, the break point did not activate. T_T

Program received signal SIGINT, Interrupt.
0x030073e0 in ?? ()
(gdb) break 0x8023F20
No symbol table is loaded.  Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (0x8023F20) pending.

This time I set a breakpoint at 0x8023F20 instead of 0x8023F21.

(gdb) c
Continuing.

continue the game.
However, the break point did not activate. T_T

Program received signal SIGINT, Interrupt.
0x030072c8 in ?? ()
(gdb) break *0x8023F20
Breakpoint 3 at 0x8023f20
(gdb) c
Continuing.

According to a stack overflow expert, *0x8023F20 is set as a pointer.

Program received signal SIGILL, Illegal instruction.
0x00000004 in ?? ()

oh my god.
The mGBA gdb server has crashed!

(gdb) bt
#0  0x00000004 in ?? ()
(gdb) c
Continuing.
warning: Remote failure reply: E07

He died completely.
Resetting with mGDB didn’t help and I had no choice but to restart mGDB.
I tried it 3 times but it didn’t work.

How do you set breakpoints?
I also want to set a read break point and a write break point, what should I do?

1 Like

It works fine for me.


gdb focuses more on source level instead of assembly level.
mgba has debug console for assembly level, which may be more suitable for your case.

It doesn’t work in my environment.
If you set a breakpoint, SIGILL will occur and it will not work.

Program received signal SIGILL, Illegal instruction.

devkit arm arm-none-eabi-gdb.exe
linux gdb

I’ve tried these two and get the same result.
MGBA gdb does not work in my environment.

mGDB 0.9.3 win32

Have you loaded it?

As much as I dislike these kinds of conversations, this kind of thread isn’t going to help things.
If anything testing on multiple emulators should be the norm.

As per VBA’a age, I’ve had exactly one rom hack run jank on it, Permafrost’s Deity Device. And shockingly thats it, granted i usually then move them to my 3ds and either run an GBA bootstrap or (explicitly for only SGW) Mgba.

It works just fine. You may need to update your devkitarm first.

Agreed, feels like a dick measuring contest

1 Like

If there is no elf symbol, it seems to specify *0x8023F20 like a pointer.
However, if you do so, signal SIGINT will occur and it will not work.

I’m in trouble because the elf symbol of FE8J doesn’t exist.

1 Like

Of course, in order for GDB to debug your application, you need to locate the compiled ELF format version of it (which includes needed debug symbols). If you compile it from source code, it is generated during linking. If you don’t have it, it is not what GDB for. I declared that at first.

BTW if you use EA, you cannot debug using GDB either because EA doesn’t generate ELF like a normal linker does.

I am currently making debug symbols for no$gba, but I know that generating elf symbols for gdb is an issue that I need to consider.
It would be easier if there are debug symbols that gdb can read and can be made in text format, do you know of any?
Reading elf symbols is also done by FEBuilderGBA and lyn, so I’m sure it can be generated, but the problem with the binary format is that it takes a lot of time to implement.

However, I think no$gba is easier at this point, unless you are writing in an advanced language like C.
In C, a line is converted into multiple asms, and there are variable assignments, so I think gdb has an advantage in dealing with that.

If gdb works, it should also be possible to connect to the IDE (Visual Studio).
// You may have already done this.

I guess the normal development style of using an IDE, setting breakpoints and debugging will be available for rom hack.
That’s one of the things that FEBuilderGBA wanted to do but couldn’t achieve.
Since we don’t know the location of the r15 and r13 registers, FEBuilderGBA is not able to retrieve and display this information.
If backtrace(bt) could be used, it would be easier to go back through the history from the hangup point.

It only accepts elf format afaik.

Yes, I write in C in most cases.

Yes, I showed that in discord server 5 years ago.


It works with any IDE with GDB/LLDB support, not only Visual Studio. I have already wrote it in this thread.
GBA Hacking in C - Documentation - Fire Emblem Universe (feuniverse.us)

Yes, it works fine.

mGBA’s debug console supports backtrace without gdb. Read this for more details.