Back to the Alpha Micro Phun Machine @ Floodgap Retrobits | Jump to: Alpha Micro Pageant of Machines | Downloads | Links and Resources

AMPM: Primer to AMOS

AMOS, the primary operating system for most Alpha Micro servers, is certainly alien to people who have only lived in a Unix-Windows duality -- but very familiar to people who have dealt with things like TOPS-10, of which it is not a descendant but can be considered strongly influenced by.

This document talks about some of the basics with starting up, setting up, using, administering and shutting down the typical AMOS-based system. By typical, I mean specifically AMOS/32, the most common version, which runs on the majority of 68K-based Alpha Micro systems; despite this, however, this document is still largely applicable to AMOS/L and the oldest S-100 WD-16 systems (less so for the most current Windows XP/EAMOS systems, which are well-documented and have their own unique characteristics). Note that this document does not cover complex administration tasks, nor does it cover the entire length and breadth of the AMOS command set, nor does it cover tools such as VUE and MULTI in anything but an elemental sense.

This document assumes you have some working knowledge of use and basic administration of a multi-user system such as Windows NT/Windows Server or a Unix or Un*x derivative operating system.

What is AMOS?

AMOS is a multiprocess/singlethreaded multiuser operating system that is proprietary and unique to the Alpha Micro line. Its current release for the modern x86 AMs is 8.2; the last release for the 68K AMs is 2.3A; and the last release for the antediluvian AM-100 is 5.0 (of its particular earlier form of AMOS).

AMOS has some unusual features for an operating system. One of the most unusual is that the 68K, a big-endian chip, is run effectively in little-endian mode due to bus line swaps needed for preserving data file compatibility with the WD-16 systems. Although the kernel (called the "monitor") preemptively multitasks, AMOS is also a strictly real-memory operating system: it does not use an MMU, nor does it require one. Memory is partitioned into fixed segments and programs are expected to be relocatable to whatever address they are loaded without any patching. Programs can also be marked as "reentrant" and/or "reusable," i.e., respectively, that their memory image(s) can be run simultaneously by multiple users without interference, and/or that the image can be held and called again with the expectation it can self-initialize without being explicitly reloaded.

AMOS/L vs. AMOS/32

As mentioned above, when I say AMOS, I mean AMOS/32, which runs on the vast majority of operational Alpha Micro installations. AMOS/L is the original 68K-based AMOS, which was introduced on the AM-100/L and the primary operating system of the AM-1000 and AM-1500, and later the AM-1200. With the advent of the 68020 and the AM-2000, Alpha Micro introduced the fully 32-bit AMOS/32, designed as backwards-compatible with AMOS/L, and maintained each version in parallel. This duality was mostly lost on casual users due to both forks being functionally and internally similar, and with AMOS 2.0 (/L and /32 flavours) the distinction became further blurred. Finally, with AMOS 2.3, Alpha Micro merged everything back into a unified version that ran on any 68K and the /L vs. /32 issue gracefully disappeared.

Getting the Console Connected

Before we even get moving, you'll need a serial console. The older "DB-9" (DE-9 actually) ports are not quite the same as a modern PC COM port and require conversion. Similarly, you'll need an adaptor for RJ-45 ports if your system has those instead. This is true even if you have a real Alpha Micro terminal like an AM-62 or AM-65. The below converter will allow you to run a DB-9 (DE-9) Alpha Micro port to a DB-25 RS-232 port connected by a straight-thru RJ-45 (such as a Cat 5 Ethernet) cable, using all eight lines. If you use RJ-45 ports on your AM, then just use the DB-25 end.

On the Alpha Micro DB-9 side, this is the wiring schedule (with 8P8C colours) for RJ-45 female to 25-pin RS-232 DB-9 (DE-9) male. Both the DB-9 (DE-9) and DB-25 modular converters can easily be found at places like Fry's for a few bucks. Colours refer to the wires within the adaptor. In this orientation, the female RJ-45 "lock snag" is at the bottom with line 1 on the left, and the male DB-9 (DE-9) has pin positions 1-5 on the top row with pin 1 on the left.

