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
The team will post updates and news about our project here

Running ATARI On 68080page  1 2 3 4 5 6 7 8 

Gunnar von Boehn
(Apollo Team Member)
Posts 6207
04 Jan 2017 10:33


Markus (mfro) wrote:

 
Gunnar von Boehn wrote:

    We have an MMU...
   
 

 
  ... and this MMU does what, exactly?
 

 
An MMU is used to define (manage) a number of attributes for memory areas.
 
The attributes can be:
  - Write-protected
  - Read-forbidden (causing exception)
  - Write-forbidden (causing exception)
  - Execute-forbidden (causing exception)
  - Memory Access Out of order allowed / not allowed (serial mode)
  - Icache/DCache-ing allowed
  - Allowed type of a memory access (Line Burst/no burst)
  - Also defining which of the memory controllers own this memory

Also the MMU can be used to MAP memory blocks to different areas in virtual memory.
 
Like for example mapping an in memory copy of the OS (TOS/KICKSTART) to the region of the original rom and write protecting it.



Cunn Pole

Posts 29
04 Jan 2017 11:37


I believe the implied question is "Will this MMU ever allow software that requires the 030/040 MMU to work unmodified?"


Markus (mfro)

Posts 99
04 Jan 2017 11:59


Gunnar von Boehn wrote:

 
Markus (mfro) wrote:

   
Gunnar von Boehn wrote:

  ...
    The attributes can be:
    - Write-protected
    - Read-forbidden (causing exception)
    - Write-forbidden (causing exception)
    - Execute-forbidden (causing exception)
    - Memory Access Out of order allowed / not allowed (serial mode)
    - Icache/DCache-ing allowed
    - Allowed type of a memory access (Line Burst/no burst)
    - Also defining which of the memory controllers own this memory
 
    Also the MMU can be used to MAP memory blocks to different areas in virtual memory.
  ...
 

 

  Thanks, Gunnar.
 
  That means that basically everything that FreeMiNT needs for memory protection is already there. Nice.
 
  I'd assume it can do the same an MC68851 or 030+ MMU can do, just the programming interface is different?
 
  Is this (the programming interface) documented somewhere?


Nixus Minimax

Posts 416
04 Jan 2017 12:14


Markus (mfro) wrote:
I'd assume it can do the same an MC68851 or 030+ MMU can do, just the programming interface is different?

I don't think it (currently) can. AFAIK the virtual-physical address translation is coarse and not done for individual pages but for rather large memory blocks of which there is a fixed number. Of course, the same mechanism could support 4k pages as in the 040 and 060 or whatever you want but still the number of entries in the table would remain fixed. In a system such as Amiga and Atari the mapping can be best put to use for moving rom and IO addresses around, remapping registers to inside the FPGA, mapping chipmem to local fastmem for chipset emulation and so on. A granular page-based system as required for Unix doesn't seem to be possible at present.



Markus (mfro)

Posts 99
04 Jan 2017 12:50


Nixus Minimax wrote:

 
Markus (mfro) wrote:
I'd assume it can do the same an MC68851 or 030+ MMU can do, just the programming interface is different?

 
  I don't think it (currently) can. AFAIK the virtual-physical address translation is coarse and not done for individual pages but for rather large memory blocks of which there is a fixed number. Of course, the same mechanism could support 4k pages as in the 040 and 060 or whatever you want but still the number of entries in the table would remain fixed. In a system such as Amiga and Atari the mapping can be best put to use for moving rom and IO addresses around, remapping registers to inside the FPGA, mapping chipmem to local fastmem for chipset emulation and so on. A granular page-based system as required for Unix doesn't seem to be possible at present.
 
 

 
  This limitation doesn't really affect FreeMiNT since it doesn't use virtual memory yet (i.e. the existing implementation maps virtual=physical). MMU is currently used only to protect system and individual process address spaces against each other.
 
  As long as the MMU would support 8k pages (other page sizes would require huge changes) for that we'd be good to go.

What you describe, however, sounds more like something similar to what the 030+ ACR registers do - a (very) limited number of 'attributable memory areas'. Not sure if this deserves to call it "MMU"...


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
04 Jan 2017 12:52


The concept of APOLLO MMU allows a LOT MORE than old 680x0 MMU.

The APOLLO MMU allows to manage several memory controllers.
This is a complete new - no 68k before did allow this.

Right now we keep this private as old software does not handle this.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
04 Jan 2017 13:12


