Loading issue on Akai S1100

[chickeneps]

Pi Zero Software 2,22.2.1, Board 2.4a, Akai S1100.

I can confirm there is a loading problem with RaSCSI and S1000's. I took the Master Studio Collection CD (S1000 CD) and took the OB sample and loaded it into our S1100 and S3000XL. No clicks on the latter but clicks on the former. I resaved the sample into a different location then converted them to WAVE. The waves are almost identical but some chunks of data get mixed up, like one packet gets there faster. Put another way, there's no corrupted data, just (probably) mixed up data. And it seems loading and saving are a problem since in the WAVE versions there seems to be more clicks than just loading it into the S1100. I'm happy to test further and/or apply any diagnostics OB_rascsi_s1100.zip .

[akuker]

For sampler noobs (such as myself).... would you be able to provide more information about what the sampler is doing at the lower level?

Are these essentially files on a filesystem? Or is the sampler doing something else?

How easy is this to reproduce? If you have multiple RaSCSIs on the bus, you could do data captures using SCSIMON to help diagnose the problem.

[chickeneps]

At 07:17 PM 3/27/2022, you wrote:

For sampler noobs (such as myself).... would you be able to provide more information about what the sampler is doing at the lower level?

Not really in terms of SCSI commands and timing. But yes everything else.

Are these essentially files on a filesystem? Or is the sampler doing something else?

They are files on a proprietary file system. AFAIK the SCSI commands are standard GET's and SET's. The issue though is likely timing of the handshakes etc. Don't take my word for it, though, I have lots of experience but I'm still just looking on the outside.

How easy is this to reproduce?

Easy, it does it every time. I have yet to establish that it corrupts data in the same or random places.

If you have multiple RaSCSIs on the bus, you could do data captures using SCSIMON to help diagnose the problem.

Are you saying to chain them up like this?

RASCSIwithS1100Image -> RASCSIwithSCSIMON -> AkaiS1100

I have the two Pi+RaSCSI, but I'd have to make a custom cable (easy) to stick the RASCSIwithSCSIMON in the middle. Do I have that correct?

How do I turn off term in the middle, and how does SCSIMON monitor all the channels? Does it log?

And I assume I'd connect them up, get the outside units ready, then run SCSIMON on the middle device, and proceed to do the LOAD.

If you could give me a step-by-step, it'd make this easier; otherwise I should be able to figure it out.

Garth Hjelte Sampler User

[guinguin-instruments]

I have the exact same problem with my Akai S1000.

• S1000 OS : v4.40
• RASCSI PCB Full Spec 2.4a
• RASCSI version 22.2.1 When using my SCSI2SD card everything work as expected.

[guinguin-instruments]

@chickeneps : what's your AKAI OS version ?

[chickeneps]

At 08:46 AM 3/29/2022, you wrote:

@.*** : what's your AKAI OS version ?

Same, 4.4.

I'd like confirmation how I can test this via SCSIMON, I'd like to go forward to fix this.

Garth Hjelte Sampler User

[guinguin-instruments]

@chickeneps : I find some doc for SCSIMON : https://github.com/akuker/RASCSI/wiki/SCSI-Bus-Capture Unfortunately, I only have one RASCSI so cannot help that much.

[akuker]

Are you saying to chain them up like this? RASCSIwithS1100Image -> RASCSIwithSCSIMON -> AkaiS1100 Exactly

I have the two Pi+RaSCSI, but I'd have to make a custom cable (easy) to stick the RASCSIwithSCSIMON in the middle. Do I have that correct? You shouldn't need a special cable, unless you really want to. There is a daisy chain board available on my tindie for $5. Or, if you are using the DB-25 connector to connect to the Akai, you could use a 50 pin ribbon cable to tie the two RaSCSI boards together.

How do I turn off term in the middle, Toggle the termination switches on the RaSCSI board

and how does SCSIMON monitor all the channels? Does it log? And I assume I'd connect them up, get the outside units ready, then run SCSIMON on the middle device, and proceed to do the LOAD. If you could give me a step-by-step, it'd make this easier; otherwise I should be able to figure it out.

Sorry for the delay in getting back to you. I'd be glad to try to walk you through step by step. I'm assuming you're using the full sized RaSCSI board. Here's a diagram of how to hook things up:

First, get RaSCSI configured and running with your setup WITHOUT scsimon running on RaSCSI #1. Scsimon will capture A LOT of data, and you probably only want to run it for a few seconds before it fills up its buffer.

When you're ready to capture the event, run the following command on RaSCSI #1: sudo nice -19 bash -c "scsimon -b 1000000"

The -b option tells scsimon how big of a buffer to use. the nice part of the command gives scsimon extremely high priority on your system.

After you've re-created the event, press CTRL-C to terminate scsimon. If the buffer fills up, scsimon will automatically quit. If this happens, you may want to re-run the operation with a larger buffer size.

scsimon should generate a semi-human readable HTML file that you can open and see all of the transactions. There will be three files - HTML, JSON and VCD. The HTML is human readable, JSON is the raw format that scsimon uses, and VCD can be opened in GTKWave.

I realize this tool isn't the most straight-forward to use. It was meant as a development tool for me to use, so I'll admit that I've been slacking with the documentation. Please let me know if you run into trouble, and I'll try to get back to you ASAP!

[chickeneps]

At 08:07 PM 3/31/2022, you wrote:

for the delay in getting back to you. I'd be glad to try to walk you through step by step. I'm assuming you're using the full sized RaSCSI board. Here's a diagram of how to hook things up:

https://user-images.githubusercontent.com/34318535/161174138-1e37893e-89c1-4c93-91c7-78cee9346c85.png image

I thought it was a huge NO-NO to use the DB25 and CEN50 at the same time. It's even printed on the board not to do that.

First...

OK, I think I'll be able to get to this this weekend.

Thanks for your detail.

Garth Hjelte Sampler User

[akuker]

I thought it was a huge NO-NO to use the DB25 and CEN50 at the same time. It's even printed on the board not to do that.

It should say "unless you know what you're doing" ;-) I've actually taken that warning off in the newer revisions.

[chickeneps]

Thanks - here's what I'm getting

Emacs!

RaSCSI is running.

It is possible that my SCSIMON Pi w/ RaSCSI may be "running RaSCSI" (that is, running the service) but as the second error says, the board may not be connected in a wholesome way.

How does one test if the board itself is fully running with the Pi in heavenly form?

The problem 'round here is that I don't have a lot of Pi's floating around, and I'm not going to spend $100 for one. Otherwise I'd just swap a Pi that may be connected better (better GPIO connection).

Garth Hjelte Sampler User

[chickeneps]

I swapped the SCSIMON Pi with a larger Pi 3, that I'm sure the GPIO is solid. Same error.

[error] Unable to register event request. Is RaSCSI already running? [error] Unable to initialize the GPIO buss. Exiting...

Garth Hjelte Sampler User

[chickeneps]

I haven't had a reply on this in a week or two, can we follow up? My Pi's are sitting waiting.

---

I swapped the SCSIMON Pi with a larger Pi 3, that I'm sure the GPIO is solid. Same error.

[error] Unable to register event request. Is RaSCSI already running? [error] Unable to initialize the GPIO buss. Exiting...

Garth Hjelte Sampler User

[akuker]

Sorry for the delay. There's been a lot going on lately.

Some thoughts:

• What Raspberry Pi OS are you using? I'd recommend trying the February release
• Are you running scsimon with sudo?
• Are you sure that rascsi isn't running? Can you run ps -aux |grep rascsi?

[chickeneps]

At 08:41 PM 4/18/2022, you wrote:

Sorry for the delay. There's been a lot going on lately.

Understood!

Some thoughts: What Raspberry Pi OS are you using? I'd recommend trying the February release

Raspbian GNU/Linux 10 (buster)

Are you running scsimon with sudo?

Yes, the command line you gave me was

sudo nice -19 bash -c "scsimon -b 1000000"

Are you sure that rascsi isn't running? Can you run ps -aux |grep rascsi?

On your instructions you didn't say to shut down RASCSI on the SCSIMON Pi. It now works. Where are the logs stored?

---

The information contained in email transmissions and any files transmitted with it are confidential and intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Please note that any review, re-transmission, copying, distribution or other use of the email is prohibited.

---

Garth Hjelte		Customer Service Representative		Chicken Systems, Inc.		4024 Williford Way		Spring Hill, TN 37174-6221 USA
800-8-PRO-EPS Toll Free Order Line (US Only)
320-235-9798 Tech Support, Sampler Questions
International Line
320-235-9798 Fax
Product Sales: @.***
Product Support: @.***
Web Page: www.chickensys.com

---

[chickeneps]

Found them. Attached. I am not certain that SCSIMON quit before I did the Akai command. The Akai is in the other room and I have to hurry to do it s1100_logs.zip s1100_logs.zip .

[Deftaudio]

just checking if there are any news here. I'd love to get my S1000 running too.

[chickeneps]

Same here, I put in the logs for the SCSIMON about a week ago.

Garth Hjelte Sampler User

[guinguin-instruments]

Same here, any update ?

[uweseimet]

@akuker Looks as if several users are still waiting for feedback?

[Deftaudio]

Just wondering if this ever got resolved?

[rdmark]

@Deftaudio There have been a lot of code changes since this was reported, some of which may impact RaSCSI's timing slightly. Would you be able to test the latest code in the develop branch and see what the behavior on an Akai is now?

[guinguin-instruments]

