Blog

You need Python with freetype-py and fonttools, plus Ruby for the ID script:

pip install freetype-py fonttools

You can use any TTF or OTF files. I used the Fast Atkinson variant already installed on my system at ~/.local/share/fonts/. If you want the standard Atkinson Hyperlegible, download the TTFs from the Braille Institute and put them somewhere convenient.

The converter is lib/EpdFont/scripts/fontconvert.py. Reader fonts use --2bit --compress --pnum. Run it once per size per style:

cd lib/EpdFont/scripts

FONT_DIR="$HOME/.local/share/fonts"
for size in 12 14 16 18; do
  for style in Regular Bold Italic BoldItalic; do
    name="atkinson_${size}_$(echo $style | tr '[:upper:]' '[:lower:]')"
    python fontconvert.py \
      "$name" "$size" \
      "${FONT_DIR}/Fast_Atkinson_${style}.otf" \
      --2bit --compress --pnum \
      > "../builtinFonts/${name}.h"
  done
done

Adjust the font path and filenames to match whichever variant you have.

All built-in font headers are included through lib/EpdFont/builtinFonts/all.h. Add your new headers there:

#include <builtinFonts/atkinson_12_bold.h>
#include <builtinFonts/atkinson_12_bolditalic.h>
#include <builtinFonts/atkinson_12_italic.h>
#include <builtinFonts/atkinson_12_regular.h>
// ... repeat for 14, 16, 18

Font IDs are SHA-256 hashes of the generated headers, computed by build-font-ids.sh. Add a block for Atkinson to that script:

echo "#define ATKINSON_12_FONT_ID ($(
ruby -rdigest -e 'puts [
  "./atkinson_12_regular.h",
  "./atkinson_12_bold.h",
  "./atkinson_12_bolditalic.h",
  "./atkinson_12_italic.h",
].map{|f| Digest::SHA256.hexdigest(File.read(f)).to_i(16) }.sum % (2 ** 32) - (2 ** 31)'
))"
# ... repeat for 14, 16, 18

Then regenerate src/fontIds.h:

bash lib/EpdFont/scripts/build-font-ids.sh > src/fontIds.h

In src/main.cpp, inside the #ifndef OMIT_FONTS block, declare the font objects and families:

EpdFont atkinson12RegularFont(&atkinson_12_regular);
EpdFont atkinson12BoldFont(&atkinson_12_bold);
EpdFont atkinson12ItalicFont(&atkinson_12_italic);
EpdFont atkinson12BoldItalicFont(&atkinson_12_bolditalic);
EpdFontFamily atkinson12FontFamily(&atkinson12RegularFont, &atkinson12BoldFont,
                                   &atkinson12ItalicFont, &atkinson12BoldItalicFont);
// ... repeat for 14, 16, 18

Then register them with the renderer in setupDisplayAndFonts(), still inside #ifndef OMIT_FONTS:

renderer.insertFont(ATKINSON_12_FONT_ID, atkinson12FontFamily);
renderer.insertFont(ATKINSON_14_FONT_ID, atkinson14FontFamily);
renderer.insertFont(ATKINSON_16_FONT_ID, atkinson16FontFamily);
renderer.insertFont(ATKINSON_18_FONT_ID, atkinson18FontFamily);

In src/CrossPointSettings.h, extend the enum:

enum FONT_FAMILY { NOTOSERIF = 0, NOTOSANS = 1, OPENDYSLEXIC = 2, ATKINSON = 3, FONT_FAMILY_COUNT };

In src/CrossPointSettings.cpp, add an ATKINSON case to both switch statements, getReaderFontId() and getReaderLineCompression():

// getReaderFontId()
case ATKINSON:
  switch (fontSize) {
    case SMALL:        return ATKINSON_12_FONT_ID;
    case MEDIUM:
    default:           return ATKINSON_14_FONT_ID;
    case LARGE:        return ATKINSON_16_FONT_ID;
    case EXTRA_LARGE:  return ATKINSON_18_FONT_ID;
  }

// getReaderLineCompression()
case ATKINSON:
  switch (lineSpacing) {
    case TIGHT:   return 0.90f;
    case NORMAL:
    default:      return 0.95f;
    case WIDE:    return 1.0f;
  }

In src/SettingsList.h, add STR_ATKINSON to the fontFamily options list:

SettingInfo::Enum(StrId::STR_FONT_FAMILY, &CrossPointSettings::fontFamily,
                  {StrId::STR_NOTO_SERIF, StrId::STR_NOTO_SANS, StrId::STR_OPEN_DYSLEXIC, StrId::STR_ATKINSON},
                  "fontFamily", StrId::STR_CAT_READER),

In lib/I18n/translations/english.yaml:

STR_ATKINSON: "Atkinson Hyperlegible"

Then regenerate the I18n headers:

python scripts/gen_i18n.py lib/I18n/translations lib/I18n/

pio run --target upload

The font should now appear as "Atkinson Hyperlegible" in the reader's font selection menu. If you ever change any of the generated header files, re-run the ID script and rebuild. Otherwise the cached layout files in .crosspoint/ on the SD card will have mismatched IDs and the cache will need to be cleared.

I added Need for Speed: Most Wanted (2005) to Steam as a non-Steam game on my Deck. The repack included a _SteamDeckFix folder and instructions to set WINEDLLOVERRIDES"dinput8,d3dx9_26,d3dx9_43=n,b" %command%= as a launch option. I did all that, but the game refused to start.

