English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 18 November 2018, 22:02   #1
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 173
Disabling 68040/060 MMUs

I want to disable the running MMU of 6040/060 processors. Before disabling the MMU I disabled the data cache (on the 68060 also the branch cache) and the instruction cache is still enabled (on the 68060 the half instruction cache). I found this common MMU routine in the Coder's bible:

Code:
  move.l  $4.w,a6
  btst    #3,$129(a6)          ;Tests for a 68040 or higher processor
  bne.s   P68040
  rts

P68040
  lea     NO040MMU(pc),a5
  jsr     -$1e(a6)             ;execute NO040MMU as exception
  rts

NO040MMU
  move.l #$00ffc000,d0
  movec  d0,ITT0
  movec  d0,ITT1
  movec  d0,DTT1
  move.l #$0000c040,d0
  movec  d0,DTT0
  lea    $30000,a0
  movec  a0,URP
  movec  a0,SRP
  moveq  #0,d0
  movec  d0,TC
  rte
I also checked with which values the MMU registers of a 68060 are written right after a reset and these values confirm the values used above:

Code:
ITT0=$00ffc000
ITT1=$00ffc000
DTT1=$00ffc000
DTT0=$0000c040
URP=$00000000
SRP=$00000000
TC=$00000000
But what I don't understand is the fact, that the registers URP&SRP are initialized with the absolute CHIP memory address $30000. Is this really necessary? Pointing to a non initialized "MMU table" where memory values could change?

Nexus7 of Andromeda with the routine from above works fine on WinUAE 060 configs, but not on my real A1200+Blizzard060. At a certain position at the beginning of the demo, right before the letters appear in front of the rotating stars, the Amiga does a reset.

But setting the adress $30000 seems to be necessary, because setting both registers set to NULL leads to a reset on my real A1200/060 in conjunction with Nexus7 much earlier at the beginning before any display starts.

Does anyone has tips or hints how to deal with this topic?

Last edited by dissident; 19 November 2018 at 08:21.
dissident is offline  
Old 18 November 2018, 23:53   #2
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,343
Hi dissident, I cannot help you on the topic because I have no direct experience on MMU of 040/060.
Anyway 'back in the days' with my Blizzard 030 I had written MMU code, that I've successfully replicated a few months ago in WinUAE.

For me it does not make much sense that with MMU Table disabled, setting URP and SRP, there is different behavior in your Blizzard
($30000 or $0 or whatever value how can make difference?)
But it may be that something obvious escapes me so I'm, like you, curious about an answer.

In your message you refer to a "Coder's bible". What/where is this document?

Cheers.
ross is offline  
Old 19 November 2018, 07:23   #3
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,109
Missing "#" and address containing different garbage?

