Mmu?

[oRBIT]

Alooong time ago I was interested in how the MMU on the 68k was working. However I pretty much gave up because of lack of (human understandable) documentation. So my question is, has things improved?

If anyone knows, is this behaviour below possible/allowed using MMU-mapped memory?

move.l #1,$0

.. where location $0 is obviously "somewhere else"?

[Leffmann]

Originally Posted by oRBIT

Alooong time ago I was interested in how the MMU on the 68k was working. However I pretty much gave up because of lack of (human understandable) documentation. So my question is, has things improved?

No I don't think it's something you can stick in a tutorial or a "how-to". Everything is explained in detail in the M68K user manuals, though it's a lot to read.

Originally Posted by oRBIT

If anyone knows, is this behaviour below possible/allowed using MMU-mapped memory?

move.l #1,$0

.. where location $0 is obviously "somewhere else"?

Yes, in very simplified terms, you chunk up the logical space, where your program operates, in 4K or 8K blocks and map them to a different physical space where the bus accesses actually occur.

It would be easier to just pause the OS, move the vector base and other system stuff out of the way temporarily, and just let the program freely use the memory from address 0 and downwards.

[Toni Wilen]

Using MMU has also another problem: 68030 MMU instructions are completely incompatible with 68040+ MMUs and each CPU model has differences how MMU works.

68040 and 060 MMUs are nearly identical, 68030 is something completely different. 68030 can do everything (nearly) that 68040 and 68060 can do, opposite is not possible. Differences: far more page sizes, much more information about page faults is available in stack frames, can continue execution mid instruction after fault, much more flexible page maps, and much more.

[NorthWay]

The 030 is best left alone. The 040/060 mmu is straightforward.
I have played lots of games with it myself, and made tools that use them.

Any 040+ with a proper SetPatch loaded will already have set up mmu tables for you that you can take a look at.

