I'd like to write a little app to allow a PSP to be used as a "wireless display/terminal". I've already developed a suitable framework for the PocketPC platform and would like to try for a common framework that I could extend to things like PSP's, small tablets, smart phones (e.g., winmobile), etc.
Any pointers to SDK's, etc.? The hits that come back from search engines seem to be more oriented towards game rips or custom firmware (i.e., *somewhere* there has to be a codebase that they use!). I suspect the population of PSP developers is probably pretty small ??
The official SDK is available only after you become a licensed developer.
I think there's a Linux port for the PSP out there somewhere too, if you don't mind rooting the device.
IMO, stick to smartphones and tables. Android in particular makes this sort of thing easy (actually it's not so bad with MS either, but it's not like there are tons of devices running WP8). And while developing stuff to run on iOS is not hard (most of the tools are pretty close to freely accessible), once you have an app, you can really only get it to users' devices via Apple's app store (there are provisions for getting development code onto the devices, of course, but it strictly enough controlled that it's basically not practical for anyone outside the development team and perhaps a few beta testers).
WP8 (the second page has a link to Visual Studio Express 2012 for Windows Phone)
(watch the ends of the links on the above, my newsreader doesn't like including them in the link)
), with the development environment from ps2dev.org. WiFi was supported, too in my app, including ad-hoc mode. Unfortunately looks like the site is down now, and of course it works only on very old PSPs with the 1.0 firmware, where it was possible to run unsigned programs, or on jailbreaked PSPs. Last time I checked it, the official Sony Devkit was very expensive (5 figures price) and they don't sell it to anyone.
If you are interested in the ps2dev framework, I think somewhere I have an old version of their SVN repository (which was at svn.ps2dev.org, but down, too) and can upload it to my website.
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
I'd have prefered a clean "app" (on a memory stick) as that could leave the device retaining its intended functionality. But, it may be an option. Esp for PSP PHAT's, etc.
How much of the hardware did the port actually support? Folks always like to *claim* they've ported X to Y -- only to discover it's a half-baked solution (e.g., text only, no wireless, no UMD, battery doesn't charge, etc.) Sort of like building a car and neglecting to include little things like STEERING! ;-)
I'll start looking for it. Thx.
I'm not sure I want to play Apple's game. I'm also leary of devices where other cruft (esp from some *public* comm channel) can potentially be an issue. I don't want to have to invest a lot of time trying to understand someone else's security model to ensure can't be created to exploit the system interface that my app represents.
And, I'd ideally like to target things that are relatively inexpensive (e.g., obsolescent) so a user can afford to have 6 or 10 of them. E.g., imagine having one sitting on a table/counter/etc. "within arm's reach" in each room. Phones and tablets tend to get expensive really quick! Tablets are also a bit on the large side even for "little" 7 inch devices (i.e., the PDAs I've been accumulating have a 4" screen; PSP's are only slightly smaller)
Thanks! I'll track each of them down and see what they have to offer.
Cool! My *first* thought (looking at that) was "hey, just write it in lua!". But, that will only work for "controls", etc. E.g., I couldn't write a video codec in lua that would run in anything *near* real time! :-/
Can a user downgrade to *that* far back? I.e., I think most of my PSP's are at 5 or 6.something. Not sure how easily it is to go backwards (forwards being the easiest route, of course; sideways the next easiest). Is there anything to lose (brick?) trying to step that far back?
Let me look around and see what I can find for tools. The important thing is to note that it *is* possible to write code to run on the PSP without knowing the fraternal handshake, etc.
There are number of Android tablets that can be booted from their SD slots. You still need to root a copy of the OS (for the drivers), but you can leave the tablet system intact and put your customized system on a card.
I've used the HomeBrew devkit to develop a native Forth for the Nintendo DS, and I understand (though I have not used) there exists a tool chain, and some development information for the PSP which is not in (or part of) the official repository.
This might be a good staring place for your project:
You could write the performance critical parts in C and the rest in Lua. Much easier than to write anything in C.
I don't know. I stopped after upgrading to firmware 1.5. With firmware
1.0 it was possible to run your own programs in kernel mode, because Sony screwed up the security concept. In kernel mode it was even possible to access the UART (at the headphones connector). With firmware
1.5 Sony fixed it a bit: kernel mode apps are no longer possible, but you can still run your own apps. With later versions it was fixed even more, and no own apps were possible, but there are some custom modified firmware versions.
Looks like it is on github now:
The psptoolchain script is really cool: all you have to do is to checkout the repository, and then the script downloads anything you need for the GCC compiler, it compiles the GCC cross-compiler etc. Last time I tested it (from the original SVN repository) it worked with Cygwin on Windows and on Debian Linux without problems. The GCC compiler was even patched to support some of the special MIPS vector math instructions of the PSP.
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
I was hoping to "write the performance critical parts in C and the rest in Limbo" (under an Inferno VM). This gives me many of the niceties that Inferno makes available for distributed applications without crippling me with Limbo's performance limitations.
To do so, I could either *host* Inferno under some "lean"/efficient environment *or* port it to run on bare metal. Having access to that metal becomes a key part of the problem (i.e., give me a schematic and datasheets for all the devices and I'd be all set)
Yes, I've poked around with various CFW -- but, primarily in the same/original spirit for which they were intended (i.e., games). What I would ideally like is the sources for those CFW... (assuming they hook *all* the hardware and aren't just a thin veneer)
Great! I found some references via Mr Peabody's Way Back Machine.
Argh! I *hate* this sort of build environment! I want to build "off line". I.e., tell me what to download and let me build a development system *without* having it 'net connected.
[The Chumby build system takes the same sort of "we'll do it for you" attitude]
I suppose I can build a disposable machine, let it download everything, and then EXTRACT all those additions from it before scrapping it.
Thx! Looks like I've got my work cut out for me... :-/
That would (probably) be ideal (in terms of preserving the original functionality of the devices). I've, instead, been willing to "settle" for status as an "app" so users could freely switch between "me" and the other uses for their device(s).
The biggest problem with Android *tablets* is size and cost. They're hardly "unobtrusive". And, putting AT LEAST one in each room can get expensive, fast! E.g., we'd realistically need at least 10, here (assuming the "fixed" displays are handled with my current approach).
They're just too large to slip in a pocket and carry around with you -- without being VERY conscious of their presence.
The smaller option is Android based *phones*. But, those are equally expensive and hard to justify *not* being used as PHONES!
Hi Don, I think phones will keep on getting cheaper - not sure how cheap the PSP is though, but I can imagine sub $100 phones with 800x480 and above displays (and I can imagine the market being already ahead of my imagination...). If you can tolerate the android mess (the newer the version the messier, latencies to user action in the range of 0 to a few seconds just to show/hide a window and that sort of modern day mess, heck, if I sell something that dirty I know I'll never get away with it) I think phones are by far your best option. Then you can get them with a GPS each so you will be able to find your way in the house.... :D .
Here, it seems like most smartphones (a "plain phone" won't do) are subsidized by a service subscription (lots of reasons for this -- ALL of them in the vendor's favor! :> ). I'm not sure how robust cheaper phones will actually be. I see PSP's abused pretty severely -- yet keep on working. Not sure a phone could tolerate that same sort of (physical) abuse!
Also, I think there's a lot more (in terms of dollars and cents) in a typical cell phone (radio, GPS) than in a PSP. A PSP is
*just* designed to "play games" -- not be a general purpose computing platform (with telecom capability).
Lastly, I think there is some appeal to "tinkerers" being able to repurpose what might otherwise be considered "junk". Psychologically, think about how you would react to 10 cell phones scattered around your house. "Where's *my* phone? My *real* phone??!"
The biggest appeal to Android is that it *could* make the underlying hardware more readily exposed. OTOH, there seem to be lots of "exceptions" to license terms "requiring" (encouraging) open disclosure of sources:
"Oh, this part of the design isn't really software. This binary object for this subsystem isn't really firmware (wink, wink) so we can just tell you to include it as a binary object in your build and how to push it into the corresponding bit of hardware that relies on it..."
I don't have to come up with a "Solution". Rather, show how different sorts of devices can be repurposed to fit this aspect of my design. Who knows... some new device might come on the scene that is *perfect* for such repurposing! (Teach a man to fish...)
There's already a 7in smartphone available from a Chinese vendor. I think that's far too unwieldy to put to your face [maybe they expect everyone uses a BT headset] but 7in, depending on form factor, I think is kind of the minimum size for a *general* use tablet.
Even used, phones are more expensive than similarly sized tablets.
There are a quite a few "mini" tablets with screens in the 4 to 5 inch range. I don't pay much attention to them, but a quick search on Google turned up a few 4GB with SD slot for under $80 (didn't check new or used). Still may be too steep if you require lots of them.
Real question is whether you can shoehorn your app(s) onto the tiny screen, allowing for failing eyesight, shaking hands, etc., that you like to worry about. The form factor becomes more important with smaller screens: long and narrow is easier to carry or put in your pocket, but if the user needs to read much (not just identify icons), personally I think a more square form is easier to work with.
Dunno. I'm not an "iPad"/tablet user (my Tablet PC's are ~14in diag). But, I'm not looking for a "general use" format. Think, instead, of something like a remote control. E.g., for a TV, it might nominally give you controls for volume +-, channel +-, and mute. (I suspect these are the most commonly used buttons on a TV remote)
If you wanted to do something else -- perhaps *pick* from a set of predefined channels -- the screen would be redrawn to give you that set of "channel selections". Or, one of several (prioritized?) screens of selections. I.e., you are now concerned with picking a channel so there is no need to waste real-estate on PIP controls, forward/reverse program navigation, etc.
If you're listening to a music program, you might, instead, be presented with volume +-, track +-, pause, etc. I.e., you are always making selections from a relatively small, focused set of options. In much the same way that you want menus to be short instead of long lists of every conceivable action/command.
Selections vary with your current/recent actions, location, preferences, etc. So, the system can exploit the limited screen real estate to focus on just those -- requiring you to do something *else* to bring up other possibilities.
E.g., if you're in the bathroom, chances are, you don't want to adjust the irrigation criteria! So, if you happen to have some overwhelming desire to do this (while sitting on The Throne?), you will have to go fish for those controls. But, once presented, they won't have to share the screen with the controls for the surveillance system; or the HVAC system; or...
Makes sense. They have to do more (maintain the radio, camera, etc.). And, I suspect there is some bias in pricing that relates to service plans, etc. (if phones are *too* cheap, then a carrier has less of a "hold" on the subscriber: "It's only a $20 phone. If my new carrier requires me to buy a different model, I'm only walking away from $20!")
Ah, last time I checked, 7" was the bottom of the line. I suspect for exactly the reason you originally cited: minimum size for general use!
My preferred UI modality is earpiece and touchpad. I don't like having to tie up two hands *and* two eyes to interact with . (I suspect most folks have memorized the locations of the "important" buttons on their TV remotes -- so they can use the remote with one hand and without taking their eyes off the screen! The same should be true of *most* interfaces, IMO.)
But, I think most people are nervous in any interaction that doesn't involve their eyes. Even if their eyes should be elsewhere (e.g., on the road ahead!). But, this can also be a deficiency in those interfaces: lack of nonvisual feedback to confirm your actions and/or an ability to easily "undo"/correct actions ("Crap! I didn't want to change channels... I wanted to mute the audio! Now I have to get the previous channel back *and* mute the audio!")
C grumbles at the thought of having something in the ear all day!
It seems (empirically) that a handheld interface can be smaller for a given set of "disabilities". I.e., a user can bring the display to whatever focal distance is best for their eyes (assuming your arms are long enough :>). ET/PT can be compensated by resting the active hand on the edge of the handheld and extending an actuating finger into the active surface. etc.
By contrast, a fixed display/interface (e.g., on a wall) seems like it needs to be larger to get the same sort of "interaction reliability". The wall won't move *with* your hand, etc.
Interface is intended to be terse. Imagine how the exact same interface is mapped onto an aural modality. "Lots of text" read to the user would place a high cognitive load on him/her. Instead, you'd opt for abbreviated representations.
"71 degrees cooling to 68" instead of "The HVAC system is set to cool mode. The current setpoint temperature is 68 degrees but the present indoor temperature is 71 degrees. As a result, the ACbrrr is actively cooling the house at this time. The override is not currently in effect."
"channel 13 at 28%, paused" instead of "The TV is currently tuned to broadcast channel 13. The volume is at 28% and the program material is currently paused"
[exaggerated text examples, of course]
All the extra words that might make a 3rd grade English teacher happy are just extra clutter that the user has to wade through, aurally.
[I believe "aural memory" is significantly different/shallower than "visual memory". I.e., it seems like it takes more effort to remember a long string of words received aurally than the same information presented in a visual form. Though that may just be a personal limitation? I've been exploring other options to convey information aurally -- "sound icons" - in the hope that you can remember a particular *sound* instead of specific words. But, that "lexicon" quickly becomes yet another cognitive challenge! :-/ ]
I just want to talk to the computer and have it understand and answer me intelligently. But I don't think I'll make it to the 23rd century. Even with training, voice recognition still makes too many mistakes, and AI still isn't anywhere close to where it needs to be.
Mostly correct. Palsy is a problem for any touch interface. I have a friend who can't hit a button smaller than about 2 inches square.
It's just as complex visually: the user must at least be able to distinguish the current temp from the set temp (by label, ordering or whatever), and it's helpful to have indication that the system is on and in which direction it's going. Whether indication is given by colors or by symbols, etc. doesn't really matter.
The problem is that words, in general, convey much less information than do pictures. Memory is organized and accessed in terms of "symbols" which are largely independent of the amount of information associated with them. Short term memory can handle only 7 to 10 symbols, regardless of the amount of information associated with the symbols.
E.g., for most people using directory assistance, "7 1 6" would be a string of more or less arbitrary digits. To me, it means "Buffalo" and conveys a whole lot of information - including that its area code is 716 - that the string of digits does not. When I hear a phone number starting with "7 1 6", I immediately substitute "Buffalo" and discard the digits - one symbol for three. Doesn't work with "2 1 6" because that string of digits means nothing to me.
The word "four" is associated (mainly) with a number.
The phrase "four score" is a symbol prefix - ie. it isn't meaningful itself (nobody counts in "scores" any more), but it is associated with one or more symbols that do have meaning. Prefixes create expectations that an associated symbol is intended. We experience surprise if what follows does not correspond to those expectations.
The phrase "Four score and seven" likely is a meaningful symbol to some people, but to me it also is a symbol prefix.
The phrase "Four score and seven years" is a symbol associated with a man, social injustice, a war, a location, the text (at least the first paragraph) of an important speech, and a myriad of other ideas.
The phrase "Four score and seven beers", to those who even recognize its origin in print, is a symbol associated with Jughead (Archie comics) reading aloud in history class. [Contrary to popular belief, many dumb things predate the internet.]
"Four score and seven years". "Four score and seven beers".
Same length (if abstract symbols can be said to have a length). Similar sounding. Very different information content.