ideas for getting Akai S1000 to work with scsi2pi

[sadguitarius]

Hello, I was just directed to this fork from PiSCSI since development has slowed down over there, and I'd like to pick up this issue and see if there's any way to make progress on it here. I can see that the codebase has changed quite a bit and that the ScsiController class no longer exists.

I was optimistic about trying scsi2pi, but I'm still getting corrupt file transfers with the S1000. Would you be able to point me in the direction of where I might be able to try playing with bus delays to see if I can get anywhere? I'd love to use this library and help contribute in whatever way I can, but it's a nonstarter until I can at least get it up to parity with the setup I currently have with PiSCSI.

I did find this document which appears to point to some relevant delay timings on page 265, although I'm not terribly up to speed with how this stuff works. There's an example code snippet here as well.

Any ideas would be greatly appreciated. Thank you!

[uweseimet]

@sadguitarius Note that I converted your issue into a discussion.

Regarding timings, it is important to ensure that any timing change is covered by the SCSI specification. For SCSI2Pi this means that if the current timing violates the specification it may be required to update the SCSi2Pi code accordingly. If there is no violoation of the specs, but if there is hardware that expects a non-standard timing, it is unlikely that SCSI2Pi will be changed. Delays/timeouts with SCSI are mostly relevant for the SCSI initiator, not the SCSI target.

If there is data corruption during a transfer it is quite likely not a timing issue, but a wrong handling of SCSI bus phases or something hardware-related, e.g. bad cable quality or wrong termination. The logfile usually contains details in such a case, something containing "expected size was n bytes". The actual SCSI data transfer uses a handshake and not a timing. Timings are only used for the arbitration/selection phases at the beginning of sending a SCSI command, for the bus settle delay and a rather long timeout (3s) in case of bus phase issues during the transfer.
If the SCSI transfer was successfully initiated, on the target side there are only two timeouts. One that ensures that each REQ/ACK handshake does not take longer than 3 seconds, and the bus settle delay, which ensures that all signals are stable before being used.
The bus settle delay timeout handling is in the WaitBusSettle() method in the RpiBus class.

[sadguitarius]

Thanks for your reply. In the link I sent to the PiSCSI issue, I noted that in my case, changing MIN_EXEC_TIME in scsi_controller.h (which no longer exists) to 400 solved the problem I was having and didn't result in any perceptible downsides with other SCSI equipment. To be clear, there's nothing wrong with the cable, and I was getting perfectly fine results with PiSCSI using the added delay. Now when I try SCSI2Pi, I see no warnings or errors with logging set to trace, but the data comes out jumbled.

I understand your reticence to just plug arbitrary numbers in and hope for the best, which is why I at least attempted to find some basis in standards for the delay value though my knowledge is limited. My ultimate goal is to be able to interface >30 year old equipment with modern storage in whatever way I can. That said, do you think you could provide some assistance with how I might go about accomplishing a similar patch with SCSI2Pi so I can at least maintain a version of the software that I can use? Where would be an appropriate place for injecting an additional delay if I wanted to try matching the results I was getting with PiSCSI?

I do personally feel it would be valuable to have the ability to create exceptions for specific devices, even if this meant exposing some parameters in a config file or something and not necessarily hard-coding exceptions for each device. The likelihood of Akai releasing a bugfix OS for a sampler released in 1988 is far less likely. Like I said, I'm happy to contribute to this project and whatever community evolves around it, but I'm less motivated to invest time and energy in it if I can't get it off the ground to begin with. Thanks so much!

[uweseimet]

MIN_EXEC_TIME slows down the command execution, which is something not requested by the SCSI specification. On the contrary, usually you would want commands to run as fast as possible. Compared to PiSCSI, SCSI2Pi offers up to 25% higher data transfer rates, and I do not want to sacrifice this benefit by adding non-standard delays. It seems that your Akai has issues with correctly evaluating the SCSI bus phase signals. Only if it turned out that SCSI2Pi is missing a delay required by the SCSI specification I would address this. In such a case this delay would not be something configurable, though, because all relevant SCSI delays have well-defined, non-configurable values.

If you want to patch SCSI2Pi, you should have a look at the AbstractController and/or Controller class. The SCSI2Pi Controller class is similar to the PiSCSI ScsiController class, which contains the delay you mentioned. By comparing these classes you might find a place where to add the delay you need. Note, though, that there is no need for the SysTimer class anymore in SCSI2Pi. This means that there is probably no straightforward way of adding the timing you need to SCSI2Pi.

[sadguitarius]

Totally understood. I did start patching the Controller class and noticed the absence of the SysTimer class. I can at least see where all this stuff is in the code now, so it should be easy enough. And once I get it working, I'll also see if I can figure out how to properly fix the transfer issues without the delay. Thanks!

[uweseimet]

If there is anything new, especially if you find a solution compliant with the standard, please provide feedback.

[uweseimet]

One more note: MIN_EXEC time is used at various code locations in PiSCSI. It may be useful to know which location is the one that is relevant for your hardware. This might provide more insight.