|
I have used Mark Williams C in exactly the way you describe - with
one double-sided drive on a 1040, with the RDY RAM disk. It can
be done. For a program the size and complexity of "Whack", I
needed a second disk drive, For my own sanity, I needed a hard
disk.
They do not tell you exactly what to put on each disk, because the
optimum configuration will depend on your program development
habits.
Here are some facts that Mark Williams does not make clear, but
which you must understand before proceeding.
1. The Mark Williams division onto COMPILER, COMMAND, and SOURCE
is arbitrary and may be ignored.
2. The Mark Williams C system uses several "shell environment
variables" to locate components of itself. When you issue a
command, you are usually asking it to run a program. Some
programs (ls, cat, and cd - for example) are built into the shell
itself. Others (egrep, db, cc, make) are programs that must be
loaded and executed. The Mark Williams C shell uses the
environment variable PATH to locate these programs. The PATH is a
comma-separated list of places to look for the programs that go
with the commands. The built in commands come from places called
".bin" or ".cmd", but they are always available, and I have never
found any real need to understand what these things are.
Let's assume you build your ram disk as "d:".
Therefore, for your environemnt, your PATH will contain
",d:\bin,a:\bin"
In folder a:\bin ON MORE THAN ONE DISK, you will store the
commands that you use infrequently. In the RAM disk folder
d:\bin, you will store commands you use frequently.
When you issue a command, the shell will first look in the current
directory (that's the leading comma), then on the RAM disk, and
then infolder a:\bin, for a program whose name matches your
command.
Likewise the LIBPATH variable handles the search for libraries by ld,
and the INCLUDE path handles the search for system .H files. The
TMPDIR variable is a little different, it contains only one name.
The division between COMPILER and COMMAND arrises from the need to
have all the components of the compiler accessible at once in
order for MAKE to work properly. Therefore, make, cc, cc0-cc3, ld,
and the /lib folder, and the /include folder, all have to be
available at once. The other commands (me, egrep, strip) can be
stored on another disk, and it is okay to swap to that disk before
issuing the command. There just isn't room for all the commands
to be on the same disk at the same time. For technical reasons,
the commands and programs used by the compiler and "make" need to
all be available without resorting to swapping disks.
Swapping disks, however, is a problem if your DATA is also on the
disk.
When working with a single drive and a RAM disk, I found it
necessary to put several components of the compiler on the same
disk as my source files. So, if I were working on program FOO, I
would create a disk with folders FOO, BIN, INCLUDE, and LIB, and
put msh, the compiler phases, make, and some of the libraries on
this disk.
I would have a boot disk that contained a RAM disk that was
preloaded with folders BIN, LIB, and TMP. In the LIB folder
I would put LIBC.A, and if workingon GEM program, LIBAES.A and
LIBVDI.A. There is a big speed improvement if the libraries are
on RAM disk. If there's room, but ME (microemacs) on the RAM
disk, but be careful to leave enough TMP to be able to compile
your code. If it doesn't fit on D:, you need to put ME inthe bin
folder of your FOO disk.
Any small (file size) commands that you use frequently should be
preloaded in BIN of the RAM disk. If you suddenly decide to use
the SORT command on your source code, for some reason, you swap in
the commands disk and "cp a:\bin\sort.prg d:\bin", swap back your
program disk, and issue the sort command. You may then have to
delete d:\bin\sort.prg before you have enough room on the RAM disk
for TMPDIR.
So, in summary, you need:
- COMPILER and SOURCE disks as a place to go to get infrequently
used commands, but usually you don't use either of them.
- A boot disk that contains a RAM disk backup that is preloaded
with
msh.prg profile� bin lib tmp
me.prg(?) libc.a
libaes.a(?)
libvdi.a(?)
- Each application disk:
<application-folder> bin lib include
<application source, me.prg cc0.prg stdio.h
object, and exe> cc.prg cc1.prg <others you use>
ld.prg cc2.prg
libm.a(?)
In PROFILE, set up the following:
setenv PATH ,d:\bin,a:\bin
setenv LIBPATH d:\lib,a:\lib
setenv INCLUDE a:\include
setenv TMPDIR d:\tmp
If you want real speed, find a way to arrange for your .o files to
appear on the RAM disk as well. For small programs, I took to
copying the application folder to the RAM disk, and working there
with the COMPILER disk in drive a:, but you have to remember to
copy your files back to floppy before you turn your computer off!
When doing this, I usually left me.prg on floppy in order to make
room.
Things get much easier with a second floppy drive, since
you can then have your application on a disk of it's own, and swap
between the COMMANDS and COMPILER disk in the second drive,
depending on which disk contained the commands you needed. I
rarely used the COMMANDS disk, and never the SOURCE disk. I went
after COMMANDS when I needed db, sort, egrep, but that's about all.
From this information, you should be able to figure out what files
to put where, and what you want to put in PROFILE, in order to do
the various things that you want with the RAM disk. If you still
can't figure out a specific configuration, write back and I will
help you out with it.
Regarding the 10 track formatter, I would say that you should not
use it to store your only copy of some critical data, or to ship
data to a friend in California, but if it works for you, use it
for squeezing an extra few bytes out of your limited
configuration. I use Twister (came in a magazine) and it never
fails.
(The potential for harm with the 10 track formatter is if you use
the floppy in a drive that spins too fast, the end of the 10th
track will clobber the start of the first.)
I can't say yes or not to using 1st word. The version of
microemacs I distribute from PRNSYS:: can be given an init file
that allows you to reprogram the keys the way you want them, and
has several other nice features that are missing from the one that
comes with MWC. I also have ERROR.CMD, which is compatible with
the microemacs -A switch, which you'll never get 1st word to
understand.
|