[WIP] YAPSxP: Yet Another PSX Emulator for PSP

[wraggster]

Via PSPGen (http://www.pspgen.com/modules.php?name=News&file=article&sid=2614) comes news of yet another PSX Emulator for the PSP Announcement called YAPSxP, heres the translated details:


A third bearing of PCSX? you undeceive this future emulator does not have strictly anything to have with PCsx. It is not finalized yet bus Hlide is in full writing “from the scratch” of this emulator.

Before speaking to you about this new project, it thus should be explained a minimum how it was born and why. Hlide is the programmer who had proposed to program Dynarec de Psx-P.

These ideas and the theory advanced to make function this Dynarec knew to convince us of its capacities. We thus put in contact Hlide and Yoshihiro. If the goodwill seemed to be on the two sides, Yoshihiro forever given its sources to Hlide for reasons which are clean for him and which it will explain you directly on our forum if he wants of it But it is its choice and it should be respected.

At all events, Hlide had always stated its desire for developing another more powerful project because, in his opinion, PCsx is not adapted for a bearing on PSP and will never give a real satisfaction. It however sincerely wanted to take part in the creation of Dynarec de Psx-P, feeling able to carry out two projects without parasitizing one with the profit of the other.

This project is still on paper and it misses in Hlide some technical information but it knew to interest some other developers in the project and feasibility seems more than obvious to us.

Note that PSPGen will be the official site of YAPSxP and that we will open a dedicated site.

OK heres what Hilde himself said about this new project:


Indeed, tired to await the hypothetical source of Yoshihiro which to me was promised so that I integrate a dynarec, I decided to only leave in the adventure.

How was born this adventure?

The starting point of my adventure, it was to propose a dynarec which could be carried out at least twice more quickly than the PSX could not make, by hoping that the remainder of the emulation will not exceed other half of the resources available: in short to allow to emulate the PSX in fullspeed. A chalenge, in fact.

Why I PCSX does not begin again?

It is simple, this source is absolutely not adapted for the PSP. It is not particularly optimized because it is written for GCV survitaminés in gigahertz which naturally manage realities of double precision double precisions. If you try to generate this code for the PSP, you will obtain a at the very least ineffective monstrous code because the PSP nativement does not manage the realities with double precision double precision - very much used in the GTE for example: the PSP will row in the plays of action 3D which make massive use of the GTE. Approximately, it is what you obtain with PSX-P.

What currently contains YAPSxP?

- The dynarec CORE0 (R3000AF) which will be declined in CORE1 then in CORE2, once the emulation of the GTE (in progress) and the entirely implemented COP0.

What will contain YAPSxP?

- The management of a standard pad (already written but not tested)
- The management of graphics (GPU, there I touch on the manner of proceeding)
- The management of the video (MDEC, lives the VFPU!)
- The management of the images (CDR, euh… that will not impassion me masses that…)

What is what YAPSxP will not contain, at least initially?

- savestates
- safeguards
- the sound (I do not despair to do it one day)
- in short, the remainder

Here are, the sources will not be LPG as I had envisaged at the beginning. I am in the active life thus one will not have to hope to see it turning completely for Christmas: he will not serve anything to ask for to me the date of a first release. I do not believe that PCSX was done in one month in the beginning. However that does not make a month that I begin this project, but the dynarec is in very good way and should promise not badly with the management of the GTE and COP0.

NOTE: if there are talented developers among you who would like to contribute on parts that I do not hope to implement for the first release, you can always contact me by PM.

NOTE2:
- CORE0, dynarec which is carried out like an interpreter, primarily for the need for Proof Of Concept and déboggage.

- CORE1, dynarec taking again the base of the CORE0 but by carrying out a block with as much as possible instructions generated in order to release sufficient resource CPU for the remainder to emulate. Already tested with happiness on a pre version.

- CORE2, dynarec with additional optimizations which will make it possible the emulator to be a little more “intelligent”.

So yet another PSX Emulator for PSP project, lets hope we see a release from one of the 3 one day soon.

[nyrtrublue]

wow this is amazing

[Mr.Denny]

interesting :)

[LampDev]

So ... just more announcements, no actual binary to test, eh?

[jimmi]

wow .. the more the merrier !

[gunntims0103]

