[WIP] YAPSxP: Yet Another PSX Emulator for PSP

**dagger89** · November 6th, 2006, 03:27

So any1 still think its fake? o.O... If so you're crazy

..

And hilde, I could have sworn I've seen the name hilde with other emulation projects in the past... or my memory just sucks

**Exophase** · November 6th, 2006, 03:29

Originally Posted by hlide

liveness analysis ? you mean to foresee which register is used before recompiling an atomic block of orginal instructions so you can optimise the generated code depending of what registers it uses ? well, that also mean you need to generate a sequence of instructions for each gte instruction instead of calling them. Does it really worth ?

I read somewhere some games really use those flags but it would be great if indeed no game is really using those flags and that would simplify and speed up a lot GTE emulation for sure.

Liveness analysis on the flags, not the registers. Yes, you would have to recompile GTE instructions, instead of just calling functions. If you use VFPU afterall it might be worth it, depending on how often VFPU instructions are used in the PS1 game (I would assume they're mostly inside a tight kernel of the 3D engine).

If you don't want to do that it might be worthwhile to have two versions of each GTE instruction, at least. One that generates all flags, and one that generates no flags. I don't know how much the liveness overlaps, however. If it truly is common for games to not use any flags then you can offer the no flags version as an option universally. Otherwise, you'd only use it when analysis indicates that all flags generated will be dead.

Dead flag elimination is very common for dynarecs of machines with flags. Even gpSP does it, although only for Thumb instructions.

**hlide** · November 6th, 2006, 03:38

Originally Posted by Exophase

1) Even if VFPU has overflow it's totally different, because it's floating point the results of these operations will never overflow (since they fall within the overall range of 32bit float). Instead you'll end up losing a lot of information, but you can at least determine if it would have overflowed integer-wise with a comparison, as usual (I have no idea how to even test VFPU regs though, you might have to put them back into integer regs..)

you will find MAC0/1/2/3 with the 8 least significant bits at 0 at worst case. So far as games are only using IR0/1/2/3 parts in 16-bit precision, that's okay. If they are using MAC0/1/3/4, can we be sure there wouldn't any artefacts as result ? well, okay, you seem pretty confident about VFPU, I will try this one without falling through in 64-bit integer calculations. But I would still need to know how handle vector comparisons to set flags :/. Argh I cannot simply convert MAC0/1/2/3 to 32-bit integer to detect their overflows. I really dislike those flags to emulate

((

Anyway, your discuss helps me a lot to see better on the importance or not of the loss of precision. I would write two versions, one with flags, the other without flags.

thx, i should try to sleep now

**hlide** · November 6th, 2006, 03:43

Originally Posted by dagger89

So any1 still think its fake? o.O... If so you're crazy

..

And hilde, I could have sworn I've seen the name hilde with other emulation projects in the past... or my memory just sucks

hLide

well i don't remember to have done an emulator. I did write some OSes for fun but an emulator I don't think so.

**hlide** · November 6th, 2006, 03:51

Originally Posted by Exophase

Anyway, do you think it might be possible to keep the GTE regs as float then only convert when going to/from the CPU and them? I wonder. Anyway, setting all the flags alone probably takes more time than doing the math, especially when in VFPU. Dead flag elimination would certainly go a long way since you probably almost never need any of them, however you'd want large blocks or superblock analysis to get anywhere with this. But even saving it with some typical GTE instruction blocks would be a good win. You do have to set as many as 19 flags, the computation involved for all of that is staggering. If you don't have to set flags then you can do the saturation instructions pretty quickly using the min and max instructions (and perhaps keeping some constants in registers). You can do this for either VFPU or integer implementation (of course, since you can do them in parallel for VFPU it'd be even better there).

Do you add this section ? I don't remember to have seen it :/

well you're right it would be the right solution. Well I may reconsider to store GTE registers as float value and then generate FLAG register only when I need to read it (can be done in CORE0/CORE1) or better when determining which bits are tested (CORE2 ?).

good night !

**pkmaximum** · November 6th, 2006, 04:13

Originally Posted by Exophase

You doubt everything, don't you..? It's not like the guy said he has a perfectly functional PS1 emulator and is sitting on it. Just that he's in the process of writing one.

This scene has a lot of people who believe everything or believe nothing when it comes to upcoming releases, unfortunately quzar is right about this... that belief or disbelief is almost never based on any evidence or even common sense.

I'm going to have to say to calm down a bit Exophase =P

You are definently very very skilled at coding and its hard to doubt you sometimes

But you should understand how many hoax's the PSP scene has been through. Also let met clarify "hard coded FFVII emulator, runs like dirt people but I will release sources tomoro"
*Next day
"I passed on the sources to a good friend of mine *cough* *cough*"

Come one we seen people hoax the most rediculous things, "Why they do it" no clue.

Also Linux on the PSP, another hoax which I'll probably not understand any time soon

But that apparently didn't have anything special about it, but still they said it was real, and they typically did a good hoax job on it.

And Exophase, I don't call everything fake, and if you knew me in this scene before you judged me you would certainly understand my good nature about the PSP scene, and my defense for people =P

But to me, it seems like you are really desperate to see this real, I have been seeing you post in the topics dedicated to PSX on the PSP a lot. Why you do it? Not sure.... But don't take anything someone says too personal =P

Also Exophase great work on GPsp V0.8 fantastic piece of work!

**Exophase** · November 6th, 2006, 04:23

IR0/1/2/3 are the lower bits, not the upper ones. Unfortunately with the floating point calculations you lose the precision in the lower bits, so they too will be affected. If it is true that the 8 least significant bits are 0 most of the time for the full answers then that at least gives you some hope, although 32bit floating point precision gives you even less than that (23 bits, not 24)

This is a rough idea for computing the flags (may or may not have any merit, just a thought):

First, keep in mind that when it comes to flags you tend to operate them on an abstract way and rarely need their values literally. Because of this it is often useful to have a different internal representation for this when you emulate. Of course, since there aren't branching instructions you will have to piece together the entire flags register when it's needed, which can be quite messy. I don't know how frequent this is. For some games it might be never. Anyway.

Keep in VFPU regs several constant scalars set to the upper limits, IE 8796093022208, 32768, 4096, 1024, 256, and one for the lower limit, -1. Then include versions that have each one less (except the lower one, it'd be 0). You would use the max/min instructions on the first one to set the flag, in a vector somewhere, and the max/min instructions on the second to actually perform the saturation. Then basically each flag is stored in a single register, and the flag is set if the value is the boundary - fortunately, since these are powers of 2 you can check a single bit to determine if the flag is set or not.

This requires a ton of registers.. you have 128 VFPU registers so maybe it'll actually be enough, but it's hard to tell without laying everything out.

When the GTE flags register is read from you would have to perform VFPU float to int, shift, and ins instructions to get each flag. It's not too bad but there are so many flags.. but I imagine this is something that is rarely needed.

Please tell me if this idea makes any sense to you.

**DPyro** · November 6th, 2006, 04:31

Gee Exophase you seem really interested in this emu....maybe you should help him code it

**Exophase** · November 6th, 2006, 04:33