The Amiga had a great trick. Both the CPU and the display/audio hardware share the same RAM (called Chip RAM), so they have to arbitrate for access to it, through a chip called Agnus, which prioritises who gets to read/write memory, depending on importance. You can starve the blitter, you can starve the CPU, but you can't starve the audio or video or disk I/O. As the 68000 CPU only needed memory access every second clock cycle, the Amiga designers arranged it so that the custom chips preferred odd cycles and saved the even cycles for the 68000. So your 68000 runs at full speed.
But if you need more and more work done by the custom chips, it starts to rob some of the even cycles from the 68000.
If you have a 16-colour lowres screen (4 bitplanes), Denise (the chip that turns RAM values into video signals) only reads display data on odd cycles. But if you add another bitplane for 32 colours, she needs some of the even cycles. If you add another bitplane for HAM or EHB mode, she needs even more.
In hires mode, it needs twice the bandwidth for twice the pixels. So if you have a 4-colour hires screen, it only needs odd cycles and the 68000 is full speed. If you go for 8 or 16 colours, it starts slowing the 68000 down.
This is why the default Workbench screen is 4-colour hires. It's hires to look nice and professional like an IBM, and not like a kid's toy like the Atari ST's default lowres GEM interface. It's 4-colours to show it's colourful and not black-and-white, but it's not 8- or 16- colours because that would nearly halve the speed of the CPU !!!
Neat. 3MB would have been insane. That year, my family bought the 512KB trapdoor expansion for A500, so that we could play Monkey Island. It was every bit worth it!
Of course, the extra 512KB made our Amiga that much more useful, and eventually we did the solder-jumper change to make it chip, as our A500 is a rev6 with the 1MB ECS Agnus.
I still have this A500; now it also has 8mb fast on cpu slot, an ECS denise and a 68010.
Cool! I never knew anyone who did a 68010 upgrade back in the day.
I also had a 30 meg hard drive on my A500 (Supra, which included the RAM expansion.) It was a pretty decent Amiga setup. I taught myself C on that machine (Lattice / SAS C)
> This is why the default Workbench screen is 4-colour hires. It's hires to look nice and professional like an IBM, and not like a kid's toy like the Atari ST's default lowres GEM interface
The Atari ST had a professional resolution of 640x400 monochrome with a 70hz refresh rate. The Amiga had a 640x200 resolution non-interlaced, or a 640x400 interlaced which was basically a kid's toy.
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.
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.
I never knew anyone who used the ECS "productivity" modes. That would've required an expensive multisync monitor since other Amiga stuff would still need the 15 kHz support. The only useful feature of ECS, as far as I can recall, was support for additional chip RAM.
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.
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.
Was all this engineered and then implemented, or did they play it by ear? Seems very complex for the time. Now with Pis and ESP32s one can just cobble up together whatever Frankenstein with off the shelf parts, but this seems very elegant with bespoke chips, sans 68000. This is way way way over my head, but intellectually intriguing.
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)
That's one reason why adding fast ram (= exclusive access by the CPU) to an Amiga 1200 doubled the speed of the machine for most workloads without changing the CPU.
I wish there was a way to recapture the feeling of magic produced by using the Amiga. From usability to programmability, everything seemed exciting, new, and with unlimited possibility.
It really was like going from a black-and-white world to seeing full color.
I always said that if 1% of the effort (and money) put into overcoming the PC architecture's shortcuts was put into the Amiga, the computing world would be in a very different place.
I'm afraid that the feeling of magic if (was) a phenomenon related to passing the boundary between the "black and white" and "full color" worlds, not the "full color" world itself.
What we have now easily available offers much more unlimited possibilities. 24-bit color, 4K resolution, all the 3D you may care about, all the audio you may care about, gigabytes of RAM, terabytes of storage, easy programmability from tinker-friendly stuff like pygame or processing.org or löve to world-construction kits like Godot. Or the whole Web thing. All available at a trivial cost or free. Where's the magic though?
I think that much of the "magic" feeling comes from pushing things to the limit, and beyond. This requires a limited possibility. Basically all art is built around some kind of a limitation and playing with it.
(Being young and having time to tinker with hardware just for the joy of the audiovisual effects goes without saying.)
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.
Maybe its me, but i believe the primary or secondary reason for screen is different screens had different resolutions and color depths, both of which dont really exist these days on any major OS.
I've been thinking a lot about this. Virtual desktops gets us somewhat close, but not quite. You're right the difference in resolution and colour depth isn't really relevant any more.
What I think made screens feel different was as a grouping mechanism, usually driven by a single application (though in more recent versions of AmigaOS you could open "public screens") that would manage the layout for that screen. You can do that with virtual desktops, but it takes some effort to simulate the behaviour.
I'm slowly iterating on something like that for my wm. I now snapshot the (by default tiling) layout and restore it, letting me "open" and "close" screens/virtual desktops, and re-open the applications on them, so instead of opening a single application that opens a screen, I will open a "project" and it will open a desktop and multiple applications on it whose windows will snap into place. I'm not happy with it yet, but it feels somewhat closer to me to how it felt to use Amiga screens.
It feels like the concept faded with the advent of large VRAM and fast fill rate graphics accelerators. I remember old X Window System workstations supporting multiple concurrent windows with different color depths and modes. The hardware would compose windows from memory during display scan-out, all to save VRAM.
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.
- 3D apps (games) render at a resolution less than the desktop for performance reasons (even in fullscreen mode to avoid switching the video signal)
- Similarly, streaming sticks/TVs render the UI at 720-1080p and overlay on hardware decoded 4K video (very common in anything that's not a console, Apple TV, or NVIDIA Shield)
- Handling non-high DPI apps on a high-DPI desktop, or handling systems with mixed DPI displays
- Combining HDR and SDR content on the same desktop. Same with deep-color apps.
- UI effects like the OS X genie effect, app thumbnails
I think there's a difference between concept and the implementation. I see screens as simply compositing. Different regions have different resolutions and color depths and you use display hardware to combine these together. For modern personal computers, we got this in Windows Vista and OS X 10.0.
Circa 1985 hardware has significant limitations and it's leaking through abstractions both ways. A modern program supporting deep color writes to an array consisting of R16G16B16A16 values, next to a legacy program writing R8G8B8 and even a window with 10-bit 4:2:0 YUV HDR video. On the Amiga, the hardware leaks through by having to deal with separate bit planes and palettes.
Similarly, the 3D hardware in a modern GPU easily upscales a legacy application's surface 1.25x to handle the mid-DPI laptop screen I'm using right now. 1985 hardware can't do that, because you're fiddling with the DAC output, you can only have one screen/ViewPort scan line, no overlapping regions, and if you look carefully, blank lines between regions for the hardware to reconfigure.
Yes, but my point is that while the resolution / colour change was one aspect of screens, it wasn't really the most interesting one. We relied heavily on screens also for e.g. productivity applications that didn't have a particularly compelling reason to change either.
Many applications had settings to run either in windows on the Workbench screen, or on a separate screen. Some would then let you choose between windows on a separate screen or running effectively full-screen. And using screens like a grouping mechanism like that was overall the more common use of screens other than for e.g. paint applications that needed the different colour modes.
It felt like a less offensive version of Windows MDI concept.
It's not that there are no applications today that approximate it because there absolutely are. It's more that on AmigaOS this was ubiquitous and expected and you didn't need to do anything to fullscreen these applications - only small utilities tended to lack options to run on their own screen.
In later versions of AmigaOS, you could also open "public" screens that like the Workbench screen allowed windows from multiple applications on the same screen, somewhat like virtual desktops, but that somehow felt less compelling, I think because you then relied on separately starting multiple applications.
Ah I understand what you're saying. That was the only way to multitask on the Mac on System 5 and 6. Even with System 7, using the _hide others_ option was common, which is still there today.
Even on big screens, I like MacOS's two level cmd-` to cycle between windows in the same app and cmd-tab to cycle between apps, and App Expose (4 fingers down on the trackpad). I know what I want to find is in another browser window or spreadsheet window.
How do different resolutions (pixel sizes) work? I get that everything memory related (including color mode and depth) could be switched on a raster line.
In theory it should be possible to change the frequency of the video signal mid screen as well, but I have a hard time to imagine switching repeatedly every frame wouldn't have driven the monitors of the time crazy. Even multi-sync monitors needed probably a couple of frames to sync, right?
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.
Kinda, but a CRT literally doesn’t have precise pixel targeting in the way an LCD does. Instead, you’re telling the electron gun to draw red for a little while, and it paints what it paints.
Analog monitors don't care about the dot clock. They draw lines, but you can put whatever signal you want in the lines so long as the dot clock doesn't exceed the available bandwidth. So horizontal resolution is effectively a range you can change at any time and the monitor won't even notice.
Vertical resolution is very much part of the spec, but even then CRTs will sync to hilariously out-of-spec signals that gain or lose lines per frame. Sanely-designed graphics hardware like the Amiga wouldn't do this, but the Atari 2600 wasn't sanely designed and had plenty of games that played fast and loose with NTSC. Atari graphics hardware only generated a single line of graphics and relied on H-Blank effects for literally everything else. Even the vertical retrace signal was controlled by the game. So it was very common to see badly programmed games send too many lines, and a different wrong number of lines each frame, which nobody noticed until people started writing 2600 emulators.
It’s basically just an SD TV signal, the vertical height in lines doesn’t change, it largely just swaps if each line outputs 320 or 640 pixels during its assigned time period.
Having interlaced and non interlaced modes at once seems a bit funky though, but I assume it just forces everything into interlaced with the non interlaced mode sections having the same line sent on both fields?
"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.
No, there is actually a difference between an interlaced and non-interlaced signal. A non-interlaced signal has an integral number of lines per field without the half-line that an interlaced signal would have. With a non-interlaced signal, a classic CRT will scan all of the fields with the same alignment instead of interleaving even/odd fields vertically. There was a definite visual difference between a non-interlaced mode and an interlaced mode repeating the same screen for both fields.
It’s worth noting that this is not actually explicit in the standard so much as it is just a natural consequence of not including the half-line. Since the raster is continually moving across and down, including during all retraces (until the actual blanking pulses reset them), the presence of the half-line means that the horizontal retrace doesn’t reset at the end of the half line, it just continues scanning horizontally while the vblank pulse resets the vertical deflection to the top of the screen. Similarly, all scan lines are actually very slightly tilted down on all CRTs unless there is compensation for it. The vertical deflection is consistently moving across the length of the horizontal trace.
Edit: if you have a set that is miscalibrated or worn out, you can end up actually seeing the retrace lines during what should be blanking
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.
Forgot to add this earlier. Later versions of AmigaOS that support non-15kHz rates will promote all screens to the lowest screen mode that can suppprt all visible screen resolutions. So, if you drag a NTSC:High Res Interlaced (640x400@60i) screen down in front of a Multiscan:Productivity (640x400@70p) screen, then the front screen will also display in Prpductivity mode.
Yeah-- the Atari roots (and Jay Miner's influence) clearly show in the Amiga.
An alternative future fiction I think about, when Commodore or Atari come up in conversation, is one where Irving Gould didn't run Jack Tramiel out of Commodore and Warner Communications listened to Atari's old guard engineers and released new platforms (versus running the home video game industry into the ground trying to milk the 2600 forever).
Obviously, in that world the Amiga would have ended up being an Atari product and the ST a Commodore product. I think both companies would have been healthier and, as such, would have been able to do more with the platforms. Their combined influence might have actually given the IBM PC and Macintosh a run for their money.
I think Atari would have done right by the Amiga. A properly executed version of it would have been a fantastic games console and I think Atari could have done that. It's hard to say what the home and business computer future of an Atari Amiga would have been, but it Atari would have made a kick-ass Amiga console.
Likewise, the ST could have been a lower cost Mac killer, especially if they leaned-in to Mac emulation / compatibility. I think Commodore had the chops and credibility to execute the ST as a business computer in a way the real Tramiel-run Atari never could. Atari couldn't overcome the stigma of Atari being a video game company.
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...
Being earlier to market seems like it would have made a huge difference in competing with the IBM PC. I don't know if the dominance of the PC was a foregone conclusion by 1985. If the Amiga and ST could have been relased in 1984 it might have made a difference. Either way it's fun to think about counterfactuals.
I think the Amiga could have been released at least 6 months earlier if not for the litigation between Tramiel's Atari and Commodore gumming-up the works. The Amiga was massively more capable than the Macintosh of the day-- with preemptive multitasking, color, and NTSC video compatibility. There wasn't a Mac that held a candle to to the OCS Amiga graphics until the Macintosh II in 1987. I think a stronger Amiga marketing presence could have killed Macintosh.
VGA didn't come to the PC until 1987. The Amiga easily exceeded the capabilities of EGA. Windows 1.0 was released in 1985 and is much less capable and sophisticated than Workbench. I don't know much about the evolution of the native Amiga productivity software market. Failing the growth of that market in this counterfactual world arguably the A2000 and a bridge board was probably the first Amiga that could have seriously taken-on the IBM PC. That wasn't until 1987 in our timeline. It might have happened sooner in my hypothetical, but probably not years sooner.
Atari could have marketed the Amiga better than Commodore ever did. I recognize that's not really saying much. The post-Tramiel Commodore was an adrift ship of fools when it came to choosing which products to produce and how to market them. Commodore couldn't figure out what to sell (and how not to cannibalize or compete with their own products) or how to sell what it did produce.
I'm less sure what would have happened if the ST had been released as the Commodore product it arguably was. I do think a world where Tramiel stayed w/ Commodore would have made them more focused. They would have have developed fewer products (and likely no products that competed with other Commodore products) and aggressively driven costs down. I think a Commodore with Tramiel still heading it up would have been in a better position, financially and in terms of market perception, to put out a GUI-based business computer than Atari. I'm just not sure how much sooner I'd want to speculate a Commodore ST could have been released in this hypothetical.
The ST was also positioned more as a Mac killer than a PC killer, like my hypothetical Amiga.
You're likely right, though-- by 1985 the IBM PC was probably destined for dominance.
> I don't know if the dominance of the PC was a foregone conclusion by 1985.
I firmly believe it was, as it's the philosophy (i. e. the open architecture) that gave it such a headstart that the competition couldn't have catched up. Keep in mind what an open architecture really means in the world, i. e. not just the West.
> Failing the growth of that market in this counterfactual world arguably the A2000 and a bridge board was probably the first Amiga that could have seriously taken-on the IBM PC.
Pitting an already well-established and rapidly expanding open architecture and Commodore's first foray into an open architecture against each other wouldn't have, and indeed didn't, play(ed) out in the latter's favor.
The A2000, a workstation-class machine, arrived in March '87. Too late. Around that time Compaq had already sold around 25,000 of their first Deskpro 386 machines, which hit the streets half a year earlier. According to Michael Geran of E. F. Hutton & Co., Compaq sold 90,000 Deskpro 386 computers in the second quarter of '87 alone.
The bridgeboard was an option for cost-conscious operators, especially those with small businesses. They were well-received especially in West Germany where the A2000 sold well. Their limiting nature and performance wouldn't have made them relevant.
> I think a stronger Amiga marketing presence could have killed Macintosh.
> I don't know if the dominance of the PC was a foregone conclusion by 1985
It absolutely was. Simply on account of the name on the grey box.
If it hadn't been IBM, maybe somebody like DEC may have gotten their shit together to take the market instead of farting around with overly high margin products and eating themselves from the inside.
But the way "business" culture was in the 80s the "respectable" productivity machine could not have come from the games/"home" market. Apple maybe but they opted instead to go close off the Apple II line (which in fact had a strong productivity sector thing going on, especially in schools) and push the Macintosh which was a good product but started off weak in terms of capability and costly on price.
In the early to mid-80s it was either going to be a CP/M machine or a CP/M-like machine (like the PC). These are Visicalc/Lotus-123/WordPerfect machines to their customers, and they cared not at all about graphics capabilities until later. Just needed 80 columns, floppies, and reasonable amounts of memory.
Hell there was terror in the microcomputer market when IBM made moves to go "downmarket" into it with the PCjr (which was a flop). The hype leading up to it, and the noises about how it would be a Commodore and Atari killer was insane.
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.
> 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
I don't think a blitter is that big of a deal, especially for games. A sprite/tile architecture would be better for games.
I wish that the ST came with the YM2203, instead of the YM2149. That would make it an even better machine for music, with the addition of 3 4-op FM voices.
Frame rates on games on the ST were terrible, which just came down to there not being enough cycles in a single frame to really move stuff around. Sprites or tiles would be great but are a bit specific. Blitter hardware subsumes all of that under a more general utility. The STe's blitter when it finally came along was great. But by then it was too late, nobody was going to make games for it because the market was too small.
Once clockspeeds got up to what the Falcon could do, it was unnecessary. But again, too late.
The Amiga also struggles with frame rates, with most games running at 30hz/25hz. There are quite a few games that have better gameplay on the Commodore 64 port than the Amiga port.
The only arcade games that use the bitmap/blitter architecture were mostly Williams games like Robotron, Joust, and so forth. Everything else was tiles/sprites, except for the Atari vector games.
Despite its obviously far lower MIPS rating the 6502 could just get more "video game" type work done in a clock cycle than a 68000. 68000 interrupt responsiveness was also pretty terrible.
Looking back 68000 had little business in video game type machines. I like the 68000 from a programming POV but it's faster for doing a pile of fast integer calculations than it is at moving memory around and responding to interrupts.
But Atari and Commodore were also imagining their machines to be targeting productivity more than games, so.
The frame rate of games of the era was dictated by the frame rate of the video output. They would have struggled with higher frame rates, but that was entirely moot.
I mean, that's just pedantic. Of course the display frame rate was fixed. The point is what the effective game loop responsiveness was. which was often a fraction of the actual display's capability. If you go back and play some of the classic games of that era, there's often low responsiveness to joystick movements etc.
Graphic fidelity on the 16-bit machines was great. Latency was sometimes bad, depending on how much they were trying to do in the game loop.
It's not pedantic because it means it was categorically not that the machine "struggled with frame rates" but that the frame rates were imposed by external factors.
I can't recall many games with "low responsiveness to joystick movements". On the contrary, latency from movement to action were typically lower than on modern hardware.
It is being pedantic, the others are talking about Amiga games when they say "the Amiga struggles". While the video output was always 50/60Hz, there were plenty of games that failed to update at that rate, taking 2 frames (25/30Hz) or 3 frames (16/20Hz) or some jittery janky mix inbetween.
It could be that what they wanted to do just couldn't be done in 1 frame. Or often it could, the games were just poorly optimised.
There were plenty of games where the code didn't care to pick up the joystick movements in a reasonable time, making the game feel sluggish, even if the joystick movements can be read directly from the CIA port.
Compare games with perfect framerates like Turrican 2, Superfrog or Leander, with games that don't, like Magic Pockets, Xenon 2, Driller. In fact, compare the official version of Stunt Car Racer with the cracked version, where the crackers massively improved the drawing speed and thus the framerate!
> Or often it could, the games were just poorly optimised.
So in other words it wasn't generally an issue with the Amiga, but with sloppy work.
> There were plenty of games where the code didn't care to pick up the joystick movements in a reasonable time, making the game feel sluggish, even if the joystick movements can be read directly from the CIA port.
We clearly had very different experiences. To me that is not something that every concerned me.
> So in other words it wasn't generally an issue with the Amiga, but with sloppy work.
It's both. Programmers' visions for their games either had to be scaled back because the 68000 just wasn't fast enough, or they implemented what they wanted and it tanked the framerate. Sometimes they met in the middle because the programmers thought 25/30Hz was good enough. Sometimes even the finest programmers, with the most optimised code, ended up with a 25Hz game because what they wanted the game to be demanded it.
Of course, some programmers said "this entire game has to run in 1 frame" and made of sure that. Sometimes it's the same programmers, e.g. Sensible Soccer is typically 1 frame, but Cannon Fodder is often not. Uridium 2 is typically 1 frame but Fire & Ice is often not.
The Amiga 1200 opened up new games possibilities, not just because of its added bitplanes allowing 256 colours, but also because having 2MB of Chip RAM instead of 512KB, and a CPU roughly double the speed, made more games viable.
> We clearly had very different experiences
It will depend on the games you played. Something you can try as a challenge: complete the first level of Magic Pockets on an unmodified Amiga 500 (or an emulation of one at its normal speed). Feel how laggy and awkward it is. Even a video doesn't give you that understanding. Then try the first level of Superfrog.
68020 and onwards could also get substantially more work done in a cycle than a 68000. So Amiga 1200 or Atari Falcon not only had substantially higher bus speeds they were just ... better... at the CPU level in terms of how much work could be done.
I break out this diagram every time Amiga graphics hardware comes up:
https://amigadev.grimore.org/Hardware_Manual_guide/node02d4....
The Amiga had a great trick. Both the CPU and the display/audio hardware share the same RAM (called Chip RAM), so they have to arbitrate for access to it, through a chip called Agnus, which prioritises who gets to read/write memory, depending on importance. You can starve the blitter, you can starve the CPU, but you can't starve the audio or video or disk I/O. As the 68000 CPU only needed memory access every second clock cycle, the Amiga designers arranged it so that the custom chips preferred odd cycles and saved the even cycles for the 68000. So your 68000 runs at full speed.
But if you need more and more work done by the custom chips, it starts to rob some of the even cycles from the 68000.
If you have a 16-colour lowres screen (4 bitplanes), Denise (the chip that turns RAM values into video signals) only reads display data on odd cycles. But if you add another bitplane for 32 colours, she needs some of the even cycles. If you add another bitplane for HAM or EHB mode, she needs even more.
In hires mode, it needs twice the bandwidth for twice the pixels. So if you have a 4-colour hires screen, it only needs odd cycles and the 68000 is full speed. If you go for 8 or 16 colours, it starts slowing the 68000 down.
This is why the default Workbench screen is 4-colour hires. It's hires to look nice and professional like an IBM, and not like a kid's toy like the Atari ST's default lowres GEM interface. It's 4-colours to show it's colourful and not black-and-white, but it's not 8- or 16- colours because that would nearly halve the speed of the CPU !!!
I had an Amiga 500, then a 3000. You could really feel the slow performance with 8 and 16 color Workbench screens on the 500.
>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.
I eventually added another 2 megs of fast RAM to my Amiga. It was a huge boost! 3 megs of RAM in 1990 felt insane.
Neat. 3MB would have been insane. That year, my family bought the 512KB trapdoor expansion for A500, so that we could play Monkey Island. It was every bit worth it!
Of course, the extra 512KB made our Amiga that much more useful, and eventually we did the solder-jumper change to make it chip, as our A500 is a rev6 with the 1MB ECS Agnus.
I still have this A500; now it also has 8mb fast on cpu slot, an ECS denise and a 68010.
Cool! I never knew anyone who did a 68010 upgrade back in the day.
I also had a 30 meg hard drive on my A500 (Supra, which included the RAM expansion.) It was a pretty decent Amiga setup. I taught myself C on that machine (Lattice / SAS C)
> This is why the default Workbench screen is 4-colour hires. It's hires to look nice and professional like an IBM, and not like a kid's toy like the Atari ST's default lowres GEM interface
The Atari ST had a professional resolution of 640x400 monochrome with a 70hz refresh rate. The Amiga had a 640x200 resolution non-interlaced, or a 640x400 interlaced which was basically a kid's toy.
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.
I never knew anyone who used the ECS "productivity" modes. That would've required an expensive multisync monitor since other Amiga stuff would still need the 15 kHz support. The only useful feature of ECS, as far as I can recall, was support for additional chip RAM.
Productivity modes were used a lot with the AGA machines. By that time, VGA monitors were cheap and plentiful.
I knew a few owners of 1200s and 4000s. They all had 1084 monitors. I had a VGA monitor on my 3000 though.
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.
For everyone wondering why there are so many dollar values in the diagram: $ meant hex in the vernacular of the day.
(Could mean string too, but that'd a different story)
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.
Was all this engineered and then implemented, or did they play it by ear? Seems very complex for the time. Now with Pis and ESP32s one can just cobble up together whatever Frankenstein with off the shelf parts, but this seems very elegant with bespoke chips, sans 68000. This is way way way over my head, but intellectually intriguing.
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)
That's one reason why adding fast ram (= exclusive access by the CPU) to an Amiga 1200 doubled the speed of the machine for most workloads without changing the CPU.
But then there ist fast-RAM
Username checks out!
I wish there was a way to recapture the feeling of magic produced by using the Amiga. From usability to programmability, everything seemed exciting, new, and with unlimited possibility.
It really was like going from a black-and-white world to seeing full color.
I always said that if 1% of the effort (and money) put into overcoming the PC architecture's shortcuts was put into the Amiga, the computing world would be in a very different place.
I'm afraid that the feeling of magic if (was) a phenomenon related to passing the boundary between the "black and white" and "full color" worlds, not the "full color" world itself.
What we have now easily available offers much more unlimited possibilities. 24-bit color, 4K resolution, all the 3D you may care about, all the audio you may care about, gigabytes of RAM, terabytes of storage, easy programmability from tinker-friendly stuff like pygame or processing.org or löve to world-construction kits like Godot. Or the whole Web thing. All available at a trivial cost or free. Where's the magic though?
I think that much of the "magic" feeling comes from pushing things to the limit, and beyond. This requires a limited possibility. Basically all art is built around some kind of a limitation and playing with it.
(Being young and having time to tinker with hardware just for the joy of the audiovisual effects goes without saying.)
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.
Maybe its me, but i believe the primary or secondary reason for screen is different screens had different resolutions and color depths, both of which dont really exist these days on any major OS.
I've been thinking a lot about this. Virtual desktops gets us somewhat close, but not quite. You're right the difference in resolution and colour depth isn't really relevant any more.
What I think made screens feel different was as a grouping mechanism, usually driven by a single application (though in more recent versions of AmigaOS you could open "public screens") that would manage the layout for that screen. You can do that with virtual desktops, but it takes some effort to simulate the behaviour.
I'm slowly iterating on something like that for my wm. I now snapshot the (by default tiling) layout and restore it, letting me "open" and "close" screens/virtual desktops, and re-open the applications on them, so instead of opening a single application that opens a screen, I will open a "project" and it will open a desktop and multiple applications on it whose windows will snap into place. I'm not happy with it yet, but it feels somewhat closer to me to how it felt to use Amiga screens.
It feels like the concept faded with the advent of large VRAM and fast fill rate graphics accelerators. I remember old X Window System workstations supporting multiple concurrent windows with different color depths and modes. The hardware would compose windows from memory during display scan-out, all to save VRAM.
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.
The use case definitely exists today:
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.
I think there's a difference between concept and the implementation. I see screens as simply compositing. Different regions have different resolutions and color depths and you use display hardware to combine these together. For modern personal computers, we got this in Windows Vista and OS X 10.0.
Circa 1985 hardware has significant limitations and it's leaking through abstractions both ways. A modern program supporting deep color writes to an array consisting of R16G16B16A16 values, next to a legacy program writing R8G8B8 and even a window with 10-bit 4:2:0 YUV HDR video. On the Amiga, the hardware leaks through by having to deal with separate bit planes and palettes.
Similarly, the 3D hardware in a modern GPU easily upscales a legacy application's surface 1.25x to handle the mid-DPI laptop screen I'm using right now. 1985 hardware can't do that, because you're fiddling with the DAC output, you can only have one screen/ViewPort scan line, no overlapping regions, and if you look carefully, blank lines between regions for the hardware to reconfigure.
Yes, but my point is that while the resolution / colour change was one aspect of screens, it wasn't really the most interesting one. We relied heavily on screens also for e.g. productivity applications that didn't have a particularly compelling reason to change either.
Many applications had settings to run either in windows on the Workbench screen, or on a separate screen. Some would then let you choose between windows on a separate screen or running effectively full-screen. And using screens like a grouping mechanism like that was overall the more common use of screens other than for e.g. paint applications that needed the different colour modes.
It felt like a less offensive version of Windows MDI concept.
It's not that there are no applications today that approximate it because there absolutely are. It's more that on AmigaOS this was ubiquitous and expected and you didn't need to do anything to fullscreen these applications - only small utilities tended to lack options to run on their own screen.
In later versions of AmigaOS, you could also open "public" screens that like the Workbench screen allowed windows from multiple applications on the same screen, somewhat like virtual desktops, but that somehow felt less compelling, I think because you then relied on separately starting multiple applications.
Ah I understand what you're saying. That was the only way to multitask on the Mac on System 5 and 6. Even with System 7, using the _hide others_ option was common, which is still there today.
Even on big screens, I like MacOS's two level cmd-` to cycle between windows in the same app and cmd-tab to cycle between apps, and App Expose (4 fingers down on the trackpad). I know what I want to find is in another browser window or spreadsheet window.
How do different resolutions (pixel sizes) work? I get that everything memory related (including color mode and depth) could be switched on a raster line.
In theory it should be possible to change the frequency of the video signal mid screen as well, but I have a hard time to imagine switching repeatedly every frame wouldn't have driven the monitors of the time crazy. Even multi-sync monitors needed probably a couple of frames to sync, right?
In the context of the Amiga you didn’t need to change the signal frequency, the underlying video signal stayed the same.
For wider pixels, the hardware just drew each pixel for longer, and for taller pixels each pixel spanned more lines.
Pixels weren’t real in the CRT days :)
> 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
Kinda, but a CRT literally doesn’t have precise pixel targeting in the way an LCD does. Instead, you’re telling the electron gun to draw red for a little while, and it paints what it paints.
LCD and OLED panels consist of a fixed, unchangeable matrix of native pixels. (Same for the discontinued Plasma TVs.) CRTs don’t have that.
[dead]
Analog monitors don't care about the dot clock. They draw lines, but you can put whatever signal you want in the lines so long as the dot clock doesn't exceed the available bandwidth. So horizontal resolution is effectively a range you can change at any time and the monitor won't even notice.
Vertical resolution is very much part of the spec, but even then CRTs will sync to hilariously out-of-spec signals that gain or lose lines per frame. Sanely-designed graphics hardware like the Amiga wouldn't do this, but the Atari 2600 wasn't sanely designed and had plenty of games that played fast and loose with NTSC. Atari graphics hardware only generated a single line of graphics and relied on H-Blank effects for literally everything else. Even the vertical retrace signal was controlled by the game. So it was very common to see badly programmed games send too many lines, and a different wrong number of lines each frame, which nobody noticed until people started writing 2600 emulators.
It’s basically just an SD TV signal, the vertical height in lines doesn’t change, it largely just swaps if each line outputs 320 or 640 pixels during its assigned time period.
Having interlaced and non interlaced modes at once seems a bit funky though, but I assume it just forces everything into interlaced with the non interlaced mode sections having the same line sent on both fields?
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
No, there is actually a difference between an interlaced and non-interlaced signal. A non-interlaced signal has an integral number of lines per field without the half-line that an interlaced signal would have. With a non-interlaced signal, a classic CRT will scan all of the fields with the same alignment instead of interleaving even/odd fields vertically. There was a definite visual difference between a non-interlaced mode and an interlaced mode repeating the same screen for both fields.
It’s worth noting that this is not actually explicit in the standard so much as it is just a natural consequence of not including the half-line. Since the raster is continually moving across and down, including during all retraces (until the actual blanking pulses reset them), the presence of the half-line means that the horizontal retrace doesn’t reset at the end of the half line, it just continues scanning horizontally while the vblank pulse resets the vertical deflection to the top of the screen. Similarly, all scan lines are actually very slightly tilted down on all CRTs unless there is compensation for it. The vertical deflection is consistently moving across the length of the horizontal trace.
Edit: if you have a set that is miscalibrated or worn out, you can end up actually seeing the retrace lines during what should be blanking
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.
Forgot to add this earlier. Later versions of AmigaOS that support non-15kHz rates will promote all screens to the lowest screen mode that can suppprt all visible screen resolutions. So, if you drag a NTSC:High Res Interlaced (640x400@60i) screen down in front of a Multiscan:Productivity (640x400@70p) screen, then the front screen will also display in Prpductivity mode.
I don’t know much about Amiga, but from this article I recognize the Atari 8 bit / ANTIC DLI heritage at play!
Yeah-- the Atari roots (and Jay Miner's influence) clearly show in the Amiga.
An alternative future fiction I think about, when Commodore or Atari come up in conversation, is one where Irving Gould didn't run Jack Tramiel out of Commodore and Warner Communications listened to Atari's old guard engineers and released new platforms (versus running the home video game industry into the ground trying to milk the 2600 forever).
Obviously, in that world the Amiga would have ended up being an Atari product and the ST a Commodore product. I think both companies would have been healthier and, as such, would have been able to do more with the platforms. Their combined influence might have actually given the IBM PC and Macintosh a run for their money.
I think Atari would have done right by the Amiga. A properly executed version of it would have been a fantastic games console and I think Atari could have done that. It's hard to say what the home and business computer future of an Atari Amiga would have been, but it Atari would have made a kick-ass Amiga console.
Likewise, the ST could have been a lower cost Mac killer, especially if they leaned-in to Mac emulation / compatibility. I think Commodore had the chops and credibility to execute the ST as a business computer in a way the real Tramiel-run Atari never could. Atari couldn't overcome the stigma of Atari being a video game company.
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...
Being earlier to market seems like it would have made a huge difference in competing with the IBM PC. I don't know if the dominance of the PC was a foregone conclusion by 1985. If the Amiga and ST could have been relased in 1984 it might have made a difference. Either way it's fun to think about counterfactuals.
I think the Amiga could have been released at least 6 months earlier if not for the litigation between Tramiel's Atari and Commodore gumming-up the works. The Amiga was massively more capable than the Macintosh of the day-- with preemptive multitasking, color, and NTSC video compatibility. There wasn't a Mac that held a candle to to the OCS Amiga graphics until the Macintosh II in 1987. I think a stronger Amiga marketing presence could have killed Macintosh.
VGA didn't come to the PC until 1987. The Amiga easily exceeded the capabilities of EGA. Windows 1.0 was released in 1985 and is much less capable and sophisticated than Workbench. I don't know much about the evolution of the native Amiga productivity software market. Failing the growth of that market in this counterfactual world arguably the A2000 and a bridge board was probably the first Amiga that could have seriously taken-on the IBM PC. That wasn't until 1987 in our timeline. It might have happened sooner in my hypothetical, but probably not years sooner.
Atari could have marketed the Amiga better than Commodore ever did. I recognize that's not really saying much. The post-Tramiel Commodore was an adrift ship of fools when it came to choosing which products to produce and how to market them. Commodore couldn't figure out what to sell (and how not to cannibalize or compete with their own products) or how to sell what it did produce.
I'm less sure what would have happened if the ST had been released as the Commodore product it arguably was. I do think a world where Tramiel stayed w/ Commodore would have made them more focused. They would have have developed fewer products (and likely no products that competed with other Commodore products) and aggressively driven costs down. I think a Commodore with Tramiel still heading it up would have been in a better position, financially and in terms of market perception, to put out a GUI-based business computer than Atari. I'm just not sure how much sooner I'd want to speculate a Commodore ST could have been released in this hypothetical.
The ST was also positioned more as a Mac killer than a PC killer, like my hypothetical Amiga.
You're likely right, though-- by 1985 the IBM PC was probably destined for dominance.
> I don't know if the dominance of the PC was a foregone conclusion by 1985.
I firmly believe it was, as it's the philosophy (i. e. the open architecture) that gave it such a headstart that the competition couldn't have catched up. Keep in mind what an open architecture really means in the world, i. e. not just the West.
> Failing the growth of that market in this counterfactual world arguably the A2000 and a bridge board was probably the first Amiga that could have seriously taken-on the IBM PC.
Pitting an already well-established and rapidly expanding open architecture and Commodore's first foray into an open architecture against each other wouldn't have, and indeed didn't, play(ed) out in the latter's favor.
The A2000, a workstation-class machine, arrived in March '87. Too late. Around that time Compaq had already sold around 25,000 of their first Deskpro 386 machines, which hit the streets half a year earlier. According to Michael Geran of E. F. Hutton & Co., Compaq sold 90,000 Deskpro 386 computers in the second quarter of '87 alone.
The bridgeboard was an option for cost-conscious operators, especially those with small businesses. They were well-received especially in West Germany where the A2000 sold well. Their limiting nature and performance wouldn't have made them relevant.
> I think a stronger Amiga marketing presence could have killed Macintosh.
That is an intriguing possibility!
> I don't know if the dominance of the PC was a foregone conclusion by 1985
It absolutely was. Simply on account of the name on the grey box.
If it hadn't been IBM, maybe somebody like DEC may have gotten their shit together to take the market instead of farting around with overly high margin products and eating themselves from the inside.
But the way "business" culture was in the 80s the "respectable" productivity machine could not have come from the games/"home" market. Apple maybe but they opted instead to go close off the Apple II line (which in fact had a strong productivity sector thing going on, especially in schools) and push the Macintosh which was a good product but started off weak in terms of capability and costly on price.
In the early to mid-80s it was either going to be a CP/M machine or a CP/M-like machine (like the PC). These are Visicalc/Lotus-123/WordPerfect machines to their customers, and they cared not at all about graphics capabilities until later. Just needed 80 columns, floppies, and reasonable amounts of memory.
Hell there was terror in the microcomputer market when IBM made moves to go "downmarket" into it with the PCjr (which was a flop). The hype leading up to it, and the noises about how it would be a Commodore and Atari killer was insane.
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.
> 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
I don't think a blitter is that big of a deal, especially for games. A sprite/tile architecture would be better for games.
I wish that the ST came with the YM2203, instead of the YM2149. That would make it an even better machine for music, with the addition of 3 4-op FM voices.
Frame rates on games on the ST were terrible, which just came down to there not being enough cycles in a single frame to really move stuff around. Sprites or tiles would be great but are a bit specific. Blitter hardware subsumes all of that under a more general utility. The STe's blitter when it finally came along was great. But by then it was too late, nobody was going to make games for it because the market was too small.
Once clockspeeds got up to what the Falcon could do, it was unnecessary. But again, too late.
The Amiga also struggles with frame rates, with most games running at 30hz/25hz. There are quite a few games that have better gameplay on the Commodore 64 port than the Amiga port.
The only arcade games that use the bitmap/blitter architecture were mostly Williams games like Robotron, Joust, and so forth. Everything else was tiles/sprites, except for the Atari vector games.
Despite its obviously far lower MIPS rating the 6502 could just get more "video game" type work done in a clock cycle than a 68000. 68000 interrupt responsiveness was also pretty terrible.
Looking back 68000 had little business in video game type machines. I like the 68000 from a programming POV but it's faster for doing a pile of fast integer calculations than it is at moving memory around and responding to interrupts.
But Atari and Commodore were also imagining their machines to be targeting productivity more than games, so.
The frame rate of games of the era was dictated by the frame rate of the video output. They would have struggled with higher frame rates, but that was entirely moot.
I mean, that's just pedantic. Of course the display frame rate was fixed. The point is what the effective game loop responsiveness was. which was often a fraction of the actual display's capability. If you go back and play some of the classic games of that era, there's often low responsiveness to joystick movements etc.
Graphic fidelity on the 16-bit machines was great. Latency was sometimes bad, depending on how much they were trying to do in the game loop.
It's not pedantic because it means it was categorically not that the machine "struggled with frame rates" but that the frame rates were imposed by external factors.
I can't recall many games with "low responsiveness to joystick movements". On the contrary, latency from movement to action were typically lower than on modern hardware.
It is being pedantic, the others are talking about Amiga games when they say "the Amiga struggles". While the video output was always 50/60Hz, there were plenty of games that failed to update at that rate, taking 2 frames (25/30Hz) or 3 frames (16/20Hz) or some jittery janky mix inbetween.
It could be that what they wanted to do just couldn't be done in 1 frame. Or often it could, the games were just poorly optimised.
There were plenty of games where the code didn't care to pick up the joystick movements in a reasonable time, making the game feel sluggish, even if the joystick movements can be read directly from the CIA port.
Compare games with perfect framerates like Turrican 2, Superfrog or Leander, with games that don't, like Magic Pockets, Xenon 2, Driller. In fact, compare the official version of Stunt Car Racer with the cracked version, where the crackers massively improved the drawing speed and thus the framerate!
Compare the scrolling of https://youtu.be/V1R7Pd329Bc?t=1969 or https://youtu.be/wFtLGDywZlg?t=553 with https://youtu.be/_4U4ZW37haU?t=114 or https://youtu.be/BXR2yswfC6E?t=862 -- it's purely the programmer's fault.
> Or often it could, the games were just poorly optimised.
So in other words it wasn't generally an issue with the Amiga, but with sloppy work.
> There were plenty of games where the code didn't care to pick up the joystick movements in a reasonable time, making the game feel sluggish, even if the joystick movements can be read directly from the CIA port.
We clearly had very different experiences. To me that is not something that every concerned me.
> So in other words it wasn't generally an issue with the Amiga, but with sloppy work.
It's both. Programmers' visions for their games either had to be scaled back because the 68000 just wasn't fast enough, or they implemented what they wanted and it tanked the framerate. Sometimes they met in the middle because the programmers thought 25/30Hz was good enough. Sometimes even the finest programmers, with the most optimised code, ended up with a 25Hz game because what they wanted the game to be demanded it.
Of course, some programmers said "this entire game has to run in 1 frame" and made of sure that. Sometimes it's the same programmers, e.g. Sensible Soccer is typically 1 frame, but Cannon Fodder is often not. Uridium 2 is typically 1 frame but Fire & Ice is often not.
The Amiga 1200 opened up new games possibilities, not just because of its added bitplanes allowing 256 colours, but also because having 2MB of Chip RAM instead of 512KB, and a CPU roughly double the speed, made more games viable.
> We clearly had very different experiences
It will depend on the games you played. Something you can try as a challenge: complete the first level of Magic Pockets on an unmodified Amiga 500 (or an emulation of one at its normal speed). Feel how laggy and awkward it is. Even a video doesn't give you that understanding. Then try the first level of Superfrog.
68020 and onwards could also get substantially more work done in a cycle than a 68000. So Amiga 1200 or Atari Falcon not only had substantially higher bus speeds they were just ... better... at the CPU level in terms of how much work could be done.
As an Amiga user that sounds like a horrible alternative future...
The Amiga is before my time, but I'm getting TempleOS vibes a bit, graphics-wise.