The Amiga, Circa 2010 — Dead and Loving It 383
Orion Blastar writes "While many Amiga users have moved on to Linux, Mac OS X, and even, gasp shock, Microsoft Windows, some of us don't want to give up so easily. There are two open source projects that are keeping the Amiga legacy alive even if Amiga Inc. seems to be deader than a doornail and not really doing much but selling old Classic Amiga games for new platforms. Like WINE, there was a project to run AmigaOS 3.1 software for Linux and other platforms, but it evolved instead into an open source operating system named Amiga Research OS, or AROS. AROS is best run inside an emulator, and while it is not a modern OS like Linux, it can be downloaded and run inside of Linux (and the downloads section has more). While it is not ready for prime time yet, it is a promising OS that is being ported to many platforms and uses the user friendly Amiga GUI we Amiga users grew up with." Read on for more.
"OK — maybe AROS is not modern enough for you, and you like Linux instead. Then you might like Anubis OS, as it is a hybrid of AROS and Linux. Much like when Apple took NextStep (based on *BSD Unix and the MACH kernel) and the classic Mac OS to make Mac OS X, this project wants to take Linux and AROS and do the same thing.For those who want the classic Amiga, there is UAE, the Universal Amiga Emulator, which needs kickstart ROMs and boot disk images to work. You can buy them from Amiga Forever; the emulator comes with all the files you need plus other goodies.
For the classic Amiga 68K series, it is recreated via the Minimig, which uses SD cards instead of floppy disks; a must for retro computer hobbyists. AmigaOS 4.1 exists for PowerPC based SAM 440EP systems like the SAM 440Ep systems and parts sold here. (I am not associated with Amiga Kit or Amiga Inc. or any Amiga company. I am just an Amiga user since 1985 and very much into retro computing.)"
Re:The Amiga, Circa 2010 — Dead and Loving I (Score:2, Informative)
A few great Amiga ideas I'm still waiting for (Score:4, Informative)
Re:A few great Amiga ideas I'm still waiting for (Score:1, Informative)
Maybe not.. But a amiga 2000 from 1987 was definitely ahead of a 95 pc in many areas. It was for example with lightwave and toaster board to produce cgi stuff seen in movies and series. One example would be babylon 5. The first few seasons was rendered entirely on a amiga render farm.
Re:2010 (Score:2, Informative)
..Year of the Amiga Desktop
It's Year of the Amiga Workbench, you fool!
MorphOS (Score:3, Informative)
Re:A few great Amiga ideas I'm still waiting for (Score:2, Informative)
You're both right. The scanning was the same for the whole screen. The copper just reconfigured the graphics chip at a certain raster position so that it would output pixels from a different memory location, in a different color mode and with different pixel sizes (durations really). It still all ended up looking the same to the monitor. Remember that the monitor was basically just a TV set without a tuner, so we're talking about the equivalent of a fixed-frequency monitor.
Re:2010 (Score:1, Informative)
IAnd somehow I think I am in the majority.
You are. Linux zealots want to revise history to make it seems as if they gained a boatload of ex-Amiga users. They got a few, but many of them went for higher ground after that ship sank.
Re:What was that Amiga tank game? (Score:1, Informative)
Would it be Firepower [lemonamiga.com]?
Me and a buddy used to play this one all the time.
Re:A few great Amiga ideas I'm still waiting for (Score:5, Informative)
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.
Re:Move on (Score:4, Informative)
I'm afraid it doesn't allow more than a single resolution on my screen at once, it just offers a resizable window. Besides which, we're talking about hardware here.
From wikipedia: [wikipedia.org]
Uses of the copper
* It can be used to change video hardware mid-frame. This allows the Amiga to change video configuration, including resolution, between scanlines. This allows the Amiga to display different horizontal resolutions, different colour depths, and entirely different frame buffers on the same screen. The AmigaOS graphical user interface allows two programs to operate at different resolutions in different buffers, while both are visible on the screen simultaneously.
So is the Amiga more powerful than both VirtualBox and the Mac? Again, Amiga wins! :P
Re:Move on (Score:1, Informative)
Who needs multiple resolutions in 2010? LCDs can't handle anything except their native resolution very well, and besides I can't think any use for low resolutions any more (unless you're trying to achieve real-time raytracing, you might want to run it first at 640*480).
So is the Amiga more powerful than both VirtualBox and the Mac?
No.
Again, Amiga wins! :P
No. It doesn't win. Not in 2010.
Re: X vs. Amiga (Score:4, Informative)
Actually, the big problem with X with regards to network transparency is xlib, not the X11 protocol. The protocol is very well designed for remote use (although not as nice as NeWS or DPS), but xlib was designed to make X11 programming 'easy' and so wrapped an asynchronous protocol in a synchronous API. Run a typical xlib program over the network and you'll see that the network is not saturated and the CPU load on both machines is tiny. The reason for this is that the client is spending most of its time in blocking xlib calls. If you have a 100Mb/s network with 100ms latency, you can only make ten blocking xlib calls per second, which doesn't come close to using the network throughput.
XCB does a lot to improve on this. It's very close to the protocol and designed for asynchronous use. If you write good XCB code, your app will be very responsive over the network (or all apps using your toolkit, if you are using the XCB to write a toolkit).
Xlib is too low level to be nice for writing apps and too high level to be nice for writing toolkits.
Re:2010? Welcome 2010! Welcome back Amiga! (Score:1, Informative)
Win95 didn't kill the Amiga, the new owners did, coupled with the first viable alternative that was available at the time...Linux.
Win95 didn't kill the Amiga, neither the new owners.
You can still buy new AmigaOS 4.1 and new Amiga Hardware SAM440EP and FLEX motherboards on internet computer stores.
So keep in mind that Amiga is still here.
Re:2010 (Score:3, Informative)
Windows 95 had nothing at all to do with the Amiga's death, commercially. It wasn't even out on the market during the commercial life of the Amiga.
There were two big factors in the Amiga's death. The smaller of the two, but still very substantial, was piracy. While Amigas had a number of very cool niches, the big engine of Amiga sales was home computers, largely driven by gaming. Most of that was in Europe, and at the peak of the Amiga years, piracy was so bad some releases that sold tens of thousands in the USA and Canada (smaller markets, and also not immune to piracy) might have sold 50 copies in Germany or the UK, the two largest markets for Amiga games.
The second was Commodore, on many levels. For one, while they were spending literally tens of millions on bloated salaries and perks for the top management ( the top few guys at C= were making more than the top few guys at IBM or Apple in the early 90s), but we had the lowest R&D budget in the industry. We could deal with some of that simply by hiring the very best engineers one could hire, and working crazy hours. But given how dependent Amiga evolution was on custom chip work -- which is not cheap -- there was just no way to keep up without more investments. So many leading edge designs were done, but they came in later than they should have (our 64-bit graphics project started in 1988, for example, also supporting true color, planar and chunky graphics, MPEG-like compression modes in hardware, and 8-channel 16-bit sound, but by 1993, it was still prototype chips, and engineering didn't have the budget to complete things).
These pretty much worked together in a vicious circle. Curiously, sales of high end systems remained at least flat, well into the end days. Folks who needed to run Video Toasters or Supergens or whatever still needed new Amigas. Commodore had never done much to promote these uses.
There was only a brief hope post-Commodore, despite all the Amiga fans wanting more. The first resurrection, at ESCOM, formed a separate Amiga Technologies division, put existing Amigas back into production, and started working on a new hardware and software platform that could have been reasonable for the middle-late 1990s. Unfortunately, ESCOM themselves blew it in the PC market... and that killed it all.
Nothing after that, far as I know, involved anyone who had actually made personal computers -- there were a bunch of wannabes, that's about it. And the ideas just got progressively worse with each change of hands. And THEY all knew it better than we ex-C= did. A few of us were consulting for ESCOM/Amiga Technologies, they had their own ideas, but they were smart enough to listen.
But they were confused enough for the short time Gateway2000 owned the Amiga assets (you could make a decent enough multimedia computer today using Linux, at least if you set Windows up as the metric, but that was not true when Gateway was involved). And pretty much everything the "new" Amiga, Inc. did was wrong, but you couldn't tell them anything. Not that they were going to do anything new in hardware, anyway, but backing PowerPC in those days was the stupidest move possible -- no good for desktops, no good for portables, not even much of a presence in set top boxes. I guess, if they were building a GUI for a network switch, maybe :-)