[comp.periphs] Making a Mac talk SCSI to a Sun

roy@phri.UUCP (02/09/87)

	We've got a bunch of Sun 3/50's and are thinking of getting some
Apple Macs, mostly to do MacPaint type of stuff (which the Suns would be
great at if only the software existed, and in a form we could afford).  It
would be kind of nice if we could get the Suns and the Macs talking to each
other in some faster way than running xmodem at 9600 baud.  It occured to
me that both machines have SCSI ports, and there might be some way to make
them communicate that way.

	Being basicly ignorant of the details of how SCSI works, I have no
idea if this is practical, or even possible.  Would it be possible, for
example, to use the SCSI ports to do simple file transfer?  How hard would
it be to write some software to make the Sun emulate a SCSI disk for the
Mac?  Of course we wouldn't waste a whole Sun as a Mac disk server, but if
it was possible to have a SCSI-server daemon running in the background, it
might be an attractive way to go.

	So, is this idea brilliant, assinine, or somewhere in-between?
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

"you can't spell deoxyribonucleic without unix!"

tim@hoptoad.UUCP (02/11/87)

I believe there would be problems with having two SCSI masters.  A better
solution would just be to use the products intended to connect computers
togethers, that is, networks.  Put the Macs on an Appletalk network and use
a FastPath gateway to connect to the Suns on Ethernet; or put the Macs
directly on Ethernet using the new EtherSC.

You can call Kinetics for more information on the Fastpath and EtherSC:
(415) 947-0998.  Walnut Creek, CA.
-- 
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)

Second Coming Still Vaporware After 2,000 Years

bob@osu-eddie.UUCP (02/11/87)

In article <2594@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:

> (...) It would be kind of nice if we could get the Suns and the Macs
>talking to each other in some faster way than running xmodem at 9600
>baud.

How about using a Kinetics FastPath box as an Appletalk-to-Ethernet
gateway, and get some software that lets you do TCP/IP things (Telnet,
FTP, the works) on the Mac?  Kinetics can point you to some (for
money), as can mod.protocols.appletalk (for free).  That way one
hardware investment serves your whole network.

> (...) How hard would it be to write some software to make the Sun
>emulate a SCSI disk for the Mac?  Of course we wouldn't waste a whole
>Sun as a Mac disk server, (...)

How about making the Sun NFS server also an AFP server for the Mac,
like Apple's new Mac-based file server?  Somebody's bound to do it
very soon...
-- 
 Bob Sutterfield, Department of Computer and Information Science
 The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277
 bob@ohio-state.{arpa,csnet} or ...!cb{osgd,att}!osu-eddie!bob
 (614) 292 - 0915 or (614) 292 - 5813

martin@minster.UUCP (02/13/87)

In article <1784@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>I believe there would be problems with having two SCSI masters.  A better

No, SCSI (as opposed to SASI) was explicitly designed to allow any, or
all, of the devices to be masters. If having two masters dosn't work, then
one of the machines dosn't implement SCSI correctly (or completely!).

I don't know about the implementations on the Sun, or the Mac, but all
high performance (which I assume the Sun interface, at least is) interfaces
should implement disconnect-reconnect to allow overlapped seeks, and
this automatically gives one the multi-master capability (again so long
as the software is not broken :-).

	Martin

PS
	The review of the Mac+ in November '86 Byte states that the
throughput of the SCSI interface is 320K bytes per second; does anyone
know if it is really this slow? SCSI is rated at 10M Bits (= 1.25 M Bytes)
per second, where is the factor of (almost) four going?

morrist@ncrcae.UUCP (02/16/87)

In article <540211194.20192@minster.UUCP> martin@minster.UUCP (martin) writes:
>In article <1784@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>>I believe there would be problems with having two SCSI masters.  A better
>
>No, SCSI (as opposed to SASI) was explicitly designed to allow any, or
>all, of the devices to be masters. If having two masters dosn't work, then
>one of the machines dosn't implement SCSI correctly (or completely!).
>
>I don't know about the implementations on the Sun, or the Mac, but all
>high performance (which I assume the Sun interface, at least is) interfaces
>should implement disconnect-reconnect to allow overlapped seeks, and
>this automatically gives one the multi-master capability (again so long
>as the software is not broken :-).

The real question is whether one or both of the SCSI devices can act
as both a Target and an Initiator. In every SCSI transaction, one device
acts as a target, and one acts an initiator. In the case of SCSI disk and
tape devices, the host acts as the initiator and the disk or tape controller
 acts as the target. In the case of host to host communication, at least one
of the devices (and preferably both) must be capable of acting as
a target as well as an initiator. Most SCSI protocol chips allow
both target and initiator operation. It does however, take significant
additional software to allow the target role to be used.

fjo@ttrde.UUCP (02/16/87)

In article <540211194.20192@minster.UUCP>, martin@minster.UUCP writes:
> 
> PS
> 	The review of the Mac+ in November '86 Byte states that the
> throughput of the SCSI interface is 320K bytes per second; does anyone
> know if it is really this slow? SCSI is rated at 10M Bits (= 1.25 M Bytes)
> per second, where is the factor of (almost) four going?

The SCSI speed limit on the Mac+ is due to the fact that there is no
DMA used for SCSI data transfer. All data transfer (in good Apple 
"squeeze every drop of power from the CPU" tradition) is done directly
by the 68000.  Perhaps this will change on the MacII? 

cramer@clem.UUCP (02/16/87)

