ISO Driver

Introduction

ARK-4 does not require any form of ISO Driver configuration, there are only two ISO Drivers available (Inferno 2 and Sony's NP9660) which the CFW will automatically choose from depending on the format used.

There are largely three types of formats: PBP, ISO and CSO, plus many alternatives/derivatives of CSO.

For the PBP format, which is the Official Sony Format, the Original Sony NP9660 driver is used. For all other unofficial formats, Inferno 2 is used.

The Inferno 2 ISO driver is an evolution of the Inferno Driver found, among others, in the PRO CFW, for which ARK itself is an evolution of.

Evolution of Inferno ISO Driver

Before ARK-4, several different versions of the Inferno driver were created for different purposes, lets look at all of them, and try to add a versioning system to them, so we can have an idea of the evolution of this driver. We will start with PRO-C, which we will call Inferno 1.

• Inferno 1: the original Inferno driver as seen in PRO-C. It includes the block offset cache speedup hack that greatly improved speed with CSO format in comparison to traditional drivers such as M33 Driver. It also included an overall cache that could use the extra RAM on PSP slims to improve speed, this is knwon as Inferno Cache, though it had conflicts with the Force Extra RAM patch.
• Inferno 1V: the original Inferno driver port for PROVITA, used up to ARK-3. It was a stripped down version of the one in PRO-C, minus the Inferno Cache since the Vita lacked the PSP Slim's extra RAM.
• Inferno 1S: an experimental Inferno 1V fork that added support for Splitted ISO files (SSO), it was meant to improve the experience of transfering ISO files via FTP, it was scrapped and never used but source code can still be found in the original ARK-1 repository under the name inferno.new.
• Inferno 1D: a port of Inferno 1 to the ME CFW with added support for the DAX file format. It uses two separate algorithms to handle CSO and DAX.
• Inferno 1.5: available in PRO-C2, 1.5 is one of the greatest updates to a PSP ISO Driver ever made in regards to Compressed ISO reading speed. Thanks to the research of developer Codestation, we were able to figure out a new speedup hack that proved to be the biggest one yet. It uses the fact that whenever a game requests data, the compressed data is always going to be smaller than the requested data, thus the buffer given by the game can be used to read all the compressed data at once and process each block in place, thus hugely reducing the amount of IO calls to satisfy the data request (which for an ISO is only one IO call), to put it in technical forms, the algorithm went from having a linear O(n) complexity (where n = amount of IO calls) to having the same constant O(1) complexity as an ISO. During this research, Codestation also developed a lightweight version of CSO called ZSO, which is structurally identical to a CSO file but data is compressed using the LZ4 instead of the standard DEFLATE algorithm, which offers the fastest decompression speed available, while being identical to CSO in its structure allowed the same algorithm to be used for both formats.
• Inferno 1.5V: a stripped down version of the newly updated Inferno 1.5 ported over to Adrenaline. It gets rid of Inferno Cache as it was considered unnecessary on PS Vita, and also removes support for ZSO format, while maintaining the speedup hacks for CSO.

Now that we've covered the evolution of the Inferno Driver over the years, we can focus on all the changes done to it in ARK-4 that justifies it being called Inferno 2.

• Dynamic Patching: all static offset patching done to the isofs library has been replaced with dynamic patching algorithms. This makes Inferno capable of working on a wide variety of configurations, including the original PSP, unmodified PS Vita Emulator, Adrenaline-patched PS Vita Emulator and PSP Toolkits such as testkits and devkits.
• Emulation of Empty UMD Drive: on older versions of Inferno, as well as other ISO Drivers, it was never intended for the driver to run without an ISO file to be mounted, thus several bugs existed that caused malfunction when the driver was used without an ISO file specified, this prevented emulation of an empty UMD drive, which was needed on PS Vita to run certain homebrew that checked for a UMD. The main bug was in the implementation of the function sceUmdCheckMedium, a boolean function used to check if a UMD is inserted in the drive, on ISO driver this function was hardcoded to always return true, except if an ISO driver is not specified, then it was hardcoded to wait in an infinite loop until one is (which never happens). The solution used by eCFW such as ARK (up to ARK-3) and TN-CEF (including Adrenaline) was to include a small dummy fake.cso file to mount when no ISO file is speficied. On the new Inferno 2 driver, among other things, this function has been corrected to behave exactly like the original, simply returning False if no ISO has been specified, thus allowing the ISO driver to simulate an empty UMD drive by loading it without an ISO file specified.
• Completely revamped Compressed ISO Reader: the CSO driver available with the original Inferno was heavily hardcoded to work only with CSO and only with the PSP. The entire reader was completely re-written from scratch with much much less and lighter code, much more portability (it has been ported to PC, PS2/OPL and Wii/Nintendont) as well as a much more generic and configurable structure, allowing for easily adding support for other formats without changing the core reader.
• Improved Compressed ISO Read Speeds: not only is the algorithm written with efficiency in mind, it also implements a more aggressive form of the speedup hacks seen on Inferno 1.5.
• Support for other compressed formats: the new reader was also made to be easily configurable and expandable to support other formats, having been given support for not only CSO and ZSO as seen on Inferno 1.5, but also adds support for DAX as seen on ME's Inferno update as well as early SE/OE CFW, as well as the rarely seen before JSO and CSOv2 formats. The driver also supports different block sizes, with 2K and 8K being more common (the higher the block size, the better the compression, but also the more memory used by the driver and thus less available for plugins). All formats benefit equally of the speedup hacks, meaning that performance is mainly left on the decompression algorithm they use.
• Improved Inferno Cache compatibility: issues between Inferno Cache and Force Extra RAM has been resolved, including being able to use it with PRO Online, as well as allowing the use of Inferno Cache on PS Vita and PSP 1K. The Cache size is no longer configurable, but it adjusts automatically depending on device/configuration, while also allowing for enough free space for other features or plugins.

Compressed ISO Formats

Regarding Compressed ISO formats, the new algorithm is the same for all of them, and the same speedup hacks apply, meaning that whichever format you want to use will depend on the compression algorithm of the format itself. The rule of thumb here is that the faster the algorithm, the less compressed data is, while higher compression algorithm offer worst performance.

The Following table shows each format in relation to compression, speed and other variables, along with commentary.

Format and Author	Specs	Compression Ratio vs Decompression Speed	Comments
CSO by Booster	Supported Algorithm: DEFLATE Supported Block Size: Any (2K is Standard)	Great compression size, Slow decompression speed	Uses same de/compression algorithm as DAX, but a lighter structure. While it supported any block size, the standard was 2K (it was also the only size allowed by compression tools, including the official one) in contrast to DAX's 8K. Traditionally this meant DAX was faster as it had to process less blocks than CSO, but this is no longer true with the new reader, thus they both perform the same regardless of block size. However this also means that standard 2K CSO is bigger than DAX, but CSO compressed using the same 8K block size as DAX actually produces a smaller image. Meaning that an 8K CSO is supperior to DAX in every way (this could be the reason DAX himself dropped support for DAX in favor of CSO, though the M33 driver never supported anything other than 2K CSO).
DAX by Dark_Alex	Supported Algorithm: DEFLATE Supported Block Size: 8K Only	Great compression size, Slow decompression speed	A competing format of CSO, it uses a slightly different structure though the compression algorithm is the same. The original version did not allow for Non-Compressed sectors, a feature added on Version 1, though in a complicated and inefficient way. Though the format used to be faster than CSO, this was merely due to unoptimized IO access in the older drivers. Eventually support for the format was dropped with the M33 CFW.
JSO by Uncle Jam	Supported Algorithm: LZO or DEFLATE Supported Block Size: Any	Average compression size, Fast decompression speed	This format was created long ago as a response to the slow nature of unoptimized cso/dax readers of the time and combined technical aspects of both CSO and DAX while also adding its own unique features. It attempted to improve speed by adding support for LZO de/compression format, however this had relatively bad results since the main issue with speed on those old drivers was the heavily unoptimized IO calls. It supported either LZO or DEFLATE, but both couldn't be used at the same time on a single file.
ZSO by Codestation	Supported Algorithm: LZ4 Supported Block Size: Any (2K is Standard)	Worst compression size, Fastest decompression speed	This format was created as another late attempt at improving compressed ISO speeds, this time using the incredibly fast LZ4 de/compression algorithm. It was soon after discovered that it wasn't just the compression algorithm that affected the speed of CSO, but the main bottleneck was in the incredibly huge amount of IO calls being done for every single data request by the game (as opposed to a single IO call per data request on ISO). This meant that now standard CSO performs well enough for most cases.
CSOv2 by UnknownBrackets	Supported Algorithm: LZ4 and DEFLATE Supported Block Size: Any (8K is Standard)	Good compression size, Good decompression speed	An attempt at combining the good compression ratio of CSO with the great decompression speed of ZSO, it also has some technical aspects from JSO (such as multiple algorithm support and detection of non-compressed blocks). In this format each block is compressed with either algorithm, meaning that both algorithms are used at the same time throught the file.

Format War

Format wars aren't a thing exclusive to the movie industry, and Sony is certainly no stranger to them, though they had nothing to do with this one (at least initially, they did end up making their own PBP format for PSN releases).

Back when the first ISO drivers showed up on the console, memory sticks weren't bigger than 2GB, which necessitated the implementation of a space-saving mechanism in the form of a compression format for ISO files.

Compressing an ISO into a ZIP file would not be enough, as you can't do random-access on ZIP files, you have to decompress the entire file before you can use it. This works for classic retro console roms as they are small enough that the entire file can be loaded into RAM, but for a UMD that can reach up to 1.8GB, this was not going to cut it.

It was then that two formats appeared: Booster's CSO and Dark_Alex's DAX formats. On these formats, compression is done on a per-sector (or per-block) basis, rather than the entire file, allowing for random access directly on the compressed file. The only downside is that compressing small chunks instead of the whole file will always be detrimental to compression ratio, in this case, even though CSO and DAX use the same compression algorithm as ZIP, an ISO compressed into a ZIP file will have slightly better compression. Though this wasn't too bad and compression ratio was pretty good anyways, specially with games that used lots of uncompressed data and dummy files (pretty common in optical media).

Each format had their own benefit, with DAX considered to be overall faster and having better compression, but CSO being much simpler and more powerful (in a great moment of "forward thinking", CSO could actually work on DVD and Bluray ISOs, while DAX was limited to UMD and Mini-DVD). Also, while the CSO format was standardized to having 2K blocks, it was meant to use any block size, meaning if they had gone with 8K blocks as DAX had done, then CSO would have been as fast as DAX while being even more compressed (due to being an overall more space-efficient format).

A little bit after the creation of CSO and DAX, a third competitor named JSO entered the scene. Developed by Uncle Jam, the format was aiming at using a faster decompression algorithm, LZO in this case, to improve the speed of the format. This never took off however and the format never gained much popularity, even though many PC apps at the time would fully support converting to and from this format. The reason for its failure main have been related to the unoptimized usage of I/O present in drivers of the era, rendering the speedup gained with the faster decompression function relatively unnoticeable. Though the format has seen a ressurection with ARK-4's optimized Inferno 2 driver as it offers the best tradeoff between speed and compression ratio.

Most ISO Drivers (i.e. SE and OE) for a while would implement support for both formats, though eventually Dark_Alex (the most famous PSP CFW developer of all time) would drop support for his own DAX format when the M33 CFW was created.

Because DAX offered faster speeds and better compression than standard CSO files, even though it went unsupported the format went on to gain a sort of niche following and an aura of being the "superior even if not popular format", pretty similar to what happened to Betamax. Interestingly enough, the speed differences between DAX and CSO related to the block size all goes away with a properly I/O optimized driver, and a CSO file created using 8K blocks will provide better compression ratio than DAX.

Fast forward to the end of the PRO era and a new fourth format arrives in the scene. Created by Codestation, the ZSO format uses the same exact binary structure of a CSO, with the difference of using the much faster LZ4 algorithm to handle compression. The LZ4 algorithm is the fastest algorithm available, though the speed is traded off with compression ratio, having the worst among the different formats. The format however reached the same dead end that JSO had found in the day: the bottleneck and main issue that slows down CSO is not the compression algorithm, but the huge amount of I/O calls being issued when reading any compressed format. Once this bottleneck was aliviated, the original CSO format became much faster to use and therefore most people decided to stick with it instead of migrating to ZSO. Where ZSO did find more success was in the PSP's sister bigger console, the PS2.

Which algorithm to use nowadays largely depends on the use-case. If speed is your priority then ZSO and JSO are good options, while for space saving you can use CSO or DAX. The format can also depend on the game, with more intensive games benefiting more from faster decompression (such as ZSO with GTA games), while with other games the slower decompression only results in a bit more loading times but no difference in gameplay and thus CSO/DAX works fine (such as the case of Minis).