What could Atari have done better with the ST?

[Cyprian]

And why is call from only user mode possible better than some trap ?

from technical point of view Amiga's motherboard doesn't support User/Supervisor mode.
Amiga was created as a console and designers decided that functionality isn't needed and they just didn't implement it (as it is in Atari).
Therefore finally, all programs by default have access to all memory, like low memory $0-$400 and also all hardware registers.

[dlfrsilver]

And why is call from only user mode possible better than some trap ?

from technical point of view Amiga's motherboard doesn't support User/Supervisor mode.
Amiga was created as a console and designers decided that functionality isn't needed and they just didn't implement it (as it is in Atari).
Therefore finally, all programs by default have access to all memory, like low memory $0-$400 and also all hardware registers.

This is the first time i heard about this. The User and Supervisor modes are tied to the 68000. It's clearly stated in the Amiga bible that you can't have full access to the hardware without activating Supervisor mode.

Just try to access restricted functions of the Amiga in user mode when supervisor mode is required, and you will see what happens

PS : What about the ST ? (should be the same).

[AtariZoll]

And why is call from only user mode possible better than some trap ?

from technical point of view Amiga's motherboard doesn't support User/Supervisor mode.
Amiga was created as a console and designers decided that functionality isn't needed and they just didn't implement it (as it is in Atari).
Therefore finally, all programs by default have access to all memory, like low memory $0-$400 and also all hardware registers.

That's wrong explanation. User/supervisor is matter of CPU. In case of Atari ST, glue chip is what gives bus error if RAM below $800 is accessed in user mode. I repeat: all interrupts, traps and other exceptions are always executed in supervisor mode.

[shoggoth]

This is the first time i heard about this. The User and Supervisor modes are tied to the 68000. It's clearly stated in the Amiga bible that you can't have full access to the hardware without activating Supervisor mode.

Just try to access restricted functions of the Amiga in user mode when supervisor mode is required, and you will see what happens

PS : What about the ST ? (should be the same).

Hardware registers are available in user mode afaik. That's not the case on the ST, which also protects <0x800.

[Frank B]

This is the first time i heard about this. The User and Supervisor modes are tied to the 68000. It's clearly stated in the Amiga bible that you can't have full access to the hardware without activating Supervisor mode.

Just try to access restricted functions of the Amiga in user mode when supervisor mode is required, and you will see what happens

PS : What about the ST ? (should be the same).

Hardware registers are available in user mode afaik. That's not the case on the ST, which also protects <0x800.

As a bonus they tend to be read and write on the ST. On the Amiga they are read or write. That's why you have duplicate registers like dmaconr and dmacon.

The ST is fully 68000 compatible too. The Amiga isn't.. Don't try and use TAS from code running in chip RAM. Hard reset time if you do.

[Frank B]

This is the first time i heard about this. The User and Supervisor modes are tied to the 68000. It's clearly stated in the Amiga bible that you can't have full access to the hardware without activating Supervisor mode.

Just try to access restricted functions of the Amiga in user mode when supervisor mode is required, and you will see what happens

PS : What about the ST ? (should be the same).

Hardware registers are available in user mode afaik. That's not the case on the ST, which also protects <0x800.

100% correct. User mode programs on the Amiga can poo over any register or CPU vector. On the ST they can't.

[Cyprian]

This is the first time i heard about this.

I'm completely not surpprised. You proved many times that you knowledge about your Amiga is really limited.

The User and Supervisor modes are tied to the 68000. It's clearly stated in the Amiga bible that you can't have full access to the hardware without activating Supervisor mode.

Just try to access restricted functions of the Amiga in user mode when supervisor mode is required, and you will see what happens

Please prove that is true and provide test application with source code.

That's wrong explanation. User/supervisor is matter of CPU. In case of Atari ST, glue chip is what gives bus error if RAM below $800 is accessed in user mode. I repeat: all interrupts, traps and other exceptions are always executed in supervisor mode.

Hmm, the motherboard (I mean one of its chipset) based on FC codes (User/Supervisor mode) should generate the bus error in case of access to defined memory areas. In case of Amiga, motherboard doesn't care about FC codes - therefore it doesn't support User/Supervisor mode.

[joska]

And why is call from only user mode possible better than some trap ? Function table ? That's very inappropriate name of something what is much more than function table. What is that "function table" if not OS call ?

Did I say it wasn't an OS call? Please read again The Amiga calls the OS via pointers, not via traps. Basically the AmigaOS OS-calls can be regarded as libraries.