(BTW, if you hack your Kickstart to start chipmem at $00010000 then you'll see Enforcer catch a few unexpected bugs, typically in very old software.)

[matthey]

Originally Posted by NorthWay

The 030 is best left alone. The 040/060 mmu is straightforward.
I have played lots of games with it myself, and made tools that use them.

Any 040+ with a proper SetPatch loaded will already have set up mmu tables for you that you can take a look at.

(BTW, if you hack your Kickstart to start chipmem at $00010000 then you'll see Enforcer catch a few unexpected bugs, typically in very old software.)

Different programs using the MMU can interfere with each other. It's also nice to have an easier interface for using the MMU. This is where it is worth considering at least supporting ThoR's mu system.

ThoR's tools remap low memory $0 to fast memory as this gives a speedup while maintaining better compatibility with games that need the VBR pointing to $0. It's also a good idea to report and protect low memory from writes as this is what many NULL pointers end up accessing (not always $0).

MuScan 40.3 (28.11.99) © THOR
[CLI 8]

68060 MMU detected.
MMU page size is 0x1000 bytes.

Memory map:
0x00000000 - 0x00003FFF CopyBack Single Remapped to 0x087D4000
0x00004000 - 0x001FFFFF CacheInhibit Imprecise NonSerial
0x00200000 - 0x00BBFFFF Blank
0x00BC0000 - 0x00BFFFFF CacheInhibit I/O space
0x00C00000 - 0x00D7FFFF Blank
0x00D80000 - 0x00DFFFFF CacheInhibit I/O space
0x00E00000 - 0x00EFFFFF Blank
0x00F00000 - 0x00F00FFF CacheInhibit
0x00F01000 - 0x00F21FFF CacheInhibit I/O space
0x00F22000 - 0x00F7FFFF CacheInhibit
0x00F80000 - 0x00FFFFFF CopyBack
0x01000000 - 0x06FFFFFF Blank
0x07000000 - 0x0801CFFF CopyBack
0x0801D000 - 0x0801FFFF CacheInhibit
0x08020000 - 0x0853BFFF CopyBack
0x0853C000 - 0x087CBFFF CacheInhibit Imprecise NonSerial
0x087CC000 - 0x0DF7FFFF CopyBack
0x0DF80000 - 0x0DFFFFFF CacheInhibit
0x0E000000 - 0x3FFFFFFF Blank
0x40000000 - 0x40FFFFFF CacheInhibit I/O space
0x41000000 - 0x5FFFFFFF Blank
0x60000000 - 0x7FFFFFFF CacheInhibit Imprecise I/O space
0x80000000 - 0xFFFFFFFF Blank

[NorthWay]

I made my stuff for myself as there were no available ones at the time.
THOR seems to have made sure to make versions of just about everything I put up on AmiNet.

But trust me, you want to change your chipmem to start at $00010000 if you can spare the extra 60K.

[daxb]

Someone knows for what is the first 4k (0x00000FFF) in my memory map? As far as I understand it is protected for access faults.

MuScan 40.3 (28.11.99) © THOR

68040 MMU detected.
MMU page size is 0x1000 bytes.

Memory map:
0x00000000 - 0x00000FFF Repairable Invalid (0x00000000)
0x00001000 - 0x001FFFFF CacheInhibit Imprecise NonSerial
0x00200000 - 0x005FFFFF CacheInhibit
0x00600000 - 0x00A7FFFF CacheInhibit I/O space
0x00A80000 - 0x00BBFFFF CacheInhibit
0x00BC0000 - 0x00BFFFFF CacheInhibit I/O space
0x00C00000 - 0x00D7FFFF CacheInhibit
0x00D80000 - 0x00DFFFFF CacheInhibit I/O space
0x00E00000 - 0x00E9FFFF CacheInhibit
0x00EA0000 - 0x00EBFFFF CacheInhibit I/O space
0x00EC0000 - 0x00F7FFFF CacheInhibit
0x00F80000 - 0x00FFFFFF WriteProtected Repairable Remapped to 0x01000000
0x01000000 - 0x0107FFFF CopyBack Blank
0x01080000 - 0x02FFFFFF CopyBack
0x03000000 - 0x07FFFFFF
0x08000000 - 0xFFFFFFFF Repairable Invalid (0x00000000)

[Kalms]

The library wants to force programs that access location $0 to be stopped, but programs that access $4 to continue running as usual. (Not sure about higher addresses.) The finest granularity the MMU has in 040 is 4kB, so it's a software/hardware hack:

the first 4kB is marked as "repairable invalid". This means
invalid - if a program accesses it, it will generate an access violation
repairable - the access violation handler may be able to do stuff and let the program continue to run

Marking the first page in this manner allows the library to manually inspect every single access to an address lower than $1000, and choose whether to let the program continue (program notices nothing strange except a small performance hitch) or to stop the program and signal a null pointer access to the user.

[daxb]

Thanks for explanation!

or to stop the program and signal a null pointer access to the user.

Is that a special error requester or something else? I`ve MuForce/sashimi running what in most cases show Byte/Word/Long read/write from/to <address>. This is not what you mean in case the address is lower than $1000?

[Kalms]

I don't know how the condition is signalled, never used it myself - just read through mmu.library related docs some time ago. It could potentially be that it is MuForce that reprograms the first page as invalid & installs its own access violation handler and prints messages to sashimi (so this would just result in a read/write to address 0 message).

[NorthWay]

This is how Enforcer works:
You access the lower 4K - exception happens.
Exception handler checks what you try to do:
If long read of $4 then it changes the protection of the first page, runs the instruction again (in trace mode IIRC), changes back the first page protection, and then goes back to normal execution.
If you tried something else then it changes page protection to something I can't remember so you get an exception along the lines of trying to access non-existing memory, and it sets back the protection again.

The version of Enforcer from C= pointed memory at chipmem when running the trace so a few tools modified it to point at fastmem instead to speed it up.

[Kalms]

oic, thanks!

[daxb]

Yup, thanks. I found some more info in MuForce.guide "68040 notes" part.

[Toni Wilen]

Enforcer sources are also really well commented if you want to see how MMU exception handlers work in real world program with different MMU models.