Trouble with chip ram data cache

[remz]

Hi everyone,

I am having a really hard time figuring out why on WinUAE 4.10.1, with 68040 + Data Cache Emulation enabled, I am getting strange color glitches in my game.

According to my tests, if I disable the data cache, the bug goes away.
My setup for the repro is like so:
- I have buffer allocated in Chip ram
- I am setting a few colors in that buffer
- Then I use the blitter to copy those colors into a copperlist (also in Chip)

The only far-fetched explanation I have would be as if the CPU writes to my chip ram buffer are not copybacked into memory: they remain in cache. So the blitter cannot fetch the values correctly and pushes garbage colors in my copperlist.

I am normally expecting all Chip RAM should be always non-data cacheable? And is WinUAE 4.10.1 emulating this behaviour?

[Toni Wilen]

Do you have MMU emulation enabled?

UAE 68040+ cache emulation has a special case: if MMU emulation is disabled, chip ram is forced non-data cacheable, even if data cached is enabled. But if MMU emulation is enabled: chip ram is allowed to be cached if data cache is enabled. MMU setup is expected to disable chip ram caching.

[remz]

Thank you so much, Toni: That was exactly it.
Disabling MMU and the issue is gone.

What I understand from this is that almost any 'old applications' using chip ram would fail even on a real Amiga in such scenario: Basically a 68040 Amiga with MMU needs to have the OS aware of the existence of the MMU and set up accordingly to always disable data cache in the whole chip ram address range (i.e.: between 256KB and 2MB depending on model).

[phx]

Originally Posted by remz

What I understand from this is that almost any 'old applications' using chip ram would fail even on a real Amiga in such scenario:

Not really. Either you boot from Workbench and 68040.library has set up the MMU correctly before enabling caches, or you boot from floppy disk, out of the boot block, with data caches not yet enabled. No problem in both cases.

Basically a 68040 Amiga with MMU needs to have the OS aware of the existence of the MMU and set up accordingly to always disable data cache in the whole chip ram address range (i.e.: between 256KB and 2MB depending on model).

Exactly. You should have configured your OS correctly, so 68040 or 68060.library can be loaded by SetPatch. Otherwise this is a user error.

Only in the case you want data caches on 68040 enabled with the OS disabled (i.e. starting from boot block), you have to setup the MMU yourself. Which could be quickly done with the Transparent Translation registers. Supervisor mode, Fast-RAM base address in d0:

        mc68040
        move.l  #$0000c040,d1
        movec   d1,itt0                 ; Cache Inhibit ChipRAM & Custom Chips
        movec   d1,dtt0
        and.l   #$ff000000,d0
        beq     .1                      ; main program in $00xxxxxx region?
        or.w    #$c020,d0
.1:     movec   d0,itt1                 ; Cache Copyback for Fast RAM
        movec   d0,dtt1

        ; paged MMU off
        nop
        moveq   #0,d0
        pflusha
        nop
        movec   d0,tc

[remz]

That must be it then: My setup in Winuae is workbench installed for a 68020. Basically the OS doesn't "know" it is a 68040 with MMU. I wonder why it happens that the MMU is enabled by default (?): it would have felt safer and more backward compatible to keep it disabled as well as caches, until the OS choose the enable them.

Many thanks to you as well!

[Thomas Richter]

The Os does know which CPU is installed. Just that SetPatch does not find the 68040.library, and thus caches stay disabled all the way on the 68040. However, there is even more trouble calling: The 68040 does not implement all FPU instructions,and thus may cause software alerts that are otherwise fixed by the 68040.library. Phx solution does not solve that, and it would neither work with Zorro-III expansion boards.

[remz]

Good to know, thanks.

It is not a worry in my game because I am targetting base 68000, no cache or no cache or mmu or fpu need not to be required nor used.

It just felt strange that enabling a hardware feature (i.e.: mmu) would lead to software bugs.

Side note: Apparently, the 68080 has a "smart data copyback cache" that is more compatible, although I didn't read into the implementation details.

[paraj]

You could also have a bug that only triggers under specific circumstances. WinUAE is great for debugging, but it's not perfect for ironing out defects that occur with real accelerators.

[SpeedGeek]

This problem is WinUAE specific. Real 68040 Amiga's disable the Chip RAM cache in hardware. The only thing the MMU can do in this case is determine if the no-cache mode will be serialized or non-serialized.

BTW, I'm considering moving this thread into support.winuae. Is there any reason why it should not be moved?

[Toni Wilen]

Originally Posted by SpeedGeek

This problem is WinUAE specific. Real 68040 Amiga's disable the Chip RAM cache in hardware. The only thing the MMU can do in this case is determine if the no-cache mode will be serialized or non-serialized.

Yeah but do all of them do that? I remember some 68060 (or 68040) board that didn't work very well if data cache was enabled without 680x0.library MMU setup (or using TTRs to disable caching in first 16M of address space). Perhaps they inhibit chip ram but not some important IO regions or something (or vice versa).

WinUAE by design does the worst case scenario. Unless it is confirmed all (mostly sane) 68040/060 boards do work with data cache enabled but without TTR or MMU setup. (and also enable copyback mode when talking to compatible RAM)

[Thomas Richter]

Typically, TTx registers are initialized to inhibit caching in the low 16MB area, and caching is enabled for all areas above the 24 bit address space. That is not entirely correct, but typically sufficient to load at least SetPatch and the 68040.library which then provides the correct and robust MMU setup.

[SpeedGeek]

Originally Posted by Toni Wilen

Yeah but do all of them do that? I remember some 68060 (or 68040) board that didn't work very well if data cache was enabled without 680x0.library MMU setup (or using TTRs to disable caching in first 16M of address space). Perhaps they inhibit chip ram but not some important IO regions or something (or vice versa).

WinUAE by design does the worst case scenario. Unless it is confirmed all (mostly sane) 68040/060 boards do work with data cache enabled but without TTR or MMU setup. (and also enable copyback mode when talking to compatible RAM)

The exec.library uses the CACR for CPU identification. So it is necessary to disable the cache first before modifying the CACR. The MMU is disabled at this time so the TTRs are the only way to keep the cache disabled while modifying the CACR.

Fat Gary disables the Chip RAM cache for the A3000 & A4000. Properly designed accelerator cards have logic to disable the Chip RAM cache for the other Amiga models.