>You could really feel the slow performance with 8 and 16 color Workbench screens on the 500.

Until you added FAST RAM (e.g. via lefthand expansion slot), exclusive to the CPU.

The system prefers allocating there unless CHIP is explicitly requested.

It was nice of the ST to offer a special black and white screen mode on a custom monitor. The Amiga had the memory bandwidth to offer the same, but chose to only offer PAL/NTSC and no other custom video signals at launch, probably to avoid making its display chip even more complicated.

The Amiga had a "professional" resolution of 1008x1024 PAL or 1008x800 NTSC, 4-colour greyscale with a 15Hz refresh rate via its A2024 monitor (which effectively sampled 4 screens worth of video output and stitched them together).

You could also buy a "flicker fixer" (later included internally in the A3000) which gave you full colour 640x512 at 25Hz or 640x400 at 30Hz if you didn't like interlace.

In 1990, the ECS chipset gave you "Productivity" mode (640x480 at 60Hz, 4 colours) and "Euro72" (640×400 at 70Hz, 4 colours) - there's a nice list here: https://amiga.lychesis.net/articles/ScreenModes.html

But different strokes for different folks. The Amiga distinguished itself by being easily genlockable to video and having a 4096 colour palette and 21kHz 4-channel 8-bit sampled sound replay in 1985. The ST distinguished itself by having MIDI ports and a choice of either monochrome monitor, or the TV (or a colour monitor based on NTSC/PAL) if you wanted to do anything in colour. It found its niche in controlling other musical devices.

But the ST did have a garish green low-res desktop by default.

Later Amigas also supported VGA monitors with 31kHz horizontal refresh rate, with just a passive adaptor. I used a VGA monitor with my Amiga 1200 up until I switched to PC, and a tweaked video mode with 704×520 pixels.

If you wanted to play games on an Amiga or an Atari ST you needed to use a TV-signal compatible 15kHz monitor or a Multisync monitor. I ran desktop programs in 640×200 mode with four colours on both my ST and my Amiga 500 before I upgraded.

There were also "flicker fixer" add-ons for the Amiga, converting the interlaced modes to VGA signals: one was built into the Amiga 3000.

As a kid the 70 Hz made a much more professional impression on me than the colors, but of course the colors were much cooler.

I so wish we could go back to that convention, rather than the silly '0x' convention. Every language I write in my head (and there's been a bunch) uses that.

Most of it was architected before implementation, The timing was a pretty core part of the system, I believe the intention was to give every machine some fast RAM that had a CPU only bus, but that fell to budget demands. You could still get a memory expansion which the CPU would have all to itself. There were a few details that were late tweaks, and there were a whole bunch more that could have been easy additions at implementation time if they had known at the time what we knew after 20 years worth of demo coding on the Amiga.

A lot of the features of the Amiga came from exactly that form of hindsight with the 8 bit machines. The Copper, sprites being arbitrary height, and display addresses being 'live' rather than top-of-frame initialisation values came from seeing programmers of the 8-bit machines finding tricks to undo much of the fixed function behaviour so they could reuse sprites or trick the display RAM fetch to suddenly jump to another place. The Amiga came with a lot of that automatic behaviour removed and then performed by the copper allowing for low level coders to just access the core behaviour instead of trying to trick the hardware into doing it (like the way you remove borders on the c64)

I think there's truth to what you say.

The Amiga pushed the boundary in so many directions at once that the horizon extended far beyond what I was used to with the DOS/EGA/TSR/ISA/x86/PC Speaker environment. Or, the monochrome VT100/PDP-11/multitasking/multiuser systems I used in college.

At the same time, it was clear the horizon was limited...but could be pushed back through a combination of cleverness, and discovery, and code. You felt like there were true discoveries to be made, whether it was through looking at source code found on UUCP, by finally understanding the purpose of some struct found in the Amiga ROM Kernel Reference Manual, or just experimenting with blitter or copper code.

Despite (or perhaps because of) the depth of knowledge available, computing today feels stale; anything "new" is only new to you. A million people would look at your "innovation" with disdain as its such a well-trodden path.

In a way I welcome AI-based coding, because if there's no joy (for me) in the (coding/discovery) journey, perhaps I can at least feel there's magic in getting to a new destination more quickly than ever.

Color depths, not modes per se, and it's more that XFree86/X.Org by virtue of being lowest common denominator didn't have optimizations based on it, and over time GTK and others forgot they exist.

Some systems like Xsgi went further with having several visuals used for predefined purposes in their modified Motif versions

I used X11 on some 8-bit framebuffers back in the day, and I remember the palette changing depending on which window was in the foreground. The foreground window would have proper colour, and the background ones would generally have crazy clashing colours.

But none of that really requires separate "screens" any more.

I love the screen concept, but the different resolutions and colour depth are the weakest reason for them on modern hardware.

> Pixels weren’t real in the CRT days :)

True, but it gets more purely true if we add the word analog in front of CRT. While no CRT had pixels native to the display in the way LCD & LED monitors do, it's worth clarifying whether we're talking about the video signal's native traits or the display's.

Most techies today were raised in a digital video world, so they learned to think of display output as being natively digital. Many struggle to fully wrap their heads around how a natively 'non-pixel' analog video signal is even a coherent concept. Often, they'll start by conceding "Sure, I get that in the 'old days', video output was converted into analog somewhere downstream before it 'hit glass', but raster image data in a digital computer was still 'born' as discrete pixels in a frame buffer. Even if it's converted to analog for display output, somewhere there's a natively 'pixel' form of that raster, right?"

While that was true on virtually all early 8-bit computers like the Apple II, Atari 400/800, C64, etc, it wasn't always the case before that. Some early digital computers displayed raster imagery on analog televisions which never existed anywhere as discrete pixels. Instead, they synthesized each horizontal scanline as an analog waveform. While these scanlines did technically have a resolution, that resolution was expressed as frequency and bandwidth of the waveform, not pixels. The raster image never at any point existed as discrete pixels, in much the same way that early audio recordings on vinyl discs or cylinders were never discrete "audio samples."

Thus, analog video imagery from some early digital computers wasn't just a display conversion of a 'ground truth' pixel raster, no pixels ever existed. For many digital natives it can be challenging to conceptualize media that isn't fundamentally quantized into discrete digital values.

In a sense pixels arent even real today right? It's an abstraction

In TV land, there is no non-interlaced. It's all interlaced. You provide fields at 50Hz/60Hz* and the CRT displays one after the other, interleaved.

https://en.wikipedia.org/wiki/Interlaced_video

"Non-interlaced" is just sending the same line for both fields, "interlaced" is sending different lines for each field. You can update your "non-interlaced" screen at 50/60Hz and the viewer will see movement, because it's transmitted for both fields. If you were updating just one line of an interlaced screen at 50/60Hz, it would only be transmitted every second field, so the viewer would perceive 25/30Hz movement.

For high-resolution monitors, Commodore and 3rd parties offered a "flicker fixer", which took the raw output, buffered both fields in its own RAM, and re-emitted the combined image as a single frame.

https://en.wikipedia.org/wiki/Flicker_fixer

*: actually 59.94Hz

AmigaOS does indeed enable the extra half line when any visible viewports are interlaced. Fortunately that just works because the individual “non-interlaced” fields are still legible when shifted back and forth by a half line.