So any1 still think its fake? o.O... If so you're crazy :p..
And hilde, I could have sworn I've seen the name hilde with other emulation projects in the past... or my memory just sucks
Printable View
So any1 still think its fake? o.O... If so you're crazy :p..
And hilde, I could have sworn I've seen the name hilde with other emulation projects in the past... or my memory just sucks
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.
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 :)
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 !
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 :rolleyes:
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 :confused: 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!
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.
Gee Exophase you seem really interested in this emu....maybe you should help him code it :p
I'm always calm here. :) Just seriously spoken.
Thanks.. I think?Quote:
Originally Posted by pkmaximum
I know all too well how many hoaxes this scene has been given. Actually, I've been part of emulation scenes for the past 10 years, and hoaxes have been rampant since the very beginning. I understand that it's hard for people to trust..Quote:
Originally Posted by pkmaximum
The problem is that 19 times out of 20 (okay, random number, but most of the time) hoaxes are really easy to spot. Maybe not for everyone, but if you can't understand why something is fake then you should listen to those who can, to tell you.
Going around blindly saying things are fake, or things are real, is shortsighted no matter how often hoaxes happen. The problem is that you don't seem to be giving any reason for why things seem fake.. and it's hard to listen to when there is so much evidence that they're real. Pretty much the same story for when things are obvious hoaxes (like that alleged PSP emulator by our friend S!ms)
Don't know anything about it, but even if it was hoaxed well in the general sense (some good photoshops here and there) it would have probably been thrown off by properly constructed technical inquiries, just like all the rest..Quote:
Originally Posted by pkmaximum
You called that PSXP video fake too (or at least implied that there was a good chance it was fake), which IMO was silly. I don't know if you call EVERYTHING fake, but you seem to easily doubt PS1 emulators for some reason..Quote:
Originally Posted by pkmaximum
Not at all. It doesn't make much difference to me at all if any emulators for PSP are real, save for my own perhaps (okay, don't think too hard about that statement). I don't have much time to play PS1 games on my PSP, and I'd probably rather play them on my PC.. but I've played most of them years ago already.Quote:
Originally Posted by pkmaximum
I like PS1 emulation ;) I've been following it on PC since the days of PSEmuPro, so I'm very interested.. also, I learned what I know about emulation by having long conversations with the old emulator authors like Pete Bernert, Xeven, shunt, PsYcHoJaK, etc. The moment PSP was announced I was talking to Xeven about PS1 emulation on it. Course, that was years ago..Quote:
Originally Posted by pkmaximum
There's an even greater interest in PS1 emulation because it's kinda a battle between Sony and homebrew devs. It's nice to see people who do this stuff for free triumph over large corporations.
Heh, it ain't personal when it ain't directed towards me ^_^ It's just commentary. Although, I do think hlide seems like a good guy and it'd be great if he was taken seriously.Quote:
Originally Posted by pkmaximum
Thanks *_*Quote:
Also Exophase great work on GPsp V0.8 fantastic piece of work!
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.
And Hlide, you are clearly intelligent, I was looking over your dyranec instructions, between you and Exophase, and I'll say it again "I wish you the best of luck on this project".
Exophase, you are right, and when I state something from now on, its only in best interest to be fair to the coder behind the project, to state why I feel a certain way. Well:
I have been put down too much in the past, for things that really just seemed to real to me, and I refuse to be put down any more. So I decided I will not believe something until the raw proof is in my field of vision (not a computer screen =P)
But once again, I look forward, to anything on the PSP that is being done. Just I'm more of an N64 person though =P
But the day I can play Castle Vania Symphony of the Night on my PSP, would be very nice ^_^
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"
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.
i doubt its fake, PSPGen are a fairly reliable source
My thoughts exactly! :cool:Quote:
If its anything like the other phantom emu im not gonna hold my breatth.
Theres been a whole lot of talk but not much to speak about.
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.
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.
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...
well i use 6 matrixes for permanent usage so only matrix 0 and 1 are left for any transient purpose in my emulator. :/
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 :/
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.
This is great news that theres another one being worked on! :) ...Lets just hope we really do get to see this some day.
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).
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.
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.
Its great that more coders are working on PS1 emulators for our PSPs. Lets hope we actually get a sniff at them.
So now there's 3 PS emulators in the works...I just wish we can get a sample of them before Sony put's theirs out first...I don't know about any of you guys here, but that would just rock my world. Best of luck to all the coders working on these three emus.
I've done some tests with psx4all just now, and it seems Ridge Racer completely ignores all flags... I removed all the flag setting code and it still runs perfectly (and faster :)).
I'm going to try some other games and tell you if any seems to have problems.
edit: maybe we should take this discussion to the developer's forum? I've also done some other experiments with the GTE, it would be interesting to continue discussing ways to improve it.
Wouldn't hlide need to have PSP coder usergroup in order to access those forums :rolleyes:
Ah..I thought you meant the private forum :p
what must I do ? I'm lost.
Hmm I meant the secret developer forums :p
Someone give him coder status then :) I'm sure he's a pretty good coder and this emulator is going to be real good. He also seems very excited, but then again, who wouldn't? :)
hlide: not sure, I didn't measure, hehe. Maybe the whole thing got about 5%? Hard to tell by eye, and also hard to tell how faster the CPU/GTE alone became. But anyway not having to set the flags opens a handful of doors for optimizing :) But I found out some games to hang right at the start. Might need to test later which flag exactly they want. Or maybe they just want 0 and I removed the command to clear it every op :p
I'll do those later today, little busy now.
There is a global flag called CHKSUM which is set to 1 when other flags are set. Maybe some games only checks this bit so one way would be simply to this bit to 1 for any overflow or limitation.
if not enough, when this bit is set at the end of a cop2 execution, just set the other bits to 1 at the end.
well i don't know if i have a coder status, but i don't where to go.
You don't... it appears below your name (like me).
Once you get it, some new forums will appear at the bottom of the list.
The rule here so far is that you actually have to release something prior to getting coder status. You can easily discuss this in the development forum and if you want I'll prune the fun dynarec talk out of here and move it to a seperate thread there.
as you wish
Well it appears your a PSP Coder now :)
arf ! ok i'm checking it
I think I got coder status before releasing HOTA... :p
Hmm, that reminds me, I have to fix the screen and add music to HOTA... And do something else... I'm out of ideas though :p
Considering you released your daedelus mod thinger within two weeks of you joining here, i think you had released something prior to being codered ;)