some fancy ideas for a extended (68k?) CISC-CPU

[Thomas Richter]

Originally Posted by malko

This is a nonsense as what you call a "correct model in principle" requires a huge amount of hardware resources to do a simple task as printing a text on the screen.

Which huge resources? Do you know how many resources are needed for that, and why that is "too much"?

Originally Posted by malko

Where is the flexibility when you have to install .net and directX to gain access to your Gfx card preferences (not to mention the Gb of hard disk space required for such "drivers" and dependencies) ?

Where is the problem installing it? I don't think it needs "GBs", but even if it would, where is the problem today? The flexibility is that you can pick the vendor, and the vendor can update the hardware without changing the software that runs on the system.


That is certainly a problem on the Amiga side with its Os so tightly coupled to the hardware. You cannot "upgrade" the custom chips, for example, without changing things in the graphics.library, which is in ROM, which you cannot easily upgrade as a user.

Originally Posted by malko

Regarding the way you consider an OS as "modern", I am asking to myself now if the "bug" correction made for AmigaOS 3.1.4 & upcoming 3.2 are really going the good way ?...

Why are there quotes around "bug corrections"? Which changes weren't? How many bugs were fixed compared to that? 3.1.4 came on a small number of disks. And what would you have done differently?

Originally Posted by malko

and maybe better understand why you are so strongly trying to discourage everyone trying to improve things differently.

How do you want to improve things, then? I mean, instead of complaining, which is the usual way of handling things the "Amiga way?" 3.1.4 was a very moderate update in terms of features, and it fixed a relatively large set of issues.

[Bruce Abbott]

Originally Posted by Thomas Richter

That is certainly a problem on the Amiga side with its Os so tightly coupled to the hardware. You cannot "upgrade" the custom chips, for example, without changing things in the graphics.library, which is in ROM, which you cannot easily upgrade as a user.

One man's meat is another man's poison.

Imagine you are Commodore and you want to make the Amiga flexible enough to take any graphics card with unknown capabilities, like the PC. So you put slots in it and just add a monochrome text adapter with dedicated monitor because hey, serious users don't want fancy graphics right? But if they did then 3rd party manufacturers would supply their needs, and any drivers or OS support can come on disk, saving you a bundle in development costs.

But what about non-serious users? They want to play games and use their TV instead of a monitor to save costs (the same reason you put a cassette tape interface and BASIC ROM in the base machine). So you release another card that does a mere 4 colors in 320x200 with nothing fancy (just the ticket for games, right?) sit back and watch the money roll in.

Except it doesn't. Now you realize that people actually do want fancy graphics, but they also want compatibility with existing software. So you make a card that can do a whole 16 colors out of 64 as well as the original TV and text resolutions - which 'oops' means you now need another dedicated monitor.

But 3rd time's the charm - you create a new high performance bus that can easily support much higher resolution graphics and lots of colors. So you pull out all the stops and design a video card that not only emulates all the earlier ones, but does 256 colors in 320x200 with chunky pixels! That's sure to hit the spot, despite needing yet another dedicated monitor that won't work with any of the previous cards. Finally you have a winning combination that will last into the next century and beyond!

Meanwhile, C64's are flying out the door even though they have dedicated chips that can't be 'upgraded', and you can't figure out why. Surely nobody would want to buy a system with exactly the same graphics as last year's model? It doesn't make sense, and yet for some strange reason people love them. Perhaps you should have duplicated that sales model with a new computer so amazing that it created another enduring standard worth upgrading to?

Nah, that would never fly with the 'serious' crowd. Best to go down the same path IBM did with their micro-channel architecture - that's how you ensure a bright future for your company. Commodore forever!

The thing is, some of us actually prefer to stick with a technology we have gotten to know and appreciate, rather than dumping it every time something slightly better appears. We enjoy trying to get more out of it, especially when we can see that it hasn't reached its full potential yet, and enjoy working with stuff that's not the latest thing but may be new to us.

How do you want to improve things, then? I mean, instead of complaining, which is the usual way of handling things the "Amiga way?" 3.1.4 was a very moderate update in terms of features, and it fixed a relatively large set of issues.

Don't get upset about it, just soak up the nostalgia and remember it's not serious. We all appreciate what you guys have done with OS3.1.4, and hope 3.2 will be even better.

