Open Keyboard Project

[jean]

[EDITED] the part speaking of how to retrieve scan codes has changed...
Here i am, just back from holidays! Let's answer some questions...

Is anyone willing to ship a pre-modded chat pad with cable for about $15 (or more)?

I can do the PSP Side sio part myself...

Forget about it... the chatpad itself costs about 30€... and the "cable" is not something you can attach to the device without having to open it. You have to do a whole lot of work to adeguate plastic shape (or your chatpad will be huge) and a little soldering to have the right connector connected. The PSP side of sio part is...well, nothing. There is no hardware addition to chatpad's to make it work with PSP (apart from sio connector that some online stores sell already done). Again (sorry if this sounds pedant) in the three releases of this hack there are images, more valuables than 1000 words.

For the pikey stuff, please notice the following:
Angelo IS NOT the coder of pikey, even if he claimed he is the "mantainer". Despite the fact that Angelo first pointed out the irda.prx issue -and a possible workaround- he is not even responsible of the 3.xx working version. AFAIK jube first claimed he succeded in making pikey work for 3.xx and helped me compiling my version (that published while my site was working).
To make a working 3.xx pikey version (even without irda support) work with chatpad, turn off all input plugin but the SIO one. Then turn on the output plugin you like. Only issue i could not fix in pikey was the inability to set baud rate, that hence remains a standard 4800 on PSP side. So, you should set 4800 on ChatPad side, too (9600 for default). This is now possible only on flashing time (due to some technical problems i encountered) and i see it's not very user friendly. I will fix this thing somehow in next firmware release (if someone is willing to see what can be done on PSP side for baudrate setting, you're welcome).
Protocol: while chatpad is continuously powered, press [people]+A or [people]+S to set _serial_ or _advanced_ mode. In serial mode, a press e.g. "a" is sent as ascii char "a"; in advanced mode, a press e.g. "a" will be sent as a scan code 85 = 21+64, while the release of "a" will be sent as 21. The scan code can be easily figured out: first line up, first row on the left is 1,first key second line is 21 and so on, 2nd MSB of a one-byte-code set meaning "pressed" (released if 0) (MSB reserved for future use). Please notice that in standard serial mode a [shift]+[a] will be sent as "A", while in advanced mode single press and release messages for each key would. Pikey at the moment works with standard serial mode only: i never wrote a plugin handling advanced mode despite of its simplicity because i'm planning to add some features (like the remote control of lights and settings)....but maybe it's a good idea to make one in the meanwhile...

EVEN IF YOU ARE NOT MICRO DEVS, LOOK INTO OpenKeyboard SOURCES: COMMENTS ARE A PRIMITIVE MANUAL.

Finally, thanks for your interest;
To all guys asking in educated and polite manner: sorry for the delay, i didn't meant to ignore anyone.
To all guys not so polite in their requests: this is not customer service.
Thanks to l0rdnic0 for credits in his video (nice work with the working hearphones!)
Feel free to ask anything still blurry.

jean

PS: i need some talented PSP dev to care about this: http://forums.ps2dev.org/viewtopic.php?t=10802
please, help me in my idea of a better interface.

[mypspdev]

If of interest, under 3.xx (now cf 4.01-m33-2), for SIO interface I use:
- a SIO prx to be loaded with GetChar, PutChar, PutData, PutString, BaudRAte
- my eboot load and start the sio.prx and with Up/Down arrow changes the baud rate on PSP side then get or put chars

It works fine both on Slim and on Phat, last toolchain, last cf .

As Keyboard I'm using at present an emulator of VT100 terminal: it works fine.

If of interest I can share here following the code, as soon as I'll be back at my personal computer with source.

Regards to all

[jean]

...i know the entire prx story, and i even published an "official SIO driver", that's probably what you're using... the sad thing is that i just couldn't manage to make it work in vsh mode under pikey. As soon as you set baudrate, the whole system hangs on my phat...[EDIT] SOLVED...or at least workarounded. Jump to page 5 for some source code doing this...

[mypspdev]

...i know the entire prx story...

I surely did believe.....
I'm using a derived SIO from last MapThis application...

