GP2X Gba Emu And Static Translation


Very nice to hear that the opcodes seem to be running without any errors. Fantastic work!
Moments like the situation you described are the things I hate about coding. Good that you've worked it out, else it could have been very frustrating.

Cheers,
Dave
 
TKF15H posted on Jul 19 2006 at 12:59 AM said:
While this may look like an odd step in the opposite direction, it is the biggest part of recompiling GBA code. This done, I have to come up with an efficient way to dump the output buffer to a file, ignoring what has been output already. This will make the interpretor a bit faster when it runs code it has already been over once, but really slow on the first time.

Are you emulating on a pc to create the .c file?

David
 
Last edited by a moderator:
dwelch posted on Jul 23 2006 at 03:34 AM said:
TKF15H posted on Jul 19 2006 at 12:59 AM said:
While this may look like an odd step in the opposite direction, it is the biggest part of recompiling GBA code. This done, I have to come up with an efficient way to dump the output buffer to a file, ignoring what has been output already. This will make the interpretor a bit faster when it runs code it has already been over once, but really slow on the first time.

Are you emulating on a pc to create the .c file?

David

From what I understood, it seems to be all done on a GP2X
 
Last edited by a moderator:
A_SN posted on Jul 22 2006 at 10:01 PM said:
dwelch posted on Jul 23 2006 at 03:34 AM said:
TKF15H posted on Jul 19 2006 at 12:59 AM said:
While this may look like an odd step in the opposite direction, it is the biggest part of recompiling GBA code. This done, I have to come up with an efficient way to dump the output buffer to a file, ignoring what has been output already. This will make the interpretor a bit faster when it runs code it has already been over once, but really slow on the first time.

Are you emulating on a pc to create the .c file?

David

From what I understood, it seems to be all done on a GP2X

Thats what I understood too, just sounds painful that way. But I guess he already had the emulator working on the gp2x. I assume the source he posted was pre-easy 8-battery bug?
 
Last edited by a moderator:
dwelch posted on Jul 22 2006 at 10:34 PM said:
TKF15H posted on Jul 19 2006 at 12:59 AM said:
While this may look like an odd step in the opposite direction, it is the biggest part of recompiling GBA code. This done, I have to come up with an efficient way to dump the output buffer to a file, ignoring what has been output already. This will make the interpretor a bit faster when it runs code it has already been over once, but really slow on the first time.

Are you emulating on a pc to create the .c file?

David

It can be done on either. The code is cross-platform so it's just a matter of building it for the PC then getting the output and compiling/linking with the GP2X version.

I assume the source he posted was pre-easy 8-battery bug?
The code on sourceforge? If so, yes, but the bug was in another file (GBA.cpp).

btw, sorry about the lack of updates. The day before yesterday I managed to buy a mother-board for my PC so I could finally migrate from my ol' AthlonXP1800+ to an Athlon64 3500+. With that I had to reinstall windows, SP2, Linux, gp2xDevkit, Visual Studio, Platform SDK, and tonnes of new games to try out the hardware!! :D
 
Last edited by a moderator:
TKF15H posted on Jul 23 2006 at 12:55 AM said:
btw, sorry about the lack of updates. The day before yesterday I managed to buy a mother-board for my PC so

Are you kidding. This is supposed to be fun, not a job. No need to apologize for having fun doing something else. This would be a good time to take that favorite GBA rom and actually play it in your gba for a while.
 
Last edited by a moderator:
an athlon64 3500+ would be such overkill for that favorite GBA rom. go play some counterstrike! ;)
 
Last edited by a moderator:
dwelch posted on Jul 26 2006 at 07:42 PM said:
A_SN posted on Jul 18 2006 at 02:03 PM said:
TKF15H posted on Jul 18 2006 at 07:54 PM said:
whoa, it was just a curious looksie, no need to go through all that work right now. o_O

lol, oops, too late :) i was bored anyways

then i'm stopping, here's what i've done so far http://www.yousendit.com/transfer.php?acti...35aa30a5e6f4c7d

Is that link still valid? I dont see any files...

no, expires after a week. want it?
 
Last edited by a moderator:
A_SN posted on Jul 26 2006 at 07:35 PM said:
dwelch posted on Jul 26 2006 at 07:42 PM said:
Is that link still valid? I dont see any files...

no, expires after a week. want it?

I found it...I had downloaded it..
 
