What could Atari have done better with the ST?

[Frank B]

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.

You're really not getting it. Let me try and explain for you again.
$dff180 is a chip register location on the Amiga. Its analog on the ST is $ff8240.

The ST has a form of memory protection where user mode programs (think of them as non root) cannot corrupt them.
Both the vector table and the chip locations are protected from user mode access on the ST. User mode programs can't trap a trap handler or CPU exception handler. User mode programs can't crap all over IO registers. They have to either be in supervisor mode or access them via the OS.

The Amiga has no such protection mechanism. Any process can crap all over the machine. The ST is far better in this regard.

[Cyprian]

please decide whether:

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

or

It's clearly stated in the Amiga bible that you can't have full access to the hardware without activating Supervisor mode.

[shoggoth]

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.

Nah, it's not unrelated, since the 68k CPU allows you to have privilege levels assigned to different memory regions. You're right when it comes to the fact that AmigaOS partly runs in supervisor mode, the opposite wouldn't be possible since exceptions for obvious reasons end up in supervisor mode, and certain instructions require supervisor privilege. After all, the Amiga does have a 68k CPU. We all know that, no need to go teenage about it.

AmigaOS and the Amiga does however not exploit supervisor mode beyond that, and that's the point certain posters made.

[joska]

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.

Exactly, it's a subroutine. I think it's rather clever. It also means that Workbench can load further libraries and treat these exactly like the system libraries. The Amiga has used clever (and clean) system extensions like this since day one.

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.

This is pretty much what you do on the Amiga (although not sure about parameter passing). Something like this (from memory, as I said I haven't done this since the late 80's...):

move.l a6,-(sp)
lea librarybase,a6
jsr function(a6)
move.l (sp)+,a6

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 ?

Why would a trap be simpler? Yes, on the ST this may be true because many OS-functions needs to go to supervisor-mode to access hw anyway. But as others have pointed out this is not necessary on the Amiga. A simple jsr is quicker than a trap too.

A nice sideeffect of this strategy is that the OS *has* to be cleanly written, as the OS itself will be pre-empted. So everything must be thread-safe. Which is something no TOS has ever been remotely close to be.

[AtariZoll]

Joska: you said: "you have an array of function pointers, look up the correct one for the function you want to call and JSR to it."
Look up the correct one - that means in computer terminology to use table and calculate which value to choice. Then you come with: lea librarybase,a6
jsr function(a6) - what is pretty much different - just using constant displacement. Now, that librarybase must be on some constant loc, and that would be ROM only then, so it was not exactly like that. Especially if it should be expandable. So, pointers must be in RAM.
Trap was not invented by Atari or Digital Research. That's 68000 design in purpose. Trap is just not slower than picking some address from somewhere and perform jsr . Idea with trap was not to use it in supervisor mode because access to HW registers (which must be not always privileged - in Falcon for instance) . Lot of GEMDOS traps accessing no any HW registers. It is just way to use short opcode (2 bytes) instead 6 byte jsr (or even more if must pick address from somewhere) and in RAM placed vector, according to current location of OS or expansion code. C64 has lot of jumptables to allow ROM subrutine calls even if change their address in later revisions. Trap is more advanced way for that, indeed.
All it has nothing with cleanness. We need efficiency - this is not kitchen or garden What is not clean in OS running in supervisor mode ? Can CPU be interrupted when is in supervisor mode ? So, OS function can be preempted too. I see here lot of confusion in opinions about. And app can run in supervisor too more or less time - what has nothing with thread safety. Safety is discussed here already - memory protection in first place.

I'm thinking about why Desktop accessories were not more used as some main applications - for instance word processing or similar. With that, you could easily switch between apps, without closing any. There is even way of data exchange in AES. Probably it's because not well solved loading of accessories. User needs to place all them in ROOT of disk, and restart - so pretty much not flexible way. DR should solve it better - maybe just adding function to place APPs title in Desktop menu and exit to Desktop - but leaving it in RAM. Then could run other APP, or go back to some already "menuized" one. Of course, there should be option to exit and remove APP completely.

[shoggoth]

It's fairly obvious that a trap + switch to supervisor mode is slower than a function call, AtariZoll. It needs at ~3 times as many bus accesses, and on the other side is there's the function dispatcher which I can guarantee you is fairly ugly compared to the AmigaOS calling convention, adding even more. It does however mean we got the supervisor switch, which would otherwise have to be added on the "other" side of the call.

[AtariZoll]

It's fairly obvious that a trap + switch to supervisor mode is slower than a function call, AtariZoll. It needs at ~3 times as many bus accesses, and on the other side is there's the function dispatcher which I can guarantee you is fairly ugly compared to the AmigaOS calling convention, adding even more. It does however mean we got the supervisor switch, which would otherwise have to be added on the "other" side of the call.

Trap # takes 36 cycles. jsr takes 20 . That self is not 3:1 . And if you add cycles to get subroutine address then trap will be faster. I will not go here in how good is solved function dispatcher switch in TOS - we talk about Amiga so called (by some, I really have no opinion about it) multitasking

[galax]

I'm thinking about why Desktop accessories were not more used as some main applications - for instance word processing or similar. With that, you could easily switch between apps, without closing any.

Multidesk later allowed desk accessories to be loaded and unloaded on the fly, releasing the precious RAM they used, a big deal for many of us before 2MB and 4MB upgrades became more common. If this ability had been there from day 1 they would probably have been used a lot more for suites of applications.

[shoggoth]

It's fairly obvious that a trap + switch to supervisor mode is slower than a function call, AtariZoll. It needs at ~3 times as many bus accesses, and on the other side is there's the function dispatcher which I can guarantee you is fairly ugly compared to the AmigaOS calling convention, adding even more. It does however mean we got the supervisor switch, which would otherwise have to be added on the "other" side of the call.

Trap # takes 36 cycles. jsr takes 20 . That self is not 3:1 . And if you add cycles to get subroutine address then trap will be faster.

You have an additional function dispatcher *after* the trap - which is a subroutine. Which is larger: [subroutine] or [subroutine + trap]?

I will not go here in how good is solved function dispatcher switch in TOS - we talk about Amiga so called (by some, I really have no opinion about it) multitasking

EDIT: Oops. I answered your post before reading that last sentence properly. Happy trigger finger.

[shoggoth]

EDIT: double post.

[AtariZoll]

You have an additional function dispatcher *after* the trap - which is a subroutine. Which is larger: [subroutine] or [subroutine + trap]?
...

What comes after trap or jsr depends from how OS is solved, and how much subfunctions should that OS call to serve. But all this hunt for couple cycles and talk what is faster has no sense, really. Such calls are not performed so often, that it will affect speed of running SW. OS is there to perform execution of frequent tasks, and should provide simple and low RAM using way for calling them. And trap is what can it best. If APP needs to seek adress in some tables and similar, that's not good way. This is how I see good OS. Talking about some cleanness, and need for user mode is really not argumented here. Especially in case of Amiga without mainboard support for memory protection in user mode.

[joska]

Joska: you said: "you have an array of function pointers, look up the correct one for the function you want to call and JSR to it."
Look up the correct one - that means in computer terminology to use table and calculate which value to choice. Then you come with: lea librarybase,a6
jsr function(a6) - what is pretty much different - just using constant displacement. Now, that librarybase must be on some constant loc, and that would be ROM only then, so it was not exactly like that. Especially if it should be expandable. So, pointers must be in RAM.

I'm not going to argue about semantics (ref. your definition of "look up"), just point out that I was trying to explain why Workbench' OS functions are not running in Supervisor mode as one poster pointed out. Sure, you could probably TRAP instead of JSR, but why? It doesn't matter if you're in supervisor mode or not, so why force it? And why add a trap handler with a function dispatcher if you don't have to?

Amiga OS function calling is very simple.

And app can run in supervisor too more or less time - what has nothing with thread safety. Safety is discussed here already - memory protection in first place.

Please start reading more carefully before you post. I have never said that thread-safe has anything to do with supervisor or not. Of course it hasn't. Read again - Workbench can pre-empt any process, even when the process is in the middle of running some OS library function. So the OS library functions must be thread-safe. And this is A Good Thing.

I'm thinking about why Desktop accessories were not more used as some main applications - for instance word processing or similar.

Desk accessories can't be unloaded, can't have a menu, can't allocate memory (well, you can but won't be freed until a reset) and only works when the main application is waiting inside some evnt_-loop. Nevertheless there were a lot of accessories that tried to replace "proper" applications. The biggest problem was that in a time where the majority of users had 512 or 1024kb you really couldn't multitask anyway. And this is partially why the A500 was such a pain to work with. I have an A600 with 6Mb RAM and a harddrive, now Workbench starts to make sense. Even though the UI is still quite horrible you can atleast work efficiently with multitasking.

[AdamK]

