p-sprint (psp keyboard emu)

[Arwin]

First, I *really* like the idea of two-press combos to type! I also
like the way the middle letters are slightly raised- matches the
buttons well.

Thanks.

Second, it feels backwards to me...I continuously hit the
second press, then the first. For some reason, when I locate
e.g. 'n' on the screen, my fingers go right to the mini version of the layout
and I press circle first, then square. maybe that would be better switched!

I've noticed it too, once I realised that if I didn't look at the screen but just mentally thought where the buttons should be (not too hard, after all there's a clear logic there), it was much easier.

After your comment, I realise that the on-screen 'help' is main the problem here. There is too much mental interference between selecting a group and the location of the button.

I've come up with a new idea for this:

Code: Select all

 l   u   r   s   t   o
a!, (-) cde ijk opq uvw
:?; 'ab fgh lmn rst xyz

I tried this and it helps a lot, especially if you also raise the middle letters (I made a drawing on paper - I may post a concept screenshot in a minute).

When typing a lot, I also noticed that some button combinations are easier to type. You would probably gain a lot of typing speed by rearranging the most used letters to the easiest combinations. My concern with that is that for someone who doesn't type very often, it will become a lot harder to look up the letters, like when you use a real keyboard for the first time (so-called 'hunt-and-peck-typing').

Next, capital letters are too intermixed to make them modal...ever
use the Palm Pilot's Grafitti system? Consider a combo that makes
the following single letter capitalized, then returns to lower. (Grafitti
also has a combo to swap b/t lower and upper mode for acronyms)

I just realised last night that I can use a lot of combined button presses for additional options. I was thinking about this for ALT, CTRL, SHIFT, and perhaps a cursor lock or (in phase 2) dictionary lookups. SELECT could be used to bring up a menu for this, but combinations that involve pressing two buttons could function as shortcuts.

So say I want a capital letter 'E'. I could still use select to go into full CAPS, but I could also do right - right[keep pressed] - and then down/cross.

(edited:)

combo, keep second pressed, then right or circle(left or right ALT)
combo, keep second pressed, then left or square(left or right CTRL)
combo, keep second pressed, then up or triangle(left or right NUMLOCK)
combo, keep second pressed, then down or cross(left or right SHIFT)

down-triangle (CAPS-Lock)
down-square (CTRL-Lock)
down-circle (ALT-Lock)
down-cross (SPECIAL KEYS-Lock)

cross-left (customiseable / activate most-common-by-length dictionary)
cross-up (NUM-Lock)
cross-right (customiseable / activate search dictionary)
cross-down (CURS-Lock)

(still thinking about the best actual combinations)

Also, consider using a trigger instead of select.

With the above, it won't be necessary anymore. I would like to see select as a standard option for bringing up a context menu though. And start as a default for <Confirm> - that would also do away with the region confusion for cross and circle for confirm.

Repeat isn't very important. Maybe left trigger for upper case + numbers.

For now, I'm going to try to stick to the eight buttons as much as possible. That way this keyboard standard will actually be portable to most keypad+four buttons devices, which could be very useful. And I still want to reserve the L and R button with the Analog stick for mouse simulation.

I'll allow for customisation options to use additional buttons as shortcuts though.

Finally, we're going to need a ~ (tilde) in there for URLs really soon!

I'll replace my failed attempt at inserting the Euro sign with the '~' in the next version.

This will enable so much.
I can't wait for a basic text editor. It will be useful. An interface for wget, too! Or lynx.......keep up the good work!

Thanks! Yes, it does open up things a bit. :)

[shifty]

I've come up with a new idea for this:

Code:
l u r s t o
a!, (-) cde ijk opq uvw
:?; 'ab fgh lmn rst xyz

sorry. i don't quite understand it...but i'll wait for you to explain it more.

When typing a lot, I also noticed that some button combinations are easier to type. You would probably gain a lot of typing speed by rearranging the most used letters to the easiest combinations.

Yes, I would guess that the six double presses are the easiest. Followed
by the 6 combos that use the same position on the left and right
halves (e.g. left, [] and up, /\). Followed by the 12
combos that go from dpad to buttons, or buttons to Dpad. Followed
by the 12 that use the same thumb on two different buttons. (6+6+12+12 = 36).

And I hear you about confusing people at first. Maybe some clever
ideas would help? For example, make all the double presses vowels?
That's easy to remember. A E I O U Y, right across the front.
Maybe lay out the rest in alphabetical order. (BCDFGHJ, etc).

Here's another thought. Most people remember the punctuation
characters above the numbers. Maybe reserve a two-button combo to be "shift." Punctuation could be entered by "shift" followed by the number key. e.g. $ = shift + 4

Another thought...Maybe down and x could used differently.
For example:
left and right cursor could be x+left, x+right.
up/down cursor could be x+up, x+down.
Space could be down+x.
Shift could be down+/\
Number mode could be down, down.
Punctuation could be down, up.
Numbers could be:
left + [] /\ O = 1 2 3
up + [] /\ O = 4 5 6
right + [] /\ O = 7 8 9

So say I want a capital letter 'E'. I could still use select to go into full CAPS, but I could also do right - right[keep pressed] - and then down/cross.

Yeah, that sounds good, but I'd be careful about distinguishing between
releasing and not releasing keys. I'd avoid select as much as possible.

And start as a default for <Confirm> - that would also do away with the region confusion for cross and circle for confirm.

Yeah, start feels naturally like return/enter. It's in nearly the same place. I actually found myself unconsciously pressing it after
entering lines in p-sprint!

Thinking about using ssh in the future, we'll want tab, and cursor up/down, too.

One final thought. Maybe after the first press, all the letters that
can't be entered could disappear.

[Arwin]

I've come up with a new idea for this:

Code:
l u r s t o
a!, (-) cde ijk opq uvw
:?; 'ab fgh lmn rst xyz

Code: Select all

1st key             : l   u   r   s   t   o
2nd key: left side : a!, (-) cde ijk opq uvw
2nd key: right side: :?; 'ab fgh lmn rst xyz

means, the letters cdefgh can be accessed through the r key. After having pressed the r key, the first row of letters belongs to the left side of the PSP, the second to the right side.

