Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Information about the Apollo CPU and FPU.

CPU Caches

Vincent Rivière

Posts 87
31 Oct 2016 21:36


I have been told that the Apollo Core handles the CPU caches transparently. In other words, that the caches are always on, and that the CINVA instruction has no effect. This looks quite surprising, so I would like to have more information about how to write correct code.

Here are a few very common cases.

1) Load a program and execute it.
The classic approach is:
- flush the data cache so the freshly read data will really be stored to RAM
- invalidate the instruction cache to force the CPU to load new instructions from RAM

How does the Apollo Core handles this scenario?
Is there some internal synchronization between the Instruction and Data cache, so maybe the RAM is not involved at all?

2) Read data with DMA
The most common case is floppy track data read with DMA. The DMA will store the data directly into the RAM. Then the CPU will use it.
But if the data cache is enabled, the CPU will read obsolete data from the cache, instead of the new data from actual RAM.
How can the Apollo Core handle this situation?


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
02 Nov 2016 21:40


APOLLO does cache fast-mem, but does NOT cache IO/Chipmem.

This means a Floppy-DMA writing to Chipmem will go to chipmem.
But Apollo will not cache chipmem.
This means every access to this memory will be executed and we will always read latest version from memory.
So this will work fine.

Then Apollo does cache fastmem.
Apollo has Harvard Cache design with 2 caches.
1 Cache for Instruction
1 Cache for Data

Now if we for example read from IDE.
The CPU will copy from IDE to Fast-mem.
And update the memory and the DCache...
Icache and Dcache of Apollo communicate.
This is a new feature.
All old 68K did only update DCache on writes.
Apollo will also update the Icache...

This means Icache is automatically always in Sync.




Markus (mfro)

Posts 99
03 Nov 2016 05:45


Gunnar von Boehn wrote:

    This means Icache is automatically always in Sync.
   

    I guess this mechanism will need to be extended (or "classic" cache flushes/invalidates implemented which would probably be more efficient as only the code itself knows about the right time to update) once you start integrating DMA-like functionality into the FPGA (i.e. in the standalone device)?


Vincent Rivière

Posts 87
03 Nov 2016 09:59


Gunnar von Boehn wrote:

APOLLO does cache fast-mem, but does NOT cache IO/Chipmem.

OK, this avoids any trouble.

BTW: I'm pretty sure that the QINDEX22 benchmark with EmuTOS for Amiga has been run from Chip RAM (so, with caches disabled). I would be curious to see the result from FastRAM :-)


Szyk Cech

Posts 191
03 Nov 2016 14:49


I suppose DCache is whole outdated after DMA writes to Chip memory.
But I suppose ICache will NOT be outdated after DMA writes to Chip memory. Is that true?!? Or maybe whole (DCache and ICache) are reread after DMA writes to Chip memory?!?


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
03 Nov 2016 22:55


Szyk Cech wrote:

I suppose DCache is whole outdated after DMA writes to Chip memory.
  But I suppose ICache will NOT be outdated after DMA writes to Chip memory. Is that true?!? Or maybe whole (DCache and ICache) are reread after DMA writes to Chip memory?!?

Not sure I understand you.

According to Commodore/Amiga guidelines - the Dcache will NOT cache the chipmem. So there is no problem at all - and nothing to worry about.
;-)




Markus (mfro)

Posts 99
04 Nov 2016 08:16


So the conclusion is - from what I learned from IRC - Apollo core currently just doesn't allow any other bus master than itself to the FPGA internal bus.
 
  Makes things a whole lot simpler.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
04 Nov 2016 18:50


Markus (mfro) wrote:

So the conclusion is - from what I learned from IRC - Apollo core currently just doesn't allow any other bus master than itself to the FPGA internal bus.

Err, no this is not how is it.

The fact is that the AMIGA chipset bus and the 680x0 CPU Bus in the Amiga are not fully connected.

The CPU can _NOT_ see DMA writes of the Chipset.
Therefore its impossible for any CPU or Accelerator in the AMIGA to snoop them.

This is not a limitation of the 68000 not Apollo-68080 this is how the AMIGA bus and chipset were designed.




Markus (mfro)

Posts 99
04 Nov 2016 19:14


Gunnar von Boehn wrote:
Amiga are not fully connected.
 
  The CPU can _NOT_ see DMA writes of the Chipset.
  Therefore its impossible for any CPU or Accelerator in the AMIGA to snoop them.
 
  This is not a limitation of the 68000 not Apollo-68080 this is how the AMIGA bus and chipset were designed.
 
 

Aha. Understood. Thanks, Gunnar.



OneSTone O2o

Posts 159
06 Nov 2016 12:38


How about ATARI, would Apollo be able to detect DMA transfers there (ACSI/FDD-DMA, STE/TT-DMA-Sound, but this is read only)?


John William

Posts 563
09 Nov 2016 01:51


Gunnar von Boehn wrote:

Markus (mfro) wrote:

  So the conclusion is - from what I learned from IRC - Apollo core currently just doesn't allow any other bus master than itself to the FPGA internal bus.
 

 
  Err, no this is not how is it.
 
  The fact is that the AMIGA chipset bus and the 680x0 CPU Bus in the Amiga are not fully connected.
 
  The CPU can _NOT_ see DMA writes of the Chipset.
  Therefore its impossible for any CPU or Accelerator in the AMIGA to snoop them.
 
  This is not a limitation of the 68000 not Apollo-68080 this is how the AMIGA bus and chipset were designed.
 
 

That works for me EXTERNAL LINK 

posts 11