68030 PMMU config help needed

GFA, ASM, STOS, ...

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

rpineau
Atari Super Hero
Atari Super Hero
Posts: 501
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

68030 PMMU config help needed

Postby rpineau » Thu Mar 02, 2017 11:42 pm

Hi all.
Me and Juliusz have been testing using a 68020 on our 68020 card via a small adapter.
We had some promising result but we're running into some issue on TOS 2.06.
We can enable the instruction cache and that work fine and we get pretty much the same speed as the 68020 at the same frequency (32MHz in our case).
If we enable the data cache. the machine freeze.
After doing some (A lot!) of reading it is obvious that to get the data cache to work we need to setup a proper PMMU tree why TOS 2.06 doesn't do (we might test with a German TOS 3.06 patched for the PAK soon but for now ... bare with me :) ).
We tried Emutos.. same issue even though it does set a PMMU tree. So not sure yet why this doesn't work with Emutos.

The machine can boot through the auto folder and freeze just before displaying the desktop.
We've tried a few things with the CIIN pin of the 68030, and fully allowing TOS caching and not allowing ST RAM caching for example.. which works.. but is not what we want :)
So I tried to write small piece for code to setup the PMMU tree from the auto folder (not tested yet on real hardware) and a I a F-Line exception on a pmove instruction when setting the new TC register value (code attached).

Our CIIN test (VHDL) :

Code: Select all

   -- 68030 experimentation
    CIIN_int <= '1'   when
               (Address_bus >= x"00E00000" and Address_bus < x"00E40000" and AS_CPU = '0') -- tos
            or   (Address_bus >= x"FFE00000" and Address_bus < x"FFE40000" and AS_CPU = '0') -- tos shadow
            or   (Address_bus >= x"00000000" and Address_bus < x"00400000" and cpu_space = "001") -- ram user data
            or   (Address_bus >= x"00000000" and Address_bus < x"00400000" and cpu_space = "101") -- ram supervisor data
            or   (Address_bus >= x"00000000" and Address_bus < x"00400000" and cpu_space = "010" and AS_CPU = '0') -- ram user program space
            or   (Address_bus >= x"00000000" and Address_bus < x"00400000" and cpu_space = "110" and AS_CPU = '0') -- ram supervisor program space
            else '0';


if we remove the 2 lines doe the data space the machine works but none of the ST RAM get cached.
With these 2 lines we can boot but not get to desktop.

So is there a PMMU guru that could tell us what we're doing wrong :) (and help us if possible :) ).
Regards,
Rodolphe
You do not have the required permissions to view the files attached to this post.
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

neanderthal
Retro freak
Retro freak
Posts: 16
Joined: Sun Jul 10, 2016 10:58 pm

Re: 68030 PMMU config help needed

Postby neanderthal » Fri Mar 03, 2017 1:03 am

Just a thought,it is a 030 you are trying to boot right? For the 020 has no onchip MMU(first line of text).And would that be standard 68k TOS2.06? I quess this is some sort of booster for ST/E?

rpineau
Atari Super Hero
Atari Super Hero
Posts: 501
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: 68030 PMMU config help needed

Postby rpineau » Fri Mar 03, 2017 1:08 am

yes it is a 68030. and yes this is standard unpatched TOS 2.06 (US).
And yes this is a booster for the STE/MSTE (And latter STF/Mega ST) : viewtopic.php?f=15&t=28277
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

neanderthal
Retro freak
Retro freak
Posts: 16
Joined: Sun Jul 10, 2016 10:58 pm

Re: 68030 PMMU config help needed

Postby neanderthal » Fri Mar 03, 2017 1:21 am

Ok,will do some reading there what you are up to :)..Have done some rather deep twiddling on the falcy and things that first comes to mind is stackframes.(since the frackers differ between the CPU versions,cant use same code for as on 68k for stack analysis).But cool that you are almost at desktop boot.

rpineau
Atari Super Hero
Atari Super Hero
Posts: 501
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: 68030 PMMU config help needed

Postby rpineau » Fri Mar 03, 2017 1:56 am

