Independent studio · Operating systems
Tombasoft
A five-person studio writing whole operating systems for eighties hardware, on a build farm, an emulation rig and a vault that share no machine.
- Castalia 92386 VGA desktop
- CastaliaOS 98 PEFreeDOS-based desktop
- ChumOSAmiga Workbench alternative
- C-128 WorkSpaceCommodore 128 desktop
The problem
- Hard constraints
- A build must never wait behind an emulator run, and the reverse.
- Every published image stays available, byte for byte, indefinitely.
- No analytics, no third-party trackers, no data collection anywhere in the studio’s public infrastructure — a published commitment, not a preference.
- Root on every machine. Cross-compilers, emulator builds and kernel parameters are pinned by the team, not by a platform.
- Affordable for five people with no publisher money behind them.
Tombatossals Softworks — Tombasoft — writes operating systems for machines most people threw out decades ago: a VGA desktop for 386-class hardware, a FreeDOS-based one, a Workbench replacement for the Amiga and a workspace for the Commodore 128. Five people, across Spain and the United States, with no managers and no publisher.
That is two build problems wearing one hat. Compiling an operating system is wide work that spreads across every core you can give it. Proving one is not: the image has to be booted, in a cycle-accurate emulator, driven to a desktop and looked at — and an emulator is a stopwatch, not a farm. On the single large machine they had, the two starved each other.
And the artefacts never stop arriving. Every release is a disk image that has to keep booting forever, every build is promoted from a specific artefact, and the studio keeps every version of every sprite and every track it has ever made. None of that belongs on the disk of a machine that gets reinstalled when a cross-compiler changes.
Architecture
Edge
Public sites and downloads
2 ×Volt 2
Build
Build farm
2 ×Apex 7
Build
Emulation test rig
3 ×Forge 3
Storage
Artefact and asset vault
2 ×Apex 3
Archive
Write-once release archive
2 ×Forge 9
What it runs on
Edge
Public sites and downloads
2 ×Volt 2
4 vCore · 8 GB · 75 GB NVME
Two small virtual servers behind a floating address: one carries the studio site and the devlog, the other the encrypted newsletter and the download mirrors. 8 GB each is more than a static site needs on a Tuesday and exactly what it needs on a release day.
From $12.99 per month
Build
Build farm
2 ×Apex 7
AMD EPYC 7402 · 128 GB DDR4 · 2× 1.92 TB NVMe
The wide part of the pipeline, twice over: 24 cores and 48 threads of EPYC 7402 with 128 GB apiece, and a mirrored pair of NVMe devices holding the dependency and compiler caches. A full cross-platform build takes every thread it is given, and the second machine is what lets a release build and a branch build run at the same time.
From $259.99 per month, $230.00 one-time setup
Build
Emulation test rig
3 ×Forge 3
Intel Xeon E-2288G · 32 GB DDR4 · 2× 960 GB NVMe
Cycle-accurate emulators for the 386, the Amiga and the Commodore machines are serial by nature and want megahertz, not width. Three Xeon E-2288G boxes at 5 GHz boot every image on every target after every commit — one rig per platform family, so a slow Amiga sweep never queues behind a 386 one.
From $109.99 per month, $70.00 one-time setup
Storage
Artefact and asset vault
2 ×Apex 3
AMD Ryzen 7 Pro 3700 · 32 GB DDR4 · 4× 14 TB SATA
Two vaults, one in each region, each carrying 56 TB across four spindles behind an eight-core Ryzen. They hold every image ever released, every promoted build and the full history of the studio’s art and audio, content-addressed and never overwritten. Their job is to be cheap per terabyte and still be here in ten years.
From $219.99 per month, $219.00 one-time setup
Archive
Write-once release archive
2 ×Forge 9
Ryzen 7 3800X · 32 GB DDR4 · 2× 480 GB NVMe + 1× 14 TB SATA
The copy that accepts writes and refuses deletes: NVMe for the working index in front of a 14 TB spindle for the bulk, sited away from the vault it mirrors. Removing anything is a deliberate, logged, two-person operation rather than something a mistyped command can do at three in the morning.
From $120.99 per month
Techniques worth naming
Two build lanes, two machines
The pipeline was profiled before anything was ordered. Stages that parallelise went to the wide machines; stages that do not — every emulator boot — went to the high-clock rigs. Neither queue can starve the other, because they are not the same queue.
Booting as the acceptance test
An operating system is not built until it boots. Every commit produces an image that is booted headless on its target emulator, driven to the desktop and screenshotted; the screenshot is diffed against the last known-good one. A regression is a picture, not a log line.
Cross-toolchains pinned on root
A 1985 target needs a compiler nobody packages any more. Every cross-compiler, assembler and emulator is built from source and pinned at an exact version on the machines, which is only possible with root and is why a managed build service was never on the table.
Content-addressed vault
Images, builds and assets are stored under the hash of their own bytes and never overwritten. A release from years ago is fetched by the same hash its notes carry, and a corrupted file cannot masquerade as a good one — its address would be wrong.
Promote, never rebuild
The artefact that goes to the download page is the one that passed the boot tests, by hash. Nothing is rebuilt at release time, which removes the whole category of "it worked on the build machine".
Nothing that phones home
The public sites run no analytics and set no third-party cookies, and the newsletter goes out from a machine the studio controls. Root everywhere is what makes the promise checkable: there is no agent on any box the team did not put there.
Support
Extended cover, around the clock
Agreed with this account
Tombasoft
Release nights. An operating system ships when the last emulator sweep comes back clean, which is rarely office hours and never predictable a week out.
A named route, around the clock
An agreed escalation path that reaches the people who administer these machines at any hour, on any day, without going through a form first.
Release windows, told in advance
The studio tells us when a release window opens and we do not touch the underlying platform inside it. No maintenance lands on a night they are shipping.
The same people, not a second queue
Extended cover changes when we are reachable and how fast a fault is escalated. It does not hand the account to a different team, because there is not one.
Extended cover is agreed per account and written down before it applies. It changes when we are reachable and how quickly a fault is escalated — it does not create a second queue, a premium tier or a response time we have not signed. Everything on the support page is still true here.
What changed
- A build and an emulator sweep run at the same time on machines that cannot slow each other down, which is the property the old single box could not have.
- Every operating system the studio has published still boots, from the same image, fetched by the hash printed in its release notes.
- The no-tracking commitment is enforced by architecture — there is no third-party code on any machine — rather than by a privacy page.
- A release night has a number to call, and the platform underneath it is left alone until the window closes.
No performance percentages appear on this page. We publish figures we have measured under a named method, and these deployments are described by their architecture instead.
Ready when you are
Bring us a workload, not a shopping list
Tell us what the thing actually does and we will tell you which machines fit — including when the answer is a cheaper one than you asked for.
Shared from $4.99/moVirtual from $6.99/moBare metal from $35.99/mo