SCSI to Ethernet Adapter on New Hardware

[saybur]

Some more progress: the unknown extended message can apparently just be ignored.  If the firmware does that instead of sending MESSAGE REJECT things... just work.  That's not a very satisfying answer and I hope it isn't creating a hidden problem.  On the plus side, large transfers are working, and the files are intact on arrival.  Huzzah!

I also did some work on the packet reception code in general.  The real hardware has some long wait times (~100-150us) as it switches phases during packet reception.  I was originally emulating this behavior.  However, those do not appear to be important, and after commenting them out packet reception is noticeably faster.  A speed test using the same dataset as in previous post:

"scuznet" emulated device: 38.6 MB in 3m49s, or ~1.35 Mbit/sec

That's about 15% faster than the same test on the real Nuvolink, which I'm pretty happy to see!  It'll need more testing to verify if there's an actual improvement overall, but it's encouraging none the less.

 

[Trash80toHP_Mini]

Nice to hear good reports like this. Rock on!

 

[Bunsen]

Are you using AVR assembler to target the SCSI bus, or Arduino code?

 

[saybur]

This is all in AVR C, with a tiny touch of inline assembly for a few timing-sensitive operations.  The Arduino in the pictures is forced into reset: I'm just using it as a USB UART to get packets from the board to my PC for debugging.

 

[paws]

At the risk of derailing your thread completely, do you know how big a difference there is between SCSI hosts and SCSI targets? Would it be possible to use hardware as (relatively) simple as yours to implement a SCSI host?

The reason I ask is because there exists a standard, SMDI, that computers like old Macs used to load audio data directly into the memory of samplers (musical instruments) via SCSI, and I've long wanted to make something that made that possible from a modern computer - but it basically involves pretending to be a host. The specific command set related to the activity is quite simple, but I don't know anything about all the stuff around those commands, nor the electricals.

 

[cheesestraws]

As far as I know there's no real hardware difference between an initiator and a target, but that is a dim and uncertain memory

 

[trag]

Are you bit banging the SCSI side of the interface using ports on the XMEGA microcontroller  or do you have a SCSI chip on there too?

Beautiful work, by the way.  Very cool.   How long have you been working on this?

 

[saybur]

That's really neat, I'd never heard of SMDI before.  It shouldn't be too awful to make your own initiator; on the hardware side, things are very similar, with only minor changes in which signals you're required to drive.  The initiator logic would be different, but implementing it shouldn't be any more difficult in scope than the kind of thing I had to do for this project.