Ps1 emulation is really starting to pick up interest. This is what the third ps1 emu being worked on. None have in-fact been released but i belive that all emu's are gonna be great. Im especially looking forward to AC's emu. It would be great if all the coders got togther that are creating a ps1 emu and work on just one, but i dought that will happin........

[SpacemanSpiff]

So based on what I can understand from the shoddy translation, he has written the dynarec engine but hasn't built the emulator yet for it to be implemented?

[The_Ultimate_Eggman]

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

[mavsman4457]

This is great news to hear but it is quite annoying to not ever get releases. Hopefully we will see a release of one of the three sometime soon. This also means that if one of these has compatibility issues with a certain game then we could just play that game on one of the other two. Hopefully these coders see it as a competition and will want to showcase their work by releasing it.

[JKKDARK]

glad to hear it. I hope that it's not a fake :)

[Malksta]

sounds cool

[Jpdeathblade]

Hey, how are we going to use R2, L2, R3, L3, and the second anilog? Just wondering =P

Anyway great news, cant wait for this emulator?

[yoshinatsu]

Hey, how are we going to use R2, L2, R3, L3, and the second anilog? Just wondering =P

Anyway great news, cant wait for this emulator?

Button combinations...

Ummm, but what the hell happened guys?
Everyone started to make their own PSOne emulator. We have 3 up until now (No offence, but I think PS1P looks more promising, although we actually HAVE a PSXP beta.)
Should I start one too?:p J/K
But WHEN TF are we gonna get our hands on these goodies???

[goaliedude]

awsome hope it comes out soon !

[TerryMathews]

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.

[DPyro]

He probably means the plugins yoshi coded.

[Basil Zero]

wow, and i thought the PSX scene was dead.

[Lodis]

Imagine if all of the individual devs of these Psx emulator WIP actually worked together.

[mr_nick666]

I think "Fingers crossed" sums it up nicely... :rolleyes:

[S34MU5]

i just wana play mgs and ff on my psp!

and i will be enternally gratefull

[Gene]

Imagine if all of the individual devs of these Psx emulator WIP actually worked together.

i smell a party

[Emeriastone]

I'll be interested to see what comes of this.

[Veskgar]

Great news. I think its fair to say that a PS1 Emulation is the HOLY GRAIL of homebrew. I'm glad that there are so many W.I.P. projects. The homebrew scene is bound to give SONY a run for its money someday when it comes to PS1 Emulation.

An Emulator written from scratch would be fantastic.

[doverkiller]

less blabla, more product!
learn from google! :)

[emuking]

great news i cant wait till one of the ps1 emus get released

[MikeDX]

I think I'm going to wait for the official sony psp emulator, that'll do me ;)

[Makaveli777]

Imagine if all of the individual devs of these Psx emulator WIP actually worked together.

I was thinking the same thing. Instead of trying to achieve indivdual feats they should come togther and make the greatest ps1 emulator for psp ever. I should be called ultimate psx1p or somethin lol.

Oh yeah that translation was pretty bad too so I dont quite get whats so special about this emulator.

[dagger89]

A clear non-google translation is needed... Some things make as much sense as a crackhead talking...

[Exophase]

Yeah, the translations are pretty messed up, but all I can say is..

It's ABOUT TIME.

Tired of seeing all these PCSX derived emulators everywhere. They're even more annoying than the VBA ports (no offense meant to anyone :P)..

Nice to see someone actually has the guts to start a PS1 emulator for himself. However, doing one directly for PSP from the start is perhaps suicidal. Still...

Anyway, no one's going to collaborate here, because PS1P and PSXP's work is largely redundant, I'd say PSXP hasn't done anything interesting over PS1P. And they're both working off of PCSX, something that this emulator obviously doesn't want to be involved with.

