🚀 go-pugleaf

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