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.

Are We Just Nostalgic Or Should the Amiga Advance?page  1 2 3 4 5 6 7 8 9 10 11 12 13 

Steve Ferrell

Posts 424
02 Jul 2019 23:20


Renee Cousins wrote:

nsklaus - wrote:
memory protection was planned and so was smp.

  If we're being really honest with ourselves, we know this to be false. The next step was Hombre and PA-RISC running Windows NT. Amiga OS would become the CD64 OS (to keep costs down) and otherwise exist only as OS-friendly emulation.

Exactly.  SMP didn't become a "thing" in the tech industry until around 1996 with the release of Windows NT 4, two years after Commodore had already gone bankrupt. NT 4 Server supported 8-way SMP. I don't recall memory protection, SMP, or process isolation for classic AmigaOS ever being discussed.  Even with OS4, such things weren't talked about until after its release in 2003 and the earliest info that I can find where it was discussed via Hyperion's website was around 2006-2007.



Geoff Wells

Posts 43
02 Jul 2019 23:56


Renee Cousins wrote:

nsklaus - wrote:
memory protection was planned and so was smp.

  If we're being really honest with ourselves, we know this to be false. The next step was Hombre and PA-RISC running Windows NT. Amiga OS would become the CD64 OS (to keep costs down) and otherwise exist only as OS-friendly emulation.

LOL!  We're having a big debate about the virtues of a lightweight AmigaOS on Motorola 68K and I totally forgot that we could have ended up with Window on PA-RISC.  Thanks for reminding me.  Too funny.


Renee Cousins
(Apollo Team Member)
Posts 142
03 Jul 2019 00:04


Geoff Wells wrote:

 
Renee Cousins wrote:

 
nsklaus - wrote:
memory protection was planned and so was smp.

    If we're being really honest with ourselves, we know this to be false. The next step was Hombre and PA-RISC running Windows NT. Amiga OS would become the CD64 OS (to keep costs down) and otherwise exist only as OS-friendly emulation.
 

  LOL!  We're having a big debate about the virtues of a lightweight AmigaOS on Motorola 68K and I totally forgot that we could have ended up with Window on PA-RISC.  Thanks for reminding me.  Too funny.
 


It's a sobering thought, for sure.


Geoff Wells

Posts 43
03 Jul 2019 00:09


@Steve

I seem to remember memory protection being a point of differentiation in early releases of Windows NT (same as with OS/2).  It was one of the compelling stability arguments for the server implementation over Windows 3.11 (or Windows for Workgroups).

I don't know that it came up in specific AOS vs. Windows discussions but in the PC-DOS/Windows 3.x/Windows 95/Windows NT discussions it came up quite a bit.  If I remember correctly, it was one of the drivers for the progression to Windows 95 (no longer running on top of DOS, memory protection above 1 MB and 32 bit).  The full implementation not coming until Windows 2000.


Samuel Crow

Posts 424
03 Jul 2019 00:11


If Hombre came out on Windows NT it would have killed Commodore if they hadn't died already because it wouldn't have been different enough to stand out from the competition.  Perfomance-wise and feature-wise both.


Steve Ferrell

Posts 424
03 Jul 2019 01:24


Geoff Wells wrote:

  @Steve
 
  I seem to remember memory protection being a point of differentiation in early releases of Windows NT (same as with OS/2).  It was one of the compelling stability arguments for the server implementation over Windows 3.11 (or Windows for Workgroups).
 
  I don't know that it came up in specific AOS vs. Windows discussions but in the PC-DOS/Windows 3.x/Windows 95/Windows NT discussions it came up quite a bit.  If I remember correctly, it was one of the drivers for the progression to Windows 95 (no longer running on top of DOS, memory protection above 1 MB and 32 bit).  The full implementation not coming until Windows 2000.
 

 
 
Yes, process separation as well as memory protection was incorporated into NT 4 and NT 3.51.  Versions of Windows prior to NT 3 all had variants of MS-DOS running underneath, so there was no memory protection nor process separation, therefore any app, be it a badly behaving/badly written Windows app or a DOS program could bring the whole system down.  Windows NT also introduced the NTVDM, or the NT Virtual DOS Machine in 1993.  It allowed for running DOS and pre-Windows NT apps via a sand-box.  The NTVDM was made a part of Windows NT in 1993.  The NTVDM prevented misbehaving apps from gobbling up and/or corrupting system memory or from crashing the OS.  There's a good read about it here:  EXTERNAL LINK 
So there was a full implementation of memory protection and process separation prior to Windows 2000.  NT 4 Server was rock solid and added SMP which was why it was adopted by the corporate IT infrastructures around the world.  NT 4 Server was released in 1996 along with the Workstation, Terminal Server and Embedded versions.


