The goal is for Chime (in the PE) to behave like RasMol, namely,
when script and pdb filenames are not prefixed with a path, they
are looked for in the same folder from which the RasMol
application was run, or the "Start in" folder specified in a
Windows Shortcut, which we'll call the "project folder". 
Moreover, when scripts load pdb files, or call subscripts, and
when these filenames are not prefixed with a path, they too are
sought in the project folder.

The following were determined by experimentation without reference to
any javascript or Netscape documents. This may not be the only solution!

In order for Chime's default folder (for scripts and pdb's) to be
a user- specified "project folder", the html file containing the
<embed ...> invoking Chime must actually reside in the project
folder. (It did not work to prefix the <embed...> tag or the
entire html file containing it with a <base href=""> tag.
This had noticeable effects, but not the desired one. It did not work
to prefix the script name with the project folder; the main script
ran but load commands or subscripts within it sought their files
in the home folder.)

It is not possible to use a javascript variable to create a frame
in a frameset.  Therefore, a dummy document leftwrap.htm is loaded
in the left frame, and the body of this document contains only
javascript to set document.location.href equal to a string generated
by javascript.

When the project folder has not been specified, or has
been blanked, leftwrap.htm loads pe_proj.htm from the home
folder (explorer).

When the project folder is nonblank, leftwrap.htm loads
"file:///" + project_folder + "pe_proj.htm".

The file pe_proj.htm must be copied into the project folder by
the user. In this file, when project_folder is nonblank, the
busy.gif loaded at the bottom below Chime must be preceded by a
<base href=""> tag which specifies the home folder, available from
the variable top.main_base.

With the above strategy, script commands to Chime cannot use the
relative prefix "../shared/" for files because the local context
is now the project folder. Therefore, the variable shared_base
containing the absolute path to the shared folder was created in
top_vars.js, and prefixed to shared pdb files and shared scripts
(e.g. view1.spt) in loadit2.js.

----------------

LONG SCRIPTS. Chime-saved scripts can be very long. I used a
1,271-line script as a test case.  I created top.manual_spt_disconnect
to speed up execution of such long scripts.

When the message numbers only are processed, it took 22 sec for the image
to appear, and 47 seconds for ready to return.

When messages are echoed, it took 22 sec for the image to appear,
and many messages appeared, but after about 5 min, messages stopped appearing.
Ready had not returned by 10 minutes! Unclear whether it was still processing
messages or was never going to get ready again.