I'm sure if hlide needs help he'll ask the right people though (I've answered a small question of his already)

[hlide]

Yeah, the translations are pretty messed up, but all I can say is..

It's ABOUT TIME.

Tired of seeing all these PCSX derived emulators everywhere. They're even more annoying than the VBA ports (no offense meant to anyone :P)..

Nice to see someone actually has the guts to start a PS1 emulator for himself. However, doing one directly for PSP from the start is perhaps suicidal. Still...

Anyway, no one's going to collaborate here, because PS1P and PSXP's work is largely redundant, I'd say PSXP hasn't done anything interesting over PS1P. And they're both working off of PCSX, something that this emulator obviously doesn't want to be involved with.

I'm sure if hlide needs help he'll ask the right people though (I've answered a small question of his already)

thx Exopase :)

let me give you a better translation :

Before talking about this new project, I must explain at least how this project started and why it does. Hlide is a programer who proposes himself to code a dynarec for Psx-P.

His ideas and theories spoken to make this dynarec convinced us he has abilities. So we arrange a meeting between Hlide and Yoshihiro. If the good will seemed to be both sides, Yoshihiro did never give his source to Hlide for some reasons only Yoshihiro knows and can explain on our chat if he wished. But it is his choice and we must respect his choice.

Whatever, Hlide always did express his wish to develop another project more efficient for, according to him, PCsx isn't adapted for a porting on PSP and will never give a real satisfaction. However, he did sincerely wish to help to create a dynarec for PSX-P, being willingly to handle two projects without any competition.

This project is still on the draft and it lacks to Hlide some pieces of technical informations but he managed to have some other developers got interested on the project and the feasibility of this project seems more evident.

Notice that PSPGen will be the offical website for YAPSxP and we will open a dedicated (?) website.

I let Hlide to announce this project in our Forum

---

Indeed, weary of waiting for the hypothetical source code that Yoshihiro promised me so that I may integerate amy dynarec, I decided to go alone in this adventure.

How this adventure starts ?

The starting point was to propose a dynarec which could execute at least as twice as PSX could do, hoping the leaving ressource would be enough for emulation : to say short, to be able to emulate PSX fullspeed. A challenge, indeed.

Why I don't take PCSX as a starting project ?

It's simple, this source code isn't absolutely adapted for PSP. It isn't particulary optimised because it is written for PCs sur-vitaminized in gigaherts that can handle reals in double precision. If you try to generate this code, you get a bloated code for the least inefficient for PSP because PSP doesn't handle reals in double precision natively - often used in GTE for instance : PSP will go slower in the 3D action games which use a lot of GTE. To say short, it is what you get with PSX-P.

What does YAPSxP contain actually ?

- dynarec CORE0 (R3000AF) that will be derived into CORE1 then CORE2, once GTE emulation (wip) and COP0 emulation are wholy implemented.

What will YAPSxP contain ?

- Standard pad (already written but not tested)
- Graphics (GPU, well I need to evaluate the best way to use GU)
- Video (MDEC, vive le VFPU !)
- Image ISO, etc. (CDR, not the part I'm really intrested however...)

What won't YAPSxP contain, at least for the first release ?

- savestates
- backups
- sound (I don't deseperate to do it one day)
- shortly, the rest

Voilà, source won't be GPL as I wanted at the begining. I have a job so you mustn't expect to watch it running for Christmas : don't even try to asm me when the first release will be. I don't believe that PCSX was done in one month. It isn't one month along that I started this project, but dynarec is in good position ans should bring some promises.

NOTE: if some tantented developpers amoungst you would like to contribute on parts I don't think to implement for the first time, I may try to contact me.

NOTE2:
- CORE0 is an interpreter-like dynarec, essentially for need of Proof Of Concept and debugging.

- CORE1 is CORE0 executing the biggest sequence of generated instructions so that it may run faster than the real PSX and allows some CPU ressource for the rest to emulate. Already tested with success on a preversion.

- CORE2, dynarec with additional optimisations that allow emulator to be more "intelligent".

-----

Okay, my translation must suck a lot but it is very late now, so be indulgent.

Good night !

[mavsman4457]

Great news. I think its fair to say that a PS1 Emulation is the HOLY GRAIL of homebrew. I'm glad that there are so many W.I.P. projects. The homebrew scene is bound to give SONY a run for its money someday when it comes to PS1 Emulation.

An Emulator written from scratch would be fantastic.

As for now a PS1 emu would be the holy grail but eventually it will be all about devhook. The future firmware updates will give us many things we never saw coming to a PSP. Especially if you own a PS3.


Okay, my translation must suck a lot but it is very late now, so be indulgent.

Good night !

Nice to see that you have joined the DCemu network. Goodluck to you with your emulator and it seems that you will be taking the Exophase path by starting from scratch and reaping the benefits. Good luck and never give up.

[Exophase]

Why hlide is awesome:

He actually posts on boards. And with a lot of technical information about his project.

About PCSX using doubles for GTE.. that's pretty sad. Back in the day it was expected to use 64bit ints for GTE in PS1 emulators, because it is afterall fixed point. The better emulators used this, but the open ones didn't seem to. I remember trying to convert some to this (one that may not have been open source, I don't remember). Anyway, this is necessary for full precision, but I have been told that the VFPU's precision is sufficient. Which is good because MIPS is almost as bad as with 64bit int as it is with 64bit floats. VFPU is 32bit float, but the intermediate calculations (multiplies + adds) are probably handled with more precision than this.

I assume the "core 0" that exists right now is a threaded interpreter. Turning that into a "full" dynarec shouldn't be too hard (path I took with gpSP). Fortunately MIPS opcodes are easy to emit.

Hopefully GPU -> GU will go down well, I don't know all of the specifics but I bet PSP is up for the task. It has all of the basic OpenGL features, plus (as far as I'm aware) the ability to take textures from anywhere in VRAM and hopefully the ability to render outside the framebuffer too, if it has that I bet there won't be problems mapping the GPU straight to it. Unfortunately PSP doesn't have a lot of VRAM so you can't really enhance the PS1 display much.. but it'd be great if you could at least store PS1 VRAM completely in PSP VRAM with an exact 1:1 mapping. It'd be very fast and accurate.

[pkmaximum]

I'll believe it when I see it.

[Exophase]

I'll believe it when I see it.

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.

[hlide]

Why hlide is awesome:

He actually posts on boards. And with a lot of technical information about his project.

About PCSX using doubles for GTE.. that's pretty sad. Back in the day it was expected to use 64bit ints for GTE in PS1 emulators, because it is afterall fixed point. The better emulators used this, but the open ones didn't seem to. I remember trying to convert some to this (one that may not have been open source, I don't remember). Anyway, this is necessary for full precision, but I have been told that the VFPU's precision is sufficient. Which is good because MIPS is almost as bad as with 64bit int as it is with 64bit floats. VFPU is 32bit float, but the intermediate calculations (multiplies + adds) are probably handled with more precision than this.

I assume the "core 0" that exists right now is a threaded interpreter. Turning that into a "full" dynarec shouldn't be too hard (path I took with gpSP). Fortunately MIPS opcodes are easy to emit.

Hopefully GPU -> GU will go down well, I don't know all of the specifics but I bet PSP is up for the task. It has all of the basic OpenGL features, plus (as far as I'm aware) the ability to take textures from anywhere in VRAM and hopefully the ability to render outside the framebuffer too, if it has that I bet there won't be problems mapping the GPU straight to it. Unfortunately PSP doesn't have a lot of VRAM so you can't really enhance the PS1 display much.. but it'd be great if you could at least store PS1 VRAM completely in PSP VRAM with an exact 1:1 mapping. It'd be very fast and accurate.

1) GTE : an example is much speaking, take "rtps";
it takes a rotation matrix that multiplies a vector then translate the result vector then project it in 2D. The rotation multiplication with a vector can be done totally with a simple VFPU instruction without loss precision. But addition with translation vector can overflow, so you just need to convert the result vector in integer then use a 64-bit addition with translation vector (which wouldn't take more than 4 or 5 instructions). Anyway I need to retrieve them like integers so I can set the GTE FLAG register in case of overflow as a real GTE would do. However I wouldn't expect a real speedup but it shouldn't be worse than using double. Another possibility is to work on 64-bit integer and use "madd" instructions but you need to do inline assembly as well since gcc doesn't seem to generate them implicitely :/

2) CORE0 generates a sequence of instructions "terminating" with a "jr $ra" instruction so it can return to the dispatcher for each "recompiled" instruction. A further step would be simply to remove this instruction so that we may execute the biggest sequence possible. Another thing is to translate jump and call as possible which can be done two ways : to keep a map of source and target address to patch at the end of a recompilation and before execution or to insert a temporary jump to a function which would patch this jump with the right address. Previously, I did some tries with a very simple recursive recompile function that works well with my small PSX-like code test, but I can imagine for a very big code, you may exceed the PSP stack and crash :/.

3) I'm working on GPU->GU. The best thing to do is to use the same operation on GU if it exists. Well, I suppose if I could find some open source on good GPU OpenGL plugin (I found two but they sounds incomplete), it may help with me to avoid some caveats and to be aware of some hacks. It's my currently priority : to have a working GPU->GU with an exact 1:1 mapping. I think we can do it though I probably need to dig more about GU and OpenGL since it is not something I used to use.

oh my god , i would like to sleep but i cannot :/

[Exophase]

This is a bit far off, but if you ever get recompiled GTE working you can use liveness analysis to reduce the flag generation. You'd probably eliminate most flags this way since they're not often used. Course, you could also cache the GTE registers in VFPU ones this way.

The overflow is for 44 bit fixed point, right? I don't really understand why it can't overflow intermediately, for each of the multiplies + adds in the dot products, you can have results much larger than 32bits. I imagine that the calculations are all 44bit internally on PS1.. maybe PSP's VFPU has a lot of internal precision and overflow flags too?

Also, even with enough bits you don't necessarily have the exact precision to represent 32bit fixed point in 32bit floating point. Hopefully what you do have is "close enough."

I think there is actually an option to tell GCC to generate MADDs. It usually avoids them because they're usually not worth it (because of having to play with the hi/lo registers), only really when doing exactly these vector operations. But if precision/flags are not an issue there's no way you'd get anything near the performance with madd as you would with VFPU.

[hlide]

This is a bit far off, but if you ever get recompiled GTE working you can use liveness analysis to reduce the flag generation. You'd probably eliminate most flags this way since they're not often used. Course, you could also cache the GTE registers in VFPU ones this way.

The overflow is for 44 bit fixed point, right? I don't really understand why it can't overflow intermediately, for each of the multiplies + adds in the dot products, you can have results much larger than 32bits. I imagine that the calculations are all 44bit internally on PS1.. maybe PSP's VFPU has a lot of internal precision and overflow flags too?

Also, even with enough bits you don't necessarily have the exact precision to represent 32bit fixed point in 32bit floating point. Hopefully what you do have is "close enough."

I think there is actually an option to tell GCC to generate MADDs. It usually avoids them because they're usually not worth it (because of having to play with the hi/lo registers), only really when doing exactly these vector operations. But if precision/flags are not an issue there's no way you'd get anything near the performance with madd as you would with VFPU.

1) I map GTE registers on VFPU indeed in integer forms, that is on 4 matrixes. To calculate, I convert them to float with the needed precision then make some float operations then convert them back to integers. VFPU being undocumented, i don't know how to get the flags directly from float and for MAC0/1/2/3 you cannot do it on float because of loss of precision : IR0/IR1/IR2/IR3 are truncated part of MAC0/1/2/3 so you will loss the less significant bits in IR0/IR1/IR2/IR3 and have a different behavior than a real one.

