Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!mbaker
From: mbaker@ucs.adelaide.edu.au (Matthew Baker)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Hardware Project: RAM disk
Message-ID: <3563@sirius.ucs.adelaide.edu.au>
Date: 5 Jun 91 13:13:47 GMT
References: <QcGzpBG00UgI9Yw5kd@andrew.cmu.edu>
Organization: Information Technology Division, The University of Adelaide, AUSTRALIA
Lines: 75

(I'm posting rather than mailing because I think this has potential to be
an ST topic)

From article <QcGzpBG00UgI9Yw5kd@andrew.cmu.edu>, by es2a+@andrew.cmu.edu (Eric Stuyvesant):
> 
>     I've been considering building some sort of RAM disk for my 4 Mb
> 1040STE, and was wondering if anyone else out there would be similarly
> interested...

If it works, I might build one (huge :)

>     Necessary components of said RAM disk:
> 
> * use of SIMMs
- SIPs would result in a slightly cheaper device. Use machine pin socket strip
instead of $IMM $ocket$
> * support of at least 2 Mb in a minimum construction
> * support for different sized SIMMs (256K, 1Meg, 4Meg)
> * as cheap as possible
-A major hassle with _anything_ using DRAMS is the refresh timing. The
TI 746301 is the only DRAM controller I have had much experience with, and
that was extremely frustrating. Hence I use SRAMS in all my projects. :)
> 
> *  Cartridge port interface, similar to the Alpha Systems RAMdisk.  This
> has the disadvantage of being slow, and very non-portable to non-ST
> systems.

Not necessarily slow, but inconvenient. Means a large box stuck to the side of
the machine.

> 
> *  Serial interface, possibly with a native CPU.  This would definitely
> be slow, even at 19200, but would be supremely portable to non-ST
> systems.

Considered building a similar system using an 8086/1772 to use my old ss 
floppy drive - problems were with the speed as you suggest. Lousy thruput.

> *  SCSI interface, possibly with a native CPU.  I imagine that this
> would be rather expensive to build, due to the cost of SCSI chipsets and
> an ACSI->SCSI converter board.  It would, however, be useful on non-ST
> systems.  Throughput would probably be not bad.
Native CPU more or less essential, (68000 series (eg 010, 070) weould be good)
The NCR 5380 - SCSI chip, is not very expensive. Easy to talk to as well.
> 
> *  ACSI interface, possibly with a native CPU.  This would probably be
> easier and cheaper to build than the SCSI version, but would be much
> less useful on non-STs.

True, less useful. Easier to talk, can do it all without an ACSI chip
really (my developmental network adapter uses ACSI for speed - MIDI is
way too slow.)
> 
> *  CPU replacement board.  Basically, replace the CPU with a CPU+memory
> daughterboard.  Fast, but again, not useful on non-STs.

Not worth the effort. Way too complicated, and not much room in an ST.

>     I'd like to look at these possibilities in more detail, and try to
> get at the relative costs and strengths of each of these, then build
> something.  Is there anyone else out there who would be interested in
> working on this?  I'm sort of surprised that there are no commercial
> SCSI RAMdisks on the market.  Or am I missing them?  Any comments are
> welcome, as right now I don't have the hardware knowledge to build one
> of these or the software knowledge to write the drivers.

Software is not too difficult... hardware, well, if you're not into 
hardware, I don't wish to be a downer, but build something simpler first :)

It's a _very_ nice idea. Would make a _fantastic_ /tmp device. SCSI sounds
good. More comments?

> -Eric Stuyvesant

 
Matthew