As you say, Amiga OS will never be a 'modern' operating system, so there is no point trying to make it into one. But with your help we can make it into a better OS for existing Amigas, and perhaps even for 'new' computers based on the original Amiga architecture. Only for fun of course - nobody would be irresponsible enough to use an Amiga for 'serious' purposes.

[Thomas Richter]

Originally Posted by Bruce Abbott

Imagine you are Commodore and you want to make the Amiga flexible enough to take any graphics card with unknown capabilities, like the PC. So you put slots in it and just add a monochrome text adapter with dedicated monitor because hey, serious users don't want fancy graphics right? But if they did then 3rd party manufacturers would supply their needs, and any drivers or OS support can come on disk, saving you a bundle in development costs.

How to answer that? CBM did not develop the Amiga. It rather fell into their hands by pure luck (or pure greed of Atari, if you want to put it differently). So the above does not quite apply. As a result, CBM management really haven't had much of an idea what to make of the machine. The PC was designed by a single team, as a budget competitor to the Apple II, as cheap as possible.


CBM haven't had the vision to use the system as the basis of a business machine, they didn't even know how this market worked. It would have required a different Os and a different abstraction.


If you look a bit over the fence, MacOs had a quite fine graphics system, entirely CPU driven of course, but abstracted in a way that allowed graphics cards. There were no "bitplanes" at all, no "blitter primitives", no "minterms", but pixels and drawing primitives, along with an abstract language (the "PICT" resource) that described vector graphics.


Of course, Apple invested more money into the software than CBM did, and problaby more money than CBM had, but CBM had a ready-to-use system, and from day one, started just to exploit them, without investing much into it.

Originally Posted by Bruce Abbott

Meanwhile, C64's are flying out the door even though they have dedicated chips that can't be 'upgraded', and you can't figure out why.

That was, however, already a declining market at that time, and it was quite obvious already close to the end of the home computer market. The computer industry, at the age of Amiga, started to work differently than it did before, and CBM did not realize that.


Before, the market was: "Sell great hardware, let the users care about software". But that stopped working, and management didn't notice. Instead, CBM tried to compete with rather lousy software (what was the name? TextCraft? GraphicsCraft?) hoping to get a foot into the door. Didn't work. "You never get fired by buying IBM." That kind of stupid thing worked, for IBM. The only vision there was at CBM: "Hey, the C64 had a great chipset, here we have another better chipset, so it must sell".


Initially, that worked to some degree, but there was no future in this business.

Originally Posted by Bruce Abbott

The thing is, some of us actually prefer to stick with a technology we have gotten to know and appreciate, rather than dumping it every time something slightly better appears. We enjoy trying to get more out of it, especially when we can see that it hasn't reached its full potential yet, and enjoy working with stuff that's not the latest thing but may be new to us.

There is no problem tinkering with old hardware. Really. I share the hobby, but it's that: A hobby. I don't claim that the machine is great by today's values, or comptetative by any means. It isn't. It remains what it was: A home computer, a toy. That's not meant in a negative sense, but in an application sense.

Originally Posted by Bruce Abbott

As you say, Amiga OS will never be a 'modern' operating system, so there is no point trying to make it into one. But with your help we can make it into a better OS for existing Amigas, and perhaps even for 'new' computers based on the original Amiga architecture. Only for fun of course - nobody would be irresponsible enough to use an Amiga for 'serious' purposes.

Precisely, and there was not an attempt to revolutionize anything, it really shouldn't. It is far too late for that by multiple decades. In fact, I do not quite see the point in changing things at the AmigaOs side because that would counteract the purpose of the machine. The only chance is to remove here and there some annoyances. (Which is also why I don't quite understand AROS, but that's another discussion).



Which is also why I don't understand the purpose of the thread. Whatever people cook up, it wouldn't close the bridge to a modern PC, but even then, it *shouldn't*. The system is designed to what it is (or was), and adding "some modern CPU" makes it less an Amiga, and not more an Amiga, or a "better Amiga". It at best becomes another niche system that is related to the Amiga, but I don't need that. If I would need a better computer, I wouldn't start from AmigaOs and the Amiga chipset - nowadays.

[Thorham]

Originally Posted by Thomas Richter

It remains what it was: A home computer, a toy.

