Gp2psx V0.34

[Emu&Co]

Dave at I realize that what you mean is "absolute efficiency" so I may have set up a straw man here. But even so, I have to wonder...is there a most efficient way to emulate a computer system? I don't think there would be, as it depends on the approach or goal of the engineer, which seems to me to not be set in stone.

Just felt like playing philosopher I guess...keep up the good work z. And Dave, you're probably right

edit: rife with typos

​

No human will be able to figure out the absolute best and most efficient way to code a particular emu. One way does exist. That way would use every last cycle of all of the hardware combinations have them talking together real efficient with the cleanest code possible with little wasted time. Even with this theoretical best case (which could never be achieved by even the smartest coder working all of his life) PSX would not run full speed with sound on the GP2X. It is just a hardware limit and it IS absolute. I am not saying it is not worth doing as people here seem to like it so it is worth something. I am just trying to put it in perspective so that people like Paradox aren't dissapointed and don't expect miracles.

​

Tell me one thing. Why did I get fullspeed PSX Emulation with my old PII 233 MHz? If it's right, what you say this should be impossible, but it works very well. I respect your opinion, but I'm sure it will work, because I've seen it already on such speeds.

 

[Turambar]

Were you running that in software or wiht gpu plugins that offloaded work to your graphics card? Even it is was software only im fairly certain a P2 is more powerfull than an ARM9 at the same clock speed.

 

[Paradox]

dave why did you have to come here and stir shit up? the emulator is coming along fine and i am confident it will someday reach full speed,maybe not with sound.

 

[ruffnutts]

I hate it when people start putting a damper on things, i think this emu is doing great so far! lol

 

[Vimacs]

thats one of the reason why noone likes davec, he is a idiot

 

[gdelappa]

Tomb Raider doesn't work with 0.34d
However, Tomb Raider II demo works, but still too slow to be playable.

So, the ones that work are still too slow.

 

[Spearhead]

thats one of the reason why noone likes davec, he is a idiot

​

Now now, i would put a damper on the rudeness here.

I think he's just much too negative for most of us. Tends to turn people away, that kind of behaviour...
I'm not saying negativity should stop alltogether, some is needed, but Dave... he's in overdrive mode it seems

 

[zodttd]

I have a feeling DaveC doesn't understand the internals of an emulator very well, but I could be wrong. Not to mention, a MHz by MHz comparison isn't a good way of comparing processors and architectures. I think it's just a case of my timing of releasing the Zodiac's PSX emulator right after he said it would be impossible. It shouldn't matter to him, and I have nothing against him. Point is, ignore his negativity.

My plan of getting the PSX running at playable speeds on the GP2X is this:
- Almost all PSX emulation code has been handed down from FPSE 0.08 it seems. You can tell by looking at the structure of code between emulators source code releases. The same is true with GPU's. Most have kept the same structure as the doomed.org docs explained to do it. Unai would like to redo the GPU completely, which may just speed things up dramatically. By the same token, it could slow things down. We'll see.
- A dynamic recompiler will speed things up by taking a psx R3000A instruction and turning it into a nice and simple ARM instruction. This is much cleaner than using the current interpreter which does about the same thing, but in C.
- My GPU blitting code is weak. Its planned to get it compiled in assembly tommorow.
- A good frameskip. As you can see I'm working on frameskipping with the current GPU lately. Today I have another release lined up that skips the rendering of frames when skipping the blitting of a frame. This will speed things up quite a bit, but currently needs tweaking to reduce graphical issues and speed things up.
- Some games are already playable, even with sound, such as one of my fav games One Piece Mansion.

So later today I'll have a new release. It will fix the compatibility issue that broke a lot of games. It also means HLE no longer works, and I plan on removing it for awhile until things shape up more. HLE isn't very compatible yet anyways in this codebase. Frameskip will work better. This means you'll notice a speed increase using frameskip more than before. It's not perfect though, and considered expieremental.

It seems most games get around 10 FPS. That's pretty impressive considering it's only counting frames that have changed. The actual framerate is probably a good amount higher. I'll implement a normal framerate indicator soon, but I use this one since it shows the actual amount of frames being rendered which is useful to me, more so than bragging rights of x amount of FPS.

So a new release coming...

 

[Vimacs]

yay

 

[Phil]

Well thats just fawesome.

 

[Paradox]

yay yay

i get so happy whenever zodttd makes a new post..

 

[Shikaku]

Not to mention, a MHz by MHz comparison isn't a good way of comparing processors and architectures.

​

Athlon CPUs seem to work faster than Intel CPU's not because of clockspeed but because of Motherboard speed. I have no idea how the ARM processor works, but it should be similar, so let me just give a simple example.

(I know there is specific jargon, but I don't know it and I want to keep it simple anyway. Also this may be wrong...)

A CPU does 3 things: Decode, process, send

First a process is sent to the CPU. This isn't usable directly by the CPU...

Decode: ...so it has to be decoded for the CPU to...

Process: ... process. The result is then...

Send: ... Sent back to whatever needs it.

Now, the beauty of CPUs is this: multitasking. Let me just use DPS for the decode, process, send, and make a little table. 1 Column is 1 CPU cycle (action)

D D P P S D D
   D D D P P P
     D P P P S
       D P P P
         D D P
           D P
             D

It can take any # of CPU cycles to decode, process, or send, but you get the idea. L1/L2 cache comes in play here: the bigger the cache, the more it can multitask (more instructions to be able to store). Again, no idea at all about the dual ARM cores...

Assembly makes the process of decoding much more easier. Every line of "true" assembly is 1 machine code line (programmers: I'm talking about things like MOV). Therefore it takes less space to do the process and it is generally done faster. Add to the fact that if you take advantage of assembly optimization, you have faster general processing.

Eh.. why did I bring this up again?

Oh yeah! MOTHERBOARDS!!

If 1 motherboard can transport things to the right part faster than another motherboard, the speed with the same CPU on those 2 motherboards in general will be different. This is why HyperTransport for AMD helps beat Intel in a lot of the tests, even though Intel has higher clock speeds (GHz) than the AMD: Intel has raw power, while AMD motherboards tend to be more efficient.

Now take the GP2X.... ehh how fast is everything? No clue =/

 

[ruffnutts]

Im playing iss 2 pro evolution soccer and it works, a little slow but perfect looking , if only we had a speed boost, fooball on the gp2x woohoo

version 0.34c btw

 

[Ando]

how much faster does everybody thinks this emu will get when and if it uses the second proccesor?

 

[ruffnutts]

hopefully a lot faster, thats if it needs it who knows

 

[Paradox]

the second processor isnt the same as the first one, its pretty crap or so ive read, using the second processor could actually slow things down (something Squidge said once)

 

[Hanz™]

hopefully a lot faster, thats if it needs it who knows

​

Unlikely to be a lot faster. It all depends on whether it can be used at all effictively.

 

[ruffnutts]

I thought it was for sound anyway?

 

[Ando]

well that kinda stinks <_< i really hope he is able to use it effectively though when he is able to

 

[Vimacs]

the second processor isnt the same as the first one, its pretty crap or so ive read, using the second processor could actually slow things down (something Squidge said once)

​

its not crap, its pretty much the same as teh first one, but it only haves 4/4k cache instand of 16/16 and only a mpu instand a mmu, the second cpu can be of great use if used right.