[jube]

best use jeans sio prx, it links fine, and has an added circular buffer, i used it for all my dev work and it works well.

[l0rdnic0]

OK Jean hope my questions are not to noobish but here goes.

Here i am, just back from holidays! Let's answer some questions...

(Welcome Back!!)

To make a working 3.xx pikey version (even without irda support) work with chatpad, turn off all input plugin but the SIO one.

(Help me out here are you telling me to modify the piKeyconfig.txt file and type in DISABLED PLUGINS = piKeyIR.prx)

Then turn on the output plugin you like.

(Umm how do I do that?)

Only issue i could not fix in pikey was the inability to set baud rate, that hence remains a standard 4800 on PSP side. So, you should set 4800 on ChatPad side, too (9600 for default). This is now possible only on flashing time (due to some technical problems i encountered) and i see it's not very user friendly.

(OK so I'll modify your code to use 4800 Baud and re-flash)

[color][people]+S to set _serial_ or _advanced_ mode[/color]. In serial mode, a press e.g. "a" is sent as ascii char "a"

(Do I need to do this each time I intend to use the keyboard, IE: after I load each program?)

EVEN IF YOU ARE NOT MICRO DEVS, LOOK INTO OpenKeyboard SOURCES: COMMENTS ARE A PRIMITIVE MANUAL.

(Think I'm good here just that piKey and PRX crap messing me up)

Finally, thanks for your interest;
Thanks to l0rdnic0 for credits in his video (nice work with the working hearphones!)

(Srsly No Problem and THANK YOU for taking the time to get back to me and thanks for your input.)

[l0rdnic0]

OK sorry for the dbl post, wanted to keep this separate from my last post.

So, I re-flashed using 4800 Baud. I then booted up the PSP into Jeans SIO test app.

Set the baud rate to 4800 and the keyboard works fine. Then I exited out and was happy to see that the keyboard responded in the VSH. I launched the web browser and then entered the OSK, but was unable to type. I unplugged the keyboard form the PSP and plugged it back in while still in the OSK. The keyboard blinks (like it normally does when I first connect it) and I am able to type for about 10 seconds while the keyboard is blinking after that the keyboard stops responding, WHY!!!!! gah so close. If I unplug the keyboard and plug it back in it works again for about 10 seconds. So thats what I keep doing help me. :P

Jean
looking through your code I see the following,

void enterPowerSave(){
// debug test
// USART_Write('s');
// USART_Write('l');
// USART_Write('e');
// USART_Write('e');
// USART_Write('p');
PORTA = 0;
INTCON.RBIE = 1; // enables PORTB on-change interrupt
asm{
sleep; // sleep?
}
}



Why is that word Sleep in red is that an error??? I dont think that asm should be there, am I right? Thing is, if I remove that during build I get an Undeclared identifier [sleep] in expression. Do you have an updated openKeyboard.c file?

[Neubit]

Hey, Nic0, i finally got my chatpad, man that thing is smaller then I imagined! Hi Jean, you and everyone else who are making progress on this are doing a great job! Props to all :) I'm going to give this a try myself, hope to give my 2 cents. Jean, can you please confirm that openkeyboard03.zip is the latest compile of code for the chatpads firmware. Thank you!

[l0rdnic0]

nubit,

I'll send you my latest hex file. After reading Jeans last post I had to re-compile.

diid you get that Jap version kbd?

[Neubit]

nubit,

I'll send you my latest hex file. After reading Jeans last post I had to re-compile.

diid you get that Jap version kbd?

Yeah i got the Japanese one man, i don't want to preorder and wait for 2 weeks for the US version, Im gonna miss out on all the fun :P

[jean]

(Help me out here are you telling me to modify the piKeyconfig.txt file and type in DISABLED PLUGINS = piKeyIR.prx)

yes

(Umm how do I do that?)

you can leave defaults

(Do I need to do this each time I intend to use the keyboard, IE: after I load each program?)

No, openKeyboard firmware automagically stores settings in internal flash. [EDIT]...you were right, now on 0.3 there's a bug that doesn't allow settings to be saved correctly, will correct it asap in 0.3.1

I am able to type for about 10 seconds...

Ok, i see the point.
A brief explanation... when in an HB you want to use serial port you have to do 3 things:
1) Turn off remote manager
2) Turn on SIO power
3) init SIO stuff
Problem is on point 1. VSH enables remote manager that tries for 3 times to power on SIO and search for a responsive remote controller and it can't find one, of course, so it finally shut SIO power down...too bad.
"Sleep" you see is part of the fully functional power saving manager on chatpad's side, in fact, if you use your keyboard with pspAdvancedSio everything goes a charme (provided you've setted the right baudrate on PSP side, too through UP/DOWN keys). Problems are on the SIO initialization under VSH in pikey...let me investigate a bit (i think i have at least a version of pikey that doesn't suffer this)...
Seems i've to publish some stuff...everyone willing to host files or willing to suggest a free hosting service PM me, with an email address to send files to if needed.

[l0rdnic0]

Jean,

So the fact that sleep is red in the code does not mean that its an error.

As mentioned before I can host the files that you have an I have even created a package with all the latest files that I have from your project, which includes the following.

1, seplugins folder containing your build of piKey
2, GAME.txt with the irda.prx patch (don't know if I really need this)
3, PSP/GAME/SIO_Chatpad (your SIO application)
4, My latest build of your code in HEX
5, All your sources from Chatpad3.zip
6, All of your images from Chatpad.zip and others that Folklord provided to me before his computer blew-up
7, A readme that has the header from openkeyboard.c, Comments and instructions from the forum about the people button and how to use your SIO application (sorry no change log, if you have one please email me)


I would like to send it to you for your approval. If you want I'll PM you my email address. I will work today on setting you up with an FTP account on my FTP server that will have HTTP access for people to link to. Its not much but it is a full T1 up and down. I am in no way a web or FTP admin but unless there is an issue of traffic I can host the files for you.

[jean]

openKeyboard pikey driver on arrival!!! Works smooth...only thing i have problems with at the moment is forcing on speakers despite the presence of the sio connector connected to PSP. Deniska here (http://forums.ps2dev.org/viewtopic.php?t=8732) claims his MapThis! does the trick, but i could not find where in the sourcecode (maybe i mistakenly downloaded the wrong version?!). Next issue i will face -if i can solve this- will be device plug/unplug handling. Any advice appreciated.

[l0rdnic0]

Can I ask that you provide me with your working code? I understand that your trying to trick the system to continue to play sound out of the speakers but since I wired a headphone pass through I can live without that part..

:D

[jean]

Ok, guys... i asked deniska by pm for a more indeep explanation, but i think i figured it out how the speaker stuff works. Far from being well known, there is a mechanism that enables or disables speakers output depending on event fired by the hp/sio port. When sio port is enabled anyway, without caring of what's attached on its port, we stop all modules that could interfer and redirect interrupt handling to a function of ours, so maybe the "someone plugged in something, shut that speakers down!" event cannot reach its destination and hence speakers remain on. Deniska's GPS are generally battery operated, so SIO power can be shut in any moment and everything is fine anyway, while in my case if -for instance- i unplug and then replug chatpad it COULD communicate but it's not powered. So i will try handling those events solving two problems with a single solution. As a secondary issue, i noticed that while chatpad's driver (i mean the PSP side, not firmware) is active, PSP never goes in power-save mode or stand by....something i use is sending powerTicks?? Must investigate (but unfortunately my remaining free time before i return to my routine is shrinking...)

jean

PS: @ l0rdnic0: sure! but i still need to clean up the code a little bit, before...

[everlasting]

Ok, guys... i asked deniska by pm for a more indeep explanation, but i think i figured it out how the speaker stuff works. Far from being well known, there is a mechanism that enables or disables speakers output depending on event fired by the hp/sio port. When sio port is enabled anyway, without caring of what's attached on its port, we stop all modules that could interfer and redirect interrupt handling to a function of ours, so maybe the "someone plugged in something, shut that speakers down!" event cannot reach its destination and hence speakers remain on. Deniska's GPS are generally battery operated, so SIO power can be shut in any moment and everything is fine anyway, while in my case if -for instance- i unplug and then replug chatpad it COULD communicate but it's not powered. So i will try handling those events solving two problems with a single solution. As a secondary issue, i noticed that while chatpad's driver (i mean the PSP side, not firmware) is active, PSP never goes in power-save mode or stand by....something i use is sending powerTicks?? Must investigate (but unfortunately my remaining free time before i return to my routine is shrinking...)

jean

PS: @ l0rdnic0: sure! but i still need to clean up the code a little bit, before...

I guess you probably already know but it seems that the sio port is only powered up if headphones connected. The headphones socket has some extra pins, i mean you only need three pins for a headphone socket but it is quite common that these sockets have four or five pins. Normally these extra pins are connected to ground when nothing is inserted and they are connected to nothing when headphones connected. So this is probably the source of the signal you are looking for, and responsible of the powering up the sio.
I don't have any idea if it is possible to control this by software, guess yes but i don't know.
If i were you i would start by looking at the hprm libs. I just looked there for a few minutes and found this:

int sceHprmIsHeadphoneExist (void)
Determines whether the headphones are plugged in.
int sceHprmIsRemoteExist (void)
Determines whether the remote is plugged in.
int sceHprmIsMicrophoneExist (void)
Determines whether the microphone is plugged in.

[jean]

@everlasting: thanks for caring, but i think you misunderstood the problem. We don't care about having a real or fake hearphone jack inserted in its plug with SIO conector. I'm trying to force speakers on when this happens, and we all know it's possible because if you leave sio port empty, initialize sio (power on, intr-handling fn replaced, etc...) and then you stick a connector into port, well speakers are still on. And that's exactly how deniska's mapthis works AFAIK. BUT i would like to programmatically choose speaker activation without havng to rely on this kind of system malfunction. By this point of view sceHprm* fns are quite useless; on the other side, one thing that could be very useful to me is setting up a callback that would be called whenever sio/hp plug insertion state changes to stress if we have to power on again: any idea on how to do such a thing??(and please don't tell me to setup a timer that continuously checks for sceHprm*...things are not meant to be done that way, i will NOT go that way unless strictly necessary)

PS: please, don't quote entire posts -expecially the long ones-....aside from my verbosity this thread is yet a pain in the a** to read :)

[EDIT]
investigating on sceHprmSetConnectCallback and sceHprmRegisterCallback...no known prototype, but i hope they only take a SceUID like every other callback registering function...
@l0rdnic0: this is a required feature, even in your case..otherwise, if you accidentally unplug chatpad during a session you'll have to restart your PSP or launch an application that messes with SIO to have it back functional.

[jube]

on a slim its easy, there is a function that detects the composit cable type, this is activated by grounding a pin with a 10k on the sio ( forget which but is on my post about the connector ) you can just wire a 10k to the pin and detect the change with a standard callback.
On the phat, big problem, its the standard sio driver that detects the change ( it polls the device ) , if you disable it you disable the detect, you need to write your own poll if you want that function, or re-write the chatpad firmware to respond to the psp poll correctly and thus use the built-in detect.
There may be another way by hooking something to do with the mic?

[jean]

S**T! Are you saying sceHprmSetConnectCallback and sceHprmRegisterCallback are slim only??

[everlasting]

We don't care about having a real or fake hearphone jack inserted in its plug with SIO conector

Well you should care about the causes that power up the sio and the causes that make the speakers mute and redirect this sound to the headphones. At least this last one is related with what i explained about the functioning of the heaphones socket, a hardware understanding helps software development.
It is quite difficult to do anything whithout no official documentation but my point of view is:

Code: Select all

void 	pspDebugSioInit (void);

Initialize the sio port and i would say that calls at least to:

Code: Select all

int 	sceHprmIsHeadphoneExist (void);
int 	sceHprmIsRemoteExist (void);
int 	sceHprmIsMicrophoneExist (void)

If you initialize the sio without inserting anything this functions will return false and no power will be redirect to the port and obviously the sound won't be redirected either to the headphones. This process must be done only once and this explains the functioning of the "map this" which as i read have self-powering.
So, if i understood you well in previous posts you want to power the keyboard with the power of the port so you can't do the tricky stuff of initialize the sio without anything pluged and the plug it. Well the thing is that it is needed to find the funtions that power the headphones and sio, and then i would make a thread (not a timer) to check the states of the hprm* functions.
I have not a working PSP right now but first of all i would try to see if the hprm* functions activates automatically the power on sio or redirect the sound. I guess they just only report the state but testing is cheap, and may be you are lucky.
Hope this post was of some help for you.

EDIT:
Does anybody know what is this?Will route the sound either to the headphones or to the speakers?That would be great!!

int sceAudioRoutingSetMode (int mode)
Set routing mode.
int sceAudioRoutingGetMode ()
Get routing mode.

[jube]

jean.......

nope, not at all, they are common.

but looking at the post above i would say

int sceHprmIsRemoteExist (void);

depends upon the correct polling mentioned earlier, but

int sceHprmIsHeadphoneExist (void);
int sceHprmIsMicrophoneExist (void)

are very interesting in that they indicate a 2 flags somewhere that change depending on the resistance state of the phones and mic circuit, which is exacly what you need to test for change of plug state.

[jube]

nt sceAudioRoutingSetMode (int mode)
Set routing mode.
int sceAudioRoutingGetMode ()
Get routing mode.

now that looks VERY interesting, will check it out tomorrow when am back to software.

[jean]

wooohooooo....seems i found it(the speakers issue, not the callback one)....strange i didn't see it in the first searches i did..must be the age...however this post (http://forums.ps2dev.org/viewtopic.php? ... 5255c80577) says:

Code: Select all

int sceCodecOutputEnable(int enable_headphone, int enable_speaker);

that's 0x856E7487 in sceCodec_driver (hope that's already loaded by vsh...)

@everlasting:
-everybody under the sun knows how a switch works, but thanks for explanation :)
-i'm not using pspDebug* but the sio driver i put together myself.
-neither pspDebug* nor mine sioDriver initializing functions return nothing useful for my purpose
-MapThis is not "self powering"...it's the GPS device that's battery operated!! lol ;)
-timer or thread, it's the same shit (ops, sorry i really said that!)...at school they told me "Why bothering on a multithread environment with all that semaphores if you can do active-poll!!!</sarchasm>" that means: no. These things require a callback.
-hprm fns you pointed are read-only: no setters, man (like that "void" in prototypes make you suspect...).
-Functions like sceAudioRoutingSetMode seem to be false positive according to silverspring.
BTW, even if it seems i'm rude, i really love you everlasting: searching for the functions you pointed, after a few jumps have taken me on something really resemble solution of all our problems!! Thanks! (really!)