It's fairly obvious that a trap + switch to supervisor mode is slower than a function call, AtariZoll. It needs at ~3 times as many bus accesses, and on the other side is there's the function dispatcher which I can guarantee you is fairly ugly compared to the AmigaOS calling convention, adding even more. It does however mean we got the supervisor switch, which would otherwise have to be added on the "other" side of the call.

Trap # takes 36 cycles. jsr takes 20 . That self is not 3:1 . And if you add cycles to get subroutine address then trap will be faster.

You have an additional function dispatcher *after* the trap - which is a subroutine. Which is larger: [subroutine] or [subroutine + trap]?

Dispatcher could be implemented as a simple jumptable (it is a jumptable in FreeMiNT) which is not very expensive. There are much more expensive things on OS entry / OS exit to do, so really, TRAP vs. JSR is not the important thing to argue.

The problem (I see) in AmigaOS JSR method, is that, other then Exec, there is no guarantee that a library will be available at the same offset. Some usually are and were, but that changed later on, and some software did not work on more modern AmigaOS versions, because of that, and required patching.

The problem (I see) in TOS, is that there was no clean way to expand the system and add additional functions. This lead to the ugly XBRA standard which, while solves the problem, is an ugly hack and introduces a dispatcher after a dispatcher and so on (FreeMiNT more or less solved it for its extensions, but legacy stuff remains.

[AtariZoll]

[
I'm not going to argue about semantics (ref. your definition of "look up"), just point out that I was trying to explain why Workbench' OS functions are not running in Supervisor mode as one poster pointed out. Sure, you could probably TRAP instead of JSR, but why? It doesn't matter if you're in supervisor mode or not, so why force it? And why add a trap handler with a function dispatcher if you don't have to?
Amiga OS function calling is very simple....
Please start reading more carefully before you post. I have never said that thread-safe has anything to do with supervisor or not. Of course it hasn't. Read again - Workbench can pre-empt any process, even when the process is in the middle of running some OS library function. So the OS library functions must be thread-safe. And this is A Good Thing. ...
Desk accessories can't be unloaded, can't have a menu, can't allocate memory (well, you can but won't be freed until a reset) and only works when the main application is waiting inside some evnt_-loop. Nevertheless there were a lot of accessories that tried to replace "proper" applications. The biggest problem was that in a time where the majority of users had 512 or 1024kb you really couldn't multitask anyway. And this is partially why the A500 was such a pain to work with. I have an A600 with 6Mb RAM and a harddrive, now Workbench starts to make sense. Even though the UI is still quite horrible you can atleast work efficiently with multitasking.

Nothing is simpler than using trap, designed specially for that - OS function call. We talking here about supervisor mode and related. I don't see why you came at all with thread-safe issue. It has nothing with way how function call is solved.
Then, you say me that read more carefully ... and then you start blah about what Desktop ACCessories can not do Read it again, and you will see that I talked about what Atari/DR should do, and there is even removal from RAM mentioned
I don't agree that there was no enough RAM. In 512 KB there is normally some 350 KB free space. Well done SW (ASM for instance) must not use lot of RAM. There are nice utils taking only 10-150 KB RAM.

[rabindranath72]

The problem (I see) in AmigaOS JSR method, is that, other then Exec, there is no guarantee that a library will be available at the same offset. Some usually are and were, but that changed later on, and some software did not work on more modern AmigaOS versions, because of that, and required patching.

There's only one fixed address in AmigaOS, I think it was 0x400. All other addresses weren't guaranteed to be the same from one version to the other, but this is clearly documented IIRC. If apps didn't work anymore, the fault was of the developer who didn't follow Commodore's recommendations.

[joska]

We talking here about supervisor mode and related. I don't see why you came at all with thread-safe issue. It has nothing with way how function call is solved.

Let me quote myself:

A nice sideeffect of this strategy (pre-empt not only user code, but also the OS functions) is that the OS *has* to be cleanly written, as the OS itself will be pre-empted. So everything must be thread-safe. Which is something no TOS has ever been remotely close to be.

I had the impression that we were discussing whether Workbench was pre-emptive or not. But apparently not anymore

Anyway, please bear in mind that Exec is (or atleast attempts to be) a microkernel. Treating as much as possible of the OS as subroutines is exactly the point. While supervisor/user really doesn't matter much in the Amiga, it makes a difference in 68000 designs in general. And Workbench was not Commodore's invention, it's an adaption of an already existing 68000 OS.

Then, you say me that read more carefully ... and then you start blah about what Desktop ACCessories can not do Read it again, and you will see that I talked about what Atari/DR should do, and there is even removal from RAM mentioned

I did not comment your suggested improvements, it was a response to this:

I'm thinking about why Desktop accessories were not more used as some main applications - for instance word processing or similar.

Maybe I misunderstood you. Anyway, Geneva proved already in the early 90's that GEM applications can be multitasked, even though it's "just" cooperative multitasking. Atari could have done this themselves if they had the time and resources. Or foresight!

I don't agree that there was no enough RAM. In 512 KB there is normally some 350 KB free space. Well done SW (ASM for instance) must not use lot of RAM. There are nice utils taking only 10-150 KB RAM.

Most software was *not* written in assembler, and a lot of software really needed most of the available megabyte for itself. It doesn't matter if the instructions are few if they handle "large" data. The Amiga suffered badly from this, together with the disk swapping *hell* when you attempted to actually multitask on a plain 500. The ST was much better in it's stock form. Yes, the OS was simpler and quite badly implemented, but it was much more usable in real life when you were a poor student with a plain 1040. However, Workbench became much better later on when users could afford RAM-expansions and mass storage. TOS really didn't improve much.

Anyway, it's refreshing to see that you've changed your mind about multitasking. Not that long ago you deemed the ST unsuitable for that

[AtariZoll]

I did not say that TOS is suitable or not for multitasking. After all, they worked on MultiTOS around 1992. Things are, that I did not miss it when I worked on Atari. For programming with good development SW it was really not necessary. And I had lot of RAM already in 1988.
Actually, my idea about diverse way of using ACCessories was realized in task switchers - like Twist. But I never used it, just tried once.

After all posts about Amiga, multitasking, supervisot/user blah, let me summarize my opinion on topic:

1. HW fine scroll like in STE - so video base possible at any even address, + support for pixelwise hor. shift in range 1-15 px . That would need only some + logic and registers in shifter and MMU.

2. Universal expansion bus - with complete CPU bus, other relevant signals, so can attach RAM expansions, hard disk adapters, video cards etc ...

3. Better TOS - maybe best and not to complicated improvement would be better and easier usable load of resident SW (called Desktop ACCessories as it was done) - so it could be more of in RAM (max 6 ACCessory was possible at once) , and then could simply switch between with mouse or some hotkeys.
Concrete realization would mean that regular AES APP can be started in normal way, but there should be extra option to exit to Desktop without terminating it. And there must be point in code where reenter leads. Additionally, some hotkeys handled by OS would make APP switch even easier.
Unlike Joska, I think that it would be most useful for people without hard disks, to avoid slow floppy loads and swaps.

[AtariZoll]

This thread is so boring without some screenshots, so I feel need to post some:

ACCramfree1.png

ACCramfree2.png

ACCramfree3.png

ACCramfree4.png

Did it with TOS 2.06 just because it has opt. to show free RAM, same is in all other TOS versions. After removing RDISK (3rd pic) there is again all RAM available, and no restart was used. Someone here said: " can't have a menu, can't allocate memory (well, you can but won't be freed until a reset) "
Even about menu is wrong - I see nice menu on screenshot OK, Joska probably meant drop down menu. That would be little harder with ACCs, but possible. However, my point was that instead ACC could be some better system, and then every APP could have own drop down menu as usual.

[qq1975b]

Sprite controller makes sense besides the hardware scrolling?

[joska]

Did it with TOS 2.06 just because it has opt. to show free RAM, same is in all other TOS versions. After removing RDISK (3rd pic) there is again all RAM available, and no restart was used. Someone here said: " can't have a menu, can't allocate memory (well, you can but won't be freed until a reset) "

Of course, "anything" is possible if you invent your own way of doing it. A brilliant way of preventing your stuff from working with future versions of the OS.

Accessories can't be unloaded under any TOS. Yes, you can use hacks like Chameleon that does this for you. I used it for a long time.
Also, memory allocated (and by that I mean allocated properly using Malloc, not by questionable hacking) by a desk accessory is never freed under TOS < 2. If you do a resolution change that memory will be lost - a reset is required. TOS 2.x was the first TOS that handled this situation correctly.

Even about menu is wrong - I see nice menu on screenshot OK, Joska probably meant drop down menu. That would be little harder with ACCs, but possible.

Not possible to do cleanly with any currently existing TOS. Geneva, MagiC, N.AES, XaAES and (maybe?) MyAES handle accessories like any other application and might allow this. But the desk accessory concept is rather meaningless under these systems.

However, my point was that instead ACC could be some better system, and then every APP could have own drop down menu as usual.

Why not just do what Geneva did with great success and allow normal GEM-apps to run concurrently? Geneva proved that this is not only possible but actually works brilliantly with little RAM usage. If Atari had done this *and* bundled every ST with proper development tools it would have had great impact on this platform.

[AtariZoll]

Joska, you forgetting about what this thread is. I just gave example for something better than existing ACC system. So, really no need to talk here about Geneva etc - they came later, so really pointless. Especially when you are wrong about some simple features.
I had TOS 1.00 when wrote that CopyACC, and used Malloc in middle of ACC to allocate RAM for RAMdisk, and of course used regular memfree by it's removal. So , ACC self can not be removed (that's TOS/AES design flaw), but allocated RAM by code in ACC can be simply removed by regular memfree.
Your first sentence is really something what you should not write - pure assumption, based on nothing. And for me it just means that you are not so good programmer as may think Not knowing some simple things well, but continue discussion instead checking it - what can be done really in short time.
I did nothing in my own way, used regular TOS and AES calls. Only floppy R/W is done via low level FDC access, because I was not happy with XBIOS 8/9 speed.

