Document Gotek 3D-printed case and relocated TOS switcher on Low machine

- Release pushed to 4 Dec 2026 at 189.99 EUR
- Workbench 3.1 confirmed, other versions via USB
- Emulation: A1200/A500/A600/CD32, OCS/ECS/AGA/RTG
- 25 games incl. new titles, save slots
- WHDLoad + floppy/HD/CD-ROM sideloading
- 4x USB-A, third-party and legacy peripherals
- Display options, box contents, AC adapter note
- Add official + press sources

.eleventyignore

@@ -1,5 +1,3 @@
-stefankoelle/
-timecapsule/
 scripts/
 .tmp/
 

AGENTS.md

@@ -1,4 +1,4 @@
-# AGENTS.md — moonweb-site
+# AGENTS.md, moonweb-site
 
 ## Projektuebersicht
 
@@ -23,8 +23,8 @@ Monorepo fuer 6 statische Websites unter www.moonweb.org + stefankoelle.de, basi
 
 ### Andere Sites (nicht im Monorepo)
 
-- 28k8.moonweb.org — 90er BBS/Scene-Archiv
+- 28k8.moonweb.org, 90er BBS/Scene-Archiv
-- buildbroken.moonweb.org — .NET Open Space Blog Archiv
+- buildbroken.moonweb.org, .NET Open Space Blog Archiv
 
 ## Dateistruktur
 
@@ -101,23 +101,23 @@ npm run build:moonweb           # Moonweb + Timecapsule (fuer Deployment)
 
 ## Design-Prinzipien
 
-1. **Header konsistent** — Identischer Site-Switcher auf allen Home-Sites
+1. **Header konsistent**, Identischer Site-Switcher auf allen Home-Sites
-2. **Content flexibel** — Detailseiten duerfen eigenes Layout haben
+2. **Content flexibel**, Detailseiten duerfen eigenes Layout haben
 3. **Accent-Farben:** hub=#3b6ea5, infra=#99333A, smarthome=#1f8a8a, code=#3E5098, retro=#8a6d3b (inlined in base.njk)
-4. **Englisch** — Alle Sites komplett auf Englisch
+4. **Englisch**, Alle Sites komplett auf Englisch
-5. **Keine Analytics** — Keine Tracking-Tools
+5. **Keine Analytics**, Keine Tracking-Tools
-6. **Sensible Daten** — Infra-Content wird manuell redigiert (keine IPs, Keys, Passwoerter)
+6. **Sensible Daten**, Infra-Content wird manuell redigiert (keine IPs, Keys, Passwoerter)
 
 ## URL-Struktur
 
 Alle Sites sind unter `www.moonweb.org` als Subverzeichnisse erreichbar:
-- `www.moonweb.org/` — Hub (Root)
+- `www.moonweb.org/`, Hub (Root)
-- `www.moonweb.org/infra/` — Infra
+- `www.moonweb.org/infra/`, Infra
-- `www.moonweb.org/smarthome/` — Smarthome
+- `www.moonweb.org/smarthome/`, Smarthome
-- `www.moonweb.org/code/` — Code
+- `www.moonweb.org/code/`, Code
-- `www.moonweb.org/retro/` — Retro
+- `www.moonweb.org/retro/`, Retro
-- `www.moonweb.org/timecapsule/` — Timecapsule (2001 Design)
+- `www.moonweb.org/timecapsule/`, Timecapsule (2001 Design)
-- `www.moonweb.org/impressum/` — Impressum
+- `www.moonweb.org/impressum/`, Impressum
 
 Cloudflare Redirects leiten alte Subdomains weiter:
 - `hub.moonweb.org/*` → `www.moonweb.org/*`
@@ -145,10 +145,10 @@ npm run prebuild:cv             # Alle Pre-Build Tasks (inkl. CV PDF)
 ```
 
 Dateien:
-- `stefankoelle/pdf/cv-style.css` — WeasyPrint-Stylesheet (A4, Typografie)
+- `stefankoelle/pdf/cv-style.css`, WeasyPrint-Stylesheet (A4, Typografie)
-- `stefankoelle/pdf/build-pdf.sh` — Shell-Skript fuer PDF-Generierung
+- `stefankoelle/pdf/build-pdf.sh`, Shell-Skript fuer PDF-Generierung
-- `stefankoelle/cv-print.njk` — Standalone HTML-Template (nur CV-Content)
+- `stefankoelle/cv-print.njk`, Standalone HTML-Template (nur CV-Content)
-- `stefankoelle/pdf/cv.pdf` — Generiertes PDF (Output)
+- `stefankoelle/pdf/cv.pdf`, Generiertes PDF (Output)
 
 Wichtig: Das PDF wird via Eleventy-Passthrough ins Build-Output kopiert (`dist/stefankoelle/pdf/cv.pdf`).
 

DESIGN.md

@@ -1,57 +1,57 @@
-# moonweb.org Hub-Konzept (v5 — fast vollständig, letzte Lücken vor SPEC.md/PLAN.md)
+# moonweb.org Hub-Konzept (v5, fast vollständig, letzte Lücken vor SPEC.md/PLAN.md)
 
 Status: Konzeptrunde nahezu abgeschlossen. Noch keine Umsetzung.
 
-## 1. Header/Layout-Prinzip — final
+## 1. Header/Layout-Prinzip, final
 
 Für alle Home-Bereich-Sites (infra, smarthome, code, retro) gilt ab jetzt ein klares Prinzip:
 
-- **Header ist das Wichtigste** — identisch über alle vier Sites (Site-Switcher, Banner, Farbakzent der jeweiligen Domain).
+- **Header ist das Wichtigste**, identisch über alle vier Sites (Site-Switcher, Banner, Farbakzent der jeweiligen Domain).
 - **Übersichtsseiten** (Domain-Root) folgen dem einheitlichen Card-Grid-Grundlayout.
-- **Detailseiten/Subseiten** übernehmen den gleichen Header, dürfen darunter aber ein **eigenes, freieres Layout** haben (wie es bei `/ledmatrix/` auf stefankoelle.de heute schon der Fall ist — Pinbelegung, API-Doku, Fotos in freier Anordnung statt starres Card-Raster).
+- **Detailseiten/Subseiten** übernehmen den gleichen Header, dürfen darunter aber ein **eigenes, freieres Layout** haben (wie es bei `/ledmatrix/` auf stefankoelle.de heute schon der Fall ist, Pinbelegung, API-Doku, Fotos in freier Anordnung statt starres Card-Raster).
 
 Das ist ein wichtiger Unterschied zu v3/v4: nicht "alles identisch", sondern **Header konsistent, Content-Layout pro Subseite flexibel**.
 
-## 2. LEDMatrix-Migration — erledigt (Phase 5)
+## 2. LEDMatrix-Migration, erledigt (Phase 5)
 
 - `/ledmatrix/` wurde vollständig ins Monorepo migriert und liegt unter `stefankoelle/de/ledmatrix/`.
 - Deploy erfolgt über IONOS SFTP alongside dem stefankoelle.de Onepager.
 - Die URL `stefankoelle.de/ledmatrix/` bleibt unverändert bestehen.
 
-## 3. Detailtiefe pro Domain — final festgelegt
+## 3. Detailtiefe pro Domain, final festgelegt
 
 | Domain | Detailseiten? | Regel |
 |---|---|---|
-| smarthome | Ja, aber nur wenn genug Content da ist | Übersicht zeigt Aufbau des Smarthomes; ein Thema bekommt sofort eine Detailseite, wenn Daten vorhanden sind — sonst wird das Thema vorerst nur in der Übersicht erwähnt (kein Platzhalter-Zwang) |
+| smarthome | Ja, aber nur wenn genug Content da ist | Übersicht zeigt Aufbau des Smarthomes; ein Thema bekommt sofort eine Detailseite, wenn Daten vorhanden sind, sonst wird das Thema vorerst nur in der Übersicht erwähnt (kein Platzhalter-Zwang) |
-| code | **Nie** | Nur Übersichtskarten + Link zu GitHub — bewusst kein Duplizieren von README-Inhalten |
+| code | **Nie** | Nur Übersichtskarten + Link zu GitHub, bewusst kein Duplizieren von README-Inhalten |
-| infra | Kaum, eher übersichtsorientiert | Hauptteil bleibt bewusst oberflächlich, da sensible Daten (IPs, Keys, interne Topologie) nicht öffentlich dürfen — siehe Punkt 4 |
+| infra | Kaum, eher übersichtsorientiert | Hauptteil bleibt bewusst oberflächlich, da sensible Daten (IPs, Keys, interne Topologie) nicht öffentlich dürfen, siehe Punkt 4 |
-| retro | Ja, aber bewusst rudimentär | Thema ist inhaltlich noch unausgereift — nur Grundgerüst anlegen, keine weitere Zeit investieren |
+| retro | Ja, aber bewusst rudimentär | Thema ist inhaltlich noch unausgereift, nur Grundgerüst anlegen, keine weitere Zeit investieren |
 
-## 4. Infra-Sensitivität — Redaktionsregel (neu, wichtig für SPEC.md)
+## 4. Infra-Sensitivität, Redaktionsregel (neu, wichtig für SPEC.md)
 
-Da infra "eher oberflächlich" bleiben soll, braucht es eine einfache Faustregel, was rein darf und was nicht — sonst ist das bei der Migration der bestehenden Docs (Heimnetzwerk-Final etc.) jedes Mal eine Einzelfallentscheidung:
+Da infra "eher oberflächlich" bleiben soll, braucht es eine einfache Faustregel, was rein darf und was nicht, sonst ist das bei der Migration der bestehenden Docs (Heimnetzwerk-Final etc.) jedes Mal eine Einzelfallentscheidung:
 
 - **Darf rein:** Architektur-Ebene (Proxmox + Synology + Docker-Host, VLAN-Konzept ohne konkrete interne IP-Pläne, welche Diensttypen laufen, welche Tools genutzt werden).
 - **Darf nicht rein:** konkrete IP-Adressen, WireGuard-Keys/Preshared-Keys, Passwörter, interne Hostnamen mit Rückschlussmöglichkeit, Backup-Ziele mit Zugangsdaten.
 
 Diese Regel gilt 1:1 auch für retro/smarthome, ist aber bei infra am relevantesten, weil dort die Rohdokumente (z. B. Heimnetzwerk-Final-v3.2, GL_Flint2_Final_v2) aktuell sehr konkret sind (u. a. reale IPs, WireGuard-Keys) und beim Übertragen aktiv gekürzt werden müssen.
 
-## 5. Bilder/Assets — final
+## 5. Bilder/Assets, final
 
 Alle Bilder bleiben **im GitHub-Repo** versioniert (kein separates Cloudflare R2/Images). Einfachster Weg, passt zum ohnehin geplanten Monorepo-Ansatz.
 
-## 6. DNS — bereits bei Cloudflare
+## 6. DNS, bereits bei Cloudflare
 
 Zone liegt schon bei Cloudflare, Pages-Anbindung ist damit ohne Zusatzschritt möglich. Offen bleibt nur, wohin die nackte Domain `moonweb.org` zeigt (siehe offene Frage 1 unten).
 
-## 7. Übersetzung, Last-Updated, Analytics, Perplexity-Rückkanal — final
+## 7. Übersetzung, Last-Updated, Analytics, Perplexity-Rückkanal, final
 
 - **Übersetzung:** einmaliger KI-gestützter Durchlauf pro Dokument bei der Migration, kein wiederkehrender Prozess.
-- **Last-Updated-Anzeige:** einfachste Lösung — im Zweifel **gar keine Anzeige**. Stattdessen soll der Anspruch sein, dass Inhalte grundsätzlich aktuell gehalten werden, statt ein Datum zu zeigen, das dann veraltet wirkt.
+- **Last-Updated-Anzeige:** einfachste Lösung, im Zweifel **gar keine Anzeige**. Stattdessen soll der Anspruch sein, dass Inhalte grundsätzlich aktuell gehalten werden, statt ein Datum zu zeigen, das dann veraltet wirkt.
 - **Analytics:** keine Statistik-Erfassung, weder Cloudflare Web Analytics noch anderes.
 - **Perplexity-Rückkanal:** zurückgestellt, wird später erneut betrachtet, keine Zeit jetzt investieren.
 
-## 8. Offene Kleinigkeiten — beantwortet
+## 8. Offene Kleinigkeiten, beantwortet
 
 Die vier ursprünglich offenen Punkte wurden inzwischen in SPEC.md/PLAN.md beantwortet:
 
@@ -60,7 +60,7 @@ Die vier ursprünglich offenen Punkte wurden inzwischen in SPEC.md/PLAN.md beant
 3. **Start-Reihenfolge:** Alle Sites gleichzeitig (PLAN.md §1: "launch simultaneously")
 4. **Platzhalter-Verhalten:** Keine Platzhalter, ehrliche kurze Seiten + WIP-Hinweise (SPEC.md §5, retro/ hat WIP-Badge)
 
-## 9. Gesamtstand — Konzept vollständig
+## 9. Gesamtstand, Konzept vollständig
 
 Alle Entscheidungsgrundlagen sind in SPEC.md (was) und PLAN.md (wie/wann) umgesetzt:
 

PLAN.md

@@ -1,30 +1,30 @@
-# moonweb.org — Implementation Plan
+# moonweb.org, Implementation Plan
 
 Companion to `SPEC.md`. Documents the completed migration from separate subdomain sites to a unified `www.moonweb.org` subdirectory structure.
 
-## Phase 0 — Repo & tooling setup
+## Phase 0, Repo & tooling setup
 
 1. Created the `moonweb-site` monorepo.
 2. Initialized Eleventy project structure per `SPEC.md §10`.
 3. Set up `shared/_includes/base.njk` (header + card-grid) with accent colors inlined.
 4. Verified local dev server works per site.
 
-## Phase 1 — Content migration & authoring (per domain)
+## Phase 1, Content migration & authoring (per domain)
 
-1. **code** — GitHub aggregator, `_data/repos.json`, overview page grouped by subcategory.
+1. **code**, GitHub aggregator, `_data/repos.json`, overview page grouped by subcategory.
-2. **smarthome** — overview + detail pages where content exists.
+2. **smarthome**, overview + detail pages where content exists.
-3. **infra** — shallow overview with redaction pass (no IPs, keys, passwords).
+3. **infra**, shallow overview with redaction pass (no IPs, keys, passwords).
-4. **retro** — minimal overview with WIP notices.
+4. **retro**, minimal overview with WIP notices.
-5. **hub** — central index linking all sites, including redirect `.htm` files for old www.moonweb.org paths.
+5. **hub**, central index linking all sites, including redirect `.htm` files for old www.moonweb.org paths.
-6. **timecapsule** — integrated from moonweb-www, preserves original 2001 design under `/timecapsule/`.
+6. **timecapsule**, integrated from moonweb-www, preserves original 2001 design under `/timecapsule/`.
 
-## Phase 2 — CI/CD
+## Phase 2, CI/CD
 
 1. GitHub Actions workflow `build-deploy-moonweb.yml`: single Eleventy build for all moonweb sites + timecapsule build, deploy via IONOS SFTP.
 2. GitHub Actions workflow `deploy-stefankoelle.yml`: stefankoelle.de build, deploy via IONOS SFTP.
 3. Cloudflare redirect rules for old subdomains (`scripts/cloudflare/`).
 
-## Phase 3 — Consolidation to www.moonweb.org
+## Phase 3, Consolidation to www.moonweb.org
 
 All moonweb.org sites now live under `www.moonweb.org` as subdirectories:
 
@@ -55,7 +55,7 @@ Cloudflare redirects forward old subdomains:
 - `.eleventyignore` excludes `stefankoelle/` and `timecapsule/` (built separately).
 - `build-pdf.sh` temporarily renames `.eleventyignore` for stefankoelle build.
 
-## Definition of done — Achieved
+## Definition of done, Achieved
 
 - All sites live under `www.moonweb.org` as subdirectories, deployed via IONOS SFTP.
 - `www.moonweb.org/code/` reflects the current GitHub repos via the `.moonweb.yml` aggregator.

README.md

@@ -1,6 +1,6 @@
 # moonweb-site
 
-Monorepo for the **moonweb.org** homelab — six static sites built with [Eleventy](https://www.11ty.dev/), deployed to [IONOS SFTP](https://www.ionos.de/).
+Monorepo for the **moonweb.org** homelab, six static sites built with [Eleventy](https://www.11ty.dev/), deployed to [IONOS SFTP](https://www.ionos.de/).
 
 ```
 www.moonweb.org/           -> Central index & gateway

SPEC.md

@@ -1,4 +1,4 @@
-# moonweb.org — Specification
+# moonweb.org, Specification
 
 Status: Migration complete. All sites live under `www.moonweb.org` as subdirectories, deployed via IONOS SFTP.
 
@@ -36,9 +36,9 @@ Old subdomain redirects (via Cloudflare):
 |---|---|---|---|
 | hub | `/` | Gateway, links to everything, one-line description per destination | Minimal |
 | infra | `/infra/` | Shallow, structured overview of the stack: Proxmox, Synology, VLANs, Docker hosting, dev environment | Reference, high-level only |
-| smarthome | `/smarthome/` | Why the homelab exists — sensors, automation, calendar/contacts sync, dashboards, media | Project storytelling |
+| smarthome | `/smarthome/` | Why the homelab exists, sensors, automation, calendar/contacts sync, dashboards, media | Project storytelling |
-| code | `/code/` | Curated, sorted GitHub catalog — overview only, always linking out to GitHub | Portfolio |
+| code | `/code/` | Curated, sorted GitHub catalog, overview only, always linking out to GitHub | Portfolio |
-| retro | `/retro/` | Physical retro hardware collection (not software/demos — that's 28k8's domain) | Simple, factual |
+| retro | `/retro/` | Physical retro hardware collection (not software/demos, that's 28k8's domain) | Simple, factual |
 | timecapsule | `/timecapsule/` | Original www.moonweb.org content from 2001, preserved as-is | Retro 2001 design |
 
 ## 4. Design system
@@ -49,7 +49,7 @@ Old subdomain redirects (via Cloudflare):
 - **Overview (index) pages** use a shared card-grid layout (clean card-grid with banner header, grouped card sections, sans-serif, generous whitespace, light theme only, no heavy JS).
 - **Detail/sub-pages** keep the same header but may use a freer layout below it.
 
-Note: stefankoelle.de uses its own independent design — it does not follow this header-consistent principle.
+Note: stefankoelle.de uses its own independent design, it does not follow this header-consistent principle.
 
 ### 4.2 Accent colors per domain
 
@@ -63,31 +63,31 @@ Note: stefankoelle.de uses its own independent design — it does not follow thi
 
 ### 4.3 URL convention
 
-`/section/slug/` — lowercase, hyphenated, trailing slash. All sites share a single Eleventy build with computed `pathPrefix` per section.
+`/section/slug/`, lowercase, hyphenated, trailing slash. All sites share a single Eleventy build with computed `pathPrefix` per section.
 
 ## 5. Content depth rules (per domain)
 
 | Domain | Detail pages? | Rule |
 |---|---|---|
-| smarthome | Yes, when there's enough content | Index shows how the smart home is structured; a topic gets a detail page immediately if enough data exists — otherwise it's mentioned in the overview only, no placeholder required |
+| smarthome | Yes, when there's enough content | Index shows how the smart home is structured; a topic gets a detail page immediately if enough data exists, otherwise it's mentioned in the overview only, no placeholder required |
 | code | Never | Overview cards + link to GitHub only. No duplicating README content. |
-| infra | Rarely | Deliberately shallow — most of the raw material is sensitive (see §6) |
+| infra | Rarely | Deliberately shallow, most of the raw material is sensitive (see §6) |
 | retro | Yes, but minimal | Topic is still immature; create only a rudimentary overview, don't over-invest time |
 
-General rule across all domains: **if content is too thin for a good detail page, skip the detail page — don't create a placeholder.**
+General rule across all domains: **if content is too thin for a good detail page, skip the detail page, don't create a placeholder.**
 
 ## 6. Infra content redaction rule
 
 Because infra must stay shallow and public-safe:
 
-- **Allowed:** architecture level — Proxmox + Synology + Docker host, VLAN concept without concrete internal IP plans, which service types run, which tools are used.
+- **Allowed:** architecture level, Proxmox + Synology + Docker host, VLAN concept without concrete internal IP plans, which service types run, which tools are used.
 - **Not allowed:** concrete IP addresses, WireGuard keys/preshared keys, passwords, internal hostnames that allow inference, backup targets with credentials.
 
 This rule applies to any domain but is most relevant for infra, since the source documents currently contain real IPs and keys that must be actively stripped during migration.
 
 ## 7. Language
 
-All sites in the monorepo are written **entirely in English**. Existing German source documents are translated once during migration via a single AI-assisted pass — not a recurring process. New `.moonweb.yml` metadata and generated content are authored in English from the start.
+All sites in the monorepo are written **entirely in English**. Existing German source documents are translated once during migration via a single AI-assisted pass, not a recurring process. New `.moonweb.yml` metadata and generated content are authored in English from the start.
 
 ## 8. GitHub automation (www.moonweb.org/code/)
 