Sure, all those big box Amigas were toys

[meynaf]

Originally Posted by Thorham

Sure, all those big box Amigas were toys

And NASA used toys for so many years...

[Thomas Richter]

Originally Posted by Thorham

Sure, all those big box Amigas were toys

Yes, unfortunately. CBM never got into the application market, and they never offered the services this market required. Had these machines been used productively? Rarely so. Had they been used in offices? Rarely so. There were a couple of niche applications (TV studios, I already said that) where they played their strength, but that's it.


The big market (for CBM) were the console/keyboard machines. Sold much more of them.

[Thorham]

Originally Posted by Thomas Richter

Yes, unfortunately.

[Gorf]

Originally Posted by Thomas Richter

CBM haven't had the vision to use the system as the basis of a business machine, they didn't even know how this market worked. It would have required a different Os and a different abstraction.

How so?
In an other post you mentioned, that MS-DOS was not an operating system at all! So it was not until 1990 PCs got an operating system ...
Yet the PC was more successful in the 80s.

It was surely not the AmigaOS (or its limitations) that was hindering the Amiga, but Commodores failed marketing and near bankruptcy in 85

If you look a bit over the fence, MacOs had a quite fine graphics system, entirely CPU driven of course, but abstracted in a way that allowed graphics cards.

We are talking at this point about a machine with 128kB RAM and 64kB ROM.
No CLI, no color, no multitasking at all (with exception for the desktop calculator) - not even halting task and switching ... all that came later.
No hard drive, a tiny screen and of course not even the possibility to use a graphics card, since there was no bus - not even a simple expansion slot.

It was so unsuccessful in the beginning, that Steve Jobs had to leave his own company ...

There were no "bitplanes" at all,

Well of course there was a bitplane - exactly one

no "blitter primitives", no "minterms", but pixels and drawing primitives, along with an abstract language (the "PICT" resource) that described vector graphics.

Interestingly enough "PICT" does exactly what I proposed in this thread in the very beginning as a CPU feature (byte-code and repeat-feature):

The PICT file format consists essentially of serialized QuickDraw opcodes. The original version, PICT 1, was designed to be as compact as possible while describing vector graphics. To this end, it featured single byte opcodes, many of which embodied operations such as "do the previous operation again".

But in Amiga terms PICT is more or less the same as a Copper-List with Blitter instructions.

But actually we are talking about limitations here - here is nothing within AmigaOS that would prevent such a feature - and so someone did implement it:

http://aminet.net/package/util/dtype/MacPict2-dtc

Apple PICT Datatype

Of course, Apple invested more money into the software than CBM did, and problaby more money than CBM had,

Very true - but that is not the fault of AmigaOS or the system itself ...

but CBM had a ready-to-use system, and from day one, started just to exploit them, without investing much into it.

No - Amiga was no where ready in summer 1984 - and actually CBM did invest a lot of money in the first months. After paying over $50 million for a bunch of custom chips and some graphical demos, the real work only just began.
That is the reason we ended up with the Metacompco TripOS: Commodore needed something working and they needed it fast ...

The problem was, that after Jack was gone everything startet to crumble and the Plus4 an C16 where dead in the water, the C64 sales going down - so CBM was out of money a year later

The only thing that saved CBM in 1985 was Bill Herd's Frankenstein Monster - the C128.

(But C128 sales did compete with the Amiga later on .. but since the Amiga was not ready in the first halve of 85 CBM had no choice.)

Before, the market was: "Sell great hardware, let the users care about software". But that stopped working, and management didn't notice.

It still worked for the C128 in 85 and even for the AppleII GS in 86 ...
The GS outsold the Mac by far in its first year, despite the planed graphical interface was not ready and came a year later....

But in general, you are right here.

Instead, CBM tried to compete with rather lousy software (what was the name? TextCraft? GraphicsCraft?) hoping to get a foot into the door.

Well GraphiCraft and TextCraft were not too bad as a start - the problem was that CBM did not understand software at all:
They did not see the need for constant improvements and development and new versions every year ... at least not in the first Amiga years.

If they would have constantly improved GraphiCraft and TextCraft and bought some spreadsheet software as well, they would maybe still be in business...

It remains what it was: A home computer, a toy. That's not meant in a negative sense, but in an application sense.