Thanks
We get to desktop if we disable the data cache (either via /CIIN or by not enabling cache in the Desktop).
It might indeed just be that the TOS 2.06 knows 68020 stack frames but not 68030 (even though it does work with a 68030 with instruction cache enabled and data cache disabled).
The PMMU tree you'll find in my code comes from a few different sources. The one currently in there comes from the Tos Patch 3.06 FIL file ( P_MMU3.FIL ).
But it is very similar to others I've seen
We could also try the one from Emutos or even copy the of a TT (256 byte dump from $700).
In any case thanks for offering to help.
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

neanderthal
Retro freak
Retro freak
Posts: 16
Joined: Sun Jul 10, 2016 10:58 pm

Re: 68030 PMMU config help needed

Postby neanderthal » Fri Mar 03, 2017 2:43 am

Ah just a thought that came to mind,,and yea you mentioned that it boots all the way with datacache off(ergo should not be stack frames issue).Kinda thought about the tricks I had to do when doing ints on the 030 instead of a plain old 000.Mostly intrigued why must admit.In theory PMMU is only for memory protection and stuff(Mint and Linux and so forth)..Actually never studied that part of 030 since in the falcy it behaves pretty much like a standard 000(exept for stack frames and some other stuff since the PAL:s emulate the 68k bus)..Came to think of a long shot,since it boots all the way upto desktop,so sounds like,maybe some funky stuff with blitter bus arbituration..Just becauase thats the only thing that I know of that later TOS use for drawing windows and so on.Well anyhows,happy bughunting :)

rpineau
Atari Super Hero
Atari Super Hero
Posts: 501
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: 68030 PMMU config help needed

Postby rpineau » Fri Mar 03, 2017 3:32 am

With the 68020 in place with have no blitter or DMA issue (but there is no data cache on the 68020).
I found 2 contradictory statements in the various things I read online. One says the all the ST RAM should be cacheable, and one says it shouldn't be because of the blitter and DMA.
But obviously it works on the Falcon as both cache are enabled and it has a blitter and more than one DMA device (in one chip..).
I'll have to ask Juliusz but from memory, blitter enable or not doesn't make any difference.
Thanks, Rodolphe
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

User avatar
Arne
Captain Atari
Captain Atari
Posts: 400
Joined: Thu Nov 01, 2007 10:01 am

Re: 68030 PMMU config help needed

Postby Arne » Fri Mar 03, 2017 4:41 am

ehmmm... why don't you just assert /MMUDIS?
I see that you do not use /CPU_AS to validate data accesses. Why?
Shouldn't

Code: Select all

(...)
(Address_bus >= x"00000000" and Address_bus < x"00400000" and CPU_FC(1) /= CPU_FC(0) and AS_CPU = '0')
(...)

do the job?

rpineau wrote:and one says it shouldn't be because of the blitter and DMA.

No... the MegaSTE uses a unified cache and it works. Same for many other 68000/020/030 speeders for the ST. Even if you throw out the Blitter you still have to fiddle with ACSI/FDD DMA.

There is an article for a 68030 daughterboard to be placed in a 68020 socket in c't 07/1993. Unfortunately they do not talk about the OS.
What's the level of /CBACK and /STERM? You tied them to Vcc?
The c't article shows a schematic where /CBREQ is tied to Vcc and /CBACK is left open. Don't know why they pull an output to some level.

About 68030 and 2.06 the PAK 68/3 article reads:
- some HDD drivers have problems with a non-initialised MMU. AHDI hasn't.
- MMU init can be done via AUTO Folder Prg. but a reset via keyboard will hang up the system as the MMU tables in RAM are being destroyed. The RESET mnemonic very soon in TOS will reset the L1 and all external peripheral but not the MMU which will access the erased tables!

Besides: thanks to Thorsten Otto you may build your own 2.06: http://www.atari-forum.com/viewtopic.php?f=16&t=31243
Or you may ask Holger Zimmerman (pakman). If he doesn't know... nobody knows. :D
Last edited by Arne on Fri Mar 03, 2017 5:12 am, edited 1 time in total.
Image

rpineau
Atari Super Hero
Atari Super Hero
Posts: 501
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: 68030 PMMU config help needed

Postby rpineau » Fri Mar 03, 2017 5:08 am

Hi Arne.
Thanks for taking time to reply.

the AS_CPU was a test, it's not needed.
I'm no sure disabling the MMU solves the data caching issue ? But we can try that.
Also I agree your equation does the same but as we're testing we're separating the cases to see what works and what doesn't.

The schematics is probably the same as the on in the 68030 UM where I took mine from.

/CBACK , /STERM , /CIIN and /MMUDIS are pull-up to VCC via 4.7K.
/CBREQ is not connected (no burst mode here), /CIOUT, /STATUS and /REFILL are not connected.

I'm not sure what Juliusz used for his test in term of HDD driver. I'll make my adapter (I made oen and send it to him so not I need to make another one :) ) this weekend and will be able to run more tests. I'm using HDDRiver 10.01

As for the pmmu config in auto folder, what you're saying makes total sense. But this would at least make it work after power cycling. I know the TOS does a reset really (it's the 2nd instruction after a move/w #$2700,sr on ST/STE and I think the 3rd instruction on TT/Falcon) and if we wanted to make the reset work we would need a patch to jump to some code that disable the PMMU and return to the instruction after the reset (the reset being move after the code that disable the pmmu).
But at least putting such a prg in the auto at first would allow us to make sure this is indeed the issue but in my code (zip file above), I get a F-Line exception when trying to debug this in Hatari (I'll be able to do some real debugging on the MSTE hopefully this weekend by putting mon030.prg in the auto before the pmmu conf code).

I've read the post about the TOS 2/06/3.06 build with great interest :) but seems I would need the Alcyon compiler/assembler to build it so this is not a "ready to go" solution yet but definitively something to look into to easily patch a TOS 2.06 for 68030.
Thanks for all the suggestions :)

Regards, Rodolphe
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

User avatar
Arne
Captain Atari
Captain Atari
Posts: 400
Joined: Thu Nov 01, 2007 10:01 am

Re: 68030 PMMU config help needed

Postby Arne » Fri Mar 03, 2017 5:22 am

rpineau wrote:I'm no sure disabling the MMU solves the data caching issue ?

I thought the main issue is with the MMU?

You may try KAOS (@ $FC0000). I guess you do the /CE and/or /OE asserting of your EPROMs/Flash by VHDL so changing the address should not be much work. KAOS will not init all STE hardware (DMA sound...) of the STE but it may boot to the desktop. Probably not many people tried that as it is no viable solution for the STE.

rpineau wrote:I've read the post about the TOS 2/06/3.06 build with great interest :) but seems I would need the Alcyon compiler/assembler to build it so this is not a "ready to go" solution yet but definitively something to look into to easily patch a TOS 2.06 for 68030.

I haven't tested it yet myself but it should be ready-to-go as the Alcyon comes pre-compiled in the /bin folder. Just read Thorsten Otto's comments carefully and ignore Atarizoll's "comments".

I tried to connect my PC with PARCP and Ghostlink to my TT yesterday. To no avail.... Wanted to transfer that archive and check myself. :?
Image

rpineau
Atari Super Hero
Atari Super Hero
Posts: 501
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: 68030 PMMU config help needed

Postby rpineau » Fri Mar 03, 2017 6:18 am

Sorry . I wasn't clear I guess :)
We have a test board with a 68030 on the 68020 board ... just to test.
As this doesn't seem to work as it doesn't fully boot I was wondering if it's because TOS 2.06 is not installing a PMMU tree.
So I was trying to setup one from the auto folder as a test, which is why I did this post.
So may be our problem is not the PMMU but i'd like to rule that out by configuring it with a proper tree for the ST/STE/MSTE.
As I get a F-Line exception in Hatari when debugging my code, I thought to ask here and provided my code.

Your input has been very valuable though as it gave us other things to look at.

As for the TOS sources, yea I re-read the comments and will re-download the archive and transfer it to the MSTE or TT (I need to re-install mint to have a proper shell :) ).
I use the usb parcp from a Mac and that works very well. I also have a HxC floppy emulator which is also useful for transfer.
I any case thanks a lot for all your help and idea.

Regards, Rodolphe
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

User avatar
Arne
Captain Atari
Captain Atari
Posts: 400
Joined: Thu Nov 01, 2007 10:01 am

Re: 68030 PMMU config help needed

Postby Arne » Fri Mar 03, 2017 6:46 am

What I wanted to clarify regarding KAOS: it is a bullet-proof solution for 68030 speeders on a ST. So you may give it a try and see it it boots to desktop with D-cache on.

