Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!think!ames!sdcsvax!ucbvax!UOTTAWA.BITNET!051332
From: 051332@UOTTAWA.BITNET (John Turnbull)
Newsgroups: comp.sys.atari.st
Subject: Re: KERMIT (& XMODEM, YMODEM, ARC, and UUDECODE)
Message-ID: <8707200156.AA03649@ucbvax.Berkeley.EDU>
Date: Sun, 19-Jul-87 21:50:56 EDT
Article-I.D.: ucbvax.8707200156.AA03649
Posted: Sun Jul 19 21:50:56 1987
Date-Received: Mon, 20-Jul-87 03:48:50 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 119


This is a repost of some ideas that I sent out some weeks back that
filed to make it to the INFO-A16 digest due to a failure at SCORE.
Sorry to those that have seen it before.

Two interesting programs drifted out of Atari some time back:
FOLDRXXX.PRG and DISKBAR.PRG, both by Landon Dyer, I think.
(both can be obtained from PROG-A16@CANADA01 or ATARINET@UHUPVM1)

The interesting thing, to me, isn't what the programs do, but how they
do it:

FOLDRXXX.PRG reads its own filename to determine the number of
folders that the user wants to use on his system.  The filename then
acts like a mini resource file for the program.  The advantage being
that if the user wants to change the default settings for the program
he need only use the  'Show info ...'  option from the desktop to
change the name of the program, rather than firing up the program
to reset the defaults or using a text editor to dicker with the
resource file.

DISKBAR.PRG is a strange thing that writes a flashing bar in the last
32 pixals of the last two scan lines on the screen each time that a disk
is read or written.  OK I use it, but more importantly it demonstrates
how a considerable amount of information can be quickly presented to the
user without using a large amount of screen space.

The PD wishlist
How can these techniques be used?  The following are some ideas and
examples only:

A) Mods on the FOLDRXXX theme:
BARREL.TTP, Moshe Braner's intelligent disk-print spooler.  When this
program is installed at the start of a session it asks the user how
large a barrel to install in multiples of 12 k.  BARRELXX.TTP, where
XX is an integer from 1-99 would install a barrel up to 1188k -- more
than enough for the mega STs and would save boot time, as the user
would not need to answer the same question each session.  The program
could also use the hold down 'ALT' key trick if the user wanted to
change the default.

ETERNAL2.PRG*, the nearly penultimate RAM disk uses a resource file that
contains only 4 active bytes of information, yet eats 1k of disk space
and adds one additional file to the AUTO folder.  ETRYXXXX.PRG,
where 'Y' is a character disk identifier, and XXXX is the size in Kbytes
would save the space on disk, and make changing the default size of the
RAM disk easier with the 'Show info ...' option.

DCFORMAT.PRG & DCFMTCLR.PRG*, the new super flexible disk formatting
utilities seem less amendable to this type of modification as there are
so many options, yet, most users will have a preferred format that they
use for most disks.  When you fire up these programs, you are presented
a menu of options, seemingly a large number of permutation, yet some of
the options are mutually exclusive. FCFTXXXX.PRG allows 4 characters for
option data.  GEM allows only upper case letters and the numbers 0-9
in a filename (and '_' on good days) which is equal to 36*36*36*36 >
1.5 million states.  An additional option in the menu might be
'SAVE DEFAULT' causing the program to compute a coded representation of
the chosen options in the menu, then rename the original file to
reflect the chosen states.  Clearly. the new name might be a bit odd:
DCFTJQ_9.PRG or DCFTK43T.PRG, and the users could not edit the name to
make changes, but you could keep one or two different copies (one
82 track fast formatter for the ST and one IBM formatter) for most work
and still use either if you needed a one of disk for some special reason.
(BTW.  Please add an option to name the disks.  Some of the disk library
utilities require a unique name for each disk.  A random number disk
name option might be nice too.)

B) Mods on the DISKBAR theme:
DISKBAR2.PRG, how about a bunch of diskbars, one for each disk all along
the bottom of the screen?

FUEL.PRG (no it does not exist yet, and I can't write it), A program
that uses the pixals in the first scan line to show the amount of free
ram in memory, say 1 pixal = 1k free space.  On a monochrome screen
you could see if you had any fraction of 600k free memory, in medium
res, 300k.  For the mega STs, you might need to bump that up to
1 pixal = 10k (make it user selectable i.e. FUELXX.PRG).  This would be
useful when you have a large RAM disk, several desktop utilities, and
a word processor all in memory, and decide to edit 3 or 4 things at a
time.  Clearly, nobody will count pixals, but do you really look at the
fuel guage in your car, or just glance and decide if it will get you
where you want to go.

BARRELXX.PRG (again) Reserve the last 2 pixals in each scan line to
show how much junk is in the barrel.  At 1 pixal = 1k of junk, a med
res screen can keep track of a 300k barrel.  (We must leave the first
pixals in a scan line unaltered as too much text is over on the left
side of the screen.)

Finally:
FILESIZE.PRG (also does not exist in this form yet).  The desktop ICONS
have 12X12 pixal holes in the middle of them.  It would be nice if you
could get some idea of the size of a file by looking at the ICON.
If the 2nd through 11th pixal in the 2nd scan line *inside* an ICON was
used to show file size at a rate of 1 pixal = 1k (= 1 disk block) and
the pixals in the 3rd through 11th scan line showed size at a rate of
1 pixal = 10k, then filesize could be estimated from 1k to 909k.  The
same program might also reserve the top two scan lines inside the
directory window to indicate the amount of free space (in blocks) on
the disk. This might not be practical to do continuously, but a desktop
accessory trigger might be used to update the filesize by reading the
FAT table on request, or it might be done each time a new directory is
opened or altered.

Well, that is more than enough for now.  There is no way that I could
implement any of there ideas, so I'll leave them to you, and for
discussion.  /JT

*  Sorry, authors of DCFORMAT and ETERNAL2, but I have forgotten your
names.  I did not intend to slight you.  /JT


John Turnbull,          NetNorth: 051332@uottawa
30 Somerset Ave,        BITNET:   051332@uottawa
Dept. of Biology,       ARPAnet:  051332%uottawa.bitnet@wiscvm.wisc.edu
Univ. of Ottawa,        UUCP:     ...!psuvax1!051332%uottawa.BITNET
Ottawa,  Ontario,       JANET:    051332%uottawa@rl.earn
CANADA,  K1N 6N5.       ICBM:     45 25' 33'' N  75 39' 05'' W