Amiga was not more or less a toy than the Mac or the PC at that time - so yes: it is a hobby and it is limited and it is retro - but for many it was and is not just a toy.
Such descriptions and categorisations are unnecessary and not helpful in any way.

Which is also why I don't understand the purpose of the thread.

Ideas for a compact instruction set?

Whatever people cook up, it wouldn't close the bridge to a modern PC,...

this is not what this thread is about

[Thomas Richter]

Originally Posted by Gorf

It was surely not the AmigaOS (or its limitations) that was hindering the Amiga, but Commodores failed marketing and near bankruptcy in 85

Sure, absolutely. The problem is that CBM never invested into AmigaOs, or rather, their investments were too small to make a difference. The problem was not the software, but the business model (or the lack thereof). That IBM and the PC became succesful was not a matter of technology.

Originally Posted by Gorf

Interestingly enough "PICT" does exactly what I proposed in this thread in the very beginning as a CPU feature (byte-code and repeat-feature):


But in Amiga terms PICT is more or less the same as a Copper-List with Blitter instructions.

Errr, you misunderstand. PICT has nothing to do with the copper, or hardware for that matter. PICT can be best described as a precursor of postscript. It is a collection of drawing instructions that were forwarded to the Quickdraw component of MacOs.


The point is not "can the Amiga do it" - it can. The problem is that the Amiga graphics system never had this abstraction at operating system level. Graphics is just a junkyard of a minimally abstracted operations of the Amiga custom chips. Apple had a vision, defined an abstract coordinate system, abstract drawing primitives, a resource manager, and made that a core part of the operating system.

Originally Posted by Gorf

No - Amiga was no where ready in summer 1984 - and actually CBM did invest a lot of money in the first months. After paying over $50 million for a bunch of custom chips and some graphical demos, the real work only just began.
That is the reason we ended up with the Metacompco TripOS: Commodore needed something working and they needed it fast ...

Precisely, so they threw the thing together rather quickly, and lacked a clear perspective. This way, we have system components made by people that had good ideas and clear visions (exec, intuition), system components that were just collections of helper functions (graphics), some last-minute glue code (layers) that duplicates functions of graphics and intuition, and some hot-patched disk layer (Tripos). Or as Olaf put it: AmigaOs looks as if it is held together by several layers of glue, duct-tape and chewing gum. I can only agree.



You feel that the whole system is thrown together in a rush, and lacks a design and vision of other contemporary systems. MacOs didn't have the vision of exec providing multitasking, but the whole thing works rather consistent in its ideas with only some minor "design issues" around Quickdraw and its "a5-world" that is a bit different from the rest of the "handle-resource system". If you read "Inside MacIntosh", you get the feeling that a Steve Jobs overlooked the development and poked people. The net result may have deficiencies, but at least it is something consistent.



Thus, you feel that AmigaOs was done by separate engineers, separate working groups, each more or less capable, sometimes with diverging goals and ideas, but a technical management that provided a clear vision and a clear overall design of the thing was missing. AmigaOs is exactly the manifestation of the lack of management at CBM.


In the end, it wouldn't have mattered too much (after all, Windows 95 looked similar as some graphical toolkit on top of the MS-DOS junkyard, which was just a quick-and-dirty clone of CP/M), but there was never an investment made by CBM to improve matters, or throw the junkyard overboard. To be fair, they never had the money to do so either.

Originally Posted by Gorf

Well GraphiCraft and TextCraft were not too bad as a start - the problem was that CBM did not understand software at all:
They did not see the need for constant improvements and development and new versions every year ... at least not in the first Amiga years.

Correct. They still hung on the home-computer attitude. "Let's deliver something minimal, users will fix that." But that didn't work anymore. Users, even more so professional users, did not only expect a working hardware, but a working environment, including software and services.

Originally Posted by Gorf

If they would have constantly improved GraphiCraft and TextCraft and bought some spreadsheet software as well, they would maybe still be in business...

Maybe so, yes.

Originally Posted by Gorf

Ideas for a compact instruction set?

No, because what comes out of this thread is irrelevant. If you want something realistic that is workable and that would have sufficient critical mass: arm thumbcode. There is hardware, software, development tools, and a working environment.

[Gorf]

Originally Posted by Thomas Richter

Errr, you misunderstand. PICT has nothing to do with the copper, or hardware for that matter.