Protontricks. Install it via Flatpak if you have not already:

flatpak install flathub com.github.Matoking.protontricks

Find your game's App ID and install the d3dx9 verb:

flatpak run com.github.Matoking.protontricks -l | grep -i "most wanted"
flatpak run com.github.Matoking.protontricks 2910532096 d3dx9

This installs all d3dx9 DLLs (versions 24 through 43) as native overrides in the game's Wine prefix. Ignore the wall of warnings, that is normal. After this, the game launched fine with no WINEDLLOVERRIDES needed.

If you are fighting with older DX9 games on the Deck, skip the launch option approach and go straight to Protontricks.

BIP38 is a standard for encrypting Bitcoin private keys with a passphrase. Instead of storing a raw private key (which anyone who sees it can use), you store an encrypted version that requires a password to unlock.

The encrypted key is a 58-character Base58 string starting with "6P". Without the password, the underlying private key is cryptographically inaccessible.

But, this is the interesting part, not everything in a BIP38 key is encrypted.

A decoded BIP38 key has this structure:

Bytes 0-1:   Prefix (identifies the key type)
Byte 2:      Flag byte (compression settings)
Bytes 3-6:   Address Hash (4 bytes, NOT encrypted)
Bytes 7-42:  Encrypted data

That Address Hash is crucial. It's the first 4 bytes of SHA256(SHA256(bitcoin_address)), stored in plaintext within the encrypted key.

Its original purpose is verification during decryption. Ff you enter the wrong password, the derived address won't match this hash. But for my purposes, it allowed me to verify that a recovered key matched a known Bitcoin address without ever knowing the password.

Bitcoin uses Base58Check encoding, which appends a 4-byte checksum to encoded data. Any transcription error—a single wrong character—produces an invalid checksum. The probability of a random error still passing? About 1 in 4.3 billion.

The Base58 alphabet is worth noting:

123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

Missing: 0 (zero), O (capital O), l (lowercase L), I (capital I). These were deliberately excluded to reduce visual ambiguity. A thoughtful design choice that nonetheless failed to account for my friend's handwriting.

I had a candidate key with a valid checksum. But did it belong to the expected Bitcoin address?

This is where the unencrypted Address Hash becomes useful:

def key_matches_address(bip38_key, bitcoin_address):
    # Extract hash from key (bytes 3-6)
    key_hash = base58_decode(bip38_key)[3:7]
    
    # Calculate expected hash from address
    addr_bytes = bitcoin_address.encode('utf-8')
    addr_hash = sha256(sha256(addr_bytes))[:4]
    
    return key_hash == addr_hash

The hashes matched. Mathematical confirmation that my recovered key corresponded to the known address, without any password or blockchain access required.

The handwritten notes contained a second BIP38 key. I applied the same process—this time, two characters were completely illegible, requiring a search through 58 × 58 = 3,364 combinations.

One candidate emerged with a valid checksum. But the Address Hash check revealed something unexpected: this key belonged to a different Bitcoin address entirely.

The writer had apparently documented two separate wallets. The second address remains unknown until decryption.

For anyone facing a similar problem, here's the core code.

import hashlib

BASE58 = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"

def base58_decode(s):
    num = 0
    for c in s:
        num = num * 58 + BASE58.index(c)
    result = []
    while num > 0:
        result.append(num % 256)
        num //= 256
    result.reverse()
    return bytes([0] * (len(s) - len(s.lstrip('1'))) + result)

def double_sha256(data):
    return hashlib.sha256(hashlib.sha256(data).digest()).digest()

def verify_checksum(key):
    decoded = base58_decode(key)
    payload, checksum = decoded[:-4], decoded[-4:]
    return checksum == double_sha256(payload)[:4]

def get_address_hash(bip38_key):
    """Extract address hash from BIP38 key (bytes 3-6)."""
    return base58_decode(bip38_key)[3:7]

def calculate_address_hash(bitcoin_address):
    """Compute expected hash from a Bitcoin address string."""
    return double_sha256(bitcoin_address.encode('utf-8'))[:4]

def key_matches_address(bip38_key, bitcoin_address):
    """Check if key belongs to address, without needing the password."""
    return get_address_hash(bip38_key) == calculate_address_hash(bitcoin_address)

def search_with_insertion_and_replacement(key_57):
    """Search for valid 58-char key by inserting one char and replacing one."""
    for fix_pos in range(len(key_57)):
        original = key_57[fix_pos]
        for fix_char in BASE58:
            if fix_char == original:
                continue
            modified = key_57[:fix_pos] + fix_char + key_57[fix_pos+1:]
            
            for ins_pos in range(len(modified) + 1):
                for ins_char in BASE58:
                    candidate = modified[:ins_pos] + ins_char + modified[ins_pos:]
                    if verify_checksum(candidate):
                        return candidate, fix_pos, fix_char, ins_pos, ins_char
    return None

• BIP-0038 Specification - The encrypted private key standard
• Base58Check Encoding - Bitcoin Wiki
• Learn Me a Bitcoin: Base58 - Visual explanation of the encoding
• bitaddress.org - Open source tool for offline key operations

The keys were recovered. The funds were moved to more robust storage.

A few observations from the experience:

