Elektranox
Well-Known Member
- Joined
- Dec 3, 2005
- Messages
- 1,805
- Age
- 34
- Location
- Oldenburg, Germany, Earth
- Website
- elektranox.dyndns.org
any news?
GP2X Gba Emu And Static Translation
- Thread starter A_SN
- Start date
Elektranox posted on Sep 2 2006 at 11:45 PM said:
Well,
Ive been pretty busy at work but Ive passed my eyes through the graphic code when I realized it was all in C++
Im not an expert at C++, if it was pure C I could be of help but not in this case unfortunally.I don't know about TKF15H's progress... any news?
Regards,
bitcoder
Last edited by a moderator:
Well, I haven't coded anything permanent (just test code, and it ain't done), but I've been looking at the GPU code also. Trying to see how viable/beneficial it is to cache transformed images during the interpretation + code output stage and then relying on that cache durin the compiled code execution stage.
The thing is that to build the cache, some way of identifying the image must be used, most likely a hash of the image. But is it possible to hash image data quickly enough to be significantly faster than just rotating the the image on run time? Is the cache going to be so big with certain games that it may cause space problems?
The thing is that to build the cache, some way of identifying the image must be used, most likely a hash of the image. But is it possible to hash image data quickly enough to be significantly faster than just rotating the the image on run time? Is the cache going to be so big with certain games that it may cause space problems?
Elektranox
Well-Known Member
- Joined
- Dec 3, 2005
- Messages
- 1,805
- Age
- 34
- Location
- Oldenburg, Germany, Earth
- Website
- elektranox.dyndns.org
mh it would be nice if you work with the sourceforge CVS
Yeah I will, soon as I get something worth uploading (around the same time as the first beta).
Right now we're looking for some place to live in, and once that's found our stuff is going to get sent over by truck (my computer being in there somewhere). I WANT MY PC!!
Right now we're looking for some place to live in, and once that's found our stuff is going to get sent over by truck (my computer being in there somewhere). I WANT MY PC!!
ryosaeba
Certified Guru
TKF15H posted on Sep 10 2006 at 07:49 PM said:Yeah I will, soon as I get something worth uploading (around the same time as the first beta).
Right now we're looking for some place to live in, and once that's found our stuff is going to get sent over by truck (my computer being in there somewhere). I WANT MY PC!!
I hope you get your PC soon
I'm looking forward to any progress on a gba emulator. It's the most important missing playable emulator for me.
I'd be willing to pay for a playable one, and be sure to receive a donation as soon as there will be some results.
Last edited by a moderator:
wipeout2000
Member
Yea definitely, I'm really looking forward to this emulator. You can count on a donation from me in the future. (if it works better than the current gba emulator )
)gmiller1018
Member
Not sure where this all is but I wanted to put a note here on the SDL version of the Visual Boy Advance emulator that I had to fix for the class I teach using the GBA as an example of an imbedded ARM achitecture. The SDL version that were out there for source code debugging were crippled in many ways. In trying to figure out what was broken I put code into the SDL version that would display the code as it executed and fix the code that allowed gdb to connect to it for source code debugging. I recompiled the code with Visual Stuid 2005 and have been using it for a while with no problems. Now this probably does not help much here because this only shows the ARM assembly as it executes but there may be some use that can be made out of the code. I will put a like together that post at the source code so if anyone needs it they can have it. If someone is interested in the running code for XP I can post a link to that as well.
Good luck TKF15H ...
Good luck TKF15H ...
Exophase
Nothing good will ever come of Exophase.
I wanted to through my two cents on this, if no one minds.
Static translation in general runs into the age old problem of indeterminate (indirect) branches. These are encountered all the time in normal code, the two most common places are switches (jump tables) and returns (usually of the form bx lr). They also happen often in interrupt handlers and in the BIOS.. IE, things that most games use. So, I see that the solution here is to bail out to VBA if the addresses aren't found. But you're not going to find most of those addresses in the first place, so you'll quickly run back to the interpreter and back to where you started. I just wanted to make clear that indirect branches happen all the time in ARM code.
It was mentioned that you can get around this by generating code as the game is played. But that would require that all compatible games have all of their code paths exhausted, which is something you won't be able to guarantee. Just imagine playing a game and having it crash halfway through because the user did something the tester didn't. Granted, that could (and will) happen anyway, but this is the kind of insidious thing that would probably get you on virtually ever game. Also, you can (and in fact do!) get collisions with branch targets to RAM.
For those wondering about self-modifying code - virtually every game I've encountered will in fact copy code to RAM and execute it there. Determining this completely statically (at run time) will be difficult to impossible, not to mention doing anything to compensate for it. There are also games that use actual bonafide self-modifying code, in other words, they will overwrite specific instructions with their own at runtime, and they often do it several times within a single video frame. See Camelot's games for good examples of this (and many other things that are a pain to emulate).
.. it's a little late to say something like this, but I think your approach to producing code, that is, working on VBA's source one opcode at a time, was extremely time in-efficient and will be far more prone to error than it should have been. The reason why I say this is because VBA's interpreters are pretty sloppy and hand expanded/optimized. In other words, they're probably at least 16x more code than what you'd need, to benefit decoding speed. But since you're doing it statically this speed gain means absolutely nothing to you. I doubt you'd want to start over, but you'd probably end up with a far more maintainable and debuggable code base if you either started from scratch or translated a lighter weight or more macro oriented interpreter (or you could use gpSP's cpu_threaded.c as a base.. it is much more organized and easier to work with than cpu.c but there might be accuracy problems as compared to VBA, and it doesn't implement a couple things no GBA game uses).
Now, about the approach of going from ARM -> C -> ARM.. I can see it having some pros and cons. First, the obvious advantages.. well, you get the compiler's expensive optimizations. A lot of these will be a waste because the code will have already been optimized in this way, but I can think of at least three important things that it'd give you that you won't have to do yourself:
- very efficient register allocation
- liveness analysis (redundant assignment elimination), which will especially help with all the redundant flag elimination.
- constant propogation/constant folding
You get these things for free which is of course very nice. And it's more portable, which is always nice too. However, there are cons:
- Look back to my first paragraph; you could have it fall back on a dynamic recompiler for things that are missed, but in this case it's impractical because you'd need GCC on the GP2X (and it'd pause the game very noticeably)
- The compiler probably won't be able to map flag generation natively which is something you could do very well and easily in ARM -> ARM.
- Even though compilers have good register allocation they're not necessarily terribly agressive with using as many registers as they can.
- Requires a playthrough beforehand, of course...
Okay, one last thing. As was mentioned a huge bottleneck is video rendering. Of course you could shrug it off and just let the thing frameskip like crazy, and this will be okay, at first. But let me tell you, VBA's video renderer is terribly inefficient. And trying to go to hardware acceleration off the bat will make your life miserable! Not only will it kill portability but it's not totally possible anyway. It just doesn't map well (I could go indepth as to why but for now take my word for it). You'll have to do a ton of higher level transformations to even make it partially work.
Software renderers are just very underrated. gpSP uses a 100% software renderer and it really doesn't do that badly, some games run fine at 0 frameskip. In fact, it even competes pretty decently with the hybrid software/hardware rendering of SNES9x TYL. Pixel for pixel GBA can be a LOT more intensive than SNES, rendering-wise, although SNES just has more overall pixels (about 50% more). I'd say, maybe think about this later, don't go for it at first. Of course you can use VBA's renderer at first. But if you're interested gpSP has a pretty portable renderer, if you use SDL it should be possible to drop it in (works fine on PC's with SDL). It's not 100% accurate and it's missing some things but it's good enough for most games.
Okay, I think I've done enough shameless self promotion in this thread >_> Good luck with this project, it all sounds very interesting.
Static translation in general runs into the age old problem of indeterminate (indirect) branches. These are encountered all the time in normal code, the two most common places are switches (jump tables) and returns (usually of the form bx lr). They also happen often in interrupt handlers and in the BIOS.. IE, things that most games use. So, I see that the solution here is to bail out to VBA if the addresses aren't found. But you're not going to find most of those addresses in the first place, so you'll quickly run back to the interpreter and back to where you started. I just wanted to make clear that indirect branches happen all the time in ARM code.
It was mentioned that you can get around this by generating code as the game is played. But that would require that all compatible games have all of their code paths exhausted, which is something you won't be able to guarantee. Just imagine playing a game and having it crash halfway through because the user did something the tester didn't. Granted, that could (and will) happen anyway, but this is the kind of insidious thing that would probably get you on virtually ever game. Also, you can (and in fact do!) get collisions with branch targets to RAM.
For those wondering about self-modifying code - virtually every game I've encountered will in fact copy code to RAM and execute it there. Determining this completely statically (at run time) will be difficult to impossible, not to mention doing anything to compensate for it. There are also games that use actual bonafide self-modifying code, in other words, they will overwrite specific instructions with their own at runtime, and they often do it several times within a single video frame. See Camelot's games for good examples of this (and many other things that are a pain to emulate).
.. it's a little late to say something like this, but I think your approach to producing code, that is, working on VBA's source one opcode at a time, was extremely time in-efficient and will be far more prone to error than it should have been. The reason why I say this is because VBA's interpreters are pretty sloppy and hand expanded/optimized. In other words, they're probably at least 16x more code than what you'd need, to benefit decoding speed. But since you're doing it statically this speed gain means absolutely nothing to you. I doubt you'd want to start over, but you'd probably end up with a far more maintainable and debuggable code base if you either started from scratch or translated a lighter weight or more macro oriented interpreter (or you could use gpSP's cpu_threaded.c as a base.. it is much more organized and easier to work with than cpu.c but there might be accuracy problems as compared to VBA, and it doesn't implement a couple things no GBA game uses).
Now, about the approach of going from ARM -> C -> ARM.. I can see it having some pros and cons. First, the obvious advantages.. well, you get the compiler's expensive optimizations. A lot of these will be a waste because the code will have already been optimized in this way, but I can think of at least three important things that it'd give you that you won't have to do yourself:
- very efficient register allocation
- liveness analysis (redundant assignment elimination), which will especially help with all the redundant flag elimination.
- constant propogation/constant folding
You get these things for free which is of course very nice. And it's more portable, which is always nice too. However, there are cons:
- Look back to my first paragraph; you could have it fall back on a dynamic recompiler for things that are missed, but in this case it's impractical because you'd need GCC on the GP2X (and it'd pause the game very noticeably)
- The compiler probably won't be able to map flag generation natively which is something you could do very well and easily in ARM -> ARM.
- Even though compilers have good register allocation they're not necessarily terribly agressive with using as many registers as they can.
- Requires a playthrough beforehand, of course...
Okay, one last thing. As was mentioned a huge bottleneck is video rendering. Of course you could shrug it off and just let the thing frameskip like crazy, and this will be okay, at first. But let me tell you, VBA's video renderer is terribly inefficient. And trying to go to hardware acceleration off the bat will make your life miserable! Not only will it kill portability but it's not totally possible anyway. It just doesn't map well (I could go indepth as to why but for now take my word for it). You'll have to do a ton of higher level transformations to even make it partially work.
Software renderers are just very underrated. gpSP uses a 100% software renderer and it really doesn't do that badly, some games run fine at 0 frameskip. In fact, it even competes pretty decently with the hybrid software/hardware rendering of SNES9x TYL. Pixel for pixel GBA can be a LOT more intensive than SNES, rendering-wise, although SNES just has more overall pixels (about 50% more). I'd say, maybe think about this later, don't go for it at first. Of course you can use VBA's renderer at first. But if you're interested gpSP has a pretty portable renderer, if you use SDL it should be possible to drop it in (works fine on PC's with SDL). It's not 100% accurate and it's missing some things but it's good enough for most games.
Okay, I think I've done enough shameless self promotion in this thread >_> Good luck with this project, it all sounds very interesting.
Epicenter
Well-Known Member
In response to your comments about software renderers-- for something like the GBA, you'll have a lot of difficulty. Sure, VBA's renderer is garbage. But it runs slowly on PCs with >2 GHz Athlon 64 processors and GeForce 6-series video cards, so you know something is more deeply wrong than just 'it's slow'. Assuredly, SquidgeSNES' slowdown issues stemming from graphics don't come from being a flat-out bad renderer at all. Sure, it's not as efficient as it could be if it were pure ASM, but some things like transparency just won't work at acceptable speed without some sort of hardware assistance, with the additional complexity of the SNES still to emulate. While a software renderer may work just fine, when it isn't a terrible piece of shit, on a platform like the aforementioned A64/GeForce 6 combo .. on a portable system like this, it isn't the right route to take for any sort of tasking emulation.
iignotus
The one and only
People say that everywhere lol.Yod4z posted on Sep 29 2006 at 04:13 PM said:
Last edited by a moderator:
Epicenter
Well-Known Member
Quit acting like an asshole. He's a developer, not your fucking servant. There's not a button on him you push and emulators come out. If he wants to post his progress before he has a program to show, that's to your benefit. If you don't want to listen, fine. But don't come in here bitching that he hasn't sent you build shortly after starting an ambitious project.o0o0o posted on Sep 29 2006 at 11:49 AM said:
Last edited by a moderator:
Epicenter posted on Sep 29 2006 at 03:06 PM said:
I would absolutely love to be proven wrong. I develop software as well, just not for the GP, since I barely have time to even play it. So I do fully understand what kind of dedication is involved. However, I've also seen nothing to indicate this project has gotten anywhere or has any intention of going anywhere. I mean, he's been without a house and computer for how many months now? I'm just calling it as I see it, sorry if that offends you personally. Inflamatory, maybe. Bitching, no. Either way, I guess it at least it provokes some conversation.
Last edited by a moderator:
KillerStefan
Still Fresh
I WAS STUPID AND POSTED LINK TO ROMS WHAT IS AGAINST THIS SITE RULES AND NOW I AM BANNED.
Epicenter
Well-Known Member
The point is you come across as a total ingrate, and it doesn't really do anyone any good to hear you say, "hey, there's no emulator yet". I'm sure he didn't forsee 'real life problems' getting in the way and I'm sure his #1 priority is not making sure GP32X patrons are pleased, it's tending to his personal affairs and if he has time, doing software development at his leisure that doesn't earn him a cent like this project.o0o0o posted on Sep 29 2006 at 05:30 PM said:
Last edited by a moderator:
iignotus
The one and only
Not only did I have to adblock your entire signature, but you're not allowed to post rom links here, not to mention spam your site. So stop all that.KillerStefan posted on Sep 29 2006 at 09:14 PM said:Need GBA roms? Please visit my site: xxxxxxxxx for a very large collection of roms. We have now 14.000+ roms but we keep on going
Last edited by a moderator:
Epicenter
Well-Known Member
He's definitely breaking some rules with that link and his sig is quite large (if he got rid of the giant goddamn Link picture it'd be fine). But that's a hell of a pile of ROMs, I'll give him credit for that. I'm going to be setting a mass-downloader on some sections of this site tonight, that's for sure. Wait, you didn't hear that. I didn't say anything. I was never here.
EDIT: What the fuck? Ecco and Gunstar Heroes are completely omitted from his Genesis section. That's like making a sandwich and forgetting the bread. Wow.
EDIT: What the fuck? Ecco and Gunstar Heroes are completely omitted from his Genesis section. That's like making a sandwich and forgetting the bread. Wow.