gandreas@umn-d-ub.D.UMN.EDU (Glenn Andreas) (07/13/88)
In article <13829@apple.Apple.COM> tecot@apple.apple.com.UUCP (Ed Tecot) writes: >In article <46753DN5@PSUVM> DN5@PSUVM.BITNET (D. Jay Newman) writes: >>Another thing, I would like to see the Color Quickdraw code patched for the >>Plus/SE machines, so that the color calls would revert to the basic b/w calls. >>This can't be too hard, can it? > >The reason this isn't done is because it would cost over 4K of system heap ^^^!!!! >space. > > _emt 4K!!! 4K!!! You mean to say, that my system heap will go from 380k to 384k!! Jeez. In these days of inits that take up 70k+ I think that 4k is a very small price to pay for this. Well, how about an INIT that does this. And while we're at it, how about an INIT that will catch the 68881 codes and translate them into SANE calls (I've heard rumors about such things). If you make them INIT's, then they can optionally be used. Then my mac plus will seem like a mac II (only slower. and only 1 bitplane. and no slots. and no 68020 opcodes.) Seriously, if I had my choice between the color quickdraw patcher with the fake 68881, and some of the other things that come standard with the system (Map CDEV, MacroMaker) or many of the other INITs that are nice-to-have-and- are-usually-loaded-even-though-they-take-up-memory, guess which one I'd pick. On a related note, does anyone have any ideas on how to patch (old) Quickdraw to draw on two different bit planes to sort of fake it's old color system? You see, I once wrote this old VBL routine that did page swapping at the right times to produce a true gray scale (black, dark gray, light gray, white). There was a lot of flicker, but it might be useful for limited applications (I wrote part of a gray-scale paint program to play with it. Kinda neat). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = "When I was young, all I wanted was to be | - gandreas@ub.d.umn.edu - = = ruler of the universe. Not that isn't | Glenn Andreas = = enough" - Alex P. Keaton | (Yes, a new signature!) = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
dgold@Apple.COM (David Goldsmith) (07/15/88)
In article <390@umn-d-ub.D.UMN.EDU> gandreas@ub.d.umn.edu.UUCP (Glenn Andreas) writes: >4K!!! 4K!!! You mean to say, that my system heap will go from 380k to >384k!! Jeez. In these days of inits that take up 70k+ I think that 4k is a >very small price to pay for this. Well, how about an INIT that does this. >And while we're at it, how about an INIT that will catch the 68881 codes and >translate them into SANE calls (I've heard rumors about such things). Unfortunately, Ed Tecot was guilty of a slight typographical error. Patching Color QuickDraw onto the Mac Plus or SE would require: 1) Rewriting it, since it uses 68020 instructions for speed in dealing with multibit pixels. 2) About 200K to 250K of memory. 3) Since CQD uses traps outside the range of the Plus/SE trap dispatcher, the trap dispatcher would have to be patched out. This would slow it down by about 30% since it would be in RAM rather than ROM. Apple examined the possibility of emulating the 881 in software. We concluded 1) It would be a tremendous amount of work -- Motorola tried it and gave up, and 2) it would be very slow. David Goldsmith Apple Computer, Inc. AppleLink: GOLDSMITH1 BIX: dgoldsmith 20525 Mariani Avenue, MS: 46B UUCP: {nsc,dual,sun,voder,ucbvax!mtxinu}!apple!dgold Cupertino, CA 95014 CSNET: dgold@apple.apple.com
adail@pnet06.cts.com (Alan Dail) (07/15/88)
Rather than rewriting color QD, would it be possible to write an INIT that
would patch the 68000 instruction set to emulate the 68020. This way code
could be written with the -mc68020 switch and still work on the plus/se.
i.e. Does the trap for unimplemented instructions allow you to determine what
instruction was executed similar to the way the A traps work. This semingly
minor patch could help simplify software development without the major work
it would take to try to patch for the 881. Also, then color QD qouldnt have
to be rewritten to run on the plus/se.
Alan Dail
UUCP: {crash uunet}!pnet06!adail
ARPA: crash!pnet06!adail@nosc.mil
INET: adail@pnet06.cts.comolson@endor.harvard.edu (Eric K. Olson) (07/16/88)
In a recent article David Goldsmith writes: >Unfortunately, Ed Tecot was guilty of a slight typographical error. Patching >Color QuickDraw onto the Mac Plus or SE would require: How about changing the CQD stubs in the DrawPicture code so that they do an ordered dither (very fast and easy) of the Lightness level of the picture data instead of the current 50% thresholding? Also, I've heard rumors that the next verion of the Printer drivers will support multibit CGrafPorts for Laserwriters (so I can CopyBits an 8 bit deep image to the Laserwriter and not get it 50% thresholded too). This was told to me by the QMS people (who really need it, because they can support full Color Laserwriter Printer CGrafPorts). Right now I have to deal with three cases to print grayscale or color data to all available printers: 1) Postscript printers [Use PS Escape and PS's image operator] 2) GrafPort (1-bit) printers [Dither myself and then print] 3) Real CQD Printers [Print Normally]. New printer drivers combined with new CQD stubs would mean I could go back to just one printing routine. Just my $0.02. -Eric Lexington Software Design: Tomorrow's Software Yesterday Eric K. Olson olson@endor.harvard.edu harvard!endor!olson D0760 (Name) (ArpaNet) (UseNet) (AppleLink)
kennel@minnie.cognet.ucla.edu (Matthew Kennel) (07/16/88)
>Apple examined the possibility of emulating the 881 in software. We >concluded 1) It would be a tremendous amount of work -- Motorola tried it >and gave up, and 2) it would be very slow. > >David Goldsmith Apple Computer, Inc. >AppleLink: GOLDSMITH1 BIX: dgoldsmith 20525 Mariani Avenue, MS: 46B >UUCP: {nsc,dual,sun,voder,ucbvax!mtxinu}!apple!dgold Cupertino, CA 95014 >CSNET: dgold@apple.apple.com Jeez, Sun does it! (e.g. compile your program with cc -fsoft). Are you admitting their superiority? Maybe it would be hard to get an EXACT '881 simulation, i.e. down to the last bit and exception, but I think you could make one that was pretty damn close. Of course it would be slow, but would it be that much slower than what's done now? Matt K. (kennel@cognet.ucla.edu)
tecot@Apple.COM (Ed Tecot) (07/17/88)
In article <13954@apple.Apple.COM> dgold@apple.apple.com.UUCP (David Goldsmith) writes: >Unfortunately, Ed Tecot was guilty of a slight typographical error. Patching >Color QuickDraw onto the Mac Plus or SE would require: > >1) Rewriting it, since it uses 68020 instructions for speed in dealing with > multibit pixels. >2) About 200K to 250K of memory. David's right if you want full Color Quickdraw, that is, something that you could use with a card connected to a color monitor. My discussion in my previous two messages assumes a b/w Quickdraw with a color interface. I didn't even consider multi-bit offscreen pixmaps. If you want that, add a lot more code and expect real poor performance. CQD takes advantage of the 68020 in such a way that it is more 3 times faster than a 68000 at the same clock. (FYI - normal 68000 code is only twice as fast on a 68020 at the same clock, and only if it is memory intensive). >3) Since CQD uses traps outside the range of the Plus/SE trap dispatcher, > the trap dispatcher would have to be patched out. This would slow it > down by about 30% since it would be in RAM rather than ROM. I didn't even think about that. I don't think anyone would be willing to pay that price. _emt
singer@endor.harvard.edu (Rich Siegel) (07/18/88)
In article <14446@shemp.CS.UCLA.EDU> kennel@minnie.UUCP (Matthew Kennel) writes: >>Apple examined the possibility of emulating the 881 in software. We >>concluded 1) It would be a tremendous amount of work -- Motorola tried it >>and gave up, and 2) it would be very slow. >> >>David Goldsmith Apple Computer, Inc. >>AppleLink: GOLDSMITH1 BIX: dgoldsmith 20525 Mariani Avenue, MS: 46B >>UUCP: {nsc,dual,sun,voder,ucbvax!mtxinu}!apple!dgold Cupertino, CA 95014 >>CSNET: dgold@apple.apple.com > >Jeez, Sun does it! (e.g. compile your program with cc -fsoft). >Are you admitting their superiority? I seriously doubt that Sun has written a 68881 emulator. A far easier solution (and for more likely) ) is that they wrote a "smart" floating-point library, that calls the FPCP if it's there, and otherwise does floating-point math in software. -Rich Rich Siegel Symantec/THINK Technologies
darin@Apple.COM (Darin Adler) (07/23/88)
In article <467@hodge.UUCP> adail@pnet06.cts.com (Alan Dail) writes: > Rather than rewriting color QD, would it be possible to write an INIT that > would patch the 68000 instruction set to emulate the 68020? Unfortunately, this is difficult, if not impossible, due to the fact that the 68000 does not fully decode the effective address word for indexed instructions. This is discussed in Appendix D.3 of the 68020 User's Manual. > Does the trap for unimplemented instructions allow you to determine what > instruction was executed similar to the way the A traps work? This seemingly > minor patch could help simplify software development without the major work > it would take to try to patch for the 881. This is the technique David G. was referring to earlier when he mentioned that Apple considered emulation the 68881 and Motorola "tried it and gave up." "Seemingly minor" is definitely *not* the right adjective. -- Darin Adler AppleLink: Adler4 UUCP: {sun,voder,nsc,mtxinu,dual}!apple!darin CSNET: darin@Apple.com
rob@uokmax.UUCP (Robert K Shull) (07/26/88)
In article <14446@shemp.CS.UCLA.EDU> kennel@minnie.UUCP (Matthew Kennel) writes: >>Apple examined the possibility of emulating the 881 in software. We > >Jeez, Sun does it! (e.g. compile your program with cc -fsoft). > Don't forget that if you compile with -fsoft you lose the advantage of hardware floating point. You still have to compile two different versions if you want hardware floating point, depending on the machine you expect to run on. Also, a program compiled to produce inline '881 on a Sun 3 with the FPU WON'T run on a Sun 3 without the FPU. I thought what we were looking for was a method to allow running a program with inline '881 code on a machine without an '881. I don't know who (if anyone) has that ability, but Sun doesn't. > >Matt K. >(kennel@cognet.ucla.edu) Robert -- Robert K. Shull University of Oklahoma, Engineering Computer Network ihnp4!occrsh!uokmax!rob CIS 73765,1254 Delphi RKSHULL Opinions contained herein do not exist, except in your imagination.