Jump to content

SCSI to Ethernet Adapter on New Hardware


Recommended Posts

  • Replies 114
  • Created
  • Last Reply

Top Posters In This Topic

Hi !

 

First congrats on your project ! And for all the work done, it’s impressive and promising for the future !

 

I’m trying a new design heavily based on yours but with a stm32 and firmware upgrades using usb and I was wondering about something you stand in your README : «The '574 is unnecessary and a result of a bad design choice on my part. It could be replaced with a '245. » Why the 574 is a bad choice ? The 245 is not a buffer with latch so you could miss frames right ?

 

Thank you again !

Link to post
Share on other sites
13 hours ago, ronan said:

First congrats on your project ! And for all the work done, it’s impressive and promising for the future !

 

Thanks!

 

13 hours ago, ronan said:

«The '574 is unnecessary and a result of a bad design choice on my part. It could be replaced with a '245. » Why the 574 is a bad choice ? The 245 is not a buffer with latch so you could miss frames right ?

 

The original design used the 574 with the latch clock hooked to /ATN, with the idea being to potentially fiddle with doing (slow) synchronous transfers; during periods when the board needed to read when /ATN was not active, an extra 74126 gate was used to block /ATN and let the microcontroller drive the latch. In the end, I felt like this caused more problems than it was worth, so I pulled the /ATN hookup from the released board but left the 574 there to minimize the disruption to the code. If I had to do it over again, I'd choose the 74LVT245 just to save an I/O pin - with async SCSI, the initiator will hold the data until you negate /REQ, so you're not in any danger of missing data.

 

The Xmega chip here does support firmware updates over USB, if that's the main thing you'd like to get. I didn't think to implement it on the board, but it could be added fairly easily by moving some signals around. AFAIK, all Xmega chips ship with a USB bootloader, so you wouldn't necessarily need a PDI programmer this way. That said, there's lots of advantages to an Arm chip here, so if you do make something let us know, I'd love to see it! :)

Link to post
Share on other sites
6 hours ago, saybur said:

The original design used the 574 with the latch clock hooked to /ATN, with the idea being to potentially fiddle with doing (slow) synchronous transfers; during periods when the board needed to read when /ATN was not active, an extra 74126 gate was used to block /ATN and let the microcontroller drive the latch. In the end, I felt like this caused more problems than it was worth, so I pulled the /ATN hookup from the released board but left the 574 there to minimize the disruption to the code. If I had to do it over again, I'd choose the 74LVT245 just to save an I/O pin - with async SCSI, the initiator will hold the data until you negate /REQ, so you're not in any danger of missing data.

 

Just to make thing clearer you would design something like the the image I attached to this post ? (Maybe directly connect the DIR Pin to GND/VCC to choose and fix the right direction of the 245).

 

If I understood well you would use the 245 only as a level converter. But for instance the STM32 as a high input threshold at 1.88V so it would not even need a chip between the physical port and the chip.

 

6 hours ago, saybur said:

That said, there's lots of advantages to an Arm chip here, so if you do make something let us know, I'd love to see it! :)

 

Sure ! I'm pretty close to releasing a PCB, I will keep you posted and release everything on github !

 

My idea with the STM32 is that indeed it's an ARM mcu but it also supports well USB and I was thinking maybe in the future to be able to do some ethernet other USB. So that we would be able to share files between a computer and the vintage macs using only USB :) 

 

 

SCSI Ethernet Design Upgrade.png

Edited by ronan
Link to post
Share on other sites

Great graphic, that's how I'd do it. Since the 245 is permanently reading from the bus you should be able to tie DIR without a problem. In case the bus floats for some reason (bad termination?) you might want to toggle /OE only when you know data is on the bus. The LVT transceivers have a 10ns/V transition time recommendation with "outputs enabled," so the current scuznet firmware does toggle /OE to avoid having the outputs on except when necessary, in case the SCSI bus is being sluggish during transitions. I don't know if this is strictly "needed" or not.

 

For bus reading, the buffer is there mainly for 5V protection (the Xmegas are TTL compatible at 3.3V). You could probably get away with not using the buffer, depending on what's on the bus: if all devices are open-collector, you should only see 2.63-3.0V on the lines. However, SCSI does allow push-pull drivers on most lines, and those can output up to 5.5V and still be in spec. I'm not familiar with the STM32s, so they may have 5V tolerant GPIO pins to avoid the problem.