EDIT: I'm probably wrong since IR0/1/2/3 keep the least significant bits and if overfow they are clamped values of MAC0/1/2/3. It is only MAC0/1/2/3 that would be different, I guess. I may need to rethink...

Why I cannot map GTE register in float forms, because some GTE instruction expects to find some input registers to be set in one of two representations 1:31:0 or 1:19:12 (outer product op0/op12 for instance) so you will have a loss of precision from the begining !

2) I think "madd" can be a good use for 64-bit integer calculations as it can add and multiplies 64-bit integers in one instrcution (but i don't check its count cycles, that's true). You simply need to set lo/hi registers at the begining and get back the lo register at the end after three "madd"s to calculate rx = vx*r11 + vy*r12 + vz*r13 + trx for instance. Here just set lo/hi with trx and then use 3 "madd"s to get back rx from lo register. It doesn't look bad for me, or am I wrong ?

[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..)

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).

2) I expect madd to be one cycle, and it's true that it is pretty good compared to what you'd be doing otherwise. The annoying thing is that you have to pull all of those values into registers, although that isn't too bad either. Still, it's dozens of instructions for a matrix multiplication alone. On VFPU it's only one instruction..

[hlide]

This is a bit far off, but if you ever get recompiled GTE working you can use liveness analysis to reduce the flag generation. You'd probably eliminate most flags this way since they're not often used. Course, you could also cache the GTE registers in VFPU ones this way.


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.