[mfro]

...I had TOS 1.00 when wrote that CopyACC, and used Malloc in middle of ACC to allocate RAM for RAMdisk, and of course used regular memfree by it's removal

That's asking for serious trouble, IMHO. In all TOS versions.

My understanding is that GEMDOS doesn't know nothing about accessories.

Thus, if you Malloc() from an accessory, the memory will be owned by the currently active foreground application.
GEMDOS will happily free that memory once that application is quit and assign it to another process that requests it later on.

You'll end up in a mess.

You might get away with blocking AES task switching (wind_update()) between Malloc() and Mfree()) and 'borrow' memory from the foreground application for a short time, but that's not what I'd call clean coding.

[AtariZoll]

Yes, GEMDOS does not know about ACC. Malloc just reserves asked amount of RAM at start of available space. It is not tied to any APP or ACC . When do memfree you refer to it by simply giving it's start address.
You are probably confused by fact that when some APP is started, all free RAM is allocated to it, regardless from how big is it's bss in PRG header.
So, if I would try to install RAMdisk in CopyACC in middle of running some AES APP, which did not memshrink at start it would not work, because no free RAM then. If it performed Mshrink, then malloc will get space not after ACC, but after running APP, but that does not mean that it is tied to that APP, it is just because order of RAM allocations performed. Of course, that's not recommended way of usage, since there will be hole in RAM after exiting APP.
But that's common problem, usually in multitasking environments.
Too bad that no Simbo to add "something" here

