>> without having it trip over itself in the process.
>
> Why? What does it need so much RAM for?

To do all the stuff it was doing that your Amiga wasn't :-)

Post a reply to this message

Le 2013-03-24 07:20, Orchid Win7 v1 a écrit :
> On 24/03/2013 12:41 AM, Francois Labreque wrote:
>> Le 2013-03-21 18:03, Orchid Win7 v1 a écrit :
>>> If you run Debian (which has no special optimisations for such
>>> hardware), you find that it crawls along alarmingly slowly. I mean, slow
>>> to the point that you can't tell if the OS is actually functioning or
>>> not. Twenty minutes for GNOME to start!
>>
>> What else did you expect from loading X11 with a heavy window manager on
>> top of it on a system that only has 2 MB of ram?
>>
>> You'd need at least 8MB to start X11 with a lightweight window manager
>> without having it trip over itself in the process.
>
> Why? What does it need so much RAM for?
>

Because the X11 specification is device-independent, so there's a few 
layers more required to deal with that, on top of it, it's a 
cleint/server environment, so it adds even more layers of code, whereas 
the AmigaOS UI is device-dependant and tied a few graphics chips with 
limited capabilities.


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On Mon, 25 Mar 2013 08:56:30 +0000, Orchid Win7 v1 wrote:

> On 24/03/2013 05:24 PM, Jim Henderson wrote:
>> Sorry, obviously I misread and thought you said 8 GB as a minimum
>> requirement. ;)
> 
> 0wned.

Nah, just misread. ;)

I'm no longer used to memory amounts being expressed in MB. :)

Jim

Post a reply to this message

>>> You'd need at least 8MB to start X11 with a lightweight window manager
>>> without having it trip over itself in the process.
>>
>> Why? What does it need so much RAM for?
>
> Because the X11 specification is device-independent, so there's a few
> layers more required to deal with that, on top of it, it's a
> cleint/server environment, so it adds even more layers of code, whereas
> the AmigaOS UI is device-dependant and tied a few graphics chips with
> limited capabilities.

That would explain why it needs more compute cycles, or why it doesn't 
utilise the Amiga's graphics acceleration hardware. It doesn't explain 
why it needs drastically more RAM.

Post a reply to this message

On 24-3-2013 14:05, Orchid Win7 v1 wrote:
>> I am afraid Andy is correct here (except for his prediction/observation
>> that the PC almost caught up, any generation of a PC system was
>> responsive when it came out of the box, but that stopped after you had
>> used it for some time).
>
>> The Amiga was a multiprocessor system with the GUI almost entirely
>> handled by a coprocessor/firmware/hardware, the distinction is hard to
>> make in this case.
>
> I'm not sure what you're trying to say with this...

That the Amiga managed to blur the distinction between these categories.

> The mouse was drawn as a hardware sprite overlay, so moving the mouse
> pointer involves poking new coordinates into some video registers. This
> takes a handful of compute cycles, and is easily implemented by a single
> interrupt handler.

IIRC it was not even that. I don't have my hardware books lying around 
anymore, but I think the horizontal and vertical motion of the mouse was 
determined by two bit gray codes. These two bits were directly connected 
to the video chip and the coordinates of the mouse were updated in 
hardware. No interrupt required.

> By default, dragging a window shows an outline. I believe there was an
> option somewhere to show full window contents while dragging. The Amiga
> had a dedicated chip for blitting areas of memory around, and
> particularly for blitting image data. That means the CPU just has to
> program a few parameters into this chip, and the window gets copied to
> its new location. Again, doesn't require much CPU power.
>
> Several parts of the OS are stored in an on-board ROM. (In particular,
> the pre-emptive task scheduler, the file-system drivers and the GUI
> rendering code.) That doesn't mean you *have* to use these; it just
> means that if you do, they don't need to be loaded from disk.
>
>> That meant that neither IO nor computations would
>> interrupt the GUI; even if you completely overloaded the machine with
>> computations and disk access the system was totally responsive visually.
>> Many times my Amiga completely hung on something but I could still move
>> the windows in real time, the mouse was functioning, even the buttons
>> could be pressed.
>
> Indeed. The Amiga was quite good at not doing that thing where
> everything stops responding until some event occurs.
>
> (Having said that, without memory protection hardware, one rogue process
> could crash the entire machine. But on the first hand, buggy software
> was rare on that platform.)

