What was wrong with the Amiga 1000/500/2000?

[litwr]

I can point the next drawbacks:

1) error in timer - http://eab.abime.net/showthread.php?t=82392;
2) no system functions for working with wildcards - it was only corrected in the A1200 (maybe in the A3000 and A600);
3) no functions to get the graphic cursor position - we have only the Move-call to set it - maybe it is still an issue;
4) falsehood about the fast RAM, no fast RAM cards were available for the A500;
5) the mess with "standard" return codes: only 0, 5, 10, 20 are actually allowed;
6) standard utility `ask' provides only two return codes and there is no any other standard way to get information from a user;
7) Basic has only 25 KB free, even the Commodore 128 has 120K, Commodore +4 has 60K, and Commodore 64 has 38K for Basic;
8) iconx doesn't allow SKIP, IF, LAB, ...
9) only limited preemptive multitasking supported because there is no kill-command in Amiga DOS.

Maybe I am wrong with some details but it requires some help to be corrected. Indeed, I don't know all the drawbacks. Let's make a complete list!

[roondar]

Just some small ones I know for certain. I'm relatively sure you got others on that list wrong as well, but I don't feel like putting in any extra time finding out, as I'm pretty sure I know where this thread is going.

Originally Posted by litwr

I can point the next drawbacks:
4) falsehood about the fast RAM, no fast RAM cards were available for the A500;

Errr, there's tons of them. Both old and new. These go into the side slot (though some go directly onto chips on the motherboard). In fact, most HDD controllers double as a fast ram memory expansions as well.

Just check the Big Book of Amiga Hardware (https://bigbookofamigahardware.com/).
Here's just one of many, many A500 fast ram expansions as an example: https://bigbookofamigahardware.com/b...ct.aspx?id=938

5) the mess with "standard" return codes: only 0, 5, 10, 20 are actually allowed;

Not true, only 0,5,10,20 are used as standard. But you can use any value and I've certainly had executables that exited with other codes.

9) only limited preemptive multitasking supported because there is no kill-command in Amiga DOS.

The lack of a kill command does not mean pre-emptive multitasking is not fully supported. It's actually a rather strange claim as multitasking has nothing to do with the ability to kill programs.

Anyway, it's not even really true: there are ways to kill processes at least starting with OS 2.0+ (which were available on all the systems you mention), although I will admit I'm not entirely sure whether this was a standard command or one that was part of the developer kit.

[litwr]

Originally Posted by roondar

Just some small ones I know for certain. I'm relatively sure you got others on that list wrong as well, but I don't feel like putting in any extra time finding out, as I'm pretty sure I know where this thread is going.

Errr, there's tons of them. Both old and new. These go into the side slot (though some go directly onto chips on the motherboard). In fact, most HDD controllers double as a fast ram memory expansions as well.

Just check the Big Book of Amiga Hardware (https://bigbookofamigahardware.com/).
Here's just one of many, many A500 fast ram expansions as an example: https://bigbookofamigahardware.com/b...ct.aspx?id=938
Not true, only 0,5,10,20 are used as standard. But you can use any value and I've certainly had executables that exited with other codes.
The lack of a kill command does not mean pre-emptive multitasking is not fully supported. It's actually a rather strange claim as multitasking has nothing to do with the ability to kill programs.

Anyway, it's not even really true: there are ways to kill processes at least starting with OS 2.0+ (which were available on all the systems you mention), although I will admit I'm not entirely sure whether this was a standard command or one that was part of the developer kit.

Thank you. This is something elusive about Fast RAM for the A500. I remember my great disappointment when I got 512 KB memory expansion in the 80s and discovered that it is not any faster than the initial 512 KB Chip RAM. Even today, when I check the A500 with fast RAM I can't get any speed boost. The A1200 with Fast RAM is really much faster than the stock A1200 but it is not true for the A500. Maybe Fast RAM in the A500 makes things faster only for some graphic modes?
I don't understand your claim that "you can use any value and I've certainly had executables that exited with other codes" because there is no way to use them. I only know about the IF-statement for this purpose and it doesn't allow to use anything but five standard values. DOS primitive BAT-files allow to use ERRORLEVEL and I know nothing that corresponds this feature in Amiga DOS.
There is no way to kill a process even in the A1200 WB. Indeed there are different multitasking. Microsoft Windows 3.1 can't kill a process but Microsoft Windows 95 can. So Amiga WB was somewhere between them.
I also forgot to mention the 10th drawback.
10) a very poor multitasking scheduler - it is easy to hang up all system just increasing the priority of a task above 20. IMHO it is rather impossible in any Unix.

[roondar]

Originally Posted by litwr

Thank you. This is something elusive about Fast RAM for the A500. I remember my great disappointment when I got 512 KB memory expansion in the 80s and discovered that it is not any faster than the initial 512 KB Chip RAM. Even today, when I check the A500 with fast RAM I can't get any speed boost. The A1200 with Fast RAM is really much faster than the stock A1200 but it is not true for the A500. Maybe Fast RAM in the A500 makes things faster only for some graphic modes?

Fast RAM for the A500 exists in two forms: "fake" Fast RAM (the cards you put in the trap door slot, also called Slow RAM) and "true" Fast RAM, which is connected to the side slot.

The confusion exists because both are not Chip RAM, so they incorrectly both get called Fast RAM by users. The technical difference is as follows:

• trap door memory is very cheap to make and add, but CPU access to it is slowed down by Chip Memory DMA cycle stealing - it acts as if it's on the Chip Memory bus, even though the custom chips can't access it. This is because it's connected to the system through the Agnus chip.
• side slot memory is more expensive to make and add, but CPU accesses to it are not slowed down by Chip Memory DMA cycle stealing - it's on a bus with just the CPU.

On an A500/A1000/A2000 there is not a big difference in speed between Chip RAM and true Fast RAM, because the Amiga design is quite effective in not slowing the CPU down as much as you might think. However, if you have true Fast RAM and run software which uses a lot of Chip RAM DMA (for example you run the system in 640x512x16 colours and have it blit a lot) then you'll see a measurable speed boost.

Generally the increase in performance for having true Fast RAM on a 68000 based Amiga is around 10-15%. This increases for faster CPU's.

I don't understand your claim that "you can use any value and I've certainly had executables that exited with other codes" because there is no way to use them. I only know about the IF-statement for this purpose and it doesn't allow to use anything but five standard values. DOS primitive BAT-files allow to use ERRORLEVEL and I know nothing that corresponds this feature in Amiga DOS.

What I mean is that executables can exit with any return code between -2 billion and +2 billion (IIRC anyway, you get to return a signed long word). It's possible the IF statement doesn't support all of them, but to be honest I don't usually make scripts so I can't verify that.

There is no way to kill a process even in the A1200 WB. Indeed there are different multitasking. Microsoft Windows 3.1 can't kill a process but Microsoft Windows 95 can. So Amiga WB was somewhere between them.

There is a way to kill tasks on OS 2.0+ (in fact, Exec has a built-in function for it in ROM), but you're correct that it's probably not included as a standard command. I'm 100% certain I have a killtask or some similar command somewhere form the developer CD though, so it is actually possible.

I also forgot to mention the 10th drawback.

You also forgot the counter is down to either 9, 8 or 7 depending on which of my answers you actually intend to take into account

10) a very poor multitasking scheduler - it is easy to hang up all system just increasing the priority of a task above 20. IMHO it is rather impossible in any Unix.

Just use the correct 'nice' statement on Unix. I forget which value to use, but you can hang the entire system like that. Same with Windows all the way up to Windows 10, if you select the correct process and give it high enough priority you can quite easily hang the system.

Anyway, I don't really agree with this to begin with. The scheduler works fine if you use it as instructed. The instructions for changing task priority tell you that you shouldn't increase priorities that high. If you do so anyway, purposefully disregarding how the system works, then that's not the schedulers fault.

[Thomas Richter]

Originally Posted by roondar

There is a way to kill tasks on OS 2.0+ (in fact, Exec has a built-in function for it in ROM), but you're correct that it's probably not included as a standard command.

Not any more or less than on Kick 1.3. Actually, there is Exec RemTask(), but even though this removes the task from getting scheduled by the system, it does not stop pending I/O operations the task initiated, and it does neither release any resources the task obtained.


Thus, for all practical purposes, AmigaOs cannot remove a running program reliably, unless the program terminates by itself. You can stop it from getting scheduled, but that is not very helpful.

[roondar]

In that case, I stand corrected. I still maintain it's not a very valid way to determine whether or not the system has pre-emptive multitasking though.

[Thomas Richter]

Originally Posted by litwr

1) error in timer - http://eab.abime.net/showthread.php?t=82392;

Err, there is no error I am aware of. For timing, use the timer.device. It times correctly.

Originally Posted by litwr

2) no system functions for working with wildcards - it was only corrected in the A1200 (maybe in the A3000 and A600);

There were link-libraries in 1.3 times to support them. It's not a feature of the A1200 to include wildcard support functions. These came into the dos.library with Kick 2.0 (v37), available for all machines. They have been integrated through the arp project.

Originally Posted by litwr

3) no functions to get the graphic cursor position - we have only the Move-call to set it - maybe it is still an issue;

None is needed. It's directly accessible in the RastPort. It's not related to the machine type.

Originally Posted by litwr

4) falsehood about the fast RAM, no fast RAM cards were available for the A500;

It's more complicated to make them. CBM went cheap.

Originally Posted by litwr

5) the mess with "standard" return codes: only 0, 5, 10, 20 are actually allowed;

Err. No. Simply no.

Originally Posted by litwr

6) standard utility `ask' provides only two return codes and there is no any other standard way to get information from a user;

