raphael’s devblog

Finally, the first public beta of my motion kit driver for the Neoflash motion kit.

You can find the Neoflash motion kit here:
http://www.neoflash.com/forum/index.php?topic=4644.0 http://www.neoflash.com/go/index.php?option=com_content&task=view&id=189&Itemid=37

It currently only works for custom firmwares < 3.71, though a simple NID fix should make it work on 3.71 too. I didn’t release that version yet because I couldn’t test it, but it will be available with the final 1.0 release.

The motion kit driver allows you to make use of the motion kit in the VSH or games even though they weren’t written for the motion kit. A configuration file allows you to setup the driver per homebrew/UMD game, so you don’t have to use the same configuration everywhere.

Also, the driver fixes the missing sound issue with the motion kit plugged in and allows you to switch between motion kit and headphones any time without problem.

The SDK provides the source for compiling libmotion_driver that allows you to interact with the driver and poll motion kit data, as well as source for a small sample application that shows usage.

DOWNLOAD

If you wonder where the last announced releases are, well, the effort with the motion kit driver was unexpectedly higher and kept me busy the last week. However, I am now in the state to do the final testing and polish on the motion kit driver before I roll it out to everyone. After that I will finish up JoySens 1.4 and release that as well.

Together with the motion kit driver, I will release a small SDK that allows developers to make use of the driver for their own homebrew creations. This guarantees that an already installed driver by the user will not interfere with the homebrews own implementation of the motion kit communication and allows the developer to influence the drivers behaviour. For the developers, that already want to start developing a game for the motion kit and want to be compatible with the driver on it’s release, you can find the header for the motion kit driver library here.

For the end-users, the first release of the motion kit driver will allow you to make some basic input through the motion kit to any of your homebrew or UMD games, without them having to be specially programmed for that. This will be achieved by forwarding the motion kit input to user specified buttons of the PSP, so the homebrew/UMD game is just handling the normal inputs. Also, those buttons can be adjusted in a configuration file per homebrew/UMD.
Also, the driver will be able to track plugging the motion kit in and out at any time and is even compatible with inserting the headphone remote, so you can at any time change the motion kit support for headphones, even in game. However, the first release will probably not yet contain a fix for the sound output problem, since I still haven’t found a viable solution to this. I’m still working on reverse engineering Sonys remote driver code to find a possible software solution that will be compatible with normal headphones/remote being plugged in.

Well, the Rubik’s challenge is over and as the interested people may have noticed, I missed getting my cube done in time. I could have submitted a working cube without any interface, but I hate such unfinished things. Well, I’m still working on my Rubik’s cube but am currently stalled by an ugly graphical glitch that I can’t seem to get rid of – oh the joys of PSP graphics programming

Apart from that I got a (gratefully sponsored) PSP Motion kit from neoflash.com today, so I’m up to writing a CFW plugin that allows users to enjoy the motion kit with all homebrew and UMD games. I’m still thinking about a good way to map the motion input to the PSP’s default control input. Currently I’m aiming at a per-homebrew/UMD game config file, that allows you to forward the motion input to any combination of the PSP’s controls – with or without disabling them. The only problem left is the disabled sound. The joy of the motion control gets hit a lot by the silence and the only solution I found till now is a hardware solution, but I’m still aiming at a possible software solution.

PS: JoySens 1.4 is in the works as well and should be released in a hand full of days (possibly a few more). It’s going to contain a fix for the broken primary button mapping, keep backlight on when the analog is pressed, disable the input when HOLD button is set as well as contain the possibility to set different configurations for VSH and game/UMD.

I just wanted to inform you that I am taking part in the devsgen.com Rubik’s challenge and I’m trying to win the price of $500.  I don’t want to give out too much information at that point, since the deadline is still too far and the competition is tough , but I can say that this is gonna be my most complete and cleaned-up homebrew for PSP.

I’m very interested in that challenge, since I find it more appealing than most other coding competitions where people can enter things they are working on for ages already and then outrule anyone that started a project specifically for that competition.  Also it gives much more possibility to show the coding skills and compare them to the other entrants, so the judging will be much more objective (or at least so I hope). I also like the fact that the source code also gets judged, since that really forces people to think about their code design, rather than club everything together so that it just plain works somehow (and I’m one of the many that suffer from the lazyness of proper code layout and commenting unless forced to ).

I really hope there are more such challenges in the future and I’m looking forward to the other entrants’ versions of a Rubik’s cube for  the PSP

So look forward to September 30th  when the result is revealed.