The Base58Check checksum made this recovery possible. Without it, I would have needed to test each candidate against the blockchain, dramatically slowing the process and requiring network access.

The unencrypted Address Hash in BIP38 is an underappreciated feature. It enables verification without secrets. Useful not just for password checking, but for confirming key-address relationships during recovery.

And finally: if you're storing cryptographic keys on paper, consider using a typewriter. Or at least print them. The human hand, whatever its other merits, was not optimised for producing unambiguous alphanumeric strings. Also it's in your own interest into not oversharing your wallet keys. So it was fun!

Here is what I discovered during my time in the Nix monastery:

The system breaks. Not occasionally. Not rarely. Constantly. And surely your working machine is still fine but your configs to update your machine might be outdated. One does not simply run nixos-rebuild and proceed with one's day. One runs the rebuild, receives an error, adjusts the configuration, runs it again, receives a different error, adjusts again, runs again. The rebuild/fix/rebuild/fix cycle becomes the primary experience of using the system.

I have broken Arch Linux exactly once in five years. NixOS breaks before I even attempt an update. Something always requires changing in the configuration before the build will consent to run.

The error messages deserve special mention. They emerge from the machine like communiques from a dimension where clarity is considered impolite. Twenty lines of stack traces referencing files in /nix/store/ with names that look like someone rolled their face across a keyboard, and then at the very bottom, almost as an afterthought: "logseq has been removed."

The package you use daily? Gone. No alternative suggested. No migration path offered. Simply… removed due to lack of maintenance. As if the system itself had decided you needed practice in adapting to sudden loss.

There is a saying about NixOS that circulates among those who have tried it: it makes hard things easy and easy things hard. This is, in my experience, precisely correct.

Want to define your entire system state in a version controlled file? NixOS handles this elegantly. Want to quickly install a package so you can get on with your actual work? Prepare to learn why your particular use case requires an overlay, or why the package exists but is marked broken, or why you need to add an additional input to your flake, or why the version you need conflicts with something else in your dependency tree.

And then there are proprietary binaries. Corporate software. Anything not packaged for NixOS. This is where the immutable dream collides with the messy reality of software distribution.

On a traditional Linux distribution, you download a binary, make it executable, and run it. On NixOS, you enter a world of workarounds: steam-run, buildFHSUserEnv, patchelf, autoPatchelfHook, manually specifying interpreters and library paths. The StackExchange thread documenting these methods reads like a catalog of incantations, each with its own trade-offs and failure modes. Yes, this is the cost of running an immutable system. But when running a downloaded binary requires consulting documentation and selecting from multiple incompatible approaches, something has gone wrong with the user experience.

A computer, at the end of the day, should be a tool for getting work done. This seems obvious, yet NixOS has a way of inverting this relationship. The computer becomes the work. The configuration becomes the project. The tool demands more attention than the tasks you acquired the tool to accomplish.

My own dream was modest: atomic project directories with nix-shell, containing all dependencies, activated automatically when I enter the directory. I already use direnv quite effectively for this. The NixOS vision promised something even more sophisticated, a world where each project carries its complete environment specification, perfectly reproducible across machines and time.

The reality? When I start a new project, I want to get it running as soon as possible. I do not want to spend an afternoon figuring out how to declare dependencies in Nix. I do not want to debug broken overlays. I do not want to discover that some package I need will never be officially maintained because it fell on the wrong side of a political dispute within the community. (Xlibre, the Firefox fork, provides a useful example of how ideology can trump utility in package inclusion decisions.)

More and more of my actual work lives in Emacs or on the shell. Once a system is configured and running, I have little need to tinker with it. The operating system should fade into the background, a substrate upon which real work occurs. NixOS refuses to fade. It demands constant attention, constant maintenance, constant appeasement.

Here is where the story becomes genuinely strange.

NixOS has developed what might charitably be called an "intense political culture." The project has been convulsed by governance disputes that make ordinary open source drama look quaint by comparison.

In April 2024, a faction proposed creating dedicated voting seats for specific demographic categories on a project committee. Some contributors suggested this might constitute discrimination against groups not granted such seats. The response was not a measured discussion of competing values. The response was what project leaders explicitly called a "purge." Contributors were banned. The founder, Eelco Dolstra, was pressured to sign an abdication letter that others had drafted for him.

Now, I want to be careful here. Reasonable people can disagree about representation policies. The question of how to make open source communities more welcoming admits multiple answers, and thoughtful people hold different views.

What seems less reasonable is labeling everyone who disagrees with your specific implementation a "Nazi" and removing them from the project. The word has a meaning. It refers to adherents of a specific ideology responsible for industrial genocide. Using it to describe someone who thinks committee seats should not be allocated by demographic category does not clarify anything. It obscures. It transforms a policy disagreement into an accusation of monstrous evil, which conveniently exempts one from having to engage with the actual arguments.

This rhetorical move, I should note, works equally well when deployed by any faction. Once you have established that your opponents are not merely wrong but wicked, any action against them becomes not just acceptable but morally required. The technique is old. It is effective. It does not produce good software or healthy communities.

The situation continued deteriorating into 2025. In September, five of seven moderators resigned, accusing the Steering Committee of interference. Or perhaps the Steering Committee was attempting to address problems with moderation bias. The accounts diverge depending on who you ask. LWN covered the fallout, and the commentary reveals just how deep the divisions run. What seems clear is that a Linux distribution has become a venue for political conflict that has little to do with package management, and the fallout is not producing better software.

