Overview Features Instructions Performance Forum Downloads Products Reseller Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
VISIT APOLLO IRC CHANNEL



All TopicsNewsPerformanceGamesDemosApolloVampireReleases
Information about the Apollo CPU and FPU.

Explain How An MMU Workspage  1 2 3 

Gunnar von Boehn
(Apollo Team Member)
Posts 3155
15 Nov 2017 11:04


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.



Vojin Vidanovic

Posts 770
15 Nov 2017 14:28


Gunnar von Boehn wrote:

  AMIGA OS is not designed for this today.
  AMIGA OS can not easily use SMP.
  AMIGA OS can not control NUMA memory views.
 
  This feature would transparently support old applications.
  This can be done but is _NOT_ in planned for any releases coming soon.

The major problem is we are in no control on developing the AOS then.

Pardon my logic, but then I find backward compatibile MMU unneded.

a) AmigaOS: Debugging and enforcer tools can be made using new MMU
Yes, we will loose 101% backward compatibility, but there are very few things that use MMU on AOS 3.x.

b) AROS: Memory protection, virtual mem. etc. can be supported by AROS 68k supporting new MMU, just like 080 CPU

c) Linux: We just need a kernel release that includes support for new MMU

Surely, there are a way higher priorities. But its great news, since I believe this 3 tasks are less demanding then wasting LE space or slowing the CPU by emulating old MMU.


Peter Heginbotham

Posts 106
15 Nov 2017 17:23


Is the apollo MMU open for something like MMULib to use


Vojin Vidanovic

Posts 770
15 Nov 2017 17:37


Peter Heginbotham wrote:

Is the apollo MMU open for something like MMULib to use

I am not in the team, but to the best of publicly known, NO.

ApolloMMU is used for memory mapping and will be using for ROM
mapping with next cores, but just internally by the team.


Gunnar von Boehn
(Apollo Team Member)
Posts 3155
15 Nov 2017 18:28


Peter Heginbotham wrote:

  Is the apollo MMU open for something like MMULib to use
 

 
In theory, yes.
 
APOLLO supports right now several OS perfectly.
Those are AROS, ATARI, MAC, and AMIGA OS.
 
So the question is - if one solution for all of them makes most sense.
 
Also the only maintainer of MMU.lib is THOR.
THOR is a very busy person and trying to reach THOR to discuss technical detail was in my experience not easy, he seems to have very little time for actual development.
But he seems to spends a lot time in forums.
 


Vojin Vidanovic

Posts 770
15 Nov 2017 18:54


Gunnar von Boehn wrote:

  Also the only maintainer of MMU.lib is THOR.
  THOR is a very busy person and trying to reach THOR to discuss technical detail was in my experience not easy, he seems to have very little time for actual development.
  But he seems to spends a lot time in forums. 

Dont give up. Would be right person for ApolloMMU job :-)
That is, if he accepts.



Roman S.

Posts 127
15 Nov 2017 19:35


THOR might spend a lot of time on the forums, but he often posts interesting things... and I use a lot of his software - new layers.library, shell updates, utils from his MMUlib package... many still updated from time to time. And now he is probably busy with OS 3.1.4.


Vojin Vidanovic

Posts 770
15 Nov 2017 20:23


Roman S. wrote:

  . many still updated from time to time. And now he is probably busy with OS 3.1.4.
 

 
  If the Norse God is doing OS update first, let him finish.


Markus (mfro)

Posts 85
15 Nov 2017 20:55


I would assume that having DMA transfers work with CPU (virtual) addresses might be fine for Amiga OS (where - at least as far as I know - each process has its own unique address range), but is probably a no-go killer argument for Linux (where each process has the same virtual address range).
 


Gunnar von Boehn
(Apollo Team Member)
Posts 3155
15 Nov 2017 23:21


Markus (mfro) wrote:

  killer argument for Linux
 

The killer argument is memory protection.
You can prevent DMA from overwriting System resources.
Especially on the AMIGA where all DMA channels can be started from userspace - a typo in initializing one could cause DMA to kill the system - in worst case the DMA overwrite would go unnoticed.
 
DMA using the MMU in not invented by us.
This is a common feature in professional systems.
For them the killer argument is to use the virtualization on System level.  E.g. running ATARI and AMIGA in parallel.
Each having their own system not knowing about the other.


Mr Niding

Posts 225
16 Nov 2017 13:18


Thomas made a comment on aorg;

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".

http://www.amiga.org/forums/showthread.php?p=833216#post833216


Gunnar von Boehn
(Apollo Team Member)
Posts 3155
16 Nov 2017 13:31


Mr Niding wrote:

  Thomas made a comment on aorg;
 

   
Thomas misunderstands what we talk about here.
   
CachePreDMA() does nothing else than a slow and simple cache-flush.
A cacheflush is of course not needed by designs which offer HW-coherency.
But saving a costly flush was not the main point.
   
 
Our point is that we can provide memory protection on DMA.
We can prevent DMA from overrunning programs.
You can think of this like "Enforcer for the Chipset".
This was never possible on AMIGA before.
Also OS4 can not do this.


