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"