Here is what makes all of this so frustrating:

The idea of NixOS is genuinely excellent. An immutable, declarative operating system. Define your reality in a configuration file. Reproduce it anywhere. Roll back mistakes effortlessly. This is not foolish. This is, in fact, exactly what many of us want from our computers.

I should note: I love immutable, declarative systems in the right context. On the server side, systems like Talos and Bottlerocket Linux demonstrate the genuine value of this approach. When you need security, reproducibility, and minimal attack surface, declaring your system state and preventing runtime drift makes perfect sense. These systems work because servers have constrained, well defined purposes. You know in advance what the machine needs to do.

A personal workstation operates under different constraints. You do not always know what you will need tomorrow. A new project appears. A client requires some obscure tool. You want to experiment with a technology you read about this morning. The freedom to simply install something and proceed with your work has real value. NixOS trades this freedom for theoretical reproducibility, and the exchange rate is unfavorable for daily use.

The execution has problems. Significant, practical problems that make daily use a trial rather than a pleasure.

The political situation introduces additional uncertainty about the project's future direction and whether it can maintain the contributor base necessary for a healthy ecosystem.

And yet nothing quite like NixOS exists elsewhere. You can approximate its features: BTRFS snapshots for rollbacks, git repositories for dotfiles, aconfmgr for declarative package management, Docker for development environments. These solutions work. They do not require learning a pure functional configuration language or monitoring mailing lists for political developments.

But they are not the same thing. They are workarounds, not the integrated vision NixOS promises.

I find myself wishing for a project with NixOS's conceptual ambition, maintained by people capable of distinguishing between technical disagreements and moral emergencies, documented clearly enough that the Arch Wiki does not remain the superior reference for basic tasks. Something perhaps built on Gentoo's foundations, for those who appreciate that sort of thing, but with governance that prioritizes building software over enforcing orthodoxies.

Such a project does not appear to exist yet. Perhaps someone will fork the technology and rebuild the community on different foundations. Perhaps someone like DHH will stumble into this space and create enough noise to force a reckoning. Perhaps a new project will emerge that captures the declarative dream without the accompanying dysfunction as Ubuntu did back then with Debian.

Until that day, the NixOS concept remains in a peculiar limbo imho: too broken for daily use, too unique to ignore entirely, too politically fraught to recommend without extensive caveats. It is not ready for personal use. Perhaps it will be someday. Perhaps not. And I do have my doubts about companies really using it besides as a Homebrew alternative for a package manager on Mac OS.

So where does this leave me? Not necessarily back to Arch, though the Arch Wiki remains one of the finest pieces of technical documentation ever assembled (and, ironically, often explains NixOS tasks better than NixOS documentation does).

My time with NixOS taught several lessons again:

Reproducibility has value, but not at the cost of hours lost to rebuilds and debugging. Error messages should communicate what went wrong, not recite the internal state of a lazy evaluation engine. A community more interested in political purity than functional software will produce neither purity nor functional software. Sometimes the boring solution (Arch with BTRFS snapshots, version controlled dotfiles, containerized development environments) accomplishes most of the goal with a fraction of the friction.

What I actually want is simple: a configuration file that describes my system for easy setup. Something that installs my packages and applies my dotfiles when I set up a new machine. This should not be revolutionary. But there are already too many dotfile managers out there. This should not require learning a pure functional programming language. This should not force me to engage with political disputes about which software is ideologically acceptable.

Do I recommend NixOS? Not for daily use on a machine where you need to get work done. Do I recommend paying attention to NixOS? Absolutely. Something interesting is happening there, even if the interesting thing is primarily a demonstration of how technical projects can be consumed by non-technical conflicts.

The declarative, immutable operating system remains a worthy goal. The path to achieving it may require starting fresh, with different governance, different priorities, and perhaps a willingness to learn from NixOS's mistakes rather than repeating them.

Until then, there are distributions that simply work. There is the accumulated wisdom of decades of Unix documentation.

It was around 1887 (give or take a few astral fluctuations) when three gentlemen of dubious respectability founded the Hermetic Order of the Golden Dawn in London. One of them, Dr. William Wynn Westcott, was a coroner by trade and an occultist by disposition, which tells you something about Victorian England that the tourism boards prefer not to mention.

Westcott claimed the foundational documents of the Golden Dawn had been transmitted to him from a mysterious Fräulein Sprengel in Germany, representing an even older occult order. Whether this German connection actually existed or was (as seems rather more likely) a convenient bit of mythmaking to give the whole enterprise a patina of Ancient Authenticity™, we shall probably never know. The universe is not in the habit of answering such questions directly.

Westcott has been suggested as the inventor of Enochian Chess, but some (including Westcott himself) claimed the documents describing it were among those supplied from that older German group. The authorship remains unclear, at least partially because the Golden Dawn considered Enochian Chess to be a secret teaching. And secrets, by their nature, tend to be incompletely transmitted.

"Enochian" refers to the Biblical patriarch Enoch, father of Methuselah, who "walked with God" (Genesis 5:24) and "was taken from this life, so that he did not experience death" (Hebrews 11:5). In occult tradition going back to Queen Elizabeth I, Enoch is considered a source of hidden mystical knowledge. The variant was also called Rosicrucian Chess, after the Order of the Rosy Cross, a continental mystic fraternity from which the Golden Dawn claimed descent.

