GP32 Let's Flog A Dead Horse!

[generalnmx]

So, there might be a way to get GBA ROMs, or large ROMs of any system with specs lower then the GP32, working on the GP32 after all Am I wrong in assuming the graphics are the largest part of a GBA program? If so, we might be able to use a graphics ripper and load it from disk. Yet along with the emulator itself, this either be an incredibly slow process or a nightmare to code. So let's explore an option that would make 100 coding gurus faint!

Theoretically, we can make a "Translating Compiler" which outputs code for one machine given the code from another machine. Wee, doesn't that sound impossible! So, again theoretically, a GBA2GP32.EXE is indeed possible. In fact, given the C source of the GBA program, we could do this rather easily. But if we need to work with only the binary compiled program, we'd have to setup the specifications in such a way that we literally "decompile" the program into something the translator can understand.

Personally I'd rather see a Neo Geo AES or a Nintendo 64 emulator come out of this. Yes, a Nintendo 64 emulator would be possible given the specs vs GP32, but like I said, this is all theory! There's also the problem where GP32 has no GPU or VRAM, so we could experience a pretty big slowdown unless the system in question is far slower then the GP32.

I'm not saying someone should go out and do this. I really just think the idea of Translating Compilers and Compiler Compilers are neat

 

[Robster]

Heh... the funny part about this is that there is no need for a "translating compiler" because the GBA and the GP32 have compatible CPUs and run the same code

That bit about "there's always the problem where GP32 has no GPU...". It's a big, scary problem and it's the reason that GBA emulators take heaps of horsepower currently.

Oooh- I said horsepower! Nice segue into "Keep flogging the horse, generalnmx, but executable code is the least of your problems!"

 

[damaki]

In fact it is what's currently being coded, somebody had this idea before you and is trying to make it work. I can't remember the name of the emulator but that's the one which has been the most recently updated.

 

[Tobriand]

The emu is GPAdvance. Its being coded by one Enf65, and looks very very very promising. However, it currently has no sprite support (mode 1, 2), so isn't much use for playing games.

 

[Rico]

Dynamic recompilation has had limited success in emulation, I believe Project64 and PearPC do it to some extent. Enf64's emulator seems to be on hold, though

 

[Inopia]

Pfft, this is a stupid idea. First of all there is no distinction between code and data in binary files, so decompiling raw opcodes simply don't work. If you want to decompile/recompile something you need two binaries, one with the original data (the GBA rom) and one with the recompiled code (the GP32 code). This means you double the size of the rom, instead of shrinking it.

On top of that, the difference between GP32 and GBA is not a matter of CPU, since they are more or less the same. The difference lies in the hardware around the ARM core. Since there's no operating system, all I/O is memory mapped. (There is a BIOS on GBA ofcourse, but it doesn't really play a big role) This means that in order to emulate GBA on GP32 instead of emulating the processor, you need to emulate the behaviour and the results of memory writes/reads.

This is possible, using the MMU inside the GP32, but there are a few quirks. First of all the GP32 screen has a refresh rate of 50hz, in order to match the GBA you have to set it to 60hz. But because the LCD is on the same clock as the rest of the machine, it puts limitations on the CPU speed. The highest it will go is 120mhz afaik. This leaves about 120-17 = 103 mhz to emulate sound and graphics. You'd think that's enough, but the GBA hardware has a lot of special bits that flip tiles, doublesize sprites etc. Add to that the DMA and hblank problems you got yourself a real challenge.

