Some News Of Things To Come...


You don't have to follow that magical 33MHz number if you write an emulator purely written to play games and not give "accurate emulation". Hence the term underclocking came about.

*** What makes MIPS32 R3000A processor clocked at 33MHz impossible to run on a 266MHz ARM920T? ***

Oh, and the MIPS instruction set that the PSX is based on is one of the most simplistic processors to emulate. It is usually a stepping stone for writing emulators. Just look at how easy it is to write a disassembler for MIPS "bytecode".

*** DaveC: You noted how 33MHz is a higher number than 3MHz. What makes the PSX and its 33MHz processor impossible to emulate to your satisfactory on the GP2X, whereas the 3MHz processor of the SNES is a viable emulator? ***

Nothing makes the MIPs "impossible" to run on a 266 MHz ARM. The first problem is that the CPU in the GP2X is not a 266 MHz ARM. It is a 200 MHZ ARM and not everyone can push it to 266 MHz. Some crap out at 240.

Again it is not just the CPU you are emulating in the PSX. If it was true that all you had to do was emulate a R3000A CPU at 33 MHz and you were finished then yeah it could be done at a decent speed. CPU emulation is just the start, Now move on to audio, 3D polygon rendering etc. Things start to get slow.

The 65c02 in the SNES is also ancient architecture, and it runs 10x slower than the mips.
 
Last edited by a moderator:
DaveC, no one is denying that the SNES architecture runs 10x slower than mips, but each instruction on the SNES requires more GP2X cpu cycles to run than an instruction on the PSX. The people I would trust most to give us an accurate reading on the possibility of a PSX emu of playable quality are the ones who have worked on it over the past several months. I'm more optimistic about the possibility than I ever have been before, though I must admit I was excited just to play through the reactor level in FF7 albeit at slightly under half speed :)
 
Wow, your ability to not understand what I'm trying to tell you is amazing.

DaveC, please follow this logic in the order listed:
- The CPU emulation, that is to say, the ability to take one instruction from the PSX's R3000A MIPS processor and translate it into something the ARM processor can process, takes over 50% of the GP2X's processing time when running psx4all.
- The GPU DMA, processing of graphics data to be laid out in the framebuffer, and then copying the framebuffer to the GP2X screen, takes almost all the rest of the GP2X's processing time.
- This processing time is the amount of time taken up doing certain tasks in psx4all on the GP2X. This is known as profiling code.
- If the emulating the CPU takes the majority of GP2X's processing power, we do not have to concern ourselves with other factors.

Nevermind. Maybe this will make more sense to you...
The "65c02" processer of the SNES you speak of...
What makes it 10x slower than the (PSX) MIPS processor?
Also consider how it relates to emulation with your answer.
 
DaveC picture in your mind a vectorgraphic system with x,y,z coordinates then apply a 2d pixelated picture that molds after the x,y,z coordinates thats how the Psx makes 3d scenes

it looks like 3d but its 2d

glitches will be frequent in most apps becuse the polygon is composed of independent 2d x,y,z blocks but it works.

Now fire up any psx emulator on your pc and say how many games have those glitches (almost any game huh)
 
Mudi: Just saw what you wrote...I'm leaning towards the whole "The clockspeed is 10x as low but it means little in terms of emulation due to the amount of cycles it takes the GP2X to handle each SNES instruction over the PSX". What I wonder is what the SNES transparency thing is all about. Mudi, is the transparency issue due to lack of knowledge of how it works on the SNES? If so, it would be a good example of what I'm trying to express.



Lister is correct. That molding of a texture is what the GTE does in the PSX. It was emulated poorly in the past. A processor with a Vector FPU (VFPU) instruction set helps that code along greatly though.
 
