Acidmods
Console Modding------ ( Here you can talk about your favorite Consoles ) => PSP's => PSP Phat (1000) => Topic started by: gr8npwrfl on May 25, 2008, 08:50:29 PM
-
I have a question for all the modders out there
The problem with all the mods that seem to be going on on this board are the switches to make them work. If you do more than one mod we all seem to have a problem on what functions to delete or what goofy keystrokes to create.
I want to add functions to my PSP not eliminate some.
I have been working on the multi - memory stick mod. The problem is you have to tell the controller chip how big each memory stick is so that the controller knows when to switch to the next chip.
To be able to use 1,2,4,8,16 gig sticks each memory slot will require three dip switches for a total of 12 switches. If I could add to the m33 control menu so that I can select them on the screen I eliminate all of the switches. My mod will allow up to 64 gig of storage space inside the PSP.
Now if I put in an amp for louder sound,
The 4 memory sticks
LED pulse mod controller
LCD back panel display
I will need to add 16 switches and two adjustment trimmers that will take more space than the mods and what will I give up to get them..
Not a good solution.
I have figured out a way for the mods to talk to the CFW AND the interface screen you could program in an xml text file so you can just select your mods on the screen of the PSP.
No one does that yet that I know of.
No programming required you create an XML template and that determins the background, The graphics, the color, and the options on your screen.
We should get together and create a standard that everyone can use there could be 65,536 different mods and if you create a mod that uses the interface you would be assigned a mod number.
The interface is so simple people have overlooked it.
A pic can talk to and get data from the irda interface and the custom firmware already supports the built in irda interface !
We can not only send data to the PSP firmware we can receive data from the firmware.
Instead of pressing the single button twelve times to select the type of led blink option you want you could just have the modes on the screen and select the one you want. NO EXTRA SWITCH MODS ANYMORE !
So if a person wants to use the idea for interface to their mods they will just request a number and no one else would use that number but them. That way no two mods would interfere with each other.
The setup interface for their mod would just be a template, you would not have to reprogram the CFW. When you upgrade the CFW your interface to your hardware mod still works.
The outside of your PSP would look stock. No funky switches
I looking for input from other people on creating this standard
-
hmm, sounds like a good idea, but the only team with enough experience would be Team M33, i've tried developing myself and i tell ya, it ain't a walk in the park
-
or instead of putting it into the cfw you could just make an app or program that works along with the cfw to interface with the mods
-
or instead of putting it into the cfw you could just make an app or program that works along with the cfw to interface with the mods
yes if you think m33 are the only people who can program the psp u are serously mistaken, Acidmods is more of hardware modding so it will be hardish to find a comperdent person to write this for u.
couldn't this just be done by programing a PIC?
-
programming ic is the solution yes
you won't be able to put it into a custom firmware, you will always end up doing extra switches if you want to turn mods on or off
because you can't just add a feature to the custom firmwares, you will need to choose what the psp has, you just cant add a extra software switch to it.
it is possible though with a programming ic as ghost_death said
-
I like the seperate app idea. I have already found a simple app that has the source code and I am looking into it.
If we have the pic pass commands structured like ID,Command,Data,CRC and make them packets we could define a command and data set that anyone doing a mod could use and talk to the same interface app.
The ID would select the xml text file that is used so your hardware interface would have a unique screen and command set to turn your mods on and off.
If we clearly defined the packets we could give a sample xml file and the code for the pic so that a person doing a mod would not have to be a programmer to use it.
The ird interface would be built into the CFW app and the ird software would be in the pic so that a user would just have to fill in their packets to get communication to the xml file the app reads from for the screen and options.
When you program a web page you do not worry about the underlying protocol of the web that makes the web page works you just use it !
-
As the app starts it would list the xml files in a menu. You just scroll to select a file, that file talks to a particular mod, and you are controlling your mod from a menu in the CFW. When your mod sends data to the app with your unique id the app knows which screen you are talking to by your particular xml file selected by your id.
Very straight forward very elegant and unlimited expandability.
We would have a doc that lists the command and data structure you just use it.
-
i like the app idea 2(since i thought of it) but you could maybe have an app that talks 2 a pic 2 the switches of the mod it wold cool but the only one that could not do that is if you do the dual nub you gotta take the on and off switch out but why has no1 just moved it some else on the psp