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.

Explain How An MMU Workspage  1 2 3 

Peeri the Sunlight

Posts 71
05 Dec 2017 02:36


I wonder this pointless debate about MMU... Amiga don't use MMU, apollo team is keen to resurrect Amiga, they make it and they decision how to proceed.
If somebody wish to resurrect 68k Mac, go a head, don't waste time here. AMAX, Fusion, Shapeshifter etc are nice toys, but if I would love MAC, I would buy a MAC... I love Amiga, and i'm happy to say that I have Vampire :)


Michal Warzecha

Posts 209
05 Dec 2017 07:51


Yes, You're right here. I'm not even try to pushing any one here to rebuild existing MMU in core to work like old one, but if 080 MMU is as goog as Gunnar said, mayby there is a chance to use it?
I have no clue how MMU works because I'm not a programer, but I think it's depended of software, OS probably. Mayby there is a chance to force AOS to work with new MMU?


Samuel Crow

Posts 424
05 Dec 2017 10:36


Michal Warzecha wrote:

Yes, You're right here. I'm not even try to pushing any one here to rebuild existing MMU in core to work like old one, but if 080 MMU is as goog as Gunnar said, mayby there is a chance to use it?
  I have no clue how MMU works because I'm not a programer, but I think it's depended of software, OS probably. Mayby there is a chance to force AOS to work with new MMU?

What do you mean?  The current MMU is used to remap memory.  If the memory is where you want it to be, why move it?  What do you want to use it for?

First off, hard drive paging is only possible if you have free address space.  We would need a 64bit AROS variant to make effective use of it at this point since AmigaOS can only address 1.5 Gigs maximum RAM anyway, in 32 bit mode.

As for memory protection, it can't be fully implemented in AmigaOS even if a fully compatible MMU architecture is present due to design decisions early in the operating system's evolution.  We'll have to use other techniques for crash prevention anyway so, why bother with memory protection?

I don't know what else to use the MMU for.


Michal Warzecha

Posts 209
05 Dec 2017 11:28


To be honest I'm not interested in MMU, because for WHDLoad and moving icons in Workbench it's not necesary. But some ppl ask for it because they can't run some rare programs. I don't know how MMU works and why others need this so much, and I can understand team they don't want waste time to change current MMU to archaic one. That's why I'm only asking: did current MMU allow to run all of this not working stuff via some AOS patch or something? Without touching core? I have find some posts that some programs don't really use MMU, but require it's presence. Mayby there is some way to cheat those programs?


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
05 Dec 2017 11:36


Michal Warzecha wrote:

But some ppl ask for it because they can't run some rare programs.

 
I think this is a misunderstanding.
 
 
First of all AMIGA OS - does not use and does not need an MMU.
 
An MMU is traditionally used for 3 things.
a) Virtual memory = Not used on AMIGA / Needed by Linux
b) Memory protection = Not possible on AMIGA / Used by Linux
c) Finding coding error / bad pointer = Used by AMIGA with Enforcer
 
 
The 32bit 68K CPUs have a normal address range of 4 GB of memory.
But AMIGA OS does support "only" 2 GB.
 
The 68k MMU design have one page descriptor entry of 32bit size per page. As more memory the system has as more descriptors are needed.
 
As for each memory access the MMU needs to lockup and check the descriptor entry - this would slowdown the system to turtle speed.
To prevent this the CPUs have internal descriptor caches.
These caches have of course by design a limited size.
 
This means of your program uses more memory than your MMU cache size can cover then your system will run slower.
 
 
The old 680x0 MMU designs have 3 major drawbacks.
 
A) They do not support 64bit memory
b) They are not able to support NUMA bus systems, with multible memory controllers
C) The descriptor layout is "mixed" and the not efficient for systems like AMIGA OS - which want to use the MMU primarily for debugging.
 
 
The 68080 is designed differently to fix all 3 problems.
 
