Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!munnari.oz.au!uhccux!uhunix1.uhcc.Hawaii.Edu!kiki
From: kiki@uhunix1.uhcc.Hawaii.Edu (Jack W. Wine)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: SCSI chip project
Message-ID: <12873@uhccux.uhcc.Hawaii.Edu>
Date: 6 May 91 07:43:35 GMT
References: <12824@uhccux.uhcc.Hawaii.Edu> <5578@wucc.waseda.ac.jp> <12850@uhccux.uhcc.Hawaii.Edu> <5599@wucc.waseda.ac.jp>
Sender: news@uhccux.uhcc.Hawaii.Edu
Organization: University of Hawaii
Lines: 55


>Reverse engineering of WD1772 cannot be difficult. My explanation was too 
>terse: WD1772 has a data separator inside and I said replacing a better
>data separtator would be cheaper and more up-to-date. Programming SCSI
>interface is not terribly easy. At least for me. If future TOS supports
>arbitrary SCSI bus read/write commands, the burden for us will be greatly
>reduced. I don't like that NCR thing very much because it's a bit CPU
>dependent.

Thanks for relating this experience, because it points me toward a possibly
better solution to directly replacing the floppy controller chip with the NCR
5380. If a microcontroller (mcu) was connected to the ST DMA chip instead, then
compatibility with TOS could still be retained!  It would receive and trans-
late all the WD 1772 commands to the appropriate SCSI commands for the NCR
5380.  

A SCSI floppy drive would bootup and execute a program to flip a spare sound
port bit which would signal the mcu that all subsequent commands are for the
NCR 5380.  Maybe a good mcu with huge ram buffer could be connected to multi-
ple 5380s?  Then something like OS/9 would be required???  

The only problems with this approach are that I don't know WD 1772 commands
and I don't have any schematics, timing data, and signal definitions for the
ST.  Does the Atari Developer Docs give complete info concerning the entire
line of ST/TTs?  If someone could provide a short review of it, it would be
appreciated.

>I personally think ICD's ATARI-SCSI board is very good for using hard drives
>(including st506 things) but when it comes to using it for other purposes like
>connecting a streamer tape, image scanner or a printer, the burden for me is
>too great to bear. Even minix-st source code doesn't help too much. My experi-
>ence is that there are so many vendor specific commands and non-standard op-
>tions for SCSI. But I suppose I must learn those things one of these days.

Since the TT has a SCSI, am I wrong to assume that Atari does have some sort
of SCSI software toolkit?  If not, then that should be a top priority project
for them, because connecting SCSI peripherals to the Atari should be made 
simpler and standardized for developers.  Easing the porting of SCSI peripherals
would increase the value of the ST/TT line immensely.

>Sigh. I remember a chap once built a SCSI monitor on his own that displays all
>the happenings along the SCSI bus, e.g. such and such command with such and
>such arguments was issued by unit what and unit what responded etc . etc. I
>just don't feel like building one myself. I am really envious of your attach-
>ment to SCSI.

A SCSI monitor is a good idea!  Maybe Atari or someone will develop one for the
TT; it would be great if it was fashioned like a software debugger.  Instead
of forcing you to remember specific SCSI commands, it should be smart enough to
let you point to a device and execute a battery of appropriate commands.

Since my STe went to Atari heaven, all I can do is think about how to make it
better!

Jack