Overview Features Instructions Performance Forum Downloads Products OrderV4 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 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 

Gunnar von Boehn
(Apollo Team Member)
Posts 4735
30 Jun 2019 21:26


nsklaus - wrote:

the original team itself did break compatibilty few times during amigaos life.

 
What makes you think this?
I think compatibility was never broken on AMIGA.
AMIGA OS 1 programs run fine on AMIGA OS2 and OS3
 
You voiced here several times your "dislike" of some OS3 behavior.
Can you help me understand on which experience your dislike is based?

My personal experience is that if people code AMIGA really in depth - often these coders fall in love with the spirit of AMIGA.
A spirit which Linux does not have - and never will have.
A spirit which your proposals will kill.

Have you in depth AMIGA OS coding knowledge?
Like did you write AMIGA OS programs using AMIGA OS structures?

I can understand that Amiga "users" that never coded in depth
and never fell in love with the way Amiga works - ask what you ask for.



Nsklaus -

Posts 63
30 Jun 2019 21:51


@gunnar
"the original team itself did break compatibilty few times during amigaos life."
  - What makes you think this?
 
  some people use kickstart switchers, because some programs don't run well under latest roms. i've also read some interview from the original team member long ago, where they were stating just this.
  they also stated future updates would need compatibility break.
  and no i won't try and dig up the old interview and articles.
 
  "I think compatibility was never broken on AMIGA.
  AMIGA OS 1 programs run fine on AMIGA OS2 and OS3"
 
  not all programs obviously otherwise there would be no need to switch roms. latest roms would be the best and only used roms. but this is not the case.
 
 
  "You voiced here several times your "dislike" of some OS3 behavior.
  On which experience is your dislike based?"
 
  it is not dislike. on the contrary, i think it was great. in its time. long ago.
  now it is just terribly outdated.
 
 
  "How good do you know the internals of AMIGA OS?
  Did you write AMIGA OS programs using AMIGA OS structures?"
 
  zero, none. doesn't prevent me to simple deductions, logic thinking.
  what i'm telling is true for all OSes. all the other OSes went the way i'm describing. even aros and morphos are going that route.
 
  "Have you long year experience in coding ASM/C in AMIGA or on what is your opinion based?"
 
  i have zero experience on coding on amiga.
  my opinion is based on plain logic.
  i code on linux. programs for linux. i'm just and ex-amiga user.
  i've sold all my amiga stuff in 2002, (a4kppc, cvisionppc, delfina, ariadne, etc all maxed out, well it was already outdated in 2002.
  both hardware-wise and software-wise.
  amiga was amazing. back then. now it is Not. at best it could serve as general, overall, vague inspiration for aros or morphos.
  amigaos is legaly frozen in limbo since 199x.
  being able to run it is nice, good POC for demo'ing the apollo project, but all effort (software-wise) should go to aros. imho.
  everyone is free to disagree.
 
 


Gunnar von Boehn
(Apollo Team Member)
Posts 4735
30 Jun 2019 22:05


Thanks for your very honest answer.

My impression is that you underrate Amiga OS.
Simply for the fact that you never coded for it.

nsklaus - wrote:

but all effort (software-wise) should go to aros.

This is a valid opinion.
But you should join the Aros developers if you think like this.




Nsklaus -

Posts 63
30 Jun 2019 22:13


Gunnar von Boehn wrote:
 
  I can understand that Amiga "users" that never coded in depth
  and never fell in love with the way Amiga works - ask what you ask for.
 

 
  i can understand that.
  but, there must be a way to somehow remove the limitations and instability.
 
  2gb ram limitation is bad.
  crashes are bad.
  not being able to kill task and free resources is bad.
 
  even if amiga concepts are really great, and coding for it make one to love them, those problems show something must be wrong or unfinished in the design.
 


Steve Ferrell

Posts 390
30 Jun 2019 23:01


nsklaus - wrote:

what is it you all as a community that you don't understand ?
   

Right now, the only one failing to understand, is you.  Please educate yourself in regard to memory protection and hardware abstraction and stop throwing ridiculous wish-lists around.  AmigaOS 3.x reached the end of the road years ago.  There is no way to add memory protection to it nor any of the other modern features/terms you keep throwing around.

