Hi all,
I am a total newbie to programming the PSP, but I am a professional embedded programmer and hardware designer (Since in 97). Now one thing I really want to use my PSP for is as a controller to access my multimedia via WLAN, but I do not want to compromise the security on my home WLAN where I run WPA (Personal). I have fooled a bit around with version 2.00 and some of the features I need. I could enable via a web based interface (using the 2.00 browser). However I would much rather have a real application running on my PSP.
So the question is.. Is it feasible to make WPA support for 1.50, are someone working on it? Or is it better to concentrate on getting "real" homebrew up and running on 2.00?
I guess I would prefer the latter, but the only thing I need from 2.00 is the WPA support so either option would work for me..
Regards
Henrik
Homebrew WPA support
> Is it feasible to make WPA support for 1.50
Possibly.
One approach is to figure out the new PSP 2.0 format/encryption, load in the 2.0 modules and cross your fingers they will run on the core 1.50 components (perhaps patching the 1.0/1.50 system a bit)
> Or is it better to concentrate on getting "real" homebrew up and running on 2.00?
That's another separate path. Other people are working on that AFAIK.
I don't know how well the current user mode TIFF hack would work for LAN apps. You have to load a number of PRX files from flash0, and do the initialization (the current 1.0/1.50 WiFi samples need kernel memory access to do their tricks)
Possibly.
One approach is to figure out the new PSP 2.0 format/encryption, load in the 2.0 modules and cross your fingers they will run on the core 1.50 components (perhaps patching the 1.0/1.50 system a bit)
> Or is it better to concentrate on getting "real" homebrew up and running on 2.00?
That's another separate path. Other people are working on that AFAIK.
I don't know how well the current user mode TIFF hack would work for LAN apps. You have to load a number of PRX files from flash0, and do the initialization (the current 1.0/1.50 WiFi samples need kernel memory access to do their tricks)
>> Is it feasible to make WPA support for 1.50 ?
> One approach is to figure out the new PSP 2.0 format/encryption
Done that.
Fortunately it is only a software/firmware change, and existing PSPs can decrypt the new modules.
PSAR Dumper version 2 (see other thread) will let you dump the 2.0 UPDATE PSAR file including decrypting 2.0 PRX files for "fair use" analysis/disassembly/use.
There are plenty of new system entries, and only a few new User mode entries (see other thread)
> load in the 2.0 modules
> cross your fingers they will run on the core 1.50 components
That works too. The problems come due to the dependencies on the new PRX modules on core system models.
For example, the 2.0 WLan components rely on the 2.0 WLanDriver. The WLanDriver needs the 2.0 DMA controller and other 2.0 system components.
Loading additional system components can get in the way of the existing (1.0/1.50 components).
This goes back to the problem of stopping/removing existing components (a bottleneck in using the MPH Firmware Launcher). Some modules can be stopped and replaced, other ones can't.
Perhaps we need a better "reboot" style of restarting the system in a half-1.x half-2.x world?
> One approach is to figure out the new PSP 2.0 format/encryption
Done that.
Fortunately it is only a software/firmware change, and existing PSPs can decrypt the new modules.
PSAR Dumper version 2 (see other thread) will let you dump the 2.0 UPDATE PSAR file including decrypting 2.0 PRX files for "fair use" analysis/disassembly/use.
There are plenty of new system entries, and only a few new User mode entries (see other thread)
> load in the 2.0 modules
> cross your fingers they will run on the core 1.50 components
That works too. The problems come due to the dependencies on the new PRX modules on core system models.
For example, the 2.0 WLan components rely on the 2.0 WLanDriver. The WLanDriver needs the 2.0 DMA controller and other 2.0 system components.
Loading additional system components can get in the way of the existing (1.0/1.50 components).
This goes back to the problem of stopping/removing existing components (a bottleneck in using the MPH Firmware Launcher). Some modules can be stopped and replaced, other ones can't.
Perhaps we need a better "reboot" style of restarting the system in a half-1.x half-2.x world?
