Here is some trivia on the file system that, in conjuction with a good peeker
and poker, will alllow you to set your file system in a cleaner configuration.

The file management system on the 600 essentially works on two levels.  The
first level is the "DOS".  The second level is the "HHOS" that actually runs
the computer.  These two systems work together to produce the information you
see when you list or "Disk Ref" [F3] a disk.  The first byte we will cover is
the DOS byte, and the second will be the HHOS byte.

The DOS byte is the byte which produces the R, H, and A tags on all files.
This byte is the twelfth byte in the 32 byte DOS information block at the
beginning of each file.  The R tag means that the file is in ROM.  The H tag
means that the file will not be displayed by a Ref [F3], but it can still be
listed with the system manager list command.  ENVIRON.SYS is an example of a
hidden file.  The A tag simply means that the file was generated by system
application program.  I have noticed that programs Xmodemed from CIS often do
not have the A tag, and that files saved from Basic in ASCII usually do not get
tagged either.  For neatness sake I remove the A tag from applications so I can
tell them apart from data files.  Here are the byte values for the various
letter combinations:

R:01   R H:03   R H A:23   R   A:21   H A:22   H:02   A:20   No Tag:00

Other values caused the file to be "lost".  The second byte of interest is
located in the HHOS information block which follows the DOS information block.
This information is only valid for application files.  Our HHOS byte is the
38th byte in the file, and it may have three different values.  "V" means that
the file is visible all the time.  "S" means that the file is only visible when
other file that use it are present.  "I" means that the file is invisible all
the time.  DOS bytes take precedence over HHOS bytes.  As an example, based on
the above explanation, you would expect to find an "S" for the HHOS byte in the
file DAT.!41.  It turns out that it is a "V", but the presence of the DOS "H"
makes it function like an HHOS "S".  I know, this is starting to get a bit
confusing...but this byte has its uses.  In my 224K system I keep the contents
of the disk that came with the computer in memory for easy access.  Normally
this would clutter the system manager screen up.  But by setting the HHOS byte
to "I", and leaving the DOS byte alone the file will be hidden while in memory,
but visible when it is on disk with a Ref [F3].  Now you say, what about the
conveinence of moving the cursor over the filename and running?  Well, it is
even more conveinent to assign the file to function key and access it as a pop-
up!  Or, at least it would seem that if you needed to format a disk to save a
file, pressing a control key to format the blank disk would be easier than
stopping everything and exiting, etc.

The program that I used to make my modifications was Rampatch.  I am not
familiar with any other peek and poke program that will hunt files up for you
in memory for modification.  If your program does not have this capability, you
might be better off making the modifications to the file while it is on disk.
The first 32 bytes, or the DOS block that I refer to are found in sectors 5-11
on the disk.  The HHOS byte is the 6th byte in the actual file, and lower case
letters may be used in the place of upper case letters.  A space will produce
the same result as a "V".  If you accidently put a bad byte value in the DOS
byte, putting a valid value in that byte will restore the file.  Any questions
about this process may be sent to Steve Ringley, 73727,1202