Do you use /ECS, /OCS in your logic to start a bus-cycle?

Regarding PARCP: I wanted to use the parallel cable.
Image

rpineau
Atari Super Hero
Atari Super Hero
Posts: 501
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: 68030 PMMU config help needed

Postby rpineau » Fri Mar 03, 2017 7:36 am

Ok I'll look for a KAOS TOS version tomorrow then.
As for /ECS and /OCS, no we're not using them to start the cycle, we're relying on /AS.
Our card is mostly based on the Motorola AN944 doc, LUCAS and other things we could find online. We then re-wrote the code in VHDL but it does the same thing for the major part. As far as I understand it, any cycle started using /ECS and /OCS needs to be validated by /AS or ignored if /AS is not asserted (cache hit).

As for PARCP, my mistake, I missed the part about the Ghostlink cable in your post (read to fast, sorry about that).
Regards,
Rodolphe
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

User avatar
Arne
Captain Atari
Captain Atari
Posts: 400
Joined: Thu Nov 01, 2007 10:01 am

Re: 68030 PMMU config help needed

Postby Arne » Fri Mar 03, 2017 8:04 am

rpineau wrote:As far as I understand it, any cycle started using /ECS and /OCS needs to be validated by /AS or ignored if /AS is not asserted (cache hit).