Geoff Wells

Posts 43
03 Jul 2019 01:44


Steve Ferrell wrote:

Geoff Wells wrote:

  @Steve
   
    I seem to remember memory protection being a point of differentiation in early releases of Windows NT (same as with OS/2).  It was one of the compelling stability arguments for the server implementation over Windows 3.11 (or Windows for Workgroups).
   
    I don't know that it came up in specific AOS vs. Windows discussions but in the PC-DOS/Windows 3.x/Windows 95/Windows NT discussions it came up quite a bit.  If I remember correctly, it was one of the drivers for the progression to Windows 95 (no longer running on top of DOS, memory protection above 1 MB and 32 bit).  The full implementation not coming until Windows 2000.
 

 
 
  Yes, process separation as well as memory protection was incorporated into NT 4 and NT 3.51.  Versions of Windows prior to NT 3 all had variants of MS-DOS running underneath, so there was no memory protection nor process separation, therefore any app, be it a badly behaving/badly written Windows app or a DOS program could bring the whole system down.  Windows NT also introduced the NTVDM, or the NT Virtual DOS Machine in 1993.  It allowed for running DOS and pre-Windows NT apps via a sand-box.  The NTVDM was made a part of Windows NT in 1993.  The NTVDM prevented misbehaving apps from gobbling up and/or corrupting system memory or from crashing the OS.  There's a good read about it here:  EXTERNAL LINK   
  So there was a full implementation of memory protection and process separation prior to Windows 2000.  NT 4 Server was rock solid and added SMP which was why it was adopted by the corporate IT infrastructures around the world.  NT 4 Server was released in 1996 along with the Workstation, Terminal Server and Embedded versions.

So, would it be fair to say that we agree that isolation of processes via memory protection should improve stability but the challenge lay in maintaining the existing mechanism in AmigaOS?  This may seem like an obvious statement but given all of the different responses I want to make sure I understand where people are coming from.

Given I'm just ramping up on AmigaOS (Events, IPC, etc.) I'd be thankful if you could point me at any relevant reading.


Steve Ferrell

Posts 424
03 Jul 2019 01:56


Geoff Wells wrote:

 
Steve Ferrell wrote:

 
Geoff Wells wrote:

    @Steve
     
      I seem to remember memory protection being a point of differentiation in early releases of Windows NT (same as with OS/2).  It was one of the compelling stability arguments for the server implementation over Windows 3.11 (or Windows for Workgroups).
     
      I don't know that it came up in specific AOS vs. Windows discussions but in the PC-DOS/Windows 3.x/Windows 95/Windows NT discussions it came up quite a bit.  If I remember correctly, it was one of the drivers for the progression to Windows 95 (no longer running on top of DOS, memory protection above 1 MB and 32 bit).  The full implementation not coming until Windows 2000.
   

   
   
    Yes, process separation as well as memory protection was incorporated into NT 4 and NT 3.51.  Versions of Windows prior to NT 3 all had variants of MS-DOS running underneath, so there was no memory protection nor process separation, therefore any app, be it a badly behaving/badly written Windows app or a DOS program could bring the whole system down.  Windows NT also introduced the NTVDM, or the NT Virtual DOS Machine in 1993.  It allowed for running DOS and pre-Windows NT apps via a sand-box.  The NTVDM was made a part of Windows NT in 1993.  The NTVDM prevented misbehaving apps from gobbling up and/or corrupting system memory or from crashing the OS.  There's a good read about it here:  EXTERNAL LINK     
    So there was a full implementation of memory protection and process separation prior to Windows 2000.  NT 4 Server was rock solid and added SMP which was why it was adopted by the corporate IT infrastructures around the world.  NT 4 Server was released in 1996 along with the Workstation, Terminal Server and Embedded versions.
 

 
  So, would it be fair to say that we agree that isolation of processes via memory protection should improve stability but the challenge lay in maintaining the existing mechanism in AmigaOS?  This may seem like an obvious statement but given all of the different responses I want to make sure I understand where people are coming from.
 
  Given I'm just ramping up on AmigaOS (Events, IPC, etc.) I'd be thankful if you could point me at any relevant reading.
 

 