[NoQuarter]

I love reading things over my head...

Great job hlide for taking on this project,thank you.
I just started using exophase's emu and I must say it's phenomenal!
Thank you both for your efforts :)

[dagger89]

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

[Exophase]

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]

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]

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

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]

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]

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 :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!

[Exophase]

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]

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

[Exophase]

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

I'm always calm here. :) Just seriously spoken.


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

Thanks.. I think?


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*"

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..

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)


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.

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..


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

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..


But to me, it seems like you are really desperate to see this real

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.


, I have been seeing you post in the topics dedicated to PSX on the PSP a lot. Why you do it?

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..

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.


Not sure.... But don't take anything someone says too personal =P

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.


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

Thanks *_*

[pkmaximum]

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"

[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! :cool:
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. :eek:

[Vega]

Its great that more coders are working on PS1 emulators for our PSPs. Lets hope we actually get a sniff at them.

[hlide]

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.

If you did reverse-engineer his eboot.pbp (a simple .elf file to disassemble) you will found out it is a PCSX 1.5 version using Peops GPU Soft. The last beta he compiled should be a PCSX 1.6 beta version. He got rid of PMF version.

[Apoklepz]

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.

[Tinnus]

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.

[hlide]

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.

sure I didn't think there is one here.

[DPyro]

Wouldn't hlide need to have PSP coder usergroup in order to access those forums :rolleyes:

[quzar]

Wouldn't hlide need to have PSP coder usergroup in order to access those forums :rolleyes:

http://www.dcemu.co.uk/vbulletin/forumdisplay.php?f=77 newb =P

[DPyro]

Ah..I thought you meant the private forum :p

[hlide]

what must I do ? I'm lost.

[JKKDARK]

Ah..I thought you meant the private forum :p

wait, is there a private forum for the mods/admins here? =P

[hlide]

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.

faster : which ratio ? 1% 5% 10% 25% 200% :p

[Tinnus]

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.

[hlide]

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.

[Tinnus]

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.

[quzar]

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.

[hlide]

as you wish

[DPyro]

Well it appears your a PSP Coder now :)

