Things the Amiga didn't get right from Day 1

[Thomas Richter]

Actually, the whole point of the bootblock booting was to enable exactly that - to replace AmigaDOS aka Tripos by something else. To remind you, all the bootblock does is to call InitResident("dos.library") which starts AmigaDOS. At this point, only the core system (exec, trackdisk, graphics, intuition) are initialized, but AmigaDOS is not, so something else taken from disk could take over.

It is anybodies guess why the system was designed this way, but my feeling is that Tripos was considered a "last minute temporary solution" that would have been potentially replaced by CAOS should it ever become ready, so a "wedge" like this was created.

Under 1.2, the "dos.library" is not even a proper exec library, it is rather a patch-up job that, for each entry, just calls into one of the Tripos-provided "GlobVec" entries with the help of a little trampoline funtion. It wouldn't surprise me if nodoby liked this situation and rather considered this as only an interim solution.

[Bruce Abbott]

Originally Posted by Gorf

I as electrical engineer I do not disapprove ;-)
Some others also don’t:
https://www.histo.cat/1/Microchip-00954a.pdf

https://www.designercircuits.com/DesignNote1c.pdf

Disadvantages of Capacitive Power Supply:
1. Not isolated from the AC line voltage which introduces safety issues

To meet UL safety requirements, the capacitor must be rated for use in series with the mains

Originally Posted by Gorf

But it was just one idea, keeping the battery away from the board is another, there may be other solutions...

There is usually already a fitting (expensive) high voltage capacitor.… you could place the clock-chip next to it and provide the information via an optocoupler to the computer board to be save and fulfill all regulations.

Or you could shine a light on a photocell, or...

But all of these 'innovative' ideas are still tied to mains power. A brief power outage, moving the computer from one outlet to another, unplugging it for safety during a lightning storm etc. all kill the clock time. Had Commodore done it this way, we would now be talking about yet another thing they 'didn't get right from day 1'.

[Gorf]

Originally Posted by Bruce Abbott

As I said: there is already such a capacitor in the main power supply

Originally Posted by Bruce Abbott

Or you could shine a light on a photocell, or...

Yes, some "glow light" (is this the right English term?) and a photocell would also work.

Or, as mentioned before, storing the battery in a save place, where it can do no harm.

Or ....

But all of these 'innovative' ideas are still tied to mains power. A brief power outage, moving the computer from one outlet to another, unplugging it for safety during a lightning storm etc. all kill the clock time. Had Commodore done it this way, we would now be talking about yet another thing they 'didn't get right from day 1'.

Come on!
That would be the behavior most video recorders and radio-clocks showed back then and would have been perfectly fine.

I know you are not a fan of the idea of a RTC, but now the "reasons" against it become ridicules.

The only valid point are the (small) additional manufacturing costs, but as I showed earlier these can be more than compensated if it attracts even just a tiny percentage of additional customers.

Maybe "Overdock" can give us some information how many A500 RAM-expansions came with a buffered RTC ;-)
My guess would be: a lot.
Mine did.

All big box Amigas had a RTC, the A1000 is the only exception ... it should not be.

[Bruce Abbott]

Originally Posted by Gorf

CP/M would have helped the Amiga to be taken serious as an office computer as well.

Many computer designers thought it would make their systems be 'taken serious', but by the time the Amiga came out CP/M was all but dead. And having used it myself I can understand why.

Everybody trashes TRIPOS, but the alternatives were worse. It gave us lots of good stuff like longer filenames, multiple command lines, shared libraries etc. which the others didn't have. Being ported down from minicomputers (rather than up from 8 bit microcomputers) gave us a perspective that better matched the Amiga's advanced 16/32 bit architecture, providing a much richer and more interesting experience than other contemporary platforms.

But as usual, Amiga fans focus on the perceived failings and don't appreciate what they have, while giving other systems a pass. If we are going to talk about what the Amiga 'didn't get right from day 1' then we should also compare it to what other systems 'didn't get right'. MSDOS (the so-called 'professional' OS for the platform people like comparing the Amiga to) didn't get much right 'from day 1' and was still pretty wrong 20 years later. Whatever failings AmigaDOS had pale in comparison.

[Thomas Richter]

Originally Posted by Bruce Abbott

