doesnt load on 2.x

about time :D. i hope it works on 2.6 :)

YEAHHH i've been waiting for a good gba emu for ages! thank zx!

it's very good for an initial release, a bit slow but beeing zx-81 the good coder he is, this will make rapid progress for sure. thanks zx-81.

i get a white box whenever i load a rom. anyone else get it?

Man... THIS ROCK!!!

FINALLY SHINING FORCE ROTDD ON MY PSP!!!

I CAN'T WAIT FOR FULL SPEED!

Keep up the good work Zx-81.

Just out of curiousity, exactly what is it that makes this version so much better than the other ports? I've looked over the source and I haven't seen any optimizations to the actual critical portions of the emulator.



I hate to break it to you all, but unless someone rewrites the CPU core completely a VBA port to PSP will probably not achieve full CPU emulation speed for a majority of games, and unless someone rewrites the video rendering functions a VBA port will never achieve low or no frameskip. And if the CPU isn't being emulated full speed then sound is just going to be awful no matter what (the direct sound channels, anyway).



Don't mean to sound too negative, but I've looked through VBA's source enough and it just isn't an efficient emulator. The CPU core has had some strong brute force style optimizations thrown at it, but the result is something rather huge (not cache friendly for a low cache machine like PSP) and the more important optimizations are x86 only. At the same time it misses some somewhat obvious optimizations that involve more than expanding tables. It also spends a lot of extra cycles maintaining more accuracy than it really needs to.



The renderer is much worse off, it's just very slow. It is done in a way that very literally models the GBA's video hardware and it's quite accurate but there are a lot of potential optimizations it misses (okay, some at the slight expense of accuracy), even some pretty simple ones.



Don't get me wrong, I'm not saying VBA is a bad emulator, quite the contrary, obviously it's the best GBA emulator available for desktop computers. However, the devs never really bothered making it super fast because I suppose there was never enough of a reason to, and doing so quickly becomes a serious headache. The emulator, like No$GBA, was also made with developers in mind, meaning it has to play to certain rules to provide higher accuracy than is necessary to plau most commercial ROMs.



I don't want to take anything away from ZX-81's accomplishments here but I also don't see anywhere where he gives any indication that this will get any faster. In fact, given that he says he tried almost pointless things like converting the code from .cpp to .c expecting it to actually substantially improve performance, I'd say that he doesn't have any real plans for making this faster now, or any real hope. Once again, props go to PSPUpdates for instilling false hope and expectations within their naive readers.



*puts on flame proof suit*

#75, I'm not gonna flame you, since you gave constructive cristicism. Since you do sound like you know much programming and coding, you should take a shot behind the emulator making perspectives.

Not saying it's not possible, just that a lot would have to be rewritten, to the point where the important parts of the emulator probably wouldn't resemble VBA anymore. I don't know who said things like this about SNES9xTYL, but this is in a whole different league. Just compare the minimum requirements of SNES9x on a PC with those of VBA.



The ME probably wouldn't be that much help because the direct sound channels in GBA require relatively high bandwidth communication between the CPU and the sound chip (it's stream), and most of the processing is done in the CPU, so the actual overhead for the digital sound emulation isn't that much. You could do the GBC audio channels on the ME, but that too wouldn't give you much benefit because it doesn't take much processing to emulate them. You might be able to do video on a separate processor, but the ME can't access VRAM, so to behave efficiently you'd probably have to put the main CPU execution on the ME and the video on the main processor. This is good for when the video isn't changing very much, however, if it's changing rapidly this would slow things down tremendously. The synchronization would also have to be pretty tight, to the scanline. I don't really know yet what kind of potential is there, but I do know that it wouldn't necessarily be easy to up and move this kind of code around.

DOWNGRADE AND USE DEVHOOK!



There's absolutely nothing to lose.



And here's what you gain:



-All homebrew

-Easy to use homebrew

-All 2.0 and 2.5 features

Zx-81: How did going from C++ to C give you 20% speed? I'm skeptical that it wasn't something else that was doing it. VBA uses almost no C++ features to begin with, especially not in speed critical areas. From the looks of things most of what you did was unmangled some names so could you please explain to me how that gained you so much speed, when you're using GCC both before and after?



As far as the CPU emulation goes, even if you're a master at MIPS ASM you will probably only gain so much, MIPS doesn't even have flags. Now mind you, VBA's flags generation code is far from optimal (hint: you can generate all four in six instructions). Just the same, there's still a huge overhead in decoding for ARM. Interpretive emulation isn't the way to go.



To everyone else; No, I'm not going to work on a VBA port. I have good reasons that may or may not become clear sooner or later.

Translating c++ in C, permits to use gcc instead of g++, and to succeed to compile this emulator using better optimization ;) ... Even if you don't use OO programming, class and templates, c++ will be always equal or slower than pure C, because there are many implicit initializations and run-time checks that are not done in pure C ...



Zx.

@Exophase: You did point out some issues (From what i know of programing i know a lot but not enough to actully program hoebrew) but like most ppl said here why not help with the project.

You don't have to code anything just give feed back to zx-81 im sure he would appriciate it, npt tp say the the whole psp community would finally have a GBA Emu running at Full Speed.

Well in the end its your choice to help or not but i stongly think you would be a good asset to this project and that zx-81 would apriciate your help.



@zx-81: Good job man don't give up im sure that you'll get this Emu up and running at FullSpeed real soon, and im sure that everyone agrees with the fact that this a great Emu and runs better then the other ones.

Thx for this one a keep up the good work!!