Last edited by a moderator:
There ain't gonna be much news for the time being. As I had mentioned earlier, I'm moving to another state this week so not much coding will be done. When I get there, I'll be staying at some lady's place for about a month, and I have no idea if she has a PC/internet (NOOOOO!!!! :p). I will however, take a 286 laptop ( XD ) to work on, so I won't be idle. I almost went and did that USB mod to my 2x today, as I'd rather work on my GP2X than on a 286, but I couldn't due to not having all the parts necessary. Couldn't find that 68uF capacitor nor the USB host plug. >_<
 
TKF15H posted on Jul 27 2006 at 03:21 AM said:
There ain't gonna be much news for the time being. As I had mentioned earlier, I'm moving to another state this week so not much coding will be done. When I get there, I'll be staying at some lady's place for about a month, and I have no idea if she has a PC/internet (NOOOOO!!!! :p). I will however, take a 286 laptop ( XD ) to work on, so I won't be idle. I almost went and did that USB mod to my 2x today, as I'd rather work on my GP2X than on a 286, but I couldn't due to not having all the parts necessary. Couldn't find that 68uF capacitor nor the USB host plug. >_<

There, I translated a few more interesting files http://www.yousendit.com/transfer.php?acti...42744604FC9438A seems like no other file is worthy of being translated
 
Last edited by a moderator:
Heya TKF15H,

I too agree static recompilation sounds like the way to go, and wish you the best of luck.

As to not take over a thread with a semi-offtopic request, if someone could PM me and either explain or link me to a static recompilation article, that would be great.

When I considered static recompilation, one reason I had it in my head that it wouldn't be feasible for the PSX as a 600MB game would become considerably larger after being translated. TKF15H, dwelch, or anyone else care to say what size increase in outputted ROMs are average for GBA games, and what I could expect on my end of things?

Thanks, and good luck TKF15H. Glad to see you giving this a chance. Others are too afraid to play with the big Ninny. ;)
 
Thanks! :D

one reason I had it in my head that it wouldn't be feasible for the PSX as a 600MB game would become considerably larger after being translated
Only if you were to recompile data. The actual executables' size rarely goes over 1MB, right?

I had a link to a tutorial somewhere... I had to nuke windows and I lost the bookmark in the process, I'll go look for it.
 
zodttd posted on Jul 29 2006 at 06:28 PM said:
As to not take over a thread with a semi-offtopic request, if someone could PM me and either explain or link me to a static recompilation article, that would be great.

When I considered static recompilation, one reason I had it in my head that it wouldn't be feasible for the PSX as a 600MB game would become considerably larger after being translated. TKF15H, dwelch, or anyone else care to say what size increase in outputted ROMs are average for GBA games, and what I could expect on my end of things?

http://en.wikipedia.org/wiki/Binary_translation

I started to write my usual very long response, and will spare you unless you are interested. The above is a good place to start. I was in contact with Graham Toal and owe him a lot for pulling me into SBT and teaching me and/or bouncing ideas off of me (I think I helped him with stuff too, I dont know). His SBT HOWTO is linked on the above page. I wouldnt use it as a this is how you have to do it. I think translation is an art form, the skill or art is in deciding that this platform or specific game needs to be done this way. To elimate human error in my hundreds of hours of boring typing translations I will compare my output to an emulator this way. In the case of gba to gp2x, the door opens wider because you can actually execute some or all of the code on the gp2x (you have to trap the i/o with an mmu though or translate that out ahead of time).

With this thread and time to think about it I think the dynamic translation that is going on is the right approach. I am dying to see the code/result, but we all have to wait...

Your other question, my guess is you have to have the whole source binary in your translation. Programs created by compilers as well as assembly programmers are going to do things like this:
r3 = [r1]
or this
r3 = [r1+r2]
This being pseudo code meaning some address is in register r1, r3 gets the value stored at the address stored in r1. Unless the code looks like this:
r1 = 0x8000;
r3 = [r1]
You are probably not going to have a translator smart enough to figure out all the addresses in memory a binary is going to need. There will be constants and worse, variables, stored in the memory space of the source platform. You will basically have to emulate that, not translate it. To do that you will need the original binary in the translation.
if for example the original binary is mostly map or tile or graphics data and not code mixed with constants and variables, well you will still need all of those bytes, but you wont be doubling the size of your original when going to the translation.

for the portion that is code and constants and variables all mixed together I would say you could be looking at at least doubling the size of the original when you get it translated.