I must say that it is not proper preemptive if depends on app and how often it will process that OS access - to call it so. Unless someone is very wrong about how Amiga really switching apps.

Yes, you are very wrong Workbench/AmigaOS pre-empts any process at any time - even when the process is in the middle of executing an OS function (unlike e.g. MiNT) like reading a file from floppy. But a process can *prevent* task-switching from happening by calling an OS function specifically designed to do this. OK, this is not considered "proper" in today's operating systems, but todays computers are about one gazillion times faster and have 10.000 times as much RAM. You can afford spending resources on the OS while playing games on modern computers. But you wouldn't want to play games on an Amiga 500 if the game couldn't be in charge of the resources.

[dlfrsilver]

Please prove that is true and provide test application with source code.

Just stop talking poo and look here :

"While in supervisor mode, you have complete access to all data and registers, including those used for task scheduling and exceptions, and
can execute privileged instructions."

=> this means that in user mode you CAN'T access to all data registers ! And you can't execute priviledge instructions.

You just showed your own lack in 68000 knowledge, never mind the knowledge of the Amiga hardware/architecture !

Most Amiga programs are using the supervisor mode in order to get full access to the machine.

Just to give a few example : All the copy protections requires the Amiga to pass in supervisor mode (RNC copylock, etc). If you don't it will just crash !!

Why ? Because you need for that to set an exception, and this exception allows to pass from user mode to supervisor mode !

And this is just one of the few examples

When a game use a Trace Vector Decoder, you really think you can make it in user mode ?

Do you understand now why Atarizoll said you were giving a wrong explanation. So now you can apologize for saying such a crap.

Go back to the 68000 programming book, you need it !

[Arne]

I'm completely not surpprised. You proved many times that you knowledge about your Amiga is really limited.:

Simbo is gone... no need for starting new wars

(...)
Just try to access restricted functions of the Amiga in user mode when supervisor mode is required, and you will see what happens

Please prove that is true and provide test application with source code.

