🚀 go-pugleaf

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