0xff

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

After some discussion at worldofspectrum, I learned that the problem with Fuse PSP is psplib’s restrictive disclaimer, which prohibited commercial use of the code. psplib is the library that I initially wrote for fMSX PSP; it is common to all the ports I’ve done to date. While the disclaimer wasn’t actually meant to serve as a legal document (as I mentioned in the forum, I’ve always considered psplib public domain software), Philip’s argument is that it went against GPL, which prohibits user restrictions.

To resolve this incompatibility, I’ve decided to license psplib under the GPL. The library is already undergoing structural changes (parts of it have needed tweaks for a while now), so now seems as good a time as any. The updated library is in the trunk branch of Fuse PSP’s repository.

Fuse PSP binaries are once again downloadable.

One feature that both fMSX and Atari800 could use is auto ROM type selection, as I’m sure I’m not the only person who finds selecting correct type of ROM an annoyance. I’d like to ask those of you who are dedicated fans of fMSX or Atari800 for help.

The method I have planned involves mapping a ROM CRC32 value to specific cart type, maintaining the settings in a growing list. Bunch of these lists would eventually be consolidated into a larger “super list” that would be included with the emulators, effectively eliminating the process of cart type selection (for vast majority of carts, anyway).

If anyone is interested in working to create such lists, please let me know by leaving a comment. Alternatively, if you’re aware of an existing list (perhaps for a different port), it would be great if you could point out the location. Thanks

If you’re a PSP developer and/or considering developing wifi-enabled applications for the PSP, you might find this Adhoc Matching Diagram helpful. While it doesn’t explain everything in detail, it provides general idea on the steps that the generic PSP wi-fi enabled application takes, when setting up matching.

Ad-hoc matching is the initial step of setting up communication between PSP units - selecting which machines are going to participate in a communication session. It generally entails sending connection requests, and simultaneously listening for connection-related events (such as incoming connection requests). Because communication is peer-to-peer, the notion of host/client is implied - usually the machine requesting a connection is considered the client, while the machine receiving the connection request is the host.