[WIP] YAPSxP: Yet Another PSX Emulator for PSP

[Exophase]

Well...

I'd say, it's okay to feel the way you do. That is, "I won't get my hopes up until I can play it." I don't blame you for feeling that way anyway.

It's just a matter of holding out, and showing doubt.. that is, no reason to believe anyone's lying with this one.

'course, nothing was ever said about a lot being done, just some of the core CPU work. We can only hope it actually makes it all the way.

[XioN980]

i doubt its fake, PSPGen are a fairly reliable source

[modcase]

If its anything like the other phantom emu im not gonna hold my breatth.

My thoughts exactly!
Theres been a whole lot of talk but not much to speak about.

[hlide]

IR0/1/2/3 are the lower bits, not the upper ones.

IR0/1/2/3 are normally set from MAC0/1/2/3 but they are saturated so they are always between -32768 or 32767. So long as MAC0/1/2/3 don't exceed those min et max values, IR0/1/2/3 are okay. If they do exceed, IR0/1/2/3 would be saturated anyway to those min/max values so I think it is okay for them indeed. Plus they are always loaded or stored as 16-bit word so that okay to be fit as a float. It sounds as if the problem only concerns MAC0/1/2/3, TRX/Y/Z, R/B/BBK which are always 32-bit words if you need to load/store them as float.

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)

Yes that's the main trouble, i cannot keep MAC0/1/2/3 as float registers because it only can keep a "24-bit integer" when MAC0/1/2/3 needs to store 1:31:0 bits. So if you use GPL (General purpose interpolation) :
MAC1=A1[MAC1 + IR0 * IR1]
MAC2=A2[MAC2 + IR0 * IR2]
MAC3=A3[MAC3 + IR0 * IR3]
IR1=Lm_B1[MAC1]
IR2=Lm_B2[MAC2]
IR3=Lm_B3[MAC3]
[0,8,0] Cd0<-Cd1<-Cd2<- CODE
[0,8,0] R0<-R1<-R2<- Lm_C1[MAC1]
[0,8,0] G0<-G1<-G2<- Lm_C2[MAC2]
[0,8,0] B0<-B1<-B2<- Lm_C3[MAC3]

and call successive GPL, you are accumulating errors but it is also true that IR1/2/3 and Rx/Gx/Bx are being saturated anyway, so as long as the code doesn't need to look at MAC0/1/2/3 it should be okay.

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.

i don't see any easy way to do :/.

typically to set FLAGS for MAC1/2/3 should look that way ?

vli.t C000, [1<<(30-12), 1<<(29-12), 1<<(28-12)] // bits A1p, A2p, A3p
vli.t C010, [1<<(27-12), 1<<(26-12), 1<<(25-12)] // bits A1n, A2n, A3n
vli.t C020, [MIN, MIN, MIN] // -32767.0
vli.t C030, [MAX, MAX, MAX] // +32768.0
vslt.t C020, MAC1MAC2MAC3, C020 // cn[i] = IR[i] < (1-(1<<31)) ? 1.0 : 0.0 (unsure about this instruction)
vsge.t C030, MAC1MAC2MAC3, C030 // cp[i] = IR[i] >= (0+(1<<31)) ? 1.0 : 0.0
vmul.t C020, C020, C000 // A[i]p = cp[i]<<(31-i)
vmul.t C030, C030, C010 // A[i]n = cn[i]<<(28-i)
vadd.t C020, C030, C020 // A[i] = A[i]p + A[i]n
vadd.s S020, S020, S021 // FLAGS = A[1] + A[2];
vadd.s S020, S020, S022 // FLAGS += A[3];
vf2i.s S020, S020
mfv t8, S020
or t9, t9, t8 // t9 contains (GTE FLAG >> 12).

...

li t8, 0x7F87E // CHECKSUM = 1 if one of those bits are set
and t8, t9, t8
beql t8, zero
lui t8, 8
or t9, t8, t9
sll t9, t9, 12
mtv t9, FLAG



for IR1/2/3 with lm=0 (no negative limit):

vli.t C000, [1<<(24-12), 1<<(23-12), 1<<(22-12)] // bits B1, B2, B3
vli.t C010, [MAX, MAX, MAX] // 65535.0
vslt.t C020, C010, IR1IR2IR3 // 65535.0 < IR[i] ? 1.0 : 0.0
vmin.t IR1IR2IR3, IR1IR2IR3, C010 // IR[i] = min(IR[i], 65535.0)
vmul.t C020, C020, C000
vadd.s S020, S020, S021
vadd.s S020, S020, S022
vf2i.s S020, S020
mfv t8, S020
or t9, t9, t8 // t9 contains GTE FLAG.
...
blahblah

well i dunno if it works...

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.

well i use 6 matrixes for permanent usage so only matrix 0 and 1 are left for any transient purpose in my emulator. :/

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.

well i see several caveats, take this example :

