@cdimauro

ppc is with us almost twenty five years.
So it is important.
arm never was used in Amiga.
So nobody care about buffy and/or pistorm.
main problem with AROS is ofcourse AROS developers and followers do not accept that
change to little endian cpu will break compatibility.
If they already break compatibility they should add memory protection to AROS.
Thats not happend.
So AROS ends as worse uae.
Nobody need crap like AROS that is not compatible with Amiga OS and has not memory protection.

cdimauro Quote:

I see two problems with the Amiga o.s.: it's not really (!) real-time, and the worst is that it's too much tailored to the Amiga hardware. BTW, even Commodore wanted to get rid of the Amiga hardware, for good reasons (too much obsolete). IMO AROS is what the Amiga o.s. should have been: multi-platform, and not bounded to the Amiga hardware.

Steve Shireman Quote:

Here I quote from the 1990 RKM (the blue one) in the chapter on Exec Tasks: "The Amiga Exec library provides a real-time message-based multi- tasking environment." Copyright 1990 by Commodore-Amiga (Addison- Wesley RKM Libraries and Devices book) Some models of Amiga have even been advertised in some of the new products' glossies as having a real-time OS. (maybe the CD32, I don't remember now) but I do not think that marketing has ever understood the concept. I also design real-time systems for my profession, and have studied the subject formally for many years. I use words differently than many people, but it is to try to overcome complacency in others. I seriously do not believe that very many people actually understand how technically advanced the Amiga really is, and how much it is worth. I doubt that there is anything I can say to convince you that the Amiga Exec is a real-time design. I understand that real-time means many things to many people, and that is part of the problem here. There are many applications written that do not take full advantage of the Amiga real-time Exec, but in one way or another, all applications take advantage of some aspect of it. The Amiga real-time Exec is probably the best overall design for real-time that is currently available. ... Well, I have heard Tim Jennison refer to the Amiga OS as Real time. The 1.3 RKM's (Exec chapter of Libraries) refer to it as a Real Time OS. I even refer to it as such when I am not on this list It was designed to solve the real-world problems involved in having a computer work with video and multimedia. Are there tougher problems for a computer to solve? Not too, many, but if you scratch your navel hard enough you might be able to come up with a few. I have several products out that use commercial RTOS's (USX, MTOS, etc) I can tell you that there is nothing in them that the Amiga does not have in its architecture. But the Amiga API has some nice features that these other commercial RTOS's do not have. The messaging system in Amiga is very nice. There is nothing available like Arexx in these other systems. Almost any embedded system architect would kill to have this functionality, and have it so small. (EmbeddedJava and Windows CE will NEVER get there from there) But [Amiga] Exec is a very well kept secret. ... Apologies to everyone for the discussion length. First, I was just correcting the incorrect definition of real time operating system that was being used. Andy. There is no one single definition for real-time (thus the Alice in Wonderland phenomenon will always exists, and helps to fire off these rants, since real-time means different things to different people). Of the 6 RTOS books laying about my office, no two are the same even in how they approach the difficult task to define what is meant by real-time, and I only saw one that used your 'correct' definition. Of course my favorite definition is the one from the RKM Exec chapter. Since the proper Real-time constraints have to be selected for each application, there will always be differences in professional opinions. Second, there are no current RTOS goals; the goals are still being formulated as I understand it. Well, then, I can hope that the granularity of the OS is reduced, and RTOS performance might improve. If I say things creatively enough, maybe I can get another section created on the ICOA web site like what happened with my my AMP rant How about ARTOS? Now that seems catchy to me. Third, while making the AmigaOS real time is possible, it would be necessary to have good solid reasons 'why' first. Jeff Porter understood why, as I discussed this with him at Orlando Devcon, as well as earlier Devcons, the subject of RTOS seemed well-understood by the Exec Gurus I discussed it with. (Bryce Nesbitt discussions, and a Mike Sinz conference) Jeff Porter knew even then that Microsoft was working toward the embedded market (with what I presume is now called WindowsCE), as the potential numbers of embedded real-time systems far exceeds the Desktop numbers, and at least that thought had infected some in the ranks of Commodore-Amiga engineering. I am very pleased that the licensing by Amiga Inc has opened up the possibility of very low cost hardware for the OS to run on. As long as Exec doesn't get botched up in the future I will be mildly happy. In fact, Exec could be made better, and less granular, as well as the rest of the system libraries. I pray often for this when I can't sleep. I have an internet appliance application that runs using the commercial package USX Multitask. (which is advertised as a RTOS). The product would be greatly enhanced to run on Exec, rather than Multitask. Does Multitask have any features or guarantees of operation that is better than AmigaOS? Absolutely not. It is much easier to violate real-time latency on this commercial RTOS than it is with AmigaOS. Andy, part of our difference in opinions is that I am speaking of Real RTOS's, and you are speaking of textbook RTOS's. The 'solutions' for Real-Time designers in the marketplace right now are poor to rotten (IMHO). This is another way to say, "Niche Market Opportunity" But I see it as an area where a single developer would have trouble without 'mothership' support. Forth, if you're going to choose goals, it helps a lot to know why you are choosing goals. How about greed? How about to expand some existing control, and also up and coming niche markets? PLC's and virtual PLC's (which I have been asked to design) have over a $10 billion market. I wouldn't mind a .000l % piece of that market. (a .1 MilliNiche) I see value in being able to label our OS with your "textbook" definition of real-time (and call it ARTOS=Amiga Real Time Operating System), that can undergo the scrutiny of the control industry/internet appliance markets, etc. It would be nice to have latency numbers (and quality numbers as well) to advertise that one could competitively compare with the numbers (we have it, so let's flaunt it!) that Microsoft is claiming with WindowsCE, and what EmbeddedJava will claim.

