There are no major changes to report with this update; it synchronizes the PSP version with the Marat’s official distribution. There are changes to the VDP (video) code, although I haven’t noticed any differences in rendering or performance.
August 13th, 2008 Posted by Akop in fuse, psp, release
This is a small update to fix current known issues. Changes in this version:
August 9th, 2008 Posted by Akop in psp, sms plus, todo, wifi
Here’s a preview of the SMS Plus emulator, with adhoc wi-fi gameplay support (ignore the idiotic clicking - it’s caused by the camera’s zoom lens):
As you can see, a large part of the work is done. There are still some things that need polishing, however:
Cheers,
Akop
August 7th, 2008 Posted by Akop in psp
I have spent the last few days (weeks?) rewriting psplib into its successor library, libpl. Most importantly, graphics, font and image rendering core is being rewritten from scratch; it’s already significantly better than the older version. Among changes so far:
Future plans:
Simple “upgrading” to libpl from psplib no longer seems possible; therefore, emulators will have to be largely rewritten to use the new library. Once the work is finished, I also hope to have some sample code available, in case anyone wants to write applications based off the library.
If you’re interested in the progress, you can find semi-nightly builds in the libpl directory, under the trunk branch of the svn repository. No promises on the code actually compiling (or doing anything useful, for that matter)
Many thanks to the ps2dev/psp forum folks for their helpful answers to many of my questions.
July 31st, 2008 Posted by Akop in psp, rant
I finally broke down and bought a component cable, to be able to play PSP games on a TV. The experience was… disappointing, to say the least. The entire PSP screen takes up a fraction of the television’s screen, somewhat killing the point of having a TV cable. The XMB/DVD playback screen is larger (it’s displayed in interlaced mode), but still relatively small.
This probably wouldn’t be that big of an issue, if the cable worked on traditional TV’s (it won’t, unless your TV supports progressive scan), but it doesn’t, and using it on a big-screen TV kinda makes you wonder why the whole thing was put together in the first place.
July 28th, 2008 Posted by Akop in fuse, psp, release
This update fixes the following issues present in version 0.9.0.2:
Updates from 0.9.0.1 (just to reiterate):
July 27th, 2008 Posted by Akop in fuse, psp, release
New in this version:
This version also includes extended DSK support; however, this does not seem to work correctly at the moment. Since the next version of Fuse is going to have drastically revamped 765 support, I’m probably not going to work on this until the next version.
UPDATE At least one user has reported palette corruption problems, so I’m pulling the new version down until I can revert the psplib code back to an older version. Please bear with me, and if you have the version originally released, please don’t distribute it.
July 27th, 2008 Posted by Akop in fuse, psp
Most of the bugs/known issues from the last release of Fuse PSP have been fixed (the sole exception being the speed of tape loading, and there’s not much that can be done about that).
Next version will also include a bunch of new features and improved hardware support — exact details are currently being worked out.
July 24th, 2008 Posted by Akop in fuse, psp
I tracked down the source of the tape loading freeze: the problem is in the sound code, and should be fixed in the next release.
July 20th, 2008 Posted by Akop in development, psp
In the process of making changes to psplib’s video rendering routines, I came across a strange problem - calling a certain library function resulted in screen and palette corruption. Since the function was used to access contents of the VRAM, I figured it was because I was writing to the wrong location in memory somewhere.
The strange thing was that I had a similar function already in place, and except for some minor semantic differences, the code was the same. Even more surprisingly, commenting out the code that called the function did not help - the only thing that did was completely removing the function’s definition.
I finally tracked down the problem to the compiler’s optimization flag (O2). Completely disabling optimization with (-O0) got rid of the corruption. I’m not sure if this will have any detrimental effects on the rendering library in terms of speed (I doubt that it will, as psplib’s renderer is extremely frugal), but I suppose that I’ll eventually find out.
UPDATE It looks like optimization (much like the proverbial chinaman) is not the main issue here. While I haven’t completely resolved the issue, it is fairly certain that it’s related to reading/writing to VRAM. The issue seems to be commonplace, and I’ve found possible explanations here and here (see section marked Important).