Yes, we're in absolute agreement.  That's what Gunnar and myself and few others have been saying in this thread all along.  A new OS for the Amiga incorporating process separation and memory protection for stability, with the ability to run legacy apps (sandboxed) for backward compatibility, requires an entirely new OS, at least at the kernel level....but there are a few here who can't grasp that idea.  Microsoft understood this over 25 years ago and even named their new OS, NT, which stood for New Technology to differentiate it from all versions of DOS and Windows that came before it.  I have to run to a meeting but I will post some links when I return.

But remember what Gunnar stated, in moving to a new OS we will lose what attracted us to AmigaOS in the first place, which was a lightweight, nimble OS that allowed programmers to access the hardware directly in order to eek out every last drop of performance.
 


Geoff Wells

Posts 43
03 Jul 2019 02:12


@Steve

Good.  So, for me I agree that we need to aim for backwards compatibility, maintain the ability to hit the hardware, keep the OS highly performant by allowing access to shared memory but I haven't given up on the idea that we may yet be able to build in some protection.  As noted, I'm willing to accept that this may be my naivety talking.  :)

Even if we look at the example of Windows 95, there were improvements in stability by creating process isolation above the 1 MB boundary but allowing all processes to access below.  Certainly not as good as Windows NT but better than 3.1.  Also, Microsoft may not have had the flexibility of hardware that we might.

In any case, thanks for anything you can send along.  I'll let it rattle around in the old noodle for a bit and see if I can pull something coherent together.



Tim Trepanier

Posts 132
03 Jul 2019 02:17


When i started this thread i didn't it to be monopolized by memory protection. Are there other simple ways to advance the Amiga forward that you'd like to see?

I know some people will be against anything that breaks any existing software, but i'm willing to break some in order to get a better user experience.

1. change to using window borders to resize windows instead of a gadget in the bottom right corner

2. be able to change the WB and public screen mode resolution, size, colours, etc... without closing all everything open on it

Both of these would break some software, but they are important to the user experience for me.
What would you like changed?



Geoff Wells

Posts 43
03 Jul 2019 02:19


Sorry, one other thing...

@Gunner

Thanks for your patience.  I know there isn't currently documentation on the MPU but perhaps you could point me at some docs on a similar implementation (PPC?  ARM?).  I don't need implementation or instruction details but a high level overview to give me a better understanding of what permissions and potential page table layouts might look like.

Thanks.


Geoff Wells

Posts 43
03 Jul 2019 02:20


Sorry @Tim.  I'll take it offline and/or start another thread.


Steve Ferrell

Posts 424
03 Jul 2019 03:48


@Geoff Wells

Here's a link that should provide you with everything you ever wanted to know about the Amiga as far as kernel design and how to code for AmigaOS:  EXTERNAL LINK




Steve Ferrell

Posts 424
03 Jul 2019 04:01


Geoff Wells wrote:

  @Steve
   
    Good.  So, for me I agree that we need to aim for backwards compatibility, maintain the ability to hit the hardware, keep the OS highly performant by allowing access to shared memory but I haven't given up on the idea that we may yet be able to build in some protection.  As noted, I'm willing to accept that this may be my naivety talking.  :)
 
    Even if we look at the example of Windows 95, there were improvements in stability by creating process isolation above the 1 MB boundary but allowing all processes to access below.  Certainly not as good as Windows NT but better than 3.1.  Also, Microsoft may not have had the flexibility of hardware that we might.
   
    In any case, thanks for anything you can send along.  I'll let it rattle around in the old noodle for a bit and see if I can pull something coherent together.
   
 

 
 
Well, actually there wasn't any real process isolation or memory protection under Windows 95.  Any app or program could wreck another one, or bring down the OS.  Window 95 DID allow programs to use memory above the DOS limit that began at the 640KB boundary.  MS-DOS 7.0 was still the underlying OS and Windows 95 was simply a GUI that ran on top of that.  Win 95 did provide for virtual memory though.
 
Under Windows 3.x, 95, 98 and Millenium, allowing certain apps to use separate memory spaces above or below the 640KB boundary is not process isolation because each and every app still has the ability to corrupt the other's memory space or crash the OS.  Process isolation with memory protection didn't occur until Windows NT was released with its NTVDM.  This NTVDM virtual machine kept each instance of an MS-DOS app or older Windows program contained in a sandbox and if that app misbehaved and tried to access resources outside the sandbox, the OS would halt that offending app before any chaos ensued.