PS: FOUND some bugs on OKPF 0.3 that prevents regular saving on flash of lightMode and sendMode settings: corrected, will be released as 0.3.1 ASAP.

[jube]

seems to work, need to test what it does in VHS,GAME etc etc

[everlasting]

Jean you took me wrong:

-everybody under the sun knows how a switch works, but thanks for explanation :)

I explained you how a headphones socket works, not a switch. But i am sure you also knew how these works too.

-MapThis is not "self powering"...it's the GPS device that's battery operated!! lol ;)

Very sarchastic from you.Yeah i meant the gps wasn't taking the power from the sio.

-timer or thread, it's the same shit (ops, sorry i really said that!)...at school they told me "Why bothering on a multithread environment with all that semaphores if you can do active-poll!!!</sarchasm>" that means: no.

Really?(ironic)

-hprm fns you pointed are read-only: no setters, man (like that "void" in prototypes make you suspect...).

As Jube said "flags", these are not timers,I assumed you knew how to use them, now i see i was wrong.

-Functions like sceAudioRoutingSetMode seem to be false positive according to silverspring.

Finally something interesting. I will check it.

BTW, even if it seems i'm rude, i really love you everlasting: searching for the functions you pointed, after a few jumps have taken me on something really resemble solution of all our problems!! Thanks! (really!)

