Detour

Life in a start-up business is nothing if not interesting and time-consuming.  TraceLink is growing quickly, and we've released several versions of our software to new customers.  While not retro in any computing sense, it has meant that I've not had a lot of time to continue exploring computing history.

The Amiga's are stored away (A stock A4000 with a CF card adapter instead of the HD, and my hotrodded A4000 with its 68060 accelerator and 128MB of RAM and VGA output).  WINUAE sits idle, waiting for my return...

When I have had some time, I have been playing with emulating another machine, much older than the Amiga, which is part of my history.  Once-upon-a-time I owned a PDP-11/40 with some large disk drives and a tape subsystem.  While long ago sold due to space and power reasons, I spent quite a bit of time resurrecting this machine from its fate in the back-room of a high school electronics lab.  The students had not been kind to the PDP, and backplane pins were broken or smashed flat, power harnesses cut, and other damage done on it.  A few months of work and the PDP-11/40 was back in business...

The PDP-11 computers from Digital Equipment Corporation (1970 - 1984) were 16-bit machines with some limited virtual memory capabilities (22 bit and 24 bit extended addressing both existed), large I/O capabilities for the time, and the ability to drive up to 64 terminals at the same time on the same machine when timesharing.  Physically they were large machines, often the size of washing machines or larger.  Disk drives were extremely expensive and fragile at the time, and storage sizes seem laughable given today's multi-terrabyte drive, often only 5MB or so per 14-inch removable platter.

Today's computing resources have advanced now to the point where it is not only possible to completely emulate these old machines, but to do it much faster than the original machine could have possibly run.  SIMH is my tool of choice for configuring a virtual PDP-11, and it emulates multiple CPU and peripheral configurations with ease.

The PDP-11 series ran different OS's for different purposes, unlike most of the home computers to come later.  Some popular systems were RSTS/E (general purpose time sharing), RSX-11M+ (good for larger development efforts and I/O jobs), RT-11 (a real-time OS and single user - much like CP/M and PC-DOS to come later), and of course Unix.  After the PDP-15, the -11 was the place were much of the Unix systems we have today were born.

For fun, I will briefly explore a few of the OS's mentioned above and compare them with our modern systems.  I think it will be especially interesting to see early versions of Unix, and understand how they are both the same and different than our modern versions, such as Linux and even Mac OSX.

Stay tuned!

A taste of game design past...

Ars Technica is running a series by Jeremy Reimer  that is focusing on game development for the Amiga. 
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.

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.

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.

T

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.

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.

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.

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.

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.