Mark Watson

Posts 5
03 Jul 2019 04:04


One of the Ironies of the OS as hardware arbitrator, is now desktops and servers tend towards recursive virtualization and sandboxing because the OS is now so complicated and still doesn't sufficiently shield programs from one another.  E.g. sandboxing a some user code, inside a Java VM, inside a docker container, inside a Linux VM inside a ESX server.  Obviously with something like that performance is lost all over the place, multiple nested file systems, network access, context switching, etc.  So now we have a great new idea: IOMMU!  This allows the hardware to service the VMs directly without having to have each nested VM passing requests up to its host one level at time.  So what was once a big part of OS actually needs to done by the hardware directly to avoid leaking performance.

There is a great video by Casey Muratori on the case for simplifying the OS and standardizing the hardware ISA:

EXTERNAL LINK 



Steve Ferrell

Posts 424
03 Jul 2019 06:28


Mark Watson wrote:

  One of the Ironies of the OS as hardware arbitrator, is now desktops and servers tend towards recursive virtualization and sandboxing because the OS is now so complicated and still doesn't sufficiently shield programs from one another.  E.g. sandboxing a some user code, inside a Java VM, inside a docker container, inside a Linux VM inside a ESX server.  Obviously with something like that performance is lost all over the place, multiple nested file systems, network access, context switching, etc.  So now we have a great new idea: IOMMU!  This allows the hardware to service the VMs directly without having to have each nested VM passing requests up to its host one level at time.  So what was once a big part of OS actually needs to done by the hardware directly to avoid leaking performance.
 
  There is a great video by Casey Muratori on the case for simplifying the OS and standardizing the hardware ISA:
 
  EXTERNAL LINK   
 
 

 
That makes sense for a server hosting many different virtual machines that are running many different operating systems.  For a desktop system running a single OS, seeking some level of backward compatibility, not so much.
 
We're talking about an enhanced AmigaOS with memory protection and process separation and running it on a 68080 which runs around 200 MIPS.  Such an OS would run just fine on the Vampire.  Heck, Windows NT ran just fine on a 25.6 MIPS 486DX at 66 MHz.  An enhanced AmigaOS with memory protection and process separation, while not as fast as classic AmigaOS on the same CPU, should still scream on a Vampire at 200 MIPS.
 


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
03 Jul 2019 06:36


Geoff Wells wrote:

I don't want to make AOS/AROS like Unix and I'm not too interested in a hosted environment (ARIX/UAE/ABox/etc.).  My joy, as I'm sure with many here, is the elegance of the 68K based hardware combined with the original OS.  I just have a feeling we could do more with the OS in a complimentary way similar to what you've achieved with AMMX.

Its good that we agree that our goal is not  to have another random Unix and not to run AMIGA apps in something like UAE. ;-)
Lets accept that full memory protection is a fiction that we can not reach with AMIGA OS.

Now lets look what we have and what we can do.

Lets first define some names.
a) "MPU"
APOLLO MPU is called the "MEMORY PROTECTION UNIT".
Its designed for ACCESS CONTROL to memory areas.
Different Types of ACCESS are: READ/WRITE/EXECUTE
This means the MPU on APOLLO can monitor _ALL_ memory access and
can report and control it.
The APOLLO CPU has build in DMA channels.
Such DMA channels are e.g. used for Network.
All writing DMA channels go on APOLLO through the MPU.
This means e.g. SPRITE DMA which only READs is not MPU controlled.
But all "dangerous" DMA which can write is controlled.

On old AMIGAs DMA was never MMU controlled.
This means a wrong setup DMA would go undetected on old 68K chips and would kill the system. This is now different on APOLLO.
Errorsly setup DMA could be detected by the MPU.

b) MAU
Is the MEMORY ADDRESS UNIT.
This unit can be used to "map" memory around = virtual addresses.
Again DMA on APOLLO channels use this unit.
This means DMA can be used to virtual memory regions.

C) CPU Cache Coherency
APOLLO CPU Cache snoop memory access.
This means DMA channels are transparent to APOLLO and the CPU caches are automatically coherent.
This is a main design difference to old 68K CPUs.
It gives us 2 big advantages now.

* The system can do just DMA, and all is good.
On old Amiga DMA to fastmem needed to flush the caches which causes a slowdown - often neglecting the speed bonus of the DMA.

