Add chat-archive description

Update repos and CV from prebuild
Revert Kölle to Koelle in meta/title/alt tags for SEO, keep Kölle in visible text
2026-09-17 17:00:25 +00:00 · 2026-09-17 16:45:17 +02:00 · 2026-09-17 16:21:56 +02:00 · 2026-09-14 12:15:26 +02:00 · 2026-09-13 23:44:49 +02:00 · 2026-09-13 23:33:43 +02:00
225 changed files with 2981 additions and 866 deletions
@@ -1,5 +1,3 @@
-stefankoelle/
-timecapsule/
 scripts/
 .tmp/

@@ -43,15 +43,15 @@ jobs:
      - name: Validate build output
        run: |
          echo "Build output:"
-          find dist -maxdepth 2 -type f | sort | head -40
+          find dist/moonweb -maxdepth 2 -type f | sort | head -40
          echo "..."
          echo "Total files:"
-          find dist -type f | wc -l
+          find dist/moonweb -type f | wc -l

          # Verify key directories exist
          for dir in "" infra smarthome code retro timecapsule; do
-            if [ -n "$dir" ] && [ ! -d "dist/$dir" ]; then
-              echo "Error: dist/$dir not found"
+            if [ -n "$dir" ] && [ ! -d "dist/moonweb/$dir" ]; then
+              echo "Error: dist/moonweb/$dir not found"
              exit 1
            fi
          done
@@ -60,7 +60,7 @@ jobs:
        uses: actions/upload-artifact@v7
        with:
          name: dist-moonweb
-          path: dist/
+          path: dist/moonweb
          retention-days: 7

  deploy:
@@ -73,12 +73,12 @@ jobs:
        uses: actions/download-artifact@v8
        with:
          name: dist-moonweb
-          path: dist/
+          path: dist/moonweb

      - name: Deploy via SFTP
        uses: wlixcc/SFTP-Deploy-Action@v1.2.6
        with:
-          local_path: './dist/*'
+          local_path: './dist/moonweb/*'
          server: ${{ secrets.IONOS_SFTP_HOST }}
          username: ${{ secrets.IONOS_SFTP_USER }}
          password: ${{ secrets.IONOS_SFTP_PASSWORD }}
@@ -99,7 +99,7 @@ jobs:
          if [ "${{ needs.deploy.result }}" = "success" ]; then
            echo "moonweb.org deployed successfully!" >> $GITHUB_STEP_SUMMARY
          else
-            echo "Deployment failed. Check the deploy jobs for details." >> $GITHUB_STEP_SUMMARY
+            echo "Deployment failed. Check the deploy job for details." >> $GITHUB_STEP_SUMMARY
          fi
          echo "" >> $GITHUB_STEP_SUMMARY
          echo "### Sites" >> $GITHUB_STEP_SUMMARY
@@ -1,4 +1,4 @@
-# AGENTS.md — moonweb-site
+# AGENTS.md, moonweb-site

 ## Projektuebersicht

@@ -23,19 +23,18 @@ Monorepo fuer 6 statische Websites unter www.moonweb.org + stefankoelle.de, basi

 ### Andere Sites (nicht im Monorepo)

- 28k8.moonweb.org — 90er BBS/Scene-Archiv
- buildbroken.moonweb.org — .NET Open Space Blog Archiv
+- 28k8.moonweb.org, 90er BBS/Scene-Archiv
+- buildbroken.moonweb.org, .NET Open Space Blog Archiv

 ## Dateistruktur

 ```
 moonweb-site/
-├── hub/                    # Eleventy-Config + index.njk
-├── infra/                  # Eleventy-Config + index.njk + 8 Subseiten
-├── smarthome/              # Eleventy-Config + index.njk + 9 Subseiten
-├── code/                   # Eleventy-Config + index.njk
-│   └── _data/repos.json
-├── retro/                  # Eleventy-Config + index.njk + 13 Subseiten
+├── hub/                    # Index + Redirects (.htm) + impressum.njk
+├── infra/                  # Index.njk + 8 Subseiten
+├── smarthome/              # Index.njk + 9 Subseiten
+├── code/                   # Index.njk
+├── retro/                  # Index.njk + 13 Subseiten
 ├── timecapsule/            # Eleventy 2.x (eigene Config)
 │   ├── eleventy.config.js
 │   ├── package.json
@@ -53,15 +52,20 @@ moonweb-site/
 ├── shared/                 # Gemeinsame Komponenten
 │   ├── _includes/
 │   │   ├── base.njk        # Basis-Layout (Header, Site-Switcher, Footer)
-│   │   └── card-grid.njk   # Card-Grid Template
-│   ├── base.css
-│   └── theme-*.css
+│   │   ├── card-grid.njk   # Card-Grid Template
+│   │   └── sitemap.njk     # Zentrale Sitemap
+│   ├── base.css             # Shared CSS (Layout, Cards, Typografie)
+│   └── favicon/             # Favicon-SVGs pro Section
+├── _data/
+│   └── repos.json           # GitHub-Aggregator Output
 ├── scripts/
-│   ├── github-aggregator/
-│   └── merge-moonweb.sh    # Merge-Skript fuer Deployment
+│   ├── github-aggregator/   # Python: liest .moonweb.yml -> repos.json
+│   └── cloudflare/          # Redirect-Setup fuer alte Subdomains
 ├── .github/workflows/
 │   ├── build-deploy-moonweb.yml   # CI/CD: IONOS SFTP (www.moonweb.org)
 │   └── deploy-stefankoelle.yml    # CI/CD: IONOS SFTP (stefankoelle.de)
+├── eleventy.config.js       # Zentrale Eleventy-Config (alle moonweb Sites)
+├── .eleventyignore          # Schliesst stefankoelle/, timecapsule/ aus
 ├── DESIGN.md
 ├── SPEC.md
 ├── PLAN.md
@@ -72,10 +76,10 @@ moonweb-site/

 ## Technischer Stack

- **SSG:** Eleventy (11ty) v3.1.6 (hub, infra, smarthome, code, retro)
+- **SSG:** Eleventy (11ty) v3.1.6 (hub, infra, smarthome, code, retro) - zentrale Config
 - **SSG:** Eleventy v2.0.1 (timecapsule - retro 2001 Design)
 - **Templates:** Nunjucks (.njk)
- **CSS:** Variables-basiert mit Accent-Farben pro Site
+- **CSS:** Variables-basiert mit Accent-Farben (inlined in base.njk)
 - **Deploy (moonweb):** IONOS SFTP
 - **Deploy (stefankoelle):** IONOS SFTP
 - **CI/CD:** GitHub Actions (2 Workflows)
@@ -85,38 +89,35 @@ moonweb-site/
 ```bash
 npm install
 cd timecapsule && npm install   # Timecapsule Dependencies
-npm run prebuild                # Pre-Build Tasks (CV PDF generieren)
-npm run dev:hub                 # localhost:8081
-npm run dev:infra               # localhost:8082
-npm run dev:smarthome           # localhost:8083
-npm run dev:code                # localhost:8084
-npm run dev:retro               # localhost:8085
-npm run dev:stefankoelle        # localhost:8086
-npm run dev:timecapsule         # localhost:8087
-npm run build                   # Alle Sites bauen
-npm run build:moonweb           # Nur moonweb Sites (ohne stefankoelle)
-npm run merge:moonweb           # Sites mergen fuer Deployment
+npm run prebuild:cv            # Pre-Build Tasks (CV PDF generieren)
+npm run dev                     # Moonweb Sites (localhost:8081)
+npm run dev:stefankoelle        # stefankoelle.de (localhost:8086)
+npm run dev:timecapsule         # Timecapsule (localhost:8087)
+npm run build                   # Alle moonweb Sites
+npm run build:stefankoelle      # Nur stefankoelle
+npm run build:timecapsule       # Nur timecapsule
+npm run build:moonweb           # Moonweb + Timecapsule (fuer Deployment)
 ```

 ## Design-Prinzipien

-1. **Header konsistent** — Identischer Site-Switcher auf allen Home-Sites
-2. **Content flexibel** — Detailseiten duerfen eigenes Layout haben
-3. **Accent-Farben:** hub=#3b6ea5, infra=#99333A, smarthome=#1f8a8a, code=#3E5098, retro=#8a6d3b
-4. **Englisch** — Alle Sites komplett auf Englisch
-5. **Keine Analytics** — Keine Tracking-Tools
-6. **Sensible Daten** — Infra-Content wird manuell redigiert (keine IPs, Keys, Passwoerter)
+1. **Header konsistent**, Identischer Site-Switcher auf allen Home-Sites
+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
+5. **Keine Analytics**, Keine Tracking-Tools
+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/infra/` — Infra
- `www.moonweb.org/smarthome/` — Smarthome
- `www.moonweb.org/code/` — Code
- `www.moonweb.org/retro/` — Retro
- `www.moonweb.org/timecapsule/` — Timecapsule (2001 Design)
- `www.moonweb.org/impressum/` — Impressum
+- `www.moonweb.org/`, Hub (Root)
+- `www.moonweb.org/infra/`, Infra
+- `www.moonweb.org/smarthome/`, Smarthome
+- `www.moonweb.org/code/`, Code
+- `www.moonweb.org/retro/`, Retro
+- `www.moonweb.org/timecapsule/`, Timecapsule (2001 Design)
+- `www.moonweb.org/impressum/`, Impressum

 Cloudflare Redirects leiten alte Subdomains weiter:
 - `hub.moonweb.org/*` → `www.moonweb.org/*`
@@ -140,14 +141,14 @@ Das CV-PDF wird via WeasyPrint generiert:

 ```bash
 npm run pdf:cv               # Einzelnes PDF generieren
-npm run prebuild             # Alle Pre-Build Tasks (inkl. CV PDF)
+npm run prebuild:cv             # Alle Pre-Build Tasks (inkl. CV PDF)
 ```

 Dateien:
- `stefankoelle/pdf/cv-style.css` — WeasyPrint-Stylesheet (A4, Typografie)
- `stefankoelle/pdf/build-pdf.sh` — Shell-Skript fuer PDF-Generierung
- `stefankoelle/cv-print.njk` — Standalone HTML-Template (nur CV-Content)
- `stefankoelle/pdf/cv.pdf` — Generiertes PDF (Output)
+- `stefankoelle/pdf/cv-style.css`, WeasyPrint-Stylesheet (A4, Typografie)
+- `stefankoelle/pdf/build-pdf.sh`, Shell-Skript fuer PDF-Generierung
+- `stefankoelle/cv-print.njk`, Standalone HTML-Template (nur CV-Content)
+- `stefankoelle/pdf/cv.pdf`, Generiertes PDF (Output)

 Wichtig: Das PDF wird via Eleventy-Passthrough ins Build-Output kopiert (`dist/stefankoelle/pdf/cv.pdf`).

@@ -160,6 +161,10 @@ CSS-Dateien werden als Passthrough kopiert (kein Hash im Dateinamen). Bei CSS-Ae

 Bei jeder CSS-Anpassung `?v=N` um 1 erhoehen, sonst cached der Browser die alte Datei.

+### skoelle GitHub-Repo im Auge behalten
+
+Bei Aenderungen an stefankoelle.de (Inhalte, Technologien, URLs) pruefen, ob die Datei `../skoelle/README.md` ebenfalls aktualisiert werden muss. Das README ist die Kurzform des Lebenslaufs und soll mit stefankoelle.de synchron bleiben.
+
 ## CI/CD

 ### IONOS SFTP (www.moonweb.org)
@@ -188,7 +193,7 @@ Benötigte Secrets:

 ## GitHub Aggregator

-Das Skript `scripts/github-aggregator/aggregate.py` liest aus jedem public Repo unter `skoelle` die `.moonweb.yml` und generiert `code/_data/repos.json`.
+Das Skript `scripts/github-aggregator/aggregate.py` liest aus jedem public Repo unter `skoelle` die `.moonweb.yml` und generiert `_data/repos.json`.

 ### .moonweb.yml Format

@@ -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) |
-| 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 |
-| retro | Ja, aber bewusst rudimentär | Thema ist inhaltlich noch unausgereift — nur Grundgerüst anlegen, keine weitere Zeit investieren |
+| 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 |
+| 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 |

-## 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:

@@ -1,64 +1,74 @@
-# moonweb.org — Implementation Plan
+# moonweb.org, Implementation Plan

-Companion to `SPEC.md`. Defines order of work. All sites (hub, infra, smarthome, code, retro, stefankoelle) launch **simultaneously** — no staged rollout by domain.
+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. Create the `moonweb-site` monorepo (private until first launch, then can stay private since Pages deploys the built output, not the source).
-2. Initialize Eleventy project structure per `SPEC.md §10`.
-3. Set up `shared/layout-base.njk` (header + card-grid) and one `theme-*.css` per accent color (hub, infra, smarthome, code, retro).
-4. Verify local dev server works per site (`npm run dev:<site>`) before any content work starts.
+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)

-Work order within this phase is flexible since all domains launch together; suggested sequence based on how self-contained each domain's content is:
+1. **code**, GitHub aggregator, `_data/repos.json`, overview page grouped by subcategory.
+2. **smarthome**, overview + detail pages where content exists.
+3. **infra**, shallow overview with redaction pass (no IPs, keys, passwords).
+4. **retro**, minimal overview with WIP notices.
+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/`.

-1. **code** — simplest case, no detail pages, no sensitive-data filtering needed.
-   - Add `.moonweb.yml` to each GitHub repo (see `SPEC.md §8`).
-   - Build the aggregator script, run it once, generate `code/_data/repos.json`.
-   - Build the overview page grouped by subcategory (Automation & Sync, Dev-Tools, Web Apps, Firmware/Hardware, Misc).
-2. **smarthome** — overview first, detail pages only where content already exists.
-   - Draft the overview: how the smart home is structured (buttons/control, sensors, calendar, weather, media).
-   - For each existing topic with enough material (HomematicIP/MQTT, Tasmota, LED-Matrix *reference only, no migration*, M5Stack/WT32SC01 dashboards, WetterAPI, AirPlay, OctoPi, TubeArchivist), decide case by case: enough content → detail page; too thin → mention in overview only, no placeholder.
-   - Translate source material to English during authoring (one-time AI pass per document, per `SPEC.md §7`).
-3. **infra** — overview only, redaction pass required.
-   - Draft a shallow, structured overview: Proxmox/pve2, Synology, VLANs, Fritz!Box mesh, SSO, Docker hosting model, plus the "how I work" section (OpenClaw/OpenCode setup, dev workflow).
-   - Apply the redaction rule from `SPEC.md §6` while translating — strip IPs, keys, credentials, internal hostnames from every source document before it becomes public content.
-   - Skip detail pages unless a topic can be described without any sensitive detail.
-4. **retro** — minimal effort, rudimentary only.
-   - One overview page listing what hardware exists.
-   - Add "work in progress" notices for anything that isn't ready — better an honest short page than none.
-5. **hub** — build last within this phase since it links to all the others.
-   - One-line description + link per destination (infra, smarthome, code, retro, stefankoelle, and external links to www.moonweb.org, 28k8.moonweb.org).
+## 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/`).

-1. Write `.github/workflows/build-deploy.yml`: builds all five sites in one job (or matrix), then deploys each output folder to its corresponding Cloudflare Pages project via `wrangler pages deploy`.
-2. Create five Cloudflare Pages projects (hub, infra, smarthome, code, retro), each bound to its target custom domain (DNS already on Cloudflare, no extra setup needed).
-3. Do one full dry run per site locally before the first real deploy.
+## Phase 3, Consolidation to www.moonweb.org

-## Phase 3 — Launch
+All moonweb.org sites now live under `www.moonweb.org` as subdirectories:

-1. Deploy all five sites simultaneously.
-2. Point the respective custom domains at their Pages projects.
-3. Apex domain `moonweb.org` keeps redirecting to `www.moonweb.org` for now (no change in this launch).
-4. Smoke-test cross-linking: hub → each site, site-switcher on infra/smarthome/code/retro, smarthome → external ledmatrix link, code cards → GitHub links.
+| URL | Content |
+|-----|---------|
+| `www.moonweb.org/` | Hub (root) |
+| `www.moonweb.org/infra/` | Infrastructure |
+| `www.moonweb.org/smarthome/` | Smart Home |
+| `www.moonweb.org/code/` | Code catalog |
+| `www.moonweb.org/retro/` | Retro hardware |
+| `www.moonweb.org/timecapsule/` | 2000s time capsule |
+| `www.moonweb.org/impressum/` | Legal notice |

-## Phase 4 — Explicitly deferred (not part of this build)
+Cloudflare redirects forward old subdomains:
+- `hub.moonweb.org/*` → `www.moonweb.org/*`
+- `infra.moonweb.org/*` → `www.moonweb.org/infra/*`
+- `smarthome.moonweb.org/*` → `www.moonweb.org/smarthome/*`
+- `code.moonweb.org/*` → `www.moonweb.org/code/*`
+- `retro.moonweb.org/*` → `www.moonweb.org/retro/*`

- Deciding on 28k8.moonweb.org's future (stay separate vs. eventual monorepo inclusion).
- Building any Perplexity-backchannel mechanism for reusing published site content in this project.
- Redirecting the apex domain from `www.moonweb.org` to `hub.moonweb.org`.
- Any analytics, "last updated" timestamps, or scheduled/automated content generation beyond the one-time GitHub aggregator run.
+### Technical consolidation

-## Definition of done for this build
+- Single `eleventy.config.js` at root with computed `pathPrefix` per section.
+- Shared `base.njk` layout with inlined accent colors (no per-site theme CSS).
+- Central `_data/repos.json` (moved from `code/_data/`).
+- Central sitemap (`shared/_includes/sitemap.njk`) with all 36 pages.
+- Single `robots.txt` at root.
+- `.eleventyignore` excludes `stefankoelle/` and `timecapsule/` (built separately).
+- `build-pdf.sh` temporarily renames `.eleventyignore` for stefankoelle build.