As an example, this board would not be able to act as an initiator the way it's currently hooked up: there are no drivers for /ACK and /ATN, and it doesn't listen to /MSG, /I/O, /C/D, or /REQ, but all of those could be changed around if needed.  SCSI2SD boards (at least the GPL'd versions) should have the hardware hooked up to act as an initiator if they wanted to, though I don't think that's been done in any firmware that's been released.  If you're looking for a board that already exists to do some messing around with, that might be a productive avenue to explore.

 

[saybur]

This implementation bit-bangs the interface, mainly to keep away from new old stock hardware.  Apart from the microcontroller, all the SCSI control hardware uses jelly bean logic.  I wanted to use this project as a launchpad for really learning how SCSI works, so I figured having to handle the physical layer in addition to the logical one would help with that.

As for time, I started work on this back in September, when I finally managed to get my hands on the Nuvolink.  I would have preferred to find a less obscure device, though I think it was for the best in the end: it turns out the communication method is, like, a absolutely perfect match for the way the ENC28J60 chip works.

And thanks to everyone in this thread for the encouragement, it's much appreciated!  Fixing up the HDD code now, which I have working well enough to finally be able to read and write files from the OS - playing Barrack on a IIci is a glacial experience, but it at least works as a proof of concept.

 

[rabbitholecomputing]

The board is based on a ENC28J60 Ethernet chip and XMEGA AU series microcontroller, with a SD card thrown in the mix for good measure to emulate a hard drive.  Networking has been tested under System 6 and EtherTalk seems to work fine with an unmodified Nuvotech driver. 

Super duper awesome project, and amazing progress in a short amount of time! I'd love to build one. I've been aware of the ENC28J60 since it was introduced about ten years ago, and I'm curious why you chose a non-5V native MCU, given the 5V native SCSI interface, and the fairly widespread availability of 5V native (not tolerant) ARM Cortex M0/3/4 MCUs, since it adds expense and complicates the BOM a bit. One of the coolest things about the Cypress PSoC that the SCSI2SD V5 is based around is that it has the ability to assign different voltage domains to individual pins (pin groupings, really), so you can speak SPI at 3.3VDC, and SCSI at 5VDC, negating the need for additional/separate voltage translation circuitry.

I've considered experimenting with an ENC28J60-based SCSI2SD variant, and doing something exactly along the lines of what you've accomplished.

 

[techknight]

Good thing about using an ARM Cortex, you can get speed improvements of course, and then since the firmware is written in C, it should be fairly easy to port over without doing too much work, but you would have to replace the ASM routines though. 

Regardless, this is a really nice project

Honestly, with a littel bit more cobbling, you can probably replace the ethernet PHY with an ESP8266.. and then use some of the WiFi driver development done by ants, combine the two, and you have one really badass product, with a wifi icon in the menu bar to boot!

Then, if its miniature enough, it can be put inside vintage powerbooks, replace the internal HDD, and gain wifi support at the same time? HELL yes!

 

[saybur]

...I'm curious why you chose a non-5V native MCU, given the 5V native SCSI interface, and the fairly widespread availability of 5V native (not tolerant) ARM Cortex M0/3/4 MCUs, since it adds expense and complicates the BOM a bit. One of the coolest things about the Cypress PSoC that the SCSI2SD V5 is based around is that it has the ability to assign different voltage domains to individual pins (pin groupings, really), so you can speak SPI at 3.3VDC, and SCSI at 5VDC, negating the need for additional/separate voltage translation circuitry.

It's honestly just due to my lack of familiarity with the ARM ecosystem.  I'm not an EE, just a hobbyist.  I've done several projects with garden variety 5V AVRs, so it wasn't nearly as big a leap for me to do it with an XMEGA instead: I wanted to focus on learning the SCSI bus and figuring out the specifics of the Nuvolink, and not have to fight an unfamiliar MCU in the process.  I agree with you and @technight that this would be objectively better from a technical perspective on an ARM chip, and hopefully the protocol documentation and/or the source for this board will be useful for anyone wanting to take a stab at that.

Also, man, I do feel bad for the XMEGA designers.  They are super cool little microcontrollers, but they were just too little, too late to really take a slice of ARM's pie.  If anyone reading this is familiar with AVRs and wants to see what that CPU core can really do, they're worth at least playing around with.

Good thing about using an ARM Cortex, you can get speed improvements of course, and then since the firmware is written in C, it should be fairly easy to port over without doing too much work, but you would have to replace the ASM routines though. 

The ASM in this is minimal, and is just there for time critical access to the MCU's protected registers.  It would not need to be ported.

Honestly, with a littel bit more cobbling, you can probably replace the ethernet PHY with an ESP8266.. and then use some of the WiFi driver development done by ants, combine the two, and you have one really badass product, with a wifi icon in the menu bar to boot!

Then, if its miniature enough, it can be put inside vintage powerbooks, replace the internal HDD, and gain wifi support at the same time? HELL yes!

And thanks to both of you for the nice comments 

For anyone following along, everything basically works now on my test setup: I'm booting my IIci off the prototype, downloading files from the server, unpacking, playing Swoop off the drive, etc.  I'm working on finishing up a minor PCB tweak that fixes the most egregious errors it and then this should be ready to post.

Edit: @techknight, not technight, sorry.

 

[saybur]

All right, source is up:

https://github.com/saybur/scuznet

Any questions, feel free to fire away! 

 

[olePigeon]

How about A/ROSE support?   My IIci's networking performance was significantly improved when I installed the Apple NuBUS ethernet adapter with A/ROSE.

 

[saybur]

How about A/ROSE support?   My IIci's networking performance was significantly improved when I installed the Apple NuBUS ethernet adapter with A/ROSE.

I don't really know anything about A/ROSE (or much about classic Mac driver development).  Was that specific to NuBus hardware, or did vendors make drivers for SCSI devices as well?

 

[olePigeon]

Oh, looks like you're right.  Reading the Wikipedia, it was only for NuBUS cards.  I suppose if it had caught on, it could have been used for other things.

 

[uyjulian]

It may be possible to do offloading similar to how A/ROSE did it. However, you would need to write a new INIT and/or adev for it.

 

[cheesestraws]

However, you would need to write a new INIT and/or adev for it.

Writing adevs is a right pain in the posterior </unsolicited opinion>

 

[olePigeon]

"How hard can it be?" - Jeremy Clarkson

 

[Michael_b]

All right, source is up:

https://github.com/saybur/scuznet

Any questions, feel free to fire away! 

This is very cool, congrats!