Did you also flush caches? (Disabling data cache won't automatically flush it or push data to memory if it was in copyback mode originally) Flushing MMU translation cache shouldn't be needed when disabling MMU. (But it is needed before re-enabling it, especially if tables changed)

TC should be cleared first because if URP/SRP are modified first, new MMU tables may become in use before TC is cleared (only if code crosses MMU pages and ATC already didn't have them)

And yes, if the code was only attempting to disable MMU translations, writing ot URP/SRP should not make any difference.
Toni Wilen is offline  
Old 19 November 2018, 08:42   #4
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 173
Quote:
Originally Posted by Toni Wilen View Post
Missing "#" and address containing different garbage?

Did you also flush caches? (Disabling data cache won't automatically flush it or push data to memory if it was in copyback mode originally) Flushing MMU translation cache shouldn't be needed when disabling MMU. (But it is needed before re-enabling it, especially if tables changed)

TC should be cleared first because if URP/SRP are modified first, new MMU tables may become in use before TC is cleared (only if code crosses MMU pages and ATC already didn't have them)

And yes, if the code was only attempting to disable MMU translations, writing ot URP/SRP should not make any difference.
Hi Toni, the missing # of

Code:
move.l $00ffc000,d0
is in my original code. I've forgotten it only for this example here to type in. Now corrected. But thanks for the hint.

Yes, I flushed the caches with CUSHA BC before I disabled the MMU.

Later, I turn on the MMU with its old values again. I didn't flush the MMU translation cache with PFLUSHA, because it worked without it, but I will test your version.

Okay, I will test the MMU behaviour, if I set TC=NULL first, before set URP/SRP=NULL or alternatively $30000.
dissident is offline  
Old 19 November 2018, 08:49   #5
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 173
Quote:
Originally Posted by ross View Post
Hi dissident, I cannot help you on the topic because I have no direct experience on MMU of 040/060.
Anyway 'back in the days' with my Blizzard 030 I had written MMU code, that I've successfully replicated a few months ago in WinUAE.

For me it does not make much sense that with MMU Table disabled, setting URP and SRP, there is different behavior in your Blizzard
($30000 or $0 or whatever value how can make difference?)
But it may be that something obvious escapes me so I'm, like you, curious about an answer.

In your message you refer to a "Coder's bible". What/where is this document?

Cheers.
Hi ross, "The Coder's Bible" was a collection of coding documents I found long ago. I've attached the docs. The file is named "MC68040_DisableMMU" in the directory "CPU".
Attached Files
File Type: lha CodersBible.lha (268.6 KB, 18 views)

Last edited by dissident; 19 November 2018 at 08:56.
dissident is offline  
Old 19 November 2018, 11:05   #6
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,343
Quote:
Originally Posted by dissident View Post
Hi ross, "The Coder's Bible" was a collection of coding documents I found long ago. I've attached the docs. The file is named "MC68040_DisableMMU" in the directory "CPU".
Excellent collection.
Thanks!

And thanks to Toni for the hints.
ross is offline  
Old 19 November 2018, 20:08   #7
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 173
Quote:
Originally Posted by Toni Wilen View Post

Flushing MMU translation cache shouldn't be needed when disabling MMU. (But it is needed before re-enabling it, especially if tables changed)

TC should be cleared first because if URP/SRP are modified first, new MMU tables may become in use before TC is cleared (only if code crosses MMU pages and ATC already didn't have them)

And yes, if the code was only attempting to disable MMU translations, writing ot URP/SRP should not make any difference.
I did some tests and the machine was more stable when the MMU was turned off. Nexus7 ran randomly without errors, but it's not comprehensible why it does not work all the time. This is the strangest demo I ever tested so many times.

My code now looks like this:

Code:
; a1 ... URP
; a2 ... SRP
; d1 ... TC
; d2 ... DTT0
; d3 ... DTT1
; d4 ... ITT0
; d5 ... ITT1

    CNOP 0,4
CPU040_060_MMU_off
    or.w    #$700,SR           ;Highest interrupt level
    nop
    move.l  #$00ffc000,d0
    movec.l ITT0,d4            ;Save content of ITT0
    nop
    movec.l d0,ITT0            ;New content of ITT0
    nop
    movec.l ITT1,d5            ;Save content of ITT1
    nop
    movec.l d0,ITT1            ;New content of ITT1 
    nop
    movec.l DTT1,d2            ;Save content of DTT1
    nop
    movec.l d0,DTT1            ;New content of DTT1
    nop
    move.l  #$0000c040,d0
    movec.l DTT0,d3            ;Save content of DTT0
    nop
    movec.l d0,DTT0            ;New content of DTT0
    nop
    moveq   #0,d0
    movec.l TC,d1              ;Save content of TC
    nop
    movec.l d0,TC              ;Disable MMU
    nop
    movec.l URP,a1             ;Save content of URP
    nop
    movec.l d0,URP             ;Clear user rootpointer
    nop
    movec.l SRP,a2             ;Save content of SRP
    nop
    movec.l d0,SRP             ;Clear supervisor rootpointer
    nop
    rte
And for turning the MMU on:

Code:
    CNOP 0,4
CPU040_060_MMU_on
    or.w    #$700,SR           ;Highest interrupt level
    nop
    movec.l d4,ITT0            ;Old content of ITT0 register
    nop
    movec.l d5,ITT1            ;Old content of ITT1 register
    nop
    movec.l d2,DTT0            ;Old content of DTT0 register
    nop
    movec.l d3,DTT1            ;Old content of DTT1 register
    nop
    movec.l a1,URP             ;Restore user rootpointer
    nop
    movec.l a2,SRP             ;Restore supervisor rootpointer
    nop
    PFLUSHA                    ;Flush ATCs
    nop
    movec.l d1,TC              ;Enable MMU
    nop
    rte
Well, I guess the NOP commands are not really necessary, but I want to make sure, that the 68060 really executes the commands in that order.

Many thanks for your hints, Toni.
dissident is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Swap: GVP 4060 (T-Rex II) OR MK II 060 for QuikPak A4000-060 XP REV.2 NO SALE! Sveta MarketPlace 1 20 December 2017 11:26
Amiga a3640 processor card and 68040/68040 processors Euphoria MarketPlace 3 26 February 2017 22:15
Cyberstorm Mk-III 060 - 060, 040 dummy libs Akiko support.Apps 1 07 February 2011 21:30
Help getting ACT Apollo 060 / Viper 060 and CS060Mk2 - working with ClassicWB ADV Zetr0 support.Other 30 23 March 2010 16:39
WarpEngine disabling 68040 alanh support.Hardware 4 11 October 2008 23:19

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 05:08.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.06763 seconds with 16 queries