051332@UOTTAWA.BITNET.UUCP (06/03/87)
I have been digging around in the bundles of PD goodies housed at PROG-A16 at CANADA01 and the ATARINET LISTSERVer at UHUPVM1, and I became interested in two programs that recently emerged from Atari: FOLDRXXX.PRG and DISKBAR.PRG, not for what they do, but for the tricks that they use to do it. (Please note, I am not a programmer, but the ideas may be of some value). It has occurred to me that these tricks could be used in other PD programs making them easier and more pleasant to use. Trick 1 FOLDRXXX.PRG looks at it's own filename to allocate space for a number folders that the user might want to use. If the users need more space, the name of the file can be changed with the Show Info ... option from the desktop. It also saves space on disk, as there is no .RSC file needed. Trick 2 DISKBAR.PRG this program uses the last 64 pixels in the last raster line on the monitor to show disk activity. This demonstrates how a small amount of screen space can feed a lot of data to the users. (While we're at it, why not a string of bars at the bottom? One for each drive or RAM DISK) How one might use them (just examples) ETERNAL2.PRG. Easily the nearly most penultimate RAM disk ... yet, I understand that it won't boot on the new megas. How about ETLXYYYY.PRG where X is the disk identifier, and YYYY is the default size? This will get rid of the RAMDISK.DAT file (1k of disk space for 4 bytes of active data) and help prevent the user from munging the order of the files in the AUTO folder when they attempt to change the default. Four digits to define size should take care of the megas for some time. BARREL.TOS the intelligent print spooler. It could use the first trick to set the default size for the barrel on boot, and how's about a 'fuel guage' to show the amount of space left in the barrel. i.e. the last pixel in each scan line could be used. One pixel on for each KB of stuff in the barrel. In low res, that would take care of a 200k barrel, med. or high res, 400k. BARRELXX.TOS could be configured to 2388k, more than enough for the megas if each pixel = 10k. Make it user selectable. I know that nobody will really count pixels, but then, who really looks at the car fuel guage? You just glance at it and decide if it will get you where you want to go. MEMSIZXX.PRG (no its not out there yet) an extension of the above idea. The top raster line could be a memory available guage. Again, one pixel = 10k free memory. In low res, that would be a 3000k guage. Some weeks back somebody was talking about building a super twisting, bad sector header, 82 track, 10 sector/track disk formatter utility. If it is no too late ... how about FMTVWXYZ.PRG, where V W X Y and Z are single diget or letters that set the defaults for the formatter. i.e. V 0 = SSDD, 1 = DSDD; W, 0 = normal format, 1 = fast format; X, 0 = 80 tracks, 1 = 81 tracks, 2 = 82 tracks; V, 0 = 9 sectors/track, 1 = 10 sectors/track; Z, 0 = now volume name, 1 = prompt user for volume name, 2 = calculate an 11 digit random number volume name. The opening screen could display all the options with the defaults in reverse video (the user could override these) and an additional option that would change the 'name' of the program to reflect the new defaults, or just use the new setting for the current run. Blue Sky About those empty data, program and folder ICONs. In high res there is at least a 12 X 12 pixel hole in the middle of each ICON. Could a program jump in after a disk access and draw pixels into this hole that would provide useful information? i.e. the size of the file 1 pixel = 1 or 5 k, or the read/write status of the file, or the number of items in a folder. Could a space-remaining-on-disk bar be added to the directory window, again shown as a row of pixels along the top of the window. This type of activity might be too slow for continuous use, but it might be a useful accessory that could be called from the desktop. As a rule, I think that the first pixel in a line on the screen or window should not be used. There is too much text that sits up against the left side of the screen, but the top or bottom scan lines and the last pixel in a line in a window or screen should be used to feed the user useful information. 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
ftw@datacube.UUCP (06/11/87)
A lot of that sounds good, but there is a problem with things like: FOLDXXX.PRG. That is, you would have to have a copy of the program for each permutation of the program name you wish to keep around. In the case of FOLDXXX, this is no issue, but in the case of the disk formatter you mentioned, it might eat into your free disk space some. What the TOS filesystem needs for this is the U*ix notion of a "link". (Everyone knows about links, right? :-)) This is how "cp", "ln" and "mv" all work.