And who says we aren't thankful for the work that's gone into AROS?  But even AROS doesn't support memory protection....it's based in spirit and in design on AmigaOS, so at present it suffers from all the same drawbacks as AmigaOS 3.x. ARIX is a much better choice if you REQUIRE memory protection, SMP, and virtual memory.

If you want AROS for your Vampire, no one is stopping you from using it.  I think Simo and WaWa have it running fairly well on their Vampires and have posted videos to YouTube showing how well it runs on the Vampire.  If you want modern features, you're going to have to move to a modern OS.....period....or write your own, so I suggest that you start coding rather than antagonizing everyone here.



Steve Ferrell

Posts 390
30 Jun 2019 23:09


Samuel Crow wrote:

 
Steve Ferrell wrote:
But a new OS doesn't come with the snap of ones fingers.  It takes developers and years of coding and testing and the Apollo Team already has its hands full just keeping up with Vampire hardware, let alone writing a new OS.

    Actually, open-source operating systems can be modified to run on a Vampire once a compiler exists to generate code natively for it.  What really hurts is that the new OS won't be backward compatible to the old Amiga software.  As I mentioned above, a hosted AROS can do it but there are more things to consider.
 

 
That's exactly why I mentioned ARIX.  It would be a prime candidate for the Vampire.  And just like Windows, backward compatibility has to be ditched at some point.  I think the Amiga passed that point a long time ago.  Even under Windows, you can only run old MS-DOS and  older Windows apps in a sandbox such as DOS-Box or on a virtual machine.  There's no reason why ARIX couldn't have the same functionality in the form of an Amiga-DOS-Box or a UAE emulator compiled for ARIX.
 
I'm also excited to see GCC being updated to support the 68080.  Once that effort is complete, I believe we will see many positive things happening for the Vampire.
 


Gunnar von Boehn
(Apollo Team Member)
Posts 4735
01 Jul 2019 06:15


nsklaus - wrote:

2gb ram limitation is bad.

 
I have a slightly different opinion.
 
Lets look at CPU architecture and understand the difference between 32bit and 64bit CPU architecture.
 
 
Lets look at DATA first:
- CPUs with 32bit DATA registers and 32bit BUS can "copy" 4 byte per cycle.
- CPUs with 64bit DATA registers and 64bit BUS can "copy" 8 byte per cycle.
This means 64bit DATA does improves performance!
Using 64bit Data allows you to do more with less instructions.
This means program size can even decrease slightly!
Especially if you have powerful SIMD instructions like AMMX then 64bit BUS and 64bit Registers will allow you to really improve performance a lot.
 
 
How is this with ADDRESS?
- CPU with 32bit Address can handle 4 GB memory.
  CPU with 32bit Address have compact programs.
 
- Yes, increasing the Address to 64bit will allow you to handle more memory but it comes for a price. 64Bit addresses will make all program become fatter and slower.

While 64bit Data has only advantages 64bit Address comes with measurable disadvantages.
You can clearly measure this effect on POWERPC.
The penalty of 64bit Address is measurable.

From performance and efficiency point of view its good to have 32bit ADDRESS and 64bit DATA.

As you know, 68K code is very compact and dense and AMIGA OS programs are very compact.
 
I think 32bit address is a good idea on AMIGA.
It keeps program smaller and 2GB is plenty for us.

How to explain this to your mother?
This is like running shoes.
You need to buy the size that fits you.
If you have shoe size 7 then buying shoes in size 10 is only advisable to circus clowns.



Steve Ferrell

Posts 390
01 Jul 2019 07:06


Gunnar von Boehn wrote:

  How to explain this to your mother?
  This is like running shoes.
  You need to buy the size that fits you.
  If you have shoe size 7 then buying shoes in size 10 is only advisable to circus clowns.
 

That's perfect!  Thanks for bringing some humor to this thread! :-)



Nsklaus -

Posts 63
01 Jul 2019 07:56


