Skip to content
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

Closed
jacdx opened this issue May 5, 2022 · 16 comments
Closed

E-mu Emax sampler compatibility #4

jacdx opened this issue May 5, 2022 · 16 comments

Comments

@jacdx
Copy link

jacdx commented May 5, 2022

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?

@aperezbios
Copy link
Collaborator

@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.

@jacdx
Copy link
Author

jacdx commented May 6, 2022

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.
azulscsi.zip

@aperezbios
Copy link
Collaborator

Thanks. Can you explain why SCSI termination is disabled? It must be enabled, unless it isn't the only device on the bus.

@jacdx
Copy link
Author

jacdx commented May 6, 2022

The 5380 supposedly has built-in termination. I have tried both ways though and it's the only device on the bus.

@aperezbios
Copy link
Collaborator

@jacdx thanks. Both sides of the bus must be terminated, not just one end.

@PetteriAimonen
Copy link
Collaborator

Can you try this to coax more debugging information out of the device:

  1. Boot up with Azul/ZuluSCSI connected.
  2. Remove SD card for 5 seconds, the LED should start blinking.
  3. Insert SD card back, the LED should blink once.
  4. Remove SD card and post the log file here.

Reinserting the SD card will force the log file to be saved, so all the latest debug messages should get to the log.
Otherwise the debug messages are only saved once per SCSI request, which is a bit problematic when no requests get through.

@jacdx
Copy link
Author

jacdx commented May 9, 2022

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

azullog-emaxdiag.log
azullog-reinsert.log

@PetteriAimonen
Copy link
Collaborator

Thanks for the logs!
I think I have figured out the problem.
In SCSI-1, there exists a single-initiator mode where the host does not use BSY signal, but only SEL signal to start request.
This mode was later removed from SCSI-2 standard.

Please try the attached firmware build, it adds support for single-initiator mode and some extra debug messages.
ZuluSCSIv1_1_single_initiator_test.zip

@jacdx
Copy link
Author

jacdx commented May 12, 2022

@PetteriAimonen It worked!!!! I got it working last night and spent a couple of hours in 80s heaven. Nice job!

@PetteriAimonen
Copy link
Collaborator

@jacdx Awesome! The fix will eventually be included in next firmware version :)

@chickeneps
Copy link

Is this a Emax I or a Emax II?

@chickeneps
Copy link

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.
zululog_MPC60_2022_05_12_01.txt
zululog_Roland_S550_2022_05_12_01.txt
.

@chickeneps
Copy link

Also, why does the timestamp on the log file show Dec 31st 2021?

@chickeneps
Copy link

@PetteriAimonen It worked!!!! I got it working last night and spent a couple of hours in 80s heaven. Nice job!

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?

@chickeneps
Copy link

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.

@aperezbios
Copy link
Collaborator

Also, why does the timestamp on the log file show Dec 31st 2021?

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants