-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
E-mu Emax sampler compatibility #4
Comments
@jacdx thanks for the report. Can you let us know which firmware version you're using, and preferably also include the entirety of your azullog.txt from your SD card, if possible. The firmware version is printed in the log. Feel free to redact any personal details/filenames if there's a need to do so. |
Here you go. I've been experimenting with settings a bit. Selection delay of 1, because that's what SCSI2SD requires for this board. I've tried Fat32 and ExFat, and have been experimenting with filenames. And quirks 1 vs 0. No configuration vs config file. |
Thanks. Can you explain why SCSI termination is disabled? It must be enabled, unless it isn't the only device on the bus. |
The 5380 supposedly has built-in termination. I have tried both ways though and it's the only device on the bus. |
@jacdx thanks. Both sides of the bus must be terminated, not just one end. |
Can you try this to coax more debugging information out of the device:
Reinserting the SD card will force the log file to be saved, so all the latest debug messages should get to the log. |
Ok, here's two logs. The 'reinsert' one follows your instructions. The 'emaxdiag' one, boots up, then runs a function in the Emax hard drive diagnostics menu to test the "SCSI to Echip". I believe this is a general health check of talking to the device on the SCSI bus. This does 200 passes. First one passed, the rest failed. Then I ran another function which does a read test, failed. I did these again with minimal configuration only delay=1 enabled, same results. I looked through the 5380 manual for clues, but it's above my head. I was also looking through the SCSI2SD source and saw a couple of Emax things. Not sure how that translates to this project. commit1 commit2 |
Thanks for the logs! Please try the attached firmware build, it adds support for single-initiator mode and some extra debug messages. |
@PetteriAimonen It worked!!!! I got it working last night and spent a couple of hours in 80s heaven. Nice job! |
@jacdx Awesome! The fix will eventually be included in next firmware version :) |
Is this a Emax I or a Emax II? |
Here are two logs with this new firmware with a MPC60 and a S550. The MPC60 stalls, the LED on the board lights up for 30sec or so, then stops, but the MPC stays stalled and does not recover. The S550 just doesn't see the board at all. |
Also, why does the timestamp on the log file show Dec 31st 2021? |
jacdx, could you post a empty Emax 1 (if that's what you have) image, and also comment on how large they can be? If it's like the II, the max is just shy of 1000mb. Or maybe not? |
jacdx, I got (I think) a Msgr from you and now I can't find it (typical), please contact me via email via the Chicken Systems address. |
There's no real-time clock on the ZuluSCSI microcontroller, so it has no way of knowing what the time and date is. The value has to be set to something. Closing as fixed. |
Hello,
Just got my new AzulSCSI plugged in and am having difficulty getting it working. The Emax is a 1986-1989 sampler with a NCR 5380 controller, originally having a 20MB hard drive. It uses a proprietary drive format, but can be read/written by EMXP). It is known to work with SCSI2SD. I enabled verbose logging but don't get much of note, other than a note about image size not matching the drive geometry. It appears that the images are seen and that AzulSCSI starts up fine. One quick LED flash on power, then a slightly longer one. No errors, but the Emax never seems to read from the board (no disk access LED flashes). Attempting to select another SCSI ID doesn't produce any either. Thoughts on how to debug? Possible to enable read-level or command-level logging?
The text was updated successfully, but these errors were encountered: