Never heard of these!
The original site is here:
http://ampm.floodgap.com/
It’s currently hugged to death, understandbly as This site is being served to you by a real, live Alpha Micro Eagle 300 running AMOS 2.3a and AlphaTCP!
In the meanwhile find it on archive.org:
https://web.archive.org/web/20190423162658/http://ampm.floodgap.com:80/
Always good to see a site served by a retro machine! That’s quite a series of CPU migrations, from WD-16 (in an S-100 chassis) to 68k to 88k and then x86.
http://ampm.floodgap.com/www/models.htm
I worked on Alpha Micros for several years. They were one of the many proprietary multi-user mini computers of the age that were the go to solutions for small office and departmental applications.
While the AM-1000 was a pretty simple machine (who’s primary novelty was using a VCR as a backup device), the larger machines were more sophisticated. Better processors, auxiliary I/O cards to off load processing, etc.
The OS was not spectacularly sophisticated. Applications had reserved blocks of memory, no real process protection. I won’t say that the machines were unreliable, but they did crash hard, and often enough that we just dealt with it. For our work, we honestly did not interact with the OS is any real detail (beyond editing files, copying files, etc.). I remember talking with a vendor once, asking why the system did not time stamp its files. And he basically said, “And, what, waste a disk write?” Since, yea, it would be an extra disk write to update a timestamp, and, yea, disk write were Expensive.
In our case, we used applications on top of a database development system known as AlphaBASE/Metropolis. This system had several hooks in to the OS, and was, honestly, quite sophisticated for its time. For example, I don’t recall the details, but a AlphaBASE system would restart fast than a stock AMOS system. As one of the salesmen noted at a convention when the box crashed “But look how fast it boots!”.
All of our code was in BASIC. I don’t think it was the stock AMOS BASIC, as it had special features that the stock one did not.
Metropolis had built in support for ISAM files, which were our bread and butter. In this case, as the developer, we were responsible for updating not just the records, but all of the keys as well. If a table had four keys associated with it, we’d have to insert a row in to the table, and then insert the four keys as well. The bright side is that you could have conditional keys (just don’t update them). But the dark side is that non of this was transactional. It was routine maintenance when something went amiss to have to rebuild all of the keys in the system. If the system crashed mid update, it was very easy for the records and the keys to not be in sync.
As I said, the machines were not unreliable, but computers and computer, software is software, and crashes happened. Today, with modern SQL databases and transactions and such, we rarely worry about a hard crash corrupting your DB. Back then, it was a routine concern.
At the same time, however, Metropolis offered a feature that was novel at the time. The BASIC supported this concept call “GENCODE”. GENCODE did exactly that – they generated code at compile time. Earlier, I said we’d have to update all four indexes when updating a row. In practice, we didn’t. We would use a GENCODE command that would generate the proper calls for us. This way, when we added an index to a table, we just had to rebuild the software, rather than recode and update it.
Today, you might consider a GENCODE as a macro. GENCODEs were used throughout the system and gave us sophisticated record management and screen control for our screen forms.
For such a crude box, Metropolis was a pretty neat system. Beyond the development environment, it also offered us things like multi-session terminal management and instant messaging. It utilized the color terminals we had to hilt, providing really attractive screens.
We made some pretty nice systems on top of the AM, supporting 100’s of on line users. We had one system with two machines networked together (TCP? What’s TCP? No, this was some serial thing they had.). We definitely made that machine dance.
Solved some really interesting problems.
We eventually moved on to UNIX and other DB systems.
I worked at a computer shop in 1978-1981 (programming, building and repair) and then on to DEC. But AlphaMicro was one of our brands that we sold along with Apple, ProcessTechnology, Imsai, Vector Graphics and Horizon (plus more that I can’t remember). I was factory trained on AlphaMicro, Processor Technology, Apple 2 and Vector Graphics. I as far as AlphaMicro at the time it was the AM100 system which was S100 and used the WD16 chip set (think of PDP11/03 with a different opcom outpurt. The Amos operating system was a (cough cough) copy of the DEC RSTS/E system. We had many installs of this systems in schools and in small machine shops and legal offices. All the software applications were custom to that particular install. I spent many days aligning/cleaning/repairing CDC Hawk 10Mbyte drives. The place where I got my training was in AM’s facility on the edge of Orange County Airport - now John Wayne International. Apple training in Chicago, Vector Graphic training in Chicago and Processor Tech training in Philadelphia. I built may IMSAI, VectorGraphics and Processor Technology systems.
Great first-hand account - thanks!