Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucsdhub!jack!crash!maddie From: maddie@crash.cts.com (Tom Schenck) Newsgroups: comp.sys.apple Subject: Re: GS/Mac toolbox "interpreting" Message-ID: <3258@crash.cts.com> Date: 1 Aug 88 19:36:41 GMT References: <8807302312.aa12461@SMOKE.BRL.ARPA> Reply-To: maddie@crash.CTS.COM (Tom Schenck) Organization: Crash TS, El Cajon, CA Lines: 85 In article <8807302312.aa12461@SMOKE.BRL.ARPA> AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") writes: > >The IIgs toolbox is designed to support a Desktop-based environment >(menus, windows, etc) that strongly resembled the Macintosh >desktop-based environment. This environment has nothing to do with >the 68000. > >If you mean by "simulate" that the IIgs desktop environment is any >less "real" than the Macintosh desktop environment, I disagree. > The //gs has something called "phantom slots" hard wired into the system, and also has a limited instruction trapping routing included in the hardware. Both of these things slow the //gs down, and also quallify it as Mac-like. However, it does NOT qualify it as 68000-like. Sorry. > [ description of the //gs toolbax call] > [The] amount of overhead is not amazing, although it's not tiny, either. >Usually it is small compared to the amount of time spent *in* the >toolbox routine! > The toolbox routine (like ANY toolbox routine) is designed to take into account all of the possible uses for the routine. And a lot of the time, the routines are written to be small, and thus (usually) slower than a routine written for a specific case. The trade-off for speed and compatablilty (at least in my book) is obvious. Speed. The speed decrease you get by using the toolbox routines is not worth the compatablity issue. A program heavy on math can usually avoid the toolbox routines, but a program that uses graphics and sound, and possibly a few special modes of graphics, needs to use a least a FEW of the many toolbox routines. I would like to see a game written with the toolbox. Before I get any flames about games and their usefullness, etc. I should point out that I primarily program games, so that is the primary focus of my arguments. If it's not a game, it's going to use graphics (if I write it that is.) So the toolbox routines are out, in my book. >On the Macintosh, a range of 1-word opcodes is reserved; when >executed, a "trap" to a particular vector occurs. This vector points >to the trap dispatcher, which uses the opcode to look up the address >of the toolbox routine to call. > >A small amount of "interpretation," if you want to call it that, is >not a large price to pay to be able to fix toolbox bugs (by >replacing ROM routines, etc) without needing to recompile all your >existing applications! Actually, I don't see much use for the finished machine having this feature. The end-user isn't going to have a way (usually) to modify the toolbox routine that had the problem. And I also would appriciate an explination of exactly what it is you're trying to say here. >You are perfectly free to bypass the toolbox. > >You will end up writing lots of code yourself that is already in the >toolbox. You will have to do direct access to the hardware, so you >will forfeit compatibility with future hardware revisions. The code that I end up writing is going to be a lot more speed efficient, and also a lot more specific. Toolbox routines are generalized a great deal. I still hold fast to my theory that the ROM should hold a debugger (or monitor if you preffer) and the bootstrap routine. Any and ALL toolbox routines should be included on a disk given out (at a small fee of course) to end users, and as part of the developer package. The routines included on the disk would NOT be the same routines that would have been in ROM. They should be highly specialized, and fast. They should be a lot of things. They should also include generalized routines, and memory- efficient routines. And then and only then would I use a toolbox routine. >--David A. Lyons a.k.a. DAL Systems > PO Box 287 | North Liberty, IA 52317 > BITNET: AWCTTYPA@UIAMVS > CompuServe: 72177,3233 > GEnie mail: D.LYONS2 Tom Schenck, Member 52nd St Development Team -- UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!maddie ARPA: crash!pnet01!maddie@nosc.mil INET: maddie@pnet01.CTS.COM Disclaimer : The only company who's thoughts are my own is owned by me. Tom Schenck, member 52nd Street Development Team.