>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

[dead]

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.

I remember reading a fan-made alternate history for some sort of cyberpunk game setting back on usenet in the day.

The instigating effect that diverged the timeline was some sort of technological innovation around 1983-1984 that allowed an instant leap in CPU speeds and memory densities by many orders of magnitude. The timing of the advancement was such that the IBM PC architecture was hopeless outmoded and soon died off. Apple retrofitted the tech into their Macintosh line, so they stayed relevant, but the Amiga was still in the design stage and so was able to build their new OS and UI around the enhanced capabilities. It went on to dominate computing for the next several decades.

Their version of Amiga Intuition was able to include photo-realistic VR, global networking, massive neural nets, and so forth, which all contributed to the cyberpunkness of the setting.

> Their combined influence might have actually given the IBM PC and Macintosh a run for their money.

Not a chance, I think. Combine both and you still would not have beaten the sound philosophy, openness, speed, and flexibility of the IBM PC & compatibles. Ironically, to increase your chances massively, you'd needed to have enhittification (with its preference for locked-down rubbish antithetical to general-purpose computing) already dominating the market. Even as Amigas and Ataris were much more open than their cousin's terrible grandchild of today: Apple. A platform which many Amigatari nerdlingers of yesteryear gravitated to...

yeah, substantially agree. But I also think if only Atari and Commodore teams could have just been one company... it would have been glorious. Somehow. The market couldn't afford to be split like that, the pie wasn't big enough.

Also I was an Atari ST user back then, and loved it. But the Tramiel's didn't "get" software in the early days. They failed to make the right investments to keep TOS/GEM actively developed (e.g. as a Mac alternative) until it was too late (they hired Eric Smith to work on MiNT and then MultiTOS in the early 90s but they were already done as a company by then).

And then three fundamental hardware mistakes with the ST were:

1. not shipping it with the Blitter from the start so it couldn't compete on games, obviously with the Amiga but even with 8-bits of the time

2. forcing the ROM size down to 192kB so they had to size optimize the crap out of GEM before shipping (waste of precious development time), especially including tossing away all of GDOS (which had support for proportional fonts and printer drivers etc). A 256kB or 512kB ROM would have solved a lot of problems with what I'd think wouldn't have been an insane BOM cost bump.

3. Minor but long term annoying -- tying the cartridge port to only have 128kB of address lines. If they had given it 256kB or 512kB address ability their later expansion issues (OS upgrades etc) would have been much improved.

As for the Amiga, great machine but a) it cost too much at the start so failed to catch immediate fire (the 500 rectified this to some degree) b) interlace.

As an Amiga user that sounds like a horrible alternative future...