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.
evkit, Visual Studio, Platform SDK, and tonnes of new games to try out the hardware!! 
