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.
Tuesday, December 30, 2008
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?
Tuesday, July 15, 2008
My new toy
My girlfriend got me an early gift for my birthday.
Yeah. No. Not a Wii, just the Wiimote.
I've been pining for one for the past few months, comparing everything to the price of a Wiimote, and she finally caved in and decided to get me one.
She probably didn't see the point in getting a Wiimote without the console, but I've been watching those videos and drooling with envy at the all geeky things you can do with a Wiimote and a PC with a Bluetooth adapter.
Installing the damn thing
My Bluetooth adapter is the cheapo Billionton BT-dongle that seems to do the job well enough.
It comes with IVT BlueSoleil drivers. My first try with this set of drivers kept me awake for most of the morning. The Wiimote was being detected, but GlovePIE and Wiinmote refused to detect it.
I got a copy of the BlueSoleil drivers v1.6.2.1, and these worked fine, but since my dongle was detected as an unlicensed device, I was only limited to 5MB data transfer before needing to restart BlueTooth.
GlovePIE and Wiinmote worked perfectly here, and before long I was playing TrackMania Sunrise with the Wiimote as a steering wheel,
and Portal with some difficulty.
Before long I exceeded the 5MB limit and my game of Portal was abruptly halted due to lack of control. This wouldn't do.
I finally tried going back to a newly downloaded copy of v1.6.1.4, and now BlueSoleil is not complaining about about an unlicensed device, while GlovePIE continue to work happily.
To get everything working you will need:
I'll not post complete instuctions on how to set things up here. Google can help you find that.
Yeah. No. Not a Wii, just the Wiimote.
I've been pining for one for the past few months, comparing everything to the price of a Wiimote, and she finally caved in and decided to get me one.
She probably didn't see the point in getting a Wiimote without the console, but I've been watching those videos and drooling with envy at the all geeky things you can do with a Wiimote and a PC with a Bluetooth adapter.
Installing the damn thing
My Bluetooth adapter is the cheapo Billionton BT-dongle that seems to do the job well enough.
It comes with IVT BlueSoleil drivers. My first try with this set of drivers kept me awake for most of the morning. The Wiimote was being detected, but GlovePIE and Wiinmote refused to detect it.
I got a copy of the BlueSoleil drivers v1.6.2.1, and these worked fine, but since my dongle was detected as an unlicensed device, I was only limited to 5MB data transfer before needing to restart BlueTooth.
GlovePIE and Wiinmote worked perfectly here, and before long I was playing TrackMania Sunrise with the Wiimote as a steering wheel,
and Portal with some difficulty.
Before long I exceeded the 5MB limit and my game of Portal was abruptly halted due to lack of control. This wouldn't do.
I finally tried going back to a newly downloaded copy of v1.6.1.4, and now BlueSoleil is not complaining about about an unlicensed device, while GlovePIE continue to work happily.
To get everything working you will need:
- A BlueTooth dongle (BillionTon was used here)
- Bluetooth drivers (BlueSoleil v1.6.1.4 was used here)
- GlovePIE v???
- PPPJoy
- Some patience
I'll not post complete instuctions on how to set things up here. Google can help you find that.
Tuesday, June 10, 2008
Nostalgia Hack - Super UFO
I did it for the nostalgia - the SNES unit my brother bought had a Super UFO. Needless to say, many summer nights were spent loading up games from this copier's menu.
What I did was basically NOP out instructions that were causing infinite loops, these were most likely disk access checks. I was also having trouble getting the sound to work until I discovered a routine that for some reason was copying the sound init code to non-existant memory (probably on-board custom RAM)
Strangely enough the code wasn't exactly self-modifying and could have been called from ROM instead, which is what I did.
The patched ROM doesn't play music initially for some reason - I might have NOPped out a bit more than needed - but the music can be set through the menu.
As I said, this is a fairly useless hack. If you never owned the Super UFO you probably won't appreciate this.
You nostalgic nerds can download the patch and ROM here.
UPDATE:
Found the problem why it wasn't working on Snes9xTYL for the PSP. Looks like there was a difference in what value was returned when reading from an undefined port in the different emulator versions.
Thursday, March 20, 2008
LCD Monitor Troubles
Remember my 19" Hanspree LCD monitor I got last Christmas?
Just today I noticed that it was developing horizontal streaks across the screen towards the right especially during sharp brightness level changes.
I was at work when Frans told me it was getting really bad, so I Googled and found an article that said frame rates above 60Hz weren't good for LCDs, so I had her reset it from 75 to 60. It seemed to fix it a little bit, but the streaks were still there.
In desperation I asked her to secure the monitor cable at the back of the LCD and the PC. She did so for the back of the LCD, and the problem went away.
Or so I thought...
UPDATE:
The source of the problem was a loose AC power cord. Some arcing was probably messing up the timing circuits and causing the streaks. After securing the power cord, the screen was back to normal.
Phew
Just today I noticed that it was developing horizontal streaks across the screen towards the right especially during sharp brightness level changes.
I was at work when Frans told me it was getting really bad, so I Googled and found an article that said frame rates above 60Hz weren't good for LCDs, so I had her reset it from 75 to 60. It seemed to fix it a little bit, but the streaks were still there.
In desperation I asked her to secure the monitor cable at the back of the LCD and the PC. She did so for the back of the LCD, and the problem went away.
Or so I thought...
UPDATE:
The source of the problem was a loose AC power cord. Some arcing was probably messing up the timing circuits and causing the streaks. After securing the power cord, the screen was back to normal.
Phew
Steampunk Calculator
This isn't technically steampunk, nor was it invented in Victorian-era England, but with a few brass trimmings, it would fit right in. And...
...It could fit right in your pocket!
Friday, March 14, 2008
Willow Hack - Almost There
The main part of this hack - setting aside some SRAM to save to and load from, the actual routines for accomplishing this, and the basic interface to select from 3 slots where to save or load - is complete.
I still need to write a routine that displays Willow's stats for each save game, and do something better than SELECT+B in order to access the save menu. There is also a bug where the background music isn't restored after leaving the save menu.
I also did a few kludges to make things work, such as shamelessly copy/pasting some code from other parts of the code without knowing exactly what the function calls did. Seems to work fine though.
I also need to check if I've overwritten any code that shouldn't be. Fortunately (I noticed) the assembler does export symbols from the source. This means that any labels I've used in the source code are noted down along with their memory locations in the ROM. By placing labels at the end of functions and data tables, I can compare with the original disassembly and find out if I've overrun any code.
I also noticed and rooted out a little bug where the stack head kept moving up after selecting continue. Turns out the original code forced a stack reset which I failed to include (yes, copy/paste). Although there seemed to be no ill effects right off, it might have caused problems after the player continued 20 or so times.
However aside from the savegame text and a few bugs, there are a few things I want to add before I call this patch finished and release it into the world.
I want to add the name of the area into the save game, just so the player knows more-or-less where he left off, and a percent complete value would be nice. I suppose the calculation for percent completed would be computed from the items Willow has acquired. Then there's a minor hack to the saver/loader routines which should use a checksum to verify if the savegame is valid or corrupt.
One last thing, I'd like to add my name into the credits on the PRESS START screen, but the data is tightly packed with no free memory right after it, so my last hack will entail either moving that bit of data into some place more agreeable, or add and extend the "string" writing code to allow jumping to another location in memory. Right now I've just shamelessly replaced the TM & © "LUCASFILM" with "ENDERSOFT".
For now, here's what the selection screen will look like. The data is actually a mock-up - no values are read from SRAM - but the screen is actually running off the emulator (i.e. no Photoshop tricks)
I still need to write a routine that displays Willow's stats for each save game, and do something better than SELECT+B in order to access the save menu. There is also a bug where the background music isn't restored after leaving the save menu.
I also did a few kludges to make things work, such as shamelessly copy/pasting some code from other parts of the code without knowing exactly what the function calls did. Seems to work fine though.
I also need to check if I've overwritten any code that shouldn't be. Fortunately (I noticed) the assembler does export symbols from the source. This means that any labels I've used in the source code are noted down along with their memory locations in the ROM. By placing labels at the end of functions and data tables, I can compare with the original disassembly and find out if I've overrun any code.
I also noticed and rooted out a little bug where the stack head kept moving up after selecting continue. Turns out the original code forced a stack reset which I failed to include (yes, copy/paste). Although there seemed to be no ill effects right off, it might have caused problems after the player continued 20 or so times.
However aside from the savegame text and a few bugs, there are a few things I want to add before I call this patch finished and release it into the world.
I want to add the name of the area into the save game, just so the player knows more-or-less where he left off, and a percent complete value would be nice. I suppose the calculation for percent completed would be computed from the items Willow has acquired. Then there's a minor hack to the saver/loader routines which should use a checksum to verify if the savegame is valid or corrupt.
One last thing, I'd like to add my name into the credits on the PRESS START screen, but the data is tightly packed with no free memory right after it, so my last hack will entail either moving that bit of data into some place more agreeable, or add and extend the "string" writing code to allow jumping to another location in memory. Right now I've just shamelessly replaced the TM & © "LUCASFILM" with "ENDERSOFT".
For now, here's what the selection screen will look like. The data is actually a mock-up - no values are read from SRAM - but the screen is actually running off the emulator (i.e. no Photoshop tricks)
Monday, March 10, 2008
Willow Hack News
I'm in the middle of unraveling the code to draw the backgrounds used for the START and PASSWORD screens.
Interestingly, it uses the same routines for drawing the in-game backgrounds. This is the background you see when walking through the game as Willow.
Now this routine uses two variables to specify what background is loaded to be scrolled into the screen while Willow walks to the edge of the visible screen.
The "coordinates" for the START screen is (1A,1E). I'm not sure where the password screen is stored yet. When switching to the password screen, no backgrounds are drawn (i.e. the code for drawing backgrounds is not called). Instead, the code merely switches the active nametable implying that the password screen is already drawn into memory.
So far I've determined that these values decode into a memory address where the code picks up another byte that decodes into another address, which is where the char which will be copied to the nametable is stored. I still haven't fully decoded the routine, but it's another step towards finalization.
I think it uses some form of compression in order to save space, as the routine seems to read from certain locations multiple times, instead of simple packed data. It is probably RLE, which would be ideal given the repetative nature of the backgrounds.
Meanwhile, I think I should focus on what can be done, which is implementing the load/save screens - sans backgrounds - and adding support for multiple saves.
I just feel so close to understanding how it works that I don't want to let it by.
Interestingly, it uses the same routines for drawing the in-game backgrounds. This is the background you see when walking through the game as Willow.
Now this routine uses two variables to specify what background is loaded to be scrolled into the screen while Willow walks to the edge of the visible screen.
- Each variable seems to change independent of each other
- One variable changes if Willow walks out the top/bottom of the screen, I designate this as mapY.
- The other variable changes if Willow walks out left/right of the screen, I designate this as mapX.
- The variables don't seem to be a direct index, as useful values seem to be in the 1A-1F range.
The "coordinates" for the START screen is (1A,1E). I'm not sure where the password screen is stored yet. When switching to the password screen, no backgrounds are drawn (i.e. the code for drawing backgrounds is not called). Instead, the code merely switches the active nametable implying that the password screen is already drawn into memory.
So far I've determined that these values decode into a memory address where the code picks up another byte that decodes into another address, which is where the char which will be copied to the nametable is stored. I still haven't fully decoded the routine, but it's another step towards finalization.
I think it uses some form of compression in order to save space, as the routine seems to read from certain locations multiple times, instead of simple packed data. It is probably RLE, which would be ideal given the repetative nature of the backgrounds.
Meanwhile, I think I should focus on what can be done, which is implementing the load/save screens - sans backgrounds - and adding support for multiple saves.
I just feel so close to understanding how it works that I don't want to let it by.
Wednesday, March 5, 2008
Willow Hack: Update
Remember how I said I wanted a feature to "skip" the dialog in WIllow? I really meant, make it print faster. Well, I was looking through the code today, trying to make sense of it all when I came upon some code that seemed to be reading the joystick in the dialog routine.
Aha! I thought, and noticed that the bit being tested was the one for the up button. That's when I "remembered" that in order to speed up the dialog you had to hold Up on the D-Pad. I thought this "Up" business to skip dialog was a bit silly when it's almost universally held that the B button was for "cancelling". So I remapped it to B.
I also stumbled upon how it draws text to the screen, and isolated a function call that seems to draw the background.
A little more work will be needed disassembling all this twisting code before I can figure out how it does the backgrounds. When that's done, I can be on my way to writing the Load / Save screens, and making this Proof-of-concept a full working patch!
Aha! I thought, and noticed that the bit being tested was the one for the up button. That's when I "remembered" that in order to speed up the dialog you had to hold Up on the D-Pad. I thought this "Up" business to skip dialog was a bit silly when it's almost universally held that the B button was for "cancelling". So I remapped it to B.
I also stumbled upon how it draws text to the screen, and isolated a function call that seems to draw the background.
A little more work will be needed disassembling all this twisting code before I can figure out how it does the backgrounds. When that's done, I can be on my way to writing the Load / Save screens, and making this Proof-of-concept a full working patch!
Friday, February 29, 2008
Willow Hack PoC complete!
My Proof-of-concept hack is done, and I now have a Willow ROM that allows saving current progress by pressing SELECT-B and resuming the saved game by selecting PASS WORD in the opening screen or CONTINUE after losing all your HP.
So far the hack works well on FCEUltra. I tried on NesterJ for the PSP but it crashed every time I tried to save my progress. Maybe it doesn't have support for battery backed RAM?
On a side note I called in sick, because I'm feeling really lousy, but apparently not enough to stop me from sitting in front of my PC for 6 hours straight.
Right now I'd like to change the intro screen text to "CONTINUE" instead of "PASS WORD", but I really should be getting some rest.
Once I figure out how the screens are set up and how text is drawn I'd like to put int a real save game selection screen, with allowance for 3 save games, showing info about each save game.
UPDATE: Just tested it on NesterJ version 1.20 beta, and it works perfectly! The version that the hack wasn't working with was 1.1 RM.
Download the patch and source here
So far the hack works well on FCEUltra. I tried on NesterJ for the PSP but it crashed every time I tried to save my progress. Maybe it doesn't have support for battery backed RAM?
On a side note I called in sick, because I'm feeling really lousy, but apparently not enough to stop me from sitting in front of my PC for 6 hours straight.
Right now I'd like to change the intro screen text to "CONTINUE" instead of "PASS WORD", but I really should be getting some rest.
Once I figure out how the screens are set up and how text is drawn I'd like to put int a real save game selection screen, with allowance for 3 save games, showing info about each save game.
UPDATE: Just tested it on NesterJ version 1.20 beta, and it works perfectly! The version that the hack wasn't working with was 1.1 RM.
Download the patch and source here
Thursday, February 28, 2008
Willow Hack News
I'm using a cross assembler for the SNES, but since the 65816 processor mostly extends the 6502, getting it to work for this project was easy.
Well, mostly.
I spent most of the morning trying to get the assembler to produce a valid IPS file, but I'm glad I did.
The samples I downloaded for compiling SNES patches from asm files had scripts for checking addresses when creating patch files.
I was getting symbol not found errors when trying to subtract a hex address from a variable, but had no problems adding (or any other operation, I suppose).
The error went away when I decided to use base 10 to represent the value I was trying to subtract.
So, instead of
@STEP2 = @STEP1 - $C000
It was
@STEP2 = @STEP1 - 49152
I decided to hijack the password routine and copy a bit of code from the "new game" routine. For now I just loaded up the SRAM with some default values.
It almost worked.
I had a black screen with Willow in it. Switching to inventory and back brought the screen colors to life but the palette seems messed up, though I think I have some idea of how to fix this.
With the code analysis practically complete and most critical variables identified, I can now focus on writing code. The assembler/patcher toolchain makes things much easier as all I have to do is edit the assembly code and re-run my compiler script.
Already I'm halfway to my goal of a Proof-of-concept hack, with a full hack not too far off.
Although state-saves have all but made this hack useless, it's been a fun ride. Maybe I'll put a little how-to together, for the sake of posterity.
Well, mostly.
I spent most of the morning trying to get the assembler to produce a valid IPS file, but I'm glad I did.
The samples I downloaded for compiling SNES patches from asm files had scripts for checking addresses when creating patch files.
I was getting symbol not found errors when trying to subtract a hex address from a variable, but had no problems adding (or any other operation, I suppose).
The error went away when I decided to use base 10 to represent the value I was trying to subtract.
So, instead of
@STEP2 = @STEP1 - $C000
It was
@STEP2 = @STEP1 - 49152
I decided to hijack the password routine and copy a bit of code from the "new game" routine. For now I just loaded up the SRAM with some default values.
It almost worked.
I had a black screen with Willow in it. Switching to inventory and back brought the screen colors to life but the palette seems messed up, though I think I have some idea of how to fix this.
With the code analysis practically complete and most critical variables identified, I can now focus on writing code. The assembler/patcher toolchain makes things much easier as all I have to do is edit the assembly code and re-run my compiler script.
Already I'm halfway to my goal of a Proof-of-concept hack, with a full hack not too far off.
Although state-saves have all but made this hack useless, it's been a fun ride. Maybe I'll put a little how-to together, for the sake of posterity.
Tuesday, February 26, 2008
Useless Hacks Update
I have managed to isolate most of the code that takes up the password entry, testing and stats loading for the NES game Willow. I've also identified where stats are saved in memory, how Willow's map and screen position is stored, and the all-important events and inventory flags.
Coding a replacement function that will load data from SRAM should be pretty easy, and free up a lot of ROM space in the process.
I have yet to figure out how the screens are loaded, so I can load my own custom save game screen, but that's not really part of the Proof of Concept hack.
Just to make things interesting I'll change the PASS WORD text into LOAD GAME.
That's the easy part.
Saving for my PoC requires me to tap into the main game joystick routine and save everything to RAM once a combinaion (SELECT+B) is pressed. However in a real hack it'd be nice to have save points.
Adding code to a NES ROM is a bit more problematic because of it's memory restrictions and the memory mappers designed to handle this.
You can't just add code to another bank if the original bank doesn't have any space to give up. Since only one bank is mapped at any time, you'd have to push some registers or save in RAM and switch banks to run code from another bank.
I hope to do the loading code tomorrow, that is, if Patapon doesn't distract me long enough.
Coding a replacement function that will load data from SRAM should be pretty easy, and free up a lot of ROM space in the process.
I have yet to figure out how the screens are loaded, so I can load my own custom save game screen, but that's not really part of the Proof of Concept hack.
Just to make things interesting I'll change the PASS WORD text into LOAD GAME.
That's the easy part.
Saving for my PoC requires me to tap into the main game joystick routine and save everything to RAM once a combinaion (SELECT+B) is pressed. However in a real hack it'd be nice to have save points.
Adding code to a NES ROM is a bit more problematic because of it's memory restrictions and the memory mappers designed to handle this.
You can't just add code to another bank if the original bank doesn't have any space to give up. Since only one bank is mapped at any time, you'd have to push some registers or save in RAM and switch banks to run code from another bank.
I hope to do the loading code tomorrow, that is, if Patapon doesn't distract me long enough.
Last farewell
A faint sensation, not altogether unpleasant, a feeling of coldness deep inside, while bathed in the warmth of a setting sun, while looking out upon a tower white cliff to a golden orange horizon, with feathery clouds lost in the distance.
A sadness that resembled a deep yearning for something that would, now, be forever out of reach, threatening to drown me in a torrent of tears. I was borne aloft only by the unending beauty of all that I had seen and experienced in just my two visits to this world, and yes, this beauty also brought tears to my eyes.
I felt Aslan's hot breath upon my back as I gazed for one last time upon my beloved Narnia.
It was bittersweet... yet somehow... perfect.
The last sentence was paraphrased from an interview with Anna Popplewell, regarding the film Prince Caspian being her last for The Chronicles of Narnia, and was the inspiration for this entry.
A sadness that resembled a deep yearning for something that would, now, be forever out of reach, threatening to drown me in a torrent of tears. I was borne aloft only by the unending beauty of all that I had seen and experienced in just my two visits to this world, and yes, this beauty also brought tears to my eyes.
I felt Aslan's hot breath upon my back as I gazed for one last time upon my beloved Narnia.
It was bittersweet... yet somehow... perfect.
The last sentence was paraphrased from an interview with Anna Popplewell, regarding the film Prince Caspian being her last for The Chronicles of Narnia, and was the inspiration for this entry.
Wednesday, February 6, 2008
NES Hacks: Coin Tricks
Here in the Philippines, we had the Japanese version of the Nintendo console, known as the Family Computer (aka Famicon), instead of the dull-grey clunky unit with excessively large cartridges known as the Nintendo Entertainment System.
The Famicon design featured joysticks that were permanently connected to the console and had a port at the front which was used for the optional light gun. This port was usually covered by a red plastic cap when not in use.
There was something mysterious about that port. It has little pins in it, and wat I remember is that my uncles and cousins would take a 10 centavo coin and run it across the ports pins with Contra plugged into the game slot and the unit turned on. After a few tries they would get a level select screen.
It's a wonder how anybody figured out how to do this trick, let alone that it worked at all. The regular way to do this utilizes a variation of the Konami Code.
It would be real nice if someone could come up with a solid explanation of why it works. Unless someone already has, and I haven't found the right keywords to google it.
Useless Hacks: Willow on the NES
Willow was the first RPG I played. From then on I was hooked.
It was developed by Capcom and based on George Lucas' movie of the same name, though with a somewhat different plot. Despite (or because of) this its been hailed as one of the few movie-to-game translations that are arguably better than their silverscreen counterpart.
It was developed by Capcom and based on George Lucas' movie of the same name, though with a somewhat different plot. Despite (or because of) this its been hailed as one of the few movie-to-game translations that are arguably better than their silverscreen counterpart.
I didn't own the cart, I borrowed it from a neighbor. It was the Japanese version, and although it did not use any kanji, my Japanese skills were non-existant back then, leaving much of the plot to guess, making most of the gameplay trial and error. It was very time consuming moving back and forth between towns, talking to every NPC more than twice, just to get the story to move forward.
The thing was, and I still had a blast playing it. The background song during password entry would play in my mind for some time (this was probably because it took so long to enter the password, being in Japanese) .
Recently I took up playing the game in English, just for the heck of it, and reliving fond memories of childhood.
I read somewhere that the password entry system was used in order to cut costs and development time. I believe the original plan was to have the data battery backed, just as Zelda did.
This is where the hacking comes in. I thought, why not add a save game feature to Willow?
Now, in a real NES the cart would have a set of RAM with batteries attached. It would be just another address accessible by memory. In an emulator, a header in the .nes file tells the emu that it has battery backed RAM, by convention this starts at $6000.
So, just modify the header to include battery backed RAM and poof! It became Koko Crunch!
When the emulator loads the ROM it looks for a corresponding file in the battery-backed-data folder, usually called SAVE or something. Using FCEUltra, it looks just like a raw dump of $6000 - $7FFF. For efficiency, the emulator only updates this file whenever another game is loaded or the emulator shuts down.
I tested this with your typical "Hello World!" text hexed into the RAM dump and booted the ROM. Using FCEU's debugging capabilities, I looked into RAM memory and there it was.
That was the easy part.
For a Proof of Concept Hack:
- Modify the header to make it have battery-backed RAM. (Done)
- Find where the stats are located.
- Redirect the password routine to copy battery-backed RAM to game stats.
- Implement a hack in the game joytick routine to detect an unused button combination (Select-B?) and jump to a routine that saves current stats into battery-backed RAM.
For a complete hack a load and save screen should be implmented, and multiple save slots would be nice.
So far I've found where the password is checked, but nothing too in-depth as I am currently disassembling from the emulator. I've also found the main game joystick routine, so I should be able to insert a jump to my own routine to trap the special button combination for the PoC.
Hopefully I can insert the needed code and (later on) screens without having to expand the ROM.
Wednesday, January 30, 2008
Some Sharepoint Stuff
In my real job, I do a bit of Sharepoint support, not much development, so I don't really get to work with the dotNet side of things.
I do get to work with the database, which gives quite a bit of insight on how Sharepoint works internally.
One of the things stored in the Sharepoint database is the individual settings for each webpart.
Now, our client has a Sharepoint based site, with some custom dotNet stuff thrown into the defaut.aspx of the template's web Homepage. This Homepage really gives us headaches because some users have the ability to close webparts. This could be easily fixed by getting into the Modify view, but something with the additional code prevents Modify view from working.
What happens is when you place the web in Modify mode, the browser gets stuck and stops responding, and CPU usage goes up. I've debugged it and partially traced it to an infinite loop in the resize functions in Sharepoint's Javascript code.
I'm not too eager just yet to go messing around with the dotNet code, as some loaded controls might be involved in messing up the page's DOM heirarchy or something that could cause an infinite loop.
To restore the missing webpart, we have a backup default.aspx of the vanilla Sharepoint web Hompage which we use to temporarily replace the dotNet-messed-up one.
With the vanilla page in place we can safely call Modify mode and restore the webpart.
Now I was asked how we could prevent users from closing the webpart accidentally, and one of the things that came up was to disable the close button. This can only be done in Modify mode, which requires the vanilla page, which requires that no one is using the site, which can only be done during non-business hours.
With a global user base, and a shift nearly opposite to the business users, the window where we can use the vanilla page to do our stuff is only 2-3 hours. Coupled with the fact that there are hundreds of sites to change, it begins to be impractical.
So with some determination I set out to find where Sharepoint stored the settings for webparts, and the field tp_AllUsersProperties seemed to invite further investigation. It's an image field, used to store an arbitrarily large binary value. Here is what I have so far:
"Header" - Always present: Doesn't seem to change
0105 0000 0002 2A00 4A00 2900 033D 0000 022A 0049 0029 0003 3E00 0001
"Separator" - Seems to separate entities
0F01
"Close Disabled" - Present if "Allow Close" is unchecked.
15 0029 0003 4800
"Zone Change Disabled" - Present if "Allow Zone Change" is unchecked
2B 0029 0003 4800
"Minimise Disabled" - Present if "Allow Minimise" is unchecked.
16 0029 0003 4800
Description - Text
02 0029 0003 FFFF nn
nn is the length of the text in bytes, no null termination
Detail Link - URL
1A 0029 0003 FFFF nn
nn is the length of the text in bytes, no null termination
1B 0029 0003 FFFF nn
nn is the length of the text in bytes, no null termination
1F 0029 0003 FFFF nn
nn is the length of the text in bytes, no null termination
27 0029 0003 FFFF nn
nn is the length of the text in bytes, no null termination
20 0029 0003 FFFF nn
nn is the length of the text in bytes, no null termination
"EOF" - Always appears at the end
0F0F
It only seems to encode the Advanced Settings.
If it is null, default settings are used when in Modify mode.
If no text entities are defined, there must be at least one text entity before the EOF marker. The entity can be any text entity such as Detail but it should be truncated as:
1A 0029 00
each entity is followed by the separator, unless it is the last entity, where is will be followed by the EOF marker.
If entities have an identifier (first byte), a robust parser should be able to read the entities even if they were written in any order, unless it expects an order in which they are written.
nn is only a byte wide so the maximum number of characters in the text entities is 255.
Having incorrect values results in an error with Sharepoint not being able to "serialize" the webpart.
I have no idea what the recurring values "0029 0003 FFFF" mean. Changing them results in the same error as above.
I haven't tried this on another Sharepoint, or across multiple sites.
You should join tp_PagerUrlId to the Docs table in order to find the page that the webpart is on.
tp_WebPartId ias actually a GUID of a hash of the webpart name. See about that here.
As we are looking to eliminate the ability to Modify I've since moved on to more simpler Javascript to hide the webparts Modify buttons.
Anyway, I hope this is useful to somebody.
I do get to work with the database, which gives quite a bit of insight on how Sharepoint works internally.
One of the things stored in the Sharepoint database is the individual settings for each webpart.
Now, our client has a Sharepoint based site, with some custom dotNet stuff thrown into the defaut.aspx of the template's web Homepage. This Homepage really gives us headaches because some users have the ability to close webparts. This could be easily fixed by getting into the Modify view, but something with the additional code prevents Modify view from working.
What happens is when you place the web in Modify mode, the browser gets stuck and stops responding, and CPU usage goes up. I've debugged it and partially traced it to an infinite loop in the resize functions in Sharepoint's Javascript code.
I'm not too eager just yet to go messing around with the dotNet code, as some loaded controls might be involved in messing up the page's DOM heirarchy or something that could cause an infinite loop.
To restore the missing webpart, we have a backup default.aspx of the vanilla Sharepoint web Hompage which we use to temporarily replace the dotNet-messed-up one.
With the vanilla page in place we can safely call Modify mode and restore the webpart.
Now I was asked how we could prevent users from closing the webpart accidentally, and one of the things that came up was to disable the close button. This can only be done in Modify mode, which requires the vanilla page, which requires that no one is using the site, which can only be done during non-business hours.
With a global user base, and a shift nearly opposite to the business users, the window where we can use the vanilla page to do our stuff is only 2-3 hours. Coupled with the fact that there are hundreds of sites to change, it begins to be impractical.
So with some determination I set out to find where Sharepoint stored the settings for webparts, and the field tp_AllUsersProperties seemed to invite further investigation. It's an image field, used to store an arbitrarily large binary value. Here is what I have so far:
"Header" - Always present: Doesn't seem to change
0105 0000 0002 2A00 4A00 2900 033D 0000 022A 0049 0029 0003 3E00 0001
"Separator" - Seems to separate entities
0F01
"Close Disabled" - Present if "Allow Close" is unchecked.
15 0029 0003 4800
"Zone Change Disabled" - Present if "Allow Zone Change" is unchecked
2B 0029 0003 4800
"Minimise Disabled" - Present if "Allow Minimise" is unchecked.
16 0029 0003 4800
Description - Text
02 0029 0003 FFFF nn
nn is the length of the text in bytes, no null termination
Detail Link - URL
1A 0029 0003 FFFF nn
nn is the length of the text in bytes, no null termination
1B 0029 0003 FFFF nn
nn is the length of the text in bytes, no null termination
1F 0029 0003 FFFF nn
nn is the length of the text in bytes, no null termination
27 0029 0003 FFFF nn
nn is the length of the text in bytes, no null termination
20 0029 0003 FFFF nn
nn is the length of the text in bytes, no null termination
"EOF" - Always appears at the end
0F0F
It only seems to encode the Advanced Settings.
If it is null, default settings are used when in Modify mode.
If no text entities are defined, there must be at least one text entity before the EOF marker. The entity can be any text entity such as Detail but it should be truncated as:
1A 0029 00
each entity is followed by the separator, unless it is the last entity, where is will be followed by the EOF marker.
If entities have an identifier (first byte), a robust parser should be able to read the entities even if they were written in any order, unless it expects an order in which they are written.
nn is only a byte wide so the maximum number of characters in the text entities is 255.
Having incorrect values results in an error with Sharepoint not being able to "serialize" the webpart.
I have no idea what the recurring values "0029 0003 FFFF" mean. Changing them results in the same error as above.
I haven't tried this on another Sharepoint, or across multiple sites.
You should join tp_PagerUrlId to the Docs table in order to find the page that the webpart is on.
tp_WebPartId ias actually a GUID of a hash of the webpart name. See about that here.
As we are looking to eliminate the ability to Modify I've since moved on to more simpler Javascript to hide the webparts Modify buttons.
Anyway, I hope this is useful to somebody.
Wednesday, January 23, 2008
PSP-Dev Woes
Today was by far the most painless install of the psp toolchain I ever did. While this is only the second time, and I hope I won't have to do it again soon, I did learn a few things along the way.
The first thing I did was to jot down exactly how I installed the toolchain and what problems popped up, so I wouldn't have to rely on my now-rusty memory.
It helped bucket loads that I was using Dan Peori's toolchain/library installers. It took a while but when everything was done, most of the source code I had on me was compiling without a glitch.
I wasn't supposed to go back to trying to code for the PSP. I wanted very much to give up on it, since I couldn't think of anything useful to begin to write and start learning that PSPDEV-lore. Everything about programming for the PSP seems so complicated and it's hard to get your hands on some easy-to-understand documentation.
I was also beaten to the Multi-Update folder idea, something that allows you to switch the contents of your update folder, as only one update folder is allowed on your PSP.
A tower defense game has already been made. It would be nice to make one with nice graphics though. At this point it thinking about developing for the PSP brings me back to SDL, as there is a port available for the PSP, it would be so much easier to develop on the PC, work out the main bugs, then port it to the PSP.
Maybe I should go back to square one, write a bouncing ball app, and move on from there.
The first thing I did was to jot down exactly how I installed the toolchain and what problems popped up, so I wouldn't have to rely on my now-rusty memory.
It helped bucket loads that I was using Dan Peori's toolchain/library installers. It took a while but when everything was done, most of the source code I had on me was compiling without a glitch.
I wasn't supposed to go back to trying to code for the PSP. I wanted very much to give up on it, since I couldn't think of anything useful to begin to write and start learning that PSPDEV-lore. Everything about programming for the PSP seems so complicated and it's hard to get your hands on some easy-to-understand documentation.
I was also beaten to the Multi-Update folder idea, something that allows you to switch the contents of your update folder, as only one update folder is allowed on your PSP.
A tower defense game has already been made. It would be nice to make one with nice graphics though. At this point it thinking about developing for the PSP brings me back to SDL, as there is a port available for the PSP, it would be so much easier to develop on the PC, work out the main bugs, then port it to the PSP.
Maybe I should go back to square one, write a bouncing ball app, and move on from there.
Monday, January 14, 2008
A Sense of Accomplishment
I've been missing a sense of accomplishment that comes with the things I used to do. Things I rarely get to do now, because of work and the fact that I dont own all my time (i.e. have a girlfriend).
Sometimes I really miss doing things what others might consider wasting time, things like sketching landscapes and mecha and anime girls (usually in skimpy outfits), playing a musical instrument like a guitar or a piano, finishing an RPG, putting together electronic gadgets out of spare parts, writing semi-useless programs that have no real use beyond the esoteric, writing stories from imagination, reading countless books all day.
When it comes down to it, these things don't really mean anything to anyone in the long run and in the context of the real world can be dropped in favor of something more productive, like coding for profit, watching the news, or heck, catching up on sleep.
I guess I had a lot of time to do those things and I got used to doing them, and now I'm out of my comfort zone I'm just having to adjust all my priorities.
And sometimes I find I've replaced those things with something similar, but not exactly the same, like blogging, and reading articles and blogs.
Maybe it's all part of growing up, and sacrificing time for yourself for time for others.
Maybe I have a lot to look forward to, when I'm sixty, then my own family can let me have my own time in my "lab" with all those gutted electronic parts and half-assembled computers and books and magazines.
For now though, it's an accomplshment enough to get work done and come back home.
Sometimes I really miss doing things what others might consider wasting time, things like sketching landscapes and mecha and anime girls (usually in skimpy outfits), playing a musical instrument like a guitar or a piano, finishing an RPG, putting together electronic gadgets out of spare parts, writing semi-useless programs that have no real use beyond the esoteric, writing stories from imagination, reading countless books all day.
When it comes down to it, these things don't really mean anything to anyone in the long run and in the context of the real world can be dropped in favor of something more productive, like coding for profit, watching the news, or heck, catching up on sleep.
I guess I had a lot of time to do those things and I got used to doing them, and now I'm out of my comfort zone I'm just having to adjust all my priorities.
And sometimes I find I've replaced those things with something similar, but not exactly the same, like blogging, and reading articles and blogs.
Maybe it's all part of growing up, and sacrificing time for yourself for time for others.
Maybe I have a lot to look forward to, when I'm sixty, then my own family can let me have my own time in my "lab" with all those gutted electronic parts and half-assembled computers and books and magazines.
For now though, it's an accomplshment enough to get work done and come back home.
Tuesday, January 8, 2008
Igor, it's ALIVE!
As you know, I've been having problems reading my old backup DVDs with my Samsung DVD-writer (model SH-S182M)
This morning I tried a firmware update, first, using the same fimware version as it currently had (SB04). When that didn't work, I tried the latest version SB05.
After flashing the utility rebooted my computer, and I popped in a backup DVD expecting nothing, as usual, when all of a sudden XP's autoplay feature kicked in and scanned the DVD.
I must admit I am a bit skeptical, only time and a few reboots will tell.
Meanwhile, I greedily grab all my porn backups just in case it stops working soon...
This morning I tried a firmware update, first, using the same fimware version as it currently had (SB04). When that didn't work, I tried the latest version SB05.
After flashing the utility rebooted my computer, and I popped in a backup DVD expecting nothing, as usual, when all of a sudden XP's autoplay feature kicked in and scanned the DVD.
I must admit I am a bit skeptical, only time and a few reboots will tell.
Meanwhile, I greedily grab all my porn backups just in case it stops working soon...
Friday, January 4, 2008
New-Computer Woes
I've had my new PC for almost a month now, and for the most part, it's not had any problems. I say for the most part, because there were some issues I had with it.
The motherboard, an ASUS P5B-MX WiFI Solo AP sports 4 SATA ports and 1 IDE port. As I was upgrading everything besides the drives, this proved to be an almost fatal mistake. I had a 80GB, a 160GB and a DVD-ROM that were all IDE. One of these drives would be left out.
My first thought was to go USB and buy an enclosure, but I didn't really think that the transfer speeds would be up to par, and another plug on my power strip and wires running to my PC wasn't going to make that corner of my room any prettier.
Instead of buying a new SATA drive and saving myself a headache I stubbornly decided to try the roundabout, unorthodox, alternative way, using a SATA-to-IDE converter.
I knew my chances of finding one were slim as these devices weren't exactly regularly-used items, but I was loath to buy a new hard disk.
After asking around several computer stores in the Megamall area with no luck, I asked my uncle who happened to know someone who sold the very device I was looking for. Hindsight, I should have taken his advice and sold him the 160GB so my losses in buying a new SATA drive would be minimized but I still thought I could save more money with the converter.
The first unit I recieved was a dud. It failed to detect any of the drives. I had it replaced and the new one finally worked.
It wasn't without fault, it failed to detect either the 160GB or the DVD-ROM. There were no instructions with the device. It only detected my 80GB (single partition, jumpers set to Master) which was fine with me, as I could now use all my drives at the same time. My 80GB hosted my OS, but it posed no problem as the BIOS allowed booting from any drive.
Just to satiate my curiosity, I ran Nero's Disc Speed test to see if the SATA-IDE converter made things worse. Although I didn't have a proper control for the results, it was just as fast as the 160GB on the IDE.
With the IDE connected to the 160GB and the DVD-ROM, and my PC booting from the SATA-IDE connection, I mopped my brow of sweat and thought - problem solved!
No such luck.
This time, the problem came from the DVD-ROM. Up until I got the SATA-IDE converter, I was forced to switch between the DVD-ROM and the hard disk manually, shutting down every time I needed a file from one or the other media.
I recall having used the DVD-ROM to install most of the software on my PC with no problems. Now it was acting up and refusing to read most of my backup DVDs! CDs seemed to work fine, as did pirated DVDs such as containing the entire fourth season of the series 24.
Just my backup DVDs that contained my PC installers, PSP games and girl-on-girl porn collection was unreadable! I kept getting an error: "incorrect function" when trying to read my backups. I managed to get it working sometimes, but only if I did the following:
Windows then detects the DVD-R and can read it in explorer. However, opening and closing the tray caused the problem to re-appear.
I tried a System Restore and a new install of Windows XP but neither was able to get my drive working the way it used to.
Strangely enough, when I boot into DOS via UBCD, it can read the DVD backups just fine. The only problem is the DVD is flaky when it comes to booting. So booting into UBCD is a hit-and-miss affair. It has been this way since I got it, so maybe the DVD hardware really does have a problem.
Maybe I should just get a new SATA DVD-ROM save myself a headache.
The motherboard, an ASUS P5B-MX WiFI Solo AP sports 4 SATA ports and 1 IDE port. As I was upgrading everything besides the drives, this proved to be an almost fatal mistake. I had a 80GB, a 160GB and a DVD-ROM that were all IDE. One of these drives would be left out.
My first thought was to go USB and buy an enclosure, but I didn't really think that the transfer speeds would be up to par, and another plug on my power strip and wires running to my PC wasn't going to make that corner of my room any prettier.
Instead of buying a new SATA drive and saving myself a headache I stubbornly decided to try the roundabout, unorthodox, alternative way, using a SATA-to-IDE converter.
I knew my chances of finding one were slim as these devices weren't exactly regularly-used items, but I was loath to buy a new hard disk.
After asking around several computer stores in the Megamall area with no luck, I asked my uncle who happened to know someone who sold the very device I was looking for. Hindsight, I should have taken his advice and sold him the 160GB so my losses in buying a new SATA drive would be minimized but I still thought I could save more money with the converter.
The first unit I recieved was a dud. It failed to detect any of the drives. I had it replaced and the new one finally worked.
It wasn't without fault, it failed to detect either the 160GB or the DVD-ROM. There were no instructions with the device. It only detected my 80GB (single partition, jumpers set to Master) which was fine with me, as I could now use all my drives at the same time. My 80GB hosted my OS, but it posed no problem as the BIOS allowed booting from any drive.
Just to satiate my curiosity, I ran Nero's Disc Speed test to see if the SATA-IDE converter made things worse. Although I didn't have a proper control for the results, it was just as fast as the 160GB on the IDE.
With the IDE connected to the 160GB and the DVD-ROM, and my PC booting from the SATA-IDE connection, I mopped my brow of sweat and thought - problem solved!
No such luck.
This time, the problem came from the DVD-ROM. Up until I got the SATA-IDE converter, I was forced to switch between the DVD-ROM and the hard disk manually, shutting down every time I needed a file from one or the other media.
I recall having used the DVD-ROM to install most of the software on my PC with no problems. Now it was acting up and refusing to read most of my backup DVDs! CDs seemed to work fine, as did pirated DVDs such as containing the entire fourth season of the series 24.
Just my backup DVDs that contained my PC installers, PSP games and girl-on-girl porn collection was unreadable! I kept getting an error: "incorrect function" when trying to read my backups. I managed to get it working sometimes, but only if I did the following:
- Remove the hard disk from the IDE. DVD is the only device on it.
- Boot into Windows. Run Doug Knox's XP CD fix. This removes filters that CD-burning software may have installed and left when uninstalled.
- Reboot. Make sure desired DVD-R is already inside the DVD-ROM.
Windows then detects the DVD-R and can read it in explorer. However, opening and closing the tray caused the problem to re-appear.
I tried a System Restore and a new install of Windows XP but neither was able to get my drive working the way it used to.
Strangely enough, when I boot into DOS via UBCD, it can read the DVD backups just fine. The only problem is the DVD is flaky when it comes to booting. So booting into UBCD is a hit-and-miss affair. It has been this way since I got it, so maybe the DVD hardware really does have a problem.
Maybe I should just get a new SATA DVD-ROM save myself a headache.
Subscribe to:
Posts (Atom)