Everybody trashes TRIPOS, but the alternatives were worse. It gave us lots of good stuff like longer filenames, multiple command lines, shared libraries etc. which the others didn't have. Being ported down from minicomputers (rather than up from 8 bit microcomputers) gave us a perspective that better matched the Amiga's advanced 16/32 bit architecture, providing a much richer and more interesting experience than other contemporary platforms.

Partially. Shared libraries are exec domains, unless you call the BCPL segments that reside in L: also libraries as Tripos does. Tripos added loadable handlers, and a "virtual file system", which is a quite unique construction.


On the other hand, Tripos did not have multitasking, but multithreading/cooperative multitasking, and this caused a couple of conflicts with exec, such as lack of proper synchronization and Forbid()/Permit() "locking" instead of semaphores. The packet communication is rather a "hot fix" to fit Tripos to the exec core, so the two systems really do not fit well together.


Concerning options, MS-DOS aka "quick and dirty DOS" (as bought by M$ and sold to IBM) would have been a much weaker choice, and so would have been CP/M. But a BSD-style/ix style system would have been a better choice, but probably not available, or not available in time.



The problem really was that the system development was late, so a quick solution was required.


What other systems got right, after a while, was to ditch all the legacy nonsense and came up with a real Os. M$ ditched MS-DOS and its GUI (aka Windows 98/ME), and replaced it by the NT kernel. Apple ditched MacOs and replaced it by the mach kernel, essentially an ix-derivate.



CBM never had the money or vision to do so. Kick 2.0 brought a couple of worthwhile changes, replacing the Tripos kernel by "Arp", the outcome of the "Amiga Replacement Project". It was no longer native BCPL, but it was not the big changes M$ and Apple made to their systems.

[TEG]

Originally Posted by Gorf

All big box Amigas had a RTC, the A1000 is the only exception ... it should not be.

The A1000 was clearly marketed as a professional machine during its presentation. So the lack of RTC was clearly a mistake. Small things like that can make the user change his mind about a product for the worst.
I remember, at work their was PC running under DOS which did not have a RTC. The first thing the DOS did during the boot, was to ask for the date. It was so annoying.

I wonder if a debate occurred at CBM about the necessity for an RTC on the Amiga.

[Gorf]

Originally Posted by Bruce Abbott

Many computer designers thought it would make their systems be 'taken serious', but by the time the Amiga came out CP/M was all but dead. And having used it myself I can understand why.

Yes - and still additional CP/M on the A1000 would have been a good thing:

It would have given the Amiga hundreds of legacy applications ready to use.
Yes somewhat "outdated" - but we only talk about a couple of years max.
And very important: no future!

So while it would have enabled a large quantity of software titles right from the start it would not have been a real competitor to native AmigaOS.

It would only have been some kind of "kickstarter"

Everybody trashes TRIPOS, but the alternatives were worse.

Well - have a closer look at OS-9.
Not sure if an appropriate deal with Microware was possible back then, but OS-9 fulfills all the requirements for sure.

Not saying TripOS was a terrible choice, but it was maybe not the most fitting choice.

It gave us lots of good stuff like longer filenames,

25 characters in OS-9 but that in not a hard limit.

multiple command lines,

OS-9 provides that even on a CoCo...

shared libraries etc. which the others didn't have.

that is Exec stuff and not TripOS.

[Gorf]

Originally Posted by Bruce Abbott

But as usual, Amiga fans focus on the perceived failings and don't appreciate what they have, while giving other systems a pass.

Nooo

I don't think you understand most of the critique here the right way.
We all love the Amiga and with the exception of "Overdoc" everybody here believes it was the single most advanced widely available platform in the 80s.

But this thread asks the questions, what our beloved computing platform did not get right. And if we are brutally honest: a lot of things.
Even if others did even worse. But still there was much room for improvement and the sum of all these things might have helped to ensure the survival.
(assuming Commodore would have acted accordingly in the following years).

[Bruce Abbott]

Originally Posted by Gorf

As I said: there is already such a capacitor in the main power supply

...across the mains input to reduce EMI, yes. But that is not useful for a tranformerless power supply (capacitor has to be in series with the mains, not in parallel).

Yes, some "glow light" (is this the right English term?) and a photocell would also work.

Or, as mentioned before, storing the battery in a save place, where it can do no harm.

Or ....

Yep, all 'solutions' that were either not considered, or soon dropped by the industry in favor of rechargeable batteries.

Come on!
That would be the behavior most video recorders and radio-clocks showed back then and would have been perfectly fine.

