Quote:
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.
Quote:
|
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.
Quote:
|
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.
Quote:
|
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'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.
Quote:
|
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.
Quote:
|
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.
Quote:
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?
Quote:
|
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.