- All sites live on their respective platforms:
-  - hub, infra, smarthome, code, retro on Cloudflare Pages under their intended domains.
-  - stefankoelle.de on IONOS via SFTP deployment.
- code.moonweb.org reflects the current GitHub repos via the `.moonweb.yml` aggregator, grouped by subcategory.
- smarthome.moonweb.org gives an accurate picture of what's running on the homelab today, with detail pages only where content already existed.
- infra.moonweb.org describes the stack shallowly with zero sensitive data leaked.
- retro.moonweb.org exists with an honest, minimal overview (WIP notices allowed).
- hub.moonweb.org correctly links everything, including the external sites (www.moonweb.org, 28k8.moonweb.org).
- stefankoelle.de is a working onepager with CV, Projects, Languages, Impressum, and the LED Matrix documentation sub-page.
+## 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.
+- `www.moonweb.org/smarthome/` gives an accurate picture of what's running on the homelab.
+- `www.moonweb.org/infra/` describes the stack shallowly with zero sensitive data leaked.
+- `www.moonweb.org/retro/` exists with an honest, minimal overview.
+- `www.moonweb.org/` correctly links everything.
+- `stefankoelle.de` is a working onepager with CV, Projects, Languages, Impressum, and LED Matrix documentation.
+- Old subdomains redirect via Cloudflare to new paths.
+- Old www.moonweb.org content preserved under `/timecapsule/`.
+
+## Remaining items
+
+- Cloudflare redirect rules need activation (script ready, needs `CLOUDFLARE_API_TOKEN` and `CLOUDFLARE_ZONE_ID` secrets, or manual dashboard setup).
+- Google Search Console: new property `www.moonweb.org` not yet created.
+- `moonweb-www` repository not yet archived.
@@ -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
@@ -21,21 +21,26 @@ stefankoelle.de            -> CV, career, personal site (LED Matrix docs)
 ```
 +-------------------------------------------------------------------+
 |                     GitHub Actions CI                              |
-|  +-----------+ +------------+ +-------------+ +---------+ +------+ |
-|  | build:hub | |build:infra | | build:smart | | build:... | | build:timecapsule | |
-|  +-----+-----+ +-----+------+ +------+------+ +----+----+ +----+----+ +--------+ |
-|        |             |               |             |        |          |        |
-|        v             v               v              v        v          v        |
-|   dist/hub/    dist/infra/   dist/smarthome/    dist/.../  dist/timecapsule/     |
-+--------+---------------------------------------------------+--------------------+
-         |                                                   |
-         v                                                   v
-+------------------+                               +------------------+
-|    IONOS SFTP    |                               |    IONOS SFTP    |
-| (www.moonweb.org)|                               | (stefankoelle.de)|
-+--------+---------+                               +--------+---------+
-         v                                                   v
-  www.moonweb.org/*                              stefankoelle.de
+|  +-------------------+  +---------------------+                   |
+|  | build-deploy-     |  | deploy-stefankoelle |                   |
+|  | moonweb           |  |                     |                   |
+|  +--------+----------+  +----------+----------+                   |
+|           |                        |                               |
+|           v                        v                               |
+|    npm run build            npm run build:stefankoelle             |
+|    + build:timecapsule      |                                     |
+|           |                 |                                     |
+|           v                 v                                     |
+|    dist/moonweb/       dist/stefankoelle/                        |
+-----------+------------------------+-------------------------------+
+            |                        |
+            v                        v
+------------------+       +------------------+
+|    IONOS SFTP    |       |    IONOS SFTP    |
+| (www.moonweb.org)|       | (stefankoelle.de)|
+--------+---------+       +--------+---------+
+         v                          v
+  www.moonweb.org/*         stefankoelle.de
 ```

 ---
