Hacker News Reader

Comment by elpocko | Hacker News Reader

https://www.youtube.com/watch?v=5o8E3ycB7Aw

In case someone wants to see for themselves how "instantly" it really was. Skip to ~9:50 when it gets real sluggish.

Edit: if you don't wear nostalgia glasses, you can watch the bits of screen being redrawn piece by piece after something moves or a menu closes. Everything is flickering. Opening and closing a menu takes up to one second. The text being typed in the editor lags. This is not more responsive than a modern system, far from it. Obviously.

View on HN

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.

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)

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

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

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.

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.

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.

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.

There's a good article about this:

https://www.datagubbe.se/stupidslow/

(previous discussion)

https://news.ycombinator.com/item?id=40604972

The Amiga feels fast because its slowness is predictable. Modern systems have unexpected slowness, and unexpected things are always more noticeable.

I had a sidecar with my Amiga 1000, which allowed you to use an XT MFM hard drive + controller card for the Amiga side. Once kickstart + the software loaded, it was incredibly fast. It was weird having a full IBM PC + Amiga in one conjoined machine.

But I agree that predictable slowness is a thing. One only need to discuss traffic jams vs a 20 minute car trip without them.

Hence the caveat "Aside from the loading times," :)

The "instantly" refers to user input: clicking a button, typing, or moving the mouse was as fast as it could possibly get because of how close the OS was to the bare metal, with no fluff bogging down the experience. Simply put, there were no wasted frames, as there were none to waste. Nowadays, at the very least, you get a couple millisecond of latency. That was not the case here.

Also, this is a machine from NINETEEN EIGHTY F//G FIVE, and it's still probably faster than your average PC running Windows 11.

The GUI was fast because it was fixed layout, MUI on the Amiga was slow as well. We tend to go that way to get UI that is easy to create. You see the same in all GUI libraries the more CPU you have the more you use it.

MUI was slow because it layered on a crazy amount of configurability. You didn't need things to get slow with resizeable/dynamic layouts even then.

MUI was slow because it was written in C and went all-in on BOOPSI, as well as supporting fully dynamic layout. It could likely have been faster, but the sort of people who paid for it were also the sort of people who bought CPU accelerators.

Not surprising since this is a floppy-based system. An HD-based A3000 cold booted faster than most modern systems:

https://www.youtube.com/watch?v=G-e3w7Hh9eU

Also gp talks about input responsiveness (e.g. key and mouse input), and that has indeed much less latency on those old-school home computers than on modern systems where each input event goes through layers and layers of abstraction bloat before causing a visible change on the display.

Floppy based Amigas were incredibly clunky. Each file shown in the Workbench GUI has its own icon file (".info" file) which is loaded separately, resulting in additional time for each file in a "drawer" (Amiga folder.)

Reply on news.ycombinator.com