The PCI bus is a *very* nice bus, perhaps the most modern bus design on the planet, at with with PCIe. It is used on a number of non-x86 architectures, most notably Sun SPARC boxes. I would be more than a bit surprised if Apple didn't eventually adopt it regardless of their decision to go to x86.
I can't speak to the merits of ATI's chips, but isn't having any decent GPU better than having none at all? Certainly GPUs were a relatively new thing in the Macintosh world, and you have to get your GPUs from *somebody*.
It is too bad that Firewire is on the way out, though.
Even Intel thinks they can do better now, but their RISC and later VLIW efforts failed in the face of x86-entrenchedness
So why don't they just make a processor that can handle two instruction sets, and phase the old instruction set out?
I have never been convinced that Intel wanted the Itanium to replace the x86 architecture, because it was too exotic and cost too much. More like an attempt to capture part of the high end server market away from POWER, SPARC, and Alpha. It certainly did a pretty good job of cannibalizing the latter, in some sort of mutual suicide pact.
The Itanium was so inappropriate as an x86 upgrade path that Intel deserves half of the credit for establishing x86 dominance for another generation. AMD the other half of course.
Thanks for the clarification on cooperative multitasking in System 7. That, I have to admit, is enough to consider Mac System 7 a real "operating system".
MS-DOS, of course, isn't a general purpose operating system at all. More like a "disk driver", or a system that operates disks, hence the name Disk Operating System. If they thought DOS was an operating system they would have called it "MS-OS".
The 1984 Mac world had Desk Accessories.
Yes, but Mac desk accessories were more like toys than real applications, the rough equivalent of terminate-and-stay-resident (TSR) utilities like Sidekick on MS-DOS. They were programmed completely differently, had all sorts of special rules, and most particularly could use only a relatively small amount of memory.
I wasn't particularly fond of the original Macs - expensive, black and white, no shades of grey, 512x342 pixel screen, usually 512K of RAM, and not particularly expandable. It wasn't hard to prefer an Amiga over a machine that had hardware like that. Tables were reversed as soon as the (color) Mac II variants became affordable though, although by that time the Amiga was on the way out, and for very good reasons, unfortunately.
don't get me started on how much better of an OS System 7 was as compared to AmigaOS
System 7 was a great (even outstanding) environment, to be sure, but I think it is a stretch to call it an "operating system", in the modern sense of the term. For all its advantages, it wasn't really even multitasking, let alone preemptively multitasking. More like (manual) application switching, something that was considered revolutionary in the Mac world circa 1984. Andy Hertzfeld was considered a hero for figuring out how to do that, because the system just wasn't designed for it.
Anything else would break backward compatibility with a design that had programs regularly tweaking system variables at fixed addresses in low memory and doing all sorts of other dangerous and intrusive things with no locking whatsoever. That is where Amiga OS was superior, from the very outset - it was designed to do preemptive multitasking in a big way, and did it very well, with minimal resources. I used to start up a dozen little programs or three or four command shells on an Amiga with 256K(!) of memory, and they would all update the screen very nicely, no matter what I was doing.
That's not to say that the Mac didn't become a much nicer environment for a wide variety of applications once the (originally very expensive) Mac II came out, pre-emptive multitasking or not. I certainly wanted one. I like the look of System 7 better than that of Mac OS X. And Quark was a program to die for...
I think you are neglecting the merits of having a (preemptively) multitasking operating system with a decent user interface in the first place, something that was a major attraction to a lot of people. Windows was ugly by comparison, up until the day Windows NT 4 was released.
The OS overhead could be a bit much for games, but slow compared to not having a blitter at all? There were plenty of games that didn't need to go outside the operating system, other than occasionally writing to the frame buffer of course (which was perfectly legitimate). Why reinvent functionality that is perfectly adequate (for what you are doing) in the first place?
The operating system made a *big* difference though. The Atari ST had decent hardware, and lots of great games, but the operating system was basically a DOS clone with a non-multitasking (and rather simple minded) graphical environment thrown on top of it. On the Amiga, open a half dozen command line shells, an editor, and a paint program - no problem. On the Atari ST, with its comparable hardware (in most respects) it was all one program at a time, which made it *much* less fun in real life. That is the difference the OS makes.
Twenty years ago? I don't think so. Twenty years ago Amiga popularity was at its peak. Fifteen years ago, on the other hand (especially with the advent of Window 95), it was clearly on the decline, and virtually dead not too long afterwards.
[begin rant] X is precisely everything the Amiga was not, an innovation that set open systems graphics back by at least a decade. Aside from an SGI app here or there I never saw an X interface that looked good until 1998 or so. Functional yes, attractive compared to the alternatives, not in the slightest.
X was so poorly designed that network transparency, which should have been its greatest strength, was essentially unusable anywhere other than the local LAN, and still is to this day. RDP runs circles around what X can do, for example, across any real network. To get X to perform like RDP you have to have an intermediary layer like NX that uses all sorts of tricks to work around the design deficiencies of X in the first place. You have to use some sort of wrapping protocol just to get rudimentary security, so you can actually open a remote terminal session across the Internet, a wrapper for which there are no real standards, and which doesn't come configured or installed on a default basis practically anywhere. Let's run SSH, map a bunch of ports, and set a half dozen environment variables! No thank you.
Regrettably, the history of X largely consists of undoing or making extensions to work around the severe limitations of the original design, limitations that (among other things) made X programming more difficult than practically any other graphics system on the planet, with the possible exception of (horror of horrors) Win32. [end rant]
Well, I'm all for taking out everyone who develops a inner platform, and shooting him.
That will work great when the day comes where we are all running essentially the same operating system, with the same graphical environment, libraries, utilities, and all. None of this KDE vs. GNOME stuff.
And isn't virtually every programming language on the planet just an inner platform for C and kernel level system calls?
At work, I have a $10 hunk of Chinese plastic called a monitor stand that includes a keyboard caddy. Works just as well.
Not nearly as pretty, I bet. Amiga 1000s were the best looking computers around.
Regardless, hardware abstraction is what made the move from PCI to AGP to PCIe so simple.
PCI, AGP, and PCIe are all bus abstractions. A program that (for example) writes to a frame buffer doesn't really have to care about the distinction at all. Have the video BIOS set the mode, and away you go.
The problem is when the resolution is completely different than what you are expecting, and then you need device independent graphics in a big way, something usually difficult to handle without operating system support.
In principle though, we could define a standard hardware level interface to each type of I/O card and we would hardly need device drivers at all. The Macintosh II video support was like this. Every video card had to have a bitmapped frame buffer that the OS (and applications) could access with one of a handful of pixel depths and pixel formats, or the OS wouldn't support it.
It is like when CD-ROMs first came out for PCs. What do you mean, I have to install one of a dozen different device drivers to access a CD-ROM? Booting from a CD-ROM was impossible.
The best part about Amiga audio was the per channel 6 bit volume modulation, which made it possible to effectively have four channels of fourteen bit digital audio, each with independent sample rates and excellent dynamic range, using hardware that was much superior to that common on PCs for a very long time. Sampled digital audio cards weren't common on PCs until what, 1995? If you didn't have a sound card at all you got wonderful one bit sound, like the Apple II.
4,096 colors (when the PC was limited to 16...)
When the Amiga came out, the only common bitmapped graphics support on PCs was CGA, which had four selections of four fixed, extremely ugly colors. You only got 16 (fixed) colors in text mode. When EGA came out, you still only got a set of 16 fixed colors to choose from. PC graphics were pathetic until VGA became common, and then only for low resolution games.
It sounds like you are talking about auto-stretch scaling. That the monitor is at 800x600, the game is 320x240 and is automatically up-scaled to 800x600 by the OS.
There were only two basic horizontal resolutions on a standard Amiga - 320 and 640. There was hardware to switch resolutions (and palettes and bit depths) on a scan line by scan line basis. There were no aliasing problems because there was no real scaling done, the graphic chip just output pixels at one of two different rates (albeit with different palettes and bit depths), potentially on a line by line basis.
So you could grab the menu bar at the top of the screen and pull it down (vertically) to reveal another screen behind it. Separate frame buffers - one program (games and paint programs especially) could write all over the frame buffer of a screen that was invisible or only partially visible on the screen. All this vertical screen motion didn't involve moving any bits around in memory, so it was instantaneous - no waiting for anything to redraw.
The Amiga allowed you to dedicate back buffers (so called "smart refresh") to ordinary windows as well, to avoid redraws when a part of a window was exposed or brought to the front. Screen level double buffering, hardware line drawing, pixel blitting, bitmap movement, vertical palette changes, hardware sprites, all par for the course.
With a hardware sprite, for example, you could have a mouse pointer that moved around without ever touching the underlying frame buffer. The application didn't care, didn't worry, the mouse pointer was just an operating system controlled sprite that was overlaid on the video output in hardware. None of this "hide the mouse pointer", then draw, then restore (or XOR) the mouse pointer stuff that was common in competing operating systems at the time.
Similar hardware, by the way, was used to implement many of the early Atari game machines, inexpensive consoles that often implemented very nice games with only 4K of RAM (albeit typically 16 or more kilobytes of game cartridge ROM on top of that). On Atari game consoles there was usually no bitmap at all, just a bunch of hardware tiles and sprites. Can't fit much of a bitmap in 4K of RAM (or less in some cases).
In any case, the Atari graphics hardware guy ended up at Amiga, and the remaining Atari folks designed an Amiga competitor (the Atari ST) with very conventional frame buffer support and none of the exotic graphics hardware goodness Atari had a considerable reputation for, let alone as implemented on steroids in the Amiga hardware design, at very low cost.
That is why it is much more practical to deal with the Amiga Research OS (AROS) or an Amiga emulator, which both run on x86 boxes. You would have to be quite a diehard or have a very special application to purchase a contemporary PPC Amiga.
It is worth mentioning that when they first came out, Amigas were much less expensive than (color) Macintoshes, and rather less expensive than any remotely comparable PC as well. Most of the games in the PC world ran in four (fixed, ugly) color CGA at the time. Apple II games were much better looking than that, on machines with a tiny fraction of the resources.
It only needs to read the data back in if it has given the space to another process
That is the way it *ought* to work. In reality, applications get completely paged to disk after any extended idle period, and sooner than that if there is any significant disk activity. Linux pages out process pages in favor of disk buffers all the time. So you come back a few hours later, hit a key and wait five or ten seconds while everything pages back in again. Compared to an Amiga, that is really annoying. It's even (horror of horrors) worse than Windows. I haven't noticed my Windows PC swap in years.
To be fair, I think there is a setting where you can tweak that to some degree,/proc/sys/vm/swappiness or something like that.
Atari TOS wasn't really an operating system in the modern sense of the term. More like a nice version of DOS, complete with 8.3 filenames and no multi-tasking to speak of. GEM wasn't half bad, but it was woefully limited compared to the Amiga windowing system, unless a single running application with a small number of windows was all you needed.
I really liked the Atari monitors though - they were extraordinarily crisp. And the Atari ST hard drives were faster (and more common at first) than ones for the Amiga. Atari STs often had more RAM too. And the Atari monochrome mode (with the right monitor) produced much more stable displays at high resolutions - no interlacing required. That was a disadvantage of the Amiga until the Amiga 3000 came out, especially for desktop publishing applications.
Personally, I like Deluxe Paint better than anything I have seen since then. Other than a few applications like that (and modern ports thereof) it is probably mostly a hobby thing.
The Amiga is extremely easy to program for, so one of these days there might be a number of useful applications that people might run a VM for. Or it could escape the VM and be used as an operating system for embedded systems. Amiga programming is certainly a lot easier than Linux kernel mode programming. Of course (by comparison) there aren't any device drivers to speak of.
When I had an Amiga, way back when, I didn't use it to get any "real work" done except software development (I worked on computer games). But it was an enormous amount of fun as a hobby computer just installing and running the sort of things you could could get on "Fred Fish" disks. Amiga Basic had its quirks, but it was a lot better hobbyist type language than the business oriented corruption Visual Basic became. I would rather play with Applesoft Basic than Visual Basic. All three versions of BASIC courtesy of Microsoft, of course.
The big problem with modern, memory protected, multiple address space operating systems is that you could no longer get direct address to the frame buffer or the other hardware. That makes programming quick and dirty hobbyist type applications much harder than it was on systems that did not have such restrictions. On the Amiga I could trivially control hardware from *Basic* using no more than peeks and pokes. Or draw all over the frame buffer, or write sound applications without going through a half dozen layers of operating system indirection, and so on. Of course AROS probably doesn't work like that any more, unfortunately. Other advantages aside, it is no fun feeling alienated from the hardware. Kernel programming just isn't quite the same - radically more complex and error prone these days, for one thing.
Better than the original Mac, absolutely. Better than the Mac II, for many things, yes. Video production, games, most entry level applications, yes. The Mac II was *expensive* and often slow by comparison.
For graphic design and desktop publishing not so much. That is where the Mac II really shined. There was nothing comparable to Quark on the Amiga. Device independent or high bit depth raster graphics on the Amiga were the exception, not the rule. The sort of thing that made the Mac slower at first, and the Amiga lacking a few years later.
Relative to what it was trying to accomplish, the Apple IIgs was the slowest computer I have ever used. Imagine trying to backport a subset of Mac OS Classic to a 2.8 Mhz 16 bit CPU with an 8 bit data bus. The early Macs were slow enough (i.e. barely tolerable) even with a much better processor at two and a half times the clock rate.
By comparison, the Amiga (and the Atari ST in its own way) was just plain fast.
And Mac OS "classic" was not an OS, was a crash-prone, non-multitasking toy.
Yes. Structurally speaking, Mac OS Classic was about as much an operating system as DOS was (aside from a a very nice GUI programming environment). One application running at a time, and special tricks required to switch to anything else. Programs were statically compiled to access critical system state variables at fixed addresses in low memory, there was no locking, no scheduler, etc. There was no real multitasking because of that, not even cooperative multitasking.
By comparison Amiga OS was a modern multiprocess multitasking operating system in every way except originally there was no memory protection, and no virtual memory. More like a modern embedded system than a general purpose operating system, but *very* fast, and ridiculously easy to program for.
Sorry, you can keep this feature. I, for one, like having things like disk caching that works.
In order to safely flip the power switch to power off an early Amiga, you had to wait until all pending disk writes were complete. This was pretty easy to do if you didn't have any disk writing background tasks running. Just wait for the drive lights to go out and then wait another couple of seconds for the superblock write to happen (which causes the drive light to flash a second time), and then you were good.
Woe be to the person who didn't wait for the second flash, because he/she would generally have to repair the disk on reboot. That happened to me a couple of times before I learned my lesson.
The real performance advantage of the early Amigas over many modern PCs is *no virtual memory*. It is amazingly fast to do just about anything if half of your applications haven't paged out to disk, as Linux is wont to do for inactive processes even when there are gigabytes of free memory in the system.
The Amiga, of course, originally didn't have any memory protection, which made programmers very careful. If you want to develop something for a quasi-embedded system it is ten times easier to debug "kernel level" code on an Amiga than for practically any other system, because the debugger, editor, test tools, etc. are all running in the same address space as what is being tested.
If you develop kernel mode code your kernel will crash and burn anyway, especially painful if you are on the same system, so it is awfully convenient to take advantage of the simplicity it allows. Even with memory protection turned on, Amiga OS is a single address space operating system. It is ridiculously simple to develop multitasking systems for a single address space OS compared to the hoops you have to jump through to do the same things in user mode in a more traditional Unix style operating system. Much higher performance too, of course.
Making the drive handle things at the file level is the equivalent of turning it into a NAS device where the system software would generally be inaccessible, unmodifiable, and un-upgradeable, unfortunately. It would still be an interesting engineering challenge, of course.
The "compatibility mode" jumper shifts the alignment of logical block addresses to the underlying physical sectors so that instead of the physical sectors starting at LBAs that are a multiple of 8, they instead start at LBAs that are a multiple of 8, minus 1. That way the first partition, which traditionally starts at LBA 63, will be physical sector aligned. No gratuitous read modify write, no performance penalty, at least for the first partition.
Of course you don't want to switch the jumper on a formatted drive, because the position of all the data will shift by 512 bytes, making it look like garbage to any ordinary filesystem.
Actually, with flash drives everything related to the issue is much *worse*, due to the way flash works - the internal block sizes are huge (128KB). Because of this, contemporary flash drives are enormously complex, sort of like a filesystem with a 128 KB internal block size that sub allocates (and moves around, and coalesces) lots of little 512 byte "sectors" for presentation to the outside world.
That doesn't do any good if the partition it is on starts with an LBA that is not a multiple of 8. Windows versions prior to Vista create the first partition starting at LBA 63, which is not 4KB aligned.
The people who will have performance problems will primarily be Windows XP users who purchase the newer style drives and do not realign the first partition accordingly. Some versions of "fdisk" on Linux have a similar deficiency, with an "cylinder" based user interface and odd size cylinders in the name of MSDOS compatibility. Not sure if that has been fixed yet.
Slashdot Mirror
The PCI bus is a *very* nice bus, perhaps the most modern bus design on the planet, at with with PCIe. It is used on a number of non-x86 architectures, most notably Sun SPARC boxes. I would be more than a bit surprised if Apple didn't eventually adopt it regardless of their decision to go to x86.
I can't speak to the merits of ATI's chips, but isn't having any decent GPU better than having none at all? Certainly GPUs were a relatively new thing in the Macintosh world, and you have to get your GPUs from *somebody*.
It is too bad that Firewire is on the way out, though.
Even Intel thinks they can do better now, but their RISC and later VLIW efforts failed in the face of x86-entrenchedness
So why don't they just make a processor that can handle two instruction sets, and phase the old instruction set out?
I have never been convinced that Intel wanted the Itanium to replace the x86 architecture, because it was too exotic and cost too much. More like an attempt to capture part of the high end server market away from POWER, SPARC, and Alpha. It certainly did a pretty good job of cannibalizing the latter, in some sort of mutual suicide pact.
The Itanium was so inappropriate as an x86 upgrade path that Intel deserves half of the credit for establishing x86 dominance for another generation. AMD the other half of course.
Thanks for the clarification on cooperative multitasking in System 7. That, I have to admit, is enough to consider Mac System 7 a real "operating system".
MS-DOS, of course, isn't a general purpose operating system at all. More like a "disk driver", or a system that operates disks, hence the name Disk Operating System. If they thought DOS was an operating system they would have called it "MS-OS".
The 1984 Mac world had Desk Accessories.
Yes, but Mac desk accessories were more like toys than real applications, the rough equivalent of terminate-and-stay-resident (TSR) utilities like Sidekick on MS-DOS. They were programmed completely differently, had all sorts of special rules, and most particularly could use only a relatively small amount of memory.
I wasn't particularly fond of the original Macs - expensive, black and white, no shades of grey, 512x342 pixel screen, usually 512K of RAM, and not particularly expandable. It wasn't hard to prefer an Amiga over a machine that had hardware like that. Tables were reversed as soon as the (color) Mac II variants became affordable though, although by that time the Amiga was on the way out, and for very good reasons, unfortunately.
OS/2? On a 68000? Are you sure about that?
don't get me started on how much better of an OS System 7 was as compared to AmigaOS
System 7 was a great (even outstanding) environment, to be sure, but I think it is a stretch to call it an "operating system", in the modern sense of the term. For all its advantages, it wasn't really even multitasking, let alone preemptively multitasking. More like (manual) application switching, something that was considered revolutionary in the Mac world circa 1984. Andy Hertzfeld was considered a hero for figuring out how to do that, because the system just wasn't designed for it.
Anything else would break backward compatibility with a design that had programs regularly tweaking system variables at fixed addresses in low memory and doing all sorts of other dangerous and intrusive things with no locking whatsoever. That is where Amiga OS was superior, from the very outset - it was designed to do preemptive multitasking in a big way, and did it very well, with minimal resources. I used to start up a dozen little programs or three or four command shells on an Amiga with 256K(!) of memory, and they would all update the screen very nicely, no matter what I was doing.
That's not to say that the Mac didn't become a much nicer environment for a wide variety of applications once the (originally very expensive) Mac II came out, pre-emptive multitasking or not. I certainly wanted one. I like the look of System 7 better than that of Mac OS X. And Quark was a program to die for...
I think you are neglecting the merits of having a (preemptively) multitasking operating system with a decent user interface in the first place, something that was a major attraction to a lot of people. Windows was ugly by comparison, up until the day Windows NT 4 was released.
The OS overhead could be a bit much for games, but slow compared to not having a blitter at all? There were plenty of games that didn't need to go outside the operating system, other than occasionally writing to the frame buffer of course (which was perfectly legitimate). Why reinvent functionality that is perfectly adequate (for what you are doing) in the first place?
The operating system made a *big* difference though. The Atari ST had decent hardware, and lots of great games, but the operating system was basically a DOS clone with a non-multitasking (and rather simple minded) graphical environment thrown on top of it. On the Amiga, open a half dozen command line shells, an editor, and a paint program - no problem. On the Atari ST, with its comparable hardware (in most respects) it was all one program at a time, which made it *much* less fun in real life. That is the difference the OS makes.
Twenty years ago? I don't think so. Twenty years ago Amiga popularity was at its peak. Fifteen years ago, on the other hand (especially with the advent of Window 95), it was clearly on the decline, and virtually dead not too long afterwards.
[begin rant] X is precisely everything the Amiga was not, an innovation that set open systems graphics back by at least a decade. Aside from an SGI app here or there I never saw an X interface that looked good until 1998 or so. Functional yes, attractive compared to the alternatives, not in the slightest.
X was so poorly designed that network transparency, which should have been its greatest strength, was essentially unusable anywhere other than the local LAN, and still is to this day. RDP runs circles around what X can do, for example, across any real network. To get X to perform like RDP you have to have an intermediary layer like NX that uses all sorts of tricks to work around the design deficiencies of X in the first place. You have to use some sort of wrapping protocol just to get rudimentary security, so you can actually open a remote terminal session across the Internet, a wrapper for which there are no real standards, and which doesn't come configured or installed on a default basis practically anywhere. Let's run SSH, map a bunch of ports, and set a half dozen environment variables! No thank you.
Regrettably, the history of X largely consists of undoing or making extensions to work around the severe limitations of the original design, limitations that (among other things) made X programming more difficult than practically any other graphics system on the planet, with the possible exception of (horror of horrors) Win32.
[end rant]
Well, I'm all for taking out everyone who develops a inner platform, and shooting him.
That will work great when the day comes where we are all running essentially the same operating system, with the same graphical environment, libraries, utilities, and all. None of this KDE vs. GNOME stuff.
And isn't virtually every programming language on the planet just an inner platform for C and kernel level system calls?
At work, I have a $10 hunk of Chinese plastic called a monitor stand that includes a keyboard caddy. Works just as well.
Not nearly as pretty, I bet. Amiga 1000s were the best looking computers around.
Regardless, hardware abstraction is what made the move from PCI to AGP to PCIe so simple.
PCI, AGP, and PCIe are all bus abstractions. A program that (for example) writes to a frame buffer doesn't really have to care about the distinction at all. Have the video BIOS set the mode, and away you go.
The problem is when the resolution is completely different than what you are expecting, and then you need device independent graphics in a big way, something usually difficult to handle without operating system support.
In principle though, we could define a standard hardware level interface to each type of I/O card and we would hardly need device drivers at all. The Macintosh II video support was like this. Every video card had to have a bitmapped frame buffer that the OS (and applications) could access with one of a handful of pixel depths and pixel formats, or the OS wouldn't support it.
It is like when CD-ROMs first came out for PCs. What do you mean, I have to install one of a dozen different device drivers to access a CD-ROM? Booting from a CD-ROM was impossible.
Hardware accelerated 4-channel digital audio
The best part about Amiga audio was the per channel 6 bit volume modulation, which made it possible to effectively have four channels of fourteen bit digital audio, each with independent sample rates and excellent dynamic range, using hardware that was much superior to that common on PCs for a very long time. Sampled digital audio cards weren't common on PCs until what, 1995? If you didn't have a sound card at all you got wonderful one bit sound, like the Apple II.
4,096 colors (when the PC was limited to 16...)
When the Amiga came out, the only common bitmapped graphics support on PCs was CGA, which had four selections of four fixed, extremely ugly colors. You only got 16 (fixed) colors in text mode. When EGA came out, you still only got a set of 16 fixed colors to choose from. PC graphics were pathetic until VGA became common, and then only for low resolution games.
It sounds like you are talking about auto-stretch scaling. That the monitor is at 800x600, the game is 320x240 and is automatically up-scaled to 800x600 by the OS.
There were only two basic horizontal resolutions on a standard Amiga - 320 and 640. There was hardware to switch resolutions (and palettes and bit depths) on a scan line by scan line basis. There were no aliasing problems because there was no real scaling done, the graphic chip just output pixels at one of two different rates (albeit with different palettes and bit depths), potentially on a line by line basis.
So you could grab the menu bar at the top of the screen and pull it down (vertically) to reveal another screen behind it. Separate frame buffers - one program (games and paint programs especially) could write all over the frame buffer of a screen that was invisible or only partially visible on the screen. All this vertical screen motion didn't involve moving any bits around in memory, so it was instantaneous - no waiting for anything to redraw.
The Amiga allowed you to dedicate back buffers (so called "smart refresh") to ordinary windows as well, to avoid redraws when a part of a window was exposed or brought to the front. Screen level double buffering, hardware line drawing, pixel blitting, bitmap movement, vertical palette changes, hardware sprites, all par for the course.
With a hardware sprite, for example, you could have a mouse pointer that moved around without ever touching the underlying frame buffer. The application didn't care, didn't worry, the mouse pointer was just an operating system controlled sprite that was overlaid on the video output in hardware. None of this "hide the mouse pointer", then draw, then restore (or XOR) the mouse pointer stuff that was common in competing operating systems at the time.
Similar hardware, by the way, was used to implement many of the early Atari game machines, inexpensive consoles that often implemented very nice games with only 4K of RAM (albeit typically 16 or more kilobytes of game cartridge ROM on top of that). On Atari game consoles there was usually no bitmap at all, just a bunch of hardware tiles and sprites. Can't fit much of a bitmap in 4K of RAM (or less in some cases).
In any case, the Atari graphics hardware guy ended up at Amiga, and the remaining Atari folks designed an Amiga competitor (the Atari ST) with very conventional frame buffer support and none of the exotic graphics hardware goodness Atari had a considerable reputation for, let alone as implemented on steroids in the Amiga hardware design, at very low cost.
That is why it is much more practical to deal with the Amiga Research OS (AROS) or an Amiga emulator, which both run on x86 boxes. You would have to be quite a diehard or have a very special application to purchase a contemporary PPC Amiga.
It is worth mentioning that when they first came out, Amigas were much less expensive than (color) Macintoshes, and rather less expensive than any remotely comparable PC as well. Most of the games in the PC world ran in four (fixed, ugly) color CGA at the time. Apple II games were much better looking than that, on machines with a tiny fraction of the resources.
It only needs to read the data back in if it has given the space to another process
That is the way it *ought* to work. In reality, applications get completely paged to disk after any extended idle period, and sooner than that if there is any significant disk activity. Linux pages out process pages in favor of disk buffers all the time. So you come back a few hours later, hit a key and wait five or ten seconds while everything pages back in again. Compared to an Amiga, that is really annoying. It's even (horror of horrors) worse than Windows. I haven't noticed my Windows PC swap in years.
To be fair, I think there is a setting where you can tweak that to some degree, /proc/sys/vm/swappiness or something like that.
Atari TOS wasn't really an operating system in the modern sense of the term. More like a nice version of DOS, complete with 8.3 filenames and no multi-tasking to speak of. GEM wasn't half bad, but it was woefully limited compared to the Amiga windowing system, unless a single running application with a small number of windows was all you needed.
I really liked the Atari monitors though - they were extraordinarily crisp. And the Atari ST hard drives were faster (and more common at first) than ones for the Amiga. Atari STs often had more RAM too. And the Atari monochrome mode (with the right monitor) produced much more stable displays at high resolutions - no interlacing required. That was a disadvantage of the Amiga until the Amiga 3000 came out, especially for desktop publishing applications.
What's one do with an Amiga VM?
Personally, I like Deluxe Paint better than anything I have seen since then. Other than a few applications like that (and modern ports thereof) it is probably mostly a hobby thing.
The Amiga is extremely easy to program for, so one of these days there might be a number of useful applications that people might run a VM for. Or it could escape the VM and be used as an operating system for embedded systems. Amiga programming is certainly a lot easier than Linux kernel mode programming. Of course (by comparison) there aren't any device drivers to speak of.
When I had an Amiga, way back when, I didn't use it to get any "real work" done except software development (I worked on computer games). But it was an enormous amount of fun as a hobby computer just installing and running the sort of things you could could get on "Fred Fish" disks. Amiga Basic had its quirks, but it was a lot better hobbyist type language than the business oriented corruption Visual Basic became. I would rather play with Applesoft Basic than Visual Basic. All three versions of BASIC courtesy of Microsoft, of course.
The big problem with modern, memory protected, multiple address space operating systems is that you could no longer get direct address to the frame buffer or the other hardware. That makes programming quick and dirty hobbyist type applications much harder than it was on systems that did not have such restrictions. On the Amiga I could trivially control hardware from *Basic* using no more than peeks and pokes. Or draw all over the frame buffer, or write sound applications without going through a half dozen layers of operating system indirection, and so on. Of course AROS probably doesn't work like that any more, unfortunately. Other advantages aside, it is no fun feeling alienated from the hardware. Kernel programming just isn't quite the same - radically more complex and error prone these days, for one thing.
It was better than the Mac in it's day
Better than the original Mac, absolutely. Better than the Mac II, for many things, yes. Video production, games, most entry level applications, yes. The Mac II was *expensive* and often slow by comparison.
For graphic design and desktop publishing not so much. That is where the Mac II really shined. There was nothing comparable to Quark on the Amiga. Device independent or high bit depth raster graphics on the Amiga were the exception, not the rule. The sort of thing that made the Mac slower at first, and the Amiga lacking a few years later.
Relative to what it was trying to accomplish, the Apple IIgs was the slowest computer I have ever used. Imagine trying to backport a subset of Mac OS Classic to a 2.8 Mhz 16 bit CPU with an 8 bit data bus. The early Macs were slow enough (i.e. barely tolerable) even with a much better processor at two and a half times the clock rate.
By comparison, the Amiga (and the Atari ST in its own way) was just plain fast.
And Mac OS "classic" was not an OS, was a crash-prone, non-multitasking toy.
Yes. Structurally speaking, Mac OS Classic was about as much an operating system as DOS was (aside from a a very nice GUI programming environment). One application running at a time, and special tricks required to switch to anything else. Programs were statically compiled to access critical system state variables at fixed addresses in low memory, there was no locking, no scheduler, etc. There was no real multitasking because of that, not even cooperative multitasking.
By comparison Amiga OS was a modern multiprocess multitasking operating system in every way except originally there was no memory protection, and no virtual memory. More like a modern embedded system than a general purpose operating system, but *very* fast, and ridiculously easy to program for.
Sorry, you can keep this feature. I, for one, like having things like disk caching that works.
In order to safely flip the power switch to power off an early Amiga, you had to wait until all pending disk writes were complete. This was pretty easy to do if you didn't have any disk writing background tasks running. Just wait for the drive lights to go out and then wait another couple of seconds for the superblock write to happen (which causes the drive light to flash a second time), and then you were good.
Woe be to the person who didn't wait for the second flash, because he/she would generally have to repair the disk on reboot. That happened to me a couple of times before I learned my lesson.
The real performance advantage of the early Amigas over many modern PCs is *no virtual memory*. It is amazingly fast to do just about anything if half of your applications haven't paged out to disk, as Linux is wont to do for inactive processes even when there are gigabytes of free memory in the system.
The Amiga, of course, originally didn't have any memory protection, which made programmers very careful. If you want to develop something for a quasi-embedded system it is ten times easier to debug "kernel level" code on an Amiga than for practically any other system, because the debugger, editor, test tools, etc. are all running in the same address space as what is being tested.
If you develop kernel mode code your kernel will crash and burn anyway, especially painful if you are on the same system, so it is awfully convenient to take advantage of the simplicity it allows. Even with memory protection turned on, Amiga OS is a single address space operating system. It is ridiculously simple to develop multitasking systems for a single address space OS compared to the hoops you have to jump through to do the same things in user mode in a more traditional Unix style operating system. Much higher performance too, of course.
Making the drive handle things at the file level is the equivalent of turning it into a NAS device where the system software would generally be inaccessible, unmodifiable, and un-upgradeable, unfortunately. It would still be an interesting engineering challenge, of course.
This would require a firmware change, and for SATA drives, it is just not going to happen. High end SCSI drives maybe.
The "compatibility mode" jumper shifts the alignment of logical block addresses to the underlying physical sectors so that instead of the physical sectors starting at LBAs that are a multiple of 8, they instead start at LBAs that are a multiple of 8, minus 1. That way the first partition, which traditionally starts at LBA 63, will be physical sector aligned. No gratuitous read modify write, no performance penalty, at least for the first partition.
Of course you don't want to switch the jumper on a formatted drive, because the position of all the data will shift by 512 bytes, making it look like garbage to any ordinary filesystem.
Actually, with flash drives everything related to the issue is much *worse*, due to the way flash works - the internal block sizes are huge (128KB). Because of this, contemporary flash drives are enormously complex, sort of like a filesystem with a 128 KB internal block size that sub allocates (and moves around, and coalesces) lots of little 512 byte "sectors" for presentation to the outside world.
NTFS has been 4K aligned for a long time now.
That doesn't do any good if the partition it is on starts with an LBA that is not a multiple of 8. Windows versions prior to Vista create the first partition starting at LBA 63, which is not 4KB aligned.
The people who will have performance problems will primarily be Windows XP users who purchase the newer style drives and do not realign the first partition accordingly. Some versions of "fdisk" on Linux have a similar deficiency, with an "cylinder" based user interface and odd size cylinders in the name of MSDOS compatibility. Not sure if that has been fixed yet.