Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Eric Bailey
My last official contribution to GitHub was something I’ve wanted for a long time: Writing the code to display an ACCESSIBILITY.md file’s contents on the repository landing page. This content lives in the same tab component that the README, License, Code of Conduct, Security, and important information is surfaced. For example, I’m using an ACESSIBILITY.md file located in ./github to communicate my accessibility statement on my a11y-webring.club repository. Here’s an image of it in action: The file only appears if it is supplied, so it is not a required part of creating or maintaining a repository. However, it is my hope that the act of providing one becomes more commonplace the same way providing those other special kinds of files are. Another broader hope I have is that this promotion of content helps to normalize accessibility as a consideration and practice in some small way—something that helps to send a signal of a mature software project. I’m excited to see how people use this new addition to the platform. I would also like to extend a huge thank you to Jan Maarten and Maria Lamardo for their help getting this effort across the finish line.
I owe a lot of my professional identity and success to CSS-Tricks. CSS-Tricks repeatedly gave me the opportunity to write for them. In doing so, they helped to both socialize and normalize accessibility as a mainstream frontend concern. I’m deeply thankful to them for this. The team was also a joy to work with, notably Geoff Graham. He’s a mensch, and one of the nicest people you can interact with in the frontend web space. If you have not been following the news about the site, Kevin Powell has a good video about the whole situation: Content skipped. I’m not speaking on behalf of Geoff, Chris, or others involved with running the current version of CSS-Tricks. I’ve got skin in the game as an author. This is my personal opinion, born of my feelings and beliefs. I think a lot of the web’s infrastructure should be co-ops, and CSS-Tricks is knowledge infrastructure. To that point, I should also point out that the website covers far more than just CSS. The corporate model of ownership can be a risk. If infrastructure is not part of a corporation’s core strategy, it is not a priority. As Kevin’s video touched on, it seems like promotion via owning the frontend content space isn’t part of Digital Ocean’s strategy anymore. It is not that CSS-Tricks does not have value. It is that Digital Ocean cannot see it. It is deeply, tragically ironic to me that Digital Ocean allowed this to transpire. This is because I know for a fact that the techniques and philosophies shared by CSS-Trick authors helped to shape iterations of their product’s UI. Some may be quick to point out that this knowledge now—illegally—exists inside of LLM training data, so the risk of the website going away is mitigated. To this, know that we should be striving to keep resources like CSS-Tricks going. Human creativity is the force that creates new techniques, strategies, and technologies. The web will calcify without voices sharing what they know, forever locking us into endless permutations of a fixed point in time. Unlike corporations, co-ops don’t have to be motivated by profit. By not needing to prioritize growth at all costs it means co-ops can instead prioritize and incentivise things like preservation and cultivation. It is also a successful model of operation, one that even already exists, and flourishes in the tech space. Collective ownership can also serve as checks and balances for, and protection against hierarchical decision-making. I only need to point to the chaotic and aberrant decisions many CEOs in the technology space have been making as of late to demonstrate the value of this approach. Paddy Srinivasan, if you somehow wind up reading this: Save some face and take a big swing. Give CSS-Tricks back to the people who love it.
The city next to the town I grew up in had a shopping center that was built atop a sanitary landfill. For those unfamiliar, creating a sanitary landfill involves taking landfill waste, spreading it into thin layers, compacting it, then paving over it. It enjoyed popularity as a practice in the 60s and 70s. I’m all but sure this shopping center was built in the mid-to-late 70s. It was the 90s when I was a kid and started going to it. Of note was a Kmart that I’d frequent with my parents when running errands. At some point, the certain parts of the tile floor of the Kmart started to buckle and bubble—their edges tinged with an ominous yellowish brown color. The reason for this is that is that the landfill was sealed improperly—accumulating methane and carbon dioxide gasses was pushing decomposing waste upwards and outwards. The employees put up some warning signage around the worst of it, but that was pretty much it. They did not have the expertise, nor the incentives to do anything past indicating the problem. One day we tried to go to the Kmart, and it was closed for good. A few years later the entire shopping center had to be demolished and the landfill had to be dug up and disposed of.
I made an app! What Can’t I Press? is an app that allows you to: Read, search, and filter through screen reader keyboard shortcuts. Scan open apps and add their keyboard shortcuts to the collection. Copy a keyboard shortcut to your clipboard, with modifier keys to format the keyboard shortcut in different ways. Export the list of keyboard shortcuts in its current state as JSON. It is intended to be both a reference and a discovery tool. Here’s a quick demo of it in action: Two open apps placed side-by-side on macOS: TextEdit and What Can't I Press? TextEdit is open to a blank document. What Can't I Press? shows a search input, an expand/collapse all toggle button, a list of 4 disclosures in a collapsed state, a notification message, a shortcut filter input, a download icon, and two buttons labeled "Scan all open apps" and "Scan last focused app". The disclosures are labeled, "JAWS", "Narrator", "NVDA", and "VoiceOver" and each has a badge tallying how many shortcuts are present. The notification message reads, "What Can't I Press cannot detect all possible keyboard shortcuts. Be sure to also check manually." The mouse cursor clicks the "Scan last focused app" button and a brief scan happens. The list of disclosures updates to show global keyboard shortcuts and shortcuts for TextEdit. All disclosures are set to an expanded state, and links to jump to the next section are also revealed. The mouse cursor then clicks on the search input, where the word "save" is entered. It then briefly scrolls through the list to show what apps have functionality related to saving. The search input is cleared by clicking a clear button, then focus is placed on the filter input, where Commandkbd> + s is entered. The list of keyboard shortcuts filters to show all shortcuts that incorporate these keystrokes. The cursor then clicks on the Commandkbd> + S save row button, and places focus on the TextEdit document. The content "⌘S" is inserted into the document via pasting. The app is also available as a web experience, and can be installed as a Progressive Web App. This form of the experience only allows viewing and filtering screen reader keyboard shortcuts, as scanning open apps is not possible using current web technologies. Why did I make it? App and webapp keyboard shortcuts are an often overlooked area of user experience, especially when it comes to working nicely with assistive technology. As much as possible we should not put the burden on the person using assistive technology to use workarounds. In other words: what is added as a convenience for someone who doesn’t require assistive technology should not impair someone who does require assistive technology functionality to get what they want or need. I made this app to help speed up and streamline the process of adding keyboard shortcuts in a safe and responsible way. For more background on this act, reference my post, How an accessibility designer adds keyboard shortcuts to a web app. Limitations What Can’t I Press? cannot detect all keyboard shortcuts used by an app. Consider this as a tool that helps as a first pass, but always be sure to also manually check. There are specific ways of declaring keyboard shortcuts in code that can be picked up by a scan, but not everyone uses those methods. Microsoft is an especially poor actor in this regard. The app is also currently unsigned. This means you’ll have to bypass operating system warnings about installing unsigned apps. All app source code is on GitHub and set to public, so you can review exactly what you’re signing up for. Getting the app signed is on the roadmap, so consider this more of a soft-launch announcement. Is it free? Yes. This kinda reads like you think all keyboard shortcuts should be rebindable Also yes. Looks like you used a LLM to make this A third yes. I honestly couldn’t have made this without it, and I have complicated feelings about that. Believe me, there was a ton of human intervention required. What’s with the icon? It’s a stovetop gas burner. You shouldn’t press it with your hand. I’m really funny, I know. And what about this anecdote that I couldn’t resist sharing? A friend mentioned one of their coworkers uses an app whose main mode of operation is text entry. For whatever reason, pressing Command + b toggles open a navigation drawer, and not, you know, apply bold formatting. This isn’t even an accessibility issue, it’s straight-up bad design. Is this app helpful? Let me know!
I think about evolved antennas a lot. If you’re not familiar, an evolved antenna is created when you set an evolutionary algorithm on the task of producing a structure that is as efficient at its intended function as possible. Past that there’s no human input, the algorithm just does its thing. It: Modifies elements of the initial design, Evaluates how well the design would perform according to a set of requirements, Adds or discards the changes accordingly, then Repeats until a success threshold has been achieved via iteration. Some evolved antenna practices also create a series of designs in parallel. They then pit the outputs against each other as a final layer of proving out efficacy. This process mimics natural selection. Here, mutations that are beneficial to surviving in an environment are passed through generations. It also creates absolutely wild, alien outputs: Source: Human-Competitive Results: Evolved Antennas for Deployment on NASA’s Space Technology 5 Misson - SlideServe. An evolved antenna looks the way it does because the algorithm that creates it is focused on the efficiency of the artifact it produces. It has no concept of what antennas are “supposed to look like”. That’s a bias that is inherent to us humans. Structural limitations I also have a light fascination with early programming. Specifically, the creativity involved with how programmers accommodated limitations inherent with the medium. Early mainframe programmers were constrained to the point where there would be a limit on the number of characters you could use, which led to cryptic names that oftentimes required a physical dictionary to look up the human-friendly meaning of something. There was also a long tail of this practice even after the hardware-imposed restrictions of the mainframe era. This was likely built on muscle memory, “best practice”, and a DRY mindset taken too far. Fortunately, contemporary practice—where computational power is far more luxurious—favors clarity over brevity. Profusion and proliferation Nowadays function and variable names are long and luxurious. We’re inundated with text. Flooded by it, even. In fact, we’ve gotten so good at using text that we built software to produce it for us, on demand and at volume. There have been some good things to come out of this development if you make digital experiences for a living. Concerns such as documentation, design systems, styleguides, and other vital-yet-neglected areas of the practice are suddenly critical for operations. It turns out that written words that help to explain things and create consistency are extremely important. Who knew! Here, I must confess: As someone who has long-favored these downplayed and underfunded areas of the trade, I have found myself ugly laughing at this tragicomic phenomenon. I also know that being able to feel this smug ruefulness is on borrowed time. Returning to this sudden explosion of text content—as well as other factors—we now have words for everyone who wants, or may eventually need them. Well, anyone who can pay. Decoupling and system gaming Many contemporary LLM-providing companies operate under a model where you pay them proportionate to how much computational power you utilize. This is sold via tokens, which is an abstract representation of a segment of content to be processed. Money is something people are reluctant to part ways with. This creates incentives to get creative. I’ve read all sorts of clever techniques, tricks, optimizations, and hacks people have created to lower token expenditure. The one that stands out to me most is the caveman prompt. It promises to “[cut] 65% of tokens by talking like caveman”. Of note is its ability to specify the level of “grunt”: Futurecasting The caveman prompt is a signal. Right now we live in a space where full, complete words and sentences are still desirable for us humans, and LLMs work with it. This space is in competition with a few intractable realities: LLM companies are continuing to operate at a loss. The real cost of using their services may manifest sooner than later, as promises of profitability need to be kept. Human language is an inefficient medium for transmitting data, and largely lacks the precision needed to describe the logic that powers contemporary software. Consider concepts like Robot Interaction Language and ggwave as ways we’ve attempted to address this fact. LLM-based product development is focused more on what is produced compared to how it is made. Given these considerations, one can imagine a future where human-friendly language is a liability. The forces of cost and efficiency are difficult to overcome, especially if results can be generated with minimal effort. One can also imagine that code returns to its infant state of being terse, cryptic, and near-impenetrable due to efforts to optimize how LLMs operate. Here, human language sets the parameters and LLMs act as the dictionary. This LLM optimization might even go a step further. In the pursuit of efficiency its code output becomes a language completely decoupled from a human’s ability to follow. In the torrential downpour that is everyone saying the quiet part out loud, the CEO of OpenAI’s horrifying comment about selling our intelligence back to us is a raindrop worth paying attention to. This possible outcome may mean that this time around there is no dictionary to reference. Or there is a dictionary, but it is sold back to you at a premium. It’s easy to foresee a proprietary language that only a LLM vendor can compile, decode, and otherwise change—it’s not like there’s a lack of prior art. Preventative measures Science fiction author Vernor Vinge wrote a brilliant book titled Rainbow’s End. In it, a character named Robert Gu is cured of his Alzheimer’s and brought into a post-singularity world. Gu—a former English professor and avowed technophile—struggles to adapt to a radically changed world. In one notable scene from the book, Gu rages when dismantling a device. He finds all its internal components are sealed and labeled, informing him that there are “no user-serviceable parts within”. Code may be poised to follow this direction. Imagine a world where attempting to open up any piece of software reveals a dense forest of evolved antennas, each constructed using inscrutable, black box language. Gu's outburst of anger is valid. It stems from understanding that intentionally preventing someone from making modifications is a method of enacting control. Another notable part of the future Rainbow’s End posits is the mass-proliferation of augmented reality. Here, people can access different “layers” of perception, with paid tiers of information. Looking with your naked eyes is free, but the more information you want about something the more you need to spend. Craft and cost As someone who cares about craft, I am deeply worried about this potential future. How something is built is just as important as the results it produces—reference LLMs' bias towards producing inaccessible code as an immediate concern. Inaccessible output by default is a case of implicit and unwitting control, in that it shapes who can—and cannot—use the web. The companies that provide these models could hypothetically be compelled to address that. However, the much-needed regulation needed to prevent this systemic digital exclusion is unlikely to happen with the current status quo. Or more realistically, will happen in a way that is more in-line with the regressive path the United States is currently traveling down. Some here may argue that these systems are performing better than how human developers have, and that will increase as LLM-generated code becomes more prevalent. Here, know that: As of now, homepage accessibility errors and complexity are both on the rise, and This increase in inaccessible code will continue to be enshrined, codified, and amplified as the source code is re-scraped and fed back into model data training efforts. Websites are being built via LLM-generated code and populated LLM-generated content at an exponential pace. This, in turn, raises more concerns: Overcoming this ever-increasing inaccessible default becomes progressively more resource-intensive. This makes it something only larger organizations can afford to take on, yet will be unwilling to due to a proportionately scaling cost. Inaccessible outputs become increasingly more normalized. This makes it ever more unlikely to be questioned as something that needs intervention. Command and control More distant—yet more relevant—fears center around explicit control. We're already seeing this manifest with refusals to communicate facts that may be inconvenient for LLM providers’ success. More abstractly, this entire model of operation is antithetical to one of the most radical and equalizing forces humans have ever invented. And subversion of this model is deliberate. You must imagine Sam Altman holding a knife to Tim Berners-Lee's throat. Anil Dash The public internet has been available for 35 years, and open source for 28. Both are revolutionary ideas that upended traditional ways of how knowledge is distributed. The lifespan of these ideas are also tiny blips compared to the centuries of traditional power structures and systems that came before them. It’s also enough time for said structures and systems to figure out how to address these existential threats and return things to how they prefer to operate. Being robbed of the profound openess and transparency we have become accustomed to means that we place control of reality in the hands of closed, unaccountable organizations. Here, we need to think deeper than code. Antifuture There is a potential future where we are lead down a path that works against our own self-interests, amnesic to how we wound up where we are and without the language to communicate it. Dominant players are contemptuously bypassing the standards process. We are already seeing attempts to manipulate LLM output to serve political agendas. Even further, this manipulation can occur with the providers themselves. Also recall that the more unaccountable LLM output is normalized the less we will question its outputs. Now be the villain and imagine what is possible if these agendas feel threatened. Before the internet there was Usenet. Before Usenet there was ARPANET. Through this lens, the browser is just another place information is stored. Here, we should be worried about the wolf-in-sheep’s-clothing threat of monopolistic vertical interoperability—interfacing what came before as a method to subsume it. You may be reading this post as a paranoid fear response. I should point out that these fears are cultivated. Here, know that I am not feeling fear as much as anger and a desire to preserve what is boring and works. You can open Notepad and type whatever you want into it. You can open Paint and draw whatever you can imagine. You can publish whatever you want online with a small degree of technical know-how. This all costs nothing past the hardware, software, and connection fee. We take this for granted, to our own detriment. Being open and transparent is a radical strength, not a weakness. We should not throw this away in the pursuit of a convenient perceived inevitability.
More in programming
This Refurb Weekend is a sequel in two ways. Six years ago I fixed the power supply and case fan in my 68EC030-based Alpha Microsystems Eagle 300, a more modernized and substantially faster Alpha Micro running AMOS, their unique DEC-inspired multiuser operating system. These blue-collar boxes were very common in many vertical markets due to their tightly integrated business-specific software packages, and are especially unusual for running their big-endian 68000-series processors little-endian (for data file backwards compatibility with their WD-16 ancestors). The 1990s-era Alpha Micro Eagle family improves on the originals with later 68K and even ColdFire CPUs, plus Ethernet and faster SCSI. The second way it's a sequel is to our previous Alpha Micro refurb weekend, a double header restoring an Alpha Micro AM-1000 and AM-1200, two members of Alpha Micro's most popular series of computers and some of the closest things they made in the early '80s to desktop workstations. From the outside, the Eagle comes in a PC-style case, but it's not a PC: ampm.floodgap.com using the webserver provided with AlphaTCP — yes, Alpha Micros can be networked — and its own on-board Ethernet. At the time the cooling fan failure was putting a lot of strain on the hard disk because it was overheating, and since this was my first Alpha Micro and I wanted to keep it in good nick, I decided I would put a SCSI2SD in it after the repair and get rid of the spinning disk entirely. Fast-forward to last fall, a little over a year ago, when I tried to do exactly that with a ZuluSCSI. And then it wouldn't start. thought was a replacement unit I could raid for parts, but it turned out to be something rather more special — and then I was even more fortunate when I got the Eagle 300 back out of storage to make one last attempt at reviving it. To cap it off we'll go stick ZuluSCSIs in everybody else, including my Motorola ColdFire-based Eagle 450, the first ColdFire server ever produced and what used to be the fastest Eagle in the house until the new hotness came. I even converted the external BlueSCSI the AM-1200 was using to an internal ZuluSCSI too. Now nearly everybody's got a solid-state boot disk and they're all a good bit more zippy, so we'll gawk at the internals, compare 68K CPU and storage benchmarks and most importantly learn from my mistakes, because as my late father always said, "I'd rather be lucky than good." On a more solemn note, we'll also observe a moment of silence for one of the line's creators who passed away last year. It's time for a Refurb Multi-Weekend Sequel. Alpha Microsystems, founded in Orange County, California in 1977, produced what were considered some of the earliest "poor man's minicomputers," smaller and more affordable multi-user systems that run a bespoke, Digital Equipment Corporation-influenced operating system named AMOS. In our previous entry we discussed their history in detail. First-generation Alpha Micros like the AM-100, designed by Dick Wilcox who also wrote most of the operating system, used large S-100 cases and a CPU chipset called the WD-16, derived from the Western Digital MCP-1600 chipset — the same one used in DEC's LSI-11 CPU — but with higher performance microcode developed by Rich Notari. These machines thoroughly outclassed low-end PDP-11s yet were substantially cheaper, and Alpha Micro found a ready audience initially with hobbyists and then later corporate turnkey environments, where its integrated AlphaBASIC and database functionality gave it a competitive advantage. As the WD-16 had little elbow room to evolve, in 1982 Alpha Micro introduced new systems based on the Motorola 68000, porting AlphaBASIC and AMOS to run natively, but swapping address lines to make it appear little-endian for compatibility with WD-16 data files and AlphaBASIC P-code. These new machines included the AM-1000, Alpha Micro's most popular single model, and by 1984 it constituted the majority of the over 20,000 Alpha Micro machines then in active use. An idealized Alpha Micro office from the 1980s might look like this photo, from their actual advertising of the period. The main system is an AM-1042E, the S-100 box sitting on the pedestal next to the printer, using an AM-100/L CPU with an 8MHz 68000 (the same as the AM-1000, which was integrated into a desktop case), and in the factory-standard configuration shipped with 512K of RAM and a 60MB Winchester ST-506 hard disk. The system served some number of local users connected directly via serial ports, in this case the two administrative assistants with AM-60 terminals (a modified and rebadged Wyse WY-100). The fact everyone here was in the same room with the machine was helpful, because AMOS is a strictly real-memory operating system and executable code ran from where it was loaded in the user's fixed memory allocation — there was no memory protection. Although the admin assistants' explicit permissions were limited by which account they were logged into, using the same style of project-programmer numbers as DEC (e.g., [1,2] being the operator account), an errant job of theirs could readily stomp on another and it was not rare for busy systems with buggy software to regularly crash. On the other hand, this also made it fast and efficient with little separation between you and the hardware, and even Alpha Micros with fairly modest specifications could support hundreds of simultaneous users. Alpha Microsystems tried multiple times to broaden the line technologically, though these efforts were largely for naught. Early attempts to put equivalent hardware onto a PC ISA co-processor card, with software to interchange between MS-DOS and AMOS, yielded only an expensive and poorly-selling PC that wasn't good at either OS (eventually the company gave up producing turnkey systems and just sold the card). In 1984 Alpha Micro introduced UNIMOS, a licensed version of AT&T System V UNIX which ran on modified AM-1000 hardware with an MMU, but it was likewise too expensive and garnered little interest from new users nor demand from existing ones. The cost of its development, the Unix license and its associated royalties, and a simultaneous lawsuit from DEC over AMOS's similarities subsequently caused lasting damage to the company, and by the end of the decade Alpha Micro found itself almost entirely dependent on legacy AMOS users. In the wake of Wilcox's 1990 retirement and original investor Bob Hitchcock's own departure in 1991, new management tried once more with Unix systems based on the Motorola 88000 — which Motorola abandoned shortly afterwards for the PowerPC AIM alliance, and so no hardware ever shipped. anybody — yes, really, just two months after the '030's October introduction — initially offering a 20MHz CPU, 32K of L2 cache and supporting up to 360 simultaneous terminals, but even the lowliest 30-user configuration started north of $40,000 [about $117,600 in 2026 dollars]. By contrast, Alpha Micro was uncharacteristically tardy in adopting the 68040 and didn't release the 33MHz AM-4000 until 1993. It was nevertheless nearly as expensive, and for most small offices, which were now increasingly Alpha Micro's financial anchor, that kind of money was simply beyond consideration. In 1993 the company settled on a two-board approach to solve both problems at once. The CPU board, dubbed the Roadrunner and designed by engineer Joshua Stumpf, contained the new processor, standard RAM SIMM slots, L2 cache (if present), and SCSI controller. This board was specifically designed to also fit in legacy machines, specifically the desktop AM-1000, AM-1200 and AM-1600 and server AM-2000 and AM-3000 systems, and initially came in a 68030 and two 68040 versions. A second board served as the CPU board's system interface, linked together using a custom "X-BUS" interconnect over twin 34-pin cables. For legacy installs, this second board was an active interposer physically replacing the original processor, which in elderly units sometimes needed to be desoldered (though that was also true for the few third-party CPU upgrades then extant, like InterLink's Dimension-030, so the Roadrunner was at least no worse). But this second board could be a whole new system architecture of its own, and that was what the I/O board was, designed by Rod Hewitt. It carried the power supply connectors, controlled the system front panel, contained the System Security Device for licensing (more on this later), presented built-in external ports for parallel, SCSI and (for certain loadouts) Ethernet, had an internal port for an optional floppy drive, and provided SIMM-format "paddle card" slots for option cards. Best of all, these boards were smaller and — by using off-the-shelf commodity hardware — cheaper to manufacture, and could be paired into multiple configurations, together becoming the company's long-promised updated low-end and mid-range systems. reasons I've related elsewhere, and I managed to land it for just a couple hundred bucks in fully working order. (Boy, are those days gone.) Based on the software still on the hard disk, this machine was previously used at a chain of three party stores in Washington state as a centralised rental and point-of-sale system, a common turnkey application. On arrival it sported the same loadout as in this article's first picture except for its original smaller-capacity Tandberg QIC tape drive, which in Alpha Micro parlance is called a tape streamer. Since these systems don't boot from CD, QIC tape is your only way to cold start and restore most 68K Alpha Micro computers if the hard disk fails. These systems also don't support the old Alpha Micro VHS backup system, hopefully to be the subject of a future article, which was ubiquitous in their early hardware. There is a single hard disk in the second 5.25" bay, though these first-generation systems also supported 5.25" and 3.5" floppy drives using an AM-219 controller board. original Refurb Weekend. our previous Alpha Micro foray we discussed the SSD's role, a chip installed in every 68K (and later x86) Alpha Micro, even the earliest S-100 boards, used by the operating system and any installed VAR software packages to enforce copy protection and license caps. The SSD number on the rear is just a serial number, printed on the rear plate for convenience and engraved on the SSD chip inside, which I'll show you in a moment. This number is not the key stored inside the chip, up to 256 bytes in length, which only Alpha Micro recorded. When a VAR wanted to lock an install to a particular system, they would provide their private code to Alpha Micro plus the user's SSD serial number, and Alpha Micro would look up the key and generate an alphanumeric PIC (Product Installation Code) that the VAR either used for direct installation or to provide to the user. During the installation process the PIC (usually irreversibly) encoded a binary overlay for the protected executable(s), making it impossible to run them on a system where the SSD didn't match. To facilitate logic board swaps and upgrades, the SSD is socketed and easily transplanted into a new board, but PICs were expensive then and unobtanium now, another reason hard disk backups were so critical. % curl -I http://ampm.floodgap.com/ HTTP/1.0 200 OK Date: Sun, 11 Oct 2026 23:43:03 GMT Server: AMOS-HTTPD/1.3C(111) MIME-version: 1.0 Content-type: text/html Last-modified: Sun, 11 Oct 2026 23:42:00 GMT Content-length: 30242 Content-encoding: 7bit in our most recent article. In this picture it's also attached to an AM-401 CD-ROM, which is the trusty Toshiba XM-5401B in an external case, though only specific ROM versions are supported. It can't boot from this drive, but it can read AMOS-formatted partitions, and with external software can also access ISO 9660 filesystems. Onscreen is a performance estimate using the built-in SI.LIT tool, which we'll be using to benchmark our new solid-state disks when we get them in there. Here's that output. .si dsk0: SI--AMOS System Information, (C) Copyright 1990, Alpha Microsystems Inc. Version 3.0(114) Computer Type: Eagle Main Processor: 68030 Co-Processor: None MMU present: Yes Operating System: AMOS 2.3A(484) Boot PROM revision: M00 Number of SSDs: 1 Total Memory: 16384 K-bytes Resident Monitor Memory: 6218 K-bytes Computing Index (CX), relative to AM-100: 36.9 48 bit FP Index (4X), relative to AM-100: 36.3 Floating Point Index (FX), relative to AM-100/L: 5.6 Disk Index (DX), relative to ST-506: 15.3 I don't know why it identified the 68EC030 as having an MMU, because it doesn't, but we're mostly interested in the "computing index" figure (SI's equivalent of an integer score) which is 36.9 times faster than Alpha Micro's original AM-100, and the "disk index" hard disk throughput test, which rates the spinning disk it came with as 15.3 times faster than their early ST-506 drives. Remember these figures as a baseline; we'll be referring to them again. On the front panel in both pictures you can see the number "0" in the LEDs. That's where the system status is displayed, initially by the firmware, then the OS monitor during boot and then in operation. We'll come back to this as well. original Refurb Weekend involved replacing the old AT supply with an ATX one and a converter. Since that post I found a NOS AT supply for cheap and I needed the ATX supply for something else, so I removed the converter and installed the new AT supply. This is that unit. The CPU and the 53C710 are both clocked by an 80MHz crystal divided down to 40MHz; there are also 16MHz and 50MHz oscillators on the board which appear to be used for the PLD and bus logic. Likely for cost reasons there is no L2 cache, though another thing to keep in mind is — so I'm told — that for compatibility reasons with 68000 and 68010-era AMOS software it is not possible to enable the data cache (or at least not without substantial difficulty). In fact, we observed exactly this phenomenon when looking at the driver for the InterLink Dimension-030 CPU upgrade, which puts a 68030 in an AM-1000: it never set the data cache bit in the '030's CACR at all. Although some machines can accept an external L2 cache, including one we'll look at in detail, anything it would provide is strictly I-cache. but is functionally equivalent in AMOS. not). I have such an example later on. Other serial paddlecards can also be installed. The AM-314 provides only four serial ports, but is not merely a cut-down AM-318 — the AM-314 can also be configured for RS-422 (the AM-318 is strictly RS-232) and supports all RS-232 handshake lines (the AM-318 only RTS/CTS), and in certain configurations can trigger a remote reboot from a connected distant console by grounding pin 1 with pin 7. By contrast, the more exotic AM-338 provides an IBM Binary Synchronous Communication "Bisync" link, typically used for Remote Job Entry (RJE) or CICS connections with IBM mainframes, but could theoretically have also worked with some early point-to-point networks like BITNET. It connects to an AM-339 which provides the physical port. a future article. Notice how many of these PCBs say "Made in USA"! A different era. from my SGI Indigo^2 retrofit to see if it could sit on them. It did, so I sheathed them in electrical tape as a "bed," put the ZuluSCSI into initiator mode, connected the old hard disk and the ZuluSCSI to my copy rig, and left it to image the drive to the SD card. didn't change: the boot sequence wasn't starting. I freaked out, immediately powered it off, and checked everything inside that I'd touched to find I had not properly reconnected the CPU board's power connector. original. I dug up Rod's old E-mail to see if there were any clues in it and recalled what he'd said about the PLDs being dynamically reprogrammed on every startup — from the CPU board. I also knew from the service manual that the X-BUS cables, the only connection between the I/O board and the CPU board, had to be correctly connected or the service manual warned damage could result. A horrible theory stirred in my head: perhaps I had managed to accidentally corrupt the PLDs by effectively bringing up the I/O board without the CPU board, where the boot PROMs used to reprogram them are located. However, that also suggested a solution — there are many undocumented jumpers on the AM-319 and I wondered if one of them could be used to trigger a clean reset of the programmable logic. in a future article). He also had an interest in digital television, developing TSReader, a way to analyse the MPEG-2 transport streams commonly used for satellite, cable and IPTV transmissions. ZTERM and in particular TSReader became far and away his most popular software packages. However, a few years prior and unbeknownst to many, he had quietly entrusted a copy of the TSReader source code to a friend officially "just in case," and sold ZTERM to MicroSabio, a long-time Alpha Micro support company that maintains A-Shell, a way of running AlphaBASIC applications on modern operating systems. The reason became clear later — he was dying, and it was not treatable. The source code for TSReader was duly posted after his passing and remains today as his most popular legacy. Rest in peace, Rod, and thank you. Without Rod's guidance, though, there wasn't much more I could think of to do at that point. I unplugged it, pulled the clock battery and let it sit for a couple days to see if that was enough to reset the PLDs, assuming that was the actual problem, and it didn't. It still seemed like it should be repairable if I could only figure out how, but as there was little point in having it sit fruitlessly on the workbench I removed all the remaining cables from the system board and moved the machine to cold storage until I could come up with something else. In the meantime I turned to my alternative system to get ampm.floodgap.com back up and running, though to discuss it we need to bring the history forward some more. only in the E500: a junior-varsity 68040, which is what the E400 was, didn't have much appeal. Both the E200 and E400 were quietly dropped. For large installs that required substantial numbers of serial ports, the existing AM-319 board had to be expanded. The revised AM-319-20 board, providing four built-in serial and parallel ports with a UPS monitor port and a higher-performance DP83902 Ethernet NIC, still had two paddlecard slots, but these slots were widened to 60 pins and could now be part of a bus connected to an external chassis. Alpha Micro had long sold the AM-990, a large capacity case (in this image as used for the AM-4000, though I apologise I don't have a better image of it) and the AM-990 Jumbo, which was even larger. A new higher-performance serial card was developed to take advantage of the widened paddlecard slots, an optically-isolated eight-port card called the AM-359. Twelve AM-359s could be installed in the AM-990, yielding 96 ports when connected to a fan-out in one of the AM-319-20's paddlecard slots (the four on-board ones made an even hundred); the Jumbo could take another twelve AM-359s for another 96 ports connected to the second, a whopping total of 196 serial ports when combined with the base four. If you needed even more, the AM-3501 sidecar chassis could take you well beyond. There was no point in supporting the 68EC030 with such a monster: this new Eagle, officially the Eagle 550 Super Eagle, was 68040 or bust. that large, a Super Eagle in the standard case could support up to 60 ports, four on the AM-319-20 and then seven AM-359 cards in the usual position. The E550 Super Eagle additionally came as a separate upgrade kit for the E500 and the few E400s that sold, essentially a system board swap, though when sold as a turnkey system it was always with the 40/80MHz CPU. The E550 introduced a new Seiko timekeeper chip as well which not only maintained the time but also the "CMOS settings," the first Alpha Micro with an on-screen setup utility in ROM allowing boot configuration. Subsequently the company was tardy once again in adopting Motorola's newest 68K CPU, this time the superscalar 68060, which had come out in 1994 aimed squarely at the Intel Pentium but didn't reach Alpha Micro customers until mid-1997. This took two forms, a new 66MHz '060 Roadrunner upgrade option for the E550 Super Eagle and the AM-4000 (lesser Eagles need not apply), and a new AM-6000 large system. Interestingly, the AM-6000 is strongly based on the E550, reflected in its internal designation as the AM-3500-6000 making it a "stealth" Eagle. The '060 Roadrunner not only included the new CPU but also 64K of L2 cache, support for up to 256MB of RAM in four SIMM slots, and 68-pin Fast and Wide SCSI-2 using the NCR 53C770. along with E100s and a smattering of E500s and Super Eagles. However, it was not lost on company management that Motorola believed the 68000 family was fast approaching a performance wall. This was made most clear by their then-enthusiastic participation in the PowerPC AIM alliance, but also the rise of ColdFire, which Motorola had first announced in 1994 as well. ColdFire was in its own way Motorola's oblique admission that 68K was losing desktop competitiveness to x86, an attempt to scale the ISA down to embedded markets where its familiarity could be an asset. Approximately 20% of the instruction set such as BCD and certain addressing modes were eliminated, meaning the canonical ColdFire could not be fully binary-compatible with any extant 68K. On the other hand, such cuts enabled the core to execute nearly every remaining instruction in a single clock cycle, and the initial die was a miniscule 4.4mm² at 0.5μm, a third the size of Motorola's own 68300-series CPU32+. Some amount of this work was done by altering the microcode of the 68040V, a fully static 68LC040. Mindful that ColdFire's incompatibility might impair adoption, Motorola chose to create a bridge first-generation chip from this altered 68040V where omitted user mode instructions were left in, demonstrated on die photos. While the new chip had smaller 2K instruction and 1K data caches than the 68040V, and the MMU was also eliminated, this deviation from spec was still sufficient to run regular 68EC040 code at the user level. Motorola called this first-generation ColdFire chip the MCF5102, produced on a 0.6μm process, and introduced it in 1995 drawing 0.8W at 20MHz and reaching 33MHz. Clock-for-clock there was no way this chip could eclipse an '060, and the emerging "true" ColdFire 520x series couldn't run existing Alpha Micro software, but the MCF5102 was still faster than an '030 and nearly as fast as an '040 — in fact, we'll prove it. On top of that it was cheaper and AMOS didn't need the MMU anyway, making for a plausible mid-range machine that wouldn't imperil (much) sales of the E500 or E550. alt.sys.alpha-micro, though credit must be given to John F. G. Leighton, then Alpha Micro's VAR marketing manager, who chose to print the review unedited in marketing materials, even Rod's gentle complaints. Since this is the only E450 I have personally laid my hands on, we will be referring to his comments liberally as a point of comparison, and consequently the E450's history is probably the best documented of any 68K Eagle. It rolled out to users in October at the annual meeting in nearby Riverside, California. This particular system was a gift from someone who inherited it from an 9-1-1 emergency dispatch centre and wanted to find it a good home, another way that running an Alpha Micro-powered web server has paid off. I was able to quickly get into the system (if it's not clear by now, I love hacking into Alpha Micros) and reconfigure it, and it had lurked as the E300's work spare and a test unit since then. Like the E300 it has a bootable tape drive, but this time it's a more modern DDS/DAT. E450, and it claims not to have an SSD at all (untrue). As such, I'm not sure I can believe the stated manufacturing date of September 2002, and at least one date inside directly contradicts it. It's possible this was a case with a transplanted board. 1999 as prerequisites for the AM-370, an unidentified off-the-shelf 100Mbit PCI NIC that goes into the "slot" at J5. To access these PCI slots, that rear panel I pointed out needs to be removed. The AM-370's availability implies all shipping E450s should have had them by then — there was even an alleged board-swap program to do so. I've yet to find another one, so I don't know if that's true, but it would be interesting to find out because with this card or the OEM equivalent you would have two fully operational NICs and multihoming was reportedly supported. I also don't know what's going on with the unpopulated "option connector" at P5 to the right/east of the AT power connectors. other slots. The E450 is one of only a few Alpha Micro systems that can accept an optional external L2 cache, though as mentioned this cache is only enabled for instructions, and the form factor does not match any PC cache stick — in fact, it's the same as a 72-pin SIMM, so don't put the wrong one in the wrong place (Rod also objected to this). The only size supported is 64K, the same cache stick used for the AM-6000 and the '060 Roadrunner, part #PDB-00701-00. I've never seen this cache stick and comparison of his numbers with my cacheless E450 suggests it only yields around a fourteen percent boost, not nothing but not much, likely because it can't do anything for the data cache (though stand by for a very important observation on actual clock speed). The E450 also has two 72-pin SIMM slots, which need not be paired and support up to 256MB, though as with the earlier systems the machine needs to be jumpered to tell it how much is there. The tag on the one in J11 (service order 13009, apparently) is dated January 18, 2002: that makes this machine at least eight months older than its alleged manufacturing date, and to have received an upgrade suggests it's even older than that. Between the two sticks this system has 72MB of RAM. Below/south of the RAM SIMMs are the three paddlecard slots. Also in this image is another obvious non-populated area: a pin-grid array marked "PGA040" at U89 in the northeast/upper right hand corner. That sounds like somewhere the CPU would go, and the footprint looks like an '040. So where's the actual processor? fast is it doing it, though? While Rod's review stated his prerelease system was apparently running at 33MHz, the oscillator closest to the CPU can be seen clearly in this photograph, and it's ... 25MHz. There are no other crystals on the board except for the serial port one you saw earlier, the official marketing announcement has a board layout that also clearly labels this crystal as 25MHz, and nothing in the MCF5102 user's manual says the chip does anything tricky with the clock. As it happens, the only place in Alpha Micro documentation where the E450's CPU speed is given is Rod's review: everywhere else, even the data sheet, simply says it's a ColdFire and nothing more. Since mine is only 14% slower than his, and his had the cache, his can't possibly have been running at 33MHz either. The E450 is a 25MHz ColdFire, full stop. In a backwards way, however, this is nothing less than validation of how performant early ColdFires could be. Recall that our E300, a 40MHz 68EC030, had a "CX" computing index score on the SI.LIT benchmark of 36.9. The same benchmark on this E450 with a 25MHz MCF5102 gets a score of 59.9, and Rod's with 64K L2 came in at a whopping 68 (Alpha Micro said 68.5; either one is around 14% higher). By contrast, the E550 Super Eagle, with a full 40MHz ("80MHz") 68040 Roadrunner clocked 60% faster and 32K of L2 cache, officially gets ... 79.9 (note from the future: my figure is 83.6) — the full cached-up faster-clocked 68040's performance on the same code is only around 33-40% better, and just 16-22% or so if the E450 has its cache too. Put another way, the CX/MHz ratio of the faster 68040 was right around 2.0, while the CX/MHz ratio of the MCF5102 is 2.4 without the cache, and almost 2.75 with it. Likely because the lower clock speed would have looked bad in marketing materials, similar to why General Magic never mentioned the clock speed of the DataRover 840, Alpha Micro simply chose not to mention it either. Still, this machine's surprising efficiency proves ColdFire, at least early on, definitely had legs. I'm not sure how Rod got it wrong except that an earlier version may indeed have run that part, though with these numbers, if there had ever been a production 33MHz E450 it might have seriously endangered sales of Alpha Micro's remaining '040s — perhaps that's why they didn't use it even though the faster part existed. Best guess is that the AM-138 was originally designed for the 68040 and then quickly retrofitted for ColdFire, leaving the PGA region as an "R&D test point" (as documented). our prior entry, and he referred me to a longtime Alpha Micro vendor that they still partner with for existing installations. It took a few months, but this vendor was able to locate what appeared to be another E300 with working boards and we negotiated a price and getting it shipped. "everything console" connected to the top left port (G1) via the dongle at the typical speed of 19200bps. Good, it booted fine, we got a dot prompt, we can get into it, networking is already configured, and (as is typical for most Alpha Micro installations of the era) there is no password on the operator account. I powered it off and now that we know where the system thinks the console is, we'll get a proper self-test readout. I powered it back on with the reset button held in and the self-test came right up. The self-test can autosense the baud rate by mashing the spacebar when the front LED flashes "5b," and then the test runs, with the LED showing the current state and additional details sent to the serial port. ---------------- SYSTEM SELF-TEST ---------------- Version 2.1(120) Prom Rev. N00 for the AM-174 board. polling complete. Boot configuration: Processor - 68040 Memory detected - 32M bytes Primary serial ports - 4 SCSI Controller press [space] to bypass memory test MEMORY TEST passed - 32M bytes TIMER TEST passed SERIAL PORT TEST Primary serial ports - 4 Port # 0 passed Port # 1 passed Port # 2 passed Port # 3 passed SCSI Controller Controller Self-test passed SCSI drive Self-test passed Find diagnostic cylinder passed Write/read test passed 40?! This is not a Eagle 300! We need to open this thing up. didn't expect was the CPU board on the bottom: it's a full 68040, just like the test said. Bclk for the bus clock, and then a second exactly twice as fast labeled Pclk as the so-called processor clock. In the 68020 and 68030, which accept a single clock signal, their internal ALU runs at only half the bus speed such that the 40MHz 68EC030 in the Eagle 300 actually has an ALU running at just 20MHz. For the 68040 Motorola removed this limitation to run its ALU at full bus speed, but the chip designers also studied trace data to optimize for the most common instructions, implementing a 7-stage pipeline where most effective address calculations and fetches occur with no penalty. The upshot of this was to cut most instructions' cycle count in half or more. The 2x processor clock is truly used, but not to speed up the ALU, so it's wrong to say the 68040 is "double-clocked." In a two-part 1990 article in IEEE Micro, Motorola explains that "Pclk provides timing reference points within each Bclk period," employing it for synchronous sub-cycle timing, and furthermore explicitly states that "all internal operations cycle at the Bclk rate." Still, the fact this clock signal was present at all gave Apple an excuse to tout both timings for '040 Macintoshes, and Alpha Micro cheerfully reported just the faster one, even though the chip only appears to run at that comparative speed from its larger 4K L1 cache, unhindered ALU and reduced cycles per instruction. On this board, Pclk is provided by the same 80MHz crystal we saw on the AM-172, divided down by two to yield Bclk in the same way the 68EC030 board does for its single 40MHz clock. (For the E400's AM-174-00, this crystal would have been 66MHz divided down to 33MHz.) The single parity FPM SIMM slot and 16MHz and 50MHz oscillators are also present, as well as the same 53C710 SCSI controller, here a genuine NCR part. However, new for this board is 32K of L2 cache at the upper right/northeast corner, implemented with two IDT 71B74 8K cache-tag RAMs together providing 29 bits (512MB) of address comparison, and then four Cypress CY78C185 8K SRAMs for the cache itself. Remember, however, that in AMOS all cache is I-cache. Effectively this 40/80MHz AM-174 makes our new system a full Eagle 500, so why is it labeled as "only" an E300? I don't how how these systems originally shipped from the factory nor whether the E500 designation actually appeared on the back, but Alpha Micro did run a promotion in late 1997 where you could upgrade any Roadrunner '030 to a Roadrunner '040 by swapping the CPU board. My guess is this is one of those systems, and because that upgrade kit wouldn't have changed the plate on the back itself, the reseller simply noted it to be a working E300 and sold it to me as such. While that wasn't exactly what I was hoping for, it's a really nice bonus, as evidenced by the system benchmark (taken on the SCSI hard disk it shipped with): That score officially makes it the new fastest Alpha Micro in the shop by far (this is where that prior 83.6 number came from, compared to the E450's 59.9 and E300's 36.9). It seemed a shame to carve it up as spare parts, so let's have a little look around. A surprising thing about the system configuration file (SYS:AMOS32.INI, a/k/a AMOS32.INI[1,4]) is that only one terminal is actually defined, which makes you wonder what those two RJ-21s are doing. Best guess is that this machine passed through a couple hands and ended its prior service as a single user's toy, much as my own machines are now. In a related phenomenon an annoyingly small number of terminal types are defined, all inconvenient, likely to save memory. On the other hand, the full AlphaTCP suite (based on SpiderTCP and SpiderStreams, best known as the Windows NT TCP/IP stack before 3.5) is defined and present, and we saw it running before, so we ought to be able to make use of that. That's its IP address, and we saw Telnet was running (TCP:TELNED.LIT), but there's a snag: The TCP:CONFIG. file sets up TCPEMU, AlphaTCP's master daemon, acting as its service description file (really a sort of up-script). This line for the Telnet daemon causes an automatic log-on from a Telnet session and inconveniently forces the FWYCOL terminal type, intended for a real Wyse WY-370. That's also the terminal setting for the single serial port which our "everything console" doesn't speak, meaning I can't visually edit anything without making a big mess. Ironically, that AM-75 colour head my E300 uses is itself a modified WY-370, but no longer speaks that terminal emulation either. But we have another option! Now knowing its IP address, I set up a small wired network to my MacBook Air. Although some terminal programs like Kermit 95 can speak WY-370 over Telnet, using MacWise — now freeware and runs on Tiger and Power Macs all the way to Tahoe on Apple silicon — I managed to discover that its TeleVideo 925 emulation will partially match FWYCOL. This was just enough to, with some care, edit TCP:CONFIG. and remove all the defaults so that I could manually select the terminal type on Telnet login. I then reset the FTP user credentials in TCP:FTPUSR., uploaded a copy of ANSI.TDV from the Eagle 450, and changed the TDVDEF line in a test copy of SYS:AMOS32.INI to allow it as a terminal type, which at last got me a proper session. I'm not sure of this system's most recent owner and the seller didn't know either, but there were two interesting domains in its TCP:HOSTS. file (identical to /etc/hosts) for that IP address. One domain name belongs to someone who appears to have been a recording engineer (!). This domain still exists, but is only partially functional, so I've chosen not to link it here. The other domain name was for a personal genealogy site, now parked, and that site appeared to be what it was currently offering via the Web server on HTM:, mapped to PPN [7,77]. However, because the HTML files were not on an extended directory device, I can't tell when the site was created because the old AM file system doesn't preserve modification times: Looking up this domain in the Wayback Machine, it seems to have been active in the early 2000s. Still, not bad assuming it was still serving it then. differently on the AM-172 and AM-174s, so it seemed safer just to never separate them in the first place. I wasn't even going to move the SSD and hard disk — since TCP/IP networking was already set up on the E500, I could just upload the site to the E500's hard disk instead. Only the E300's power supply, serial port cards and Tandberg QIC streamer would stay. Once the new transplanted system was working, then I'd see about doing the ZuluSCSI upgrade again. It tried to boot. Startled, I powered it off, connected the everything console, and turned it back on with the reset button held in to force a self-test. Except for the missing hard disk, it passed the self-test — even the SCSI controller tested good. I decided to push my luck and connect the ZuluSCSI, and this time it did throw a 2d. I freaked out again, powered it off, let it sit and then gingerly turned it back on. It still did it. However, when I disconnected the ZuluSCSI, it went back to trying to boot, and a repeated self-test was still clean. This was clearly new behaviour — beforehand, it wouldn't do anything, not even enter the self-test, let alone attempt booting. Recall that error 2d had two mentions in the manual, the second one referencing the primary and secondary boot devices. Since the self-test said the SCSI controller was fine, this made me suspicious that there was something about the ZuluSCSI's configuration the machine didn't like. Knowing some systems can get finicky about sluggish devices immediately after power-up, I reconnected the ZuluSCSI and powered the E300 back on. Code 2d duly appeared, but this time instead of turning it off, I hit the reset button just to see what it would do. SI.LIT had actually dropped to around 10, which was 33% slower than its original hard disk. .scsi Dispatched SCSI port: SCSI id 7: (reserved) SCSI bus host adaptor SCSI id 6: No device or unable to report SCSI id 5: No device or unable to report SCSI id 4: No device or unable to report SCSI id 3: SCSI-2 (tape) TANDBERG TDC 4200 =08:01CREATED12119 SCSI id 2: No device or unable to report SCSI id 1: No device or unable to report SCSI id 0: SCSI-2 (disk) ZULUSCSIHARDDRIVE 2.3BZuluSCSI .si dsk0: SI--AMOS System Information, (C) Copyright 1990, Alpha Microsystems Inc. Version 3.0(114) Computer Type: Eagle Main Processor: 68030 Co-Processor: None MMU present: Yes Operating System: AMOS 2.3A(484) Boot PROM revision: M00 Number of SSDs: 1 Total Memory: 16384 K-bytes Resident Monitor Memory: 6218 K-bytes Computing Index (CX), relative to AM-100: 36.8 48 bit FP Index (4X), relative to AM-100: 36.3 Floating Point Index (FX), relative to AM-100/L: 5.6 Disk Index (DX), relative to ST-506: 41.2 .si dsk0: SI--AMOS System Information, (C) Copyright 1990, Alpha Microsystems Inc. Version 3.0(114) Computer Type: Eagle Main Processor: 68030 Co-Processor: None MMU present: Yes Operating System: AMOS 2.3A(484) Boot PROM revision: M00 Number of SSDs: 1 Total Memory: 16384 K-bytes Resident Monitor Memory: 6218 K-bytes Computing Index (CX), relative to AM-100: 36.9 48 bit FP Index (4X), relative to AM-100: 36.3 Floating Point Index (FX), relative to AM-100/L: 5.6 Disk Index (DX), relative to ST-506: 100.4 six times faster than the original hard disk). There's no obvious caching in the Blaster's firmware that I could see, and although the AMOS system-wide disk cache was on, the test is supposed to be unaffected by OS-level caching. On the other hand, when I rebooted AMOS from software, its score went back to 41 and 100 thereafter. More on this phenomenon later. Termination power was sufficient to power the Blaster. But what the Blaster didn't fix, even with its later firmware, was the 2d code the E300 kept throwing from a cold start. Although booting after a manual reset was still fine, it refused to start after a power cycle without assistance, which I need it to be able to do if there's a power outage when I'm not around. .ini file, but since the issue appeared to be what the E300 thought was the secondary device and I knew the streamer was connected and working, I had a look at the back boot DIP switches first. The previous setting was #1 and #3 on, which would attempt a boot from the (non-existent) floppy drive first, and then try the SCSI hard disk. This had always worked before, but we have no floppy drive and I'm not likely to find an AM-219 anytime soon, so I tried the other boot position where it attempts a boot from the streamer first — again, known good electronics — by switching #4 on. And that worked: now it boots reliably. The conversion is complete. So, with the E300 resurrected and finally successfully converted to solid state, let's really push our luck here ... by doing the same with the others! (I should note I excluded the E100s this time around; I haven't found a special task or physical location for them yet.) SI.LIT disk score of 30.9. For this system I bought a ZuluSCSI Wide, which tops out at 34 MB/s read and 15 MB/s write, and which I already use in my Apple Network Servers with a similar NCR 53C825A. .scsi Dispatched SCSI port: SCSI id 15: No device or unable to report SCSI id 14: No device or unable to report SCSI id 13: No device or unable to report SCSI id 12: No device or unable to report SCSI id 11: No device or unable to report SCSI id 10: No device or unable to report SCSI id 9: No device or unable to report SCSI id 8: No device or unable to report SCSI id 7: (reserved) SCSI bus host adaptor SCSI id 6: No device or unable to report SCSI id 5: No device or unable to report SCSI id 4: No device or unable to report SCSI id 3: No device or unable to report SCSI id 2: SCSI-2 (tape) HP C1533A A907 9 SCSI id 1: No device or unable to report SCSI id 0: SCSI-2 (disk) ZULUSCSIHARDDRIVE 2.3WZuluSCSI .si dsk0: SI--AMOS System Information, (C) Copyright 1990, Alpha Microsystems Inc. Version 3.0(114) Computer Type: Eagle Main Processor: 68040 Co-Processor: None MMU present: Yes Operating System: AMOS 2.3A(484)-15 Boot PROM revision: D00 Number of SSDs: 1 Total Memory: 73728 K-bytes Resident Monitor Memory: 4366 K-bytes Computing Index (CX), relative to AM-100: 59.9 48 bit FP Index (4X), relative to AM-100: 58.2 Floating Point Index (FX), relative to AM-100/L: 7.9 Disk Index (DX), relative to ST-506: 51.0 .si dsk0: [...] Disk Index (DX), relative to ST-506: 52.2 . the last Alpha Micro article we booted our AM-1200 desktop system using a BlueSCSI attached to its external 50-pin Centronics-style SASI port, which with some tweaks to the settings file can be made compatible enough for its very old bus. But I'd like to use that device for other things, so we'll put the old ZuluSCSI card — more than fast enough for this thing — inside. To avoid me having to dismantle it every time I want to switch the disk image, I disconnected one of its unused serial ports and threaded a USB cable there. SUB0:. It's as fast as the BlueSCSI was, probably because both devices can easily saturate its slow SASI bus: AMOS 1.4 misdetects its 68010 as a 68000 (AMOS 2.3A detects the CPU correctly), but like the E450, there was no second test bump either. "everything console." I should point out that the E500 has a slightly later version of AMOS than the E300 and E450 and we get a little more explanation with the bus readout: While all three systems support synchronous SCSI, this version of AMOS actually reports it, along with the width (8-bit, because it's only Fast SCSI, not Wide). Now, what about performance? The ST32272N we replaced is a 7200rpm drive while the ST310151N in the E300 was only 5400rpm, thus accounting for the E500's better baseline disk score, and the E500's faster CPU probably explains its slightly higher first-run result of 46.3. But the second run is even more lopsided than what we saw with the E300, a massive 180.7. Since two of the systems were doing it, it was time to dig in a little more. The ZuluSCSI Blaster has a debug mode switch which echoes status and current operation to a connected machine over USB serial at 115200bps, so I hooked up both the E500's serial console and the USB port of the Blaster simultaneously to the MacBook Air to watch what SCSI operations occurred during the benchmark test. very unusual: there wasn't any. In fact, even though the baseline score had sunk down to a dismal 10 or so because of all the debugging data it was emitting, the second run was still a blistering 180.7. This really sounded like operating system caching, but except for the AM-1200 where I wasn't running it to save memory, the other three systems were running the standard disk cache as virtually any performance Alpha Micro would — and allegedly SI.LIT should be unswayed by it. For some reason the E450's cache configuration wasn't locking UFDs (user file directories, i.e., PPNs), but turning that off on the E500 and E300 didn't make a difference, and all three were caching everything else including the MFD (master file directory). However, when I turned off caching altogether at runtime (using the CACHE.LIT tool and disabling with OFF), though the scores got really low, they were now consistent from run to run. Do note our observation isn't enough to fully explain the E450, which also runs the OS disk cache, but didn't have a second run bump. If you disable the cache on the E450, although its overall score declines, it still remains consistent from run to run. One possibility is that the driver for its later SCSI controller just isn't as aggressive. Although the overall issue certainly calls into question how useful SI.LIT is as a disk benchmark, despite being likely the only Alpha Micro benchmark tool you can expect most recent systems to come with, the question then becomes how comparative disk performance on an Alpha Micro should be measured. Was it still fine for me to continue with my usual practice of leaving the cache on and testing immediately after boot? It's probable that there'd be little in the cache by that point, whatever would be there would likely be similar from system to system (assuming the same version of the operating system), and likelier still that whatever was present in the cache wouldn't be very germane to SI.LIT. Under my current knowledge of AMOS I think these numbers are still broadly comparable; I just have to keep in mind that the score on subsequent runs is likely to be bogus. precisely even with our E450 here). The E100 was discontinued shortly afterwards in 2001. SI.LIT CX score of 816 (!) on dual Athlon 2800+ CPUs. Later AM-113 SuperFalcons were just serial ports and a socket for the SSD; the main system was now more than suitable to service them, and Motorola wasn't making any more 5102 CPUs either. The Eagle 800 that same year ran the same technology in miniature, bringing the great experiment to a close with the discontinuation of the last E250 and E450 systems, and today's systems sold by the reformulated Alpha Microsystems LLC use the same x86-based architecture. Over their production lifetime, analysis of known serial numbers suggests around ten thousand 68K Eagles were ultimately sold, and now I've got five of them. Rest in peace, Rod. They're still great machines.
A decade ago, a little bit of history was made. I didn't realize it, but a colleague made a great point, one of those real mind-changing points that seem too obvious to admit same-day. But, the next day, calver.org was born. At the time my team maintained the Python infrastructure for eBay and PayPal, and we were stuck deciding whether we were really ready for a "major" 1.0 release. Semantic Versioning was the only game in town and "major" means "big", right?! Thankfully, a wiser colleague mentioned: Ubuntu and Twisted don't struggle with version number debates. They slap a date on it and keep shipping. In fact, their date-based versions were even better because you always knew where it stood, in terms of updatedness and support. The only problem is that no one really knew about it. Somehow, this problem solving versioning alternative, arguably as old as history itself, had gone nameless for millenia, conspiring to make me feel foolish in an office meeting. Never again! Ten years of adoption Fast forward 10 years, we've seen CalVer adopted by Apple, Nvidia, JetBrains, and countless others. (We have a timeline!) The site may have more inbound links than any other project of mine. Apple made the biggest jump, at WWDC 2025: iOS went from 18 to 26 macOS from 15 to 26 watchOS from 11 to 26 and visionOS from 2 to 26 All landing on one, consistent number like a car's model year. I still remember the texts from the Venn diagram fanbase of my friends who love Apple and reasonable versioning. No such texts from when NVIDIA announced calendar versions across the GPU Operator, RAPIDS, and its monthly NGC containers, but still very cool. Open source, too: Home Assistant, pip, CockroachDB, and yt-dlp all ship on dates, with plenty more on the users page. The conversation even reached the language core; PEP 2026 proposed versioning CPython as 3.YY, and it almost happened, too. And it's never too late, time marches on! Fixing the notation But I don't think I got every detail right from day 1. That's the main motivator for CalVer 26. It's high time to start righting a couple idiosyncratic token design choices, starting with some additions: Meaning Before 26.0 26.0 Full year YYYY YYYY Short year (6, 16) YY YY Zero-padded year (06, 16) 0Y 0Y Short month (1 ... 12) MM M Zero-padded month (01 ... 12) 0M 0M Short week (1 ... 52) WW W Zero-padded week (01 ... 52) 0W 0W Short day (1 ... 31) DD D Zero-padded day (01 ... 31) 0D 0D Seeing double First, the doubled letters. From the first version (16.6), MM and DD meant the unpadded month and day, which reads backwards to anyone who knows date formats (ISO 8601's YYYY-MM-DD, Java, moment.js, day.js), as some community members correctly pointed out. I was ready to flip them, until I checked what people actually use: most projects with a YY.MM.MICRO badge (conda, Twisted, Ansible's tooling) don't pad, and more than a dozen other version management tools (like bumpver and bump-my-version) implement the old meaning. So, it's too late to flip MM's meaning. Instead, 26.0 deprecates it and offers a more explicit and hopefully clearer option: M is the short month, 0M the padded one, and MM is a technically-retired synonym for M. In case you're wondering, the explicit 0M was me being overinspired by Ubuntu's approach, perhaps: 6.06 pads its month but not its year, and YY.0M says exactly that. To pad or not to pad I think it's worth a detour into why padding is even a thing anyways. It's become important now that new ecosystems have emerged that enforced SemVer formatting semantics, and I wanted clear guidance about on the spec site. SemVer forbids leading zeros outright, so Cargo rejects 26.04.0 and Go modules reject v26.04.0. Even Python's packaging spec normalizes leading zeros away, so you can tag 2026.08.19 if you want, but PyPI will still show 2026.8.19. NVIDIA's GPU Operator docs put it this way: "Zero padding is omitted for month to be still compatible with semantic versioning." CalVer was always intended to drop in where SemVer was used. So 26.0 recommends unpadded (YYYY.M.D) as a sane "pure" default for software libraries. But libraries are not the only objects of versioning schemes. The exception is a version that becomes a filename, an image tag, or an object-store key that gets listed lexically. There, padding keeps 26.10 sorted after 26.09, which is why Ubuntu, NixOS, and NVIDIA's own NGC containers pad. More evidence of teams designing their versions. We love to see it. Our FAQ has a longer discussion of the padding issue, as well. Optional segments There was never any rule against them, but 26.0 makes optional trailing segments more explicit with square brackets. Now, yt-dlp's scheme can finally be written down: YYYY.0M.0D[.MICRO]. For the CalVer badges I could find on GitHub, they all stay valid for now. I've got a note on the deprecated spellings and a new copy-paste badge section for new ones. What else is new? It's always a great time to add more citations to the site. A spec changelog; the spec now versions itself: 16.6, 19.7, 26.0. A FAQ: breaking changes, same-day releases, and padding. The users page, rebuilt by category, with past users of note (schemes change; that's fine) and tooling. Case studies: Apple and NVIDIA in, yt-dlp replacing youtube-dl. Much of the thinking behind these changes happened in the GitHub issue tracker over the years, and 19 or so issues close with this release. That's where ideas for CalVer should go, so by all means, open an issue, and we'll get it sorted! In due time, of course. In closing, I can't believe I still love belaboring these numbers so much. Thanks to all (but especially Mark, Glyph, Hugo, issue reporters, translators, and maintainers) for the discussion, and ultimately making the most timely versioning system a timeless classic. See also 2016 announcement Designing a version My Yap on Why CalVer beats Semver
Four sincere attempts at OKRs, four failures, and every time: "you didn't do it right." Maybe the framework doesn't fit you -- so how do you find one that does?
Multiple concurrent writers. Multiple processes. Same SQLite. No modifications.
Brilliant jerks, ZIRP-era managers, and how psychological safety lost the plot. Part 3 of my conversation with Dr. Cat Hicks.
