Could Jpcsp= Psp Emulation For Pandora?


QUOTE
You write a recompiler to Java or JVM, not an interpreter (writing to Java is worse performance-wise). This is easier than writing one to a real machine language though.
Your right, it just didnt sound as good. XD. In most ways it's a simplified dynarec.
 
jaycee900 said:
sold said:
LOL. I believe you meant nucular :lol: j/k

No 'Nuclear' is right, I take it from your spelling your a yank? U 'spell it like it Sounds like' A


I was joking. But I suppose since a certain leader of a certain super power gets it wrong, I see how you may have taken me seriously. :D Also, if you were gonna spell it like it sounds, you would spell it properly cause it sounds like nuclear. :lol:

chad78 said:
Quote from the jpcsp.org forums "at this point no games or demos are running so asking about that is useless! :)"

http://jpcsp.org/forum/viewtopic.php?f=6&t=36



It is running a demo or 2 at the moment as far as I've read. Note the main page and also this topic on the jpcsp forum http://jpcsp.org/forum/viewtopic.php?f=4&t=20

(***DISCLAIMER*** I sort of understand just enough to get by, but have only ever dabbled with Visual Basic and a tiny bit of java stuff a loooooong time ago. I'm not a programmer and will probably never be very good at it so I am not trying to sound like I know what I'm talking about here, i.e. I suck.)

http://jpcsp.org/forum/viewtopic.php?f=4&t=6 <---- it seems you can kinda call into native C/C++ code using JNI. Sounds difficult to me as it would probably mean the dev would have to be good at java and c or c++ to make this approach work.

Does this mean the core program is written in java but utilizes C/C++ for the tricky bits? Is this like a class/library/thingy? Would this mean a performance boost? Or is it basically a complicated load of bollocks? Any clarification would be appreciated.

EDIT: According to kyosys link, several American presidents have had a problem pronouncing nuclear. Scary :lol:
 
Last edited by a moderator:
sold said:
EDIT: According to kyosys link, several American presidents have had a problem pronouncing nuclear. Scary :lol:
Its not really that scary, they are all Southerners (Or, in the case of our current Commander in Chief, pretending to be one). Its just a dialect thing. But really, once you get on the world stage, you have to make the effort not to sound like a hick, rather than embrace it.
 
Last edited by a moderator:
I'm one of the JPCSP dev team. We're coding JPCSP with an interpreter for now. Yes it's very slow and I wouldn't expect for it to run on Pandora. The main reason I decided to help them is because it may be quicker to develop a full Allegrex decoder and interpreter (CPU+FPU+VFPU) this way. So I would see this emulator as a preliminary experience until it would be possible to make it in C/C++ and code a dynarec with a full instruction set and a reasonable HLE set emulation for games.
 
hlide said:
I'm one of the JPCSP dev team. We're coding JPCSP with an interpreter for now. Yes it's very slow and I wouldn't expect for it to run on Pandora. The main reason I decided to help them is because it may be quicker to develop a full Allegrex decoder and interpreter (CPU+FPU+VFPU) this way. So I would see this emulator as a preliminary experience until it would be possible to make it in C/C++ and code a dynarec with a full instruction set and a reasonable HLE set emulation for games.
*Pandora Fan Parser* Wow, Hlide is guaranteeing full-speed PSP emulation at the Pandora launch. I need to go post this in Prophet's emulator sticky *Pandora Fan Parser*
 
Last edited by a moderator:
hlide said:
I'm one of the JPCSP dev team. We're coding JPCSP with an interpreter for now. Yes it's very slow and I wouldn't expect for it to run on Pandora. The main reason I decided to help them is because it may be quicker to develop a full Allegrex decoder and interpreter (CPU+FPU+VFPU) this way. So I would see this emulator as a preliminary experience until it would be possible to make it in C/C++ and code a dynarec with a full instruction set and a reasonable HLE set emulation for games.
With all those people working on it, especially yourself, you should be able to have a full Allegrex interpreter in no time flat at all.
 
Last edited by a moderator:
Good luck with the project hlide. It'd be cool to see jpcsp take off. It looks promising (especially because its active. I wonder if it would work on the eee pc or are the system requirements are too high?
 
I welcome more Java projects, PSP-emulation might not be for the Pandora (regardless of language) but the main problem now isn't speed, it's quality.

All you who complain about the choice of language clearly have NO programming experience whatsoever. Use some JNI (which isn't that difficult) for the most crucial parts if necessary, and OpenGL for rendering and it would run just as fast as any other language.

Bad algorithms/datastructures makes code slow most of the time, so in that case Java is a much better choice than lower lever languages.
http://kano.net/javabench/data - The difference is either in Javas favour or basically no difference in everthing more advanced the a straight number crunching loop.
http://kano.net/javabench/ - Try for yourself. I'm going to do it now, just out of curiosity.

Edit: I didn't quite like these benchmarks. Including the startup time for the JVM? Nonsense. Second, they are still mostly number chrunchers, not real software. If one were to draw some graphics, using hardware through OpenGL, the performance would probably have been almost the same.
 
Drawing is not an issue at all, several benchmarks have shown that even python (and sometimes perl) are often faster than c at opengl.

I'm curious what will come of this project, since it makes my idea of writing an emulator in RPython (PyPy) much less crazy.
 
Micket said:
I welcome more Java projects, PSP-emulation might not be for the Pandora (regardless of language) but the main problem now isn't speed, it's quality.
Speed is an important factor in emulation quality.

Micket said:
All you who complain about the choice of language clearly have NO programming experience whatsoever. Use some JNI (which isn't that difficult) for the most crucial parts if necessary, and OpenGL for rendering and it would run just as fast as any other language.

Bad algorithms/datastructures makes code slow most of the time, so in that case Java is a much better choice than lower lever languages.
http://kano.net/javabench/data - The difference is either in Javas favour or basically no difference in everthing more advanced the a straight number crunching loop.
http://kano.net/javabench/ - Try for yourself. I'm going to do it now, just out of curiosity.

Edit: I didn't quite like these benchmarks. Including the startup time for the JVM? Nonsense. Second, they are still mostly number chrunchers, not real software. If one were to draw some graphics, using hardware through OpenGL, the performance would probably have been almost the same.


You criticize other people for having no experience programming and say that Java is a better choice than lower level languages, but I have to ask, do you program emulators? Because in my opinion emulators have done quite well without being written in Java, and really Java doesn't offer very much to improve programming emulators unless your mindset is heavily slanted towards it to begin with.

Emulators are also a lot closer to "number crunchers" than a lot of the "real software" you might be thinking of.

And using JNI completely defeats the purpose of using Java for this team, which is for portability.

I explained why a Java based recompiler has potential shortcomings and is inflexible compared to what you can do if you roll your own. You can take it or leave it. I'm not sure JPCSP will actually go that far though.
 
Last edited by a moderator:
ingrin said:
*Pandora Fan Parser* Wow, Hlide is guaranteeing full-speed PSP emulation at the Pandora launch. I need to go post this in Prophet's emulator sticky *Pandora Fan Parser*
what !? are you pulling my leg ?
 
Last edited by a moderator:
hlide said:
ingrin said:
*Pandora Fan Parser* Wow, Hlide is guaranteeing full-speed PSP emulation at the Pandora launch. I need to go post this in Prophet's emulator sticky *Pandora Fan Parser*
what !? are you pulling my leg ?

Yep ;)
 
Last edited by a moderator:
Exophase said:
Micket said:
I welcome more Java projects, PSP-emulation might not be for the Pandora (regardless of language) but the main problem now isn't speed, it's quality.
Speed is an important factor in emulation quality.

Micket said:
All you who complain about the choice of language clearly have NO programming experience whatsoever. Use some JNI (which isn't that difficult) for the most crucial parts if necessary, and OpenGL for rendering and it would run just as fast as any other language.

Bad algorithms/datastructures makes code slow most of the time, so in that case Java is a much better choice than lower lever languages.
http://kano.net/javabench/data - The difference is either in Javas favour or basically no difference in everthing more advanced the a straight number crunching loop.
http://kano.net/javabench/ - Try for yourself. I'm going to do it now, just out of curiosity.

Edit: I didn't quite like these benchmarks. Including the startup time for the JVM? Nonsense. Second, they are still mostly number chrunchers, not real software. If one were to draw some graphics, using hardware through OpenGL, the performance would probably have been almost the same.


You criticize other people for having no experience programming and say that Java is a better choice than lower level languages, but I have to ask, do you program emulators? Because in my opinion emulators have done quite well without being written in Java, and really Java doesn't offer very much to improve programming emulators unless your mindset is heavily slanted towards it to begin with.

Emulators are also a lot closer to "number crunchers" than a lot of the "real software" you might be thinking of.

And using JNI completely defeats the purpose of using Java for this team, which is for portability.

I explained why a Java based recompiler has potential shortcomings and is inflexible compared to what you can do if you roll your own. You can take it or leave it. I'm not sure JPCSP will actually go that far though.


I don't think speed is the most important concern when the emulators are barely running demos. I like to make software work first, then run fast (and from the looks of it, thats exactly what the JPCSP team had in mind, looking at hildes reply in this thread)

My experience hardly meassures up to what you know. From what's worth mentioning, I've worked on a NSF-emulator/player, which was put on hold but it gave me at least insight into what emulation is.

About JPCSP, I really can't find information that they chose Java due to portability. I'm browsing through their forums but i can't seem to verify that claim at all (neither from hilde in this thread either). Introducing JNI for number chrunching parts (as the JPCSP admin said he might on their forum) doesn't hurt portability the slightest, as compiling it again is trivial. The system specific code could hurt portability, and using Java is one convenient way to avoid those problems.
But thats not the reason I would have to chose Java. It's just usually more convenient to work with higher level languages, less bugs, faster developement, thus more time over for important parts.

But OK, i came on too strong. Due to the nature of emulation, C/C++ is probably very suitable in many ways, but i still don't think it's a bad idea at all go work with Java on this project.
 
Last edited by a moderator:
Micket said:
I don't think speed is the most important concern when the emulators are barely running demos. I like to make software work first, then run fast (and from the looks of it, thats exactly what the JPCSP team had in mind, looking at hildes reply in this thread)
It certainly isn't the most important concern, but in the long run it is a concern at any rate. Most emulator authors will not focus on an optimal speed solution from the start, but will have some of these things in mind such that the initial design is compatible with it. This includes language decisions. It's interesting that hlide is using JPCSP as a testing ground for later writing an emulator in another language.

Micket said:
My experience hardly meassures up to what you know. From what's worth mentioning, I've worked on a NSF-emulator/player, which was put on hold but it gave me at least insight into what emulation is.
I think that would give you insight. The point I want to make is not that Java is unsuitable for emulation (because it's a fine language for writing one in), but that in general C can be almost as good. I say this because emulation designs tend to be more "wide" than "deep" in OOP hierarchical terms, and there needn't be a lot of heap allocated data structures running around dynamically, nor really a lot of data structures in general. OOP emulator designs tend to consist of several singleton classes which is not really an advantageous design over a struct + several functions working on it.

Micket said:
About JPCSP, I really can't find information that they chose Java due to portability. I'm browsing through their forums but i can't seem to verify that claim at all (neither from hilde in this thread either). Introducing JNI for number chrunching parts (as the JPCSP admin said he might on their forum) doesn't hurt portability the slightest, as compiling it again is trivial. The system specific code could hurt portability, and using Java is one convenient way to avoid those problems.
But thats not the reason I would have to chose Java. It's just usually more convenient to work with higher level languages, less bugs, faster developement, thus more time over for important parts.
They didn't say specifically that this is why they're doing it, but it has been alluded to several times and brought up as a key point in response.

One example

http://jpcsp.org/forum/viewtopic.php?f=4&t=11

I think the things you've mentioned are fine, if they really apply. It's too easy to gloss over a language being "higher level" and thus automatically improving the quality of production for anything you write for it. This is not the case.

A lot of people are especially defensive of Java, I think because of Sun's approach with it. They've been determined to make it a commercially viable language (and in many ways have succeeded), and to do so they had to position it as a language that is highly general purpose and competitive with all others on all grounds. This mentality has trickled down to a lot of the more hard core Java users. You can use Java for anything, but sometimes it really isn't ideal. In some cases (IMO this one), it's just a matter of hitting a nail with a giant mallet. In other cases it's an outright hindrance. But, if Java is the language that you use then all the more power to you - I think when you get down to it it's about the programmer and melding well with a language will give you far more success than using a "better" one that you don't fit with. In cases such as this anyway.

Micket said:
But OK, i came on too strong. Due to the nature of emulation, C/C++ is probably very suitable in many ways, but i still don't think it's a bad idea at all go work with Java on this project.
It's not a bad idea. I think the real reason they're using Java is because Java is what people know, and people who don't know Java are usually comfortable learning it (rather than the other way around). Afterall, Java is what is being taught as a core language at universities, even where C is used as an intro Java is what they teach people to be meaningfully good at (or its counterpart C#).

When you look at the nature of this project, it's really very interesting. A whole ton of people, who have an intermediate or so knowledge of these things are chipping in bits of code incrementally. If anything Java is acting as a good vehicle for a highly open source, collaborative project. It'll be interesting to see where it goes from here. I might start checking it out and looking at the commits just for the fun of it.

The thing is, if the team ultimately just care about getting something that works for purposes of discovering how to emulate the PSP (which is not just a learning experience for them, but really important for people who will want to do it later) then portability shouldn't matter. Not if it isn't going to fast enough for too long, although possibly they can achieve speed regardless. I would definitely pick C (although C++ has compelling features like templates, just more used to C), and if all the people interested in working on this preferred C or C++ then it'd be in C or C++. That's how I see it anyway.
 
Last edited by a moderator:
You make alot of good points, but my initial reply was really directed not to you (as i know that you know what you talk about) but to those who went "Eww slow!".

I won't make guesses at what programming experience the JPCSP-developers have, but from what i've seen i gather they know more than just Java.

I'm all for choosing the right tool for the job. At work i constantly shift between MATLAB, Fortran, C/C++, Python, Shell scripts, maybe even some haskell, and surprisingly little Java (since the tools i build are very problem specific with almost only me as it's userbase).

Maybe I'm just to tired to see segfaults and memory leaks. Even with skilled developers these don't tend to go away completely until the projects reach a VERY mature state. Memory management is a big help, Alot of the times the problems doens't really occur in the actual engine, but rather in GUI's and things that doesn't really need the maximum performance.

Anyway, I'm going to grab a SVN-checkout when i find the time, this project looks very interesting.
 
Micket said:
Maybe I'm just to tired to see segfaults and memory leaks. Even with skilled developers these don't tend to go away completely until the projects reach a VERY mature state. Memory management is a big help, Alot of the times the problems doens't really occur in the actual engine, but rather in GUI's and things that doesn't really need the maximum performance.

Anyway, I'm going to grab a SVN-checkout when i find the time, this project looks very interesting.
Although this is kinda straying off path, just want to reiterate that the nice thing about emulators is that they're not shuffling a lot of dynamic data structures around so you really don't need garbage collection (if they are you probably did something unnecessary). When segfaults come up they're easy to eliminate and tend to not be finicky.

On the other hand, determining why an emulated game doesn't work can be a hundred times harder than fixing memory bugs :\
 
Last edited by a moderator:
Back
Top