The 68080 does "split" the memory mapping and memory protection into
2 different units.
The 68080 MMU for mapping and the 68080 MPU for protection.
The MPU uses much more efficient, compressed description information.
This new compressed MPU design allows to enable MEMORY / protection on the AMIGA - but now without slowing the system down.
 
So this is a huge improvement.
 
 
 
 
 
Traditionally Using an MMU for debugging is only possible on VAMPIRE for free.

Of course the old tools like Enforcer can NOT support the new features of APOLLO.
APOLLO has a number of new features which improve debugging.
a) compressed MPU design = Debugging without slowdown
b) Breakpoint and Watchdog support = much more efficient and flexible then what previous cores could offer.
c) Several Internal Trace register = providing extra debugging history where the CPU came from etc

Of course to use these new features, a new tool needs be used.
This new tool is there and is tested by the team.


Peter Heginbotham

Posts 214
05 Dec 2017 13:04


how does a zorro III slots work on a A4000ec30, but this is all moot as none of the current vampire machince have Zorro III. For me these would be a specific use case when the A3000 or A4000 are supported and given it would be based on the V4 most of the cards would be redundant.
 


Michal Warzecha

Posts 209
05 Dec 2017 13:51


Gunnar von Boehn wrote:

 
  Of course to use these new features, a new tool needs be used.
  This new tool is there and is tested by the team.
 

 
  Wow, this is probably great news :)
  So, if needed tool is under development, I think no one should raise any objections now. In my opinion MMU topic shuld be closed until MMUVTool arrive.
  To be honest, too much people ask about too much things now. They want new and rare features, but They still don't even have Gold 2.7 or 3.0 and have anu clue how new Vampire is working. Hope new public core release arrive soon and whole team should rest for a while when ppl and trolls start testing new things :)

Thank's for explanation Gunnar.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
05 Dec 2017 14:33


wrote:
For me these would be a specific use case when the A3000 or A4000 are supported and given it would be based on the V4 most of the cards would be redundant.
 

 
No you do NOT need this.
Also not on A4000 + Vampire.
 
Kolla, mixes here up stuff again, and spreads nonsense.
One does needs an MMU to use Zorro.
 
The MMU usage for Zorro is a very ugly hack to tweak for some 68040 Systems. The 68040 CPU CPU has a design limitation.
The trick turns of 68040 CPU bursting for some Zorro cards.
 
68080 does not have this problem to start with.
So this ugly hack would not make sense on Vampires at all.
 


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
05 Dec 2017 15:06


Thread cleaned up a little.
Too much off-topic and also false stuff posted was posted.

The purpose of the forum is to help people and answer technical question. Please help here also and try to stay on topic.



Mack B Wallace

Posts 2
19 May 2018 16:12


Hi all,

The topic of the MMU interest me - especially with the Apollo core and the Vampire. I know there have been quite a few postings regarding whether an MMU is needed, or that it is a waste and 'just slows down the CPU,' and some other garbage to chuckle at.

I know, from a previous posting of mine, that some are very adamant about the Apollo core not being an emulation. I understand the point of view. However, IMHO, it is an emulation in hardware. And there is nothing wrong with that... especially when what has been made is better in so many ways than the original. The Apollo core and the hardware it sits on is f...ing awesome, and it is something that all the guys involved in bringing it to life can and should be enormously proud of.

That being said. My interest in an MMU on my Amiga is because, actually, without one, my Amiga operating system, provided by Commodore, does not work. Now, to be fair, I am talking about Commodore's release of AT&T Unix SVR4 for use on the A3000 and the A2500 with the 2620/2630 accelerators. That puts me in a rather niche market.

So some minor corrections - yes, some Amigas have MMUs, and some even have the MMU on the same chip/die as the CPU (i.e. 68030, 68040, 68060). And there are some AmigaOS programs that make use of a MMU (e.g. WHDload), and some operating systems that require one (e.g. Amiga Unix, Linux, etc.).