Geez, this is getting long again. if, as I assume it is, the original binary was made with a modern compiler that throws in gobs of library calls that you never use. And the translation has a dynamic nature to it such that it only translates the code you are going to run and not everything in the binary. Then your translation itself would be, could be, much smaller than the original. but the original still would be resident in the translation, so instead of 2x or larger it might be 1.25 go 1.5 the size of the original.

Each translation is different. You are going to learn so much about so many things by attempting this, its probably worth it to try. The odds are you will give up, but even then you will have learned so much. I think writing an emulator would do the same thing, be an incredible learning experience, and if you make it through to the end well you will get rewarded from the respect you have earned from your peers.

My biggest warning, and the first thing you should do, is not worry so much about the processor to processor translation, but the peripherals, video in particular will eat your shorts. No matter how good of a code translation you do, it could run 10000 times faster, you have to emulate the source platform hardware, if it has a 3d engine and the target does not, you are not going to make it and the code translation effort is a total waste of time. choose your source platforms and games to translate wisely. All I was trying to do was prt asteroids to the gba and failed miserably (to reach real time speed) all because I didnt look ahead to the vector graphics engine. sure I could have easily made it because asteroids hardly takes advantage of the vector graphics. All of the objects can be pre-calculated as tiles or sprites, by then I had lost the energy and desire...I am a bit worried about how the graphics hardware from the gba is going to emulate in the gp2x. It may defeat some of this effort. Likewise, I assume PSX means PS1, PS2, PSP, etc the sony family of play stations, look at the video hardware emulation first. Take a working (open source) emulator on a PC, have it capture the data needed for any individual screen refresh, take that data and the video hardware emulator, port just that part to the gp2x, emulate the drawing of that screen update a few thousand times and time it. If you cannot exceed real-time speed enough to allow bandwidth for the translation code, you are not going to make it without hand tuning the graphics emulation. There again some games may barely take advantage of the hardware and may be easy to find shortcuts, others may not (As an example asteroids, easy, asteroids deluxe a little harder, tempest, much harder, no shortcuts).

The gp2x can read sd cards, even 2x or 3x 6000mb will fit on some sd cards yes? (Are they up to 4gb or just 1gb?) So you might make it. I assume a large part of that 600mb is game data that doesnt get translated or C or C++ libraries that dont need to be translated, so it would hopefully fit on a 1gb sd.

As far as gba games, I am trying to remember, the gba carts are based on bits not bytes, so 128M is 128M bits or 16 mbytes. For most of the GBA games you should have no problem fitting these on a sd card. Getting the whole game in memory on the gp2x for execution? Maybe another story. I still assume that there will be large portions that are raw graphics and with a good translation you can do a 1 to 1 copy of those to the translation. Also the gba and gp2x use the same instruction set. Now this is something to worry about, any good GBA programmer is going to use thumb mode. If that gets translated to arm mode, it effectively doubles the side of your translation. Basically you can pack twice as many thumb instructions in the same size binary. The gp2x will certainly execute thumb mode, it is just slower than arm mode on this platform. Although, if/since this translation is going to C code then back to asm, the option is there to compile to arm or compile to thumb. The thumb binary wont be half the size but it should be considerably smaller than the arm mode compile and that may make the difference in whether you can get the whole thing to fit in the gp2x ram or not. You may have hit on yet another challenge to running the gba on the gp2x. I think most gba games are going to be relatively small, but there will simply be a few that cannot run on the gp2x because of their size.
 
Last edited by a moderator:
The gp2x can read sd cards, even 2x or 3x 6000mb will fit on some sd cards yes? (Are they up to 4gb or just 1gb?) So you might make it. I assume a large part of that 600mb is game data that doesnt get translated or C or C++ libraries that dont need to be translated, so it would hopefully fit on a 1gb sd.
Sure it'll fit, only 0.5% of those 600mb actually have to be translated. The nice thing about emulating a CD-ROM based system is that executables and data are often very clearly separated. In a cartridge based one, the entire thing could be program code for all we know. Then there's the fact that few games actually stuffed every last megabyte on the disc.
 
I just updated the website again, it should look better in IE now, but I haven't checked yet. Added the A7Board, a place where people can talk about the emu freely. Maybe a little too freely. We'll see.

btw, my trip has been postponed to Wednesday. :)

[edit] Got the date wrong. >_<
 
Back
Top