From the shell? Oh, certainly. RequestFile, RequestChoice exist as files. ASK was updated to also retrieve strings.

Originally Posted by litwr

7) Basic has only 25 KB free, even the Commodore 128 has 120K, Commodore +4 has 60K, and Commodore 64 has 38K for Basic;

That depends on the memory of the system. Besides... scrap Basic. Microsoft Basic was notoriously buggy.

Originally Posted by litwr

8) iconx doesn't allow SKIP, IF, LAB, ...

Err, what? IconX just starts a regular shell. Of course it can use "If".

Originally Posted by litwr

9) only limited preemptive multitasking supported because there is no kill-command in Amiga DOS.

There is none because there is no resource tracking. See below.

[idrougge]

Originally Posted by Thomas Richter

From the shell? Oh, certainly. RequestFile, RequestChoice exist as files. ASK was updated to also retrieve strings.

Note that he said A1000/A500/A2000. There was a lot that was corrected in 2.0 or 3.0.

[duga]

No colour composite output, corrected in A600/A1200. That's about it.

[litwr]

Originally Posted by roondar

Fast RAM for the A500 exists in two forms: "fake" Fast RAM (the cards you put in the trap door slot, also called Slow RAM) and "true" Fast RAM, which is connected to the side slot.

Generally the increase in performance for having true Fast RAM on a 68000 based Amiga is around 10-15%. This increases for faster CPU's.
What I mean is that executables can exit with any return code between -2 billion and +2 billion (IIRC anyway, you get to return a signed long word). It's possible the IF statement doesn't support all of them, but to be honest I don't usually make scripts so I can't verify that.
There is a way to kill tasks on OS 2.0+ (in fact, Exec has a built-in function for it in ROM), but you're correct that it's probably not included as a standard command. I'm 100% certain I have a killtask or some similar command somewhere form the developer CD though, so it is actually possible.

Just use the correct 'nice' statement on Unix. I forget which value to use, but you can hang the entire system like that. Same with Windows all the way up to Windows 10, if you select the correct process and give it high enough priority you can quite easily hang the system.

Anyway, I don't really agree with this to begin with. The scheduler works fine if you use it as instructed. The instructions for changing task priority tell you that you shouldn't increase priorities that high. If you do so anyway, purposefully disregarding how the system works, then that's not the schedulers fault.

Thank you very much for your clarificatons about Fast RAM cards for the Amiga 500. However my misconception about fast RAM for the Amiga 500 has several excuses. All this matter is still rather in dense shadow. Is it a part of something known as the "Commodore curse"?

The fast RAM cards for the Amiga 500 were very rare and expensive. It is sad that even http://amiga.resource.cx/performance.html doesn't have data for such cards. I can actually activate Fast RAM only after I ran FastMemFirst system utility. There is no such program for the A1200 which activates its fast RAM automatically. The results are here. So I can note that Fast RAM for the Amiga 500 provides only about 2% speed boost - it is rather funny.

But you are definetely wrong about return codes. They can have any values but you can use only five of them. It is, indeed, really crazy. IMHO it was a strange Commodore manager who forced engineers to cannibalize normal usage of return codes.

The possibility to kill a process is definitely a part of the proper preemtive multitasking because such kind of multitasking assumes that the system can control its processes. It is well known that TripOS, which was used as a base for Workbench, has a serious flaw - it lacks resource tracking, and this maybe caused a problem with the process kill.

