Ars Technica is running a series by
Shadow of the 16-bit Beast: an Amiga gaming retrospective talks about development tools and teams for the early years of Amiga game development. The article isn't very deep from a technical viewpoint, instead focusing more on the attitudes of the publishers and development teams of the time.
By the time the Amiga came along, my game development days were behind me. Instead I remember fondly playing some classic Amiga games like Ports of Call, Civilization, Defender of the Crown, and Master Of Orion. While today's games and platforms have far surpassed those days, I don't believe that game play has progressed as quickly. You can have all the fancy graphics in the world, but if it's not an interesting game, then you've wasted your money.
Monday, June 14, 2010
Sunday, May 2, 2010
Emulation vs. Hardware
Before I move into the 3.x versions of Amiga OS, I think I'd like to talk about emulation as it applies to older machines. A lot of older machines have software emulations of some kind now available for another computer platform. For example, I have been using WinUAE as a stand-in for the actual hardware while exploring the Amiga. While I won't talk about that specially here, I do want to address the things that I have been thinking about while using this emulator and others (and having actual hardware to compare it against, instead of memories.)
Many of the existing emulators are labors of love - love for the platform they emulate and the software that could be run on it. There is a desire to preserve at least a shadow of these old platforms, and luckily those with enough skill and time have made the effort. Many practical people can and do question the sanity of putting in thousands of hours into re-creating a dead computing platform (I will guess you're not one of them, since you're reading this blog), and oftentimes these platforms reside in a murky area of legality and copyright quagmire. The truth is much of this legacy software and hardware would be forgotten entirely and lost to history - old software does not age gracefully and will degrade and disappear in the blink of an eye if not preserved. (If you questions this - How many of you run CP/M, once the most popular home DOS system, at home? Didn't think so...)
While writing the last few entries, I attempted to re-create in software what would have taken me much time and effort to do physically. Tracking down some of these old machines isn't how I want to spend most of my time, and keeping them running and happy is harder yet. In the case of some of the larger systems it may be becoming impossible (Yes, I have run a PDP-11/40 with core memory and RK05 drives in my basement - while it looks cool it's not very practical.)
So here's my take on the whole idea:
1. It preserves that which is becoming scarce in a way accessible to many. You can put the actual hardware in a museum, but making it available to the average person is better, even if its virtual.
2. It allows the exploration of configurations that would have been very expensive or rare at the time they were originally available. My hardware Amiga would have cost over $14,000 at time of release, if you could have done it at all.
3. It preserves software that is essentially abandoned, even if someone somewhere still thinks there's some commercial dollars to squeeze out of it. (They're wrong - and yes, people protect copyrights for other reasons - They're wrong too, in this case. Your game/productivity/utility software came out in 1985? Get over it.)
4. The legality can sometimes be murky due to our IP laws. Based on strict morality, I don't have any issues over it. (See 3) Much of this software is still copyrighted, and some is truly abandoned (no known owner), and even still others have been officially released of copyright by the holders. That's all great, and should be observed if you're going to try and make money off of it (yeah, sure.)
5. In addition to the hardware emulators, a lot of software is beginning to be archived. I see this much like I see libraries - for the education of the people. Sure there's lots of games out there, but see 3. Even of more interest are things like SCSI drivers, printer drivers, etc. Or how about old word processors? Do you still have documents around in old WP formats? I do - it would be neat to read them again.
6. The emulations aren't always perfect, but mostly they're good enough. I figure they generally work about as well as some of the old hardware they're trying to emulate! How many times in a day did you reset your TRS-80 Model I level 2 because the ribbon cable between the keyboard and expansion unit was loose? Yeah, like that.
So, go forth, emulate, and learn about these old machines and how they worked (or didn't.) Learn about why we both pine for and run from some of these old machines, learned from them (or didn't), and applied those lessons (or didn't.) If you own some of these old machine, bring them out from the basement and rediscover them - they will provide ample perspective on where we've been and perhaps on how we got here.
Many of the existing emulators are labors of love - love for the platform they emulate and the software that could be run on it. There is a desire to preserve at least a shadow of these old platforms, and luckily those with enough skill and time have made the effort. Many practical people can and do question the sanity of putting in thousands of hours into re-creating a dead computing platform (I will guess you're not one of them, since you're reading this blog), and oftentimes these platforms reside in a murky area of legality and copyright quagmire. The truth is much of this legacy software and hardware would be forgotten entirely and lost to history - old software does not age gracefully and will degrade and disappear in the blink of an eye if not preserved. (If you questions this - How many of you run CP/M, once the most popular home DOS system, at home? Didn't think so...)
While writing the last few entries, I attempted to re-create in software what would have taken me much time and effort to do physically. Tracking down some of these old machines isn't how I want to spend most of my time, and keeping them running and happy is harder yet. In the case of some of the larger systems it may be becoming impossible (Yes, I have run a PDP-11/40 with core memory and RK05 drives in my basement - while it looks cool it's not very practical.)
So here's my take on the whole idea:
1. It preserves that which is becoming scarce in a way accessible to many. You can put the actual hardware in a museum, but making it available to the average person is better, even if its virtual.
2. It allows the exploration of configurations that would have been very expensive or rare at the time they were originally available. My hardware Amiga would have cost over $14,000 at time of release, if you could have done it at all.
3. It preserves software that is essentially abandoned, even if someone somewhere still thinks there's some commercial dollars to squeeze out of it. (They're wrong - and yes, people protect copyrights for other reasons - They're wrong too, in this case. Your game/productivity/utility software came out in 1985? Get over it.)
4. The legality can sometimes be murky due to our IP laws. Based on strict morality, I don't have any issues over it. (See 3) Much of this software is still copyrighted, and some is truly abandoned (no known owner), and even still others have been officially released of copyright by the holders. That's all great, and should be observed if you're going to try and make money off of it (yeah, sure.)
5. In addition to the hardware emulators, a lot of software is beginning to be archived. I see this much like I see libraries - for the education of the people. Sure there's lots of games out there, but see 3. Even of more interest are things like SCSI drivers, printer drivers, etc. Or how about old word processors? Do you still have documents around in old WP formats? I do - it would be neat to read them again.
6. The emulations aren't always perfect, but mostly they're good enough. I figure they generally work about as well as some of the old hardware they're trying to emulate! How many times in a day did you reset your TRS-80 Model I level 2 because the ribbon cable between the keyboard and expansion unit was loose? Yeah, like that.
So, go forth, emulate, and learn about these old machines and how they worked (or didn't.) Learn about why we both pine for and run from some of these old machines, learned from them (or didn't), and applied those lessons (or didn't.) If you own some of these old machine, bring them out from the basement and rediscover them - they will provide ample perspective on where we've been and perhaps on how we got here.
Monday, April 26, 2010
Amiga 2.04
Skipping over the 2.0 release (nobody except for some early Amiga 3000 owners saw it anyway) to 2.04, we enter the realm of the purple Kickstart boot screen and the revised system color scheme and icons. WB2.0 was a significant change for the Amiga OS - it included more GUI controls in the ROM (including a standard file requester), the new color scheme and 3D look icons, support for larger hard disks, improved font handling, and a re-write of the core in C rather than BCPL.
The 3D look was much better than the former isometric look, and the Workbench screens now took on a much more professional look.
Also included for the first time was AREXX, a version of the IBM REXX language that is intended for scripting and macros. Standard AREXX ports were soon included in major software as a way of adding scripting and inter-program messaging, similar to Microsoft's OLE.
Support for the ECS chipset was now included, which meant higher resolution screens, assuming you had a flicker fixer or suitable monitor. No longer was the family TV the default display device! And the preferences tool had grown up, with many different major sections giving increased customization potential.
2.1 continued the trend with increased optimization and features for the A600 (such as IDE drive support.) 2.1 was a software only upgrade and didn't require a new ROM.
The 3D look was much better than the former isometric look, and the Workbench screens now took on a much more professional look.
Also included for the first time was AREXX, a version of the IBM REXX language that is intended for scripting and macros. Standard AREXX ports were soon included in major software as a way of adding scripting and inter-program messaging, similar to Microsoft's OLE.
Support for the ECS chipset was now included, which meant higher resolution screens, assuming you had a flicker fixer or suitable monitor. No longer was the family TV the default display device! And the preferences tool had grown up, with many different major sections giving increased customization potential.
2.1 continued the trend with increased optimization and features for the A600 (such as IDE drive support.) 2.1 was a software only upgrade and didn't require a new ROM.
Sunday, April 25, 2010
Amiga 1.3
Kickstart/Workbench 1.3 was the last of what I'll call the "White boot screen with hand" releases, referring to the hand with a disk image prompting for a boot disk. 1.3 fixed some large bugs in the OS, including autoconfig for memory boards (no more addmem commands needed), the addition of the Shell (and NEWCON: device), and, most importantly to me and my new hard drive, autoboot from hard drives. The Fast Filing System (FFS) was also now included in ROM - this made a huge improvement in speed for larger devices, and meant you could boot from FFS formatted disks, including floppies.
Visually 1.3 made some strong advances, with a new look to icons but still retaining the 1.x color scheme. Draws still had their isometric 3D look, which I always found somewhat distracting - to me it looked as if they were floating around and isolated, rather than part of a "desktop". The preferences program made some progress also, with some of the key areas now on their own instead of rolled into one mega screen.
The RAM disk remained, and a new recoverable (at least from warm boots) RAMB0: device was available. The new device was fixed sizer rather than dynamically sized, so you needed to think ahead to how much memory you wanted to use. The Shell and NEWCON: added command line recall like the big boys as well as some in-line editing.
Gone now was AmigaBASIC, a casualty of poor programming by Microsoft. The FD files for 1.3 were included, so you could continue to use programs that relied on the information contained in them. Oh, and KeyToy was now at version 3.5.
Visually 1.3 made some strong advances, with a new look to icons but still retaining the 1.x color scheme. Draws still had their isometric 3D look, which I always found somewhat distracting - to me it looked as if they were floating around and isolated, rather than part of a "desktop". The preferences program made some progress also, with some of the key areas now on their own instead of rolled into one mega screen.
The RAM disk remained, and a new recoverable (at least from warm boots) RAMB0: device was available. The new device was fixed sizer rather than dynamically sized, so you needed to think ahead to how much memory you wanted to use. The Shell and NEWCON: added command line recall like the big boys as well as some in-line editing.
Gone now was AmigaBASIC, a casualty of poor programming by Microsoft. The FD files for 1.3 were included, so you could continue to use programs that relied on the information contained in them. Oh, and KeyToy was now at version 3.5.
Saturday, April 24, 2010
Amiga 1.2
Workbench 1.2 (and Kickstart 1.2) was the next big step for the Amiga OS. Released with the Amiga 2000 and Amiga 500, and available as a Kickstart disk for Amiga 1000 owners, it included many bug fixes and some expanded functionality. The garish color scheme remained intact, but the disk count had increased by one to two total. The first disk contained the core OS features and was bootable, the second was labeled "Extras" and was not bootable.
The main Workbench now included a RAM based virtual disk as standard. This acted as a fast non-permanent disk space useful for storing temporary files, commands that were accessed frequently, and other features that would benefit from the speed increase and not suffer in the event of loss during a system crash. I frequently used the RAM: device as a place to put header files for C programs I was compiling. Of course the limit was memory size - put too much into your RAM disk and you wouldn't have enough memory left to run programs!
The Extras disk had three major new features: AmigaBASIC, MicroEmacs, and KeyToy, er, I mean PCUtil.
AmigaBASIC continued the tradition of including a version of the BASIC language with home computers. A true Microsoft BASIC, it most closely resembled the Macintosh version of BASIC, also written by Microsoft. It even allowed for low level access to the OS functions through an include-file-like mechanism (FD files). But, like most interpreted BASIC's it was slow, and had a fatal flaw that would limit its growth: It would not run on more advanced machines. Microsoft had broken the rules and mis-used the upper eight bits of addresses such that on any machine with greater than 24 bit addressing (such as the 68020 and better) it would malfunction.
MicroEmacs was a port of the Unix based MicroEmacs, and is available for many different architectures. It was a bold statement and a nod to the workstation users to include it on the Amiga, in effect equating the Amiga to much more expensive machines where serious text editors were normally found.
PCUtil was a nod towards allowing MSDOS users to transfer files to and from the Amiga. It allowed an owner of the 1020 5.25" drive to read and write from MSDOS formatted disks, as long as they were not mounted as standard drives with the Amiga file system.
The main Workbench now included a RAM based virtual disk as standard. This acted as a fast non-permanent disk space useful for storing temporary files, commands that were accessed frequently, and other features that would benefit from the speed increase and not suffer in the event of loss during a system crash. I frequently used the RAM: device as a place to put header files for C programs I was compiling. Of course the limit was memory size - put too much into your RAM disk and you wouldn't have enough memory left to run programs!
The Extras disk had three major new features: AmigaBASIC, MicroEmacs, and KeyToy, er, I mean PCUtil.
AmigaBASIC continued the tradition of including a version of the BASIC language with home computers. A true Microsoft BASIC, it most closely resembled the Macintosh version of BASIC, also written by Microsoft. It even allowed for low level access to the OS functions through an include-file-like mechanism (FD files). But, like most interpreted BASIC's it was slow, and had a fatal flaw that would limit its growth: It would not run on more advanced machines. Microsoft had broken the rules and mis-used the upper eight bits of addresses such that on any machine with greater than 24 bit addressing (such as the 68020 and better) it would malfunction.
MicroEmacs was a port of the Unix based MicroEmacs, and is available for many different architectures. It was a bold statement and a nod to the workstation users to include it on the Amiga, in effect equating the Amiga to much more expensive machines where serious text editors were normally found.
PCUtil was a nod towards allowing MSDOS users to transfer files to and from the Amiga. It allowed an owner of the 1020 5.25" drive to read and write from MSDOS formatted disks, as long as they were not mounted as standard drives with the Amiga file system.
Friday, April 23, 2010
Amiga 1.0
Let's take a tour through some of the AmigaOS versions, courtesy of the WinUAE emulator. WinUAE is great, because it allows us to emulate various hardware configurations without having to invest the time in configuration of real hardware. Various versions of the AmigaOS are available online in collection form, if your persistent enough to find them.
After insertion of the Kickstart 1.0 disk (OK, really an ADF file containing an image of the disk, but let's pretend we have actual hardware here), we get a similar screen to the first requesting the Workbench Disk. Unless we hard-reset (i.e. turn off the power) we shouldn't need the Kickstart disk again, since the machine reads its contents into a write-protected 256KB area of memory (known as Writable Control Store (WCS).) After the initial boot, the WCS acts as if it were a ROM to the machine.
Workbench 1.0 wasn't the prettiest environment among its contemporaries, with its blue-white-black-orange color scheme. This color scheme was actually chosen for a reason - it bled less on color televisions. Monitors were still expensive, often costing a significant percentage of the machine cost, and were not all that common in "home" computers (think C64) Commodore was betting that Amiga users would be using home televisions as their display devices.
The 1.0 Workbench uses a file-folder metaphor to presenting programs, similar to the Macintosh, GEOS, and Windows. Workbench specific information about a file or folder is stored in a separate file with a ".info" extension. Workbench doesn't actually display the files, but uses the .info files to control the action. Here you see the default screen after double-clicking on the Workbench disk icon. The left border of the window shows a fuel-gauge indicating that the disk is about 3/4ths full, and the top border shows the name of the open window. Standard controls on a window are a close button, a minimize button to shrunk the window to an icon on the desktop, and a button that brings the window to the foreground if it is occluded behind other windows. At the bottom right is a resize tool to control the size of the windows. Visible on the Workbench disk are a few "drawers" (directories), a clock tool, a preferences tool, and a trashcan tool. Operation of these should be immediately obvious to anyone today which is a good indication of how strong this metaphor is. Notice I said "visible" - remember the workbench only displays .info files - also part of AmigaDOS is a powerful command-line environment, which we will explore shortly.
Here I have started the clock utility and opened the System drawer. Since the Amiga is fully multi-tasking, the clock utility runs as its own process, independent of anything else running on the system. This was truly groundbreaking for a home computer in 1985. Inside the System drawer are a few utilities like a disk copier and formatter, and the CLI (Command Line Interface) entry-point. Although the CLI is the default operating mode of the Amiga (it starts there, executing a script called "S:Startup-Sequence", the Workbench takes over from it and in order to get back you need to start a new one.
Here I have started the CLI and executed the "list" command, which gives file information on the current directory. I have also left the Clock running in the background to demonstrate how it continues to run undeterred. Yes this doesn't seem like much in 2010, but in 1985 the ability to run more than one program at a time was the province of workstations and bigger machines. Note also the aforementioned .info files for the drawers. Also notice that there are other files on the disk, not visible in the Workbench. These comprise of various system-level directories, such as libs and c. The AmigaOS did a good job of hiding its complexity from the user in the Workbench, but fully exposed it through the CLI when the power was needed.
Our last stop on this brief tour is in the Preferences tool, since I think it is a good indication of the maturity of the system, or lack thereof. For Workbench 1.0 the Preferences tool was simple and compact, but didn't allow much customization for the user. The user could set the mouse speed and double-click speed, the key repeat, adjust the basic four colors of the Workbench, set the time and baud rates, adjust the mouse pointer and printer, and... that's about it. The more adventurous were going to have to learn to play with the CLI.
Amiga 1000, Kickstart 1.0, WB 1.0
The Amiga 1000 was the original Amiga, and I will be booting this virtual machine using the original OS and a standard factory configuration. Since the machine did not have a built in ROM, the A1000 required a Kickstart disk upon hard-reset. The first thing that greets us on startup is a screen requesting this disk and some notes from the speaker.After insertion of the Kickstart 1.0 disk (OK, really an ADF file containing an image of the disk, but let's pretend we have actual hardware here), we get a similar screen to the first requesting the Workbench Disk. Unless we hard-reset (i.e. turn off the power) we shouldn't need the Kickstart disk again, since the machine reads its contents into a write-protected 256KB area of memory (known as Writable Control Store (WCS).) After the initial boot, the WCS acts as if it were a ROM to the machine.
Workbench 1.0 wasn't the prettiest environment among its contemporaries, with its blue-white-black-orange color scheme. This color scheme was actually chosen for a reason - it bled less on color televisions. Monitors were still expensive, often costing a significant percentage of the machine cost, and were not all that common in "home" computers (think C64) Commodore was betting that Amiga users would be using home televisions as their display devices.
The 1.0 Workbench uses a file-folder metaphor to presenting programs, similar to the Macintosh, GEOS, and Windows. Workbench specific information about a file or folder is stored in a separate file with a ".info" extension. Workbench doesn't actually display the files, but uses the .info files to control the action. Here you see the default screen after double-clicking on the Workbench disk icon. The left border of the window shows a fuel-gauge indicating that the disk is about 3/4ths full, and the top border shows the name of the open window. Standard controls on a window are a close button, a minimize button to shrunk the window to an icon on the desktop, and a button that brings the window to the foreground if it is occluded behind other windows. At the bottom right is a resize tool to control the size of the windows. Visible on the Workbench disk are a few "drawers" (directories), a clock tool, a preferences tool, and a trashcan tool. Operation of these should be immediately obvious to anyone today which is a good indication of how strong this metaphor is. Notice I said "visible" - remember the workbench only displays .info files - also part of AmigaDOS is a powerful command-line environment, which we will explore shortly.
Here I have started the clock utility and opened the System drawer. Since the Amiga is fully multi-tasking, the clock utility runs as its own process, independent of anything else running on the system. This was truly groundbreaking for a home computer in 1985. Inside the System drawer are a few utilities like a disk copier and formatter, and the CLI (Command Line Interface) entry-point. Although the CLI is the default operating mode of the Amiga (it starts there, executing a script called "S:Startup-Sequence", the Workbench takes over from it and in order to get back you need to start a new one.
Here I have started the CLI and executed the "list" command, which gives file information on the current directory. I have also left the Clock running in the background to demonstrate how it continues to run undeterred. Yes this doesn't seem like much in 2010, but in 1985 the ability to run more than one program at a time was the province of workstations and bigger machines. Note also the aforementioned .info files for the drawers. Also notice that there are other files on the disk, not visible in the Workbench. These comprise of various system-level directories, such as libs and c. The AmigaOS did a good job of hiding its complexity from the user in the Workbench, but fully exposed it through the CLI when the power was needed.
Our last stop on this brief tour is in the Preferences tool, since I think it is a good indication of the maturity of the system, or lack thereof. For Workbench 1.0 the Preferences tool was simple and compact, but didn't allow much customization for the user. The user could set the mouse speed and double-click speed, the key repeat, adjust the basic four colors of the Workbench, set the time and baud rates, adjust the mouse pointer and printer, and... that's about it. The more adventurous were going to have to learn to play with the CLI.
Thursday, April 22, 2010
Expanded Amiga 500, Death of a Friend
The Amiga 500 is a 68000 machine, with all of the limits that implies. I had expanded mine several times over - the 512KB expansion/clock option was nice, and the extra 4MB Fast RAM was even nicer. Adding the hard disk made the machine much more usable, and I was starting to do some video capture with my DCTV box. On my job I was working with VAX's and MIPs R3000 based boxes, and the A500 was starting to feel a little sluggish in comparison. Memory was getting tight too, as I was running UUCP in the background and processing a fair number of Usenet newsgroups nightly, thanks to a connection through a friend at Digital Equipment Corporation to the Internet, and later through Portal ( portal.com!gdc!aminet). I eventually found what I wanted from a company near Dallas called Microbotics.
Microbotics made a 68030 based accelerator for the A500 called the VXL-30. This card had various options (see link), but mine was a 68EC030 clocked at 40Mhz with the 68882 math co-processor. The board fit into the motherboard's CPU socket, and you placed the original 68000 on the board to allow the machine to fall back to "stock" speeds for some games and other non-030 friendly software. By this time my A500 was up to Workbench 2.04 standards, and the original (or OCS) Agnus chip was replaced with the upgraded "Fat Agnus" chip, allowing a full 1MB of Chip RAM.
I was also in the process of moving from Ohio to Texas, and I fortuitously found myself near the Microbotics facility. This was great, since my board was an early board and needed some changes to accept the new RAM-32 card which provided 32-bit RAM for the accelerator board. Since the board sit into the original CPU slot (the A500's expansion options were limited after all), all memory access had to be made to the original 16-bit bus also. This put a serious crimp on the speed of the 68030 when it needed to access memory. The solution was 32-bit RAM, and I wanted it badly. So badly I walked into the front door of the company and sat in the parking lot while the engineers modded my board to accept the RAM card. And I maxed it out: 8MB of glorious 32-bit ZIP memory.
The performance increase was great - I was now rendering ray-traces faster than the MIPs box at work, and disk transfers just flew. The Amiga 500 transformation was complete, from stock A500 to the A500 muscle car, chopped and lowered with a blower.
But, to use technology and science fiction writer Jerry Pournelle's favorite phrase, "Alas" it wasn't to be a long honeymoon. After leaving Dallas my next port of call was going to be Tulsa Oklahoma, via a side trip back east. And, the company said, I needed to be there yesterday. This meant I wasn't going to be packing my machines up lovingly, and I would have to fly out leaving them behind. The packing would be done later by the shipping company. They did a reasonable job, except that they did not secure the card in the machine, which broke loose from its socket and scrambled itself and the motherboard. The A500 was dead.
It was early 1993, and the Amiga scene in the US was starting to dim - Commodore had not done a good job marketing the machines nor in upgrading the special technology that made the original Amiga's special. I decided it was time to transition to the PC world. With the help of a nice insurance settlement for the Amiga, and the sale of the remains of the A500 (for parts mostly, tho I suspect that the gentleman who bought the accelerator card should have been able to revive it with effort), I moved to an Intel '486DX 33Mhz (12MB RAM) with a VLB SVGA video card and a Soundblaster.
Next: Revisiting that "accelerated" through emulation
Later: "New" Amiga hardware!
Microbotics made a 68030 based accelerator for the A500 called the VXL-30. This card had various options (see link), but mine was a 68EC030 clocked at 40Mhz with the 68882 math co-processor. The board fit into the motherboard's CPU socket, and you placed the original 68000 on the board to allow the machine to fall back to "stock" speeds for some games and other non-030 friendly software. By this time my A500 was up to Workbench 2.04 standards, and the original (or OCS) Agnus chip was replaced with the upgraded "Fat Agnus" chip, allowing a full 1MB of Chip RAM.
I was also in the process of moving from Ohio to Texas, and I fortuitously found myself near the Microbotics facility. This was great, since my board was an early board and needed some changes to accept the new RAM-32 card which provided 32-bit RAM for the accelerator board. Since the board sit into the original CPU slot (the A500's expansion options were limited after all), all memory access had to be made to the original 16-bit bus also. This put a serious crimp on the speed of the 68030 when it needed to access memory. The solution was 32-bit RAM, and I wanted it badly. So badly I walked into the front door of the company and sat in the parking lot while the engineers modded my board to accept the RAM card. And I maxed it out: 8MB of glorious 32-bit ZIP memory.
The performance increase was great - I was now rendering ray-traces faster than the MIPs box at work, and disk transfers just flew. The Amiga 500 transformation was complete, from stock A500 to the A500 muscle car, chopped and lowered with a blower.
But, to use technology and science fiction writer Jerry Pournelle's favorite phrase, "Alas" it wasn't to be a long honeymoon. After leaving Dallas my next port of call was going to be Tulsa Oklahoma, via a side trip back east. And, the company said, I needed to be there yesterday. This meant I wasn't going to be packing my machines up lovingly, and I would have to fly out leaving them behind. The packing would be done later by the shipping company. They did a reasonable job, except that they did not secure the card in the machine, which broke loose from its socket and scrambled itself and the motherboard. The A500 was dead.
It was early 1993, and the Amiga scene in the US was starting to dim - Commodore had not done a good job marketing the machines nor in upgrading the special technology that made the original Amiga's special. I decided it was time to transition to the PC world. With the help of a nice insurance settlement for the Amiga, and the sale of the remains of the A500 (for parts mostly, tho I suspect that the gentleman who bought the accelerator card should have been able to revive it with effort), I moved to an Intel '486DX 33Mhz (12MB RAM) with a VLB SVGA video card and a Soundblaster.
Next: Revisiting that "accelerated" through emulation
Later: "New" Amiga hardware!
Wednesday, April 21, 2010
My First Ami
The first Amiga I owned was the A500. I paid cash for the machine, the A501 512KB memory and clock board, the 1084 monitor, and a dual external disk drive (two drives in one case.) It was 1987, and I was upgrading from the C64.
The A500 came with a soap-bar sized mouse with two prominent buttons. Like most mice of the period (but unlike Sun workstation mice) it was a mechanical mouse, with a roller ball that needed cleaning often, especially in a dusty basement room like mine. Physically the A500 was a self-contained computer, containing both the keyboard and the CPU and Memory. Also included was a single 880KB 3.5" floppy drive, which was accessible on the right side of the machine. The power supply was an external brick, which given the failure rates of commodore power supplies was probably a blessing.
Standard memory was 512KB, which was considered "Chip" memory. This meant that is was accessible to both the 68000 CPU and the special custom chips. Because this caused contention for the memory, programs did not run at full speed when only this memory was available. Adding the A501 gave you another 512KB (labeled "Fast RAM" because it wasn't shared) and a battery backed clock. The card fit into a slot set in the bottom of the machine, behind a panel and could be installed by the end user.
Kickstart 1.2 was standard on my machine, along with Workbench 1.2. (Shown is the Kickstart 1.3 "insert disk" graphic - 1.3 was similar to 1.2, but included bug fixes to allow booting from hard disks.) Included also with the machine was the AmigaBASIC software, which I played with but was never that interested in.
The first expansion beyond the basics was a memory expansion. Another 4MB was useful in running the Wordperfect word processor, as well as allowing me to run a C compiler from the RAM disk and avoid floppy grinding. After about a year I finally gave in and purchased a hard drive. This was a seagate ST4096 80MB SCSI drive, driven from a Supradrive SCSI controller. At the time 80MB felt like a pure luxury - only one problem though! The drive enclosure I had was meant for 3.5" drives, and the ST4096 was a 5.25" drive. This meant my drive ran "naked", sitting on top of a piece of cardboard perched on the open drive case. Never had a problem.
Next: Expanding the A500, death of a friend.
The A500 came with a soap-bar sized mouse with two prominent buttons. Like most mice of the period (but unlike Sun workstation mice) it was a mechanical mouse, with a roller ball that needed cleaning often, especially in a dusty basement room like mine. Physically the A500 was a self-contained computer, containing both the keyboard and the CPU and Memory. Also included was a single 880KB 3.5" floppy drive, which was accessible on the right side of the machine. The power supply was an external brick, which given the failure rates of commodore power supplies was probably a blessing.
Standard memory was 512KB, which was considered "Chip" memory. This meant that is was accessible to both the 68000 CPU and the special custom chips. Because this caused contention for the memory, programs did not run at full speed when only this memory was available. Adding the A501 gave you another 512KB (labeled "Fast RAM" because it wasn't shared) and a battery backed clock. The card fit into a slot set in the bottom of the machine, behind a panel and could be installed by the end user.
Kickstart 1.2 was standard on my machine, along with Workbench 1.2. (Shown is the Kickstart 1.3 "insert disk" graphic - 1.3 was similar to 1.2, but included bug fixes to allow booting from hard disks.) Included also with the machine was the AmigaBASIC software, which I played with but was never that interested in.
The first expansion beyond the basics was a memory expansion. Another 4MB was useful in running the Wordperfect word processor, as well as allowing me to run a C compiler from the RAM disk and avoid floppy grinding. After about a year I finally gave in and purchased a hard drive. This was a seagate ST4096 80MB SCSI drive, driven from a Supradrive SCSI controller. At the time 80MB felt like a pure luxury - only one problem though! The drive enclosure I had was meant for 3.5" drives, and the ST4096 was a 5.25" drive. This meant my drive ran "naked", sitting on top of a piece of cardboard perched on the open drive case. Never had a problem.
Next: Expanding the A500, death of a friend.
Sunday, April 18, 2010
AmigaDOS and Intuition
In addition to its powerful custom chip set and video friendly output, the Amiga had something no other desktop machine could offer at the time: A true multi-tasking windowed environment. The Mac had a powerful windowing system (and was even starting to have color - 1987 saw the introduction of the color capable Mac II), the PC had, well, Windows 2.0 and MS-DOS. I think I will save comments on Windows 2.0 for another day - the best I can say about it here was that it allowed overlapping windows.
The Amiga had AmigaDOS, a TRIPOS derived, command-line based disk operating system in the mode of a Unix shell or perhaps TRISDOS command prompt. It also had Intuition, a "library" of graphical user-interface components that formed the basis for the main graphical environment of the Amiga: Workbench. A key feature of the Amiga was that the core graphical components of the windowing system were part of the machines firmware (known as Kickstart - note I didn't say "ROM", as the first Amiga machines used a protected memory area rather than true ROM and loaded Kickstart from disk when the machine was first turned on.) This meant that even when Workbench wasn't active, the core command-line interface of the machine (or the CLI) was still presented graphically in a window - the Amiga had no true text mode, as in the IBM PC.
The Workbench provides an environment that would be familiar to most PC users today - windows with pointers and graphical tools such a buttons and boxes, and a file-drawer metaphor for presenting files and directories. Grab a file icon, drag it to another drawer, and it is copied (or renamed, etc.) The difference between this environment and today's Windows or Mac OSX isn't a large chasm, which is testament to how well thought out it was.
Below the CLI and Workbench was Exec, the true beating heart of the Amiga OS. Today you might call Exec a "microkernel", and you wouldn't be too far wrong. Exec provided task scheduling for a true preemptive multitasking system, core support for dynamic libraries and devices, and a rather efficient inter-process communication facility that took advantage of the flat shared memory space in the Amiga. Exec was light-years ahead of its contemporaries - MS-DOS was single-tasking and monolithic, and the Mac was monolithic with a cooperative cpu-sharing scheme available with Multifinder.
Not bad for a machine that could run with 256KB memory and one disk drive!
Next: My First Ami
The Amiga had AmigaDOS, a TRIPOS derived, command-line based disk operating system in the mode of a Unix shell or perhaps TRISDOS command prompt. It also had Intuition, a "library" of graphical user-interface components that formed the basis for the main graphical environment of the Amiga: Workbench. A key feature of the Amiga was that the core graphical components of the windowing system were part of the machines firmware (known as Kickstart - note I didn't say "ROM", as the first Amiga machines used a protected memory area rather than true ROM and loaded Kickstart from disk when the machine was first turned on.) This meant that even when Workbench wasn't active, the core command-line interface of the machine (or the CLI) was still presented graphically in a window - the Amiga had no true text mode, as in the IBM PC.
The Workbench provides an environment that would be familiar to most PC users today - windows with pointers and graphical tools such a buttons and boxes, and a file-drawer metaphor for presenting files and directories. Grab a file icon, drag it to another drawer, and it is copied (or renamed, etc.) The difference between this environment and today's Windows or Mac OSX isn't a large chasm, which is testament to how well thought out it was.
Below the CLI and Workbench was Exec, the true beating heart of the Amiga OS. Today you might call Exec a "microkernel", and you wouldn't be too far wrong. Exec provided task scheduling for a true preemptive multitasking system, core support for dynamic libraries and devices, and a rather efficient inter-process communication facility that took advantage of the flat shared memory space in the Amiga. Exec was light-years ahead of its contemporaries - MS-DOS was single-tasking and monolithic, and the Mac was monolithic with a cooperative cpu-sharing scheme available with Multifinder.
Not bad for a machine that could run with 256KB memory and one disk drive!
Next: My First Ami
The Amiga
The Amiga
I wanted to start with the Amiga - it is a machine that invokes strong emotions in some people, and I have personally owned one (now three.) The Amiga is a machine of significance not only because of the technology, but also because of the users. Used by many in the arts, it was the true crossover of technology and computing. Computers had escaped the businessman's desk and landed in television studios, artist lofts, and in music studios. Often derided by the business world as a "game machine", the Amiga was misunderstood and sometimes miscast. Yes, it had many quality games, but also available were "serious" business tools like the Wordperfect word processor (which I used to write papers in college), and professional tools like the Video Toaster system and Lightwave.
There have been many stories told about the birth of the Amiga - it is well documented elsewhere - so I will concentrate on perspective and description.
The core of the Amiga, like the earlier Macintosh, was based on the Motorola 68000 CPU and a 16/32 bit data path to memory and other peripherals. At the time of release (1987), the 68000 wasn't the top-of-the-line in Motorola's catalog (the 68020 had been available since 1984), but it was a cost effective chip with a growth path. For perspective, the PC world was a mix of older 8086/8088 machines and the newer "AT" class machines with the Intel 80286 - first deliveries of the 80386 would start in 1987 with limited volume.
Beyond the shared CPU architecture, the Amiga hardware diverged from the Mac quickly, providing custom chips for graphics and sound. These chips allowed the machine to offload certain operations from the CPU, thus allowing the machine to function at a much higher level than its core processor might indicate. The Agnus chip, with its blitter and copper functions provided much of the power of the Amiga and contributed greatly to the Amiga's suitability as a graphics machine (and game machine.)
Another hardware trait of the Amiga that contributed to its early success is video support. At its heart, the Amiga was a video machine. With built-in genlock support it slotted easily into a video production role. This was most evident in the display modes available, based on NTSC and PAL standard formats, including true interlaced support. These formats, combined with the available color modes (most notably HAM), are to my mind the single most important trait of the Amiga, leading to its largest user adoption, but also causing derision from the "business" community. For video production the Amiga was ideal; for spreadsheets the screen did not have the fidelity that business users demanded - interlaced screens are terrible when you're trying to concentrate on facts and figures. Later numerous solutions were marketed (and even included as standard in the A3000), known as "flicker fixers" and "scan doublers", but Commodore never really invested in providing a good solution for business users and the Amiga didn't catch up with the Mac and PC worlds until much later with the advent of RTG graphics cards.
Next: AmigaDOS and Intuition
Saturday, April 17, 2010
Underway
Underway
Here you will find a general rambling of my attempts to bring life back to old hardware and software. I intend to write about these things from both a historical perspective and through the lens of today. I don't have a set agenda - it will be wherever my fancy leads me, and whenever I have the time. I will make use of both the real hardware and emulations of that hardware, and hopefully make comparisons where I have direct knowledge.
I expect that you will join me in this - I certainly don't know everything (or sometimes anything!) about these old machines, and would enjoy reading comments - just don't flame me if I screw up some fact about your favorite machine! Just remind me that the foo-o-matic 2000 couldn't transmit greater than 9600 baud on more than four RS-232 lines simultaneously (or whatever), and we'll move on. Accuracy is important, but not the most important thing.
I know I'm not unique here, but there seems to be enough interest around in this topic and it has been something that I enjoy, so I thought I'd share what I can, and in the process maybe learn something new through the rigor of writing about it.
My background is in software engineering, where I started as a "code slave" in 1985. At that time I had been using micros at home for a number of years and some Digital Equipment Corporation machines at various institutions (PDP-11, Vax-11). I was also the Sysop of the Science Fiction SIG on Portal, where I met many influential people in the microcomputer world, especially in the Amiga forums where I was especially fond of Harv Laser. I was also eventually voted lead Sysop for Portal, which mostly involved holding internal meetings and presenting our point of view to Portal.
Later work took me around the country on various jobs, where I worked with many different machines and software and established myself as a "Big data" kind of programmer - databases, parallel programming, caching. I wrote code for PDP-11's, Vax's, PC's, Unix workstations (Sun, MIPS, RS/6000, AT&T, HPUX, Dec Alpha), mainframes (GE, IBM), Macintosh, and Amigas. Languages I have used professionally include C, C++, various assmebler architectures (Z80, 6502, 68000, VAX Macro), Basic, Java, and now Scala.
Today I am a principal software architect at Tracelink, Inc. where I am working with the new (to me) breed of functional programming with Scala and the Lift framework for a groundbreaking combination of cloud computing and enterprise level application.
Ok, enough "retro me" - next I will get started with a machine that is dear to me, and also readily available in hardware and emulation!
Subscribe to:
Posts (Atom)