[amiga386]

To give a corresponding example, try moving the mouse while loading from floppy disk on Windows 95, ten years later. The mouse pointer judders!

This does not happen on a 1985 Amiga, even with a fraction of the CPU power, which it needs all of it to redraw UI damage as seen.

The reason is that the Amiga system prioritised input processing above normal tasks, it had preemptive multitasking where hardware timers triggered a CPU interrupt to let the kernel switch to a new timeslice, and of course reading a floppy disk was done with hardware interrupts and DMA transfers because the OS knew exactly what hardware it was dealing with, while PC compatibles couldn't guarantee those transfer modes (https://wiki.osdev.org/Floppy_Disk_Controller) so Windows 95 would inevitably handle floppy drives with polling.

[sehugg]

Windows 95 was hamstrung by DOS compatibility. If you installed OS/2, you could have butter-smooth mouse cursor movement even while formatting a floppy disk and running a DOS (or even Windows!) VM in another window. And if you had a XGA card (which no one did) you had a hardware mouse cursor sprite, just like the Amiga (except only one boring sprite and no cool audio/video tricks)

[vintermann]

DOS was only about 3 years older than Workbench, and OS/2 was about 8 years younger.

[LargoLasskhyfv]

There were SCSI floppy drives. Rare, though. However, with the right controller, not necessarily Adaptek, and drivers for it, they enabled all of that, too.

[kamma4434]

The mouse pointer on Amiga was a sprite. So it flies above the bitmaps below, thence the 50fps frame rate.

[amiga386]

If the Amiga's mouse-pointer sprite was removed and the pointer was rendered onto a bitmap, it would still be 50Hz. There is more than enough time to do that.

The flawless refresh rate comes from the fact the update is executed as part of a level 3 priority CPU interrupt triggered by the vblank refresh. Interrupt code reads the hardware register of a dedicated chip that has been measuring the mouse's potentiometers this whole time, to see how much they've moved. The mouse itself is a passive device.

It then sends a input event to Intuition, whose priority 20 input.device task (the highest priority task in any normal Amiga system) processes the event and updates the hardware sprite coordinates, but could equally write it onto the bitmap. It has the time to do that because everything else in the system waits for it.

Compared to a modern PC, which also uses a hardware cursor... the mouse is an active device and sends its own potentiometer readings as USB input events, which arrive to be processed by an independent USB subsystem in the kernel and is bundled with all the other USB traffic from devices attached on the same bus. A vblank interrupt couldn't get the mouse coordinates even if it wanted to.

[amiga386]

I should correct myself here and say it's not potentiometers, but that the mouse has vertical/horizontal wheels that let infrared light through to detectors, and the hardware is counting a quadrature-encoded pair of pulse trains, so it can tell how many steps back/forward each axis has moved.

Nice article about it: https://www.markwrobel.dk/post/amiga-machine-code-letter11/

It also estimates that, if the hardware counters are sampled every vblank, it's accurate (no missed wraparound) for the mouse moving at up to 3km/h! But it's still possible to whip the mouse around faster than that, so action games might like to sample the mouse more often than once per frame.

[kalleboo]

Famously Gates thought that the Mac cursor may have been a sprite, when it was actually in software https://www.folklore.org/Shut_Up.html

Apple loved doing things in software, ever since Woz wrote the Apple II disk routines in software so their floppy drives didn't need their own controller (the Commodore machines had a whole second CPU running an operating system in theirs). This is also why the one thing that WOULD lag the cursor on a classic Mac was formatting a floppy disk, since it required interrupt-level timing.

Even to this day Apple loves running things in software - the speakers on modern Mac laptops are driven in software - macOS has a daemon that runs and adjusts the speaker volume, tracking the sound pressure sent to them to keep them from being blown out. When Asahi Linux added speaker support, they had to reimplement this from scratch.