*It didn't seem you were rude, indeed you pretended and were rude as i have been here (i recognize it).
*The difference is i was trying to help you as many people in the thread and i got the kind of answer you have written.
*Believe me i regret to have been of some help. Your picture "I eat noobs" should have meant anything for me.
*There are "worse" things than noobs, those who believe to have all the answers and request help. You don't need any help, why do you ask for it?. Hope everyone realize this.

[l0rdnic0]

Hey if I seem quiet it’s because I know nothing about coding, if I did I would most definitely try to help. From an end user perspective I can only express my thanks to everyone for trying to contribute. I can't tell you how often I check this thread per day/night.

Jean thanks for the updates I know your waist deep in code and your working hard, I would like to think that you’re looking forward to the day that you can show people your work and I know it will pay off for you.

Jube and Everlasting thanks for all your suggestions and help!!!!!

[jean]

@evelasting: life is hard, take it easy, man! i tried to jokingly inform you that in my POV you did not fully understand what we are doing here, but you were anyway trying to teach everyone. If you say that I didn't understand, well,... i don't know what to say, but perhaps i don't need to say anything... You've been useful your way, cheer! But please, now stop it, don't start a flame here. Any advice is still welcome and greatly appreciated (but try not to insist when i say it's a no-no)

@everyone else: testing...don't worry i'll release it soon (i would have just published code snppets, but would have risked to seem an idiot....still too much dirt in my code!)