Please!
Come on man!

Would you please at least TRY to not misunderstand what I wrote ...

I of course did never say such a thing!

I said "in Amiga terms" we had something that provides a similar outcome:
a Copper-List with Blitter instructions can draw something on the screen.
It is a compact byte-code like list of instructions

So does PICT - it is a byte-code list of QuickDraw primitives that draws something on the screen (vie CPU).

The point is not "can the Amiga do it" - it can. The problem is that the Amiga graphics system never had this abstraction at operating system level.

But the OS is modular enough to provide such an abstraction via library and/or datatypes.

So there is no conceptual error in this case.

Apple had a vision, defined an abstract coordinate system, abstract drawing primitives, a resource manager, and made that a core part of the operating system.

the first iterations of QuickDraw were very limited and not really that visionary. Resource management in the OS came much later.
We are talking about 64KB ROM for everything in the first Mac.

Precisely, so they threw the thing together rather quickly, and lacked a clear perspective. This way, we have system components made by people that had good ideas and clear visions (exec, intuition), system components that were just collections of helper functions (graphics), some last-minute glue code (layers) that duplicates functions of graphics and intuition, and some hot-patched disk layer (Tripos). Or as Olaf put it: AmigaOs looks as if it is held together by several layers of glue, duct-tape and chewing gum. I can only agree.

and we all know this since forever ...

Of course it would have been nice if the "native" CAOS would have worked out back than and if Andy Finkel would have managed to at least retrofit some resource management as he had paned:

http://www.devili.iki.fi/mirrors/haynie/caos.html

Thus, you feel that AmigaOs was done by separate engineers, separate working groups, each more or less capable, sometimes with diverging goals and ideas, but a technical management that provided a clear vision and a clear overall design of the thing was missing.

At least for the TripOS-part this is very true - a completely different group, a different language, different concept .... in that light out is even astonishing they managed to duck-tape it together as good as they did

But its not like DOS and Windows were actually a good marriage in the beginning despite being fron the same company:

In the end, it wouldn't have mattered too much (after all, Windows 95 looked similar as some graphical toolkit on top of the MS-DOS junkyard, which was just a quick-and-dirty clone of CP/M), but there was never an investment made by CBM to improve matters, or throw the junkyard overboard. To be fair, they never had the money to do so either.

again:
all that does not really speak against most of the concepts and ideas of AmigaOS ... in the case not even against its flawed implementation back in the day

No, because what comes out of this thread is irrelevant. If you want something realistic that is workable and that would have sufficient critical mass: arm thumbcode.

I mentioned SH4 already earlier (thumb is based on that...)
But it's obviously not about what is already out there, but some new ideas, new concepts, fresh input

[Thomas Richter]

Originally Posted by Gorf

I said "in Amiga terms" we had something that provides a similar outcome:
a Copper-List with Blitter instructions can draw something on the screen.
It is a compact byte-code like list of instructions

But that's not even close to what PICT is. PICT is not about blitting, copper, hardware, whatsoever. It is really very remote from these ideas.

Originally Posted by Gorf

But the OS is modular enough to provide such an abstraction via library and/or datatypes.

That's not what I mean. AmigaOs is build "upside down". Quickdraw had PICT build in, from day 1, so there was a vision that a "graphics can be represented by abstract drawing instructions". The equivalent of quickdraw in Amiga land is graphics. graphics has no such thing. It doesn't even have the same carefully design coordinate system quickdraw came with.

So, for example, if you had to draw graphics on the Amiga, you would at best store a bitmap in the application binary, you would need to keep care that it is in chip ram (lack of abstraction!), and then use the blitter to draw the pixels to the screen. MacOs had a different mindset. Instead of the pixels, you would store the drawing instructions in the PICT resource, and the Os would render it, and the graphics would be scaling to various monitor sizes from day 1 on.

Originally Posted by Gorf

The first iterations of QuickDraw were very limited and not really that visionary. Resource management in the OS came much later. We are talking about 64KB ROM for everything in the first Mac.

I'm not talking about resource management, but Resources in the sense of MacOs. A resource is structured data contained in the resource fork of an application, a chunk of data that can be flushed out of main memory, reloaded, and interpreted by the Os. The stunning part of MacOs is that you can take an application - any application - and take the resource editor - and look into the dialogs, menus, windows and images ("PICT" resources) the application uses, completely from the outside, and even modify this information (e.g. to translate applications).

