Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Editorials => Topic started by: Oldsmobile_Mike on June 04, 2015, 03:30:30 AM
-
http://distrita.com/a-eon-interview-about-amigas-future/
-
Nice find Mike! I remember AmiDelf announcing his new website some time back... looks like it's really taken off! I had forgotten about it but re-bookmarked! :)
I'll certainly be looking forward to all the new A-Eon announcements too!
-
Nice find Mike!
Someone posted it on one of the Google+ Amiga groups, figured it was worth sharing. :)
-
Bloody good read, well said Trevor! :-) and good work Matthew!
On and on I say...!
-
Its a bit depressing that they sold less then 2000 AmigaOnes. I really hope this improves in the future, maybe with some cheaper hardware.
-
He doesn't say they sold 2000, the statement made was in the excess of 200 but less than 2000.
So could be 201. Which is disappointing, fingers crossed for the next batch of AmigaOnes.
-
I am supporter, and I'm surprised its over 200.
Its an expensive system for a limited market, with many potential customers dismissing NG hardware entirely.
Adding MorphOS to the mix may slightly increase the X5000's market potential, but A-eon's market is likely to remain small.
-
I don't think its people dismissing Amiga NG, it is the cost. Which there is not alot they can do about it. Of course crowd sourcing can help with this but again developers and the Amiga community seem to be afraid of it.
Those that have used it have been success though and sold in high numbers and to a wider audience and not just limiting themselves to our small community.
-
@ Lurch
Crowd sourcing can provide funds, but the board still has to be designed.
And building and testing that design is no small task.
I don't think there are enough of us willing to contribute to see such a project through to completion.
-
another great interview from our Trevor! We're lucky to have him on our team guys:)
-
I don't think its people dismissing Amiga NG, it is the cost.
In many cases it's lack of interest. You could sell X1000s for a 100 bucks, and many Amiga people still won't buy one just because they don't want one. A sizable part of the Amiga community is not a market for these machines.
-
@Iggy sure but the design work is already happening, with crowd sourcing suddenly you have a huge exposure to people outside a couple of forums. This would cover the costs easily.
Just look at all the other successfully funded projects and reasonable pricing they can achieve. These other projects also needed to design hardware, some with complicated circuit boards.
So I don't think designing the board can be used as an excuse. At the end of the day more people buying the cheaper something can become. We need to think outside the tiny Amiga community, when I mention the Amiga many people don't even know it still exists and many would purchase new hardware. They don't frequent Amiga forums or niche Amiga websites, but I've pointed them at a couple of sites.
@Thorham I don't think that is the case, I would jump at new hardware. I especially like the idea of putting a motherboard in a retail box and sell through some local stores.
Anyway, there are a lot of people wanting new hardware and most just lurk and don't bother taking part in forums for risk of being shot down. There is plenty of interest on other non Amiga sites when the Amiga is mentioned. They're just waiting for good spec hardware at a reasonable price. Hopefully the X5000 hits the spot, even the lessor X3500 may be the sweet spot that gains interest again.
-
I don't think that is the case, I would jump at new hardware. I especially like the idea of putting a motherboard in a retail box and sell through some local stores.
Yes, you would, but many don't. I wouldn't, because NG doesn't provide me with what I want.
Many people in the Amiga community are only interested in Classic and new hardware for Classic. Underestimating this when creating new non-classic hardware can bite you in the butt.
For many it's nostalgia, and NG doesn't deliver this. For many others it's the original Amiga games, and NG doesn't offer any advantages for that. In both cases the original hardware and Uae give you the best experience. Then there are people like me who like the original hardware as a cool retro platform. NG doesn't do that either, which is fine, because it's not what it's for anyway.
When you want to produce new hardware that's not related to the original hardware at all, you really have to keep this is mind.
-
For me, AmigaOS + SW was about 90% of what 68k Amiga Computer meant to me.
In the end, CBM manufactured HW part of my A4k system was the thing holding it back to please my growing needs. With NG PPC HW I've been able to continue with the 90% of Amiga.
(it would be easier if late 90's I had dropped the desire to handle modern data with miggy)
-
That was a good read, thanks :)
-
"However, we have acquired a worldwide, non-exclusive, perpetual licence to use the Amiga One (and AmigaOne), AmigaOS and Boing Ball names and associated trademarks from Hyperion Entertainment."
Interesting. I knew about AmigaOne license, did not know about the others.
-
Yes, you would, but many don't. I wouldn't, because NG doesn't provide me with what I want.
Many people in the Amiga community are only interested in Classic and new hardware for Classic. Underestimating this when creating new non-classic hardware can bite you in the butt.
For many it's nostalgia, and NG doesn't deliver this. For many others it's the original Amiga games, and NG doesn't offer any advantages for that. In both cases the original hardware and Uae give you the best experience. Then there are people like me who like the original hardware as a cool retro platform. NG doesn't do that either, which is fine, because it's not what it's for anyway.
When you want to produce new hardware that's not related to the original hardware at all, you really have to keep this is mind.
The nostalgia crowd is only one small group, I'm part of that group as it was my second computer. However there is a larger group that gets overlooked that does not take part in the Amiga community.
They are Amiga fans, still out there waiting for new hardware. These are the people that are being overlooked.
They don't even know amiga.org and other forums exist or even that there is new hardware being produced. Advertising just for the Amiga community is a mistake as it is just too small.
The Amiga community is also not the end all be all of Amiga users. Just a small group of people that post on forums.
Amiga.org would be by tradition classic users so if this forum thread was on another forum it would have different responses.
Also I would disagree about Amiga NG not offering that nostalgia feel, AmigaOS 4.1 feels like a natural progression from AmigaOS 3.9. RuninUAE also is seamless once setup so you can even run igame and WHDLoad by just a double click.
At the end of the day it feels like a powerful A1200/A4000 with RTG. So my Pegasos II proudly sits along side my A1200T. Giving me the best of both worlds.
-
For many it's nostalgia, and NG doesn't deliver this.
Really? How do you know, have you tried/tinkered with any NG system? :)
-
They are Amiga fans, still out there waiting for new hardware. These are the people that are being overlooked.
They don't even know amiga.org and other forums exist or even that there is new hardware being produced. Advertising just for the Amiga community is a mistake as it is just too small.
This. :hammer:
Went to that thing in NJ, talked to at least a half-dozen active Amiga owners, only one is a member here. I laughed when a guy pulled out a video of Doommaster like it was "new news". Hate to be all like "I know all about him!" ;)
Even when I post on Facebook I almost always get comments from friends about "I should take my Amiga's out of the closet". I've got friends on there who were active developers and hardware owners back in the day, who have never even heard of this forum. If only there were some way to advertise to *them*. Hummmm.... :D
-
...Many people in the Amiga community are only interested in Classic and new hardware for Classic...
And a sizable number of us aren't.
It would really have to be both low cost AND extremely capable for me to consider wasting anything on the further pursuit of a virtually dead system.
Nostalgic value be damned, I need practical utility to interest me.
While you speak for yourself, Thorham, do you really think you speak for the majority of the market?
Because if you do, the Amiga really is dead.
-
Great interview!
-
While you speak for yourself, Thorham, do you really think you speak for the majority of the market?
Because if you do, the Amiga really is dead.
The market is dead, else there would be tens if not hundreds of thousand of users out there, and growing by the day to be considered a minimal market. There will be no reigniting any old markets, that dye has been caste a very long time ago.
A paradigm shift is an absolute must as a new market has to be created as quickly as possible. That means it has to compete with the current successful OSs and thrive. In order not only compete with those successful OSs and also thrive, it has to be modern, different, and uniting the Amiga base in short order. It will take a person with alot of capital and connections to make that happen.
-
The market is dead, else there would be tens if not hundreds of thousand of users out there, and growing by the day to be considered a minimal market. There will be no reigniting any old markets, that dye has been caste a very long time ago.
A paradigm shift is an absolute must as a new market has to be created as quickly as possible. That means it has to compete with the current successful OSs and thrive. In order not only compete with those successful OSs and also thrive, it has to be modern, different, and uniting the Amiga base in short order. It will take a person with alot of capital and connections to make that happen.
Do you know such a person?
-
"...it has to be modern, different,..."
Well, if the aim is to change it just to be different there is not point. Besides, if it's changed to be much different from what it is now then it's not AmigaOS anymore, we can call it StrawberryOS or Elate or whatever...
I think you meant different from the mainstream though, that it already is.
-
"...it has to be modern, different,..."
Well, if the aim is to change it just to be different there is not point. Besides, if it's changed to be much different from what it is now then it's not AmigaOS anymore, we can call it StrawberryOS or Elate or whatever...
I think you meant different from the mainstream though, that it already is.
Absolutely.
-
The market is dead, else there would be tens if not hundreds of thousand of users out there, and growing by the day to be considered a minimal market. There will be no reigniting any old markets, that dye has been caste a very long time ago.
A lot of people are into retro gaming, but many games have a retro style and they're build in modern platform. So you get the same feeling as using a retro computer while having an experience beyond what a retro computer can give.
Kamelito
-
AROS has the best chance of attracting new users. Most people agree there will be no new users when your competition is a $100 ARM computer.
Some people like a PowerPC system and have invested a lot of money in it. Some have invested a lot of money in a 68k system. I wouldn't change if I had spent so much money on (68k/PowerPC) already.
-
The market is dead, else there would be tens if not hundreds of thousand of users out there, and growing by the day to be considered a minimal market. There will be no reigniting any old markets, that dye has been caste a very long time ago.
A paradigm shift is an absolute must as a new market has to be created as quickly as possible. That means it has to compete with the current successful OSs and thrive. In order not only compete with those successful OSs and also thrive, it has to be modern, different, and uniting the Amiga base in short order. It will take a person with alot of capital and connections to make that happen.
is creating a new market an aim for itself? do we need to become addicted to some completely new independent product, as if it was not enough being addicted to amiga as is? what would be the purpose in all that, even assuming it had any chance to happen? i dont get it.
-
A paradigm shift is an absolute must as a new market has to be created as quickly as possible. That means it has to compete with the current successful OSs and thrive. In order not only compete with those successful OSs and also thrive, it has to be modern, different, and uniting the Amiga base in short order. It will take a person with alot of capital and connections to make that happen.
A shift towards what? AmigaOs as an "operating system" is as unfit for the future as an operating system can be. Most elementary services are missing and cannot be introduced without compromising backwards compatibility. So, whatever needs to be created is something very different from AmigaOs. Now, ask yourself, why do you want to do that? There are already plenty of alternatives on the market, depending on your needs. IOS, Android, Linux, Windows, Firefox-Os, ChromeOs...
Now, what is the market niche for "just another Os"?
The only anwer I can give is that AmigaOs targets at retro applications, and if you want anything different, get something different and do not attempt to "modernize" AmigaOs since that's not going to end anywhere. But that means that the Os must (mostly) stay as it is, with all it flaws, as bound to the hardware as it is.
-
@wawrzon & Thomas Richter
(http://dailysmspk.files.wordpress.com/2012/08/well-said-quotes-sms.jpg)
-
is creating a new market an aim for itself? do we need to become addicted to some completely new independent product, as if it was not enough being addicted to amiga as is? what would be the purpose in all that, even assuming it had any chance to happen? i dont get it.
Current market (desktop for middle aged men who want to remember their youth) is a failure. Target needs to be shifted to the larger (and new to us as a community) market with the goal of obtaining 1% market share. I think we all can agree there is something special about the Amiga, or at least it's spirit that we have yet to find outside of our communities. It's that spark that we need to present to the rest of the world at their level at competitive pricing. That spark needs to be not only aimed at middle age men who remember their younger years playing on a A500/A1200, but also the 30s and under crowd that haven't touched anything other then Windows, Android/Linux, or iOS machines.
-
Current market (desktop for middle aged men who want to remember their youth) is a failure.
That depends on your definition of "failure" and your definition of "market". Target needs to be shifted to the larger (and new to us as a community) market with the goal of obtaining 1% market share. I think we all can agree there is something special about the Amiga, or at least it's spirit that we have yet to find outside of our communities.
Is there? Define what is "special about the Amiga"... because I don't know. The only answer I can give are "old applications". For the problems they solve, there are either better solutions on more modern hardware, or the problems went away, they are no longer relevant. It's that spark that we need to present to the rest of the world at their level at competitive pricing.
The "spark" that drove Amiga back then was competing hardware at competative price, giving rise to a software market. Now, competing hardware today spells "PC", and applications spell "Windows compatible". Or, at a even broader level "Smartphone" and "Apps".
Everything that drove the Amiga back then is still there today. It's just on different hardware, different architectures and different products.
I don't know which other "Spark" you mean if there is one. Again, the only spark I remembered went on to other platforms, and for good reason.
That spark needs to be not only aimed at middle age men who remember their younger years playing on a A500/A1200, but also the 30s and under crowd that haven't touched anything other then Windows, Android/Linux, or iOS machines.
Those people want "F*c*book" and "Games". Guess what, they can get that with existing hardware. Or rather, if you want to slam on a solution to that problem the name "Amiga", then it has to be something entirely different than AmigaOs because AmigaOs is certainly *not* good for those people and their applications.
What you fail to realize is that the market changed quite a bit from back then. Back then, the market was (relatively) small compared to today's hardware market, users were "computer freaks" that new about their machines and that defined "playing with them" as "programming them". You could sell hardware by advanced technology because the buyers understood a bit about technology.
Computers today are mass-products. The problems they solve are all-world problems, "F*c*book" I already mentioned, Office, mail, photography, video, games. Users have no clue about their machines, they only use them, and do not buy them because of their advanced technology, but because they have some fruit on their back or a red dot somewhere in the logo. At least the majority of users...
Now, what exactly is it that Amiga or AmigaOs has to offer here, and how to compete with such products? New hardware? That's PC hardware, because that's the only one that's available for a competitive price. Even the "fruit label" has learned that. Software? Well, that's currently still either the stuff from Billyboy, or the fruity Os. Pengiuns are quite irrelevant for the mass market (server is something different, but do you consider Amiga as a server product?) And even that is fading away as "product" means more and more "HTML 5" as operating system. Google has learned that lesson very well, and I believe that they will outlast Apple and MS for exactly that reason.
Now, tell me again which relevance AmigaOs could play under such changed circumstances. If I define it by "I need a browser for HTML5", then the Os underneath is irrelevant. But even for Internet, AmigaOs is unsuitable due to Security reasons. Or the utter lack of any security infrastructure to begin with.
The game is simply over, face it. It's an old system, nice to play with, interesting for historical reasons for a handful of old farts like me. If that's not market enough, I don't know.
-
Current market (desktop for middle aged men who want to remember their youth) is a failure. Target needs to be shifted to the larger (and new to us as a community) market with the goal of obtaining 1% market share. I think we all can agree there is something special about the Amiga, or at least it's spirit that we have yet to find outside of our communities. It's that spark that we need to present to the rest of the world at their level at competitive pricing. That spark needs to be not only aimed at middle age men who remember their younger years playing on a A500/A1200, but also the 30s and under crowd that haven't touched anything other then Windows, Android/Linux, or iOS machines.
as one of these middle aged men i dont have any interest in shift to any larger market for younger audience, as this shift is inevitably bound to resignation of what amiga ever was. i really dont understand this logic, and do not see what is there to gain for either party. this is also the reason all amiga ng alternatives are bound to fail, beyond maintaining some sort of status quo. and the people know it instinctively and while dreaming of something never to come do not actually wager to budge a bit, except maybe for pure name fans if they really had some actual label to slap on whatever it might be.
-
A future based on AmigaOS? An OS stuck in the past? Why? What's the point? Even my A1200 with 68030 can do better than cruddy old AmigaOS.
Anyone who thinks AOS is going to go anywhere is dreaming and needs to start seeing things from a realistic viewpoint.
Basically it's replace AOS by something that's MUCH better, or no chance in hell.
-
A future based on AmigaOS? An OS stuck in the past? Why? What's the point? Even my A1200 with 68030 can do better than cruddy old AmigaOS.
Anyone who thinks AOS is going to go anywhere is dreaming and needs to start seeing things from a realistic viewpoint.
Basically it's replace AOS by something that's MUCH better, or no chance in hell.
You ARE living in a fantasy, aren't you?
Your '030 is pathetic compared to any cpu used in a NG system.
And comparing my ten years old 2.7 GHz G5 system to your processors is pointless, the 68K series even ramped up to 2 or 3 times it current clock speeds would still benchmark at a small fraction of the performance.
And I was a big supporter of the 68K family when it was relevant.
Of course, that was back in the '80's and '90's when I was working for a company that sold systems based on those processors.
You can continue to live in your dream world, but don't expect to make statements you can't support in public without being challenged.
-
Current market (desktop for middle aged men who want to remember their youth) is a failure. Target needs to be shifted to the larger (and new to us as a community) market with the goal of obtaining 1% market share. I think we all can agree there is something special about the Amiga, or at least it's spirit that we have yet to find outside of our communities. It's that spark that we need to present to the rest of the world at their level at competitive pricing. That spark needs to be not only aimed at middle age men who remember their younger years playing on a A500/A1200, but also the 30s and under crowd that haven't touched anything other then Windows, Android/Linux, or iOS machines.
as Thomas already wrote all amiga successors are very unsecure regarding Internet. The only protection right now is obscurity. If you want to attract a broader audience you must offer security and for that you would need memory protection what requires heavy changes at the OS. A modernized OS would have not much to do anymore with the existing platforms and the software would need to be rewritten for it. And you need software and services that are unique and had to be developed as well.
Much more important in my view right now would be modern development tools.
Regarding "middle aged man", I am one of those too
There were millions of Amigas sold in germany so I assume there are a lot of middle aged man who can remember of Amiga. If we manage to convince only parts of these the platform would already be in a much better state. To reach the group of below 30 (the smartphone/tablet generation) you would need something completely different including completely new software so I think that is by far out of reach.
-
You ARE living in a fantasy, aren't you?
Your '030 is pathetic compared to any cpu used in a NG system.
And comparing my ten years old 2.7 GHz G5 system to your processors is pointless, the 68K series even ramped up to 2 or 3 times it current clock speeds would still benchmark at a small fraction of the performance.
And I was a big supporter of the 68K family when it was relevant.
Of course, that was back in the '80's and '90's when I was working for a company that sold systems based on those processors.
You can continue to live in your dream world, but don't expect to make statements you can't support in public without being challenged.
Do not be too proud on your PPC :)
When running 68k in UAE on modern hardware most of the systems are outperformed already (not G5 or X1000 of course, at least not yet)
-
You ARE living in a fantasy, aren't you?
Your '030 is pathetic compared to any cpu used in a NG system.
What on earth do NG systems have to do with the fact that a 68030 can run something better than AOS? I wasn't talking about HARDWARE, I was talking about SOFTWARE. S-O-F-T-W-A-R-E. Get it?
Why, in the name of all that's good and wholesome, would I say that a 68030 can run better things than NG? NG can run something better than AOS, too. In both cases it's only impossible because nothing better has been written yet.
68030 -> Can do better than AOS.
NG -> Can do MUCH better than AOS.
Understand now?
-
Do not be too proud on your PPC :)
When running 68k in UAE on modern hardware most of the systems are outperformed already (not G5 or X1000 of course, at least not yet)
You mean running 68K emulation on an X64?
Of course, but that isn't a real 68K.
Its an Intel derived processor pretending its a 68K.
Which, considering my past disdain for Intel's products is pretty depressing.
-
What on earth do NG systems have to do with the fact that a 68030 can run something better than AOS? I wasn't talking about HARDWARE, I was talking about SOFTWARE. S-O-F-T-W-A-R-E. Get it?
Why, in the name of all that's good and wholesome, would I say that a 68030 can run better things than NG? NG can run something better than AOS, too. In both cases it's only impossible because nothing better has been written yet.
68030 -> Can do better than AOS.
NG -> Can do MUCH better than AOS.
Understand now?
Sorry, I knew it was snide when I posted it.
My apologies for what was probably my deliberate misinterpretation.
Yes AOS is weak.
I have considered purchasing an OS4 system to play around with, but frankly the its a weak re-implementation of OS3.1 (and 3.1 had a lot of rough spots in its day).
We could do better.
Probably why I'm using MorphOS. It could evolve into something completely beyond AOS. Particularly when they make the proposed ISA change and jetison legacy compatibility.
And...I'll have to admit, if a decent re-implementation of the 68K is done, I'll probably follow that really closely.
After all, I was working in sales and development simultaneously when we moved from the 68000 to the 68020.
Frightening jump in performance per cycle (not so much with the '30).
Then the '040 and '060 provided yet another big jump.
Were there a serious attempt to start there ('40/'60), and move forward...
Particularly if it was a higher end FPGA or better yet dedicated silicon...
Hey, you'd have my attention.
A 64bit GHz speed 68K derived processor, yeah a pipe dream, but it would be cool.
And as to Amiga OS?
Yeah we are on the same page.
Too primitive.
Again, my apologies.
-
Sorry, I knew it was snide when I posted it.
My apologies for what was probably my deliberate misinterpretation.
Cool, thanks :)
And...I'll have to admit, if a decent re-implementation of the 68K is done, I'll probably follow that really closely.
That's probably very hard, because a reimplementation implies backward compatibility with existing software. If that's the case, then you're still stuck with a sizable portion of AOS crud. What I'd rather see is something completely new that has absolutely no ties to AOS at all, so that you could implement whatever you wanted, in whatever way that you wanted. Classic and NG would have to go their own separate ways, of course.
The big problem is that you'd end up with a cool OS with no software :( For NG it would also mean that there would be no ties to Amiga anymore.
-
Cool, thanks :)
That's probably very hard, because a reimplementation implies backward compatibility with existing software. If that's the case, then you're still stuck with a sizable portion of AOS crud. What I'd rather see is something completely new that has absolutely no ties to AOS at all, so that you could implement whatever you wanted, in whatever way that you wanted. Classic and NG would have to go their own separate ways, of course.
The big problem is that you'd end up with a cool OS with no software :( For NG it would also mean that there would be no ties to Amiga anymore.
Yeah, I know it can be hard to let go.
But evolution offers so much more than backward compatibility does.
The last OS' I used on the 68K were micro kernel OS', as is MorphOS.
Jettison backward compatibility and we can embrace SMP, 32 or 64 bit addressing, and all the other goodies inherent in a modern operating system.
And I know the 68K can do better.
Amiga OS has a lousy multi-tasking system based on a cooperative round robin form of task switching.
Other OS' I've used (for the 68K) had real priority based preemptive multitasking.
Back when Intel boxes couldn't out multi-task a Radio Shack Color Computer, I was using 68K based systems that could dance circles around those lame calculator derived pos.
So, I wholly agree, we could do better.
Even in the '80s and '90s we could have done better.
-
The repsonses by you. It is like the opening to a video game.
"Your 68k is no match for my PowerPC."
"Your puny systems are dead"
-
The repsonses by you. It is like the opening to a video game.
"Your 68k is no match for my PowerPC."
"Your puny systems are dead"
Sorry, senor Devil Chicken, I was not thinking clearly yesterday.
One-upmanship over such points is childish.
And I still work on hacking project involving 8 and 16 bit processor, if I was that concerned about performance I'd only use modern cpus.
Older hardware holds more than a little fascination for me.
Performance wise, it still can't hold a candle to newer designs.
-
Amiga OS has a lousy multi-tasking system based on a cooperative round robin form of task switching.
Other OS' I've used (for the 68K) had real priority based preemptive multitasking.
The Amiga has always had real priority based preemptive multitasking.
-
The Amiga has always had real priority based preemptive multitasking.
No, it doesn't.
And we've discussed this before on this site.
It has just the type of task switching scheme I mentioned.
Doubt me?
Find a module in Amiga OS that sets the priority level.
-
No, it doesn't.
And we've discussed this before on this site.
The default scheduler is round-robin but Exec does preemptively multitask Jim.
It has just the type of task switching scheme I mentioned.
Doubt me?
Find a module in Amiga OS that sets the priority level.
http://aminet.net/package/until/misc/Executive
Et voila! ;)
-
No, it doesn't.
And we've discussed this before on this site.
It has just the type of task switching scheme I mentioned.
Doubt me?
Yes, I do doubt you. I have no idea where you get the idea from that AmigaOS has a "cooperative" multitasking system rather than preemptive. The original MacOS was a cooperative multitasking system where you had to sprinkle your code with calls to yield the CPU. AmigaOS has no such function, because the OS will preemptively switch between tasks on a prioritized round-robin basis. I've never heard anyone claim that it's not preemptive... until now.
Sure, it has no "fairness" algorithm** (unless you have Executive installed) and setting the task priority to max almost kills multitasking. However, try setting a CPU intensive task to REALTIME_PRIORITY_CLASS, THREAD_PRIORITY_TIME_CRITICAL in Windows and see what happens. It's not pretty... Neither of these aspects demote AmigaOS from preemptive to cooperative, though.
Find a module in Amiga OS that sets the priority level.
exec.library->SetTaskPri() sets a task's priority. Or are you asking something else?
Hans
** NOTE: AmigaOS 4.x has a "pluggable" scheduler, so it could be updated with different scheduling algorithms in future.
-
The Amiga has always had real priority based preemptive multitasking.
True. Any task can take over the system and turn off multitasking so it is not secure but it is preemptive multitasking by definition. Responsiveness was traded for security.
I feel the AmigaOS has been slighted (not by mongo). The AmigaOS is one of the best and most responsive OSs at multitasking (near real time OS made the Toaster possible). Code reuse and modularity are also top notch even today. The AmigaOS trades security for speed and ease of use. There was a lot of forward thinking in the AmigaOS design and choice of 68k CPU which allows most software from 1985 to still work today. Both the AmigaOS and 68k CPU have survived the test of time quite well, IMO, despite not having been developed anywhere near their potentials. The Amiga weak point (originally it's strength) was the custom chips which again were under developed. Compare the AmigaOS to the DOS+Windows, MacOS, RiscOS and the Amiga has less growing pains and more speed. It's the lack of a more modern 68k AmigaOS, lack of more modern 68k hardware (which I believe can be kept very compatible) and as a result lack of more modern software and software support that makes the grass greener on the other side of the fence.
-
True. Any task can take over the system and turn off multitasking so it is not secure but it is preemptive multitasking by definition. Responsiveness was traded for security.
I feel the AmigaOS has been slighted (not by mongo). The AmigaOS is one of the best and most responsive OSs at multitasking (near real time OS made the Toaster possible). Code reuse and modularity are also top notch even today. The AmigaOS trades security for speed and ease of use. There was a lot of forward thinking in the AmigaOS design and choice of 68k CPU which allows most software from 1985 to still work today. Both the AmigaOS and 68k CPU have survived the test of time quite well, IMO, despite not having been developed anywhere near their potentials. The Amiga weak point (originally it's strength) was the custom chips which again were under developed. Compare the AmigaOS to the DOS+Windows, MacOS, RiscOS and the Amiga has less growing pains and more speed. It's the lack of a more modern 68k AmigaOS, lack of more modern 68k hardware (which I believe can be kept very compatible) and as a result lack of more modern software and software support that makes the grass greener on the other side of the fence.
By those words (which I have bold faced) you make my point.
The OS is cooperative, preemptive multitasking would always allow another process to eventually gain control.
Not that a round robin scheduler always precludes preemptive operation.
But a decent OS would always reserve some time slices for kernel operations that would allow enforcement of task switching.
In short, see the second sentence in my post.
Obviously there IS prioritization.
Thanks for pointing to that module.
I missed that.
But in the case of the Amiga (and OSX and Windows for that matter), the definition of a preemptive Multitasking OS has been seriously abused.
-
@thread nice read
However more must be done on Linux, we dont need 20+ distros.
The Linux users want a fast efficient Linux system, OS in 10 MB max.
Linux users want ASSEMBLY development system.
Even on Windows Games are still problematic to write.
Amiga had it good back in the day, but suffered - too many programming languages at poor level, but most hit the wall at AGA.
These days Classic users want more 68k power than a 68060 ~ 100+ MHZ but an AGA+ chipset or at least code compatible simulated chipset using OpenGL for 24 bit graphics.
At end of the day Amigans want to bang hardware/GFX in assembler - real hardware or simulated. I dont know if AMD have released any register info for their chips to directly access.
Only when these systems are available and under £300 systems we can rejoice.
I personally think new Amiga systems should use sub $100 processors as a rule + media processor + FPGA.
Linux users can use assembler
Amiga classic users - Stripped Linux + 68k amige emulator can simulate a standard AGA+ chipset in FPGA and code GFX in assembler + 68k.
Amiga needs a low level compatible assembly + GFX across Amiga devices
But we also need uptodate game developer systems like UNITY addon for Amiga code. so we can create code compatible games and programs forever.
An example of a game developer community I wish was for Amiga is like the following :
Scirra development system to create games fast on windows and export to mobile devices.
https://www.scirra.com/store
-
By those words (which I have bold faced) you make my point.
The OS is cooperative, preemptive multitasking would always allow another process to eventually gain control.
Not that a round robin scheduler always precludes preemptive operation.
But a decent OS would always reserve some time slices for kernel operations that would allow enforcement of task switching.
In short, see the second sentence in my post.
No. Preemptive multitasking uses a timer that lets tasks run until their time is up and then the task is preempted (interrupted) to give another a turn. This is how the Amiga works. Preemptive multitasking can be turned off with other operating systems through Admin privileges or hacking which makes their multitasking no less preemptive (while it's working). The task doesn't have to worry about task scheduling or what task is running with preemptive multitasking. Cooperative multitasking requires the task to call an OS function to allow another task to run. The Amiga exec.library does have a Switch() function (-$36) but it is private (even though it may be useful in some cases). The Amiga is considered to have preemptive multitasking though.
-
No. Preemptive multitasking uses a timer that lets tasks run until their time is up and then the task is preempted (interrupted) to give another a turn. This is how the Amiga works. Preemptive multitasking can be turned off with other operating systems through Admin privileges or hacking which makes their multitasking no less preemptive (while it's working). The task doesn't have to worry about task scheduling or what task is running with preemptive multitasking. Cooperative multitasking requires the task to call an OS function to allow another task to run. The Amiga exec.library does have a Switch() function (-$36) but it is private (even though it may be useful in some cases). The Amiga is considered to have preemptive multitasking though.
Considered, but not actually is (since preemption can be defeated).
But this is by the definitions I use (obviously), not those you all use (or in my opinion, abuse).
And no, preemptive systems don't always use a simple timer based task switch.
Other systems (that don't use a round robin scheduler) assign a specific percentage of the available time slices to each process.
Since, in the case of Amiga OS, a task CAN seize all available resources, cooperation between tasks is necessary to assure that other processes will receive their share of system resources.
Edit - Looking over this, my bias is (even to me) painfully obvious.
Coming from OS' that always give ultimate priority to the kernel (and thus will never allow a single process to assume complete control of a system), Amiga OS has been (somewhat) disappointing.
So...by common definition, using the term preemptive is acceptable (even if this can be defeated) AND prioritization has previously been documented.
So... I'll cede this one to you guys.
With the qualifier that it is a piss poor implementation of preemptive multi-tasking.
-
So... I'll cede this one to you guys.
I'm still gonna add something :D
Since, in the case of Amiga OS, a task CAN seize all available resources, cooperation between tasks is necessary to assure that other processes will receive their share of system resources.
How? Only if a Forbid() Permit() pair is ever truly needed for certain things is there some kind of cooperativeness in the OS.
Which leads me to a question: Why is there Forbid() and Permit() in the first place? Apart from shutting the OS down I see no reason for those functions to be there at all.
With the qualifier that it is a piss poor implementation of preemptive multi-tasking.
Indeed. Not useless, but crappy non the less. Strange seeing how easy it is to write something better. One of these days I'm going to sit down and just do it... maybe... perhaps...
-
If you kept all the major components including being able to rename any file. I wouldn't care if it was re-done.
You should do a poll now on which parts of the OS can be modified. It would be nice if the users were able to have a vote.
-
If you kept all the major components including being able to rename any file. I wouldn't care if it was re-done.
You should do a poll now on which parts of the OS can be modified. It would be nice if the users were able to have a vote.
With 'writing something better' I mean a completely new OS that's entirely incompatible with AOS. Not a single part would be kept. It would be more of a proof of concept than anything else, because there would be no software to run on it, of course.
I would also do it in 68k assembly language. Completely. Some people will probably tell you that that's a very bad idea :D
-
Edit - Looking over this, my bias is (even to me) painfully obvious.
Coming from OS' that always give ultimate priority to the kernel (and thus will never allow a single process to assume complete control of a system), Amiga OS has been (somewhat) disappointing.
So...by common definition, using the term preemptive is acceptable (even if this can be defeated) AND prioritization has previously been documented.
So... I'll cede this one to you guys.
With the qualifier that it is a piss poor implementation of preemptive multi-tasking.
The AmigaOS requires cooperation between good behaving preemptively multitasking tasks. Again, this was a tradeoff of security (and to a lesser extent stability) for speed and ease of use. It was a better trade-off back in the day when CPU power was more limited but I would argue that the advantages are under-appreciated today. Would there be Amiga users today if the Amiga ran at the speed modern secure operating systems would run on a <100MHz 68k CPU? Would the Amiga be as fun and easy to use?
Which leads me to a question: Why is there Forbid() and Permit() in the first place? Apart from shutting the OS down I see no reason for those functions to be there at all.
Resources need to be shared with a multitasking AmigaOS and the 68k and locking CPU instructions (CAS, CAS2, TAS) didn't work correctly because of the way the memory bus was accessed with the custom chips (cache coherency issues between the CPU and custom chips). C= could have solved the problem if they made (or licensed) their own customized CPU to go with the custom chips but that was exceedingly expensive back then. This is no longer a problem today in FPGA (SMP should be possible too).
Forbid()/Permit() are not as big of worry as exec/Supervisor() and dos/Format(). The Amiga will never be as secure as BSD but there are a few things we could do to improve security (or at least improve stability and make it quick and easy to recover and restore from problems).
-
I actually like Thorham's idea, even if it is impractical.
You wouldn't have any software to run.
But, given a fresh slate, you could undoubtedly come up with a better OS.
I'd start with a micro kernel (again, my bias).
All the cores functions could be protected in this and additional functions could be dynamically loaded in layers outside the kernel.
Coding directly with an assembler makes sense.
Yes, its more painful, but it would also result in more compact, faster code.
Of course, the next thought that occurs to me is that while I like the idea of keeping the 68K cpu (or better yet an '030, '040, or '060), the custom chips in the Amiga date it.
Better, 16 bit sound would be nice.
Certainly better video with 2D and 3D acceleration wouldn't hurt.
A better bus could help speed up access to these elements.
And...well there's a lot more.
But, even retaining the Amiga's core architecture, yeh a better OS could be done.
-
...One of these days I'm going to sit down and just do it... maybe... perhaps...
Should you ever seriously decide to do this, I'm in.
Again (and I DO know this is repetitive), we start with the kernel deciding what absolutely has to reside at the core, and work out from there.
-
Resources need to be shared with a multitasking AmigaOS and the 68k and locking CPU instructions (CAS, CAS2, TAS) didn't work correctly because of the way the memory bus was accessed with the custom chips (cache coherency issues between the CPU and custom chips).
You don't need those, because you can use bset and bclr. These instructions test the bit they set or clear before writing to the bit. With this you have test then set and test then clear. Perfectly fine for such mechanisms. Aren't CAS. CAS2 and TAS for multiple CPUs anyway?
The Amiga will never be as secure as BSD
Unless you run BSD on it :D
Coding directly with an assembler makes sense.
Yes, its more painful, but it would also result in more compact, faster code.
It's more fun! 68k assembly language is a hobby of mine. C is nice, but I use it for utilities like Lua5.3 with some added libraries, or some other miscellaneous things.
Should you ever seriously decide to do this, I'm in.
Don't wait for it.
-
You don't need those, because you can use bset and bclr. These instructions test the bit they set or clear before writing to the bit. With this you have test then set and test then clear. Perfectly fine for such mechanisms. Aren't CAS. CAS2 and TAS for multiple CPUs anyway?
The 68k, like most CISC processors, does read-modify-write cycles atomically (together). This is used on the Amiga extensively for incrementing/decrementing library open counts for example. RISC can't do this because the ALU and load/store instructions are separate (problematic for PPC Amigas). The locking instructions like CAS, CAS2, TAS are used for resource arbitration which is essential for multiple CPUs/cores but they can also be used for multitasking resource arbitration. MacOS and Unix like OSs use them more than they should considering how slow they are (hundreds of cycles in worst cases). The AmigaOS started with Forbid()/Permit() and later added semaphores. AmigaOS 4 added spinlocks and their locking instructions should work without the custom chips (which they need to use more). I'm no expert on this topic and it can be tricky so I will stop here (one reason programming on a PC is more difficult for beginners).
-
True. Any task can take over the system and turn off multitasking so it is not secure but it is preemptive multitasking by definition. Responsiveness was traded for security.
... The AmigaOS is one of the best and most responsive OSs at multitasking (near real time OS made the Toaster possible). Code reuse and modularity are also top notch even today. The AmigaOS trades security for speed and ease of use.
... Compare the AmigaOS to the DOS+Windows, MacOS, RiscOS and the Amiga has less growing pains and more speed. ....
Nice thread & nice post.
Never thought that the ability to stop task switching for a while is one of the reasons why AOS has been so wickedly fast (responsive).
Instead of NG developments done behind closed doors I would love to see alternative kernels etc. and some recompiled apps for it, for user community to try, to see how they can behave.
When we now have Ghz instead of Mhz to play with, there should be room to take "slower" ways in use without being slower than the fastest multitasker and responder OS+HW of y1990.
++
Also... when thinking of multicore systems. IMO: server OSs (Linux, Unix, OSX, NT) have taken SMP in use without considering if it would give better responsives if some core is put to deliver the user experience (dedicated to it heavily, if not totally).
I'm thinking that if the SW that is responsible for user experience (responsiveness) would have very high priority on some core, it more likely has the data it needs on the L2 cache etc.... IMO, some OS need several cores at 2Ghz to say "tada", so focusing stuff on only one core might not be good idea for that kind of mammoth OS. But I think for some OS (that almost fits in L2 cache of a core) it might work better.
-
"However, we have acquired a worldwide, non-exclusive, perpetual licence to use the Amiga One (and AmigaOne), AmigaOS and Boing Ball names and associated trademarks from Hyperion Entertainment."
Interesting. I knew about AmigaOne license, did not know about the others.
A-EON having been using the Boingball and AmigaOS branding on their products for quite some time so nothing new here.
-
You don't need those, because you can use bset and bclr. These instructions test the bit they set or clear before writing to the bit. With this you have test then set and test then clear. Perfectly fine for such mechanisms.
When you are programming in higher level languages you dont have those assembler instructions available. The compiler may generate code using those instructions but it is not guaranteed. For example Intuition manual recommends using Forbid()/Permit() pair if you are toggling flags in your Window structure.
Forbid()/Permit() pair is also fundamental part of AmigaOS design. When you are scanning certain system lists you must arbitrate access with these. When Workbench launched program is returning it must call Forbid() before exit. If you are sending a message to public message port you must use Forbid() for protection. Many functions in the OS are serialized and are executed in Forbid() like memory handlers and library init/expunge functions.
Semaphores in AmigaOS are internally using Forbid(). AllocMem() is using Forbid() and it is very slow function what hampers multitasking very badly if called repeatedly.
-
With 'writing something better' I mean a completely new OS that's entirely incompatible with AOS. Not a single part would be kept. It would be more of a proof of concept than anything else, because there would be no software to run on it, of course.
I would also do it in 68k assembly language. Completely. Some people will probably tell you that that's a very bad idea :D
To develop a new OS just as "proof of concept" with no software for it instead of f.e. helping on Aros 68k to improve it sounds rather weird to me but go for it if you want
-
You don't need those, because you can use bset and bclr. These instructions test the bit they set or clear before writing to the bit. With this you have test then set and test then clear. Perfectly fine for such mechanisms. Aren't CAS. CAS2 and TAS for multiple CPUs anyway?
For that, or at least, for systems with multiple bus masters. The Amiga infrastructure does not need those, resource locking is done in a different way. Unfortunately, a pretty broken way.
AmigaOs uses "Forbid()/Permit()" as low-level locking mechanism, along with "Disable()/Enable()". Unfortunately, the former cannot work on multi-core systems, whereas the latter is even more broken as it requires even a communication to the slow custom chips.
Other operating systems use a smarter and more scalable design where the lowest level synchronization primitive is not based on disabling multitasking completely, but on semaphores. Everything else is then based on top of this, including monitors (this is the closest analog to exec semaphores, which are - actually - not really semaphores in the classical sense, but rather "monitors").
As of 2.04, Forbid() locking (fortunately) grew out of fashion in many places, even the dos.library uses now semaphores in many places - though for backwards compatibility, also runs a forbid-lock on top. (Shudder).
-
The 68k, like most CISC processors, does read-modify-write cycles atomically (together). This is used on the Amiga extensively for incrementing/decrementing library open counts for example.
Actually, bset/bclr or addq are not atomic, at least not in the sense the word is used today. A second bus master could intercept the instruction at any time and then observe Os structures in an inconsistent way. Except that such bus masters are absent on the Amiga as single-core machine.
Library open counts are, however, not really secured due to atomicity of addq/subq, but are rather Forbid/Permit locked. Or actually, the whole story is a bit more complicated, as library open consists of the low-level exec function which is forbid-locked, and a high-level ramlib add-on which is patched in by the system itself as soon as dos becomes available. Then, however, locating libraries is due to the single-threaded ramlib task to which exec (or rather, the ramlib patch on top of exec) communicates. Thus, this is a pretty complex beast and had, as of 1.3, quite a couple of loopholes.
addq/bset and friends are thus less often used by the Os as one may think. In fact, if you are writing in a higher level language, one cannot guarantee that the compiler emits the right instructions in first place (unless you're using C++11, which does have atomic variables. "atomic" in the real sense. Of course, there is no such compiler on the Amiga.)
-
...Don't wait for it.
Yes, I rather figured that.
-
When you are programming in higher level languages you dont have those assembler instructions available.
For an OS it doesn't seem a problem to have some handwritten code here and there. User programs should use OS facilities for locking mechanisms.
Forbid()/Permit() pair is also fundamental part of AmigaOS design. When you are scanning certain system lists you must arbitrate access with these. When Workbench launched program is returning it must call Forbid() before exit. If you are sending a message to public message port you must use Forbid() for protection. Many functions in the OS are serialized and are executed in Forbid() like memory handlers and library init/expunge functions.
Semaphores in AmigaOS are internally using Forbid(). AllocMem() is using Forbid() and it is very slow function what hampers multitasking very badly if called repeatedly.
I didn't expect that. What a steaming pile :(
To develop a new OS just as "proof of concept" with no software for it instead of f.e. helping on Aros 68k to improve it sounds rather weird to me but go for it if you want
Is it so weird to want something new that's not hampered by cruddy design? Anyway, if they want 68k assembly language optimizations for 68k Aros, then that meight be interesting for me.
For that, or at least, for systems with multiple bus masters.
Good, I want to try some things, and don't want to be stuck with instructions that may or may not work properly.
-
Is it so weird to want something new that's not hampered by cruddy design? Anyway, if they want 68k assembly language optimizations for 68k Aros, then that meight be interesting for me.
While I don't know the design goals of AROS, I would assume that some form of source-code based compatibility is desired there. So I afraid AROS suffers from the same elementary Forbid/Permit problem AmigaOs has. But anyhow, this pair is only one of many design flaws.
While I agree that it is probably not weird to want something new, I should also say that I wouldn't really expect much interest from outside on such a project. There are many things that could be done better, better than AmigaOs, or Linux, or Windows, all together. But whatever design you come up with, it is really the application base that makes a living Os, and as such, any new design is damned to be irrelevant... Good, I want to try some things, and don't want to be stuck with instructions that may or may not work properly.
bset and friends are surely working correctly, and are - as far as AmigaOs is concerned - "atomic enough" if you get my drift. TAS/CAS/CAS2 and so on is nothing you can count on on Amiga hardware. It will probably not do what you want, and even interact badly with some bus protocols. For example, I'm not entirely sure what a TAS into Zorro RAM might possibly do. It's probably even board dependent.
-
True. Any task can take over the system and turn off multitasking so it is not secure but it is preemptive multitasking by definition. Responsiveness was traded for security.
I feel the AmigaOS has been slighted (not by mongo). The AmigaOS is one of the best and most responsive OSs at multitasking (near real time OS made the Toaster possible).
I am not so sure is this true. If Amiga multitasking is so good why MP3 players or CD burners need large buffers?
To me it seems multitasking on Amiga is unpredictable.
-
I am not so sure is this true. If Amiga multitasking is so good why MP3 players or CD burners need large buffers?
To me it seems multitasking on Amiga is unpredictable.
Actually, this is really not the fault of the multitasking. First of all, "large" is really a matter of perspective. Is a one megabyte buffer large or small? For the Amiga, it is large, for a PC, it is small.
But more important, the problem is really slow I/O. Look at the bandwidth average Amiga hardware has to offer. Probably a couple of MBs per second. Consider the latency of the average old Amiga harddrive (from the museum). Now compare that with a PC (probably hundred to thousand times higher bandwidth) times lower latency, times larger buffers....
-
Is it so weird to want something new that's not hampered by cruddy design? Anyway, if they want 68k assembly language optimizations for 68k Aros, then that meight be interesting for me.
one would have to chat with aros developers, where asm optimizations would be already useful. there is already 68k asm in places, mostly by jason and toni but also some optimizations by matthey. best is to read neccessary documentation, join developers mailing list, get access to the repository and kcommunicate with them. im a member, but im not experienced in coding. however, wherever i can help, i will. for instance to setup local build environment.
-
I am not so sure is this true. If Amiga multitasking is so good why MP3 players or CD burners need large buffers?
To me it seems multitasking on Amiga is unpredictable.
Paula's audio buffer size is limited by the custom chips (easily fixed with enhanced custom chips). The Amiga serial ports were limited to low speeds because of limited buffer size support. Amiga IDE was limited by small buffer sizes (and old PIO modes) until the 4000T. Without proper buffer sizes, the CPU has to do more work and the Amiga with 68k CPU has a limited pool of CPU cycles to start with. Buffer sizes were probably adequate when the Amiga was created but were barely or in most cases not upgraded with ECS and AGA. The Amiga did receive expansion boards and accelerators which fixed many of these bottlenecks.
Try installing Windows XP on an old 386, 486 or Pentium CPU to see how responsive it is in comparison to a 68k Amiga. I had the fan die in an old laptop with Pentium M (roughly the performance of a Pentium III at the same clock speed but more efficient on power) which caused the clock speed to run at 800MHz. Responsiveness was worse than most 68k Amigas even though it had some processing power in slow motion. These modern OSs with their security, features and bloat have a lot of overhead. MOS PPC Macs also are more responsive and performance efficient than with their previous Mac OS X. Any surprise?
-
Paula's audio buffer size is limited by the custom chips (easily fixed with enhanced custom chips). The Amiga serial ports were limited to low speeds because of limited buffer size support. Amiga IDE was limited by small buffer sizes (and old PIO modes) until the 4000T. Without proper buffer sizes, the CPU has to do more work and the Amiga with 68k CPU has a limited pool of CPU cycles to start with. Buffer sizes were probably adequate when the Amiga was created but were barely or in most cases not upgraded with ECS and AGA. The Amiga did receive expansion boards and accelerators which fixed many of these bottlenecks.
I am not sure is this related only to slow I/O. For example your real time application, is it still working right if you have GCC compiling large source code at background at lower priority?
Try to run simple non-IO real time task at priority 0 and GCC below 0.
You might find out that GCC is loading some files from the disk and this is delegated by the OS to tasks running at higher priority than your task. Suddenly your real time task is blocked by the OS serving low priority tasks.
To me it seems that if you dont raise your own priority over OS tasks you dont get served as expected. It doesnt matter how fast your system is. As long as you are running at priority lower than 10 the scheduler cant guarantee you fair share to the CPU.
Try installing Windows XP on an old 386, 486 or Pentium CPU to see how responsive it is in comparison to a 68k Amiga.
But Windows XP has lot more features than Amiga, like memory protection, built-in TCP/IP and USB stacks, and bunch of services (like you mention below).
I had the fan die in an old laptop with Pentium M (roughly the performance of a Pentium III at the same clock speed but more efficient on power) which caused the clock speed to run at 800MHz. Responsiveness was worse than most 68k Amigas even though it had some processing power in slow motion. These modern OSs with their security, features and bloat have a lot of overhead. MOS PPC Macs also are more responsive and performance efficient than with their previous Mac OS X. Any surprise?
Sure. No surprise there. But on the other hand raw performance is still same. Heavy computational tasks run roughly at same speed and it is not possible to have significant gain in the RC5-72 contest for example.
-
I am not sure is this related only to slow I/O. For example your real time application, is it still working right if you have GCC compiling large source code at background at lower priority?
"Real time" depends on the CPU performance and OS/multitasking efficiency so it only applies for a particular OS with a particular CPU doing specific tasks. This phrase is more commonly used when referring to embedded systems with defined bounds. Needed Cache sizes and response times can be calculated with most embedded systems but not for general purpose computers. This is why I used the phrase "near real time" when referring to general purpose computers. The AmigaOS with Toaster was real time enough for it's purposes on the Amiga where it was not possible with much faster processors on other operating systems. Throw in some more background tasks on the Amiga (like GCC compiling in the background at low priority) and the response time may have dropped too much. Add a faster 68k processor and the background tasks may be possible again with Toaster.
I asked for a lower task priority for vbcc's vc (maybe 68k only?) to be able to compile in the background while editing. Frank Wille chose a task priority of -2 which made a huge difference in editor responsiveness (major slow down to minor slow down). I am using a CSMK3 68060@75MHz with many of the bottlenecks we talked about before removed. A slower and less efficient Amiga may not feel so responsive while compiling and editing.
-
I am not sure is this related only to slow I/O. For example your real time application, is it still working right if you have GCC compiling large source code at background at lower priority?
As far as the Amiga task system works, it should. A higher priority task will always pre-empt a lower priority task. Thus, whenever your "real time" (something like that does not exist on the Amiga) application requires the CPU, and it has a higher priority than the background job, it gets the CPU. You might find out that GCC is loading some files from the disk and this is delegated by the OS to tasks running at higher priority than your task. Suddenly your real time task is blocked by the OS serving low priority tasks.
It's not quite as bad. The FFS has a higher priority, yes, but it does not do much. It just prepares a couple of buffer pointers and then gives control back to the hardware abstraction level aka "device". Here, again the game is the same: If you have hardware that is smart enough, the device will only initiate a DMA, and hence give control back to the foreground job as long as the transfer is running. CPU time is not "burned" while waiting for the I/O.
If you are have a sorry "PIO-only" host adapter, you have a problem, though, because somehow somewhere the CPU needs to take the time from to transport the data from the disk to the RAM. That, then, of course, can really steal important time and make your day, and the device has no knowledge about which I/O it should initiate first as the origin of the request is lost. But that's not really the fault of the AmigaOs, but rather of the hardware requiring full CPU attention for I/O. It does not happen for DMA-based host adapters.
Nothing in the device, however, and nothing in the filing system - at least in the Amiga FFS - will block. The FFS is itself multithreaded (in some sense), so it can take multiple requests at once and schedule them to the device independently. I'm not so sure about these alternative "professional" or "smart" filing systems whether they can really do that. FFS can... To me it seems that if you dont raise your own priority over OS tasks you dont get served as expected. It doesnt matter how fast your system is. As long as you are running at priority lower than 10 the scheduler cant guarantee you fair share to the CPU.
Probably task priorities do not work as you expect them to work. The priority does not define a proportionality factor for the time slice of CPU time a task gets. It is rather an absolute number of which task can pre-empt which other task. As long as there is a higher priority task requiring the CPU, all lower tasks do not get the CPU at all. That is, if there is a task running at priority one, everything at priority zero and below gets *no* time at all. (And not just "less time". I mean really: NOTHING). Thus, if you have a foreground job at prio=1 and a background compiler job at prio=0, then the compiler does not run at all. As simple as that. Whether that's good or bad is another rmatter, but this is how exec works.
-
"Real time" depends on the CPU performance and OS/multitasking efficiency so it only applies for a particular OS with a particular CPU doing specific tasks. This phrase is more commonly used when referring to embedded systems with defined bounds. Needed Cache sizes and response times can be calculated with most embedded systems but not for general purpose computers. This is why I used the phrase "near real time" when referring to general purpose computers. The AmigaOS with Toaster was real time enough for it's purposes on the Amiga where it was not possible with much faster processors on other operating systems. Throw in some more background tasks on the Amiga (like GCC compiling in the background at low priority) and the response time may have dropped too much. Add a faster 68k processor and the background tasks may be possible again with Toaster.
I asked for a lower task priority for vbcc's vc (maybe 68k only?) to be able to compile in the background while editing. Frank Wille chose a task priority of -2 which made a huge difference in editor responsiveness (major slow down to minor slow down). I am using a CSMK3 68060@75MHz with many of the bottlenecks we talked about before removed. A slower and less efficient Amiga may not feel so responsive while compiling and editing.
Yes, at best "near real time".
That is why you threw me with your comment about Amiga multitasking being one of the best.
I've worked with embedded OS', and Amigas don't come close in terms of true real time response, consistent performance, or reliability.
-
I just want to say that my main build host for Gentoo Linux/m68k was one of my A1200s with Blizzard 1260 clocked at 50MHz and with 192MB RAM. It would run gcc more or less constantly, and that never affected its responsiveness as webserver and certainly not me using vim or doing other tasks. Responsiveness only went downhill when it ran out of physical RAM and started paging much. With Linux one can adjust many parameters to adjust swap priority and still have well responding interaction.
-
Buffers & 68k AOS multitasking...
In late 90's some people burned CDs with their pretty basic A2000 computers while on x86 200Mhz was said to be the absolute minimum. That's because the low overhead on Amiga.
At that time also I burned CDs with my A4000/060. I did not have burnProof capable CDRW drive (nor burner SW supporting burnproof). I had to use pretty large buffer so that A4000 had time to transfer enough data with some 4x burn speed. And .iso had to be prepared beforehand. But it was possible and worked reliably with just 50Mhz.
IIRC, with 060/50 I did not need to have very large buffers. And I think I had executive shuffling all my heavy tasks to lower priority automatically. near-realtime needing apps were automatically left as they were or they were promoted higher than 0 priority.
To me Amiga of late 90's was unusable without executive as I used multitasking very heavily all the time.
hehe... and the classic.... trying to handle a floppy disk with x86 was a nightmare always vs how it worked on Amiga ... floppy or serial I/O could destroy x86 computer responsiveness totally, while Amigas did not show any negative effect.
(actually, even today, USB still kills my i5 laptop responsiveness sometimes, nothing seem to run runs beside Win kernel...)
-
I found out what happened to BeOS it was later re-released as Zeta by magnussoft. Last release was in 2007.
-
As far as the Amiga task system works, it should. A higher priority task will always pre-empt a lower priority task. Thus, whenever your "real time" (something like that does not exist on the Amiga) application requires the CPU, and it has a higher priority than the background job, it gets the CPU. It's not quite as bad. The FFS has a higher priority, yes, but it does not do much. It just prepares a couple of buffer pointers and then gives control back to the hardware abstraction level aka "device".
Here, again the game is the same: If you have hardware that is smart enough, the device will only initiate a DMA, and hence give control back to the foreground job as long as the transfer is running. CPU time is not "burned" while waiting for the I/O.
This is only true when you are reading file sequentially. You can do "nasty" things like ExAll() some huge directory. Likewise using Examine()/ExNext() is "friendly". But again MatchFirst()/MatchNext() with the callback hook... even just Lock()ing a file is relatively expensive operation.
Big oops.
If you are have a sorry "PIO-only" host adapter, you have a problem, though, because somehow somewhere the CPU needs to take the time from to transport the data from the disk to the RAM. That, then, of course, can really steal important time and make your day, and the device has no knowledge about which I/O it should initiate first as the origin of the request is lost. But that's not really the fault of the AmigaOs, but rather of the hardware requiring full CPU attention for I/O. It does not happen for DMA-based host adapters.
But it does happen when you use RAM disk or DynamiCache since they dont use DMA. Just unpack large archive to RAM disk...
I dont see where "near real time OS" comes from when conditions are random. Works most of time but dont do this or that.
Even just OpenLibrary() is enough to let higher priority tasks to miss their deadline as OpenLibrary() can have very long Forbid().
-
I found out what happened to BeOS it was later re-released as Zeta by magnussoft. Last release was in 2007.
Remember its huge success? No? See, this is exactly what I think about attempts to create new operating systems.
-
This is only true when you are reading file sequentially. You can do "nasty" things like ExAll() some huge directory. Likewise using Examine()/ExNext() is "friendly". But again MatchFirst()/MatchNext() with the callback hook... even just Lock()ing a file is relatively expensive operation.
Yes. Or mostly. The FFS management functions are not threaded, but rather go back to the device. As long as the device requests blocks from the hardware, and as long as the hardware runs on DMA, your task gets the CPU. If the directories are buffered, then the FFS copies directly from its buffers. It does not make sense to preempt this operaion as the CPU is required for this anyhow. But it does happen when you use RAM disk or DynamiCache since they dont use DMA. Just unpack large archive to RAM disk...
Yes, certainly, but what else can a single CPU do? Either, you copy the data to the RAM, or you don't. But you need the CPU for that, so the time for that needs to come from somewhere. I dont see where "near real time OS" comes from when conditions are random. Works most of time but dont do this or that.
It's not a real time Os, not even close. I don't know who claimed that, but I didn't. For that, it would need to guarantee maximal reaction times for certain operations, which it certainly can't. A task can Forbid() at any time and thus lock out any other operation for an infinite amount of time, a big no-no for any real-time Os. Even just OpenLibrary() is enough to let higher priority tasks to miss their deadline as OpenLibrary() can have very long Forbid().
Well, OpenLibrary() does have a Forbid(), but not a long one. It rather uses the Forbid() to scan through the library lists. If it does not succeed there, then exec (or rather, ramlib) calls Permit() and creates a message to the ramlib task to load the library from disk. As soon as the message comes back, it tries again. The amount of blocking imposed by OpenLibrary() is thus not higher than that of any other disk-based operation. Besides, any disk based operation will break a Forbid() since it includes a Wait(), or at least two: one of the task waiting for the filing system, and one of the filing system waiting for the device.
-
@KimmoK
I used to have an old 486 with a tower of CD burners to provide software and other material to students. The CPU is not much of an issue here, it all boils down to I/O, and having DMA SCSI is a major plus compared the typically CPU hungry IDE.
-
BeOS exists today as the open source project Haiku, and they are progressing steadily, participate yearly in Google's Summer of Code (which also resulted in rudimentary IPv6 support 4-5 years ago). There is hardly any cause for "Be-littling" when wearing an Amiga hat. Haiku has all the stuff Amiga users moan about constantly, but it is a different user experience.
https://www.haiku-os.org/
-
Well, OpenLibrary() does have a Forbid(), but not a long one. It rather uses the Forbid() to scan through the library lists. If it does not succeed there, then exec (or rather, ramlib) calls Permit() and creates a message to the ramlib task to load the library from disk. As soon as the message comes back, it tries again. The amount of blocking imposed by OpenLibrary() is thus not higher than that of any other disk-based operation. Besides, any disk based operation will break a Forbid() since it includes a Wait(), or at least two: one of the task waiting for the filing system, and one of the filing system waiting for the device.
looks like a reason why one gets that annoying ramlib error eventually one doesnt even know where that does come from..
-
BeOS exists today as the open source project Haiku, and they are progressing steadily, participate yearly in Google's Summer of Code (which also resulted in rudimentary IPv6 support 4-5 years ago). There is hardly any cause for "Be-littling" when wearing an Amiga hat. Haiku has all the stuff Amiga users moan about constantly, but it is a different user experience.
https://www.haiku-os.org/
I'm not wearing any hat, and I'm not making any statement about the quality of their Os. I'm only observing that their user basis is "next to nothing". Look at the popularity of Linux, compared to other Os installations: That's probably a whopping 1%. The times where you could write your custom Os for custom hardware and make that a success story are over.
Thus, if you want to waste your time there, I've really no objections, why should I. But I've better plans with my life. (-:
-
Remember its huge success? No? See, this is exactly what I think about attempts to create new operating systems.
Microsoft did his (dirty) part to it not were a success
http://www.internetnews.com/ent-news/print.php/3073811/
-
Microsoft did his (dirty) part to it not were a success
http://www.internetnews.com/ent-news/print.php/3073811/
yawn...
-
Well, OpenLibrary() does have a Forbid(), but not a long one. It rather uses the Forbid() to scan through the library lists. If it does not succeed there, then exec (or rather, ramlib) calls Permit() and creates a message to the ramlib task to load the library from disk. As soon as the message comes back, it tries again. The amount of blocking imposed by OpenLibrary() is thus not higher than that of any other disk-based operation. Besides, any disk based operation will break a Forbid() since it includes a Wait(), or at least two: one of the task waiting for the filing system, and one of the filing system waiting for the device.
I was not thinking actual OpenLibrary() call but library init process (I was unclear). Some libraries precalculate data in libinit taking (relatively) long time to complete, especially on slower Amigas.
But this was just another example how unpredictable multitasking in Amiga is...
I know you know this stuff :-)
-
I'm not wearing any hat, and I'm not making any statement about the quality of their Os. I'm only observing that their user basis is "next to nothing". Look at the popularity of Linux, compared to other Os installations: That's probably a whopping 1%.
In this you ignore all Android devices, networking gear, HPC, cloud services, virtualization platforms, smart TVs, media centers etc etc and solely look at the dwindling market that is "desktop computers"?
The times where you could write your custom Os for custom hardware and make that a success story are over.
Thus, if you want to waste your time there, I've really no objections, why should I. But I've better plans with my life. (-:
I am happy many people feel differently, so that we actually have some progress in terms of technology and science in general. It's like, what kind of dumbass would make a game about silly birds being used as sling shot ammo, don't they know "tanks" already exists?!
-
I was not thinking actual OpenLibrary() call but library init process (I was unclear). Some libraries precalculate data in libinit taking (relatively) long time to complete, especially on slower Amigas.
But this was just another example how unpredictable multitasking in Amiga is...
I know you know this stuff :-)
Given that the init function is called from ramlib, and ramlib multitasks like every other task, it is not quite as bad as you think. Library initialization is not running under a Forbid() state. It's single-threaded because only a single thread cares about it, and that's ramlib.
-
@Thomas Richter
Oh. Maybe I remember wrong. Apparently I have to check my reference code when I get home. All these details are getting more and more vague every year...