[mypspdev]

Hi jean,
is this the source of your firmware for ChatPad to be flashed for the Pic?

Code: Select all

// FIRMWARE REPLACEMENT FOR CHATPAD's pic16f883.....
// see attached documents to learn more
// first release from jean (jean[at]ecando.it www.ecando.it)
// for the Open Keyboard Project
// thanks alot to Gidi (who owns an half of my chatpad)
// and my sweethart piceta; they helped me handling
// cable knots while testing.

const char map[4][49] = { //////// CHARACTER MAPPING MATRIX
// normal char press
{56,  57,  48,  13, 112,  44,   0,
  0,   0,   0,  46,  32, 109,   0,
  0, 122, 120, 118,  99,  98, 110,
 97, 115, 100, 103, 102, 104, 106,
113, 119, 101, 116, 114, 121, 117,
 49,  50,  51,  53,  52,  54,  55,
107, 105, 111,   0,   0, 108,   8},

// shifted
{56,  57,  48,  13,  80,  44,   0,
  0,   0,   0,  46,  32,  77,   0,
  0,  90,  88,  86,  67,  66,  78,
 65,  83,  68,  71,  70,  72,  74,
 81,  87,  69,  84,  82,  89,  85,
 49,  50,  51,  53,  52,  54,  55,
 75,  73,  79,   0,   0,  76,   8},

// green alt
{56,  57,  48,  13,  41,  58,   0,
  0,   0,   0,  63,  32,  62,   0,
  0,  96,  39,  45, 187, 124,  60,
126, 154, 123, 168, 125,  47,  39,
 33,  64, 128,  37,  35,  94,  38,
 49,  50,  51,  53,  52,  54,  55,
 91,  42,  40,   0,   0,  93,   8},

// red alt
{56,  57,  48,  13,  61,  59,   0,
  0,   0,   0, 191,  32, 181,   0,
  0, 230, 156,  95, 231,  43, 241,
225, 223, 240, 165, 163,  92,  34,
161, 229, 232, 254,  36, 253, 249,
 49,  50,  51,  53,  52,  54,  55,
169, 236, 242,   0,   0, 248,   8}
};  ////////// END OF MAPPING MATRIX

  unsigned char AMask = 0;
  unsigned char BMask = 0;
  unsigned char data[] = {0,0,0,0,0,0,0};
  unsigned char oldData[] = {0,0,0,0,0,0,0};
  unsigned char sc = 0;
  unsigned char idx = 0;

  // alternates (shift,green,red) mapping to translation map
                        // 0  1  2  3  4  5  6  7
  unsigned char alts [] = {0, 1, 2, 2, 3, 3, 3, 3};
  unsigned char alt;

void main() {

  OSCCON = 0x67;                    // 01100111 - 0110 stands for 4Mhz internal clock

  ANSEL  = 0;                       // Configure AN pins as digital I/O
  ANSELH = 0;
  
  PORTA  = 0;                       // init port A
  TRISA  = 0;                       // 1 = input
  
  PORTB       = 0;                  // initialize PORTB
  TRISB       = 255;                // designate PORTB as all input
  OPTION_REG = 0;                   // pull-ups enabled

  PORTC       = 0;                // initialize PORTC
  TRISC       = 0;                // designate PORTB 0-7 as output

  USART_Init(9600);              // Initalize USART (9600 baud rate, 1 stop bit, no parity...)
                                 // hope will override 0s set with PORTC=...

//----- TEST ------------------------
    USART_Write('O');
    USART_Write('K');
    USART_Write('.');
    USART_Write('.');
    Delay_ms(100);
//------------------------------------

  do {
     idx = 0;
     sc = 0;
     PORTC = 1;

     oldData[0] = data[0];
     oldData[1] = data[1];
     oldData[2] = data[2];
     oldData[3] = data[3];
     oldData[4] = data[4];
     oldData[5] = data[5];
     oldData[6] = data[6];

     for &#40;AMask=1; AMask<128; AMask<<=1&#41;&#123;
         PORTA = ~AMask;
         data&#91;sc&#93; = ~PORTB;
         for &#40;BMask=1; BMask<128; BMask<<=1&#41;&#123;
             if &#40;data&#91;sc&#93;&~oldData&#91;sc&#93; & BMask&#41; USART_Write&#40;map&#91;alt&#93;&#91;idx&#93;&#41;;
             idx++;
         &#125;
         sc++;
     &#125;

     alt = alts&#91;data&#91;2&#93;&1|&#40;&#40;data&#91;1&#93;&1&#41;<<1&#41;|&#40;&#40;data&#91;0&#93;&64&#41;>>4&#41;&#93;;
  &#125; while &#40;1&#41;;                   // endless loop

&#125;

I found it on
http://www.mp3car.com/vbulletin/input-d ... rd-15.html
by jean80.

From there some more important news to build up chatpad to PSP:

Also, the baud rate of the uart is 120 buad. This is really slow, but i guess it doesnt need to be any faster.

The controller polls for external ascessories with the command 0x8C. Once there is a return signal, the controller holds the Tx line high.

So to activate the keyboard, you need to send the signal of 0x8C at 120 buad serially to the keyboard's Rx line. Once that occurs, im sure the keyboard will start spitting out characters. However, i dont have a chatpad, so i cant be too certain.

And I was looking for the pinout of the Chatpad keyboard, found here:

http://pictures.xbox-scene.com/xbox360 ... inout.jpg

Soldering:

http://nuxx.net/gallery/v/acquired_stuf ... wsIndex=0

http://nuxx.net/gallery/v/acquired_stu ... jpg.html

Another issue I was lloking for: Pinout for PIC:

The pinout for the 28pin SSOP gives the SSI interface on:
pin 14 - SCLK/SCL
pin 15 - SDI/SDA
pin 16 - SDO

And the UART on:
pin 17 - TX/CK
pin 18 - RX/DT

Tracing the tracks from the J1 header should easily tell you which one they are using for the comms link.

The device supports ISP (in-circuit programming via JP1 header?) on:
pin 24 - PGM
pin 27 - ICSPCLK
pin 28 - ICSPDAT
pin 1 - _MLCR/VPP

Thanks

[l0rdnic0]

I'm not Jean but I can tell you that the code you have posted here is 0.1 code, It was Jeans first code base that was available. Jean if I'm wrong correct me.

The latest version that was made available to the public was 0.3 code. I have that code but its not worth sending it to you at the moment cause Jean has found a few bugs and is trying to resolve them. Keep checking this thread for updates as we don't have a drop dead date as to when the new release is coming. Jean is hard at work so sit tight :D

[mypspdev]

I'm not Jean but I can tell ....

Thanks very much, it's just to have something to play with as well as all link to source code are deleted here ..... without waiting jean for next deliveries ...... when they will happen..... sooner or later ....