Hi, as some of you know, I'm currently working on an optical disk emulator (similar to HDL, just better ;-)) for both TOOLs and retail PS2s. As of now, it works (somewhat), but I need some more information to support some advanced features (and possibly some games relying on the reported drive status to be quite accurate). I'm especially looking for a state table of the CDVD drive, as seen by modules calling directly into CDVDMAN, but also including the mechanical state of the drive. For example, the drive consists of the tray+motor, feed and spindle motors and the optical pickup. If a new disk is inserted, a certain time is required for the spindle motor to get at the desired speed; afterwards, the focus and tracking coils of the pickup need to place the lens at the correct position before the RF signal can be decoded. During this time, functions like sceCdDiskReady report the drive is not being ready, and any commands sent to it are either blocked (not issued at all) or delayed (issued, but take some additional time to complete). What puzzles me most is the handling of non-blocking commands (NCMDs) in the CDVD driver. The driver can have one command (like read, pause, stop and so on) outstanding; that is, it has sent it to the drive and waits for an interrupt from the controller (indicating the command has been completed). During this time, the same command cannot be issued again, and the corresponding function call will fail (you cannot invoke sceCdRead if another read operation is pending). To check the command status, applications can use sceCdSync; it checks (and optionally waits) for the last NCMD to be complete. However, according to the 3.0 SDK doc, there is one caveat when using it with sceCdRead: if the disk surface is heavily damaged, the drive may read indefinitely, so the read command does never complete. In this case, a BREAK NCMD can be sent to abort the operation (even if sceCdSync indicates the previous command to be still pending). If this command is issued, sceCdSync is used to check for completion of the break, not the original command. Has anyone ever seen a table of the mechanical drive states, transitions between them and the corresponding information that could be seen at the software side? For example, at which exact times functions like sceCdSync/sceCdDiskReady/sceCdStatus report which code? Of course, I could write some test programs and use my half-dead lasers to construct this table myself, but I thought I'd ask first whether anyone has already done (parts of) this research ;-). Best regards, SilverBull
