Development: Extensible GBA Emulator

Plus if everything needs to be compiled, that cuts off a certain amount of freedom for the user I would say. Scripts on the other hand could easily be tweaked to individual needs and improved by many.

Touched said:

It wouldn't be as convenient. Right now, I can create wrappers for any C function or a pointer to an arbitrary struct or whatever. I can control the emulator's current state by embedding Python. The alternative you speak of is a compiled module, which wouldn't make much sense given multiple instances of the emulator, and exposing memory blocks would be much more difficult.

Click to expand...

Yes, but if the extension portion of the code is modularized, then you could write libraries for other languages such as Lua and even Java if properly wrapped, allowing choice of language at the slight cost of full control over the application. However, if you expose enough parts of the program, the disadvantage isn't as evident and you gain a lot of possibilities. A project very similar to this one by knizz was made which used Lua. The difference however was that it exposed the methods into the Lua manually, but enough was exposed that you could do a lot of powerful things. Obviously this is still your project but it was just a thought I had.

Shiny Quagsire said:

Yes, but if the extension portion of the code is modularized, then you could write libraries for other languages such as Lua and even Java if properly wrapped, allowing choice of language at the slight cost of full control over the application. However, if you expose enough parts of the program, the disadvantage isn't as evident and you gain a lot of possibilities. A project very similar to this one by knizz was made which used Lua. The difference however was that it exposed the methods into the Lua manually, but enough was exposed that you could do a lot of powerful things. Obviously this is still your project but it was just a thought I had.

Click to expand...

What I was planning to do was create a generic wrapper for the plug-in module, which would include things like the loading of the module, etc. Thus, if someone wanted to change the language that the module was loaded in, all they'd have to do would be rewrite this module. You'd have to know C in order to do this anyway, it'd just be more convenient. However, I do not see why you'd want to use Java. Lua or Ruby I could understand, but if you're using Java, you might as well just use C++? I'm going to try to make this project as modular as possible though. Thanks for that link. I'll look into the source to see how knizz embedded Lua. However, I'm of the opinion that Python is a much more versatile and succinct language than Lua.

In an attempt to acquiesce to requests here, I've create a C++ library which will form the back-end of the new Python-based emulator. This library contains all the core functions necessary to implement your own emulator, in whatever language you desire (as long as you write the appropriate bindings). I shall attempt to make the code as minimal and as fully functional as possible. Write now, a number of (critical) things do not work properly. I've disabled save states, because I'd like to make them saved to the RAM, rather than a file on the disk. This will be to allow you to decide what you want to do with the file. However, I've modified the processor core to allow for better debugging features. You can now set read/write breakpoints on any address you desire. Anyway, this is basically just a taster. I'll commit more changes soon. Now that I've forked VBA-M's source, I'll be free to edit as much of the source as I please - this is what was slowing my progress down before.

The source can be found on my GitHub repository. I'll update the main post with a link, and hopefully with a sample application. Otherwise, you can look at the test application in the source. It doesn't do much, but it's a proof of concept.

Touched said:

As a GBA hacker, an emulator is one of our fundamental tools. Although the options we have are stable, there is no all-in-one solution. You have to resort to an SDL port of VBA to debug ASM, for example. However, there is no reason to think that an emulator can't be extended like any other tool.

Click to expand...

No one uses NO$GBA apparently XD
Also, you talk about the SDL version of VBA like it's a bad thing.

NearEDGE said:

No one uses NO$GBA apparently XD
Also, you talk about the SDL version of VBA like it's a bad thing.

Click to expand...

NO$GBA is closed-source and Windows only, so I think that plays a major part. I wish it weren't - I'd love to know how they got the solar sensor working. I don't mean to imply that it's bad. I just meant that there are too many ports, and even VBA-M doesn't succeed in merging them all. I'm slowly working on upgrading the emulator - you can see that I've embedded it in my upcoming script editor - that's going to have many Pokemon specific features, such as warping and script debugging.

At the same time, NO$GBA is literally two add-ons from being perfect(GBA IR Adapter and GBA WiFi Adapter) and runs flawlessly on just about any windows emulator that supports OpenGL.
Martin Korth deserves a lot of credit for having put 12 years of work into NO$

Also, I'll argue that it isn't necessarily a good idea to combine a script editor with an active debugger. The scripts should be edited cold, and assembly should be debugged actively. A big reason for this is that scripts don't adhere to exactly the same rules as machine code and have to be interpreted by the game for use. You'll have to either compromise debugging power or compromise safety to do it.

NearEDGE said:

At the same time, NO$GBA is literally two add-ons from being perfect(GBA IR Adapter and GBA WiFi Adapter) and runs flawlessly on just about any windows emulator that supports OpenGL.
Martin Korth deserves a lot of credit for having put 12 years of work into NO$

Also, I'll argue that it isn't necessarily a good idea to combine a script editor with an active debugger. The scripts should be edited cold, and assembly should be debugged actively. A big reason for this is that scripts don't adhere to exactly the same rules as machine code and have to be interpreted by the game for use. You'll have to either compromise debugging power or compromise safety to do it.

Click to expand...

Yes, he does. I just wish he'd open source that work, and have a paid license for corporate work. You can have multiple debuggers you know. I have a limited debugger for scripts, which steps per command, and a more in-depth debugger for ASM. I don't see the problem in doing that. I'm well aware that scripts and machine code aren't equivalent - but neither is any other higher level language, and they all have debuggers. Debugging is just another abstraction...

Touched said:

Yes, he does. I just wish he'd open source that work, and have a paid license for corporate work. You can have multiple debuggers you know. I have a limited debugger for scripts, which steps per command, and a more in-depth debugger for ASM. I don't see the problem in doing that. I'm well aware that scripts and machine code aren't equivalent - but neither is any other higher level language, and they all have debuggers. Debugging is just another abstraction...

Click to expand...

He always had a paid license for corporate work, not that it really matters at this point since he released NO$GBA as 100% Freeware back in July. My issue with script debugging is that pointers and variables are not handled the same way that real scripting languages are. The script used in pokemon is less of a scripting language and more of a collection of subroutines(Which is probably what it is) which are called using constants. What I meant earlier about safety is that in order to debug the script you have to edit the script which will mean juggling all of those constant references to addresses either manually or automatically. The problem with either method is that it's highly likely to screw up. I say scripts should be edited cold because it takes time to change a script, edit references to that script, edit contiguous memory, whateves, and those things should be done manually. For the additional trouble it has the potential to cause, you're better off making a save state and reloading the ROM.

EDIT: What I'm trying to say is, there are many layers of abstraction missing between this and other scripting languages that have to be addressed first because the scripting language itself is not a high level language.

I meant like a corporate open source license, as in its free if you also make open source software from it, but if you commercialise it, then you have to pay. It's not that advanced a debugger. It simply allows you to double check logic and see what's in the memory banks. I'm not trying to force the "language" to be something it's not. It just makes the black box that is scripting slightly less opaque. I guess to call it a debugger is a bit of a misnomer. It's just a collection of tools that make testing scripts less tedious.

How do you find scripting tedious? Like, what about it specifically I mean?
With the exception of not being able to create variables, I find it to be an excessively simple and straight forward way to get things done.