It is pretty well known how the transparencies work, the problem is implementation. I have written an algorithm that does transparencies similar to SNES ones and does them very fast on the GP2X (one of those projects I lost when my HD crashed a couple months back, I'll have to work on making that work again), but I don't think anyone so far has attempted to implement such a thing into the SNES emulator. I think it's more an issue of the SNES emulator being a port that can use a lot of enhancement rather than an issue of no understanding of the hardware.

But no one really wants to write a ground-up from-scratch SNES emulator. It's a scary idea, to me at least. Too much hardware to emulate, some of which has NO documentation and has taken years for the big SNES emulators to reverse engineer.
 
DaveC, please follow this logic in the order listed:
- The CPU emulation, that is to say, the ability to take one instruction from the PSX's R3000A MIPS processor and translate it into something the ARM processor can process, takes over 50% of the GP2X's processing time when running psx4all.
- The GPU DMA, processing of graphics data to be laid out in the framebuffer, and then copying the framebuffer to the GP2X screen, takes almost all the rest of the GP2X's processing time.
- This processing time is the amount of time taken up doing certain tasks in psx4all on the GP2X. This is known as profiling code.
- If the emulating the CPU takes the majority of GP2X's processing power, we do not have to concern ourselves with other factors.


Ok then a question,

If it takes 50% of the GP2X power for CPU emulation then how much do the other things take?

MIPs - 50%

GTE - %

Audio - %

2D rendering - %

Other tasks - %
 
Last edited by a moderator:
I been reading bits of this but not really read any the big posts except zodttds.
davec and that other one epicenter or somethin PSX4ALL is GREAT!! Its great on gp2x zaurus and v43

Zodttd I read someone say thet the v43 version runs some games fullspeed with sound ? is that the version i have ? I havent got to play it yet as im still trying to get a joynux !!!! but the intros look very fast !
 
DaveC: I'll answer your question the best I can. But I still would like to know what makes you think the SNES CPU is 10x as slow as the PSX CPU. I have yet to see anything you say that indicates *why* PSX emulation will never be "fullspeed" according to your specifications, on the GP2X. You give points as to why it can be hard to do PSX emulation on the GP2X, but in the same breath explain the same reasons that SNES will be just as hard. Truly make some sense of what you mean, and show us what makes you so sure. I imagine you are very sure of this, and take is as fact, since you've repeated the same thing about PSX/SNES for over a year now. So if it's a fact, show some proof behind your hypothesis.

Cabbages: I might be able to add USB pad support to V43's psx4all. I will need to get a USB pad to test with, so it might be a bit of time. It's definitely "do-able" as I have the example code needed.
 
that might not be needed :p (by me anyway) As im waiting on digitalcube to get back to me but it look sliek they are goin to sell me a joynux :D.
 
Hmm, I will run the profiler again later, but from memory I think it went something like this:

I believe I included the coprocessors into the 50-60% CPU emulation time frame.

Audio is not as big a deal as most would think, though when I last profiled the code it included the SPU DMA, but not the decoding of XA. I'd estimate about almost 20% if it were, otherwise it's not even notable.

I just felt the need to note how you say "2D Rendering" as if there is "3D rendering". There is ONLY 2D rendering on the PSX. There is NO 3D acceleration. Instead you have a coprocessor handle some math needed to handle the vector math. Got to love textures! 2D rendering takes up about 30-40%.

The other tasks take up maybe 10%.

Basically, the largest portion of GP2X's clocks are spent on the CPU and GPU. This includes the coprocessors. If the coprocessors aren't used it's still the same case though.

I can verify these numbers as needed.

Cabbages: Have you been to www.coolzet.com ?
 
yup i been lookin there a few times but the shop bit is under construction. I actually have been emailing digital cube in korea and they been replying :D and sounds like they are going to sell me one but they say somethin about it only having korean manual and i just told them i dont need a manual hahaha.
 
Props to Tinnus, who said most of what I wanted to say about PS1 emulation. But not everything!

For all you guys saying that PS1 emulation requires strong vector, floating point, and hardware acceleration, you probably haven't used Virtual Gamestation on a lowend PC. Sure, it might need some frameskip here and there, but frameskip is typically much more bearable than far under speed CPU/sound emulation.

And all the people talking about falling short of 60FPS on a PS1 emulator. Most PS1 games are never 60FPS, they are 15/20/30.

And to the people comparing PS1's CPU to SNES's.. it doesn't matter if PS1's CPU is a lot faster when it's also a lot easier to emulate more efficiently. Most MIPS instructions correspond to 1 ARM instruction. Although you do need to swap things in and out of memory and registers, 65c816 will access memory in general much more than MIPS because it's a CISC CPU. It also has 8/16bit mode checks to worry about for both arithmetic and memory. Not to mention flags.

We might not ever see perfectly fullspeed PS1 emulation on GP2X, but I'm certain it'll at least be better than a lot of you are making it out to be.
 
Exophase has spoken. :)

It's better to have an intelligent person say you're right instead of caring if DaveC says you're wrong.
 
We might not ever see perfectly fullspeed PS1 emulation on GP2X, but I'm certain it'll at least be better than a lot of you are making it out to be.
Exactly - it may never be full-speed but as long as the devs enjoy the challenge - who cares?
All users will benefit in the long run from people developing any application as ideas & methods spread.
If a playable PSX emulator is the result then that's great; I must admit I was getting a bit uncertain at one point (I was giving a couple of very vocal posters more credit than they probably deserve) but now I reckon there's a lot of hope.

IMHO 60 fps is rarely a necessity unless shoddy design means that game timing is dependant on the framerate; possibly why certain people have given up on designing for the gp2x? I often (lightheartedly) blame the hardware. :D

Best of luck, we will all avidly monitor your progress - the peaks and troughs, enjoying every minute of it.

EDIT: changed 'sceptical' to 'doubtful' as doubtful about whether 'k' or 'c'..? I read too much american spelling and it's corrupting my mind.. ;)
 
Last edited by a moderator:
ZodTTD, PM sent just in case it gets lost again :)

Reply here if it does.
 
Back
Top