Markus (mfro) wrote:

  This limitation doesn't really affect FreeMiNT since it doesn't use virtual memory yet (i.e. the existing implementation maps virtual=physical). MMU is currently used only to protect system and individual process address spaces against each other.
   
  As long as the MMU would support 8k pages (other page sizes would require huge changes) for that we'd be good to go.
 
  What you describe, however, sounds more like something similar to what the 030+ ACR registers do - a (very) limited number of 'attributable memory areas'. Not sure if this deserves to call it "MMU"...
 

 
OK, we need to go into the details.
We use the term MMU with different meanings.
 
Actually APOLLO has internally 2 units.
  a) MMU
  b) MPU
 

 
The purpose of the MMU is to provide control of the memory-type.
It does define memory blocks as :
IO-memory, in-order Memory, normal memory, non cacheable memory etc.
And it allows mapping/remapping of those blocks.
Like providing memory in "legacy" expansion areas like AMIGA RANGER memory... Stuff like that.
 
The MMU main purpose is controlling the memory from a hardware point of view. This allows us to set up the same hardware either as NEO-GEO, or AMIGA, or ATARI...
By mapping devices/memory/io-arrays to the appropriate space.
 
The goal of this unit is control of memory arrays.
The granularity is atm 256 KB per entry.
 
Set up of these configurations are done by our BIOS.
We provide user tools for replacing the ROM in memory.
But we do today not support legacy software changing the memory definitions/mappings.

 
 
On the other hand...
The MPU (Memory Protection Unit) is do assist programmers or debuggers by stetting protection bits for memory areas.
 
I understand you that actually you do NOT want to use our MMU but our MPU. You want to protect some pages for user-mode access.

We see the MPU as a device to help software developers.
We have more protection bits than old 68k did had.
E.g We allow to map areas as NO-EXECUTE.
This helps for debugging and for example allows protection against code in stack attacks.
 
This means our MPU can provide better protection than any previous 68k.
 
As you have the sources of Free-Mint it should be no problem to add support for our new protections bits to FreeMint to enable what you want.
 
We can work together on this if you like.


OneSTone O2o

Posts 159
04 Jan 2017 20:55


That sounds already better... :) But we are talking about system where major software is 20 years old and more. Developer scene is small. Would be nice if it could be mapped to 100% PMMU compatibility behaviour for existing software, call it PMMU legacy mode.


Markus (mfro)

Posts 99
04 Jan 2017 21:12


Gunnar von Boehn wrote:

...
  I understand you that actually you do NOT want to use our MMU but our MPU. You want to protect some pages for user-mode access.
 
  We see the MPU as a device to help software developers.
  We have more protection bits than old 68k did had.
  E.g We allow to map areas as NO-EXECUTE.
  This helps for debugging and for example allows protection against code in stack attacks.
 
  This means our MPU can provide better protection than any previous 68k.
 
  As you have the sources of Free-Mint it should be no problem to add support for our new protections bits to FreeMint to enable what you want.
 
  We can work together on this if you like.

Thank you Gunnar. I reckon Atari users won't care much how you name it, as long as MiNT works ;).

We'd basically need 8k page granularity and a means for easy and fast switch of page tables on context switches.


Gunnar von Boehn
(Apollo Team Member)
Posts 6207
04 Jan 2017 21:25


Markus (mfro) wrote:

We'd basically need 8k page granularity and a means for easy and fast switch of page tables on context switches.

I see.

Let me repeat my understanding:

1) Virtual = Physical Adressing
2) 8k granulariy
3) Each task has own Access/disallowing map and WRITE access to any non owned pages is not allowed?

How is read access allowed?

Is it correct that you would flush all cached MPU entries - set pointer to new entries on task switch?

How long are typical task time slices on Freemint?




Olivier Landemarre

Posts 147
04 Jan 2017 23:01


Gunnar von Boehn wrote:

 
Markus (mfro) wrote:

    We'd basically need 8k page granularity and a means for easy and fast switch of page tables on context switches.
   

   
    I see.
   
    Let me repeat my understanding:
   
    1) Virtual = Physical Adressing
    2) 8k granulariy
    3) Each task has own Access/disallowing map and WRITE access to any non owned pages is not allowed?
   
    How is read access allowed?
   
    Is it correct that you would flush all cached MPU entries - set pointer to new entries on task switch?
   
    How long are typical task time slices on Freemint?
   
   
   
 

 
  I'm not very familiar with internal Mint kernel, but I think can answer on some of this questions
 
  3: Not exactly, for each application we can decide if a program can share it's memory or not or only in supervisor mode or be in read only. Application can alloc memory with the same choice.
 
  see 5.5.1 : EXTERNAL LINK   
  for memory allocation :  http://toshyp.atari.org/en/00500c.html#Mxalloc
 
 
  Typical time task is 20ms
 
  I hope work on standalone version, you do so incredible job.
 
  Olivier
 
 
 


