Search options (Page 50 of 57)

My apologies, but I wasn't clear before about the ReadBufferCapacity() problem on the 1210S. For some reason, the 1210S resets itself if a SCSIOP_READ_BUFFER_CAPACITY is issued to it. When it resets itself, it is unresponsive for some seconds and the following SCSI commands fail with either "UNIT_ATTENTION - POWER ON, RESET, OR BUS DEVICE RESET OCCURRED" or "LUN NOT READY - BECOMING READY".

I noticed the /c2 option wasn't working, though, since bC2ErrorData == FALSE.

I started doing tests on an old Nakamichi.

It works with px_d8, but not when reading subcodes. I've posted a question elsewhere on the forum to hopefully determine exactly how px_d8 does subcode reading, so maybe I can troubleshoot it.

The disc that failed when I tested it yesterday was a single track disc (US version of Ace Combat 3). However, I tried on a multi trakc disc (Japan version of Ace Combat 1), and the px_d8 works.

Reading is much slower than in the last version. My guess is this is due to the additional read commands used for subcode reading (which weren't being run before, since the buffer was 0 < MINIMUM_DRIVE_BUF_SIZE).

I've got some other SCSI drives I'll try to get tested eventually (Some old Nakamichi, Toshiba, other Plextor models, Yamaha, etc) and report results.

pDisc->SCSI.pszTitle == 0, because pDevice->bCanCDText == FALSE, so the pszTitle array isn't initialized. Same problem exists with pszPerformer, etc. I bypassed it by checking first if pDisc->SCSI.pszTitle == 0, and similar for other psz* variables. I'm not sure if that's the best solution, though.

One other problem which I haven't looked into yet is, after reading all the scrambled sectors for a PSX disc, an error is presented:

Unfortunately it looks like there are some other obstacles. I had to bypass "ReadDiscInformation" as the Ultraplex doesn't support those commands either.

The call to ScsiPassThroughDirect seems to only read 2448 bytes into lpbuf (if I'm understanding the ioctl call correctly -- DataTransferLength is only 2448. But then lpbuf2 is lpbuf + combined offset, and combined offset on this disc is 9160 bytes. lpbuf2 then goes past the end of the lpbuf array.

I think the incompatibility is (partly) because the Ultraplex 40 doesn't support the SCSIOP_READ_CD read command used in ReadTOCFull. It only supports 0xd8 reads.

I also did some testing with my Creative RW121032E which is (I believe) a rebadged PX-W1210TA. You are correct, on PSX discs px_d8 fails with "ILLEGAL_REQUEST. ILLEGAL MODE FOR THIS TRACK". In contrast, the PX-W1210S and Ultraplex 40 seem to work with px_d8 on these discs.
However, I was able to get the RW121032E to dump a Saturn disc using 0xd8.

On another note, why are some drives noted as only supporting scrambled reads on PCE discs?

Just dumped Steamgear Mash with DIC and noticed that the size of the data track and the first audio track do not match the size / hash in the database.

Here's the stdout from when I ran the drive on the Ultraplex 40:

Does anyone know the compatibility of the PX-716AL?

Error logs are huge with the latest build. Like 1GB with a perfect disc.

*EDIT* Seems data only discs have this problem

*EDIT2* Seems to be the case with certain discs only

I've said "There are many discs, where the whole R-W area is padded with 0xFF"

Maybe it's better to detect any padding, not only 0xff? If 10 or 11 bytes out of 12 for 1 subchannel are the same = padding. Like, channel T: 08 08 08 08 09 08 08 08 08 08 08 09 => 10 bytes are 08 and 2 bytes are 09 => padded with 0x08.