@KimmoK

Quote:

KimmoK wrote: To People with x1000: is X1000 caliber PPC computer too slow for firefox & web on Linux?

No. Not at all.

Comparing X1000 to my x86 dual celeron 2.4GHz both running Linux Mint;

PPC cranks up mozilla about 2sec faster.
PPC loads my ISPs homepage (filled with all kinds of crap) about 3sec faster.
x86 starts you tube vids about 4sec faster.

So PPC running 6MHz slower does the job sometimes faster, sometimes slower.
Maybe the PPC works faster because the network is Big Endian. (?)
Don't know, don't care.

Anyway, they are comparable, and the x86 is about a year newer.

_________________
Tinkering with computers.

@cdimauro

good for its time and purposes...

but you just overwrote what he also wrote... no software left except that of the OS developers

@OlafS25

Quote:

OlafS25 wrote: @cdimauro good for its time and purposes...

But the design wasn't good. Any Amiga coder with enough experience and knowledge of o.ses should be aware of it. And it's not rocket science: that's academical stuff that anyone can find in (o.ses) literature.

Unless if an enlighted new o.ses guru wants to rewrite it, of course. But in such case I can't wait reading his revolutionary theory.
Quote:

but you just overwrote what he also wrote... no software left except that of the OS developers

I have overwritten nothing, because they were two different arguments. One was the o.s. design, and that's what I've talked about.

The other was: what happens after fixing all that stupid (I borrow the same used by the MorphOS developer) design decisions, and introducing the listed modern features? Of course it requires changes in the existing software. The amount of changes depends strictly by every single application.

@cdimauro