[shoggoth]

I'm under the impression that GEMDOS memory allocated by a process, is owned by that process. When the process exists, memory allocated by that process is freed too, unless terminating using ptermres().

[joska]

Yes, GEMDOS does not know about ACC. Malloc just reserves asked amount of RAM at start of available space. It is not tied to any APP or ACC . When do memfree you refer to it by simply giving it's start address.

Correct. Allocated memory blocks are not "owned" by an AES process, because there is no such thing as an AES process. However, the allocated memory is owned by it's GEMDOS process. How else can TOS know which memory blocks to free when a process terminates?

In plain TOS there is only one active GEMDOS process, and that is the currently running application/program. A desk accessory is *not* a GEMDOS process. Any memory allocated by it will belong to the GEMDOS process that was active at the time of allocation. So when that process is terminated it will also free any memory allocated by accessories.

Memory allocated by a DA is actually owned by the GEMDOS process that is running when the application (the DA) makes the Malloc call. When that process terminates, GEMDOS will free the memory. Previously, the AES was not always getting AC_CLOSE messages to DAs until after a program had already terminated, and all of its resources freed. Now, a DA can be assured that it will receive the AC_CLOSE message before the application terminates, so any memory that it has allocated will not already be invalidated at AC_CLOSE time.

(http://dev-docs.atariforge.org/files/TT ... 6-1991.pdf)

Your ramdisk is safe, as long as it allocates memory while the ROM desktop is active so it's memory will be valid as long as the desktop isn't terminated. This happens only when changing resolution. Before TOS 2 the ROM desktop was not a GEMDOS process and was never really terminated, so when the user issued a resolution change the RAM allocated by desk accessories would be "lost" when the DA got restarted.

However, if your ramdisk for some reason allocates memory while another application is running the ramdisk will be invalidated as soon as that application exits to the desktop.

Looks like we don't need Simbo...