I would love to run Amiga Unix on an Apollo core. The thought of compiling large programs in 1/2 or 1/4 of the time rather than waiting hours or even half a day is very appealing. (I've never gotten the GNU cross compiler on another platform to work - even with help from some on the GNU mailing list).

But I sympathize with the Apollo core team. Motorola seemed to make every MMU a bit different, and in many cases, incompatible with one another. So which does one chose to emulate / replicate? I personally am partial to the 68030 version, because that or the 68851 MMU is what Amiga Unix runs on. But those who run Linux, probably want to see the 68060 version to take advantage of the most mature 68k kernel and software. And, to my understanding, a MMU is no simple piece of hardware to implement either - let alone the prospect of different versions to make 'someone' happy.

So it is something I watch and (usually) silently hope for.
But I still appreciate the work of the Apollo and Vampire teams.

...just my two bits worth... if that.

 


OneSTone O2o

Posts 159
19 May 2018 16:38


I mostly agree with you, except for one thing: Apollo is not an emulation. Because Emulation is software running on different CPU. But Apollo runs natively in a chip, without code transfer to a different processor type.


Roy Gillotti

Posts 517
19 May 2018 16:50


oneSTone o2o wrote:

  I mostly agree with you, except for one thing: Apollo is not an emulation. Because Emulation is software running on different CPU. But Apollo runs natively in a chip, without code transfer to a different processor type.
 

  Not to mention VHDL code of the FPU core can be directly used to create real silicon designs at a Fab house. Price wise this would be a huge endeavour.


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
19 May 2018 17:03


Mack B Wallace wrote:

  That being said. My interest in an MMU on my Amiga is because, actually, without one, my Amiga operating system, provided by Commodore, does not work. Now, to be fair, I am talking about Commodore's release of AT&T Unix SVR4 for use on the A3000 and the A2500 with the 2620/2630 accelerators. That puts me in a rather niche market. 

Its a bit niche, but 68k-compatibile MMU implementation would bring:

a) Few AmigaOS tools incl. virtual memory (not an priority on 128/512mb systems, but then again ...)

b) m68k Linux would work out of box. Not optimized, but would work.

c) Would aid some Atari ST/TT/Falcon compatibility

While not a priority, it has some sense.




M Rickan

Posts 177
19 May 2018 17:36


Roy Gillotti wrote:

Not to mention VHDL code of the FPU core can be directly used to create real silicon designs at a Fab house. Price wise this would be a huge endeavour.

That cost is also relative and constantly dropping.

Going to silicon isn't cost prohibitive if you have a viable product.




Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
19 May 2018 18:27


Gunnar von Boehn wrote:

  This new compressed MPU design allows to enable MEMORY / protection on the AMIGA - but now without slowing the system down.
 

 
  Interesting, I have missed this in new MMU description.
 
  Any plan to implement/use it in e.g. AROS 68k?
  how big is the penalty, and could v4 handle it a bit "better" under AmigaOS? Could some Guru handler be developed for OS 3.9 as external tool, similar to old MMU enforcer in this matter?
 
  Seems 080 goes 64-bit and mem protected too :-) Since its single core design SMP is currently not an issue.
 


Eric Gus

Posts 477
19 May 2018 21:46


Not an emulation, but better to think of it as a "hardware chip logic clone" implemented (or reimplementation as the case maybe) in new modern reconfigurable silicon..  for all purposes its "hardware" its a chip just like the original fabbed chip was .. no real difference except how the circuit pathways are put on the chip.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
20 May 2018 07:11


Vojin Vidanovic wrote:

Could some Guru handler be developed for OS 3.9 as external tool, similar to old MMU enforcer in this matter?

Yes such Enforcer like tools was developed already.
Flype wrote it.
You can use it today already on Vamp.


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
20 May 2018 07:21


Gunnar von Boehn wrote:

  Yes such Enforcer like tools was developed already.
  Flype wrote it.
  You can use it today already on Vamp.

Great! Its release to users/developers would be nice. A Linux kernel that has AC080 MMU support "some time later" and old design MMU could be largerly forgotten.

posts 58page  1 2 3