I0908@DKAFHS1.BITNET (07/12/89)
Date: 12 July 1989, 13:43:26 SET From: Cornelius Caesar BITNET / EARN: I0908 at DKAFHS1 To: info-atari16 at score.stanford.edu By the way, George (Woodside), here is another suggestion for the next release of Turtle: Is it possible to include support for other disk formats, namely 40 tracks, double sided ( = 360 K like the normal IBM 5 1/4" drives)? I have such a drive hooked up to my Atari but cannot use the cheap 5 inch disks for my backups now. Cornelius
woodside@ttidca.TTI.COM (George Woodside) (07/13/89)
In article <8907121203.AA03380@ucbvax.Berkeley.EDU> I0908@DKAFHS1.BITNET writes: ...[edited]... >By the way, George (Woodside), here is another suggestion for the >next release of Turtle: Is it possible to include support for other >disk formats, namely 40 tracks, double sided ( = 360 K like the normal >IBM 5 1/4" drives)? >I have such a drive hooked up to my Atari but cannot use the cheap >5 inch disks for my backups now. There seem to be just slightly more disk formats in use on ST than there are ST's in the world. How that works out, I'm not sure... :^) Turtle is working it's way up to the top of mu queue, since I have to add support for the fixed TOS 1.4 Archive feature. At that time, I'll be considering a more flexible means of specifying floppy characteristics. As usual, memory is a severe problem in 1M systems (and since all my STs are 1M, you better believe Turtle will always work on 1M systems!). Another problem is not overwhelming the less technical users with options they don't understand, and passing the proper data from the front end program (TURTLE.PRG) to the real workhorse (TTLECEC.TTP), and to the RAMdisk when it has to be generated. One method I've been considering is to stop specifying the media format all together. When the backup begins, it will ask for the disk to write before filling the RAMdisk. Then, it can determine the output media characteristics, tailor the RAMdisk on the fly, build the image, and copy it. Then, check the next output disk, etc. It would make the user interface more confusing, I'm afraid. And, there is the problem of encountering an output disk with greater capacity than the RAMdisk can handle. But, in the long run, it may make it simpler. And, it would be a boon to few users I know who have one single sided and one double sided drive. -- *George R. Woodside - Citicorp/TTI - Santa Monica, CA *Path: ..!{philabs|csun|psivax}!ttidca!woodside
rthurlow@van-bc.UUCP (Rob Thurlow) (07/18/89)
I have another request for Turtle. It is great, and has saved my bacon twice
now, but I always have a problem with it's method for packing the most files
on each disk. It always finds the largest file in the current directory that
will fit on the disk and adds that next, continuing until the disk is full.
The problem is that this scrambles my AUTO folder quite badly. I have
learned to copy that manually to another disk, but I don't like it. In
general, I'd like to see Turtle only use this algorithm if it is determined
that the entire folder WON'T fit on the floppy, preserving the directory
order otherwise. The only other beef is that everything I've seen so far to
restore from Turtle disks is either buggy or slower than anything; if anyone
writes the ultimate Unturtle, I'd like to hear about it. Turtle is terrific
George, thank you from someone who's been saved by it.
--
Robert Thurlow {uunet,ubc-cs}!van-bc!rthurlow
Vancouver, BC, Canada or rthurlow@van-bc.UUCP
In the heart of Kitsilano or rthurlow@wimsey.bc.cawoodside@ttidca.TTI.COM (George Woodside) (07/20/89)
In article <184@van-bc.UUCP> rthurlow@van-bc.UUCP (Rob Thurlow) writes: >I have another request for Turtle. It is great, and has saved my bacon twice >now, but I always have a problem with it's method for packing the most files >on each disk. It always finds the largest file in the current directory that >will fit on the disk and adds that next, continuing until the disk is full. >The problem is that this scrambles my AUTO folder quite badly. I have >learned to copy that manually to another disk, but I don't like it. In >general, I'd like to see Turtle only use this algorithm if it is determined >that the entire folder WON'T fit on the floppy, preserving the directory >order otherwise. The only other beef is that everything I've seen so far to >restore from Turtle disks is either buggy or slower than anything; if anyone >writes the ultimate Unturtle, I'd like to hear about it. Turtle is terrific >George, thank you from someone who's been saved by it. You're welcome. But, I'm afraid that it's not likely that I'll be able to implement the "files-in-same-order-if-the-folder-fits" request. Turtle has severe memory problems. It, with the RAMdisk, just barely fits into the 1M machines. Adding features and options is limited by memory to the most crucial items. The most crucial, in the immediate future, is the support of the way TOS 1.4 handles the Archive bit. Next is more flexibility for diskette formats. When Turtle reads a directory, it constructs a list of files, sorted in size order. It starts at the top of the list, writing every file that fits into the RAMdisk. When it hits the bottom of the list, if it skipped any files, it needs another disk. It it didn't skip any, the folder is finished, and it's off to the next one. Trying to back that out to a sequence imitating the hard disk directory would cost considerable memory, which, in my humble opinion, would be better applied to other problems. I get frequent requests for a restore utility. One of these days...... Turtle, the virus killer, Make, and the thirty-odd other programs I've posted here (and other places) are what I needed, when I needed them. Since such trivialities as home, job, family, etc. tend to limit the amount of time I have free, I write what I need the most. When I need a restore program that does something too unusual to be accomodated by what's available now, I'll write what I need. Working for a living sure cuts into my day..... -- *George R. Woodside - Citicorp/TTI - Santa Monica, CA *Path: ..!{philabs|csun|psivax}!ttidca!woodside
neil@cs.hw.ac.uk (Neil Forsyth) (07/25/89)
In article <4821@ttidca.TTI.COM> woodside@ttidcb.tti.com (George Woodside) writes: >Turtle has severe memory problems. It, with the RAMdisk, just barely fits >into the 1M machines. Adding features and options is limited by memory to >the most crucial items. The most crucial, in the immediate future, is the >support of the way TOS 1.4 handles the Archive bit. Next is more flexibility >for diskette formats. Why not trash the GEM stuff and the Turtle Logo. I guess that would give you more memory. If a program is run as a '.prg' then you can still use the mouse via the Line-A routines & variables. You could then access text menus. Not so pretty but more memory. If a program is run from \auto it gets more memory because GEM is not up yet. How about a \auto version that only comes up when say both shifts are pressed during boot time. (Now folk will yell at me because this conflicts with their magic utility :-) >*George R. Woodside - Citicorp/TTI - Santa Monica, CA >*Path: ..!{philabs|csun|psivax}!ttidca!woodside +-----------------------------------------------------------------------------+ ! DISCLAIMER: Unless otherwise stated, the above comments are entirely my own ! ! ! ! "I think all right thinking people in this country are sick and tired of ! ! being told that ordinary decent people are fed up in this country with ! ! being sick and tired. I'm certainly not and I'm sick and tired of being ! ! told that I am!" - Monty Python ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh, Scotland, UK ! +-----------------------------------------------------------------------------+
woodside@ttidca.TTI.COM (George Woodside) (07/27/89)
In article <2868@brahma.cs.hw.ac.uk> neil@cs.hw.ac.uk (Neil Forsyth) writes: >In article <4821@ttidca.TTI.COM> woodside@ttidcb.tti.com (George Woodside) >writes: >>Turtle has severe memory problems. It, with the RAMdisk, just barely fits >>into the 1M machines. Adding features and options is limited by memory to >>the most crucial items. The most crucial, in the immediate future, is the >>support of the way TOS 1.4 handles the Archive bit. Next is more flexibility >>for diskette formats. > >Why not trash the GEM stuff and the Turtle Logo. I guess that would give you >more memory. If a program is run as a '.prg' then you can still use the mouse >via the Line-A routines & variables. Because that's not the program where the more severe memory constraint is. "TURTLE.PRG" is the GEM front end. It has the menus, mouse, etc. It does all the user interface work, and builds a command line for the other program. "TTLEXEC.TTP" is the program that does the backup work. It has to fit into memory with the RAMdisk, and that's the one that's squeezed to the max. The two programs trigger each other via shel_exec, so they have to be kept the same size in order to fit into the same memory space, once the RAMdisk is activated. Since the majority of ST users are not software hackers, I resist the temptation to implement any non-standard interface techniques. Part of the elegance of the ST is that, by having GEM built in, it provides a platform which offers the same user interface across a wide scope of programs. Given years of remembering obscure control-key commands and wierd letter-options from CP/M, MS-DOS, and UNIX, I find menus and clearly explained options in dialog boxes a real pleasure. Point and click is the next best thing to audible commands, in my opinion. -- *George R. Woodside - Citicorp/TTI - Santa Monica, CA *Path: ..!{philabs|csun|psivax}!ttidca!woodside