Sirius DOS

Why?

The Anodyne personal supercomputer project poses a dilemma: with how conjoined hardware and software are both in theory and in product, it is hard to significantly improve one without being held back by the other. Just try installing Xilinx Vivado and marvel at all of the gigabytes of disk space you will end up needing – and that’s the minimum required to start making anything.

The cause of this problem is something programmers are, incidentally, already familiar with: it’s called coupling, and it is indeed a scourge. Even though products continue to climb into the stratosphere as measured by benchmarks, scientific computing and visual rendering of 3D and video, the experience of using them and programming them has become severely stunted. One does not simply “do whatever” as they could in the 1990s now that programming has become pigeonholed into existing architectures, paradigms and ways of being.

We have to break this coupling in order to reopen the door to impactful experimentation. The only way to do that is by solving the catch-22, hence the creation of Sirius DOS. DOS was chosen as a foundation because of its widespread use, unassuming architecture that can be expanded upon easily and its virtue as a period piece of the 1980s and early 1990s when it was an open question what media formats or instruction sets your computer might be using. Indeed, even on DOS we will fast be realising some great innovations—such as the software modular memory technique—without even having to touch an FPGA.

How so?

To start, the project will retread the footprints of Ken Thompson:

1. an editor
2. an assembler
3. a kernel overlay

In our case, the following software will do these jobs, respectively:

1. Quindle
2. Oración
3. Hinterlib

Unlike Thompson’s original UNIX, these will not be a crummy amalgamation of primitive tools. Quindle will be a high-colour program running up to 1280×1024 in resolution with a fully-fledged virtual terminal and fixed tiling window system, Oración will be a modular assembler with instruction encodings and aliases composed in source files, and Hinterlib will subsume the MS-DOS subsystems already present while also pulling double duty to converge the programs using it onto a unified API for both DOS applications and hosted applications on other systems it supports.

These are just the basics however. With these in hand, the creation of the so-called ‘developmental quartet’—Inbound, Outbound, Rebound and Earthbound—can begin. These tools provide the rest of the plumbing necessary to develop software products to completion: build orchestration, software package creation, software distribution strategies, and finally the procurement of software from yonder, respectively.

Outgrowing MS-DOS

Sirius DOS must necessarily have humble beginnings. With Quindle as its editor, Oración as its assembler, Hinterlib as its kernel overlay, and the developmental quartet to orchestrate the development cycle, work can begin in realising the first new systems unique to Sirius DOS in contrast to other DOSes, contemporary and historical.

Prime and subprime ABIs

Sirius DOS will provide two distinct application binary interface minimums, the prime and subprime ABIs. The prime ABI is also further distinguished into the the single-wide prime ABI and the double-wide prime ABI, while the subprime ABI stands alone in its clade.

Prime ABI

In general, the prime ABI is a graphical interface for the ‘full fat’ Sirius DOS user experience. It provides 15-bit high colour support at the pel level directly to software, and supports up to three compatible displays simultaneously in this way (see below). Programs adhering to the prime ABI are written to operate in both ‘single-wide’ and ‘double-wide’ modes:

• Single-wide mode requires a monitor and video card that can support 640×480 pels in 15-bit high colour.
• Double-wide mode requires a monitor and video card that can support 1280×1024 pels in 15-bit high colour.

ISA requirements

Furthermore, the prime ABI requires (and thus provides), at a minimum, the full instruction set provided by the Intel 80486 and Intel 80387 together, excluding all instructions that are either used for switching to and from protected mode or are simply not usable in real mode.

Subprime ABI

The subprime ABI is a textual interface for the ‘low fat’ Sirius DOS user experience. It provides a single reversible unidirectional monochrome ASCII text stream as its interactive medium with the user. This stream is congruent with the standard C stdin–stdout pair, notably excluding stderr (though there are mechanisms to get ahold of that otherwise).

Input

The subprime textual stream provides three interactive input modes for submitting data into stdin:

1. character-based input where one ASCII character at a time is (irreversibly) typed and consumed without buffering
2. line-based input where a continuous stream of ASCII characters are consumed as a single contiguous line, allowing the user freedom to Backspace and re-type the content until Enter is pressed to submit it to the program
3. page-based input where a continuous stream of ASCII characters including newlines are consumed as a single block, allowing the user freedom to Backspace and retype the content until they press Shift+Enter to submit the page to the program

The input methods also provide the ability to register transformation subroutines of combinatorial complexity at the primitive level, making it practical to do simple one-for-one transformations for things like password masking or choice rendering of [Y/N/Q]-type user prompts.

Output

Output is always permanent and linear, and is modelled to be one of the three possible states the shell rendering loop can be in (the others being input and idle). Only printable ASCII characters and the non-printable control codes BEL and LF are permitted to be sent.

---

All of these design restrictions help to minimise incompatibility and improve the consistency of the user experience across many platforms and conforming applications.

ISA requirements

Unlike the prime ABI—which expects at least an i486—the subprime ABI is more forgiving, only mandating the full instruction set as provided by the Intel 80286 and Intel 80287 together. Like the prime ABI, the subprime ABI also excludes all instructions that are either used for switching to and from protected mode or are simply not usable in real mode.

Multi-monitor support

While much development happens in a DOSBox-X session, Sirius DOS is not an apocryphal development; therefore, stretching its legs involves taking advantage of hardware features provided by some of the components it will commonly come to employ even though they may not have been widely used contemporarily or even implemented in virtual environments such as DOSBox. True multi-monitor support—that is, using multiple displays independently to increase the sum of one’s total screen real estate—is one such feature.

Many SKUs in Cirrus Logic’s popular line of 2D ‘Windows accelerator’ ISA and PCI cards provide the ability to relocate the card’s VGA registers from their original IBM-standard location. This essentially makes it practical to control and feed more than one such video card at the same time. This feature is not to be confused with the CGA–Hercules ‘dual monitor’ configuration, as each monitor–card pair is fully equipped, however a similar user experience to it is often constructed anyway.

Revisiting modularity

One of the big concepts in modern computing Sirius DOS gives a lot of thought to is that of software modularity in the context of binary formats for application code and data. While this was mostly an afterthought left to application developers, there were some trends that persisted somewhat for their obvious virtue; for example, many code blobs had a file extension bearing the x86 variant they expected to be run on, most often .386 for ‘32-bit capable’ code. Also considered are the various strategies—now considered antique or even downright novel— for code reuse and what would later become known as ‘dynamic linking’, such as the technique of overlays.

To start with, Sirius DOS takes the toolset of software modular memory as a premise in how it approaches the subdivision of data (including code treated as such). In general, regardless of the underlying architecture, Sirius DOS handles prime ABI code blobs with the .486 file extension and subprime ABI code blobs with the .286 file extension, with a catch-all .X86 file extension for brave souls.

These code blobs are not run or executed directly; instead, they are collated into a bill of lading that contains basic metadata needed to start up a fully-fledged application with all of its data collections and code modules. It is at the level of this bill of lading that dynamic loading of architecture-dependent code blobs can take place, constituting a simple sort of ‘fat binary’ provision in practise. It also means that regardless of architecture, a data module need only be named and filed once.

In general, all code blobs are nothing but pure, straight machine code with no adornments or sanctioned metadata included in-line whatsoever. Furthermore, they are all limited to 64 kibibytes in size, starting from offset 0 (in contrast to 0x100 offset of COM files). They are also required to be fully relocatable, meaning their instruction stream is not allowed to modify segment registers directly. Not to worry, though: Sirius DOS will provide a straightforward and performant way to accomplish just the same in a more intelligent way by adding no more than a single additional step.