On the terminal/PC DB-25 side, this is the writing schedule (with 8P8C colours) for RJ-45 female to 25-pin RS-232 DB-25 male. Colours refer to the wires within the adaptor. In this orientation, the female RJ-45 "lock snag" is at the bottom with line 1 on the left, and the male DB-25 has pin positions 1-13 on the top row with pin 1 on the left.

If you only have 9-pin RS-232 ports on your terminal, use any standard PC 25->9 converter cable to get you the proper polarity and pinout at this point.

There is no real convention for where the console terminal port usually sits, so you may need to try different ports before you find it. If the ports are arranged horizontally left to right, try the left-most port; if they are arranged left to right and top to bottom, try the upper left port or bottom right port. Either way, configure your terminal for 19.2kbps, 8N1 or 9600bps, 8N1. If you don't have a real Alpha Micro terminal, you might have some garbage when you boot, which is expected. Somewhat later we will discuss how to change the characteristics of your terminal if you have this problem.


AMOS has several filesystem conventions which will sound familiar to DEC users, but may be strange to others.

All files are in 6.3 format, which is to say, six letter filenames and three letter extensions. Like most operating systems, there are a number of reserved file extensions (this list is not exhaustive):

Every file is associated with a disk number (such as DSK0:) and a project-programmer number (such as [1,2]). This setup is often called an "account" in Alpha Micro documentation and I also use such terms more or less synonymously. For example, the bootstrap script lives in DSK0:AMOS32.INI[1,4]. The project-programmer number is best thought of as a "user directory" -- in this case, the home directory of the system administrator account. PPNs can be password protected, which is the basis of user accounts and user security in AMOS. When you switch PPNs with the LOG command, you assume the privileges of that PPN (and if the PPN is password protected, you must enter the password to access that account). PPNs are 8 bits each and are expressed in octal, so the highest PPN for a given disk is [377,377].

Remembering the PPN and disk number for a whole bunch of accounts would be irritating and tough to juggle, so you can establish an alias called an ersatz for a (disk,PPN) pair. There are several common ersatzes on just about every system:

In general, most ersatzes refer to a standard location. For example, the ersatz initialization file lives in SYS:ERSATZ.INI, which is almost always DSK0:ERSATZ.INI[1,4]. This file contains a list of ersatzes and their (disk,PPN) equivalents, separated by whitespace and an equals (=) sign. Users will often have accounts defined as an ersatz, such as TRM1: or USER1:.

Similarly, OPR:, the operator/system administrator account, is virtually always DSK0:[1,2]. There can be operator accounts ([1,2]) on other disks with administrative privileges to accounts on those disks, but not to the system at large.

There are no subdirectories in AMOS.

If you omit the disk name, then the current one you are logged into is assumed. If you omit either part of the PPN, like [,5], or the PPN altogether, then the current one you are logged into is also assumed. Things like COPY DSK1:=DSK0:, for example, don't copy the whole disk; it copies from the current PPN you are in on DSK0: to the same PPN on DSK1:, assuming it exists.

Wildcards (*,?) are valid in filenames, file extensions and PPNs (e.g., [*,5] and [*2,???] are legal, although [2*,5] is not -- note that ??? would match a number of one or two digits as well as three), but not disk device specifications. The idiom [] is the same as [*,*], so COPY DSK1:[]=DSK0:[] would copy all files (because COPY also assumes *.* by default). To refer to all disks, use ALL:.

PPNs can also be used to designate things akin to ACLs and user groups. By default, a particular file is readable and (for executable files) executable by anyone, but can only be written to or deleted by people logged into its PPN or a PPN with the same project number (the first number of the two). Thus, assigning people the same project number allows them to be in the same "workgroup" and access and manipulate each others' files. For AMOS filesystems with "extended files" in them, this can be made much more granular. Remember, anyone logged into OPR: can read, write, change and delete anything.

Systems may also have usernames for login, but this is different from a PPN/password system. If you get a username prompt and you don't have a login, try System Service, which is the default administrative user on a minimally-configured system. This username is usually attached to the SYS: account. Another common pre-configured username is DEMO, which is often attached to OPR:.

