English Amiga Board


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

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

 
Join Date: Sep 2015
Location: Germany
Posts: 214
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 07:21.
dissident is offline  
Old 18 November 2018, 22:53   #2
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,772
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, 06:23   #3
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 22,836
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, 07:42   #4
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 214
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, 07:49   #5
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 214
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, 47 views)

Last edited by dissident; 19 November 2018 at 07:56.
dissident is offline  
Old 19 November 2018, 10:05   #6
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 1,772
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, 19:08   #7
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 214
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  
Old 24 January 2019, 09:30   #8
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 214
Quote:
Originally Posted by dissident View Post
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.
Well, I have found an explanation what the values written to the TTx registers mean:

ITT0=$00ffc000
*Enable transparent translation
*Apply for user&supervisor mode
*For "writethrough" instruction cache (In this case instructions are cached)
*For logical address space $00000000-$ffffffff

ITT1=$00ffc000
*Enable transparent translation
*Apply for user&supervisor mode
*For "writethrough" instruction cache (In this case instructions are cached)
*For logical address space $00000000-$ffffffff

DTT0=$0000c040
*Enable transparent translation
*Apply for user&supervisor mode
*Inhibited data cache&precise exception model
*For logical address space $00000000-$00ffffff

DTT1=$00ffc000
*Enable transparent translation
*Apply for user&supervisor mode
*For writethrough data cache
*For logical address space $00000000-$ffffffff

URP= $00000000
*No translation table user mode

SRP= $00000000
*No translation table supervisor mode

TCR= $00000000
*Disable translation

This config is written by the OS if a 68040 CPU is available but the MMU is disabled.

Important: The memory blocks defined in DTT0 and DTT1 overlap. The 68040 (3.4 TRANSPARENT TRANSLATION) and 68060 (4.4 TRANSPARENT TRANSLATION) docs of Motorola say:
Quote:
If either of the TTRs matched during an access to a memory unit (either instruction or data), the access is transparently translated. If both registers match, the TT0 status bits are used for the access.
This confirms this passage:
Quote:
The 68040 and Zorro III The 68040 does not have the problem that the 68030 has with Zorro II space. The 68040 contains two registers to give data space a default mapping without the need of a Memory Management Unit (MMU). On an Amiga with a 68040, Exec uses one of these registers to map the low 24-bits of the Amiga's address space (the Zorro II range, $00000000-$00FFFFFFFF) as non-cachable and serialized1 . The Amiga uses the second register to map the remaining memory ($01000000-$FFFFFFFF) as cachable and non-serialized. Because of its mapping, any RAM in this region will yield considerably higher performance than RAM in Zorro II space. Unfortunately, this mapping can cause problems for a Zorro III device that is not RAM.
which is part of the Developper V2.1 package and the whole document can be found here: http://amigadev.elowar.com/read/ADCD.../node0161.html

Last edited by dissident; 27 February 2019 at 17:40.
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 10:26
Amiga a3640 processor card and 68040/68040 processors Euphoria MarketPlace 3 26 February 2017 21:15
Cyberstorm Mk-III 060 - 060, 040 dummy libs Akiko support.Apps 1 07 February 2011 20:30
Help getting ACT Apollo 060 / Viper 060 and CS060Mk2 - working with ClassicWB ADV Zetr0 support.Other 30 23 March 2010 15:39
WarpEngine disabling 68040 alanh support.Hardware 4 11 October 2008 22: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 00:21.


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