It is sad that you don't want to help people to get a more complete list of the first Amigas drawbacks. It is quite natural for a scientific approach to systematize things.

I have never read a complaint that the nice utility can crash a system. For example, nobody mentions `nice' here - https://unix.stackexchange.com/quest...single-command
The use of `nice' can cause problems - https://www.linuxquestions.org/quest...Wa84FE4E9J8EwQ - but is not the system crash. However you are rather right. But you can't set too high priorities in Unix as a user, it requires rights of superuser. So in Amiga OS, it would be better to use a bit different "mechanics" for working with the priority.

Originally Posted by roondar

You also forgot the counter is down to either 9, 8 or 7 depending on which of my answers you actually intend to take into account

Of course, your answers have made my claims #4 and #10 less valuable. Thank you again. But in new less valuable forms they still exist.

Originally Posted by Thomas Richter

Err, there is no error I am aware of. For timing, use the timer.device. It times correctly.

A hardware timer is very good to use sometimes.

Originally Posted by Thomas Richter

There were link-libraries in 1.3 times to support them. It's not a feature of the A1200 to include wildcard support functions. These came into the dos.library with Kick 2.0 (v37), available for all machines. They have been integrated through the arp project.

There were no such functions in the original stock Amigas 1000/500/2000 - it was a serious drawback. IMHO some ppl still don't upgrade their vanilla hardware.

Originally Posted by Thomas Richter

None is needed. It's directly accessible in the RastPort. It's not related to the machine type.

Thank you, maybe I just missed this. So my claim #3 is deactivated.

Originally Posted by Thomas Richter

Err. No. Simply no.

Please clarify your answer. What is a way to use return codes?

Originally Posted by Thomas Richter

Err, what? IconX just starts a regular shell. Of course it can use "If".

Excuse me but I can give you a cite from AmigaDOS Inside & Out (by Ruediger Kerkloh, Manfred Tornsdorf, Bernd Zoller): "All script files can be started this way, with a few exceptions. IconX executable script files can only contain commands that can be entered directly in AmigaDOS. Commands like Skip, Lab, If, etc. are not allowed".

[roondar]

Originally Posted by litwr

The fast RAM cards for the Amiga 500 were very rare and expensive. It is sad that even http://amiga.resource.cx/performance.html doesn't have data for such cards. I can actually activate Fast RAM only after I ran FastMemFirst system utility. There is no such program for the A1200 which activates its fast RAM automatically. The results are here. So I can note that Fast RAM for the Amiga 500 provides only about 2% speed boost - it is rather funny.

Expensive is debatable, but rare isn't. These things were sold all over the place and Amiga magazines were filled with adverts for them. They were available in large numbers.

The FastMemFirst utility doesn't activate Fast RAM at all. It is merely meant to make the OS allocate "true" fast memory before it allocates "fake" fast memory (i.e. slow memory). It's there for people who have both a trap-door expansion and a side-car expansion on their A500.