Jobs and Terminals

Jobs are the AMOS equivalent of processes on other operating systems. The maximum number of jobs available on your computer is defined on startup, and then jobs are "allocated" from that maximum pool. A fixed amount of available memory is assigned statically to a job when it is allocated. Jobs are generally also statically allocated on startup, and may or may not be attached to terminals, although some may be dynamically allocated by subsystems like MULTI or AlphaTCP (for example, the webserver job that served you this page was dynamically allocated by AlphaTCP, started up with a fixed memory allocation, served the file and then died off after its job was done).

Terminals are much more flexible, dynamic entities than on many operating systems. Every terminal must have a job attached to be functional, but the job attached to the terminal may change. In addition, you can force input into a job as if the terminal the job is attached to were entering the commands (in fact, this is very common in the system initialization file).

We'll talk about adding more jobs and terminals presently.

PICs, Licenses and the SSD

Every AM system has a Software Security Device (SSD), a serial number acting as a unique identifier. Although license management is generally not of much interest to a casual hobbyist who picked up a used Alpha Micro to mess around with, and probably would give Richard Stallman a really nasty twitch, you should know how it works in case you decide to upgrade the system software later.

To manage license caps and lock installable software options to a particular machine, many installed software packages require a PIC (Product Installation Code) keyed to the SSD. The PIC enforces certain options and, where applicable, maximum user caps. If you do not have a PIC for a particular package and system combination, do not try to install the software or you may damage your system with a failed install. Later versions of AMOS may not require you to enter a PIC for certain packages like AlphaTCP, so check your documentation.

Typically, the PIC will come from the vendor or VAR who sold you the package. Your SSD's serial number is usually on the exterior of the system case and must be provided to the VAR to generate the PIC when you purchase it.

Starting Up and Shutting Down the System

The console terminal should be turned on first, along with any printers. If you have external disk drives, those should be turned on next, and then the main system.

If this is done right, on an AM-62 or compatible terminal you should see something like 'System booting, please wait' in the status line and the Alpha Micro logo and copyright scroll into view. After that, the lines in SYS:AMOS32.INI will be executed.

At that point, most systems will put you at an AMOS command prompt (., a single dot), usually in the OPR: account. If this doesn't happen, type LOG OPR: and, if requested, the operator account password. You will now have administrative privileges.

On certain systems, you may need to enter a username/password first, and you will usually be placed in whatever PPN is the default for that username. If you don't have a username, try System Service or DEMO. (I have some tips on how to legally! break into a used Alpha Micro you may have acquired on the Eagle 450 page, showing the steps how I got control over that particular machine.)

Shutdown requires generally no special preparation. Make sure all users are out of any applications, including you, and are logged off the system. At that point, barring special caching or backend setups, you can simply turn off the main system, followed by external drives, printers and finally the console terminal. However, if you are using devices with write-behind caching or just want to be paranoid, unmount those devices with MOUNT diskspec:/U, such as MOUNT FLP0:/U. Your system should have these "special devices" marked.

Command Syntax

Online help is available for selected commands by typing HELP (alone for the table of contents, or with the command name).

Commands consist of a command name, any switches (switches start with /), an input file, and for those files generating output, an output file such as any of the following:



Switches can also come at the end of a command line, although most people coming from a DOS or Unix background (like me) will probably put them in leading position and that's fine too. However, if you are using a system prior to AMOS 2.0, you must put them at the end: TYPE SYS:AMOSL.INI /P If you are using, say, 1.3C, remember to convert examples below to this format.

Redirection (<, >) is supported on later versions of the operating system, and so is piping, although these operations are not chain-able. If this doesn't work right, type SET REDIR to make sure that redirection is enabled. The REDIR command can "steal" the output from a command if you are otherwise unable to redirect.

Later versions of the AMOS command line understand quoted strings and backslashes. You might also be able to hit CTRL-R to retype a line.