--------------------------------------------------------------------------
SQR 5 Square vector.
Fields: sf
Opcode: cop2 $0a00428
sf=0 sf=1
in: [IR1,IR2,IR3] vector [1,15,0][1,3,12]
out: [IR1,IR2,IR3] vector^2 [1,15,0][1,3,12]
[MAC1,MAC2,MAC3] vector^2 [1,31,0][1,19,12]

Calculation: (left format sf=0, right format sf=1)

[1,31,0][1,19,12] MAC1=A1[IR1*IR1] [1,43,0][1,31,12]
[1,31,0][1,19,12] MAC2=A2[IR2*IR2] [1,43,0][1,31,12]
[1,31,0][1,19,12] MAC3=A3[IR3*IR3] [1,43,0][1,31,12]
[1,15,0][1,3,12] IR1=Lm_B1[MAC1] [1,31,0][1,19,12][lm=1]
[1,15,0][1,3,12] IR2=Lm_B2[MAC2] [1,31,0][1,19,12][lm=1]
[1,15,0][1,3,12] IR3=Lm_B3[MAC3] [1,31,0][1,19,12][lm=1]
--------------------------------------------------------------------------

there is two versions : sqr0/sqr12

if you do :

lwc2 IR0IR1, 0(a0) // how can I determine if i must use [1,15,0] or [1,3,12] conversion to float ?
lwc2 IR2IR3, 4(a0) // how can I determine if i must use [1,15,0] or [1,3,12] conversion to float ?

...

sqr0 // well i'm expecting [1,15,0] format for input/output IR1/2/3

...

swc2 IR0IR1, 0(a0) // how can I determine if i must use float conversion to [1,15,0] or [1,3,12] ?
swc2 IR2IR3, 4(a0)// how can I determine if i must use float conversion to [1,15,0] or [1,3,12] ?

the same thing is also valable for mtc2/mfc2 operations.

well, I think you see the point why i cannot load/store GTE registers as float register :/

[hlide]

if I read correctly, this emu is going to be based on Yoshi's source. later in the post, the author said he didn't intend to GPL it. if it really is Yoshi's source, it has to be GPLed since it came from a GPLed project originally.

You are totally wrong. This emu has nothing comparable with Yoshihiro's emu and is being written from scratch. I was told to help him but I got fed up with him because he was too secretive with his source. My future emu has nothing to do with PCSX so Yoshihiro's PSX-P too. Those are two seperate topics, so please don't try to confuse people with that kind of assertion !

The fact I am not using a GPL license doesn't mean it wouldn't be a GPL source in future time when things would be settled. I prefer to be able to release some executables without any source to start. That's all.

[Baboon]

This is great news that theres another one being worked on! ...Lets just hope we really do get to see this some day.

[DPyro]

You are right Exophase for the most part. I am confident in this emulator in being real, but I just don't want to get another emulator, like PSPX-P VBeta, and find out, it was just pac man fan's work with a new GUI.

This has been said before, but some people seem to have thick sculls. Yoshi didn't use ANY of pmf's source. The only parts of his emulator are from pcsx core. The rest are his plugins and menu. PSPSOne was in no shape to be usable. If it had been, I'm sure there would be a ps1 emu on everyones PSP by now (plus the fact that 3 coders have already said PSPSOne is unusable).

Sometimes I wonder why SONY just doesn't port those games over to the PSP, like Exophase said, "There is a high demand for Final Fantasy VII"

It's not up to Sony whether games are ported or not. It's the companies decision to port games over. If they feel theres not enough money in it to be worthwhile, so be it.

[DPyro]

You are totally wrong. This emu has nothing comparable with Yoshihiro's emu and is being written from scratch. I was told to help him but I got fed up with him because he was too secretive with his source. My future emu has nothing to do with PCSX so Yoshihiro's PSX-P too. Those are two seperate topics, so please don't try to confuse people with that kind of assertion !

The fact I am not using a GPL license doesn't mean it wouldn't be a GPL source in future time when things would be settled. I prefer to be able to release some executables without any source to start. That's all.

It's no wonder Yoshi is so secretive about his source. Back in the 2.00 days, Yoshi gave MPH his downgrader source. MPH then compiled it and claimed it as his own. From then on, he's been a lil paranoid on who to trust with his code. Kinda sucks, but thats the way it goes.

[quzar]

This has been said before, but some people seem to have thick sculls. Yoshi didn't use ANY of pmf's source. The only parts of his emulator are from pcsx core. The rest are his plugins and menu. PSPSOne was in no shape to be usable. If it had been, I'm sure there would be a ps1 emu on everyones PSP by now (plus the fact that 3 coders have already said PSPSOne is unusable).

um... without released source there is nothing to back that up. just because monkey screams it doesn't make it true.

also, you shouldn't double post. you're staff.

[hlide]

It's no wonder Yoshi is so secretive about his source. Back in the 2.00 days, Yoshi gave MPH his downgrader source. MPH then compiled it and claimed it as his own. From then on, he's been a lil paranoid on who to trust with his code. Kinda sucks, but thats the way it goes.

still, here we are speaking about a GPL source which he doesn't own. That's silly because I'm not that kind of moron who would try to con everybody telling I am the author of PCSX.