@@ -104,13 +104,13 @@ summary: "Compact MVG/S-Bahn departure monitor with configurable stations."
 repo_url: "https://github.com/skoelle/mvg-departures"
 ```
 
-A local aggregator script reads `.moonweb.yml` from all repos via the GitHub API, and the result is committed into `_data/repos.json` inside the monorepo. This runs manually, on demand — no scheduled automation for now.
+A local aggregator script reads `.moonweb.yml` from all repos via the GitHub API, and the result is committed into `_data/repos.json` inside the monorepo. This runs manually, on demand, no scheduled automation for now.
 
 ## 9. Content maintenance
 
 - infra, smarthome, retro, stefankoelle: **fully manual**, edited in vim, committed via git push. No automation.
 - code: the only automated piece is the GitHub aggregator described in §8.
-- No "last updated" timestamps are shown anywhere — the goal is that content is simply kept current, not that staleness is displayed.
+- No "last updated" timestamps are shown anywhere, the goal is that content is simply kept current, not that staleness is displayed.
 - No analytics/tracking of any kind on any site.
 - Images/assets live versioned directly in the monorepo (no external asset host).
 
@@ -159,19 +159,19 @@ moonweb-site/
 
 ## 11. Technical stack
 
-- **Static site generator:** Eleventy (11ty) v3.1.6 — single config at root, computed `pathPrefix` per section, per-section collections.
+- **Static site generator:** Eleventy (11ty) v3.1.6, single config at root, computed `pathPrefix` per section, per-section collections.
-- **Static site generator (timecapsule):** Eleventy v2.0.1 — separate config, preserves original 2001 design.
+- **Static site generator (timecapsule):** Eleventy v2.0.1, separate config, preserves original 2001 design.
-- **Templates:** Nunjucks (.njk) — shared `base.njk` layout, `card-grid.njk` for index pages, `sitemap.njk` for central sitemap.
+- **Templates:** Nunjucks (.njk), shared `base.njk` layout, `card-grid.njk` for index pages, `sitemap.njk` for central sitemap.
 - **Styling:** Custom CSS (`base.css`) with accent colors inlined as `<style>` in `base.njk`. No per-site theme CSS files.
 - **Build:** entirely in GitHub Actions.
-- **Deploy:** IONOS SFTP — all sites deployed to `/websites/moonweb/`, stefankoelle.de to `/websites/stefankoelle/`.
+- **Deploy:** IONOS SFTP, all sites deployed to `/websites/moonweb/`, stefankoelle.de to `/websites/stefankoelle/`.
-- **DNS:** Cloudflare — DNS management + redirects from old subdomains (hub.moonweb.org, etc.).
+- **DNS:** Cloudflare, DNS management + redirects from old subdomains (hub.moonweb.org, etc.).
 - **Runtime:** fully static, no server-side code, no containers for the website itself.
 - **Local preview:** Eleventy's built-in dev server with live reload (`npm run dev` for all moonweb sites, `npm run dev:stefankoelle`, `npm run dev:timecapsule`).
 
 ## 12. Explicitly out of scope
 
-- Migrating 28k8.moonweb.org into the monorepo — undecided, revisit later, likely never.
+- Migrating 28k8.moonweb.org into the monorepo, undecided, revisit later, likely never.
-- Any Perplexity-backchannel mechanism — deferred.
+- Any Perplexity-backchannel mechanism, deferred.
 - Analytics of any kind.
 - Automated content generation/translation pipelines beyond the one-time GitHub aggregator for code.

code/index.njk

@@ -1,8 +1,8 @@
 ---
-title: "Open Source Projects — GitHub Repos & Code | moonweb"
+title: "Open Source Projects, GitHub Repos & Code | moonweb"
 section: "code"
 tags: "code"
-description: "Curated catalog of my public GitHub projects — automation, dev tools, web apps, and firmware."
+description: "Curated catalog of my public GitHub projects, automation, dev tools, web apps, and firmware."
 layout: base.njk
 subcategories:
   - "Smart Home Apps"
@@ -12,6 +12,7 @@ subcategories:
   - "Retro"
   - "Web Projects"
 ---
+<h1>Open Source Projects</h1>
 <p class="site-intro">A curated catalog of my public GitHub projects, sorted by topic.</p>
 
 {% for subcat in subcategories %}

eleventy.config.js

@@ -10,6 +10,10 @@ module.exports = function (eleventyConfig) {
   eleventyConfig.addGlobalData("site", { url: "https://www.moonweb.org" });
   eleventyConfig.addFilter("date", (d) => d.toISOString());
 
+  // Exclude the standalone sites from the root (moonweb) build
+  eleventyConfig.ignores.add("stefankoelle/**");
+  eleventyConfig.ignores.add("timecapsule/**");
+
   // Computed pathPrefix based on page's section front matter
   eleventyConfig.addGlobalData("eleventyComputed", {
     pathPrefix: (data) => SITES[data.section]?.pathPrefix ?? "",
@@ -24,6 +28,12 @@ module.exports = function (eleventyConfig) {
 
   // --- Passthrough copies ---
 
+  // Retro: Storm ST / Cloudy ST page images
+  eleventyConfig.addPassthroughCopy("retro/storm-cloudy/*.jpg");
+
+  // Retro: ET4000 page images
+  eleventyConfig.addPassthroughCopy("retro/et4000-experiment/*.jpg");
+
   // Root-level shared assets
   eleventyConfig.addPassthroughCopy({ "shared/base.css": "shared-base.css" });
   eleventyConfig.addPassthroughCopy({ "shared/favicon/hub.svg": "favicon.svg" });

hub/impressum.njk

@@ -25,7 +25,7 @@ layout: base.njk
 </p>
 
 <p>
-  The moonweb.org sites document my private home lab, retro-computing and personal coding projects and are non-commercial. stefankoelle.de presents my professional background (CV) as the same author.
+  The moonweb.org sites document my private home lab, retro-computing and personal coding projects; they are non-commercial. stefankoelle.de presents my professional background (CV) as the same author.
 </p>
 
 <p>
@@ -43,7 +43,7 @@ layout: base.njk
 
 <h3>2. Purpose of these Websites</h3>
 <p>
-  The moonweb.org websites (home, smarthome, infra, code, retro, timecapsule) document my private home-lab, home-automation and retro-computing hobby projects. buildbroken.moonweb.org is an archive of a blog I created with friends in our spare time. 28k8.moonweb.org is a homage to the 90s era. stefankoelle.de presents my professional CV and background as the same person. All are part of one personal project network and share this legal notice and privacy policy.
+  The moonweb.org websites (home, smarthome, infra, code, retro, timecapsule) document my private home lab, home-automation and retro-computing hobby projects. buildbroken.moonweb.org is an archive of a blog I created with friends in our spare time. 28k8.moonweb.org is a homage to the 90s era. stefankoelle.de presents my professional CV and background as the same person. All are part of one personal project network and share this legal notice and privacy policy.
 </p>
 
 <h3>3. Hosting</h3>
@@ -51,17 +51,12 @@ layout: base.njk
   Two different hosting providers are used within this network:
 </p>
 
-<h4>a) www.moonweb.org (home, infra, smarthome, code, retro, timecapsule) &mdash; IONOS SE</h4>
+<h4>a) IONOS SE &mdash; hosts www.moonweb.org (home, infra, smarthome, code, retro, timecapsule) and stefankoelle.de</h4>
 <p>
   Hosted on web space provided by IONOS SE, Elgendorfer Str. 57, 56410 Montabaur, Germany, acting as a processor under Art. 28 GDPR (Data Processing Agreement in place).
 </p>
 
-<h4>b) stefankoelle.de &mdash; IONOS SE</h4>
+<h4>b) Cloudflare Pages &mdash; hosts buildbroken.moonweb.org and 28k8.moonweb.org</h4>
-<p>
-  Hosted on web space provided by IONOS SE, Elgendorfer Str. 57, 56410 Montabaur, Germany, acting as a processor under Art. 28 GDPR (Data Processing Agreement in place).
-</p>
-
-<h4>c) buildbroken.moonweb.org, 28k8.moonweb.org &mdash; Cloudflare Pages</h4>
 <p>
   Hosted via Cloudflare Pages, operated by Cloudflare, Inc., 101 Townsend St, San Francisco, CA 94107, USA. Cloudflare processes connection-level data (e.g. your IP address, request headers) as part of its content delivery and DDoS/security systems. This is governed by Cloudflare&rsquo;s Data Processing Addendum, which incorporates the EU Standard Contractual Clauses (2021) as a safeguard for the transfer of data to the USA. See <a href="https://www.cloudflare.com/privacypolicy/">cloudflare.com/privacypolicy</a>.
 </p>
@@ -104,7 +99,7 @@ layout: base.njk
 
 <h3>7. Changes to this Policy</h3>
 <p>
-  I may update this policy if the setup of any website in this network changes — for example, if a visit counter or analytics tool is added to stefankoelle.de or to any moonweb.org subdomain. Any such change will be documented here before it goes live.
+  I may update this policy if the setup of any website in this network changes, for example, if a visit counter or analytics tool is added to stefankoelle.de or to any moonweb.org subdomain. Any such change will be documented here before it goes live.
 </p>
 
 <p><em>Last updated: August 2026</em></p>

hub/index.njk

@@ -1,9 +1,9 @@
 ---
-title: "Stefan Koelle — Homelab, Smart Home, Code & Retro Hardware | moonweb"
+title: "Stefan Kölle, Homelab, Smart Home, Code & Retro Hardware | moonweb"
 section: "hub"
 tags: "hub"
 permalink: /index.html
-description: "Stefan Koelle — Senior Software Developer & Architect based in Munich. Homelab projects, smart home automation, open-source code, and retro hardware."
+description: "Stefan Kölle, Senior Software Developer & Architect in Munich. Homelab projects, smart home automation, open-source code, and retro hardware."
 layout: base.njk
 ogImage: "/stefan-koelle-foto.jpg"
 sections:
@@ -38,7 +38,7 @@ sections:
         href: "https://28k8.moonweb.org"
         emoji: "💾"
       - title: "moonweb.org 2001"
-        summary: "The original www.moonweb.org as it was in 2001 — preserved as a time capsule."
+        summary: "The original www.moonweb.org as it was in 2001, preserved as a time capsule."
         href: "/timecapsule/"
         emoji: "🌐"
       - title: "inseco.de"
@@ -52,29 +52,29 @@ sections:
 ---
 <div class="intro">
   <div class="intro-text">
-    <h1>Hey, I'm Stefan 👋</h1>
+    <h1>Hey, I'm Stefan Kölle 👋</h1>
     <p>Welcome to moonweb, my personal corner on the internet. This is where I document my homelab, smart home setups, infrastructure experiments, retro hardware, and the code that ties it all together.</p>
-    <p>I'm a Senior Software Developer &amp; Architect based in Munich with 20+ years in the trenches, from Turbo Pascal on the 486 to .NET Core, Kubernetes, and AI-driven development today. By day I build microservices and cloud architecture, by night I dive into smart home automation, restore retro computers, and automate things that don't necessarily need automating.</p>
+    <p>I'm a Senior Software Developer &amp; Architect based in Munich with 20+ years in the trenches, from Turbo Pascal on a real 486 back in the day to .NET, Kubernetes, and AI-driven development today. By day I build microservices and cloud architecture, by night I dive into smart home automation, restore retro computers, and automate things that don't necessarily need automating.</p>
-    <p>Everything here runs on a homelab that has been evolving since the mid-90s, from multiple 486s and Pentiums back in the day to today's Proxmox cluster. Have a look around.</p>
+    <p>Everything here runs on a homelab that has been evolving since the mid-90s, from multiple 486s and Pentiums back then to today's Proxmox cluster. Have a look around.</p>
   </div>
-  <img class="intro-photo" src="/stefan-koelle-foto.jpg" alt="Stefan Koelle" width="280" height="280">
+  <img class="intro-photo" src="/stefan-koelle-foto.jpg" alt="Stefan Kölle" width="280" height="280">
 </div>
 
 {% include "card-grid.njk" %}
 
 <section class="about-expanded">
   <h2>What this site is about</h2>
-  <p>moonweb is a collection of personal projects that have grown over the past 25 years. What started as a single 486 running a BBS in the mid-90s has turned into a full homelab with Proxmox, Docker, smart home automation, and a growing collection of retro hardware. The name "moonweb" comes from the original domain moonweb.org, which has been online since 2000.</p>
+  <p>moonweb is the personal project site of Stefan Kölle (also spelled Stefan Koelle in English), a collection of projects that have grown over the past 25 years. What started as a single 486 running a BBS in the mid-90s has turned into a full homelab with Proxmox, Docker, smart home automation, and a growing collection of retro hardware. The name "moonweb" comes from the original domain moonweb.org, which has been online since 2000.</p>
   <p>Each section of this site documents a different part of the setup. The <a href="/infra/">infrastructure section</a> covers the Proxmox cluster, Synology NAS, Docker containers, networking, and backup strategies. The <a href="/smarthome/">smart home section</a> shows what automation projects are running, from Tasmota energy monitoring to MQTT sensors and AirPlay audio. The <a href="/code/">code section</a> lists the public GitHub projects that power these setups, and the <a href="/retro/">retro section</a> documents the hardware collection.</p>
 
   <h2>What I do professionally</h2>
-  <p>I work as a Senior Software Developer &amp; Architect at TENHIL GmbH (formerly stellenanzeigen.de), where I build and maintain microservices on .NET Core and Kubernetes. My day job involves designing cloud-native architectures, building APIs, and migrating legacy applications to modern stacks. I've been working with .NET since the early 2000s and have used everything from ASP Classic to the latest .NET 8 features.</p>
+  <p>I work as a Senior Software Developer &amp; Architect at TENHIL GmbH (formerly stellenanzeigen.de), where I build and maintain microservices on .NET and Kubernetes. My day job involves designing cloud-native architectures, building APIs, and migrating legacy applications to modern stacks. I've been working with .NET since the early 2000s and have used everything from ASP Classic to the latest .NET 10 features.</p>
   <p>Since early 2025, I've fully embraced AI-assisted development. I use Claude Code for most of my private projects and at work for Jira story implementation. The productivity gains are massive, and it's changed how I approach software development entirely. I also use OpenCode with OpenRouter for Python-based home lab projects.</p>
 
   <h2>The homelab</h2>
-  <p>The homelab has been evolving since the mid-90s. Today it runs on a Proxmox cluster with a Synology DS918+ NAS, multiple Docker hosts, and an OpenWrt router for multi-WAN failover. The setup includes Prometheus and Grafana for monitoring, InfluxDB for time-series data from smart home sensors, and a full backup strategy covering NAS snapshots, offsite copies, and cloud storage.</p>
+  <p>The homelab has been evolving since the mid-90s. Today it runs on a <a href="/infra/proxmox/">Proxmox cluster</a> with a Synology DS918+ NAS, multiple Docker hosts, and an OpenWrt router for multi-WAN failover. The setup includes Prometheus and Grafana for <a href="/infra/monitoring/">monitoring</a>, InfluxDB for time-series data from smart home sensors, and a full <a href="/infra/backup-strategy/">backup strategy</a> covering NAS snapshots, offsite copies, and cloud storage.</p>
-  <p>The smart home side includes HomematicIP thermostats bridged to MQTT, Tasmota smart plugs for energy monitoring, AirPlay multi-room audio on Raspberry Pi devices, and various ESP32-based dashboards and LED matrix displays. Everything is documented in the respective sections of this site.</p>
+  <p>The smart home side includes HomematicIP thermostats bridged to MQTT, <a href="/smarthome/tasmota-energy/">Tasmota smart plugs</a> for energy monitoring, AirPlay multi-room audio on Raspberry Pi devices, and various ESP32-based dashboards and LED matrix displays. Everything is documented in the respective sections of this site.</p>
 
   <h2>Retro computing</h2>
-  <p>Outside of work, I collect and maintain retro hardware. The collection includes Atari ST machines (a Mega ST 4 fleet and a Mega ST 2), Amiga systems, a 486 DX2-66 tower, and various MiSTer and MiST FPGA setups for preservation. I also run Batocera in the living room for casual retro gaming. The retro section documents the hardware, the maintenance, and the occasional deep-dive into compatibility issues like the 15kHz monitor problem on the Atari ST.</p>
+  <p>Outside of work, I collect and maintain retro hardware. The collection includes Atari ST machines (a <a href="/retro/atari-mega-st-fleet/">Mega ST 4 fleet</a> and a Mega ST 2), Amiga systems, and various MiSTer and MiST FPGA setups for preservation. The DOS environment is rebuilt rather than original, I reproduce a <a href="/retro/dos-486-tower/">486 DX2-66</a> on the MiSTer FPGA. I also run Batocera in the living room for casual retro gaming. The retro section documents the hardware, the maintenance, and the occasional deep-dive into compatibility issues like the <a href="/retro/atari-monitor-compatibility/">15kHz monitor problem</a> on the Atari ST. On the Amiga side, I'm following <a href="/retro/the-a1200/">The A1200</a> console ahead of its December 2026 launch.</p>
 </section>

infra/backup-strategy/index.njk

@@ -11,29 +11,29 @@ layout: base.njk
 
 <p>The homelab uses a layered backup approach, split into two independent
 tracks: NAS user content, and Proxmox VM/LXC backups. Both follow a
-3-2-1-style rule — multiple copies, multiple media types, at least one
+3-2-1-style rule: multiple copies, multiple media types, and at least one
 copy on a different machine.</p>
 
-<h2>NAS user content — four layers</h2>
+<h2>NAS user content, four layers</h2>
 <table>
 <tr><th>Layer</th><th>Target</th><th>Frequency</th><th>Purpose</th></tr>
 <tr><td>Snapshots</td><td>Synology, built-in</td><td>Hourly</td><td>Fast recovery of accidentally deleted files</td></tr>
 <tr><td>Local backup</td><td>USB drive attached to the NAS</td><td>Daily</td><td>Local versioned backup, independent of the NAS disks</td></tr>
-<tr><td>Offsite sync</td><td>External drive on a Raspberry Pi in a different room</td><td>Weekly</td><td>Geographically separated copy within the flat</td></tr>
+<tr><td>Offsite sync</td><td>External drive on a Raspberry Pi in a different room</td><td>Weekly</td><td>Physically separate copy in a different room</td></tr>
 <tr><td>Cloud archive</td><td>Cloud storage</td><td>Continuous</td><td>Off-site copy for worst-case scenarios (fire, theft)</td></tr>
 </table>
 
-<h2>Proxmox VM/LXC backups — three copies, two machines</h2>
+<h2>Proxmox VM/LXC backups, three copies, two machines</h2>
 <table>
 <tr><th>Copy</th><th>Target</th><th>Frequency</th></tr>
-<tr><td>1 — original</td><td>Proxmox host itself</td><td>Daily</td></tr>
+<tr><td>1, original</td><td>Proxmox host itself</td><td>Daily</td></tr>
-<tr><td>2 — primary offsite</td><td>Synology NAS (different machine)</td><td>Daily, right after copy 1</td></tr>
+<tr><td>2, primary offsite</td><td>Synology NAS (different machine)</td><td>Daily, right after copy 1</td></tr>
-<tr><td>3 — secondary offsite</td><td>Raspberry Pi backup target, different room</td><td>Daily (skipped one day/week to avoid network contention with the weekly NAS sync)</td></tr>
+<tr><td>3, secondary offsite</td><td>Raspberry Pi backup target, different room</td><td>Daily (skipped one day/week to avoid network contention with the weekly NAS sync)</td></tr>
 </table>
 
 <h2>Design principles</h2>
 <ul>
-<li>Backups always cross at least one machine boundary — nothing is considered "backed up" if it only lives on the source machine's local disk.</li>
+<li>Backups always cross at least one machine boundary, nothing is considered "backed up" if it only lives on the source machine's local disk.</li>
 <li>Weekly and daily jobs are scheduled to avoid saturating the internal power-line network link used by the offsite backup target.</li>
 <li>All scheduled jobs ping a dead-man's-switch monitoring service; a missed backup triggers an alert.</li>
 <li>Power to the offsite drive is only switched on for the duration of its weekly sync, to save power and extend disk life.</li>

infra/dev-environment/index.njk

@@ -9,29 +9,29 @@ layout: base.njk
 <h1>Xubuntu Dev VM</h1>
 <div class="detail-content">
 
-<p>This is a Xubuntu virtual machine on <a href="/proxmox/">Proxmox pve2</a> in the study that serves as my main development environment, replacing the need for a dedicated physical workstation. It's designed to be lightweight, remotely accessible from anywhere, and — most importantly — completely disposable, which is what makes it a safe place to let AI coding agents operate with far more autonomy than I'd otherwise allow.</p>
+<p>This is a Xubuntu virtual machine on <a href="/infra/proxmox/">Proxmox pve2</a> in the study that serves as my main development environment, replacing the need for a dedicated physical workstation. It's designed to be lightweight, remotely accessible from anywhere, and, most importantly, completely disposable, which is what makes it a safe place to let AI coding agents operate with far more autonomy than I'd otherwise allow.</p>
 
 <h2>Why a disposable VM is the biggest advantage</h2>
 <ul>
-<li><strong>Daily backups as a safety net</strong> — the VM is backed up once a day through Proxmox. If an AI agent breaks the system, misconfigures something critical, or deletes the wrong files, I simply restore yesterday's snapshot rather than manually debugging the damage.</li>
+<li><strong>Daily backups as a safety net</strong>, the VM is backed up once a day through Proxmox. If an AI agent breaks the system, misconfigures something critical, or deletes the wrong files, I simply restore yesterday's snapshot rather than manually debugging the damage.</li>
-<li><strong>No irreplaceable local data</strong> — nothing important lives only on this VM. All actual project code lives in Git repositories, so after a restore I just <code>git pull</code> everything back and I'm exactly where I left off, minus whatever the agent broke.</li>
+<li><strong>No irreplaceable local data</strong>, nothing important lives only on this VM. All actual project code lives in Git repositories, so after a restore I just <code>git pull</code> everything back and I'm exactly where I left off, minus whatever the agent broke.</li>
-<li><strong>Higher trust, more autonomy for AI agents</strong> — because the worst-case outcome is "restore a snapshot and re-pull," I can give coding agents like OpenCode much broader permissions on this machine than I would on a system holding unique, unbacked-up state. The blast radius of a mistake is capped at "lose a few hours of uncommitted work," never at "lose data."</li>
+<li><strong>Higher trust, more autonomy for AI agents</strong>, because the worst-case outcome is "restore a snapshot and re-pull," I can give coding agents like OpenCode much broader permissions on this machine than I would on a system holding unique, unbacked-up state. The blast radius of a mistake is capped at "lose a few hours of uncommitted work," never at "lose data."</li>
-<li><strong>Cheap to rebuild from scratch</strong> — if the VM ever gets into a truly bad state, standing up a fresh Xubuntu VM and re-cloning repos is a short, well-understood process rather than an emergency.</li>
+<li><strong>Cheap to rebuild from scratch</strong>, if the VM ever gets into a truly bad state, standing up a fresh Xubuntu VM and re-cloning repos is a short, well-understood process rather than an emergency.</li>
 </ul>
 
 <h2>Remote workflow via SSH</h2>
 <ul>
-<li><strong><a href="https://herdr.dev/">Herdr</a></strong> — manages my development workspaces over SSH, letting me organize and switch between multiple project contexts on the VM without manually juggling terminal sessions.</li>
+<li><strong><a href="https://herdr.dev/">Herdr</a></strong>, manages my development workspaces over SSH, letting me organize and switch between multiple project contexts on the VM without manually juggling terminal sessions.</li>
-<li><strong><a href="https://opencode.ai/de">OpenCode</a></strong> — the AI coding agent I run inside these workspaces; it's the main reason the VM's disposability matters, since it can act with elevated freedom knowing any damage is trivially reversible.</li>
+<li><strong><a href="https://opencode.ai/de">OpenCode</a></strong>, the AI coding agent I run inside these workspaces; it's the main reason the VM's disposability matters, since it can act with elevated freedom knowing any damage is trivially reversible.</li>
-<li><strong><a href="https://github.com/jesseduffield/lazygit">lazygit</a></strong> — terminal UI for Git, used for fast commit/branch/diff workflows directly inside the SSH session without leaving the terminal.</li>
+<li><strong><a href="https://github.com/jesseduffield/lazygit">lazygit</a></strong>, terminal UI for Git, used for fast commit/branch/diff workflows directly inside the SSH session without leaving the terminal.</li>
 </ul>
 
 <h2>Graphical fallback via Chrome Remote Desktop</h2>
 <ul>
-<li><strong>Full desktop access</strong> — when a GUI IDE is preferable to terminal-based editing, Chrome Remote Desktop connects straight into the Xubuntu desktop from any device.</li>
+<li><strong>Full desktop access</strong>, when a GUI IDE is preferable to terminal-based editing, Chrome Remote Desktop connects straight into the Xubuntu desktop from any device.</li>
-<li><strong>WebStorm</strong> — used for TypeScript projects that benefit from a full IDE (refactoring tools, debugging, integrated test runners).</li>
+<li><strong>WebStorm</strong>, used for TypeScript projects that benefit from a full IDE (refactoring tools, debugging, integrated test runners).</li>
-<li><strong>PyCharm</strong> — used the same way for Python projects.</li>
+<li><strong>PyCharm</strong>, used the same way for Python projects.</li>
 </ul>
 
-<p class="redacted-note">This setup deliberately treats the dev VM as ephemeral infrastructure, not a pet — the philosophy is: keep state in Git, keep the VM replaceable, and let daily backups absorb the risk of giving an AI agent real write access to the system.</p>
+<p class="note">This setup deliberately treats the dev VM as ephemeral infrastructure, not a pet, the philosophy is: keep state in Git, keep the VM replaceable, and let daily backups absorb the risk of giving an AI agent real write access to the system.</p>
 </div>

infra/docker/index.njk

@@ -9,62 +9,62 @@ layout: base.njk
 <h1>Docker Container Strategy</h1>
 <div class="detail-content">
 
-<p>My homelab runs almost entirely on Docker, spread across three dedicated Debian VMs instead of installing containers directly on bare metal or on the NAS operating system itself. Each VM is a clean, disposable Docker host that can be snapshotted and backed up as a whole through Proxmox, and every service is defined declaratively as a Docker Compose file living under <code>/docker-data/compose/&lt;service&gt;/</code>. This keeps the setup portable, reproducible, and easy to document — if a host dies, restoring a VM snapshot brings every container definition back with it.</p>
+<p>My homelab runs almost entirely on Docker, spread across three dedicated Debian VMs instead of installing containers directly on bare metal or on the NAS operating system itself. Each VM is a clean, disposable Docker host that can be snapshotted and backed up as a whole through Proxmox, and every service is defined declaratively as a Docker Compose file living under <code>/docker-data/compose/&lt;service&gt;/</code>. This keeps the setup portable, reproducible, and easy to document. If a host dies, restoring a VM snapshot brings every container definition back with it.</p>
 
 <h2>The three Docker hosts</h2>
 <ul>
-<li><strong>docker-host-pve</strong> — Debian VM on the main Proxmox server (PVE). This is the primary target for almost all container deployments, including my own images pulled from GHCR. Fully covered by Proxmox VM backups, so the whole host can be restored in one shot.</li>
+<li><strong>docker-host-pve</strong>, Debian VM on the main Proxmox server (PVE). This is the primary target for almost all container deployments, including my own images pulled from GHCR. Fully covered by Proxmox VM backups, so the whole host can be restored in one shot.</li>
-<li><strong>docker-host-nas</strong> — Debian VM running directly on the Synology (via Virtual Machine Manager). Identical setup and folder structure to the PVE host, but used specifically for containers that need direct access to NAS storage volumes, such as media-processing tools that read and write large file libraries.</li>
+<li><strong>docker-host-nas</strong>, Debian VM running directly on the Synology (via Virtual Machine Manager). Identical setup and folder structure to the PVE host, but used specifically for containers that need direct access to NAS storage volumes, such as media-processing tools that read and write large file libraries.</li>
-<li><strong>docker-host-pve2</strong> — Debian VM on the secondary Proxmox server (pve2), which lives in the study and is treated as a pure test/dev environment. New containers and compose setups get trialed here before being promoted to docker-host-pve.</li>
+<li><strong>docker-host-pve2</strong>, Debian VM on the secondary Proxmox server (pve2), which lives in the study and is treated as a pure test/dev environment. New containers and compose setups get trialed here before being promoted to docker-host-pve.</li>
 </ul>
 
 <h2>Standardized layout</h2>
 <ul>
-<li><strong>/docker-data/compose/</strong> — one subfolder per service, each containing its own <code>docker-compose.yml</code> (and <code>.env</code> where needed).</li>
+<li><strong>/docker-data/compose/</strong>, one subfolder per service, each containing its own <code>docker-compose.yml</code> (and <code>.env</code> where needed).</li>
-<li><strong>/docker-data/volumes/</strong> — persistent container data, kept outside the compose folders so it survives redeploys.</li>
+<li><strong>/docker-data/volumes/</strong>, persistent container data, kept outside the compose folders so it survives redeploys.</li>
-<li><strong>/docker-data/backups/</strong> — local backup staging before data is pulled into the wider backup chain.</li>
+<li><strong>/docker-data/backups/</strong>, local backup staging before data is pulled into the wider backup chain.</li>
-<li><strong>Same convention everywhere</strong> — because all three hosts follow this identical structure, moving a service between hosts or rebuilding a host from scratch is just a matter of copying the compose folder and running <code>docker compose up -d</code>.</li>
+<li><strong>Same convention everywhere</strong>, because all three hosts follow this identical structure, moving a service between hosts or rebuilding a host from scratch is just a matter of copying the compose folder and running <code>docker compose up -d</code>.</li>
 </ul>
 
 <h2>Own GitHub projects</h2>
 <ul>
-<li><strong>icloud-contacts-sync</strong> — syncs contact data between iCloud and other systems.</li>
+<li><strong>icloud-contacts-sync</strong>, syncs contact data between iCloud and other systems.</li>
-<li><strong>calendar-sync</strong> — keeps calendars synchronized across sources.</li>
+<li><strong>calendar-sync</strong>, keeps calendars synchronized across sources.</li>
-<li><strong>mvg-departures</strong> — pulls Munich public transport (MVG) departure data for local dashboards.</li>
+<li><strong>mvg-departures</strong>, pulls Munich public transport (MVG) departure data for local dashboards.</li>
-<li><strong>wetter-api</strong> — a small weather API/worker pair, built from a custom GHCR image and updated automatically via Watchtower.</li>
+<li><strong>wetter-api</strong>, a small weather API/worker pair, built from a custom GHCR image and updated automatically via Watchtower.</li>
 </ul>
 
 <h2>Infrastructure containers</h2>
 <ul>
-<li><strong>mosquitto-mqtt</strong> — central MQTT broker for smart-home and sensor messaging.</li>
+<li><strong>mosquitto-mqtt</strong>, central MQTT broker for smart-home and sensor messaging.</li>
-<li><strong>grafana, prometheus, influxdb</strong> — the monitoring and metrics stack for dashboards and time-series data.</li>
+<li><strong>grafana, prometheus, influxdb</strong>, the monitoring and metrics stack for dashboards and time-series data.</li>
-<li><strong>healthchecks, uptime-kuma, cadvisor</strong> — service and container health/uptime monitoring.</li>
+<li><strong>healthchecks, uptime-kuma, cadvisor</strong>, service and container health/uptime monitoring.</li>
-<li><strong>dyndns-updater</strong> — keeps DNS pointed at the home connection; my own project, see <a href="https://github.com/skoelle/dyndns-updater">skoelle/dyndns-updater</a> on GitHub.</li>
+<li><strong>dyndns-updater</strong>, keeps DNS pointed at the home connection; my own project, see <a href="https://github.com/skoelle/dyndns-updater">skoelle/dyndns-updater</a> on GitHub.</li>
-<li><strong>watchtower</strong> — automatically checks for and applies container image updates on a daily schedule.</li>
+<li><strong>watchtower</strong>, automatically checks for and applies container image updates on a daily schedule.</li>
-<li><strong>authelia, nginx-proxy-manager</strong> — authentication layer and reverse proxy for exposing internal services safely.</li>
+<li><strong>authelia, nginx-proxy-manager</strong>, authentication layer and reverse proxy for exposing internal services safely.</li>
-<li><strong>postfix</strong> — internal mail relay used by other containers (e.g. Watchtower notifications) to send email.</li>
+<li><strong>postfix</strong>, internal mail relay used by other containers (e.g. Watchtower notifications) to send email.</li>
-<li><strong>portainer</strong> — web UI for managing containers across hosts.</li>
+<li><strong>portainer</strong>, web UI for managing containers across hosts.</li>
-<li><strong>exporters</strong> — Prometheus exporters for Fritz!Box, Zyxel switches, Nginx, and SNMP devices, feeding the Grafana/Prometheus stack.</li>
+<li><strong>exporters</strong>, Prometheus exporters for Fritz!Box, Zyxel switches, Nginx, and SNMP devices, feeding the Grafana/Prometheus stack.</li>
 </ul>
 
 <h2>Smart home containers</h2>
 <ul>
-<li><strong>Home Assistant</strong> — only used for homematicIP integration to mqtt.</li>
+<li><strong>Home Assistant</strong>, only used for homematicIP integration to mqtt.</li>
 </ul>
 
 <h2>Application containers</h2>
 <ul>
-<li><strong>SearXNG</strong> — self-hosted, privacy-respecting metasearch engine that aggregates results from multiple search providers without leaking queries to any of them. Used as the default search backend for local browsing and AI tools.</li>
+<li><strong>SearXNG</strong>, self-hosted, privacy-respecting metasearch engine that aggregates results from multiple search providers without leaking queries to any of them. Used as the default search backend for local browsing and AI tools.</li>
-<li><strong>Open WebUI</strong> — chat interface for locally hosted LLMs.</li>
+<li><strong>Open WebUI</strong>, chat interface for locally hosted LLMs.</li>
-<li><strong>Stirling PDF</strong> — self-hosted PDF toolkit for merging, splitting, converting, compressing, and editing documents without uploading them to external services.</li>
+<li><strong>Stirling PDF</strong>, self-hosted PDF toolkit for merging, splitting, converting, compressing, and editing documents without uploading them to external services.</li>
-<li><strong>ArchiveBox</strong> — personal web archiving of bookmarked pages.</li>
+<li><strong>ArchiveBox</strong>, personal web archiving of bookmarked pages.</li>
-<li><strong>TubeSync / TubeArchivist [NAS]</strong> — download and archive YouTube content directly onto NAS storage; these run on docker-host-nas specifically because they need direct volume access to the Synology's disks.</li>
+<li><strong>TubeSync / TubeArchivist [NAS]</strong>, download and archive YouTube content directly onto NAS storage; these run on docker-host-nas specifically because they need direct volume access to the Synology's disks.</li>
-<li><strong>Music Stretto</strong> — music streaming server for the local MP3 library on the Synology, accessible from the home dashboard.</li>
+<li><strong>Music Stretto</strong>, music streaming server for the local MP3 library on the Synology, accessible from the home dashboard.</li>
 </ul>
 
 <h2>Development tools</h2>
 <ul>
-<li><strong>Gitea</strong> — self-hosted Git server acting as a mirror of my GitHub repositories, giving me a local fallback and faster internal access.</li>
+<li><strong>Gitea</strong>, self-hosted Git server acting as a mirror of my GitHub repositories, giving me a local fallback and faster internal access.</li>
 </ul>
 
 </div>

infra/index.njk

@@ -1,5 +1,5 @@
 ---
-title: "Homelab Infrastructure — Proxmox, Docker & Networking | moonweb"
+title: "Homelab Infrastructure, Proxmox, Docker & Networking | moonweb"
 section: "infra"
 tags: "infra"
 description: "Homelab infrastructure overview: Proxmox hosts, Synology NAS, Docker VMs and Setup-Guides."
@@ -34,14 +34,15 @@ sections:
         summary: "Multi-WAN router with WiFi and Powerline failover, plus IoT VLAN 189 isolation."
         href: "/infra/openwrt/"
 ---
+<h1>Homelab Infrastructure</h1>
 <p class="site-intro">A peek under the hood of my homelab. Proxmox, Synology, Docker, and how everything is wired together.</p>
 
 {% include "card-grid.njk" %}
 
 <section class="about-expanded">
   <h2>The setup at a glance</h2>
-  <p>The infrastructure runs on three main machines: a Proxmox VE host (Intel NUC, 64GB RAM) as the primary compute node, a Synology DS918+ NAS for storage and Docker services, and a Xubuntu VM on Proxmox for development. An OpenWrt router handles multi-WAN failover with WiFi and Powerline backhaul, and four Zyxel GS1200-8HP managed switches distribute the network across the flat.</p>
+  <p>The infrastructure runs on three physical machines: a Beelink S12 Pro running Proxmox as the primary host, a second Beelink running Proxmox as a test host, and a Synology DS918+ NAS for storage and Docker services. Development runs in a Xubuntu VM on the Proxmox hosts. An OpenWrt router handles multi-WAN failover with WiFi and Powerline backhaul, and four Zyxel GS1200-8HP managed switches distribute the network across the flat.</p>
-  <p>The whole stack is monitored via Prometheus and Grafana, with node exporters on every machine, cAdvisor for container metrics, and SNMP exporters for network hardware. Backups follow a 3-2-1 strategy: local snapshots, NAS copies, offsite sync to a Raspberry Pi in a different room, and cloud archive for worst-case scenarios.</p>
+  <p>The whole stack is monitored via Prometheus and Grafana, with node exporters on every machine, cAdvisor for container metrics, and SNMP exporters for network hardware. Backups follow a layered strategy: local snapshots, NAS copies, offsite sync to a Raspberry Pi in a different room, and cloud archive for worst-case scenarios.</p>
 
   <h2>Why Proxmox</h2>
   <p>Proxmox VE was chosen over alternatives like ESXi or plain Docker for several reasons. The open-source model means no licensing headaches. LXC containers provide near-native performance for lightweight services without the overhead of full VMs. The web UI makes it easy to manage snapshots, backups, and migrations. And the ZFS support on the underlying Debian system gives us reliable snapshots and send/receive for the backup chain.</p>

infra/lxc/index.njk

@@ -9,36 +9,36 @@ layout: base.njk
 <h1>LXC Container Strategy</h1>
 <div class="detail-content">
 
-<p>Alongside the Docker-based setup, I run a small number of Linux Containers (LXC) directly on the main Proxmox host (PVE). An LXC is an OS-level virtualization container — unlike a Docker container, which packages a single application and its dependencies, an LXC behaves like a full lightweight Linux system with its own init process, systemd services and package manager, but without the overhead of a full virtual machine. Proxmox manages LXCs natively as first-class citizens, right next to VMs, with their own snapshotting, backup and resource-limit tooling. I use far fewer LXCs than Docker containers, reserving them for cases where a persistent, OS-like environment or tight integration with Proxmox itself makes more sense than a containerized app.</p>
+<p>Alongside the Docker-based setup, I run a small number of Linux Containers (LXC) directly on the main Proxmox host (PVE). An LXC is an OS-level virtualization container. Unlike a Docker container, which packages a single application and its dependencies, an LXC behaves like a full lightweight Linux system with its own init process, systemd services, and package manager, but without the overhead of a full virtual machine. Proxmox manages LXCs natively as first-class citizens, right next to VMs, with their own snapshotting, backup and resource-limit tooling. I use far fewer LXCs than Docker containers, reserving them for cases where a persistent, OS-like environment or tight integration with Proxmox itself makes more sense than a containerized app.</p>
 
 <h2>Why LXC instead of Docker here</h2>
 <ul>
-<li><strong>Native Proxmox integration</strong> — LXCs show up directly in the Proxmox UI with their own resource graphs, backup jobs and snapshots, without needing a Docker host VM in between.</li>
+<li><strong>Native Proxmox integration</strong>, LXCs show up directly in the Proxmox UI with their own resource graphs, backup jobs and snapshots, without needing a Docker host VM in between.</li>
-<li><strong>Lower overhead than a VM</strong> — an LXC shares the host kernel, so it starts almost instantly and uses less RAM/CPU than a full Debian VM, while still feeling like a real, persistent Linux machine.</li>
+<li><strong>Lower overhead than a VM</strong>, an LXC shares the host kernel, so it starts almost instantly and uses less RAM/CPU than a full Debian VM, while still feeling like a real, persistent Linux machine.</li>
-<li><strong>Better fit for system-level services</strong> — some services (like a DNS resolver or a database server) benefit from being a stable, always-on OS process with predictable networking, rather than an ephemeral, frequently-redeployed container.</li>
+<li><strong>Better fit for system-level services</strong>, some services (like a DNS resolver or a database server) benefit from being a stable, always-on OS process with predictable networking, rather than an ephemeral, frequently-redeployed container.</li>
-<li><strong>Simplicity for infrequently-changed services</strong> — these three services rarely change their configuration, so the extra flexibility of Compose-based redeployment isn't needed; a straightforward apt-installed service is easier to reason about long-term.</li>
+<li><strong>Simplicity for infrequently-changed services</strong>, these three services rarely change their configuration, so the extra flexibility of Compose-based redeployment isn't needed; a straightforward apt-installed service is easier to reason about long-term.</li>
 </ul>
 
 <h2>Pi-hole</h2>
 <ul>
-<li><strong>Purpose</strong> — network-wide DNS sinkhole and ad/tracker blocking for every device on the home network.</li>
+<li><strong>Purpose</strong>, network-wide DNS sinkhole and ad/tracker blocking for every device on the home network.</li>
-<li><strong>Why LXC</strong> — DNS resolution needs to be rock-solid and always reachable at a fixed IP; running it as a lean, dedicated LXC avoids depending on the Docker host VM being up, and keeps it isolated from Docker networking quirks that could interfere with DNS.</li>
+<li><strong>Why LXC</strong>, DNS resolution needs to be rock-solid and always reachable at a fixed IP; running it as a lean, dedicated LXC avoids depending on the Docker host VM being up, and keeps it isolated from Docker networking quirks that could interfere with DNS.</li>
-<li><strong>Advantage</strong> — near-zero overhead, boots in seconds after a Proxmox host reboot, and its stability is decoupled from whatever is happening on the Docker hosts.</li>
+<li><strong>Advantage</strong>, near-zero overhead, boots in seconds after a Proxmox host reboot, and its stability is decoupled from whatever is happening on the Docker hosts.</li>
 </ul>
 
 <h2>Ubuntu-Worker</h2>
 <ul>
-<li><strong>Purpose</strong> — a general-purpose Ubuntu LXC used as a flexible worker/utility machine for ad-hoc scripts, cron jobs and small maintenance tasks that don't warrant their own container image.</li>
+<li><strong>Purpose</strong>, a general-purpose Ubuntu LXC used as a flexible worker/utility machine for ad-hoc scripts, cron jobs and small maintenance tasks that don't warrant their own container image.</li>
-<li><strong>Why LXC</strong> — it needs to behave like a normal Linux box (full package manager, cron, shell access) rather than a single-purpose containerized app, which makes an LXC a much better fit than wrapping everything in Docker.</li>
+<li><strong>Why LXC</strong>, it needs to behave like a normal Linux box (full package manager, cron, shell access) rather than a single-purpose containerized app, which makes an LXC a much better fit than wrapping everything in Docker.</li>
-<li><strong>Advantage</strong> — quick to spin up, snapshot and roll back via Proxmox, and useful as a lightweight sandbox for testing shell scripts or automation before productionizing them elsewhere.</li>
+<li><strong>Advantage</strong>, quick to spin up, snapshot and roll back via Proxmox, and useful as a lightweight sandbox for testing shell scripts or automation before productionizing them elsewhere.</li>
 </ul>
 
 <h2>MariaDB</h2>
 <ul>
-<li><strong>Purpose</strong> — central relational database instance, currently used by services such as nginx-proxy-manager, reachable over the network at a fixed internal IP.</li>
+<li><strong>Purpose</strong>, central relational database instance, currently used by services such as nginx-proxy-manager, reachable over the network at a fixed internal IP.</li>
-<li><strong>Why LXC</strong> — a database benefits from direct, persistent disk access and predictable performance without the extra storage-driver indirection of Docker volumes; running it as an unprivileged LXC keeps it isolated while still feeling like a native MariaDB install.</li>
+<li><strong>Why LXC</strong>, a database benefits from direct, persistent disk access and predictable performance without the extra storage-driver indirection of Docker volumes; running it as an unprivileged LXC keeps it isolated while still feeling like a native MariaDB install.</li>
-<li><strong>Advantage</strong> — simple backup via <code>mysqldump</code>, straightforward remote access configuration (bind-address, dedicated service users per consuming application), and one central database that multiple Docker containers on other hosts can connect to over the network instead of each running their own database container.</li>
+<li><strong>Advantage</strong>, simple backup via <code>mysqldump</code>, straightforward remote access configuration (bind-address, dedicated service users per consuming application), and one central database that multiple Docker containers on other hosts can connect to over the network instead of each running their own database container.</li>
 </ul>
 
-<p class="redacted-note">All three LXCs run exclusively on the main Proxmox host (PVE), not on pve2 or the Synology — they're intentionally kept centralized since they're few in number and don't need the multi-host redundancy that the Docker setup has. IPs, credentials and specific VMIDs are omitted here; only the reasoning behind the LXC-vs-Docker choice is shown.</p>
+<p class="note">All three LXCs run exclusively on the main Proxmox host (PVE), not on pve2 or the Synology; they're intentionally kept centralized since they're few in number and don't need the multi-host redundancy that the Docker setup has. IPs, credentials and specific VMIDs are omitted here; only the reasoning behind the LXC-vs-Docker choice is shown.</p>
 </div>

infra/monitoring/index.njk

@@ -11,15 +11,15 @@ layout: base.njk
 
 <p>Prometheus and Grafana form the central monitoring stack for the whole
 homelab, running as Docker containers on the NAS. Every machine in the
-flat — Proxmox host, Docker VM, Synology NAS, and Raspberry Pi devices —
+flat, including the Proxmox host, Docker VM, Synology NAS, and Raspberry
-feeds metrics into this central instance.</p>
+Pi devices, feeds metrics into this central instance.</p>
 
 <h2>What's monitored</h2>
 <ul>
-<li><strong>Proxmox host metrics</strong> — a PVE exporter reports node-level and per-VM/LXC CPU, memory, and disk metrics into a dedicated Grafana dashboard.</li>
+<li><strong>Proxmox host metrics</strong>, a PVE exporter reports node-level and per-VM/LXC CPU, memory, and disk metrics into a dedicated Grafana dashboard.</li>
-<li><strong>Host metrics everywhere</strong> — a node exporter runs on the NAS, the Docker host, and every Raspberry Pi, feeding basic CPU/RAM/disk/network stats.</li>
+<li><strong>Host metrics everywhere</strong>, a node exporter runs on the NAS, the Docker host, and every Raspberry Pi, feeding basic CPU/RAM/disk/network stats.</li>
-<li><strong>Container metrics</strong> — cAdvisor runs on both the Docker host and the NAS, breaking down resource usage per container.</li>
+<li><strong>Container metrics</strong>, cAdvisor runs on both the Docker host and the NAS, breaking down resource usage per container.</li>
-<li><strong>Network hardware via SNMP</strong> — an SNMP exporter polls a network-attached printer for toner level, page count, and status, proving the same pattern works for any SNMP-capable device.</li>
+<li><strong>Network hardware via SNMP</strong>, an SNMP exporter polls a network-attached printer for toner level, page count, and status, proving the same pattern works for any SNMP-capable device.</li>
 </ul>
 
 <h2>Dashboards</h2>
@@ -50,9 +50,8 @@ temperature thresholds) are planned but not yet implemented.</p>
 <h2>Open items</h2>
 <ul>
 <li>Alerting rules are not yet configured for most services.</li>
-<li>The secondary (test) Proxmox host isn't monitored yet — it's usually powered off.</li>
+<li>The secondary (test) Proxmox host isn't monitored yet; it's usually powered off.</li>
 <li>Retention policy for Prometheus data hasn't been tuned.</li>
-<li>Monitoring data itself isn't currently backed up.</li>
 </ul>
 
 </div>

infra/openwrt/index.njk

@@ -9,13 +9,13 @@ layout: base.njk
 <h1>OpenWrt Multi-WAN Router</h1>
 <div class="detail-content">
 
-<p>The study has historically suffered from unreliable network connectivity. To solve this, I set up an OpenWrt router that combines two WAN paths — WiFi and a dedicated Powerline link back to the server room — with automatic failover between them.</p>
+<p>The study has historically suffered from unreliable network connectivity. To solve this, I set up an OpenWrt router that combines two WAN paths, WiFi and a dedicated Powerline link back to the server room, with automatic failover between them.</p>
 
 <h2>Multi-WAN setup</h2>
 <ul>
-<li><strong>WAN 1 — WiFi (802.11ac)</strong> — higher throughput but less stable, used for bulk transfers and general traffic.</li>
+<li><strong>WAN 1, WiFi (802.11ac)</strong>, higher throughput but less stable, used for bulk transfers and general traffic.</li>
-<li><strong>WAN 2 — Powerline (Ethernet backhaul)</strong> — lower throughput but rock-solid, carries latency-sensitive traffic like VPN tunnels and Teams calls.</li>
+<li><strong>WAN 2, Powerline (Ethernet backhaul)</strong>, lower throughput but rock-solid, carries latency-sensitive traffic like VPN tunnels and Teams calls.</li>
-<li><strong>Failover</strong> — both paths are active simultaneously; if one drops, traffic automatically shifts to the remaining path. This provides redundancy in both directions.</li>
+<li><strong>Failover</strong>, both paths are active simultaneously; if one drops, traffic automatically shifts to the remaining path. This provides redundancy in both directions.</li>
 </ul>
 
 <p>Traffic is routed intelligently based on connection quality: VPN and real-time communication prefer the stable Powerline path, while everything else benefits from the higher WiFi throughput when available.</p>
@@ -28,7 +28,7 @@ layout: base.njk
 </ul>
 
 <h2>IoT VLAN 189</h2>
-<p>A dedicated, isolated network segment for IoT devices, running on a separate small WiFi access point on a different channel. This keeps smart home hardware — including the balcony sensors and light controller — off the main network while maintaining full connectivity to the homelab services.</p>
+<p>A dedicated, isolated network segment for IoT devices, running on a separate small WiFi access point on a different channel. This keeps smart home hardware, including the balcony sensors and light controller, off the main network while maintaining full connectivity to the homelab services.</p>
 <ul>
 <li><strong>VLAN ID:</strong> 189</li>
 <li><strong>Purpose:</strong> Isolate IoT/smart home devices from general network traffic.</li>
@@ -37,6 +37,6 @@ layout: base.njk
 </ul>
 
 <h2>Monitoring</h2>
-<p>The OpenWrt router is integrated into the <a href="/monitoring/">Prometheus monitoring stack</a> via SNMP exporter, providing visibility into WAN uptime, throughput, and connection quality across both paths.</p>
+<p>The OpenWrt router is integrated into the <a href="/infra/monitoring/">Prometheus monitoring stack</a> via SNMP exporter, providing visibility into WAN uptime, throughput, and connection quality across both paths.</p>
 
 </div>

infra/proxmox/index.njk

@@ -9,35 +9,35 @@ layout: base.njk
 <h1>Proxmox Virtualization</h1>
 <div class="detail-content">
 
-<p>Proxmox VE (Virtual Environment) is a free, open-source virtualization platform that combines KVM-based full virtual machines with lightweight LXC containers in a single web-managed system. It's built on top of Debian, includes ZFS storage management, backup/restore, clustering and monitoring out of the box, and is the foundation my entire homelab runs on — both the <a href="/docker/">Docker</a> hosts and the standalone <a href="/lxc/">LXC services</a> live as guests on top of it.</p>
+<p>Proxmox VE (Virtual Environment) is a free, open-source virtualization platform that combines KVM-based full virtual machines with lightweight LXC containers in a single web-managed system. It's built on top of Debian, includes ZFS storage management, backup/restore, clustering and monitoring out of the box, and is the foundation my entire homelab runs on, both the <a href="/infra/docker/">Docker</a> hosts and the standalone <a href="/infra/lxc/">LXC services</a> live as guests on top of it.</p>
 
 <h2>Hardware</h2>
 <ul>
-<li><strong>PVE (main server)</strong> — a Beelink Mini-PC, running as the primary Proxmox host. It has a 500GB SSD for VM and container storage, and connects to the network via the server-room Zyxel switch.</li>
+<li><strong>PVE (main server)</strong>, a Beelink S12 Pro, running as the primary Proxmox host. It has a 500GB SSD for VM and container storage, and connects to the network via the server-room Zyxel switch.</li>
-<li><strong>pve2 (test server)</strong> — a second Proxmox host, physically located in the study and connected via the OpenWRT-side Zyxel switch. It's dedicated purely to testing and development, running the third <a href="/docker/">Docker host VM (docker-host-pve2)</a> plus experimental setups without risking the production environment.</li>
+<li><strong>pve2 (test server)</strong>, a second Proxmox host, physically located in the study and connected via the OpenWrt-side Zyxel switch. It's dedicated purely to testing and development, running the third <a href="/infra/docker/">Docker host VM (docker-host-pve2)</a> plus experimental setups without risking the production environment.</li>
-<li><strong>Backups</strong> — nightly VM backups from PVE run at 00:30 to an NFS share on the Synology (<code>nas:/volume1/backup</code>), with retention of the last 3 daily, 3 monthly and 1 yearly backup.</li>
+<li><strong>Backups</strong>, nightly VM backups from PVE run at 00:30 to an NFS share on the Synology (<code>nas:/volume1/backup</code>), with retention of the last 3 daily, 3 monthly and 1 yearly backup.</li>
 </ul>
 
 <h2>Advantages</h2>
 <ul>
-<li><strong>Mixed virtualization</strong> — full KVM virtual machines and lightweight LXC containers run side by side on the same host, so I can pick whichever fits a service best.</li>
+<li><strong>Mixed virtualization</strong>, full KVM virtual machines and lightweight LXC containers run side by side on the same host, so I can pick whichever fits a service best.</li>
-<li><strong>Web-based management</strong> — the entire cluster, its VMs, containers, storage and backups are managed from one browser UI via Authelia/Nginx, no separate tooling needed.</li>
+<li><strong>Web-based management</strong>, the entire cluster, its VMs, containers, storage and backups are managed from one browser UI via Authelia/Nginx, no separate tooling needed.</li>
-<li><strong>Built-in ZFS support</strong> — snapshots, checksumming and pool management are native, making disk setup and VM protection straightforward.</li>
+<li><strong>Built-in ZFS support</strong>, snapshots, checksumming and pool management are native, making disk setup and VM protection straightforward.</li>
-<li><strong>Native backup/restore</strong> — scheduled backups to an external NFS target are configured directly in Proxmox, without third-party backup software.</li>
+<li><strong>Native backup/restore</strong>, scheduled backups to an external NFS target are configured directly in Proxmox, without third-party backup software.</li>
-<li><strong>No licensing cost</strong> — the platform is fully usable without a subscription by switching to the no-subscription repository, which matters for a homelab that isn't running on enterprise support contracts.</li>
+<li><strong>No licensing cost</strong>, the platform is fully usable without a subscription by switching to the no-subscription repository, which matters for a homelab that isn't running on enterprise support contracts.</li>
 </ul>
 
 <h2>Open-source edition</h2>
 <ul>
-<li><strong>Proxmox VE Community/no-subscription</strong> — the enterprise repositories are disabled and the host is switched to the free "no-subscription" package repository, giving full functionality identical to the paid tiers minus vendor support and the enterprise-only repo.</li>
+<li><strong>Proxmox VE Community/no-subscription</strong>, the enterprise repositories are disabled and the host is switched to the free "no-subscription" package repository, giving full functionality identical to the paid tiers minus vendor support and the enterprise-only repo.</li>
-<li><strong>License</strong> — Proxmox VE itself is open source (AGPLv3); the subscription only adds official support and access to the more conservative enterprise update channel.</li>
+<li><strong>License</strong>, Proxmox VE itself is open source (AGPLv3); the subscription only adds official support and access to the more conservative enterprise update channel.</li>
 </ul>
 
 <h2>Setup process</h2>
 <ul>
-<li><strong>Bootstrap</strong> — on new Beelink hardware, an initial OS (Windows) needs to be cleared first; entering the BIOS (DEL key) to set the boot order to USB-first allows booting the Proxmox installer.</li>
+<li><strong>Bootstrap</strong>, on new Beelink hardware, an initial OS (Windows) needs to be cleared first; entering the BIOS (DEL key) to set the boot order to USB-first allows booting the Proxmox installer.</li>
-<li><strong>Base install</strong> — Proxmox VE installed directly from ISO, then updated after disabling the enterprise repo and enabling the no-subscription repo.</li>
+<li><strong>Base install</strong>, Proxmox VE installed directly from ISO, then updated after disabling the enterprise repo and enabling the no-subscription repo.</li>
-<li><strong>Storage</strong> — an additional SSD is partitioned (GPT via <code>parted</code>) and turned into a ZFS pool through the Disks → ZFS section of the web UI.</li>
+<li><strong>Storage</strong>, an additional SSD is partitioned (GPT via <code>parted</code>) and turned into a ZFS pool through the Disks → ZFS section of the web UI.</li>
-<li><strong>Networking/backup target</strong> — an NFS share from the Synology is mounted for backup storage, and a nightly backup job is scheduled per VM.</li>
+<li><strong>Networking/backup target</strong>, an NFS share from the Synology is mounted for backup storage, and a nightly backup job is scheduled per VM.</li>
-<li><strong>Guest creation</strong> — VMs (like the Debian Docker-host VMs) and LXCs (Pi-hole, Ubuntu-Worker, MariaDB) are created through the web UI, with ISO images uploaded to local storage beforehand.</li>
+<li><strong>Guest creation</strong>, VMs (like the Debian Docker-host VMs) and LXCs (Pi-hole, Ubuntu-Worker, MariaDB) are created through the web UI, with ISO images uploaded to local storage beforehand.</li>
 </ul>

infra/synology/index.njk

@@ -9,28 +9,28 @@ layout: base.njk
 <h1>Synology NAS</h1>
 <div class="detail-content">
 
-<p>The NAS at the center of the homelab is a Synology DS918+, a 4-bay desktop NAS originally released in 2018. It runs Synology's DSM operating system and uses SHR (Synology Hybrid RAID) across its four drive bays, mixing different drive capacities while still keeping a full mirror-equivalent level of redundancy. After a focused cleanup pass at the end of 2025, the NAS was stripped down to only the packages and containers that are actually in active use, rather than years of accumulated, half-used software.</p>
+<p>The NAS at the center of the homelab is a Synology DS918+, a 4-bay desktop NAS originally released in 2018. It runs Synology's DSM operating system and uses SHR (Synology Hybrid RAID) across its four drive bays, mixing different drive capacities while keeping single-drive fault tolerance. After a focused cleanup pass at the end of 2025, the NAS was stripped down to only the packages and containers that are actually in active use, rather than years of accumulated, half-used software.</p>
 
 <h2>Storage</h2>
 <ul>
-<li><strong>Bays</strong> — 4 drive slots, populated with a mix of large-capacity HDDs rather than a single uniform set, which SHR was specifically chosen to support.</li>
+<li><strong>Bays</strong>, 4 drive slots, populated with a mix of large-capacity HDDs rather than a single uniform set.</li>
-<li><strong>RAID type</strong> — SHR (Synology Hybrid RAID), giving single-drive fault tolerance while allowing disks of different sizes to be mixed and later upgraded one at a time without rebuilding the whole array from scratch.</li>
+<li><strong>RAID type</strong>, SHR (Synology Hybrid RAID), giving single-drive fault tolerance while allowing drives to be upgraded one at a time without rebuilding the whole array from scratch.</li>
-<li><strong>Snapshots</strong> — Btrfs snapshot replication is used for file versioning instead of the classic recycle bin, taken hourly with a retention schedule of 7 days, 3 weeks, 3 months and 1 year.</li>
+<li><strong>Snapshots</strong>, Btrfs snapshot replication is used for file versioning instead of the classic recycle bin, taken hourly with a retention schedule of 7 days, 3 weeks, 3 months and 1 year.</li>
 </ul>
 
 <h2>What runs on it today</h2>
 <ul>
-<li><strong>Docker host VM</strong> — a dedicated Debian VM (docker-host-nas) runs on the NAS's virtualization layer, hosting containers that specifically need direct access to NAS storage volumes.</li>
+<li><strong>Docker host VM</strong>, a dedicated Debian VM (docker-host-nas) runs on the NAS's virtualization layer, hosting containers that specifically need direct access to NAS storage volumes.</li>
-<li><strong>File storage & backup target</strong> — the core role of the NAS remains classic network storage, plus acting as the backup destination for scheduled Proxmox VM backups from the rest of the homelab.</li>
+<li><strong>File storage & backup target</strong>, the core role of the NAS remains classic network storage, plus acting as the backup destination for scheduled Proxmox VM backups from the rest of the homelab.</li>
-<li><strong>Legacy packages removed</strong> — unused DSM packages (like a web/photo/media package, an old drive-sync service and unused indexing) were uninstalled to reduce background load and disk writes.</li>
+<li><strong>Legacy packages removed</strong>, unused DSM packages (like a web/photo/media package, an old drive-sync service and unused indexing) were uninstalled to reduce background load and disk writes.</li>
 </ul>
 
 <h2>Main strengths</h2>
 <ul>
-<li><strong>Central storage hub</strong> — single source of truth for files and backups that every other host in the network (Proxmox VMs, exporters, workstations) can write to or read from.</li>
+<li><strong>Central storage hub</strong>, single source of truth for files and backups that every other host in the network (Proxmox VMs, exporters, workstations) can write to or read from.</li>
-<li><strong>Built-in snapshotting</strong> — Btrfs-based snapshots give point-in-time recovery without the overhead of a separate versioning package.</li>
+<li><strong>Built-in snapshotting</strong>, Btrfs-based snapshots give point-in-time recovery without the overhead of a separate versioning package.</li>
-<li><strong>Flexible RAID</strong> — SHR allows disks to be swapped and capacity to grow over time without needing matched drive sizes from day one.</li>
+<li><strong>Flexible RAID</strong>, SHR allows capacity to grow over time by swapping in larger drives.</li>
-<li><strong>Lightweight virtualization</strong> — running a single purpose-built Docker VM on the NAS keeps storage-adjacent workloads close to the data, without turning the NAS itself into a general-purpose application server.</li>
+<li><strong>Lightweight virtualization</strong>, running a single purpose-built Docker VM on the NAS keeps storage-adjacent workloads close to the data, without turning the NAS itself into a general-purpose application server.</li>
 </ul>
 
 </div>

retro/amiga-hardware-landscape/index.njk

@@ -9,14 +9,14 @@ parent: "/retro/"
 <h1>Running AmigaOS in 2026: MiSTer FPGA vs Amiberry on Pi</h1>
 <div class="detail-content">
 
-<p>AmigaOS 3.2.3 runs beautifully both on FPGA and on modern ARM boards — the question is which trade-offs you're willing to accept. Both approaches have their place, and the choice often comes down to what you're trying to do: run demos at perfect timing, or tinker with software at higher resolutions.</p>
+<p>AmigaOS 3.2.3 runs beautifully both on FPGA and on modern ARM boards, the question is which trade-offs you're willing to accept. Both approaches have their place, and the choice often comes down to what you're trying to do: run demos at perfect timing, or tinker with software at higher resolutions. If you're weighing up the hardware options themselves (Vampire V4, A600GS or MiSTer) rather than the OS, head over to the <a href="/retro/amiga-modern-platforms/">hardware comparison</a>.</p>
 
 <h2>Two Roads to the Same Workbench</h2>
 <ul>
-<li><strong>MiSTer with the Minimig-AGA core</strong> — the most hardware-authentic option. Native resolution tops out around 800×600, with RTG (Picasso96) support pushing that up to 1080p. Timing accuracy and near-zero input latency make it the pick for demos and cycle-sensitive software.</li>
+<li><strong>MiSTer with the <a href="/retro/mist-mister-fpga/">Minimig-AGA core</a></strong>, the most hardware-authentic option. Native resolution tops out around 800×600, with RTG (Picasso96) support pushing that up to 1080p. Timing accuracy and near-zero input latency make it the pick for demos and cycle-sensitive software.</li>
-<li><strong>Amiberry on a Raspberry Pi</strong> — the flexible option. Running headless (no X11 desktop, straight from the console/KMS framebuffer) is the single biggest performance lever — the difference between a laggy desktop and a snappy 60fps Workbench.</li>
+<li><strong>Amiberry on a Raspberry Pi</strong>, the flexible option. Running headless (no X11 desktop, straight from the console/KMS framebuffer) is the single biggest performance lever, the difference between a laggy desktop and a snappy 60fps Workbench.</li>
-<li><strong>The HDF minefield</strong> — hard disk image files either carry an RDB partition table or they don't, and getting the geometry parameters (surfaces/sectors/reserved blocks) wrong produces the classic "Not a DOS disk in device DH0" error. Reformatting through HDToolBox from a fresh install is often faster than debugging geometry math.</li>
+<li><strong>The HDF minefield</strong>, hard disk image files either carry an RDB partition table or they don't, and getting the geometry parameters (surfaces/sectors/reserved blocks) wrong produces the classic "Not a DOS disk in device DH0" error. Reformatting through HDToolBox from a fresh install is often faster than debugging geometry math.</li>
-<li><strong>Picking a monitor</strong> — a 4:3 panel at native 1280×1024 (like an older NEC MultiSync) gives the most period-accurate Workbench experience; anything widescreen needs scaling compromises.</li>
+<li><strong>Picking a monitor</strong>, a 4:3 panel at native 1280×1024 (like an older <a href="https://www.nec-display.com/" target="_blank">NEC MultiSync 1970NXp</a>) gives the most period-accurate Workbench experience; anything widescreen needs scaling compromises.</li>
 </ul>
 
 <h2>When to choose MiSTer</h2>
@@ -40,8 +40,8 @@ a Pi to Amiga development without tying up expensive FPGA hardware.</p>
 Some demos use raster tricks that only work on real AGA hardware or the
 MiSTer's FPGA core. Some productivity software depends on specific
 accelerator card features that neither platform emulates perfectly.
-And the perennial question of Kickstart ROM versions — 3.1 for
+And the perennial question of Kickstart ROM versions, 3.1 for
-compatibility, 3.2 for features — applies equally to both setups.</p>
+compatibility, 3.2 for features, applies equally to both setups.</p>
 
-<p class="redacted-note">Both setups now run side by side without any real winner — MiSTer for authenticity and demos, the Pi for tinkering and RTG resolutions.</p>
+<p class="note">Both setups now run side by side without any real winner, MiSTer for authenticity and demos, the Pi for tinkering and RTG resolutions.</p>
 </div>

retro/amiga-modern-platforms/index.njk

@@ -9,15 +9,21 @@ parent: "/retro/"
 <h1>Vampire V4, A600GS or MiSTer: Amiga Hardware Isn't a Simple Speed Race</h1>
 <div class="detail-content">
 
-<p>Trying to compare Amiga hardware options by benchmark numbers alone is a trap. A Dhrystone score from a real FPGA CPU implementation and an ARM chip's MIPS rating measure completely different things — and neither tells you much about which system will actually run your favourite demo correctly.</p>
+<p>Trying to compare Amiga hardware options by benchmark numbers alone is a trap. A Dhrystone score from a real FPGA CPU implementation and an ARM chip's MIPS rating measure completely different things, and neither tells you much about which system will actually run your favourite demo correctly.</p>
 
 <h2>The Contenders</h2>
 <ul>
-<li><strong>Vampire V4 Standalone</strong> — an FPGA-implemented 68080 CPU that's genuinely blisteringly fast (sub-second Workbench boots), but software compatibility suffers since the 68080 isn't a perfect 68060 clone. Best for games and demos, not for daily productivity.</li>
+<li><strong>Vampire V4 Standalone</strong>, an FPGA-implemented 68080 CPU that's genuinely blisteringly fast (sub-second Workbench boots), but software compatibility suffers since the 68080 isn't a perfect 68060 clone. Best for games and demos, not for daily productivity.</li>
-<li><strong>A600GS / A1200NG</strong> — ARM-based boards running Amiberry underneath, in either a complete mini-PC (A600GS) or a drop-in motherboard replacement with real floppy and CompactFlash support (A1200NG). Cheap, plug-and-play, but with occasional software compatibility quirks.</li>
+<li><strong>A600GS / A1200NG</strong>, ARM-based boards running Amiberry underneath, in either a complete mini-PC (A600GS) or a drop-in motherboard replacement with real floppy and CompactFlash support (A1200NG). Note: this A1200NG is a third-party upgrade board, a different product entirely from Retro Games' upcoming "The A1200" console covered on its own page. Cheap, plug-and-play, but with occasional software compatibility quirks.</li>
-<li><strong>MiSTer with the Minimig core</strong> — "loses" on paper to A600GS in raw MIPS numbers, but wins on emulation accuracy and software compatibility. Its D-Cache-on mode is faster still but introduces glitches, so it's best left off for stability.</li>
+<li><strong>MiSTer with the Minimig core</strong>, "loses" on paper to A600GS in raw MIPS numbers, but wins on emulation accuracy and software compatibility. Its D-Cache-on mode is faster still but introduces glitches, so it's best left off for stability.</li>
-<li><strong>The real decision factor</strong> — not speed, but compatibility, stability, and how much you value hardware-accurate timing versus raw throughput.</li>
+<li><strong>The real decision factor</strong>, not speed, but compatibility, stability, and how much you value hardware-accurate timing versus raw throughput.</li>
 </ul>
 
-<p class="redacted-note">Conclusion after digging through all three: if you already own a working MiSTer, there's no compelling reason to chase the newer ARM boards for "better" performance — the practical difference is marginal, and MiSTer's broader core library wins in the long run.</p>
+<p class="note">Conclusion after digging through all three: if you already own a working MiSTer, there's no compelling reason to chase the newer ARM boards for "better" performance, the practical difference is marginal, and MiSTer's broader core library wins in the long run.</p>
+
+<h2>How I Run My Amiga Today</h2>
+<p>For now I'm not running original hardware, I reproduce my Amiga on the <a href="/retro/mist-mister-fpga/">MiSTer FPGA</a> using the Minimig core. My classic Amiga is mapped out there with Workbench and the tools I used back in the day, spread across different configurations and several Workbench versions, so I can revisit exactly how the machine felt across the years.</p>
+<p>I've also spent time with <a href="/retro/pimiga-journey/">PiMiga</a>, an Amiga-on-a-Raspberry-Pi distro that bundles Amiberry with a full A1200 AGA setup and Workbench 3.1. It's not real hardware, but it's another way to run the machine cheaply, and I documented how the different versions compare.</p>
+<p>I'm still keen on the real thing, though. Retro Games Ltd. is shipping an Amiga 1200 console on 4 December 2026, and I've been following everything public about it. There's a dedicated page on that: <a href="/retro/the-a1200/">The A1200: Release Date, Specs and What's Included</a>.</p>
+<p>If you want the detail on getting AmigaOS itself running across MiSTer and Amiberry, rather than comparing the hardware, that's covered on the <a href="/retro/amiga-hardware-landscape/">Running AmigaOS in 2026</a> page.</p>
 </div>

retro/atari-mega-st-fleet/index.njk

@@ -9,15 +9,23 @@ parent: "/retro/"
 <h1>The Atari Mega ST Fleet: Three Machines, Three Jobs</h1>
 <div class="detail-content">
 
-<p>Somewhere along the way, "one Atari ST" turned into three Mega ST 4 machines plus a Mega ST 2. Rather than let them gather dust, each one got a clearly defined purpose — from untouched nostalgia piece to fully upgraded workstation.</p>
+<p>Somewhere along the way, "one Atari ST" turned into three Mega ST 4 machines plus a Mega ST 2. Rather than let them gather dust, each one got a clearly defined purpose, from untouched nostalgia piece to fully upgraded workstation.</p>
 
 <h2>The Lineup</h2>
 <ul>
-<li><strong>The heirloom machine</strong> — kept as close to factory-original as possible, running the stock TOS 1.04 and a classic floppy drive. Its job is to be a baseline reference: if something breaks on a modded machine, this one proves the fault isn't in the software.</li>
+<li><strong>The heirloom machine</strong>, kept as close to factory-original as possible, running the stock TOS 1.04 and a classic floppy drive. Its job is to be a baseline reference: if something breaks on a modded machine, this one proves the fault isn't in the software.</li>
-<li><strong>The "Low" machine</strong> — a bargain-bin Mega ST 4 rebuilt with a Cloudy/StormyCloud combo for TOS switching and extra FastRAM, a Gotek floppy emulator, an UltraSatan hard disk emulator, and a SidecarTridge multi-device for ROM, floppy, and Wi-Fi tricks. This is the demo- and game-machine, optimized for fast disk-image swapping rather than serious productivity.</li>
+<li><strong>The "Low" machine</strong>, a bargain-bin Mega ST 4 rebuilt with a <a href="/retro/storm-cloudy/">Cloudy/Storm ST combo</a> for TOS switching and extra FastRAM, a <a href="/retro/gotek/">Gotek floppy emulator</a>, an <a href="/retro/ultrasatan/">UltraSatan</a> hard disk emulator, a <a href="/retro/sidecartridge/">SidecarTridge multi-device</a> for ROM, floppy, and Wi-Fi tricks, and a <a href="/retro/atari-networking-bbs/">Wi-Fi modem</a> for dialing into BBSs. This is the demo- and game-machine, optimized for fast disk-image swapping rather than serious productivity.</li>
-<li><strong>The "High" machine</strong> — the workstation build. A MonSTerBoard adds 8MB of AltRAM, IDE storage, and flashable TOS (currently TOS 2.06), running Geneva for real multitasking. A NetUSB adapter and original Atari keyboard/mouse round it out, with an ET4000 graphics card in the pipeline for higher resolutions.</li>
+<li><strong>The "High" machine</strong>, the workstation build. A <a href="/retro/monsterboard/">MonSTerBoard</a> adds 8MB of AltRAM, IDE storage, and flashable TOS (currently TOS 2.06), running Geneva for real multitasking. An <a href="/retro/et4000-experiment/">ET4000 graphics card</a> drives a dedicated monitor for higher resolutions. A <a href="/retro/netusb/">NetUSBee</a> adapter and an <a href="/retro/eiffel/">Eiffel interface</a> for a PS/2 keyboard and mouse round it out, with the original Atari keyboard and mouse now on the "Low" machine.</li>
-<li><strong>The spare Mega ST 2</strong> — a reserve and donor machine, kept in largely original condition, used to safely test upgrades before they go into the "real" machines.</li>
+<li><strong>The spare Mega ST 2</strong>, a reserve and donor machine, kept in largely original condition, used to safely test upgrades before they go into the "real" machines.</li>
 </ul>
 
-<p class="redacted-note">Fun fact: two of the "problem" machines turned out to have nothing wrong with the boards at all — a badly soldered CPU socket and a leftover blitter patch bridge were the actual culprits. Moral of the story: check your solder joints twice before blaming the silicon.</p>
+<h2>Extensions Not Yet Installed</h2>
+<p>A few upgrades have been bought or built but aren't in a machine yet, either waiting to go in or kept as spares:</p>
+<ul>
+<li><strong>A second <a href="/retro/gotek/">Gotek floppy emulator</a></strong>, bought alongside the one fitted to the "Low" machine, still unbuilt and ready for another machine or as a spare.</li>
+<li><strong>An <a href="/retro/eiffel-pico/">Eiffel Pico USB adapter</a></strong>, bought and configured but not yet installed, so I haven't decided which machine it will go into.</li>
+<li><strong>A new <a href="/retro/sidecartridge/">SidecarTridge Multi-device</a> Revision 3</strong>, bought as an upgrade over the Revision 0 in use on the "Low" machine, still uninstalled until I decide where to put it.</li>
+</ul>
+
+<p class="note">Fun fact: two of the "problem" machines turned out to have nothing wrong with the boards at all, a badly soldered CPU socket and a leftover blitter patch bridge were the actual culprits. Moral of the story: check your solder joints twice before blaming the silicon.</p>
 </div>

retro/atari-monitor-compatibility/index.njk

@@ -9,15 +9,15 @@ parent: "/retro/"
 <h1>The 15kHz Problem: Finding a Monitor That Speaks Atari</h1>
 <div class="detail-content">
 
-<p>Atari ST colour modes (Low-Res and Medium-Res) run at a horizontal scan frequency of 15kHz — a frequency almost no modern VGA monitor supports, since anything made in the last two decades expects at least 30kHz. High-Res monochrome runs at roughly 35kHz and gets along fine with most displays, but colour gaming is a different story entirely.</p>
+<p>Atari ST colour modes (Low-Res and Medium-Res) run at a horizontal scan frequency of 15kHz, a frequency almost no modern VGA monitor supports, since anything made in the last two decades expects at least 30kHz. High-Res monochrome runs at roughly 35kHz and gets along fine with most displays, but colour gaming is a different story entirely. A few older premium panels are the notable exceptions, and the NEC MultiSync LCD1970NXp is the best known of them.</p>
 
 <h2>Panel Technology Matters More Than You'd Think</h2>
 <ul>
-<li><strong>MVA/PVA panels</strong> — the surprise winners. Their flexible crystal alignment tolerates unusual 15kHz signals far better than standard panels. A NEC MultiSync LCD1970NXp with an MVA panel handles Medium-Res colour reliably, once you fine-tune the H.Size setting.</li>
+<li><strong>MVA/PVA panels</strong>, the surprise winners. Their flexible crystal alignment tolerates unusual 15kHz signals far better than standard panels. The classic example is the <a href="https://www.nec-display.com/" target="_blank">NEC MultiSync LCD1970NXp</a>, a 19-inch premium panel from around 2005 that genuinely handles 15kHz. Most LCDs only accept analogue VGA from 31kHz up, but this one is one of the rare exceptions, letting you connect an Amiga 500/1200, Atari ST or arcade board directly over a VGA cable without an upscaler. Its high-quality panel also gives wide 176-degree viewing angles and a strong 800:1 contrast, and it handles Medium-Res colour reliably once you fine-tune the H.Size setting. It's the monitor that runs my MiST and MiSTer.</li>
-<li><strong>IPS panels</strong> — a mixed bag. Some work (a widescreen Lenovo ThinkVision LT1952p reportedly fills the screen beautifully via an ST2VGA adapter), others don't, and there's no way to tell without testing.</li>
+<li><strong>IPS panels</strong>, a mixed bag. Some work (a widescreen Lenovo ThinkVision LT1952p reportedly fills the screen beautifully via an ST2VGA adapter), others don't, and there's no way to tell without testing.</li>
-<li><strong>VA panels</strong> — a dead end. Modern VA displays like the Dell SE2722HX and SE2422HX have a minimum horizontal frequency of 30kHz, ruling out native 15kHz signals entirely.</li>
+<li><strong>VA panels</strong>, a genuine hidden gem. The <a href="https://www.amazon.de/dp/B0957KH8X7/" target="_blank">Dell SE2722HX 27</a> (identical to the SE2722H) officially lists its horizontal range as starting at 30kHz, but its video scaler actually handles unlisted 15kHz support, something the community discovered through testing. Because it has a VGA input, it takes the raw RGB signal of old computers and upscales it to its native Full-HD 1920×1080, letting you connect an Amiga, Atari ST or arcade board directly without an OSSC or RetroTINK. Its VA panel gives a strong 3000:1 contrast for deep blacks, and it separates PAL and NTSC signals cleanly for smooth scrolling. It drives my Atari Mega ST 4 "Low" at 15kHz. The trade-offs: no built-in speakers, you have to switch the OSD aspect ratio to 4:3 (it's a 16:9 widescreen panel), and a heavily upscaled analogue signal can show faint vertical jailbars, which most retro fans accept given the price.</li>
-<li><strong>The universal fix</strong> — an Open Source Scan Converter (OSSC) upsamples the 15kHz signal for any HDMI monitor, at the cost of extra hardware and money.</li>
+<li><strong>The universal fix</strong>, an Open Source Scan Converter (OSSC) upsamples the 15kHz signal for any HDMI monitor, at the cost of extra hardware and money.</li>
 </ul>
 
-<p class="redacted-note">If you're chasing 15kHz authenticity, buy the specific panel model people have already confirmed working in the forums — don't trust a spec sheet that just says "supports VGA."</p>
+<p class="note">If you're chasing 15kHz authenticity, buy the specific panel model people have already confirmed working in the forums, don't trust a spec sheet that just says "supports VGA."</p>
 </div>

retro/atari-networking-bbs/index.njk

@@ -1,52 +1,33 @@
 ---
-title: "Getting a 40-Year-Old Computer Online: Atari ST Networking and BBS Access"
+title: "Dialing Into BBSs with a Wi-Fi Modem on the Atari ST"
 section: "retro"
 tags: "retro"
-description: "Connecting an Atari ST to the modern internet and to dial-up-era bulletin board systems, warts and all."
+description: "Using dhansel's WifiModem on the Atari Mega ST 4 'Low' to dial into telnet bulletin board systems with terminal software, no real phone line required."
 layout: base.njk
 parent: "/retro/"
 ---
-<h1>Getting a 40-Year-Old Computer Online: Atari ST Networking and BBS Access</h1>
+<h1>Dialing Into BBSs with a Wi-Fi Modem on the Atari ST</h1>
 <div class="detail-content">
 
-<p>The Atari ST predates the consumer internet entirely, yet a surprising amount of retrofitted networking hardware exists to get one talking to a modern network — or to a bulletin board system straight out of the dial-up era.</p>
+<p>My <a href="/retro/atari-mega-st-fleet/">Mega ST 4 "Low"</a> uses a ready-built Wi-Fi modem based on <a href="https://github.com/dhansel/WifiModem" target="_blank">dhansel's WifiModem</a> firmware, an ESP8266 module that connects a serial port to Wi-Fi. With it, the machine can dial into telnet-based bulletin board systems using its own terminal software, recreating the dial-up BBS experience without a real phone line.</p>
 
-<h2>The Toolbox</h2>
+<h2>The WifiModem</h2>
+<p>dhansel's WifiModem is firmware for the ESP8266 that makes a serial port talk to Wi-Fi. It does this in two ways, and they're mutually exclusive:</p>
 <ul>
-<li><strong>STinG</strong> — the classic TCP/IP stack for TOS, still the backbone for anything network-related on an original machine, from Telnet sessions to FTP transfers.</li>
+<li><strong>Modem emulation</strong>, the computer on the serial port talks to the module as if it were a Hayes-compatible modem, sending AT commands. It can "dial" an IP address or hostname, and the module connects to that host over Telnet. This is what lets a vintage computer dial into telnet BBSs.</li>
-<li><strong>ESP32-based Wi-Fi modules</strong> — small serial-attached boards that emulate a modem over Wi-Fi. Results vary wildly between firmware projects: one variant handles HTTP downloads fine but can't do Telnet, another supports full modem emulation but drops connections unpredictably during longer BBS sessions.</li>
+<li><strong>Telnet server</strong>, a computer on the Wi-Fi network can connect to the module's port 23 and the module passes communication through to the serial connection, letting you reach the Atari itself over Wi-Fi.</li>
-<li><strong>Terminal software quirks</strong> — ANSI art and special characters routinely render incorrectly in period terminal clients, an ongoing annoyance when connecting to text-heavy BBS systems.</li>
-<li><strong>File transfer the easy way</strong> — a plain FTP client on the Atari talking to a NAS on the local network sidesteps most of the internet-connectivity headaches entirely, especially for moving disk images and software archives back and forth.</li>
 </ul>
+<p>For dialing out to BBSs, the modem emulation mode is the relevant one. The module understands Hayes-style commands like <code>ATDT</code> followed by a hostname or IP address, and can even limit the line speed via the S37 register for an authentic slow-modem feel. Since the ESP8266 only has RX/TX pins, there are no hardware control lines, but the module handles the "+++" escape sequence to return to command mode during a call.</p>
 
-<h2>Why connect a 40-year-old computer to the internet</h2>
+<h2>Dialing the DarkForce! BBS</h2>
-<p>The obvious question is "why bother?" — the Atari ST was never designed
+<p>To put it to the test, I dialed into <a href="https://www.telnetbbsguide.com/bbs/dark-force-bbs/" target="_blank">the DarkForce! BBS</a>, an Atari-centric system that has been running since the early 90s on a Mega ST4 with BBS Express! ST software. It's a fitting target for an Atari ST, since it's a fellow Atari machine at heart. With the terminal software on the Mega ST sending <code>ATDT</code> to the Wi-Fi modem, the connection to <code>darkforce-bbs.dyndns.org</code> over Telnet worked, and the ANSI login screen, message boards and file sections of a real BBS came up on the original hardware, no phone line involved.</p>
-for the internet, and the experience of using it online is objectively
-worse than any modern device. But that's not the point. The real
-satisfaction comes from making old hardware do things it was never
-designed to do, understanding the networking stack at a level that modern
-abstractions hide, and experiencing the dial-up era's BBS culture on
-original hardware.</p>
 
-<h2>The BBS experience</h2>
+<h2>Why do it</h2>
-<p>Bulletin board systems from the dial-up era are still running today,
+<p>The obvious question is "why bother?", the Atari ST was never designed
-maintained by enthusiasts who keep the old software alive. Connecting to
+for networking, and a modern device does all this far more easily. But
-one from an original Atari ST — via a Wi-Fi modem emulation — is a
+that's not the point. There's real satisfaction in making old hardware do
-genuinely nostalgic experience. The ANSI art login screens, the message
+things it was never meant to do, and in experiencing the dial-up era's BBS
-boards, the file sections, the door games — it's all exactly as it was
+culture on original hardware, over Wi-Fi instead of a phone line.</p>
-in the early 1990s. The main difference: instead of tying up a phone
-line, the connection goes over Wi-Fi to a BBS that's accessible from
-anywhere in the world.</p>
 
-<h2>Lessons learned</h2>
+<p class="note">If you're chasing BBS nostalgia on real hardware: budget far more patience for the networking layer than for the actual computer. The 1980s hardware is the easy part; convincing 2020s Wi-Fi and modern BBS ANSI dialects to cooperate is the real challenge.</p>
-<p>The biggest lesson: networking on retro hardware is 90% patience and
-10% actual configuration. The STinG stack is well-documented but
-fragile — wrong TCP/IP settings silently break connections without
-useful error messages. The ESP32 Wi-Fi modules are cheap and flexible
-but require careful firmware selection for the specific use case. And
-terminal emulation is a rabbit hole of character sets, escape sequences,
-and display quirks that haven't been relevant for decades but still
-matter when connecting to a BBS that renders ANSI art.</p>
-
-<p class="redacted-note">If you're chasing BBS nostalgia on real hardware: budget far more patience for the networking layer than for the actual computer. The 1980s hardware is the easy part; convincing 2020s Wi-Fi and modern BBS ANSI dialects to cooperate is the real challenge.</p>
 </div>

retro/batocera-living-room/index.njk

@@ -9,15 +9,15 @@ parent: "/retro/"
 <h1>Batocera in the Living Room: One Box, Every Retro System</h1>
 <div class="detail-content">
 
-<p>Not every retro session calls for hardware-accurate FPGA timing. Sometimes you just want to grab a controller on the couch and pick something from a big menu — that's exactly what the Batocera station in the living room is for.</p>
+<p>Not every retro session calls for hardware-accurate FPGA timing. Sometimes you just want to grab a controller on the couch and pick something from a big menu, that's exactly what the Batocera station in the living room is for.</p>
 
 <h2>What's Under the Hood</h2>
 <ul>
-<li><strong>Software emulation, not FPGA</strong> — Hatari for Atari ST, UAE for Amiga, DOSBox for DOS, MAME/FBA for arcade, plus the usual console emulators (NES, SNES, Mega Drive, PlayStation). It's the go-to place for Atari ST gaming in this setup, since MiSTer's own ST core is unreliable.</li>
+<li><strong>Software emulation, not FPGA</strong>, Hatari for Atari ST, UAE for Amiga, DOSBox for DOS, MAME/FBA for arcade, plus the usual console emulators (NES, SNES, Mega Drive, PlayStation). It's the go-to place for Atari ST gaming in this setup, since MiSTer's own ST core is unreliable.</li>
-<li><strong>ROM organisation</strong> — following the TOSEC standard and cleaning up collections with RomVault DAT files, aiming for "1G1R" (One Game One ROM) sets to keep launcher menus from turning into an unmanageable wall of duplicates.</li>
+<li><strong>ROM organisation</strong>, following the TOSEC standard and cleaning up collections with RomVault DAT files, aiming for "1G1R" (One Game One ROM) sets to keep launcher menus from turning into an unmanageable wall of duplicates.</li>
-<li><strong>Curated sources</strong> — a well-known "scene DVD" collection covers Atari ST releases comprehensively; Amiga has no equally tidy equivalent, since TOSEC's Amiga archive is comprehensive but messy, mixing dozens of crack-group releases per game.</li>
+<li><strong>Curated sources</strong>, a well-known "scene DVD" collection covers Atari ST releases comprehensively; Amiga has no equally tidy equivalent, since TOSEC's Amiga archive is comprehensive but messy, mixing dozens of crack-group releases per game.</li>
-<li><strong>Division of labour with MiSTer/MiST</strong> — Batocera wins on convenience and breadth, MiSTer/MiST win on accuracy and low-latency feel for serious sessions.</li>
+<li><strong>Division of labour with MiSTer/MiST</strong>, Batocera wins on convenience and breadth, MiSTer/MiST win on accuracy and low-latency feel for serious sessions.</li>
 </ul>
 
-<p class="redacted-note">If you're building a similar box: don't skip the DAT-file cleanup step. An unsorted TOSEC dump makes browsing physically painful once you cross a few thousand entries.</p>
+<p class="note">If you're building a similar box: don't skip the DAT-file cleanup step. An unsorted TOSEC dump makes browsing physically painful once you cross a few thousand entries.</p>
 </div>

retro/dos-486-tower/index.njk

@@ -2,37 +2,37 @@
 title: "The 486 DX2-66: Rebuilding a DOS Era on MiSTer FPGA"
 section: "retro"
 tags: "retro"
-description: "Recreating a Vobis-Highscreen 486 DX2-66 setup on MiSTer FPGA, down to the original DOS configuration."
+description: "Rebuilding the Vobis-Highscreen 486 DX2-66 experience from memory on MiSTer FPGA, as it felt back in the day."
 layout: base.njk
 parent: "/retro/"
 ---
 <h1>The 486 DX2-66: Rebuilding a DOS Era on MiSTer FPGA</h1>
 <div class="detail-content">
 
-<p>Long before Atari ST and Amiga took over the retro corner, a Vobis-Highscreen 486 DX2-66 in its distinctive Colani-designed tower case was the main PC. The original hardware is long gone, but the entire setup has been recreated 1:1 on MiSTer FPGA — same DOS version, same drivers, same AUTOEXEC.BAT and CONFIG.SYS, same directory structure.</p>
+<p>Long before Atari ST and Amiga took over the retro corner, a Vobis-Highscreen 486 DX2-66 in its distinctive Colani-designed tower case was the main PC. The original hardware is long gone, and I never kept a backup, so this MiSTer FPGA build isn't a byte-for-byte copy. It's a rebuild from memory, set up the way I remember it and the way it felt to use back then, the DOS version, the drivers, and the AUTOEXEC.BAT and CONFIG.SYS that got everything working.</p>
 
 <h2>The original hardware</h2>
-<p>The Vobis-Highscreen was a premium PC in its day — the Colani design gave it a distinctive curved case that still looks futuristic. Inside it ran an Intel 486 DX2 at 66MHz with 8MB of RAM, a Sound Blaster 16, and a Tseng ET4000 graphics card. A 200MB hard drive and a 3.5" floppy drive completed the setup. The machine was the go-to system for early-90s classics like Doom, Wing Commander, Duke Nukem 3D, and Lemmings.</p>
+<p>The Vobis-Highscreen was a premium PC in its day, the Colani design gave it a distinctive curved case that still looks futuristic. Inside it ran an Intel 486 DX2 at 66MHz with 8MB of RAM and a Sound Blaster 16. A 200MB hard drive and a 3.5" floppy drive completed the setup. The machine was the go-to system for early-90s classics like Doom, Wing Commander, Duke Nukem 3D, and Lemmings.</p>
 
 <h2>The MiSTer recreation</h2>
-<p>The AO486 core on MiSTer FPGA reproduces the original hardware with near-perfect accuracy. The key was not just getting the hardware emulation right, but rebuilding the exact software environment: the same MS-DOS version, the same memory managers (HIMEM.SYS, EMM386), the same Sound Blaster drivers, and the same AUTOEXEC.BAT and CONFIG.SYS tuning that made the original machine run smoothly. Even the directory structure and file names match the original setup.</p>
+<p>The AO486 core on MiSTer FPGA handles the hardware convincingly. The real work was rebuilding the software environment from memory: the MS-DOS version, the memory managers (HIMEM.SYS, EMM386), the Sound Blaster drivers, and the AUTOEXEC.BAT and CONFIG.SYS tuning that made the original machine run smoothly.</p>
 
 <h2>Context: DOSMENU</h2>
-<p>A key part of the preserved environment is <strong><a href="https://28k8.moonweb.org/bbs/pc/dosmenu/">DOSMENU</a></strong>, a boot configuration utility written in Turbo Pascal 6.0 in 1994 — originally developed specifically for this Colani 486 machine. DOSMENU let you choose at boot time which AUTOEXEC.BAT and CONFIG.SYS commands to load — a critical feature in the DOS era, where memory management was manual and games often required different driver configurations. Features included saveable presets, a built-in MOD player, PCX picture display, and a DoubleSpace memory unloader. The original source: ~50k of Turbo Pascal, roughly 1900 lines plus some inline assembler.</p>
+<p>A key part of the preserved environment is <strong><a href="https://28k8.moonweb.org/bbs/pc/dosmenu/">DOSMENU</a></strong>, a boot configuration utility written in Turbo Pascal 6.0 in 1994, originally developed specifically for this Colani 486 machine. DOSMENU let you choose at boot time which AUTOEXEC.BAT and CONFIG.SYS commands to load, a critical feature in the DOS era, where memory management was manual and games often required different driver configurations. Features included saveable presets, a built-in MOD player, PCX picture display, and a DoubleSpace memory unloader. The original source: ~50k of Turbo Pascal, roughly 1900 lines plus some inline assembler.</p>
 
-<h2>Why a 1:1 recreation</h2>
+<h2>Why a rebuild from memory</h2>
-<p>The point isn't just to play DOS games — it's to preserve the exact computing experience from that era. The way DOS memory management worked, the way sound drivers had to be configured manually, the way batch files chained together to create a usable environment. This level of detail is lost when you just launch a DOS game from a modern frontend. The MiSTer setup recreates the entire boot process, from BIOS POST to the C:\> prompt, just as it was in the mid-90s.</p>
+<p>The point isn't just to play DOS games, it's to recapture the computing experience from that era. The way DOS memory management worked, the way sound drivers had to be configured manually, the way batch files chained together to create a usable environment. This level of detail is lost when you just launch a DOS game from a modern frontend. The MiSTer setup recreates the whole boot process, from BIOS POST to the C:\> prompt, the way I remember it from the mid-90s.</p>
 
 <h2>What's preserved</h2>
 <ul>
-<li><strong>DOS boot environment</strong> — the exact AUTOEXEC.BAT and CONFIG.SYS from the original machine, including memory manager configuration and Sound Blaster IRQ settings.</li>
+<li><strong>DOS boot environment</strong>, the AUTOEXEC.BAT and CONFIG.SYS set up from memory, including memory manager configuration and Sound Blaster IRQ settings.</li>
-<li><strong>Game installations</strong> — original game installations with their setup utilities, configuration files, and saved games, all in the same directory paths as the original.</li>
+<li><strong>Game installations</strong>, DOS games installed and configured the way I used them, with setup utilities and saved games.</li>
-<li><strong>System utilities</strong> — Norton Commander, PKZIP, the usual toolkit of the era, all configured the way they were used daily.</li>
+<li><strong>System utilities</strong>, Norton Commander, PKZIP, the usual toolkit of the era, set up the way they were used daily.</li>
-<li><strong><a href="https://28k8.moonweb.org/bbs/pc/dosmenu/">DOSMENU</a></strong> — a custom boot configuration utility written specifically for this Colani 486 in 1994. Built in Turbo Pascal, it let you choose at boot time which AUTOEXEC.BAT and CONFIG.SYS commands to load — essential for managing DOS memory across different games and applications.</li>
+<li><strong><a href="https://28k8.moonweb.org/bbs/pc/dosmenu/">DOSMENU</a></strong>, a custom boot configuration utility written specifically for this Colani 486 in 1994. Built in Turbo Pascal, it let you choose at boot time which AUTOEXEC.BAT and CONFIG.SYS commands to load, essential for managing DOS memory across different games and applications.</li>
-<li><strong>The quirks</strong> — the specific workarounds and tweaks that were needed to get everything running together, the kind of institutional knowledge that only exists on a well-used personal machine.</li>
+<li><strong>The quirks</strong>, the specific workarounds and tweaks that were needed to get everything running together, the kind of institutional knowledge that only exists on a well-used personal machine.</li>
 </ul>
 
 <h2>AO486 vs real hardware</h2>
-<p>The MiSTer AO486 core handles the emulation convincingly. Timing accuracy is good enough for games that rely on cycle-sensitive behavior. Sound Blaster emulation covers the standard OPL3 FM synthesis and digital audio. The main trade-off is that some hardware-specific quirks — like the exact timing of the ET4000 graphics card or the behavior of specific ISA bus peripherals — aren't perfectly replicated. But for the purpose of preserving a working DOS environment, it's more than sufficient.</p>
+<p>The MiSTer AO486 core handles the emulation convincingly. Timing accuracy is good enough for games that rely on cycle-sensitive behavior. Sound Blaster emulation covers the standard OPL3 FM synthesis and digital audio. The main trade-off is that some hardware-specific quirks, like the behavior of specific ISA bus peripherals, aren't perfectly replicated. But since this is a rebuild from memory rather than an exact copy anyway, that's more than good enough for a working DOS environment.</p>
 
 </div>

retro/eiffel-pico/index.njk

@@ -0,0 +1,48 @@
+---
+title: "Eiffel Pico USB: Modern USB Keyboard, Mouse and Joysticks for the Mega ST"
+section: "retro"
+tags: "retro"
+description: "The Eiffel Pico USB adapter brings USB keyboard, mouse and joysticks to the Atari Mega ST, a modern upgrade over the PS/2 Eiffel."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>Eiffel Pico USB: Modern USB Keyboard, Mouse and Joysticks for the Mega ST</h1>
+<div class="detail-content">
+
+<p>Alongside the PS/2 <a href="/retro/eiffel/">Eiffel interface</a> I've also bought the <a href="https://klydes-korner.site/en/product/atari-eiffel-pico-usb-adapter/" target="_blank">Atari Eiffel Pico USB</a>, the modern USB-based successor. It's configured and ready, but I haven't decided which machine it will go into yet.</p>
+
+<h2>What it does</h2>
+<p>The Eiffel Pico USB lets you use a USB keyboard, a USB mouse (or an original Atari mouse) and a USB or DB-9 joystick with your Atari Mega ST(E) or TT. It's based on the work of Field of Cows, improved by TrickyDee and reworked by Klyde, and it emulates the HD6301 chip from the Atari keyboard, so the Atari thinks it's connected to an original keyboard. There are no drivers needed, it's plug and play, powered entirely by the Atari, and connects via a straight RJ12 (6P6C) cable.</p>
+
+<h2>Key features</h2>
+<ul>
+<li><strong>Multilingual interface</strong>, French, English, German, Spanish and Italian.</li>
+<li><strong>Atari keyboard emulation in many TOS languages</strong>, US/UK English, German, French, Spanish, Italian, Swiss, Danish, Swedish, Finnish, Norwegian, Dutch, Hungarian, Czech and Polish.</li>
+<li><strong>Adjustable USB mouse speed</strong>.</li>
+<li><strong>Original Atari or compatible mouse</strong> supported on the DB-9 port for purists.</li>
+<li><strong>Adjustable dead zone</strong> for USB joysticks.</li>
+<li><strong>Adjustable autofire</strong> for USB and DB-9 joysticks.</li>
+<li><strong>Key mapping</strong> of the Atari ST keyboard.</li>
+</ul>
+
+<h2>Compatibility</h2>
+<p>It supports up to 4 USB devices (keyboard, mouse, joysticks), though keyboards with integrated USB hubs aren't compatible. Alongside the USB ports it includes two standard 9-pin Atari joystick ports, Joy0 and Joy1, for an authentic retro experience. A known-working list of keyboards and mice is maintained on the product page.</p>
+
+<h2>Eiffel PS/2 vs. Eiffel Pico USB</h2>
+<table>
+<tr><th>Feature</th><th>Eiffel PS/2</th><th>Eiffel Pico USB</th></tr>
+<tr><td>Peripherals</td><td>PS/2 keyboard + mouse</td><td>USB keyboard + mouse (or original)</td></tr>
+<tr><td>Joysticks</td><td>2 PS/2-era ports</td><td>USB joysticks + 2 Atari DB-9 ports</td></tr>
+<tr><td>Modern hardware</td><td>Needs PS/2 (or USB via adapter)</td><td>Native USB, modern peripherals</td></tr>
+<tr><td>Extra features</td><td>F11/F12 mapping</td><td>Multilingual, mouse speed, dead zone, autofire, key mapping</td></tr>
+</table>
+<p>The PS/2 Eiffel is the classic option if you already have PS/2 hardware. The Pico USB is the modern choice, letting you use any USB keyboard and mouse without PS/2 adapters, with far more configuration options.</p>
+
+<h2>My Setup</h2>
+<p>I've bought the Eiffel Pico USB and configured it, but it's not installed yet, so I haven't decided which machine it will go into. It sits alongside the other uninstalled extensions for now.</p>
+
+<h2>Sources</h2>
+<ul>
+<li><a href="https://klydes-korner.site/en/product/atari-eiffel-pico-usb-adapter/" target="_blank">Atari Eiffel Pico USB adapter - Klyde's Korner (product)</a></li>
+</ul>
+</div>

retro/eiffel/index.njk

@@ -0,0 +1,39 @@
+---
+title: "Eiffel Interface: PS/2 Keyboard, Mouse and Joysticks for the Mega ST"
+section: "retro"
+tags: "retro"
+description: "Using the Eiffel interface to connect a PS/2 keyboard, mouse and joysticks to the Atari Mega ST 4 'High'."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>Eiffel Interface: PS/2 Keyboard, Mouse and Joysticks for the Mega ST</h1>
+<div class="detail-content">
+
+<p>My <a href="/retro/atari-mega-st-fleet/">Mega ST 4 "High"</a> workstation uses an Eiffel interface, which lets me connect a standard PS/2 keyboard and mouse plus two joysticks to the machine's keyboard port. The original Atari keyboard and mouse have moved over to the <a href="/retro/atari-mega-st-fleet/">Mega ST 4 "Low"</a> machine.</p>
+
+<h2>What the Eiffel is</h2>
+<p>The Eiffel is a free, GPL open-source project to connect a standard PC mouse and keyboard to an Atari ST, Mega ST, TT or Falcon. It was originally started by Laurent Favard with help from Didier Mequignon. Features include:</p>
+<ul>
+<li><strong>PS/2 mouse support</strong>, up to two mouse wheels and five buttons.</li>
+<li><strong>PS/2 keyboard support</strong>, standard 102/105-key with extra keys, with F11 mapped as the Atari Help key and F12 as the Undo key (changeable via a small GEM setup application).</li>
+<li><strong>Two 9-pin Atari joystick ports</strong>, Joy0 and Joy1, like the original keyboard.</li>
+<li><strong>Works with TOS, Magic, MiNT and Geneva</strong>, I have it running under Geneva myself.</li>
+<li><strong>In-system programming</strong> of the PIC for firmware updates.</li>
+</ul>
+
+<h2>The version I use</h2>
+<p>I use the <a href="https://klydes-korner.site/en/product/ps2-to-atari-eiffel-adapter-with-joysticks/" target="_blank">PS/2 Atari Eiffel adapter with joystick ports</a> from Klyde's Korner. This version connects to the keyboard port (RJ12) of an Atari Mega ST(E) or TT, and includes two joystick ports alongside the PS/2 keyboard and mouse. It's plug and play, comes pre-programmed with the latest firmware (v1.10.1Mq, which fixes a joystick firing problem), and needs no drivers. It connects via an RJ12 (6P6C) straight cable, and works with a native PS/2 keyboard and mouse or certain PS/2-compatible USB devices via a USB-to-PS/2 adapter.</p>
+
+<h2>Why use it</h2>
+<p>Original Atari keyboards are getting rare and expensive. The Eiffel is a cheap, modern alternative that brings a standard PS/2 keyboard and mouse to the machine, along with the two joystick ports the original keyboard had. It also gives a much better typing feel: I use a Cherry PS/2 keyboard, which is far more pleasant to type on than the original, and a Logitech PS/2 mouse that tracks noticeably better than the original Atari STM1 mouse. It makes the workstation far more practical to use day to day. The older Eiffel versions were originally built and sold by Lyndon Amsdon, with the design documented on the <a href="https://hardware.atari.org/eiffel/index.htm" target="_blank">Atari Hardware Guide</a>, and the project history is covered in the <a href="https://wiki.newtosworld.de/index.php?title=Eiffel_Interface" target="_blank">Atari Wiki</a>.</p>
+
+<h2>My Setup</h2>
+<p>In my Mega ST 4 "High" machine the Eiffel connects the PS/2 keyboard and mouse, keeping the workstation fully usable alongside the <a href="/retro/monsterboard/">MonSTerBoard</a>, <a href="/retro/et4000-experiment/">ET4000</a> and <a href="/retro/netusb/">NetUSBee</a>. The original Atari keyboard and mouse are now used with the "Low" machine.</p>
+
+<h2>Sources</h2>
+<ul>
+<li><a href="https://klydes-korner.site/en/product/ps2-to-atari-eiffel-adapter-with-joysticks/" target="_blank">PS/2 Atari Eiffel adapter with joystick ports - Klyde's Korner (product)</a></li>
+<li><a href="https://hardware.atari.org/eiffel/index.htm" target="_blank">Eiffel - Atari Hardware Guide</a></li>
+<li><a href="https://wiki.newtosworld.de/index.php?title=Eiffel_Interface" target="_blank">Eiffel Interface - Atari Wiki-NEU</a></li>
+</ul>
+</div>

retro/et4000-experiment/index.njk

@@ -1,26 +1,56 @@
 ---
-title: "Why an ET4000 Graphics Card and a Mega ST Don't Mix (Yet)"
+title: "The ET4000 in a Mega ST: Higher Resolutions, Eventually Working"
 section: "retro"
 tags: "retro"
-description: "A cautionary tale about pushing 1980s power supplies past their limits with a modern-ish graphics card."
+description: "How an ET4000 ISA graphics card ended up working in a heavily upgraded Atari Mega ST, via a STGA adapter, and what it took to get there."
 layout: base.njk
 parent: "/retro/"
 ---
-<h1>Why an ET4000 Graphics Card and a Mega ST Don't Mix (Yet)</h1>
+<h1>The ET4000 in a Mega ST: Higher Resolutions, Eventually Working</h1>
 <div class="detail-content">
 
-<p>An ET4000 ISA graphics card, adapted to the Atari MegaBus, promises higher resolutions and more colors than the native Shifter chip can dream of. In practice, bolting one onto a heavily upgraded Mega ST turned into a lesson in power supply physics.</p>
+<p>An ET4000 ISA graphics card, adapted to the Atari MegaBus, promises higher resolutions and more colors than the native Shifter chip can dream of. Getting one running in my heavily upgraded <a href="/retro/atari-mega-st-fleet/">Mega ST 4 "High"</a> machine turned out to be a genuine hardware battle, but it now works like a charm.</p>
 
-<h2>What Went Wrong</h2>
+<h2>The STGA Adapter</h2>
+<p>The key to running an ET4000 in an Atari ST is a <a href="http://www.harbaum.org/till/atari/index.html" target="_blank">STGA adapter</a>, a design published by Till Harbaum in the ST-Magazin (issues 5, 6 and 7 in '93) that lets you drive an ET4000 VGA card in an Atari ST. I found a nice STGA adapter for ET4000 cards on ebay-kleinanzeigen.de, reproduced by an Atari forum user. After some research into which type of ET4000 could work, I bought one on ebay.de, and here it is running in my Atari Mega 4.</p>
+
+<h2>The Card and Driver</h2>
+<p>I can confirm that a card with the RAMDAC SC11487CN works with the Nova T8 and T6 drivers. And importantly, this particular card does not need -12V, which simplifies the wiring considerably. The STGA adapter comes with its own VDI (STGA_VDI.SYS, v1.3b), a control panel as a CPX module, and a ROM module that switches to the VGA automatically at boot.</p>
+
+<h2>What Made It Difficult</h2>
 <ul>
-<li><strong>Power supply overload</strong> — the stock Mega ST PSU simply wasn't designed to feed a MonSTerBoard, an ET4000, and a MegaBus adapter at the same time. The 5V and 12V rails ended up right at their instability limit.</li>
+<li><strong>Power supply overload</strong>, the stock Mega ST PSU simply wasn't designed to feed a MonSTerBoard, an ET4000, and a MegaBus adapter at the same time. The 5V and 12V rails ended up right at their instability limit.</li>
-<li><strong>The missing -12V</strong> — the ET4000 needs -12V for its output drivers, usually tapped from the RS-232 port, adding yet another drain on an already stressed supply.</li>
+<li><strong>The missing -12V</strong>, many ET4000 cards need -12V for their output drivers, usually tapped from the RS-232 port, adding yet another drain on an already stressed supply. The card I used avoids this.</li>
-<li><strong>Heat with nowhere to go</strong> — the card runs hot, and the Mega ST case has zero provision for active cooling.</li>
+<li><strong>Heat with nowhere to go</strong>, the card runs hot, and the Mega ST case has zero provision for active cooling.</li>
-<li><strong>Signal integrity issues</strong> — the ISA-to-MegaBus adapter introduces reflections at higher frequencies, and access to ET4000 RAM is roughly 65% slower than native ST RAM, with no hardware BitBLT to make up for it.</li>
+<li><strong>Signal integrity issues</strong>, the ISA-to-MegaBus adapter introduces reflections at higher frequencies, and access to ET4000 RAM is roughly 65% slower than native ST RAM, with no hardware BitBLT to make up for it.</li>
 </ul>
 
-<h2>The Practical Fallback</h2>
+<h2>How It Got Working</h2>
-<p>FPGA cores on MiSTer and MiST only emulate the native ST Shifter — there's no ET4000 emulation on the horizon given the FPGA resources it would require. The real answer for higher resolutions turned out to be software: Hatari running in VDI mode on a Raspberry Pi 400, which comfortably delivers 1280×768 with far more colors and zero PSU drama.</p>
+<p>Solving it came down to giving the supply the headroom it needed. With a properly beefed-up power supply to cover the 5V and 12V rails, plus a cooling solution for the card, the stability problems went away. The ET4000 now drives higher resolutions and more colors than the Shifter chip can natively produce, turning the "High" machine into a genuine workstation.</p>
 
-<p class="redacted-note">Lesson learned: "just add a graphics card" on 40-year-old hardware is never "just" anything. The ET4000 project isn't dead, but it's shelved until there's a properly beefed-up power supply and cooling solution to go with it.</p>
+<h2>The Context</h2>
+<p>FPGA cores on MiSTer and MiST still only emulate the native ST Shifter, with no ET4000 emulation on the horizon given the FPGA resources it would require. So the real hardware approach remains the only way to get those higher resolutions, and now it works in the Mega ST 4 "High" machine with its dedicated <a href="/retro/atari-monitor-compatibility/">monitor</a>.</p>
+
+<h2>Gallery</h2>
+<img src="et4000-1.jpg" alt="The ET4000 graphics card with STGA adapter" width="590" height="443">
+<p class="caption">The ET4000 graphics card ready for installation.</p>
+
+<img src="et4000-2.jpg" alt="ET4000 card installed in the Mega ST" width="590" height="443">
+<p class="caption">The ET4000 installed in the Mega ST.</p>
+
+<img src="et4000-3.jpg" alt="ET4000 card detail and wiring" width="590" height="443">
+<p class="caption">Close-up of the card and its wiring.</p>
+
+<img src="et4000-4.jpg" alt="ET4000 running at higher resolution" width="590" height="443">
+<p class="caption">The ET4000 driving a higher resolution desktop.</p>
+
+<img src="et4000-5.jpg" alt="ET4000 final setup in the workstation" width="590" height="443">
+<p class="caption">The finished ET4000 setup in the workstation.</p>
+
+<h2>Sources</h2>
+<ul>
+<li><a href="http://www.harbaum.org/till/atari/index.html" target="_blank">Till Harbaum's Atari page - STGA adapter</a></li>
+</ul>
+
+<p class="note">Lesson learned: "just add a graphics card" on 40-year-old hardware is never "just" anything. But with the right STGA adapter, a compatible card, and the power supply and cooling sorted, the ET4000 now runs where I always hoped it would.</p>
 </div>

retro/gotek/index.njk

@@ -0,0 +1,42 @@
+---
+title: "Gotek Floppy Emulator: USB Stick Drive for the Atari ST"
+section: "retro"
+tags: "retro"
+description: "Using cheap Gotek floppy emulator clones with HxC firmware to replace floppy drives with USB stick images on the Atari Mega ST."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>Gotek Floppy Emulator: USB Stick Drive for the Atari ST</h1>
+<div class="detail-content">
+
+<p>Floppy drives and disks get unreliable after decades, so I picked up two cheap Gotek floppy emulator clones from AliExpress and followed the guides to bring USB stick disk images to the Atari. One is installed in my <a href="/retro/atari-mega-st-fleet/">Mega ST 4 "Low"</a>, the other is still unbuilt.</p>
+
+<h2>What a Gotek is</h2>
+<p>A Gotek is a cheap floppy drive emulator sold by the Chinese company of the same name, available in many variants on AliExpress, eBay and Amazon for around 20 Euro. To the Atari it looks like a normal floppy drive, but the disk data actually lives as disk-image files on a USB stick. That makes it easy to archive and preserve many old disks in little space, and to exchange data with a modern PC.</p>
+
+<h2>The HxC firmware upgrade</h2>
+<p>On their own, stock Gotek drives are of limited use on the Atari. The trick is to flash them with <a href="https://hxc2001.com/floppy_drive_emulator/" target="_blank">Jean-François del Nero's HxC firmware</a>, which dramatically expands their capabilities and makes them properly usable with the ST. Installing it involves flashing a new bootloader over a serial connection, then the firmware itself is loaded from the USB stick. The full steps are covered in the <a href="https://www.chzsoft.de/site/hardware/usb-stick-floppy-emulator-am-atari-st/" target="_blank">CHZ-Soft guide</a> and the <a href="https://www.jungsi.de/hxc-floppy-emulator-hardware/" target="_blank">HxC overview on Jungsi's Corner</a>.</p>
+
+<h2>Modes and image formats</h2>
+<p>The HxC firmware reads disk images in HFE format, a bit-for-bit copy of a disk's magnetisation that can even emulate unusual floppy formats. The emulator can run in several modes:</p>
+<ul>
+<li><strong>Indexed mode</strong>, loads files like DSKA0000.HFE, DSKA0001.HFE from the stick's root, selected with the drive's buttons.</li>
+<li><strong>Autoboot mode</strong>, offers 16 image slots, with slot 0 holding the AUTOBOOT.HFE configuration program.</li>
+<li><strong>File selector mode</strong>, needs an extra LCD display to browse and select images directly.</li>
+</ul>
+<p>Using the HxC software you can convert common Atari ST, MSA and other disk formats into HFE, create new images, and transfer files between the images and a PC. Always use double-density (DD) recording for the ST, and set the interface mode to Atari ST.</p>
+
+<h2>Installation</h2>
+<p>For the drive to work in the Atari, it has to be jumpered to drive select 0 (S0). Whether it runs as internal drive A: or external drive B:, the wiring inside a floppy station uses the usual power and data cables, though the data cable isn't keyed, so check pin 1. The front bezel of the floppy station may need cutting out to fit the emulator mechanically.</p>
+
+<h2>My Setup</h2>
+<p>One of the Gotek emulators is installed internally in my Mega ST 4 "Low" machine, giving it reliable disk-image storage on a USB stick alongside the <a href="/retro/storm-cloudy/">Cloudy/Storm ST combo</a>, the <a href="/retro/sidecartridge/">SidecarTridge</a> and the <a href="/retro/atari-networking-bbs/">Wi-Fi modem</a>. The second Gotek is still unbuilt, waiting to go into another machine or to serve as a spare.</p>
+<p>For the internal mount I printed a <a href="https://www.thingiverse.com/thing:2664753" target="_blank">Gotek case from Thingiverse</a> that fits in the floppy bay. I used this to relocate the Storm/Cloudy TOS switcher: the 2-way switch is mounted in a slot at the front of the printed case, right where the floppy opening is. So the TOS switcher now sits at the front of the floppy bay, which meant no drilling into the case at all, and there was already space there for it.</p>
+
+<h2>Sources</h2>
+<ul>
+<li><a href="https://www.chzsoft.de/site/hardware/usb-stick-floppy-emulator-am-atari-st/" target="_blank">USB-Stick-Floppy-Emulator am Atari ST - CHZ-Soft (installation guide)</a></li>
+<li><a href="https://www.jungsi.de/hxc-floppy-emulator-hardware/" target="_blank">HxC Floppy Emulator [Retro] - Jungsi's Corner</a></li>
+<li><a href="https://www.thingiverse.com/thing:2664753" target="_blank">Gotek floppy emulator case - Thingiverse (3D print)</a></li>
+</ul>
+</div>

retro/index.njk

@@ -1,8 +1,8 @@
 ---
-title: "Retro Computing — Vintage Hardware & FPGA | moonweb"
+title: "Retro Computing, Vintage Hardware & FPGA | moonweb"
 section: "retro"
 tags: "retro"
-description: "Physical retro hardware collection — Raspberry Pi units, Pi 400, and vintage computing setups."
+description: "Physical retro hardware collection, Raspberry Pi units, Pi 400, and vintage computing setups."
 layout: base.njk
 sections:
   - heading: "Atari ST Corner"
@@ -10,26 +10,50 @@ sections:
       - title: "🖥️ The Mega ST Fleet"
         summary: "Three Mega ST 4 machines and a Mega ST 2, each with a clearly defined role from heirloom to workstation."
         href: "/retro/atari-mega-st-fleet/"
-      - title: "⚡ ET4000 Experiment"
+      - title: "⚡ ET4000 in the Mega ST"
-        summary: "Why bolting a graphics card onto a Mega ST overloads a 1980s power supply, and what actually solved the resolution problem."
+        summary: "Adding higher resolutions to the Mega ST 4 'High' via a STGA adapter and an ET4000 card, and what it took to get it working."
         href: "/retro/et4000-experiment/"
       - title: "📺 Monitor Compatibility"
         summary: "The 15kHz problem explained, and which modern monitor panels actually cooperate with Atari colour modes."
         href: "/retro/atari-monitor-compatibility/"
-      - title: "🔌 Networking & BBS"
+      - title: "🔌 Wi-Fi Modem & BBS"
-        summary: "Getting an Atari ST online via STinG and Wi-Fi modem hardware, and dialing into classic bulletin board systems."
+        summary: "Dialing into telnet bulletin board systems from the Mega ST 4 'Low' using dhansel's WifiModem and terminal software."
         href: "/retro/atari-networking-bbs/"
+      - title: "🌀 Storm ST & Cloudy ST"
+        summary: "Adding 8 MB Alt-RAM and flashable TOS to the Mega ST, switching between EmuTOS and TOS 1.04."
+        href: "/retro/storm-cloudy/"
+      - title: "🧠 MonSTerBoard"
+        summary: "How the MonSTerBoard turns the Mega ST 4 'High' into a workstation with 8 MB TT-RAM, dual IDE and flashable TOS."
+        href: "/retro/monsterboard/"
+      - title: "🌐 NetUSBee"
+        summary: "Real internet via STinG and a USB port for FAT16 data exchange with Windows on the Mega ST 4 'High'."
+        href: "/retro/netusb/"
+      - title: "💳 SidecarTridge Multi-device"
+        summary: "An apps platform in a cartridge, adding Wi-Fi, ROM emulation and floppy/hard-disk images to the Mega ST 4 'Low'."
+        href: "/retro/sidecartridge/"
+      - title: "💾 Gotek Floppy Emulator"
+        summary: "Replacing floppy drives with cheap Gotek emulators and HxC firmware, using USB stick disk images on the Mega ST 4 'Low'."
+        href: "/retro/gotek/"
+      - title: "💽 UltraSatan"
+        summary: "Giving the Mega ST 4 'Low' a real ACSI hard disk on an SD card with the UltraSatan Mini from Lotharek."
+        href: "/retro/ultrasatan/"
+      - title: "⌨️ Eiffel Interface"
+        summary: "Connecting a PS/2 keyboard, mouse and joysticks to the Mega ST 4 'High' with the Eiffel adapter."
+        href: "/retro/eiffel/"
+      - title: "⌨️ Eiffel Pico USB"
+        summary: "The modern USB-based Eiffel successor, bringing USB keyboard, mouse and joysticks to the Mega ST. Configured, not yet installed."
+        href: "/retro/eiffel-pico/"
   - heading: "Amiga Corner"
     cards:
-      - title: "💾 AmigaOS on Modern Platforms"
+      - title: "⚔️ Vampire, A600GS or MiSTer"
-        summary: "Running AmigaOS 3.2.3 on MiSTer FPGA versus Amiberry on a Raspberry Pi, and the HDF pitfalls to avoid."
+        summary: "Why comparing modern Amiga hardware options by benchmark numbers alone is actively misleading, and how I run my Amiga today."
         href: "/retro/amiga-modern-platforms/"
+      - title: "💾 Running AmigaOS in 2026"
+        summary: "MiSTer FPGA versus Amiberry on a Raspberry Pi, two very different ways to get a fully working AmigaOS 3.2.3 desktop today."
+        href: "/retro/amiga-hardware-landscape/"
       - title: "🥧 The PiMiga Journey"
         summary: "Three generations of the PiMiga distro compared, and why the newest release isn't automatically the best one."
         href: "/retro/pimiga-journey/"
-      - title: "⚔️ Vampire, A600GS or MiSTer"
-        summary: "Why comparing modern Amiga hardware by benchmark numbers alone is actively misleading."
-        href: "/retro/amiga-hardware-landscape/"
       - title: "📦 The A1200"
         summary: "What's confirmed so far about Retro Games Ltd.'s upcoming Amiga 1200 console, ahead of its 2026 launch."
         href: "/retro/the-a1200/"
@@ -47,7 +71,7 @@ sections:
   - heading: "DOS & PC"
     cards:
       - title: "💻 The 486 DX2-66"
-        summary: "A complete DOS environment rebuilt 1:1 on MiSTer FPGA, down to the original AUTOEXEC.BAT."
+        summary: "Rebuilding a DOS era from memory on MiSTer FPGA, recreating the environment the way it felt back then."
         href: "/retro/dos-486-tower/"
   - heading: "Overview"
     cards:
@@ -56,6 +80,7 @@ sections:
         href: "/retro/retro-corner-snapshot/"
 
 ---
+<h1>Retro Computing</h1>
 <p class="site-intro">Hardware I've collected and kept running over the years. From Atari ST and Amiga to MiSTer FPGA and DOS environments.</p>
 
 {% include "card-grid.njk" %}

retro/mini-arcade-handheld-roundup/index.njk

@@ -13,11 +13,11 @@ parent: "/retro/"
 
 <h2>What to Watch For</h2>
 <ul>
-<li><strong>The bootleg trap</strong> — devices built around VT369-style chips (NES-compatible, not real arcade hardware) often bundle 200+ "games" that turn out to be unlicensed clones and homebrew hacks, cataloged in enthusiast bootleg-game wikis. No Pac-Man, no Donkey Kong, just look-alikes.</li>
+<li><strong>The bootleg trap</strong>, devices built around VT369-style chips (NES-compatible, not real arcade hardware) often bundle 200+ "games" that turn out to be unlicensed clones and homebrew hacks, cataloged in enthusiast bootleg-game wikis. No Pac-Man, no Donkey Kong, just look-alikes.</li>
-<li><strong>Genuinely licensed compact options</strong> — devices built around real Namco or SNK licenses deliver actual classics (Pac-Man, Galaga, Dig Dug, dozens of Neo Geo titles) with premium displays, at a similar price point to the bootleg boxes.</li>
+<li><strong>Genuinely licensed compact options</strong>, devices built around real Namco or SNK licenses deliver actual classics (Pac-Man, Galaga, Dig Dug, dozens of Neo Geo titles) with premium displays, at a similar price point to the bootleg boxes.</li>
-<li><strong>Expandable options</strong> — some cabinet-style devices accept extra MAME ROMs via SD card, letting you add real arcade classics after the fact — the one feature the bootleg boxes almost never offer without heavy soldering.</li>
+<li><strong>Expandable options</strong>, some cabinet-style devices accept extra MAME ROMs via SD card, letting you add real arcade classics after the fact, the one feature the bootleg boxes almost never offer without heavy soldering.</li>
-<li><strong>The maximalist route</strong> — a Raspberry Pi running RetroPie, or a MiSTer FPGA setup, both scale to tens of thousands of games or hardware-accurate arcade cores respectively, at the cost of more setup effort.</li>
+<li><strong>The maximalist route</strong>, a Raspberry Pi running RetroPie, or a MiSTer FPGA setup, both scale to tens of thousands of games or hardware-accurate arcade cores respectively, at the cost of more setup effort.</li>
 </ul>
 
-<p class="redacted-note">If a mini-arcade's game list reads like a string of titles you've genuinely never heard of, that's the tell. Real arcade classics have instantly recognisable names — bootlegs hide behind vague, generic-sounding ones.</p>
+<p class="note">If a mini-arcade's game list reads like a string of titles you've genuinely never heard of, that's the tell. Real arcade classics have instantly recognisable names, bootlegs hide behind vague, generic-sounding ones.</p>
 </div>

retro/mist-mister-fpga/index.njk

@@ -9,15 +9,15 @@ parent: "/retro/"
 <h1>MiST and MiSTer: Two FPGA Boxes, Two Very Different Personalities</h1>
 <div class="detail-content">
 
-<p>Both boards run classic computers as hardware-accurate FPGA cores rather than software emulation, but living with them side by side reveals they're not interchangeable — each one is simply better at certain jobs.</p>
+<p>Both boards run classic computers as hardware-accurate FPGA cores rather than software emulation, but living with them side by side reveals they're not interchangeable, each one is simply better at certain jobs.</p>
 
 <h2>Division of Labour</h2>
 <ul>
-<li><strong>MiST for Atari ST</strong> — older and more limited in scope than MiSTer, but its ST/STE core is rock solid. It's the default choice for anything Atari, paired with a network-capable configuration for file transfers.</li>
+<li><strong>MiST for Atari ST</strong>, older and more limited in scope than MiSTer, but its ST/STE core is rock solid. It's the default choice for anything Atari, paired with a network-capable configuration for file transfers.</li>
-<li><strong>MiSTer for everything else</strong> — Amiga, DOS (via the AO486 core), and a huge library of other systems. Its Atari ST core, oddly, is the less reliable one of the two boards — reason enough to keep MiST around instead of retiring it.</li>
+<li><strong>MiSTer for everything else</strong>, Amiga, DOS (via the AO486 core), and a huge library of other systems. Its Atari ST core, oddly, is the less reliable one of the two boards, reason enough to keep MiST around instead of retiring it.</li>
-<li><strong>Native resolution ceiling</strong> — both boards only emulate the original Shifter chip on Atari ST: Low-Res (320×200), Medium-Res (640×200), and High-Res (640×400 mono). No ET4000-style graphics card emulation is on the table; a Falcon030 core with higher native resolutions has been rumoured for years without shipping.</li>
+<li><strong>Native resolution ceiling</strong>, both boards only emulate the original Shifter chip on Atari ST: Low-Res (320×200), Medium-Res (640×200), and High-Res (640×400 mono). No ET4000-style graphics card emulation is on the table; a Falcon030 core with higher native resolutions has been rumoured for years without shipping.</li>
-<li><strong>Known rough edges</strong> — accessory programs loading but not appearing on the desktop, and disabled XBOOT support, are still open items to chase down on the MiST side.</li>
+<li><strong>Known rough edges</strong>, accessory programs loading but not appearing on the desktop, and disabled XBOOT support, are still open items to chase down on the MiST side.</li>
 </ul>
 
-<p class="redacted-note">The takeaway after months of use: don't assume the shinier, newer board wins every category. Sometimes the "older" FPGA implementation is simply the more mature one for a specific chipset.</p>
+<p class="note">The takeaway after months of use: don't assume the shinier, newer board wins every category. Sometimes the "older" FPGA implementation is simply the more mature one for a specific chipset.</p>
 </div>

retro/monsterboard/index.njk

@@ -0,0 +1,49 @@
+---
+title: "The MonSTerBoard: Alt-RAM, IDE and Flashable TOS for the Mega ST"
+section: "retro"
+tags: "retro"
+description: "How the MonSTerBoard adds 8 MB of TT-RAM, dual IDE and flashable TOS to my Atari Mega ST 4 'High' workstation."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>The MonSTerBoard: Alt-RAM, IDE and Flashable TOS for the Mega ST</h1>
+<div class="detail-content">
+
+<p>My <a href="/retro/atari-mega-st-fleet/">Mega ST 4 "High"</a> workstation is built around the MonSTerBoard, an upgrade board from Alan Hourihane that sits on the MegaBus and adds 8 MB of TT-RAM, dual IDE interfaces and a 2 MB flashable TOS to any Atari ST, STe, Mega ST or Mega STe, hence the name. It's the board that turns the "High" machine into a genuine multitasking workstation.</p>
+
+<h2>What the MonSTerBoard adds</h2>
+<ul>
+<li><strong>8 MB of TT-RAM</strong>, alternate memory usable with TOS 2.06, MiNT and MagiC. Configurable via the M_ALTRAM program, which then goes into the auto-start folder.</li>
+<li><strong>Dual IDE interfaces</strong>, two IDE connections on the board, ideal for a CompactFlash or IDE-SD adapter as mass storage.</li>
+<li><strong>Flashable TOS (2 MB)</strong>, a 2 MB flash chip that can hold up to four TOS images, so you can switch operating systems in software.</li>
+<li><strong>Optional real-time clock</strong>, a connector for an RTC module based on the Dallas DS1338 (already present on Mega ST/Mega STE mainboards).</li>
+<li><strong>512K EmuTOS and flash disk support</strong>, the spare flash space can even hold a fast boot disk or an EmuTOS image.</li>
+</ul>
+
+<p>The heart of the board is a Xilinx XC9572XL CPLD that ties it all together. For a Mega ST, the board needs a separate MegaBus adapter board, also available from Alan.</p>
+
+<h2>Installation</h2>
+<p>Installation is fairly straightforward. For a Mega ST, plug the MonSTerBoard together with the adapter onto the MegaBus, connect the power supply and run a cable to pin 10 of the ACSI port. One thing that catches people out: the original TOS ROMs on the mainboard must be removed, otherwise the machine keeps booting the old TOS instead of the one on the flash board.</p>
+
+<h2>The jumper block</h2>
+<p>The board has an 18-pin jumper block. The top row is 3.3V, the bottom row is GND, and combined with the middle row they set the options. From left to right: TOSSEL, FLASHSW, FLASHON, IDESW, SCL and SDA.</p>
+<ul>
+<li><strong>TOSSEL</strong>, for STFM/Mega ST with TOS 1.xx: jumper to GND boots from 0xE00000 (e.g. TOS 2.xx), jumper to 3.3V boots from 0xFC0000 (e.g. TOS 1.xx).</li>
+<li><strong>FLASHSW</strong>, swaps the second 1 MB of the flash chip between the 0xE00000 and 0xFC0000 windows, so you can flash the other operating system.</li>
+<li><strong>FLASHON</strong>, disables access to the flash for recovery mode, so the original ROMs can be reinstalled if needed.</li>
+<li><strong>IDESW</strong>, swaps the first and second IDE interfaces.</li>
+<li><strong>SCL/SDA</strong>, connection for the RTC module.</li>
+</ul>
+
+<h2>Software</h2>
+<p>Alan provides three programs for the MonSTerBoard: M_FLASH.ZIP to write the onboard flash, M_ALTRAM.ZIP to configure the RAM (2, 4, 6 or 8 MB, then placed in the auto-start folder), and M_RTC.ZIP for the Dallas RTC module. In total you can install four TOS versions: two 192 KB and two 256 KB images.</p>
+
+<h2>My Setup</h2>
+<p>In my Mega ST 4 "High" machine the MonSTerBoard provides the 8 MB of TT-RAM that TOS 2.06 and Geneva use for real multitasking. For storage I use the dual IDE interface, with a CompactFlash card attached and booting the system directly from it. There's no ACSI hard drive connected in this machine; the IDE boot is noticeably faster than an ACSI drive would be. Combined with the <a href="/retro/et4000-experiment/">ET4000 graphics card</a> and its dedicated monitor, it's the most capable machine in the fleet.</p>
+
+<h2>Sources</h2>
+<ul>
+<li><a href="https://www.jungsi.de/monster-atari-st/" target="_blank">MonSTer [Atari ST] - Jungsi's Corner (installation guide)</a></li>
+<li><a href="https://www.atarikit.co.uk/monster/monster.html" target="_blank">MonSTer order form - AtariKit (official page)</a></li>
+</ul>
+</div>

retro/netusb/index.njk

@@ -0,0 +1,36 @@
+---
+title: "NetUSBee: STinG, Real Internet and USB for the Mega ST"
+section: "retro"
+tags: "retro"
+description: "How the NetUSBee adds STinG networking, real internet and a USB port to my Atari Mega ST 4 'High', plus FAT16 USB stick transfer with Windows."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>NetUSBee: STinG, Real Internet and USB for the Mega ST</h1>
+<div class="detail-content">
+
+<p>My <a href="/retro/atari-mega-st-fleet/">Mega ST 4 "High"</a> workstation uses a NetUSBee, a network card with two USB ports that plugs into the Atari's cartridge (ROM) port. It's what gives the machine real internet access via STinG, and the USB port lets me swap data with a modern Windows PC using a simple FAT16 USB stick.</p>
+
+<h2>What the NetUSBee adds</h2>
+<ul>
+<li><strong>Ethernet networking</strong>, a RTL8019AS network chip (the same one used by EtherNEC), giving the ST genuine network and internet access.</li>
+<li><strong>Two USB ports</strong>, an ISP1160 USB controller (as used in EtherNAT), supporting USB mice, keyboards and, importantly, USB mass storage.</li>
+<li><strong>Optional IRQ line</strong>, to speed up transfers and free up CPU time for applications.</li>
+<li><strong>Compatibility</strong>, works with ST(e), Mega ST(e), Falcon and TT, connecting via the cartridge/ROM port.</li>
+</ul>
+
+<h2>Real Internet with STinG</h2>
+<p>For networking I use the STinG TCP/IP stack together with the <code>enec.stx</code> (or <code>enec3.stx</code> for 68030) network card driver. Once configured, the Mega ST gets a real IP address on the network and can reach the internet, connecting the 1980s machine to modern services. The original NetUSBee was developed by Candle'O'Sin, and the current production runs are sold by Lotharek in a sturdy grey metal case that matches the Atari look.</p>
+
+<h2>Exchanging Data with Windows via USB</h2>
+<p>The USB port is particularly handy for data exchange. I use a FAT16-formatted USB stick, which the ST can read and write through the USB mass-storage driver. Because FAT16 is also readable on a modern Windows PC, I can transfer files between the Atari and a Windows machine just by moving the stick between them, no special cables or network tricks required.</p>
+
+<h2>My Setup</h2>
+<p>In my Mega ST 4 "High" machine the NetUSBee sits in the cartridge port, working alongside the <a href="/retro/monsterboard/">MonSTerBoard</a> that handles IDE storage and Alt-RAM. It rounds out the machine as a true workstation: real internet via STinG, USB storage for file exchange, fast IDE boot from a CompactFlash card, and the ET4000 driving a dedicated monitor.</p>
+
+<h2>Sources</h2>
+<ul>
+<li><a href="https://www.jungsi.de/retro-atari-st-netusbee/" target="_blank">NetUSBee [Atari ST] - Jungsi's Corner (installation guide)</a></li>
+<li><a href="https://lotharek.pl/productdetail.php?id=46" target="_blank">Netusbee - Lotharek (order page, firmware and drivers)</a></li>
+</ul>
+</div>

retro/pimiga-journey/index.njk

@@ -2,7 +2,7 @@
 title: "PiMiga 3 to 5: Chasing the Perfect Amiga-on-a-Pi Distro"
 section: "retro"
 tags: "retro"
-description: "Three generations of PiMiga later, here's what actually changed — and why newer isn't always better."
+description: "Three generations of PiMiga later, here's what actually changed, and why newer isn't always better."
 layout: base.njk
 parent: "/retro/"
 ---
@@ -13,11 +13,11 @@ parent: "/retro/"
 
 <h2>What Changed Across Versions</h2>
 <ul>
-<li><strong>PiMiga 3.0 (2022)</strong> — the original recipe: Amiberry under DietPi with an XFCE desktop and the iGame v2 launcher. Now effectively retired, with no further updates.</li>
+<li><strong>PiMiga 3.0 (2022)</strong>, the original recipe: Amiberry under DietPi with an XFCE desktop and the iGame v2 launcher. Now effectively retired, with no further updates.</li>
-<li><strong>PiMiga 4.0 (2024)</strong> — brought multi-architecture support (ARM and Intel/AMD) and swapped in the MegaAGS launcher, with roughly 4,800 games pre-installed. Its biggest strength: MegaAGS ships with strong trainer/cheat support baked into its game profiles.</li>
+<li><strong>PiMiga 4.0 (2024)</strong>, brought multi-architecture support (ARM and Intel/AMD) and swapped in the MegaAGS launcher, with roughly 4,800 games pre-installed. Its biggest strength: MegaAGS ships with strong trainer/cheat support baked into its game profiles.</li>
-<li><strong>PiMiga 5.0 (Dec 2025, final release)</strong> — the creator's last planned version. Switches back to the simpler iGame v2 launcher, drops in 600+ auto-switching backdrops, and adds native support for the newest Pi hardware — but loses much of the trainer-focused depth that made version 4 so useful for casual replay sessions.</li>
+<li><strong>PiMiga 5.0 (Dec 2025, final release)</strong>, the creator's last planned version. Switches back to the simpler iGame v2 launcher, drops in 600+ auto-switching backdrops, and adds native support for the newest Pi hardware, but loses much of the trainer-focused depth that made version 4 so useful for casual replay sessions.</li>
-<li><strong>The real decision criterion</strong> — not "which is newest" but "do I care more about trainers/cheats (stick with v4's MegaAGS) or about the latest hardware support and polish (go with v5's iGame)". Running both on separate SD cards sidesteps the choice entirely.</li>
+<li><strong>The real decision criterion</strong>, not "which is newest" but "do I care more about trainers/cheats (stick with v4's MegaAGS) or about the latest hardware support and polish (go with v5's iGame)". Running both on separate SD cards sidesteps the choice entirely.</li>
 </ul>
 
-<p class="redacted-note">Also worth knowing: getting the display right on an older 4:3 monitor is almost never a Raspberry Pi config.txt problem — it's nearly always an Amiberry/X11 scaling setting. Check the emulator's Integer Scaling option before touching boot config files.</p>
+<p class="note">Also worth knowing: getting the display right on an older 4:3 monitor is almost never a Raspberry Pi config.txt problem, it's nearly always an Amiberry/X11 scaling setting. Check the emulator's Integer Scaling option before touching boot config files.</p>
 </div>

retro/retro-corner-snapshot/index.njk

@@ -2,31 +2,52 @@
 title: "The Retro Corner Today: A Snapshot of the Whole Setup"
 section: "retro"
 tags: "retro"
-description: "A tour through every retro system currently active across the home, room by room."
+description: "A tour through every retro system currently in the home, which ones are set up and running, and which are boxed and ready to use."
 layout: base.njk
 parent: "/retro/"
 ---
 <h1>The Retro Corner Today: A Snapshot of the Whole Setup</h1>
 <div class="detail-content">
 
-<p>What started with childhood memories of an Atari ST and an Amiga 500 turned into a full-blown home retro-computing corner after 2020. Here's what's actually running right now, spread across two rooms plus a handful of portable devices.</p>
+<p>What started with childhood memories of an Atari ST and an Amiga 500 turned into a full-blown home retro-computing corner after 2020. Here's a snapshot of the whole setup, which machines are actually set up and running right now, and which are boxed and ready to use on demand.</p>
 
-<h2>Room by Room</h2>
+<h2>The study</h2>
+<p>The study holds the bulk of the serious gear. The <a href="/retro/mist-mister-fpga/">MiSTer FPGA</a> and the MiST FPGA are set up here, both connected to a <a href="https://www.nec-display.com/" target="_blank">NEC 1970NXp</a>. The <a href="/retro/atari-mega-st-fleet/">Mega ST 4 "Low"</a> machine is set up and running on a <a href="https://www.amazon.de/dp/B0957KH8X7/" target="_blank">Dell SE2722HX 27</a> that handles 15kHz, serving as the demo- and game-machine.</p>
+<p>The rest of the Atari hardware is stored here but not set up, mainly for lack of space:</p>
 <ul>
-<li><strong>The office</strong> — home base for the serious gear: three Atari Mega ST 4 machines plus a Mega ST 2, a MiSTer FPGA covering Amiga/DOS/arcade cores, and a MiST FPGA dedicated to Atari ST. A Raspberry Pi 400 running Hatari and PiMiga rounds things out as the flexible, high-resolution alternative to hardware that can't quite keep up on screen quality.</li>
+<li><strong>The Mega ST 4 "High"</strong>, the upgraded workstation, is boxed and can be set up on demand. It has its own EIZO FlexScan L365 15-inch monitor for the ET4000, and when I use it I set it up in the living room on the dining table. The L365 is a genuinely good 15-inch panel, with a sharp 1024×768 image and wide viewing angles that make it a great fit for high-resolution Atari desktop work, and it does the ET4000's output justice.</li>
-<li><strong>The living room</strong> — a Batocera box for casual, couch-friendly sessions across dozens of systems, from Atari ST to arcade to consoles, no FPGA timing precision required.</li>
+<li><strong>The heirloom Mega ST 4</strong>, kept factory-original, is not set up.</li>
-<li><strong>On the move</strong> — a small collection of handheld emulation devices for retro gaming away from a screen.</li>
+<li><strong>The Mega ST 2</strong>, the spare and donor machine, is not set up.</li>
-<li><strong>The focus, unmistakably</strong> — Amiga and Atari ST are the heart of the collection; everything else (DOS, arcade, handhelds) exists to fill in the gaps around those two platforms.</li>
 </ul>
 
-<h2>The office setup in detail</h2>
+<h2>Why the EIZO FlexScan L365 is a great fit</h2>
-<p>The office houses the main retro computing workstation. The three Mega ST 4 machines each have a defined role: one runs GEM-based productivity software, one is set up for MIDI music production with a connected synthesizer, and one serves as the development machine for ST software. The Mega ST 2 is the backup and testing machine. The MiSTer FPGA handles Amiga and DOS emulation with near-perfect timing accuracy, while the MiST provides a dedicated Atari ST experience without the overhead of the MiSTer's larger feature set.</p>
+<p>The L365 was a genuinely premium 15-inch panel when it launched in 2001, and that quality still shows today. It was one of the brightest and most contrast-rich LCDs of its era, with 300 cd/m² brightness and a 450:1 contrast ratio, far ahead of most competitors, and it already offered gamma correction and precise colour temperature adjustment, features usually reserved for expensive CRT monitors. It also had a DVI-D digital input alongside VGA, which avoided the flicker of analogue LCDs and gave a pixel-sharp image.</p>
+<p>For retro computing it's ideal. Its native 1024×768 at 4:3 matches the classic Atari/DOS desktop resolutions, and its high-quality scaling chip upscales lower resolutions like 640×480 or 800×600 far more cleanly than cheap monitors from the same era. And EIZO built it for round-the-clock industrial and office use, so after more than 20 years it still runs perfectly without noticeable backlight degradation. That's exactly what you want driving the ET4000 in the "High" machine.</p>
 
-<h2>The living room setup</h2>
+<h2>The NEC MultiSync LCD1970NXp: a different class</h2>
-<p>The Batocera box in the living room takes a completely different approach — it's not about hardware authenticity, it's about convenience. A compact PC boots directly into the Batocera frontend, providing a console-like experience for casual retro gaming on the TV. Controllers are wireless, the interface is controller-friendly, and the focus is on games that work well from a couch rather than demos or productivity software that needs a keyboard and mouse.</p>
+<p>The NEC MultiSync LCD1970NXp, released around 2005/2006, is a different machine class entirely and a clear step up from the EIZO L365. It's a larger 19-inch panel in 5:4 format with a higher 1280×1024 resolution, and its strength lies in a premium panel combined with unusual versatility for retro hardware.</p>
+<p>Unlike cheap TN panels, it uses a high-quality panel with enormous viewing-angle stability, 176 degrees in both directions, so colours don't shift or darken when you view it from an angle or above. Its typical 800:1 contrast ratio, nearly double the EIZO's, delivers deep blacks and strong colours for its era.</p>
+<p>What really makes it legendary among retro enthusiasts is its 15kHz support. Most LCD monitors only accept analogue VGA signals from 31kHz up, but the 1970NXp is one of the rare exceptions that handles genuine 15kHz. That lets you connect an Amiga 500/1200, Atari ST or old arcade boards directly over a VGA cable without a pricey upscaler and get a stable picture. It also has solid ergonomics, an ErgoDesign stand with a very smooth 110mm height adjustment and integrated cable management.</p>
+
+<h2>The two monitors compared</h2>
+<table>
+<tr><th>Spec</th><th>EIZO FlexScan L365 (2001)</th><th>NEC MultiSync LCD1970NXp (2005)</th></tr>
+<tr><td>Size</td><td>15-inch (compact)</td><td>19-inch (large)</td></tr>
+<tr><td>Resolution</td><td>1024×768 (4:3)</td><td>1280×1024 (5:4)</td></tr>
+<tr><td>Contrast</td><td>450:1</td><td>800:1</td></tr>
+<tr><td>Viewing angle</td><td>Good for 2001</td><td>Excellent (176°)</td></tr>
+<tr><td>Special extra</td><td>Very sharp DOS scaler</td><td>15kHz support for Amiga/arcade</td></tr>
+</table>
+<p>The EIZO is ideal if you want the typical, space-saving look of the first LCD generation for an original Windows 98 machine. The NEC is the technically more modern, larger and far more versatile all-rounder, especially valuable for home-computer enthusiasts who need 15kHz support for Amiga and similar systems. Both are excellent, just in different roles.</p>
+
+<h2>The living room</h2>
+<p>The <a href="/retro/batocera-living-room/">Batocera box</a> is the couch-friendly setup for casual sessions across dozens of systems, no FPGA timing precision required. The Raspberry Pi 400 (running Hatari and <a href="/retro/pimiga-journey/">PiMiga</a>) also lives here, connected to a small NEC 18-inch monitor as the flexible, high-resolution alternative to the original hardware. The <a href="/retro/the-a1200/">A1200</a> console is on pre-order and will join this setup.</p>
+
+<h2>On the move</h2>
+<p>Outside the two rooms there's a small collection of <a href="/retro/mini-arcade-handheld-roundup/">handheld emulation devices</a> for retro gaming away from a screen.</p>
 
 <h2>How it all connects</h2>
 <p>All machines share the same network infrastructure, with FTP access to the NAS for file transfers. Disk images and software archives are stored centrally and served to individual machines as needed. The MiSTer and MiST both use SD cards for storage, while the original hardware uses CompactFlash adapters or SCSI-to-IDE bridges depending on the machine. The Raspberry Pi 400 accesses the same NFS shares as the other Pis in the flat.</p>
 
-<p class="redacted-note">The honest status update: several open items remain — documenting the exact handheld models, and waiting on the A1200 Mini pre-order. Retro computing, it turns out, is never really "done."</p>
+<p class="note">The honest status update: several open items remain, documenting the exact handheld models, and the full-size <a href="/retro/the-a1200/">A1200</a> is on pre-order ahead of its 4 December 2026 launch. Retro computing, it turns out, is never really "done."</p>
 </div>

retro/sidecartridge/index.njk

@@ -0,0 +1,47 @@
+---
+title: "SidecarTridge Multi-device: An Apps Platform in a Cartridge"
+section: "retro"
+tags: "retro"
+description: "How the SidecarTridge Multi-device turns the cartridge port of my Atari Mega ST 4 'Low' into an apps platform for floppy, hard disk, ROM and Wi-Fi."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>SidecarTridge Multi-device: An Apps Platform in a Cartridge</h1>
+<div class="detail-content">
+
+<p>My <a href="/retro/atari-mega-st-fleet/">Mega ST 4 "Low"</a> machine uses a SidecarTridge Multi-device, a small board with a Raspberry Pi Pico W inside that plugs into the cartridge port and turns the Atari into an apps platform. It brings Wi-Fi and a microSD slot to the machine and runs a growing catalog of modular apps, no soldering and no internal mods required. I bought the original Revision 0 back in late 2023/early 2024, and I've since picked up the new Revision 3 as well.</p>
+
+<h2>What it does</h2>
+<p>The SidecarTridge Multi-device works in any Atari ST, STE, Mega, TT or Falcon. A Raspberry Pi Pico W inside brings Wi-Fi and a microSD slot, and the board interacts with the cartridge bus in real time to emulate a range of devices:</p>
+<ul>
+<li><strong>ROM emulation</strong>, load 64K or 128K cartridge ROMs from microSD or over Wi-Fi and swap them on the fly.</li>
+<li><strong>Drives emulator</strong>, floppy and hard-disk emulation from a microSD card, so you can boot any image without a mechanical floppy drive.</li>
+<li><strong>Browser</strong>, search floppy images directly from the ST over Wi-Fi and boot them, with no PC in the middle.</li>
+<li><strong>MIDI-to-IP</strong>, bridge the ST's MIDI port to the internet, so networked MIDI works against players anywhere.</li>
+<li><strong>Real-time clock</strong>, plus other apps, all switchable without reflashing.</li>
+</ul>
+
+<h2>An apps platform, not just an emulator</h2>
+<p>Firmware V2 reworks the device into an apps platform. Instead of one fixed mode, it runs a catalog of modular apps you can switch between in seconds, with over-the-air updates and per-app configuration. The hardware and firmware are open source on GitHub, so the community keeps adding new apps and the Atari keeps gaining capabilities.</p>
+
+<h2>How it works</h2>
+<p>Setup takes about ten minutes. Slide the Multi-device into the cartridge port, power on, and on first boot it exposes its own SIDECART Wi-Fi network. You join it from a phone or laptop, pick your home Wi-Fi, and from then on the device joins your network automatically. Once connected it shows a QR code with its IP, which opens a web UI listing every installed app, and you pick what your ST should become. On the "Low" machine I use it for the ROM and floppy side of things, alongside the <a href="/retro/storm-cloudy/">Cloudy/Storm ST combo</a> and the Gotek for disk-image swapping.</p>
+
+<h2>Revision 0 vs. Revision 3</h2>
+<p>My Revision 0 is the very first version sold at the end of 2023/start of 2024, and it's the one in use on the "Low" machine. The new Revision 3 is a complete redesign that addresses feedback from early buyers. Functionally both run the same firmware and do the same things, but the v3 is noticeably improved:</p>
+<ul>
+<li><strong>Size and stability</strong>, the Rev 0 was a long, wide 2-layer board that stuck out and could flex if knocked. The v3 is a much more compact 4-layer board that sits more discreetly and doesn't flex.</li>
+<li><strong>Signal quality</strong>, the Rev 0 used simple tinned (HASL) contacts, which can oxidise over time on the sensitive Mega ST bus and cause sudden crashes. The v3 uses a high-quality ENIG gold finish plus two inner copper layers for cleaner power, so transfers run flawlessly.</li>
+<li><strong>Wi-Fi reception</strong>, on the Rev 0 the antenna sat over normal traces that dampened the radio signal, so the connection could drop if the ST was in a bad spot. The v3 has a copper clearance area under the antenna for a stronger, more stable connection.</li>
+<li><strong>Power draw</strong>, the Rev 0 loads the aging 5V rail a bit more. The v3 was optimised to draw noticeably less and run more efficiently.</li>
+<li><strong>Layout and Pico W mounting</strong>, on the Rev 0 the buttons and connectors were in the original spots and the Pico W had to be soldered on tall pin headers. The v3 repositions the buttons ergonomically and lets the Pico W be soldered flat, plus adds JST sockets for external buttons without soldering.</li>
+</ul>
+
+<h2>My Setup</h2>
+<p>The original Revision 0 SidecarTridge is in use on the Mega ST 4 "Low" machine. The new Revision 3 I've bought but not yet installed, so it's still sitting alongside the other uninstalled extensions until I decide where to use it.</p>
+
+<h2>Sources</h2>
+<ul>
+<li><a href="https://sidecartridge.com/products/sidecartridge-multidevice-atari-st/" target="_blank">SidecarTridge Multi-device for Atari ST - official product page</a></li>
+</ul>
+</div>

retro/storm-cloudy/index.njk

@@ -0,0 +1,42 @@
+---
+title: "Storm ST & Cloudy ST: Flashable TOS and Alt-RAM for the Mega ST"
+section: "retro"
+tags: "retro"
+description: "Installing the Storm ST (8 MB Alt-RAM) and Cloudy ST (flashable TOS) combo in my Atari Mega ST, switching between EmuTOS and PP's improved iTOS 1.04."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>Storm ST &amp; Cloudy ST: Flashable TOS and Alt-RAM for the Mega ST</h1>
+<div class="detail-content">
+
+<p>I just installed the new Storm ST and Cloudy ST combo in my <a href="/retro/atari-mega-st-fleet/">Mega ST 4 "Low"</a> machine. Now I can switch from EmuTOS 1.0.1 to PP's improved <a href="https://atari.8bitchip.info/tosimprgu.html" target="_blank">iTOS 1.04</a> and also have 8 MB of Alt-RAM under EmuTOS.</p>
+
+<h2>The Cloudy ST</h2>
+<p>The Cloudy ST is an extremely compact TOS adapter for Atari ST, STM, STF, STFM and Mega ST. It allows you to switch between two TOS ROMs: one ROM comes with EmuTOS preinstalled, the other one can be flashed via software, for example with TOS 2.06 or TOS 1.0x. It works together with the <a href="https://wiki.newtosworld.de/index.php?title=Storm_ST" target="_blank">Storm ST</a> and/or the Lightning ST, needs an address decoder (hexE00000) which the Storm ST provides, and is fully compatible with TOS 2.06, EmuTOS and TOS 1.00 - 1.04 (on mainboards that support 1 Mbit ROMs).</p>
+
+<h2>The Storm ST</h2>
+<p>The Storm ST is a compact add-on for the Atari ST, STM, STF, STFM and Mega ST that adds 8 megabytes of alternate RAM, usable with TOS 2.06, EmuTOS and MagiC. (Alternate RAM is not supported by TOS 1.x.) It also provides the address decoder for TOS 1.0x, 2.0x and EmuTOS, making it the perfect companion for the Cloudy's flashable TOS board, plus a connector for an optional real-time clock. With EmuTOS, Alt-RAM and the RTC are detected and used automatically with no software required.</p>
+
+<h2>My Setup</h2>
+<p>With the Storm ST and Cloudy ST combo in place, the machine boots into EmuTOS 1.0.1 with all 8 MB of Alt-RAM available, or switches over to PP's improved iTOS 1.04 for maximum software compatibility with games and demos from the era. iTOS 1.04 adds real FAT16 filesystem support, so it works much better with hard disks and mass storage, plus a few welcome extras on top of the classic TOS 1.04 behaviour. It's the best of both worlds: the modern conveniences of EmuTOS combined with the improved, authentic-feeling iTOS.</p>
+
+<h2>Gallery</h2>
+<img src="storm-cloudy-1.jpg" alt="Storm ST and Cloudy ST installed in the Mega ST" width="590" height="443">
+<p class="caption">The Storm ST and Cloudy ST combo installed in the Mega ST.</p>
+
+<img src="storm-cloudy-2.jpg" alt="Storm ST and Cloudy ST board detail" width="590" height="443">
+<p class="caption">Close-up of the Storm ST and Cloudy ST boards.</p>
+
+<img src="storm-cloudy-3.jpg" alt="Storm ST and Cloudy ST with wiring" width="590" height="443">
+<p class="caption">The Storm ST and Cloudy ST with their wiring in place.</p>
+
+<img src="storm-cloudy-4.jpg" alt="Storm ST and Cloudy ST final install" width="590" height="443">
+<p class="caption">The finished installation in the Mega ST.</p>
+
+<h2>Sources</h2>
+<ul>
+<li><a href="https://wiki.newtosworld.de/index.php?title=Storm_ST" target="_blank">Storm ST - Atari Wiki-NEU</a></li>
+<li><a href="https://wiki.newtosworld.de/index.php?title=Cloudy" target="_blank">Cloudy - Atari Wiki-NEU</a></li>
+<li><a href="https://atari.8bitchip.info/tosimprgu.html" target="_blank">TOS improving (iTOS) - PP's Atari page</a></li>
+</ul>
+</div>

retro/the-a1200/index.njk

@@ -1,54 +1,64 @@
 ---
-title: "The A1200: What We Know Before It Ships"
+title: "The A1200: Release Date, Specs and What's Included"
 section: "retro"
 tags: "retro"
-description: "A close look at Retro Games Ltd.'s upcoming Amiga 1200 console, based on everything public so far."
+description: "The A1200 by Retro Games ships 4 December 2026 with Workbench 3.1, AGA/OCS/ECS/RTG emulation and 25 pre-installed games. All the confirmed specs, as of September 2026."
 layout: base.njk
 parent: "/retro/"
 ---
-<h1>The A1200: What We Know Before It Ships</h1>
+<h1>The A1200: Release Date, Specs and What's Included</h1>
+<p><em>Last updated: 11 September 2026</em></p>
 <div class="detail-content">
 
-<p>Retro Games Ltd. opened pre-orders for The A1200 in November 2025, with delivery slated for June 2026 at a suggested price of 189.99 Euro. As with their previous mini-consoles, official details have trickled out slowly — deliberately, it seems.</p>
+<p>Retro Games Ltd. has been drip-feeding details about The A1200, a full-size reimagining of the classic Amiga 1200, for well over a year. Since the summer, most of the open questions have been answered officially, so this is a summary of everything that's now confirmed, as of September 2026.</p>
 
-<h2>What's Confirmed So Far</h2>
+<h2>Release date and price</h2>
+<p>The A1200 was originally announced with a June 2026 delivery, but was pushed back several times. It now launches on <strong>Friday 4 December 2026</strong> at a suggested price of <strong>189.99 Euro</strong>. A USB-C power cable is included, but the AC adapter is not, so you'll need your own power supply or a phone charger.</p>
+
+<h2>Workbench and software</h2>
+<p>The biggest addition since the initial announcement is that the machine ships with <strong>Workbench 3.1</strong> pre-installed and ready to boot. This means it's not just a games machine, you can also run Amiga productivity and creative software right out of the box. Via a USB stick you can load other Workbench versions, so a preferred release can be selected.</p>
+
+<h2>Emulation coverage</h2>
+<p>Rather than a single fixed core, The A1200 emulates several Amiga configurations:</p>
 <ul>
-<li><strong>Games</strong> — 25 titles pre-installed in total, with only 9 officially confirmed at time of writing: the Turrican trilogy, Defender of the Crown I & II, Beneath a Steel Sky, Lure of the Temptress, Ruff 'n' Tumble, and The Settlers II. The rest are being held back, likely on purpose, as a marketing drip-feed.</li>
+<li><strong>Amiga 1200 (AGA)</strong>, the headline machine.</li>
-<li><strong>Hardware essentials</strong> — a fully functional keyboard in the original design, a CD32-style gamepad, a tank-mouse replica, HDMI output, USB-A ports, and USB sideloading support for ADF/HDF game files.</li>
+<li><strong>Amiga 500 (OCS)</strong>, <strong>Amiga 600 (ECS)</strong> and the <strong>CD32</strong>.</li>
-<li><strong>The mystery SD slot</strong> — a slot spotted at Gamescom 2025 in the position of the original floppy drive, widely speculated to be for SD-card-based game loading, but not officially confirmed.</li>
+<li><strong>RTG support</strong>, a newly developed feature that lets compatible software run at higher screen resolutions than the original chipset allowed.</li>
-<li><strong>Expected internals</strong> — likely an Allwinner ARM SoC running Amiberry underneath (following the pattern of the earlier A500 Mini), rather than genuine 68EC020 silicon.</li>
+<li>RAM, CPU and chipset settings are adjustable, so different Amiga hardware configurations can be reproduced.</li>
+</ul>
+
+<h2>Games</h2>
+<p>There are 25 games pre-installed, launched from a simple carousel. The line-up includes Defender of the Crown I &amp; II, the Turrican trilogy, Beneath a Steel Sky, Lure of the Temptress, Ruff 'n' Tumble, The Settlers II, Slam Tilt, Rocket Ranger and the newer Amiga title Reshoot Proxima 3.</p>
+<p>Each game gets four save slots, while The Settlers II adds six in-game save slots. Controls can be remapped, assigning controller buttons and analogue inputs to keyboard, mouse and joystick functions.</p>
+
+<h2>Loading your own software</h2>
+<p>Legally acquired Amiga software can be sideloaded via USB stick. This includes full <strong>WHDLoad</strong> support as well as floppy, hard-drive and CD-ROM images. Games can be saved and resumed at any time, which helps with the punishingly difficult classics.</p>
+
+<h2>Hardware and ports</h2>
+<p>The A1200 keeps the original full-size design with a fully working keyboard. There are <strong>four USB-A ports</strong> for gamepads, joysticks, mice and USB flash drives, and third-party controllers and keyboards are supported. With an appropriate adapter, even original Amiga peripherals can be used.</p>
+<p>For display output it offers 50 Hz PAL and 60 Hz NTSC, plus scaling modes, CRT effects, smart crop and aspect ratio settings over HDMI.</p>
+
+<h2>What's in the box</h2>
+<ul>
+<li>The A1200 home computer</li>
+<li>THEMOUSE, a 2-button USB mouse</li>
+<li>THEGAMEPAD, an 8-button USB gamepad</li>
+<li>USB-C power supply cable (AC adapter not included)</li>
+<li>HDMI cable</li>
+<li>Quickstart manual</li>
 </ul>
 
 <h2>Context: where this fits in the retro landscape</h2>
-<p>The A1200 sits in a growing market of mini-consoles and FPGA recreations.
+<p>The A1200 sits in a growing market of mini-consoles and FPGA recreations. Unlike MiSTer FPGA, which aims for cycle-accurate hardware reproduction, the A1200 is a software emulation box, similar to the A500 Mini that Retro Games Ltd. released in 2022. The A500 Mini was well-received but had its quirks, and the A1200 addresses some of those criticisms, particularly with the working keyboard and expanded I/O.</p>
-Unlike MiSTer FPGA, which aims for cycle-accurate hardware reproduction,
+<p>There's a legitimate debate about software emulation versus FPGA in 2026, and some of the Amiga community is waiting for a full FPGA-based Amiga. But at 189.99 Euro, the A1200 is an approachable plug-and-play entry point that ships with a real Workbench and strong sideloading support.</p>
-the A1200 is a software emulation box — similar to the A500 Mini that
-Retro Games Ltd. released in 2022. The A500 Mini was well-received but
-had its quirks: limited game selection, no keyboard support, and an
-emulation layer that didn't quite match the original hardware in all
-cases. The A1200 appears to address some of these criticisms, particularly
-with the keyboard and expanded I/O.</p>
-
-<h2>How it compares to alternatives</h2>
-<p>For someone who wants to run Amiga software today, there are several
-options. A real A1200 with a compact flash adapter and a modern LCD
-monitor is the purist approach, but requires maintenance and debugging.
-MiSTer FPGA offers near-perfect hardware reproduction but costs
-significantly more. Amiberry on a Raspberry Pi is the budget option,
-with good compatibility but occasional timing issues. The A1200
-positions itself as a plug-and-play alternative — set it up in minutes,
-no configuration required, at the cost of some flexibility.</p>
 
 <h2>What this means for the Amiga community</h2>
-<p>If the A1200 ships on time and delivers on the promised feature set,
+<p>The original hardware is getting harder to find in good condition, and the capacitor-bomb motherboard issue means that even working units need recapping. A modern, reliable reproduction, even as software emulation, lowers the barrier significantly. The 25 pre-installed games give newcomers a curated starting point, and the USB sideloading support means the library can be expanded without hardware modifications.</p>
-it could become the default entry point for people curious about the
-Amiga. The original hardware is getting harder to find in good condition,
-and the capacitor-bomb motherboard issue means that even working units need
-recapping. A modern, reliable reproduction — even if it's software
-emulation — lowers the barrier significantly. The 25 pre-installed games
-give newcomers a curated starting point, and the USB sideloading support
-means the library can be expanded without hardware modifications.</p>
 
-<p class="redacted-note">Worth a heads-up if you're pre-ordering: not every regional shop went live on launch day, and lesser-known international retailers sometimes get product photos and details before the official site does. With a seven-month wait to delivery, there's no rush to jump on the very first listing you find.</p>
+<h2>Sources</h2>
+<ul>
+<li><a href="https://retrogames.biz/products/thea1200/" target="_blank">Retro Games: official THEA1200 product page</a></li>
+<li><a href="https://www.gamersglobal.de/news/347901/the-a1200-infos-zu-betriebssystem-unterstuetzter-peripherie-und-mehr" target="_blank">GamersGlobal: Workbench, supported peripherals and more (July 2026)</a></li>
+<li><a href="https://collectors-junkies.com/retro-games-thea1200-ab-dezember-2026/" target="_blank">Collectors-Junkies: THEA1200 from December 2026 (August 2026)</a></li>
+</ul>
 </div>
-

retro/ultrasatan/index.njk

@@ -0,0 +1,40 @@
+---
+title: "UltraSatan: ACSI Hard Disk on an SD Card for the Atari ST"
+section: "retro"
+tags: "retro"
+description: "Using the UltraSatan Mini from Lotharek to give the Atari Mega ST 4 'Low' a real ACSI hard disk on an SD card."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>UltraSatan: ACSI Hard Disk on an SD Card for the Atari ST</h1>
+<div class="detail-content">
+
+<p>My <a href="/retro/atari-mega-st-fleet/">Mega ST 4 "Low"</a> uses an UltraSatan, an ACSI-connected device that gives the Atari a real hard disk using cheap SD/MMC cards. I bought the <a href="https://lotharek.pl/productdetail.php?id=258" target="_blank">UltraSatan Mini</a> from Lotharek, a revised, compact version of the classic device.</p>
+
+<h2>What the UltraSatan is</h2>
+<p>The UltraSatan is the improved successor to the earlier SatanDisk, designed by Jookie. It connects to the ACSI port of an Atari ST and emulates a hard disk, with the storage living on SD/MMC cards. The name comes from being the "ultra" successor to the SatanDisk, and has nothing to do with the occult. Its strengths:</p>
+<ul>
+<li><strong>SD/MMC storage</strong>, cheap, quiet and reliable, replacing aging hard disks and floppies.</li>
+<li><strong>Two card slots</strong>, so it can act like two hard disks on one machine.</li>
+<li><strong>Hot-pluggable cards</strong>, SD cards can be swapped without powering off the computer.</li>
+<li><strong>Battery-backed clock</strong>, a built-in RTC to keep the Atari's clock working.</li>
+<li><strong>Multiple firmware slots</strong>, with a basic firmware so it keeps working even if a flash upgrade goes wrong.</li>
+</ul>
+
+<h2>The UltraSatan Mini</h2>
+<p>The Mini variant from Lotharek connects directly to the external ACSI port (no cable needed), supports microSD cards only, and is powered via a MicroUSB connector (a 5V phone charger is needed, not supplied). It works with the ICD PRO driver (free), HDDriver (commercial) or PeraPutnik, and you can even change the device name shown by the driver.</p>
+
+<h2>Getting it running</h2>
+<p>First use is practically plug-and-play: connect the device, switch it on, insert a prepared SD card and start the computer. The ICD driver on the card runs without problems and the desktop is set up. If you set up cards with HDDriver, make sure you use a current version, older ones threw a "Error reading partition data" error that was fixed in a later release. The card can even be made Windows-compatible, making data exchange between the Atari and a PC trivial.</p>
+
+<p>Installation details are well covered in <a href="https://www.jungsi.de/retro-atari-st-ultrasatan-lotharek/" target="_blank">Jungsi's UltraSatan article</a>, which also notes that for use in a Mega ST you can bridge two pins on the underside so the device is powered via the ACSI port, removing the need for a separate power cable.</p>
+
+<h2>My Setup</h2>
+<p>In my Mega ST 4 "Low" machine the UltraSatan Mini provides the hard-disk storage on an SD card, alongside the <a href="/retro/storm-cloudy/">Cloudy/Storm ST combo</a>, the <a href="/retro/gotek/">Gotek</a>, the <a href="/retro/sidecartridge/">SidecarTridge</a> and the <a href="/retro/atari-networking-bbs/">Wi-Fi modem</a>.</p>
+
+<h2>Sources</h2>
+<ul>
+<li><a href="https://lotharek.pl/productdetail.php?id=258" target="_blank">UltraSatan Mini - Lotharek (product page)</a></li>
+<li><a href="https://www.jungsi.de/retro-atari-st-ultrasatan-lotharek/" target="_blank">UltraSatan [Atari ST] - Jungsi's Corner (installation guide)</a></li>
+</ul>
+</div>

scripts/github-aggregator/README.md

@@ -1,7 +1,7 @@
 # GitHub aggregator
 
 Reads a `.moonweb.yml` file from each of the `skoelle` GitHub repos and
-regenerates `code/_data/repos.json`. Run manually — not wired into CI.
+regenerates `code/_data/repos.json`. Run manually, not wired into CI.
 
 ## Usage
 

shared/_includes/base.njk

@@ -5,7 +5,7 @@
   <meta name="viewport" content="width=device-width, initial-scale=1">
   <title>{{ title }}{% if 'moonweb' not in title and 'stefankoelle' not in title %} · moonweb.org{% endif %}</title>
   <meta name="description" content="{{ description }}">
-  <meta name="author" content="Stefan Koelle">
+  <meta name="author" content="Stefan Kölle">
   <meta name="theme-color" content="{% if section == 'hub' %}#3b6ea5{% elif section == 'infra' %}#99333A{% elif section == 'smarthome' %}#1f8a8a{% elif section == 'code' %}#3E5098{% elif section == 'retro' %}#8a6d3b{% else %}#3b6ea5{% endif %}">
   <link rel="canonical" href="{{ site.url }}{{ page.url }}">
   <meta property="og:title" content="{{ title }}{% if 'moonweb' not in title and 'stefankoelle' not in title %} · moonweb.org{% endif %}">
@@ -14,6 +14,7 @@
   <meta property="og:url" content="{{ site.url }}{{ page.url }}">
   <meta property="og:type" content="{% if parent %}article{% else %}website{% endif %}">
   <meta name="twitter:card" content="summary">
+  <meta name="twitter:site" content="@StefanKoelle">
   <meta name="twitter:title" content="{{ title }}{% if 'moonweb' not in title and 'stefankoelle' not in title %} · moonweb.org{% endif %}">
   <meta name="twitter:description" content="{{ description }}">
   {% if ogImage %}<meta name="twitter:image" content="{{ site.url }}{{ ogImage }}">{% endif %}
@@ -30,12 +31,12 @@
     {% if parent %}
     "itemListElement": [
       { "@type": "ListItem", "position": 1, "name": "{{ section }}", "item": "{{ site.url }}/" },
-      { "@type": "ListItem", "position": 2, "name": "{{ title }}", "item": "{{ site.url }}{{ page.url }}" }
+      { "@type": "ListItem", "position": 2, "name": "{{ title | safe }}", "item": "{{ site.url }}{{ page.url }}" }
     ]
     {% else %}
-    "name": "{{ title }}{% if 'moonweb' not in title and 'stefankoelle' not in title %} · moonweb.org{% endif %}",
+    "name": "{{ title | safe }}{% if 'moonweb' not in title and 'stefankoelle' not in title %} · moonweb.org{% endif %}",
     "url": "{{ site.url }}",
-    "author": { "@type": "Person", "name": "Stefan Koelle" }
+    "author": { "@type": "Person", "name": "Stefan Kölle" }
     {% endif %}
   }
   </script>
@@ -44,7 +45,7 @@
   {
     "@context": "https://schema.org",
     "@type": "Person",
-    "name": "Stefan Koelle",
+    "name": "Stefan Kölle",
     "url": "https://www.moonweb.org",
     "image": "https://www.moonweb.org/stefan-koelle-foto.jpg",
     "jobTitle": "Senior Software Developer & Architect",

shared/base.css

@@ -40,6 +40,12 @@ body {
 
 main { max-width: 1100px; margin: 0 auto; padding: 2rem; }
 
+main > h1 {
+  margin: 0 0 1rem;
+  font-size: 1.8rem;
+  color: var(--text);
+}
+
 .site-intro {
   margin-bottom: 2rem;
   font-size: 1rem;
@@ -123,7 +129,7 @@ main { max-width: 1100px; margin: 0 auto; padding: 2rem; }
   margin-left: 0.5rem;
 }
 
-.redacted-note {
+.note {
   font-size: 0.85rem;
   color: #666;
   background: #f0f4f8;

smarthome/air-quality/index.njk

@@ -22,7 +22,7 @@ layout: base.njk
 </ul>
 
 <h2>Rooms covered</h2>
-<p>The dashboard monitors 10 rooms across the apartment: server room, balcony, living room (desk and iMac areas), kitchen, bathroom, hallway, study, children's room, and bedroom. Each room shows current temperature and humidity, with optional pressure and light-level readings where sensors support it.</p>
+<p>The dashboard monitors 9 rooms (10 sensors) across the apartment: server room, balcony, living room (desk and iMac areas), kitchen, bathroom, hallway, study, children's room, and bedroom. Each room shows current temperature and humidity, with optional pressure and light-level readings where sensors support it.</p>
 
 <h2>Dashboard features</h2>
 <ul>

smarthome/airplay-audio/index.njk

@@ -25,7 +25,7 @@ speaker app.</p>
 a software mixer stage (<code>+20&nbsp;dB</code> via an ALSA softvol plugin) sits between
 shairport-sync and the hardware. The hardware mixer itself is deliberately
 left fixed at 100% / 0&nbsp;dB, and shairport-sync only ever adjusts its own
-internal software volume — this avoids the volume jumps and mixer
+internal software volume. This avoids the volume jumps and mixer
 conflicts that show up when multiple layers all try to control loudness.</p>
 
 <h2>Bathroom-specific integration</h2>
@@ -33,7 +33,7 @@ conflicts that show up when multiple layers all try to control loudness.</p>
 radio stream automatically when its light sensor detects the light has
 been switched on. A simple flag file signals whether AirPlay is currently
 active, so the automatic radio stream politely stays off while someone is
-actively AirPlaying — and resumes its normal behavior as soon as the
+actively AirPlaying, and resumes its normal behavior as soon as the
 AirPlay session ends.</p>
 
 <h2>Why this design</h2>

smarthome/balkonpi/index.njk

@@ -13,13 +13,13 @@ layout: base.njk
 self-contained smart-balcony controller: light control, an internet
 radio player, sensor readings, and its own backup/monitoring, all on
 very modest hardware. The goal is to make the balcony a more pleasant
-space — light control when it gets dark, background music while sitting
+space, light control when it gets dark, background music while sitting
 outside, and temperature readings to know what to expect before stepping
 out.</p>
 
 <h2>What it does</h2>
 <ul>
-<li><strong>Audio output</strong> via a DIY PWM-to-analog circuit on two GPIO pins — the Pi Zero has no built-in audio jack, so this is a well-known community workaround using a small RC filter.</li>
+<li><strong>Audio output</strong> via a DIY PWM-to-analog circuit on two GPIO pins, the Pi Zero has no built-in audio jack, so this is a well-known community workaround using a small RC filter.</li>
 <li><strong>Physical controls</strong>: a push button for the balcony light and a toggle switch for music playback, read directly via GPIO.</li>
 <li><strong>HTTP communication</strong> with an ESP32-based balcony light controller.</li>
 <li><strong>Internet radio</strong> via a lightweight command-line audio player, controlled by a small custom tool ported from an earlier bathroom-Pi project.</li>
@@ -28,7 +28,7 @@ out.</p>
 <h2>Hardware details</h2>
 <p>The Pi Zero W is connected to an ESP32 microcontroller that handles
 the actual light switching via a relay module. Communication happens
-over HTTP — the Pi sends a simple request to toggle the relay, and the
+over HTTP, the Pi sends a simple request to toggle the relay, and the
 ESP32 responds with the current light state. The ESP32 also reads a
 DHT22 temperature and humidity sensor, publishing the values to MQTT
 for the home dashboard. This split makes sense: the Pi handles the
@@ -37,7 +37,7 @@ handles the real-time hardware control.</p>
 
 <h2>Monitoring & backup, even on tiny hardware</h2>
 <p>Despite the very limited RAM, this Pi still participates in the same
-Prometheus monitoring pattern as the rest of the fleet — with the metrics
+Prometheus monitoring pattern as the rest of the fleet, with the metrics
 collector's default configuration trimmed down to only the essential
 collectors, since the full default set noticeably overloaded the CPU on
 this specific board. It also runs a nightly rsync backup of its own

smarthome/home-dashboard-controls/index.njk

@@ -13,30 +13,30 @@ parent: "/smarthome/"
 
 <h2>Lighting & ambience</h2>
 <ul>
-<li><strong>Balkon</strong> — LED on/off toggle for the balcony lighting.</li>
+<li><strong>Balkon</strong>, LED on/off toggle for the balcony lighting.</li>
-<li><strong>Beleuchtung (all rooms)</strong> — global "all on"/"all off" shortcut plus per-room toggles for living room and kitchen lighting.</li>
+<li><strong>Beleuchtung (all rooms)</strong>, global "all on"/"all off" shortcut plus per-room toggles for living room and kitchen lighting.</li>
 </ul>
 
 <h2>Music controls</h2>
 <ul>
-<li><strong>Kitchen</strong> — quick buttons for SomaFM, a classical station, and an off switch, all routed to the kitchen speaker.</li>
+<li><strong>Kitchen</strong>, quick buttons for SomaFM, a classical station, and an off switch, all routed to the kitchen speaker.</li>
-<li><strong>Living room</strong> — the same SomaFM/classical options plus dedicated Lounge, 2000s and Deluxe stations, and an off switch.</li>
+<li><strong>Living room</strong>, the same SomaFM/classical options plus dedicated Lounge, 2000s and Deluxe stations, and an off switch.</li>
 </ul>
 
 <h2>Tasmota smart plugs</h2>
 <ul>
-<li><strong>TasmoAdmin</strong> — link straight into the central Tasmota device dashboard for firmware and config management.</li>
+<li><strong>TasmoAdmin</strong>, link straight into the central Tasmota device dashboard for firmware and config management.</li>
-<li><strong>Power strips (Gosund P1)</strong> — two multi-outlet strips covering the home-office network gear and backup drive, and the iMac corner with its peripherals.</li>
+<li><strong>Power strips (Gosund P1)</strong>, two multi-outlet strips covering the study network gear and backup drive, and the iMac corner with its peripherals.</li>
-<li><strong>Single sockets (SP112)</strong> — four individually switchable outlets covering hallway, kitchen, dryer and washing machine circuits, each also powering an associated LED matrix or small Pi.</li>
+<li><strong>Single sockets (SP112)</strong>, four individually switchable outlets covering hallway, kitchen, dryer and washing machine circuits, each also powering an associated LED matrix or small Pi.</li>
-<li><strong>Other plug families</strong> — additional Nous, Eightree (ESP32-based), Athom and IDS smart plugs cover spare capacity, living-room seating/desk outlets, storage room, kitchen appliances, and a few legacy TV/PC outlets (several currently marked defective).</li>
+<li><strong>Other plug families</strong>, additional Nous, Eightree (ESP32-based), Athom and IDS smart plugs cover spare capacity, living-room seating/desk outlets, storage room, kitchen appliances, and a few legacy TV/PC outlets (several currently marked defective).</li>
 </ul>
 <p>The plug collection has grown over time as different brands became available at different price points. Gosund P1 multi-socket strips handle areas with multiple devices, while the SP112 single sockets cover dedicated appliances. Eightree plugs are ESP32-based and flashable to Tasmota, while the Athom and IDS models round out the remaining circuits. A Tasmota RF Bridge extends the ecosystem to RF-only devices like the 3D printer plug in the study.</p>
 
 <h2>Special devices &amp; status</h2>
 <ul>
-<li><strong>Tasmota RF Bridge / Delock</strong> — bridges RF-only devices (like the home-office 3D printer plug) into the Tasmota/MQTT ecosystem.</li>
+<li><strong>Tasmota RF Bridge / Delock</strong>, bridges RF-only devices (like the study 3D printer plug) into the Tasmota/MQTT ecosystem.</li>
-<li><strong>LED Matrix restarts</strong> — one-click restart buttons for each of the six room LED matrix displays (living room, study, bathroom, kitchen, hallway, Nepomuk room), avoiding a manual power-cycle.</li>
+<li><strong>LED Matrix restarts</strong>, one-click restart buttons for each of the six room LED matrix displays (living room, study, bathroom, kitchen, hallway, children's room), avoiding a manual power-cycle.</li>
-<li><strong>Healthchecks &amp; version info</strong> — direct links into the Healthchecks dashboard and a version/status overview for the connected devices.</li>
+<li><strong>Healthchecks &amp; version info</strong>, direct links into the Healthchecks dashboard and a version/status overview for the connected devices.</li>
 </ul>
 
 <h2>Calendar &amp; weather</h2>
@@ -47,11 +47,11 @@ parent: "/smarthome/"
 
 <h2>Network shortcuts</h2>
 <ul>
-<li><strong>Routers & mesh</strong> — quick links to the main Fritzbox and its mesh repeaters covering different floors and the kitchen/IoT band.</li>
+<li><strong>Routers & mesh</strong>, quick links to the main Fritzbox and its mesh repeaters covering different floors and the kitchen/IoT band.</li>
-<li><strong>Switches</strong> — direct access to each Zyxel switch's admin page (server room, living room, PowerLAN, OpenWRT segment).</li>
+<li><strong>Switches</strong>, direct access to each Zyxel switch's admin page (server room, living room, PowerLAN, OpenWRT segment).</li>
-<li><strong>OpenWRT & mini router</strong> — links into the OpenWRT admin UI and the small travel router used for testing.</li>
+<li><strong>OpenWRT & mini router</strong>, links into the OpenWRT admin UI and the small travel router used for testing.</li>
-<li><strong>Sensors & MQTT</strong> — shortcuts to server-room and balcony sensor readings, bathroom analog values, and background worker/API status pages (HTML and JSON views).</li>
+<li><strong>Sensors & MQTT</strong>, shortcuts to server-room and balcony sensor readings, bathroom analog values, and background worker/API status pages (HTML and JSON views).</li>
 </ul>
 
-<p class="redacted-note">This dashboard is intentionally simple: static HTML, no login, meant purely for convenience on the local network rather than as a secured control surface. Device names and room assignments are shown for structure; a few outlets are currently unused or marked defective and simply act as placeholders for future devices.</p>
+<p class="note">This dashboard is intentionally simple: static HTML, no login, meant purely for convenience on the local network rather than as a secured control surface. Device names and room assignments are shown for structure; a few outlets are currently unused or marked defective and simply act as placeholders for future devices.</p>
 </div>

smarthome/homematic-mqtt/index.njk

@@ -9,7 +9,7 @@ layout: base.njk
 <h1>HomematicIP + MQTT</h1>
 <div class="detail-content">
 
-<p>HomematicIP room thermostats (living room, bedroom, home office) report
+<p>HomematicIP room thermostats (living room, bedroom, study) report
 temperature and humidity into the smart home dashboard via a small,
 deliberately low-tech bridge: <strong>Home Assistant → MQTT → InfluxDB</strong>.</p>
 
@@ -18,7 +18,7 @@ deliberately low-tech bridge: <strong>Home Assistant → MQTT → InfluxDB</stro
 Docker container, but the underlying Python library lost compatibility
 with HomematicIP's cloud API and hasn't been maintained since 2022. Home
 Assistant, on the other hand, ships an actively maintained HomematicIP
-Cloud integration — so instead of chasing a broken exporter, the bridge
+Cloud integration, so instead of chasing a broken exporter, the bridge
 now runs as native Home Assistant automations that simply republish
 sensor state changes to MQTT.</p>
 

smarthome/index.njk

@@ -1,5 +1,5 @@
 ---
-title: "Smart Home Projects — Home Assistant, MQTT & IoT | moonweb"
+title: "Smart Home Projects, Home Assistant, MQTT & IoT | moonweb"
 section: "smarthome"
 tags: "smarthome"
 description: "Smart home projects: Home Assistant, MQTT sensors, AirPlay audio, OctoPrint, and energy monitoring."
@@ -7,7 +7,7 @@ layout: base.njk
 sections:
   - heading: "Control & Automation"
     cards:
-      - title: "Home dashboard"
+      - title: "Home Control Buttons"
         summary: "Lighting, music, and Tasmota device control shown on the home dashboard."
         href: "/smarthome/home-dashboard-controls/"
         emoji: "🎛️"
@@ -52,7 +52,7 @@ sections:
         href: "https://github.com/skoelle/mvg-departures"
         emoji: "🚇"
       - title: "Google Calendar sync"
-        summary: "Private calendar synced into the homelab with notifer and web interface."
+        summary: "Private calendar synced into the homelab with notifier and web interface."
         href: "https://github.com/skoelle/calender_sync"
         emoji: "📅"
       - title: "Focus App"
@@ -78,6 +78,7 @@ sections:
         href: "/smarthome/kids-rfid-player/"
         emoji: "🎵"
 ---
+<h1>Smart Home Projects</h1>
 <p class="site-intro">The heart of the homelab. Home Assistant, MQTT sensors, dashboards, and automation projects that make everyday life a little more interesting.</p>
 
 {% include "card-grid.njk" %}
@@ -88,7 +89,7 @@ sections:
   <p>The home dashboard runs on multiple touch displays around the flat: an ESP32-S3 WT32-SC01 in the living room and an M5Stack in the study. Both show room temperatures, energy usage, and quick-action buttons for lighting and music control.</p>
 
   <h2>Automation philosophy</h2>
-  <p>The goal is subtle automation that improves daily life without being intrusive. Lights turn on when someone enters a room, music starts playing in the bathroom when the light switches on, and LED matrix displays show the time, weather, and laundry status. But nothing talks unless spoken to — no voice assistants, no always-on microphones, just simple sensor-driven automation that runs locally without cloud dependencies.</p>
+  <p>The goal is subtle automation that improves daily life without being intrusive. Lights turn on when someone enters a room, music starts playing in the bathroom when the light switches on, and LED matrix displays show the time, weather, and laundry status. But nothing talks unless spoken to, no voice assistants, no always-on microphones, just simple sensor-driven automation that runs locally without cloud dependencies.</p>
 
   <h2>Self-hosted services</h2>
   <p>Beyond hardware automation, several self-hosted services run on the Synology NAS: TubeArchivist and TubeSync for YouTube archiving, OctoPrint for remote 3D printer control, iCloud Contacts Sync for keeping the address book up to date, and a Google Calendar sync for dashboard widgets. Each service is containerized and backed up as part of the NAS backup strategy.</p>

smarthome/kids-rfid-player/index.njk

@@ -9,43 +9,43 @@ layout: base.njk
 <h1>Kids RFID MP3 Player</h1>
 <div class="detail-content">
 
-<p>An Arduino-based MP3 player where kids select audio content by holding RFID cards against the device. No screen, no menus, no WiFi — just tap a card and music plays. Built together with my son in 2018 as a cheaper, more flexible alternative to commercial products like the Hoerbert or Tonuino.</p>
+<p>An Arduino-based MP3 player where kids select audio content by holding RFID cards against the device. No screen, no menus, no WiFi, just tap a card and music plays. Built together with my son in 2018 as a cheaper, more flexible alternative to commercial products like the Hoerbert or Tonuino.</p>
 
 <h2>Why this exists</h2>
 <p>Commercial kids' audio players have trade-offs. The Hoerbert only offers 9 direct-select buttons with color-coded cards that aren't very intuitive for very young children. The Tonuino uses expensive RFID figures and relies on WiFi streaming, which introduces latency and dependency on network availability. This project aimed for the best of both worlds: RFID-based content selection with local-only playback, analog volume control, and minimal buttons.</p>
 
 <h2>Hardware</h2>
 <ul>
-<li><strong>Arduino</strong> — the microcontroller running the custom firmware.</li>
+<li><strong>Arduino</strong>, the microcontroller running the custom firmware.</li>
-<li><strong>RFID module</strong> — reads MIFARE cards to trigger audio playback.</li>
+<li><strong>RFID module</strong>, reads MIFARE cards to trigger audio playback.</li>
-<li><strong>DFPlayer Mini</strong> — compact MP3 player module with built-in amplifier, handling audio decoding and playback directly from an SD card.</li>
+<li><strong>DFPlayer Mini</strong>, compact MP3 player module with built-in amplifier, handling audio decoding and playback directly from an SD card.</li>
-<li><strong>Pololu power switch</strong> — handles auto-shutdown to prevent battery drain, replacing a manual toggle switch that a child would forget to turn off.</li>
+<li><strong>Pololu power switch</strong>, handles auto-shutdown to prevent battery drain, replacing a manual toggle switch that a child would forget to turn off.</li>
-<li><strong>Analog volume knob</strong> — a rotary potentiometer for tactile volume control, deliberately chosen over digital buttons.</li>
+<li><strong>Analog volume knob</strong>, a rotary potentiometer for tactile volume control, deliberately chosen over digital buttons.</li>
-<li><strong>3 LEDs</strong> — green (playing), yellow (paused), red (stopped/at end).</li>
+<li><strong>3 LEDs</strong>, green (playing), yellow (paused), red (stopped/at end).</li>
 </ul>
 
 <h2>How it works</h2>
-<p>Each RFID card is mapped to a specific audio file on the SD card. Hold a card against the reader and the corresponding story or song starts playing. Hold the RFID keychain against the reader to pause; hold it again to resume. No other buttons exist on the device — the design intentionally minimizes interaction points so even a toddler can use it independently.</p>
+<p>Each RFID card is mapped to a specific audio file on the SD card. Hold a card against the reader and the corresponding story or song starts playing. Hold the RFID keychain against the reader to pause; hold it again to resume. No other buttons exist on the device; the design intentionally minimizes interaction points so even a toddler can use it independently.</p>
 
 <h2>Auto-shutdown behavior</h2>
 <p>The power management distinguishes between two states to avoid unnecessary battery drain:</p>
 <ul>
-<li><strong>Stopped</strong> (playback reached the end) — the device shuts down after 5 minutes.</li>
+<li><strong>Stopped</strong> (playback reached the end), the device shuts down after 5 minutes.</li>
-<li><strong>Paused</strong> (user paused via RFID) — the device stays on for 1 hour before shutting down, allowing easy resumption.</li>
+<li><strong>Paused</strong> (user paused via RFID), the device stays on for 1 hour before shutting down, allowing easy resumption.</li>
 </ul>
 
 <h2>The case</h2>
-<p>The enclosure is a custom-built retro-style wooden box, painted by hand. The name "Rocky Box" came from my son, who painted a Paw Patrol character on the front. The design is deliberately quirky and homemade rather than polished — it has character.</p>
+<p>The enclosure is a custom-built retro-style wooden box, painted by hand. The name "Rocky Box" came from my son, who painted a Paw Patrol character on the front. The design is deliberately quirky and homemade rather than polished; it has character.</p>
 
 <h2>What's missing (by design)</h2>
 <ul>
-<li>No resume after power-off — turning the device off mid-playback means starting the story over from the beginning.</li>
+<li>No resume after power-off, turning the device off mid-playback means starting the story over from the beginning.</li>
-<li>No skip forward/backward within a track — stories play start to finish.</li>
+<li>No skip forward/backward within a track, stories play start to finish.</li>
 </ul>
 <p>Both omissions are intentional. Young children don't need seeking functionality, and keeping the interface to just "tap card, listen" reduces confusion.</p>
 
 <h2>Setup</h2>
-<p>All 100 RFID cards were pre-programmed once and labeled with numbers. No card learning or reprogramming is needed after initial setup — just hand a child a numbered card and they know which story it triggers.</p>
+<p>All 100 RFID cards were pre-programmed once and labeled with numbers. No card learning or reprogramming is needed after initial setup, just hand a child a numbered card and they know which story it triggers.</p>
 
 <h2>Code</h2>
 <p>The Arduino firmware is not yet published on GitHub. It's a custom implementation (not Tonuino), written in C++ for the Arduino platform. The code may be uploaded in the future.</p>

smarthome/octoprint/index.njk

@@ -12,12 +12,12 @@ layout: base.njk
 <p>A Raspberry Pi 3B runs OctoPrint for remote 3D-printer control, plus a
 live camera stream so print progress can be checked without walking over
 to the printer. This eliminates the need to stand next to the printer
-watching the first layer — a quality-of-life improvement that's hard to
+watching the first layer, a quality-of-life improvement that's hard to
 go back from once you've experienced it.</p>
 
 <h2>Current setup</h2>
 <ul>
-<li><strong>OctoPrint</strong> runs as a Docker container — the main remote control interface for the printer.</li>
+<li><strong>OctoPrint</strong> runs as a Docker container, the main remote control interface for the printer.</li>
 <li><strong>Camera streaming</strong> is handled by a lightweight camera-server project, exposing both an HLS stream and an MJPEG stream, the latter wired directly into OctoPrint's webcam panel.</li>
 <li><strong>Container management</strong> (Portainer, cAdvisor, a node exporter) runs alongside, giving the same monitoring pattern as the rest of the fleet.</li>
 </ul>
@@ -27,7 +27,7 @@ go back from once you've experienced it.</p>
 camera-server project provides two streaming modes: MJPEG for the
 OctoPrint dashboard (low latency, works in any browser) and HLS for
 remote viewing over slower connections. The MJPEG stream is the primary
-way to check on prints — it loads quickly and updates in real time in the
+way to check on prints; it loads quickly and updates in real time in the
 OctoPrint web interface.</p>
 
 <h2>History</h2>
@@ -39,7 +39,7 @@ that point to better reflect its now-singular focus on the printer.</p>
 
 <h2>Notable OS lesson</h2>
 <p>After moving this Pi to a newer OS release, boot configuration files
-moved to a new path — editing the old path silently does nothing, which
+moved to a new path. Editing the old path silently does nothing, which
 is an easy trap when following older notes or tutorials for the same
 hardware. The lesson: always verify that configuration changes actually
 take effect, especially after OS upgrades on embedded hardware.</p>

smarthome/tasmota-energy/index.njk

@@ -11,7 +11,7 @@ layout: base.njk
 
 <p>Power monitoring across the flat runs on a mix of Tasmota-flashed smart
 plugs, tracking accumulated kWh per device and feeding daily usage
-figures into the home dashboard. The setup uses 8 Tasmota-enabled devices
+figures into the home dashboard. The setup uses a number of Tasmota-enabled devices
 covering kitchen appliances, office equipment, entertainment systems,
 and LED matrix displays.</p>
 
@@ -27,7 +27,7 @@ and LED matrix displays.</p>
 
 <h2>Multi-socket power strips</h2>
 <p>Several rooms use multi-outlet smart power strips (each socket
-individually switchable and metered) rather than single smart plugs — this
+individually switchable and metered) rather than single smart plugs. This
 keeps things like "washing machine + dryer" or "office desk cluster" on
 one strip while still tracking each socket's consumption separately.</p>
 
@@ -35,7 +35,7 @@ one strip while still tracking each socket's consumption separately.</p>
 <p>New devices go through a standard conversion flow (from the
 manufacturer's original cloud-dependent firmware to Tasmota) using a
 well-documented community process. It occasionally fails on the first
-attempt due to a transient Wi-Fi handshake issue — retrying resolves it
+attempt due to a transient Wi-Fi handshake issue; retrying resolves it
 without any special handling.</p>
 
 <h2>How the data flows</h2>
@@ -56,12 +56,12 @@ via Flux to display real-time and historical usage charts.</p>
 </ul>
 
 <h2>Air quality and climate data</h2>
-<p>The same InfluxDB instance also stores temperature and humidity readings from HomematicIP room sensors and ESP32 DHT22 devices. These feed the <a href="/air-quality/">air quality dashboard</a>, which visualizes 24-hour climate history across 10 rooms. The energy and climate data share the MQTT-to-InfluxDB pipeline but live in separate measurement categories, keeping power monitoring and environmental sensing cleanly separated.</p>
+<p>The same InfluxDB instance also stores temperature and humidity readings from HomematicIP room sensors and ESP32 DHT22 devices. These feed the <a href="/smarthome/air-quality/">air quality dashboard</a>, which visualizes 24-hour climate history across 9 rooms (10 sensors). The energy and climate data share the MQTT-to-InfluxDB pipeline but live in separate measurement categories, keeping power monitoring and environmental sensing cleanly separated.</p>
 
 <h2>Why Tasmota over alternatives</h2>
 <p>Tasmota was chosen over alternatives like ESPHome or Tuya firmware for
-several reasons. The local-only control means no cloud dependency — the
+several reasons. The local-only control means no cloud dependency; the
-plugs work even if the internet is down. The MQTT integration is mature
+plugs keep working offline. The MQTT integration is mature
 and well-documented. The energy monitoring sensors are accurate enough
 for home use (typically within 5% of a dedicated energy meter). And the
 firmware supports a wide range of hardware, making it easy to find

stefankoelle/_includes/cv-content.njk

@@ -5,18 +5,18 @@
     <h3>Stefan Kölle</h3>
     <p>Senior Software Developer & Software Architect<br>
     Neumarkter Str. 86c, 81673 München<br>
-    E-Mail: <a id="email-link" href="mailto:cv@stefankoelle.de">cv@stefankoelle.de</a></p>
+    Email: <a id="email-link" href="mailto:cv@stefankoelle.de">cv@stefankoelle.de</a></p>
   </div>
 
   <div class="profile">
     <h3>Profile</h3>
-    <p>Experienced Senior Software Developer and Software Architect with over 20 years of experience in developing and managing microservices and IT architectures. Specialized in .NET Core and Kubernetes, with hands-on experience in AI-assisted development using Claude Code. Clear focus on efficient, innovative, and sustainable solutions. Highly skilled in executing complex projects, building cloud-native services, and optimizing processes through modern technologies.</p>
+    <p>Experienced Senior Software Developer and Software Architect with over 20 years of experience in developing and managing microservices and IT architectures. Specialized in .NET and Kubernetes, with hands-on experience in AI-assisted development using Claude Code. Clear focus on efficient, innovative, and sustainable solutions. Highly skilled in executing complex projects, building cloud-native services, and optimizing processes through modern technologies.</p>
   </div>
 
   <div class="core-technologies">
     <h3>Core Technologies</h3>
     <ul>
-      <li>.NET Core 10 (Dockerized), Clean Architecture</li>
+      <li>.NET 10 (Dockerized), Clean Architecture</li>
       <li>Claude Code / AI-assisted Development</li>
       <li>SolR, Kubernetes, Terraform, Azure (WebApps, Tables, Blobs), AWS</li>
       <li>Uptrends, Sentry, Loki/Grafana, Quartz.NET</li>
@@ -38,7 +38,7 @@
     <li><b>AI Workshop</b> Organized and led an internal team workshop on AI-assisted search query parsing and natural language processing for job search optimization.</li>
     <li><b>Active Services Migration to Kubernetes (2025)</b> Planned migration of active production services from legacy hosting to Kubernetes, including documentation and architectural concepts.</li>
     <li>Consistently delivering full-time output while working part-time, recognized across multiple product teams for high productivity and reliable delivery.</li>
-    <li><b>Technologiestack:</b> .NET Core, Kubernetes, Docker, TypeScript, Claude Code, OpenAI, Terraform, Sentry, Loki/Grafana.</li>
+    <li><b>Technology stack:</b> .NET, Kubernetes, Docker, TypeScript, Claude Code, OpenAI, Terraform, Sentry, Loki/Grafana.</li>
   </ul>
 
   <p><strong>TENHIL GmbH & Co. KG</strong> (08/2022 - 2024)</p>
@@ -46,7 +46,7 @@
     <li><b>OpenAI Integration (2024)</b> Integrated OpenAI-based salary data generation into a multi-tenant microservice, enabling automated, AI-driven content enrichment at scale.</li>
     <li>Solely responsible for designing and building multiple core backend microservices end-to-end, including application services, geo data, feed generation, salary data, and email delivery integrations.</li>
     <li>Collaborating closely with the Product Owner to create and implement new services.</li>
-    <li>Technologies: .NET Core 10, Docker, Azure, Terraform, Uptrends, Sentry, Loki, Quartz.NET.</li>
+    <li>Technologies: .NET 10, Docker, Azure, Terraform, Uptrends, Sentry, Loki, Quartz.NET.</li>
   </ul>
 
   <h3 class="page-break">Senior Software Developer / Senior Software Architect</h3>

stefankoelle/_includes/stefankoelle.njk

@@ -5,7 +5,7 @@
   <meta name="viewport" content="width=device-width, initial-scale=1.0">
   <meta http-equiv="X-UA-Compatible" content="IE=edge">
   <meta name="theme-color" content="#ffffff">
-  <title>{% if title %}{{ title }}{% else %}Stefan Koelle{% endif %}</title>
+  <title>{% if title %}{{ title }}{% else %}Stefan Kölle{% endif %}</title>
   <meta name="description" content="{{ description }}">
   <link rel="apple-touch-icon" sizes="57x57" href="/assets/apple-icon-57x57.png">
   <link rel="apple-touch-icon" sizes="60x60" href="/assets/apple-icon-60x60.png">
@@ -25,7 +25,7 @@
   <meta name="msapplication-TileColor" content="#ffffff">
   <meta name="msapplication-TileImage" href="/assets/ms-icon-144x144.png">
   <link rel="canonical" href="{{ site.url }}{{ page.url }}">
-  <meta name="author" content="Stefan Koelle">
+  <meta name="author" content="Stefan Kölle">
   <meta property="og:title" content="{{ title }}">
   <meta property="og:description" content="{{ description }}">
   <meta property="og:url" content="{{ site.url }}{{ page.url }}">
@@ -39,7 +39,7 @@
   {
     "@context": "https://schema.org",
     "@type": "Person",
-    "name": "Stefan Koelle",
+    "name": "Stefan Kölle",
     "url": "{{ site.url }}",
     "jobTitle": "Software Developer",
     "sameAs": [
@@ -84,7 +84,7 @@
       </div>
 
       <div id="head">
-        <div id="foto"><img src="/assets/stefan-koelle-foto.jpg" alt="Foto von Stefan Koelle" style="width: 100%;"></div>
+        <div id="foto"><img src="/assets/stefan-koelle-foto.jpg" alt="Photo of Stefan Kölle" style="width: 100%;"></div>
       </div>
 
       <div id="background-image"></div>

stefankoelle/assets/manifest.json

@@ -1,5 +1,5 @@
 {
- "name": "Stefan Koelle",
+ "name": "Stefan Kölle",
  "short_name": "SK",
  "icons": [
   {

stefankoelle/cv-print.njk

@@ -3,7 +3,7 @@
 <head>
   <meta charset="UTF-8">
   <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  <title>CV - Stefan Koelle</title>
+  <title>CV - Stefan Kölle</title>
 </head>
 <body>
   <div id="container">
@@ -14,7 +14,7 @@
           Senior Software Developer & Software&nbsp;Architect
         </div>
         <div id="headline-photo">
-          <img src="../assets/stefan-koelle-foto.jpg" alt="Stefan Koelle">
+          <img src="../assets/stefan-koelle-foto.jpg" alt="Stefan Kölle">
         </div>
       </div>
       {% include "cv-content.njk" %}

stefankoelle/index.njk

@@ -1,6 +1,6 @@
 ---
-title: "Stefan Koelle"
+title: "Stefan Kölle"
-description: "Experienced Senior Software Developer and Software Architect with over 20 years of experience. Specialized in .NET Core and Kubernetes, with hands-on experience in AI-assisted development using Claude Code."
+description: "Experienced Senior Software Developer and Software Architect with over 20 years of experience. Specialized in .NET and Kubernetes, with hands-on experience in AI-assisted development using Claude Code."
 layout: stefankoelle.njk
 ---
 <div class="headlinespace">
@@ -22,7 +22,7 @@ layout: stefankoelle.njk
 <div id="personalprojectscontent">
   <h2>Personal Projects</h2>
 
-  <h3>moonweb.org (since 2020)</h3>
+  <h3>moonweb.org</h3>
   <p>My personal corner on the internet, documenting the homelab, smart home setups, infrastructure experiments, retro hardware, and the code that ties it all together. Everything runs on a homelab that has been evolving since the mid-90s.</p>
   <ul>
     <li><b><a href="https://www.moonweb.org/">moonweb.org</a></b>: Overview of all sites and projects.</li>
@@ -35,17 +35,31 @@ layout: stefankoelle.njk
   <h3>Home Network Projects (2025-2026)</h3>
   <ul>
     <li><b>Docker Host (Proxmox PVE)</b><br>Virtualized Docker host with Debian 12.2 running containerized services including Portainer, Prometheus, Grafana, Gitea, monitoring exporters, and more. Full architecture documented on <a href="https://www.moonweb.org/infra/docker/">moonweb.org/infra</a>.</li>
+    <li><b>Infrastructure</b><br>The whole homelab runs on a <a href="https://www.moonweb.org/infra/proxmox/">Proxmox cluster</a> with a <a href="https://www.moonweb.org/infra/synology/">Synology NAS</a>, <a href="https://www.moonweb.org/infra/lxc/">LXC containers</a>, and a <a href="https://www.moonweb.org/infra/backup-strategy/">full backup strategy</a>. More on <a href="https://www.moonweb.org/infra/">moonweb.org/infra</a>.</li>
     <li><b>InfluxDB Time-Series Integration</b><br>Deployed InfluxDB 2.x for sensor data collection from Tasmota smart plugs and HomematicIP thermostats, replacing older MySQL-based storage with modern time-series architecture.</li>
     <li><b>LED Matrix ESP32 InfluxDB Integration</b><br>Data persistence layer for <a href="/ledmatrix/">LED Matrix ESP32</a> sensor systems (DHT22 temperature/humidity) with InfluxDB 2.x backend. Automated collection at 60-second intervals for historical trend analysis.</li>
     <li><b>Air Quality Dashboard</b><br>Dynamic HTML5 dashboard consuming real-time sensor data from InfluxDB via Flux query API. Displays temperature and humidity across all network locations, accessible via nginx reverse proxy. See also <a href="https://www.moonweb.org/smarthome/air-quality/">moonweb.org/smarthome</a>.</li>
     <li><b>Tasmota Energy Monitoring</b><br>Smart plug energy tracking with 8 Tasmota-enabled devices, integrating MQTT data collection and visualization. See also <a href="https://www.moonweb.org/smarthome/tasmota-energy/">moonweb.org/smarthome</a>.</li>
+    <li><b>Smart Home Additions</b><br>Multi-room <a href="https://www.moonweb.org/smarthome/airplay-audio/">AirPlay audio</a> on Raspberry Pi, a <a href="https://www.moonweb.org/smarthome/balkonpi/">balcony solar Pi</a>, an ESP32 <a href="https://www.moonweb.org/smarthome/home-dashboard-controls/">home dashboard</a>, and <a href="https://www.moonweb.org/smarthome/octoprint/">OctoPrint</a> for 3D printing. More on <a href="https://www.moonweb.org/smarthome/">moonweb.org/smarthome</a>.</li>
     <li><b>Network Hardware & Monitoring</b><br>Four Zyxel GS1200-8HP managed switches in the server room, living room, and study, plus a <a href="https://www.moonweb.org/infra/openwrt/">Multi-WAN OpenWrt router</a> for failover and VLAN segmentation. All switches feed into <a href="https://www.moonweb.org/infra/monitoring/">Prometheus monitoring</a> via SNMP exporters, and IoT devices are isolated in VLAN 189.</li>
   </ul>
 
+  <h3>Open-Source Tools & Side Projects</h3>
+  <p>Most of these live on <a href="https://github.com/skoelle">GitHub</a> and are documented in more detail on <a href="https://www.moonweb.org/code/">moonweb.org/code</a>.</p>
+  <ul>
+    <li><b><a href="https://github.com/skoelle/kctl-tui" target="_blank">kctl-tui</a></b>: A terminal UI (Go + Bubble Tea) for everyday Kubernetes work, with guided context/namespace selection and an AWS Secrets Manager sync workflow.</li>
+    <li><b><a href="https://github.com/skoelle/m5stack-dashboard" target="_blank">M5Stack Dashboard</a></b> &amp; <b><a href="https://github.com/skoelle/wt32sc01-dashboard" target="_blank">WT32-SC01 Dashboard</a></b>: ESP32 dashboards showing live weather, calendar, and Munich transit departures on physical hardware.</li>
+    <li><b><a href="https://github.com/skoelle/dyndns-updater" target="_blank">DynDns Updater</a></b>: Cloudflare + FreeDNS DynDNS updater for FritzBox (TR-064), running as a Docker container.</li>
+    <li><b><a href="https://github.com/skoelle/calender_sync" target="_blank">Google Calendar Sync</a></b>: Syncs a private Google Calendar into MariaDB with recurring-event expansion and a FastAPI web UI.</li>
+    <li><b><a href="https://github.com/skoelle/mvg-departures" target="_blank">MVG Departures</a></b>: Compact Munich transit departure monitor with configurable stations, direction filters, and a mobile-friendly view.</li>
+    <li><b><a href="https://github.com/skoelle/icloud-contacts-sync" target="_blank">iCloud Contacts Sync</a></b>: Automated iCloud contacts sync to MariaDB via CardDAV, with birthday email digest and a read-only API behind Authelia.</li>
+    <li>PeopleCostCounter, Focus App, and more on <a href="https://github.com/skoelle?tab=repositories" target="_blank">GitHub</a>.</li>
+  </ul>
+
   <h3>Retro Computing (2022/2023)</h3>
   <ul>
     <li>MiSTer and MiST FPGA Systems for preservation (see also <a href="https://www.moonweb.org/retro/mist-mister-fpga/">moonweb.org/retro</a>).</li>
-    <li><a href="https://www.moonweb.org/retro/dos-486-tower/">DOS System</a>, <a href="https://www.moonweb.org/retro/the-a1200/">Amiga System</a>, and <a href="https://www.moonweb.org/retro/atari-mega-st-fleet/">Atari ST System</a> with the environment from the early 90s.</li>
+    <li><a href="https://www.moonweb.org/retro/dos-486-tower/">DOS 486 environment</a> rebuilt on MiSTer FPGA, <a href="https://www.moonweb.org/retro/amiga-modern-platforms/">Amiga</a> reproduced on modern hardware, and <a href="https://www.moonweb.org/retro/atari-mega-st-fleet/">Atari ST Systems</a> with the environment from the early 90s.</li>
   </ul>
 
   <h3>Upgrade of old <a href="https://www.moonweb.org/retro/atari-mega-st-fleet/">Atari Mega 4</a> (2021)</h3>
@@ -148,26 +162,43 @@ layout: stefankoelle.njk
   <p>I've fully embraced the AI-assisted development paradigm since early 2025. At work, I've taught <strong>Claude Code</strong> a workflow for handling Jira stories end-to-end: it evaluates requirements, provides feedback to the PO, and creates a detailed implementation plan. From there, it's mostly about supervising the plan while the code generation runs largely autonomously. For code review, we use a second AI (e.g., Codex) as a quality gate to catch issues that might slip through. In migration projects, I define the exact plan upfront and Claude Code executes it with increasing independence. The output gain is massive, delivering in a fraction of the time.</p>
     <p>Privately, I work with <strong><a href="https://opencode.ai">OpenCode</a></strong> paired with OpenCode Zen, Merge Gateway, and OpenRouter, mostly for Python-based home lab and automation projects. See my <a href="https://www.moonweb.org/code/">GitHub projects</a> for examples and the <a href="https://www.moonweb.org/infra/dev-environment/">Dev VM setup</a> for the infrastructure behind this workflow.</p>
 
-  <h3>.NET Core</h3>
+  <h3>.NET</h3>
   <ul>
-    <li>Working with .NET Core since 2018 at stellenanzeigen.de GmbH &amp; Co. KG, which became TENHIL GmbH &amp; Co. KG in 2022, where I migrated the old VB and ASP-Classic applications to modern .NET Core.</li>
+    <li>Working with .NET since 2018 at stellenanzeigen.de GmbH &amp; Co. KG, which became TENHIL GmbH &amp; Co. KG in 2022, where I migrated the old VB and ASP-Classic applications to modern .NET.</li>
     <li>Built around a dozen microservices, including Jobs Per Mail, JobApply, GeoService, Feedexporter, and Salary Data Service, first hosted on Azure and built with Docker, Terraform, Azure Tables, Azure Blobs, S3 buckets, and PostgreSQL.</li>
-    <li>Since this year, all of these microservices run in our self-hosted Kubernetes cluster on AWS machines.</li>
+    <li>Since 2026, all of these microservices run in our self-hosted Kubernetes cluster on AWS machines.</li>
     <li>Introduced Squidex as a headless CMS for the microservice backend, with Sentry and Loki for monitoring and logging, and Quartz.NET, later Hangfire.NET, for scheduled jobs.</li>
+    <li>Privately built <a href="https://github.com/skoelle/marcer-gamedvd-launcher" target="_blank">Marcer GameDVD Launcher</a>, a console tool for browsing and launching Atari ST/Falcon games from a USB stick.</li>
   </ul>
 
-  <h3>TypeScript</h3>
+  <h3>Go</h3>
+  <ul>
+    <li>First used Go for <a href="https://github.com/skoelle/kctl-tui" target="_blank">kctl-tui</a>, a terminal UI for Kubernetes built with Bubble Tea, handling context selection, namespace management, and AWS Secrets Manager sync.</li>
+    <li>Used Hugo (Go Templates) to rebuild the <a href="https://buildbroken.moonweb.org" target="_blank">build broken</a> blog archive (<a href="https://github.com/skoelle/buildbroken-blog-archive" target="_blank">source</a>) from Wayback Machine snapshots.</li>
+  </ul>
+
+  <h3>TypeScript / JavaScript</h3>
   <ul>
     <li>Using Node.js privately for over a decade, TypeScript since its early days, and professionally at TENHIL since 2024.</li>
-    <li>Since this year, TypeScript is my go-to for AI-built microservices.</li>
+    <li>Since 2026, TypeScript is my go-to for AI-built microservices.</li>
     <li>Built an MCP (Model Context Protocol) server for ChatGPT integration in 6 half-days using Claude Code.</li>
     <li>Implemented a TypeScript widget renderer for AI-driven applications with the OpenAI Chat Kit.</li>
+    <li><b>Static site generators:</b> <a href="https://www.11ty.dev">Eleventy</a> (v3) for <a href="https://github.com/skoelle/moonweb-site" target="_blank">moonweb.org</a> (6 sites, Nunjucks templates) and stefankoelle.de, <a href="https://astro.build">Astro</a> for the <a href="https://github.com/skoelle/28k8-moonweb-org" target="_blank">28k8 BBS retro site</a>.</li>
   </ul>
 
   <h3>Python</h3>
   <ul>
     <li>Working with Python since 2020 on private projects, home lab tooling, and automation scripts.</li>
-    <li>Since this year, increasingly using Python for home network projects, with development accelerated by AI-assisted workflows in OpenCode.</li>
+    <li>Since 2026, increasingly using Python for home network projects, with development accelerated by AI-assisted workflows in OpenCode.</li>
+    <li><b>FastAPI web projects:</b> <a href="https://github.com/skoelle/calender_sync" target="_blank">Google Calendar Sync</a>, <a href="https://github.com/skoelle/mvg-departures" target="_blank">MVG Departures</a>, <a href="https://github.com/skoelle/icloud-contacts-sync" target="_blank">iCloud Contacts Sync</a>.</li>
+    <li><b>Flask:</b> <a href="https://github.com/skoelle/dyndns-updater" target="_blank">DynDns Updater</a>, a Cloudflare + FreeDNS DynDNS updater for FritzBox as a Docker container.</li>
+  </ul>
+
+  <h3>Arduino / PlatformIO</h3>
+  <ul>
+    <li>Built ESP32 dashboards (<a href="https://github.com/skoelle/m5stack-dashboard" target="_blank">M5Stack</a>, <a href="https://github.com/skoelle/wt32sc01-dashboard" target="_blank">WT32-SC01</a>) showing weather, calendar, and Munich transit departures on physical hardware.</li>
+    <li><a href="/ledmatrix/">LED Matrix ESP32</a>, the date/weather/status displays in every room (see the Home Automation section above).</li>
+    <li><a href="https://www.moonweb.org/smarthome/kids-rfid-player/">Kids RFID MP3 Player</a>: Interactive audio playback system with RFID tags, powered by an Arduino Nano.</li>
   </ul>
 
   <h3>.NET Framework</h3>
@@ -206,7 +237,8 @@ layout: stefankoelle.njk
   <h3>PASCAL</h3>
   <ul>
     <li>Started with PASCAL on PC in 1993, using TurboPascal 6.0, 7.0, and Borland Pascal 7.0.</li>
-    <li>Developed DOSMENU, a menu system for DOS, and tools for Fidonet.</li>
+    <li>Developed <a href="https://github.com/skoelle/turbopascal-xlib-unit" target="_blank">X-LIB Unit</a>, a VGA graphics library used in the demos below.</li>
+    <li>Developed <a href="https://28k8.moonweb.org/bbs/pc/dosmenu/" target="_blank">DOSMENU</a>, a menu system for DOS, and <a href="https://28k8.moonweb.org/bbs/pc/kosmos-design/" target="_blank">tools for Fidonet</a>.</li>
     <li>Created two games: a Wheel of Fortune clone and a two-player Tetris.</li>
     <li>Studied PASCAL for one year in school (1994) and one semester on UNIX (Solaris) during studies in 1996.</li>
   </ul>
@@ -215,7 +247,7 @@ layout: stefankoelle.njk
   <ul>
     <li>Began learning Assembler on the Atari ST in 1992, creating simple programs with Pure Assembler, part of the Pure C Pack.</li>
     <li>Developed a small text mode demo with sound using DevPAK.</li>
-    <li>Gained experience on PC in 1994, creating four demos using inline assembler in TurboPascal.</li>
+    <li>Created four demos on PC using inline assembler in TurboPascal: <a href="https://github.com/skoelle/dos-phobia-welcome-intro" target="_blank">Phobia Welcome Intro</a> (1994) and three <a href="https://github.com/skoelle/dos-tcm-intros" target="_blank">TranceMission Intros</a> (1992/1993), with VGA graphics and SoundBlaster audio.</li>
   </ul>
 
   <h3>C</h3>
@@ -241,7 +273,7 @@ layout: stefankoelle.njk
 <div id="impressumcontent">
   <h2>Legal Notice (Impressum, § 5 DDG)</h2>
   <p>Stefan Kölle<br>Neumarkter Str. 86c<br>81673 München</p>
-  <p>Phone/Fax: +49-(89)-20006547<br>E-Mail: <a id="email-impressum" href="#">[email protected]</a></p>
+  <p>Phone/Fax: +49-(89)-20006547<br>Email: <a id="email-impressum" href="#">[email protected]</a></p>
   <p>Responsible for content according to § 18 (2) MStV: Stefan Kölle, address as above.</p>
   <p>Full legal notice & privacy policy for this website and the moonweb.org network: <a href="https://www.moonweb.org/impressum/">moonweb.org/impressum</a>
 </div>

stefankoelle/ledmatrix/index.njk

@@ -8,7 +8,7 @@ description: "WiFi-controlled LED display solution with REST API, DHT22 sensor,
   <meta charset="UTF-8">
   <meta name="viewport" content="width=device-width, initial-scale=1.0">
   <meta name="description" content="{{ description }}">
-  <meta name="author" content="Stefan Koelle">
+  <meta name="author" content="Stefan Kölle">
   <link rel="canonical" href="{{ site.url }}{{ page.url }}">
   <meta property="og:title" content="{{ title }}">
   <meta property="og:description" content="{{ description }}">
@@ -25,7 +25,7 @@ description: "WiFi-controlled LED display solution with REST API, DHT22 sensor,
     "@type": "Article",
     "headline": "{{ title }}",
     "description": "{{ description }}",
-    "author": { "@type": "Person", "name": "Stefan Koelle" },
+    "author": { "@type": "Person", "name": "Stefan Kölle" },
     "url": "{{ site.url }}{{ page.url }}"
   }
   </script>

timecapsule/src/index.md

@@ -11,7 +11,7 @@ quicknav:
   - { label: "sitemap", url: "/beginning/sitemap.html" }
 ---
 
-Welcome to the new <b>moonweb.org</b> website. After <b>2 years</b> of part-time development, it is finally <b>here</b>.
+Welcome to the new <b>moonweb.org</b> website by <b>Stefan</b>. After <b>2 years</b> of part-time development, it is finally <b>here</b>.
 
 ## The Idea
 
@@ -21,7 +21,7 @@ Since computer education in schools or colleges here in Germany isn't very compr
 ## The Website
 
 This page mostly describes <b>my life</b>, the <b>products I have developed</b>, and the <b>projects I have been part of</b>.
-You can also find some general information about the person who played a <b>major role in my IT learning process</b>, Matthias. Together, we took our first steps in <b>computer programming in 1988</b> on an Atari STFM 1040, a great machine.
+You can also find some general information about the person who played a <b>major role in Stefan's IT learning process</b>, Matthias. Together, we took our first steps in <b>computer programming in 1988</b> on an Atari STFM 1040, a great machine.
 
 ## The Person