[hlide]

arf ! ok i'm checking it

[Tinnus]

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

[quzar]

Considering you released your daedelus mod thinger within two weeks of you joining here, i think you had released something prior to being codered ;)

[Exophase]

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.

Yeah, you're right, with the saturation they should be okay.


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.

For the interpolation they probably usually won't, isn't it usually used for color?


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 of course I didn't realize the existence of the vslt instructions, in fairness you just found them so that changes things a lot. What I was saying is that you can keep the GTE flags in their separate VFPU registers if possible (if you have room) and only do the conversions when you need it.


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

I'd have to see what kind of layouts you can get away with. 2 matrices is still 32 registers right?


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

Yes, but since you can still statically determine within blocks what form the registers are taking you can at least leave them cached as floating point registers inbetween certain GTE instructions, don't you think? And hope error doesn't accumulate too much.

[hlide]

For the interpolation they probably usually won't, isn't it usually used for color?I guess

Well of course I didn't realize the existence of the vslt instructions, in fairness you just found them so that changes things a lot. What I was saying is that you can keep the GTE flags in their separate VFPU registers if possible (if you have room) and only do the conversions when you need it.

don't worry, i really understand your point.

actually this code has some errors and I found right now a way to squeeze more :

____________________
viim.s S011, 16384 # 1<<(26-12)
viim.s S010, 8192 # 1<<(25-12)
vadd.s S012, S011, S011 # 1<<(27-12)
viim.s S000, 8
vscl.t C000, C010, S000 # [1<<(30-12),1<<(29-12),1<<(28-12)]

lvi.t C020, [-2147483648.0, -2147483648.0, -2147483648.0] # TOFIX they must be 43-bit limit not 30-bit limit :/
lvi.t C030, [+2147483647.0, +2147483647.0, +2147483647.0] # TOFIX

vslt.t C020, C130, C020 # cn[i] = MAC[i] < -2147483648.0 ? 1.0 : 0.0
vsge.t C030, C130, C030 # cp[i] = MAC[i] >= +2147483647.0 ? 1.0 : 0.0

vdot.t S100, C020, C000 # Ap = (cp[0] * 1<<(30-12-i)) + (cp[1] * 1<<(29-12-i)) + (cp[2] * 1<<(28-12-i))
vdot.t S133, C030, C010 # An = (cn[0] * 1<<(27-12-i)) + (cn[1] * 1<<(26-12-i)) + (cn[2] * 1<<(25-12-i))
vadd.s S133, S100, S133 # (FLAGS >> 12) = (An + Ap);
...
___________________________