michael schulz Quote:

A context switch on AmigaOS is much quicker than in some larger operating systems. Here are some context switch speeds for different machines/operating systems (in microseconds): 26 uS for 25MHz Amiga A4000/040 AmigaOS 3.1 71 uS for 100MHz Pentium Linux 1.2.13 89 uS for 233MHz AlphaStation 255/233 Digital Unix 3.2 102 uS for 150MHz DEC 3000/300 OSF/1 2.0 106 uS for 66MHz Snake HP-UX 9.x 126 uS for 25MHz Amiga A2000/030 AmigaOS 2.1 128 uS for 40MHz Viking SunOS 4.1.3 131 uS for 167MHz SPARC Ultra-1 Solaris 2.5 210 uS for 33MHz 486 386BSD 0.1 212 uS for 50MHz RIOS AIX 3.2

https://kgsvr.net/andrew/amiga/amiga.diffnt.html

I can vouch for Steve Shireman. I have been to his house several times and we went to an Amiga show in St. Louis, Missouri. He designed embedded systems. One embedded project was Amiga 2000s with custom boards being used for milking cows. People don't see embedded systems which are hidden away kind of like the AmigaOS but unfortunately not together. Steve was making the same arguments I've been making but decades ago.

The AmigaOS was amazing for the time! It had one of the earliest microkernels, earliest preemptive multi-tasking and earliest use of dynamic libraries for a personal computer. AmigaOS was designed from inception to be so thin that it can't get much thinner.

Carl Sassenrath speaks at Amiga30.eu
https://www.youtube.com/watch?v=ZlPhPQxQKRc&t=766s

Amiga users and businesses don't understand the Amiga technology and history. Throw it all away and start over? Make it bloated and slow by adding desktop Linux features like a SLAB allocator and .so libraries? People who understand keep repeating the same things over and over and over again while the Amiga keeps failing over and over and over again. It's very frustrating and sad!

Last edited by matthey on 14-May-2021 at 11:36 AM.
Last edited by matthey on 14-May-2021 at 11:29 AM.

@eliyahu

Indeed that’s funny...

Still we are here reading the posts...

_________________
Sometimes we give people a lot of credit just because they’re writing nice sentences even if it isn’t adding up to much.

@matthey

MorphOS still do it the Amiga way at least for .library so in a sense it is a better AmigaOS than AmigaOS 4.1.

Last edited by kamelito on 14-May-2021 at 03:27 PM.

@kamelito

