AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (02/03/89)
>Date: Wed, 1 Feb 89 22:32:54 -0500 (EST) >From: "Jeremy G. Mereness" <jm7e+@andrew.cmu.edu> >[...] My concern is because AE is a third party company, and I am not >certain how the Transwarp will work; I can only guess that it works >like the old Transwarp; an onboard chip w/ its own onboard high-speed >memory. I don't know how much would be compromised from the >motherboard, or how much GS/OS depends upon the same. [...] I recall >some programs choking with the old Transwarp, and others choked on >GS's with Unidisks. [Oops--I left out this paragraph in the first copy I mailed you, Jeremy.] I don't know exactly how it works either, but the whole idea of an accelerator board is to speed up the hardware; I don't see any reason for it to affect software compatibility except for real-time stuff (like games) that doesn't take the intelligent step of synchronizing itself with the 1/60-second tick counter. As long as the thing knows when to revert to the old speed, there should be no problem. And I assume there will be a way to ask the TransWarp to pretend it doesn't exist if it's ever necessary. -- What was causing the choking w/ the old Transwarp? How can the old Transwarp cause trouble on "GS's with Unidisks" if it doesn't work with the GS? (It doesn't, right? Otherwise why would we need a new one?) >Again, I don't have much experience w/ GS/OS except that GS owners >here complain that it is too slow. They choose not to use it. Are there any systems where the users _don't_ compalain that it's too slow? I'm confident that speed will continue to improve in future releases of the system disk; excitement about GS/OS will grow as more File System Translators are (hopefully) released [allowing transparent use of disks from non-ProDOS file systems], and as more applications are written to take intelligent advantage of the disk caching and other GS/OS features. >DA's are fun and even useful, but I don't want to sacrifice >performance because of them, or because an operating system that >supports them relies on virtual memory for its most basic >functions. There is no virtual memory on the GS. Certain kinds of things are loaded when they're needed, though. The closest it gets to virtual memory is something called "dynamic segments"--pieces of programs can be loaded when they are used rather than when the main program (or the main part of the desk accessory, or driver, or whatever) is loaded. >The Macintosh must access its system disk to open windows, draw >dialog boxes, cut/paste/copy, perform any file operations in an >application, print, and scroll downward to view more of a document >(maybe that's why Mac drives do not have "in use" indicators). "Must" is the wrong word. Most applications _do_ cause disk access when doing the things you mention, but they could easily avoid it if they wanted to. What's happening in most of those cases is that resources are being loaded off disk (out of the application's resource fork). These resources could be templates for windows, alerts, or dialogs; they could be dynamic code segments; they could be just about anything. By the way, some mac drives _do_ have in-use indicators. In any case, there's an audible in-use indicator--you can hear the disk accesses. >[...] The events I described occur on a Mac with 1 megabyte of >memory. Experimenting with a RAMdisk revealed that none of that >memory is used by the system as a cache, which I think of as a kludge >anyway. What was the cache setting in the control panel? A cache is definitely _not_ a kludge--it's a really keen idea that you will find implemented in many systems and in many ways. On mainframes, often RAM is cached so that frequently-used information gets stored in special high-speed (and much more expensive) memory. A disk cache is the same idea--on the Mac, and in GS/OS, frequently-used disk blocks are kept in RAM for fast access. The difference it makes is amazing, especially if you have deep subdirectories; directory blocks and bitmap blocks are the most commonly cached kind. >That damned machine used no more than 512K to do its job, and still >could not swallow the whole document. The only solution is a hard >drive, which is very expensive. What application were you using? Sounds like it wasn't written too intelligently. >DOS 3.3 and Pro[DOS] 8 loaded themselves entirely into memory. Thus, >programs had instant access to all the routines necessary for I/O. >Surely, GS/OS has a larger job to perform, but the most basic >functions of a DOS should be memory resident. DOS 3.3 and ProDOS 8 were _small_! GS/OS is bigger, but it _is_ all loaded into RAM. Any disk access is caused directly or indirectly by the application you're running; given enough memory, an application can do most of the disk access when it starts up if it wants to. >[...] And if you ever grow tired of the easy-to-use interface, you >had better take a year off work w/ your $5000 system to write another >one. Have you seen MPW, the Macintosh Programmer's Workshop? I think it would make you happy. >jeremy mereness >jm7e+@andrew.cmu.edu >r746jm7e@cmccvb (bitnet) --David A. Lyons bitnet: awcttypa@uiamvs DAL Systems CompuServe: 72177,3233 P.O. Box 287 GEnie mail: D.LYONS2 North Liberty, IA 52317 AppleLinkPE: Dave Lyons