Account for Sale
(Needs Verification)
Posts 219/ 2
16 Nov 2017 14:26


Some sort of legacy MMU is needed if you want to have support for all kinds of legacy 68k operating systems. The sooner that exists, the sooner you can expand the user base across the various 68k platforms. The sooner that exists, the sooner you will have more developers using Apollo Core. and developers who are more eager to support "the real" MMU on their respective platforms.

Quite a few platforms are "doomed" to forever use legacy MMU. Like the old commercial ones, NeXTSTEP, SunOS, Apollo/DomainOS etc. Some old platforms have become open source in the meantime, and can in principle be "re-activated", for example Plan9.


Gregthe Canuck

Posts 215
17 Nov 2017 01:08


Gunnar has repeatedly mentioned that making the Apollo/Vampire the best solution for Amiga is their primary goal.

Other operating systems (such as Linux) are low down on the priority list. It would be a mistake to water down the team's time on even more obscure operating systems.

With limited time and resources it is important the team stay focused on one goal - a revived AMIGA 68K platform.




Steve Ferrell

Posts 185
17 Nov 2017 02:51


Account for sale wrote:

Some sort of legacy MMU is needed if you want to have support for all kinds of legacy 68k operating systems. The sooner that exists, the sooner you can expand the user base across the various 68k platforms. The sooner that exists, the sooner you will have more developers using Apollo Core. and developers who are more eager to support "the real" MMU on their respective platforms.
 
  Quite a few platforms are "doomed" to forever use legacy MMU. Like the old commercial ones, NeXTSTEP, SunOS, Apollo/DomainOS etc. Some old platforms have become open source in the meantime, and can in principle be "re-activated", for example Plan9.

The point of the Vampire has never been to support all those legacy operating systems you mentioned.  If you're interested in supporting those operating systems I suggest you stroll over to their respective forums and begin your trolling there.  We're pretty tired of your trolling here.  If enough people in those forums are interested in a revival then they can work to create their own FPGA solution for their platforms just as Gunnar and several others have done for the Amiga.

We're tired of all your whining on this and several other forums in regard to an MMU.



M Rickan

Posts 133
17 Nov 2017 03:31


gregthe canuck wrote:

  With limited time and resources it is important the team stay focused on one goal - a revived AMIGA 68K platform.

And of course what constitutes a 68K Amiga is subject to interpretation.

One side is saying that a revival must first be a reimplementation to ensure that existing software is supported. New and improved features are secondary because they will require new applications.

The other side maintains that reimplementing less frequently used features is less of a priority because few applications use them and new software development will only happen if new and improved features become available.

Neither side is right.

But what we do know: there are very few remaining features that need to be implemented to satisfy the first group. Once that is out of the way there's no looking back.



Samuel Crow
(Apollo Team Member)
Posts 270
17 Nov 2017 06:43


Gunnar von Boehn wrote:

 
  Our point is that we can provide memory protection on DMA.
  We can prevent DMA from overrunning programs.
  You can think of this like "Enforcer for the Chipset".
  This was never possible on AMIGA before.
  Also OS4 can not do this.

I like the sound of this.  This is forward thinking.  Some graphics card MMU architecture designs are limited to texture and shader buffers and make more circuits necessary for the CPU.  An integrated MMU Architecture is better for efficiency even if the SAGA core absorbs the MMU.


Account for Sale
(Needs Verification)
Posts 219/ 2
17 Nov 2017 22:10


Steve Ferrell wrote:

  The point of the Vampire has never been to support all those legacy operating systems you mentioned.

Vampire is not the topic here, the apollo core is, and Gunnar wrote the other day:

It was always clear that: APOLLO's roadmap includes to run everything any 68K can run. This means also including running Linux.



Steve Ferrell

Posts 185
17 Nov 2017 22:15


Account for sale wrote:

 
Steve Ferrell wrote:

    The point of the Vampire has never been to support all those legacy operating systems you mentioned.
 

 
  Vampire is not the topic here, the apollo core is, and Gunnar wrote the other day:
 

  It was always clear that: APOLLO's roadmap includes to run everything any 68K can run. This means also including running Linux.

 

 
Well, that's funny, because 99.9% of your posts on this forum and over at A.org are ones bashing the Vampire for its lack of an MMU.  And right now, the Vampire is the only thing running the Apollo core so take your trolling elsewhere.

And my comments regarding those other operating systems still stands.  If you're so hell-bent on reviving those obscure and dead systems then head on over to their respective forums and make yourself useful instead of repeating the same attacks here over and over
 


Vojin Vidanovic

Posts 770
17 Nov 2017 23:06


Account for sale wrote:

  It was always clear that: APOLLO's roadmap includes to run everything any 68K can run. This means also including running Linux.

 
  True, but that is in time. Hope you are all aware its a core that gets developed further, bugfixed and improved. As with FPU, one point of criticism might be gone in few months.

posts 49page  1 2 3