MacOs had the ability to load this structured information when needed, in chunks represented by a "handle", and flush these resources from memory if memory became low, from a running application, with only a 68000 available.

Thus, if you wanted to show an alert, for example, you would not fill some kind of alert structure and call the Os as you do in AmigaOs (or any other Os I know of), you would instead load an ALRT resource and provide the resource Id, and the Os would do all the organization for you, and the information how the Alert looks like and what it says are part of the resource fork of the application. There aren't many structures in MacOs at all, with some exceptions in Quickdraw and its A5-world.

That was a visionary design - applications not just as "binary junk that is run by the CPU", or "pixel data to be copied to the screen" - but as collection of structured information.

It is unfortuntately hard to describe without giving a complete course in MacOs.

[Gorf]

Originally Posted by Thomas Richter

But that's not even close to what PICT is. PICT is not about blitting, copper, hardware, whatsoever.

And I did not says SO!!


Please read what I really wrote and stop acting like I meant something utterly stupid.
Your behavior here is very close to being insulting.

That's not what I mean. AmigaOs is build "upside down". Quickdraw had PICT build in, from day 1, so there was a vision that a "graphics can be represented by abstract drawing instructions".

QuickDraw was build with just black and white (square) pixels in mind - the team had to work very hard to make it work with the color gfx of the Mac II - in fact it was a total rewrite

But besides that I know what you meant und did not argue your point in that regard.

The equivalent of quickdraw in Amiga land is graphics. graphics has no such thing. It doesn't even have the same carefully design coordinate system quickdraw came with.

So, for example, if you had to draw graphics ...

nobody said otherwise...

I'm not talking about resource management, but Resources in the sense of MacOs. A resource is structured data contained in the resource fork of an application, a chunk of data that can be flushed out of main memory, reloaded, and interpreted by the Os. The stunning part of MacOs is that you can take an application - any application - and take the resource editor - and look into the dialogs, menus, windows and images ("PICT" resources) the application uses, completely from the outside, and even modify this information (e.g. to translate applications).

A couple of pages earlier, when we talked about message passing I mentioned that an OS should provide an abstracted GUI that would probably have something like that ...

My concept would probably be closer to an "Edje" in EFL (Enlightenment) - a "resource" in form of a bytecode - provided by the application but "swallowed" by the GUI...

MacOs had the ability to load this structured information when needed, in chunks represented by a "handle", and flush these resources from memory if memory became low, from a running application, with only a 68000 available.

all in all this is just a feature of the GUI - it could probably be implemented in Intuition as well.
Instead of in a "fork" it would be stored in a "hunk"...

Thus, if you wanted to show an alert, for example, you would not fill some kind of alert structure and call the Os as you do in AmigaOs (or any other Os I know of), you would instead load an ALRT resource and provide the resource Id, and the Os would do all the organization for you, and the information how the Alert looks like and what it says are part of the resource fork of the application.

see above ...

That was a visionary design - applications not just as "binary junk that is run by the CPU", or "pixel data to be copied to the screen" - but as collection of structured information.

This was not all there from day one in MacOS and most things were not even envisioned...
AmigaOS with it's libraries is surely not less flexible and expandable.
It just was not done and so we ended up in a mess of proprietary extensions instead of a clean house ...

It is unfortuntately hard to describe without giving a complete course in MacOs.

you don't need to: I am using it every day

[Thomas Richter]

Originally Posted by Gorf

QuickDraw was build with just black and white (square) pixels in mind - the team had to work very hard to make it work with the color gfx of the Mac II - in fact it was a total rewrite

That's true, but the design idea remained.

Originally Posted by Gorf

all in all this is just a feature of the GUI - it could probably be implemented in Intuition as well.
Instead of in a "fork" it would be stored in a "hunk"...

Yes, of course one "could" do that, but it's a bit too late. Unfortunately, nobody did it back then. Instead, we have this graphics.library, with all structures documented, and nearly impossible to extend.

[Minuous]

Originally Posted by Bruce Abbott

"What are you complaining about, these programs work fine in OS3.x - oh sorry, we mean 3.5 or 3.9 only. What are you doing still using 3.0?".

