dobiestation
patreon
Technical Insight: The PS2's CDVD Drive and Loading Times
🕑 Added 2021-03-05 01:04:36 +0000 UTCShoutout to the GTA V Online team for inspiring this post.
The fifth generation of home consoles popularized the use of disc media in consoles. Cartridges were more expensive and unreliable to produce - publishers would have to predict how many units would sell and order that many cartridges - and discs had far greater capacity. The original PlayStation had around 700 MB of disc capacity, and by contrast, the Nintendo 64's largest games were only 64 MB. The PS2 has even more capacity, sporting 4.7 GB for single-layer DVDs and 8.5 GB for dual-layer DVDs.
However, these advantages come with a cost: load times. Ideally, 5.5 MB/s can be read on a DVD on the PS2. This is not entirely bad on its own, but seek times are a different story. To be able to read different parts of a disc, a servo has to mechanically move the laser, which is S.L.O.W. A "full seek" takes around 100 ms, which is several frames, not including the time it takes to even read the data! It's very easy to get loading times that spiral out of control, so developers have to take extra care with their filesystem management.
Minimizing Seeks: Place Related Data Together
As mentioned before, seek operations, where the CDVD drive moves to a different spot on the disc, are debilitatingly slow. Unfortunately, this means that the most logical way of organizing game assets, placing them into many separate files, is also the slowest. If textures, model vertices, sound, scripts, etc. are separated, when loading a level that has all these things, the CDVD drive is going to jump all over the disc. Ideally, all assets that need to be loaded for each area should be stored right next to each other. This means the CDVD drive only has to do a single seek, and then all the necessary data can be read.
Many PS2 games, such as Spider-Man 2 (pictured above), compromise. Files that are accessed infrequently are separated to make organization easier, and all of the important data is stored in at least one database file. This is not ideal, but it beats the cost of seeking to every game asset.
Constant Angular Velocity - Place Important Data at the End of the Disc
The PS2's CDVD drive uses Constant Angular Velocity (CAV), which means that reads on the outer edge of a disc are faster than on the inner edge. In the case of a DVD, outer edge reads are over twice as fast as inner edge reads! Obviously, this means that the most important data should be placed at the end of a disc. A less obvious implication is the use of "dummy files", files not used for anything except taking up space. If a game doesn't need the entire disc for its assets, then to make optimal use of CAV, it has to place a dummy file at the beginning of the disc - in the case of Spider-Man 2, there is a 2 GB dummy file.
(On an unrelated note: certain games have unused assets lying in dummy files, and one of the most spectacular cases is Bloody Roar 4. Its dummy files contain the Renderware SDK, the library used for rendering 3D graphics in many PS2 games!)
Don't Spam the IOP
Normally, the Emotion Engine, the main CPU of the PS2, has no direct control over the CDVD Drive. Instead, the EE must make a request to the Input/Output Processor to read data from the disc. This is fine on its own, as it allows the EE to do other things while the IOP is handling the request. However, because the EE is clocked 8x faster than the IOP, it is possible for the EE to overwhelm the IOP with too many requests, preventing it from doing meaningful work.
A relatively common anti-pattern is for a game to make a request to read data, then continuously ask the IOP if the read has finished before proceeding with some other task. This is bad for two reasons: the first being the load it places on the IOP, and the second being that the EE is effectively doing nothing. Both these factors can cause loading times to be longer than they have to be.
Implications for Emulators
In an optimized environment, three hardware units will be doing work when reading disc data: the EE, IOP, and CDVD drive. And when different parts on a console are working concurrently, bugs start appearing...
If a game has to do a seek, it knows that it has a lot of time before the CDVD drive starts reading. It is common for the EE to be doing some other task under the assumption that the read will finish in several frames. If the read finishes too soon, this can confuse the game, causing freezes, crashes, or infinitely-long loading screens.
Sometimes CDVD timings mask other bugs. Shadowman 2 (pictured above) allocates a buffer large enough to hold 16 disc sectors, but due to a game bug, it will sometimes try to read 17 sectors. If CAV is not implemented in an emulator, this causes previously read data to be overwritten, which manifests as texture corruption.
Closing
While almost every PS2 game needs loading screens, load times can be rather egregious in many cases. This often stems from a poor understanding of the CDVD drive, and other factors not listed here can adversely affect load times, such as if the disc is being streamed and if the data is compressed or not. It's too late to change these loading times outside of per-game hacks, but it's still good to know about the kind of work (or lack thereof) that went into optimizing one's favorite games.
Comments
Draisey Digital
Mindblowing that they put an entire SDK in their dummy files. But this explains why emulators have trouble with PS2 games. You have to think of the entire hardware package, not just what's on the motherboard.
Lollie
Love these technical posts, never knew about the relation between dummy files and disc reads. Arcane knowledge.