@ferell
 
  you didn't understand what i'm saying.
  i'm not talking about updating amigaos itself.
  there is no sources available, and it is in a legal status that makes it dangerous to use (in large scale, commercialy, not personaly).
  amigaos the real one, is in a frozen state, it is good to look at, put in a frame and hang it on the wall. it can serve as inspiration for building lookalike OSes such as morphos or aros.
 
  since morphos is closed source, aros seems to be the best available candidate to use and start modernizing from. little by little.
 
  the idea i'm discussing is to take the good inspiration, the good ideas from amigaos (the real one) and overcome its limitations, when reimplementing things in aros. here and there breaking a little bit compatibility to gain much needed feature.
 
  basicaly what morphos intent to do with morphos4, but done on aros.
  a good result could be to have something like 80% compatible to the original, so mostly the same, but just gaining benefits that have been tested and appreciated everywhere else in all other OSes around the world. like i was saying even atari too did just that in one of its version. it is just the idea of having one more aros branch that is more modern. that doesn't erase aos3.1 or current aros branch from history. it just create one more choice to use. purists can still use original aos or current aros and be like it's 199x in all its glory if they wish to. i'm not talking about deleting or killing anything, just adding one more choice.
  what i'm discussing is not for right now, but for the years to come.
  what direction do we want to go from here on.


Kamelito Loveless

Posts 91
01 Jul 2019 12:36


AFAIK, nobody outside the Morphos Team know what version 4.0 will be. We just know that it is an architecture change probably to X64 with a set a very limited HW because of drivers.
  The Q/BOX never saw the light of the day except the kernel Quark. So the Q/BOX is not a priority for the team, A/BOX enhancement is.
 
  Why that? The Morphos Team said that the users wanted new features for the A/BOX which as you know is an improved AmigaOS 3.1. If you code in C using the 3.1 API then a recompile will suffice to make it work for Morphos. So all in all Morphos is more or less AmigaOS 3.1 for PPC with all its advantages and all its flaws.

I think that AmigaOS as it is for 68k is nearlly perfect. AmigaOS 4 and Morphos, even Aros didn't succeed to bring the OS to today standard. (decades of coding!!).
In the end if they ever succeed which I doubt, the OS will become bloated like Windows,MacOS, Linux who want that?
We just want to have fun with our Amigas not changing the world, it is not 1985.

  ----
  o High Super/Usermode switch speed
  o Low interrupt latency
  o IntThreads and Int PCode abstraction
  o Memory protection
  o Symmetrical multi processing (SMP)
  o Task/Thread and Clan/Chief model
  o Resource tracking
  o Asynchronous message system
  o Virtual memory (optional)
  o Recursive Memory Management
  o Distributed computing
  o No access to Kernel structures
  o Clean design with an elegant API
  o Micro/pico kernel mixture


Nsklaus -

Posts 63
01 Jul 2019 13:10


