AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (08/03/88)
>Date: Mon, 1 Aug 88 19:36:41 GMT >From: Tom Schenck <ucsdhub!jack!crash!maddie@UCSD.EDU> >Subject: Re: GS/Mac toolbox "interpreting" >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. I don't even *want* to be "68000-like"! If I want a 68000, I'll buy a machine that uses one. Phantom slots? The IIgs has "ports" and "slots." Ports are like cards that aren't really physically plugged in, like on the //c, so I guess this is what you're talking about. Please explain why you think this slows down the system. The only "instruction trapping" the IIgs has is through vectors that the 65816 calls for BRK and COP instructions. Please explain why you think this slows down the system. >The toolbox routine (like ANY toolbox routine) is designed to take into >account all of the possible uses for the routine. Probably true in many cases. If you need speed in a particular case, by all means do it your own way. >The speed decrease you get by using the toolbox routines is not worth >the compatablity issue. [...] I would like to see a game written with >the toolbox. Sure, some applications you do need more speed than the toolbox provides. In that case toolbox use may be minimal. There *is* a way to stay compatible with super-hires on future machines, even if the screen memory moves: Use the GetAddr (or was it GetAddress? One of them is in MiscTools; the one you want is in QuickDraw II) to get the address of a table that tells you the starting address of each of the 200 scan lines on the super-hires screen. If you want to se *animation*-intense games written with QuickDraw II, you'll probably have to wait until we have a faster IIgs. There are certainly plenty of *other* kinds of games written in the desktop environment, supporting desk accessories (& therefore using the toolbox). >>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. WHOA! Try "Get a new version of the system disk." On both the Mac and the IIgs, the system disk makes numerous patches to ROM-based toolbox routines when you boot. If there's something I'm being vague on, please specify. >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. Apple is busy enough just writing ONE version of each toolbox routine. If they had to write 79 specialized versions of each one, it would never get done. However, *you* and everyone else is free to write nice modular packages of routines and install them, for the duration of your program, as a "user toolset" callable through the $E10008 vector in a way exactly parallel to the way system tools are called (through $E10000). >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 --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