Ofcourse it's possible, but if you want to shrink the GBA rom size you'll need to either write a decent memory manager with page swapping (wich shouldn't be hard to do) or keep the rom compressed in memory, but that would seriously hurt performance.

In fact, you need to have support from your hardware to implement paging, and since the GP32 has a nice MMU, it could work.

 

[fdave]

Ofcourse it's possible, but if you want to shrink the GBA rom size you'll need to either write a decent memory manager with page swapping (wich shouldn't be hard to do) or keep the rom compressed in memory, but that would seriously hurt performance.

I think that's the hard bit. Very hard. For each opcode you would have to check whether the memory was swapped in. You couldn't run code antively, there would be no way.

So you kill performance of the cpu emu, and you'd end up thrashing the Flash cache.

GBA emulation on GP32 for roms over 6 or 7 Meg is not going to happen imho. Just buy a GBA

 

[Robster]

GBA emulation on GP32 for roms over 6 or 7 Meg is not going to happen imho.

Says who? If you have 32MB or 64MB in your GP32, it's no problem

I'm hoping for a good GBA emulator, as it would be a good reason for more people to get the upgrade

 

[Inopia]

fdave, note the last line in my post. Ofcourse I wasn't proposing we implement paging in software

 

[MojoJojo]

Theoretically, we can make a "Translating Compiler" which outputs code for one machine given the code from another machine.

Theoretically, you can't do this; you come up against the halting problem. However, it can be done with a large proportion of programs if a skilled user works with it. My house mate works on Specialisation, which is fairly closely related to this sort of thing. In both cases you have to derive high level concepts (e.g. draw sprite in middle of screen) from low level machne code (MOV R0, R1).

Specialisation has been done with a PIC chip... anything more complicated and the large space state makes things difficult.

It would be extremely hard.

I don't think there is much point... the current approach works a lot better, because instead of trying to work out if some code is going to write to the OAM memory, and putting in your sprite drawing code there, you can mark the OAM memory as unwritable, catch the exception that occurs when anything attempts to write to it and draw your sprite then.
(Although this isn't the way it's actually going ot work, from what I can tell).

So, basically, it's not very practical... extremely hard to do, and wouldn't really give you any benefit.

 

[generalnmx]

Heh... the funny part about this is that there is no need for a "translating compiler" because the GBA and the GP32 have compatible CPUs and run the same code

That bit about "there's always the problem where GP32 has no GPU...". It's a big, scary problem and it's the reason that GBA emulators take heaps of horsepower currently.

Translation would still be required because, as you said, the GP32 has no GPU. Like I said, I am talking about a compiler, not an emulation virtual machine.

Theoretically, you can't do this; you come up against the halting problem. However, it can be done with a large proportion of programs if a skilled user works with it. My house mate works on Specialisation, which is fairly closely related to this sort of thing. In both cases you have to derive high level concepts (e.g. draw sprite in middle of screen) from low level machne code (MOV R0, R1).

Yeah theoretically I, myself, would never be able to do this alone. But given a thousand monkies working on infinite time, maybe they could do it...yet those same thousand monkies could probably spit out a GBA emulator in less time I don't see how it's theoretically impossible given the correct resources though.

Dynamic recompilation has had limited success in emulation, I believe Project64 and PearPC do it to some extent. Enf64's emulator seems to be on hold, though

I'm not talking about making a virtual machine (game emulators are usually just virtual machines), I'm talking about making a compiler. All theoretically of course, just debating it for fun.

Pfft, this is a stupid idea. First of all there is no distinction between code and data in binary files, so decompiling raw opcodes simply don't work. If you want to decompile/recompile something you need two binaries, one with the original data (the GBA rom) and one with the recompiled code (the GP32 code). This means you double the size of the rom, instead of shrinking it.

I wasn't talking about a virtual machine. If the compiler was setup correctly, it should output only GP32 code. Yes it IS technically possible, but the specifications would be a nightmare to define properly. In fact, it would probably be 100x faster to code a full-speed GBA emulator with sound using page faults

On top of that, the difference between GP32 and GBA is not a matter of CPU, since they are more or less the same. The difference lies in the hardware around the ARM core. Since there's no operating system, all I/O is memory mapped. (There is a BIOS on GBA ofcourse, but it doesn't really play a big role) This means that in order to emulate GBA on GP32 instead of emulating the processor, you need to emulate the behaviour and the results of memory writes/reads.

I wasn't talking about just the GBA, as I mentioned Neo Geo AES and Nintendo 64. The GBA was just a popular example, hence the "Flogging a Dead Horse". And again, this isn't a virtual machine, it's a compiler.

 

[Dozer]

Wtf does flogging a dead horse mean?

 

[Pirotic]

buy this dead horse i have off me, lets say £5? and i'll tell you.

flogging a dead horse is like trying to sell something which is of no use to anybody

 

[Dozer]

I'm sure dead horses are worth something... glue?

 

[generalnmx]

"Flogging a dead horse" refers to the over-used topic of whether GBA games can ever run, of any form, on the GP32. Though it wasn't my intention for this to be about JUST the GBA, since I was going to make an example of it, therefore the title. Also known as "Kicking a dead horse" - raising controversial issues which have already been discussed in circles again and again.

 

[Tobriand]

flogging a dead horse is like trying to sell something which is of no use to anybody

Are you sure? I always thought of it as an expression of pointlessness, since flogging (i.e. whipping, beating, etc.) is used by particularly cruel people to get more work out of, say, a horse. That is, if its pulling a cart, and it gets hit, then it pulls harder to try and get away from the whip, and thus the cart gets from A to B faster.

Now, if you replace a horse with a dead one, then, of course, beating it will have no effect. You could, with quite a lot of confidence, say that no matter how hard you flogged the horse, you'd get exactly the same ammount of work out of it - nothing. Thus, to flog a dead horse is entirely pointless.

Then the expression gets applied to other topics which are likewise - so a translating compiler is fun to talk about in principle, but, since its a billion times harder to realise than pretty much any other way of getting there, completely pointless.

 

[Inopia]

This idea just DOES NOT WORK. It cannot work. You are obviously not a programmer, otherwise this would have been clear to you

GPU might sound like CPU, but there's no GPU opcodes or anyting like that. So how do you want to decompile code for a GPU? You cannot take a raw binary and decompile it, and then recompile it for a different system. For a different CPU maybe, but not for a different graphics core.

 

[Dozer]

I'm pretty sure generalnmx can code. But is this meant to be taken seriously anyway? :huh:

 

[Inopia]

Hmm, you're probably right. I usually never fall for these trolls though

 

[generalnmx]

This was all a theoretical analysis. Like I said in my previous posts and all posts after that, I am not proposing this as a realistic venture. I am a Computer Science Major, and one of my courses this summer is Automata Theory. Some of the material got me thinking, and I had a lengthy discussion with my professor concerning this same issue. We eventually agreed while it may be POSSIBLE, it wouldn't be PROBABLE.

I thought the other programmers here would get a kick out of discussing the issue, perhaps I was mistaken. Personally I like discussing and designing code structures more then actually programming