Looking for an AmigaOS Task Manager

[bwinkel67]

Originally Posted by malko

Do you know if on Mac all games were only "system standard" coded or if they discretely killed the system and reactivated it upon exit ?

No, there were definitely games that took over the screen, but it wasn't the norm. My point with AmigaOS is that it seems rare that an application open up in a window within Workbench, instead using the entire screen. Even on old 512x342 screen resolution Macs, most apps and many games settled on the "open in a window" model. It's not everything, of course and when the Mac first came out in 84/85 people were breaking rules left and right.

I think being part of Apple's Mac Developer Program really helped software start to conform to their model. I wrote a bunch of apps (not games) in the early 90's on the Mac and the development kits you got really focused on the windowing environment, and event loop programming.

[bwinkel67]

Originally Posted by Thomas Richter

The average Mac game was something different than the average Amiga game. The Mac was never designed to be a game machine, it's hardware is rather poor for that. There is no hardware acceleration, only black & white output, and even if later models included color, access to it was hidden behind the system layer. This strong abstraction helped the system to become expandable and flexible, and it also disciplined software authors.

The first color Macs (II) came out in '87 so I wouldn't categorize the Mac as a black & white only machine. I will say that I never saw any parallax-style games but the color Macs did have games like Myst in the early 90's.

As I pointed out previously, if the Amiga was designed to be a gaming machine with all its advanced hardware, then why did developers have to break system rules, circumventing the OS environment, to write those games? Seems Bass Ackwards...you'd think the Mac folks would be breaking all the rules to keep up with the Amiga hardware.

[bwinkel67]