True.
Anyway: someone disassembled and commented the bootcode of 2.06/3.06 (it's somewhere on this forum).
From my local copy I quote this little snippet which seems to be included in 3.06 but not 2.06:

Code: Select all

IF ROM_TOS306
         move.l    #$808,d0
         movec     d0,cacr

         moveq     #0,d0                  ; set vector base to address 0
         movec     d0,vbr
         pmove     ($e35fe4).l,tc         ; 0L - disable PMMU
         pmove     ($e35fe4).l,tt0         ; 0L
         pmove     ($e35fe4).l,tt1         ; 0L
         frestore  ($e35fe4).l            ; 0L - clear FPU

         btst      #0,(scu_gp1).w         ; memconfig valid?
         beq.s     reset3               ; (no)
ENDIF

It's directly behind the jump to the diag cart.
#$808 clears D-Cache and I-Cache. VBR should be set by 2.06, too. Otherwise an 020 should crash if VBR does not point to $0 - as I understand it.

rpineau wrote:As for PARCP, my mistake, (...)

Nope. PARCP = parallel, Ghostlink = serial.
Image

rj1
Atari freak
Atari freak
Posts: 56
Joined: Mon Sep 28, 2015 8:01 pm

Re: 68030 PMMU config help needed

Postby rj1 » Fri Mar 03, 2017 8:32 am

Thanks for all the replies.

rpineau wrote:With the 68020 in place with have no blitter or DMA issue (but there is no data cache on the 68020).
I found 2 contradictory statements in the various things I read online. One says the all the ST RAM should be cacheable, and one says it shouldn't be because of the blitter and DMA.
But obviously it works on the Falcon as both cache are enabled and it has a blitter and more than one DMA device (in one chip..).
I'll have to ask Juliusz but from memory, blitter enable or not doesn't make any difference.
Thanks, Rodolphe


Yes, blitter made no difference for data cache testing of 030. For test, it was even removed form the board (with proper links added).

Arne wrote:ehmmm... why don't you just assert /MMUDIS?


We will try that.

Arne wrote:I see that you do not use /CPU_AS to validate data accesses. Why?


We are now, it's just not in the code Rodolphe posted. This makes sense as we know address bus is stable and valid when AS_CPU asserted, so we don't latch some not yet settled address number.

Arne wrote:There is an article for a 68030 daughterboard to be placed in a 68020 socket in c't 07/1993. Unfortunately they do not talk about the OS.
What's the level of /CBACK and /STERM? You tied them to Vcc?
The c't article shows a schematic where /CBREQ is tied to Vcc and /CBACK is left open. Don't know why they pull an output to some level.


We have that article.
Our /CBACK and /STERM are pulled up high.
/CBREQ is floating on our adapter. This is indeed interesting that they pull it high. Maybe a bug is in the schematic only, as there is CBACK and CBREQ next to each other in there - anyone has this board and can confirm this pin is floating and not pulled up?

Arne wrote:About 68030 and 2.06 the PAK 68/3 article reads:
- some HDD drivers have problems with a non-initialised MMU. AHDI hasn't.


I'm using ppera's driver + CE. But the issue is present also when booting from floppy and no CE connected.

Arne wrote:You may try KAOS (@ $FC0000). I guess you do the /CE and/or /OE asserting of your EPROMs/Flash by VHDL so changing the address should not be much work. KAOS will not init all STE hardware (DMA sound...) of the STE but it may boot to the desktop. Probably not many people tried that as it is no viable solution for the STE.


We can try KAOS.

Arne wrote:Do you use /ECS, /OCS in your logic to start a bus-cycle?


We don't use those at all.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: 68030 PMMU config help needed

Postby dml » Fri Mar 03, 2017 9:46 am

Don't know if it's helpful but here's my implementation of the Falcon030 PMMU setup.

The tree it implements is a close match for the F030 tree, with some extra tweaks by me (to add an un-cached shadow of main memory). There's a commented block of text showing the tree layout and mapped spaces.
You do not have the required permissions to view the files attached to this post.

rpineau
Atari Super Hero
Atari Super Hero
Posts: 501
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: 68030 PMMU config help needed

Postby rpineau » Fri Mar 03, 2017 3:39 pm

Thanks DML. I'll take a look at your code asap.
Arne, I also have that disassembled TOS 2.06/3.06 code and I see the part you're referring to to disable the PMMU. Latter in the code they also set it and the table looks very similar to mine :

Code: Select all

setupPMMU:   lea       ($700).l,a0
         lea       ($e363f0).l,a1         ; translation table
         move.w    #$3f,d0               ; 64 descriptors
setupPMMUl:   move.l    (a1)+,(a0)+
         dbra      d0,setupPMMUl

* PMMU Table:
* $x.......
*   $700: $00000742,$10000001,$20000001,$30000001,$40000001,$50000001,$60000001,$70000001,
*   $720: $80000041,$90000041,$A0000041,$B0000041,$C0000041,$D0000041,$E0000041,$00000782,

* $0.......
*   $740: $000007C2,$01000001,$02000001,$03000001,$04000001,$05000001,$06000001,$07000001,
*   $760: $08000001,$09000001,$0A000001,$0B000001,$0C000001,$0D000001,$0E000001,$0F000001,

* $Fx......
*   $780: $00000041,$01000041,$02000041,$03000041,$04000041,$05000041,$06000041,$07000041,
*   $7a0: $08000041,$09000041,$0A000041,$0B000041,$0C000041,$0D000041,$0E000041,$000007C2,

* $00...... or $FF......
*   $7c0: $00000001,$00100001,$00200001,$00300001,$00400001,$00500001,$00600001,$00700001,
*   $7e0: $00800001,$00900001,$00A00001,$00B00001,$00C00001,$00D00001,$00E00001,$00F00041,

* The purpose of the PMMU is to disable caching in the area of the address space that doesn't contain ram:
* $00F00000..$00FFFFFF
* $80000000..$EFFFFFFF
* $F0000000..$FEFFFFFF
* $FFF00000..$FFFFFFFF

         pmove     ($e364f0).l,crp         ; CPU Root Pointer: $80000002,$00000700: 4 byte descriptor, at $700, lower limit: $00000
         pmove     ($e364f8).l,tc         ; Translation Control Register: $80F04445: MMU enabled, pagesize = 15, bits: 4,4,4,5
         pmove     ($e364fc).l,tt0         ; Transparent Translation Register 0: $017E8107
         pmove     ($e36500).l,tt1         ; Transparent Translation Register 1: $807E8507
         rts


but my code (in Hatari) trigger a line-F exception on the pmove to tc so my guess is thatI'm doing something wrong :)

Thank you all for your help
Rodolphe
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1563
Joined: Sun Jul 31, 2011 1:11 pm

Re: 68030 PMMU config help needed

Postby Eero Tamminen » Sat Mar 04, 2017 10:21 pm

rpineau wrote:but my code (in Hatari) trigger a line-F exception on the pmove to tc so my guess is thatI'm doing something wrong :)


Note that if you enable enable MMU emulation in Hatari, Hatari's (WinUAE) CPU emulation changes to less accurate mode, which doesn't emulate caches effect on how many cycles things take.


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 1 guest