In article <540211194.20192@minster.UUCP> martin@minster.UUCP (martin) writes:
>In article <1784@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>>I believe there would be problems with having two SCSI masters.  A better
>
>No, SCSI (as opposed to SASI) was explicitly designed to allow any, or
>all, of the devices to be masters. If having two masters dosn't work, then
>one of the machines dosn't implement SCSI correctly (or completely!).
>
>I don't know about the implementations on the Sun, or the Mac, but all
>high performance (which I assume the Sun interface, at least is) interfaces
>should implement disconnect-reconnect to allow overlapped seeks, and
>this automatically gives one the multi-master capability (again so long
>as the software is not broken :-).

This is not exactly correct.  Disconnect/reconnect support is not related
to having multiple initiators (referred to above as "masters").
Disconnect/reconnect is a SCSI facility that allows a target controller
to give up the SCSI bus during the execution of a command if it is not needed.

Here is sketch of how disconnect/reconnect works:

	Initiator (usually the host CPU) selects the target controller
	(in this case assume a disk controller).  As part of the selection 
	protocol, the initiator sends a message to the disk controller 
	indicating it may disconnect if it would like.

	The intiator sends a command to the target.  Let's assume it is 
	a read command.

	The target realizes that performing the read will require a seek.
	It sends a disconnect message to the initiator to indicate that
	it wants to disconnect from the SCSI bus.

	Time passes and the head finally reaches the appropriate track.
	The target signals that it wants to reconnect to the SCSI bus.

	The initiator and target perform the reconnection protocol, and
	the SCSI bus goes into DATA IN phase.  Data is transfered
	from the target to the initiator.

	The target indicates command completion by sending the status
	and command completion messages.

Please note that disconnect/reconnect support is optional according the SCSI
spec.  Sun introduced disconnect/reconnect support in our 3.3 SunOS release.

Supporting multiple initiators is optional under the SCSI spec.  Many SCSI 
implementations, including Sun's, do not support multiple initiators. 

Due to the fact that Sun does not support multiple initiators, interfacing
a Mac to a Sun SCSI port would be non-trivial.  I suspect it would be more
productive to try to run the AppleTalk protocol through a serial port -
the Sun 3/50 uses the same Zilog serial chip as the Mac.

Sam Cramer	uucp:	{cbosgd,decwrl,hplabs,seismo,ucbvax}!sun!cramer
		arpanet: cramer@sun.com

tim@hoptoad.UUCP (02/17/87)

In article <540211194.20192@minster.UUCP> martin@minster.UUCP (martin) writes:
>In article <1784@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>>I believe there would be problems with having two SCSI masters.  A better
>
>No, SCSI (as opposed to SASI) was explicitly designed to allow any, or
>all, of the devices to be masters. If having two masters dosn't work, then
>one of the machines dosn't implement SCSI correctly (or completely!).

I am well aware of this; as I pointed out, the Mac does *not* implement SCSI
very well.  The SuperMac people replaced the SCSI Manager with their own
software and tripled performance (combined with a lower disk interleave, of
course) for the Dataframe XP drives.  I would be very surprised if it had
any debugged or real capabilities not exploited by the existing peripherals.

>I don't know about the implementations on the Sun, or the Mac, but all
>high performance (which I assume the Sun interface, at least is) interfaces
>should implement disconnect-reconnect to allow overlapped seeks, and
>this automatically gives one the multi-master capability (again so long
>as the software is not broken :-).

But this is the Sun, and both the Sun and the Mac would have to be "high
performance".  I don't know SCSI very well, but the disconnect-reconnect
sequence sounds like it may be exactly what the SCSI Manager lacks.

>	The review of the Mac+ in November '86 Byte states that the
>throughput of the SCSI interface is 320K bytes per second; does anyone
>know if it is really this slow? SCSI is rated at 10M Bits (= 1.25 M Bytes)
>per second, where is the factor of (almost) four going?

It is true; the reason they got away with it was that it was so much faster
than the HD20 and other pre-Mac Plus Mac hard disks, except the ones that
required major surgery.  The reason is bad software.  But SuperMac isn't
talking about what they fixed, and neither is anyone else who knows.
Perhaps we could all work it out here?
-- 
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)

Celibacy is just soft-core eunuchry.

jgh@miduet.UUCP (02/26/87)

In article <1821@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>
>....  I don't know SCSI very well, but the disconnect-reconnect
>sequence sounds like it may be exactly what the SCSI Manager lacks.
>
The hardest thing that you probably will have to add is not the disconnect-
reconnect, which is an optional performance feature, but for at least one
end of the Sun-Mac connection to know about being a target as well as an
initiator. Most device drivers I have met only know about initiate, and
quite a few 'intelligent' host interfaces also.


In article <540211194.20192@minster.UUCP> martin@minster.UUCP (martin) writes:
>.... SCSI is rated at 10M Bits (= 1.25 M Bytes) per second....
>
I thought top-whack speed was something like 2MByte/sec (async mode,
the one most people use). Can someone with a spec tell us?  I have
at least two products here claiming 1.5M.
The usual reason for a 1.25M speed is an ESDI disk, whose raw data rate
from the HDA is 10M bits/sec. Many 5.25" drives with embedded scsi controllers
are based on the same HDA that is used for an equivalent capacity ESDI drive.

(HDA = head-disk assembly)

Jeremy.		(I don't speak for my employer)
-- 
Jeremy Harris	jgh@gec-mi-at.co.uk	...!mcvax!ukc!hrc63!miduet!jgh