News of Free 060 Like Apollo Core License

[grond]

Going back to the point of this thread, is it the "V2" or "V4" core that is being offered?

There is only one core which is adapted for different hardwares, namely the V2 and the V4. What features can and will be included into a core for a new hardware will depend on that hardware. If it has a relatively small FPGA, the FPU would likely have more microcoded (i.e. transparently software-emulated) instructions than if a larger FPGA was used.

[Niding]

And Gunnar has had 2 cups of coffe today it seems. He decided to go into more details about the MMU mechanics of legacy and Apollo;

http://www.apollo-core.com/knowledge.php?b=4¬e=11026&z=U8rPdR

The MMU topic seems to be confusing.

Lets us try to explain it.

An MMU is a piece of logic which allows to do three things.
a) It allows to map blocks of memory to another address.
A typical used block size is 4 KB.
Modern MMU also support bigger blocks e.g 64KB or 1MB.
Support for bigger blocks gives for some applications advantages.

b) the MMU allows to control cache setting for blocks.

c) The MMu allows to write/protect memory

APOLLO 68080 has a build in MMU.

Where is the difference between APOLLO and previous 68K CPUs?

Previous 68K CPUs did NOT come with a memory controller inside the CPU.
This means the memory access logic, the memory layout and control of this was always done OUTSIDE of the CPU.
This means while the CPU could inside change their logical view of the addresses with the MMU - it did not have any understanding of how this is mapped outside - as this understanding was controlled by the mainboard chips of the system.

Also the other way around - if the mainboard chips did do some DMA access - they could not know how these areas are mapped inside the CPU MMU.

This old concept did create many problems.
You all have seen those on the AMIGA.

DMA channels on the AMIGA did always work on physical address.
While programs would work on virtual addresses.
This mismatch was not solvable on AMIGA.
If an application was requesting DMA and was using its virtual view of addresses this was leading to crashes.

APOLLO fixes this problem.

APOLLO has the SAGA DMA channels inside the CPU core.
This means both DMA and CPU can use the same representation of the world.
This does solve a number of old problems.
The CPU does see automatically if DMA channels update memory which is cached by the CPU caches.
This means the CPU has always a coherent view of the memory.
This solves many old DMA issues and also allow the usage of APOLLO with many CPU cores. All CPU cores and the DMA engines share one coherent view of the world.

Another big difference to old 68K CPUs is that old 68K CPUs
did only support 1 bus.

APOLLO is designed as a system supporting several memory controllers.

Old MMUs did had a linear address view in 1 dimension.
APOLLO has a multidimensional view.

All these concepts which APOLLO offers are new to the 68K world.
These concepts do exist already today in other enterprise systems.

Coherent multi core systems supporting several memory channels or memory hierarchies are state of the art today.
Apollo is from ground up designed to support this too.

AMIGA OS is not designed for this today.
AMIGA OS can not easily use SMP.
AMIGA OS can not control NUMA memory views.

To provide a old fashioned 1 dimensional memory view to old AMIGA MMU applications - a clean solution would be to provide an sub MMU with 1 dimension inside the multidimensional MMU view.

This feature would transparently support old applications.
This can be done but is _NOT_ in planned for any releases coming soon.

[psxphill]

And Gunnar has had 2 cups of coffe today it seems. He decided to go into more details about the MMU mechanics of legacy and Apollo

Essentially, he still doesn't want to do it.

"To provide a old fashioned 1 dimensional memory view to old AMIGA MMU applications - a clean solution would be to provide an sub MMU with 1 dimension inside the multidimensional MMU view.

This feature would transparently support old applications.
This can be done but is _NOT_ in planned for any releases coming soon."

The rest seems like a sales pitch & I don't think I am the target audience of that pitch.

If it has a relatively small FPGA, the FPU would likely have more microcoded (i.e. transparently software-emulated) instructions than if a larger FPGA was used.

Are you referring to FEMU as micro code? Because that is misleading, I assume it's because the original 68882 was microcoded (as was the 68000) and it makes it an easier sell.

How would that work if you wanted to put the FPGA on a chip carrier with 68040 compatible bus for inserting into a Power Mac or Next Cube?

[guest11527]

And Gunnar has had 2 cups of coffe today it seems. He decided to go into more details about the MMU mechanics of legacy and Apollo;

http://www.apollo-core.com/knowledge.php?b=4¬e=11026&z=U8rPdR

Unfortunately, again misconceptions here. Of course AmigaOs has a mechanism to handle the differences between logical and physical addresses for DMA devices. This mechanism consists of two exec functions, namely CachePreDMA() and CachePostDMA(). And they are even used by the DMA-capable devices CBM manufactured. Not by some third-party devices drivers whose authors "believed to know better", and they are patched away to almost-nothing by some other group of users that "believe to know better what they are good for".

*Sigh*.

[TrashyMG]

Unfortunately, again misconceptions here. Of course AmigaOs has a mechanism to handle the differences between logical and physical addresses for DMA devices. This mechanism consists of two exec functions, namely CachePreDMA() and CachePostDMA(). And they are even used by the DMA-capable devices CBM manufactured. Not by some third-party devices drivers whose authors "believed to know better", and they are patched away to almost-nothing by some other group of users that "believe to know better what they are good for".

*Sigh*.

Gunnar answers your post on the bottom of this thread.
http://www.apollo-core.com/knowledge.php?b=4¬e=11026