1.00 Bogus Firmware

From PSP Developer wiki
Jump to navigation Jump to search

Description

This is an official testbench firmware update that was added to the Network Update servers in early January 2005. Sony did this to perform QA tests of the network update feature before the official 1.50 update launch.


Because people started looking into the update list urls and searched for possible updates, people started guessing possible urls that may be hosting updates (only a dummy update file was hosted on regular servers at the time), one of those update urls had an update list that pointed to a test update in PBP format that was eventually dubbed as the "1.00 Bogus Firmware"

Installing this firmware update, as-is, would cause a brick, Sony Public Relations at the time indicated that servicing these devices would not be covered by the warranty.

There several theories as to why the bricking happened were made, such as the bootloader (IPL) being deleted due to missing a IPL driver in the updater. What actually happened was that the registry/user settings were not downgraded from the Release 1.00 (1.0.3) and the older system software (1.0.0) was not able to read it.

In order to properly install it, you will need to install the system software, and then clear out the registry after booting. You can also utilize the registry patcher application to patch the 1.0.3 registry to have it downgrade to the older settings version.

It can be installed with the 1.0.3 IPL, however sleep mode does not work. According to the SDK changes log, this was fixed in later firmware revisions of 1.0.3 (1.00).

Version Differences from Release 1.0.3

This firmware is known to most as 1.00 "bogus" also known as 1.0.0 bogus, this was a Pre-release 1.00 with some development/debug modules mixed in to specifically assist in the development of VSH modules.

The few modules that were left in for development purposes was 'loadcorei', 'rebooti', and 'dlgsample_plugin'. There are some modules that were modified for development purposes to provide more debug information. Most of the firmware contains kernel messages that would not normally be seen by the typical user.

It does not contain a DECI2P debugging module so its not certain how these messages would be seen, possibly through another active host file system receiving the TTY information.

The firmware uses loadcorei by default to allow plain modules to be loaded during runtime, and 'dlgsample_plugin' was a development sample for the dialog utility. It's uncertain what rebooti.prx did differently than reboot.prx.

The reset combo (Start+Select+Square+Triangle) does not work on 1.0.0, this was implemented later on with 1.0.3.

System Version Information

[ 1.00 Bogus ]

release:1.00:
build:106,1:root@psp-vsh
system:16214,0x00100000:
vsh:2004_1104_s16214_p3883_v8335:


[ 1.00 Release ]

release:1.00:
build:228,0,3,1,0:root@psp-vsh
system:17919@release_103a,0x01000300:
vsh:p4029@special_day1,v9972@special_day1,20041201:

XMB Menu Differences

TODO: Screenshots/sounds.

Due to the early revision of the firmware, there are some major differences with the firmware compared to the launch 1.00. Early assets such as XMB navigation sounds/icons were present in the firmware but later removed or changed around.

Probably the most notable difference is the boot up sound:

XMB Menu Bugs

As with any in-development software, the XMB kernel comes with several bugs that are not found under normal conditions.

  • GAME Category
  1. UMD/MemoryStick Firmware Updates do not work, this is probably due to the startup information from the firmwares updates that contain more information than what the VSH is trying to read.
  2. All EBOOTs show up corrupt, as with the issue from above, this can only be mediated by using the bogus firmware PARAM.SFO since it matches the information that the XMB needs or patch the firmware's game_plugin to allow it to read the new information.
  3. Loading any game/application from the Memory Stick will cause a lower default memory allocation and current working directory error when the system reboots.
  • VIDEO Category
  1. While playing an hour long MPEG4 video from the MemoryStick, the video starts to desync the audio/video. The video starts slowing down but the audio continues to play in a normal speed.
  2. Playing an MPEG4 video, and jumping an hour using the control panel options causes the same symptoms as above. This likely might be due to how the firmware buffers videos rather than seeking from UMD.
  3. (Not really a bug but an interesting development tidbit they left in), You can have multiple video folders under MP_ROOT. Where normally you'd have a 100MNV01 folder, and put in all your MP4 videos, with the bogus firmware, you can have multiple videos named such as 100MNV02, 100MNV03, etc. This would allow you to be able to categorize the videos in some way. They all show up normally under the VIDEO category regardless.
  • MUSIC Category
  1. Minor codec changes were made that cause specific MP3s from showing under [MUSIC].
  • PHOTO Category
  1. If you delete the Digital Cameras folder it will cause the system to lock up immediately after exiting the category.
  2. Loading a large photo causing the viewer to act up, such as zooming into a photo will causing a 200% increase in size.
  • SETTINGS Category
  1. The Network Update servers are different than the release, they're using test dummy servers for the updates.
  2. Daylight Savings does not stay persistent in display. By setting the option to on, and rebooting the firmware will cause the time/date to display without daylight savings. By going to the setting again will cause it to correct itself.
  3. The 'Network Settings' icon does not have an animation when highlighted on, the assets for the shadow/fade does exist but are not being used.
  4. The 'Internet Connection Test' in the 'Network Settings' fails immediately when using a Static IP address, but works when connecting within a game/application.

System Kernel Differences

The firmware is an early revision of the Release 1.00 (1.0.3), containing a mixture of in-development XMB modules as well as some internal debug kernel drivers providing assistance for developing the firmware.

Development Modules

One of the internal kernel modules 'loadcorei.prx' allows plain (user or kernel) modules to be loaded either VSH or kernel. This would allow Sony to keep updating the firmware overtime without needing to encrypt it for every revision. There is a 'loadcore.prx' module in the firmware which is similar to the release 1.0.3 loadcore.

API Differences

There is alot of missing API that is normally called in Release 1.0.3 such as 'sceKernelDevkitVersion', which returns the system software version. This would usually report '0x01000300' on Release 1.00 but in the event it did exist, it would've returned: 0x00100000 (note the position of the numbers.)

There are also some API calls are do not work or are unfinished to some degree, specifically 'sceKernelExitGame' will cause the system to reboot rather than exit to the XMB. This is likely due to how parameters are being passed through the VSH main module.

This is also intentional as the XMB is was not intended to be seen by game developers of the SDK release, as with the later revision '1.0.2 Development Firmware' which shows a balloon SDK sample instead of the VSH. It wasn't until '1.0.3 Firmware' that developers were able to access the System Software menu.

Querying for the total available memory size does not exist yet in the firmware and must be done manually with other kernel functions.

Alot of API calls when in development on the firmware tend to be a kernel mode export. 'sceKernelLoadModuleMs' from modulemgr.prx is a kernel mode export on 1.0.0 but a user-mode export on 1.0.3. As well as sceKernelLoadModuleBufferUsbWlan which is used for loading modules from a Gameshare executable (or at least intended to) as well as a USB-based Gamesharing functionality that was intended later on via PS2.

System Kernel Bugs

  1. When loading a game/application from the Memory Stick will be allocated a very default low memory pool, this is fixed by patching the 'sceSystemMemoryManager' with one from 1.0.3 or specifying a heap size in the development of the application/game.
  2. When loading a game/application from the Memory Stick, the current working directory (CWD) will not be set on boot causing application using the boot parameters to fail. This can be fixed by loading the application again via sceKernelLoadExec. The issue likely lies with the VSH equivalent of sceKernelLoadExec.
  3. When loading a UMD game, no audio will be outputted, this is due to the Media Engine API not being fully developed and causing the ATRAC3 audio to fail. This can be *only* fixed by patching in the 'me_wrapper' from 1.03 into the firmware.
  4. Network Setting Configurations are not indexed properly, where the first network connection is indexed as '-1' not '0'.