As for your benchmark, whether or not you see a performance increase with true Fast RAM on the Amiga 500 is dependent on what the system is doing. Under some situations there will not be much difference between a Chip RAM only A500 and one with Fast RAM, under others it can be as much as 15%. This is because Chip RAM on the A500 is actually fast enough to normally feed the 68000 without wait states (i.e. it already runs mostly at full speed). It's only when you start to saturate the Chip Memory bus with high levels of DMA (such as high resolution GFX in many colours, or using the Blitter) you'll start to see advantages.

But you are definetely wrong about return codes. They can have any values but you can use only five of them.

You have now been corrected on this by both me and Thomas. The latter happens to be one of the current coders of Amiga OS. If you won't accept what he says about what the OS does and doesn't do, then there is no point in me trying.

The possibility to kill a process is definitely a part of the proper preemtive multitasking because such kind of multitasking assumes that the system can control its processes.

Pre-emptive multitasking is a defined technical term and if you look the term up, you'll note definitions of it it never actually mention anything about implementing stopping/killing tasks.

You're re-defining a well known term here. Be my guest, but don't talk about using a scientific approach in that case.

It is sad that you don't want to help people to get a more complete list of the first Amigas drawbacks. It is quite natural for a scientific approach to systematize things.

Me correcting you does not mean I don't want an accurate list. It means I want any such list (regardless of how pointless I might personally think it to be) to at least be accurate rather than just filled with opinions (in this case mostly yours).

I have never read a complaint that the nice utility can crash a system. For example, nobody mentions `nice' here - https://unix.stackexchange.com/quest...single-command
The use of `nice' can cause problems - https://www.linuxquestions.org/quest...Wa84FE4E9J8EwQ - but is not the system crash. However you are rather right. But you can't set too high priorities in Unix as a user, it requires rights of superuser. So in Amiga OS, it would be better to use a bit different "mechanics" for working with the priority.

I've quite literally hung a Sun workstation by accident while doing my computer science studies when I used the command incorrectly to set a user-land process I considered to be harmless to get an extremely high priority rather than a low one (which I intended).

Note here that all mutlitasking OS's around support setting task priorities at levels which can cause serious problems. This is not an Amiga only thing or an Amiga problem. The reason that it's possible is that there are situations in which you do want or need a priority above 20 in Amiga OS. ChangeTaskPri is not designed to be randomly used, it's a system maintenance tool designed for those that know what they're doing.

You might just as well claim that Amiga OS is flawed because it lets you format your boot disk.

Of course, your answers have made my claims #4 and #10 less valuable. Thank you again. But in new less valuable forms they still exist.

Your claim for #4 was that "no fast RAM cards were available for the A500". This is not true at all. You might want to try a new claim that they were 'expensive' or didn't help enough with performance, but those are just your personal opinions and not facts.

Claim #10 was that the multitasking scheduler was weak because using system tools inappropriately can end up hanging the system. I showed you this is an strange claim because these kind of things are possible in many OS's so they're not really an Amiga specific (let alone Amiga 500/1000/2000 specific) problem or drawback.

A hardware timer is very good to use sometimes.

There is nothing in the Amiga stopping you using hardware timers and the timers work fine. The thread you link was answered by people who showed it was your code that had the problem, not the timer. Hardly conclusive evidence, then.

Fundamentally however, if you are running through the OS, you should use the OS's functions for timing. Not doing so and then claiming it's the systems fault is really not that smart. The Amiga has a multitasking operating system, you're not supposed to randomly access the hardware unless you intend to kill the OS to begin with (and there are plenty of people who think you shouldn't do that either). If you leave the OS running, use the OS functionality.

There's really no excuse to not do so. It's an extremely bad practice that won't work on Unix or Windows either.

There were no such functions in the original stock Amigas 1000/500/2000 - it was a serious drawback. IMHO some ppl still don't upgrade their vanilla hardware.

The original PC didn't have 640KB installed, so that's a big downside to it. And because not everyone upgraded their PC, that means it's just a bad system. What kind of logic is that?

