Hi all
Developing a sio based hardware project and would like to get hold of pikey running on 3.71, am not interested in the ir mapping etc since developing for the slim but need to add code to support the excellent sio driver posted by jean, i think jf is working on this, is a pre-release of the 3.71(3.80 m33_x, 3.9 ) possibe ?
Pikey 4 release date?
Re: Pikey 4 release date?
Pikey 0.4 unofficial is already out... been out for more than a month. It supports through 3.52, and mostly works with 3.80/3.90. We were looking at 3.7x support, but thought that given the nid resolver in 3.80+ that it wasn't worth the effort. We're looking into why one mode doesn't work in 3.80+.jube wrote:Hi all
Developing a sio based hardware project and would like to get hold of pikey running on 3.71, am not interested in the ir mapping etc since developing for the slim but need to add code to support the excellent sio driver posted by jean, i think jf is working on this, is a pre-release of the 3.71(3.80 m33_x, 3.9 ) possibe ?
ah! Is that the one posted over at qj.net? the one with the empty 3.71 folder?
Did not realise it was 3.71 alone giving you grief!, got entirly wrong end of stick; thought it was 3.71 and beyond giving troubles!
Well excellent then! hopefully will have jeans sio driver integrated and working with the touchscreen in no time ( i wish!!!! have to learn lots more psp flavoured c and finish the mod tutorial for a start!! )
is pikey on the svn here?, i dont seem to be able to find it in the trunk.
My prog skills are not yet up to the standard of you code gods on this site so if i post some damn stupid questions sorry in advance !!
Did not realise it was 3.71 alone giving you grief!, got entirly wrong end of stick; thought it was 3.71 and beyond giving troubles!
Well excellent then! hopefully will have jeans sio driver integrated and working with the touchscreen in no time ( i wish!!!! have to learn lots more psp flavoured c and finish the mod tutorial for a start!! )
is pikey on the svn here?, i dont seem to be able to find it in the trunk.
My prog skills are not yet up to the standard of you code gods on this site so if i post some damn stupid questions sorry in advance !!
Pikey is not in the ps2dev repo. The pspirkeyb library is. Fanjita used to maintain pikey, but stopped after 0.3.jube wrote:ah! Is that the one posted over at qj.net? the one with the empty 3.71 folder?
Did not realise it was 3.71 alone giving you grief!, got entirly wrong end of stick; thought it was 3.71 and beyond giving troubles!
Well excellent then! hopefully will have jeans sio driver integrated and working with the touchscreen in no time ( i wish!!!! have to learn lots more psp flavoured c and finish the mod tutorial for a start!! )
is pikey on the svn here?, i dont seem to be able to find it in the trunk.
My prog skills are not yet up to the standard of you code gods on this site so if i post some damn stupid questions sorry in advance !!
Sony started changing the kernel-level nids at 3.71, altering them again for 3.80 (and 3.90), so D_A decided to add the ability to resolve the older nids into the current ones. That way, people don't have to reprogram their plugins/prxs every time the firmware changes (theoretically). As long as the nid you use is one he resolves, the kernel function will work using the old nid. He also resolves some of the 3.71 nids as well so that 3.71 stuff should work without change.
cool! thanks loads am looking at the code now, will post for help ( and boy will i need it ! ) when have a valid serial data stream from the ts, hopefully next week when the low voltage ts controller turns up.
Thanks again, i intend to post the finished project for the intrepid who want their own ts.
Thanks again, i intend to post the finished project for the intrepid who want their own ts.
If you get to the point where you are getting serial data into the PSP from the keyboard, adding a driver into the pspirkeyb would be the next step. That would make it work with pikey and various homebrews (once the devs get around to updating to the new pspirkeyb code, at least).
The drivers would be found in the file 'pspirkeyb/libpspirkeyb/pspirkeyb.c'. Look over the drivers already there to get an idea of how they work. For the main part, they do this:
- Get the next data byte. The IR keyboards do this by reading the IRDA device, but you'd do it by reading the serial.
- Check if a data packet has been fully assembled. If not, exit.
- Data packet ready, so decode packet to scancode.
- Lookup scancode in table.
- Report key transition.
It's pretty simple. The main thing is figuring out the data packet structure and making a list of all the codes for each key. With an IR keyboard, you would use something like the IrDAmon program to do that. It simply waits on the IRDA device for data, then prints it to the screen. You would do the same for the serial for your keyboard.
The drivers would be found in the file 'pspirkeyb/libpspirkeyb/pspirkeyb.c'. Look over the drivers already there to get an idea of how they work. For the main part, they do this:
- Get the next data byte. The IR keyboards do this by reading the IRDA device, but you'd do it by reading the serial.
- Check if a data packet has been fully assembled. If not, exit.
- Data packet ready, so decode packet to scancode.
- Lookup scancode in table.
- Report key transition.
It's pretty simple. The main thing is figuring out the data packet structure and making a list of all the codes for each key. With an IR keyboard, you would use something like the IrDAmon program to do that. It simply waits on the IRDA device for data, then prints it to the screen. You would do the same for the serial for your keyboard.
Ok looks pretty straightforward to support my sio kbd, since i am using a microcontroller as the serial source i can controll the data packet thus alowing minimal coding to the standard sio input driver in pikey ( just a little tweaking to accomidate new sio buffer ).
Supporting my touch screen overlay in keyboard mode will be harder requiring a new input and output driver to the framework, and using the graphic drawing functions in the developers tools.
Just to make sure, despite what it says in the Unofficial 0.4 piKey Manual.doc
"Unofficial piKey 0.4 runs as a plugin for Dark_AleX’s /M33’s/HX’s and Wildcard’s custom firmwares. It can also be run from various homebrew applications that to use keyboard input. If you are using a custom firmware above 3.71, please ensure you have the 1.50 kernel installed. There are 2 versions in this package.
- PSP’s with kernels of 3.52 and below.
- PSP’s with kernels of 3.71 and above.
Please select the correct package otherwise piKey will not work for you."
i can use the installer/source/binaries in the "3.52 and below " folder on my 3.90 slim? ( obviously with the configs being correct etc )
Supporting my touch screen overlay in keyboard mode will be harder requiring a new input and output driver to the framework, and using the graphic drawing functions in the developers tools.
Just to make sure, despite what it says in the Unofficial 0.4 piKey Manual.doc
"Unofficial piKey 0.4 runs as a plugin for Dark_AleX’s /M33’s/HX’s and Wildcard’s custom firmwares. It can also be run from various homebrew applications that to use keyboard input. If you are using a custom firmware above 3.71, please ensure you have the 1.50 kernel installed. There are 2 versions in this package.
- PSP’s with kernels of 3.52 and below.
- PSP’s with kernels of 3.71 and above.
Please select the correct package otherwise piKey will not work for you."
i can use the installer/source/binaries in the "3.52 and below " folder on my 3.90 slim? ( obviously with the configs being correct etc )
For data packets, you might consider something like:jube wrote:Ok looks pretty straightforward to support my sio kbd, since i am using a microcontroller as the serial source i can controll the data packet thus alowing minimal coding to the standard sio input driver in pikey ( just a little tweaking to accomidate new sio buffer ).
Supporting my touch screen overlay in keyboard mode will be harder requiring a new input and output driver to the framework, and using the graphic drawing functions in the developers tools.
Just to make sure, despite what it says in the Unofficial 0.4 piKey Manual.doc
"Unofficial piKey 0.4 runs as a plugin for Dark_AleX’s /M33’s/HX’s and Wildcard’s custom firmwares. It can also be run from various homebrew applications that to use keyboard input. If you are using a custom firmware above 3.71, please ensure you have the 1.50 kernel installed. There are 2 versions in this package.
- PSP’s with kernels of 3.52 and below.
- PSP’s with kernels of 3.71 and above.
Please select the correct package otherwise piKey will not work for you."
i can use the installer/source/binaries in the "3.52 and below " folder on my 3.90 slim? ( obviously with the configs being correct etc )
key: 0xC0 scancode /scancode
touchscreen: 0xD0 X Y /X /Y
Sending the NOT of the value as part of the packet allows the driver to verify the integrity of the packet data. It's one of the things I like about the Palm keyboard.
One thing to remember about pikey - it has NOTHING to do with the keyboard driver. It USES the keyboard library (pspirkeyb). As such, the only thing you need to worry about is a driver for pspirkeyb. Once that works, pikey support is automatic.
Ok, 3 questions maybe i could have posted in a separate thread:
1) Why not to code libraries as a prx so old compiled binaries (we cannot recompile), would work with newer keyboard driver just swapping prxs? This would only require function entry points in prx to be consistent.
2) I've completely rewritten ChatPad's firmware to make it work with PSP...this project is going to grow because there's a large interest around ChatPad (because of those people trying to mount it in their "carputers"); i'm working on a fully on-the-fly configurable keyboard firmware, and i plan to insert a PSP specific mode: in this working mode, i could not only send ascii chars once, but buttonPress/buttonRelease messages like other keyboards, improving usefulness of keyboard in homebrew games: ANY advice of what a great keyboard firmware could do is appreciated.
3) Can't we look in our program if pikey prx is loaded and if so, query it for data instead of conflicting reinstantiating pspirkeyb?? In win32 i used to do things like that creating a system wide mutex other programs can check on.
1) Why not to code libraries as a prx so old compiled binaries (we cannot recompile), would work with newer keyboard driver just swapping prxs? This would only require function entry points in prx to be consistent.
2) I've completely rewritten ChatPad's firmware to make it work with PSP...this project is going to grow because there's a large interest around ChatPad (because of those people trying to mount it in their "carputers"); i'm working on a fully on-the-fly configurable keyboard firmware, and i plan to insert a PSP specific mode: in this working mode, i could not only send ascii chars once, but buttonPress/buttonRelease messages like other keyboards, improving usefulness of keyboard in homebrew games: ANY advice of what a great keyboard firmware could do is appreciated.
3) Can't we look in our program if pikey prx is loaded and if so, query it for data instead of conflicting reinstantiating pspirkeyb?? In win32 i used to do things like that creating a system wide mutex other programs can check on.
1) Both pikey and pspirkeyb have prx libs available, but for some reason, most devs seem to prefer using the static version of pspirkeyb (probably because it's less work to use the static lib).
2) As a slim owner, I'm VERY interested in work with the ChatPad. If you ever get the interface going, please report it here and I'll do one up myself so I can help with the PSP programming. :)
3) Yes, both pikey and pspirkeyb come with example code on how to look for/load the prx library. Devs could look for pikey, then pspirkeyb (for the case where pikey isn't installed). Pikey is not part of the official SDK - it was 3rd party software released by fanijta/noobz. As such, it never made it into any "devkit", which is unfortunately what most PSP devs use. Most devs are also therefore using out-of-date versions of pspirkeyb as well, given that most devkits are fairly old. Then add the fact that many devs aren't comfortable with the PSP prx library system, and you see why many just link in the pspirkeyb static lib and forget about it.
2) As a slim owner, I'm VERY interested in work with the ChatPad. If you ever get the interface going, please report it here and I'll do one up myself so I can help with the PSP programming. :)
3) Yes, both pikey and pspirkeyb come with example code on how to look for/load the prx library. Devs could look for pikey, then pspirkeyb (for the case where pikey isn't installed). Pikey is not part of the official SDK - it was 3rd party software released by fanijta/noobz. As such, it never made it into any "devkit", which is unfortunately what most PSP devs use. Most devs are also therefore using out-of-date versions of pspirkeyb as well, given that most devkits are fairly old. Then add the fact that many devs aren't comfortable with the PSP prx library system, and you see why many just link in the pspirkeyb static lib and forget about it.
Well did not realise there was a psp slim kbd project so far underway !! I have not seen the chatpad specs so few questions?
1) Chatpad, powered of the sio port or self powerd?
2) Does it clip on to the base of psp slim in sexy manner?
3) Physical dimensions?
pspirkeyb seems best alternative as baisis to the chatpad project given irkbd general acceptance and support in the dev community, since Jean has controll over his side of the data stream, just a little work on the micro code should be able to replicate the data structure to a standard/good ir kbd alredy supported by pspirkb then as jf suggested redirect the input stream from ir to sio.
Unfortunatly to drive my touchscreen overlay in kbd mode will need to use pikey framework and create new input module, since have to display the kbd ( i am thinking display touch locations as transparency when osk is called by an app ), or is the pspirkbd framework able to do that?
1) Chatpad, powered of the sio port or self powerd?
2) Does it clip on to the base of psp slim in sexy manner?
3) Physical dimensions?
pspirkeyb seems best alternative as baisis to the chatpad project given irkbd general acceptance and support in the dev community, since Jean has controll over his side of the data stream, just a little work on the micro code should be able to replicate the data structure to a standard/good ir kbd alredy supported by pspirkb then as jf suggested redirect the input stream from ir to sio.
Unfortunatly to drive my touchscreen overlay in kbd mode will need to use pikey framework and create new input module, since have to display the kbd ( i am thinking display touch locations as transparency when osk is called by an app ), or is the pspirkbd framework able to do that?
The ChatPad is part of the XBox 360 Messenger Kit. It clips to the XBox 360 controller and give you a thumb operated keypad. Someone is trying to interface it to the PSP serial, but it is NOT in any shape or form a PSP peripheral. You can google for reviews and photos. I posted a link on the forum here a little while ago showing the ChatPad, and how to disassemble it.jube wrote:Well did not realise there was a psp slim kbd project so far underway !! I have not seen the chatpad specs so few questions?
1) Chatpad, powered of the sio port or self powerd?
2) Does it clip on to the base of psp slim in sexy manner?
3) Physical dimensions?
pspirkeyb seems best alternative as baisis to the chatpad project given irkbd general acceptance and support in the dev community, since Jean has controll over his side of the data stream, just a little work on the micro code should be able to replicate the data structure to a standard/good ir kbd alredy supported by pspirkb then as jf suggested redirect the input stream from ir to sio.
Unfortunatly to drive my touchscreen overlay in kbd mode will need to use pikey framework and create new input module, since have to display the kbd ( i am thinking display touch locations as transparency when osk is called by an app ), or is the pspirkbd framework able to do that?
Any kind of onscreen keyboard, using a touchscreen or not, will require a LOT more program intervention than pikey or pspirkeyb can supply. Your best bet for a touchscreen is to just provide a means for devs to simply get the coords of a screen touch and leave the rest to them in implementing something like the Danzef onscreen keyboard.
YEAH! I made it work!! At this point, i think this requires its own topic...
http://forums.ps2dev.org/viewtopic.php?p=64736#64736
Anyway, just to answer question where they're asked:
For every other point, please refer to the topic linked above.
http://forums.ps2dev.org/viewtopic.php?p=64736#64736
Anyway, just to answer question where they're asked:
Yes, i can make this little wonder send anything you like, whatever the protocol (even ps2 with little modifications), BUT i think we should exploit it the more we can, and code a specific larger handler to fully support all chatpad can give us...since Jean has controll over his side of the data stream, just a little work on the micro code should be able to replicate the data structure to a standard/good ir kbd
Bad luck, this is true, but i'm glad to inform you that the minimum hardware we need is the gray zone you see in photos, approx 100mm large x 50 mm long x 4mm tall.The ChatPad is part of the XBox 360 Messenger Kit. It clips to the XBox 360 controller and give you a thumb operated keypad
For every other point, please refer to the topic linked above.
Yes JF your prob very right about just letting the devs get on with it, for the non kbd usage mode of the ts i was just going to publish the data packet format along with the mico code and thats it !! But for the kbd usage i was very interested in the abbility to hook into sce functions (in the xmb/internet browser for a start) which pikey gave me, now after investigating the hombrew scene and finding out that often the sce apps are crap compared to the homebre equivelents i am more inclined to code my own osk with touchscreen support and graft that into my fave apps, most of which come from zx81 and are open source anyway ( appart from mapthis which is also open source! ).
Reading the dev docs in pikey though and it states i can build an input driver that draws an overlay with few functions, but says these functions in development and may not work, that may be just what i need as baisis of code if it all works!!
Reading the dev docs in pikey though and it states i can build an input driver that draws an overlay with few functions, but says these functions in development and may not work, that may be just what i need as baisis of code if it all works!!
errr, my psp code skills just not up to that task at moment!! Anyway concentrating on how to fit circuitry into pspslim ( not much f**** room anywher in there ) and accomidate the extra 1/2 mm on the top casing, if anyone else fancies the code task be my guest, will have finished proto in week or 2 , low voltage ts controller chip has to turn up and have to breadboard it all up for the proof of concept before the prototype, then the proto itself.
yep just what i was thinking not going to jump into pikey straight away !! Going through this website ( which is f*** amazing by the way )as i go along and absorbing the prog advice. Have my toolchain and libs installed ok on cygwin, psplink and gbd/insight for debug ( having few probs with gbd on newer fw's ), when i fully understand the module tutorial will be ready to go i think.