What is wrong with that? Those are a lot better than 3.0. It seems odd that you would expect application developers to limit themselves to such old and inadequate OS versions, just because you don't want to install an update.

[Thorham]

Originally Posted by Minuous

What is wrong with that? Those are a lot better than 3.0. It seems odd that you would expect application developers to limit themselves to such old and inadequate OS versions, just because you don't want to install an update.

For anything pre-AGA I'd probably write for 2.04 and for AGA 3.0. That way most people can actually use it. What does 3.5+ offer that makes it so much better than 3.0 anyway?

[Minuous]

@Thorham:

http://www.bambi-amiga.co.uk/amigahistory/os35feat.html for starters, but that is just comparing 3.1 to 3.5. Comparing 3.0 to 3.9, the list would be even bigger.

[Thorham]

Originally Posted by Minuous

@Thorham:

http://www.bambi-amiga.co.uk/amigahistory/os35feat.html for starters, but that is just comparing 3.1 to 3.5. Comparing 3.0 to 3.9, the list would be even bigger.

Thanks. Okay, I must admit that's quite a list.

[Gorf]

Originally Posted by Thorham

Thanks. Okay, I must admit that's quite a list.

Well most of it are tools and libraries and support for peripherals ... "extras"

Sure - quite some useful things among them, but they can of be used or oder OS Versions as well - or at least could.

The sections "big fixes" and "enhancements" are not that long after all and are mostly iterating datatypes

[Bruce Abbott]

Originally Posted by Thomas Richter

How to answer that? CBM did not develop the Amiga.

I did say 'imagine'. But when Commodore took over the Amiga was not a finished product, and it probably never would have been if they hadn't taken it on.

The PC was designed by a single team, as a budget competitor to the Apple II, as cheap as possible.

Correct, or more accurately to stop people from buying Apple II's instead of their mainframes. IBM's top management didn't have much of an idea what to do their machine either. Luckily they left the design and marketing to people who did have some idea. But in many ways they just got lucky. The combination of unfulfilled small business demand, partnering with Microsoft and attracting the clone makers was a winner, but not by design.

CBM haven't had the vision to use the system as the basis of a business machine, they didn't even know how this market worked. It would have required a different Os and a different abstraction.

So then neither neither did IBM, or practically anyone else in the personal computer industry at that time. Hell, IBM couldn't even write their own OS! They thought people would use their PC on TV with ROM BASIC and cassette tape storage! How out of touch was that? And when that didn't happen, they released the PC JR, a total flop in the marketplace! What were they thinking?

But who produced an advanced but affordable desktop computer with a fully multitasking OS, sufficiently abstracted that developers wouldn't have to hit the hardware to get acceptable performance? Commodore with the Amiga. Nobody else at that time had such vision.

That was, however, already a declining market at that time, and it was quite obvious already close to the end of the home computer market.

That may be obvious to you now, but few realized it in February 1984 when Commodore bought the Amiga. And in truth there were still a few years left in the home computer market - for the right product. Commodore sold a total of around 4 million Amigas despite mismanagement and a weak financial position.

Which is also why I don't understand the purpose of the thread. Whatever people cook up, it wouldn't close the bridge to a modern PC

Yes, that is clear. Nobody is talking about 'closing the bridge to a modern PC'. Some are talking about alternatives that will probably only find niche applications if any, and we don't care if they don't. We are only doing it for fun after all - and why not? I bet 99% of the stuff 'modern' developers are playing with won't go anywhere either (just look at all the unfinished projects on Github...).

[Bruce Abbott]

Originally Posted by Minuous

What is wrong with that? Those are a lot better than 3.0. It seems odd that you would expect application developers to limit themselves to such old and inadequate OS versions, just because you don't want to install an update.

Well let's see.

First off, nobody seems to have it in stock.

Then there are the system requirements:-

An Amiga. OK, I think I can manage that.

020 or higher CPU. Damn, No OS3.9 for the A500! But I have an A1200 so...

KS3.1 ROM. Damn! Now I have to buy new ROMs and install them too.

6MB RAM. Oh well, guess I was going to buy a RAM expansion eventually anyway.

A Hard Drive. I have a 1GB CF card, hopefully that will do.

And a CDROM drive. And a CDROM drive? Are you kidding?