MMU test translate1 fails on real machine

[dirkwhoffmann]

Test case: https://github.com/dirkwhoffmann/vAmigaTS/tree/master/CPU/MMU30/30translate1

This test installs a very simple MMU table which maps the $Axxxxx range to $Dxxxxx. After enabling the MMU, it changes the background color to green by writing into $AFF180.

In FSUAE and vAmiga, it works just fine:

On the real machine, however, the test fails. The background color remains yellow and an illegal instruction is executed shortly after.

A misaligned MMU table was my first guess, but I think that's not the case (I am aligning the MMU table with align 4 which should align it to an address which is a multiple of 16). Unfortunately, I am running out of ideas of what could cause the crash.

[dirkwhoffmann]

I've found this in SetCPU.c (fish-0187.lha.zip):

/*
    SetCPU V1.4
    by Dave Haynie (released to the public domain)

... 

/* Page tables and other MMU stuff must be on a page sized boundary, and
   that boundary must be a power of two.  This routine allocates such an
   aligned block of memory. */

Looks like a smoking gun to me...

[dirkwhoffmann]

Update: I'm basically stuck. After trying a myriad of things, my test programs still don't run on the real machine.

Fortunately, I've managed to compile Dave Haynie's SetCPU program (which is pretty simple) with Beppo's amiga-gcc cross platform tool chain. This let's me to switch to Plan B: I'll use SetCPU as a starting point to write some simple MMU tests in C. Maybe it'll reveal why the real MMU doesn't like me (all my test programs work well in UAE).

Update 2: I've ordered an ACA1234 which is a 68030 accelerator card that can be plugged into the ACA500plus. I'll then have 2 machines with an 68030 for performing real-life tests.

[mras0]

Just a shot in the dark, but could it be some kind of cache effect (either on the page tables or on the mapped pages)? If you haven't already, you could try to flush all caches in a couple of strategic places either manually or with CacheClearE/CacheClearU.

Another thing that might be worth looking at something like MuFastRom (from mmu.libraray which has source available) does. You could dump the page tables before and after running it to see what it does exactly and compare it what you expect.

[dirkwhoffmann]

Just a shot in the dark, but could it be some kind of cache effect (either on the page tables or on the mapped pages)?

I though so, too, especially because whichAmiga is flushing the cache at various places (before and after changing MMU registers). I copied some of the code into mine, but it didn't help.

The next thing I'll try is to setup the exact same MMU table in a modified version of SetCPU that is used in my test case. Maybe my MMU table has an invalid structure for whatever reason.

Another thing that might be worth looking at something like MuFastRom (from mmu.libraray which has source available) does. You could dump the page tables before and after running it to see what it does exactly and compare it what you expect.

MuTools looks very promising. Unfortunately, I can't run it easily on my Terrible Fire A500, because I only have an HDF (MuTools didn't fit on an ADF). With the ACA1234, this shouldn't be a problem any more. A nice side-effect of having the ACA500plus involved is the ability to switch easily between different Kickstart Roms and Ram configurations.

[mras0]

Unfortunately I only have my 060 so I can't help in testing. Is your 030MMU known to be working? FWIW I've tried your test in WinUAE and it works fine except if I use Z3 fast ram, but I'm not sure if that's possible with your configuration. Could there be something related to non-24 bit addresses? Do you have a UAE config that matches the machine you're testing on?

Even if you can't currently test with HDFs you could create the page table dumps I mentioned in UAE and try them on your real machine if you don't want to wait on the new board.

[dirkwhoffmann]

Strange. SetCPU also has a FastRom option. After enabling it, both my 68030 Amigas crash. Interestingly, they crash the same way than my own test case.

The tool works well in FSUAE

and so it does in vAmiga:

[dirkwhoffmann]

@mras0: Could you perhaps try to run SetCPU on your 68060? Internally, it'll branch to different MMU code, but it's still interesting to see if it works there.

The screenshots above were generated with the version on this ADF.

setCPU is named file, because I converted the exe with vAmiga. At the moment, vAmiga renames every exe to file after dragging it into the emulator.

[mras0]

Don't think it recognizes >030 from skimming the source. Running it it says "System: 68030" and "file fastrom" doesn't crash but doesn't seem to do anything either.

[dirkwhoffmann]

Don't think it recognizes >030 from skimming the source

Yes, you're right. The 68040 code I was talking about is apparently in WhichAmiga.

What can be said, I think, is that my test hardware "has issues".

Let's consider options:

1. Trash the 68030/68040 project and let Moira focus on the 68000/68010/68020.
2. Take UAE as a reference implementation and mimic what we see there.
3. Try to make the testing hardware work.

At the moment, I tend to go for 2. My second choice would probably be 1.

[mras0]

Before choosing option 1 or 2 I think it would be worthwhile to create a UAE config that 100% matches your test hardware and a small self-contained test executable/ADF (+source) showing the issue and posting it to EAB (asm code forum). It's not unlikely that someone could spot an error (in either your code, the setup or UAE). At the very least someone with a know good 030 could run the code.

[mithrendal]

we could also ask someone who did already some serious Amiga MMU programming and has therefore the experience to judge what is going on here for example @MichaelSinz (AmigaEnforcer). Maybe he likes to give us a hint or direction to look at why on a real 68030 this test fails whereas on MMU supporting Amiga emulators the test passes ?

[dirkwhoffmann]

Just a side note: UAE tests have to be performed with latest WinUAE. Up to now, I've compared vAmiga with FSUAE, because WinUAE doesn't run on the M1. Apparently, FSUAE utilizes an outdated MMU implementation which is revealed, e.g., by the following test (ignore red and green colors by now).

The test creates a MMU table with an invalid table descriptor. Accessing this entry results in a bus fault. FSUAE reacts by creating a type B stack frame whereas latest WinUAE creates a (shorter) type A frame.

[dirkwhoffmann]

Let's consider options:

1. Trash the 68030/68040 project and let Moira focus on the 68000/68010/68020.
2. Take UAE as a reference implementation and mimic what we see there.
3. Try to make the testing hardware work.

I’ve reconsidered the situation and finally decided to pull the plug. The main reason is that I don’t have adequate hardware for testing. Based on my recent experience with accelerator cards, I - how shall I say - do no longer believe in them. Buying a stock A3000 is not an option either, because prices are beyond ridiculous. WinUAE is cumbersome for me, because I can't run Windows on my current dev machine. To make a long story short: The project has left the "fun zone".

I might resurrect the project when FSUAE has been updated with the latest WinUAE code.

FPU support might still come in form of a M68020 / M68882 combo, but not anytime soon. My next steps will be to remove MMU code from Moira and improve 68010 / 68020 accuracy.

Today, I've cleaned up my test cases a bit. I'll keep them in the vAmigaTS repo as they might be useful for other people.

For reference: Commit 115f803 ist the last commit containing MMU code.