* CPU is also ocherent to more CPUs
This concept would in theory also allow SMP CPU systems with several APOLLO cores to work coherent. This is a very important and a key feature to build an SMP system.

From technical point we have some useful building blocks.
One start could be to use the MPU to detect programming errors.

Sidenote:  APOLLO has also improved debugging features.
APOLLO can do pretty good debugging.
You can set breakpoints on the "PC" reaching a certain function,or the CPU updating a certain variable in memory.

One could build on top of this pretty nice tools.


Steve Ferrell

Posts 424
03 Jul 2019 06:50


Gunnar von Boehn wrote:

Geoff Wells wrote:

  I don't want to make AOS/AROS like Unix and I'm not too interested in a hosted environment (ARIX/UAE/ABox/etc.).  My joy, as I'm sure with many here, is the elegance of the 68K based hardware combined with the original OS.  I just have a feeling we could do more with the OS in a complimentary way similar to what you've achieved with AMMX.
 

 
  Its good that we agree that our goal is not  to have another random Unix and not to run AMIGA apps in something like UAE. ;-)
  Lets accept that full memory protection is a fiction that we can not reach with AMIGA OS.
 
  Now lets look what we have and what we can do.
 
  Lets first define some names.
  a) "MPU"
  APOLLO MPU is called the "MEMORY PROTECTION UNIT".
  Its designed for ACCESS CONTROL to memory areas.
  Different Types of ACCESS are: READ/WRITE/EXECUTE
  This means the MPU on APOLLO can monitor _ALL_ memory access and
  can report and control it.
  The APOLLO CPU has build in DMA channels.
  Such DMA channels are e.g. used for Network.
  All writing DMA channels go on APOLLO through the MPU.
  This means e.g. SPRITE DMA which only READs is not MPU controlled.
  But all "dangerous" DMA which can write is controlled.
 
  On old AMIGAs DMA was never MMU controlled.
  This means a wrong setup DMA would go undetected on old 68K chips and would kill the system. This is now different on APOLLO.
  Errorsly setup DMA could be detected by the MPU.
 
 
  b) MAU
  Is the MEMORY ADDRESS UNIT.
  This unit can be used to "map" memory around = virtual addresses.
  Again DMA on APOLLO channels use this unit.
  This means DMA can be used to virtual memory regions.
 
 
  C) CPU Cache Coherency
  APOLLO CPU Cache snoop memory access.
  This means DMA channels are transparent to APOLLO and the CPU caches are automatically coherent.
  This is a main design difference to old 68K CPUs.
  It gives us 2 big advantages now.
 
  * The system can do just DMA, and all is good.
  On old Amiga DMA to fastmem needed to flush the caches which causes a slowdown - often neglecting the speed bonus of the DMA.
 
  * CPU is also ocherent to more CPUs
  This concept would in theory also allow SMP CPU systems with several APOLLO cores to work coherent. This is a very important and a key feature to build an SMP system.
 
 
  From technical point we have some useful building blocks.
  One start could be to use the MPU to detect programming errors.
 
 
  Sidenote:  APOLLO has also improved debugging features.
  APOLLO can do pretty good debugging.
  You can set breakpoints on the "PC" reaching a certain function,or the CPU updating a certain variable in memory.
 
  One could build on top of this pretty nice tools.

Sticking to your original design goals without any feature-creep has served you well.  Discussions about memory protection and process separation should be put aside until there's a need for it, and it isn't needed for classic apps running on a single user system that isn't running mission critical applications.



Lord Aga
(Apollo Team Member)
Posts 119
03 Jul 2019 10:26


nsklaus - wrote:

am i a troll now? really ?
 

Nice avatar :)
Seems I was right at the very beginning. I have a pretty good trolldar.

Writing walls of text, obsessively asking people to do something while at the same time not doing anything yourself is pretty much a telltale (bear) sign.


Kamelito Loveless

Posts 259
03 Jul 2019 17:31


Steve Ferrell wrote:

@Geoff Wells
 
  Here's a link that should provide you with everything you ever wanted to know about the Amiga as far as kernel design and how to code for AmigaOS:  EXTERNAL LINK
 
 

There’s also good magazines like AC Tech, AmigaWorld tech journal and Amiga Transacor and if you speak French AmigaNews Tech.


posts 244page  1 2 3 4 5 6 7 8 9 10 11 12 13