I haven't done any programming in a while now. It's probably because the PSP plugin I was trying to make was totally pwned by another person's plugin.
The plugin is another attempt to allow a user to organize games and applications into folders on the PSP, and it does the job in a much better way both interactively and programatically, and I wave the white flag and now use it myself.
It's also because I can seem to find the time I need to really get into programming. I really don't want to break my time down for you in order to illustrate, but four hours of programming sometimes just doesn't seem to cut it in order to learn or make something useful.
Perhaps it's just that I don't have a focus right now.
So I've dropped programming for a while and now I'm going back to playing games.
Recently I've started playing Final Fantasy VIII again. It's one of the RPGs I've already finished, but more or less enjoyed enough the first time around to warrant a second playthrough.
The first time I played it, I was in college, and I only rented to play the game, so I didn't have much time to really get into it, nor did I finish it.
The savegame slept on my memory card until the day PSX emulation became feasible, and following instructions, I made a memory card reader out of a floppy disk connector and some instructions on the web.
The second time I played it, I between jobs and had so many games to play that I didn't really bother to spend the time to get to know the game that well.
I'm playing it on my PSP nowadays, more or less for nostalgia than the need to finish it. I could be spending more time on Patapon 2, but I've grown a bit tired of killing bosses over and over again in order to level up my army so I can go back to killing bosses over and over again.
Maybe it's my video card, but Resident Evil 4 gets me motion sick after a few minutes of play. Then again I was never really a fan of first-person-shooters.
I haven't touched Final Fantasy X in a while. I'm using PCSX2 to emulate it (I don't own a PS2), and fortunately my video card can crank enough polygons per second to make it playable.
It'd be nice to own a PS2 and play all those great games, but I can't bring myself to shell out some money to buy a second hand unit and some games with scratched or second-rate DVDs.
Maybe if someone sold me one for Php 4,000, I'd bite. But that's almost a new Inno3D GForce 9600 GTS DDR3.
Thing is, I'm not even much of an avid PC gamer.
*sigh*
Monday, March 23, 2009
Tuesday, March 10, 2009
Hitched!
After five years, we finally got married!
My dear Fransly and I tied the knot on February 28, 2009 at the Hearts of Jesus and Mary Parish Church, at West Triangle subdivision in Quezon City.
My father decided to come late to the church, but I didn't let that ruin the day for me. The road leading to the front of the church was torn up for repairs/renewal, but I didn't let that ruin the day for me.
The cloudless day brought a heat wave but also gave perfect lighting for picture-taking. Hats off to the Ariel Javelosa team for grabbing such lovely pictures. Thank you Max!
Reception was held at the Gazebo Royale's Champagne hall, where we surprised everyone (photographers especially) by running down the red carpet to the front of the pavillion where we had our first dance that rocked the crowd and really set the mood. I have Donna to thank for coreographing, and Tina and Onchit for joining us in the dance.
Dinner was quickly served. We didn't get to eat much with all the photos being taken, but everyone seemed to enjoy the food served by Eloquente, while Seren8 played our choice of music.
After the AVPs, the games, and everything to everyone's surprise I sang "Beautiful in My Eyes" and though I botched it a bit at the second stanza, nobody seemed to notice.
The deal was, Fransly wanted me to sing either that or "Danny's Song" (I really didn't want to sing the part "I think I'm gonna have a son" because then people might interpret it literally), but wanted it to be a "surprise", so she didn't know when I was going to sing.
I would have wanted to sing "The Way You Look Tonight" using Steve Tyrell's version, which IMO is more jaunty than the original or Buble's, since I know the lyrics better, I might not have botched it. Oh well.
Hitched! provided us with on-the-day wedding coordination and lots of help hooking us up with the wedding band and other details we missed. We couldn't have done it without you.
Partypics provided the photobooth which doubled as our souvenirs.
Overall, it was the best wedding I could have wished for.
To cap it off, we spent another day at the Linden suites, which I didn't really get to enjoy all that much as I had a really bad cough.
Finally, I must thank my dear wifey for rubbing her nose against mine and stealing that kiss (I know it was you!) If not for that fateful day, none of this would have happened, and I wouldn't be as happy as I am now.
My dear Fransly and I tied the knot on February 28, 2009 at the Hearts of Jesus and Mary Parish Church, at West Triangle subdivision in Quezon City.
My father decided to come late to the church, but I didn't let that ruin the day for me. The road leading to the front of the church was torn up for repairs/renewal, but I didn't let that ruin the day for me.
The cloudless day brought a heat wave but also gave perfect lighting for picture-taking. Hats off to the Ariel Javelosa team for grabbing such lovely pictures. Thank you Max!
Reception was held at the Gazebo Royale's Champagne hall, where we surprised everyone (photographers especially) by running down the red carpet to the front of the pavillion where we had our first dance that rocked the crowd and really set the mood. I have Donna to thank for coreographing, and Tina and Onchit for joining us in the dance.
Dinner was quickly served. We didn't get to eat much with all the photos being taken, but everyone seemed to enjoy the food served by Eloquente, while Seren8 played our choice of music.
After the AVPs, the games, and everything to everyone's surprise I sang "Beautiful in My Eyes" and though I botched it a bit at the second stanza, nobody seemed to notice.
The deal was, Fransly wanted me to sing either that or "Danny's Song" (I really didn't want to sing the part "I think I'm gonna have a son" because then people might interpret it literally), but wanted it to be a "surprise", so she didn't know when I was going to sing.
I would have wanted to sing "The Way You Look Tonight" using Steve Tyrell's version, which IMO is more jaunty than the original or Buble's, since I know the lyrics better, I might not have botched it. Oh well.
Hitched! provided us with on-the-day wedding coordination and lots of help hooking us up with the wedding band and other details we missed. We couldn't have done it without you.
Partypics provided the photobooth which doubled as our souvenirs.
Overall, it was the best wedding I could have wished for.
To cap it off, we spent another day at the Linden suites, which I didn't really get to enjoy all that much as I had a really bad cough.
Finally, I must thank my dear wifey for rubbing her nose against mine and stealing that kiss (I know it was you!) If not for that fateful day, none of this would have happened, and I wouldn't be as happy as I am now.
Tuesday, December 30, 2008
Plugins for the PSP - 2
My efforts to ask for any help of the QJ.Net forums on hacking the PSP to add something similar to folders in the GAME menu created a rather lengthy thread that was filled with a lot of critiscm.
Eventually I posted some information that more or less showed that I knew what I was doing, and then the tides turned. Those who were telling me that what I was doing (disassembling the game_plugin module) was next to impossible, was silly, and was clearly the wrong approach, now nodded and said that what I had found was correct, and that they knew that information all along, and even offered me to join a group they were building devoted to hacking the VSH modules.
I don't really see why they are so uptight about sharing that information, when all the stuff they can actually do to hack the PSP was made possible by the sharing of information.
Anyway, I'm once again on my own. I've been a bit busy and I haven't had time to work on this. I shouldn't be spending so much time working on this project, as I'm about to get married in 2 months and there's a still lot of things that need planning and preparation.
With the slightest bit of help I have found the code that executes when the user selects a game, so I'm that much closer to realizing my goal. All I need to find know is how the code passes around the information containing the selected game, but finding this is a bit harder than I expected.
Eventually I posted some information that more or less showed that I knew what I was doing, and then the tides turned. Those who were telling me that what I was doing (disassembling the game_plugin module) was next to impossible, was silly, and was clearly the wrong approach, now nodded and said that what I had found was correct, and that they knew that information all along, and even offered me to join a group they were building devoted to hacking the VSH modules.
I don't really see why they are so uptight about sharing that information, when all the stuff they can actually do to hack the PSP was made possible by the sharing of information.
Anyway, I'm once again on my own. I've been a bit busy and I haven't had time to work on this. I shouldn't be spending so much time working on this project, as I'm about to get married in 2 months and there's a still lot of things that need planning and preparation.
With the slightest bit of help I have found the code that executes when the user selects a game, so I'm that much closer to realizing my goal. All I need to find know is how the code passes around the information containing the selected game, but finding this is a bit harder than I expected.
Wednesday, December 10, 2008
Plugins for the PSP
I've been working on a pet project of mine that I thought would be fun to do. I've been able to write and compile code for running on custom firmware on the PSP for a while now, but I haven't decided on what to do.
I've wanted to make a decent game, perhaps a bike-physics game clone of the one on teagames that I enjoyed so much playing during dull hours at the office, or a tower defense game with nice graphics and interesting weapons.
I've finally got more or less of a hang on the use of makefiles, enough that tweaking them a bit doesn't faze me like it used to. I don't exactly bother to write one from scratch though, as there are still some things I don't fully understand.
I've also enjoyed using plugins, which are really fantastic as it really lets you do so many more things with the PSP than what it can out-of-the-box.
So now I've tried to write my own plugin, based on an existing one, but with different features. It's been considered by some extremely difficult to put folders for games in the XMB. And I wholly agree.
But I've come up with an idea that might work.
When you place a folder in your /PSP/GAME folder that doesn't contain an EBOOT.PBP (the executable) , the XMB will display it as "Corrupted Data". This is just the way it's designed, zero levels deep.
There are plugins that allow you to categorize your games, and by placing them in different folders, you can select which category is currently active, and it displays only those games in the xmb.
These plugins use a button combination or a menu to select the category.
I thought of a way to let a folder show up in GAME, by spoofing an EBOOT when the firmware is trying to read the name and icon for the EBOOT.
The firmware tries to load an EBOOT for each folder it sees in /PSP/GAME. In the empty folder, it tries to load an EBOOT.PBP and as there is none, it fails and tells the firmware that the game is probably corrupt.
With my plugin in place, the code fails, but the plugin catches it and instead generates a fake EBOOT on the fly using the name of the folder and a default icon stored somewhere accessible, and tells the firmware everything is OK, don't worry, there is an EBOOT here.
Right now this is all the plugin does - it just allows folders to be displayed as EBOOTs in the XMB.
Now comes the hard part - intercepting when the user tries to open my fake EBOOT.
Normally the firmware tries to load the game, displaying the gameboot intro before launching the game.
What I need to do is catch the keypress before the firmware does, figure out what EBOOT the user is pointed at, check if it is one of mine, and if so, cancel loading the EBOOT and switch "categories" - folders really - and flush the memory stick cache.
This is where it gets interesting.
The PSP firmware is made up of several modules that load other modules as needed. The vshmain module (?) is the module that displays the top-level menu, the XMB.
When you select a top level item, vshmain (?) loads the approriate module - game_plugin in my case.
game_plugin is now responsible for reading the memory stick, drawing the icons, handling the menu. I'm not sure if it is entirely responsible though, it probably makes calls to other existing modules.
I makes sense that the game_plugin module contains a subroutine for checking if the user has pressed a button, or acting on button presses. What I need to do is patch the module to jump to my own code for checking button presses, before I call the original code.
As of now, I only have a fleeting understanding of how this can be done. With my previous knowlege of patching ROM code, I have some idea, but this is a 32-bit RISC platform with relocatable code, making things much more difficult for someone from a 8/16-bit fixed code background. There is probably some mechanism to locate the module's base entry point, and offset from there to some function.
I don't know how to find that function yet. But I have some ideas.
Learn MIPS assembly.
The module loads gameboot.pmf prior to launching the game. Look for the string gameboot.pmf, and to the code that references it and backtrack until you can find where the button presses are. Hopefully button polling/testing can be easily identified in assembly. (HAH!) NOPping out code is a time-honored method of isolating code.
Patch the code somewhere appropriate to jump to a function in my plugin.
This function needs to know what EBOOT the game_plugin module is currently "looking" at. Even after finding the right place to patch and patching the code, this is much more difficult to do. Perhaps the module's memory space contains an array of paths, and an index to the current entry.
Or perhaps there is a function that does this. With the caching that the XMB implements, this makes things much more difficult. Perhaps recoding a game_plugin is easier in the long run.
One thing fir sure, I would have learned a lot more by the time I'm done with this project, whether it is complete or not.
I've wanted to make a decent game, perhaps a bike-physics game clone of the one on teagames that I enjoyed so much playing during dull hours at the office, or a tower defense game with nice graphics and interesting weapons.
I've finally got more or less of a hang on the use of makefiles, enough that tweaking them a bit doesn't faze me like it used to. I don't exactly bother to write one from scratch though, as there are still some things I don't fully understand.
I've also enjoyed using plugins, which are really fantastic as it really lets you do so many more things with the PSP than what it can out-of-the-box.
So now I've tried to write my own plugin, based on an existing one, but with different features. It's been considered by some extremely difficult to put folders for games in the XMB. And I wholly agree.
But I've come up with an idea that might work.
When you place a folder in your /PSP/GAME folder that doesn't contain an EBOOT.PBP (the executable) , the XMB will display it as "Corrupted Data". This is just the way it's designed, zero levels deep.
There are plugins that allow you to categorize your games, and by placing them in different folders, you can select which category is currently active, and it displays only those games in the xmb.
These plugins use a button combination or a menu to select the category.
I thought of a way to let a folder show up in GAME, by spoofing an EBOOT when the firmware is trying to read the name and icon for the EBOOT.
The firmware tries to load an EBOOT for each folder it sees in /PSP/GAME. In the empty folder, it tries to load an EBOOT.PBP and as there is none, it fails and tells the firmware that the game is probably corrupt.
With my plugin in place, the code fails, but the plugin catches it and instead generates a fake EBOOT on the fly using the name of the folder and a default icon stored somewhere accessible, and tells the firmware everything is OK, don't worry, there is an EBOOT here.
Right now this is all the plugin does - it just allows folders to be displayed as EBOOTs in the XMB.
[screenshot goes here]
Now comes the hard part - intercepting when the user tries to open my fake EBOOT.
Normally the firmware tries to load the game, displaying the gameboot intro before launching the game.
What I need to do is catch the keypress before the firmware does, figure out what EBOOT the user is pointed at, check if it is one of mine, and if so, cancel loading the EBOOT and switch "categories" - folders really - and flush the memory stick cache.
This is where it gets interesting.
The PSP firmware is made up of several modules that load other modules as needed. The vshmain module (?) is the module that displays the top-level menu, the XMB.
When you select a top level item, vshmain (?) loads the approriate module - game_plugin in my case.
game_plugin is now responsible for reading the memory stick, drawing the icons, handling the menu. I'm not sure if it is entirely responsible though, it probably makes calls to other existing modules.
I makes sense that the game_plugin module contains a subroutine for checking if the user has pressed a button, or acting on button presses. What I need to do is patch the module to jump to my own code for checking button presses, before I call the original code.
As of now, I only have a fleeting understanding of how this can be done. With my previous knowlege of patching ROM code, I have some idea, but this is a 32-bit RISC platform with relocatable code, making things much more difficult for someone from a 8/16-bit fixed code background. There is probably some mechanism to locate the module's base entry point, and offset from there to some function.
I don't know how to find that function yet. But I have some ideas.
Learn MIPS assembly.
The module loads gameboot.pmf prior to launching the game. Look for the string gameboot.pmf, and to the code that references it and backtrack until you can find where the button presses are. Hopefully button polling/testing can be easily identified in assembly. (HAH!) NOPping out code is a time-honored method of isolating code.
Patch the code somewhere appropriate to jump to a function in my plugin.
This function needs to know what EBOOT the game_plugin module is currently "looking" at. Even after finding the right place to patch and patching the code, this is much more difficult to do. Perhaps the module's memory space contains an array of paths, and an index to the current entry.
Or perhaps there is a function that does this. With the caching that the XMB implements, this makes things much more difficult. Perhaps recoding a game_plugin is easier in the long run.
One thing fir sure, I would have learned a lot more by the time I'm done with this project, whether it is complete or not.
Tuesday, October 14, 2008
Dead and Alive
Few things that I can really count as strange happen to me.
I would have ignored the fact that my PSP inexplicably died on me, only to have it suddenly return to life, then intermittently work, and finally start working again. I would have relegated it to the perversity of the inanimate.
So it only served to raise the event to even higher levels of mystery when the same thing happened to someone else, at around the same time, and stranger still, to someone sharing my first name.
I'm just glad that my PSP is back and better (except for that piece of tape holding the LCD backlight flex cable to the connector)
I would have ignored the fact that my PSP inexplicably died on me, only to have it suddenly return to life, then intermittently work, and finally start working again. I would have relegated it to the perversity of the inanimate.
So it only served to raise the event to even higher levels of mystery when the same thing happened to someone else, at around the same time, and stranger still, to someone sharing my first name.
I'm just glad that my PSP is back and better (except for that piece of tape holding the LCD backlight flex cable to the connector)
Thursday, October 2, 2008
WiiMote in Action
As you know I got a WiiMote a few months a go for my birthday, but I haven't been using it lately. The lack of buttons makes it difficult to play Final Fantasy X, which is what I'm spending my gaming time on nowadays.
Well, here's a couple of videos of my WiiMote setup in action.
I hadn't setup the Wii "sensor" bar I DIY'd when I made these videos, so there's no point n' click action here yet.
TrackMania Sunrise
Portal
Well, here's a couple of videos of my WiiMote setup in action.
I hadn't setup the Wii "sensor" bar I DIY'd when I made these videos, so there's no point n' click action here yet.
TrackMania Sunrise
Portal
Wednesday, October 1, 2008
Doh!
Fans of Point-and-click games would do well to be aware that Broken Sword 2.5 is out! And it's totally free!
I love point-and-click games (and their precursor, the click-and-type games?) Never mind that I probably haven't solved one yet without the help of a walkthrough.
In fact, I can't wait to have kids, have them grow up a bit and so I can install a PC-based media center with a 42-inch LCD, (or will OLED be the display of choice in the far future?) WiiMotes and ScummVM installed, and introduce them to Those Games Their Father Played Back In Those Days, encouraging them to play them as they will be the only games installed on the PC, and declaring lazy Saturday afternoons as Family Point-and-Click Time.
Oh they will hate me.
When I heard Broken Sword 2.5 even existed, my first thought was - is it ScummVM compatible? Does it use the same engine even?
My second thought was - if it did, maybe I could play it on my...
PSP...
Doh!
(The happy music playing in my head slowed to a stop like an audio tape stuck in the mechanism. Audio tapes? How archaic...)
I love point-and-click games (and their precursor, the click-and-type games?) Never mind that I probably haven't solved one yet without the help of a walkthrough.
In fact, I can't wait to have kids, have them grow up a bit and so I can install a PC-based media center with a 42-inch LCD, (or will OLED be the display of choice in the far future?) WiiMotes and ScummVM installed, and introduce them to Those Games Their Father Played Back In Those Days, encouraging them to play them as they will be the only games installed on the PC, and declaring lazy Saturday afternoons as Family Point-and-Click Time.
Oh they will hate me.
When I heard Broken Sword 2.5 even existed, my first thought was - is it ScummVM compatible? Does it use the same engine even?
My second thought was - if it did, maybe I could play it on my...
PSP...
Doh!
(The happy music playing in my head slowed to a stop like an audio tape stuck in the mechanism. Audio tapes? How archaic...)
Returning Strings from WinAPI in VB.Net
I know this has been covered a lot in other places, but the things is, all their examples have failed to work for me. Here I offer another method, one that worked for me.
Declare Auto Function GetWindowText Lib "user32" Alias "GetWindowTextA" (ByVal hwnd As Integer, ByVal lpString As String, ByVal cch As Integer) As Integer
This is the usual declaration of the API function GetWindowText. As we know lpString should be marshalled as a LPCSTR, but according to this article, VB.Net doesn't allow you to specify the marshaling attribute on parameters, and purportedly the above declaration works just fine.
When I tried this version of the API call, using GetWindowTextLength to determine the length of the string to be filled with spaces before passing to GetWindowText, I ended up with a bunch of non-ASCII characters. When I tried using the MarshalAs attribute, all I got was an empty string of the "correct" length.
After some exasperation I decided that since the API was expecting a pointer to a string, I might as well give one, or the closest to one, a byte array. The declaration was then:
Declare Auto Function GetWindowText Lib "user32" Alias "GetWindowTextA" (ByVal hwnd As Integer, ByVal lpByteArray As Byte(), ByVal cch As Integer) As Integer
Then:
...
Dim Ret As Integer, sByte As Byte()
Ret = GetWindowTextLength(hwnd)
If Ret > 0 Then
ReDim sByte(Ret + 1)
lret = GetWindowText(hwnd, sByte, Ret + 1)
Return System.Text.Encoding.ASCII.GetString(sByte)
End if
...
Just as a sanity check (and before I found the Encoding.ASCII.GetString function), I stepped through the function to see what was being stored in sByte. They looked to be ASCII-flavored bytes (mmmm) so I looked for a function to convert them to a string, et voila!
I was actually expecting to be required to pass the first member of the byte array as a parameter to GetWindowText, but apparently .Net did the math and converted the byte array into a pointer of sorts.
I must admit I'm a bit new to .Net (two years of actual usage) and newer to managed and unmanaged code mixing, so I can't tell you that this is the right way to do it, but this method worked where others failed.
I'm on .NET 2003, in case you were wondering.
Declare Auto Function GetWindowText Lib "user32" Alias "GetWindowTextA" (ByVal hwnd As Integer, ByVal lpString As String, ByVal cch As Integer) As Integer
This is the usual declaration of the API function GetWindowText. As we know lpString should be marshalled as a LPCSTR, but according to this article, VB.Net doesn't allow you to specify the marshaling attribute on parameters, and purportedly the above declaration works just fine.
When I tried this version of the API call, using GetWindowTextLength to determine the length of the string to be filled with spaces before passing to GetWindowText, I ended up with a bunch of non-ASCII characters. When I tried using the MarshalAs attribute, all I got was an empty string of the "correct" length.
After some exasperation I decided that since the API was expecting a pointer to a string, I might as well give one, or the closest to one, a byte array. The declaration was then:
Declare Auto Function GetWindowText Lib "user32" Alias "GetWindowTextA" (ByVal hwnd As Integer, ByVal lpByteArray As Byte(), ByVal cch As Integer) As Integer
Then:
...
Dim Ret As Integer, sByte As Byte()
Ret = GetWindowTextLength(hwnd)
If Ret > 0 Then
ReDim sByte(Ret + 1)
lret = GetWindowText(hwnd, sByte, Ret + 1)
Return System.Text.Encoding.ASCII.GetString(sByte)
End if
...
Just as a sanity check (and before I found the Encoding.ASCII.GetString function), I stepped through the function to see what was being stored in sByte. They looked to be ASCII-flavored bytes (mmmm) so I looked for a function to convert them to a string, et voila!
I was actually expecting to be required to pass the first member of the byte array as a parameter to GetWindowText, but apparently .Net did the math and converted the byte array into a pointer of sorts.
I must admit I'm a bit new to .Net (two years of actual usage) and newer to managed and unmanaged code mixing, so I can't tell you that this is the right way to do it, but this method worked where others failed.
I'm on .NET 2003, in case you were wondering.
Tuesday, September 30, 2008
Woe is me - part deux
It's official - my PSP is really bricked.
I tried reviving it with Despertar del Cementerio, and initially it looked fine - the DC7 menu booted up, I selected the option to install firmware 4.01 M33, it went through the motions of formatting flash rom and installing the firmware.
But when it was all done I rebooted with a normal battery and it was still dead. Even trying to boot into the firmware off the memory stick (Test M33 option) produced the same results.
I have repartitioned, regen'ed the IDStorage, restored the NAND from corly's "clean" flashdump, all to no avail.
I have a brain-dead PSP. The heart works, but the head is empty. I'm still thinking of an explanation why it quit on me like that, all of a sudden.
I guess now I have to decide to give it a new lease on life, or let it go.
There is the third option to gut it and make a crude display adapter for it, or turn it into a digital frame. Good luck with that
I tried reviving it with Despertar del Cementerio, and initially it looked fine - the DC7 menu booted up, I selected the option to install firmware 4.01 M33, it went through the motions of formatting flash rom and installing the firmware.
But when it was all done I rebooted with a normal battery and it was still dead. Even trying to boot into the firmware off the memory stick (Test M33 option) produced the same results.
I have repartitioned, regen'ed the IDStorage, restored the NAND from corly's "clean" flashdump, all to no avail.
I have a brain-dead PSP. The heart works, but the head is empty. I'm still thinking of an explanation why it quit on me like that, all of a sudden.
I guess now I have to decide to give it a new lease on life, or let it go.
There is the third option to gut it and make a crude display adapter for it, or turn it into a digital frame. Good luck with that
Monday, September 29, 2008
Woe is me
Yesterday my girlfriend was towing me around while looking for a new pair of shoes, and while we were in one store, I plopped down on a sofa and whipped out my almost 1-year old PSP.
I was playing N+, and all of a sudden the unit just... died.
I thought, ok, it's just the battery, but I just charged it, so maybe its that RemoteJoyLite plugin -- it's always crashing --, I'll just do cold boot.
So I tried pulling the power switch up for ten seconds. The power LED turns green for a few seconds, then dies. I try it again. The same thing. I have never seen a bricked PSP before, but I hope that that is all it is - a corrupt firmware.
When I got home I try to plug in the AC adapter, to no avail. I went as far as disassembling my PSP. I got as far as removing the LCD frame, but it was almost morning and my girlfriend has work early, so after a few tries I finally got the PSP back together.
Right now I have my PSP with me, at the office. I was hoping to borrow somebody's PSP and make a Pandora battery.
I already have the magic memstick, so unbricking is my last course of action before having the unit fixed (which will cost me the half price of second-hand PSP phat, at least, that's what replacing the motherboard will cost me)
But in my rush not to get to work late, it seems I left the magic memstick at home, bugger that.
The thing is, I haved dropped my PSP (from about 1 foot), and it did fall a bit hard -- hard enough to somehow get the battery cover lock out, but still leave the whole PSP and battery cover lock mechanism intact.
I really wouldn't want to lose my PSP. It's almost a part of me, and 1 year isn't good enough for me to say goodbye to it yet. If I ever resurrect it I promise never to drop it, ever again.
I feel guilty for shelling out some money to fix it after my girlfriend has repeatedly told me how badly I treat it, I almost feel like I don't deserve to have it fixed.
But leaving it broken just doesn't feel right... and if it could never be fixed, I would at least like to scrap the LCD and build a driver for it, turn it into a digital frame or a mini monitor. Good luck with that though - Alexan doesn't even stock up on PICs, much less FPGAs.
If anyone has a phat compatible motherboard to sell (for cheap), let me know?
I was playing N+, and all of a sudden the unit just... died.
I thought, ok, it's just the battery, but I just charged it, so maybe its that RemoteJoyLite plugin -- it's always crashing --, I'll just do cold boot.
So I tried pulling the power switch up for ten seconds. The power LED turns green for a few seconds, then dies. I try it again. The same thing. I have never seen a bricked PSP before, but I hope that that is all it is - a corrupt firmware.
When I got home I try to plug in the AC adapter, to no avail. I went as far as disassembling my PSP. I got as far as removing the LCD frame, but it was almost morning and my girlfriend has work early, so after a few tries I finally got the PSP back together.
Right now I have my PSP with me, at the office. I was hoping to borrow somebody's PSP and make a Pandora battery.
I already have the magic memstick, so unbricking is my last course of action before having the unit fixed (which will cost me the half price of second-hand PSP phat, at least, that's what replacing the motherboard will cost me)
But in my rush not to get to work late, it seems I left the magic memstick at home, bugger that.
The thing is, I haved dropped my PSP (from about 1 foot), and it did fall a bit hard -- hard enough to somehow get the battery cover lock out, but still leave the whole PSP and battery cover lock mechanism intact.
I really wouldn't want to lose my PSP. It's almost a part of me, and 1 year isn't good enough for me to say goodbye to it yet. If I ever resurrect it I promise never to drop it, ever again.
I feel guilty for shelling out some money to fix it after my girlfriend has repeatedly told me how badly I treat it, I almost feel like I don't deserve to have it fixed.
But leaving it broken just doesn't feel right... and if it could never be fixed, I would at least like to scrap the LCD and build a driver for it, turn it into a digital frame or a mini monitor. Good luck with that though - Alexan doesn't even stock up on PICs, much less FPGAs.
If anyone has a phat compatible motherboard to sell (for cheap), let me know?
Subscribe to:
Posts (Atom)
