Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!nosc!marlin!aburto From: aburto@marlin.NOSC.MIL (Alfred A. Aburto) Newsgroups: comp.sys.amiga.tech Subject: Re: PowerVisor and floating point coprocessor Message-ID: <1429@marlin.NOSC.MIL> Date: 31 May 90 20:28:27 GMT References: <23May1990110844167@BLEKUL11.BITNET> <1420@marlin.NOSC.MIL> <11977@cbmvax.commodore.com> <11981@cbmvax.commodore.com> Reply-To: aburto@marlin.nosc.mil.UUCP (Alfred A. Aburto) Distribution: comp.sys.amiga.tech Organization: Naval Ocean Systems Center, San Diego Lines: 105 In article <11981@cbmvax.commodore.com> daveh@cbmvax (Dave Haynie) writes: >In article <11977@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >>In article <1420@marlin.NOSC.MIL> aburto@marlin.nosc.mil.UUCP > >Yup, that's exactly what I found with older SetCPUs -- on some 68020 boards, >the program would crash. Later, when I fixed it for 68030 operation, the >crashes stopped, but the program erronously reported the presence of an MMU. > >The culprit, as Valentin mentioned, was the FPU decoding hardware on some of >the 68020 boards out there. As shown in the Motorola documentation, each >coprocessor has it's own CPU space address, and proper design will decode the >full address for FPU select. But, in some designs, they don't, and what you >end up with is an FPU that responds to MMU instructions. > >What I currently do in SetCPU is this: > > [Dave's code --- omitted] Hello Dave, I like the way you used your task TC_TRAPCODE to intercept the trap. While I knew about these things in the task control block it did not dawn on me to use them. Perhaps if each task actually did handle its own traps there would be much less problems with GURU's, but thats extra code that generally goes ignored I think. Anyway, below shows how I handled the problem with the CSA boards (which have the hardware co-processor interface booboo). Not quite like what you did, but it seems to work very well ... ******************** Exception Routine ********************************** Exception: MOVE.L A6,-(A7) MOVEA.L _SysBase,A6 JSR _LVODisable(A6) ;Things work better if I do this. JSR _LVOSupervisor(A6) JSR _LVOEnable(A6) MOVEA.L (A7)+,A6 RTS ************************* Check MMU Types ******************************* Check_MMU: MOVE.L A5,-(A7) MOVE.L CPU_Type,D0 ;000/010/020/030/040 CPU Types Set ;Elsewhere (040 determined via FSAVE). CMPI.B #$01,D0 BLE S0908 ;[Deleted 030/040 MMU Code] S0906: CMPI.B #$02,D1 ;CPU_Type = 68020? BNE.S S0908 ;No ;Yo LEA.L X_MMU851,A5 ;Check 68851 MMU BSR Exception ;Returns D0 = 0 if No 68851 ;Returns D0 = 1 if 68851 Present. ;[Deleted 851 MMU [ON/OFF] Code] S0908: MOVEA.L (A7)+,A5 ;Done. RTS X_MMU851: MOVEQ.L #$00,D0 ;Indicate No 68851 MMU. DC.W $4E7A,$8801 ;MOVEC VBR,A0 MOVE.L $34(A0),-(A7) ;Save Co-Processor Protocol Vector MOVE.L $2C(A0),-(A7) ;Save F-Line Vector LEA.L S0910,A1 ;Trap To Indicated Location. MOVE.L A1,$34(A0) ;Replace Co-Processor Protocol Vector MOVE.L A1,$2C(A0) ;Replace F-Line Vector MOVE.L A7,A1 ;Save A7 DC.W $F000,$2400 ;PFLUSHA MOVEQ.L #$01,D0 ;Indicate 68851 MMU. S0910: MOVE.L A1,A7 ;Restore A7 MOVE.L (A7)+,$2C(A0) ;Restore Co-Processor Protocol Vector MOVE.L (A7)+,$34(A0) ;Restore F-Line Vector RTE BTW, on BIX (amiga.special/cover.girl) the question was asked if one could smoothly switch between CPU's on the A3000, assuming a 68040 co-processor CPU board existed and was installed in the co-processor socket? The idea is to smoothly switch CPU's without a reboot. Would this be difficult to do on the A3000? Al Aburto aburto@marlin.nosc.mil