Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!mcsun!ukc!harrier.ukc.ac.uk!hobby.ukc.ac.uk!wabe
From: wabe@ukc.ac.uk (W.A.B.Evans)
Newsgroups: comp.sys.atari.st
Subject: Re: Ram Disk
Message-ID: <345@hobby.ukc.ac.uk>
Date: 24 Jun 91 18:29:23 GMT
References: <310asplundm@physc1.byu.edu>
Reply-To: wabe@ukc.ac.uk (W.A.B.Evans)
Organization: Computing Lab, University of Kent at Canterbury, UK.
Lines: 64

In article <310asplundm@physc1.byu.edu> asplundm@physc1.byu.edu writes:
>I am presently using EDISK on my ST, and I love the reset-proofness of it,
>but I find it annoying that I can't change Ram Disk sizes without a cold
>re-boot.  Can anybody either tell me what I am doing wrong, or tell me about
>a better program?
>
>Matt Asplund
>BYU
>Provo UT

	As far as I am aware, ALL reset proof ramdisks involve a RESET if
they are resized. In this EDISK is no exception.

	However the main point of this reply is to draw your attention to 
Mark Williams Co.'s RDY ramdisk utility that is now PUBLIC DOMAIN - even if 
you are not a registered licensee of Mark Williams "C". This is FAR more
sophisticated than EDISK (I am familiar with both!) - in that it allows
you to configure Reset-Proof ramdisks that are Booting or non-booting and
you can simultaneously load as many ramdisks as memory and/or volume letters
(C:\,D:\,....P:\) allow. You may also configure the ramdisk to have the FAT
structure of a FLOPPY so you can SECTOR-copy the entire contents of floppies
quickly onto them (using DFT.PRG - a program within DFSUITE2 - also available
on the network) - or you may use 16-bit FATS for additional access speed. 
Further they may be saved WITH CONTENTS to .PRG files on floppy or hard 
disks and loaded again with ease by simply executing them.

	As Mark Williams reputedly no longer write software for the ST, there
was a hiccup when I tried to use my old RDY installations on a new STE. I
looked into the problem, to discover it was to do with the RESET VECTOR not
being correct for the STE. A minor hack produced RDE.PRG - the STE-compatible
version of Mark Williams' RDY.PRG - which, with Mark Williams Co.'s 
permission, was distributed on atari.binaries.st last January or early 
February. This has solved similar problems for many who recently "upgraded"
to an STE - as is testified by the many Emails I've received.

	One further advantage is that saved RDY ".PRG" files may be packed
with an efficient packer (like PFXPAK - also PUBLIC DOMAIN) that makes them
extremely economical to store on Floppy. Working this way with a 4-Mbyte STE
I can load many different utilities on different ramdisks simultaneously and
have not so far felt the need for expensive error-prone hard-disks.

			Anyway, hope this may help some readers.

					W. Alan B. Evans
					[ wabe@ukc.ac.uk ]

P.S.:  Whilst EDISK is not as sophisticated as RDY/RDE, it is excellent
as a SINGLE reset proof ramdisk. It works equally well on the new TOS as
well as the older versions - which means it "looks up" the proper RESET
VECTOR, *((long *)0x4), in Supervisor Mode before executing it - which was
the fault with RDY (or at least the version of RDY I was given when I 
upgraded to Mark Williams "C" version_3.0.6). When I upgraded I never was
given the sourcecode of this "newer" RDY that worked satisfactorily on 4Mb
machines (presumably there was insufficient space on the upgrade disk) - so
I would be obliged if anyone who bought version 3.++ of Mark Williams "C"
and who presumably got this "updated sourcecode" - which is now also PUBLIC
DOMAIN (or so I learn from a FAX from Mark Wms' Dale Schumacher - but I don't
really know where to access it) could be bothered to Email me this. True I 
could probably get it from Mark Wms. Co. also - but, as they've left the 
ST-scene, let's not bother them. I would then, I believe, be able to modify
it so that a single RDY.PRG would work (like EDISK) on all ST machines
 - the only slight doubt is whether there is enough room in the bootsector
of a self-loading RDY ramdisk to include the few bytes of additional code 
required to "look-up" the reset address vector before using it.