funny to think that you can use a dot product to merge bits :). Well, i hope it is only 1 cycle :/

when you try to read FLAG (S333) with "mfc2 rd, FLAG", you just need to :
transform FLAG content into integer, test a mask to see if you need to set CHKSUM bit to 1 and shift all to left 12 bits. (I don't see why we need to do so after a gte instruction, to do so just when reading FLAG should be enough instead). Of course if we could set the other bits only when reading this FLAG that would be better but is more difficult because you need to pre-analyse the code to generate.




I'd have to see what kind of layouts you can get away with. 2 matrices is still 32 registers right?

yes : 4 x 4 = 16 registers, so you need 2 matrixes for 32 registers. GTE has 64 registers indeed so 4 matrixes. My GPR dnd GTE registers are loaded and stored in VFPU registers. The 2 left matrixes are scratch matrixes. For MDEC (i'm planning to use the VFPU vbfy1/2 "butterfly" instructions i recently digged in MDEC algorihtm) I maybe need to "steal" some matrix to GTE, since I don't think MDEC is used in conjonction with GTE. Keep in mind that GTE register has integer form, if you want all them to be float, you will need nearly 8 matrixes if I remember well.





Yes, but since you can still statically determine within blocks what form the registers are taking you can at least leave them cached as floating point registers inbetween certain GTE instructions, don't you think? And hope error doesn't accumulate too much.
_______________ DeViL code >8>=>
lwc2 MAC1, 0(a0)
lwc2 MAC2, 4(a0)
lwc2 MAC3, 8(a0)
...

bltz a1, t0, 0f
nop
jal gte_gpl12
...
b 1f
...
0: jal gte_gpl0
...
1:
swc2 MAC1, 0(a2)
swc2 MAC2, 4(a2)
swc2 MAC3, 8(a2)
...
_______________

how do you know ?(a0) contains indeed a [1:3:12] format or a [1:16:0] before encountering the real GPL12 instruction ?
and how you will store ?(a2) ?

[zodttd]

I believe MDEC is completely seperated from the GTE. So there should be no worries there, the two shouldn't "mix".

[Zaitmi]

Sorry, I'm a little slow... but is dynarec implemented in this emulator already?

[hlide]

dynarec is done at 90%, still need to make GTE, COP0 and HLE dynarec.
what is missing is a complete hardware emulation (GPU, CDR, SIO, etc.)
So there is a dynarec but not an emulator. Normally i'm pairing with another developper to make a complete emulator and waiting for an SVN access to develop together.

[tsurumaru]

dynarec is done at 90%, still need to make GTE, COP0 and HLE dynarec.
what is missing is a complete hardware emulation (GPU, CDR, SIO, etc.)
So there is a dynarec but not an emulator. Normally i'm pairing with another developper to make a complete emulator and waiting for an SVN access to develop together.

Hi hlide.

This may be unfeasible, but if you have an almost complete dynarec, and the Anonymous Coder has an emulator without a working dynarec, why don't you ask Wraggy to put you guys in touch and see if you can't collaborate....?

[Exophase]

He wants to promote new emulators written from scratch.

[tsurumaru]

He wants to promote new emulators written from scratch.

Well thats an honourable enough intention, I didn't realise though, is the Anonymous Coder's emulator a PCSX port?

[hlide]

Hi hlide.

This may be unfeasible, but if you have an almost complete dynarec, and the Anonymous Coder has an emulator without a working dynarec, why don't you ask Wraggy to put you guys in touch and see if you can't collaborate....?

well the way I want my dynarec to run is not totally compatible with his emulator which is undoubtedly derived from pcsx-like emulator since it is very specific to psp. I mean I cannot even use my dynarec for another MIPS-based platform. What you need is not to adapt the dynarec to the emulator but to adapt the emulator to the dynarec if you want to retain all its potentiality. Which is basically the same as rewriting from the scratch.

[wraggster]

this is turning out to be a very interesting thread, not that i get a chance to read threads these days, too busy /too tired :)

[zodttd]

It most surely is wraggster. :)
With such amazingly talent centered on this project, it will be good to stay on top of this one.

[mr_nick666]

this is turning out to be a very interesting thread, not that i get a chance to read threads these days, too busy /too tired :)

I agree :D I dont understand 90% of it but I keep reading and being fascinated! :p Every day is a school day at DCemu ;)