AmigaOS4.1 also does use .library, nobody is saying that we should replace .libraries, with anything else. “.so” shared objects were introduced to make easier to convert UNIX/LINUX stuff to AmigaOS, that’s way its there, and its is feature of ELF executable format.

Arguing way be better to not be able to hear, or see, or to walk, or not being able to pee, is silly, most people say it better to be able to do more.

I think your comment is clear yours vs mine, all you clamming here is that your is better because your fanboy.

Last edited by NutsAboutAmiga on 14-May-2021 at 04:25 PM.
Last edited by NutsAboutAmiga on 14-May-2021 at 04:24 PM.
Last edited by NutsAboutAmiga on 14-May-2021 at 04:23 PM.
Last edited by NutsAboutAmiga on 14-May-2021 at 04:19 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@matthey

The whole point of a real-time OS is to have deterministic scheduling - tasks are set to happen at specified times or not at all (“fail”) - you cannot have delayes due to random other tasks that “interrupt” for attention - like they do on AmigaOS.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@NutsAboutAmiga

The SDL libs are using .so under AmigaOS 4.1 .library under Morphos…

@kamelito

You can statically link SDL if like to as well, I do that.
I believe SDL was Linux thing long before it was Amiga thing.

While basilisk II & MPlayer support SDL, its mostly games using SDL, and its mostly is going to be one program/game loading SDL, so sharing code between 2 or 3 programs make little or no difference, it might actually add some overhead, if you need to make some kind of context structure to keep track of data that is unique to the programs using .library, as you don’t wont individual states of different programs to change state of data in library, .so files behave more like .a files, no context structure is needed, as its actually linked etch time into the program is started, so it becomes part of the program. Not actually having to make major changes to convert SDL to a AmigaOS format, means that its less work etch time it has to be updated to a newer version of SDL.

Last edited by NutsAboutAmiga on 14-May-2021 at 08:44 PM.
Last edited by NutsAboutAmiga on 14-May-2021 at 08:23 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

kamelitoQuote:

MorphOS still do it the Amiga way at least for .library so in a sense it is a better AmigaOS than AmigaOS 4.1.

Yes, in many ways MorphOS is more faithful to the original AmigaOS philosophy than AmigaOS 4. AmigaOS 4 adopted an inferior library standard which does not share code as well increasing the memory footprint and introducing the version problems of .so libraries. MorphOS went with a much better memory allocator as well using TLSF which greatly reduces memory fragmentation and improves performance of dynamic memory (de)allocation with minimal increase in memory usage.

https://www.morphos-team.net/tlsf

TLSFMem is efficient enough to use on all but the lowest memory 68k Amigas. The performance improvement on my 68060 is amazing even though the 68060 has a relatively slow BFFFO instruction taking 9-13 cycles which is used often by TLSFMem. The 68k BFFFO instruction is only 1-2 cycles in the Apollo core so it is possible to have greatly improved dynamic memory (de)allocation performance over what the original AmigaOS had and which should make the AmigaOS more appealing for embedded use. A good test program that uses *lots* of dynamic memory allocations is VBCC. I bet the MorphOS TLSF allocator would destroy the AmigaOS 4 SLAB allocator in both performance and memory used in any descently large compile. Anybody want to run that test on the same hardware? A stop watch should be good enough if there is as much difference as I expect there to be.

kolla Quote:

The whole point of a real-time OS is to have deterministic scheduling - tasks are set to happen at specified times or not at all (“fail”) - you cannot have delays due to random other tasks that “interrupt” for attention - like they do on AmigaOS.

Higher priority tasks and interrupts get control on the AmigaOS due to their priority. The AmigaOS has preemptive multitasking so "random other tasks" get interrupted by higher priority tasks and interrupts. The microkernel AmigaOS operates in user mode a very high percentage of the time so all but the most critical and tiniest AmigaOS code can be interrupted and that code relinquishes control quickly. It is possible to execute user tasks at insanely high priority and add interrupts at high enough priority to interfere with the normal function of the system but that is more a security issue rather than a real time problem.

Quote:

