>> I'm pretty much certain that's not correct.
>
> well, they were directly connected to Denise and there were hardware
> counters in Denise for X and Y.
>
>> 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.
>
> I can not find the logic circuit of Denise, so perhaps you are right and
> the contents of the register had to be fetched and put in the mouse
> sprite x and y.

That was my understanding. The hardware may well be in the same chip, 
but it's under software control. (Like I said, it only takes a few 
op-codes to copy the X and Y coordinates from one pair of registers to 
another.)

>>> 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?
>
> Because I have written programs at that level.
> It is a great way to avoid a busy wait on an event in a high level
> language. Just check if your condition is met, if not pass control back
> to the scheduler. Repeat until you have something to do.
>
> What I remember from those days is that a process could be interrupted
> by a higher level process, but user programs ran until they voluntary
> gave control back to the scheduler.*

> *) trying to google things, the wiki page on Exec_(Amiga) claims that
> linus once mistakingly said that AmigaOS was cooperative. In earlier
> versions of this page it *was* apparently considered cooperative,
> because google quotes a text that is no longer there.

http://en.wikipedia.org/wiki/Exec_%28Amiga%29

"Exec is the multi-tasking kernel of AmigaOS. It enabled pre-emptive 
multitasking in as little as 256k of memory (as supplied with the first 
Amiga 1000s). Exec provided functionality for multi-tasking, memory 
allocation, interrupt handling and handling of dynamic shared libraries."

Sounds pre-emptive to me...

In particular, like several other fully pre-emptive systems, Exec 
provides Yield(), which lets you relinquish the rest of the current 
quantum if you wish. However, if you do not call this, a hardware 
interrupt causes Exec to perform a context switch to the next runnable 
task, in round-robin fashion, whether you ask for it or not.

Indeed, were Exec not pre-emptive, there would be no need for Forbid() 
and Permit(), which disable and enable pre-emption. (It's apparently 
used as a crude form of critical section.)

Now, if you mean that a lower-priority task can never run until all 
higher-priority tasks go to sleep, then yes, that's how the scheduler 
works. Usually the very high-priority tasks were things like the 
keyboard scan, which run for a tiny amount of time and then sleep again.

Post a reply to this message