There is no concept of "searching the path" on AMOS. Instead, commands are sought for in a particular hard-coded order: SYS:name.LIT, then name.LIT in the current account, then SYS:name.CMD, then SYS:name.DO, then name.{CMD,DO} in the current account, then name.{CMD,DO}[,0]. If you don't know where a command is, try FIND name.* or if that doesn't exist, its equivalent DIR ALL:[]name.*

Here is a table of the typical filesystem commands you will use in AMOS, along with their DOS/Windows CMD.EXE and Un*xy equivalents. An asterisk (*) indicates that there might not be online help for that particular command. Common options are in (parentheses).

AMOS Un*xy Thing MS-DOS
dir (/w) (/f) ls (-C) (-l) dir (/w) ([default])
erase rm del
copy cp copy
append cat copy /c
rename mv ren
type cat type
type/p more more
find find dir /s
rename/prot(*) chmod -

Commands like COPY and RENAME that require you to specify an output filespec work a little differently. For example, to rename file A.LST to B.LST, the command would be RENAME B.LST=A.LST (like the RENAME disk command for Commodore 1541 disk drives). You can also specify a full device and PPN if necessary: for example, to copy all files named EGREP.* from, say, DSK5:[100,100] to the current PPN, then you would enter COPY EGREP.*=DSK5:EGREP.*[100,100] or the equivalent.

Unique User Tasks and Commands

Here are tasks specific to AMOS, or that AMOS handles differently.

VUE, the Visual Editor

AMOS uses VUE for most editing tasks. It's not as fat as emacs, which is like saying that I'm not as Catholic as the Pope (i.e. not much). Actually, VUE will run in as little as 32K, file size permitting.

To edit a file, type VUE filespec:. You can enter a new filename that doesn't exist, in which case VUE will ask if you want to create it. VUE will refuse to edit files with certain extensions, such as .LIT or .BAK -- rename them if you want to open it anyway. A backup file will be created (.BAK) if the file already existed, and the editor will start.

VUE is a modal editor. Press ESC to switch back and forth between edit and command modes.

VUE is much nicer on an Alpha Micro terminal because the cursor keys and special editing keys work; otherwise, you're pretty much condemned to key combinations. The equivalents for most basic operations are:

When you are done, press ESC for a command prompt and either enter FINISH (to write the file out and exit), or QUIT to abandon your changes.

Making Command Files

