Uae Portrd By Squidqe

[Venkman90]

That'd be worth getting a '2x for alone!

Great work Squidge!

​

+1

Best news in ages

DaveC is correct, in that an optimized port may take time, but with this kind of head start it looks promising

 

[sensible GP32]

hoy boy!

 

[fade]

Excellent! I just discovered PSP-UAE and although it runs well, it is a little sluggish, if it runs even a little better on the GP2X it'll be amazing! Theres some great stuff in development for this little system and we dont even have it yet!

 

[Squidge]

Well, without frameskip, UAE ran at 3 fps. I then managed to increase it to 7 fps. Now it runs at 10 fps, which should be enough for some strategy games. Some cracktro's actually look quite nice.

I've still got some tricks up my sleave yet though

 

[Jarska333]

Without sound I assume.

 

[DaveC]

How about using cyclone? With "C" and using one core this will probably not be playable with sound for action oriented games right?

Also since you have a beta board how much power does it use? They are saying that batteries won't work on it. Is it because the voltage required is too high or is it because it pulls too many milliamps?

 

[Jarska333]

Or maybe because they forgot to connect a wire.

 

[fade]

ooh i really hope amiga emulation gets to a better level than the PSP, i loved my ol A500 *sniff*

 

[Wonderdog]

Cannon Fodder, Alien Breed, Walker, Battle Isle... so many awsome Amiga titles that deserve representation!

I can't wait to see how this turns out!

#Wonderdog

 

[chris_r]

Well, without frameskip, UAE ran at 3 fps. I then managed to increase it to 7 fps. Now it runs at 10 fps, which should be enough for some strategy games. Some cracktro's actually look quite nice.

I've still got some tricks up my sleave yet though

​

Is this all using the 1st processor or have you programmed it to use the 2nd processor yet?

 

[xafier]

Well, without frameskip, UAE ran at 3 fps. I then managed to increase it to 7 fps. Now it runs at 10 fps, which should be enough for some strategy games. Some cracktro's actually look quite nice.

I've still got some tricks up my sleave yet though

​

Is this all using the 1st processor or have you programmed it to use the 2nd processor yet?

​

Last I heard it was 1st processor only and no optimization, and no assembly... so things are indeed looking good, as some stuff should be able to be shifted to the 2nd CPU and obviously get some ASM in there and FPS will start to rise can't wait personally!

 

[Squidge]

Not sure what to use the second processor for to be honest, as it's all been written for a single processor from the ground up - so one parts needs another previous part to be finished first. Suppose I could throw the actual display updating into the secondary processor, which should save a few milliseconds per frame.

For the cpu, yes it's all in C, but the way it's integrated into the main code, I'm not sure Cyclone would be easy to implement. So I've started writing my own 68K asm core just for UAE, and optimized for the gp2x

 

[Empyre]

Not sure what to use the second processor for to be honest, as it's all been written for a single processor from the ground up - so one parts needs another previous part to be finished first. Suppose I could throw the actual display updating into the secondary processor, which should save a few milliseconds per frame.

For the cpu, yes it's all in C, but the way it's integrated into the main code, I'm not sure Cyclone would be easy to implement. So I've started writing my own 68K asm core just for UAE, and optimized for the gp2x

​

Could the second processor handle the audio? or maybe do some of the blitter jobs?

<--- wants Amiga emulation soooo bad!!!

 

[Squidge]

the problem with that would be getting the blitter or audio to synchronize with the 68K processor being emulated on the other processor. I think the closest we'll be able to get is having all the emulation done on one processor, and the actual graphics and audio output (not emulation) being done on the other. Should still save quite a bit of time.

 

[Empyre]

Theres no way to pause one core while the other is still processing? thats kinda dumb!

 

[Squidge]

Well, you can't pause the cores, but you can hold the 940 in reset, or busy-loop until a situation occurs.

 

[codesmith]

Well, you can't pause the cores, but you can hold the 940 in reset, or busy-loop until a situation occurs.

​

I suspect holding the 940 in reset and having it come out when something happens will be slow (most CPUs can take dozens of cycles to come out of reset). Much better to use the dual CPU control registers, with the 920 writing data into addresses C0003B20 - C0003B3F, the triggered interrupts in the 940 putting the data in some sort of bounded queue and the 940's main loop pulling the data from the queue and processing it.

I think that the dual proc nature of the MMSP2 chip will be the most exciting feature of the gp2x; I intend to play with it extensively, with a view towards writing some sort of library that makes it relatively simple to write multiprocessing programs. The one thing that may make things tricky is that the 940 doesn't have an MMU. But then, the gp2x is an embedded device with no swap, so it may not be a problem after all. Should be interesting...

I WANT MY GP2X GADDAMMIT </cartman>

 

[Squidge]

The MMU is exactly the problem. Under Linux (which runs on the 920) all your program will see is virtual addresses, it doesn't know how to translate any virtual address to a physical address, and if you malloc 100KB, the memory will only be contiguous virtually - it could be scattered around in memory physically.

Now the 940 doesn't have an MMU, so expects physical addresses. Since you can't turn your virtuals into physicals or allocate contiguous physical memory, it will be difficult for both the 940 and 920 to process the same data without using a global physical buffer that is allocated by a device driver (which is exactly what the mpeg stuff does).

So, to use both processors properly, we need to either write our own device driver (without being able to rebuild the kernel) or chuck linux in the bin and do away with virtual addresses completely. A lot of devvers are all for throwing linux in the bin just to make life easier.

Chucking Linux in the bin also gives us another thing - lots more memory. The linux kernel and mpeg decoding routines and buffers/etc take up a lot of memory that we can't free in linux (as it's allocated at a physical address in memory on kernel bootup when the driver is initialised) but won't even get allocated if we jump in before linux.

 

[Oscaruzzo]

So, to use both processors properly, we need to either write our own device driver (without being able to rebuild the kernel).

​

Why? Isn't the kernel completely open-sourced (together with all the device drivers)?

 

[xafier]

Why? Isn't the kernel completely open-sourced (together with all the device drivers)?

​

yeah the kernel source is available, technically... I think DJWillis is in the process of making them release it, MagicEye or GPH... I'm sure we'll have it eventually, but the fact still remains we really could do with the kernel re-building with a more recent version of GCC and with a more recent kernel... which means someone understanding the thousands of lines that are different from the standard ARM kernel :huh: