Quote:
Originally Posted by Shin_Gouki
Now thats some Error stuff:
UPDATING DISPLAY BECAUSE HAVEN'T HAD ONE
interrupt!
Exception 0
|
I included a log4j.properties in the latest ZIP; I'm guessing the one you made has logging turned up a bit too high
As I say, if you have an audio CD handy; make a CUE/BIN of that and play it in the BIOS CD player ;-)
Quote:
Originally Posted by Shin_Gouki
Besides believe it or not this is already plenty. Understanding your GPU handling , another. Still many pieces of code seem clean and concise. Absolutly awesome stuff! Just from guessing its unbelieveable how much effort you put into this!
|
Yeah, some code is clearer/better than others; I will try and add more comments etc. once it is open sourced - but my failure to do so for the last few years is why I hadn't open sourced in the first place, so we'll go with what we have I guess ;-) At least all the code is in roughly the right place now, even if you don't want to look to hard at the implementations!
Note the GPU is kind of cool, 'cause I get the VM to do a lot of the hard work for me. Rather than writing 2048 or whatever different renderers (for all the combinations of rendering options) which would be painful, or auto-generating Java source which would be huge, I simply write a single generic renderer class chock full of ifs for all the different possibilities (which would obviously be horribly slow if I actually ran it)
I have empty implementation classes for each renderer, so that I can at least call them from other code.
At run time, my classloader, when asked for a particular renderer class, simply clones the generic renderer, sets static final variable initilalizers within the class according to the particular rendering options, and then hands the class over to the VM.
HotSpot, when it compiles the render method, will realize that the values of the ifs can never change and will strip out any unreachable code as it optimizes - voila instant optimal renderer ;-)
================================================== =================
As a little aside, I thought I'd mention something that is different about JPSX compared to some other emus.
I made the decision early on to try and simulate the real hardware timing.
Thus interrupts happen on a separate thread as close to possible as when they're supposed to (except the CD which I run a little fast when not streaming video, because I'm impatient!)
The CPU thread is also not speed limited in any unusual way, it usually ends up waiting on a VSYNC.
This poses a bit of a problem, since the PSX just usually does this by sitting in a busy-wait loop waiting for a memory location to be changed by the IRQ handler.
Since I don't want to suck all the CPU (and I like playing multiple games at once), the emulator will detect busy-wait loops, and escalate them to a java monitor wait(), which will be notify()ed whenever a new interrupt occurs!
Anyway, while the solution is a nice idea, it can lead to problems in practice. There is at least one bad race condition (bug) in the BIOS code which I have to workaround - it just happens not to cause a problem on a real PSX.
In addition, there are a few games out there which as far as I can tell do some strange CD loading (One of the Madden games did this for sure)... they basically seem to rely on the fact that they will have enough CPU time between CD interrupts to deal with the sector data, but they don't actually do any handshaking between the interrupt code and the regular code.
I could be wrong here. For sure some of the people here know better than me how the CD controller is supposed to work, so I'm super happy to be starting to get it out there. As I say shoot me your email if you want to try it out.
Once a few people have it working correctly, I'll put it up there on google code
Last edited by grahams; August 6th, 2008 at 19:20..
Reason: Automerged Doublepost