Excuse me but I can give you a cite from AmigaDOS Inside & Out (by Ruediger Kerkloh, Manfred Tornsdorf, Bernd Zoller): "All script files can be started this way, with a few exceptions. IconX executable script files can only contain commands that can be entered directly in AmigaDOS. Commands like Skip, Lab, If, etc. are not allowed".

Again, Thomas is one of the OS coders. He knows what it can and can't do. He's the resident expert here.

[litwr]

Originally Posted by roondar

You have now been corrected on this by both me and Thomas. The latter happens to be one of the current coders of Amiga OS. If you won't accept what he says about what the OS does and doesn't do, then there is no point in me trying.

It is really very sad. I have just asked to help with an example. I have searched much but couldn't find any.

Originally Posted by roondar

Pre-emptive multitasking is a defined technical term and if you look the term up, you'll note definitions of it it never actually mention anything about implementing stopping/killing tasks.
You're re-defining a well known term here. Be my guest, but don't talk about using a scientific approach in that case.

No, I am not redefining. I only assume the quite obvious thing that any definition is a part of more general system of definitions. We can understand a particular definition only because we can use their system. I told you about an obvious relation. IMHO it is quite clear that a good system that can switch tasks, can also remove them. It is not a part of a strict official definition but it is very close to it.

Originally Posted by roondar

Me correcting you does not mean I don't want an accurate list. It means I want any such list (regardless of how pointless I might personally think it to be) to at least be accurate rather than just filled with opinions (in this case mostly yours).

Indeed, I have just placed my opinions for a judgement! You and others have just corrected some things. Thanks! But I published those my opinions because things that caused them made me feel uncomfortable.

Originally Posted by roondar

I've quite literally hung a Sun workstation by accident while doing my computer science studies when I used the command incorrectly to set a user-land process I considered to be harmless to get an extremely high priority rather than a low one (which I intended).

It is interesting. However it is not clear did you have the superuser rights then? Anyway I have accepted that my claim #10 is rather weak.

Originally Posted by roondar

Your claim for #4 was that "no fast RAM cards were available for the A500". This is not true at all. You might want to try a new claim that they were 'expensive' or didn't help enough with performance, but those are just your personal opinions and not facts.

You are right. I wrote rather about popular feelings about Fast RAM which were quite common in the 80s and even maybe in the 90s. Commodore didn't provide information that there were also Slow RAM in addition to Fast and Chip RAM. A lot of peple thought that a trap door RAM expansion was Fast or Chip RAM. So we had some falsehood around this matter. Indeed I was wrong that there were not any Fast RAM cards anywhere. So you have helped me to find the truth. But you can also find that my claim has a real background and it is not just my invention.

Originally Posted by roondar

There is nothing in the Amiga stopping you using hardware timers and the timers work fine. The thread you link was answered by people who showed it was your code that had the problem, not the timer. Hardly conclusive evidence, then.

Fundamentally however, if you are running through the OS, you should use the OS's functions for timing. Not doing so and then claiming it's the systems fault is really not that smart. The Amiga has a multitasking operating system, you're not supposed to randomly access the hardware unless you intend to kill the OS to begin with (and there are plenty of people who think you shouldn't do that either). If you leave the OS running, use the OS functionality.

Yes, it is right. But it is very irritating when someone can use hardware timer on the A1200 and can't on the A500. Indeed it is rather a very tiny drawback. Leffmann didn't claim that my code is wrong but he helped me to understand that the Amiga 500 OS changes hardware timer periodically. So I had to use raster interrupts for timings on the A500.

Originally Posted by roondar

The original PC didn't have 640KB installed, so that's a big downside to it. And because not everyone upgraded their PC, that means it's just a bad system. What kind of logic is that?

A change of ROM chips is not that easy that memory expansion in the open IBM PC architecture. I know that some people might not change ROM chips because it could make their Amiga less compatible with old software. The IBM PC architecture has been constantly improving but a Commodore 64 made in 1993 was almost the same as a Commodore 64 fabricated in 1982. Amiga architecture philosophy was closer to IBM PC in this point but it also had relations with the Commodore 64. I addition I have written about drawbacks of the original Amigas, not the upgraded ones.