I never had an Amiga (too expensive at that time), and I will not start an issue on this topic. Just some remarks/questions.
Glue does receive FCx, so it will probably use them to some degree. It does get the whole addressbus either, so it can restrict access to certain address ranges. Either in supervisor or usermode (first doesn't make sense IMHO).
Anyway: how does the Amiga react on a move <ea>, SR instruction which is only allowed in supervisor mode? I'd say this is a pretty important instruction. I don't know about tas instruction in preemptive OS (Amiga does have preemptive OS IIRC?).

[rabindranath72]

But a process can *prevent* task-switching from happening by calling an OS function specifically designed to do this. OK, this is not considered "proper" in today's operating systems, but todays computers are about one gazillion times faster and have 10.000 times as much RAM. You can afford spending resources on the OS while playing games on modern computers. But you wouldn't want to play games on an Amiga 500 if the game couldn't be in charge of the resources.

I suppose that's the point: you can't really call the OS pre-emptive if a task has the option of altering the OS's policy. I agree that as a practical matter, it was probably necessary.

[dlfrsilver]

I never had an Amiga (too expensive at that time), and I will not start an issue on this topic. Just some remarks/questions.
Glue does receive FCx, so it will probably use them to some degree. It does get the whole addressbus either, so it can restrict access to certain address ranges. Either in supervisor or usermode (first doesn't make sense IMHO).
Anyway: how does the Amiga react on a move <ea>, SR instruction which is only allowed in supervisor mode? I'd say this is a pretty important instruction. I don't know about tas instruction in preemptive OS (Amiga does have preemptive OS IIRC?).

You must trigger a 68000 exception first interrupt or Trap (it triggers the supervisor mode) before using "move <ea>, SR". This instructions only works in supervisor mode, and this instruction must no be used to go in Supervisor mode.

Yes the amiga OS is pre-emptive

[joska]

I suppose that's the point: you can't really call the OS pre-emptive if a task has the option of altering the OS's policy.

Is an automatic gearbox still automatic if you can override it?

There's a lot of things I like about Workbench/AmigaOS. But the hardware wasn't ready for it. I had an Amiga500 but traded it for a 1040 pretty quick because the Amiga was pretty much unusable in stock condition. You'd need atleast two floppy drives to avoid constant disk swapping, and to be honest the hardware was just too slow for such an OS. TOS was much better for my use - faster disks, DOS-compatibility, complete OS in ROM and a GUI that was atleast a little bit userfriendly. Not to mention that I got a faster CPU and twice as much RAM for less than I sold the Amiga for

[AtariZoll]

Did I say it wasn't an OS call? Please read again The Amiga calls the OS via pointers, not via traps. Basically the AmigaOS OS-calls can be regarded as libraries.

You must call things with proper names. There is instruction, code what performs OS call. Pointer, tables are not it. Library is not that. So, you still owe me the proper answer: with what instruction, code some app can access task scheduler of OS ? And as I know, you did some coding in ASM, so should really know it better.

Yes, you are very wrong Workbench/AmigaOS pre-empts any process at any time - even when the process is in the middle of executing an OS function (unlike e.g. MiNT) like reading a file from floppy. But a process can *prevent* task-switching from happening by calling an OS function specifically designed to do this. OK, this is not considered "proper" in today's operating systems, but todays computers are about one gazillion times faster and have 10.000 times as much RAM. You can afford spending resources on the OS while playing games on modern computers. But you wouldn't want to play games on an Amiga 500 if the game couldn't be in charge of the resources.

Well, I said "Unless someone is very wrong about how Amiga really switching apps." . And it was not you, and not dlfrsilver
I don't see as some big achievement that function what makes some app as only running one. Simple to solve.
Modern OS. like Windows XP performs lot of threads all time, even if no app is running. Equivalent of that in oldies would be V-blank service rutine and Timer-C (in Atari ST case) s.rut And there were some near to multitasking functions in TOS: ACCessories for instance. Vblqueue . So, to be really precise, TOS was not single task, it was on doorstep to multitasking

[Arne]

I suppose that's the point: you can't really call the OS pre-emptive if a task has the option of altering the OS's policy.

Is an automatic gearbox still automatic if you can override it?

Good point!

I see it this way: in the office I am programming embedded software. We are using an RTOS (nothing bloated like Linux, the one we use just needs a couple of KB of Flash memory). The RTOS is preemptive, i.e. any thread gets interrupted 1000 times a second and the RTOS-scheduler is called. If I design a thread that never releases the CPU by waiting on a RTOS event and does have the highest priority then all other threads will starve. Still it is preemptive by design!

[rabindranath72]

I suppose that's the point: you can't really call the OS pre-emptive if a task has the option of altering the OS's policy.

Is an automatic gearbox still automatic if you can override it?

There's a lot of things I like about Workbench/AmigaOS. But the hardware wasn't ready for it. I had an Amiga500 but traded it for a 1040 pretty quick because the Amiga was pretty much unusable in stock condition. You'd need atleast two floppy drives to avoid constant disk swapping, and to be honest the hardware was just too slow for such an OS. TOS was much better for my use - faster disks, DOS-compatibility, complete OS in ROM and a GUI that was atleast a little bit userfriendly. Not to mention that I got a faster CPU and twice as much RAM for less than I sold the Amiga for

Well, it's a useful feature if you don't risk breaking the car by overriding it!

I agree with your points; I could not afford an Amiga, but after seeing it in use back in the day, I wasn't really impressed, so I stayed with my cheaper Atari

[shoggoth]

Please prove that is true and provide test application with source code.

Just stop talking poo and look here :

"While in supervisor mode, you have complete access to all data and registers, including those used for task scheduling and exceptions, and
can execute privileged instructions."

=> this means that in user mode you CAN'T access to all data registers ! And you can't execute priviledge instructions.

You just showed your own lack in 68000 knowledge, never mind the knowledge of the Amiga hardware/architecture !

Most Amiga programs are using the supervisor mode in order to get full access to the machine.

Just to give a few example : All the copy protections requires the Amiga to pass in supervisor mode (RNC copylock, etc). If you don't it will just crash !!

Why ? Because you need for that to set an exception, and this exception allows to pass from user mode to supervisor mode !

And this is just one of the few examples

When a game use a Trace Vector Decoder, you really think you can make it in user mode ?

Do you understand now why Atarizoll said you were giving a wrong explanation. So now you can apologize for saying such a crap.

Go back to the 68000 programming book, you need it !

Take a huge chill pill.

[Frank B]

Take a huge chill pill.

Amiga persecution complex

I thought I remembered Roger was 50 hz. Need to set up my STe and look again
In any case there are several 50 hz games which use the blitter on the STE. The blitter is fast enough for 50 hz scrolling but it's a rather heavy weight way to do so.

As an experiment DFRsilver. Try the following on both machines in user mode.

On the ST: move.w #0,$ff8240
On the Amiga: move.w #0,$dff180

One will barf and one won't. Which behaviour is better?

[wongck]

What could Atari have done better with the ST?

Follow the footsteps of a successful 68000 computer that the ST was competing with and may be today we will have an Intel hardware version.
enough said.

[joska]

You must call things with proper names. There is instruction, code what performs OS call. Pointer, tables are not it. Library is not that. So, you still owe me the proper answer: with what instruction, code some app can access task scheduler of OS ? And as I know, you did some coding in ASM, so should really know it better.

English neither mine nor yours primary language, as clearly demonstrated here...

It's very simple - in TOS you call OS functions by putting some parameters on the stack and execute a trap #N instruction. In AmigaOS you don't. To put it simple you have an array of function pointers, look up the correct one for the function you want to call and JSR to it.

Library would be the correct term for this. That is even the name used by Workbench/AmigaOS itself.

There are two (?) Workbench library/OS-calls used to enable and disable multitasking. I can't remember their names right now, I haven't really *used* an Amiga since I got rid of that 500 in 1989... Unless a process disable multitasking the kernel will pre-empt any process at any time, regardless of what the process is doing. Even if it's in the middle of executing an OS library function.

I don't see as some big achievement that function what makes some app as only running one. Simple to solve.

Yes of course. I never said it was rocket science.

And there were some near to multitasking functions in TOS: ACCessories for instance. Vblqueue . So, to be really precise, TOS was not single task, it was on doorstep to multitasking

TOS was far from multitasking. There is a reason why real multitasking has been achieved only by replacing atleast the entire AES.

[Cyprian]

"While in supervisor mode, you have complete access to all data and registers, including those used for task scheduling and exceptions, and
can execute privileged instructions."

=> this means that in user mode you CAN'T access to all data registers ! And you can't execute priviledge instructions.

you are mixing two completely different things: privileged instructions / CPU registers with Hardware Registers like DMACON $dff096 / DMACONR $dff002 / INTREQ $dff09c / INTREQR $dff01e
Again, I'm not surprised by that because you proved many times, that you have a limited knowledge about Amiga and much less about ST and 68000.

In 68000 CPU vectors (like TRAP, Buss Error, Trace) are protected from writing/reading if CPU is in UserMode. It works fine in ST, but not in Amiga due to faulty design (the next one beside issue with TAS instruction, bitplane stealing unused cycles from blitter ). Finally, Amiga motherboard doesn't support User/Supervisor mode, you can write/read Hardware Registers like DMACON from User mode. It means that application can unintentionally overwrite CPU Vectors, hardware registers, destroy multitasking. etc

[AtariZoll]

...
In AmigaOS you don't. To put it simple you have an array of function pointers, look up the correct one for the function you want to call and JSR to it.
Library would be the correct term for this. That is even the name used by Workbench/AmigaOS itself. ....

Well, then it is just subroutine call, done in some slow fashion, it seems. And why APP must look in tables instead OS ? Seems not much wise.
Fastest way would be something like: reading OS routine address from some defined system variable or ROM address to a0, putting parameters in data registers - as much as needed, and perform jsr (a0) . Short code, no stack usage for parameters.
And as "greatest" benefit: CPU must not enter supervisor mode
Simpler would be with some trap. Maybe Amiga just wanted to do everything different than usual ways ?

[Frank B]

He needs to read the Amiga Hardware Reference Manual. Seriously.

[Frank B]

Simpler would be with some trap. Maybe Amiga just wanted to do everything different than usual ways ?

Perhaps they just wanted everything except exec and interrupt handlers to be in user space. It's a very clever and elegant design.
It hurt later on however. They couldn't allow for data caching chip ram for instance. Any app can own the blitter and use it directly.
There's no clean system interface to it. On the Falcon the VDI can flush the data cache after every operation. That allows for caching DMA able memory.
There is one clearly defined interface to accessing the blitter on the ST.

[dlfrsilver]

As an experiment DFRsilver. Try the following on both machines in user mode.

On the ST: move.w #0,$ff8240
On the Amiga: move.w #0,$dff180

One will barf and one won't. Which behaviour is better?

So what ? The amiga palette color 00 register $DFF180 is a user mode instruction. And that's unrelated to user/supervisor mode of the 68000 processor.

You're comparing apples and oranges. Both hardware are different.