@@ -47,9 +52,9 @@ stefankoelle.de            -> CV, career, personal site (LED Matrix docs)
 | **SSG** | [Eleventy 3.1.6](https://www.11ty.dev/) | Markdown/YAML-first, minimal JS, `_data` folders map directly to aggregator output |
 | **SSG (timecapsule)** | [Eleventy 2.0.1](https://www.11ty.dev/) | Legacy 2001 design, CommonJS config |
 | **Templates** | [Nunjucks](https://mozilla.github.io/nunjucks/) | Shared `base.njk` layout with site-switcher header, `card-grid.njk` for index pages |
-| **Styling** | Custom CSS (variables-based) | `base.css` for shared layout, `theme-*.css` per domain accent color |
+| **Styling** | Custom CSS (variables-based) | `base.css` for shared layout, accent colors inlined in `base.njk` |
 | **Fonts** | [Lobster](https://fonts.google.com/specimen/Lobster) (Google Fonts) | Distinctive heading font across all sites |
-| **CI/CD** | [GitHub Actions](https://github.com/features/actions) | Matrix build for all sites, artifact upload, merge step, parallel deploy |
+| **CI/CD** | [GitHub Actions](https://github.com/features/actions) | Single build job, parallel SFTP deploy |
 | **Deploy** | IONOS SFTP | Static hosting via SFTP upload |
 | **DNS** | Cloudflare | DNS management + redirects from old subdomains |
 | **GitHub Catalog** | Python aggregator | Reads `.moonweb.yml` from each repo, outputs `repos.json` |
@@ -63,27 +68,19 @@ stefankoelle.de            -> CV, career, personal site (LED Matrix docs)
 npm install                        # install Eleventy + deps
 cd timecapsule && npm install      # timecapsule has own deps (Eleventy 2.x)

-npm run dev:hub                    # http://localhost:8081
-npm run dev:infra                  # http://localhost:8082
-npm run dev:smarthome              # http://localhost:8083
-npm run dev:code                   # http://localhost:8084
-npm run dev:retro                  # http://localhost:8085
-npm run dev:stefankoelle           # http://localhost:8086
-npm run dev:timecapsule            # http://localhost:8087
-
-npm run dev                        # all 7 in parallel
+npm run dev                        # moonweb sites (localhost:8081)
+npm run dev:stefankoelle           # stefankoelle.de (localhost:8086)
+npm run dev:timecapsule            # timecapsule (localhost:8087)
 ```

-Each site has its own minimal Eleventy config (`<site>/eleventy.config.js`). Live reload is built in.
-
 ### Build

 ```bash
-npm run prebuild                     # pre-build tasks (CV PDF)
-npm run build                        # builds all sites
-npm run build:moonweb                # builds moonweb sites only (excludes stefankoelle)
-npm run build:hub                    # build single site
-npm run merge:moonweb                # merge all moonweb sites into dist/ for deployment
+npm run prebuild:cv                     # pre-build tasks (CV PDF)
+npm run build                        # builds all moonweb sites (hub, infra, smarthome, code, retro)
+npm run build:stefankoelle           # builds stefankoelle.de
+npm run build:timecapsule            # builds timecapsule
+npm run build:moonweb                # builds moonweb + timecapsule (for deployment)
 ```

 ---
@@ -92,18 +89,10 @@ npm run merge:moonweb                # merge all moonweb sites into dist/ for de

 ```
 moonweb-site/
-├── hub/                          # Central index & gateway
+├── hub/                          # Central index + redirect .htm files
 ├── infra/                        # Infra overview + 8 detail pages
-│   ├── backup-strategy/
-│   ├── monitoring/
-│   ├── dev-environment/
-│   └── ...
 ├── smarthome/                    # Smart home overview + 9 detail pages
-│   ├── homematic-mqtt/
-│   ├── tasmota-energy/
-│   └── ...
 ├── code/                         # GitHub catalog
-│   └── _data/repos.json          # populated by the aggregator
 ├── retro/                        # Retro hardware + 13 detail pages
 ├── timecapsule/                  # 2000s retro design (Eleventy 2.x)
 │   ├── eleventy.config.js
@@ -111,27 +100,32 @@ moonweb-site/
 │   └── src/
 ├── stefankoelle/                 # CV, career, personal site
 │   ├── eleventy.config.js
-│   ├── index.njk                 # Onepager (CV, Projects, Languages)
-│   ├── cv-print.njk              # CV-only for PDF generation
-│   ├── ledmatrix/                # LED Matrix WebServer documentation
-│   └── assets/                   # CSS, JS, images, favicons
+│   ├── index.njk
+│   ├── cv-print.njk
+│   ├── ledmatrix/
+│   └── assets/
 ├── shared/                       # Shared components
 │   ├── _includes/
 │   │   ├── base.njk              # base layout (header, site-switcher, footer)
-│   │   └── card-grid.njk         # card-grid template with emoji support
-│   ├── base.css                  # shared CSS (layout, cards, typography)
-│   └── theme-*.css               # accent colors per domain
+│   │   ├── card-grid.njk         # card-grid template
+│   │   └── sitemap.njk           # central sitemap template
+│   ├── base.css                  # shared CSS
+│   └── favicon/                  # favicon SVGs per section
+├── _data/
+│   └── repos.json                # populated by the GitHub aggregator
 ├── scripts/
 │   ├── github-aggregator/        # Python: reads .moonweb.yml -> repos.json
-│   └── merge-moonweb.sh          # Merge script for deployment
+│   └── cloudflare/               # redirect setup for old subdomains
 ├── .github/workflows/
-│   ├── build-deploy-moonweb.yml  # CI/CD: build + deploy to IONOS SFTP
-│   └── deploy-stefankoelle.yml   # CI/CD: stefankoelle.de to IONOS SFTP
-├── DESIGN.md                     # Initial concept
-├── SPEC.md                       # Full specification
-├── PLAN.md                       # Implementation plan
-├── TODO.md                       # Open items & workflow
-└── package.json                  # npm scripts for dev/build
+│   ├── build-deploy-moonweb.yml  # CI/CD: IONOS SFTP (www.moonweb.org)
+│   └── deploy-stefankoelle.yml   # CI/CD: IONOS SFTP (stefankoelle.de)
+├── eleventy.config.js            # single config for all moonweb sites
+├── .eleventyignore               # excludes stefankoelle/, timecapsule/
+├── DESIGN.md
+├── SPEC.md
+├── PLAN.md
+├── TODO.md
+└── package.json
 ```

 ---
@@ -145,24 +139,12 @@ Defined in `.github/workflows/build-deploy-moonweb.yml`:
 ```
 push to main
    |
-    +-- Build (matrix: hub, infra, smarthome, code, retro)
+    +-- Build
    |   +-- checkout -> setup-node (22) -> npm ci
-    |   +-- npm run build:<site>
-    |   +-- validate dist/<site>/ exists & non-empty
-    |   +-- upload artifact (7-day retention)
-    |
-    +-- Build timecapsule
-    |   +-- cd timecapsule && npm ci
+    |   +-- npm run build (all moonweb sites in one Eleventy run)
    |   +-- npm run build:timecapsule
-    |   +-- upload artifact
-    |
-    +-- Merge
-    |   +-- download all artifacts
-    |   +-- merge into dist/ (hub=root, others=subdirs)
-    |   +-- upload merged artifact
    |
    +-- Deploy
-        +-- download merged artifact
        +-- SFTP upload to IONOS /websites/moonweb/
 ```

@@ -223,7 +205,7 @@ Cloudflare redirects forward old subdomains:
 2. Reads `.moonweb.yml` from each repo root
 3. Filters for `category: code` entries
 4. Sorts by subcategory + title
-5. Writes combined result to `code/_data/repos.json`
+5. Writes combined result to `_data/repos.json`

 ### `.moonweb.yml` schema

@@ -241,8 +223,9 @@ repo_url: "https://github.com/skoelle/mvg-departures"
 ### Manual run

 ```bash
-export GITHUB_TOKEN=ghp_xxx
-python scripts/github-aggregator/aggregate.py
+python3 -m venv .venv
+.venv/bin/pip install pyyaml
+.venv/bin/python scripts/github-aggregator/aggregate.py
 ```

 ---
@@ -276,6 +259,7 @@ All moonweb sites are written **entirely in English**. The timecapsule uses the
 | `PLAN.md` | Phased implementation plan |
 | `TODO.md` | Open items, workflow, and current status |
 | `README.md` | This file - project overview for GitHub |
+| `AGENTS.md` | AI agent instructions for this codebase |

 ---

@@ -1,96 +1,102 @@
-# moonweb.org — Specification
+# moonweb.org, Specification

-Status: Concept finalized. This document defines *what* gets built. See `PLAN.md` for *how and in what order*.
+Status: Migration complete. All sites live under `www.moonweb.org` as subdirectories, deployed via IONOS SFTP.

 ## 1. Purpose

-A personal homelab hub consisting of a central index (`hub`) and several themed static sites, replacing the current unstructured presentation of infrastructure, smart home projects, and GitHub repos. cv (stefankoelle.de) remains external, linked from the hub and site-switcher.
+A personal homelab hub consisting of a central index (`hub` at root) and several themed static sites, all served under `www.moonweb.org` as subdirectories. The old timecapsule content (2001 design) is preserved under `/timecapsule/`. cv (stefankoelle.de) remains external, linked from the hub and site-switcher.

 ## 2. Sitemap

 ```
 moonweb-site (monorepo)
-├── hub/         → hub.moonweb.org        Central index & gateway
-├── infra/       → infra.moonweb.org      System architecture / stack overview
-├── smarthome/   → smarthome.moonweb.org  What the homelab actually runs, and why
-├── code/        → code.moonweb.org       Curated GitHub catalog
-├── retro/       → retro.moonweb.org      Physical retro hardware collection
-└── stefankoelle/→ stefankoelle.de        CV, career, personal site (SFTP deploy)
+├── hub/         → www.moonweb.org/           Central index & gateway
+├── infra/       → www.moonweb.org/infra/     System architecture / stack overview
+├── smarthome/   → www.moonweb.org/smarthome/ What the homelab actually runs, and why
+├── code/        → www.moonweb.org/code/      Curated GitHub catalog
+├── retro/       → www.moonweb.org/retro/     Physical retro hardware collection
+├── timecapsule/ → www.moonweb.org/timecapsule/ 2001-era internet time capsule
+└── stefankoelle/→ stefankoelle.de            CV, career, personal site (SFTP deploy)

 outside the monorepo, untouched:
-├── www.moonweb.org          finished, no overlap (2001-style internet time capsule)
-├── 28k8.moonweb.org         90s BBS/scene archive, separate approach, may migrate later (undecided)
-
+├── 28k8.moonweb.org         90s BBS/scene archive
+├── buildbroken.moonweb.org  .NET Open Space blog archive
 ```

-Apex domain `moonweb.org` currently redirects to `www.moonweb.org`. This stays as-is for now; a later redirect to `hub.moonweb.org` is possible but out of scope for this build.
+Old subdomain redirects (via Cloudflare):
+- `hub.moonweb.org/*` → `www.moonweb.org/*`
+- `infra.moonweb.org/*` → `www.moonweb.org/infra/*`
+- `smarthome.moonweb.org/*` → `www.moonweb.org/smarthome/*`
+- `code.moonweb.org/*` → `www.moonweb.org/code/*`
+- `retro.moonweb.org/*` → `www.moonweb.org/retro/*`

 ## 3. Domain purposes

-| Domain | Purpose | Tone |
-|---|---|---|
-| hub | Gateway, links to everything, one-line description per destination | Minimal |
-| infra | Shallow, structured overview of the stack: Proxmox (PVE + pve2), Synology DS918+, VLANs, Fritz!Box mesh, SSO, plus how I work (OpenCode/OpenClaw dev environment) | Reference, high-level only |
-| smarthome | Why the homelab exists — what's actually running on the homelab as smart home: sensors, automation, calendar/contacts sync, dashboards, media | Project storytelling |
-| code | Curated, sorted GitHub catalog — overview only, always linking out to GitHub | Portfolio |
-| retro | Physical retro hardware collection (not software/demos — that's 28k8's domain) | Simple, factual |
+| Domain | URL | Purpose | Tone |
+|---|---|---|---|
+| 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 |
+| 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 |
+| timecapsule | `/timecapsule/` | Original www.moonweb.org content from 2001, preserved as-is | Retro 2001 design |

 ## 4. Design system

 ### 4.1 Header-consistent, content-flexible principle

- **Header is identical** across infra/smarthome/code/retro: site-switcher (hub · infra · smarthome · code · retro), domain accent color, consistent branding.
- **Overview (index) pages** use a shared card-grid layout (reference: clean card-grid layout 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 (reference: `/ledmatrix/` on stefankoelle.de today — pin tables, API docs, photos in free layout instead of a rigid card grid).
+- **Header is identical** across all sites: site-switcher (home · infra · smarthome · code · retro · cv), section title (`moonweb.org` or `moonweb.org/smarthome`), domain accent color.
+- **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 is now part of the monorepo but 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

-| Domain | Accent |
-|---|---|
-| hub | Neutral blue |
-| infra | Grey-blue |
-| smarthome | Teal |
-| code | Violet |
-| retro | Own accent, still clean card-grid (no 90s styling — that belongs to 28k8) |
+| Domain | Accent | Implementation |
+|---|---|---|
+| hub | Neutral blue (#3b6ea5) | Inlined `<style>` in base.njk |
+| infra | Red (#99333A) | Inlined `<style>` in base.njk |
+| smarthome | Teal (#1f8a8a) | Inlined `<style>` in base.njk |
+| code | Violet (#3E5098) | Inlined `<style>` in base.njk |
+| retro | Brown (#8a6d3b) | Inlined `<style>` in base.njk |

 ### 4.3 URL convention

-`domain/slug/` — lowercase, hyphenated, trailing slash, matching the existing stefankoelle.de pattern (e.g. `/ledmatrix/`) so future detail pages stay consistent even if content later migrates between sites.
+`/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 (e.g. Heimnetzwerk-Final-v3.2, GL_Flint2_Final_v2) currently contain real IPs and keys that must be actively stripped during migration.
+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 (code.moonweb.org)
+## 8. GitHub automation (www.moonweb.org/code/)

 Each GitHub project repo gets a `.moonweb.yml` in its root:

 ```yaml
 title: "MVG Departures"
 category: code          # code | smarthome | infra
-subcategory: "Web Apps" # drives grouping on code.moonweb.org
+subcategory: "Web Apps" # drives grouping on www.moonweb.org/code/
 status: active
 stack: [Python, FastAPI]
 hosted_on: "Docker Host Debian (PVE)"
@@ -98,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, an AI pass turns the raw YAML into readable card copy, and the result is committed into `code/_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).

@@ -112,47 +118,60 @@ A local aggregator script reads `.moonweb.yml` from all repos via the GitHub API

 ```
 moonweb-site/
-├── hub/
-├── infra/
-├── smarthome/
-├── code/
-│   └── _data/repos.json     # populated by the GitHub aggregator
-├── retro/
-├── stefankoelle/            # CV, career, personal site
+├── hub/                    # Index + Redirects (.htm) + impressum.njk
+├── infra/                  # Index.njk + 8 Subseiten
+├── smarthome/              # Index.njk + 9 Subseiten
+├── code/                   # Index.njk
+├── retro/                  # Index.njk + 13 Subseiten
+├── timecapsule/            # Eleventy 2.x (eigene Config)
 │   ├── eleventy.config.js
-│   ├── index.njk            # Onepager (CV, Projects, Languages)
-│   ├── cv-print.njk         # CV-only for PDF generation
-│   ├── ledmatrix/           # LED Matrix WebServer documentation
-│   └── assets/              # CSS, JS, images, favicons
-├── shared/
+│   ├── package.json
+│   └── src/
+├── stefankoelle/           # Eleventy-Config + Onepager
+│   ├── eleventy.config.js
+│   ├── index.njk
+│   ├── cv-print.njk
+│   ├── ledmatrix/
+│   └── assets/
+├── shared/                 # Shared components
 │   ├── _includes/
-│   │   ├── base.njk          # shared header + footer layout
-│   │   └── card-grid.njk     # card-grid template
-│   ├── base.css              # shared CSS variables and layout
-│   └── theme-*.css           # one accent color file per domain
+│   │   ├── base.njk        # base layout (header, site-switcher, footer)
+│   │   ├── card-grid.njk   # card-grid template
+│   │   └── sitemap.njk     # central sitemap template
+│   ├── base.css            # shared CSS
+│   └── favicon/            # favicon SVGs per section
+├── _data/
+│   └── repos.json          # populated by the GitHub aggregator
 ├── scripts/
-│   └── github-aggregator/    # reads .moonweb.yml from all repos
-├── DESIGN.md                 # initial concept and design decisions
-├── SPEC.md                   # what gets built (this document)
-├── PLAN.md                   # how and in what order
-├── TODO.md                   # open items and workflow
-└── .github/workflows/
-    ├── build-deploy.yml      # builds all sites, deploys to Cloudflare Pages
-    └── deploy-stefankoelle.yml # builds stefankoelle, deploys via IONOS SFTP
+│   ├── github-aggregator/  # reads .moonweb.yml from all repos
+│   └── cloudflare/         # redirect setup for old subdomains
+├── .github/workflows/
+│   ├── build-deploy-moonweb.yml   # builds all moonweb sites, deploys to IONOS SFTP
+│   └── deploy-stefankoelle.yml    # builds stefankoelle, deploys via IONOS SFTP
+├── eleventy.config.js      # single Eleventy config for all moonweb sites
+├── .eleventyignore         # excludes stefankoelle/, timecapsule/
+├── DESIGN.md
+├── SPEC.md
+├── PLAN.md
+├── TODO.md
+└── package.json
 ```

 ## 11. Technical stack

- **Static site generator:** Eleventy (11ty) — markdown/YAML-first, minimal JS, `_data` folders map directly onto the `.moonweb.yml` aggregator output, low maintenance for five sites at this scale.
+- **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.
+- **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:** Cloudflare Pages — five separate Pages projects (one per public domain: hub, infra, smarthome, code, retro), since Cloudflare Pages binds one custom-domain set per project. stefankoelle.de deploys via IONOS SFTP. Two GitHub Actions workflows handle deployment.
- **Runtime:** fully static, no server-side code, no containers for the website itself (distinct from the actual homelab services running on the Docker host).
- **DNS:** already on Cloudflare — no additional setup step needed for Pages custom domains.
- **Local preview:** Eleventy's built-in dev server with live reload, run per-site (`npm run dev:<site>`) before any commit.
+- **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.).
+- **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 for this build
+## 12. Explicitly out of scope

- Migrating 28k8.moonweb.org into the monorepo — undecided, revisit later, likely never.
- Any Perplexity-backchannel mechanism (website content reusable inside this project) — deferred, no time invested now.
+- Migrating 28k8.moonweb.org into the monorepo, undecided, revisit later, likely never.
+- Any Perplexity-backchannel mechanism, deferred.
 - Analytics of any kind.
- Automated content generation/translation pipelines beyond the one-time GitHub aggregator for code and the one-time translation pass during migration.
+- Automated content generation/translation pipelines beyond the one-time GitHub aggregator for code.
@@ -1,87 +1,76 @@
-# TODO: Consolidation zu www.moonweb.org
+# TODO: moonweb-site

-## Uebersicht
+## Status: Consolidation Complete

-Alle moonweb.org Sites (hub, infra, smarthome, code, retro, timecapsule) unter `www.moonweb.org` als Subverzeichnisse vereinen. Deployment von Cloudflare Pages zu IONOS SFTP migrieren.
-
-**URL-Struktur nach Migration:**
-| URL | Inhalt |
-|-----|--------|
-| `www.moonweb.org/` | Hub (neue Root) |
-| `www.moonweb.org/infra/` | Infra |
-| `www.moonweb.org/smarthome/` | Smarthome |
-| `www.moonweb.org/code/` | Code |
-| `www.moonweb.org/retro/` | Retro |
-| `www.moonweb.org/timecapsule/` | Altes www (2001-Retro) |
-| `stefankoelle.de/` | CV (bleibt separat) |
+All moonweb.org sites are consolidated under `www.moonweb.org` as subdirectories, deployed via IONOS SFTP. PR #3 merged to main.

 ---

-## Phase 1: Timecapsule in Monorepo integrieren
+## Completed

- [x] 1.1 Dateien aus ../moonweb-www/src/ nach timecapsule/src/ kopieren
- [x] 1.2 timecapsule/eleventy.config.js erstellen (Eleventy 2.x)
- [x] 1.3 timecapsule/package.json erstellen (eigene Dependencies)
- [x] 1.4 timecapsule/src/_data/site.json anpassen (Domain mit /timecapsule/)
- [x] 1.5 Alle internen Pfade mit /timecapsule/ prefixieren
- [x] 1.6 Passthrough Copy in eleventy.config.js anpassen
- [x] 1.7 Build-Output pruefen (dist/timecapsule/)
+### Phase 1: Timecapsule Integration
+- [x] Copy files from moonweb-www/src/ to timecapsule/src/
+- [x] Create timecapsule/eleventy.config.js (Eleventy 2.x)
+- [x] Create timecapsule/package.json (own dependencies)
+- [x] Adapt timecapsule internal paths with /timecapsule/ prefix

-## Phase 2: Eleventy-Configs aller Sites anpassen
+### Phase 2: Single Eleventy Config
+- [x] Create root eleventy.config.js with computed pathPrefix per section
+- [x] Delete 5 per-site eleventy.config.js files (hub, infra, smarthome, code, retro)
+- [x] Delete scripts/merge-moonweb.sh
+- [x] Update shared/_includes/base.njk (inlined accent colors, root CSS path)
+- [x] Update hub/index.njk card hrefs (relative paths)
+- [x] Update hub/impressum.njk (hosting sections correct)
+- [x] Update parent values in detail pages to include section prefix
+- [x] Add tags to all pages for Eleventy collections

- [x] 2.1 hub/eleventy.config.js: site.url auf www.moonweb.org
- [x] 2.2 infra/eleventy.config.js: site.url auf www.moonweb.org
- [x] 2.3 smarthome/eleventy.config.js: site.url auf www.moonweb.org
- [x] 2.4 code/eleventy.config.js: site.url auf www.moonweb.org
- [x] 2.5 retro/eleventy.config.js: site.url auf www.moonweb.org
- [x] 2.6 shared/_includes/base.njk anpassen
- [x] 2.7 hub/index.njk: Card-Hrefs relativieren
- [x] 2.8 hub/impressum.njk: Domain-Liste aktualisieren
+### Phase 3: Build & Deploy
+- [x] Create .github/workflows/build-deploy-moonweb.yml (single build job, SFTP deploy)
+- [x] Delete old build-deploy.yml (matrix builds)
+- [x] Update .eleventyignore (exclude stefankoelle/, timecapsule/, markdown)
+- [x] Fix build-pdf.sh to temporarily rename .eleventyignore for stefankoelle build
+- [x] Fix timecapsule build path (../dist/ not ../../dist/)

-## Phase 3: Build-System anpassen
+### Phase 4: Redirects & SEO
+- [x] Create 20 redirect .htm files in hub/ for old www.moonweb.org paths
+- [x] Create central sitemap.xml (36 pages)
+- [x] Create single robots.txt at root
+- [x] Set up Cloudflare redirect rules script (scripts/cloudflare/)

- [x] 3.1 package.json: Neue Scripts fuer timecapsule + merge
- [x] 3.2 scripts/merge-moonweb.sh erstellen
- [x] 3.3 Lokal Build testen (alle Sites)
+### Phase 5: Bug Fixes
+- [x] Fix card links on index pages (add section prefix to local hrefs)
+- [x] Fix code repos missing (move repos.json to root _data/)
+- [x] Fix favicons (use section-specific favicon.svg per site)
+- [x] Fix header (show moonweb.org/smarthome instead of smarthome.moonweb.org)
+- [x] Rename hub link to home in site-switcher nav
+- [x] Remove redundant 404 pages, keep only root 404
+- [x] Add missing beginning subpage redirects (news, report, sitemap)
+- [x] Fix double-slash URLs in stefankoelle/index.njk
+- [x] Remove unused theme-*.css files
+- [x] Update stefankoelle link texts (replace old subdomain names with new paths)

-## Phase 4: Deployment umstellen
-
- [x] 4.1 Neuen Workflow .github/workflows/build-deploy-moonweb.yml erstellen
- [x] 4.2 Alten Workflow .github/workflows/build-deploy.yml entfernen
- [ ] 4.3 Alten deploy-moonweb.yml in moonweb-www deaktivieren
-
-## Phase 5: Cloudflare Redirects
-
- [x] 5.1 Redirect-Regeln einrichten (via GitHub Action)
-
-| Quell-Domain | Ziel-URL | Type |
-|-------------|----------|------|
-| `hub.moonweb.org/*` | `https://www.moonweb.org/$1` | 301 |
-| `infra.moonweb.org/*` | `https://www.moonweb.org/infra/$1` | 301 |
-| `smarthome.moonweb.org/*` | `https://www.moonweb.org/smarthome/$1` | 301 |
-| `code.moonweb.org/*` | `https://www.moonweb.org/code/$1` | 301 |
-| `retro.moonweb.org/*` | `https://www.moonweb.org/retro/$1` | 301 |
-
-**Umsetzung:** `scripts/cloudflare/setup-redirects.sh` + GitHub Action `cloudflare-redirects.yml`
-**Benötigte Secrets:** `CLOUDFLARE_API_TOKEN`, `CLOUDFLARE_ZONE_ID`
-
-## Phase 6: SEO
-
- [ ] 6.1 Google Search Console: Neue Property www.moonweb.org
- [ ] 6.2 Sitemap submiten
-
-## Phase 7: Cleanup
-
- [ ] 7.1 moonweb-www Repository archivieren
- [ ] 7.2 Cloudflare Pages Projects loeschen (nach Redirect-Test)
+### Phase 6: Documentation
+- [x] Update AGENTS.md for new structure
+- [x] Update README.md for new structure
+- [x] Update SPEC.md for new structure
+- [x] Update PLAN.md for new structure

 ---

-## Abgeschlossen
+## Remaining

-Alle Code-Aenderungen sind fertig. Nächste Schritte:
-1. Commit auf feature/consolidate-www Branch
-2. Push und PR erstellen
-3. Deployen
-4. Cloudflare Redirects einrichten
-5. Google Search Console aktualisieren
+### Cloudflare Redirects
+- [ ] Activate redirect rules (needs `CLOUDFLARE_API_TOKEN` and `CLOUDFLARE_ZONE_ID` secrets, or manual dashboard setup)
+- [ ] Verify redirects work after activation
+
+### SEO
+- [ ] Create Google Search Console property for www.moonweb.org
+- [ ] Submit sitemap
+
+### Cleanup
+- [ ] Archive moonweb-www repository
+- [ ] Delete Cloudflare Pages projects (after redirect verification)
+
+### Future
+- [ ] Cross-linking stefankoelle.de <-> smarthome
+- [ ] Consider moving LED Matrix to smarthome (when ready)
@@ -1,4 +1,21 @@
 [
+  {
+    "title": "Chat Archive",
+    "emoji": "💬",
+    "category": "code",
+    "subcategory": "Dev Tools",
+    "status": "active",
+    "stack": [
+      "Python",
+      "FastAPI",
+      "SQLAlchemy",
+      "Tauri",
+      "Rust"
+    ],
+    "repo": "chat-archive",
+    "repo_url": "https://github.com/skoelle/chat-archive",
+    "summary": "Import Instagram & Facebook (incl. E2EE) chat takeouts into a searchable MySQL database with a REST API for analysis"
+  },
  {
    "title": "PeopleCostCounter",
    "emoji": "💰",
@@ -14,6 +31,22 @@
    "repo_url": "https://github.com/skoelle/PeopleCostCounter",
    "summary": "A vanilla JS single-page tool that shows in real time how much a meeting is costing, based on team size and average salary, with English and German UIs."
  },
+  {
+    "title": "Smeagol WYSIWYG",
+    "emoji": "🧙",
+    "category": "code",
+    "subcategory": "Dev Tools",
+    "description": "Personal wiki with WYSIWYG editor for Markdown files",
+    "status": "active",
+    "stack": [
+      "Go",
+      "Milkdown",
+      "Markdown"
+    ],
+    "repo": "smeagol-wysiwyg",
+    "repo_url": "https://github.com/skoelle/smeagol-wysiwyg",
+    "summary": "A personal wiki with a real WYSIWYG editor. Single Go binary, Markdown files on disk, instant save, live reload, full-text search."
+  },
  {
    "title": "kctl-tui",
    "emoji": "🐳",
@@ -259,7 +292,7 @@
    ],
    "repo": "moonweb-site",
    "repo_url": "https://github.com/skoelle/moonweb-site",
-    "summary": "Monorepo for moonweb.org - my personal homelab hub. Six static sites (Eleventy) covering infrastructure, smart home, code, and retro hardware. Deployed to Cloudflare Pages or IONOS."
+    "summary": "Monorepo for moonweb.org - my personal homelab hub. Six static sites (Eleventy) covering infrastructure, smart home, code, and retro hardware. Deployed to IONOS."
  },
  {
    "title": "www.moonweb.org",
@@ -1,13 +0,0 @@
---
-title: "Page Not Found"
-section: "code"
-tags: "code"
-description: "The page you are looking for does not exist."
-layout: base.njk
-permalink: /code/404.html
---
-<div class="error-page">
-  <h1>404</h1>
-  <p>The page you are looking for does not exist or has been moved.</p>
-  <a class="back-link" href="/">← Back to code</a>
-</div>
@@ -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 %}
@@ -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,8 +28,35 @@ 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");
+
+  // Retro: STPSU page images + manual PDF
+  eleventyConfig.addPassthroughCopy("retro/stpsu/*.pdf");
+
+  // Retro: page-specific photo galleries (MonSTerBoard, Gotek, Eiffel, STPSU)
+  eleventyConfig.addPassthroughCopy("retro/monsterboard/*.jpg");
+  eleventyConfig.addPassthroughCopy("retro/gotek/*.jpg");
+  eleventyConfig.addPassthroughCopy("retro/eiffel/*.jpg");
+  eleventyConfig.addPassthroughCopy("retro/stpsu/*.jpg");
+  eleventyConfig.addPassthroughCopy("retro/acsi2stm/*.jpg");
+  eleventyConfig.addPassthroughCopy("retro/atari-vga/*.jpg");
+  eleventyConfig.addPassthroughCopy("retro/laser-mouse/*.jpg");
+  eleventyConfig.addPassthroughCopy("retro/mega-st-high/*.jpg");
+  eleventyConfig.addPassthroughCopy("retro/dos-486-tower/*.jpg");
+  eleventyConfig.addPassthroughCopy("retro/mistery-core/*.jpg");
+  eleventyConfig.addPassthroughCopy("retro/mini-arcade-handheld-roundup/*.jpg");
+
+  // Standalone demo group archives (static HTML)
+  eleventyConfig.addPassthroughCopy("phobia/**");
+  eleventyConfig.addPassthroughCopy("tcm/**");
+
  // Root-level shared assets
  eleventyConfig.addPassthroughCopy({ "shared/base.css": "shared-base.css" });
+  eleventyConfig.addPassthroughCopy({ "shared/fonts/lobster-latin.woff2": "fonts/lobster-latin.woff2" });
  eleventyConfig.addPassthroughCopy({ "shared/favicon/hub.svg": "favicon.svg" });
  eleventyConfig.addPassthroughCopy({ "hub/robots.txt": "robots.txt" });

@@ -76,12 +107,18 @@ module.exports = function (eleventyConfig) {
      [`hub/${dir}/index.htm`]: `${dir}/index.html`,
    });
  }
+  const beginningSubpages = ["news", "report", "sitemap"];
+  for (const name of beginningSubpages) {
+    eleventyConfig.addPassthroughCopy({
+      [`hub/beginning/${name}.htm`]: `beginning/${name}.html`,
+    });
+  }

  return {
    dir: {
      input: ".",
      includes: "shared/_includes",
-      output: "dist",
+      output: "dist/moonweb",
    },
    serverOptions: {
      host: "0.0.0.0",
@@ -9,5 +9,5 @@ permalink: /404.html
 <div class="error-page">
  <h1>404</h1>
  <p>The page you are looking for does not exist or has been moved.</p>
-  <a class="back-link" href="/">← Back to hub</a>
+  <a class="back-link" href="/">← Back to home</a>
 </div>
@@ -0,0 +1,11 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta charset="UTF-8">
+<meta http-equiv="refresh" content="0;url=/timecapsule/beginning/news.html">
+<title>Redirecting...</title>
+</head>
+<body>
+<p>Redirecting to <a href="/timecapsule/beginning/news.html">/timecapsule/beginning/news.html</a>...</p>
+</body>
+</html>
@@ -0,0 +1,11 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta charset="UTF-8">
+<meta http-equiv="refresh" content="0;url=/timecapsule/beginning/report.html">
+<title>Redirecting...</title>
+</head>
+<body>
+<p>Redirecting to <a href="/timecapsule/beginning/report.html">/timecapsule/beginning/report.html</a>...</p>
+</body>
+</html>
@@ -0,0 +1,11 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta charset="UTF-8">
+<meta http-equiv="refresh" content="0;url=/timecapsule/beginning/sitemap.html">
+<title>Redirecting...</title>
+</head>
+<body>
+<p>Redirecting to <a href="/timecapsule/beginning/sitemap.html">/timecapsule/beginning/sitemap.html</a>...</p>
+</body>
+</html>
@@ -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 (hub, 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 (hub, 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>
-<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>
+<h4>b) Cloudflare Pages &mdash; hosts buildbroken.moonweb.org and 28k8.moonweb.org</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>
@@ -1,9 +1,9 @@
 ---
-title: "Stefan Koelle — Homelab, Smart Home, Code & Retro Hardware | moonweb"
+title: "Stefan Koelle, 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 Koelle, 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:
@@ -37,8 +37,8 @@ sections:
        summary: "tHE tEMPLE BBS Mailbox and 90s releases archive."
        href: "https://28k8.moonweb.org"
        emoji: "💾"
-      - title: "www.moonweb.org"
-        summary: "The 2000s internet projects, networking and engineering."
+      - title: "moonweb.org 2001"
+        summary: "The original www.moonweb.org as it was in 2001, preserved as a time capsule."
        href: "/timecapsule/"
        emoji: "🌐"
      - title: "inseco.de"
@@ -52,10 +52,10 @@ 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>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>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 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">
 </div>
@@ -64,17 +64,17 @@ sections:

 <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 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 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, <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>
@@ -1,13 +0,0 @@
---
-title: "Page Not Found"
-section: "infra"
-tags: "infra"
-description: "The page you are looking for does not exist."
-layout: base.njk
-permalink: /infra/404.html
---
-<div class="error-page">
-  <h1>404</h1>
-  <p>The page you are looking for does not exist or has been moved.</p>
-  <a class="back-link" href="/">← Back to infra</a>
-</div>
@@ -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>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>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>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>
@@ -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>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>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>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>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>
 </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://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://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://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>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>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>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>
@@ -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-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-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-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/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>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>/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/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>
 </ul>

 <h2>Own GitHub projects</h2>
 <ul>
-<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>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>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>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>
 </ul>

 <h2>Infrastructure containers</h2>
 <ul>
-<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>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>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>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>exporters</strong> — Prometheus exporters for Fritz!Box, Zyxel switches, Nginx, and SNMP devices, feeding the Grafana/Prometheus stack.</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>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>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>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>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>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>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>Music Stretto</strong> — music streaming server for the local MP3 library on the Synology, accessible from the home dashboard.</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>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>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>
 </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>
@@ -1,47 +1,48 @@
 ---
-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."
 layout: base.njk
 sections:
-  - heading: "Plattform"
+  - heading: "Platform"
    cards:
      - title: "🖥️ Proxmox host (PVE)"
        summary: "Hosting environment for running production VMs and LXC containers for the homelab."
-        href: "/proxmox/"
+        href: "/infra/proxmox/"
      - title: "💾 Synology DS918+"
        summary: "NAS running Docker services and acting as the primary backup repository."
-        href: "/synology/"
+        href: "/infra/synology/"
      - title: "🐳 Docker VMs (Debian)"
        summary: "Primary target for new Docker/Compose services, running the monitoring exporters."
-        href: "/docker/"
-      - title: "📦 LxC Container"
-        summary: "Pi-hole, Ubuntu-Worker and MariaDB running on slim LxC Containers."
-        href: "/lxc/"
+        href: "/infra/docker/"
+      - title: "📦 LXC Container"
+        summary: "Pi-hole, Ubuntu-Worker and MariaDB running on slim LXC Containers."
+        href: "/infra/lxc/"
  - heading: "Strategies & Setup-Guides"
    cards:
      - title: "🔄 Backup strategy"
        summary: "Layered backup approach covering NAS user content and VM/LXC backups across multiple locations."
-        href: "/backup-strategy/"
+        href: "/infra/backup-strategy/"
      - title: "📊 Prometheus/Grafana"
        summary: "Central metrics collection and dashboards for hosts, containers, and hardware."
-        href: "/monitoring/"
+        href: "/infra/monitoring/"
      - title: "💻 Dev environment"
        summary: "A disposable, daily-backed-up Xubuntu VM for AI-assisted, remote development via SSH and Chrome Remote Desktop."
-        href: "/dev-environment/"
+        href: "/infra/dev-environment/"
      - title: "🌐 OpenWrt Multi-WAN"
        summary: "Multi-WAN router with WiFi and Powerline failover, plus IoT VLAN 189 isolation."
-        href: "/openwrt/"
+        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 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 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 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>
@@ -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>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>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>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>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>
 </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>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>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>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>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>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>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>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>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>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>
@@ -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 —
-feeds metrics into this central instance.</p>
+flat, including the Proxmox host, Docker VM, Synology NAS, and Raspberry
+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>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>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>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>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>
 </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>
@@ -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 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>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>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>
@@ -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>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>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>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="/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>
 </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>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>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>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>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>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>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>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>
 </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>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>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>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>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>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>
@@ -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>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>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>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 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>
 </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>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>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>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>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>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>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>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>
 </ul>

 </div>
@@ -8,11 +8,11 @@
    "dev:stefankoelle": "npx @11ty/eleventy --config=stefankoelle/eleventy.config.js --serve --port=8086",
    "dev:timecapsule": "cd timecapsule && npx @11ty/eleventy --serve --port=8087",
    "build": "npx @11ty/eleventy",
-    "build:stefankoelle": "npx @11ty/eleventy --config=stefankoelle/eleventy.config.js",
-    "build:timecapsule": "cd timecapsule && npx @11ty/eleventy && mkdir -p ../dist/timecapsule && cp -r _site/timecapsule/* ../dist/timecapsule/",
+    "build:stefankoelle": "mv .eleventyignore .eleventyignore.bak && npx @11ty/eleventy --config=stefankoelle/eleventy.config.js; mv .eleventyignore.bak .eleventyignore 2>/dev/null; true",
+    "build:timecapsule": "cd timecapsule && rm -r _site 2>/dev/null; npx @11ty/eleventy && rm -r ../dist/moonweb/timecapsule 2>/dev/null; mkdir -p ../dist/moonweb/timecapsule && cp -r _site/timecapsule/* ../dist/moonweb/timecapsule/",
    "build:moonweb": "npm run build && npm run build:timecapsule",
    "pdf:cv": "bash stefankoelle/pdf/build-pdf.sh",
-    "prebuild": "bash prebuild.sh"
+    "prebuild:cv": "bash prebuild.sh"
  },
  "devDependencies": {
    "@11ty/eleventy": "^3.1.6"
@@ -0,0 +1,447 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+    <meta charset="UTF-8">
+    <meta name="viewport" content="width=device-width, initial-scale=1.0">
+    <title>PHOBIA DemoGroup Archive - Nostalgic PC Intros from 1994</title>
+	<meta name="description" content="Explore the PHOBIA DemoGroup Archive, showcasing the 1994 PC intros, including the notable Phobia Welcome Intro. Relive the early days of PC intros with source code and more.">
+	<link rel="canonical" href="https://www.moonweb.org/phobia/" />
+    <style>
+		@font-face {
+			font-family: 'VT323';
+			font-style: normal;
+			font-weight: 400;
+			font-display: swap;
+			src: url('fonts/vt323-latin.woff2') format('woff2');
+		}
+		@font-face {
+			font-family: 'Press Start 2P';
+			font-style: normal;
+			font-weight: 400;
+			font-display: swap;
+			src: url('fonts/pressstart2p-latin.woff2') format('woff2');
+		}
+		body {
+            background-color: #1a1a1a;
+            margin: 0;
+            color: #f0f0f0;
+            font-family: 'VT323', monospace;
+            line-height: 1.6;
+            font-size: 20px;
+            overflow-x: hidden;
+            text-shadow: -1px -1px 0 #000, 1px -1px 0 #000, -1px 1px 0 #000, 1px 1px 0 #000;
+        }
+        .header {
+            display: flex;
+            align-items: center;
+            justify-content: center;
+            background-color: #000071;
+            padding: 10px 0;
+        }
+        .header img, .header canvas {
+            height: 120px;
+            margin-right: 0;
+        }
+        .header a {
+            margin: 0 15px;
+            color: #518DAF;
+            text-decoration: none;
+            font-size: 1.2em;
+        }
+        .header a:hover {
+            color: #f0f0f0;
+        }
+        .content {
+            display: flex;
+            flex-wrap: wrap;
+            padding: 20px 15px;
+            max-width: 1000px;
+            margin: 0 auto;
+        }
+        .program {
+            display: flex;
+            flex: 1 1 100%;
+            margin-bottom: 40px;
+        }
+        .program-image {
+            flex: 1 1 150px;
+            margin-right: 20px;
+        }
+        .program-image img {
+            width: 100%;
+            height: auto;
+            border-radius: 10px;
+        }
+        .video-thumb {
+            position: relative;
+            cursor: pointer;
+        }
+        .play-button {
+            position: absolute;
+            top: 50%;
+            left: 50%;
+            transform: translate(-50%, -50%);
+            width: 0;
+            height: 0;
+            border-left: 35px solid rgba(255,255,255,0.9);
+            border-top: 20px solid transparent;
+            border-bottom: 20px solid transparent;
+            filter: drop-shadow(0 0 6px rgba(0,0,0,0.6));
+            transition: opacity 0.2s;
+        }
+        .video-thumb:hover .play-button {
+            opacity: 0.7;
+        }
+        .program-description {
+            margin-top: 10px;
+            font-size: 1.1em;
+            line-height: 1.4;
+        }
+        .program-description p {
+            margin: 0.3em 0;
+        }
+        .program-info {
+            flex: 2 1 300px;
+        }
+        .program-info h2 {
+            font-size: 1em;
+            margin-top: 0;
+            margin-bottom: 10px;
+        }
+        .footer {
+            font-size: 0.9em;
+            text-align: center;
+            padding: 20px;
+            background-color: #333;
+            margin-top: 20px;
+        }
+        h1, h2 {
+            font-family: 'Press Start 2P', cursive;
+        }
+        @media (max-width: 600px) {
+			h1 {
+				font-size: 1.7em;
+			}
+			.program-info h2 {
+				font-size: 1.2em;
+				margin-bottom: 10px;
+			}
+			.header img, .header canvas {
+				width: 100%;
+				height: auto;
+			}
+            .content {
+                padding: 15px 10px;
+                flex-direction: column;
+                align-items: left;
+            }
+            .program {
+                flex-direction: column;
+                align-items: left;
+            }
+            .program-image {
+                margin-right: 0;
+                margin-bottom: 20px;
+            }
+            .program-info {
+                text-align: left;
+            }
+            .content table {
+                width: 100%;
+            }
+            .content table tr {
+                display: flex;
+                flex-direction: column;
+                margin-bottom: 0.8em;
+            }
+            .content table td {
+                padding-right: 0;
+            }
+            .content table td:first-child {
+                margin-bottom: 0.2em;
+            }
+        }
+		th, td {
+		  text-align:left;
+		  vertical-align: top;
+		  padding-right: 20px;
+		  overflow-wrap: break-word;
+		  }
+		a {
+			color:#00A6FF;
+		}
+		  
+		.lightbox {
+            display: none;
+            position: fixed;
+            top: 0;
+            left: 0;
+            width: 100%;
+            height: 100%;
+            background-color: rgba(0, 0, 0, 0.8);
+            justify-content: center;
+            align-items: center;
+        }
+        .lightbox-content {
+            position: relative;
+            width: 80%;
+            max-width: 800px;
+        }
+        .lightbox-content iframe {
+            width: 100%;
+            height: 450px;
+        }
+        .close {
+            position: absolute;
+            top: 10px;
+            right: 10px;
+            font-size: 30px;
+            color: #fff;
+            cursor: pointer;
+        }
+    </style>
+	<script>
+        function openLightbox() {
+            document.getElementById('lightbox').style.display = 'flex';
+            document.getElementById('video').src = 'https://www.youtube.com/embed/Cj3RgjVs5dk?autoplay=1';
+        }
+
+        function closeLightbox(event) {
+            if (event.target.id === 'lightbox' || event.target.className === 'close') {
+                document.getElementById('lightbox').style.display = 'none';
+                document.getElementById('video').src = '';
+            }
+        }
+    </script>
+</head>
+<body>
+    <div class="header">
+        <a href="index.html">
+            <canvas id="phobialogo" style="margin-right:20px;image-rendering:pixelated;"></canvas>
+            <img id="phobialogo-fallback" src="phobialogo.png" alt="PHOBIA" style="display:none;">
+        </a>
+    </div>
+    <div class="content">
+	
+		<div class="welcome">
+		<h1>PHOBIA DemoGroup Archive</h1>
+
+		<p>This site showcases the releases from my DemoGroup, PHOBIA. Although PHOBIA existed only briefly in 1994, it made a notable impact with its focus on PC intros. The highlight of our work was the Phobia Welcome Intro.</p>
+		<p>Feel free to explore and enjoy the nostalgia of the early days of PC intros.</p>
+		<p style="margin-bottom: 1.5em;">Best regards, Stefan Koelle</p>
+		</div>
+		
+        <div class="program">
+            <div class="program-image">
+                <div class="video-thumb" onclick="openLightbox()">
+                    <img src="welcomeintro.png" alt="Program 1 Image">
+                    <div class="play-button"></div>
+                </div>
+                <div class="program-description">
+                    <p><b>Phobia Welcome Intro</b></p>
+                    <p><a href="#" onclick="openLightbox()">YouTube Video of the Intro</a></p>
+                    <p><a href="https://github.com/skoelle/dos-phobia-welcome-intro" target="_blank">GitHub Source Code</a></p>
+                </div>
+            </div>
+            <div class="program-info">
+                <h2>Phobia Welcome Intro</h2>
+                <p>The Phobia Welcome Intro was programmed in 1994 using Turbo Pascal, with inline assembler for the graphics routines. This intro was inspired by an Amiga demo, though the specific name has been forgotten. All graphics and programming were done by Stefan Koelle on a 486 DX2-66 DOS PC.</p>
+        <p>This intro utilized an early version of the X-LIB unit, specifically the TextGraf.pas, which was also developed by Stefan Koelle. The source code for the intro is available on GitHub. The primary technique used to create the illusion of movement was color palette changes, rather than altering the pixels on the screen.</p>
+        <p>The music for the intro was borrowed from an old Amiga demo and played using a public Mod-Player. The font used in the intro was custom and compiled into the executable as an object, along with the music and graphics.</p>
+        
+        <h2>Facts</h2>
+        <table>
+            <tr>
+                <td><b>Language</b></td>
+                <td>Turbo Pascal with inline assembler</td>
+            </tr>
+            <tr>
+                <td><b>Year</b></td>
+                <td>1994</td>
+            </tr>
+            <tr>
+                <td><b>Developer</b></td>
+                <td>Stefan Koelle</td>
+            </tr>
+            <tr>
+                <td><b>Development Machine</b></td>
+                <td>486 DX2-66 DOS PC</td>
+            </tr>
+            <tr>
+                <td><b>Graphics Technique</b></td>
+                <td>Color palette changes</td>
+            </tr>
+            <tr>
+                <td><b>Music Source</b></td>
+                <td>Old Amiga demo</td>
+            </tr>
+            <tr>
+                <td><b>Music Player</b></td>
+                <td>Public Mod-Player</td>
+            </tr>
+            <tr>
+                <td><b>Custom Font</b></td>
+                <td>Compiled into the executable as an object</td>
+            </tr>
+            <tr>
+                <td><b>Graphics Library</b></td>
+                <td>Early version of X-LIB unit (TextGraf.pas)</td>
+            </tr>
+            <tr>
+                <td><b>Source Code</b></td>
+                <td>Available on GitHub<br><a href="https://github.com/skoelle/dos-phobia-welcome-intro" target="_blank">https://github.com/skoelle/dos-phobia-welcome-intro</a></td>
+            </tr>
+        </table>
+            </div>
+        </div>
+		<!--
+        <div class="program">
+            <div class="program-image">
+                <img src="program2.jpg" alt="Program 2 Image">
+                <div class="program-description">
+                    <p><b>Program 2</b></p>
+                    <p>Kurze Beschreibung des zweiten Programms.</p>
+                </div>
+            </div>
+            <div class="program-info">
+                <h2>Program 2 Information</h2>
+                <p>Hier steht der Infotext zum zweiten Programm. Dieser Text enthält detaillierte Informationen über das Programm, seine Funktionen und andere relevante Details.</p>
+            </div>
+        </div>
+        <div class="program">
+            <div class="program-image">
+                <img src="program3.jpg" alt="Program 3 Image">
+                <div class="program-description">
+                    <p><b>Program 3</b></p>
+                    <p>Kurze Beschreibung des dritten Programms.</p>
+                </div>
+            </div>
+            <div class="program-info">
+                <h2>Program 3 Information</h2>
+                <p>Hier steht der Infotext zum dritten Programm. Dieser Text enthält detaillierte Informationen über das Programm, seine Funktionen und andere relevante Details.</p>
+            </div>
+        </div>-->
+    </div>
+    <canvas id="copperbars" style="position:fixed;top:0;left:0;width:100%;height:100%;z-index:-1;pointer-events:none;"></canvas>
+    <div class="footer">
+        PHOBIA website - initially created November 1999 - code from 1994 - Stefan Koelle<br>
+        Part of <a href="/">moonweb.org</a> · <a href="/retro/">Retro Corner</a> · <a href="/impressum/">Legal Notice</a>
+    </div>
+	<div id="lightbox" class="lightbox" onclick="closeLightbox(event)">
+        <div class="lightbox-content">
+            <span class="close" onclick="closeLightbox()">&times;</span>
+            <iframe id="video" src="" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
+        </div>
+    </div>
+    <script>
+        (function() {
+            var canvas = document.getElementById('phobialogo');
+            var fallback = document.getElementById('phobialogo-fallback');
+            var ctx = canvas.getContext('2d');
+            var img = new Image();
+            img.crossOrigin = 'anonymous';
+            img.onload = function() {
+                canvas.width = img.width;
+                canvas.height = img.height;
+                fallback.style.display = 'none';
+                canvas.style.display = 'inline';
+                var origData = null;
+                try {
+                    ctx.drawImage(img, 0, 0);
+                    origData = ctx.getImageData(0, 0, canvas.width, canvas.height);
+                } catch(e) {
+                    fallback.style.display = 'inline';
+                    canvas.style.display = 'none';
+                    return;
+                }
+                var pixels = origData.data;
+                var blueMap = {};
+                for (var i = 0; i < pixels.length; i += 4) {
+                    var r = pixels[i], g = pixels[i+1], b = pixels[i+2];
+                    if (b > 30 && b > r * 1.3 && b > g * 1.2) {
+                        var key = r + ',' + g + ',' + b;
+                        if (!blueMap[key]) blueMap[key] = { r: r, g: g, b: b, count: 0 };
+                        blueMap[key].count++;
+                    }
+                }
+                var palette = [];
+                for (var k in blueMap) {
+                    if (blueMap[k].count >= 500) palette.push(blueMap[k]);
+                }
+                palette.sort(function(a, b) {
+                    var la = a.r * 0.299 + a.g * 0.587 + a.b * 0.114;
+                    var lb = b.r * 0.299 + b.g * 0.587 + b.b * 0.114;
+                    return la - lb;
+                });
+                var origColors = palette.map(function(c) { return { r: c.r, g: c.g, b: c.b }; });
+                var rotColors = origColors.slice();
+                var offset = 0;
+                function draw() {
+                    var out = ctx.createImageData(canvas.width, canvas.height);
+                    out.data.set(pixels);
+                    var d = out.data;
+                    for (var i = 0; i < palette.length; i++) {
+                        rotColors[i] = origColors[(i + offset) % palette.length];
+                    }
+                    var lookup = {};
+                    for (var i = 0; i < palette.length; i++) {
+                        var oc = origColors[i];
+                        var rc = rotColors[i];
+                        lookup[oc.r + ',' + oc.g + ',' + oc.b] = rc;
+                    }
+                    for (var i = 0; i < d.length; i += 4) {
+                        var key = d[i] + ',' + d[i+1] + ',' + d[i+2];
+                        if (lookup[key]) {
+                            d[i]   = lookup[key].r;
+                            d[i+1] = lookup[key].g;
+                            d[i+2] = lookup[key].b;
+                        }
+                    }
+                    ctx.putImageData(out, 0, 0);
+                    offset = (offset + 1) % palette.length;
+                    setTimeout(function() { requestAnimationFrame(draw); }, 120);
+                }
+                draw();
+            };
+            img.onerror = function() {
+                fallback.style.display = 'inline';
+                canvas.style.display = 'none';
+            };
+            img.src = 'phobialogo.png';
+        })();
+    </script>
+    <script>
+        (function() {
+            var canvas = document.getElementById('copperbars');
+            var ctx = canvas.getContext('2d');
+            var w, h;
+            function resize() { w = canvas.width = window.innerWidth; h = canvas.height = window.innerHeight; }
+            resize();
+            window.addEventListener('resize', resize);
+            var bars = [
+                { baseY: 0.45, amplitude: 0.18, speed: 0.7, r: 255, g: 199, b: 0, barH: 50 },
+                { baseY: 0.55, amplitude: 0.15, speed: 1.1, r: 239, g: 0, b: 0, barH: 50 },
+                { baseY: 0.52, amplitude: 0.20, speed: 0.9, r: 4, g: 203, b: 0, barH: 50 },
+            ];
+            function draw(t) {
+                ctx.clearRect(0, 0, w, h);
+                for (var i = 0; i < bars.length; i++) {
+                    var bar = bars[i];
+                    var y = h * bar.baseY + Math.sin(t * 0.001 * bar.speed) * h * bar.amplitude;
+                    var halfH = bar.barH / 2;
+                    for (var row = -halfH; row <= halfH; row++) {
+                        var rel = row / halfH;
+                        var alpha = 1 - rel * rel;
+                        var py = Math.round(y + row);
+                        if (py < 0 || py >= h) continue;
+                        ctx.fillStyle = 'rgba(' + bar.r + ',' + bar.g + ',' + bar.b + ',' + alpha.toFixed(3) + ')';
+                        ctx.fillRect(0, py, w, 1);
+                    }
+                }
+                requestAnimationFrame(draw);
+            }
+            requestAnimationFrame(draw);
+        })();
+    </script>
+</body>
+</html>
@@ -1,13 +0,0 @@
---
-title: "Page Not Found"
-section: "retro"
-tags: "retro"
-description: "The page you are looking for does not exist."
-layout: base.njk
-permalink: /retro/404.html
---
-<div class="error-page">
-  <h1>404</h1>
-  <p>The page you are looking for does not exist or has been moved.</p>
-  <a class="back-link" href="/">← Back to retro</a>
-</div>
@@ -0,0 +1,39 @@
+---
+title: "ACSI2STM: Atari ST Hard Drive Emulator"
+section: "retro"
+tags: "retro"
+description: "An ACSI to SD card hard drive emulator for the Atari ST based on an STM32 microcontroller, bought but not yet in use."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>ACSI2STM: Atari ST Hard Drive Emulator</h1>
+<div class="detail-content">
+
+<p>I bought an ACSI2STM adapter but haven't put it into a machine yet. It's a hard drive emulator for the Atari ST built around an inexpensive STM32 microcontroller and an SD card, an open-source project by retro16.</p>
+
+<h2>What it does</h2>
+<p>ACSI2STM connects to the ACSI (DB19) port at the back of the Atari ST and emulates a hard drive. It can work in three ways:</p>
+<ul>
+<li><strong>Mount SD cards</strong>, standard SD/SDHC/SDXC cards (FAT16/FAT32/ExFAT) appear on the Atari.</li>
+<li><strong>Expose raw SD cards</strong> as ACSI hard disks connected to the Atari.</li>
+<li><strong>Expose disk image files</strong> as hard disks connected to the Atari.</li>
+</ul>
+<p>It also provides an UltraSatan-compatible real-time clock if you add a simple 3V lithium battery such as a CR2032.</p>
+
+<h2>Hardware</h2>
+<p>The hardware is a custom PCB that can be ordered preassembled directly from JLCPCB. The board attaches straight to the DB19 port at the back of the ST and has three microSD card slots, with the firmware supporting up to five SD card readers. It's designed to be easy to build, extremely cheap, reliable and safe for the vintage machine. The project is mature and considered finished, with both software and hardware complete. It can even work on STs with broken DMA chips using the PIO firmware.</p>
+
+<h2>My Setup</h2>
+<p>I bought an ACSI2STM adapter, but it isn't in use anywhere yet, so it sits among my other uninstalled extensions. The <a href="/retro/ultrasatan/">UltraSatan</a> currently provides the ACSI hard-disk storage on the "Low" machine, so the ACSI2STM would be an alternative or a spare for another machine.</p>
+<p>I also collected all the parts to build a second unit from scratch, following the open-source <a href="https://github.com/retro16/acsi2stm/blob/stable/doc/hardware.md" target="_blank">hardware guide</a>, but never got around to soldering it together. If it eventually gets built, it could go into the <a href="/retro/mega-st-heirloom/">"Heirloom"</a> or the <a href="/retro/mega-st2/">Mega ST 2</a>.</p>
+
+<h2>Gallery</h2>
+<img src="acsi2stm.jpg" alt="The ACSI2STM adapter" width="640" height="640" loading="lazy">
+<p class="caption">The ACSI2STM adapter, not yet installed.</p>
+<p>The PPERA-HD-GAMES pack (1 GB iTOS version + 7 GB full pack, January 2026) was bought from Peter Putnik for 30 EUR.</p>
+
+<h2>Sources</h2>
+<ul>
+<li><a href="https://github.com/retro16/acsi2stm" target="_blank">ACSI2STM - GitHub (project page)</a></li>
+</ul>
+</div>
@@ -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>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>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>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>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 <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
-compatibility, 3.2 for features — applies equally to both setups.</p>
+And the perennial question of Kickstart ROM versions, 3.1 for
+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>
@@ -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>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>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>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). 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>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>
@@ -9,15 +9,43 @@ 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>What Is an Atari Mega ST?</h2>
+<p>The Atari Mega ST is a variant of Atari's 16/32-bit ST computer line, released in 1987 and aimed at business and desktop-publishing users. Compared to the standard 520 ST or 1040 ST, it comes in a low, flat desktop case with the floppy drive and motherboard separated from the keyboard, similar to a classic PC tower-and-keyboard setup. It shipped with a built-in Blitter chip for fast graphics operations, which the earliest 520/1040 ST models lacked, making it noticeably better suited for GEM-based desktop publishing software of the era.</p>
+<p>Mega STs were sold as Mega 1 (1 MB RAM), Mega 2 (2 MB RAM) and Mega 4 (4 MB RAM), all expandable, and were commonly bundled with monochrome high-resolution monitors for DTP work with software like Calamus or PageStream. The separated case design makes internal expansion and modification considerably easier than on an all-in-one 1040 ST, which is one reason the Mega ST remains a popular base for retro computing projects like the ones documented on this site.</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 "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 "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 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 <a href="/retro/mega-st-heirloom/">heirloom machine</a></strong>, kept as close to factory-original as possible, running the stock TOS 1.04 with a classic floppy drive and its own original Atari keyboard and mouse. 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 <a href="/retro/mega-st-low/">"Low" machine</a></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. It uses an original Atari keyboard and a <a href="/retro/mouster/">mouSTer</a> adapter with a USB mouse. This is the demo- and game-machine, optimized for fast disk-image swapping rather than serious productivity.</li>
+<li><strong>The <a href="/retro/mega-st-high/">"High" machine</a></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, an <a href="/retro/eiffel/">Eiffel interface</a> for a PS/2 keyboard and mouse, and a new <a href="/retro/stpsu/">STPSU</a> for clean, stable power round it out.</li>
+<li><strong>The spare <a href="/retro/mega-st2/">Mega ST 2</a></strong>, a reserve and test 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>Machine Inventory</h2>
+<p>All four machines were manufactured at Atari Taiwan Manufacturing Co. (indicated by the "A1" prefix in the serial numbers).</p>
+<table>
+<tr><th>Machine</th><th>Serial</th><th>Manufactured</th><th>Board</th></tr>
+<tr><td>Mega ST 2</td><td>A1 7B 4010182</td><td>11/1987</td><td>CA200019 / C100167-001 Rev.5.0</td></tr>
+<tr><td>Mega ST 4 "High"</td><td>A1 05 4009044</td><td>05/1990</td><td>—</td></tr>
+<tr><td>Mega ST 4 "Low"</td><td>A1 08 4011143</td><td>08/1990</td><td>—</td></tr>
+<tr><td>Mega ST 4 Heirloom</td><td>A1 08 4011015</td><td>08/1990</td><td>CA200019 / C100167-001 Rev.B</td></tr>
+<tr><td>Keyboard (Heirloom)</td><td>A1 07 4085985</td><td>07/1990</td><td>CA200043-004</td></tr>
+</table>
+
+<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>
+<li><strong>An <a href="/retro/acsi2stm/">ACSI2STM</a> adapter</strong>, bought but not yet in use anywhere, an alternative ACSI hard-disk emulator to the UltraSatan.</li>
+<li><strong>An <a href="/retro/atari-vga/">ST2VGA Enhanced</a> adapter</strong>, an active RGB-to-VGA adapter bought as a spare, not currently in use.</li>
+<li><strong>An original Atari STM-1 mouse converted with the <a href="/retro/laser-mouse/">laser board</a></strong>, upgraded but not currently in use.</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>
+
+<p>For the full story of how it all started, see the <a href="/retro/computer-timeline/">computer timeline</a>.</p>
 </div>
@@ -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>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>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>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>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>
 </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>
@@ -1,52 +1,47 @@
 ---
-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>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>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>
+<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>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>
+</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>Dialing the DarkForce! BBS</h2>
+<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>
+<p>Another BBS I tested is the <a href="http://18.221.141.17" target="_blank">Ignition BBS</a>, also accessible via telnet.</p>
+
+<h2>Why do it</h2>
+<p>The obvious question is "why bother?", the Atari ST was never designed
+for networking, and a modern device does all this far more easily. But
+that's not the point. There's real satisfaction in making old hardware do
+things it was never meant to do, and in experiencing the dial-up era's BBS
+culture on original hardware, over Wi-Fi instead of a phone line.</p>
+
+<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>
+
+<h2>Also worth noting</h2>
+<p>Jungsi tested a <a href="https://www.jungsi.de/wimodem232-oled-retro/" target="_blank">WiModem232 OLED</a> on his Atari ST and wrote about it on his blog. He used a different modem hardware than I did, but the idea is the same. He used "Connect" as his terminal software on the ST, but I used a different terminal program that could render ANSI graphics in ST Medium resolution, though I'd have to look up which one it was exactly.</p>
+<p>For better ANSI rendering, <strong>AnsiTerm</strong> is reportedly a better choice than Connect95 for BBS terminal use on the Atari ST.</p>
+
+<h2>Sources</h2>
+<ul>
+<li><a href="https://github.com/dhansel/WifiModem" target="_blank">dhansel's WifiModem - GitHub</a></li>
+<li><a href="https://www.jungsi.de/wimodem232-oled-retro/" target="_blank">WiModem232 OLED - Jungsi's Corner</a></li>
+<li><a href="https://www.telnetbbsguide.com/" target="_blank">Telnet BBS Guide</a></li>
+<li><a href="http://www.sfhqbbs.org/ataribbslist.php" target="_blank">Atari BBS List - sfhqbbs.org</a></li>
 </ul>

-<h2>Why connect a 40-year-old computer to the internet</h2>
-<p>The obvious question is "why bother?" — the Atari ST was never designed
-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>
-<p>Bulletin board systems from the dial-up era are still running today,
-maintained by enthusiasts who keep the old software alive. Connecting to
-one from an original Atari ST — via a Wi-Fi modem emulation — is a
-genuinely nostalgic experience. The ANSI art login screens, the message
-boards, the file sections, the door games — it's all exactly as it was
-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>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>
@@ -0,0 +1,45 @@
+---
+title: "Atari to VGA: Getting the ST Onto a Modern Monitor"
+section: "retro"
+tags: "retro"
+description: "How I connect the Atari Mega ST machines to modern VGA monitors, with three different RGB-to-VGA adapters."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>Atari to VGA: Getting the ST Onto a Modern Monitor</h1>
+<div class="detail-content">
+
+<p>To get the Atari ST onto a modern monitor, I use RGB-to-VGA adapters. I have three of them: a passive MCSWITCH adapter on the "Low" machine, a self-built adapter on the "High" machine, and a newer active ST2VGA Enhanced that isn't in use yet.</p>
+
+<h2>The MCSWITCH (Low machine)</h2>
+<p>The <a href="/retro/atari-mega-st-fleet/">Mega ST 4 "Low"</a> uses an MCSWITCH adapter (ATARI Monochrome &amp; Color VGA Adapter) by Olivier Gossuin, bought directly from him in 2021 for 23 EUR. It shows all three ST resolutions on a suitable VGA monitor, with a switch for mono and color. The version documented on <a href="http://www.albersdoerfer.de/erweiterungen/stvga.htm" target="_blank">albersdoerfer.de</a> also has an A/V connector and volume buttons, but mine is an older revision without the volume buttons and with a slightly different look. I can't find my exact version at Olivier's anymore, nor a newer one, so the adapter I have is a bit of a rare older revision.</p>
+
+<h2>The self-built adapter (High machine)</h2>
+<p>The <a href="/retro/atari-mega-st-fleet/">Mega ST 4 "High"</a> uses a self-built adapter. I had to build my own because every off-the-shelf adapter blocks the VGA slot of the <a href="/retro/et4000-experiment/">ET4000</a> card, since both connectors sit at the same spot on the machine. My solution is a short cable leading to a small box, which carries the VGA connector and the mono/color switch, so the ET4000's own VGA output stays accessible. I followed the guide at <a href="https://pest.atari.org/www.logicsays.com/atari/mono/docs/atari_vga.htm" target="_blank">pest.atari.org</a> to build the RGB-to-VGA adapter itself.</p>
+
+<h2>The ST2VGA Enhanced (not yet in use)</h2>
+<p>I also bought a new active <a href="https://sidecartridge.com/products/st2vga-atari-st/" target="_blank">ST2VGA Enhanced</a> from SidecarTridge, but it isn't in use yet. Unlike the passive adapters, the Enhanced adds an active amplifier and filter stage for early or noisy Atari machines, and carries its own +5V supply over micro-USB. It's designed for machines with weak video output, visible "jailbars", or picky LCD inputs that fail to lock to the signal. I want to try it on the "Low" machine to see whether it cleans up the output on the <a href="https://www.amazon.de/dp/B0957KH8X7/" target="_blank">Dell SE2722HX</a>, which currently shows some faint vertical stripes, and hopefully removes them.</p>
+
+<h2>A note on monitors</h2>
+<p>Passive RGB-to-VGA adapters output the Atari's native timings, so color modes (ST Low and ST Medium) need a monitor that can lock to a 15 kHz horizontal sync signal. See my <a href="/retro/atari-monitor-compatibility/">monitor compatibility</a> page for which modern panels actually work. Mono mode (ST High) works on any standard VGA display.</p>
+
+<h2>VGA switch setup</h2>
+<p>A 3-port VGA switch box routes the shared Dell monitor between the different machines:</p>
+<table>
+<tr><th>Port</th><th>VGA</th><th>USB</th></tr>
+<tr><td>1</td><td>Atari Mega 4 "High" (direct)</td><td>Raspberry Pi (not connected, otherwise no reboot)</td></tr>
+<tr><td>2</td><td>MiST</td><td>MiST</td></tr>
+<tr><td>3</td><td>MiSTer</td><td>MiSTer</td></tr>
+</table>
+
+<h2>Gallery</h2>
+<img src="stvga-low.jpg" alt="The MCSWITCH VGA adapter connected to the Atari" width="640" height="640" loading="lazy">
+<p class="caption">The MCSWITCH adapter on the Mega ST 4 "Low" machine.</p>
+
+<h2>Sources</h2>
+<ul>
+<li><a href="http://www.albersdoerfer.de/erweiterungen/stvga.htm" target="_blank">MCSWITCH (ATARI Monochrome &amp; Color VGA Adapter) - albersdoerfer.de</a></li>
+<li><a href="https://pest.atari.org/www.logicsays.com/atari/mono/docs/atari_vga.htm" target="_blank">Atari to VGA adapter build guide - pest.atari.org</a></li>
+<li><a href="https://sidecartridge.com/products/st2vga-atari-st/" target="_blank">ST2VGA Adapter - SidecarTridge (product page)</a></li>
+</ul>
+</div>
@@ -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>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>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>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>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>
 </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>
@@ -0,0 +1,43 @@
+---
+title: "My Computer Timeline: Atari ST, Amiga 500, DOS 486"
+section: "retro"
+tags: "retro"
+description: "The personal computing story behind the retro corner, from Atari ST and Amiga 500 to DOS 486 and beyond."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>My Computer Timeline: Atari ST, Amiga 500, DOS 486</h1>
+<div class="detail-content">
+
+<p>Every retro computing setup has a story. Here's mine, from the first time I sat in front of a screen to the machines I use today.</p>
+
+<h2>1983-1987: First contact</h2>
+<p>When I started primary school in 1983, friends already had computers. One showed me everything a C64 could do, except the Lego game he kept promising to show me. That never happened, but I was hooked on computers anyway. Around the same time my father brought home an Epson HX-20, a tiny portable with a small screen and a built-in microcassette drive. That's where I wrote my very first BASIC programs.</p>
+
+<h2>1987-1990: The Atari ST era</h2>
+<p>In secondary school a friend named Matthias had an Atari, and a couple of classmates in the class also got Ataris over time. For Christmas 1989 I got my own 1040STFM. A year later, Christmas 1990, came the Mega ST 4 with a MegaFile hard disk, the beginning of a much deeper relationship with the platform. Early programming started with Omikron BASIC, then quickly moved to GFA BASIC, which became the main tool for writing software on the ST. Some of the things I built during that time are preserved here: <a href="https://28k8.moonweb.org/bbs/atari/tropic-dreams/" target="_blank">Tropic Dreams</a>.</p>
+
+<h2>1990-1992: The Amiga detour</h2>
+<p>More and more classmates had Amigas, and I wanted one too. The Amiga arrived around April 1991, and while the Atari ST remained the programming machine, the Amiga became the creative hub: <a href="https://28k8.moonweb.org/bbs/amiga/mods/" target="_blank">ProTracker</a> for music, Deluxe Paint for graphics. I also released a few things under the Esprit label: <a href="https://28k8.moonweb.org/bbs/amiga/esprit/" target="_blank">ESPRIT releases</a>.</p>
+
+<h2>1992-1994: The PC arrives</h2>
+<p>Christmas 1993 brought a Vobis Highscreen 486 DX2-66 in its distinctive Colani tower case. The PC opened the door to DOS games, and in 1994 the real creative phase began: <a href="https://28k8.moonweb.org/bbs/pc/dosmenu/" target="_blank">DOSMENU</a>, the <a href="https://28k8.moonweb.org/bbs/pc/skyline/" target="_blank">SkyLine</a> demo group, and the first modem connecting to the outside world.</p>
+
+<h2>1994-2000: The Fido era</h2>
+<p>A modem in spring 1994 led to the <a href="https://28k8.moonweb.org/bbs/fido/nodelist/" target="_blank">FidoNet</a> world, and by late 1995 I was running my own <a href="https://28k8.moonweb.org/" target="_blank">BBS node</a>. Through the mid-90s I collected old and new machines enthusiastically, building up a collection that lasted until 2005 when most of it was sold off. By 2000, the FidoNet hobby had quietly faded.</p>
+
+<h2>2000-2009: The Linux server years</h2>
+<p>After the FidoNet era wound down, the focus shifted to Linux. A home network grew in Augsburg with a Smoothwall firewall, a Red Hat server, a Postfix/Apache mail and web server, and a multimedia workstation, all connected over 10 Mbit thin-Ethernet and a demand-dial RAS connection. A FreeBSD server ran Apache, Sendmail and Perl scripts alongside a Windows NT 4.0 file server. Microsoft certifications in Windows NT 4.0 and IIS 4.0 followed in 2000, and the work at IXOS SOFTWARE AG as a Web Engineer rounded out the professional side. The retro hobby took a back seat during this period, but the collection of old machines was still growing quietly in the background until 2005. The <a href="/timecapsule/location/">location</a>, <a href="/timecapsule/network/">network</a> and <a href="/timecapsule/projects/">projects</a> pages of the timecapsule have the full story.</p>
+
+<h2>2009-2017: The Apple years</h2>
+<p>Everything got reduced down to what I actually used daily. The old collection was gone, and the stack became an iMac, an iPhone, and an iPad, with no PCs at home for the first time. A Windows notebook from work was the only non-Apple machine in the house. The retro hobby was completely dormant during this period, while on the iMac .NET Mono tools kept things running.</p>
+
+<h2>2017-2020: The rebuild begins</h2>
+<p>In 2017 a Chromebook from Google joined the setup for everyday tasks, and a Synology NAS arrived. MQTT and the first ESP32 LED matrix projects ran directly on the NAS, while Arduino and ESP32 development started as a parallel hobby. The retro hobby was still dormant, but the groundwork for the homelab and smart home was being laid.</p>
+
+<h2>2020: The retro revival</h2>
+<p>In 2020 the retro computing hobby came back in full force. The Mega ST 4 fleet was rebuilt, the MiSTer and MIST FPGA boards were added, and this site was born to document it all. The machines from the 90s were given new roles instead of gathering dust: a workstation, a demo machine, a reference piece, and a spare.</p>
+<p>At the same time the <a href="/infra/">homelab infrastructure</a> grew: Proxmox servers, a Synology NAS, network planning, and a growing <a href="/smarthome/">smart home</a> setup with Home Assistant, MQTT and various ESP projects.</p>
+
+<p class="note">The pattern seems to be: every 10-15 years I rediscover the machines I grew up with and find new ways to use them.</p>
+</div>
@@ -2,37 +2,53 @@
 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>
+<img src="mister.jpg" alt="MiSTer menu on NEC MultiSync" loading="lazy">
+<p class="caption">MiSTer menu on the NEC MultiSync LCD, the same monitor that drives the real retro hardware.</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>
+<img src="mister_486_boot1_dosmenu.jpg" alt="DOSMENU Version 2.0 title screen" loading="lazy">
+<p class="caption">DOSMENU Version 2.0 title screen, the boot configuration utility.</p>
+<img src="mister_486_boot2_dosmenu.jpg" alt="DOSMENU configuration interface" loading="lazy">
+<p class="caption">The DOSMENU configuration interface showing system info, AUTOEXEC.BAT and CONFIG.SYS content, and saveable presets (F01-F10) for different boot configurations.</p>
+<img src="mister_486_boot3_dosmenu.jpg" alt="DOSMENU boot sequence" loading="lazy">
+<p class="caption">DOSMENU boot sequence showing the QEMM386 memory manager loading, registered to Stefan Koelle.</p>
+<img src="mister_486_boot4_dosmenu.jpg" alt="DOSMENU loading DOS Navigator" loading="lazy">
+<p class="caption">DOSMENU unregistered version with DOS Navigator 1.51 (by RIT Research Labs) loading at the C:\> prompt.</p>

-<h2>Why a 1:1 recreation</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>
+<h2>Why a rebuild from memory</h2>
+<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>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>System utilities</strong> — Norton Commander, PKZIP, the usual toolkit of the era, all configured 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>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>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>, 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, 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>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>
+<img src="mister_486_prg1_shell.jpg" alt="X-OS file manager" loading="lazy">
+<p class="caption">X-OS (eXtended Operating System), my Norton Commander clone for DOS, browsing the SkyLINE source directory.</p>
+<img src="mister_486_prg2_diskinfo.jpg" alt="DiskInfo V1.0" loading="lazy">
+<p class="caption">DiskInfo V1.0, a freeware disk space visualizer I wrote in 1993 for SkyLINE.</p>
+<img src="mister_486_prg3_tetris.jpg" alt="Tetris Competition" loading="lazy">
+<p class="caption">Tetris Competition, a two-player Tetris game I wrote for SkyLINE.</p>

 <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>
@@ -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>
@@ -0,0 +1,43 @@
+---
+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 have the <a href="https://www.eiffel-uno.com" target="_blank">Eiffel 3 for Mega ST, Mega STE and TT</a>, bought directly from Olivier Gossuin in 2021 for 18 EUR. As of 2026, the only place to still order one appears to be <a href="https://klydes-korner.site/en/product/ps2-to-atari-eiffel-adapter-with-joysticks/" target="_blank">Klyde's Korner</a>. 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, 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 is now used with the "Low" machine, which pairs it with a <a href="/retro/mouster/">mouSTer</a> and a USB mouse.</p>
+
+<h2>Gallery</h2>
+<img src="eiffel-ps2.jpg" alt="The Eiffel PS/2 adapter without its case" width="480" height="640" loading="lazy">
+<p class="caption">The Eiffel PS/2 adapter, shown here without its case.</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>
@@ -1,26 +1,86 @@
 ---
-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>Nova driver loading order</h2>
+<p>When using the ET4000 with Nova drivers, the loading order in the auto-start folder matters. The correct sequence is:</p>
+<ol>
+<li><code>Emulator.prg</code> (must be first)</li>
+<li><code>menu.prg</code> or <code>xmenu.prg</code></li>
+<li><code>sta_vdi.prg</code></li>
+</ol>
+
+<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>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>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>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>, 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>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>DVI incompatibility</strong>, the EIZO monitor has DVI-D (digital only), but all available DVI-to-VGA adapters only work with DVI-I (which includes analog lines). Since the EIZO lacks the analog pins, a DVI adapter cannot be used. The ET4000 has its own VGA output and connects directly to the monitor. The self-built <a href="/retro/atari-vga/">VGA adapter</a> on the Atari's native VGA output is only used as a fallback for diagnostics, when something goes wrong during boot before the ET4000 driver loads.</li>
 </ul>

-<h2>The Practical Fallback</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>
+<h2>How It Got Working</h2>
+<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>GemBench Results</h2>
+<p>How does the ET4000 actually perform on an 8 MHz 68000? GemBench 6.31 gives the answer. The reference system is an STE 68000 with stock Shifter, the "High" machine has the ET4000 running at 1024x768x256.</p>
+<img src="gembench.jpg" alt="GemBench 6.31 results on the ET4000" width="640" height="480" loading="lazy">
+<p class="caption">GemBench 6.31 running on the Mega ST 4 "High" with the ET4000.</p>
+<table>
+<tr><th>Test</th><th>Ratio</th><th>What it means</th></tr>
+<tr><td>VDI Text</td><td>269%</td><td>Nearly 3x faster, the ET4000 handles text rendering</td></tr>
+<tr><td>VDI Small Text</td><td>174%</td><td>Noticeably faster</td></tr>
+<tr><td>VDI Graphics</td><td>188%</td><td>Drawing and line work is quicker</td></tr>
+<tr><td>VDI Enquire</td><td>160%</td><td>Screen queries are faster</td></tr>
+<tr><td>VDI Text Effects</td><td>112%</td><td>Slightly faster</td></tr>
+<tr><td>GEM Dialog Box</td><td>97%</td><td>Barely affected</td></tr>
+<tr><td>Integer Division</td><td>99%</td><td>CPU-bound, unchanged</td></tr>
+<tr><td>RAM / ROM Access</td><td>99%</td><td>CPU-bound, unchanged</td></tr>
+<tr><td>Justified Text</td><td>63%</td><td>Slower, GEM still handles this via CPU</td></tr>
+<tr><td>GEM Window</td><td>69%</td><td>Slower, GEM window management adds overhead</td></tr>
+<tr><td>VDI Scroll</td><td>53%</td><td>Slower, scrolling is CPU-bound despite the card</td></tr>
+<tr><td>Blitting</td><td>32%</td><td>Much slower, no hardware BitBLT on the ET4000</td></tr>
+</table>
+<p>The overall average sits at 100%, which is misleading. The picture is split: anything the ET4000 can accelerate (text, graphics drawing) runs significantly faster, while GEM-level operations that still go through the CPU (window management, scrolling, blitting) are dragged down by the overhead of driving a higher resolution through the adapted ISA bus. Running at 1024x768 with 256 colors means roughly 3x the pixel count and roughly 25x the data volume compared to ST High (640x400 monochrome), since the ST's fixed 32 KB screen buffer holds far less data per frame than a 256-color 1024x768 framebuffer. The Nova driver without NVDI squeezes the maximum out of this particular card and driver combination. In day-to-day use, the VDI gains are what you see and feel: text is crisp, menus pop up quickly, and drawing applications are noticeably more responsive.</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" loading="lazy">
+<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" loading="lazy">
+<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" loading="lazy">
+<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" loading="lazy">
+<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" loading="lazy">
+<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>
@@ -0,0 +1,50 @@
+---
+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>Gallery</h2>
+<img src="gotek-switch-2.jpg" alt="The relocated TOS switcher at the front of the Gotek case" width="640" height="640" loading="lazy">
+<p class="caption">The relocated TOS switcher at the front of the printed Gotek case, a clear view of how it sits in the floppy bay.</p>
+<img src="gotek-back.jpg" alt="Gotek floppy emulator rear view" width="640" height="480" loading="lazy">
+<p class="caption">The Gotek in the 3D-printed case, with the relocated TOS switcher visible at the front.</p>
+<img src="gotek-switch.jpg" alt="Gotek with the relocated TOS switcher in the printed case" width="640" height="480" loading="lazy">
+<p class="caption">The Gotek rear view.</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>
@@ -1,61 +1,134 @@
 ---
-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"
    cards:
      - 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: "/atari-mega-st-fleet/"
-      - title: "⚡ ET4000 Experiment"
-        summary: "Why bolting a graphics card onto a Mega ST overloads a 1980s power supply, and what actually solved the resolution problem."
-        href: "/et4000-experiment/"
+        href: "/retro/atari-mega-st-fleet/"
+      - title: "🎮 Mega ST 4 Low"
+        summary: "The bargain-bin Mega ST 4 rebuilt as a LowRes demo and games machine with Cloudy/Storm ST, Gotek, UltraSatan and more."
+        href: "/retro/mega-st-low/"
+      - title: "🖥️ Mega ST 4 High"
+        summary: "The high-end workstation with MonSTerBoard, ET4000, NetUSBee, Eiffel and STPSU, running Geneva."
+        href: "/retro/mega-st-high/"
+      - title: "🔧 Mega ST 2"
+        summary: "The spare and test machine for the rest of the fleet."
+        href: "/retro/mega-st2/"
+      - title: "🏛️ Heirloom Mega ST 4"
+        summary: "My father's original Mega ST 4, kept factory-original as a baseline reference."
+        href: "/retro/mega-st-heirloom/"
+      - title: "🌀 Storm ST & Cloudy ST"
+        summary: "Adding 8 MB Alt-RAM and flashable TOS to the Mega ST, switching between EmuTOS and iTOS 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: "📖 TOS Explained"
+        summary: "A short explanation of TOS, the operating system behind every Atari ST, and the versions that matter today."
+        href: "/retro/tos/"
+      - 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: "💽 ACSI2STM"
+        summary: "An open-source ACSI to SD card hard drive emulator for the Atari ST. Bought, not yet in use."
+        href: "/retro/acsi2stm/"
+      - 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: "⌨️ 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/"
+      - title: "🖱️ mouSTer"
+        summary: "Connecting a modern USB mouse to the Mega ST 4 'Low' with the mouSTer DB-9 adapter."
+        href: "/retro/mouster/"
+      - title: "🖱️ Laser Mouse"
+        summary: "Converting an original Atari STM-1 mouse to a modern laser sensor with the Atari mouse laser board."
+        href: "/retro/laser-mouse/"
+      - title: "📺 Atari to VGA"
+        summary: "Getting the Mega ST onto modern VGA monitors with three RGB-to-VGA adapters: MCSWITCH, a self-build and an ST2VGA Enhanced."
+        href: "/retro/atari-vga/"
      - title: "📺 Monitor Compatibility"
        summary: "The 15kHz problem explained, and which modern monitor panels actually cooperate with Atari colour modes."
-        href: "/atari-monitor-compatibility/"
-      - title: "🔌 Networking & BBS"
-        summary: "Getting an Atari ST online via STinG and Wi-Fi modem hardware, and dialing into classic bulletin board systems."
-        href: "/atari-networking-bbs/"
+        href: "/retro/atari-monitor-compatibility/"
+      - title: "⚡ ET4000 in the Mega ST"
+        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: "🔌 STPSU"
+        summary: "Replacing the aging Mega ST 4 'High' power supply with a modern STPSU for clean, stable power, especially for the ET4000."
+        href: "/retro/stpsu/"
+      - 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: "🔌 Wi-Fi Modem & BBS"
+        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: "🧩 MiSTery Core on MIST"
+        summary: "Cloning the Low's SD card to the MIST FPGA for direct SD access, five configurations and a backup plan if the real Mega ST breaks."
+        href: "/retro/mistery-core/"
  - heading: "Amiga Corner"
    cards:
-      - title: "💾 AmigaOS on Modern Platforms"
-        summary: "Running AmigaOS 3.2.3 on MiSTer FPGA versus Amiberry on a Raspberry Pi, and the HDF pitfalls to avoid."
-        href: "/amiga-modern-platforms/"
+      - title: "⚔️ Vampire, A600GS or MiSTer"
+        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: "/pimiga-journey/"
-      - title: "⚔️ Vampire, A600GS or MiSTer"
-        summary: "Why comparing modern Amiga hardware by benchmark numbers alone is actively misleading."
-        href: "/amiga-hardware-landscape/"
+        href: "/retro/pimiga-journey/"
      - title: "📦 The A1200"
        summary: "What's confirmed so far about Retro Games Ltd.'s upcoming Amiga 1200 console, ahead of its 2026 launch."
-        href: "/the-a1200/"
+        href: "/retro/the-a1200/"
  - heading: "FPGA & Emulation"
    cards:
      - title: "🧩 MiST and MiSTer"
        summary: "Two FPGA boards with two very different personalities, and why the newer one doesn't win every category."
-        href: "/mist-mister-fpga/"
+        href: "/retro/mist-mister-fpga/"
      - title: "🛋️ Batocera in the Living Room"
        summary: "The couch-friendly, software-emulation counterpart to the FPGA rigs, covering everything from Atari ST to arcade."
-        href: "/batocera-living-room/"
-      - title: "🕹️ Mini Arcades & Handhelds"
-        summary: "A buyer's guide to compact retro gaming devices, and how to spot a bootleg clone before you buy one."
-        href: "/mini-arcade-handheld-roundup/"
+        href: "/retro/batocera-living-room/"
+      - title: "🕹️ Handheld Emulation Devices"
+        summary: "ODROID-GO, PocketGo and RG35XX, three handhelds for retro gaming on the move."
+        href: "/retro/mini-arcade-handheld-roundup/"
  - 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."
-        href: "/dos-486-tower/"
+        summary: "Rebuilding a DOS era from memory on MiSTer FPGA, recreating the environment the way it felt back then."
+        href: "/retro/dos-486-tower/"
+      - title: "👾 PHOBIA DemoGroup Archive"
+        summary: "The PHOBIA DemoGroup Archive, showcasing 1994 PC intros including the Phobia Welcome Intro, written in Turbo Pascal."
+        href: "/phobia/"
+      - title: "🎵 TranceMission Archive"
+        summary: "TranceMission demos and intros from 1992-1995, programmed in Turbo Pascal with assembler on DOS PCs."
+        href: "/tcm/"
+      - title: "🕹️ SkyLINE Productions"
+        summary: "DOS games, demos and tools from the SkyLINE era, 1993-1995."
+        href: "https://28k8.moonweb.org/bbs/pc/skyline/"
  - heading: "Overview"
    cards:
      - title: "🏠 The Retro Corner Today"
        summary: "A room-by-room snapshot of every retro system currently active across the home."
-        href: "/retro-corner-snapshot/"
+        href: "/retro/retro-corner-snapshot/"
+      - title: "📅 Computer Timeline"
+        summary: "From Atari ST and Amiga 500 to DOS 486, the personal computing story behind the retro corner."
+        href: "/retro/computer-timeline/"
+      - title: "💾 28k8 BBS Archive"
+        summary: "tHE tEMPLE BBS Mailbox and 90s scene releases archive from the 28k8 era."
+        href: "https://28k8.moonweb.org"

 ---
+<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" %}
@@ -0,0 +1,39 @@
+---
+title: "Laser Mouse: Upgrading an Original Atari STM-1 Mouse"
+section: "retro"
+tags: "retro"
+description: "Converting an original Atari STM-1 mouse to a modern laser sensor with the Atari mouse laser board."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>Laser Mouse: Upgrading an Original Atari STM-1 Mouse</h1>
+<div class="detail-content">
+
+<p>I converted an original Atari STM-1 mouse into a laser mouse using the Atari mouse laser board. It keeps the original Atari mouse shell and feel, but replaces the old mechanical/optical innards with a modern laser sensor, so the mouse actually tracks well again. It isn't currently in use on any machine, so it sits among my unused extensions for now.</p>
+
+<h2>The Atari mouse laser board</h2>
+<p>The board is a drop-in upgrade for an original Atari mouse. Instead of the worn-out original mechanism, it uses a laser sensor for smooth, accurate tracking while keeping the classic Atari mouse look. The board is sold by Tim (Lavago) and is available by email order.</p>
+
+<h2>Current version</h2>
+<p>There's a revised version of the board with several updates:</p>
+<ul>
+<li>Green PCB colour.</li>
+<li>A status LED on the board, which can be disabled with a jumper.</li>
+<li>Optimised firmware for even smoother movement.</li>
+<li>New optimised button adapters.</li>
+<li>Improved quality of the covers.</li>
+</ul>
+<p>It's available for Atari forum users by email order for 42 Euro including a 1040ST keychain (not 3D printed). When ordering by email, mention the keyword "Forum" and your address. Email: <a href="mailto:Info@Lavago.de">Info@Lavago.de</a>.</p>
+
+<h2>Why do it</h2>
+<p>The original STM-1 mouse is a classic, but the original sensors are getting tired after decades, and the feel isn't great compared to modern pointing devices. The laser board keeps the authentic Atari mouse shell while making it genuinely usable again, which is a nice middle ground between the original mouse and something like the <a href="/retro/mouster/">mouSTer</a> with a modern USB mouse.</p>
+
+<h2>Gallery</h2>
+<img src="lasermouse.jpg" alt="The converted Atari STM-1 laser mouse" width="640" height="853" loading="lazy">
+<p class="caption">The original Atari STM-1 mouse converted to a laser sensor.</p>
+
+<h2>Sources</h2>
+<ul>
+<li>Atari mouse laser board - available by email from Tim (Lavago): <a href="mailto:Info@Lavago.de">Info@Lavago.de</a></li>
+</ul>
+</div>
@@ -0,0 +1,35 @@
+---
+title: "The Heirloom Mega ST 4: A Reference Machine"
+section: "retro"
+tags: "retro"
+description: "My father's original Mega ST 4, deliberately kept in factory-original condition as a baseline reference."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>The Heirloom Mega ST 4: A Reference Machine</h1>
+<div class="detail-content">
+
+<p>This is my father's original Mega ST 4, deliberately kept in its historical, unmodified condition. It's the one machine in the fleet that stays true to how it left the factory.</p>
+
+<h2>Current State</h2>
+<ul>
+<li>Original TOS 1.04 reinstalled (onboard ROM, no external TOS switcher).</li>
+<li>No modern expansions active, no MonSTerBoard, no Cloudy/Storm.</li>
+<li>A classic floppy drive instead of a Gotek or emulator.</li>
+<li>Its own original Atari keyboard and mouse.</li>
+</ul>
+
+<h2>Details</h2>
+<p>Serial: A1 08 4011015 · Manufactured August 1990 · Board: CA200019 / C100167-001 Rev.B</p>
+<p>Original keyboard: A1 07 4085985 · Manufactured July 1990 · Board: CA200043-004, fully disassembled and cleaned on 6 March 2022.</p>
+
+<h2>Role in the Fleet</h2>
+<p>This machine serves as a nostalgia and comparison reference. When problems occur on one of the modified Megas, I can test against this unchanged original state to distinguish bus, flash, or configuration errors from genuine hardware faults. It can also be used as a test platform for uncritical experiments, but stays as close to original as possible for nostalgic reasons.</p>
+
+<h2>History</h2>
+<p>The machine spent many years at my parents' house and was fully rebuilt and brought back into operation by me after I got seriously back into retro computing in 2020.</p>
+
+<h2>Plans</h2>
+<p>The plan is to use this machine again the way it originally was: hooked up to the old SM124 black-and-white monitor, and with the two old MegaFile hard disks (a MegaFile 60 and a MegaFile 30) connected, keeping the whole setup period-correct. Both are still stored in the basement at my parents' place for now.</p>
+
+</div>
@@ -0,0 +1,60 @@
+---
+title: "Mega ST 4 High: The Workstation"
+section: "retro"
+tags: "retro"
+description: "The high-end Mega ST 4 workstation with MonSTerBoard, ET4000, NetUSBee, Eiffel interface, a modern STPSU and patched TOS 2.06, running Geneva."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>Mega ST 4 High: The Workstation</h1>
+<div class="detail-content">
+
+<p>Received for free in 2026, this Mega ST 4 was fully rebuilt and is today my primary workstation. It's the most capable machine in the fleet, running Geneva as a real multitasking environment.</p>
+
+<h2>Details</h2>
+<p>Serial: A1 05 4009044 · Manufactured May 1990</p>
+
+<h2>Work Performed</h2>
+<ul>
+<li><strong>Blitter patch</strong>, removed an existing patch and carefully bridged the severed trace with wire, verifying it with a continuity test. The installed blitter (marked S9012 / MM9092V, a National variant from week 12/1990) belongs to an unproblematic batch where the classic Mega ST blitter patch is generally no longer needed.</li>
+<li><strong>CPU socket</strong>, soldered in a 68000 socket and checked all connections to the board with a multimeter.</li>
+<li><strong>TOS</strong>, removed the onboard TOS from its sockets to avoid conflicts with the external flash TOS on the MonSTerBoard.</li>
+<li><strong>Power supply</strong>, replaced with a modern <a href="/retro/stpsu/">STPSU</a> for clean, stable power, which matters especially for the ET4000.</li>
+<li><strong>Floppy drive</strong>, the original drive was defective and got swapped with a working unit.</li>
+</ul>
+
+<h2>MonSTerBoard</h2>
+<p>The <a href="/retro/monsterboard/">MonSTerBoard</a> is plugged onto the 68000 socket, with jumpers set so TOS 2.06 is used from its flash. The TOS 2.06 is patched to skip the memory check, which noticeably speeds up the boot process. KAOS TOS is also installed on the flash, though currently I always run Geneva with <strong>NeoDesk 4.06</strong> under TOS 2.06. No TOS switcher is wired up yet, so the machine is fixed to TOS 2.06 for now. The MonSTerBoard provides up to 8 MB of AltRAM (TT-compatible range, activated via <code>m_altram.prg</code>), an IDE interface for CF/IDE storage, and a flash ROM holding multiple TOS images. I boot from a 1 GB CompactFlash card over IDE, which is noticeably faster than an ACSI drive.</p>
+
+<h2>Peripherals in Use</h2>
+<ul>
+<li><strong><a href="/retro/et4000-experiment/">ET4000 graphics card</a></strong> in the MegaBus, providing higher resolutions and better display quality with Geneva/NVDI, driving a dedicated monitor.</li>
+<li><strong><a href="/retro/netusb/">NetUSBee</a></strong> on the ROM port, giving real internet via STinG and a USB port for FAT16 data exchange with Windows.</li>
+<li><strong><a href="/retro/eiffel/">Eiffel interface</a></strong> for a PS/2 keyboard and mouse, a much better typing feel than the original hardware.</li>
+<li><strong>Self-built <a href="/retro/atari-vga/">VGA adapter</a></strong>, a short cable to a small box with the VGA connector and mono/color switch, since a standard adapter would block the ET4000's VGA output.</li>
+</ul>
+
+<h2>Role</h2>
+<p>Workstation machine with multitasking (<a href="https://www.atari-wiki.com/index.php/NeoDesk">NeoDesk</a> 4.06 under Geneva), AltRAM, IDE/CF boot, USB and network connectivity, and high-resolution display. My primary system for programming and productive work.</p>
+
+<h2>Gallery</h2>
+<img src="high-1.jpg" alt="The Mega ST 4 High machine" width="640" height="640" loading="lazy">
+<p class="caption">The NeoDesk desktop showing 4 MB ST RAM and 8 MB AltRAM from the MonSTerBoard.</p>
+<img src="high-2.jpg" alt="Mega ST 4 High internal view" width="640" height="640" loading="lazy">
+<p class="caption">The workstation running GEMBench, with the original Atari keyboard and mouse.</p>
+<img src="high-3.jpg" alt="Mega ST 4 High detail" width="640" height="853" loading="lazy">
+<p class="caption">GEMBench 6.31 results comparing the ST reference to the High machine at 1024x768 with 256 colors.</p>
+<img src="high-4.jpg" alt="Mega ST 4 High expansion" width="640" height="480" loading="lazy">
+<p class="caption">The complete setup in daylight, showing the GEM desktop on the EIZO FlexScan L365.</p>
+<img src="high-5.jpg" alt="Mega ST 4 High close-up" width="640" height="640" loading="lazy">
+<p class="caption">Geneva multitasking: qed, Sound Player, World Clock, and Memory usage running side by side.</p>
+<img src="high-6.jpg" alt="Mega ST 4 High running" width="640" height="480" loading="lazy">
+<p class="caption">A side view of the setup, showing the Cherry PS/2 keyboard, Logitech mouse via the Eiffel adapter, and the floppy drive.</p>
+<img src="high-7.jpg" alt="Mega ST 4 High setup" width="640" height="480" loading="lazy">
+<p class="caption">Geneva running Vision 3.5a and qed in parallel, with green ambient light behind the EIZO.</p>
+<img src="high-8.jpg" alt="Mega ST 4 High board" width="640" height="640" loading="lazy">
+<p class="caption">The NeoDesk Applications menu with Geneva Manager, JAnE, and Vision 3.5a, alongside the system spec file.</p>
+<img src="high-9.jpg" alt="Mega ST 4 High final" width="640" height="480" loading="lazy">
+<p class="caption">The full workstation at night, driven by the MonSTerBoard, ET4000, and TOS 2.06.</p>
+
+</div>
@@ -0,0 +1,42 @@
+---
+title: "Mega ST 4 Low: Demo and Games Machine"
+section: "retro"
+tags: "retro"
+description: "The bargain-bin Mega ST 4 rebuilt as a LowRes demo and games machine, with Cloudy/Storm ST, Gotek, UltraSatan, SidecarTridge and a Wi-Fi modem."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>Mega ST 4 Low: Demo and Games Machine</h1>
+<div class="detail-content">
+
+<p>Bought via eBay as a bargain, this Mega ST 4 is today my LowRes demo and gaming machine. It's the most heavily expanded of the fleet, but tuned for fast disk-image swapping rather than productivity.</p>
+
+<h2>Details</h2>
+<p>Serial: A1 08 4011143 · Manufactured August 1990</p>
+
+<h2>History and Repair</h2>
+<p>I had originally cut out the TOS ROMs to experiment with external solutions, and afterwards it was unclear whether the board had been damaged in the process. Moving the <a href="/retro/storm-cloudy/">Cloudy/Storm ST combo</a> to this machine via the MegaBus connector brought it back to stable operation. The actual problem turned out to be a poorly and incompletely soldered CPU socket.</p>
+
+<h2>Hardware Configuration</h2>
+<ul>
+<li><strong>CPU</strong>, 68000 with socket, plus the <a href="/retro/storm-cloudy/">Cloudy/Storm ST combo</a> via the MegaBus adapter.</li>
+<li><strong>TOS/Flash</strong>, Cloudy as the TOS switcher/flash solution with EmuTOS and PP's improved iTOS 1.04.</li>
+<li><strong>RAM</strong>, 4 MB onboard ST-RAM plus 8 MB AltRAM via the Storm ST.</li>
+<li><strong>Mass storage</strong>, a <a href="/retro/gotek/">Gotek floppy emulator</a> in a 3D-printed case and an <a href="/retro/ultrasatan/">UltraSatan</a> ACSI-SD emulator.</li>
+<li><strong>Peripherals</strong>, a <a href="/retro/sidecartridge/">SidecarTridge Multi-device</a> on the ROM port, a <a href="/retro/atari-networking-bbs/">Wi-Fi modem</a> for dialing into BBSs, an original Atari keyboard with a <a href="/retro/mouster/">mouSTer</a> and USB mouse, and an <a href="/retro/atari-vga/">MCSWITCH</a> adapter for VGA output.</li>
+</ul>
+
+<h2>Booting</h2>
+<p>Switching between High Res and Low Res is done at the VGA adapter, not in software. The iTOS 1.04 boot options select which drive to boot from:</p>
+<ul>
+<li><strong>High Res</strong>, switch to EmuTOS on the Cloudy, then set the VGA adapter to Mono. Let it boot through.</li>
+<li><strong>Low Res</strong>, switch to iTOS 1.04i on the Cloudy, then set the VGA adapter to Color. At the boot prompt:</li>
+<li><strong>1 + Space</strong>, boot from <code>C:\BT\1</code>, opens D: GAMES</li>
+<li><strong>2 + Space</strong>, boot from <code>C:\BT\2</code>, opens E: DEMOS</li>
+<li><strong>3 + Space</strong>, boot from <code>C:\BT\3</code>, opens F: Med-Res</li>
+</ul>
+
+<h2>Role</h2>
+<p>Focused on LowRes demos and games, with convenient image handling via the Gotek and SidecarTridge. The desktop environment is an original <strong>NeoDesk 3.0</strong> installation from the 1990s, just as it was back then. No need for complex productivity software or precise keyboard layouts here. The entire SD card has been cloned to the <a href="/retro/mistery-core/">MiSTery Core on the MIST</a> as a backup and for easy data transfer between the real machine and the FPGA.</p>
+
+</div>
@@ -0,0 +1,35 @@
+---
+title: "The Mega ST 2: Spare and Test Machine"
+section: "retro"
+tags: "retro"
+description: "The Mega ST 2 that serves as an inactive backup machine for the rest of the Atari fleet."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>The Mega ST 2: Spare and Test Machine</h1>
+<div class="detail-content">
+
+<p>The Mega ST 2 was given to me a while ago. Its role is purely as a backup: it sits inactive and is only meant to be brought back to life if the "High" or "Low" machine ever fails, not as an actively used machine.</p>
+
+<h2>Current State</h2>
+<p>It runs on original TOS with the internal RAM configuration, without the separate 4 MB expansion, which was removed for testing purposes and now sits set aside.</p>
+
+<h2>Details</h2>
+<p>Serial: A1 7B 4010182 · Manufactured November 1987 · Board: CA200019 / C100167-001 Rev.5.0</p>
+
+<h2>History</h2>
+<p>Everything in this machine was moved over to the <a href="/retro/mega-st-high/">Mega ST 4 "High"</a> that I was given, including its original power supply. It's not really a parts donor though, it's simply the spare machine now that the new Mega 4 carries the main setup. Back then it had an intermittent fault: after being on for a long time it would eventually show a white screen on boot. I first suspected the 4 MB expansion and removed it, but the fault persisted. Only after reverting it to the old TOS and a fully original state did it run stably again.</p>
+
+<h2>Ideas for This Machine</h2>
+<p>A few possible directions for the Mega ST 2, none of them decided yet:</p>
+<ul>
+<li>Reinstalling the 4 MB expansion, which was only removed for testing and is currently sitting set aside.</li>
+<li>An external <a href="/retro/gotek/">Gotek floppy emulator</a>, since an external unit would suit this machine well.</li>
+<li>An <a href="/retro/eiffel-pico/">Eiffel Pico USB</a> adapter for a USB keyboard and mouse.</li>
+<li>The <a href="/retro/acsi2stm/">ACSI2STM</a> as an ACSI hard disk option.</li>
+<li>A stereo sound mod.</li>
+<li>Playing MIDI Maze against the <a href="/retro/mega-st-low/">Mega ST 4 "Low"</a>: connect the two machines over MIDI, put the Mega ST 2 on the old MCSWITCH VGA adapter and the NEC monitor, and play together.</li>
+<li>The old Revision 0 <a href="/retro/sidecartridge/">SidecarTridge</a> could move here once the new Revision 3 is installed in the "Low" machine.</li>
+</ul>
+
+</div>
@@ -1,23 +1,56 @@
 ---
-title: "Mini Arcades and Handhelds: Sorting the Real Deal from the Bootlegs"
+title: "Handheld Emulation Devices: ODROID-GO, PocketGo and RG35XX"
 section: "retro"
 tags: "retro"
-description: "A buyer's guide to compact retro gaming devices, and why the cheapest option is almost never the right one."
+description: "Three handheld emulation devices for retro gaming on the move, from an ESP32-based ODROID-GO to a pocketable PocketGo and a powerful RG35XX."
 layout: base.njk
 parent: "/retro/"
 ---
-<h1>Mini Arcades and Handhelds: Sorting the Real Deal from the Bootlegs</h1>
+<h1>Handheld Emulation Devices: ODROID-GO, PocketGo and RG35XX</h1>
 <div class="detail-content">

-<p>The market for tiny plug-and-play arcade cabinets is full of traps. Some devices ship with genuinely licensed classics; others are dressed-up bootleg NES clones with unfamiliar Chinese ROM hacks pretending to be arcade games.</p>
+<p>For retro gaming away from a screen, I use three handheld emulation devices. Each one covers a different sweet spot in the trade-off between size, power and convenience. The key difference is what systems each one can actually emulate well, and how much effort it takes to get there.</p>

-<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>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>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>
+<h2>ODROID-GO</h2>
+<p>The ODROID-GO by Hardkernel is a DIY handheld built around an ESP32 microcontroller. It has a 2.4-inch 320x240 TFT display, a speaker, D-pad, face buttons, shoulder buttons, a Micro SD card slot, and a built-in rechargeable battery. It runs the stock firmware, which loads games from the SD card. The ESP32 is a dual-core chip running at 240 MHz with 4 MB of PSRAM, which is enough for 8-bit systems but starts to struggle with anything heavier.</p>
+<p><strong>What it plays well:</strong> NES, Game Boy, Game Boy Color, Sega Master System, Sega Game Gear.</p>
+<p><strong>What it does not play well:</strong> Anything beyond 8-bit is not on there, and would not run well anyway.</p>
+<p><strong>Game packs:</strong> Full game packs for all supported systems are on the SD card. No need to pick and choose.</p>
+<p><strong>Why use it:</strong> The killer feature is instant-on. The ESP32 boots in literally no time, you switch it on and the game is right there. A stopped game can be picked up again straight away. No other device in the collection comes close to this. It is the smallest and cheapest of the three, and for pure 8-bit gaming it is surprisingly capable. It is the grab-and-go option when you just want to play some NES or Game Boy games on the couch.</p>
+<img src="odroid-go.jpg" alt="ODROID-GO system selection screen" width="640" height="480" loading="lazy">
+<p class="caption">The ODROID-GO showing the Retro-Go system selection screen.</p>

-<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>
+<h2>PocketGo</h2>
+<p>The original PocketGo by BittBoy is a handheld in a Game-Boy-Advance-style landscape form factor with a 2.4-inch IPS display at 320x240. It runs on an Allwinner F1C100S chip at 533 to 798 MHz with 32 MB of RAM. The community CFW 1.3 firmware (Miyoo CFW) replaces the stock software with GMenu2X as the frontend, adds support for more emulators, a screen tearing fix, theme customisation and better overall performance. The stock firmware works but is rough around the edges, with an inconsistent button mapping across emulators and a less polished menu. It has D-pad, four face buttons, shoulder buttons, and runs off a 1000 mAh battery.</p>
+<p><strong>What it plays well:</strong> Game Boy, Game Boy Color, Game Boy Advance, NES, Sega Genesis, Sega Master System. The GBA emulation is the real draw here, something the ODROID-GO cannot do.</p>
+<p><strong>What it does not play well:</strong> SNES is playable but not perfect, with occasional slowdowns. PlayStation, CPS1/CPS2/CPS3, Jaguar, Sega CD and Sega 32X are not possible.</p>
+<p><strong>Game packs:</strong> Full game packs for all supported systems are on the SD card.</p>
+<p><strong>Why use it:</strong> It is still pocketable, the IPS screen looks great, and it fills the gap between the ODROID-GO and the RG35XX. If you want Game Boy Advance on the go without carrying something bigger, this is the one. The CFW 1.3 firmware makes a real difference over the stock software.</p>
+<img src="PocketGo1.jpg" alt="PocketGo boot screen" width="640" height="480" loading="lazy">
+<p class="caption">The PocketGo booting into Miyoo CFW 1.3.</p>
+<img src="PocketGo2.jpg" alt="PocketGo system selection" width="640" height="480" loading="lazy">
+<p class="caption">The system selection screen on the PocketGo.</p>
+
+<h2>RG35XX</h2>
+<p>The RG35XX by Anbernic is the serious handheld of the three. It has a 3.5-inch IPS display at 640x480, an Allwinner H313 quad-core ARM Cortex-A53 chip, and significantly more power than the other two. It runs GarlicOS, a custom firmware by Black Seraph built on RetroArch. GarlicOS replaces the stock firmware with a much cleaner interface, adds a sleep mode that lets you resume exactly where you left off, RTC support, overclocking options, and a wider range of configurable emulators. The stock firmware works but is bare-bones and lacks these quality-of-life features. The build quality is noticeably better than the other two devices, with a sturdier feel and a screen that is both larger and sharper.</p>
+<p><strong>What it plays well:</strong> Everything the ODROID-GO and PocketGo do, plus SNES running perfectly, PlayStation 1, CPS1/CPS2/CPS3 arcade, Jaguar, Sega CD, Sega 32X, and Neo Geo. It also supports HDMI output to a TV.</p>
+<p><strong>What it does not play well:</strong> Nintendo 64 and PSP are hit-or-miss. Dreamcast is mostly too much for it.</p>
+<p><strong>Game packs:</strong> Only the major platforms have game packs installed. The smaller systems are not pre-loaded.</p>
+<p><strong>Why use it:</strong> When you want the full experience, including PlayStation and arcade games, or when you want to hook the handheld up to a TV. It is the heaviest and least pocketable of the three, but it covers the widest range of systems.</p>
+<img src="RG35xx1.jpg" alt="RG35XX boot screen" width="640" height="480" loading="lazy">
+<p class="caption">The RG35XX boot screen.</p>
+<img src="RG35xx2.jpg" alt="RG35XX GarlicOS version" width="640" height="480" loading="lazy">
+<p class="caption">GarlicOS version 1.4.9 running on the RG35XX.</p>
+<img src="RG35xx3.jpg" alt="RG35XX system selection" width="640" height="480" loading="lazy">
+<p class="caption">The system selection screen on the RG35XX.</p>
+
+<h2>Which One for What</h2>
+<table>
+<tr><th>Device</th><th>Best for</th><th>Games loaded</th><th>Screen</th></tr>
+<tr><td>ODROID-GO</td><td>NES, Game Boy, instant-on 8-bit</td><td>All systems</td><td>2.4" TFT</td></tr>
+<tr><td>PocketGo</td><td>Game Boy Advance, 16-bit on the go</td><td>All systems</td><td>2.4" IPS</td></tr>
+<tr><td>RG35XX</td><td>PlayStation, arcade, everything at home</td><td>Major platforms only</td><td>3.5" IPS</td></tr>
+</table>
+
+<p class="note">The market for tiny retro gaming handhelds is full of traps. If a device's game list reads like a string of titles you have never heard of, that is the tell. Real arcade classics have instantly recognisable names, bootlegs hide behind vague, generic-sounding ones. All three devices above run proper emulation firmware with real ROMs, not bootleg NES clones dressed up as something else.</p>
 </div>
@@ -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>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>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>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. I also run the <a href="/retro/mistery-core/">MiSTery Core</a> on it as a full backup for the <a href="/retro/mega-st-low/">Mega ST 4 "Low"</a>, with the entire SD card cloned from the UltraSatan.</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>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>
@@ -0,0 +1,68 @@
+---
+title: "MiSTery Core on MIST: An FPGA Backup for the Mega ST 4"
+section: "retro"
+tags: "retro"
+description: "Running the MiSTery Core on the MIST FPGA board as a preserve for the Mega ST 4 Low, with five configurations from original TOS to Viking graphics."
+layout: base.njk
+parent: "/retro/"
+---
+<h1>MiSTery Core on MIST: An FPGA Backup for the Mega ST 4</h1>
+<div class="detail-content">
+
+<p>After getting the <a href="/retro/mega-st-low/">Mega ST 4 "Low"</a> fully configured, I cloned its entire UltraSatan SD card for the <a href="/retro/mist-mister-fpga/">MIST</a> FPGA board. The MiSTery Core on the MIST can access SD cards directly, so every partition from the UltraSatan is available right away, no HDD images needed. I can pull the SD card out of the MIST, put it into my computer and copy data straight onto it, just like with the UltraSatan. That keeps the MIST and the "Low" in sync and makes backups and data transfers very easy.</p>
+
+<h2>Why do it</h2>
+<p>The main reason is preservation. If the real Mega ST 4 ever breaks down, the MiSTery Core on the MIST can take over. It's not a replacement for the real hardware, but it means a dead Mega 4 doesn't leave me without a working setup.</p>
+
+<h2>The SD card workflow</h2>
+<p>The MIST reads the same SD card layout as the UltraSatan. Since the MiSTery Core supports direct SD card access, all partitions are immediately available. There's no need to convert partitions into HDD images or mount them through an emulator menu. The card comes out of the MIST and goes straight into a PC card reader. That makes it trivially easy to move data between the MIST and the real machine, and to keep backups current.</p>
+
+<h2>My configurations</h2>
+<p>I've prepared five configurations, each for a different use case:</p>
+
+<img src="mistery-configs.jpg" alt="The MiSTery Core configuration selection screen" width="640" height="640" loading="lazy">
+<p class="caption">The MiSTery Core configuration selection screen, showing all five available setups.</p>
+
+<h3>1. iTOS 1.04 (same as the Low)</h3>
+<p>The same setup as on the <a href="/retro/mega-st-low/">Mega ST 4 "Low"</a>. With iTOS, the boot options select which drive to boot from:</p>
+<ul>
+<li><strong>1 + Space</strong>, boot from <code>C:\BT\1</code>, opens D: GAMES</li>
+<li><strong>2 + Space</strong>, boot from <code>C:\BT\2</code>, opens E: DEMOS</li>
+<li><strong>3 + Space</strong>, boot from <code>C:\BT\3</code>, opens F: Med-Res</li>
+</ul>
+<p>Exactly the way I have it on the real machine.</p>
+
+<img src="itos1.jpg" alt="iTOS boot screen showing drive selection" width="640" height="640" loading="lazy">
+<p class="caption">The iTOS boot screen with the drive selection prompt.</p>
+<img src="itos2.jpg" alt="iTOS booting from the selected drive" width="640" height="640" loading="lazy">
+<p class="caption">iTOS booting from the selected drive.</p>
+<img src="itos3.jpg" alt="iTOS demo running after boot" width="640" height="640" loading="lazy">
+<p class="caption">A demo running after boot on the iTOS configuration.</p>
+
+<h3>2. 68020 14 MB with Viking Card</h3>
+<p>This is the most interesting configuration. On the real Mega 4 "Low", high resolution is limited to 640x400, which always felt small to me, hence the <a href="/retro/et4000-experiment/">ET4000</a> experiments and eventually the <a href="/retro/mega-st-high/">Mega ST 4 "High"</a>. On the MiSTery Core, I can activate an FPGA recreation of the Viking graphics card. The original Viking had 1280x900, the FPGA version uses 1280x1024, which matches exactly the native resolution of my <a href="/retro/atari-monitor-compatibility/">NEC monitor</a>. Unlike the ET4000, which gives me 256 colours, the Viking is black and white only. But paired with Geneva and the faster 68020 processor, it's genuinely pleasant to work on. The core also emulates an EtherNEC and I have STinG configured for networking.</p>
+
+<img src="viking1.jpg" alt="Viking configuration booting via EmuTOS" width="640" height="640" loading="lazy">
+<p class="caption">The Viking configuration booting via EmuTOS.</p>
+<img src="viking2.jpg" alt="Viking GEM desktop loading" width="640" height="640" loading="lazy">
+<p class="caption">The Viking GEM desktop coming up.</p>
+<img src="viking3.jpg" alt="Viking GEM desktop at full resolution" width="640" height="640" loading="lazy">
+<p class="caption">The Viking GEM desktop at full 1280x1024 resolution.</p>
+<img src="viking4.jpg" alt="Geneva desktop on the Viking card" width="640" height="640" loading="lazy">
+<p class="caption">Geneva running on the Viking card.</p>
+<img src="viking5.jpg" alt="Geneva desktop with windows open" width="640" height="640" loading="lazy">
+<p class="caption">The Geneva desktop with windows open, the final result.</p>
+
+<h3>3. 68000 8 MB</h3>
+<p>A slightly improved version of my high resolution configuration without the Viking card. I use this one for testing only.</p>
+
+<h3>4. ST TOS 1.04</h3>
+<p>As close to the original ST as possible. For playing floppy games and demos in a native configuration.</p>
+
+<h3>5. STE TOS 1.62</h3>
+<p>Same idea, but for STE-specific content. Original floppy games and demos that need STE hardware.</p>
+
+<h2>How it compares to the real Low</h2>
+<p>The MiSTery Core is an accurate FPGA recreation, so it behaves very much like the real hardware. The biggest practical differences are the Viking card option, which the real Mega ST 4 doesn't have, and the fact that the MIST has no physical MegaBus or ACSI port. But for the core use cases, preserving the "Low" setup and running floppy content, it's a solid stand-in.</p>
+
+</div>
--- a/Show More
+++ b/Show More