aburto@marlin.NOSC.MIL (Alfred A. Aburto) (05/30/90)
In article <23May1990110844167@BLEKUL11.BITNET> GHGAPAR@BLEKUL11.BITNET writes: >Hello everyone, > >I would like to make my debugger (PowerVisor) compatible with every >Amiga. This includes Amigas with coprocessors. For the single >stepping and crashtrapping features I make extensive use of the >stackframe exec saves before each task switch. Because a floating >point processor has its own registers that need to be saved, I >suppose this stackframe will be different on such a machine. >I suspect that the fsave and frestore (or something like that) have >something to do with this, because I saw those two instructions in >the alternative Schedule in exec (The one for coprocessors). How >do these two instructions work and what does the stack look like on >a floating point Amiga ? > Please note that the Motorola Programmer's Reference Manual M68000PM/AD dated 1989 has an error in describing the FSAVE instruction format. Page 4-17 of that document shows the FSAVE instruction format with bit 8 (counting from zero) set to zero, however bit 8 is a 1 for this instruction. Also, a problem I found when checking for the presence or absence of a 68851 MMU co-processor (020 only) is that while I was expecting an F-Line exception (vector $2C) for the PFLUSHA instruction on an 020 without 68851 MMU I received INSTEAD a Co-Processor Protocol exception (vector $34). This happened with an 020/882 board from CSA which had no 68851 MMU and it indicated some kind of a hardware problem with the Co-Processor interface. Well, I learned a lesson here and now I check for both types of exceptions on the 020/030 to prevent an uncontrolled system crash (just in case). Al Aburto aburto@marlin.nosc.mil
valentin@cbmvax.commodore.com (Valentin Pepelea) (05/31/90)
In article <1420@marlin.NOSC.MIL> aburto@marlin.nosc.mil.UUCP (Alfred A. Aburto) writes: > > Please note that the Motorola Programmer's Reference Manual M68000PM/AD > dated 1989 has an error in describing the FSAVE instruction format. Page > 4-17 of that document shows the FSAVE instruction format with bit 8 > (counting from zero) set to zero, however bit 8 is a 1 for this instruction. Well done. Make sure you report this to Motorola. > Also, a problem I found when checking for the presence or absence of > a 68851 MMU co-processor (020 only) is that while I was expecting an > F-Line exception (vector $2C) for the PFLUSHA instruction on an 020 > without 68851 MMU I received INSTEAD a Co-Processor Protocol exception > (vector $34). This happened with an 020/882 board from CSA which had > no 68851 MMU and it indicated some kind of a hardware problem with > the Co-Processor interface. Dave Haynie reported the same problem with the CSA board back when he was testing his SetCPU program. Try out SetCPU and see what kind of processors it reports. The problem seems to be that the CSA board improperly decodes the FCx lines and assumes that any F-line instruction is a math coprocessor instruction. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
daveh@cbmvax.commodore.com (Dave Haynie) (05/31/90)
In article <11977@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >In article <1420@marlin.NOSC.MIL> aburto@marlin.nosc.mil.UUCP >(Alfred A. Aburto) writes: >> Also, a problem I found when checking for the presence or absence of >> a 68851 MMU co-processor (020 only) is that while I was expecting an >> F-Line exception (vector $2C) for the PFLUSHA instruction on an 020 >> without 68851 MMU I received INSTEAD a Co-Processor Protocol exception >> (vector $34). This happened with an 020/882 board from CSA which had >> no 68851 MMU and it indicated some kind of a hardware problem with >> the Co-Processor interface. >Dave Haynie reported the same problem with the CSA board back when he was >testing his SetCPU program. Try out SetCPU and see what kind of processors >it reports. >The problem seems to be that the CSA board improperly decodes the FCx lines >and assumes that any F-line instruction is a math coprocessor instruction. 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: ;====================================================================== ; ; This function returns 0L if the system contains no MMU, ; 68851L if the system does contain an 68851, or the CPU number ; for CPUs with integral CPUs. ; ; This routine used to lock up on at least some CSA 68020 ; boards, though it runs just fine on those from Ronin and ; Commodore, as well as all 68030 boards it's been tested on. ; ; ULONG GetMMUType() ; ;====================================================================== _GetMMUType: move.l 4,a6 ; Get ExecBase jsr TestFlags ; Check extended CPU types cmp.l #0,d0 beq MMURealTest rts ; For any other machine, a real test must be done. The test will ; try an MMU instruction. The instruction will fail unless we're ; on a "bogus MMU" system, where the FPU responds as an MMU. MMURealTest: movem.l a3/a4/a5,-(sp) ; Save this stuff move.l #0,a1 CALLSYS FindTask ; Call FindTask(0L) move.l d0,a3 move.l TC_TRAPCODE(a3),a4 ; Change the exception vector move.l #MMUTraps,TC_TRAPCODE(a3) move.l #-1,d0 ; Try to detect undecode FPU subq.l #4,sp ; Get a local variable PMOVE_ tc,(sp) ; Let's try an MMU instruction addq.l #4,sp ; Return that local move.l a4,TC_TRAPCODE(a3) ; Reset exception stuff movem.l (sp)+,a3/a4/a5 ; and return the registers rts ; This is the exception code. No matter what machine we're on, ; we get an exception. If the MMU's in place, we should get a ; privilige violation; if not, an F-Line emulation exception. MMUTraps: move.l (sp)+,d0 ; Get Amiga supplied exception # cmpi #11,d0 ; Is it an F-Line? beq MMUNope ; If so, go to the fail routine move.l #68851,d0 ; We have MMU addq.l #4,2(sp) ; Skip the MMU instruction rte MMUNope: moveq.l #0,d0 ; It dinna woik, addq.l #4,2(sp) ; Skip the MMU instruction rte Basically, I assume things are messed up, and set d0 to -1. If things are messed up, we get a valid user-mode FPU instruction, and therefore never take an exception. If there's no MMU installed, the exception will be an F-line exception, on system with an MMU, it's a privilige violation. I don't bother checking for an MMU anymore if I know the CPU is a 68030 or 68040 (the TestFlags routine acertains this). -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "I have been given the freedom to do as I see fit" -REM
aburto@marlin.NOSC.MIL (Alfred A. Aburto) (06/01/90)
In article <11977@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >In article <1420@marlin.NOSC.MIL> aburto@marlin.nosc.mil.UUCP >(Alfred A. Aburto) writes: >> >> Please note that the Motorola Programmer's Reference Manual M68000PM/AD >> dated 1989 has an error in describing the FSAVE instruction format. Page >> 4-17 of that document shows the FSAVE instruction format with bit 8 >> (counting from zero) set to zero, however bit 8 is a 1 for this instruction. > >Well done. Make sure you report this to Motorola. > Thanks and yes I'll make sure Motorola is aware of the typo .... >The problem seems to be that the CSA board improperly decodes the FCx lines >and assumes that any F-line instruction is a math coprocessor instruction. > This explains why then I received the Co-Processor Protocol exception and not the F-Line exception (which normally one would expect). It was a very puzzling problem and it took some fooling around to figure out what was happening and how to account for it. Thanks for the feedback. Al Aburto aburto@marlin.nosc.mil
aburto@marlin.NOSC.MIL (Alfred A. Aburto) (06/01/90)
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