Genuine question: what are/were, in you opinion, the major flaws (barring memory protection, that I'm aware of) of AmigaOS, from its conceiving in the early 80's until the demise of Commodore?

(I'm explicitly ignoring post-Commodore developments because they clearly lacked serious funding... unfortunately)

@Turrican3: memory protection wasn't available with a simple 68000, but the o.s. could have been organized in a different way in order to make use of it when running on a capable processor (e.g.: MMU available -> memory protection enabled).

The major flows of the Amiga o.s. IMO are the following:
- public access to o.s. structures. ExecBase, GfxBase, etc. publicly expose sensible data which can be read and written too by any application. You should had, instead, a set of APIs to query for some information and ask for changes, in an "opaque" (see below) and controlled way;
- o.s. APIs directly exposes sensible information about internal structures, and even report pointers to them (for example, and OpenScreen gives a pointer to the Screen structure used by the o.s.!). Two solutions were possible in this case, which aren't mutually exclusive (the o.s. can use one, according to the specific case). First one is that, when the o.s. needs to give back some information to the application, it can create a proper copy of it, returning only SOME data which are useful for the caller, and packed in a proper format (read: the o.s. can return one data structure for a 32-bit app, and another one for a 64-bit app). The second one is to return an "handle" to the caller, which completely hides all structure's data; the caller then can use proper getter and setter APIs to query and ask for changes. An hybrid approach can be used, of course: a data structure can be returned by the o.s., only with some data, and putting handles in some fields to hide some information; a set of getter and setter APIs are exposed for querying opaque data (through the given handles), and asking for changes;
- no resource tracking. When an application is closed, all allocated resources should be freed. A special case is below;
- a single address space for both o.s. and applications. An application can directly share any data with any other app. The solution here is to provide a separated address space (when the processor allows it, of course), and when an app wants to share some memory with a set of apps or globally, proper APIs should be provided to "map" and control such memory. On a 68000 those operations are "void", of course;
- apps can disable the multitasking and even interrupts! No such kind of APIs should be allowed, unless for kernel-space code (which means also drivers). Controlling interrupts is also an hardware-specific part of the o.s.; that why it should be absolutely bounded in kernel-space;
- apps can take control of interrupts (or be "chained" to be served when an interrupt happens). As above, this should be allowed only in kernel-space, since it's also an hardware-specific part;
- apps can control o.s. signals. They should get and set only their signals. o.s. signals are... o.s. business!

That's what I recall now, but there might be some other stuff.

There are some minor things, but they are related to some stupid decisions made by the o.s. writers. AllocEntry is the first example. Another one is the misalignment of data structures. And so on...

@cdimauro

Kickstart 2.0 was also a step to wrong direction when it added many callback hooks where application code was called from the OS context.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@cdimauro

Thanks for the extremely detailed reply.

As an end user I *really* loved AmigaOS and its neat, clear (well, at least on the surface) structure... but at that time I knew nothing about C so I never really dug into programming. Not at that relatively low level anyway.

It's always been very fascinating to me though, and even if its time has looong passed, now that I'm slightly more proficient in C I wouldn't mind messing around a bit, somehow someday...

Last edited by Turrican3 on 21-Aug-2015 at 08:35 AM.
Last edited by Turrican3 on 21-Aug-2015 at 08:35 AM.

@cdimauro

>Amiga o.s. was good by design

You must compare to other offerings of the time (1985), especially against the mainstream, (that was MS-DOS untill 1992..1998)?

Last edited by KimmoK on 21-Aug-2015 at 10:18 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@cdimauro

Yes but even if I bore you

A OS is not a design studie or proof of concept but a base for software. What if software is not adapted to it or adaption is not possible because devs left and sources not available? You will have a nice clean modern but otherwise useless OS because of no 3rd party support. Do not forget that it is a hobby market, the few devs left do it for fun in spare time. So when you want to really make a modern OS including memory protection you must make heavy changes in the structure, the result will be "amiga-like" but other than that very different. As geit wrote all 3rd party except what the OS devs offer will stop running, in case of MorphOS there will be OWB at least, in case of AmigaOS not even that.

Last edited by OlafS25 on 21-Aug-2015 at 09:32 AM.

@cdimauro

AmigaOS design was very good for its time, there are of course good and bad things for all operating systems, it is too easy to judge with today eyes.

Given the hardware constraints, the designers did an excellent work, resulting in several forced choices and compromises just for one thing: speed.

AOS is designed to be speedy on limited hardware and resources.

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Turrican3

Quote:

I'm explicitly ignoring post-Commodore developments because they clearly lacked serious funding... unfortunately

A myth seems to reoccur that only the post-Commodore developments were misguided, whereas under Commodore the Amiga operating system was in good hands of wise men. The fact is that even during the Commodore years some ideas were born failures, and development plans were changed as people came and went, so sometimes perspectives were lost.

To give an example, take Intuition. The original (1.x) implementation by RJ Mical was essentially a disaster: a badly-designed API with apparently no notion of safety, comfort and future expandability. For sure Commodore did realize they needed to design a better API to remedy the shortcomings. But the fact that in 2.x they actually introduced TWO fundamentally different, mutually incompatible APIs (GadTools and BOOPSI) to do the same thing (i.e. design a GUI) indicates that at that particular point Intuition development lost a sense of direction. The subsequent mess lasted for decades, and still confuses new programmers when they get to reading documentation.

So it's not that all was bright and sunny with Commodore, even with serious funding.

Last edited by Trixie on 21-Aug-2015 at 09:55 AM.

_________________
The Rear Window blog

AmigaOne X5000/020 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

@Trixie
yeah, none says it was all perfect, but as usual, talking genuine amiga bad doesnt make os4 look any better..

@cdimauro

>>Custom x86 face same realities as custom PPC + more compettion perhaps.
>Competition? With Intel which as 90% of the x86 market?

Yes.

Custom PPC motherboard does not have competition in PPC space.
Custom x86 borad compete with other x86 boards. (perhaps)

>What kind of custom stuff do you talk about?

Motherboard with selected componets, produced when needed, as long as needed.

>Sure, but actually if I buy an x86 CPU I have everything which I need, included a GPU (even good one with the high-end models). In fact, my PC case is empty, except for the memory and SATA which I've attached.

I find windows disgusting. That's why I've used Linux on my x86 at home.
My motherboard had built in RadeonHD3000, it did not work properly with linux, no way to avoid mouse stuttering, had to buy NVidia card.
+Desktop 3D games require more than embedded GPUs of x86.

>>>And draw less power.
>>NOT TRUE.
>Never eared of BayTrail, Core-M? Not counting the latest low-power Xeons.

They are in same ballpark with PPC.

>>>And have way better support...
>>NOT TRUE.
>Are you kidding? Even if you need to work on PowerPCs, usually SDKs are based on PC (using Windows or Linux).

You are mixing up things.

Sure, Amigas have always been designed mainly on other computers.

Not related to the matter/topic in any way.


>And, of course, there are ZILLIONS of software for the PC.

And they suddenly run in AmigaOS if Amiga HW has x86 CPU?


>>>Take a complex web page, like Facebook, GMail, etc., and take a look at how your system performs.
>>I need the SW first. (+ JIT for JAVA)
>>Currently 667Mhz (PPC440) seems to do most of the web usage.
>>600Mhz + JIT (ARM) does it even better.
>Try Facebook and GMail, please. Then we can talk again...

Use them daily (not on Amiga)
To my understanding, both take advantage of JIT on x86/ARM, unavailable SW on AOS.

My point was. Most of the web browsing works on 600Mhz, especially with Android (JAVA JIT etc), but not all.

(At the same time some web pages are not fast even on quad core 4Ghz.)

>>For example in EUR200 motherboard+CPU BOM, PPC CPU is around 30%.
>What kind of PowerPC CPU?

For example Freescale T10xx.
[UPDATE] There exist cheaper PPCs (from EUR20 or so), but this T10xx has good enough performance & feature set. [/UPDATE]

>Can you report a complete BOM for your PowerPC solution?

Nope.
Take any motherboard BOM and slap in the SoC (+-GPU).

From what I have seen, price is not the advantage of x86 vs PPC when building a SBC or motherboard with a CPU.

RAW performance is.

IMO:
-we need 4000...6000MIPS per core for LOW END to be useable in generic computing needs
-multicore is mandatory above LOW END (but we do not have AmigalikeOS + SW for that yet)


I've read/learned it's far simpler to build a computer motherboard around PPC(or ARM) than around x86/x64.
(documentation and SoC component availablity has been better, etc, but my surroundings have been mainly designing products around PPC and MIPS, only recently around x64)

Last edited by KimmoK on 21-Aug-2015 at 10:14 AM.
Last edited by KimmoK on 21-Aug-2015 at 10:13 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@Trixie

it is not important if design was bad or not or who has caused it. It is what we have. If there would be still a big market including commercial companies a drastic change might have been possible because of enough 3rd party support, today it will split the platform that does it and many programs will no longer work.

@cdimauro

I made summary of your post (#45):

Mainstream 1985 -no multitasking

AmigaOS 1985 -apps can disable the multitasking

So, the Amiga OS is bad by design.


I disagree.
I say Amiga OS design was superior.

AmigaOS DESIGN was more than 10 years ahead of mainstream, enabling a lot of new things vs the mainstream competition.

AmigaOS design just was not perfect.

Later other people invented OS designs that are many ways better than AmigaOS design from 1985.
(none being perfect and some poorly implemented, but anyway)

Last edited by KimmoK on 21-Aug-2015 at 10:43 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

+

Stretching the old design to modern standards may be possible but too expensive?

So, now we may need updated Amiga OS design. Then a new implementation.

Last edited by KimmoK on 21-Aug-2015 at 10:49 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@KimmoK

it might be possible to modernize the OS when dropping compatibility and in fact creating a new "amiga inspired" API

But again... what software will run on it? Who will develop for it?

@Signal

Thank you for the short web speed info.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@Trixie

Quote:

So it's not that all was bright and sunny with Commodore, even with serious funding.

Absolutely, and please understand by no means I was implying that CBM's handling of the Amiga was perfect, and what came after was 100% a disaster.

But IMHO the potential was somewhat there, because at least we had a decent amount of talented people and money.

Now, it's gone... unless a true miracle happens (read: an investor comes with TONS of money), and even then, there are so many competitors that I don't know how would it be trying to start discussing a business plan to address an actual, profitable target able to sustain the platform in the medium-to-long term.

@OlafS25

>what software will run on it?

All stuff that runs via UAE/JanusUAE/WinUAE kind solution.
The rest (MorphOS apps + AROS x86 native apps) perhaps would not run.

>Who will develop for it?

Same (grazy?) people who now develop for AOS4 + Morph etc. half NG systems?

(perhaps a few more if:
-there exist modern features to use...
-multicores to enable more processing power
-memory to not to need to spend too much time in optimizations
-memory protection to more easily catch your own bugs
-memory protection to enable testing on development machine without crashing the "production system" )

Those who want to develop purely to AOS3.1 API can continue doing so, their apps might run via UAE.

Last edited by KimmoK on 21-Aug-2015 at 11:30 AM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?