There are much more to these than this brief description of .CMD/.DO file syntax would indicate, but simple files are straightforward to demonstrate. For most people, a .DO file is the closest thing to a shell-script or batch file (the difference being that .CMD files don't accept arguments, and .DO files do).

Special sequences start with a colon, and comments with a semicolon. For example, this script prints a message and edits the file specified on the command line:

; only show output of commands, not the commands themselves
; to show commands, use T
; this acts like a here-document
Now editing the file $0.
Notice that arguments start with 0.
VUE $0
Remember to put the file in a standard place like CMD: if you want to access it from other accounts.

If you put a command file called START.CMD into a particular PPN, it will execute when you log into that account (very handy for automated tasks and the like).


MULTI is a text-windowed environment manager that allows a single terminal to dynamically allocate and jump between multiple jobs, much like Unix screen or virtual consoles on most modern operating systems. I personally don't use it because it can rapidly grow a large memory footprint, and it does not play particularly nicely on anything but Alpha Micro terminals, but there are some people who adore it and you will find it on many AM systems that were in office automation environments. Its use is beyond the scope of this primer.

To start MULTI and play with it, type MULTI.

Administrator Activities

For many of these activities, this primer deals with only the barest, least complicated cases. Configuring AlphaTCP on those systems for which it is supported is discussed below.

The following tasks can generally be done "hot" without restarting:

The following tasks require you to edit the main system initialization file. Always edit a backup -- never edit SYS:AMOS32.INI directly because an error in it may make your system unbootable! The copy should be made somewhere in DSK0: as well. After editing your copy, log all users off, get to AMOS command level and as OPR: use the MONTST command to run a simulated boot in a command like this (substitute your file for TEST.INI; it must be in OPR:):
This will launch the AMOS/32 monitor (i.e., the kernel) with the new system initialization file. If this works as expected, then replace SYS:AMOS32.INI with your new file and restart the system. If it doesn't, simply reboot (either from command level or hitting the reset button) and try again.


(NB: AlphaTCP != AlphaNET. AlphaNET precedes AlphaTCP and is only useful if you have a network of Alpha Micro systems; its configuration is somewhat unusual to the AMOS-naive and is beyond the scope of this primer.)

AlphaTCP is AMOS' grafted-on TCP/IP stack, essentially an implementation of (per developer Steven Lawson) SpiderTCP and SpiderStreams, emulating System V, with later work to add Unix-like signal handling and a faked-up fork(). In fact, some of its command set feels a lot like Unix. AlphaTCP will only run on an '020 or later, and an '030 or later is strongly recommended, but machines upgraded with Roadrunners will work too so even your AM-1000 can come play if you pony up the green. Ethernet is preferred, but SLIP over a serial port is possible.

Certain machines and hardware options may demand a minimum version of AlphaTCP, or they will not function. If your particular setup came preconfigured with a particular version of AlphaTCP, do not downgrade it. (Upgrading is of course safe.)

AlphaTCP has several versions, but the minimum version that is "truly useful" is 1.3A due to the considerable stability and architectural improvements made in this release. 1.3 also was the first version with a HTTP web server, which makes sites like this even possible! Later versions add performance, fix some minor bugs and add many additional features, but if the cost of a new AlphaCD has your teeth chattering and you're running 1.3A, don't worry about it -- you won't get all the newest stuff, but you do have all the essentials and there are no known remotely exploitable security issues either. In fact, I fuzzed my 1.3C Eagle pretty badly on several ports and didn't get anything of consequence. Of course, running cleartext services like telnetd or ftpd on an WAN is a nice way to get pwn3d, so you shouldn't do that, and there is no ssh for AMOS. That's why mine sits behind a firewall for external access.

Note that BOOTP/DHCP support as a client requires 1.5.

For client applications, AlphaTCP 1.3A minimally implements NSLOOK (nslookup, DNS queries), ARP, PING, NETSTA (i.e. netstat in 6 characters), a strange PS modeled on Unix ps purely for AlphaTCP applications with a corresponding UKILL, RUPTIM (ruptime), TCPMON (a simple packet monitoring interface), UUD/UUE (uudecode/uuencode), EMAIL (an SMTP MTA interface), TELNET, FTP and TFTP. FINGER was added in 1.3B, URL (essentially a tiny curl for FTP and HTTP only) and WHOIS in 1.4, AMPM (the Alpha Micro Product Manager) in 1.5, and after great delay the very essential TROUTE (traceroute) in 1.5A. Furthering the Unix-isms, many of these use hyphenated switches, not AMOS' standard slashed switches.

There is no web browser for AlphaTCP other than what URL offers, but there is a Gopher client that we maintain at Floodgap.

Telnet Connections to AMOS

Telnet is a convenient way to log in to your server remotely (but heed my warning -- cleartext Telnet over a WAN is just asking for it, so use this only within your local trusted network). If this is configured, when you connect you will get a prompt like this:
Enter terminal type and memory required (default is 64K)
or a question mark (?) to see a list of supported terminals
Example: >am65a 64k
If you don't see your terminal type in the list you get with ?, you might need to install it. 1.3 lacks a VT100 compatible .TDV which seriously impacts the breadth of clients that can talk to it, but I have the customized one I use on the Downloads page which will work for most VT100 emulators including xterm and Mac OS X Terminal. A comfortable memory allocation if you can afford it is 640K, which is the typical amount I ask for when I log into my machine, but strictly speaking you should only allocate the minimum amount to run what you need without impacting the free memory pool on the system.

After that, you will get a login prompt. Login with your username/password. If you don't know a login username, try System Service or DEMO.

To find out what job has been dynamically allocated to you, type JOBALC (and similarly your job and pseudoterminal will also show up if you type TRMDEF). If you have 1.3C or later, the VTID command will also tell you your source IP and source port number.

To log off of a machine, type LOGOFF and a summary of usage will be printed before you disconnect.

AlphaTCP Server Notes

On the server side, AlphaTCP 1.3A implements SMTPD (AMOS' answer to sendmail), POP3D and POPPWD (POP3 and POP password management), LPD, ITCD (a tunneling service for AlphaNET), RWHOD, TELNED (telnetd), TFTPD, FTPD and HTTPD. SLIPD is present to manage the connection for SLIP systems as well, although it does not exist in the same world as the true TCP server applications and is administered differently. SNTPD (simple network time management) and TAMED (for AlphaBASIC TCP applications) were added in 1.4, POP3D was replaced by QPOP3D in 1.4A and the AMPM server was added in 1.5. Gradual improvements also occurred particularly in the web server which we'll talk about in a little bit.

All services are managed by TCPEMU, which is analogous to inetd with an attitude problem. Setting up TCPEMU and AlphaTCP is such a big topic that you really need to read the manual for it. Configuring and building an AlphaTCP installation from scratch is not exactly intuitive until you've done it a few times and made all the possible mistakes (this is indeed how I learned too). This document will assume you have a system preconfigured or someone assisted you with the initial bring-up.

Assuming you're past that point, the file TCP:NETWRK. (notice the overtly blank extension!) contains the IP address for the particular interface in question, assuming you are using a static IP and not DHCP. TCP:RESOLV. is the analogue of /etc/resolv.conf; the line tryhostfile will cause the DNS client to look at TCP:HOSTS. (in fact, first before any DNS query is made in 1.4+) for any relevant entries. Services that TCPEMU runs are in TCP:CONFIG. but you should really understand what this is doing before you edit it! Changes can be made live, but it would be best to followup with a restart to ensure that they stick.

The web server uses some ingenious but not entirely obvious tricks to map a apparently much larger filesystem onto the simple AMOS PPN scheme, and this can really trip you up if you don't understand it fully. To keep aliasing from being a problem, I recommend just keeping your names in the 6.3 format and then you don't have to worry about what long filename will map into what short one. By default, the home document is TCP:HTTPD.HTM, but files can be stored anywhere; for example, this file is /www/amos.htm, which maps into WWW:AMOS.HTM. Note that the default "default file" in a "directory" is HOME.HTM, not INDEX.HTM. Any ersatz with a PUBLIC.PPN file in it is servable by the webserver; don't put this in SYS: because that would be really stupid and dumb, wouldn't it?

As a consequence of how filename mapping is performed, it isn't possible to serve any file from the root "directory" except HTTPD.HTM (and ROBOTS.TXT, which is "special-cased"), unless you redefine where the root is using the -m option in 1.4+. Since this isn't possible in 1.3, you are limited to those two files in the root, so start defining ersatzes for everything else. FAVICON.ICO is served from TCP:FAVICO.ICO, but this isn't supported in 1.3 either.

1.3A supports imagemaps and hit counters internally. CGI scripts are also supported, but must be pre-defined in TCP:HTTPD.APP. For example, here is the one for the local systat:

CGIs do not need to emit headers, but they can if they want. You can write CGIs in AlphaBASIC too, and have them accept arguments and POSTs, but you should read the manual for security considerations first.

Unlike most of the configuration files, MIME.TYP is stored under LIB:, not TCP:.

There are some other differences in HTTPD relative to later versions which are not properly documented in the AlphaTCP manual.

TAMED offers a standard API for TCP sockets which is very complete and works for both assembly and AlphaBASIC applications, but requires 1.4. For a kludgey but functional way to add some arbitrary socket transactions to 1.3, try fingerproxy.

One final note: older versions of FTPD bug out on many graphical clients due not only to the strange filesystem but the missing SIZE command. 1.4A fixed this problem and other issues with crummy clients, but your ugly but dependable command line ftp is not bothered by any of this and works just fine with any version of FTPD. You can cd directly to a PPN, just like LOG from the command prompt. You should be running FTPD with the -n -o options to make it act "like you expect it to," and you may need to force your client not to use passive mode. For example, when connecting to this server from my Fedora workstation, I start ftp with the -A option so passive mode is turned off.


Please send me your comments, corrections and suggestions at

Links and Resources | Downloads | Back to the Alpha Micro Phun Machine