In a typical microcontroller, there is no inherent difference between real-time, safety-critical and user interface or user application code. The difference is determined by additional software – the Real-Time Operating System (RTOS). The RTOS manages when code is run, tasks are switched, what the relative priorities are and the entire associated overhead. The problem is that the system designer has little control over how the RTOS manages these tasks.

REMOVE THE RISC FROM YOUR EMBEDDED DESIGN
http://docplayer.net/45089874-Remove-the-risc-from-your-embedded-design-white-paper.html

Last edited by matthey on 14-May-2021 at 11:32 PM.
Last edited by matthey on 14-May-2021 at 11:28 PM.

@matthey

Quote:

Yes, in many ways MorphOS is more faithful to the original AmigaOS philosophy than AmigaOS 4. AmigaOS 4 adopted an inferior library standard which does not share code as well increasing the memory footprint and introducing the version problems of .so libraries.

This is not true. Whilst OS4 can use .so format libraries (with the problems you've noted), normal OS4 programs use .library files same as OS3. Most people use those or build static libraries, hardly anyone uses .so unless it is unavoidable - they cause more problems than they solve. Nice to have the extra flexibility though, and it enabled Qt to be ported.

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

Chris_Y Quote:

This is not true. Whilst OS4 can use .so format libraries (with the problems you've noted), normal OS4 programs use .library files same as OS3. Most people use those or build static libraries, hardly anyone uses .so unless it is unavoidable - they cause more problems than they solve. Nice to have the extra flexibility though, and it enabled Qt to be ported.

Perhaps "allows" would have been a better word to use than "adopted" for AmigaOS 4 introducing an optional but inferior .so library standard but "adopted" does not infer one standard or even a preferred standard. If lowering quality standards and introducing inferior technology is thought to be the best way to proliferate the Amiga then something is wrong. AmigaOS 4 isn't proliferating because the desktop hardware it runs on doesn't have a good price/performance ratio and the desktop features aren't competitive.

@matthey Quote:

matthey wrote: cdimauro Quote: I see two problems with the Amiga o.s.: it's not really (!) real-time, and the worst is that it's too much tailored to the Amiga hardware. BTW, even Commodore wanted to get rid of the Amiga hardware, for good reasons (too much obsolete). IMO AROS is what the Amiga o.s. should have been: multi-platform, and not bounded to the Amiga hardware. Steve Shireman Quote: Here I quote from the 1990 RKM (the blue one) in the chapter on Exec Tasks: [...] I doubt that there is anything I can say to convince you that the Amiga Exec is a real-time design. I understand that real-time means many things to many people, and that is part of the problem here. [...] Apologies to everyone for the discussion length. First, I was just correcting the incorrect definition of real time operating system that was being used. Andy. There is no one single definition for real-time (thus the Alice in Wonderland phenomenon will always exists, and helps to fire off these rants, since real-time means different things to different people). Of the 6 RTOS books laying about my office, no two are the same even in how they approach the difficult task to define what is meant by real-time, and I only saw one that used your 'correct' definition. Of course my favorite definition is the one from the RKM Exec chapter. Since the proper Real-time constraints have to be selected for each application, there will always be differences in professional opinions. [...] I have an internet appliance application that runs using the commercial package USX Multitask. (which is advertised as a RTOS). The product would be greatly enhanced to run on Exec, rather than Multitask. Does Multitask have any features or guarantees of operation that is better than AmigaOS? Absolutely not. It is much easier to violate real-time latency on this commercial RTOS than it is with AmigaOS. Andy, part of our difference in opinions is that I am speaking of Real RTOS's, and you are speaking of textbook RTOS's. [...]

Quoting from the link where those writings come from:
"Some said that to be officially realtime there had to be guaranteed response times,"
This is the common understanding when talking about real-time o.ses.

The primary problem with the Amiga o.s. is this:
"AmigaOS woudl not guarantee that because of e.g. Forbid()"
and Disable() too, of course.

michael schulz Quote:

A context switch on AmigaOS is much quicker than in some larger operating systems. Here are some context switch speeds for different machines/operating systems (in microseconds): 26 uS for 25MHz Amiga A4000/040 AmigaOS 3.1 71 uS for 100MHz Pentium Linux 1.2.13 89 uS for 233MHz AlphaStation 255/233 Digital Unix 3.2 102 uS for 150MHz DEC 3000/300 OSF/1 2.0 106 uS for 66MHz Snake HP-UX 9.x 126 uS for 25MHz Amiga A2000/030 AmigaOS 2.1 128 uS for 40MHz Viking SunOS 4.1.3 131 uS for 167MHz SPARC Ultra-1 Solaris 2.5 210 uS for 33MHz 486 386BSD 0.1 212 uS for 50MHz RIOS AIX 3.2

The problem with this is that, as it's reported, that you aren't measuring the o.s. context switch, but both o.s. & hardware context switch.

Quote:

https://kgsvr.net/andrew/amiga/amiga.diffnt.html I can vouch for Steve Shireman. I have been to his house several times and we went to an Amiga show in St. Louis, Missouri. He designed embedded systems. One embedded project was Amiga 2000s with custom boards being used for milking cows. People don't see embedded systems which are hidden away kind of like the AmigaOS but unfortunately not together. Steve was making the same arguments I've been making but decades ago. The AmigaOS was amazing for the time! It had one of the earliest microkernels, earliest preemptive multi-tasking and earliest use of dynamic libraries for a personal computer. AmigaOS was designed from inception to be so thin that it can't get much thinner. Carl Sassenrath speaks at Amiga30.eu https://www.youtube.com/watch?v=ZlPhPQxQKRc&t=766s

I've absolutely no problem with the amiga o.s. being used on embedded systems: I think that it's one of the best o.ses ever for this field (removing the Amiga chipset dependency).

The only concern is about real-time systems, as I've expressed above.

However real-time systems are a small part of embedded systems. Plus, if you can deal with Forbid()/Disable(), then I don't see problems using the Amiga o.s. for this as well.
Quote:

Amiga users and businesses don't understand the Amiga technology and history. Throw it all away and start over? Make it bloated and slow by adding desktop Linux features like a SLAB allocator and .so libraries? People who understand keep repeating the same things over and over and over again while the Amiga keeps failing over and over and over again. It's very frustrating and sad!

Indeed. But I think that the primary problems is due to the fact that most of the people are just users and not technical persone, so they don't understand those concepts: they just use the platform/products as they are.

@kolla Quote:

kolla wrote: @matthey The whole point of a real-time OS is to have deterministic scheduling - tasks are set to happen at specified times or not at all (“fail”) - you cannot have delayes due to random other tasks that “interrupt” for attention - like they do on AmigaOS.

This also depends on the hardware where it's running. As Matt reported, the FIDO microcontroller hasn't such problems.

@NutsAboutAmiga Quote:

NutsAboutAmiga wrote: @kamelito You can statically link SDL if like to as well, I do that. I believe SDL was Linux thing long before it was Amiga thing. While basilisk II & MPlayer support SDL, its mostly games using SDL, and its mostly is going to be one program/game loading SDL, so sharing code between 2 or 3 programs make little or no difference, it might actually add some overhead, if you need to make some kind of context structure to keep track of data that is unique to the programs using .library, as you don’t wont individual states of different programs to change state of data in library, .so files behave more like .a files, no context structure is needed, as its actually linked etch time into the program is started, so it becomes part of the program. Not actually having to make major changes to convert SDL to a AmigaOS format, means that its less work etch time it has to be updated to a newer version of SDL.

So, is SDL using .so or .library on OS4? This is the only thing which matters.

@Chris_Y Quote:

Chris_Y wrote: @matthey Quote: Yes, in many ways MorphOS is more faithful to the original AmigaOS philosophy than AmigaOS 4. AmigaOS 4 adopted an inferior library standard which does not share code as well increasing the memory footprint and introducing the version problems of .so libraries. This is not true. Whilst OS4 can use .so format libraries (with the problems you've noted), normal OS4 programs use .library files same as OS3. Most people use those or build static libraries, hardly anyone uses .so unless it is unavoidable - they cause more problems than they solve. Nice to have the extra flexibility though, and it enabled Qt to be ported.

Well, if you port the same libraries using .so when other Amiga o.s./-like platforms have them as standard .libraries, then who's more respectful of the Amiga o.s. philosophy?

@ppcamiga1 Quote:

ppcamiga1 wrote: @cdimauro ppc is with us almost twenty five years. So it is important.

For what? For whom?
Quote:

arm never was used in Amiga.

Only because nobody used it at the time, but I saw also Transputers and DSPs being used for Amigas well before that PowerPC accelerators arrived.
Quote:

So nobody care about buffy and/or pistorm.

It's clearly the opposite, according to what is found on EAB.
Quote:

main problem with AROS is ofcourse AROS developers and followers do not accept that change to little endian cpu will break compatibility.

Who are those who don't accept it? Link and quote please, because this is the first time that I'm reading it.
Quote:

If they already break compatibility they should add memory protection to AROS.

The two things aren't related.
Quote:

Thats not happend. So AROS ends as worse uae.

Only because you invent things for supporting your non-sense?
Quote:

Nobody need crap like AROS that is not compatible with Amiga OS

And where have you read this other non-sense?

AROS for 68K is binary-compatible with the Amiga o.s.. Win/UAE can even boot using AROS's ROM, instead of the regular Commodore ROM, and this is the default in WinUAE since very long time.

You clearly have no clue at all of what you're talking about.
Quote:

and has not memory protection.

Like... any other Amiga o.s. rewritings. So, what's your point here?

cdimauro Quote:

Quoting from the link where those writings come from: "Some said that to be officially realtime there had to be guaranteed response times," This is the common understanding when talking about real-time o.ses.

The use determines the required response times to be called real-time. Applying the term broadly to every use is a misnomer (poor usage) which is why the AmigaOS is sometimes called near real time. The AmigaOS is real time for those uses which it can maintain the required timing. Where was the Amiga real time?

wiki Quote:

Similarly, video games are often soft real-time, particularly as they try to meet a target frame rate. As the next image cannot be computed in advance, since it depends on inputs from the player, only a short time is available to perform all the computing needed to generate a frame of video before that frame must be displayed. If the deadline is missed, the game can continue at a lower frame rate; depending on the game, this may only affect its graphics (while the gameplay continues at normal speed), or the gameplay itself may be slowed down (which was common on older third- and fourth-generation consoles).

https://en.wikipedia.org/wiki/Real-time_computing

Tim Jenison Quote:

I have my own very personal reasons for why using that computer. That computer, by sort of bizarre sets of circumstances ended up being perfect for desktop video... The computer, as it ended up, had all this amazing video circuitry in it. It was exactly NTSC frequencies and it had a genlock input. And it had a real-time operating system ... The technical aspects did not change and they have not changed till this day. It is still the only computer that can scan an image using NTSC time... It is the only computer with a real-time operating system that is closing keyed in to video time... In short, you could not make a Video Toaster that would run on a Mac or on a Pentium. It would be impossible. The only way you can do it would be to have your own processor on board that would have a real-time operating system that was fast on switching on video clips.

https://kgsvr.net/andrew/amiga/amiga.diffnt.html

The Toaster use would even be considered hard or at least firm real time. It wasn't mission critical, the AmigaOS wasn't certified to any real time standards and the worst case response times were never measured but the Amiga got the real time job done for the founder of Newtek, Tim Jenison. Steve Shireman found the AmigaOS to be real time enough for most of his embedded projects too. The AmigaOS was as real time as many real time OSs.


cdimauro Quote:

The problem with this is that, as it's reported, that you aren't measuring the o.s. context switch, but both o.s. & hardware context switch.

Correct. The hardware and the OS together determine the system responsiveness and how real time a system can be. The 68k was known for having low interrupt latency although some ARM processors and the 68k FIDO are examples of using the hardware to improve responsiveness even further.

cdimauro Quote:

I've absolutely no problem with the amiga o.s. being used on embedded systems: I think that it's one of the best o.ses ever for this field (removing the Amiga chipset dependency). The only concern is about real-time systems, as I've expressed above. However real-time systems are a small part of embedded systems. Plus, if you can deal with Forbid()/Disable(), then I don't see problems using the Amiga o.s. for this as well.

You want to do away with the hardware dependency but I think retaining software compatibility is more important. Customizing the hardware for the AmigaOS may even have benefits for compatibility and responsiveness. Forbid/Permit and Disable/Enable macro count addresses may be able to be setup as dynamically addressed hardware registers. A count down timer could be added to make sure task switching or interrupts were not disabled for too long which should improve system robustness and help with debugging. The hardware may be able to more efficiently stop all cores with SMP although this is still inefficient. New OS support should be added which avoids the use of these functions and macros. I would like to hear from Carl Sassenrath what his plans were for adding multi-core support to the Amiga. Carl's next job after the Amiga was with Apple who hired him to create an OS like the AmigaOS but with multi-core support so he has probably thought about it. I would love to hear Carl Sassenrath and Dave Alsup (Fido system architect) discuss hardware enhancing features for a microkernel design like the AmigaOS. Most hardware is created to support a monolithic kernel and all the inefficiencies of Linux.

Hmm looks like Hyperion just Put out another not so 'mini' update but this time for AmigaOS 68k

Last edited by klx300r on 15-May-2021 at 05:32 AM.

_________________
____________________________
c64-2sids, A1000, A1200T-060@50(finally working!),A4000-CSMKIII
! My Master Miggies- Amiga 1000 & AmigaOne X1000 !
mancave-ramblings
X1000 I BELIEVE

@ppcamiga1

Absolute garbage.
AROS users and especially developers are absolutely aware of the concept of byte ordering. Why on Earth would there be a bare metal 68k emulator for ARM for use with AROS being written otherwise?
Rewriting a compatible OS needs to take these things i to consideration as well, so again, very aware. More aware than someone like yourself by a wiiiide margin.
The simple fact is people using le arches simply don't care about OS level binary compatibility. Theyre happy with UAE, standard or integration and API compatibility.
And those that do will use a version of AROS that *does* have binary compatibility.
You may not like it, but believe it or not AROS isn't being written to adhere to your likes.

As for no-one caring about things like buffee or pistorm,... err, narcissistic much?
A person only has to read anything amiga related to see that's absolutely not true.
Sooo freaking weird of you to even make the suggestion.

Last edited by fishy_fis on 15-May-2021 at 06:11 AM.
Last edited by fishy_fis on 15-May-2021 at 06:11 AM.

@matthey Quote:

matthey wrote: cdimauro Quote: Quoting from the link where those writings come from: "Some said that to be officially realtime there had to be guaranteed response times," This is the common understanding when talking about real-time o.ses. The use determines the required response times to be called real-time. Applying the term broadly to every use is a misnomer (poor usage) which is why the AmigaOS is sometimes called near real time. The AmigaOS is real time for those uses which it can maintain the required timing. Where was the Amiga real time?

If you restrict the usage then it can obviously fit. And I had no problem with that.
Quote:

Tim Jenison Quote: I have my own very personal reasons for why using that computer. That computer, by sort of bizarre sets of circumstances ended up being perfect for desktop video... The computer, as it ended up, had all this amazing video circuitry in it. It was exactly NTSC frequencies and it had a genlock input. And it had a real-time operating system ... The technical aspects did not change and they have not changed till this day. It is still the only computer that can scan an image using NTSC time... It is the only computer with a real-time operating system that is closing keyed in to video time... In short, you could not make a Video Toaster that would run on a Mac or on a Pentium. It would be impossible. The only way you can do it would be to have your own processor on board that would have a real-time operating system that was fast on switching on video clips. https://kgsvr.net/andrew/amiga/amiga.diffnt.html The Toaster use would even be considered hard or at least firm real time. It wasn't mission critical, the AmigaOS wasn't certified to any real time standards and the worst case response times were never measured but the Amiga got the real time job done for the founder of Newtek, Tim Jenison. Steve Shireman found the AmigaOS to be real time enough for most of his embedded projects too. The AmigaOS was as real time as many real time OSs.

Hum. I think that here Mr. Jenison was mixing two things.
The VideoToaster was possible because the Amiga had a system clock which was synched with TV standards (also PAL in Europe, and SECAM in France), so implementing a genlock was a perfect fit.

However this doesn't tell anything concrete about the Amiga o.s. capabilities as real-time o.s.. I mean: I don't see how the Amiga hardware allows the Amiga o.s. to be entitled as "real-time".

Those are just declarations to me, but not proofs: no facts supporting the statements.
Quote:

cdimauro Quote: I've absolutely no problem with the amiga o.s. being used on embedded systems: I think that it's one of the best o.ses ever for this field (removing the Amiga chipset dependency). The only concern is about real-time systems, as I've expressed above. However real-time systems are a small part of embedded systems. Plus, if you can deal with Forbid()/Disable(), then I don't see problems using the Amiga o.s. for this as well. You want to do away with the hardware dependency but I think retaining software compatibility is more important. Customizing the hardware for the AmigaOS may even have benefits for compatibility and responsiveness.

I think that we're mixing different things here as well.

As I've already said, I've no problem stating that the Amiga o.s. was/is a very good candidate for being used for embedded markets.

However in such market hardware and/or software compatibility isn't very important.

Specifically, the Amiga hardware can be an handicap, because this forces the Amiga o.s. to be bounded to this hardware, whereas on an embedded system you may not need this hardware (I/O is much more important; and CIAs aren't strictly bounded to the Amiga hardware). What I want to say is that you don't need to have any display logic, the Copper, the Blitter, the audio channels, etc. etc. Embedded needs are... custom, but from another perspective.
Quote:

Forbid/Permit and Disable/Enable macro count addresses may be able to be setup as dynamically addressed hardware registers. A count down timer could be added to make sure task switching or interrupts were not disabled for too long which should improve system robustness and help with debugging. The hardware may be able to more efficiently stop all cores with SMP although this is still inefficient. New OS support should be added which avoids the use of these functions and macros.

Those look kluges to me, applied to solve a very bad design problem.

Synchronization should use different tools/(hardware)primitives.
Quote:

I would like to hear from Carl Sassenrath what his plans were for adding multi-core support to the Amiga. Carl's next job after the Amiga was with Apple who hired him to create an OS like the AmigaOS but with multi-core support so he has probably thought about it.

I hope that he wasn't involved on the Aquarius project:
http://tenfourfox.blogspot.com/2019/12/and-now-for-something-completely_29.html
https://archive.org/details/scorpius_architecture/mode/2up

Quote:

I would love to hear Carl Sassenrath and Dave Alsup (Fido system architect)

Is he Mitch's brother?
Quote:

discuss hardware enhancing features for a microkernel design like the AmigaOS. Most hardware is created to support a monolithic kernel and all the inefficiencies of Linux.

Well, that was my idea: something LIKE the Amiga o.s.. Largely API compatible, with the design mistakes fixed/removed, Amiga hardware removed, and some enhancement for things like SMP/AMP.

So, a more general o.s. for the embedded market, which takes the best from our beloved one.

Why do I feel I've gone back in time to the RED VS BLUE Wars!!

_________________
AmigaNG, YouTube, LeaveReality Studio

@amigang

It’s not Blue vs Red, its Black & Blue vs Red.

Because the war never ended, but has been one-sided for a very long time, with bashing of Hyperion, and Power PC, and way not do this or that, they can’t de done, has answered many times, its all on repeat.

I guess they blame MorphOS and AROS failure to push Window and Linux out of the marked on Hyperion. Its not wherry logical, but they are like football hooligans.

Last edited by NutsAboutAmiga on 15-May-2021 at 12:41 PM.
Last edited by NutsAboutAmiga on 15-May-2021 at 12:38 PM.
Last edited by NutsAboutAmiga on 15-May-2021 at 12:37 PM.
Last edited by NutsAboutAmiga on 15-May-2021 at 12:36 PM.
Last edited by NutsAboutAmiga on 15-May-2021 at 12:36 PM.
Last edited by NutsAboutAmiga on 15-May-2021 at 12:30 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@amigang

What colour are you if your Amiga flavour is a Raspberry Pi 400 running Amikit? 😉

_________________
Amigaone X5000/20 4GB Radeon RX 550 Polaris 12 AmigaOS4.1 Final Edition Update 1
Amiga 1200 Workbench 3.1.4
Amiga CD32