CPU Caches

[Muzza]

The other day, Ross had pointed out a problem in my cache flushing code which I fixed, and I was hopeful it could fix some compatibility issues some systems had. But then dlfrsilver reported some problems with my game on his A1200 with an A1230. Setting nocache on the CLI fixed it.

I load chunks of code from disk, both from the bootblock, and for each level (and dlfrsilver was only getting a problem on the 3rd level). After loading the code I do some relocation work on it, then I flush the cache using the below code (originally from SolidGold I believe), before jumping into it.

Supervisor    equ    -30

         move.l        EXECBASE,a6
        btst        #AFB_68020,AttnFlags+1(a6)
        beq            .skipFlushCache
        lea            flushCaches(pc),a5
        jsr            Supervisor(a6)
    .skipFlushCache:

flushCaches:
    mc68020
    movec    cacr,d0
    tst.w    d0
    bmi    .1            ; 68040/68060 I-Cache enabled?

    ; clear 68020/68030 caches
    or.w    #$808,d0
    movec    d0,cacr
    rte

    mc68040
    ; clear 68040/68060 caches
.1:    nop
    cpusha    bc
    rte

My question is, is the above code correct? And what else could I be doing that may be incompatible with caches? Am I right in thinking the cache only affects Fast RAM? I don't do any self modifying code, so the only other thing I could think of that may be cache unfriendly would be things like inserting values into copper lists in Chip RAM.

Any experience with common cache gotchas would be appreciated as I'm not sure where to start looking currently. Thanks

[Thomas Richter]

Originally Posted by Muzza

My question is, is the above code correct?

No. To clear the caches, call "CacheClearU()", an exec function, which takes care of all processors and cache types. You only need to do this if you modify code, or load data as code. The typical candidates such as starting a process or creating a task perform this already for you, thus it is unnecessary in many situations.

[ross]

Originally Posted by Muzza

... But then dlfrsilver reported some problems with my game on his A1200 with an A1230. Setting nocache on the CLI fixed it.

This is significant: if the cache flush code is the same why only a sub-level is affected?
Full deactivating the caches completely changes the cards! Hence a different previously hidden problem (a race condition) may not happen.
I would also investigate elsewhere.

EDIT:
However if exec is valid and usable calling CacheClearU() is the right way, so you can get rid of any doubts on your code.
I would use direct control of the caches registers only after a complete system takeover.

[Muzza]

I wasn’t clear but yes this is all after a system takeover.

[phx]

Maybe you cannot even call Supervisor() after a complete system takeover. At least it is not advisable. Or did you leave the OS structure intact?
BTW, CacheClearU() doesn't help when you intend to support Kickstart 1.x.

[Thomas Richter]

Kick 1.x will not work with any processor with caches that are "worth mentioning", i.e 68040 and up.

[a/b]

Code looks OK to me, I use a similar setup and it's been fine. Probably a problem elsewhere.
If you are killing the system (well, depends... are you also trashing it or just disabling via Disable()/$dff09a?), for utliity functions that need supervisor instructions you could consider using trap vectors.
If calling Supervisor() is safe then calling CacheClearU() is also safe, and should be a preferred option (2.0+), but as mentioned, you'd still have to handle 1.3 and 040+ manually.

[roondar]

I'd wager this question is for Muzza's excellent Turrican 2 AGA project, in which case Kickstart 1.3 is not really a problem to worry about.

[Don_Adan]

If this is AGA version, then no kick 1.3. This is logical, only kick 3.0 or higher.

[Muzza]

Thanks for the replies, I do a system takeover but keep the system intact. And given that this is for OS2.0+, it seems sensible to change to use CacheClearU.
I agree it is probably just revealing a problem elsewhere, so I'll continue to look into that.

[Bruce Abbott]

Originally Posted by Muzza

After loading the code I do some relocation work on it

Why do you do this?

[phx]

He mentioned that he has taken over the system. Probably he even uses some trackloader for the code. So you have to do relocation yourself to support different Fast RAM expansions. At least this is what I do in my games...

[meynaf]

IF the game does not make use of extra computing power that accelerated machines have (i.e. pure 68000 speed is always enough) then you might be better off by turning caches off at startup, before the takeover.

[Muzza]

Originally Posted by phx

He mentioned that he has taken over the system. Probably he even uses some trackloader for the code. So you have to do relocation yourself to support different Fast RAM expansions. At least this is what I do in my games...

Yes, three code modules with internal references and which make calls to other modules. They are loaded into dynamically allocated memory, so all the internal and external references need relocating to point to the correct locations depending on where they are in RAM and where the other modules are.

[Muzza]

Originally Posted by meynaf

IF the game does not make use of extra computing power that accelerated machines have (i.e. pure 68000 speed is always enough) then you might be better off by turning caches off at startup, before the takeover.

It targets 68020, so I'm assuming turning off cache would have negative affects there too.


I implemented the CacheClearU change, and spent a lot of time making some copper code robust (because transitioning between copper lists in between game levels was my number one suspect for a possible race condition).
Unfortunately the reports I've had back from some testers who were good enough to try it for me are that it now crashes on level 2.


Next possible culprit is the music. It uses the TFMX player, and given that I didn't write that code myself, but had to interface with it, and that it is interrupt heavy, maybe there is a some timing issue there. But I'm just guessing really.

[Don_Adan]

For testing TFMX Pro player, you can disable music. But from my memory TFMX Pro player has no problem to works on fastest CPU's on Amiga. Only TFMX 7V player (Turrican 2 intro/outro) uses SMC in mixing routine.

[Muzza]

Originally Posted by Don_Adan

For testing TFMX Pro player, you can disable music. But from my memory TFMX Pro player has no problem to works on fastest CPU's on Amiga. Only TFMX 7V player (Turrican 2 intro/outro) uses SMC in mixing routine.

Useful to know thanks.
I use both players in my code, but the 7V one is not activated in the current build, because like you say, it's only for the intro.

[Muzza]

Disabling all audio makes no difference. I've tried various WinUAE settings to make it run faster trying to reproduce a race condition, but nothing. Very frustrating.

[Don_Adan]

Maybe this is simply code bug? Reading random value from Amiga memory or writing data in bad place?

[Muzza]

Originally Posted by Don_Adan

Maybe this is simply code bug? Reading random value from Amiga memory or writing data in bad place?

It is quite possible. I already do things like putting guards around all memory allocations in debug mode (to check for write overflows). Plus the code runs on PC too which would detect many common trashing bugs (apart from any in Amiga specific code of course).