acphssrw@csuna.UUCP (Stephen R. Walton) (08/10/88)
After literally years of thrashing about, I have finally come up with
a completely satisfactory arrangement for my A1000 which allows
efficient usage under many circumstances. I have two floppies, 2.5 MB
of RAM, and can't justify spending even $650 for a Supra 20 MB hard
disk at present. This method depends on having a shell (either WShell
or the Dillon/Drew csh) which can be told to search particular
directories on whatever floppies happen to be inserted in the drives.
I think my experience justifies sharing what I did with others on the
net.
First: I keep an entire bootable "floppy" plus some other utilities in
VD0:. For those who haven't looked at the Workbench floppy in detail,
you can get a bare bootable floppy down to about 400K worth of stuff
by deleting: (1) All printer drivers except the one you need from
devs:printers; (2) translator.library and narrator.device; (3) C:Ed,
C:Edit, and anything which is built in to your shell (alot for the
Dillon/Drew one, like Dir, List); (4) Install ARP; (5) the Demos
drawer; (6) Notepad, Clock, and Calculator; (7) Preferences; (8)
most of the Fonts except the ones you really need. Copy the resulting
floppy into VD0:. You can add some utilities if you like; I have
about 750K of stuff in VD0: right now, what with an editor, DiskMan,
WShell, ARexx, etc. Obviously, I keep a Workbench floppy handy in
case I ever need NotePad or Preferences or...
Second: make yourself a nearly empty floppy containing a
Startup-Sequence which is the minimum necessary to get you going on
VD0:. The complete directory on my floppy is:
c (dir)
Assign BindDrivers
EndIf If
Mount readkwik
Run RunBack
SetPatch
system (dir)
FastMemFirst
l (dir)
Disk-Validator
Port-Handler
devs (dir)
MountList system-configuration
asdg.vdisk.device
s (dir)
Startup-Sequence
fonts (dir)
libs (dir)
icon.library
Expansion (dir)
(Mount and/or BindDrivers want icon.library, believe it or not.) I
have the AmigaDOS C: commands up there, not the ARP ones, so I don't
have to wait for arp.library to load from floppy. The MountList
contains an entry for VD0:. Startup-Sequence consists of:
runback setpatch ; Change to run >NIL: when 1.3 is out
; SYS:System/FastMemFirst ; if you have $C000 RAM
binddrivers
if not exists vd0:c
readkwik 1 vd0: ; Floppy 1 contains VD0: stuff
endif
assign sys: vd0:
assign C: sys:c
assign L: sys:l
assign FONTS: sys:fonts
assign S: sys:s
assign DEVS: sys:devs
assign LIBS: sys:libs
newcli from vd0:s/Startup-Sequence
Notice the upward compatibility here: When 1.3 is really out, I can
use RAD: instead of VD0: and the system will reboot straight from the
RAM disk (using its Startup-Sequence). The VD0: Startup-Sequence, in
addition to everything else, should set up a floppy cacher (FaccII or
BlitzDisk) with 512 buffers (256K), a number I find just about right.
My Startup-Sequence ends with:
run wait 3+
newwsh
endcli >NIL:
but WShell-less people would want to replace the newwsh with NewCLI
from S:Startup-CLI. This latter file would set your PATH, start up
csh, and so on.
Third: Tell your shell to look in df0:c and df1:c (and maybe df0:bin
if you're a Manx C user) as well as the "usual" places. For the
Dillon/Drew Shell, you'd use something like
set _path=C:,sys:Utilities,sys:Tools,df0:bin,df0:c,df1:c
See below if you don't have and don't want a Shell like this.
Fourth: Make up some floppies for DF0:, one for each of your
environments. Put executables in the C and/or bin directories of
these floppies. I have three right now: programming,
telecommunicating, and Word Perfect. You will probably also want to
make Execute files to set up for each environment; for example, if you
don't want to keep the Word Perfect overlays in your RAM disk, assign
LIBS: to WP:LIBS when you put the Word Perfect floppy in df0:. Notice
that since all of your usual commands are in VD0: already, you can
delete all of the AmigaDOS stuff from the DF0: floppy. For example,
my programming disk has room for the Manx as, cc, ln, make, sdb, diff,
patch, grep, plus the include files and both the normal and 32-bit
libraries. The Execute script for this disk (really an ARexx file for
me) rez's as, cc, and ln and does the appropriate Set commands for the
Manx environment variables. The telecommunicating disk holds VLT and
Comm, as well as a C directory containing shar/unshar, compress, arc,
zoo, uuen/uudecode, and Kermit (for those times when only the original
will do). Then, DF1: contains whatever you're working on: your
programming project, a disk for downloading to, or your WordPerfect
documents. Whatever. If you don't use one of the Shells I mentioned,
your Execute script will have to do a PATH DF0:C add each time, and
you'll want another Execute script which will reset your Path to one
which contains no floppy directories to avoid "Please insert disk WP:
in any drive" requesters.
With this setup, I end up with about 1.1 MB free (nearly 400K of Chip
with an interlaced screen, and nearly contiguous). Some ways I could
get more memory at the cost of longer floppy access: (1) Move the
LIBS: directory back to floppy and use the ARP LoadLib command to
shove them all into memory. This would get me about 200K, which I'd
probably add to FaccII's buffers. (2) Move more things which only get
executed once on bootup (like FaccII itself and MemWatch) to a floppy
directory--I have an Assign Startups: VD0:Startups at the top of my
VD0:S/Startup-Sequence which would simply be changed to DF0:Startups if
I did this.
There it is. I hope this too-long posting helps someone else out
there with similar needs.
Stephen Walton, representing myself swalton@solar.stanford.edu
Cal State, Northridge rckg01m@calstate.BITNETdavid@ms.uky.edu (David Herron -- One of the vertebrae) (08/11/88)
Hey yeah. That's very close to what I'm planning to do -- as soon as
I get unburied from under reconfiguring the mail system here that is --
The main different thing I'm planning on doing is to zoo a lot of the
stuff which'll be residing in C: eventually (only leaving out the stuff
required to run the startup-sequence up to the point of un-zoo-ing
the archive and switching C: over to rad:c) (The reason for using
zoo instead of arc is that zoo does directory trees properly, and
also it compresses everything instead of only text files)
Doing this should give me more stuff (effectively) on the boot disk.
I have never looked much at ARP. (haven't had the time) Is it a *lot*
smaller than the standard stuff?
--
<---- David Herron -- The E-Mail guy <david@ms.uky.edu>
<---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<----
<---- Tell me Mr. Brian ... what year did csws1 win the Kentucky Derby?ejkst@cisunx.UUCP (Eric J. Kennedy) (08/11/88)
In article <1359@csuna.UUCP> acphssrw@csuna.UUCP (Stephen R. Walton) writes: > >After literally years of thrashing about, I have finally come up with >a completely satisfactory arrangement for my A1000 which allows >efficient usage under many circumstances. I have two floppies, 2.5 MB >of RAM, and can't justify spending even $650 for a Supra 20 MB hard >disk at present. Sounds very familier. I have the same setup, and my solutions were about the same. My ultimate solution is a hard drive, though. (It's now on order, let's hope I see it while I still need it.) >Obviously, I keep a Workbench floppy handy in >case I ever need NotePad or Preferences or... ^^^^^^^ Yeah, right. A power user like you? I even took a generic 'more' program, named it notepad, and shoved it in sys:utilities, just for the odd icon that wants it. >(Mount and/or BindDrivers want icon.library, believe it or not.) I Yeah, when binddrivers reads the drivers in sys:expansion, (It might even require df0:expansion, or BootDevice:expansion, or whatever; It wouldn't work out of vd0:sys/expansion with sys: assigned to vd0:sys) it also reads the .info files. Why? I don't know. I ask you, is this documented anywhere? Not that I've seen. [Lots of detail deleted] It all sounds familier, but right now I'm back to about a 100K vd0:, and devs:, libs:, l:, and fonts: back on workbench:. Why? LaTeX & Preview -- 1 Meg (fast loop mode, -R) ARexx -- ?? K Uedit -- 600 K (with _lots_ of custom macros and spelling checker with ram resident dictionary) Superbase Pro -- 400 K Utils-out-the-butt -- probably 200 K These are approximations, and probably slightly exaggerated. Still, you can see why something had to go. Running all these at once makes for a heck of a system, though. Even with all that, running without a hard disk is only a pain in the neck. With the amount of raw data I'm collecting, though, a hard disk has become (close to) a necessity. >Third: Tell your shell to look in df0:c and df1:c (and maybe df0:bin >if you're a Manx C user) as well as the "usual" places. For the >Dillon/Drew Shell, you'd use something like > set _path=C:,sys:Utilities,sys:Tools,df0:bin,df0:c,df1:c I've come up with a neat solution. I've done this, and put all of my excess cli commands, tools, utilities, etc., ad nauseum, on a series of disks with color coded labels, called 'RedTools', 'WhiteTools', 'BlueTools', etc. It's great. This rambling brought to you courtesy of my research, which keeps me up at all hours, and in strange moods... (maniacal screaming heard reverberating throughout the computer center --"I HATE graduate school!!") -- ------------ Eric Kennedy ejkst@cisunx.UUCP
dmose@agora.UUCP (Dan Mosedale) (08/15/88)
>The main different thing I'm planning on doing is to zoo a lot of the >stuff which'll be residing in C: eventually (only leaving out the stuff >required to run the startup-sequence up to the point of un-zoo-ing >the archive and switching C: over to rad:c) (The reason for using >zoo instead of arc is that zoo does directory trees properly, and >also it compresses everything instead of only text files) > >Doing this should give me more stuff (effectively) on the boot disk. A much faster way to do this is to get ahold of the DosKwik pd programs on Fish disk one-twenty-something. These programs allow you to save your entire vd0: or rad: on an unformatted disk. They are written to the disk sequentially in their own format, and therefore read into ram much more quickly than unzooing them. My setup involves booting off a customized workbench disk, copying the ReadKwik program to vd0:, and then reading all my cli commands into vd0: from a DosKwik disk. \\ "These opinions may in some way represent those of my employer... // \\ but I seriously doubt it." // \\ // Dan Mosedale dmose@agora \\ // \\/ ...tektronix!reed!percival!agora!dmose \// Newsgroups: comp.sys.amiga Subject: Re: Efficient RAM usage for hard-disk-less folks Expires: References: Sender: Reply-To: dmose@agora.UUCP (Dan Mosedale) Followup-To: Distribution: na Organization: Advanced Solutions, Hillsboro, OR Keywords: >The main different thing I'm planning on doing is to zoo a lot of the >stuff which'll be residing in C: eventually (only leaving out the stuff >required to run the startup-sequence up to the point of un-zoo-ing >the archive and switching C: over to rad:c) (The reason for using >zoo instead of arc is that zoo does directory trees properly, and >also it compresses everything instead of only text files) > >Doing this should give me more stuff (effectively) on the boot disk. A much faster way to do this is to get ahold of the DosKwik pd programs on Fish disk one-twenty-something. These programs allow you to save your entire vd0: or rad: on an unformatted disk. They are written to the disk sequentially in their own format, and therefore read into ram much more quickly than unzooing them. My setup involves booting off a customized workbench disk, copying the ReadKwik program to vd0:, and then reading all my cli commands into vd0: from a DosKwik disk. \\ "These opinions may in some way represent those of my employer... // \\ but I seriously doubt it." // \\ // Dan Mosedale dmose@agora.UUCP \\ // \\/ ...tektronix!tessi!agora!dmose \//