Markus (mfro)

Posts 99
05 Jan 2017 06:02


Gunnar von Boehn wrote:

  Let me repeat my understanding:
 
  1) Virtual = Physical Adressing
  2) 8k granulariy
  3) Each task has own Access/disallowing map and WRITE access to any non owned pages is not allowed?
 

  ...
 
Gunnar von Boehn wrote:

  How is read access allowed?
 

  MiNT maps the MMU protection bits into 5 page access types: private (own process only), global (accessible to all), super (only accessible for supervisor processes), private/read (readonly private) and invalid (not accessible at all). The page table also contains the cache inhibit bits for the memory.
 
 
Gunnar von Boehn wrote:

  Is it correct that you would flush all cached MPU entries - set pointer to new entries on task switch?
 

  If that is necessary (on "real" m68k, it's not), it can be done easily.
 
  Currently, on task switch you basically just save the MMU root pointer (indicating the process' page table) of the context you leave and restore the one for the context you enter.
 
 
Gunnar von Boehn wrote:
 
  How long are typical task time slices on Freemint?
 

  That's a user configurable value. Default is 40 ms.
 


OneSTone O2o

Posts 159
13 Feb 2017 23:00


Hello, any progress here, besides that what Vincent does with EmuTOS? I know, you still have a lot to do on Amiga side, but also the other side would be happy im any good news, like a 1040ST came up with Vampire card and you could demonstrate system information with benchmarks... :)


Grzegorz Wójcik (pisklak
(Apollo Team Member)
Posts 87
14 Feb 2017 11:00


Well... we focus on Amiga. Later we can ofc make VampTari and I  think we will.
  Right now I am impressed with Vincent fast progress with EmuTOS. Guess soon EmuTOS+FreeMiNT+fVDi will work as good as on Falcons with CT60 :-)


OneSTone O2o

Posts 159
14 Feb 2017 19:49


As long as there is still Amiga hardware beneath of the Vampire, it will only be compatible to clean GEM software. Anaything what uses direct hardware access, like most games, demos and so, will not work on EmuTOS vampirezed Amiga. But that will already be a good start. So, looking forward for all progresses! So keep on going!


Grzegorz Wójcik (pisklak
(Apollo Team Member)
Posts 87
14 Feb 2017 22:10


In that sense Vamire is similar to Firebee I guess. Unless Firebee have good Videl (or whatever it is the name) FPGA implementation


Vincent Rivičre

Posts 87
14 Feb 2017 23:46


The FireBee has Atari hardware implementation in its FPGA. Including Falcon VIDEL (even if there is still a few visual bugs). For example, EmuTOS for Falcon recompiled for ColdFire works fine on FireBee.


OneSTone O2o

Posts 159
17 Feb 2017 18:02


Firebee is quite nice but there is too much software (even "clean GEM" programmed) which never will run on Firebee as the Coldfire can not execute it. That's the same reason why Apollo 68080 has been created. Apollo is capable to run Calamus DTP, Coldfire can not. (Even if Firebee has the same FPGA as Vampire, it makes no sense to add Apollo there as a lot of Firebee peripheriaös and main memory is not accessible to a CPU in the FPGA of Firebee, this is a design weakness of Firebee)


Uros Vidovic

Posts 31
17 Feb 2017 21:31


oneSTone o2o wrote:

Firebee is quite nice but there is too much software (even "clean GEM" programmed) which never will run on Firebee as the Coldfire can not execute it. That's the same reason why Apollo 68080 has been created. Apollo is capable to run Calamus DTP, Coldfire can not. (Even if Firebee has the same FPGA as Vampire, it makes no sense to add Apollo there as a lot of Firebee peripheriaös and main memory is not accessible to a CPU in the FPGA of Firebee, this is a design weakness of Firebee)

It would be nice if you would talk about the things you have at least a little clue what is all about and not about the things you have no clue.
If you think you know something about this topic I can tell you that you dont!



OneSTone O2o

Posts 159
18 Feb 2017 16:43


This was confitmed by mfro. Look at the block diagram of firebee, where is fpga, and where is 512 MB memory, PCI, USB, network, ... From fpga view it's "behind" the coldfire, and coldfire is the master on these devices, other devices at the position of the fcpga can't access it directly. I have also checked Coldfire datasheets, which indirectly confirm this.

posts 159page  1 2 3 4 5 6 7 8