Gp2psx V0.36


the gp2x is not in the dreamcasts domain in terms of performance

[DC SPECS]

# CPU: SH-4 RISC CPU with 128 Bit FPU functions for 3D graphics computations (operating frequency: 200 MHz, 360 MIPS, 1.4 GFLOPS)
# Graphics Engine: PowerVR2 CLX2, 6.7 Mio polygons/second peak performance, supports Trilinear filtering
# Memory: Main RAM: 16 MB 64 Bit 100 MHz, Video RAM: 8 MB 4x16 Bit 100 Mhz, Sound RAM: 2 MB 16 Bit 66 MHz
# Sound Engine: Yamaha AICA Sound Processor: 22.5MHz 32-Bit ARM7 RISC CPU core, 64 channel PCM/ADPCM sampler, 128 step DSP

[GP2X SPECS]
# CPUs: Dual-core: 240 Mhz [4] host ARM920T + 240 Mhz ARM940T integrated into SoC - Overclockable by software (CPU cores rated at 200 MHz, but seem to operate at 240 MHz+ in all systems. Most machines' ARM920T can operate stably at 266 MHz, some at over 300 MHz.)
# Chipset: MagicEyes MMSP2 SoC (System-on-a-Chip)


DC has an 128bit+FPU processor gp2x has two 32bit processors
both are Reduced Instruction Set Computers
but then again gp2x 920T + 940T roughly at 440 mips
DC PPC SH-4 RISC 360 mips

[and then it gets real hairy]

DC has an PowerVR2 3d chip with 8mb vram
gp2x has an 2d accelerator that uses main memory
DC has 16mb main memory
Gp2x 64mb system wide

so my guess is that DC wins performance vise
but PSX emu is not out of reach for any of the systems

the winds could change if
1. somebody wrote a good kernel module that interfaced the 2 processors
2. GPH or open2x figures out a way to utilize the full 64mb with the linux kernel

this is my thoughts on the systems and should not be taken as "pure" facts but i think its a fair comparison

i have a question for zodttd do you build PSX4ALL binaries against Glibc or uclibc (wouldnt uclibc be better suited for an embedded system performance/size vise ?)
 
Unai was mentioning trying to put the whole GPU on the 2nd CPU, but I'm imagining this being very hard to get done. I had put a blitting routine on the 2nd CPU in a past GP2PSX, but the results weren't good as the GPU couldn't run async. Unai said he's thinking of making a "threaded" GPU of some sort. If this can be done, putting the GPU on the second processor would be closer to reality. But as mentioned, the support for the 2nd cpu isn't where it should be. It's possible, but will take some luck/time.

Meanwhile Unai and I are fixing up the GPU. It has a bug in progressive interlacing. This allows for an interlaced screen to be displayed as if it wasn't interlaced at all. Only problem is that the PSX switches between two frames in it's buffer. It's making this hard to get right. Maybe Unai can figure it out in time. :)
 
zodttd posted on May 13 2006 at 09:04 AM said:
Unai was mentioning trying to put the whole GPU on the 2nd CPU, but I'm imagining this being very hard to get done. I had put a blitting routine on the 2nd CPU in a past GP2PSX, but the results weren't good as the GPU couldn't run async. Unai said he's thinking of making a "threaded" GPU of some sort. If this can be done, putting the GPU on the second processor would be closer to reality. But as mentioned, the support for the 2nd cpu isn't where it should be. It's possible, but will take some luck/time.

Meanwhile Unai and I are fixing up the GPU. It has a bug in progressive interlacing. This allows for an interlaced screen to be displayed as if it wasn't interlaced at all. Only problem is that the PSX switches between two frames in it's buffer. It's making this hard to get right. Maybe Unai can figure it out in time. :)

The only actual use of the 2nd CPU I've seen other then the movie player is passing the sound effects to the 2nd CPU in vektor.
 
Last edited by a moderator:
icurafu posted on May 12 2006 at 07:00 PM said:
The only actual use of the 2nd CPU I've seen other then the movie player is passing the sound effects to the 2nd CPU in vektor.

Really? I thought that the Payback rolling demo was using both as well, what for I don't know however.
 
Last edited by a moderator:
Zodttd didnt say specifically that it was going to be private or public.. He just said beta. So im hoping he uploads it to all of us.

...Well even so I could make videos of basically any psx game asked for... I got most of the isos on my comp of the good games xD Plus I could just run over to my friends house to get his lil video camera.
 
Not sure if it's already asked in this 24 pages thread, but now all the emulators use the MMU hack to get faster access to the high memory (or something like that)
Would this also increase performance of the PSX emulator? or would it be pointless?
As I understand you just have to execute the hack-code one time to get it working so it shouldn't be very hard to test right?
for the rest keep up the good work!!! amazing to see FF7 on my GP2X (even if it's slow)
 
pointless, the emulator is still only using the lesser 32 mb of ram

That may not be true:

pepone said:
what give the big boost here is the fullspeed access to the framebuffer who is also in the upper memory.

This is why DrMD and SquidgeSNES are receiving massive speed boosts -- and neither of those use more than 32mb of RAM.
 
Last edited by a moderator:
So it makes access to the framebuffer faster...
is this also true if you use the SDL functions for drawing? or only when you access it yourself directly?
 
Back
Top