Jump to content
saybur

SCSI to Ethernet Adapter on New Hardware

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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! :D 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.

Share this post


Link to post
Share on other sites
On 12/1/2019 at 8:36 PM, saybur said:

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.

Share this post


Link to post
Share on other sites

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!

Edited by techknight

Share this post


Link to post
Share on other sites
8 hours ago, inertialcomputing said:

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

5 hours ago, techknight said:

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.

5 hours ago, techknight said:

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!

:D

 

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.

Edited by saybur

Share this post


Link to post
Share on other sites
7 hours ago, olePigeon said:

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?

Share this post


Link to post
Share on other sites

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.

 

Edited by uyjulian

Share this post


Link to post
Share on other sites
On 12/1/2019 at 8:36 PM, saybur said:

I've been spending some time recently making a SCSI to Ethernet adapter using all-new hardware.  I managed to snag a Nuvotech NuvoLink SC off eBay, and after doing some analysis of how it talks with the driver over SCSI, I've decoded the vendor-specific parts of the communications protocol and implemented a compatible version on a custom PCB.  Here's some pictures of the board and test setup:

 

https://imgur.com/a/ZJFfrSG

 

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.  That said, this is definitely just a prototype, so there are plenty of things that still need to be done:

 

  1. Test with MacTCP or OpenTransport on newer versions of the OS. There is conflicting information I've found online about how compatible this particular driver is.
  2. See about compatibility with other SCSI to Ethernet adapters.  Focus bought Nuvotech and appears to have re-released everything under their brand, so getting their driver working would likely be pretty easy.  I'd ideally aim to get compatibility with a driver known to be stable with Open Transport in particular (if one exists).  Other, wiser members might have some ideas on that.
  3. Finish the HDD emulator, which is only partially working.
  4. Spin a board revision that has USB for firmware updates instead of the vendor PDI interface, and fix some of the other annoying problems I caused myself with the hardware design.
  5. Fix the significant bugs that I'm sure still are lurking in the code.

 

It's been a bit of a slog to get to this point, and I mainly wanted to share this with the community and see what others thought of the project.  Plus, I was pretty happy to have pictures of this thing working: I've been banging my head on my keyboard with it for a while. :))

 

My short-term plan for this board is to release the protocol documentation, design, and code under GPLv3 and let others poke around with this.  I'll be working on getting the firmware into a slightly nicer state over the next few days and then throw all the files up on Github.  I do not have any interest in making this to a kit / product / etc: if anyone would like to take a stab at that, you'll be free to do so under the license.  At minimum, the protocol documentation will hopefully be of some value to the community.

 

If anyone has questions or comments, please fire away.  Thanks for reading! 

Have you measured current consumption while idle and active? What's up with the dual-linear-regulator design? Seems odd, am I missing something?

 

Edited by aperezbios

Share this post


Link to post
Share on other sites

So admittedly, I haven't read through this entire thread... but I just wanted to say WELL DONE! There is a huge need for this kind of hardware, I'm thrilled that you took on the task and figured it out. Amazing work. 10/10 am interested in getting a hot air station so I can do SMD work to make some of these.

 

I'll be following the thread closely!

Share this post


Link to post
Share on other sites
On 1/12/2020 at 1:09 PM, PotatoFi said:

So admittedly, I haven't read through this entire thread... but I just wanted to say WELL DONE! There is a huge need for this kind of hardware, I'm thrilled that you took on the task and figured it out. Amazing work. 10/10 am interested in getting a hot air station so I can do SMD work to make some of these.

 

I'll be following the thread closely!

Source code is up, so you can start manufacturing your own now. https://github.com/saybur/scuznet

Share this post


Link to post
Share on other sites
On 1/12/2020 at 12:04 PM, aperezbios said:

Have you measured current consumption while idle and active? What's up with the dual-linear-regulator design? Seems odd, am I missing something?

 

One is 2.63V for the terminator, and the other is 3.3V for everything else.  These could probably be switching regulators rather than big old linears, but I'm not familiar with switching regulator design and I didn't want to mess with that as part of the project.  The weird 2.63V voltage is used instead of the standard 2.85V on the terminator due to Digikey not stocking 110ohm 10-SIP bussed resistors, so I went with an alternate configuration using a lower voltage and more common 100ohm parts (this is supported as part of the spec, though I've never seen a device using it in the wild).  It would be trivial to replace the two regulator adjust resistors and move to the standard 110ohm resistor packs if desired.

 

Power consumption has not been measured, but it likely isn't all that high: figure ~100mA for the SD card, 180mA for Ethernet, and ~480mA for the terminator as the main power sinks.  Keeping with the KISS philosophy on the power side, the regulators are oversized and have pads for extra heatsinks in case that was necessary, but during testing they barely got warmer than ambient air while outside the case.

 

If a reference would be of interest, I've added the BOM I used when making my boards to Github.  That should more or less be accurate: I dropped the unnecessary 128A3U XMEGA part down to 64A3U, as the extra memories are not necessary for the firmware.

Share this post


Link to post
Share on other sites
On 1/22/2020 at 7:21 PM, saybur said:

One is 2.63V for the terminator, and the other is 3.3V for everything else.  These could probably be switching regulators rather than big old linears, but I'm not familiar with switching regulator design and I didn't want to mess with that as part of the project.  The weird 2.63V voltage is used instead of the standard 2.85V on the terminator due to Digikey not stocking 110ohm 10-SIP bussed resistors, so I went with an alternate configuration using a lower voltage and more common 100ohm parts (this is supported as part of the spec, though I've never seen a device using it in the wild).  It would be trivial to replace the two regulator adjust resistors and move to the standard 110ohm resistor packs if desired.

  

Power consumption has not been measured, but it likely isn't all that high: figure ~100mA for the SD card, 180mA for Ethernet, and ~480mA for the terminator as the main power sinks.  Keeping with the KISS philosophy on the power side, the regulators are oversized and have pads for extra heatsinks in case that was necessary, but during testing they barely got warmer than ambient air while outside the case.

 

If a reference would be of interest, I've added the BOM I used when making my boards to Github.  That should more or less be accurate: I dropped the unnecessary 128A3U XMEGA part down to 64A3U, as the extra memories are not necessary for the firmware.

 

I also found the TI REG710NA-2.7/250 which is a 2.7VDC out, 5V in, 30mA switching regulator, which is in the SOT-23-6 form factor, but it's about the same price as the LDO you're currently using.

 

image.png.27b80b4a63f9975b1264a50dedc57ec8.png

Share this post


Link to post
Share on other sites

I actually use the ATXmega128A1U in our product. 

 

Sadly this chip even though powerful, is super sensitive to voltage glitches and flash erasure. 

 

Mine has a bootloader so I can do software updates, Even with tons of filtering, and the BOD enabled continuously with the thresholds set it, every great once in awhile i find a device that is stuck in a bootloader reset cycle and flash memory erased. Its weird. Only reason why the bootloader remains is I have the fuses set to make it read/write locked. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×