I tested the latest release v22.08.01 and the problem is still present making the RASCSI unusable :-(

[rdmark]

@guinguin-instruments What you tested is 2 months old code. Please test the latest code in the develop branch. It has seen huge changes since the previous release.

[sadguitarius]

The fix referenced here seems it would similarly apply to this issue. I see a bunch of delay variables in cpp/hal/bus.h that I assume would be the area to look at. Which of these would correspond to SCSI “phase change” so I can try a test build with the new delay value to see if that works?

[sadguitarius]

@chickeneps not sure if anyone is still watching this thread, but try changing line 30 in scsi_controller.h to

static const unsigned int MIN_EXEC_TIME = 400;

and loading an Akai library image as hds (just change the file extension of an iso, or what I do is make symlinks so I can still load the iso on other samplers)

This is so far working for me and I haven't noticed any side effects. All loading glitches are gone on my S1000. I'm sure there's a better way to add this delay conditionally somehow, but at least as a proof of concept it's a good start!

[johnny-too-bad]

@chickeneps not sure if anyone is still watching this thread, but try changing line 30 in scsi_controller.h to

static const unsigned int MIN_EXEC_TIME = 400;

I can confirm that this has also worked for me! After changing the value to 400 and recompiling, I can load samples onto my s1100 without any mixed up sample data.

From what I can tell, it doesn't affect loading samples onto my s2000 either, but I'm not sure how it would affect loading with other samplers.

[rdmark]

Have you all tested other values besides 400, to see where the threshold is? Looking where the constant is used in scsi_controller.cpp it seems to be controlling a sleep timer between commands, so a higher value may introduce performance degradation on faster systems. Potentially.

[uweseimet]

IMHO making PiSCSI slower is not a good solution. I would not be surprised if the actual problem is unrelated to MIN_EXEC_TIME but rather a general issue with the bus signal handling or bus siginal timing handling, which may require further analysis (code review) and validation against the SCSI standard. If there was something wrong with the bus signal timing, making PiSCSI slower by increasing MIN_EXEC_TIME might help, but the real problem would be somewhere else. Why is MIN_EXEC_TIME needed at all, i.e. why is there a work-around for slowing down the rate of commands PiSCSI can execute?

[chickeneps]

It might be the only way. This was fixed on ZuluSCSI. SCSI is fast enough anyway and the Akai isn’t the fastest brand of SCSI so a little slowdown doesn’t wreck the world. I tested this, the scrambling of packets is unacceptable and the user needs assurance of perfect byte-for-byte transfers (like we all do).Sent from my iPhoneOn Apr 16, 2023, at 11:04 AM, Uwe Seimet @.***> wrote: IMHO making PiSCSI slower is not a good solution. I would not be surprised if the actual problem is unrelated to MIN_EXEC_TIME but rather a general issue with the bus signal handling or bus siginal timing handling, which may require further analysis (code review) and validation against the SCSI standard. If there was something wrong with the bus signal timing, making PiSCSI slower by increasing MIN_EXEC_TIME might help, but the real problem would be somewhere else.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[chickeneps]

But your point on where the real problem lies is well taken.Sent from my iPhoneOn Apr 16, 2023, at 11:04 AM, Uwe Seimet @.***> wrote: IMHO making PiSCSI slower is not a good solution. I would not be surprised if the actual problem is unrelated to MIN_EXEC_TIME but rather a general issue with the bus signal handling or bus siginal timing handling, which may require further analysis (code review) and validation against the SCSI standard. If there was something wrong with the bus signal timing, making PiSCSI slower by increasing MIN_EXEC_TIME might help, but the real problem would be somewhere else.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[sadguitarius]

I haven't yet had time to plug in values to find the minimum delay that doesn't scramble packages. This would need a lengthy recompile as well as error testing every time, so maybe some rainy day I'll get around to it. I certainly agree that increasing MIN_EXEC_TIME is not an ideal long-term solution. My point was mainly that this does work perfectly fine as far as I can tell, and I can happily use my S1000 without scrambled data. This also doesn't break anything with my Roland XV-5080, which I also use with PiSCSI.

I do think this issue deserves attention, since this is just another one of the many old devices that PiSCSI aims to keep relevant.

Currently, none of the available workarounds work as well as this does for my use case. I guess I'll continue to fudge the SCSI bus variables until a better solution comes along. Happy to help troubleshoot, but I don't have a second Pi currently, so I can't do a whole lot of testing without SCSIMON I guess.

I'm not trying to be rude, I just don't think I have the programming chops to handle the intricacies of SCSI protocol right now, and I simply need this to work in whatever manner I can get it to.

[sadguitarius]

Page 265 of this document references a 400 ns delay before reading status. There's also a 400 ns delay mentioned in the Prepare_A state on page 268. There's some example code here that uses the delay before the status command. So maybe what was found empirically to work is actually grounded in reason?

I'd love to get some more knowledgeable eyes on this to see if it really says what I think it does, but it does look like at least some version of the spec calls for adding this delay. If so, would the devs consider implementing it?

[akuker]

Hi @sadguitarius - have you tried out https://www.scsi2pi.net/ ? @uweseimet forked off PiSCSI and has made a ton of updates. AFAIK its fully compatible with the PiSCSI hardware.

There hasn't been a lot of activity on PiSCSI lately, but I wanted to respond. I hope this helps!

[sadguitarius]

Ah thank you! I had no idea about the fork. I'll check it out, it looks like some of the new additions could apply to this.