I have an old LED clock with mains-derived timing and no backup power. It only has two buttons to set the time and they are getting flaky, making it even more of a pain to reset it after a power cut. Not ideal, but back then that was all you could get. I lost the instruction manual for my VCR and took ages to figure out how to set the time. Hasn't been plugged in for years now, and probably won't ever be again...

Maybe "Overdock" can give us some information how many A500 RAM-expansions came with a buffered RTC ;-)
My guess would be: a lot.
Mine did.

So why didn't the A500 come with the extra RAM and RTC built in? One reason - cost. You say the price increase would be "more than compensated if it attracts even just a tiny percentage of additional customers", but we all know what people were buying base model A500's for - and it wasn't to make a £499 digital clock. Customers who wanted a more 'professional' machine would buy the A501 expansion. Those who didn't might be put off by having to pay more for something they didn't need.

So let's say the RTC bumped the manufacturing cost up by £5. Doesn't sound like much, but by the time it gets to retail the difference is £10. Now the total is £509 which is psychologically a lot more. Customers start thinking the ST (which for some reason doesn't need this RTC thingy) is much better value. And I bet the price was already squeezed down to get a 'magic' number, so Commodore and/or the retailer would have to eat even more if they wanted to keep sales up.

All big box Amigas had a RTC, the A1000 is the only exception ... it should not be.

The A1000 was not a 'big box' Amiga. It was 'pizza box' with no internal expansion slots and not much spare room inside. The case was also a monitor stand and keyboard drawer, a strikingly different form to match its strikingly different chipset and OS. It was designed to appeal to gamers, artists and musicians, not business suits. And the last thing on their list of must-haves was a real-time clock.

[Gorf]

Originally Posted by Bruce Abbott

...across the mains input to reduce EMI, yes. But that is not useful for a tranformerless power supply (capacitor has to be in series with the mains, not in parallel).

Sure - but that could be changed if you switch the device "off" ...

Yep, all 'solutions' that were either not considered, or soon dropped by the industry in favor of rechargeable batteries.

well - that is what I voted for in the beginning ....

So why didn't the A500 come with the extra RAM and RTC built in?

Please don't do that and stay reasonable.

Why are you now mixing up the costs for additional RAM (expensive) and RTC (cheap).

And we were talking about the A1000...

Now it is you who starts to troll

....Customers start thinking the ST (which for some reason doesn't need this RTC thingy) is much better value. And I bet the price was already squeezed down to get a 'magic' number, so Commodore and/or the retailer would have to eat even more if they wanted to keep sales up.

And did the "cheaper price" help Atari or the ST in the end?
No.
Here you go ...

(as I mentioned elsewhere: having both companies fighting over the low end market segment was one crucial element of the downfall of both.
It was simply one 68k platform to many ... but that is an other discussion)

[Bruce Abbott]

Originally Posted by Gorf

Yes - and still additional CP/M on the A1000 would have been a good thing:

It would have given the Amiga hundreds of legacy applications ready to use.

But none that anyone wanted to use. But let's say there was. This would just hold back development of native Amiga programs.

but we only talk about a couple of years max.
And very important: no future!

The Amiga desperately needed native development, and couldn't afford any distractions from that goal.

So while it would have enabled a large quantity of software titles right from the start it would not have been a real competitor to native AmigaOS.

Yes, and therefore worthless. We didn't buy Amigas to run ancient CP/M text-based apps!

Well - have a closer look at OS-9.

I hope to do that some day. I have a Tandy Color Computer III, but no disk drive for it yet.

Not saying TripOS was a terrible choice, but it was maybe not the most fitting choice.

A much better fit than CP/M or MSDOS, that's for sure.

that is Exec stuff and not TripOS.

TRIPOS also had shared libraries, and preemptive multitasking too. That made it a good fit for Amiga OS. Here's a snippet of assembler code from the 'Introduction to TRIPOS' manual. Look familiar?

INCLUDE "tripos.i "
The values of the offsets have the same name as that described in
Chapter 3 , "Calling the DOS",  but each one is preceded by LVO
(Library Vector Offset) to distinguish it from the C function entry point.
Set up a macro to call the DOS to make the program more readable :

   CALL MACRO
   JSR _LVO\l(A2)
   ENDM   

You are now ready to start the program. First, find the DOS base pointer
by calling the Kernel via a TRAP instruction:

   MOVEQ #K_FindDOS,D0   Kernel function code
   TRAP #0               No arguments
   MOVEA.L D0,A2         DOS base pointer in A2

You'll need to locate the channels that represent the standard input and
output. If the program has been invoked under the Command Line
Interface (CLI), then the calls Input and Output return the file handles
associated with these channels. If you run the program as a task, you'll
need to open a specific I/O channel. This complexity is not covered here.
Next, save the file handles in D7 and D6:

   CALL Input
   MOVE.L D0,D7          D7 holds stdin
   CALL Output
   MOVE.L D0,D6          D6 holds stdout

[Gorf]

Originally Posted by Bruce Abbott

But none that anyone wanted to use. But let's say there was. This would just hold back development of native Amiga programs.

Not really, because as you say:
nobody really wanted this kind of programs anymore.

So yes: they would have been there and could been used, like many DOS programs on the PC, but customers and programmers alike wanted something better.

I hope to do that some day. I have a Tandy Color Computer III, but no disk drive for it yet.

A much better fit than CP/M or MSDOS, that's for sure.

And I did not suggest to use CP/M instead on TripOS - and I made this very clear in multiple statements.

TRIPOS also had shared libraries, and preemptive multitasking too.

No it did not - see Thor's comment.

That made it a good fit for Amiga OS. Here's a snippet of assembler code from the 'Introduction to TRIPOS' manual. Look familiar?

Of course it looks quite familiar, as we got TripOS for the DOS part of AmigaOS.
And yes: both did/do communicate via registers on 68K.

[Gorf]

About OS-9 on 8Bit:

[ Show youtube player ]

[Bruce Abbott]

Originally Posted by Gorf

About OS-9 on 8Bit:

[ Show youtube player ]

Thanks for that. The video gets interesting about 18 minutes in, when he finally gets around to showing off OS9 on a real CoCo3. And what do we see?

       YYYY/MM/DD HH:MM:SS
TIME ?

What? No Real-time clock?

(Top marks for having a 4 digit year in 1980. Er, no - this is an update released in 2002 - the original only had 2 digits and was not Y2K compliant.)

Next he explains how all the system commands (including 'dir') are 'external', ie. files on the system disk - just like AmigaDOS. So you can't just shove in any old disk and get a directory listing.

Only 2 minutes into the meat of the video and already we have 3 'didn't get rights'.

I don't have time to watch the whole 2.5hr video this morning, so I downloaded the OS9 manual to get an overview of it. Overall I am impressed - preemptive multitasking, resident commands, support for graphic screen modes, memory management in Level 2 with the CoCo3's MMU. Seems like an excellent OS for the CoCo3.

Whether it would have ported to the Amiga better than TRIPOS is anyone's guess, but it might have gained more acceptance to its greater familiarity and good reputation on the CoCo.

Yet I am still glad that Commodore choose TRIPOS. Why? Because we got to learn about another interesting OS that wasn't based on CP/M, and it made the Amiga a bit more 'exotic' - which is a large part of its attraction for hobbyists. We don't avoid different technology because it isn't familiar - we embrace it. We don't complain about stuff they 'didn't get right' - we enjoy making it right (and more).

[Overdoc]

Originally Posted by Gorf

Maybe "Overdock" can give us some information how many A500 RAM-expansions came with a buffered RTC ;-)
My guess would be: a lot.
Mine did.

I cannot remember any A-500 512k ram expansion which did not have a RTC. And I think I have at least 30 different models, maybe even 50 if I count the bigger expansions (1.7MB and 1MB for A-500+) as well.

Most of them had a rechargeable battery (the well know 3x 1.2V ones in a blue shrink tube )
There were only very few (maybe 1 or 2 of all I have seen) which had a Li-Ion buton cell instead, which I have not seen leaking (yet? )

[Gorf]

Originally Posted by Bruce Abbott

Thanks for that. The video gets interesting about 18 minutes in, when he finally gets around to showing off OS9 on a real CoCo3. And what do we see?

       YYYY/MM/DD HH:MM:SS
TIME ?

What? No Real-time clock?

(Top marks for having a 4 digit year in 1980. Er, no - this is an update released in 2002 - the original only had 2 digits and was not Y2K compliant.)

I was posting this video to show some of the software features of OS-9 even on very limited hardware.

I thought this would be obvious to everyone here, that this is not indented to compare hardware features of the CoCo to the Amiga.

*sigh*

Next he explains how all the system commands (including 'dir') are 'external', ie. files on the system disk - just like AmigaDOS. So you can't just shove in any old disk and get a directory listing.

Exactly.
As I mentioned before, Microware's OS-9 might have been also a viable choice for the DOS-part of AmigaOS, instead of Metacomco's TripOS.

Of course with some adjustments to fit the already existing Exec/Intuition-part of AmigaOS

I don't have time to watch the whole 2.5hr video this morning, so I downloaded the OS9 manual to get an overview of it. Overall I am impressed - preemptive multitasking, resident commands, support for graphic screen modes, memory management in Level 2 with the CoCo3's MMU. Seems like an excellent OS for the CoCo3.

Whether it would have ported to the Amiga better than TRIPOS is anyone's guess, but it might have gained more acceptance to its greater familiarity and good reputation on the CoCo.

And this was my whole point a couple of comments above:
not everything was a shitty as MS-DOS or CP/M back in the mid 80s.
And TripOS was probably not the only choice left.

[Bruce Abbott]

Originally Posted by Thomas Richter

On the other hand, Tripos did not have multitasking, but multithreading/cooperative multitasking, and this caused a couple of conflicts with exec, such as lack of proper synchronization and Forbid()/Permit() "locking" instead of semaphores. The packet communication is rather a "hot fix" to fit Tripos to the exec core, so the two systems really do not fit well together.

Did you perhaps mean that it didn't have preemptive multitasking?

According to Wikipedia (where I got my information from) it did, but there is no citation and the author is anonymous. Tim King's bio site says:-

Tim King was responsible for bringing to the Amiga an operating system that he had been working on at Cambridge University called Tripos. This was a fully pre-emptive multi-tasking system written almost entirely in the programming language BCPL (a precursor to C). Tim worked with the team at Amiga who had already produced a kernel, and moved Tripos on top of this.

But this could also be wrong.

Googling didn't bring up much other than copies of the Wikipedia article, but I did find this from the 'horse's mouth':-

Tripos had a full multi-tasking kernel of its own written in Assembler, using standard shared memory message-passing techniques. EXEC had been written by Carl Sassenrath completely separately but using the same techniques (not surprising as that was pretty much state of art in 1983). So when I came along I simply left the Tripos kernel behind and bolted Tripos over EXEC.

It was of course completely multi-tasking – there was a process for each file system, a process for each open CLI and so on. A program wanting to read a file say would request data from a filing system process, the requester would wait for a reply from the file system process. If the fs process had the data in a buffer then it was returned at once, otherwise the fs process sent a message to the disk device driver and also waited for a reply. The device driver would request the data and wait for the interrupt.

So TRIPOS was 'fully' and 'completely' multi-tasking, but Tim's description of it seems to suggest that it was 'cooperative' rather than 'preemptive'. If this is true then someone should edit the Wikipedia entry, and perhaps tell Tim about the error on his website.

[Gorf]

Originally Posted by Bruce Abbott

So TRIPOS was 'fully' and 'completely' multi-tasking, but Tim's description of it seems to suggest that it was 'cooperative' rather than 'preemptive'.

And, as Thomas wrote, to make it work anyways under Exec all these forbid-permit constructions became necessary.

(Maybe that is what the developers meant when the hid the message "we did it and they f*** it up" in the ROM)

[Gorf]

But this is interesting nevertheless:

Tim King:

It was of course completely multi-tasking – there was a process for each file system, a process for each open CLI and so on. A program wanting to read a file say would request data from a filing system process, the requester would wait for a reply from the file system process. If the fs process had the data in a buffer then it was returned at once, otherwise the fs process sent a message to the disk device driver and also waited for a reply. The device driver would request the data and wait for the interrupt.

The rest works as we know it, but instead of a "filing system process" we got the dos.library.
Having this functionality provided by a real exec task, analog to the intuition task in form of some server-client model, might have solved a lot of problems and headaches ...

[grond]

Originally Posted by Gorf

The rest works as we know it, but instead of a "filing system process" we got the dos.library.
Having this functionality provided by a real exec task, analog to the intuition task in form of some server-client model, might have solved a lot of problems and headaches ...

But what about the devices such as trackdisk.device and scsi.device? Aren't they pretty much what the filesystem device would be?