Link to post
Share on other sites

Thanks for clearing everything ! This really helps understanding things about the SCSI protocol which is not 100% clear for me yet. By the way do you have any good documentation about the low level part of the protocol ?

 

Okay I have a first version of the board with an stm32 which is heavily based on your design. I attached the schematics if you want to have a look, as well as a first render of what the board would look like. Power would be delivered by a usb port which could also be used to update the board firmware.

 

I also put the SCSI and the ethernet connectors on two different sides.

 

If you got any remark don't hesitate :)

 

I'll continue routing the board tomorrow.

 

I did setup a github here : https://github.com/ronangaillard/68net

hardware.png

68net Schematic.pdf

Edited by ronan
Link to post
Share on other sites

just wondering if anyones had a similar issue of getting a crash to macsbug with when trying to shutdown the ir mac when the drivers are installed but the device isn't connected. i built one of these up and  this seems to happen every time its not hooked up via scsi unless i remove the driver from the extension folder. just not sure if its an issue on my end with my setup or if others had had similar issues.. again this is a driver issue not a issue with the scuznet board

Link to post
Share on other sites
On 11/3/2020 at 4:10 PM, ronan said:

If you got any remark don't hesitate :)

That board rendering looks great. Does your version also have an SD card for HDD emulation? Having all the connectors on two sides seems better than 3 (like USB/power and Ethernet on one side).

Link to post
Share on other sites
2 hours ago, tt said:

That board rendering looks great. Does your version also have an SD card for HDD emulation? Having all the connectors on two sides seems better than 3 (like USB/power and Ethernet on one side).

 

I did not plan to add a SD slot, I would like each project to do a single task (ie. SCSI => to ethernet) and I know other projects such as SCSI2SD already do a great job at emulating disks. Is this something you were looking for ?

 

You are right about the connectors, I'll try to move the USB to the ethernet side :)

Link to post
Share on other sites
1 hour ago, khaz said:

Does it support power via the SCSI connector? Or does it need an external power supply?

Unfortunately from what I know SCSI does not provide any power.

 

Maybe the next step would to design a connector such as SCSI2SD to get the power from the inside of the computer, and design the ethernet card to be fitted inside the Mac.

Link to post
Share on other sites
11 minutes ago, ronan said:

Unfortunately from what I know SCSI does not provide any power.

 

You can run small stuff off termination power.  This is what scsi2sd/macsd/others do, the power connector is for cases when that fails, but is not mandatory.  The successfulness of it varies depending on model of mac, mind; the Plus doesn't provide any at all unless you modify the logic board, and some other models are patchy.  But it's possible in many cases.

Edited by cheesestraws
Link to post
Share on other sites

Agreed, I’ve never even connected the internal power for a SCSI2SD (except on a Plus).  Even (most of) the accelerator boards for 68000-based Macs that include SCSI add termination power.  In my experience it’s 100% reliable to power these low-draw devices.

Link to post
Share on other sites

That's super interesting ! I plugged the power connector on my scsi2sd but I never tried without !

 

I'm going to upgrade my design to get power from SCSI and let a usb port for power fallback in case !

 

On question, would guys prefer to use a scsi -> ethernet board outside the Mac (ie. connected to the DB25 port) or inside the Mac ?

 

@saybur : I don't want monopolize your topic, I can create a new one if you want to

Edited by ronan
Link to post
Share on other sites
On 11/4/2020 at 6:43 PM, Chopsticks said:

just wondering if anyones had a similar issue of getting a crash to macsbug with when trying to shutdown the ir mac when the drivers are installed but the device isn't connected. i built one of these up and  this seems to happen every time its not hooked up via scsi unless i remove the driver from the extension folder. just not sure if its an issue on my end with my setup or if others had had similar issues.. again this is a driver issue not a issue with the scuznet board

 

I haven't had this ever happen to me, usually it just complains about the device not being present. What computer and OS are you running?

 

On 11/3/2020 at 6:10 PM, ronan said:

Okay I have a first version of the board with an stm32 which is heavily based on your design. I attached the schematics if you want to have a look, as well as a first render of what the board would look like.

 