or a system call with a wrong parameter.
quoting from memory (from the OS library, that was documented, in 
contrast to some other OSes):
"note: this routine does no error checking. If you ask it to move the 
window to the end of the universe, it will. However, the resulting 
distortion of time and space that will result from this is in general 
not a pretty sight."

>> The only way a modern PC could even come close to such GUI performance
>> is when one processor would be set aside for GUI only with no other
>> tasks and even then the other processes could steal so many cycles that
>> the GUI is slowed down markedly.
>
> Well, my understanding is that modern graphics cards have hardware
> acceleration for graphical tasks too. So the situation shouldn't be too
> much different than how it was with the Amiga's custom hardware.

Then explain how I can sometimes see a window on a PC being refreshed 
top down? Oh, you said "shouldn't" not "isn't".

Another thing that I can't get my head around is the concept that you 
click on an object that is on screen when the click is handled, not on 
the one that is on-screen when you clicked.

>> You can now complain that the screen resolution of the Amiga was much
>> less, that it was not a full implementation of a preemptive multiuser
>> system, that it had no virtual memory etc.
>
> 640x768 for the highest video resolution, which *is* fairly limited.
> (But we're talking about a long-obsolete platform, after all.)
>
> Pre-emptive: Yes. The OS is 100% pre-emptive. If some program goes into
> an infinite loop, you can kill it, and it *will* die. If some program
> tries to use all available RAM, it gets killed, and so forth.

At the user level it was not fully preemptive. You had to do an explicit 
call to allow other programs to get some time too.

> Multi-user: No. Not even slightly. But hey, it's a home computer. It has
> no networking capabilities at all,

There were cards for that, but the basic machine did not have those.

> so there's less call for multiple users.

More of a design choice. But you had to assume all programs were 
friendly. Something you would not do today.

> Virtual memory: The CPU used lacks the necessary MMU hardware to
> implement either virtual addressing, memory protection or virtual
> memory. Later on you could buy add-on cards that included the MMU, and a
> few people made software that allows virtual memory.
>
> (Adding memory protection would have broken applications. In particular,
> the OS messaging system fundamentally relies on zero-copy pointer
> passing, which doesn't work if each application lives in a different
> address space.)
>
>> But that is all irrelevant to
>> the observation that the Amiga had the best GUI response of any system I
>> have seen yet.
>
> Indeed.


-- 
Women are the canaries of science. When they are underrepresented
it is a strong indication that non-scientific factors play a role
and the concentration of incorruptible scientists is also too low

Post a reply to this message

On Mon, 25 Mar 2013 21:40:17 +0000, Orchid Win7 v1 wrote:

> That would explain why it needs more compute cycles, or why it doesn't
> utilise the Amiga's graphics acceleration hardware. It doesn't explain
> why it needs drastically more RAM.

It's more complex software that has to run on more types of hardware.

More code = more memory required.

Jim

Post a reply to this message

> It's more complex software that has to run on more types of hardware.
>
> More code = more memory required.

Also at least on the Acorn/RiscOS a lot of the OS code was written in 
assembler. IME when I used a C compiler on that platform it sucked huge 
amounts of RAM and generated equally huge files, so much in fact that I 
needed to run it under a very buggy command-line-only virtual memory 
manager (I only had 4MB RAM and it needed 8MB). This may have also 
contributed to the larger RAM requirements of Linux.

Post a reply to this message

>> The mouse was drawn as a hardware sprite overlay, so moving the mouse
>> pointer involves poking new coordinates into some video registers. This
>> takes a handful of compute cycles, and is easily implemented by a single
>> interrupt handler.
>
> IIRC it was not even that. I don't have my hardware books lying around
> anymore, but I think the horizontal and vertical motion of the mouse was
> determined by two bit gray codes. These two bits were directly connected
> to the video chip and the coordinates of the mouse were updated in
> hardware. No interrupt required.

I'm pretty much certain that's not correct.

Under sufficiently heavy CPU load, the mouse pointer became slightly 
less responsive. There's no reason for that to happen if it's all 
implemented in hardware.

>> (Having said that, without memory protection hardware, one rogue process
>> could crash the entire machine. But on the first hand, buggy software
>> was rare on that platform.)
>
> or a system call with a wrong parameter.

Sure. The OS does little or no error checking - it's faster that way. So 
passing sufficiently invalid input to the OS will crash it. As will 
writing data to low-numbered memory addresses, or to addresses which 
don't exist, or addresses with are not aligned correctly. Or executing a 
non-existent op-code, for that matter. Any number of things which, in a 
protected-mode OS, would merely halt the offending process, would be an 
OS crash under AmigaOS.

>> Well, my understanding is that modern graphics cards have hardware
>> acceleration for graphical tasks too. So the situation shouldn't be too
>> much different than how it was with the Amiga's custom hardware.
>
> Then explain how I can sometimes see a window on a PC being refreshed
> top down? Oh, you said "shouldn't" not "isn't".

Clearly the graphics is being redrawn from scratch rather than being 
recopied from an off-screen buffer. That a piece of software doesn't 
take advantage of a feature doesn't mean the feature doesn't exist. It 
seems to me that the attitude of modern software is "hey, why bother 
optimising it? Just make the user buy more hardware."

> Another thing that I can't get my head around is the concept that you
> click on an object that is on screen when the click is handled, not on
> the one that is on-screen when you clicked.

Yeah, gotta love that.

>> Pre-emptive: Yes. The OS is 100% pre-emptive. If some program goes into
>> an infinite loop, you can kill it, and it *will* die. If some program
>> tries to use all available RAM, it gets killed, and so forth.
>
> At the user level it was not fully preemptive. You had to do an explicit
> call to allow other programs to get some time too.

What in the world makes you think that? If you run two programs that 
both try to use 100% CPU, they both end up getting approximately 50% 
CPU. (And everything else becomes fairly slow.) Unless you start 
altering priorities, anyway...

>> so there's less call for multiple users.
>
> More of a design choice. But you had to assume all programs were
> friendly. Something you would not do today.

Agreed.

Interestingly, there were several virus scanner programs for the Amiga, 
so clearly there were viruses around. I guess without the Internet, it's 
just that much harder to catch one...

Post a reply to this message

> Under sufficiently heavy CPU load, the mouse pointer became slightly
> less responsive. There's no reason for that to happen if it's all
> implemented in hardware.

On the Acorn there was no concept of CPU load as we have today - the CPU 
was always running at 100%. The OS just gave control to each running 
program in turn, when it had done all of them it started again. It was 
up to each program to give control back to the OS when it was done. If 
you didn't you got to use 100% CPU, which is what most full-screen games 
did and the default for simple programs.

IIRC the mouse pointer was updated by interrupt, so unless you 
deliberately disabled interrupts or wrote some buggy interrupt handler 
you never got any issue with pointer responsiveness.

> Clearly the graphics is being redrawn from scratch rather than being
> recopied from an off-screen buffer. That a piece of software doesn't
> take advantage of a feature doesn't mean the feature doesn't exist. It
> seems to me that the attitude of modern software is "hey, why bother
> optimising it? Just make the user buy more hardware."

Or rather, "it works fine on my 1 month old uber developer PC with 
nothing else running so i won't bother optimising it to work on a 5 year 
old pc".

Post a reply to this message

On 26/03/2013 11:20 AM, scott wrote:
>> Under sufficiently heavy CPU load, the mouse pointer became slightly
>> less responsive. There's no reason for that to happen if it's all
>> implemented in hardware.
>
> On the Acorn there was no concept of CPU load as we have today - the CPU
> was always running at 100%. The OS just gave control to each running
> program in turn, when it had done all of them it started again. It was
> up to each program to give control back to the OS when it was done. If
> you didn't you got to use 100% CPU, which is what most full-screen games
> did and the default for simple programs.

The AmigaOS was pre-emptive. There is no "yield" command; when your 
quantum is up, you get suspended and the next task gets to run. Nothing 
you can do about it.

(Well, no, I lie. You can ask the OS to turn off pre-emption. If you 
forget to tell it to turn pre-emption back on, basically the system 
hangs... Needless to say, this is a rarely-used feature. Except for 
games programming.)

> IIRC the mouse pointer was updated by interrupt, so unless you
> deliberately disabled interrupts or wrote some buggy interrupt handler
> you never got any issue with pointer responsiveness.

I'm almost certain AmigaOS drove the mouse pointer with a simple 
interrupt handler too.

Post a reply to this message