So I was able to run two copies of the PC-Task emulator concurrently on a '92 Amiga 600 with 2MB of RAM under Workbench 2.1. The software allowed for it to run either in a window, or take over the entire screen. In windowing, it was rather slow, the screen updates were choppy with intermittent artifacts, the color scheme was that of the system (i.e. light blue text on grey background -- you couldn't change it in the app) and there was no scaling (you could resize the window but it would only cut off stuff that wasn't printed to the screen). Running in the windowing environment made the emulators seem very slow. When it ran graphics games, it would switch into full-screen mode. It was still multitasking and the full-screen mode can be pulled up and down and Amiga-M also works. The PC-Task application controlled its own priority: 1 for foreground and -1 for background -- I don't know what these mean but -1 seems to run slower and sometimes altogether stop.

So not bad all-in-all. However, running two copies of SoftPC concurrently on a '92 Mac with System 7.1 was a bit more robust. Both text and graphics ran scaled in their SoftPc windows with no artifacts. They also multitasked well with each other (and with my kernel hack installed, I could set priorities to slow down the background process to a crawl, thus speeding up the foreground one). One advantage the Mac has, besides handling windowing much better than the Amiga, is that windows can live off the screen. In Workbench 2.1, you can't move a window off the edge, which is a bit constraining. I was also able to repeat this on my '84 QL but it didn't run any better than the Amiga did (maybe a bit worse since it didn't allow a window environment), though it had better priority control, completely suspending the background one.

[koobo]

I suspect not all game developers broke the rules. I remember playing Civilization and it used the OS provided screen and multitasked nicely.

Anecdote on performance: I recently set upon myself a challenge to implement a smooth scrolling screen using kickstart 1.3 provided OS mechanisms. This would be a large screen with a viewport that you could move freely to show whatever part of the screen. I eventually worked out how to do it, and it worked nicely. However, a 50 FPS smooth scroll used a lot of resources when run on A500, using the graphics library function ScrollVPort. This did not leave enough power to print text on the screen while scrolling, as I originally intended. Dropping the frame rate to 25 FPS would help.

As an aside, in the documentation it is mentioned that ScrollVPort is 10 times faster on kickstart 3.0

If the same thing is done by taking over the system and setting up a custom screen, the scroll operation becomes almost free from the CPU usage perspective. However, you will then of course lose whatever functionalities the OS would normally provide, such as screen controls, dragging, mouse pointer, support for different screen modes, etc etc.

[malko]

Originally Posted by Thomas Richter

Well, that's a tautology [...]

It's not. I did not code, disassemble or see the code of these applications but only did try or use some of them. Thus I will not affirm something as the only truth but instead can give my perception as a user.

Originally Posted by Thomas Richter

[...] If CBM would have done the same with hardware, namely lock it behind the Os layer, it would also have helped software vendors to provide better software.

To my knowledge they did it when the A1200 (AGA) came out but some developpers complained (here I would like to know "which" developpers. Game dev ?) and searched ways to still be able to direcly access the hardware. What they did. But again I still consider this a a minority of coders. Reading your posts let me think that in the opposite you consider that they were the majority of coders.
I do not forget also that when AGA came out in 1992 Commodore was, unfortunately, already not in his best shape reason they released AGA and not AAA (that was not ready).

As a user point of view : take a simple HD partition (whatever size). Format it under OS 1.3 and check the time it takes (standard OS calls). Take the exact same HD, format it under OS 3 and check the time. The speed gain is relevant and see how OS functions call have been improved.
As a coder point of view : BUT if what you code is still intended for OS 1.3 user base (OS 3 base not big enough), you will continue not to use the system calls... The snake who eats itself...

Originally Posted by bwinkel67

[...] if the Amiga was designed to be a gaming machine [...]

I never saw the Amiga AS a gaming machine. I saw it as an advanced computer that also allowed astonishing games. The list of "serious" productive application that were released proves that many people thought like this.

Originally Posted by bwinkel67

No, there were definitely games that took over the screen, but it wasn't the norm. [...]

My question was not about taking over the screen, but the system.
When you have a screen of 320x256 pixels, it is understandable that you open a full screen application. It does not mean that the system is killed behind (Amiga-M or N).
Therefore many applications were opening their own screen (OS still being there behind).
As a side note : Even today on some laptops (resolution of 1200x600) it happens that application's buttons [OK][Cancel] are not visible, thus are inaccessible, because they are too below out of the screen . Windows has bad coders or is bad OS ?


Edit : Just saw koobo post. Thanks for your feedback.

[bwinkel67]

Originally Posted by malko

My question was not about taking over the screen, but the system.
When you have a screen of 320x256 pixels, it is understandable that you open a full screen application. It does not mean that the system is killed behind...

Oh, I see. Not sure it would be easy to differentiate between taking over the whole screen or circumventing the OS. Games that took over the whole screen may have needed an escape key to get out (MacOS didn't have an Amiga-M key). But you wouldn't even need to take the whole screen as it's pretty easy to circumvent the MacOS: just don't make the system call GetNextEvent/WaitNextEvent in your code which would keep everyone else away since you are now not cooperating and the kernel is just sitting there hoping you release control. So that's pretty simple and that may have happened with some games that needed all of the resources.

My first program on the Mac was a command shell and scripting language and I developed in on the QL which has a preemptive kernel. When I ported it over and compiled it on my Mac and ran a script written in its environment, the entire Mac GUI interface stopped responding because I never released control while the script ran. I had to do some work to get it to multitask (stick in WaitNextEvent calls at various places in the interpreter).

[meynaf]

Originally Posted by bwinkel67

My point with AmigaOS is that it seems rare that an application open up in a window within Workbench, instead using the entire screen.

Using entire screen has many advantages, the first of which being the number of available pen colors.

Originally Posted by bwinkel67

Even on old 512x342 screen resolution Macs, most apps and many games settled on the "open in a window" model.

The "open in a window" model has many problems.
Screen resolution might not be what the programmer needs. So what to do ? Scale ? This is absolutely horrible in system resource usage if you don't have a powerful gpu behind. Keep as is ? It might be too small, or too big.
Also when using palette display the number of available colors is reduced to keep some for the interface. You may even have to constantly remap your display ; i got significant speedup in the Amiga version of HOMM2 by just removing that remap stuff off the Mac version (which was used as basis).

Originally Posted by bwinkel67

As I pointed out previously, if the Amiga was designed to be a gaming machine with all its advanced hardware, then why did developers have to break system rules, circumventing the OS environment, to write those games?

Because even a lightweight OS such as AmigaOS takes its toll of memory and cpu power. That's neglectible on accelerated machines we have today, but for memory-starved A500 with 7Mhz 68000 every kilobyte and cpu clock did count.
Now, try to write a game such as Superfrog on 8Mhz Mac. Often it was the choice of doing it without the OS or not do it at all. We had very impressive games for the time because the OS could be killed at will.
Even today OSes cause performance troubles. Try to do sub-millisecond realtime on a "modern" system for example.

Originally Posted by bwinkel67

I don't know what these mean but -1 seems to run slower and sometimes altogether stop.

It's quite easy actually. As long as there is a higher priority program asking for cpu time, a task gets no cpu time at all. That may sound stupid but it actually helps solving race conditions in multithreaded programs ; having a simple scheduler also helps performance.

Originally Posted by bwinkel67

However, running two copies of SoftPC concurrently on a '92 Mac with System 7.1 was a bit more robust. Both text and graphics ran scaled in their SoftPc windows with no artifacts. They also multitasked well with each other (and with my kernel hack installed, I could set priorities to slow down the background process to a crawl, thus speeding up the foreground one).

A bit more robust, really ? It just better supported the wrong way of doing things. Scaling things on such a machine has probably made the emulator run a lot slower than it ought to, in comparison to running fullscreen - which the Mac does not even seem to be capable of.
Do not underestimate the power of Amiga screens. PC users run with several monitors where we can just do Amiga-M or click on the top-right button. Switching to/from fullscreen often takes several seconds (yes DX7 i'm looking at you) though it seems better now than it used to.

Originally Posted by bwinkel67

One advantage the Mac has, besides handling windowing much better than the Amiga, is that windows can live off the screen.

I wouldn't see that as an advantage !
You can't see things that are away, you can't click buttons that are away, etc.
Nah, not good. On the Amiga it is possible to resize a window down to only the title bar ; software such as Delitracker do this when clicking on "zoom" window button.

Originally Posted by bwinkel67

Not sure it would be easy to differentiate between taking over the whole screen or circumventing the OS.

You don't really need to (usually).

[Thomas Richter]

Originally Posted by bwinkel67

Oh, I see. Not sure it would be easy to differentiate between taking over the whole screen or circumventing the OS.

For the Mac, there is not much hardware to take over, and there is only one screen that sits at a predefined place. (Actually, two for the early Macs, one being reserved for MacsBugs, the system debugger).


For the Amiga, it is quite different. Drawing graphics on the screen is driven by the blitter through the graphics library. The mac didn't have dedicated hardware for that, but the closest equivalent MacOs had was "Quickdraw", the graphics manager of the Os. Bypassing the Os is similar to poking to the screen memory directly on the Mac, with the consequences that window boundaries are not respected.

Originally Posted by bwinkel67

Games that took over the whole screen may have needed an escape key to get out (MacOS didn't have an Amiga-M key).

CBM-M is not the "screen overriding terminate" key either. The Amiga has just multiple hardware layers (as many as memory allows) on which programs can draw, not just the one (or two) Mac hardware. CBM does not stop programs from drawing onto any screen - not at all. It just loads the display hardware with the address of the next screen to be shown. Programs operate independently of each other - or on the workbench, on their decision.

Originally Posted by bwinkel67

But you wouldn't even need to take the whole screen as it's pretty easy to circumvent the MacOS: just don't make the system call GetNextEvent/WaitNextEvent in your code which would keep everyone else away since you are now not cooperating and the kernel is just sitting there hoping you release control.

Precisely, but when a program would not use quickdraw to render its graphics, but would poke into screen memory directly, that would also corrupt graphics of other programs. That wasn't the norm on Mac. Applications were pretty much well-behaived.

Originally Posted by bwinkel67

My first program on the Mac was a command shell and scripting language and I developed in on the QL which has a preemptive kernel. When I ported it over and compiled it on my Mac and ran a script written in its environment, the entire Mac GUI interface stopped responding because I never released control while the script ran. I had to do some work to get it to multitask (stick in WaitNextEvent calls at various places in the interpreter).

I recall that MacOs also had a trap for "Idle" you could call once in a while to allow other applications to regain control.

[Thomas Richter]

Originally Posted by meynaf

Screen resolution might not be what the programmer needs. So what to do ? Scale ? This is absolutely horrible in system resource usage if you don't have a powerful gpu behind. Keep as is ? It might be too small, or too big.

MacOs works different from AmigaOs. You typically don't draw graphics by BltBitMap wjere you push a pixel array onto the screen. Rather, you would describe your interface by coordinates and abstract drawing instructions you could pre-record, and "replay" to get the graphics on the screen. Thus, rescaling wasn't really much of an issue, it was just scaling coordinates.



GadTools in 3.2 can work likewise, it can do the scaling for you, without having to rescale any graphics. It is only a multiplication per coordinate.

[hooverphonique]

Originally Posted by bwinkel67

If the argument is that due to the slow processor and resources, programmers had to circumvent system calls to get their programs to work, wasn't the whole point of the Amiga that it provided hardware (chip) solutions to handle that more efficiently? And didn't the Amiga provide system calls to utilize those chips?

The thing is, games and demo developers wanted to squeeze every last drop out, thus circumventing the OS - at least that's partly the answer.

The OS utilizes the custom hardware, yes, and also let's user software do so, but of course such things come with abstractions that have a costs.

[meynaf]

Originally Posted by Thomas Richter

MacOs works different from AmigaOs. You typically don't draw graphics by BltBitMap wjere you push a pixel array onto the screen. Rather, you would describe your interface by coordinates and abstract drawing instructions you could pre-record, and "replay" to get the graphics on the screen. Thus, rescaling wasn't really much of an issue, it was just scaling coordinates.

GadTools in 3.2 can work likewise, it can do the scaling for you, without having to rescale any graphics. It is only a multiplication per coordinate.

Sure, but we are not talking about lines, rectangles, filled areas or simple text here, not even static icons. An emulator's graphics output is a totally different story, as well as a game of course.

[Thomas Richter]

Originally Posted by hooverphonique

The thing is, games and demo developers wanted to squeeze every last drop out, thus circumventing the OS - at least that's partly the answer.

The problem with this approach is, and Mac developers understood this much better, the lack of forward compatibility. What does your game help iyou if it won't run on the next generation of the hardware? Apple made perfectly clear that the Os is the interface for the hardware. Apple sold an operating system and a software interface. CBM sold a piece of hardware on which by accident an Os ran on.



You seem to indicate that you only need to pay for using the Os, but that's wrong. You gain also a lot. The overall approach how you program a Mac is completely different from how you program for Amiga (or at least how the average c00l c0d3r works).

[bwinkel67]

Originally Posted by meynaf

A bit more robust, really ? It just better supported the wrong way of doing things. Scaling things on such a machine has probably made the emulator run a lot slower than it ought to, in comparison to running fullscreen - which the Mac does not even seem to be capable of.
Do not underestimate the power of Amiga screens. PC users run with several monitors where we can just do Amiga-M or click on the top-right button. Switching to/from fullscreen often takes several seconds (yes DX7 i'm looking at you) though it seems better now than it used to.

So to give some comparisons. On a '92 PowerBook 180 (33 Mhz 68030), running two sessions of SoftPC concurrently, with the background one being slowed down with my utility, it took about 9 seconds for foreground to print the screen for a game (LinkFour). Lets take a couple of seconds off if we don't have that second instance running and give it 7 seconds. On the Amiga 600 (7Mhz 68000) it took 51 seconds on a single instance. So that's a factor of 7.3 times faster. Benchmarks comparing a 16 Mhz 68030 vs 16 Mhz 68000 has it running 1.9 times faster doing graphics on a Mac. If we account for the faster clock speed, then that 1.9x becomes 8.75x. So 7.3x vs 8.75x, a gap of about 1.5. Using these numbers, MacOS would take about 61 seconds to draw the LinkFour screen vs 51 seconds in Workbench 2.1 if the Mac were running a 7.16 Mhz 68000.

[Edit: I also found benchmarks that said the PowerBook 180 was only 4.5 times faster than a Mac SE, the latter of which had a 7.8Mhz 68000 (similar to the Amiga 600). So I may have overestimated the PowerBook's performance (i.e. by just dividing 33 Mhz by 7.16 Mhz and multiplying by 1.9) and it all may be a wash. The PowerBook is a laptop so I'm sure there are shortcuts that don't make it run as fast as a desktop equivalent sporting a 33Mhz 68030.]

So we aren't talking about exterme speed differences here given the MacOS. Of course this doesn't account for software efficiency difference between PC-Task and SoftPC.

Originally Posted by meynaf

I wouldn't see that as an advantage !
You can't see things that are away, you can't click buttons that are away, etc.
Nah, not good. On the Amiga it is possible to resize a window down to only the title bar ; software such as Delitracker do this when clicking on "zoom" window button.
.

So SoftPC doesn't let you resize the screen. I assume that what it shows, it scales just once since a PowerBook display is 640 x 400 and I was able to easily have two windows of SoftPC running -- each window left about 25% of the screen area on the side and 15% on the bottom free and the graphics image looked normal (and more importantly, running in a window it had no image artifacts like the Amiga). Moving screens off the edge is very convenient, because you can move one to the side that you aren't using (say it's just running something in the background) while you focus on the foreground one. That way you can still kind of see what's going on. It feels completely claustrophobic to have the window refuse to move past the edge in Workbench. The MacOS way is very natural and of course it's how modern systems work today.

[bwinkel67]

Originally Posted by Thomas Richter

I recall that MacOs also had a trap for "Idle" you could call once in a while to allow other applications to regain control.

I think WaitNextEvent is the equivalent to calling the idle trap.

[meynaf]

Originally Posted by bwinkel67

So to give some comparisons. On a '92 PowerBook 180 (33 Mhz 68030), running two sessions of SoftPC concurrently, with the background one being slowed down with my utility, it took about 9 seconds for foreground to print the screen for a game (LinkFour). Lets take a couple of seconds off if we don't have that second instance running and give it 7 seconds. On the Amiga 600 (7Mhz 68000) it took 51 seconds on a single instance. So that's a factor of 7.3 times faster. Benchmarks comparing a 16 Mhz 68030 vs 16 Mhz 68000 has it running 1.9 times faster doing graphics on a Mac. If we account for the faster clock speed, then that 1.9x becomes 8.75x. So 7.3x vs 8.75x, a gap of about 1.5. Using these numbers, MacOS would take about 61 seconds to draw the LinkFour screen vs 51 seconds in Workbench 2.1 if the Mac were running a 7.16 Mhz 68000.

[Edit: I also found benchmarks that said the PowerBook 180 was only 4.5 times faster than a Mac SE, the latter of which had a 7.8Mhz 68000 (similar to the Amiga 600). So I may have overestimated the PowerBook's performance (i.e. by just dividing 33 Mhz by 7.16 Mhz and multiplying by 1.9) and it all may be a wash. The PowerBook is a laptop so I'm sure there are shortcuts that don't make it run as fast as a desktop equivalent sporting a 33Mhz 68030.]

So we aren't talking about exterme speed differences here given the MacOS. Of course this doesn't account for software efficiency difference between PC-Task and SoftPC.

You could try MacOS directly on an Amiga, with software such as Shapeshifter, for better comparisons. With a machine such as an A1200 with 68030, extra overhead would be minimalistic.

Originally Posted by bwinkel67

So SoftPC doesn't let you resize the screen. I assume that what it shows, it scales just once since a PowerBook display is 640 x 400 and I was able to easily have two windows of SoftPC running -- each window left about 25% of the screen area on the side and 15% on the bottom free and the graphics image looked normal (and more importantly, running in a window it had no image artifacts like the Amiga).

With regard to image quality, sounds like simple integer scaling on one side and not on the other.
Not very fair comparison anyway. A600 does not really have 640x400 and Workbench screen mode probably has fewer colors than your PowerBook.

Originally Posted by bwinkel67

Moving screens off the edge is very convenient, because you can move one to the side that you aren't using (say it's just running something in the background) while you focus on the foreground one. That way you can still kind of see what's going on.

Did you know that on the Amiga you can have the focus on a window that's partially covered by another ?
So that you can really see what's going on ?
So you do not need to push windows off screen ?

Originally Posted by bwinkel67

It feels completely claustrophobic to have the window refuse to move past the edge in Workbench.

Maybe, but this is in no way necessary for anything i can think of.
It may feel claustrophobic for you ; for me it just feels wrong if a window can be moved past the edge of the screen.

Originally Posted by bwinkel67

The MacOS way is very natural and of course it's how modern systems work today.

Modern systems are becoming more and more user unfriendly so that's not a good reference.

[malko]

Originally Posted by meynaf

[...] modern systems are becoming more and more user unfriendly so that's not a good reference.

+1

[bwinkel67]

Originally Posted by meynaf

Not very fair comparison anyway. A600 does not really have 640x400 and Workbench screen mode probably has fewer colors than your PowerBook.

I think it had 16 colors (it was a grey scale LCD), though you can hook an external VGA monitor to it.

Originally Posted by meynaf

Modern systems are becoming more and more user unfriendly so that's not a good reference.

Well, true, I'm not a big fan of the docking bar at the bottom on modern Mac OS X (or now Windows 11) or how the Start menu in Windows 8 onwards has changed. When I compare 80's and 90's systems I use Windows 7, which is my current favorite. Windows 10 isn't all that bad either but I still miss the old Start menu.

In any case, the modern windowing mechanism, which has been in place fore several decades, is shared among all modern systems. MacOS System 7 compares quite favorable to Windows 7 in my opinion. Note that for the Mac, I started not being that fond of System 8 onwards, so not every upgrade is ideal. But shared conceptual improvements like every file has an icon, every application has a window, windows can move off the screen, etc, are certainly good markers for a well designed GUIs.

[meynaf]

Originally Posted by bwinkel67

I think it had 16 colors (it was a grey scale LCD), though you can hook an external VGA monitor to it.

In comparison, A600 with ECS chipset can not do more than 4 colors on WB without hindering the performance. You need custom screen with lower resolution to reach 16 (that is, without any bad impact : on both you can have more but it has a cost).

Originally Posted by bwinkel67

In any case, the modern windowing mechanism, which has been in place fore several decades, is shared among all modern systems.

Still not a good reference

Originally Posted by bwinkel67

But shared conceptual improvements like every file has an icon, every application has a window, windows can move off the screen, etc, are certainly good markers for a well designed GUIs.

Please remove the "certainly". Not everyone agrees on that.
Every file has an icon ? Well, maybe. Though lists have always been more practical as you see more files on smaller surface.
Every application has a window ? Some just don't need any. Console programs, for example.
Windows can move off the screen ? As said, yuck.

What is really bad today with Windows - i don't know for MacOs - is that when a program is busy, you can not do anything with its window. Not move it, let alone resize it. If it has been covered by another window, you even lose all its contents until it can finally refresh !
Even on win10, it can happen that when a program goes full screen and changes screen mode, everything behind is destroyed and your desktop becomes a mess.
AmigaOS handles those cases just fine.

[bwinkel67]

Originally Posted by meynaf

In comparison, A600 with ECS chipset can not do more than 4 colors on WB without hindering the performance. You need custom screen with lower resolution to reach 16 (that is, without any bad impact : on both you can have more but it has a cost).

The version of SoftPC I had could only do CGA which is 4 colors. Not sure how that would impact it. I could have set the monitor to monochrome using only black & white...that may have sped things up.

Originally Posted by meynaf

AmigaOS handles those cases just fine.

I actually experienced that same thing today when running PC-Task in a window on my Amiga 600. For some reason the system freezes up for a short time (maybe 5 or 10 seconds) and then the window finally updates and moves. It was the weirdest thing. That also happened a few times in full screen mode when pulling the window down.

[malko]

Originally Posted by bwinkel67

[...] I actually experienced that same thing today when running PC-Task in a window on my Amiga 600. For some reason the system freezes up for a short time (maybe 5 or 10 seconds) and then the window finally updates and moves. It was the weirdest thing. That also happened a few times in full screen mode when pulling the window down.

TBH, when this happens this is something that we can all accept on a A600 from 1990 (OS 2.0 + 7Mhz CPU + 1Mb CHIP-RAM) while emulating another system but that is unacceptable on a pretended "modern" OS running on Ghz-Multi-Cores CPU with Gb of RAM (and up-to-date drivers of course) while simply using it... .