I've been badly distracted by the (lame) real world but I did manage a quick pass through the schematic. I'm completely unqualified to look at the STM32 side of things, so the following are just observations on the SCSI / Ethernet parts. Like I've mentioned elsewhere in this thread, I'm no expert on this or anything, so definitely feel free to ignore the below advice without any concerns! :D

  • All the driver chips are LS series in the schematic; I'm assuming you probably want LVx parts instead.
  • It might be good to add 100nF decoupling capacitors on all of the ENC28J60 power pins. I didn't read anything in the datasheet on this, but it is likely best-practice.
  • I didn't see a connection for the "CD" signal on U8's /CE pin, but I may just be missing it. If you're running short on free I/O pins RDBP is pretty useless and could be dropped; I'm pretty sure the only time I've used it is to do a diagnostic check on the TDBP driver.
  • R11 is the only 22ohm series terminator left on the Ethernet SPI bus. I added them to be on the safe side, since the board had decently long traces going to the Ethernet chip, but they may not be needed on your board.
  • Per the note by U4, be aware that combo of adjustment resistors should produce 2.63V for the termination resistors instead of 2.85V. This is an alternate configuration for the 100ohm resistor packs.
On 11/5/2020 at 7:16 AM, ronan said:

I'm going to upgrade my design to get power from SCSI and let a usb port for power fallback in case !

 

Over on the Bluepill SCSI device thread in Peripherals there are some reports of issues with certain systems not supplying great power; assuming that you get 0.7V drop from the Mac diode supplying TERMPWR, you're running close to the 1V dropout voltage on the LM1117 supplying +3.3V. You might want to switch to a low-dropout regulator if you're sourcing from TERMPWR. Also be aware that the Ethernet PHY can draw up to 180mA by itself when transmitting - this is not a low power board, unfortunately. IMHO I'd definitely keep a provision for external power.

 

On 11/5/2020 at 7:16 AM, ronan said:

@saybur : I don't want monopolize your topic, I can create a new one if you want to

 

It doesn't bother me at all, but it might be a good idea to make a new thread to let people not following this one know that a different approach is out there. A couple users noted early on that they would have liked to see this design based on an ARM chip anyway, so there may be interest for sure.

 

If you do make a new one I'll definitely be following along, I'm interested in seeing where this goes. :)

Link to post
Share on other sites

Thanks for your feedback about the schematics ! They did evolve a bit since my last message and are going to evolve a bit this weekend according to some minor sides I have and your feedback.

 

17 minutes ago, saybur said:

All the driver chips are LS series in the schematic; I'm assuming you probably want LVx parts instead.

Yes you’re right, the digikey sourced parts are LVx parts but I did not have LVx components in my kicad libraries so I used LS. I’m going to fix the wording this weekend.


 

17 minutes ago, saybur said:

I didn't see a connection for the "CD" signal on U8's /CE pin, but I may just be missing it. If you're running short on free I/O pins RDBP is pretty useless and could be dropped; I'm pretty sure the only time I've used it is to do a diagnostic check on the TDBP driver.

There is a connection to « CD » , I set up solder bridges to activate the connection or directly connect CE to GND. I did not connect CD to the STM32 though, is this something useful ? 
 

 

19 minutes ago, saybur said:

Per the note by U4, be aware that combo of adjustment resistors should produce 2.63V for the termination resistors instead of 2.85V. This is an alternate configuration for the 100ohm resistor packs.

I saw that on your GitHub yes. I’m going to look for more adjusted resistors on digikey and see if I can get closer to 2.85V. Should the terminator resistor arrays value be adjusted if I change this voltage ?

 

24 minutes ago, saybur said:

IMHO I'd definitely keep a provision for external power.

Good advice, I did plan to keep USB as a power source if needed.

 

26 minutes ago, saybur said:

It doesn't bother me at all, but it might be a good idea to make a new thread to let people not following this one know that a different approach is out there. A couple users noted early on that they would have liked to see this design based on an ARM chip anyway, so there may be interest for sure.

 

If you do make a new one I'll definitely be following along, I'm interested in seeing where this goes. :)

Great ! I’ll start the thread once I finish a first « final » version of the design this weekend !

 

Thanks again for the time taken for your feedback :)

Link to post
Share on other sites
47 minutes ago, ronan said:

There is a connection to « CD » , I set up solder bridges to activate the connection or directly connect CE to GND. I did not connect CD to the STM32 though, is this something useful ? 

 

Oh, OK, I get where that's going now. I'd suggest not doing it that way; there are situations where you will need to read the data bus when C/D is not asserted. It would probably be easiest to assign it to a free I/O pin to maximize your control.

 

51 minutes ago, ronan said:

I saw that on your GitHub yes. I’m going to look for more adjusted resistors on digikey and see if I can get closer to 2.85V. Should the terminator resistor arrays value be adjusted if I change this voltage ?

 

Yes, they're specific to the 2.63V variant. Standard SCSI terminators are 110ohm, so that'd be the likely choice.

Link to post
Share on other sites
On 11/7/2020 at 10:56 AM, saybur said:

 

I haven't had this ever happen to me, usually it just complains about the device not being present. What computer and OS are you running?

it turns out that my build chain on my mac is doing something strange, it would build the firmware and when flashed to the xmega the sd hdd would work but not the lan, and it would freeze up the se/30 mac i was running it on.. i ended up switching to a linux VM and building the firmware on that and now everything works as expected

Link to post
Share on other sites
On 11/5/2020 at 9:57 AM, ronan said:

 

I did not plan to add a SD slot, I would like each project to do a single task (ie. SCSI => to ethernet) and I know other projects such as SCSI2SD already do a great job at emulating disks. Is this something you were looking for ?

 

You are right about the connectors, I'll try to move the USB to the ethernet side :)

 

I do not want to favour creeping featurism. But … both your board and SCSI2SD have only one (1) SCSI port. Which means, that with a Compact Mac and the external port, I can connect either SCSI2SD or 68net/Ethernet via SCSI. Not both. I could put one inside newer Macs (SE, SE/30 …), but for the Plus, e.g. or when I want to keep the original hard disk in there, I can’t have both devices at the same time.

 

That’s why either a 2nd SCSI port for passing through the bus (best option), or a SD card would be nice. If you think of adding one, my preference would be SD over MicroSD, as SD is easier to integrate in self-made cases.

Link to post
Share on other sites

Now that I've got this running 100% I was wondering if there is any way to make the driver load on a unsupported Mac model. my SE/30 has an install of 7.6.1 (os 8 at some stage too) and I had to 'fool' the Mac to think its a Quadra 700 for it to boot this version of the system, but the NuvoLink extension complains on start up that this model isn't supported so I was wondering if there's anything I can hack in resedit to get it to load?

Link to post
Share on other sites
On 11/12/2020 at 7:16 PM, Chopsticks said:

Now that I've got this running 100% I was wondering if there is any way to make the driver load on a unsupported Mac model. my SE/30 has an install of 7.6.1 (os 8 at some stage too) and I had to 'fool' the Mac to think its a Quadra 700 for it to boot this version of the system, but the NuvoLink extension complains on start up that this model isn't supported so I was wondering if there's anything I can hack in resedit to get it to load?

 

I'm not very knowledgeable about the Mac driver side of the equation. There might be a hack to make the driver skip the gesalt check, but if there is I'm not aware of it.

 

Another avenue might be to try the Focus drivers instead. From what I've read the Focus EtherLAN SC is basically just a rebranded Nuvolink SC, but I've never tried using their drivers on a scuznet board. I suspect they probably changed some stuff in the INQUIRY response to keep this from being easy.

Link to post
Share on other sites

I'd like to have the adapter inside my SE/30, daisy chained to the SCSI2SD. 

 

Wouldn't it be great if one would put a raspi 3A or something in there too, running an AppleTalk Server for the SE? And a lighthttpd so you can configure it with netscape from the SE/30 side? Then, one could route the connection over the Wifi of the Raspi, which could also provide a smb share over Wifi…

 

Just a thought.

 

 

Link to post
Share on other sites

I'm doing a revision of the hardware to add extra features and correct some bugs. @ronan also made good observations about things to fix, which is appreciated. Here's the list of what I'm working on:

  • Move from KiCad 4 to KiCad 5, and change the footprints to match the awesome new library versions.
  • Add USB for reprogramming & config updates (not sure if USB-C or just micro at this point, and I'm uncertain about powering via USB or leaving the barrel jack).
  • Change the linear regulators to use more reasonable packaging, they're significantly oversized.
  • Fix the oversized footprint on the barrel jack if it stays.
  • Extend the board depth by 0.5mm to fit the case better, it tends to knock back and forth a bit.
  • Shift the Ethernet / power plugs to get a bit more room on the back.
  • (Possibly) add a jumper to use TERMPWR for board power.
  • (Possibly) switch from the microSD socket to a full SD socket and upgrade the software to allow hot-plugging.

For anyone who has built one of these, were there other things you found annoying and/or features you thought were missing?

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...