So, if you want to type g, you know that you have to press the right button first, and then 'up' on the right side for g (the second row is right side

sorry. i don't quite understand it...but i'll wait for you to explain it more.

Yes, I would guess that the six double presses are the easiest. Followed
by the 6 combos that use the same position on the left and right
halves (e.g. left, [] and up, /\). Followed by the 12
combos that go from dpad to buttons, or buttons to Dpad. Followed
by the 12 that use the same thumb on two different buttons. (6+6+12+12 = 36).

And I hear you about confusing people at first. Maybe some clever
ideas would help? For example, make all the double presses vowels?
That's easy to remember. A E I O U Y, right across the front.
Maybe lay out the rest in alphabetical order. (BCDFGHJ, etc).

Yes, but preferably you get the letters E, S, A, I, R, N, T, O in first. They are by far the most common. Then the others, D, L, U, C, M, F, W, Y, G, P, V, K, Q, J, X, Z, in roughly that order.

Here's another thought. Most people remember the punctuation
characters above the numbers. Maybe reserve a two-button combo to be "shift."

Yes, I would probably move towards recreating a real keyboard driver as much as possible I think, for compatibility reasons. Including the option or default setting to mirror keyboard and keyboard languages in this manner.

Yeah, that sounds good, but I'd be careful about distinguishing between releasing and not releasing keys. I'd avoid select as much as possible.

Yes, with the setup I made above I avoid select altogether, but for say a context menu wouldn't be too bad. That is of course up to the controlling application, but I could assing the windows context menu keyvalue to it if Select was pressed through the keyboard driver.

Thinking about using ssh in the future, we'll want tab, and cursor up/down, too.

Tab would be under 'special keys' along with F1-12, Home, End, Insert, Delete, Scroll Lock and so on.

One final thought. Maybe after the first press, all the letters that
can't be entered could disappear.

Yes, that could be an option. But I'm going to split the code in that regard. The keyboard driver will not include any help, but will allow a controlling application to do so. Or something like that - maybe a separate .h file for the onscreen help that people can customise or replace.

Also, people could print-out a reference card, so they can run ported applications that involve typing (like, say, ssh) without onscreen feedback at all.

[shifty]

Ah, now i get it. Maybe you could draw it like so:

Code: Select all

l : abc def
u : ghi jkl
r : mno pqr
[]: stu vwx
/\: yz

...and just because i don't want to sleep, let's consider
an efficient layout, the most valuable six: ESAIRN

Code: Select all

l : e.. ...
u : .s. ...
r : ..a ...
[]: ... i..
/\: ... .r.
O : ... ..n

Adding the next most important six : TODLUC

Code: Select all

l : e.. t..
u : .s. .o.
r : ..a ..d
[]: l.. i..
/\: .u. .r.
O : ..c ..n

Now, blanking out for a minute the 12 worst combos:

Code: Select all

l : e   t..
u :  s  .o.
r :   a ..d
[]: l.. i  
/\: .u.  r 
O : ..c   n

We have 12 of 26 letters assigned...perhaps we can
assign the remaining 14 in an intelligent way? e.g. we
know that h often follows t. Maybe we could make it easy to
enter "th" ? Or possibly we can fill in the letters so it's
easy to remember each row?

Code: Select all

remaining 14:
H, B, M, F, W, Y, G, P, V, K, Q, J, X, Z

re order:
B F G H J K M P Q V W X Y Z

pair off:
B F    G H    J K    M P    Q V    W X    Y Z

add next six pairs:

Code: Select all

l : e   tbf
u :  s  goh
r :   a jkd
[]: lmp i  
/\: quv  r 
O : wxc   n

fill in Y, Z

Code: Select all

l : eyz tbf
u :  s  goh
r :   a jkd
[]: lmp i  
/\: quv  r 
O : wxc   n

I'm trying to enter things now (with my PSP off), and I'm noticing
that it's harder to locate letters that start with the right hand. Maybe
a different layout:

Code: Select all

l : eyz tbf  []: lmp i    
u :  s  goh  /\: quv  r   
r :   a jkd  O : wxc   n  

here's something even more radical:

Code: Select all

l : e y z t  b  f
u :   s   g  o  h
r :   a   j  k  d
[]: l m p i  
/\: q u v    r 
O : w x c       n
    l u r [] /\ O

weirder still:

Code: Select all

               f
              b h
             t o d
            z g k
           y   j
          e s a i r n
         l   a p     O
          u   m v   /\
           r l u c []
           [] q x r
            /\ w u 
              O  l

but inspiring...perhaps a "speed grid" could be made
of 3x3. In this system, one diagonal is l, u, r and the
other is [], /\, O:

Code: Select all

  a
 b c
d e f
 g h
  i

Maybe better understood like this:

Code: Select all

l:  a  b  c
u:  d  e  f
r:  g  h  i
    [] /\ O

That's only 9 characters, but the next six could be
the repeat keys ( uu, ll, rr, etc)

Or perhaps two 3x3 grids could be used, followed by the
repeat keys. 9+9+6 = 24. e.g.:

Code: Select all

 v k w z x j

  e      d  
 s a    u g
i r n  p m h
 t o    b y
  l      f 

More generically:

Code: Select all

 . . . . . .

  .      .  
 . .    . .
. . .  . . .
 . .    . .
  .      . 

Maybe a different rendering, parallelograms:

Code: Select all

  . . .  . . .

. . .      . . .
 . . .    . . .
  . . .  . . .

Fill in the most important:

Code: Select all

  . . .  . . .

e . .      . . n
 . s .    . r .
  . . a  i . .

maybe it would be better to use the buttons like this? The
advantage is you can make grids.

Code: Select all

 u      /\
l r    [] .
 .      X
 

Code: Select all

. . . /\
. . . []
. . . X
l u r

Code: Select all

. . . /\
. e . []
. . . X
l u r

alright, i'm too tired now.








Maybe a more efficient layout would put the left/right repeats like this:

[Arwin]

:D

Right after I've assigned all possible combinations keycodes, I'll try to make a configuration option so you can experiment with different setups. Once I've setup the keyid-keycode-keychar chain, it should be really easy to configure.

The advantage of the current one is that it seems to be the one easiest to remember by heart (which I feel is relatively important considering that you would use it often in circumstances where you don't have on-screen assistence - eg. a ssh implementation or other keyboard dependent direct port to the ps2), at least initially. But I think there's a lot to be won by making the easiest typeable characters the most used ones. I already notice that the current layout works better with typing the Dutch language, for instance, because a number of keys that often go together turn out well on this ... (the Dutch form of '-ly' is '-lijk' ... try it out and you'll see).

Anyway, I'm off coding. I've already been off the frontpage of pspupdates too long :D (just kidding).

[Arwin]

Well, I stole some hours from the night and then I decided to take a day off from work, and after a lot of hard labour, I managed to completely rewrite the code the way I wanted it to. This means that I now have given all valid 2 button keycombos plus a select number of single keys each their own unique keyid, that combined with 3 group/shiftcodes provide enough keys to cover the full 102 keys of a standard keyboard.

These are then mapped to proper, standardised keycodes. Combined with a modifier code (control, alt or shift), that in turn produces a character value.

Also really nice is that now I've got real shift button functionality: say that the letter 's' is the combination square, square. To get the capital letter 'S', you press square, and while keeping square pressed, you press the 'up' button. Then you release both, and type square again to produce a capital 'S'. The shift button even has a left and right shift, where you can use 'triangle' as the right shift button. This works out really well. Similarly you have mappings for the control (left/square) and alt buttons (right/circle).

While I am mapping the keycodes and keychars, I have also redesigned the layout to make the easiest button combos connected to the most used letters in English. It really makes a big difference for typing speed. I drew a graphic to be able to read the letters easily and that works quite well too, so I'll be making a digital version of that soon.

Once I've mapped all 102 keys and standard character set, I'll release version 0.40a.

[Arwin]

Here's a preview with source, in case you're interested in where this is going ... it's not nearly finished, I hope to be able to release a version that contains at least the functionality of the previous version again ...

If I were a website, I would not post a newsitem on this - it's developers only really. But everything works now, it's just a matter of filling in the rest of the keys.

http://www.niwra.nl/psp/p-sprint-c/p-sprint40a.rar

[Arwin]

version 0.41a
- made the onscreen feedback dynamic: it will show the mapped keyvalues, so there's less maintenance. (But it will become a problem for showing system value codes, will have to look for something for that.)
- also made the onscreen feedback dynamic for not only group selections, but also shift(and control, alt) actions - if you make a shift combination, you'll see the button values available through that shift-combo (though you see al shift values, not just for the group you selected)

version 0.40a
- more or less completely rewrote the whole program to make the setup keycode and keychar value compatible. What this means is that the current code can easily be used to port existing, keyboard using/requiring software to the PSP by simply hooking up the p_spGetChar and/or p_spGetKeyCode functions. The code and codekey assignments should now almost be fully compatible with existing real keyboards.
- while rewriting the code and mapping, I also remapped the alphanumeric keys for easier typing. The most used keys will now typically be easiest to type, and I've also grouped keys according to how they occur together.
- added shift simulation; while you keep the first button pressed, press up. Then let both buttons go, and press the second button, and you will get a shift (e.g. 'E' instead of 'e'). Alt and control is implemented the same way (with left and right), but currently no data is loaded - though of course you can edit the source to get this done, but I'll work on it later this weekend or early next week.
- added key group selection through button combo. Currently only one group selection (only containing the numbers, including their shift values) is available, by holding left and pressing cross. The other two groups (up and cross, and right and cross) are implemented but don't hold any buttons yet. Capacity is 114 buttons currently, so more than enough to simulate a full 102 key keyboard (with some browser buttons)

see first post for latest download

[reakt]

I've now made the transition of a PC Prototype to a real PSP application, of which you can find the latest version here:

http://www.niwra.nl/psp/p-sprint-c/p-sprint41a.rar (371kb)

(See version.txt in the rar file for details)

I'm very interested in this project. The prototype's coming on. However, when I press the select button I can't see the numbers - a character is printed instead (looks a bit like a backwards 'L'). I tested version 0.41a on my PSP with 1.5 US firmware.

Some interesting observations, not in readme file:
* Start key inserts a newline (good!).
* Pressing circle then triangle in very quick succession causes the key prompts at the top to change. (Is this intentional?)

Some suggestions for changes:
* When deleting a newline - the cursor goes to right hand side of screen and the user has to delete many "invisible" characters to get to the beginning of the previous line. I think if there are no characters on the new line apart from the \n character itself then the whole line should be deleted.
* It would be useful if one could hold down the backspace key and have multiple characters deleted rather than one at a time. I've no idea how to implement this though. Same for space key.

Perhaps you've also spotted these things. It's just an early prototype I know. Great work so far.

[Arwin]

I'm very interested in this project. The prototype's coming on. However, when I press the select button I can't see the numbers - a character is printed instead (looks a bit like a backwards 'L'). I tested version 0.41a on my PSP with 1.5 US firmware.

Correct - I've changed the function of the select button. Select is now 'esc', to partner with start for enter. Not that 'esc' does anything at the moment, but that's the keycode it gives, for now.

Some interesting observations, not in readme file:
* Start key inserts a newline (good!).
* Pressing circle then triangle in very quick succession causes the key prompts at the top to change. (Is this intentional?)

It is intentional. What you're looking at is the dynamic 'shift' option. It is in fact in the version.txt, but what happens is this:

normally, you get 't' by pressing square, then triangle. Now, if you press square, and keep square pressed while you press up (or triangle, mimicking left and right shift respectively), you activate shift. If you lett these keys go and then press triangle, you get a shift-s, which is (obviously) the capital letter 'S'. Pressing the Shift button also shows you which keys are now available, which is what you saw happening. The same goes for control (left/square) and alt (right/circle). But I haven't mapped anything to the alt or control keys yet.

Some suggestions for changes:
* When deleting a newline - the cursor goes to right hand side of screen and the user has to delete many "invisible" characters to get to the beginning of the previous line. I think if there are no characters on the new line apart from the \n character itself then the whole line should be deleted.

Yeah, that was all just quick and dirty stuff, only there really to test. If the work for the keyset is done, I'm thinking I'll either work it out to a half-decent text editor, or I'll just port an existing one. No idea how hard it would be, but I would prefer doing that, especially something which has font support. The Pixie engine would be really nice to have for something like that. Alternatively, something Microwindowsy would also really help. Integrating my keyboard setup with Microwindows should also make for a very good project.

* It would be useful if one could hold down the backspace key and have multiple characters deleted rather than one at a time. I've no idea how to implement this though. Same for space key.

Yes, keyrepeat (which was sometimes there by accident already) is going to be a feature in a future version.

Perhaps you've also spotted these things. It's just an early prototype I know. Great work so far.

I really appreciate your comments. As I said, you're not really looking at a text editor, but more as a test environment for the keyboard simulation software. But obviously, there is no better test environment for a keyboard simulation than a text editor. ;)

High up on the list of things I want to do though is make a typing tutor for the keyboard method, including a few speed tests and games. That could be really fun and really helpful for making people comfortable with the method. I'll certainly be adding a lot of things to make it more user friendly, as the current way of looking up the right key-combination doesn't work - I already have a much better graphic for that now, which I'll digitise and put up soon.

Again, thanks for your input.

[Arwin]

Adding in all the keys, changing the test layout key feedback, added keyrepeat and setting up documentation. I'm adding the documentation up there now in the first post, a new version that has implemented all the new keys will follow shortly.

[Arwin]

version 0.50a
- setup all keycodes and character values for 102-key PC keyboard compatibility.
- added documentation for the mapped keys and their values (see http://www.niwra.nl/psp/p-sprint-c/doc/index.htm for the latest version)
- added proper key-repeat functionality
- wrote a getKey function with a structure interface for getting all the key info you need (keychar, keycode and modifiers - see also the documentation)
- commented the code and cleaned it up a bit

- fixed a few bugs with the p-sprint testscreen interface
- reordered the button feedback in the p-sprint testscreen (will have to be written more fundamentally as this doesn't show keys like Insert, Delete, F1-F12, and so on. See also the documentation.)

[cwbowron]

I've been looking into some of the code for p-sprint, and I thought I might share a couple ideas on how to make it more maintainable and modifiable and cut down code size. Feel free to ignore.

There are many places where you have lots of lines of code that really the same, something like

Code: Select all

	KeyCodes[3][0]=98;
	KeyCodes[4][0]=121;
	KeyCodes[5][0]=103;
	KeyCodes[6][0]=219;
	KeyCodes[7][0]=222;
	KeyCodes[8][0]=188;

	...

It might be more maintainable if you set up a couple quick data structures and just did this:

Code: Select all

	
struct {
	    int code;
	    int modifier;
	    int value;
	} key_codes[] =
	{
	    {3,0,98},
	    {4,0,121},
	    ...
	};

	for &#40;i=0;i<sizeof&#40;key_codes&#41;/sizeof&#40;key_codes&#91;0&#93;&#41;;i++&#41;
	&#123;
	    KeyCodes&#91;key_codes&#91;i&#93;.code&#93;&#91;key_codes&#91;i&#93;.modifier&#93; =
		key_codes&#91;i&#93;.value;
	&#125;
	

You could also do something similar with the DrawLower function (I see you mention that you are going to clean that up later) you could do something with structure like:

Code: Select all

struct {
    int x;
    int y;
    int color;
    int key_code_index;
} char_maps[] = { ... } ;

and initialize it with all the values, then loop over it print it out...

[Arwin]

I've been looking into some of the code for p-sprint, and I thought I might share a couple ideas on how to make it more maintainable and modifiable and cut down code size.

[...]

and initialize it with all the values, then loop over it print it out...

Thanks, that looks very nice. So, it shows I'm a complete C noob then, eh? :D This is my first project in C and my first project on the PSP, and I started coding the Sunday before last ... still have a lot to learn! Lots of firsts going on here all the time you know? For instance, the last version contains my first successful attempt at passing a structure to a function. :D

So your tips are very welcome. I do intend to allow you to read the keyboard configuration from a file, but I think I will leave a basic configuration in there by default, so then nicer looking code is definitely a boon.

[Arwin]

Experimented with some graphical keymaps, which I added to the documentation. Note that they don't cover all the key combinations/positions, just the 28 basic (easiest) ones per group.

EDIT: images removed to keep the page loading swiftly for all

[Arwin]

I also realise that I should probably write a keyread routine that reads keys in a non-blocking manner, so that an application can check for a key without ending up having to really wait for it and therefore halt the rest of the program.

Am I right, coders? I think I saw something like this in the quick hack for the MicroWindows keyboard driver code.

[cwbowron]

I also realise that I should probably write a keyread routine that reads keys in a non-blocking manner, so that an application can check for a key without ending up having to really wait for it and therefore halt the rest of the program.

Am I right, coders? I think I saw something like this in the quick hack for the MicroWindows keyboard driver code.

Yes, that would be necessary for many applications.

If you look at the way I implemented my OSK for pspChess, I have really 3 application level interfaces to the OSK.

one function that draws the osk layout for the user in its current state, one that processes an osk key press (changes the state, processes the keypress as characters when necessary) and one that reads an entire string.

I did it this way because I needed to be able to do network processing in between key presses. My approach is really more string oriented than the keyboard level driver type approach you are going for though.

[Arwin]

Ok, then (let me think out loud a bit here) I need a few things:

1. read controller
2. store controller buttoninput into a buffer (global variable)
3. parse the current and previous buffer for key or event changes
4. return the current key structure (with modifier, keycode and keychar data)
5. add an extention to the current key structure that indicates the following information a p-sprint parent application might need such as:

- selected keygroup (1-3, or 1-6 if I add the custom buffers)
- shift event (shift, control or alt, or a combination of those once I've implemented that)

The readKey function will return 1 if a key has been found and fill the parameter struct p_spKey with relevant data, or return 0 if no key was found.

Did I miss anything?

[27Bstroke6]

After looking at those diagrams, it becomes more obvious why Sony decided to stick with the crude (but ubiquitous) telephone keypad input system.

[Arwin]

After looking at those diagrams, it becomes more obvious why Sony decided to stick with the crude (but ubiquitous) telephone keypad input system.

Yeah, well, they didn't have very high demands for it obviously... :)

version 0.51a
- added a non-blocking readKey function with a new structure that contains information on which group is selected, which modifiers were pressed, and so on, all at the right time. The p-sprint testscreen uses the function to display a proper blinking cursor. I spent a few hours on getting the key-repeat to work properly, but I couldn't manage it and the night's almost up, so have to get back to that later. But this is a significant step for other coders, so I'm releasing this early version for testing and development.

Getting a key from p-sprint is a lot like reading the controller now, with a comparable, non-blocking structure setup.

It would be fun to see if it were difficult to integrate this function into MicroWindows or something similar now.

Once I get the keyrepeat working I can rewrite the p_spGetChar and p_spGetKey functions calling the readKey functions in a loop, and wrap the whole thing up in a nice header file.

[Arwin]

Had an idea for icons that you can use to indicate p-sprint's button combinations (only really 36 after) all and applied them to a picture of a keyboard:

[Arwin]

EDIT: Never mind, I got it working already on my own.

http://www.niwra.nl/psp/p-sprint-c/p-sp ... nclude.rar

A.

[Arwin]

Success! The p-sprint include files now work! Yay me! The readkey function works according to spec, and its keychar cousin seems to also, so the rest probably works too.

See first post for the latest download, which now has a separate link to the include package (which is ... smaller ;) )

Regards,
Arwin

EDIT: I also added a package with symbol graphics that you can use to overlay on your own OSKs or use to indicate which button press goes with which function, like I did above. This is the 24pixels version, I'll post the 12pixel version later

24 pixel samples:

[Arwin]

First post updated.

The include version of p-sprint now updated to version 0.53a, with key repeat back in business. Also added a (public) function to customise the key-repeat rate and threshhold.

I think this include version will go from version 0.53a to a version 1.0 soon, but first I would like to hear from others if they think it is up to spec or if they need more.

Things on my to do list:

- provide an additional library that makes text input even easier to integrate (like a default entry window)
- make a snazzy user interface
- make or cooperate or port a text editor using p-sprint
- make a training/typing game using p-sprint

[Arwin]

version 0.60a
- added p_spReadKeyEx(struct p_sp_Key myKey, int Buttons).

Comment: This function makes integrating p-sprint with your current applications easier. Say that you have a cursor implemented using the analog stick. You can now handle any of the controller's input yourself, but if it contains button input that you want p-sprint to look at for key presses, you simply pass the Buttons value to p_spReadKeyEx and look at the p_sp_Key structure to see if that resulted in anything interesting. See documentation for an example.

- added support for OS key (e.g. Apple/Win key).

Comment: Hold first button and press 'X' or 'Down', release both, and then press the second button.

- shift keys now combine properly in Key.modifiers

Comment: this means that for instance ctrl-shift-a is possible, as well as ctrl-alt-delete. ;) Ctrl-shift-a would be: hold triangle, press square, press triangle, release all, press circle.

- rewrote version.txt to apply only to the p_sprint.h and p_sprint.c files.

[Arwin]

keyboard simulation includes:

version 0.62a
- added p_spGetKeycodeFriendlyName(int keyCode, char keyName[])

Comment: this gives you the name of the key, if it is a key that has a special name and no character representation (like F1, Home, Shift, and so on)

- fixed a number of faulty keyid/code/char links that I discovered while rewriting the testscreen

keyboard simulation test screen:

version 0.62a

Rewrote the p-sprint test-screen using the include version of p-sprint. The new setup gives feedback on your group selection, shift modifications, and keynames (e.g. if you press the combination for F1, you'll see F1 in the bottom left of the screen).

Typing includes basic interpretation of the regular keys, space, backspace and enter.

The screen is a lot sparser now than the original version, and the default keymaps aren't displayed on screen. If you're completely new to p-sprint, just go ahead and test combining different button presses and see what you get. Also, you can look on the keyboard image in the forum thread that has the p-sprint combinations included.

Once I learn how to blit an image to the screen, I'll add images like that in a help screen.

[Arwin]

Just a tiny little experimental tool for quick translations of real text to psp keypresses, for those who need only a few things like 'dir' in dosbox:

http://www.niwra.nl/psp/p-sprint-c/doc/translate.htm

Example:

dir /w

[Arwin]

I wrote this as support for including p_sprint in basilisk, which can be useful for other users too, so I post it here as well.

http://www.niwra.nl/psp/p-sprint-c/p_sp ... ctions.cpp

[seventoes]

Its sad that noone is replying to this topic :(:(:(

This is a really awsome input method, and arwin has been replying to himself here :(

Ill be using P-sprint in my Cry_Wolf game soon, and ive found it very easy to impliment

(this is a bump)

[Arwin]

Thanks Seventytoes ...

It's not that bad though - it has been implemented in Dosbox, in an early organizer app, and now in Basilisk. The problem is, really, that people either don't see how serious typing could work properly on the PSP without a real keyboard, or they simply don't need it. And finally, it has a comparatively steep learning curve.

But once someone does want to do serious typing on the PSP without a keyboard, p-sprint is a good and efficient approach. I really, really wish it were included into CaSTaway, or the PSP Organiser.