051332@UOTTAWA.BITNET (John Turnbull) (07/20/87)
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
051332@UOTTAWA.BITNET (John Turnbull) (07/20/87)
oops: That last note was to have the subject: PD wish list (sort of a repost), Seems I had two outgoing files prepaired at one time. KERMIT: A week or so ago I posted a request for information on XMODEM, YMODEM, ARC and UUDECODE utilities that will run under VM/CMS, or a KERMIT that can eat 1k packets for the ST. Well, no information on the X-Y MODEMS, or KERMIT, but there is an unARC-UUD-UUEcode utility that will run on IBM mainframe lookalikes. If there are people out there on BITNET/NetNorth/EARN who would like a copy of this utility, drop me a note. No it will no manufacture ST programs that will run on the mainfram, nor is it a good idea to deARC before you download, but you can use it to peek into UUE or ARC files to read the .DOCs, and you can test the .ARKs to see if they are alive before you download them to your ST at 300 baud. I am restricting the offereing to BITNET/NetNorth/EARN because the MODULE is not ARCed or UUENCODED itself (or you would not be able to use it) so you must be able to receive IBM mail and have a RECEIVE command at your site. If you live at an IBM that is not on these networks and have some idea how I can get this MODULE to you, please drop me a note with a full BITNET address. We can experiment. /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
$CS7125@LSUVM.BITNET.UUCP (10/22/87)
I am having trouble downloading software from a mainframe to my 1040ST. Maybe somebody recognize the problem and advise. The mainframe is an ibm370 using v m cms. It has a kermit program to download to remote terminals. I have tried several terminal programs on my ST, but with no luck. The problem I was having when using uniterm 1.8 was that it would stop at random times during the tran smission, and not resume. Sometimes it would get to 20 or 30 blocks. But if it stopped, it would not resume transmission. Thank you Chris
V115LUE3@UBVMSC.CC.BUFFALO.EDU (gunslinger) (10/17/89)
Is there anyone at the University of Buffalo who has the kermit protocol?
Our computing center isn't carrying a copy of it anymore and I need to get my
hands on it. If not, could someone in the north-east please mail me there
phone # so I could download it Xmodem from them? Any efforts would be greatly
appreciated. (Preferably 1200 baud)
Thanks in advance,
Philip Smolin
v115lue3 @ubvmsdmjducey@rodan.acs.syr.edu (Matthew J. Ducey) (12/08/90)
Okay, I got some help setting up a .kermrc file, but I'm getting error messages when I try to user kermit(go into it). Can I get some help here on what this file should include? I think it doesn't like me setting the packets to 1024. -- But I still like my ST... HP-48SX GEnie M.DUCEY SOCEUR (A) Bitnet mjducey@suvm "But Sgt. Airborne, look how high we are"! mjducey@rodan.acs.syr.edu
cmm1@cunixa.cc.columbia.edu (Christopher M Mauritz) (12/09/90)
In article <1990Dec7.225948.29797@rodan.acs.syr.edu> mjducey@rodan.acs.syr.edu (Matthew J. Ducey) writes: >Okay, I got some help setting up a .kermrc file, but I'm getting error >messages when I try to user kermit(go into it). Can I get some help here >on what this file should include? I think it doesn't like me setting >the packets to 1024. Hey there. The ST version of the Kermit software really sucks. That's coming from someone from the home of Kermit, Columbia University. You'll be MUCH happier if you use UniTerm 2.0e. It is a far better implementation and much easier to deal with. You can probably find this program at your nearest anon FTP site. It is freeware. Cheers, Chris ------------------------------+--------------------------- Chris Mauritz |D{r det finns en |l, finns cmm1@cunixa.cc.columbia.edu |det en plan! (c)All rights reserved. | Send flames to /dev/null | ------------------------------+---------------------------
gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl) (12/11/90)
In article <1990Dec8.165438.25412@cunixf.cc.columbia.edu> cmm1@cunixa.cc.columbia.edu (Christopher M Mauritz) writes: >Hey there. The ST version of the Kermit software really sucks. Hey there. The version of Kermit for the ST that I am familiar with was written long before Uniterm matured into the fine program that it is now. If you want to be fair, then simply say "Use Uniterm, it's much more modern." Don't insult the work of someone who put a lot of work into a nice, small, and unfortunately slow Kermit implementation.