woodl@yvax.byu.edu (10/17/89)
I just installed a Radius 16 mhz accelorater board in my SE and find that Apple Allegro CL will not boot. I get the bomb!, error=11. So far, Radius blames Apple, and I haven't received a reply back from my AppleLink query to Apple. I don't suppose anyone out there has had any experience? Any ideas would be appreciated. All my other software has run fine, and the increase in speed has been very worthwhile. Thanks - Larry Wood, Brigham Young University, WoodL@BYUVAX.bitnet
crowston@Athena.MIT.EDU (Kevin G Crowston) (10/19/89)
This happened to me when I bought my accelerator. The problem is a bug in the Allegro floating point emulation code, to wit, it doesn't work on a 68020. Mac IIs all come with built in floating point chips, so the emulation code was mostly intended for Pluses and SEs. Coral (excuse me, Apple) says it'll be fixed in the next release, due any day now. Work around: buy a floating point chip. Kevin Crowston
chewy@apple.com (Paul Snively) (10/20/89)
In article <856woodl@yvax.byu.edu> woodl@yvax.byu.edu writes: > I just installed a Radius 16 mhz accelorater board in my SE and find that > Apple Allegro CL will not boot. I get the bomb!, error=11. So far, Radius > blames Apple, and I haven't received a reply back from my AppleLink query to > Apple. I don't suppose anyone out there has had any experience? Any ideas > would be appreciated. All my other software has run fine, and the increase > in speed has been very worthwhile. > > Thanks > > - Larry Wood, Brigham Young University, WoodL@BYUVAX.bitnet Yup, it's our problem. Put this patch in your INIT.LISP file: (in-package "CCL") (defun validate-fp-handler (handler) "If the HANDLER argument appears valid, return it. Otherwise, make a new one which Does The Right Thing. Note that the kernel will restore system floating-point exception handlers on exit, so we don't worry about that here." (let* ((old-addr (%ptr-to-int handler)) (words (list #o026417 ; move.l sp,-(a6) #o171447 ; fsave -(sp) #o027400 ; move.l d0,-(sp) #o027401 ; move.l d1,-(sp) #o070000 ; moveq #0,d0 #o010057 ; move.b 9(sp),d0 #o000011 #o004367 ; bset #27,8(sp,d0.w) #o000033 #o000010 #o171000 ; fmove.l fpsr,d0 #o124000 #o031074 ; move.w #$3400,d1 #o032000 #o141100 ; and.w d0,d1 #o063010 ; bne.s @1 #o021037 ; move.l (sp)+,d1 #o020037 ; move.l (sp)+,d0 #o171537 ; frestore (sp)+ #o541166 ; addq #4,a6 #o047163 ; rte #o027136 ; @1: move.l (a6)+,sp #o041247 ; clr.l -(sp) #o171537 ; frestore (sp)+ #o171000 ; fmove.l d0,fpsr #o104000 #o047371 ; jmp <old-handler> (logand (ash old-addr -16) #xff) (logand old-addr #xffff))) (len (length words))) (unless (= (%get-signed-word handler) (car words)) (setq handler (%register-trap #xa11e 384 (* 2 len))) ;(_Newptr:d0 (* 2 len):a0) (dotimes (i len) (%put-word handler (pop words) (+ i i)))) handler)) (defun ccl-using-fpu-p () (not (= 0 (%get-byte (%get-ptr (%int-to-ptr #x904)) #x-130)))) (when (ccl-using-fpu-p) (let* ((addr (%int-to-ptr #xc8))) (%put-ptr addr (validate-fp-handler (%get-ptr addr)))) t) Hope this helps! __________________________________________________________________________ Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. __________________________________________________________________________ C++ -- The language in which only friends can access your private members. __________________________________________________________________________
alms@cambridge.apple.com (Andrew L. M. Shalit) (10/21/89)
In article <4812@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: In article <856woodl@yvax.byu.edu> woodl@yvax.byu.edu writes: > I just installed a Radius 16 mhz accelorater board in my SE and > find that > Apple Allegro CL will not boot. I get the bomb!, error=11. So far, > Radius blames Apple, and I haven't received a reply back from my > AppleLink query to Apple. I don't suppose anyone out there has had any > experience? Any ideas would be appreciated. Yup, it's our problem. Put this patch in your INIT.LISP file: [spurious patch deleted] Whoops. The patch which Paul posted will not fix the Radius bug. Radius boards sans FPU do not generate FTRAPs correctly. MACL depends on correct FTRAP behavior (this lets us generate object code which runs on a variety of Macs). We're in the process of trying to get in touch with someone at Radius so we can fix this problem. In the meantime, getting an FPU may help. -andrew
chewy@apple.com (Paul Snively) (10/21/89)
In article <ALMS.89Oct20163158@brazil.cambridge.apple.com> alms@cambridge.apple.com (Andrew L. M. Shalit) writes: > In article <4812@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: > > In article <856woodl@yvax.byu.edu> woodl@yvax.byu.edu writes: > > I just installed a Radius 16 mhz accelorater board in my SE and > > find that > > Apple Allegro CL will not boot. I get the bomb!, error=11. So far, > > Radius blames Apple, and I haven't received a reply back from my > > AppleLink query to Apple. I don't suppose anyone out there has had any > > experience? Any ideas would be appreciated. > > Yup, it's our problem. Put this patch in your INIT.LISP file: > > [spurious patch deleted] > > Whoops. The patch which Paul posted will not fix the Radius bug. > > Radius boards sans FPU do not generate FTRAPs correctly. MACL depends > on correct FTRAP behavior (this lets us generate object code which > runs on a variety of Macs). We're in the process of trying to get in > touch with someone at Radius so we can fix this problem. > > In the meantime, getting an FPU may help. Whoops, indeed. While the patch I posted doesn't solve the problem in question, it DOES solve other floating-point errors in the versions of Macintosh Allegro Common Lisp that I mentioned. As for the Radius problem, getting an FPU not only MAY help, it DOES help. __________________________________________________________________________ Just because I work for Apple Computer, Inc. doesn't mean that they believe what I believe or vice-versa. __________________________________________________________________________ C++ -- The language in which only friends can access your private members. __________________________________________________________________________
pazzani@ics.uci.edu (Michael Pazzani) (10/21/89)
In article <4812@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: >In article <856woodl@yvax.byu.edu> woodl@yvax.byu.edu writes: >> I just installed a Radius 16 mhz accelorater board in my SE and >find that >> Apple Allegro CL will not boot. I get the bomb!, error=11. > >Yup, it's our problem. Put this patch in your INIT.LISP file: I just bought a DayStar 40MHz Accelerator for my MAC-II and Allegro CL 1.2.1 Seems to have the same problem. I've also experienced problems on a IIcx. Since both the Accelerator an IIcx use a 68030, I'm beginning to suspect that this version doesn't work with that chip. Will the posted patch work? Will upgrading to 1.2.1 help, or shoould I wait for 1.3 which should be out soon? Thanks, Mike Pazzani
gb@cambridge.apple.com (Gary Byers) (10/22/89)
In article <1989Oct21.155107.13876@paris.ics.uci.edu> Michael Pazzani <pazzani@ics.uci.edu> writes: >In article <4812@internal.Apple.COM> chewy@apple.com (Paul Snively) writes: >>In article <856woodl@yvax.byu.edu> woodl@yvax.byu.edu writes: >>> I just installed a Radius 16 mhz accelorater board in my SE and >>find that >>> Apple Allegro CL will not boot. I get the bomb!, error=11. >> >>Yup, it's our problem. Put this patch in your INIT.LISP file: > >I just bought a DayStar 40MHz Accelerator for my MAC-II and Allegro CL 1.2.1 >Seems to have the same problem. I've also experienced problems on a IIcx. >Since both the Accelerator an IIcx use a 68030, I'm beginning to suspect >that this version doesn't work with that chip. Will the posted patch work? >Will upgrading to 1.2.1 help, or shoould I wait for 1.3 which should >be out soon? > >Thanks, >Mike Pazzani This is all somewhat confusing, so please bear with me: 1) Versions of the lisp older than 1.2.2 would not run on 68030-based machines. This incompatibility was caused by an incredibly stupid little piece of code in the lisp kernel, which said "If it's not a 68020, it must be a 68000 ...". The 1.2.1 and 1.2.2 kernels differ only in that the latter recognizes 68030-based machines correctly. It is possible to patch the 1.2.1 kernel to make it into the moral equivalent of the 1.2.2 kernel with ResEdit; send me mail if you want to do this. 2) All released versions fail to handle floating-point exceptions (such as divide-by-zero) properly on systems equipped with a 68882 (vice 68881) floating-point coprocessor. This bug (and a patch for it) were reported in Tech Note #231; sadly, the patch in TN 231 contained a typo which caused the stack pointer to sail off into the ozone. Paul Snively of Mac DTS (chewy@apple.com) recently posted a corrected version of this patch to comp.lang.lisp in response to a question about MACL's interaction with Radius Accelerators which are not equipped with FPUs. 3) All versions of the lisp try to emulate floating-point instructions on systems that don't have floating-point coprocessors by catching the "F-Line" exception which should occur in such cases and using SANE to perform the floating-point operation. It seems to be the case that, on Macs equipped with Radius Accelerators without FPU chips, attempts to address the floating-point coprocessor yield "Coprocessor Protocol Violation" exceptions instead of the expected "F-Line" exception; this seems to be the reason why the lisp bombs on invocation on such machines. If anyone who's been trying to use the lisp on such a hardware configuration (Radius 68020 w/o 6888x) is willing to do some remote debugging of this situation, I'd be very interested in trying to resolve this problem that way: send me mail if you want to pursue this. Likewise, we've asked Radius what (if anything) users might be able to do or have done to their accelerator boards to remedy this problem and will continue to pursue that approach. Gary Byers gb@cambridge.apple.com