Originally Posted by roondar

Again, Thomas is one of the OS coders. He knows what it can and can't do. He's the resident expert here.

I am not an Amiga expert. So let express my respect to Thomas. Maybe he has written about modern Amiga OS? But I have just repeated my old experiment with IconX. I made a script

if exists sys:utilities/clock
sys:utilities/clock
endif

and ran it via IconX, I got "If is only valid in command files. If failed returncode 20". This script works perfectly via CLI.

BTW I have upgraded my list in the next post. One new drawback has been added there.

[litwr]

I have upgraded my list of the A1000/500/2000 drawbacks. I have removed 3 items and add one:
1) a minor problem with a timer, you can't normally use it for more than 21 minute interval on the A500, but on the A1200 there is no such limit;
2) no system functions for working with wildcards - these functions was provided only on ROMs available since 1990;
3) misguiding information about trap door RAM expansion cards, no information that the fast RAM only slightly faster than Chip RAM;
4) the mess with "standard" return codes: only 0, 5, 10, 20 are actually allowed;
5) standard utility `ask' provides only two return codes and there is no any other standard way to get information from a user;
6) Basic has only 25 KB free, even the Commodore 128 has 120K, Commodore +4 has 60K, and Commodore 64 has 38K for Basic;
7) iconx doesn't allow SKIP, IF, LAB, ...;
8) no normal variables in CLI like variables in Unix or even DOS shells.

Indeed the Amiga had a lot of advantages. Generally the Amiga in 1986 was better than any other personal computer of that time. But nothing is perfect. The first Amigas had some drawbacks. Why do not try to count them?

[roondar]

Originally Posted by litwr

No, I am not redefining. I only assume the quite obvious thing that any definition is a part of more general system of definitions. We can understand a particular definition only because we can use their system. I told you about an obvious relation. IMHO it is quite clear that a good system that can switch tasks, can also remove them. It is not a part of a strict official definition but it is very close to it.

Yes, you are redefining terms. You even admit to doing so in your text here. Your use of IMHO further cements this point. Note here that the Amiga is not the only pre-emptive multitasking system that has limitations when it comes to stopping/killing tasks. Which yet further shows that it's not a function of pre-emptive multitasking by itself.

Yes, it is right. But it is very irritating when someone can use hardware timer on the A1200 and can't on the A500. Indeed it is rather a very tiny drawback. Leffmann didn't claim that my code is wrong but he helped me to understand that the Amiga 500 OS changes hardware timer periodically. So I had to use raster interrupts for timings on the A500.

There is no difference in the hardware timers between A500/A1200. They work exactly the same because they are the same chip. Timer code is fully portable between the two, it'll work without any changes.

The OS deals with interrupts slightly differently between version though, which is where your problem comes from. Like I already pointed out: if you let the OS run, don't use the hardware timer, but rather use the OS functions. This is true regardless of the system you choose to program for.

Note here that quite literally thousands of programs that use the hardware timers on the A500 just fine. I've done so myself without any issues.

Leffmann pointed out that "The ToD works fine, you're just missing something". That means he's telling you that your method is flawed. Note also that the in very thread you link to, you did end up with working HW timer code. This also shows the hardware timer works just fine and that it's interactions with the OS that you didn't quite understand that are the issue. Again: don't use HW banging code if you want the OS to run. This won't work on other systems either.

A change of ROM chips is not that easy that memory expansion in the open IBM PC architecture. I know that some people might not change ROM chips because it could make their Amiga less compatible with old software.

There is no fundamental difference in difficulty between exchanging old style memory chips and exchanging a ROM chip. It's the literally the same thing (easier for KS roms in some cases as old PC's sometimes only had soldered RAM and KS roms have always been in sockets). As for compatibility, choosing to stick with an old version of the OS is certainly possible. But that doesn't mean it can't be upgraded or this OS upgrade isn't supported by the hardware. So it's not a drawback of the system itself, it's a drawback of choosing to not upgrade - i.e. it's a choice.

3) misguiding information about trap door RAM expansion cards, no information that the fast RAM only slightly faster than Chip RAM;

This is still not true. The A500 manual and advertising (edit: I mean here official material by Commodore) make no claims that memory expansions make the processor run faster. The manual basically only points out that having more memory means you don't need to load as often and that this means your system will be faster overall.

More in depth technical documentation (such as the developer manuals) has always included an explanation of the differences between the various RAM types.

8) no normal variables in CLI like variables in Unix or even DOS shells.

Amiga OS 1.3 CLI does have variables. They just work slightly differently than you're used too. Now, I'll be honest and admit I didn't actually know this (like I said, I don't do much scripting on the Amiga). But on the other hand, I found the answer in about 1 minute of Google time.

Here's part of an example script I copied from another EAB thread I found when Googling this:

LAB Question
echo ""
echo "Bitte wählen Sie das Quell-Laufwerk und Ziel-Laufwerk"
echo "1 = QUELLE df0: ZIEL df1:"
echo "2 = QUELLE df1: ZIEL df0:"
echo "3 = QUELLE df1: ZIEL df2:"
echo "4 = QUELLE df2: ZIEL df1:"
echo "5 = QUELLE df0: ZIEL df2:"
echo "6 = QUELLE df2: ZIEL df0:"

SETENV >NIL: choice ?

IF $choice NOT VAL GT 0
echo "Falsche Eingabe bei der Auswahl des Quell und Ziel Laufwerks."
wait 1
SKIP BACK Question
ENDIF

IF $choice GE 7
echo "Falsche Eingabe bei der Auswahl des Quell und Ziel Laufwerks."
wait 1
SKIP BACK Question
ENDIF

The above code sets and uses the variable $choice

[alkis]

Originally Posted by litwr

4) the mess with "standard" return codes: only 0, 5, 10, 20 are actually allowed;

Stop trolling.

[idrougge]

Originally Posted by litwr

8) no normal variables in CLI like variables in Unix or even DOS shells.

What is a normal variable and in what way doesn’t AmigaShell have those?

[a/b]

Originally Posted by litwr

1) a minor problem with a timer, you can't normally use it for more than 21 minute interval on the A500, but on the A1200 there is no such limit;

Wrong and wrong. You can configure timer B to count timer A underflows, making them work together as a 32-bit timer (65536*21 minutes). On any Amiga. Furthermore, it's called a high precision timer for a reason. And being able to measure long intervals is not that reason.

Originally Posted by litwr

2) no system functions for working with wildcards - these functions was provided only on ROMs available since 1990;

Ambiguous claim, but I'll say wrong and wrong. Generally speaking, system functions don't work with wildcards. Try open(), fopen(), OpenFile(), ... with "*" on any Unix-like system or windoze and report what happens.
Examine() and ExNext() are available on any Amiga.

Originally Posted by litwr

6) Basic has only 25 KB free, even the Commodore 128 has 120K, Commodore +4 has 60K, and Commodore 64 has 38K for Basic;

It's written by satansoft, expecting anything more than a dumpsterfire is not realistic.

The rest is mostly nonsense, but since Amiga shell is not my area, and what little I knew is mostly gone, so I won't comment.

[lilwshu]

A2000: Case is the size of a small house yet you can only fit 2x3.5" and 1x5.25" devices in it.

[alkis]

Originally Posted by litwr

6) Basic has only 25 KB free, even the Commodore 128 has 120K, Commodore +4 has 60K, and Commodore 64 has 38K for Basic;

Maybe you want to RTFM?
https://issuu.com/ivanguidomartucci/...ic---ebook-eng page 96

[roondar]

Originally Posted by alkis

Maybe you want to RTFM?
https://issuu.com/ivanguidomartucci/...ic---ebook-eng page 96

So, you can have essentially any size program and are limited purely by available memory, just by using the CLEAR command?

Now, I never actually programmed in Amiga Basic, so I didn't know this. But I suppose this was common knowledge (what, with it being in the manual and all)?