In article <····@internal.Apple.COM> ·····@apple.com (Paul Snively) writes:
>In article <········@yvax.byu.edu> ·····@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
In article <······················@paris.ics.uci.edu> Michael Pazzani <·······@ics.uci.edu> writes:
>In article <····@internal.Apple.COM> ·····@apple.com (Paul Snively) writes:
>>In article <········@yvax.byu.edu> ·····@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
(·····@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
··@cambridge.apple.com