News of Free 060 Like Apollo Core License

[Niding]

Putting in new stuff that would REQUIRE software to be rewritten/recompiled but not stuff that oldf software already support?

and also. ironic enough. not putting in stuff that HELPS developing new software.  it is like.. like.  releasing a new cpuarchitecture for the amiga and not release programmingsoftware with it.. (PPC anyone??

but I guess gunnar had this wet dream of MMX on the Amiga etc. so he completley forgot..  the rest of the worls..  yes.  his design..
but then.  WHY THE HYPE?  especially for stuff that will be "crap" even if they might be good?

well. yes. this IS repeating..

You dont need to recompile old software unless you want to utilize the full potential of the Vampire for that particular program.
And for the most part, Vampire will accelerate programs, and give the user more memory than has been the mainstream standard beyond relativly few that got into the higher end accelerators on the classic.

Again; you can just use the Vampire as a 1260 accelerator and ignore the "fluff".

[Niding]

Ok.

Its been repeatedly pointed to that FPU will be implimented in 2.7.

Your refusal to accept any input tells me you are a waste of time to discuss with.

Im checking out of this thead.

[Niding]

@Tellurium

I enjoyed your posts in this thread.

The level of nitpicking, regardless of target, be it AOS 3.x, AOS 4.x,Morphos, AROS, 68k, FPGA, PPC etc is quite selfdestructive.

Its almost like Life of Brian quarrel between The People's Front of Judea vs Judean's Peoples Front.

https://www.youtube.com/watch?v=WboggjN_G-4

[Niding]

@kreciu

I suspect the sheer work of making it x86 based would that many years, so not really realistic, espesially given aeon and acube has sunk alot into PPC.

Maybe Im wrong, but thats the first thing that comes to mind regarding platform move.

[Niding]

Gunnar made a general comment about the direction and intent of the Apollo core, which will adress relatively frequently asked questions;

Is was always clear that: APOLLO's roadmap includes to run everything any 68K can run. This means also including running Linux.
 
But we have a clear policy about future features:
We _NEVER_ promise the users features that are not available today but only on our roadmap.
Users always only guarantee stuff working today 100%.
 
This means even if we might even run internally Linux for testing.
As long we are not sure we can release it now.
Our official answer will always be "no you can not run Linux".

http://www.apollo-core.com/knowledge.php?b=2¬e=10876&x=1&z=Jg0cBR

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