More specifically, the name refers to the magical system of Dr. John Dee, Elizabeth's court astrologer, who spent years conversing with what he believed were angels through a scryer named Edward Kelley.

Kelley was either a genuine medium, a spectacular con artist, or (and pay attention here, because this is the important bit) both at once. Reality tunnels, you understand, are not mutually exclusive. The angels gave Dee an entire language, a hierarchy of spirits, and enough diagrams to wallpaper a cathedral. Dee's diaries, preserved in the British Museum, remain objects of fascination and controversy four centuries later.

The Golden Dawn took this material and did what occultists always do: they systematized it, cross-referenced it with everything else (Kabbalah, Tarot, astrology, Egyptian mythology, and probably their breakfast menus), and eventually decided it needed a game.

Enter Enochian Chess: a variant designed for two or four players, wherein each player (or team) commands pieces corresponding to one of the four classical elements (Fire, Water, Air, and Earth). The pieces themselves were identified with Egyptian god-forms: Osiris as King, Isis as Queen, Horus as Knight, Aroueris as Bishop, and Nephthys as Rook.

Documentary evidence for the game's existence (in the form of a Golden Dawn paper dating from no later than 1897) has come to light, but no historical documents discovered so far have given the complete rules for gameplay.

Nobel Prize-winning poet William Butler Yeats (yes, that Yeats) records in his memoirs that in 1894 he played "a curious form of chess at which there should be four players" with two other Golden Dawn members. One was MacGregor Mathers, a founding father of the order.

Westcott apparently never finished the rules. Mathers finalized the game around 1890, writing what Israel Regardie later called the "Official Ritual" describing piece movements. But Mathers was known for many things beyond rule-writing, including feuds with Aleister Crowley and playing Enochian Chess with what he called an "invisible partner," a spirit who occupied the empty chair across the board.

Joseph Hone, Yeats's biographer, described it thus: Mathers would shade his eyes with his hands and gaze at the empty chair before moving his partner's piece.

Let that image settle in your mind. A man in late Victorian London, playing a chess game derived from angelic communications, with a ghost as his teammate.

Was Mathers actually communing with spirits? Was he accessing his unconscious? Was he just very good at entertaining himself? I don't know. More interestingly, I'm not sure anyone can know from the outside.

In his book The Golden Dawn, Regardie provides a description of the boards and pieces, gives two arrays, and explains the occult methodology for deriving others. He attributes the movement rules to Mathers's "Official Ritual." But Regardie's publication lacked complete gameplay rules. For decades, people stared at these fragments, tantalized.

Which brings us to Chris Zalewski, who spent years in the 1980s reconstructing coherent rules from Regardie's publications, original manuscripts, and the Indian game Chaturanga (upon which the variant was based). When Regardie visited New Zealand in 1983, he was "astounded at the development to which Chris had taken the game."

The result was Enochian Chess of the Golden Dawn, first published in 1994, which remains the definitive text.

The magical practices of the Golden Dawn are of no concern to the chess variant community. So says the Chess Variants website, and they're not wrong. You can play Enochian Chess purely as a game, ignoring every mystical attribution, and still find it strategically fascinating.

But isn't it more fun to know the weird stuff? I think so. Your mileage may vary.

Enochian Chess can be played on a standard FIDE 8x8 board, though Golden Dawn members did not use orthodox equipment. Play is facilitated by making the corner spaces at least twice as large as other squares, because those corners (the "throne squares") have special properties.

The four throne squares are a1, a8, h1, and h8. Remember them. They'll matter.

Divide the board conceptually into four quadrants: the fiery red of the Fire angle, the watery blue of the Water angle, the airy yellow of the Air angle, and the earthy black of the Earth angle.

Place four armies upon this board, one in each corner. Each army consists of: a King (Osiris), a Queen (Isis), a Knight (Horus), a Bishop (Aroueris), a Rook (Nephthys), and four special Pawns.

The Teams

Teams are always fixed: Blue and Black versus Red and Yellow. There is no individual winner. If the blue army is eliminated but black captures both enemy kings, the blue-black team has won.

Teammates are normally forbidden from capturing each other's pieces (with one spectacular exception we'll get to). Allied pieces don't threaten each other. Blue and black kings can be adjacent without giving check.

Play proceeds clockwise around the board.

The Throne Square Problem

In all eight possible starting arrays, each throne square is occupied by two pieces: a King and one other piece (which piece depends on the array). This double occupancy is only allowed at the start. Once either piece moves, only one piece may sit on that throne square for the rest of the game.

And here's the brutal part: both pieces are captured if an enemy piece moves into a throne square while it's still doubly occupied.

Your most important piece starts the game sharing space with another piece, and if you don't move fast enough, you lose both. This is not a game designed for the strategically timid.

The Eight Arrays

There are eight different starting configurations, each named by elemental combination: "Air of Air & Water," "Fire of Fire & Earth," etc. The array determines which piece shares the throne with each King.

Regardie indicated sixteen possible arrays, but Zalewski concluded there are functionally only eight, since pairs like "Air of Fire" and "Air of Earth" have identical piece arrangements.

The choice of array also connects to which elemental board you're theoretically using:

• Air board: Yellow moves first
• Fire board: Red moves first
• Water board: Blue moves first
• Earth board: Black moves first

