Acidmods
Console Modding------ ( Here you can talk about your favorite Consoles ) => PSP's => Topic started by: galaxy3arth on January 01, 2011, 05:39:19 PM
-
if you follow this link "http://www.sparkfun.com/products/8448" it will show an analog interface 4pin 2axis analog touch screen, and if you were to look at the port for the psp analog stick it is also a 4 pin 2axis analog input. if you search around the site you will find this "http://www.sparkfun.com/products/9224" a break out board for the touch screen. theoretically you could use the psp analog stick connection to connect the touch screen, because the way they work is virtually the same
so if you were to mod a psp and put the touch screen in you should be able to slid it in some direction and get a reaction. with out software ie .prx plugins the touch screen would not get full functionality, it could not select stuff. the coding concepts are farely simple. first of all you need a way to turn it on and off, because it would inter fere with the analog stick, simple enough. the next thing you need to keep in mind is that the plugin would probably be large like ir shell. it would have to have an x y net instead of the directional analog stick which has a dead zone and when some thing leaves it go in that direction. if you want to be able to tap some thing and have it activate the corresponding code such as opening the memory stick it would have to recognize the connection from the analog stick as a button like x or o. which is why I said to make an on off switch first. next to allow to activate these links of code it must first beable to follow a chain of code all the way to the creen coordinates for said activation or click.
then once touch screen taps at those coordinates on the screen it will follow the chain back down to activate it, thus select some thing by touch. it seems highly versatile and yet really difficult and like it would take alot of processing power. so this method of the plugin should only be used on small applications such as xmb, and internet being that it has a simple interface. this is only what I recommend because if done correctly no configuration would be needed for any thing it would work for games homebrew and all. but if you need a simpler more specific way to do it I would have an individual profile for each application like the way tiltfx works, but instead of that you would have to make a map:
{list the maximum and minimum x and y coordinates}
{then list each of the activation coordinates for each part}={and give a direct link to the code it corresponds to}
for instance
M{x{0,640}y{0,248}}
A{xy{20,30}}=b{a way to link to the code}
M being min and max
A standing for application
b standing for bridge
the bridge code be a complex way to get from to the code or it could be a second plain of buttons it could use to get to said part
for instance if you press use in this order (start)->(down)->(x)] to open a menu then you can have the {link to said code} be {(start)->(down)->(x)]}
this works good and well for simple tasks but for large tasks it would need multiple maps and motion maps.
a better way to do it would be to modify the code for macrofire and link it to a simple code for the net and touch settings. then give the plugin the ability to scan a number of more specific file types for the activations of a strings of code that could be accessed using the other buttons: analog d pad r and l homebar buttons and xo/\[] and have it assign such values to the right coordinates, and in the meantime have maps created for the other more common files to speed it up and make it less intensive. to work best it would have to run behind the games. in other words not a new firmware but an addition to the existing one running in the background at all times.
keep in mind I do not know any type of coding. this is just how the concepts of a working code would be so do not try to run the stuff written above more than likely it will no :psp:
Post Merge: January 01, 2011, 09:04:43 PM
could somebody who knows programing help with this. the installation was easy just need the software
-
it seems plausible to someone like me however i will let the pros handle this one IE; Modded Matt, and FOOKZ
-
if they cant help could you try to do it :beg:
-
considering this was something i was trying to do for a while w/ my zune and actually got it working b4 microsoft did... i may take a stab at this... MAYBE... if i can get the money for the parts ill look into it
-
if its a full touch screen you want to make when you touch the screen how will it make the button work as every button that is pressed down on the board it has to ground that button so how will you do that ? ???? like the psp nub that has its own line connected to ground as when the nub goes up its grounds the board trying to make sense here?
-
no need too, PSP2 has touchscreen :/
-
the ground on the nub is used the same way
Post Merge: January 05, 2011, 09:46:03 AM
no garuntee the psp2 will be hackable
-
well the plugin tht we would have to have in order for this to work would have to have buttons to press on screen sorta like this* (see attached pic) not tht i would know how to do it (atm) but im sure if i went through w/ it i would learn the coding for it
-
This might get you thinking: http://www.sparkfun.com/tutorials/139 (http://www.sparkfun.com/tutorials/139)
Then connecting the mouse to a PSP:
PS2 Maus an PSP Projekt - Part 5 (http://www.youtube.com/watch?v=oEwhgJ9XzHQ#)
Which brings us to the conclusion the touch screen will replace that mouse in the video.
LOL its easier said than done. But i think all the hardcore developing has been done already... just put the pieces together.
-
Hmm. This is quite interesting. Does the PSP use unix or is it a custom Sony OS?
-
thanks alot will try this sounds doable just wish it was in english ,but thats ok I understand alittle german too.
Post Merge: January 14, 2011, 09:03:16 AM
I think the hardware could be simplified a bit because both the touch screen to usb and the usb to serial use a atmega series I think I can use one to get the same result. potentially the two could be doing reverse conversions of the signal so I may not need almost any of it (though thats unlikely)
Post Merge: January 14, 2011, 09:30:56 AM
trying to find good schematics on the mouse to psp thing
Post Merge: January 14, 2011, 10:08:29 AM
first follow the tutorial from "http://www.sparkfun.com/tutorials/139" then use this "http://ww1.microchip.com/downloads/en/AppNotes/91055C.pdf". the only other thing I need is the schematic for the ps/2 to psp then replace the ps2 with the rest.
Post Merge: January 14, 2011, 10:12:29 AM
can some body help me get that. and hopefully along with it the plugin he used so it can be modified for any other uses for the touch screen
Post Merge: January 14, 2011, 12:48:49 PM
never mind I just need the pin outs for the psp slim serial port. I can just use this "http://thoralt.ehecht.com/projects/SIO2USB/SIO2USB.html" and attach it to the usb touchscreen mouse made in this tutorial "http://www.sparkfun.com/tutorials/139"
Post Merge: January 15, 2011, 03:33:58 PM
don't necessarily need the pin-outs anymore ,but for convenience sake it would be nice.
I have the whole circuit figured out now. going to up the voltage of the 2.5v that the psp gives to 5v .feed that through the power source of the touch screen and the v bus of the usb connection. pretty sure I wont need the TxD output from the psp any way but Ill leave it just in case. lastly analyze the signal through the whole thing along with the psp SIO to pc serial serial port converter here "http://nil.rpc1.org/psp/remote.html" just switch the RxD and the TxD. lastly modify a config file for the remote to recognize the signals as a remap for what ever you want it to replace. this includes taps slides and so on. just wanted the pin-outs so im not going blind on the last part :winker:
Post Merge: January 15, 2011, 03:37:50 PM
time to take out the touch screen and set it up this way
-
PSP Touch Screen (http://www.youtube.com/watch?v=1s4X61PYMKU#)
It's all been done (not by me though).
How to do it? That's easy:
Touchscreen is interfaced by a microcontroller with 2 ADCs and a UART. The µc gets the position of the touch and pushes it to the PSP's SIO. The PSP runs a plugin that receives the touch info a provides an API for homebrews to use the touchscreen or hooks into the scectrl or syscon to map touches to buttons/analog stick.
Can't give u schematics/code of PS/2=>PSP. But you can find schematics+code for a PS2 Controller for PSP mod on my website (tokyodrift-dev.info). It's basically the same.
-
thanks
-
I just recently revived my psp's. My son is now getting old enough to use them so I broke them out. I was looking over at the spark web site and came across the touch screen stuff and came back here and did some searching and look what i find. Amazing! So what does this all mean? Anyone came up with a shell yet? How can i get details on all hardware needed. I found everything for the interface, but How about some details on the mircocontroller? When i first found it I was thinking nub replacement, but this is much better. I can totally see a plugin for irshell working great. I got a phat boy waiting for this mod. Im pretty good on the hardware end if i get some one to point me in the right direction for the code? I'm willing to put this stuff together and try getting a shell to work.
Post Merge: January 19, 2011, 06:56:56 AM
Sorry for the double post but i had an idea. If we use a macro plugin with this we could use different touch motions to remap combos for in game play. example 360 cw rotation could be mapped as a combo. Not sure on the code but it makes sense to me. Any word on a packaged code yet?
Post Merge: January 19, 2011, 08:36:07 AM
Here's what I'm thinking. Remaping everything i use with my right hand , so the ^o[]X and R buttons to be remapped. example the new God of War. please mind the #'s are just examples not really locations in x:y
remaps -
"O" remaped to to a touch movement say x:0,y0 to x:0 , y:75. a movement to the right from center. there would have to be a range but this is just an example. in god of war this would be a grab motion. this could be mapped to a more complex movement i think.
"X" remapped to x:0,y:0 to x:75, y:0 a upward movement. A jump in the new god of war.
"[]" and "^" are low , high attacks, respectively. the have different combo with them.
simple mode remap for low attack ie single press on "[]" remapped as just a tap somewhere on the screen say, near x:-50, y:0
and a simple high attack ie single press "^" remapped as tap near x:50 ,y:0
next is hold "[]" remapped to x:-50,y:0 to x:-50,y-50
hold "^" remapped to x:50,y:0 to x:-50,y:0 this is because this makes you jump into the air after and ready for more combos, so all you have to do to continue combo is tap the position your at to continue w a low attack while in air.
I could go on and on but it doesnt matter because i dont have any of this infront of me yet. I need to get the hardware first. i would like to get started on the code for now i guess.
edit : new plan. get hardware running, then figure out how to internalize. (if I cant do that whats the point if its not portable) , then if its all in side the psp start thinking about code. maybe by then someone will create a plug in that makes it easier on us non code junkies.
-
not yet. working with a freind of mine on the code, but I am not on my home computer right now so I will send you the links to the parts when I get back (had them all bookmarked). the base plugin is probably going to be based off of the code tokyodrift used to hook up the ps2 controller. it comes in behind firmware and makes it recognise it as a completely new legit input. so you can see the function from any plugin game etc. including macro fire and remaps good idea man. it will help to have some support started to think maybe nobody was interested.
Post Merge: January 19, 2011, 08:55:21 AM
i am bad at code but those motion samples are a good idea. we will make sure to try and put those in, because they will have to be in the base plugin to work efficiently.
so if you were to look in a remap plugin with it enabled ther will probably be a list like so:
zone: x coordinate 1- x coordinate 2
y coordinate 1- y coordinate 2 = 0x00000123
then program in multiple ones for different areas of the screen. they would not be exact as the psp does not function that way but it wouldnt change much. on the psp end a double tap of that region would mean a recognized button press. the upper part wil either be in the behind the firmware plugin syscon or in the microcontroller.
thats the base concept of how we will program in these motions. slightly diferent for drags and all but
no trouble. though I agree it should be mostly for the rightside controls.
Post Merge: January 19, 2011, 09:01:16 AM
was thinking about also getting the datel tiltfx to work for cfw be cause that should be simple maybe I can make a way for that and touch screen to work at the same time. let me know what you think.
Post Merge: January 19, 2011, 09:12:18 AM
the circuit can be simplified and shrunken not only does the atmega168 give the outs for usb but it already has rs232 protocol outs, and there is an identical board called the arduino mini so the size just got like 3 to four times smaller! :drunk:
-
the circuit can be simplified and shrunken not only does the atmega168 give the outs for usb but it already has rs232 protocol outs, and there is an identical board called the arduino mini so the size just got like 3 to four times smaller! :drunk:
ATmega168 does not have USB. It also doesn't have RS232. It just has a UART, as (i think) all AVRs have. The Board using an Arduino will be way bigger than making your own PCB. You can probably use an ATTiny with about 10 Pins. You could use 5V from the PSP if you make this mod internal. PCB could be about .5 by .5 inch or something I guess. It'd pobably need some code tricks to pack everything into such a small avr but it could work. Use assembler.
-
thanks want to get the circuit as small as possible.
Post Merge: January 19, 2011, 10:08:51 AM
I am pretty sure we can get the attiny to work. simple enough to get it to commuinicate in rs232 just need it to send the analog data
-
Another thought , Cw cheat is run in the backround of games and pops. it has a data base file. it also reads the iso code on the game and auto loads cheats for that game and it will auto load remaps and marcos as plugins. Some similar coding could be used. to update new games just copy paste note file into database. then it could also be user defined along with presets for each game. AS far as i can tell by reading some one else's tech sheet on the psp remote data bus, the psp sends info depending on what the psp is currently doing. remote buttons have different effect on xmx and in music etc. if we can read this we can tell the touch interface to switch modes between xmb , game etc
-
cant use the attiny2313 or 4313 they dont have ADC input, the touch screen needs ADC input. searching for other options
Post Merge: January 19, 2011, 02:42:56 PM
unless there is a way to make it take adc inputs, but highly doubtful
Post Merge: January 19, 2011, 02:49:52 PM
I think the attiny84 will work has higher sflash than the 44 and 24. 14pins 12ADC compatable
Post Merge: January 19, 2011, 03:06:14 PM
will have to use max2323 aswell
Post Merge: January 19, 2011, 05:03:13 PM
I just finished a rough schematic.
Post Merge: January 19, 2011, 05:13:23 PM
any ideas on a way to make the datel tlitfx 3d motion sensor work on cfw and then integrate it with the touch screen circiut or to have both working at once?
-
What about adapting ipod touch interface some how? if we can use that like a shell , and maybe we can use ipod touch apps. idk just a thought. As far as psp games and psx eboots i think that something like cw cheat is a good place to start to get remaps and macros.
I was thinking about doing some graffix work on a new shell no code yet just a skin, and see how it might look. then when i get something i like ill post and see what you think. Then maybe i can get some help w the code for the new shell.
-
hurray this is happen'n bottoms up :drunk:
-
A couple of questions about the hardware. I am not that familiar with theses micro controllers you guys are referencing, so i have some questions about them. the avr or what ever is used to hold the data is flashed with the code on the programmer. Now heres my question, Does the chip have to stay in the programmer or can it be removed and put into a board created for the psp? Im thinking it is removed after being flashed. So if this is true then can a chip be flashed and then say mailed? Next bit of questioning rely s on the previous statement about the chip being removed to be true also. If the chip is on a separate board inside the psp, what does the board need to be powered? More importantly what are the over all power requirements to make this work? i believe the touch screen overlay needs 5v not sure tho.How big would said board be? small enough to fit next to mem. stick where people put sound mods chips and cams? If more power is needed i was thinking about using umd drive for external battery internalized. the psp slim has some nice pockets to hide breakout boards and given its expanded functionality over the the remote port, i would think there might be more hardware available features and control over that port. the phat boy ports i believe are only six pin the slim is a 12 pin. More pins makes me think theres more going on there? From what i can gather we can bump up to +5v out of the audio port to power this device. the 2.5v (?) out of audio jack seems like its enough to power the microcontroller. but i the touch panel I think needs 5v?
Post Merge: January 19, 2011, 10:13:18 PM
I've been sitting here with the psp in my hand doing touch motions to figure out the ergonomics of the controls. During game play the screen could be divided into a left and right section. Controls for left hand and controls for right hand. Maybe even a "shift" button to initiate the touch on each side . next to the l+r buttons . Maybe use the l+r buttons as "shift keys". but then we loose l+r to dedicated shift keys. So i was thinking a button like a l2 r2 button could work as a shift key to initiate the touch on the appropriate side. Question, can the touch screen recognize two inputs at the same time. say to create a pinch or expand motion?
-
cant do the multi touch the way the screen works is through analog resistance. the voltage is fed on one side of the screen and the otherside when pressed uses resistance to relay the values. you can look at a sense table on the sparknotes site. the link should be above somewhere. as far as the micro controllers go the avr is used as said and may be mailed. once a program is loaded if a new program is not loaded it will boot the old one.
Post Merge: January 20, 2011, 08:48:58 AM
I found an already existant schematic for a attiny84 used with rs232 protocol communication. it has four open ADC slots and an extra 2 if we want to add anything else. since the psp doesnt use true 232 I think the mega232 is not needed. the code provided with the schematic can be used we just need to add the code to process the touch screen inputs then the hard ware side is done. the touchscreen if internalized will fit next to the memory stick, and the 5v for touch screen and microcontroller would come from one of the 5v spots on the inside of the psp, for instance the path to the leds. however if we use the external port we can use a stepup to bring it to five volts and a stepdown for the out puts to the psp side. my freind who was going to do the coding said he wouldnt do it so I think I will post a schematic to see what you guys think and somebody on here should be able to make the code if I give them the info and the code for rs232 we're building it off of.
the difference between the phat and slim remote ports is that the slim supports video out without remote joy light. it probably has another voltage source for the full screen out ,but I dont know much about that part. the six for the remote are the same. on the chip I think we should add a port for both the 5v from the psp for internal, and the regular serial port for external. I have three more programer I can bring this to so Im not worried much.
if you look up the table the pin numbers will be different because its on a different microcontroller. but the actual chart is
X sense Y sense
X1 PA0 5v ADC
Y1 PA1 float GND
Y2 PA3 ADC 5v
X2 PA2 GND float
Post Merge: January 20, 2011, 09:12:31 AM
if we can get the datel tilt fx to work too then when you use the full screen out you would have a similar control scheme motion sense instead of touch screen. I dont think the touch screen would be as nice for full screen. the current software for the datel tiltfx is for OFW only
Post Merge: January 20, 2011, 09:44:00 AM
the neo flash motion kit plugin may work for it ,but I dont know ,because its for 3.xx firmware.
Post Merge: January 20, 2011, 09:45:40 AM
as for control concepts for first person shooter games drawing a circle to zoom in would be cool.
-
Back to my split screen control idea, if we put to buttons on the back of the psp for shift purposes we could use middle fingers to activate right side regular controls by hold right side button down w middle finger. kinda like an interrupt. or vice versa activate touch by a button on the back. Im working on the shell now, basing it off irshell. i think this would be a faster way to integrate than trying to create plugins and such for xmb. I like using irshell because we get 5 user created shortcuts. plus many other features. Ill try to have at least an image file for you guys to preview some time tonight.
Post Merge: January 20, 2011, 02:50:40 PM
Here is what i got for the shell so far, I gotta walk away for a bit to work on some other stuff but i wanted to post what i got so far.
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi253.photobucket.com%2Falbums%2Fhh69%2Fmarianard_2008%2Firstouchmenu.jpg&hash=467d3eedc37f22c5b26f8e8747992ecef9abe2bc)
-
This thread is messing up I can't load the page. But I did see your having trouble loading pics. I had to host the picture some where else like photobucket, then copy the "[img]" code into your reply. pm me if you have more trouble.
-
whatever galaxy uploaded last crashed the page...
-
thanks dont know why it crashed just took a regular image it was a JPEG image just took it
-
I'm updating this because after some searching i found a lot of fake information. So, I wanted to clear some things up.
So this jube character i believe is out there duping people into thinking he created a touch screen for the psp. I think he is a fake. What we are trying to do here is real.
here are the facts so far...
1. there is a direct touch screen over lay for the psp screen. (not a direct plug'n'play yet)
2. It is connected to the psp through a microcontroller (still working on programing) through the psp's sio port and powered by the audio jack. it could be modded internally also and powered by internal psp power. side note : a replacement faceplate with overlay pre-installed might be possible.
3. programing ! the way this works is the mirocontroller is flashed using a serial interface with the pc. It is taught how to input signals from the touch screen and output communication to the psp through rs232. basic controls x,y,o,[], d-pad , l&r ,even analog stick can all be programed fairly easy. button emulation.
4. problems... code support! Writing code is difficult for me. I have basic programing knowledge at best. I think i understand how to design homebrew to work w this feature, as homebrew can be set up how ever you want, depending on how good of a dev you are. xmb control is easily possible also since controls are very simple in xmb.
goal:
1:create a plugin that can be updated with a database file so users can add/modify the script for the controller. ie: preset / user based macro's and maps , which contains the game code for each game. like a cw cheat db file.
2: create a homebrew which can read inputs from the touch screen and map out the buttons and create macros., and then add the script to the db file. So users can create they'r own touch maps and macros with out writing code to the microconroller, and share db data with others.
3: create another homebrew app/or plugin for key board inputs. this i think has been done for the xbox chat pad mod. ie:on screen touch keyboard.
a huge Thank you goes out to all involved in this project and acidmods for hosting such a good site.
-
as far as the coding goes my freind brandon may be able to help with the code.
but as far as the project goes thats sounds good. If you want to see an example of the db file manipulation and all, I can tell you there is a code out there that you get when you buy the datel tiltfx which has three analog signals. I have bothe the tiltfx and the code problem is the folder it installs is all .DAT files so I think both the plugin it would run on ofw (program wont run on cfw, when in game ,but the program to edit db it works great) the reason it doesnt work is because I think both the plugin and the eboot are both in the dat file. so I havent been able to use prx exractor or pbp unpacker because they dont recognize .DAT files. I send it all to you if you want I know the tiltfx uses the same inter face we are planning ( i took it apart) just a micro controller a step up trans former to convert the analog signal and talk through rs232 protocol. we could probably base our stuff off of it.
Post Merge: January 21, 2011, 08:52:11 AM
I think that jube guy is a fake too. most people who make something like that would put up a tut or atleast information on how to do it. if it was real he would have showed the chords and all to prove it wasnt just connected to computer or something.
Post Merge: January 21, 2011, 09:00:20 AM
about number 2 on your post the face plate of psp has the plexiglass part just glued on so we could pop that off ( i have done it before ) and do alittle light dremeling to get it to fit right. then we can just glue it into place.
Post Merge: January 21, 2011, 09:44:56 AM
just looked at the spark notes page again.
the code for detecting the x y values was there this is it
void read_x(void)
{
DDRC = 0b00010010; // Output on PC4(5V) and PC1(GND), Input on PC4(ADC)
sbi(PORTC, 4); //pull PC4 to 5V
cbi(PORTC, 1); //pull PC1 to GND
_delay_ms(1); //wait for screen to initialize
ADMUX = (1 << MUX1); //ADC2
ADCSRA = (1 << ADEN)|(1 << ADSC)|(1<<
while(ADCSRA & (1 << ADSC));
l = ADCL;
h = ADCH & 0x03;
h = h << 8;
h = h + l;
}
just need to change values so that they match the attiny84. these are for the atmega168. pins are alittle different too. after I do that I just have to set a buffer time for screen to charge and a buffer for the rs232 communication to tell psp to receive the x and y values of the touch screen then send the values gotten through the above.
almost there. :tup:
Post Merge: January 21, 2011, 09:52:35 AM
my bad, buffer time for screen to charge is already acounted for (1ms).
Post Merge: January 21, 2011, 10:08:46 AM
this code also needs to be modified to bridge the D+ and D- values they used into the R(x) we need.
-
After some thought about the face plate idea , i came up with a perfect plan for bolt on application for this hardware. full replacement case. seperated into two parts.
part1 faceplate with overlay replacing the acrylic screen cover.
part 2 the rear of the psp case is unmodded except for a hole next to the psp sio port. this is for the cable to plug into that port. Ive been throwing the idea around in my head to include a usband or serial port also, for expanding this microcontroller to handle other peripherals.We mount the board for the microcontroller to the rear case above the memory card slot. Maybe have usb/serial port in this area also.
the to parts are just connected by the ribbon cable off of the touch screen overlay.
this design is so people can do this mod without any real internal modds to the psp. it would be just a lil more complicated than a case swap.
as far as coding the code used here http://www.sparkfun.com/tutorials/139 (http://www.sparkfun.com/tutorials/139) .
Will this work for this?
void read_x(void)
{
DDRC = 0b00010010; // Output on PC4(5V) and PC1(GND), Input on PC4(ADC)
sbi(PORTC, 4); //pull PC4 to 5V
cbi(PORTC, 1); //pull PC1 to GND
_delay_ms(1); //wait for screen to initialize
ADMUX = (1 << MUX1); //ADC2
ADCSRA = (1 << ADEN)|(1 << ADSC)|(1<<
while(ADCSRA & (1 << ADSC));
l = ADCL;
h = ADCH & 0x03;
h = h << 8;
h = h + l;
}
I believe this is the code for reading the inputs of the touch screen.
so next step is getting it to communicate to the psp.
----------What about the "neo" thing? doesnt that support homebrew and cfw?fact neo does not support slim. dont know why,yet. but does support everything else.
----------what about .cfg files?
-
yeah the pin assignments have to be changed. but yes it will work
Post Merge: January 21, 2011, 02:49:07 PM
one more thing it seems this may give to transmition signals not tottally sure but I know the are going to usb which has D+ and D- but we need one output T(x) for rs232
Post Merge: January 21, 2011, 03:15:32 PM
the neo flash thing doesnt work with slim because the ports alittle different ,but I cant imagine that and updating it for current firmware would be too hard. yes it does have a config file easily edited
Post Merge: January 21, 2011, 03:29:26 PM
I know these schematics are ghetto ,but what the hell its the best I could do. I have no engineering software what so ever so let me know what you think.
Post Merge: January 21, 2011, 03:33:26 PM
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi1226.photobucket.com%2Falbums%2Fee403%2Fgalaxy3arth%2FIMG_1202.jpg&hash=ef5c2ef004e57b2004ab60719f675bfd7354c596)
Post Merge: January 21, 2011, 03:34:43 PM
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi1226.photobucket.com%2Falbums%2Fee403%2Fgalaxy3arth%2FIMG_1201.jpg&hash=b1c38e4f0625f71d26df23ad4971a7bf21b37c96)
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi1226.photobucket.com%2Falbums%2Fee403%2Fgalaxy3arth%2FIMG_1200.jpg&hash=8c8540bf0494606d006777ef25815e8e4e44b490)
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi1226.photobucket.com%2Falbums%2Fee403%2Fgalaxy3arth%2FIMG_1199.jpg&hash=4e2efc5866fcf1a003353bfdd4e354f0b5323b35)
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi1226.photobucket.com%2Falbums%2Fee403%2Fgalaxy3arth%2FIMG_1203.jpg&hash=d60f5c8f1a3071b8a12d65f4c15a1365f4d1ecf2)
Post Merge: January 21, 2011, 03:37:17 PM
the for wires that go to the right go to the touch screen as
going down
X2
Y2
Y1
X1
-
if you can clean it up a lil ill run it through cadd electrical. and post something more professional and easier to read. Dont get me wrong, awesome job. I got together a team of modders that are local to me, and a friend who is good w c++ . and we are ready for mass production. well kinda. its not like we have 200 lil Korean kids to do the work for us. The first of the month Im going to order all the hardware we need. I want to have a working prototype modded into a psp by the end of the month.
-
awsome man I will clean it up and post it up though with the camera I am using I will probably draw it on a poster. the picture is going to be huge! so I will try to down size it.
gotta be nice to have a network of people to work with.
Post Merge: January 21, 2011, 04:36:26 PM
useing this schematic the voltage supplied to the touch screen in sent through the microcontroller.
Post Merge: January 21, 2011, 05:27:49 PM
progress progress :hifive:
-
If i can Ill try to get a single sided pcb designed from what you come up with. I have my own etching kit so creating a prototype pcb for this is not far away. If you can, plaese give me a list of everything needed hardware wise. from the schematic i can see a cap and some resistors and the attiny but what else? If you give me a list Ill find a good supplier.
question: what can we do about creating our own plug for the psp's sio? Having to cut a remote control seems like a waste of money and time. I think I came across someone who connected some device through the sio that made his own plug. Ill see if I can find it again.
-
3x2 ICSP conector
12k resistor
C 0.1uf
C 1uf TAG
and you can make the SIO plug from scratch saw it once. on the psp 2000 I still dont know the exact pin outs, but I asume its the same plus 6 for the video ports. although it could always be rearanged weird but check this page for phat pin outs. "http://mc.pp.se/psp/phones.xhtml"
Post Merge: January 21, 2011, 06:02:58 PM
all the rest of the circuit is inside the attiny84 and how its programmed.
programming ( very important)
-
As for 2k pinout: http://forums.ps2dev.org/viewtopic.php?p=65070#65070 (http://forums.ps2dev.org/viewtopic.php?p=65070#65070)
are you sure u can solder that avr? (hot air soldering!).
MLF is 4x4mm in size
use PA5 and 6 for UART pls (can use hardware usi then)
dont use a 6pin connector for ISP but just some testpads (if u want to fit the whole thing into a psp)
u can probably make this single sided
I doubt u need the electrolytic capacitor if u use 5v from the psps hardware
reset pullup could become a problem for signle sided pcb
use assembler for programming, not C++ (can optimize more)
use external clock for stable uart (smd oscillator is almost as big as the avr but probably the smallest u can get)
-
Thanks Tokyo, the 2000 pin out looks great, thanks so much for that.
As for the soldering of the avr , I thought I seen a socket to accept the chip. I was thinking the chip could be flashed on the programmer and just popped into the socket?
Also Im thinking that we should include a usb adapter to add a usb device like a mouse or keyboard. So maybe if we use the design found here... (https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fwww.sparkfun.com%2Ftutorial%2FUSB%2520Touchscreen%2520Mouse%2Fschematici.jpg&hash=c075aaa2a005b5c91a9180aa1379f1e4b41232d7)
We then adapt usb to serial on our board. the back to usb for extra peripheral? I dont know the power requirements for ATMega168 but the replacement the ATMega328 says 1.8V to 5V operating voltage. I think this is the rout to take instead of the attiny?
-
Forget about USB. No way to implement a software usb host.
Sockets/DIP are for losers, use MLF for a tiny PCB
PSP should provide stable 5V (internal), no need for low volate avrs or boost converters
maybe u should use a resistor for SIO AVR TX line though
you dont have to use a remote cable if u want to make it internal
if u want usb host use arm (stm32 perhaps?)
-
As far as using internal 5v I already thought of that, but the the idea was to make this as easy as a case swap with everything pre-installed on a replacement shell. plug into the sio port and install needed files onto memory stick. Run a configuration setup (so users can define presets or load database logged pre-installed presets). and the person is good to go and now can use the touch screen in anyway they want. This way its pretty much plug'n'play for retail users. But I will do an internal permanent mod. Probably with one of my fats. Go back to 1.5 too. But if we make it easy and self contained one could always cut our sio plug and install internal . and we maybe can put a 5v on the board to do internal power. We can drop the usb thing, i was just brainstorming. but I think a host is possible and the idea is touch screen usb code is already written. and if we have a usb port maybe we can make it so users could reflash they'r avr's ?
-
software usb host is more or less impossible on an avr
usb client is possible
sw usb bootloaders are existing but rare i guess
if u make it external user cant hear sound anymore and cant use headphones, awesome
make it internal and everythings fine
-
for the case swap idea we need to ad an internalized plug to make it pretty to keep the functionality of the SIO port and so we can still take apart psp for other mods easily.
Post Merge: January 22, 2011, 02:12:29 PM
thanks well use a 16mhz crystal then and I will make the changes to the schematic.
oh yeah thanks for the slim pin out
Post Merge: January 22, 2011, 02:22:36 PM
sourdering simple (just have skills).
-
I thought i posted a reply but it must not have went through. So Ill say again.... We cant just add this (https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fwww.sparkfun.com%2Ftutorial%2FUSB%2520Touchscreen%2520Mouse%2Fschematici.jpg&hash=c075aaa2a005b5c91a9180aa1379f1e4b41232d7)
to this ? (https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fthoralt.ehecht.com%2Fprojects%2FSIO2USB%2FSIO2USB-schematic.png&hash=a9e1666ba9042cca6818b7303d167921a3c8c3be)
Post Merge: January 22, 2011, 03:10:06 PM
And Tokyo in regards to loosing audio the psp remote puts audio out why cant we?
Post Merge: January 22, 2011, 03:15:48 PM
Sorry for the double post but I just remembered with some prx or app you can still have audio with something plugged into the audio port.
-
I already thought of this ,but this can be simplified which is what we were trying to do.
I geuss if you want to do this to se if it works first ,but I thought that was only meant to connect to a computer where you have to send the request to transmit signals yourself.
go ahead and try it if you want, I have no qualms just thought we could make it smaller.
I am still going to get the other schematics done just in case. are you familier with uart?
I am not I have never used one.
-
my reason for going with the usb idea was so other devices could be programed to work with this design. But its not needed. I know where to get lib for usb touch code. this might speed up the process. because the code is already written for both sides.
Post Merge: January 22, 2011, 03:53:49 PM
this set up is also good for debugging and dev. for prototyping this might do then simplify. prove it works then make it smaller.
Post Merge: January 22, 2011, 04:19:00 PM
quick question about pin outs on slim. Why would a simple component cable need all 12 pins? im going to crack open the lil box on the cable and see whats up.
-
good idea let me know whats in it. cause I never had the cable for slim. only thing I got was the datel tiltfx (sadly disappointed) it doesnt work with cfw. I agree making it this way is good for prototyping ,and support for multiple devices would be great. I think the SIO is the gate way to things unknown as far as modding goes. even though its slow all HIDs should work.
Post Merge: January 22, 2011, 05:40:09 PM
as for the usb touch code it does have to be proted to psp first then made to work with rs232 protocol
Post Merge: January 22, 2011, 06:00:13 PM
this mod could nicely replace the dual analog situation I would much rather have a variable speed touchscreen than a second analog
Post Merge: January 22, 2011, 06:02:42 PM
the cable probably doesnt use all the pins
-
I came across this b4 and now I have a better understanding of it check it out. and an interesting point is brought up at the end. -thanks to "mc" at ps2dev
Ok, now I can't keep my soldering iron out of the remote any longer.
I built a snooping device using an EZ-USB microcontroller, and logged all the traffic between the PSP and the remote control.
First of all, forget what I said about pin 3 and 6. Looking at the logs, it is clear that pin 3 is the PSP talking, and pin 6 is the remote.
Without further ado, here are the logs I captured:
Cold start
=======
Pin6 00:00:00.557 : f0
Pin6 00:00:00.617 : f0
Pin6 00:00:00.677 : f0
Pin6 00:00:00.737 : f0
Pin6 00:00:00.796 : f0
Pin6 00:00:00.856 : f0
Pin3 00:00:00.870 : f8
Pin6 00:00:00.876 : fd 80 01 01 01 81 fe
Pin3 00:00:00.906 : fa
Pin6 00:00:00.911 : f0
Pin3 00:00:00.916 : f8
Pin6 00:00:00.921 : fd 83 01 a8 00 47 6d fe
Pin6 00:00:01.001 : f0
Pin6 00:00:01.061 : f0
Pin3 00:00:01.080 : f0
Pin3 00:00:02.430 Framing error (BRK?)
Pin6 00:00:02.430 Framing error (BRK?)
Pin6 00:00:02.555 : f0
Pin3 00:00:02.567 : f8
Pin6 00:00:02.571 : fd 80 01 01 01 81 fe
Pin3 00:00:02.600 : fa
Pin6 00:00:02.605 : f0
Pin3 00:00:02.617 : f8
Pin6 00:00:02.620 : fd 83 01 a8 00 47 6d fe
Pin3 00:00:02.650 : fb f0
Pin6 00:00:02.655 : f8
Pin3 00:00:02.667 : fd 03 01 02 fe
Pin6 00:00:02.680 : fb
Pin3 00:00:02.683 : f0
Pin6 00:00:02.685 : f0
Pin3 00:00:02.700 : f8
Pin6 00:00:02.705 : fd 84 00 00 84 fe
Pin3 00:00:02.719 : fa f0
Pin6 00:00:02.725 : f8
Pin3 00:00:02.733 : fd 02 00 02 fe
Pin6 00:00:02.745 : fa
*
Pin3 00:00:03.749 : f0
Pin6 00:00:03.757 : f8
Pin3 00:00:03.767 : fd 03 00 03 fe
Pin6 00:00:03.782 : fb
Pin3 00:00:04.800 : f0
Pin6 00:00:04.807 : f8
Pin3 00:00:04.817 : fd 02 00 02 fe
Pin6 00:00:04.832 : fa
repeat from *
As I already had seen on the oscilloscope, the last exchanges are repeated every second indefinitely. By pressing the button, I can get other exchanges:
Play/Pause Pressed
=============
Pin6 00:00:38.302 : f0
Pin3 00:00:38.317 : f8
Pin6 00:00:38.322 : fd 85 01 00 84 fe
Pin3 00:00:38.351 : fb f0
Pin6 00:00:38.357 : f8
Pin3 00:00:38.368 : fd 03 00 03 fe
Pin6 00:00:38.382 : fb
Play/Pause Released
==============
Pin6 00:00:42.250 : f0
Pin3 00:00:42.268 : f8
Pin6 00:00:42.275 : fd 84 00 00 84 fe
Pin3 00:00:42.301 : fa f0
Pin6 00:00:42.310 : f8
Pin3 00:00:42.334 : fd 03 00 03 fe
Pin6 00:00:42.350 : fb
(these logs show both one key even and one periodic event each.)
From studying this, much of the protocol becomes clear.
Control characters
============
F0 : I want to speak
F8 : Go ahead and speak
FD: Message begins
FE: Message ends
FA: Message received ok (phase 0)
FB: Message received ok (phase 1)
If a message is not acknowledged with FA/FB in due time, F0 is sent again to initiate a retransmission. If three F0's go unanswered after a connection has already been established, some kind of BREAK seems to be used to reset the communication (it's a low pulse longer than 9 bit lengths, but I haven't measured the exact length).
The actual messages begin with one command byte, the least significant bit of which is the phase bit, which is not part of the command itself. The phase is inverted for each successfully acknowledged command, so that you can tell a new command from a retransmission of an old one. This is also why there are two acknowledge codes.
After the command comes zero or more data bytes, depending on the command, and finaly a checksum, which is XOR of the command byte and all data bytes.
The periodic command, which is sent by the PSP, has command code 0x02, and one data byte which seems to be always zero.
The remote uses commands 0x80 and 0x82 during the init phase (presumably all commands that go from the peripheral to the PSP have the MSB set), probably to identify itself and perhaps set some parameters.
When keys on the remote are pressed or released, the command 0x84 is sent (this is also sent during the init phase, to tell which keys were already pressed when the remote was plugged in). It has two bytes of data, which is a 16 bit (little endian) bitfield of which keys are pressed. The keys are
0x0001: Play/Pause
0x0004: Fast Forward
0x0008: Rewind
0x0010: Vol +
0x0020: Vol -
0x0080: Hold
The remaining 10 bits do not correspond to any key on the remote, but the jumps in the codes suggest that they might be assigned to keys present on more feature-rich remotes.
Post Merge: January 22, 2011, 06:38:05 PM
could this be the extra controls we need? hmmm "The remaining 10 bits do not correspond to any key on the remote, but the jumps in the codes suggest that they might be assigned to keys present on more feature-rich remotes. "
Post Merge: January 22, 2011, 06:41:42 PM
Oh and the cable thing was kinda weird. it doesnt use all of the sio pins only the wires needed but there is something in the box. probably sends a signal back to the psp saying this is not a composite cable, its component. but i would like to find some more data on the slim only remotes and see what kind of info is going through the sio on the slim.
-
What are you guys talking about? The problem about software usb is not the usb plug but the software. A simple avr is just not powerfull enough to make a software usb host.
THE TOUCHSCREEN IS NOT USB!!!
it's just a regular resistive touchscreen interface
what's wrong with you guys?
Also forget about the remote thing, we can just switch that off and replace it with our own protocoll
why don't u just make everything internal but presolder the SIO lines to the SIO plug (internal), then the user could just swap that part too when he installs the new faceplate
-
I can't believe I didn't see that. The design "psp sio2usb" is designed to work with the pc as usb host. Sorry Tokyo.
I appreciate your input Tokyo but I would really like this device to as easy to install as possible. This way you dont need a modder to complete the install. I think if we use a device similar in design to the skype phone, and replace the face plate only , now thats simple. and will look very sleek. A face plate switch is very simple, no need to go any further into the psp. I like the idea of replacing the sio port with our kit but we need the whole board then not just the sio plug because the plug then needs to be soldered to the board. But i can't find replacement sio boards. I can find sio plugs for fat and slim but not whole boards. I like the idea of it completely internal. for guys like us thats fine but for the 10 year old kid down the street , who's dad has the money but no electrical skills he can just fork over the bucks to have it plug 'n play . And like i said b4 how hard would it be to take apart what we make and If your a capable modder , install it internal yourself. think of the masses not the guys who are modding. look at most of the question and requests for help around here, not everyone is as quite as skilled as you or some of the modders out there.
Post Merge: January 23, 2011, 05:54:51 AM
As far as sio boards if anyone knows where to find them I need one for one of my slims. If I find one Ill try the modd your way .
Post Merge: January 23, 2011, 06:24:02 AM
came across this thought i would share it here all thanks to Tyranid . (this is the guy to talk to about psp code dev.)
http://www.docstoc.com/docs/28752025/psp (http://www.docstoc.com/docs/28752025/psp)
this page has a ton of info. most of it is over my head. but there is some interesting code regarding the controls of the psp.
Post Merge: January 23, 2011, 08:27:44 AM
update: downloaded neo demo src code. going to see if I can do a lil reverse engineering. The datel unit gets uppdates from sony i guess , 5.03+ofw only?
so inside the demo package is a few files one i opened in note and this is what i find "a goldmine of code"
All thanks go to the neo team.
TARGET = rolling_ball
OBJS = main.o graphics.o framebuffer.o
CFLAGS = -O2 -G0 -Wall
CXXFLAGS = $(CFLAGS) -fno-exceptions -fno-rtti
ASFLAGS = $(CFLAGS)
LIBDIR =
LIBS = -lpspgu -lpng -lz -lm
LDFLAGS =
EXTRA_TARGETS = EBOOT.PBP
PSP_EBOOT_TITLE = Rolling Ball
PSP_EBOOT_ICON = NEO_logo_small.png
PSPSDK=$(shell psp-config --pspsdk-path)
include $(PSPSDK)/lib/build.mak
LIBS += -lpsphprm_driver
Post Merge: January 23, 2011, 08:29:51 AM
-----edit wrong code sorry grrr.
here yah go....
/* NeoTeam 2007 */
/* www.NEOFLASH.com (http://) */
#include <pspdisplay.h>
#include <pspctrl.h>
#include <pspkernel.h>
#include <pspdebug.h>
#include <pspsdk.h>
#include <pspgu.h>
#include <png.h>
#include <stdio.h>
#include "graphics.h"
#define printf pspDebugScreenPrintf
#define PSP_UART4_FIFO 0xBE500000
#define PSP_UART4_STAT 0xBE500018
#define PSP_UART_TXFULL 0x20
#define PSP_UART_RXEMPTY 0x10
unsigned int i = 0;
int pspDebugSioWaitGetchar(void)
{
i = 0;
while((i < 100000) && (_lw(PSP_UART4_STAT) & PSP_UART_RXEMPTY)) i++; // loop until rx buffer full
return _lw(PSP_UART4_FIFO);
}
PSP_MODULE_INFO("Rolling Ball Demo", 0x1000, 1, 1);
PSP_MAIN_THREAD_ATTR(0);
/* Exit callback */
int exit_callback(int arg1, int arg2, void *common) {
sceKernelExitGame();
return 0;
}
/* Callback thread */
int CallbackThread(SceSize args, void *argp) {
int cbid;
cbid = sceKernelCreateCallback("Exit Callback", exit_callback, NULL);
sceKernelRegisterExitCallback(cbid);
sceKernelSleepThreadCB();
return 0;
}
/* Sets up the callback thread and returns its thread id */
int SetupCallbacks(void) {
int thid = 0;
thid = sceKernelCreateThread("update_thread", CallbackThread, 0x11, 0xFA0, 0, 0);
if(thid >= 0) {
sceKernelStartThread(thid, 0, 0);
}
return thid;
}
unsigned long int Xaccel = 0;
unsigned long int Yaccel = 0;
int main() {
char buffer[200];
Image* ball;
//SetupCallbacks();
pspDebugScreenInit();
/* Initialise SIO*/
printf("starting..");
pspDebugSioInit();
pspDebugSioSetBaud(510416);
printf(" initialized");
initGraphics();
sceCtrlSetSamplingCycle(0);
sceCtrlSetSamplingMode(PSP_CTRL_MODE_ANALOG);
sprintf(buffer, "ball.png");
ball = loadImage(buffer);
float x = 480/2-16;
float y = 272/2-16;
int xvel = 0;
int yvel = 0;
if (!ball) {
//Image load failed
printf("Image load failed!\n");
} else {
sceDisplayWaitVblankStart();
blitAlphaImageToScreen(0 ,0 ,32 , 32, ball, x, y);
flipScreen();
}
int i = 0; // used for averaging
while(1)
{
SceCtrlData pad;
sceCtrlReadBufferPositive(&pad, 1);
Xaccel = 0;
Yaccel = 0;
for(i=0;i<10;i++)
{
pspDebugSioPutchar(0x31);
Xaccel += pspDebugSioWaitGetchar();
pspDebugSioPutchar(0x32);
Yaccel += pspDebugSioWaitGetchar();
}
Xaccel = Xaccel/10;
Yaccel = Yaccel/10;
xvel -= ( (int)Xaccel-128 );
yvel += ( (int)Yaccel-128 );
x += (float)xvel/100;
y += (float)yvel/100;
if(pad.Buttons & PSP_CTRL_CROSS)
{
break;
}
if(pad.Buttons & PSP_CTRL_LEFT) x--;
if(pad.Buttons & PSP_CTRL_RIGHT) x++;
if(pad.Buttons & PSP_CTRL_UP) y--;
if(pad.Buttons & PSP_CTRL_DOWN) y++;
if(x<0) { x = 0; xvel = xvel*-.8; }
if(x>480-32) { x = 480-32; xvel = xvel*-.8; }
if(y<0) { y = 0; yvel = yvel*-.8; }
if(y>272-32) { y = 272-32; yvel = yvel*-.8; }
clearScreen(0);
blitAlphaImageToScreen(0 ,0 ,32 , 32, ball, (int)(x+.5), (int)(y+.5));
sceDisplayWaitVblankStart();
flipScreen();
}
//sceKernelSleepThread();
sceKernelExitGame();
return 0;
}
-
page has alot of in depth information. so as far as the touch screen goes are we going back to attiny84 and all?
Post Merge: January 23, 2011, 08:38:54 AM
so we just set it up to work with touch screen. ok
Post Merge: January 23, 2011, 08:41:07 AM
as for the schematic with the attiny84 I need help with the implementation of the UART I have never used one. :help:
-
DebugSio didn't seem to work for me on any FW other than 1.5
use tyranids sio lib from pspLink, it works for 3.xx (kernel prx though)
as for uart just use the hardware uart pins (usi is actually no uart but can be used as one)
maybe a voltage divider for avr tx
-
design prototype what do you guys think?
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi253.photobucket.com%2Falbums%2Fhh69%2Fmarianard_2008%2Fprototype1.jpg&hash=6d5fb0ec52e05c98b7c3619a4b5892725ef461f7)
and yes that is a second analog nub.
-
need a boost converter if u want to use psps 1.9V
probably use attiny84 low power then, 3.3V operation, if the touchscreen works with 3v3
didn't get a boost converter to work with psps sio though, cant draw too much current (at once? diode? no clue)
-
easier solution, external power through rechargable battery pack hidden inside our stuff. the touch screen needs 5v - 5v charges psp also. so from the design i just posted we can fit a lot in the bottom part. Then we can have more options for power. Not to mention extra battery life.
-
still needs boost converter if u want acceptable battery life
possible but doesn't seem like u guess would be experienced
-
With the amount of space inside the part on the bottom of the picture, we could include the programmer and a serial port also. just a thought. I like keeping things open sourced and freeware to the public. So people could improve upon they'r machines.
-
have u ever heard of bootloaders?
where would u integrate a rs232 jack?
-
How are you planning to use the touchscreen?
-
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi253.photobucket.com%2Falbums%2Fhh69%2Fmarianard_2008%2FAvr-pg2b.jpg&hash=6c8e219f9d122f6eca0595c323987d699154216c)
use this to connect to the avr board.
Post Merge: January 23, 2011, 12:03:26 PM
HiddenVenom - The idea is to have the touch screen programed to send out marco's and remaps for buttons . So with a simple user interface one could use a preset or set they're own macro's and maps. Ie full use, in game, xmb, or homebrew. on screen keyboard could really help to. this could also be used for a simpler addon 2nd analog.
-
I like the idea but what about the start and select buttons they are blocked. maybe for convenience purposes we could flip the screen around and take a cord from the back. lastly move the analog stick up a little the asymmetrical look is kinda unattractive.
-
Sorry I didnt explain the picture the ribbon cable goes under the buttons bar and comes out at the very bottom of the psp faceplate.
Post Merge: January 23, 2011, 12:27:07 PM
As far as the analog only a demo but think xbox.
Post Merge: January 23, 2011, 12:29:14 PM
external power could power the psp and our device. So increased battery life for the psp and we dont need to bump the psp's 1.9 v sio on the slim. keep 5v.
-
I think the attiny84 mlf may be a better choice. can the usi be used for both its communication with the psp and for its "UART"? just wire the reset to one of the extra pins and when the code is written tell it that if a certain bit value is sent, to reset? if UART connection can be set this way then it will simplify this alot. so with this concept design above are we taking voltage from the serial with a step up transformer or are we getting voltage from external battery?
Post Merge: January 23, 2011, 01:02:15 PM
if the at-tiny84 already has usi then doesn't it have some kind of on board serial communication code we could just modify. the mlf package will also give us extra pins maybe after testing the extra pins could be used to expand the serial port into like one or two more on the bottom of the touch screen addon.
-
The power would come from an external battery which we use the same plug we use to charge the psp. hence the power port on our device. with extra battery we could include the programmer also maybe. depending on space.
Post Merge: January 23, 2011, 10:23:05 AM
think future expansion. Wireless remote could be added , maybe video out for the slim version. mic for skype.
btw this could be done without replacing faceplate if one wanted . Just pop out the acrylic lcd cover on the faceplate one allready has, and make a small notch in the faceplate bellow the the start button to allow the ribbon cable to escape out the faceplate.
the trick for the install is making the bottom part. The skype phone plastic shell comes in 2 versions fat and slim. Use the skype plastics and install our hardware.
Anyone Got any details on analog nub through sio? found some code that might do it but I have not looked for any kind of schematic for wiring yet.
Post Merge: January 23, 2011, 10:44:28 AM
sample code from macro fire
this is from the analog file.
void *mfAnalogStickProc( MfMessage message )
{
switch( message ){
case MF_MS_INIT:
st_enable_movement = true;
st_analogstick.deadzone = 40;
st_analogstick.sensitivity = 1.0f;
st_analogstick.originX = PADUTIL_CENTER_X;
st_analogstick.originY = PADUTIL_CENTER_Y;
break;
case MF_MS_INI_LOAD:
return mfAnalogStickIniLoad;
case MF_MS_INI_CREATE:
return mfAnalogStickIniSave;
case MF_MS_HOOK:
return mfAnalogStickAdjust;
case MF_MS_MENU:
return mfAnalogStickMenu;
default:
break;
}
return NULL;
}
void mfAnalogStickIniLoad( IniUID ini, char *buf, size_t len )
{
const char *section = mfGetIniSection();
int deadzone, sensitivity, originx, originy;
st_enable_movement = true;
inimgrGetBool( ini, section, "AnalogStickMovement", &st_enable_movement );
if( inimgrGetInt( ini, section, "AnalogStickDeadzone", &deadzone ) ) st_analogstick.deadzone = deadzone;
if( inimgrGetInt( ini, section, "AnalogStickSensitivity", &sensitivity ) ) st_analogstick.sensitivity = (float)sensitivity / 100.0f;
if( inimgrGetInt( ini, section, "AnalogStickOriginX", &originx ) ) st_analogstick.originX = originx;
if( inimgrGetInt( ini, section, "AnalogStickOriginY", &originy ) ) st_analogstick.originY = originy;
}
void mfAnalogStickIniSave( IniUID ini, char *buf, size_t len )
{
inimgrSetBool( ini, MF_INI_SECTION_DEFAULT, "AnalogStickMovement", true );
inimgrSetInt( ini, MF_INI_SECTION_DEFAULT, "AnalogStickDeadzone", 40 );
inimgrSetInt( ini, MF_INI_SECTION_DEFAULT, "AnalogStickSensitivity", 100 );
inimgrSetInt( ini, MF_INI_SECTION_DEFAULT, "AnalogStickOriginX", PADUTIL_CENTER_X );
inimgrSetInt( ini, MF_INI_SECTION_DEFAULT, "AnalogStickOriginY", PADUTIL_CENTER_Y );
}
void mfAnalogStickAdjust( MfHookAction action, SceCtrlData *pad )
{
if( st_enable_movement ){
padutilAdjustAnalogStick( &st_analogstick, pad );
} else{
pad->Lx = PADUTIL_CENTER_X;
pad->Ly = PADUTIL_CENTER_Y;
}
}
void mfAnalogStickMenu( MfMenuMessage message )
{
static MfMenuTable *menu;
static HeapUID pheap;
static unsigned char sensitivity;
SceCtrlData *pad, pad_dupe;
pad = mfMenuGetCurrentPadData();
switch( message ){
case MF_MM_INIT:
dbgprint( "Creating analogstick menu" );
menu = mfMenuCreateTables(
1,
7, 1
);
pheap = mfMemoryTempHeapCreate( 3, sizeof( MfCtrlDefGetNumberPref ) * 3 );
if( ! menu || ! pheap ){
if( menu ) mfMenuDestroyTables( menu );
if( pheap ) mfMemoryHeapDestroy( pheap );
return;
}
{
MfCtrlDefGetNumberPref *pref_deadzone = mfMemoryHeapCalloc( pheap, sizeof( MfCtrlDefGetNumberPref ) );
MfCtrlDefGetNumberPref *pref_sensitivity = mfMemoryHeapCalloc( pheap, sizeof( MfCtrlDefGetNumberPref ) );
MfCtrlDefGetNumberPref *pref_origin = mfMemoryHeapCalloc( pheap, sizeof( MfCtrlDefGetNumberPref ) );
pref_deadzone->unit = "(0-182)";
pref_deadzone->max = 182;
pref_sensitivity->unit = "% (0-200)";
pref_sensitivity->max = 200;
pref_origin->unit = "(0-255)";
pref_origin->max = 255;
sensitivity = st_analogstick.sensitivity * 100;
mfMenuSetTablePosition( menu, 1, pbOffsetChar( 5 ), pbOffsetLine( 6 ) );
mfMenuSetTableEntry( menu, 1, 1, 1, MF_STR_ASA_MOVEMENT, mfCtrlDefBool, &st_enable_movement, NULL );
mfMenuSetTableEntry( menu, 1, 2, 1, "", NULL, NULL, NULL );
mfMenuSetTableEntry( menu, 1, 3, 1, MF_STR_ASA_DEADZONE, mfCtrlDefGetNumber, &(st_analogstick.deadzone), pref_deadzone );
mfMenuSetTableEntry( menu, 1, 4, 1, MF_STR_ASA_SENSITIVITY, mfCtrlDefGetNumber, &sensitivity, pref_sensitivity );
mfMenuSetTableEntry( menu, 1, 5, 1, "", NULL, NULL, NULL );
mfMenuSetTableEntry( menu, 1, 6, 1, MF_STR_ASA_ORIGIN_X, mfCtrlDefGetNumber, &(st_analogstick.originX), pref_origin );
mfMenuSetTableEntry( menu, 1, 7, 1, MF_STR_ASA_ORIGIN_Y, mfCtrlDefGetNumber, &(st_analogstick.originY), pref_origin );
}
mfMenuInitTable( menu );
break;
case MF_MM_TERM:
mfMenuDestroyTables( menu );
mfMemoryHeapDestroy( pheap );
return;
default:
st_analogstick.sensitivity = sensitivity / 100.0f;
pad_dupe = *pad;
mfAnalogStickAdjust( MF_INTERNAL, &pad_dupe );
pbPrint( pbOffsetChar( 3 ), pbOffsetLine( 4 ), MF_COLOR_TEXT_FG, MF_COLOR_TEXT_BG, MF_STR_ASA_DESC );
pbLineRectRel( pbOffsetChar( 60 ) - ( 128 >> 1 ) - 1, pbOffsetLine( 18 ) - ( 128 >> 1 ) - 1, ( 256 >> 1 ) + 2, ( 256 >> 1 ) + 2, MF_COLOR_TEXT_FG );
pbLineCircle( pbOffsetChar( 60 ) + ( ( st_analogstick.originX - PADUTIL_CENTER_X ) >> 1 ), pbOffsetLine( 18 ) + ( ( st_analogstick.originY - PADUTIL_CENTER_Y ) >> 1 ), st_analogstick.deadzone >> 1, MF_COLOR_TEXT_FC );
/* ’²®‘OÀ•W‚̈ʒu‚ðŽ¦‚· */
pbLine(
pbOffsetChar( 60 ) + ( ( pad->Lx - PADUTIL_CENTER_X ) >> 1 ),
pbOffsetLine( 18 ) - ( 127 >> 1 ) - 1,
pbOffsetChar( 60 ) + ( ( pad->Lx - PADUTIL_CENTER_X ) >> 1 ),
pbOffsetLine( 18 ) + ( 127 >> 1 ) + 1,
( MF_COLOR_TEXT_FC & 0x00ffffff ) | 0x66000000
);
pbLine(
pbOffsetChar( 60 ) - ( 127 >> 1 ) - 1,
pbOffsetLine( 18 ) + ( ( pad->Ly - PADUTIL_CENTER_Y ) >> 1 ),
pbOffsetChar( 60 ) + ( 127 >> 1 ) + 1,
pbOffsetLine( 18 ) + ( ( pad->Ly - PADUTIL_CENTER_Y ) >> 1 ),
( MF_COLOR_TEXT_FC & 0x00ffffff ) | 0x66000000
);
pbPoint( pbOffsetChar( 60 ) + ( ( pad->Lx - PADUTIL_CENTER_X ) >> 1 ), pbOffsetLine( 18 ) + ( ( pad->Ly - PADUTIL_CENTER_Y ) >> 1 ), MF_COLOR_TEXT_FC );
/* ’²®ŒãÀ•W‚̈ʒu‚ðŽ¦‚· */
pbLine(
pbOffsetChar( 60 ) + ( ( pad_dupe.Lx - PADUTIL_CENTER_X ) >> 1 ),
pbOffsetLine( 18 ) - ( 127 >> 1 ) - 1,
pbOffsetChar( 60 ) + ( ( pad_dupe.Lx - PADUTIL_CENTER_X ) >> 1 ),
pbOffsetLine( 18 ) + ( 127 >> 1 ) + 1,
( MF_COLOR_TEXT_FG & 0x00ffffff ) | 0x66000000
);
pbLine(
pbOffsetChar( 60 ) - ( 127 >> 1 ) - 1,
pbOffsetLine( 18 ) + ( ( pad_dupe.Ly - PADUTIL_CENTER_Y ) >> 1 ),
pbOffsetChar( 60 ) + ( 127 >> 1 ) + 1,
pbOffsetLine( 18 ) + ( ( pad_dupe.Ly - PADUTIL_CENTER_Y ) >> 1 ),
( MF_COLOR_TEXT_FG & 0x00ffffff ) | 0x66000000
);
pbPoint( pbOffsetChar( 60 ) + ( ( pad_dupe.Lx - PADUTIL_CENTER_X ) >> 1 ), pbOffsetLine( 18 ) + ( ( pad_dupe.Ly - PADUTIL_CENTER_Y ) >> 1 ), MF_COLOR_TEXT_FG );
pad_dupe.Buttons |= padutilGetAnalogStickDirection( pad_dupe.Lx, pad_dupe.Ly, 0 );
{
unsigned short test_cross_offset = pbMeasureString( MF_STR_ASA_TEST_DIR ) + pbOffsetChar( 1 );
pbPrint( pbOffsetChar( 3 ), pbOffsetLine( 24 ), MF_COLOR_TEXT_FG, MF_COLOR_TEXT_BG, MF_STR_ASA_TEST_DIR );
pbPrint( test_cross_offset + pbOffsetChar( 5 ), pbOffsetLine( 23 ), pad_dupe.Buttons & PADUTIL_CTRL_ANALOG_UP ? MF_COLOR_TEXT_FC : MF_COLOR_TEXT_FG, MF_COLOR_TEXT_BG, PB_SYM_PSP_UP );
pbPrint( test_cross_offset + pbOffsetChar( 7 ), pbOffsetLine( 24 ), pad_dupe.Buttons & PADUTIL_CTRL_ANALOG_RIGHT ? MF_COLOR_TEXT_FC : MF_COLOR_TEXT_FG, MF_COLOR_TEXT_BG, PB_SYM_PSP_RIGHT );
pbPrint( test_cross_offset + pbOffsetChar( 5 ), pbOffsetLine( 25 ), pad_dupe.Buttons & PADUTIL_CTRL_ANALOG_DOWN ? MF_COLOR_TEXT_FC : MF_COLOR_TEXT_FG, MF_COLOR_TEXT_BG, PB_SYM_PSP_DOWN );
pbPrint( test_cross_offset + pbOffsetChar( 3 ), pbOffsetLine( 24 ), pad_dupe.Buttons & PADUTIL_CTRL_ANALOG_LEFT ? MF_COLOR_TEXT_FC : MF_COLOR_TEXT_FG, MF_COLOR_TEXT_BG, PB_SYM_PSP_LEFT );
}
pbPrint( pbOffsetChar( 3 ), pbOffsetLine( 27 ), MF_COLOR_TEXT_FG, MF_COLOR_TEXT_BG, MF_STR_ASA_TEST_MOVE );
pbPrintf( pbOffsetChar( 5 ), pbOffsetLine( 28 ), MF_COLOR_TEXT_FC, MF_COLOR_TEXT_BG, "%s (X,Y) = ( %03d , %03d )", MF_STR_ASA_TEST_MOVE_RAW, pad->Lx, pad->Ly );
pbPrintf( pbOffsetChar( 5 ), pbOffsetLine( 29 ), MF_COLOR_TEXT_FG, MF_COLOR_TEXT_BG, "%s (X,Y) = ( %03d , %03d )", MF_STR_ASA_TEST_MOVE_ADJ, pad_dupe.Lx, pad_dupe.Ly );
if( ! mfMenuDrawTable( menu, MF_MENU_NO_OPTIONS ) ) mfMenuProc( NULL );
break;
}
}
const PadutilAnalogStick *mfAnalogStickGetContext( void )
{
return &st_analogstick;
}
-
use tokyodrifts ps2 controller on psp stuff has every thing you need and heres the schematic.(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi1226.photobucket.com%2Falbums%2Fee403%2Fgalaxy3arth%2Fattiny84MLFPSPtouchscreenschematic.jpg&hash=c0ca95c1085169798c06f54290ce6b7d79a2b3d7)
if its wrong let me know because I didnt know much about any of this before I started the thread. I cant do any coding I am telling you now I do not know more than slightly informed about assembler. I need somebody else to do this based on the schematic. the UART may be wrong (I have no idea how to use them or what they look like o anything I just know what it does). forgot the VCC and GND for the UART just imagine one ( I am pretty sure UART has these, common sense, but I again dont really know)
I kept the electrolytic capacitor it cant hurt anything
Post Merge: January 23, 2011, 02:08:31 PM
the squares are test pads, and there is another ground at the bottom of the attiny84MLF
Post Merge: January 23, 2011, 02:09:55 PM
if it cant be done this way as far as UART then I can just move the rx and tx for psp to some other pins.
-
could you please stop posting code all the time!?
it's not helping at all
okay, it works like this: PSP <-UART-> USI - AVR - ADC <-Touch Interface-> TouchScreen
so we need 6 IOs of the avr + GND + VCC + pullup on reset + cap on VCC/GND
apart from that you need a boost converter for the battery
you can also make the UART lines accessable from outside so that one could easily interface the bootloader on the avr for flashing
do NOT integrate a usb programmer, this is just useless, needs power and is an overkill
do NOT integrate hardware for a software usb, it wont work
this is basically a design with 2 ICs: the AVR in MLF and a boost converter in the smallest package we can find
do NOT use dip packages, only for prototyping maybe
I checked the MLF package, we can make it single sided (pretty sure, maybe some 0 Ohm resistors needed?)
do NOT copy'n'paste code, it won't work, get a coder
do NOT overload the AVR, PSP has enough power to calculate macros and stuff, AVR doesn't
USE a protocol, don't just stream data to the PSP
-
oh btw, don't forget the external clk source
the schematics are weird, use eagle or kicad or something pls
-
1: how would a touchscreen usually interface the psp so that there are touchscreen drivers available?
2: if there were touchscreen drivers, why would we even bother making this
3: have u ever seen anyone seriously using linux on their psp?
4: why do you think we'd want to use linux on our psp when we're obviously making this for GameOS?
and so on...
btw, the electrolytic capacitor hurts because it's a big ass component...
-
sorry man I dont have those so could I download it from the internet or not.
I dont plan on doing anything involving usb. ( the psp is not a host and never can be)
I get what you mean for the UART now thanks
DIPs are just too bulky and there is no need for them so I never considered using one.
Post Merge: January 23, 2011, 02:24:40 PM
I get what you mean I will get rid of the capacitors.
-
1. USB/MiniUSB
2. Learning project? I dunno.
3. https://help.ubuntu.com/community/PSP
4. Sorry, I had no idea you were using GameOS. However most non-windows operating systems are UNIX-like.
-
yo guys this is a thread for touchscreen psp development not a sympathy board. KEEP ON TOPIC. no offense to hidden venom or anyone else but keep this bull:censored: off the thread.
Post Merge: January 23, 2011, 02:32:25 PM
GEEZ arguements, what are we? three
-
I need the libraries for the attiny84 mlf for eagle.
cannot write schematic with out it
-
back on track. No usb agreed. serial port on the bottom to reflash agreed? an extra analog agreed? external power agreed? attiny85 or 84 mlf agreed , uart? I think some mapping has to be done inside the attiny , at least basic button control. let macros and presets be stored in a database or cfg file on memory stick or on psp? Im sorry for the code but it is a major part of this concept. It also helps in reverse engineering. If we understand how others handle the communication through the sio it can help in the development of the hardware. Do we really know what this port is limited to yet?
-
all agreed but its the attiny84 mlf
Post Merge: January 23, 2011, 03:16:19 PM
We need a coder.
and
I...
neeeed... the...eagle...attiny...84...MLF...libraries!
:help:
or... I... am... going... to write... the next/final schematic.... on paint.
don don don
-
The guy to write this is TyRaNiD. As far lib's ill see what i can find.
-
If i was your boss and all of you all worked for me I would have fired you guys by now; yeah sometimes theres a discrepancy here and there of opinions.... it's development!! Seeing is believing!! trial and error, post results ether its good or go back to the drawing board.
Please continue on topic. I was loving where this thread was going ;) you guys just have to sort who does what and then when you find good information collaborate on how stuff can be improved/disproved.
tl;dr I never want to see this kind of bad collaboration again, if you're gonna disagree start your own dev thread else please have gracious professionalism when someone is wrong.
-
If i can get my hands on the rest of the neo's code I think I can modify it for our purpose.
-
We will be more professional because yes I get exactly what your saying we really would have been fired I actually thought this thread was going to split a couple of times.
Post Merge: January 23, 2011, 03:51:39 PM
yeah I think I have some of it wasnt it all in the source?
Post Merge: January 23, 2011, 03:52:57 PM
I am going to make another schematic in paint we can just make it in eagle later give me a second.
-
The src used was a demo game not the neo code its self. lol im looking for neo, does that make me morpheus ?
Post Merge: January 23, 2011, 04:10:05 PM
So who can bring "what" to the table?
what are we missing?
What can we do to test what we have so far?
My account at ps2dev wont work can anyone try and contact TyRaNiD?
If we get him I think our problems with code are over. Not to mention he's got all of the dev tools to test and debug all of this.
Once we have a final schematic I will build at least 3 of these to get into the hands of our devs.
Anyone got any idea on root keys? ie digitally signing our software to work with ofw.
-
I am totally lost on the implementation of the UART I am lost :help:
somebody edit the schematic so far and add this please
Rx and Tx from psp through the UART to the attiny84 mlf
-
i cleaned this thread up a bit. stay on topic please, if you disagree with the way this thread is going let me know and i can split it at anytime. It would be nice if everyone could woork together but that is just not allways doable.
everyone is welcome here to post ideas, develop a mod, or just hang out. but please do so without flaming other members.
-
agreed
-
I am totally lost on the implementation of the UART I am lost :help:
somebody edit the schematic so far and add this please
Rx and Tx from psp through the UART to the attiny84 mlf
The UART is a way to load serial data back and forth because its smaller
I say get some sort of bootloader on a PIC that can process USB i/o to read/write to a small fpga which runs everything you want to run.
its easy to keep open source using a programmable gate array plus it can do a lot of processing in a small package.
uart design compacts all of your circuitry to a few data wires instead of running parallel lines like a matrix. uart is slower but nothing noticeable since performance is not an issue.
-
kinda big but I had not considered this.
could you give me an example?
-
usb/rs-232 it doesn't matter; almost the same thing.
the computer sends/receives data to the uart chip that translates complex commands into a native format within the devices.
the ATTINY84MLF communicates between the uart only when necessary. The computer will try to communicate constantly which the avr (ATTINY84) won't be able to handle all the processing needed to do all that.
now the Rx and Tx i dont know what those do... what are they?
-
can the attiny84 MLF be programed to use one of the pins for USI/UART?
I dont see why we cant just use direct Rx Tx to psp and use the ICP for reflashing. why is the UART needed?
is it just for saving space?
-
can the attiny84 MLF be programed to use one of the pins for USI/UART?
I dont see why we cant just use direct Rx Tx to psp and use the ICP for reflashing. why is the UART needed?
is it just for saving space?
its saving processing power.
-
the Rx is the received data
the Tx is the transmitted data
they are the main data lines in the SIOport of psp
only two pins on the SIO port really needed.
they use the rs232 protocol with adjusted voltages instead of (-5v,+5v) it is (0v,2.5v)
so basically the UART is better for program development and debugging on the AVR?
Would there be a noticable difference if we didnt use the UART?
-
Would there be a noticable difference if we didnt use the UART?
A huge loss of avr performance because think about this ~ the computer is communicating with the avr without the uart chip So.... you're trying to do 7823478 billion things at once with 1 chip.
you have to detect user input from the touch pad and you have to send that data to the PSP... that pretty much uses all of the chip's resources already but now the chip also would have to communicate with the computer all the time as its connected... so the entire system will run slow since the bitrate of the chip is divided up more.
again the uart only communicates when communication is needed, so when you have rs-232 connected to the uart your uart would send a command to the avr saying "hey buddy, free up some resources we're talking now". then the avr chip reduces clock to the touch screen i/o and then you can configure whatever you have to...
Rx Tx would be only two pins yeah.
-
Question... How would we implement both touch and second nub? As far as programing goes can it be as simple as sending a package to the avr from the psp telling the avr to enable the nub? I dont think we need both the nub and the touch at the same time. How can we switch between the 2?
-
so for debugging/reflashing the performance would go down significantly.
part of the problems with the UART I am having is what pin if any on the attiny84mlf do I use for the usi ?
which model of UART should I use (cant really tell)?
Post Merge: January 23, 2011, 05:53:18 PM
for switching between duel nub and touch screen we could just do so from the psp side of things. there would not be much more processing added on as far as the AVR goes.
the AVR would just keep sending the analog info but the psp will just ignore it.
-
From a programming perspective:
Just sit waiting for one of them to get input, and the disable the other while it is being used. That way there is no button-pressing. Means that whatever is controlling them both has to be on an (almost) constant loop though.
-
Its the avr side im questioning about the dual nub. how do we wire both in and make it so the avr takes in data from both and can tell which is which? Program side I see the logic with "ifs". hardware, how to connect both nub and touch ? trying to get a full schematic of final diagram so we can see what else might be needed hardware wise. I'd like to be sure about what will be needed as i have to order enough supplies to build at least 5 of these. 1 will be internal on phat. 1 will be internal on slim. 1 will go full retail version on #2phat and other 2 go to devs. I'd hate to get everything i need except for "x" and have to wait another month for shipping 5 of 1 part. On the topic of shipping. Anyone know of american based suppliers of the things we need?
-
mouser.com has everything sparkfun has the touchscreen
andthe only uncertainty is the UART,because I dont know what to do for it
Post Merge: January 23, 2011, 07:34:27 PM
need booster for battery
need UART (dont know which one)
need SIO plugs
need attiny84MLF
need 16mhz crystal for what ever UART we use
need touch screen connector(sparkfun) can be used to make assembly faster no tiny soudering except the AVR
do you know how to implement UART?
I really need help.
-
I have to question this. why the attiny? why not something more powerful with maybe more options? I can't give an example to improve upon this right now, but some one might know of a better chip. remember it doesnt have to be all that small. why not this http://www.sparkfun.com/products/316? (http://www.sparkfun.com/products/316?)
-
Oh guys I seriously don't get your problem.
We use an ATTiny84 in MLF because it's TINY (oh rly) and probably people want this mod INSIDE their PSPs
you don't need any special hardware for UART (maybe a voltage divider/resistor) because the ATTiny has this internal. look in the datasheet for the pins
the max232 is a level shifter, for connecting UART to a PCs RS232...it's not needed for PSPs
the ATTiny WILL NOT GENERATE ANY BUTTON PRESSES!
this is just not the way it's done
the only thing the ATTiny will do is listen for a "gimme the position of the touch" command and answer that
everything else is the PSP's problem
that way you don't have to update the AVR
however, we can add a bootloader to the AVR so you can reflash it using uart, we can just write an update app for the PSP then
second analog stick is approved if you get the board layout done
-
Tokyo , thank you for your input. I respect your knowledge on this topic as we are basing this mod on some of your work with the sio port. My reasoning for asking for a replacement of the attiny I was hoping there was a chip that can handle 2 spi's? I dont know if the attiny can do that. WE are all on a huge learning curve here. I was out of the scene for quite some time, So I've been trying to get updated info. Instead of putting out info on something i dont fully understand I ask questions. I'm also tryn to see if we can simplify our circuit with a better chip. Uart is deff. in. I didn't have a good grasp on uart but im getting there. On the same topic of uart, Isn't there a chip that also has uart already?
-
the attiny84 has an USI module inside that can be used as an UART
what would you need SPI for though? Oo
read AVR307 for USI as UART
it's kinda complicated but I guess it'll work
normal UART is easier but only available on bigger AVRs
EDIT: i guess we can also take attiny4313, that one has UART and everything and is also available in MLF20
EDIT: 4313 seems to be unavailable, use 2313
-
So with the attiny2313 we can connect to analog sources(touch and nub)? edit: pd is for psp, pb is for analog sources(both connect on pb)? pa is for bootloading? Am i reading this right?"like the mlf of the attiny" good find.
-
NO the attiny4313 and 2313 do not hace adc in puts we need adc inputs
the attiny84 mlf is just fine we will just use the USI and voltage splitter.
thanks tokyo I get what your talking about now do not switch the AVR.
i will have the schematics posted by the end of the day with 2nd analog already implemented.
external UART can be used would free up some processing power.
Post Merge: January 24, 2011, 07:46:44 AM
I checked all the other AVR options already the only other viable choices were the atmega series ,but they are to big.
Post Merge: January 24, 2011, 07:48:10 AM
why would we need 2 SPIs the UART can be used for programing and is better for debugging.
-
Ok Ill take your word for it. I was just wondering if we were making it more complicated than it needed to be? could it be simplified by a better chip? I dont know, why i asked.
-
sorry didn't have a look at the ADC pins
there should be enough pins on ATmega84 anyways
let's not use an external uart chip, usi has to work :)
PIN MAP:
XTAL1 => OSZILLATOR
RESET => PULLUP / TESTPAD
DI => PSP TX
DO => PSP RX
ADC0 => TOUCHSCREEN1
ADC1 => TOUCHSCREEN2
ADC2 => ANALOG1
ADC3 => ANALOG2
GPIO1 => TOUCHSCREEN3
GPIO2 => TOUCHSCREEN4
MOSI,MISO,SCK,GND,VCC => TESTPAD
GND => GND
VCC => VCC
That should be everything needed on the AVR. You also have to use a Boost Converter for voltage supply (provides GND+VCC) and maybe a voltage divider/resistor for the DO (to 2V maybe?)
-
if we are willing to make it a little bigger it can be. like on the atmega168/324 i beleive it has on board true UART and it has extra pins more ADC compatible, but it is pretty big( unatractive)
even if it has extra pins.
I think the current design is better as far as esthetics and it should function just fine.
the design is actually simpler than it sounds.
just one attiny84mlf with power source and ground
then the touch screen ribbon cable connector soudered to four ADC pins on the attiny84mlf
test pads for ICP connection (not really needed)
then a voltage splitter from the Tx and Rx of the psp to a USI compatible pin.
for second analog send the x and y values to two ADC ports left over ,and give it a power source and ground.
the booster is just for battery.
Post Merge: January 24, 2011, 08:36:17 AM
tokyo is this for the attiny84mlf or are we switching to the atmega84?
Post Merge: January 24, 2011, 08:37:23 AM
as for occilator I think 16mhz would be good. any input?
-
dumb question maybe but doesnt nub need four pins?
-
i agree with what your saying I think the USI is more complicated but more apealing than an external UART
Post Merge: January 24, 2011, 08:41:49 AM
not dumb question you just forgot that two of them are the VCC and GND the other two are the X and Y.
-
I THINK nub only needs 2 as the other 2 are connected to VCC
not sure though
touch doesn't need 4 ADCs, only 2 ADCs and 2 GPIOs
only one voltage divider is needed (AVR->PSP)
testpads are def. needed because you have to flash the bootloader to the avr
I think we should do this with dip parts on a breadboard first anyways to test everything, then we can decide about parts like the oscillator (the slower the less power it needs)
-
tokyo-"testpads are def. needed because you have to flash the bootloader to the avr
I think we should do this with dip parts on a breadboard first anyways to test everything, then we can decide about parts like the oscillator (the slower the less power it needs)"
-agreed.
thanks for the nub stuff. silly.
hey for slim version can we include an a/v pass through with a psp sio port on the bottom of psptouch? A/V stuff is separate from RXD ,TDX , lines correct?
-
yes, sio doesn't influence A/V, we can just pass it through as I did in my PS2 controller thing
-
Idea on internal mod. Take dual nub install(old way) but instead of soldering to pspmb everything is connected to sio internal (still cant find sio complete boards) , we wouldnt razorx. as long as the slim nub can be made to fit. but if its slim we have usb charge. no need for 5v in. and i believe we can turn on/hold the psp through the sio. so no need for power switch either. maybe include our own power switch? really we could remap o[]x^ to graffical touch buttons if needed so we could take out the whole right side of the psp? just a thought.
-
sounds like some massive wiring...
btw, someone should know how to fix my freeze when putting the psp to suspend...
-
Well normal dual nub mod requires 4 wires from nub tho psp mb. If one was going to internalize the psptouch, the nub is already connected to our board. just install where original dual nub was installed. For people who need symmetry. but put the rest of the guts of the psptouch into the area behind memory stick. And our battery should be small enough to go into the umd drive area. This project could really simplify 3 mods in one.
-
I have a small problem with designing schematic. I have 2 pin outs for the attiny84mlf one is from the atmel data sheet ,but it has pins it lists as do not connect. the other is from avrfreaks this is the one I have used so far which do I use.
-
if we add the pss through like planned couldnt we us txd and rxd on the pass through port also? maybe use that port to flash?
-
yeah Ill add the pass through
if there is any space left if not just add another branch to both the tx and rx
the way the rs232 protocol works the signals should not interfere with each other as long as they are not sending the same bit assignments.
we should check into this.
Post Merge: January 24, 2011, 10:03:55 AM
yeah we can do that
-
Back to code.... so now the avr needs to receive signals from both touch and analog. Code if touch than ignore nub? then sends code through uart , uart sends code to psp. or does uart decide which?
-
you can't pass through the uart lines
it doesn't work
AVR should always do both, PSP decides what data to request
-
code would need loop both control types then correct?
not say pass through uart sorry, not sure on how to word what im thinking. pass the a/v through normal wires to our external psp sio port. directly from the the psp to the sio port. the use the remaining pins to run leads to flash our chip. no extra port needed?
We dont really need touch when displaying video out, and we dont need video out to program, so the a/v stuff could all be separate.
-
we're gonna have a usi bootloader on the AVR (someone should write that?)
then the PSP can flash the avr
you can pass through the signals for video out, not the sio signals though
-
not trying to say pass through sio signals. tryn to say use remaining pins for video out sio on psptouch to program our avr. the video out doesnt need comm pins so we can use those pins to program.
like the idea of psp flashing avr. I dont know how to write that. (yet)
basically your idea with the extension cable. splice cable so it splits video and data. the psp'sio data goes to the psptouch hardware. the psp's sio's video goes straight through unchanged. the psptouch's sio port will then have open pins. use remaing pins to send reflash data to the psptouch's avr.
Post Merge: January 24, 2011, 11:37:22 AM
how hard would it be to keep full functionality on the psptouch's sio port? say like using a remote /charging/video dock. remote is handled through sio data , so idk?
-
hard enough to make me have no idea about where to start
we'd have to get information about big parts of the PSP firmware I think, I doubt it's possible
reflashing from the PSP should be quite simple
PSP can send a cmd to the avr to make it jump to bootloader mode, then just upload the hex file, reset the avr, done
we need to write a usi uart bootloader for the avr though, doubt there is one already
-
I think we can worry about that for updates after beta is released. we're building breadboard first anyways so for dev purposes flash from programmer for now. Homebrew could be made to reflash the avr later.
As far as bootloader from psp. pretty sure this page holds the key to everything. -Tyranid- http://www.docstoc.com/docs/28752025/psp. (http://www.docstoc.com/docs/28752025/psp.)
everyone involved shoud read this . I might print it up so i can study it over and over. From my understanding we can make it so the psp does most of the work. Pspsdk is all I got to say.
-
there are only four/five pins left on the AVR
for the reset to load into boot loader mode we can just take the reset pin and connect it to an IO pin so that the AVR program can give voltage to the reset to get into boot-loader mode after a signal for that pin is received could you guys do this.
that leaves us with three pins left.
Post Merge: January 24, 2011, 12:35:58 PM
any thing you want me to do with the remaining pins?
-
can we please include a mic? pretty sure that's just something to do with a/v stuff. I got like 5 or 6 different cell phone mics just layin' around.
-
yeah any thing else that wont even need the avr there are already mic pins on SIO for av
-
for the reset to load into boot loader mode we can just take the reset pin and connect it to an IO pin so that the AVR program can give voltage to the reset to get into boot-loader mode after a signal for that pin is received could you guys do this.
why would we do that? we can just trigger the watchdog to perform a software reset
-
Thinking about how inclusive this mod has become and ,since we still have open pins on our avr. led controller maybe? can chotto be adapted? Just thinking about the other more popular mods out there.
if we're done with adding hardware I'd like to get started on code. I'll start with analog nub script and see how far i get. someone want to start brain storming input examples for touch.
-
Here is the schematic (nobody gave me the eagle libraries for the attiny84mlf so its in paint)
just needs booster for battery thats it
all done :hifive:
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi1226.photobucket.com%2Falbums%2Fee403%2Fgalaxy3arth%2Funtitled.jpg&hash=02af048e43fc45ebea8830c872bf5c5db6eb16c5)
chose the 16mhz crystal the top speed for the AVR is 20mhz ,but no need to go there.
Post Merge: January 24, 2011, 06:23:18 PM
next order of operation
1. bootloaders for USI
2. AVR code in assembler ( i cant do this)
3. plugin/ psp side of things
4. extras
Post Merge: January 24, 2011, 06:26:30 PM
any volunteers?
Post Merge: January 24, 2011, 06:34:29 PM
just thought about this but modding with a purpose is engineering. its more respectable to the public.
-
:hifive: nice job, very clean. Me and my coders will get right to work. I already know how to write the analog nub. reading the touch just takes a lil modification to the original code from sparkfun. On the psp side of things this is where stuff gets funny. the addresses are all in hex. Are we installing this onto the kernal or are we going to create a new device io? I think we should add a new device io , then we dont need to mess with the psp's flash. everything can go on m.s. these questions make a big difference in code.
"just thought about this but modding with a purpose is engineering. its more respectable to the public." -agreed. Also this more like accessory dev than a mod. I cant wait till the cfw guys get a hold of this.
-
if you don't know what you're doing, forget about making the AVR code
you can't just copy n paste some scripts, everything has to be made for working together, otherwise you won't fit the size and speed requirements
@schematics: still no voltage boost, we need testpads for RESET, GND and VCC, the testpads don't necessarily have to be close to each other if that makes routing easier, PSP SIO doesn't share VCC with AVR, only GND is used (+ TX + RX)
I'd use an oscillator instead of a crystal bc smd oscillators are smaller I think
we'll see about the freq when the avr code is done
idk how the analog interface works, information on that, anyone?
on the PSP side you should make a kernel plugin that provides an interface for the touchscreen
no device or anything, just the plugin with the exports
and i guess it has to do some hooking for using the second analog stick
-
The code for the touch w avr is in script form before it gets put on the avr. I wasnt saying copy paste, I'm saying the code is very similar, we have to change addresses, but the basics of the code are the same.
example. the code sampled from sparkfun tells us that 2 of the pins on the avr need to be floating back and forth between gd and 5v. this is so we can read the x and the y positions of the touch.
But Im not an avr guy, but I do understand some code. The psp side Is where i shine. The easiest and best way to install plugins is to add another device io . The psp can be told then that when this device is being used, use "x" plugin at "y" address. We can install this anywhere w cfw. but with ofw it has to be a new device io.
forget device io we'll just write it for cfw. make a plugin for the kernal. If anyone has questions about coding on the psp side see the tyranids' link posted on page 4 of this thread .
Just a thought we can simplify and come up with a proof on concept without creating a plugin. uart can communicate hex correct? why not map out certain positions on the screen for touch versions of buttons on the avr side. then just send the appropriate hex for button being pressed. This is how the remote works. But like I said b4 about the device io, the remote has its own device io. when communication happens over the sio, each device has an id. so the psp knows what device its talking with.
I know this isnt a solution to in game play but it is a proof of concept.
The analog doesnt need to read like a regular analog stick. since they are being mapped to buttons . the analog signal is converted to a hex code that how much you push in a direction on analog the signal is sent as a button press for x"" amount of time. "x" being the amount of x or y movement. hold nub in one direction and hold that appropriate button down. the code to the psp is just hex.
-
i have no clue what you mean by saying new device IO? so you can use it by calling sceIoFileOpen("touch0:/"); ? Why would you do that? You can just make a library that exports functions, just like sceCtrl with it's sceCtrlReadButtons function.
I'd make the avr code in asm since it's a tiny
using the remote protocol is way more complicated than just building our own plugin
-
lets go back and look at how the neo did it. it used uart and works with cfw. , not sure but is the 3axis accelerometer analog? All the code for this device is freeware and we can use that to see how they addressed the communication to the psp.
the neo uses sceCtrl. Tokyo you where right.
neo source code found here http://www.neoflash.com/forum/index.php/topic,4762.0.html (http://www.neoflash.com/forum/index.php/topic,4762.0.html) scroll down to download . It shows exactly how its done.
I'm wondering what new cfw could be like w this in it.
Can someone help by going over to ps2dev.com. Tokyo I believe you have an account there? The guys to help with the code are there.
Find tyranid send him a message. I can't log in and I can't create a new account. IDK why.
-
lol
I won't send tyranid a message
srsly, that guy is a pro, he's got better things to do
pls don't bother him with this
if you want help with all this, I can help you, but I'm quite busy at the moment, I can help you in some weeks maybe, have to finish a project for school first though (hardware to drive a psp display :), in a CPLD)
-
I will add the occilator and the testpads they are a easy fix
Post Merge: January 25, 2011, 08:02:28 AM
oh yeah and the booster
Post Merge: January 25, 2011, 08:06:14 AM
yeah sounds good tokyo we. if you could make a good code for the AVR that would be awsome.
since the AVR is basically the base of this project if it doesnt work right nothing else will.
-
As far as contacting Tyranid , It wouldn't hurt to ask. Especially if you can't be bothered to help us. You have gotten very far with the dev w your projects. And I know you know what your doing, But this guy is a god.
So let me get this straight you won't help with the code until your project is done and you won't ask for help.
This better not be an ego thing.
I don't mind waiting, if you are going to help. I'm just making sure your intentions are good.
-
agreed this has to happen. :drunk:
but to keep the thread together we cant assume its about ego
-
Im not assuming anything. I am not laying judgment either. WE need to create a plugin that handles vsh,game,pops and i know tyranid knows how to create it. So why wouldn't we ask him how?
Not to mention someone who's that into dev on psp like he is would want to see the psptouch in action. I think he would be very pleased with the challenge .
-
go ahead and ask then.
Post Merge: January 25, 2011, 08:51:28 AM
I do think we can just wait for tokyo to finish his project. I am still in school I just dont have any thing big to work on right now.
Post Merge: January 25, 2011, 09:00:31 AM
what model battery are we planning to use cause I kind like the first concept of the touch screen setup that plugs in the bottom just might want to make it thinner. have to choose a battery that is the shape we want, voltage and lasts as long as possible.
I dont think we need a design meant for internals the pcb is small enough and the places for soudering are big enough to just souder another serial port on the inside of the psp.
the only thing I thinkwould be cool would be to have a version that was not set up to run with battery maybe with a test pads so it could be hooked up with the five volts from the psp internals.
Post Merge: January 25, 2011, 09:03:56 AM
for the AVR coding I think we should just let tokyo do it this is kinda his thing. assembler is the best way to code the AVR.
Post Merge: January 25, 2011, 09:09:10 AM
I think what we are doing is pro level.
-
for the battery "k.i.s.s." ,2x"A.A.".
2x"A.A." socket here
http://www.sparkfun.com/products/8249 (http://www.sparkfun.com/products/8249)
edit:sorry this wont work>
might try to find long version to make it slimmer.
doing it this way keeps cost down and user can replace batteries easily.
Woking on updating previous design to show layout of internals.
update check this out
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi253.photobucket.com%2Falbums%2Fhh69%2Fmarianard_2008%2Fprototype2.jpg&hash=38d3e66b6df305ed4c0d88ca33d2f4d976c4b368)
-
ha
this is not about me being on an ego trip, not at all
tyranid just doesn't care about that kind of thing, at least I highly doubt he does
he's a hacker, he's probably into PS3 right now
he's a god, true, why would he care about this?
if you want to ask him, go for it, but don't expect an answer...
yes, I won't make any code until I'm done with my own project because it's just more important, sorry, but I need good marks rather than a touchscreen on my psp
WE need to create a plugin that handles vsh,game,pops
what do you want? hooking scectrl or your own interface?
-
Just so you know Tokyo I wasn't busting your ballz, I just wanted to make sure of your motives.I will take your word for it. You got stuff to do,ok, I just don't want to wait and end up with nothing. If you can help on the avr side of things great. If you can help on the psp side even better. In the mean time , I'm working on learning lua. I would like our own interface, but thats asking a lot. hooking scectrl Sounds like it might help w proof of concept.
-
actually the own interface is easier, problem is, only homebrews made to work with the touchscreen will be able to use it
-
Than hooking it is. We're going to need to be able to use everything in vsh,game,pops. Please have a look at the neo stuff. The neo stuff as all the features we need.
-
yeah hes right for commercial games generic controlls can be set to the touch screen if we use a plugin , but lets say for instance you were on the ingame menu of a commercial game it would be very difficult to have it so you could lets say tap what on the menu you wanted it would be very difficult.
but if you want to attemp this read the essay I wrote at the begining of this thread those are the concepts you would have to apply.
I know it would work if you could do it ,but it would be very game specific like the psp3d plugin. I think haveing generic control schemes for games and a way to remap them while in game would be awsome.
Post Merge: January 25, 2011, 12:26:04 PM
not quite all ,because we would have to add more complex control schemes to that you know touch zones and all. because I dont want to touch the screen on the right and have the game go to the right. I want to slide my finger to the right and have the game go left.
I think we should come up with a list of control functions we want it to have.
nothing over the top but thing like:
have a variable circle pattern mappable
double tap
variable speed and location drag for up down left right directions
sectional zones with all of these incorporated.(so that if I drag down on upper right corner it will be different than a drag on the lower right corner.)
the sectional control is not a need but stuff like that could be added as a bonus.
the variable speed and location drag and the double tap are a need for me.
list any other control schemes you would want here.
and actually would it be possible to have a app for psp where you can create generalized mappable macros of the analog values you draw? you know like it records what you draw and you choose whether it has location and speed constaints and all?
Post Merge: January 25, 2011, 12:27:58 PM
this would be after hooking. a plugin
-
Thats what the neo stuff does.it sets up basic parameters and allows for user presets and control of sensitivity . But remaps are done in "if" statements. I think Im up to the task of starting the code . second nub can be directly mapped to the o^[]x no problem. In game menu i have no idea. Creating custom remaps related to individual game code possible. I think the plugin for vsh should be as simple as possible. But irshell could make it so you just tap on the shortcut you want on the screen. As irshell shortcuts have predetermined positions on the screen. Why not write this and design it to work w irshell?
-
the design you have... I think we should still flip the screen so the ribbon cable goes around the back side of the psp ,because even if internalized it would still get in the home rows way. cant we just flip the screen backwards and write the code to work that way.
Post Merge: January 25, 2011, 12:35:02 PM
IR shell and vsh :yess:
in game menus and other highly specific stuff :dntknw: probably :sadno:
customizable general game controls :yess:
-
the orientation doesnt matter just write the code that way.
but if you look here. (https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi253.photobucket.com%2Falbums%2Fhh69%2Fmarianard_2008%2Fribbonhole.jpg&hash=11e8e79d8b9b70ce81f2ef465e394c2a823109ac)
the red box is where the ribbon cable would come out of the psp. we would slide the ribbon cable under the homebar. this is not exact but just to give you an idea.
-
the easiest way from my point of view would be to write instead of if. write the remaps and presets in piece wise mathematical equations. you know like the circle use the formula for a circle on a graph x2+y2=c then give it a variable c and a width now any size circle will work and it doesnt have to be perfect. though it does have to be somewhat around the center. for a cirle that could be drawn anywhere it would probably use the circle with a non 0,0 origin formula ( (x+b)2+(y+a)2=c) you know what I mean use math
Post Merge: January 25, 2011, 12:48:51 PM
oh OK I see what you mean. :hifive:
as for the code its your choice whether to use math or IF cause I dont know how to code for either.
Post Merge: January 25, 2011, 12:50:07 PM
the statement above probably sounds retarded :x:
-
the only difference with irshell we write a separate cfg for the shell. It would use the same plugins just not the vsh stuff.
the reasoning behind the if statements is we can be playing game normally and switch between control types using "if" logic.
-
OK that makes since.then the math based logic and the If logic can be used together. its the only way I know how to say this. I just cant think of a easier way to use complex motion with little code. math could probably be used for the variable speed ,and by variable speed I mean variable sensitivity or if I drag faster it acts as though for that moment the sensitivity is higher ,and if I drag slow it treats it like the sensitivity is lower.
just want to avoid misunderstandings.
-
Did some thinking on vsh stuff. Check out custom theme horizony2. cxmb is needed. anyways i was thinking about how to select something in vsh. started plaing in my custom themes to find something that looked simple to control found horizony. A slide motion left or right navigates left or right in menu same applies to up and down. sel is funny but i get it. as you move left and right what you want to select will always have the same position depending on where you are in the menu. example go to where your games are and as you move up and down the highlighted game is always at the same position on the screen. So predetermined x,y positions exist if we touch on that position simulate x press. check out the vid to see what im saying.
marianard_2008 - DSCF5051.mp4 (http://s253.photobucket.com/albums/hh69/marianard_2008/?action=view¤t=DSCF5051.mp4)
When i have an extra set of hands,either when my wife gets home or someone stops in , Ill do a touch demo in xmb.
marianard_2008 - DSCF5052.mp4 (http://s253.photobucket.com/albums/hh69/marianard_2008/?action=view¤t=DSCF5052.mp4)
thanks to my wife Erin for being my camera person.
-
seeing this did make me realize that atleast in xmb we will hve to make drag down = up
and drag up = down.
kinda sucks I finished my part of this already I cant really do much more except give input and information on stuff. the rest of this is for the most part up to you guys.
I think I will make an awsome concept sketch of it though XD
Post Merge: January 25, 2011, 02:26:01 PM
hey I know this is off topic and will sound retarded but are the colors on the names like level ups or something there seems to be a pattern in its change. wow this sounds dumb :confused:
Post Merge: January 25, 2011, 02:32:11 PM
is the booster for the battery really needed it sounds like its only for larger circuits? or is it to be a just in case?
http://www.electrokits.com/Datasheets/7805-Datasheet (http://www.electrokits.com/Datasheets/7805-Datasheet)
this is the link to the booster we will use so in this last schematic when you see 7805 it means the booster
the rest is the same though unlabled.
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi1226.photobucket.com%2Falbums%2Fee403%2Fgalaxy3arth%2Funtitled-1.jpg&hash=35bf6919a2dcc7f426ec657bbae7bf64d35891d8)
this is about actual size "above"
this is zoomed in "below"
(https://acidmods.com/forum/proxy.php?request=http%3A%2F%2Fi1226.photobucket.com%2Falbums%2Fee403%2Fgalaxy3arth%2Fboard.jpg&hash=834ea9ca3942997762d975404879281f252b70ee)
Post Merge: January 25, 2011, 05:15:05 PM
I know the test pads definitely have to be bigger
Post Merge: January 25, 2011, 05:19:46 PM
now that I see it in actual size how are you gonna souder this? I mean its a great size , the only thing that will get bigger is the oscillator and the test pads. this is :censored: tiny
Post Merge: January 25, 2011, 05:22:58 PM
Noooooo problems in size. maybe we send a PCB company our designs and parts then let them make it. cant cost that much.
-
lol i design you guys a PCB. Just show me schematics and datasheets and I'll go from that.
There are two types of PCBs:
*flex circuits PCBs
typical PCBs
I can design for ether (through hole) / (surface mount); I'll draw the PCBs and send you a 1:1 scale jpeg or i can post the AutoCAD file that can be sent to a PCB manufacture.
-
thanks a lot. will do
I will send you those at about noon tomorrow
-
I'd like a sample in cadd. Thanks for your input Fookz.
Great work so far. I wouldnt worry about getting boards printed yet , we still need to run everything on breadboard and get the coding done. Once we have the breadboard version working, then we can worry about the pcb board.
-
7805 is not a boost converter but a linear voltage regukator
this is totally the wrong part
boost converter is def. needed if we want to run everything from a
-
Hey Tokyo If we use a battery pack with a step up built in, dc to 5v dc,
do we still need a booster? Also on same note. will it run on 1xAA? we barely have the room for 2xAA.
Will this work?
http://www.sparkfun.com/products/8248 (http://www.sparkfun.com/products/8248)
also if its internalized, do we need a booster?
what about a charging circuit? I would like to use psp charging cable to charge and/or power psptouch, and pass the charge onto the psp. this way no dead batteries while flashing. maybe somehow make it so it wont flash unless power supply is plugged in. this way people can't mess up the flash if they'r battery goes dead during the flash.
what about these 2 products?
http://www.sparkfun.com/products/341 (http://www.sparkfun.com/products/341)
combined with
http://www.sparkfun.com/products/726 (http://www.sparkfun.com/products/726)
Post Merge: January 26, 2011, 06:07:20 AM
As far as programing the prx for vsh. Vsh need to be able to have user setting also, having them linked to theme somehow. because some custom themes change the position of of the icons. Unless it is written to work with a certain cxmb or xmb. plain xmb can be written quite easily.
a custom theme designed to be touch screen perhaps.
Also thinking about in game controls. back to right/left side touch functions. Can we display an image over the game? I think we can. If so , then lets put simulated buttons on the screen for left side controls. a simple control pad and/or analog nub. Maybe if you touch that area in the screen during game play it brings up the fake buttons/nub. Idea being having full control in game and not need real buttons. They could still be used.
One more thing, I know we can hold/sleep/wakeup the psp through sio, it would be nice to have a combo in touch that wakes up or puts the psp to sleep.
Lastly , anyone know of an American pcb maker.?
Can we get a location check in for everyone who is involved? Nothing to specific, like Country of origin or if in the states, what state? I ask for shipping and assembly purposes . Example , I have a team of assemblers ready to start work on this. But if the pcb's are all sent to germany then they have to be sent over here to the states. Centralize the dev. I dont mind coming up with funds for pbc making but I would want them shipped to me. My team could then assemble them, I would flash them and test them. And then ship them to who needs them.
We're going to have to start thinking about this from a business point of view. This will make money. With money comes problems. I believe everyone involved deserves an equal share. I didnt start doing this to make money, I wanted to improve on the psp but if it does make money the people involved should be compensated.
I hope this doesn't sound like sell out. Im just looking to where this is heading.
Post Merge: January 26, 2011, 06:34:35 AM
New idea: complete mod. strip the psp down to basic funtions. mb, power, sio , wifi, and of course the touch. no buttons. take that slimmed down psp put it in a small case.
-
I'm from germany
this won't make money, just saying...
we don't need a booster if it's internal bc the psp provides 5V or something I think
maybe we should try using the psps 1.9V, this has to work somehow
we'd still need a boost converter but it'd make it more perfect
flash thing is not a problem, bootloader stays in the flash whenever you use it to programm the chip, if flashing failed you can just try again
-
yeah I agree I like buttons just think the extra functionality is nice. lets keep buttons.
those parts will work for booster and all I didnt add booster,because I assumed that we would use a 5v battery but its fine.
Post Merge: January 26, 2011, 09:10:02 AM
yeah I think rather than an external battery if we use the VCC and GND from the SIO port it would be awsome. It would help us keep almost a no profile add on. the extra part shouldnt really use that much power. it wont really affect battery life.
either way we need a booster.
Post Merge: January 26, 2011, 09:43:22 AM
the booster would stay the same the one from sparkfun will work it changes a single double a to 5v
double As give out around 1.5v ,and the psp SIO gives out 1.5v. great.
any power source higher than 5v will work too ,because the 7805 will limit it to 5v.
thus the power source is any thing between 1.5v and some where around 9v.
Post Merge: January 26, 2011, 09:53:01 AM
we may also want to add another 7805 to limit the amps supplied.
Post Merge: January 26, 2011, 09:58:36 AM
for a model with an external battery the battery and charger listed will work too. thank alot denali.
Post Merge: January 26, 2011, 10:01:53 AM
if thers going to be on screen buttons please make them optional I dont want those.
:sadno:
Post Merge: January 26, 2011, 10:06:49 AM
Denali you are right
when I started the thread I just wanted touchscreen on psp ,but its developed into a sellable product. I think we need to check legal standing but thats it. the share should be equal because we split it into clear cut groups with different purposes code hardware production testing and all
I say equal shares. :yess:
-
Who wouldn't want touch on they're psp and if your more of a traditional gamer we give you a second nub. Keep in mind I designed this do be for the masses, your average joes. People who might be a lil nervous about soldering inside their psp. And if your a modder this gives you so much to work with. Why wouldn't you want it. granted Im not going to drop $100 for it. BUt if we can keep the price down this could take off.
The idea about the no button psp was just an idea for a mod.
I love the idea about the power from the psp. Fats do supply more power than slims. I was only saying external battery to make it easier. And Ive seen the way extrenal batteries for the psp works and thought why not power our device like that. then we get more power to your psp. External battery can be used as a power source to power the psp through 5v charge port. If we can use the io for power cool , Im not worried about it.
Had a broken fat psp remote given to me today.
note fat psp face is all one piece. modification required to faceplate to install touch.
I think its also time to think about 2 dev groups, 1 fat and 1 slim.
slim features might include external battery (lower sio v out), and video pass through.
Maybe on fats use psp to power . extra space ideas? The space between the sio and power is wider on fats. sound led bar mod? I would love to include a camera somehow but that connects through usb.
update fixed fat psp remote. hold switch was off track. works fine. only works when at mp3 playing menu, have not tried movies. Irshell lets me control my music from menu.
-
forget the money
you won't earn anything, this is gonna cost about 200$ (estimated) but you won't earn a single dollar. not one.
make sure you know that before starting the project
don't use a 7805 btw, that's not usefull, boost converter to 5V is enough.
-
I dont care about the money, I just want to see it come into action.
But i think your cost estimate is way high.
-
lol
that's what you think
alone some PCB prototypes without components (not even talking about having them soldered profesionally) is about 60$ (and that's probably not even enough)
you have to order some components that are not available everwhere, shipping for the FFC and the avr is probably 20$ (without components)
calculate about 20$ for components (incl. more shipping)
another 20 for the touchscreen incl shipping
you have to buy the faceplate, the skype thing (as a case), the analog stick, it all costs money
you have to get an avr programmer, that's another 25$ (at least, without shipping)
apart from that I highly doubt you can order everything at once, you have to order components for breadboarding, more (other) components for the prototype
and the best thing is, if there's just a tiny mistake in the PCB (layout), it'll cost another 60$ ;)
-
acidmods is not really here to make products. generally what is developed as opensource. you guys are welcome to try whatever you like though. but the only way to legally sell this is to sell it /the idea to sony...good luck. or to legally do it and paten it you would have to build the psp from the ground up. good luck with that also.
i suggest from one modder to the next, forget the money, enjoy building somthing for yourself. then deal with sony or whatever u choose. dont let hopes money cloud your ambition to create something great.
-
it does seem kinda high cause the parts are relatively cheap. i think as long as we make on a by order basis we can sell it for like $45. ordering parts how ever is a different matter if we order what we can from mouser.com it is much cheaper to buy in bulk. effectively raising profit margins. this would sell in US i think the best plan though would be to give it to the AM forum to help our benifactors
Post Merge: January 26, 2011, 12:19:34 PM
my bad double after post their price is probably accurate so nevermind
-
YOU CAN NOT SELL THIS
live with it
you can't sell it
200$ is the overall cost for the parts until you have a working prototype...if we make mistakes it's a lot more.
-
Yeah lets get back to dev.
-
so are we all good If we just use the parts denali listed I am not worried about the price not of concern just do it right the first time. lets get this done hey tokyo when do you think you will be done with your school project? I want to get a general time line of how long it will be.
And I want to know who is making the actual psp side of things ,because this is highly important?
this mod has to be done
:drunk: :drunk: :drunk: :drunk:
Post Merge: January 26, 2011, 01:17:26 PM
btw doesn't the slim give 1.5v too?
Post Merge: January 26, 2011, 01:20:20 PM
it would be nice to have all versions of psp able to use this with out an external battery
if the voltage is lower just use a different booster. duh this way the mod will be perfect
cause then the stuff will only have to be as big as the chip.
-
The psp side of things is already started.
I broke it down into steps.
1. VSH
a. Map out locations of standard xmb "highlighted" icons.(see video)
a1. take these locations make the touch zones for selecting "highlighted" icon. scecntl this action as "x" but put constraints on this.
a2. movement in xmb controlled by dpad. directly mapped as slides or 4 touch zones.
b. this plug in works very similar to cxmb.
2. music controlls. this might be as simple as using the same hex as the remote. we could add some features like slides etc. again more touch zones.
3.keyboard. working with someone with the chatpad mod about this . waiting on more info.
4.user interface to remap .
5.GAME. i saved this for last because by the time we get to this hopefully we will have learned lessons and worked out bugs. Also this is fairly intense. It uses most of the other pluggins too.
I'll reveal more on this later.
----------so right now im working on the vsh stuff.
-
alright. sounds good hopefully tokyo will give us an update soon.
Post Merge: January 26, 2011, 01:52:01 PM
I couldn't get f00ks the data sheets and schematics earlier so I will send him those some time with in the next 2 days. hard to find it all I am not very organized.
-
I was shopping around started looking at this ...
http://www.dealextreme.com/p/multimedia-charging-stand-for-psp-6577 (http://www.dealextreme.com/p/multimedia-charging-stand-for-psp-6577)
It has remote and audio pass through. the sio can be passed through.
-
I think I can make a custom case for the setup thats just the right size
I have axis to a lave that reads the auto cad files and can "print" a prototype case just have to ask the teacher about it. as for the pass through we would have to some how alternate the signals from the tx so that if another device was plugged in the pass through it the tx would not interfere with each other. the rx can just be split. I suppose that we could just send the pass throughs tx to the avr and let the avr do it. if we are to do this it is extra. no garuntee that we put this in okay.
I have begun making designs for the case as well the way I see it we go for a modern look. so I was thinking we make it like 4mm high and the length of the psp. then for the 2nd analog to be held in place use a low profile suction cup. like 2 mm in hieght 3mm at most use flexable cord to connect the analog to the rest. for the touch screen use a similar set up. have a 2-3mm suction cup that is the same size and profile as the screen. have a flexible cord go around the back of the psp to connect to the rest of it. to insure the touch screen is in the same place every time have it screw in to the top where the go cam screws in.
for the external one.
for internal use the avr to pass through tx too.
-
I really dislike the suction cup idea. I guess if you have to have your analogs to line up.
I got most of the vsh stuff figured out.
it kinda works like this.
Im building individual rco's to create plugins for certain things. At the same time Im making a cxmb just for touch screen.
top menu plugin handles most of menu operations.
Content browser plugin handles music control and photo slide show.
theres a whole bunch . post preview soon.
Creating our own xmb will add a nice touch" lol. There is a lot of images to prep yet but at least i know how Im mapping out the conrols now.
Direct scecntl is a must in VSH. This must be done on avr or uart w/e. this can be mapped in hex. I have most of the controls mapped out in hex already. Another good thing about hex is there is a code for hold and wake.so you could turn on the psp by a touch combo programed into the avr.
-
draw a power button like on a computer for stand by. XD we can make suction cups optional. have a hard mount version.
-
The best way i can see to make this work as a proof of concept first is to directly map out control zones/sliders for dpad and or analog ,o,[],^x . A virtual dual nub idea also. But only one virtual and one real. since we can't read two places at once we use real analogs for all movement, and short cut touch motions and or zones to Direct control over ,o,[],^x buttons . This way we can have simple controls whether we are on game or at vsh or using irshell. Irshell lets you launch apps on shortcuts, this could be worked in easily. Example analog up launches app1. touch zone 1 (shortcut to app1) takes priority in touch over analog.
dual nub and most nub control is done during game anyways. so just dont use nub in xmb.
-
sounds good the schematics are set. but right now we really need someone to code the AVR.
-
Ill keep going on my end, if all goes well VSH will be ready tomorrow. Once VSH is ready and i mark out the touch zones you'll see how easy IM making it for the code. slide across the y holds the opposite dpad direction, while a simple touch zone moves 1 space. 4 touch zones for movement and 2 slide parameters. double tap near your selection and that is x . double tap back icon = o . might add 1 slide for vol also.
Music/ photo control stuff next because its part of vsh plugins. but Thats just 1 slide for vol and a few touch zones. I also figured out a way to skin the media player in regular xmb music player. the psptouch interface in vsh looks sweet. preview video coming up soon.
Im having trouble uploading video.
Here is my question to you guys. Can we hook to the icon locations in the vsh for the touch zones? Every cxmb has a different setup with the icons. If we hook the touch zones to these icons then the zone would change with the new icon set. Every control for the xmb has a icon that goes with it. What do you guys think? Anyone with ideas on this code I would love for some help about now. I'm starting to think more and more that this has to be writen with the avr . Meaning the codes are going to have to be combined .
Its kinda funny. I can see this easily working with an internal mod and direct button control via hardware mod and avr touch input. Example just programing the avr to receive touch analog and convert that signal into digital switched outputs , hard wire this to the controls. only need to program the avr. no psp programing needed. What do you guys think?
Post Merge: January 29, 2011, 11:54:05 AM
Found this: in regards to txd ,rxd and audio jack power and psp standby .
this whole article is out dated but , If you throw in the knowledge we've already learned . the way an external deviec is designed to work w the psp becomes clear.
">NIL:
Joined: 14 May 2005
Posts: 26
Location: .ie
PostPosted: Sun Jun 12, 2005 11:01 am Post subject: Reply with quote
As I had a little time and I am still waiting for some low voltage components to build a proper serial line driver, I played a little with the remote port and the remote and tried to identify a few more things.
First of all, the pinout I use is based on mc's description from this page
Also, all the voltages below were measured using a (low budget) digital multimeter => only mean DC voltage was measured and I was unable to observe quick transitions or signal data, if any occured.
My interest has been in completing the identification of the remote port pins and their potential usage, following up on the good work that has already been achieved in this thread. My findings are as follows:
o Pins 1 and 4 are completely unused by the remote - This I could prove by cutting them both out of standard remote operations using a little bit of cello tape (never understimate the power of low budget technology!) As a matter of fact, further reference in this post to "cutting" or disconnecting pins simply mean that cello tape was applied on the relevant pin before the remote was plugged back in.
These are most likely Microphone Input (pin 1) and Microphone Bias (pin 4) and we can presume that the headset thingy will use an electret condenser microphone (this is a very common type of microphone these days since it generates a much better signal/noise ratio than other types of microphones, but it must be powered through a Bias output in order to do so).
I could measure voltage on pin 4, which is constant at about 2.25V. This tends to indicates that this pin most likely comes out of the MICBIAS output of the WM8750L audio chip (datasheet) rather than from the CPU, as it was previously identified that the CPU I/O pins will deliver a 2.5V voltage, not 2.25V.
When disconnecting pins 1 & 4, the remote works just as usual, so those pins are definitely optional when not using a microphone.
o Pin 2 is most definitely digital ground - no question about that. This is the reference ground I used for all the voltage measurements (eventhough I suspect that the jack ground would have been better suited to measure the microphone bias)
o Pin 5 is most certainly a +2.5V Vcc output meant to power any digital external device, as all the tests I have done would tend to prove. I was actually able to power a +3.3V RS232 line driver (which is obviously not really meant to work at that low a voltage) and even retreived some garbage serial data from it. I therefore don't really buy the idea that this +2.5V line is unable to power anything or that TxD has to be hijacked for power.
Now, the first thing to note is that to get pin 5 to provide voltage, you need to have an audio jack plugged in. It looks like, logically, the HPDETECT pin of the WM8750L is being used to indicate the presence of a connector and control the delivery of power:
1) If no jack is plugged in, the 2.5V output is inactive => external devices are left unpowered, regardless of whether the PSP is on or standby
2) If a jack is plugged in and the PSP is on standby, the 2.5V output is always active, regardless of whether the external device replies to potential PSP queries or not (see below). In other words, when the PSP is on standby, external power is applied indefinitely to any remote device. This is quite an interesting feature of the PSP. It could this mean that some CPU functions could still be avalaible when the PSP is on standby, or that a wake up signal could be sent remotely to the PSP.
3) If a jack is plugged in and the PSP is turned on, things become interesting:
a. As soon as the PSP is turned on, voltage on pin 5 drops from +2.5V to 0V for about 0.5 seconds => this provides any external device plugged onto the remote port with a cold reset, as was previously identified
b. After this reset phase, +2.5V is turned back on but it is only maintained if the remote device replies to a specific query within 5 secs.
c. If no proper reply came from the external device within 5 secs, external voltage is turned off, until the PSP itself is powered off in which case 2) applies or the device is plugged in again.
I could test this behaviour with both the remote control by disconnecting pin 6 (which effectively prevents the PSP and the PSP1001 remote device to communicate with each other) and also with my serial line driver, which becomes unpowered about 5 secs after the PSP is turned on (regardless of weather pins 3 or 6 are plugged into it or not). I also measured it directly on open lines (i.e. when nothing is plugged in)
I also checked that with pin 5 disconnected, the remote would not work at all (and no pullup was being provided to either RxD or TxD in the remote, see below). This again tends to prove that the remote only uses pin 5 as its source of power.
Now there is some more to this whole external power thingy, as I also found that:
4) If TxD (PSP pin 3) is cut, then pin 5 (+2.5V) almost instantaneoulsy falls to 0V when the PSP is powered on and we don't even go to the 5 secs phase where +2.5V is being reapplied. This means that somehow the PSP instantly detects that something is amiss with the remote and cuts power indefinitly.
5) If RxD (PSP pin 6) is cut, then we have the whole 0.5 secs 0V, 5 secs +2.5V cycle
Of course, if no pins are cut, +2.5V is being kept applied to the remote
I am not completely sure what to make of 4) above. In fact, I am wondering if we didn't mix up TxD and RxD in the first place, as I have other results that could throw some doubt about which is which:
When PSP power is off (which means that +2.5V is always on) AND PSP pin 3 is cut (TxD), within the remote device I measured 2.40V between pin3 and GND. This looks like some kind of pullup, but under the same conditions (pin 6 cut = RxD) I measured 2.5V between pin6 and GND and not 2.4V.
Now, because both these pins were cut off, these voltages came from the remote device itself and not the PSP.
I would then tend to think then that the +2.4V generated by the remote device on pin 3 comes directly from the IC in the remote, while the +2.5V on pin 6 comes from a direct passive pull up (because it's the same voltage as pin 5 = +2.5V).
For some reason, I would rather see the remote's RxD (hence the PSP's TxD) with a direct pull up @ 2.5V, while I would expect the remote's TxD (the PSP's RxD) to come out of the remote IC @ a reduced 2.4V. Currently, this does not match the description we have of the pins.
My (underpowered) serial line driver also seemed more talkative when using PSP pin 6 as TxD rather than RxD. But then again, all I was able to receive at this stage was garbage, so it's hard to draw conclusions out of it.
Of course I am in the process of building a lower power serial driver, with which I hope to establish proper serial communication with the PSP through the remote port, but this will probably take a couple more weeks. Then I will know for sure which is which between pin 3 and pin 6.
In the meantime, I guess it would be fairly easy for someone with a serial analyzer to double check which is RxD and which is TxD by cello taping one of these pins as I did.
If serial data is still being generated on the isolated line, it'll mean that it is being generated by the remote IC => the corresponding pin will be the PSP RxD.
Feel free to comment on these results."
Post Merge: January 29, 2011, 12:29:36 PM
Huge break through. Got to looking at pikey for keyboard etc. Anyone know of newest version?
-
sorry I was away for awhile I was distracted by the psp2.'
good work man. I was thinking the psp2 had a capacitive multi touch screen and a capacitive multi touch pad with the motion sensing abilities. I was thinking in touch screen mod version 2.00 we can try to inplement these see if we can replicate or even improve sonys results. XD
-
fact :fat psp audio power is 2.5 , slim power 1.9
due to this I think the 2 versions can be split into psp powered fat version. maybe think of some added feature to include w fats. but slims need external power but if you read the article that could get funny. But the slims could use some more power anyways. AS far as programing the avr we just need to program it to work with pikey. Also if we hook the mic to avr we could program voice command somehow. I really want to see this added. if we have the open adc pins?
Speaking of psp 2 , this could peak interest for psp1touch.
first 1 i build will be for fat.
-
there are ADC inputs left on the AVR though all the sound to control processing will have to be done on the psp.
Post Merge: January 29, 2011, 03:30:08 PM
in an earlier post you said can the xmb icons locations be hooked. yes because in each theme they have to map to them for the loaction to show the icons (if this makes since)
and to blink and all ect. for themes we can do this it is similar to what I proposed we do for the plugin. (first post)
and pikey can be used for analog input you know variable x and y?
-
Right! I think we've almost got it.
pikey i think is what we actually base our plugin on w added feature of hooking touch zones to xmb icons and hooking touch zones to keyboard keys. So Simple I can't believe I didn't see this all b4.
plans for tonight. Run one of my fat boys back 5.XXm33 w 1.5 plugin. Or should I just go back to 1.0/1.5 oe? I'm thinking about home brew compatibility. finish psptouch cxmb
-
awsome. we still need the AVR code. I afraid tokyo may have abandoned.
I know this is off subject but i just tried the updated verion of the psp3d plugin.
it worked great it
booted with every game
worked with halo solitude perfectly
has expanded compatability
back on topic
I think our next order of bussiness should be the app for custom configuration.
-
Thats what Im trying to say with pikey. Its not just a keyboard app. There is some custom ability there. Programing in new touch functions will have to be reflashed. We pre-program the avr to handle certain touch inputs any where on the screen. basic shapes, taps , slides. Have you unpacked the pikey package yet? the psp side is pretty much done. Im still going over the package but it looks like almost everything is there. check out this header line.....
"piKEY KEYBOARD DRIVER
-=-=-=-=-=-=-=-=-=-=-
Update release v0.3
By Fanjita
harleyg
Includes material from libpspirkeyb by Monsti,
psplink by TyRaNiD,
and remaPSP by Danzel."
SDK material is used too.
Post Merge: January 29, 2011, 06:50:03 PM
please read user guide in docs for pikey.ITS Amazing!
-
Oh guys...
Sound processing: no way to do this on avr, if u want a mic, plug it into the mic port...
Touch gestures: sure, but not on avr
why do you want to do everything on the avr? this is a MICROCONTROLLER, you can be glad if it makes touchscreen + analogstick input at once...
whatever you want to do with gestures, do it on the PSP
oh, the plugin is simple? lol?
you just have no idea
I'm still in, just still busy with my own project, this is gonna take some more weeks I think, but I have to take a 10 days break or something anytime soon bc when I ordered the PCB I can't do anything else anymore
cheap touchscreen, anyone?
-
I was just bringing up the idea of the voice stuff. I did some investigating and that can all be done within the psp. Someones already working on that.
As far as how easy the plugin is, I meant simple as in the code got simpler. Tokyo did you read what I was talking about with hooking the touch zones to icon locations? That would make the xmb stuff much simpler to write. Would it not? If the avr is not going to handle touch mapping, what is it going to do? just input x,y positions? What information can it put out? I thought the uart could handle hex? example : the media icons hooked to touch zones. When the icon/touch zone is touched for play could the avr/uart communicate the play communication? I thought that hex would have to be used for the comunication between the psp and the avr/uart? Back to hooking icons. Can this also be done with the qwerty? this pikey plugin looks promising did you look at what it does and how it works? If you get some time please check out pikey 0.3 . It says its got a built in lib of keyboards. why cant we just add our device info to the lib?
-
>That would make the xmb stuff much simpler to write. Would it not?
actually not
>what is it going to do? just input x,y positions?
exactly
>I thought the uart could handle hex?
??
>this pikey plugin looks promising did you look at what it does and how it works?
yes
>why cant we just add our device info to the lib?
probably because it's not a keyboard
-
">why cant we just add our device info to the lib?
probably because it's not a keyboard"
- We will be using it as one tho. Why not start out like that. the keyboard has all of the functions we need. Can't we just program it as a keyboard? then include it in the lib?
I dont know its why Im asking.
As far as I can tell the keyboard includes controls for every part of the psp. VSH,GAME,etc it even has analog and user preset buttons. And not to mention it gives us on screen keyboard.
-
that's just not the way you should do this.
it makes things way harder
use the touchscreen as a touchscreen and include (programm) a touchscreen driver to the pikey framework.
-
touchsreen >AVR>plugin(handles gestures and zones all more complex stuff)>any thing we want it to interface with(possibly including pikey)
-
That makes sense. So I downgraded one fat and one slim today. I landed on 5.00m33-6 . The fat was on 1.5 but I put it on 5.00m33-6. So out came all my home brew stuff. I played Wolfenstein 3d today , had the music plugin installed with some "Life of Agony" and "White Zombie" going in the background. It was a blast. Well I bring this up because I tried out some apps. I got mixed results , but I did get most of them to work on both the fat and the slim. 1st app to test was trueflow perfect for touch music interface. 2nd was truphoto another touch like interface for photos. 3rd was paint. then a few plugins . One in particular was xmbel but i couldnt get either psp to recognize in recovery to get working. THis one supposedly lets you replace your own apps for icons in xmb. so tried to put the photo app where the photos where and the music app etc. but I couldn't even get it to come up in plugins in recovery. Just more food for thought.
-
will somebody please help with coding that way we can finish this!?!?!?!!?!?!?!?
-
still busy with my own project, gonna finish the schematics and board layout, then, when I got the part I'll validate everything and then have the pcb etched
=> gonna take some more time
you guys should first try making the psp plugin though, and provide a protocol, I doubt that's gonna work out anyways...
-
I will look into the other parts ,but I hadnt been involved in the plugin up til now I think we wil start fresh with plugin and just make it using the concepts of the neo flash motion plugin. I repeat a from scratch plugin. make it work first then we can add the extra stuff.
by making it work I just mean simple slide motions.
-
The fat was on 1.5
If that was in good condition probably could have fetched a good price... not anymore though
-
It was not original 1.5 but i can go back any time.
-
when writing the plugin to use a protocol
I can just use a similar one to the standard remote protocol as well right?
-
You guys might like this seller on ebay. He sells DIY touchscreen accessories.
http://myworld.ebay.com/electronics_lee/ (http://myworld.ebay.com/electronics_lee/)
-
thanks alot I decided not the use the peice didnt really give too much information on it but it did lead me to find this.
http://ezscreen.com/Resistive-Controllers.htm (http://ezscreen.com/Resistive-Controllers.htm)
theres one already meant for rs232 communication db9
just connect it to sio plug
Post Merge: February 18, 2011, 08:39:01 AM
this brings the price down to about 55$ total
-
Hey I've been away for a while. I finally got a ps3! So any news? Anyone care anymore? This was a great project , I would love to see some programmer get involved.
-
With the PSP2 on the horizon, isn't it too late/too early for this mod?
I dunno, I'm not getting my feet wet in this one until I gut first model PSP2.
-
I think everyone who is waiting on "NGP" is going to have to wait a lil longer. I think there is still a lot of people who would like to see this come into action for the consoles they all ready have.
-
But - why not codebreak the PSP2 and use what we need to mimic it on the PSP?
I've got a 12 inch Wacom Digitizer Unit I'll give to the person who's got the most drive to do something with it.
I don't have the front bezel off the LCD, just the ribbon cable from it, and of course the rear unit, but just for the Wacom PCB should be enough to get somebody toying with the concepts. PCB is about 2"x3".
-
hope this project picks back up
what ever happened to tokyodrift I thought he was in on this mod.
-
I would love to get back at it, we need someone to code this thing, and I don't think tokyo is up for it.
-
yeah I think your right we should both start searching different forums and places for a programmer :yess:
-
Hello and wow love this forum! :hifive:. I came across this when i was trying to find REAL information about building a touch psp. Im trying to build one mostly for browser and emulated Windows os (to kinda make mini tablet that games realy good to) i came across this item and it may solve programming and setup issues??? (Noob so no idea but looks like could be helpfull??) http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_2157554_-1 (http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_2157554_-1)
Please take look and lets see if we can get this idea up and running again. I know vita is out but y not make something close for about 70.00 not spending over 200 on something we dont know if we can even hack yet? Thanks for all the great info up to this point! Love this site! :tup:
-
Hello and wow love this forum! :hifive:. I came across this when i was trying to find REAL information about building a touch psp. Im trying to build one mostly for browser and emulated Windows os (to kinda make mini tablet that games realy good to) i came across this item and it may solve programming and setup issues??? (Noob so no idea but looks like could be helpfull??) http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_2157554_-1 (http://www.jameco.com/webapp/wcs/stores/servlet/Product_10001_10001_2157554_-1)
Please take look and lets see if we can get this idea up and running again. I know vita is out but y not make something close for about 70.00 not spending over 200 on something we dont know if we can even hack yet? Thanks for all the great info up to this point! Love this site! :tup:
the vita is already getting hacked ....slow but its on its way just a matter of time before its fully opened up like the original psp's
will be getting another one soon
-
Still the price point of vita vs psp. Can get psp 1000 with inop umd drive (not needed if running cfw or home brews) for around 20.00 ebay, then the mod screen for 65.00. If it wrks its would be better imo because there are more mods out there for psp's.
edit: Anyhoo, hoping 2 jumpstart this thread again and possibly get a touch psp going. Im not knocking vita, i just dont like how Sony now has a system where you can only use there memory cards. I like how the psp u can use any through adaptors and have up to 64gigs. (Poss more) and there is the fact that most people have psps and if they spend 60 they can have one touch. (If the part i listed on other post can work?) To me the point of moding is to have something that functions in ways it was never intended or designed to wrk. (Kinda like hotrod stationwagions lol). I just dont want to see everyone give up on something that was carrying so much momentum just because of programming issues. So can we PLEASE :beg: get this going again??? :help:
[gmod]please do not double post use the edit button (whitetop)[/gmod]
-
I own a vita now. I love it. I would love to try a go at psp touch again. The problem still remains of lack of a programmer. I know how to build it not program it. but welcom to AM. nice to see fresh faces looking for something oter than rf.
nice find on the capacitive touch screen. When we started this we really only had resistive touch. A new controller would have to be designed.
this would be an awesome addition to my ps3_go device.
-
What i was wondering is the tft lcd says all the drivers and programming are built in. It also listed sample coding. Wondering if there could be homebrew of some sort 2 make this thing work? The connectors all look the same as the original psp screen.
-
I will investigate further .
-
Thats y this forum rocks :tup: ! Please let me know what you think. Even if psp 1000 touch is just pipe dream at this point i realy think all of the minds on this forum should be able 2 make something happen.
-
I find it so sad that so many post are so outdated with broken links and pictures. I just got a psp 3000 and I love it I've be soft modding it and it great being able to play those old games from the 80's and 90's. I now want to do some hardware modding and touchscreen would be a wonderful thing to have on my psp.