@kamelito
 
  i don't even talk about os4, there's hyperion in it, it is doomed period (for me). and even more, what has been done so far is insignificant. os4 does not even register on my radar. (decades of coding .. os4 ? i'm laughing. you surely meant "feign coding")
 
  now for morphos and aros the situation is different. there's talented individuals at work, doing good. for morphos4, there was a certain number of things, features, that have transpired, and are now known and confirmed by some people from the mos team, unless i'm mistaken, memory protection is one of those things i believe. as for qbox, i meant: the fundation on which the abox is currently running. the abox is not the native OS it runs on top of a lower-level layer, which is what i wanted to say when i said 'qbox'. i haven't used morphos since 1.4, i'm just following from afar, same as for aros and amiga related things in general.
  i'm interested, but it's nowhere near usable to me yet. none of it.
 
  - amigaos is cryogenically frozen, nothing can be done about it, unless maybe if it goes opensource with cloanto winning the lawsuit, that would be good but, there's a large amount of preliminary work to be done to bring it into a state where it can get compiled by today's toolchain.
  - morphos seems to be the best polished OS, but it is closed source.
  - aros is open source and taking the good direction i believe, but it's still a bit too rough to my taste. i might want to install it hosted on linux and try to help a bit eventually. (with my limited cpp skills.. though it could be good for training. one stone too birds)
  none are in good shape but aros seems the most accessible and promizing one due to it's opensource nature.
 

and about linux, being bloated, there's some linux distro that are the size of amigaos more or less, 10mb.
some distro are bloated, slow, lots of scripts running, it's a mess.
but if you now what you are doing you can have small and fast linux.
even on slow hardware such as the raspberrypi, even fat distro like ubuntu runs well. if you know what you are doing you can even improve the perf from that.. a lot.
more so, i believe that features like smp and memory protection, unicode support, resource tracking and so on, which are reported to kill the performances i believe those statement are overly exagerated to say the least.
 
 
 


A1200 Coder

Posts 61
01 Jul 2019 13:20


Gunnar von Boehn wrote:

  While 64bit Data has only advantages 64bit Address comes with measurable disadvantages.
  You can clearly measure this effect on POWERPC.
  The penalty of 64bit Address is measurable.
 
  From performance and efficiency point of view its good to have 32bit ADDRESS and 64bit DATA.

Does this mean that a single instruction on 68080 can contain one 64 bit number and one 32 bit number? But not two 64-bit numbers? And addresses are still 32 bit on 68080?


Gunnar von Boehn
(Apollo Team Member)
Posts 4735
01 Jul 2019 13:40


A1200 coder wrote:

  Does this mean that a single instruction on 68080 can contain one 64 bit number and one 32 bit number? But not two 64-bit numbers? And addresses are still 32 bit on 68080?
 

 
  Let em again explain.
  If we talk about 64bit this can mean DATA or ADDR
 
  64bit DATA gives the following
  ++ less instruction needed for the same work
  ++ more calculation per instruction
  ++ faster memory operations
 
  64bit ADDR means the following
  -- needs complete new OS
  +  can use more than 4 GB
  -- bigger and slower programs
 
 
  In other words:
  Using 64bit DATA has only advantages.
  Using 64bit ADDR has more disadvantages than advantages.
  And make for AMIGA not much sense.
 
  People with technical understanding would
  normally not ask for 64bit ADDR for AMIGA OS.


A1200 Coder

Posts 61
01 Jul 2019 14:16


Gunnar von Boehn wrote:

A1200 coder wrote:

  Does this mean that a single instruction on 68080 can contain one 64 bit number and one 32 bit number? But not two 64-bit numbers? And addresses are still 32 bit on 68080?
 

 
  Let em again explain.
  If we talk about 64bit this can mean DATA or ADDR
 
  64bit DATA gives the following
  ++ less instruction needed for the same work
  ++ more calculation per instruction
  ++ faster memory operations
 
  64bit ADDR means the following
  -- needs complete new OS
  +  can use more than 4 GB
  -- bigger and slower programs
 
 
  In other words:
  Using 64bit DATA has only advantages.
  Using 64bit ADDR has more disadvantages than advantages.
  And make for AMIGA not much sense.
 
  People with technical understanding would
  normally not ask for 64bit ADDR for AMIGA OS.

Well I was more concerned about that you can get everything you need in a single instruction. This PowerPC horror of having to load a 64-bit address with 5 instructions instead of 1, because there is space for only 16 bit data in a single instruction. So you have to keep feeding data in 16 bit portions, be it then an address or data.

M68k CPUs can have two 32 bit numbers in a single instruction, thanks to the variable length instruction encoding. So I assume 68080 improves on this, when it uses 64 bit data. So for example, writing a 64 bit number into an absolute 32 bit memory address is still just one instruction?



Mike Kopack

Posts 266
01 Jul 2019 14:21


Gunnar von Boehn wrote:

A1200 coder wrote:

  Does this mean that a single instruction on 68080 can contain one 64 bit number and one 32 bit number? But not two 64-bit numbers? And addresses are still 32 bit on 68080?
 

 
  Let em again explain.
  If we talk about 64bit this can mean DATA or ADDR
 
  64bit DATA gives the following
  ++ less instruction needed for the same work
  ++ more calculation per instruction
  ++ faster memory operations
 
  64bit ADDR means the following
  -- needs complete new OS
  +  can use more than 4 GB
  -- bigger and slower programs
 
 
  In other words:
  Using 64bit DATA has only advantages.
  Using 64bit ADDR has more disadvantages than advantages.
  And make for AMIGA not much sense.
 
  People with technical understanding would
  normally not ask for 64bit ADDR for AMIGA OS.

I would have to agree with you... to a point...

Yes, we're FAR FAR FAR away from making use of 4GB address space of 32 bit with Amiga TODAY... *IF* there is a big revival for Amiga (ok, doubtful but one can always hope) then at some point down the line >4GB address space will be needed (just like it eventually was for Windows/Linux). But we're FAR from there yet.

What's the most memory intensive Amiga application these days? Maybe some ray tracer or possibly web browser? And those BARELY make use of more than 128MB RAM if it's available. So we have a LOT of head room to go before 64 bit addressing becomes an issue.


Kamelito Loveless

Posts 91
01 Jul 2019 17:04


Donít remember the specifics but AmigaOS cannot address more than 2GB of Ram as it using 31-bits. This is so deep in the code that it cannot be overcome without a complete rewrite (31-bit pointer in the message system IIRC)


Renee Cousins
(Apollo Team Member)
Posts 139
02 Jul 2019 15:18


Gunnar von Boehn wrote:
AMIGA OS by design can not support memory protection. The AMIGA features that many people like to much about AMIGA OS are incompatible with memory protection.

AmigaOS does not support memory protection but can be patched to do so such as with MuLib. It changes nothing for legacy applications but does fix a few things to make AmigaOS more robust and provides a clear path for easily adding MMU features in a user-centric, light weight manner for future applications which require it, such as emulation and modern web browsers.


Gunnar von Boehn
(Apollo Team Member)
Posts 4735
02 Jul 2019 15:29


Renee Cousins wrote:

AmigaOS does not support memory protection but can be patched to do so such as with MuLib.

Let make clear:
Lets make clear:
MuLib can _not_ provide memory protection.
 
MuLib comes with some circumventions for some bugs in 68030 and 68060 CPUs. Those circumventions make these CPU slower on the Bus to support all Zorro cards. Credo "Better safe than sorry".
This MuMu Trick is smart - as the bugs in the ASICs of the 68030 and 68060 can't be fixed otherwise.
Luckily the 68080 CPU does not need such hacks.

Frankly, today I would not recommend people to use Virtual memory functions anymore.



Geoff Wells

Posts 32
02 Jul 2019 15:42


I've been on this forum for many years and have only commented a couple of times.  I am an owner of a V500 and have a software development background with some (very old) development on the Amiga.

To me, the spirit of the Amiga is the wonderful blend of hardware and software that resulted in a platform that seemed to always deliver more that it should be able to.  That is why this project is so exciting.  It allows the problem to be attacked from both sides - hardware and software, marrying the two to best effect.

Now, apologies if I ask or say anything that is uniformed.  It seems like this is a topic that has already had a lot of attention but I haven't heard anyone comment on what I'm asking.

Does the MPU manage access to memory for the custom chips?  Is it possible that the MPU could be extended in a way that would take into account the uniqueness of AOS that could then be latched onto by AROS?  A unique process handle that would allow for write access by the owning process and read access by any other processes that would be set by the OS as part of a context switch?

For me, the opportunity here is to look at the problem through the Amiga lens.  The original team developed the hardware and software in tandem, solving problems together that created a highly optimized computer.  Perhaps, following in their footsteps, we could improve the stability while maintaining backwards compatibility.

I'll admit I haven't put a lot of time into thinking about the problem and I understand (at some level) the challenges of having memory protection while sharing structures allocated in different process contexts.  I also love AOS but struggle with the stability at times.

Thinking about special hardware (AmigaMPU - like AMMX?) that enables memory protection with existing programs on an updated AROS puts a smile on my face.  Such a compelling reason to have a new MPU!

They said boing ball was impossible at the time.  Perhaps we can capture lighting in a bottle again with memory management.

As a side note, to forestall the comments, I am not an active contributor to AROS.  Perhaps I should be, time permitting.  Perhaps, if there is interest, this will be the project that gets me off my ass.  :)


Gunnar von Boehn
(Apollo Team Member)
Posts 4735
02 Jul 2019 15:56


You might call me old fashioned.
But I believe things should be done in the correct order.

Today AROS is not finished and not 100% AMIGA OS compatible.
There is still a lot todo to make AROS 100% compatible,
and allow AROS to run all AMIGA software.

Wouldn't it make sense to first finish and complete AROS before  talking about changing stuff and doing new incompatible additions?

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