If playing on Fire or Earth boards, only "…of Fire & Earth" arrays may be selected. On Air or Water boards, only "…of Air & Water" arrays.

The Pieces

The King (Osiris) moves one square in any direction, same as standard chess. But kings are not mated in Enochian Chess. They are captured. You must declare "check" when threatening an enemy king. A king in check MUST be moved, even if that means putting it in check again. You may move another piece only if the king is completely blocked by friendly pieces.

The Queen (Isis) moves by leaping exactly two squares in any direction, orthogonal or diagonal, jumping over intervening pieces like an alibaba. She controls only 16 of 64 squares from any position, all of her own color.

(The Chess Variants essayist speculates that in an earlier version the queen may have moved like a ferz, one square diagonally, and the bishop like an alfil, leaping two squares diagonally. But Regardie and Mathers both support Zalewski's leaping queen. Take your pick of which reality tunnel to inhabit.)

The Rook (Nephthys) moves orthogonally as in standard chess. No castling.

The Bishop (Aroueris) moves diagonally as in standard chess.

The Knight (Horus) behaves exactly as in standard chess.

The Pawns (the four Sons of Horus) move one square forward only, capturing diagonally forward. "Forward" differs by color: Yellow toward row 1, Blue toward column A, Red toward row 8, Black toward column H. No initial double step, no en passant.

Pawn promotion has restrictions: it only occurs after a player has lost at least one pawn. If all four survive, promotion must be delayed. And a pawn may only promote to its type: Pawn of Rook becomes Rook, Pawn of Knight becomes Knight.

When A King Falls

When a king is captured, all pieces of that color become frozen. They remain on the board but cannot move, don't threaten other pieces, and cannot be captured. They simply sit there as blocking terrain.

The game ends when both kings of one alliance have fallen.

The Concourse

Opposing bishops are bound on opposite colors, so they can never capture each other normally. The Concourse of Bishoping is the exception.

By completing a 2x2 square formation involving all four bishops, the moving bishop captures all three others. This is similar to the "triumph of the boat" in Chaturanga for Four Players. It's the rare case where capturing a teammate's piece is legal.

Unlike triumph of the boat, the concourse can only happen at five positions: the central squares (c4, c5, d4, d5) or the four corner clusters (b2-b3-c2-c3), (b6-b7-c6-c7), (f2-f3-g2-g3), (f6-f7-g6-g7).

The Concourse of Queens works identically. Bishops and queens cannot be combined; all four pieces must be the same type.

Here's a question that has bothered philosophers since Plato: What is a game for?

The standard answer (entertainment, passing time, competition) explains chess clubs but not Enochian Chess. Nobody constructs a variant with Egyptian god-forms, throne-seizure mechanics, and concourse captures just to pass time.

Then again, maybe they do. Fun is underrated as a motive.

The Golden Dawn, however, had a specific additional answer: Enochian Chess subsumes other passive systems of divination and has "powerful prophetic properties."

Here's how divination worked: before the game, a question was formulated. A special piece called Ptah (the creative principle, "the Opener") was placed on a square corresponding to the query's nature. The game was played, and the outcome interpreted as the oracle's answer.

Think about what this means. Unlike Tarot, where cards are drawn randomly, or the I Ching, where yarrow stalks determine hexagrams, Enochian Chess divination is active. The querent participates. Strategy matters. Skill affects outcome.

The Golden Dawn claimed you could use the game "for practical ACTIVE divination, to alter and influence events as well as to simply predict."

Bold claim. Does it work?

I have no idea. Neither do you. But here's what I can say about the game's benefits, regardless of your metaphysical commitments:

The mechanics create situations you won't find elsewhere. The leaping queen. The throne vulnerability. The frozen armies becoming terrain. The concourse that can take your own teammate's piece. The prisoner exchange negotiations. You don't need to believe in anything to enjoy complex four-player dynamics.

The fixed alliance structure with throne-seizure, prisoner exchange, and withdrawal creates a simulation of complex multi-agent relationships. You might capture an enemy king, then be offered a prisoner exchange. Do you take it? Your ally might seize your throne if your king falls. Is that good or bad? These decisions model strategic thinking that most games don't require. You're coordinating with allies whose interests partially but not completely align with yours. Sound like anything in real life?

The Concourse can only happen at five specific positions. Four pieces from four players must converge into a 2x2 formation, and whoever completes it captures all three others, including their teammate's. You learn to see these configurations forming. You develop peripheral awareness of what's developing across the whole board, not just your immediate tactical concerns. Whether this trains you to see "elemental configurations" in daily life or just makes you better at complex board games, either way it's useful.

Mathers played with an invisible partner. Yeats reported games conducted with "Mathers, his wife, and a spirit." Was Mathers communing with actual disembodied intelligence? Accessing deeper unconscious layers? Randomizing moves through a process that felt like guidance? I don't know. The experience of sitting across from an empty chair, waiting for the move to become clear, does something to consciousness. Whether "something" involves angels, archetypes, or neurology is a question I leave to specialists.

What can be said: the game changes the player. It trains attention. It forces multi-perspectival thinking. It offers structured engagement with uncertainty that is neither passive reception nor anxious control.

And it's fun. Never discount fun.

Here's something that might surprise you: people are still talking about Enochian Chess.

A Chess.com forum thread from 2012 (still occasionally revived) contains this observation: "Enochian Chess is the Occultist's Chess. It can be used both for Competition AND Divination."

Someone replies: "I just purchased my 4 boards. Just currently learning how to actually play it."

And then the inevitable lament: "If someone set up a website to play Enochian chess online, I would 100% sign up."

The Chess Variants community has taken notice too. Their essay strips away mystical elements to present Enochian Chess as pure game mechanics, concluding diplomatically: "Golden Dawn practitioners may take this essay to task for the method of presentation used, whereby the mystical nature of Enochian chess has been stripped away wherever possible. No offense is intended. Nor is it the design of this essay to endorse or refute anyone's belief system. Enochian Chess has been submitted to the Chess Variant Pages so that it may take its rightful place in the broader outline of chess variant history."

This is exactly right. The game belongs to chess history as much as occult history. It sits alongside Star Trek's Tridimensional Chess and Gygax's Dragonchess as a variant born from a particular subculture.

Steve Nichols has been supplying Enochian Chess sets, books, and software since 1982, starting with support from Israel Regardie himself and a grant from the Prince's Trust. His Windows software allows one to four players to engage without constructing elaborate boards or carving Egyptian deities.

Nichols published a trilogy through Mandrake Press: Rosicrucian Chess of the Golden Dawn includes Moina Mathers's Alpha et Omega papers, play strategy, and Active divinatory methods. Celtic Chess presents Yeats's sixteen-board sub-elemental extension, developed with Maud Gonne and George Pollexfen from a notebook dated December 1898. Khemetic Chess (Hypermodern Magick) explores recent variants, Crowley's relationship to the system, and "No Self" Enochian Chess.

Modern practitioners have proposed Looney Pyramid adaptations, DIY approaches with "two cheapo chess sets and colored electrical tape," digital implementations, simplified two-player versions, and four-dimensional expansions.

Does the game work? As divination? I genuinely don't know. As entertainment? Absolutely. As training for complex multi-agent thinking? Yes. As something that changes how you perceive pattern and possibility? The people who play regularly say so. Whether that change is "magical" or "psychological" or "just getting better at a complicated game" depends on vocabulary preferences more than observable facts.

All right. You're either intrigued, confused, or both. Now you want to actually do something. Here's how.

The Chess Variants website confirms: "Enochian chess can be played on the 8x8 board of FIDE chess." You need two standard chess sets (thrift stores work), colored tape or paint (red, yellow, blue, black), a printed board diagram with enlarged corners, and a rules summary (free at chessvariants.com). Color-code your pieces by element. Mark your corners larger. You're playing. The traditional equipment (paper stand-ups with Egyptian god designs, four-triangle squares painted in elaborate color schemes) is beautiful but unnecessary for learning mechanics.

Alternatively, Steve Nichols' software makes the game "immediately playable" without physical construction. This solves the biggest problem: finding opponents who know the rules.

Or go full immersion: purchase Zalewski's book, construct proper boards, paint attributions, create god-form pieces. This takes months but is, in Golden Dawn tradition, part of the training. Or just use colored tape. The game doesn't care.

Pick "Air of Air & Water" for first games. It's most commonly illustrated. Remember: Fire or Earth board associations require "…of Fire & Earth" arrays. Air or Water boards require "…of Air & Water" arrays.

For the traditional starting procedure: select elemental board (determines who moves first), select compatible array, players throw dice and from highest to lowest each chooses their color. The Chess Variants essayist notes this seems odd: "The player who won the die roll gets the privilege of choosing which army to operate (and whether or not that player gets the first move), but the 'winner' is then at the mercy of others in regards to choosing a teammate." Poor game design? Or deliberate teaching about limits of individual agency? With the Golden Dawn, it's genuinely hard to tell.

Start with two players. Each controls two allied elements. Each color still takes its own turn, so you alternate. Graduate to four when you have friends who've learned the system. Or just play all four positions yourself while conversing with invisible partners. Mathers did.

Do you have to believe in magic? No. "The magical practices of the Golden Dawn are of no concern to the chess variant community." Many play Enochian Chess purely as an interesting four-player variant. The throne-seizure rules, concourse captures, and frozen armies create emergent situations unavailable elsewhere. The Egyptian gods are flavor. The game is the thing. (Though if you find yourself having unusually vivid dreams after extended play, or noticing "concourse formations" in workplace politics, don't say you weren't warned. Or don't attribute it to anything supernatural. Your call.)

Where to find opponents: Chess.com forums, Reddit's r/occult and r/GoldenDawn, chess variant communities, local esoteric study groups, or yourself with an invisible partner.

First games will be confusing. The Queen's leap takes adjustment. Four armies feels chaotic. Frozen pieces create strange board states. Fifth game: patterns emerge. Tenth game: you have opening preferences. Twentieth game: you understand why this has fascinated people for over a century. Whether that fascination is "mystical insight" or "appreciation for elegant game design" or "both" is entirely up to you.

You've learned the rules. You've played some games. The Queen's leap no longer surprises you. You've watched for concourse formations, protected your throne, maybe seized an ally's. Now you want to know what's underneath.

You don't have to look. The game works fine without it. But if you're the kind of person who wants to know why the manual has extra chapters, read on.

The Chess Variants website describes original equipment: "Enochian chess was traditionally played on one of four specially constructed boards. Each board represented one of the classical elements. Each square of each board was divided into 4 triangles, which were painted one of four different colors. These triangles were not game spaces themselves, merely components of the larger square cells used to play the game. Although confusing to the eye, an Enochian chessboard is functionally identical to a FIDE 8x8 board."

Read that again. Each square divided into four triangles. You're not looking at a flat surface. You're looking down at a truncated pyramid.

In Golden Dawn conception, each of the 64 squares is the apex of a four-sided pyramid extending into dimensions that ordinary geometry doesn't acknowledge. Each triangular face carries different attributions: the element of the board (red/Fire, blue/Water, yellow/Air, black/Earth), the element of the angle (the quadrant), a color from column position via Tetragrammaton formula, and a color from rank position via the same formula. The truncated top was left blank or marked with Spirit.

Every square carries four elemental attributions simultaneously, plus Spirit. Moving a piece isn't just changing location. It's navigating interpenetrating elemental forces. Or it's just moving a piece. Depends on how you want to think about it.

The four Hebrew letters YHVH (Yod-Heh-Vav-Heh) provide structure: Yod = Fire, Heh = Water, Vav = Air, Heh final = Earth. Columns and ranks cycle through this pattern. Every square has column and rank attributions combining with board and angle attributions. Fire of Water of Air of Earth. Sixty-four unique elemental combinations.

The traditional pieces were generally stiff paper stand-ups much like the paper dolls and paper toy soldiers of the era. Each major piece had a unique name and design taken from Egyptian mythology and all the pieces were painted in four-color paint schemes. Each mounted on a base colored for affiliation. Backs painted solid by type: Kings white, Knights red, Queens blue, Bishops yellow, Rooks black. Color-coding served practical and symbolic purposes. You could identify piece type from behind. Each piece carried elemental signature interacting with square attributions.

Interestingly, original boards did not include Enochian letters from John Dee's tablets, despite the game's name. Why? Because the chessboards derive from "Servient Squares" of the Angelic Watchtowers with binding structural elements removed. Without those binding forces, placing all Enochian letters would invoke "slightly chaotic" unbound angelic forces. The game was considered dangerous enough without that variable. (Or they just thought it looked cleaner. Hard to say with Victorians.)

Those five positions where Concourse can occur? They're not arbitrary. The central squares and four corner clusters represent specific configurations where elemental forces can combine catastrophically. Four pieces of the same type, from four different armies, converge into a 2x2 formation at these positions. The moving piece captures all three others. Alliances don't matter. Intentions don't matter. The configuration produces the effect. This is the Golden Dawn teaching: certain patterns have intrinsic power regardless of who creates them. It's also just good game design. Interesting emergent mechanics from simple rules. Both can be true simultaneously.

According to Zalewski, four approaches to construction: minimal (colors only, safest for beginners), Regardie's method (omit truncated pyramid top, four triangular faces carry attributions, center left plain), spirit-bound (add Spirit symbol to top, binding elemental forces), and full attribution (paint all planetary, zodiacal, and geomantic symbols, each board becomes complete magical diagram). Most use the first or second approach. The game works fine mechanically. But knowing the deeper structure exists changes how you think about what you're doing. Or doesn't. Your reality tunnel, your choice.

Even for pure materialists: the pyramid square system encodes multiple variables into single locations. Board identity (1 of 4), angle identity (1 of 4), column position (1 of 8), rank position (1 of 8). That's 4 × 4 × 8 × 8 = 1,024 unique combinations across 256 positions (64 squares × 4 boards). Modern game designers call this "information density." The Golden Dawn called it "correspondences."

When you capture an opponent's Knight on the Watery part of the Fiery angle of the Earth board, you're asserting dominance over a specific elemental configuration. Or you're just taking a piece. Or both.

If you want deeper understanding: learn Tetragrammaton correspondences, understand column/rank cycles, know which angle you're in, consider how pieces interact with square attributions. A Fire piece on a Water square may be weakened. An Earth piece on an Earth square may be strengthened. These correspondences can inform strategy. Or ignore all this and just play. The pieces don't actually care about their mythological names. They move the same either way.

What you make of the structure is up to you. The Victorians who designed this thought it mattered enormously. Modern chess variant enthusiasts think it's interesting historical flavor. Practicing occultists think it's technology disguised as entertainment. All three groups play the same game.

Whose move is it?

Whether anything is underneath besides wood and paint is your call. Whether the invisible partner is real is your call. Whether the pyramid squares matter is your call.

The game works either way.

If you’ve read this far, thanks for letting me confuse you. I don’t think my introduction was enough to make you fully understand the game, to be honest. Especially if you just read it and didn't actually tried to play it. And there are different varieties of the game itself too. So yes, the title was a lie.

• Zalewski, Chris. Enochian Chess of the Golden Dawn. Llewellyn Publications, 1994. Amazon
• Regardie, Israel. The Golden Dawn. Llewellyn Publications, 1937/1989.
• Nichols, Steve. Rosicrucian Chess of the Golden Dawn. Mandrake Press, 2017.
• Nichols, Steve. Celtic Chess. Mandrake Press, 2019.
• Nichols, Steve. Khemetic Chess. Mandrake Press, 2022. Mandrake
• Chess Variants: Enochian Chess
• Chess.com Forum: Enochian Chess Discussion
• BoardGameGeek: Enochian Chess
• Wikipedia: Enochian Chess
• Looney Pyramids Wiki: Rosicrucian Chess