Уровни 10-12 прошли предварительный тест; HEAL-WIDTH связан с G8

Уровень 11 комната 14 проверена пользователем визуально после варианта B —
порядок падающего куска, соседней плиты и Кида корректен.  На 10 и 12
багов не найдено.

HEAL-WIDTH и G8 сведены как две половины одной темы: G8 про ширину ЗАПЕЧКИ
соседнего тайла (60 вместо 28 нужных, плюс draw_tile соседа дважды на
пометку), HEAL-WIDTH про ширину HEAL'ов (64 вместо фактических 58/57).
Оговорка из G8 перенесена: 60 = 32 свой тайл + 28 собственный свес, для
запечки самого тайла это минимум, сужать можно только пометку СОСЕДА.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.gitignore

@@ -113,3 +113,10 @@ mame/
 
 # Claude Code local settings (per-machine, not for the repo)
 .claude/
+
+# Тяжёлые справочные материалы, НЕ версионируются: docs/extra — архивы
+# исходников (~570 МБ, четыре почти одинаковых bad_apple), docs/sources —
+# клоны чужих репозиториев (Sprinter-BIOS, Estex-DSS, SaymanNsk) со своими
+# .git внутри (в коммите стали бы битыми gitlink-ссылками).
+docs/extra/
+docs/sources/

Makefile

@@ -1,10 +1,14 @@
 # Sprinter C Compiler — top-level Makefile
 #
-#   make             build host tools, libc archive, all tests, all apps
+#   make             build host tools, libc archive, all tests
 #   make tools       build only host tools (mkexe)
 #   make lib         build lib/sprinter.lib (libc) + lib/bgi256.lib (libbgi)
 #   make tests       build all libc feature tests under tests/
-#   make examples    build all real applications under examples/
+#   make examples    build all real applications under examples/ (НЕ входит
+#                    в `make all`: это регрессная сборка, а examples/ —
+#                    крупные приложения, которые её только замедляют
+#                    (mdview компилируется минутами) и ничего нового про
+#                    libc не показывают.  Собирать явно перед `make floppy`.)
 #   make floppy      package every .exe + test fixtures into mame/v306/IMG/mc.img
 #   make check       run mkexe unit tests
 #   make clean       remove all build artefacts
@@ -39,9 +43,9 @@ DATA_FILES := \
     examples/mdview/SAMPLE.MD
 
 .PHONY: all tools lib tests examples check clean sdcc floppy \
-        size-check size-baseline $(TESTS) $(APPS)
+        size-check size-baseline host-tests $(TESTS) $(APPS)
 
-all: tools lib tests examples
+all: tools lib tests
 
 tools:
 	$(MAKE) -C toolchain/mkexe
@@ -73,6 +77,14 @@ floppy: tests examples tests/seek/big.txt
 	@echo "Floppy ready: $(FLOPPY_IMG)"
 	@echo "Run:  cd $(MAME_DIR) && ./run_mame.sh"
 
+# Модульные тесты под ucsim_z80.  Обвязка — testkit/, сами наборы лежат
+# рядом с кодом, который проверяют.  MAME не нужна, идут за секунды;
+# ucsim идёт в комплекте нашего SDCC.
+HOST_TEST_DIRS := testkit applications/PoP/roomtest/tests-host
+
+host-tests:
+	@for d in $(HOST_TEST_DIRS); do $(MAKE) -C $$d || exit 1; done
+
 # Размерный регресс: сверить _CODE всех программ с docs/size_baseline.tsv.
 size-check:
 	python3 toolchain/size_check.py

applications/PoP/CLAUDE.md

@@ -23,7 +23,9 @@ sprinter-cc / libc / libbgi.  Действуют правила корневог
    исходнике, а не додумывать.
 3. Расхождение нашей реализации с SDLPoP — по умолчанию **баг у нас**, пока
    не доказано обратное (наша платформа/ABI требует отличия — тогда явно
-   зафиксировать почему в комментарии).
+   зафиксировать почему в комментарии **и записью в `docs/impl_diff.md`**:
+   что делает оригинал, что делаем мы, чем платим, что проверять при
+   регрессе).
 
 Карта сегментов: `seg005` control-диспетчер, `seg006` play_kid/коллизия/
 seqtbl, `seg007` mob/loose/падающие объекты, `seg008` отрисовка тайлов/
@@ -59,11 +61,16 @@ Princed для DAT v1.0 (контейнер/индекс/чек-сумма, ко
 
 ## Структура папки
 
-- `docs/` — планы и форматы: `PORT_PLAN.md` (общий план фаз),
-  `KID_PLAN.md`, `double_buffer_plan.md`, `loose_floors_plan.md`, форматы
-  ресурсов.  Начинать чтение отсюда.
-- `roomtest/` — **активная разработка**: комната 1 + Kid (анимация, ввод,
-  коллизия, падение, зацеп, fore-окклюзия, loose-полы).  Свой `CLAUDE.md`.
+- `docs/` — планы и форматы; **индекс с отметками актуальности —
+  `docs/README.md`**, начинать чтение оттуда.  Ключевое:
+  `levels_plan.md` (следующий этап), `layout_plan_v2.md` (раскладка кода по
+  окнам/банкам + скорость отрисовки), `PORT_PLAN.md` (карта фаз со
+  статусами).
+- `roomtest/` — **активная разработка**: уровень 1 целиком (Kid, стражи,
+  ловушки, ворота, loose-полы).  Свой `CLAUDE.md`; текущие задачи —
+  `roomtest/TASKS_OPEN.md` (закрытые с протоколами —
+  `roomtest/TASKS_CLOSED.md`), открытые баги — `roomtest/BUGS_OPEN.md`,
+  закрытые с разбором корней — `roomtest/BUGS_CLOSED.md`.
 - `poc/` — ранний proof-of-concept (снег/атлас/kbd_raw); ассеты в `poc/res/`.
 - `bgtest/`, `coltest/` — отдельные проверки фона/коллизии.
 - `toolchain/` — python-упаковщики ассетов + эталонные PNG (`1.1-2.png`).

applications/PoP/README.md

@@ -4,15 +4,22 @@
 target-слоя SDCC (sprinter-cc / libc / libbgi).  Цель — 320×256×256 (режим
 0x81), VGA-256 ассеты оригинала переносятся почти впрямую.
 
-Общий план и статус фаз — [`docs/PORT_PLAN.md`](docs/PORT_PLAN.md).
-Правила работы для ИИ-сессий — [`CLAUDE.md`](CLAUDE.md).
+**Состояние (2026-08-01): играется весь уровень 1** — комнаты и переходы,
+Kid со всем набором действий, ловушки, ворота, дверь уровня, меч и бой,
+стражи с ИИ, HP и зелья.  Нет: перехода на следующий уровень, звука,
+таймера/HUD, сохранений.
+
+- Что в работе прямо сейчас — [`roomtest/TASKS_OPEN.md`](roomtest/TASKS_OPEN.md).
+- Следующий этап (уровни 2+) — [`docs/levels_plan.md`](docs/levels_plan.md).
+- Общий план и статус фаз — [`docs/PORT_PLAN.md`](docs/PORT_PLAN.md).
+- Правила работы для ИИ-сессий — [`CLAUDE.md`](CLAUDE.md).
 
 ## Что где
 
 | Папка | Назначение |
 |-------|-----------|
-| `roomtest/` | **Активная разработка.** Комната 1 уровня 1 живой композицией тайлов + Kid: анимация (seqtbl), управление с клавиатуры, коллизия, падение, зацеп/подтягивание, fore-окклюзия, проваливающиеся полы. Свой README/CLAUDE. |
-| `docs/` | Планы (`PORT_PLAN`, `KID_PLAN`, `double_buffer_plan`, `loose_floors_plan`) и разбор форматов ресурсов Apple II / DOS. |
+| `roomtest/` | **Активная разработка.** Уровень 1 целиком: фон композицией тайлов, Kid (seqtbl-анимация, ввод, коллизия, падение, зацеп, окклюзия), ловушки, ворота, стражи, бой. Свой README/CLAUDE/TASKS. |
+| `docs/` | Планы и разбор форматов ресурсов Apple II / DOS — см. индекс в [`docs/README.md`](docs/README.md). |
 | `toolchain/` | Python-упаковщики ассетов под Sprinter (рендер комнат, атласы тайлов/Kid, извлечение данных анимации) + эталонные скриншоты. |
 | `poc/` | Ранний proof-of-concept (снег, атлас, raw-клавиатура). Ассеты в `poc/res/`. |
 | `bgtest/`, `coltest/` | Точечные проверки фона и коллизии. |

applications/PoP/docs/KID_PLAN.md

@@ -1,6 +1,21 @@
 # Prince of Persia — Kid (персонаж): анализ и план
 
-Статус: план (2026-07-16).  Опирается на разбор `SDLPoP/src/seg006.c`
+> **Статус: РЕАЛИЗОВАНО (2026-08-01).**  Kid играется целиком: интерпретатор
+> `seqtbl` + `frame_table` (`roomtest/pop_kid.c`), диспетчер `control()`
+> (`pop_ctrl.c`), коллизия/физика/зацеп (`pop_map.c`), бой и HP.  Модель
+> персонажа стала общей: `Char`-окно (`pop_state.c`) обслуживает и Кида, и
+> стражей.  Таблицы кадров и `seqtbl` уехали из `_CODE` в EMM-страницу
+> (`kid_data.bin`, см. `layout_plan_v2.md` шаг 1).
+>
+> Отступление от §2.1 плана: выбран ПАДДИНГ кадров (общий канвас), а не
+> per-frame offset — компромисс зафиксирован в `PORT_PLAN.md §6.1`.
+>
+> **Документ оставлен как СПРАВОЧНИК по модели персонажа** (`char_type`,
+> категории `actions_*`, устройство `play_seq`, объём спрайтов) — он нужен
+> при портировании остальных акторов (скелет, тень, визирь).  Текущие
+> задачи — `../roomtest/TASKS_OPEN.md`.
+
+Составлен 2026-07-16.  Опирается на разбор `SDLPoP/src/seg006.c`
 (ядро физики/управления Kid), `seqtbl.c` (таблицы последовательностей),
 `types.h` (char_type, seq_*, SEQ_*, actions_*), `SDLPoP/data/KID` (спрайты).
 Фон уже готов и проверен на MAME (`applications/PoP/roomtest`, см.

applications/PoP/docs/PORT_PLAN.md

@@ -1,8 +1,29 @@
 # Prince of Persia на ZX Sprinter — план порта
 
-Статус: план (2026-07-15).  §2 (A: kbd_mod_state / B: kbd_raw) —
-РЕАЛИЗОВАНО и частично проверено в MAME (tests/kbdraw, 2026-07-15,
-подробности в §2.2); PoC (§5) и остальные фазы — не начаты.  Опирается на
+## СТАТУС (обновлено 2026-08-01)
+
+Документ составлен 2026-07-15 как план «с нуля» и с тех пор во многом
+исполнен.  Читать его надо так:
+
+| Раздел | Что с ним сейчас |
+|--------|------------------|
+| §1 возможности библиотек | актуально как обзор, но **спрайтовый движок `sprite.h` для персонажей НЕ используется**: Kid/страж рисуются прямыми блитами атласов (`gfx_blit_cols_part*`) с ручным heal — так требует модель оригинала (§6) |
+| §2 held-state клавиатуры | **сделано** (`kbd_mod_state`, `<kbd_raw.h>`).  Открытая проблема — потеря байт при аккордах Shift+стрелка; диагноз и план в `../roomtest/TASKS_CLOSED.md` (KBD-1) |
+| §3 форматы данных | актуально; уровень читается живьём (`roomtest/pop_level.c`) |
+| §4 стратегия фона | **сделано** — тайловый рендерер в рантайме (`roomtest/pop_bg.c`) |
+| §5 PoC | **закрыт и превзойдён.**  `poc/` (плейсхолдер-персонаж) — история; активная разработка ушла в `roomtest/` с настоящей графикой |
+| §6 модель движения | **сделано**: `play_seq` + `frame_table` оригинала, не физика с нуля |
+| §7 фазы | см. отметки статуса прямо в разделе |
+| §8 риски | п.1 закрыт, п.3 закрыт (28 страниц-атласов Кида), п.2/п.4 — см. отметки в разделе |
+| §10 режим памяти | **сделано и переросло план**: `huge` + четыре банка кода; актуальная раскладка — `layout_plan_v2.md` |
+
+**Где смотреть текущее состояние, а не план:** `../roomtest/README.md`
+(что играется), `../roomtest/TASKS_OPEN.md` (что в работе), `levels_plan.md`
+(следующие уровни), `layout_plan_v2.md` (раскладка кода по окнам и банкам).
+
+---
+
+Опирается на
 `APPLEII_RESOURCE_FORMAT.md` / `MSDOS_RESOURCE_FORMAT.md` / `README.md` в
 этой папке, на текущий sprinter-cc/libc/libbgi (см. §1) и на локальные копии
 `applications/PoP/SDLPoP` (github.com/NagyD/SDLPoP, GPLv3) и
@@ -227,6 +248,13 @@ dirty-биты, heal против фона через ОЗУ-копию); `room_
 
 ## 5. Proof-of-Concept — цель: доказать, что порт вообще ощущается как PoP
 
+> **Закрыт (исторический раздел).**  PoC в `poc/` свою задачу выполнил и
+> дальше не развивается: управление ощущается как PoP, held-state работает.
+> Всё, что ниже про плейсхолдер-персонажа и приблизительную дугу прыжка,
+> — уже неправда для активной ветки: в `roomtest/` стоит настоящая графика
+> Кида и авторские таблицы кадров (§6).  Раздел оставлен ради истории
+> решений (в частности §5.1 — почему сначала был плейсхолдер).
+
 **Объём**: одна комната (например Level 1, экран старта Кида), без
 переходов между экранами, без стражников (стретч-цель, не обязательна).
 
@@ -364,45 +392,53 @@ memory/png_strip_padding_tradeoff.
 ## 7. Полноценное приложение — фазы (после PoC)
 
 Порядок — по риску и зависимостям, не по геймплейной важности.
+**Отметки статуса — на 2026-08-01.**
 
-**Фаза 0 — инфраструктура порта** (расширяет PoC, не переписывает):
-- Хелд-стейт клавиатуры — финальное решение и реализация по §2 (после
-  подтверждения пользователем).
-- Полный конвертер уровней (все 15 файлов `levels.dat`/`LEVELn`) → бинарный
-  формат приложения (можно 1-в-1 raw dump, читать по офсетам в рантайме —
-  не обязательно разворачивать в C-struct с указателями).
-- Полный конвертер фона (24 экрана × N уровней) в растры + конвертер
-  спрайт-лент Кид/стражник/скелет/тень/Джаффар в атласы `.atl` (расширение
-  `conv_sprites.py`/формата `.atl`, если частот кадров/атласов на актора не
-  хватит текущего лимита — см. риск в §8).
+**Фаза 0 — инфраструктура порта** — **СДЕЛАНА**, но иначе, чем задумано:
+- Хелд-стейт клавиатуры по §2 — сделан.
+- Конвертер уровней не понадобился: `res200N.bin` из `SDLPoP/data/LEVELS`
+  кладётся на образ как есть и читается по офсетам в рантайме
+  (`roomtest/pop_level.c`), уровень живёт в EMM-странице.
+- Конвертер фона в растры **отменён осознанно** (§4): фон собирается
+  тайлами в рантайме.  Спрайты — `toolchain/pop_pack_bg.py` /
+  `pop_pack_kid.py` / `pop_pack_guard.py` → атласы `.atl` (Kid — 28
+  страниц, риск §8 п.3 закрыт).
 
-**Фаза 1 — Кид, полный набор действий**: стоять/идти/бежать/тормозить/
-разворот/прыжок (на месте, вперёд, «прыжок с разбега»)/повисание на
-краю/подтягивание/спуск по свисанию/приседание/питьё зелья/смерть от
-провала. Переходы между экранами (`MAP`-граф, `INFO.KidStartScrn`).
+**Фаза 1 — Кид, полный набор действий** — **СДЕЛАНА**: стоять/идти/бежать/
+тормозить/разворот/прыжки/повисание/подтягивание/спуск/приседание/
+осторожный шаг/питьё зелья/смерть от провала и от пик; переходы между
+комнатами во все четыре стороны.  Осталось: **старт по данным уровня**
+(`pop_level_start_*` реализованы, но не подключены) — задача L1-START в
+`../roomtest/TASKS_OPEN.md`.
 
-**Фаза 2 — мир и ловушки**: нажимные плиты/двери через граф
-`LINKLOC`/`LINKMAP` (см. `APPLEII_RESOURCE_FORMAT.md` §1.2), шипы
-(выдвижение/втягивание/заклинивание), шаткие плиты (loose, обрушение),
-зелья (эффект по `BLUESPEC×32`), стартовые позиции по `INFO`.
+**Фаза 2 — мир и ловушки** — **СДЕЛАНА**: кнопки/ворота через
+`LINKLOC`/`LINKMAP`, шипы, loose-полы (тряска, обрушение, щебень, пробой
+потолка), зелья, дверь уровня (открывается), факелы.  Подробности и
+справочник — `gates_spikes_plan.md`.
 
-**Фаза 3 — бой**: подбор/выхватывание меча, состояние стойки, парирование/
-удар, коллизия клинков — по логике `AUTO.S`/`seg003-006.c` (референс, не
-копия). Стражник: базовое AI-поведение по `GdStartProg` (несколько
-шаблонов программ), Y-сортировка слоями уже есть в движке для «кто
-спереди/сзади».
+**Фаза 3 — бой** — **СДЕЛАНА в объёме обычного стражника**: подбор и
+выхватывание меча, стойка, удар/парирование, коллизия клинков, HP обеих
+сторон, смерть; ИИ стража (замечает Кида, подходит, боевые ветки),
+персистентность трупа между комнатами.
 
-**Фаза 4 — разнообразие противников**: скелет, тень (копия анимации Кида —
-подтверждено побайтовым совпадением данных, см. `MSDOS_RESOURCE_FORMAT.md`
-§3), толстый стражник/визирь (общая база анимации с визирем).
+**Фаза 4 — разнообразие противников** — **НЕ НАЧАТА**.  Скелет нужен на
+уровне 3, толстый — на 6, тень — на 12, визирь — на 13; привязка
+«уровень → тип стража» (`tbl_guard_type`) описана в `levels_plan.md` §1.
 
-**Фаза 5 — звук**: CBL-эффекты (шаги, удары, двери, падение) из
-`digisnd*.dat`→PCM; PC-спикер тройки (`ibm_snd*.dat`) как опциональный
-дешёвый бипер без CBL, если формат подтвердится простым парсингом.
+**Фаза 5 — звук** — **НЕ НАЧАТА**: CBL-эффекты (шаги, удары, двери,
+падение) из `digisnd*.dat`→PCM; PC-спикер тройки (`ibm_snd*.dat`) как
+опциональный дешёвый бипер без CBL, если формат подтвердится простым
+парсингом.  Опкод `SOUND` в `play_seq` пока просто съедает свой аргумент —
+точки вызова уже на месте.
 
-**Фаза 6 — оболочка**: титры, меню/выбор уровня, HUD (таймер/жизни),
-сохранение прогресса (FILE*), финальные катсцены — по минимуму,
-геймплейно не критично.
+**Фаза 6 — оболочка** — **НЕ НАЧАТА**: титры, меню/выбор уровня, HUD
+(таймер/жизни), сохранение прогресса (FILE*), финальные катсцены — по
+минимуму, геймплейно не критично.  Полоса HP — единственное, что уже есть.
+
+**Между Фазами 4 и 5 вклинивается то, чего в этом плане не было:
+переход между УРОВНЯМИ** (загрузка следующего уровня, второй тайлсет
+palace, потабличные различия уровней).  Отдельный документ —
+`levels_plan.md`.
 
 **Фаза 7 — стабилизация**: полный прогон всех 14 уровней в MAME
 (`mame_interactive.py`), затем на реальном железе; профилирование бюджета
@@ -418,23 +454,33 @@ tiny/small.
 
 (по правилу `defer_unexplained_quirks` — не гадать, проверять)
 
-1. **Held-state клавиатуры** (§2) — блокирует даже PoC, если решать
-   «правильно»; иначе PoC на компромиссном варианте 2 (таймаут-эвристика).
-2. **Бюджет спрайтов на насыщенный экран** — сцена с 2+ стражниками +
-   несколько анимированных ловушек может приблизиться к лимиту
-   ~21 спрайт/кадр (`sprite_engine_perf`) — нужна прикидка по реальным
-   уровням (сколько объектов одновременно активно в худшем экране).
-3. **Ёмкость одного атласа/страницы EMM на актора** — у Кида ~220 кадров
-   (все действия) против 4×12 у `rpgwalk` — потребуется либо несколько
-   атласов на актора с переключением по фазе действия (стоять/идти отдельно
-   от боя), либо расширение формата `.atl`/загрузчика на мульти-страничные
-   атласы — оценить фактический байтовый вес конвертированных кадров Кида
-   прежде чем проектировать.
-4. **Тайминг оригинала** — сверить логическую частоту кадров анимации
-   оригинала (Apple II ~60 Гц NTSC / DOS — фиксированный таймер) с 50 Гц
-   Sprinter; если оригинал считался на другой частоте — потребуется
-   коэффициент пересчёта смещений кадров (§6), иначе прыжки/бег будут
-   визуально быстрее/медленнее эталона.
+1. ~~**Held-state клавиатуры** (§2)~~ — **закрыт** (`<kbd_raw.h>`).  Открытый
+   остаток — не «есть ли held-state», а потеря байт при аккордах
+   Shift+стрелка: `../roomtest/TASKS_CLOSED.md`, KBD-1.
+2. **Бюджет кадра** — риск подтвердился, но не в том виде, в каком ожидался:
+   спрайтовый движок для персонажей не используется, поэтому лимит
+   «~21 спрайт/кадр» неприменим.  Реальный бюджет упирается в heal+блиты и
+   перерисовку тайлов; замер 2026-07-30 — типичный кадр ~371 К тактов
+   (~86 % периода).  Инструмент замера уже в коде: полосы бордюра `PROF()`
+   в `roomtest.c`.  План выжимания — `../roomtest/TASKS_CLOSED.md` (CLIP-1) и
+   `../roomtest/BUGS_OPEN.md` (T-1/T-2).
+3. ~~**Ёмкость атласа на актора**~~ — **закрыт**: Kid разложен на 28
+   атласов-страниц по 8 спрайтов (`pop_pack_kid.py`), страж — на 5;
+   мульти-страничного формата `.atl` не потребовалось.  Побочно
+   подтвердился компромисс паддинга (§6.1).
+4. **Тайминг оригинала** — **ОТКРЫТ, и сверка 2026-08-01 показывает
+   расхождение.**  Цифры оригинала (SDLPoP): базовый таймер `BASE_FPS = 60`
+   (`types.h:1373`), логический кадр игры — `base_speed = 5` тиков
+   (`data.h:869`), то есть **83.3 мс (12 лог. кадров/с)**; в бою
+   `fight_speed = 6` → **100 мс (10/с)**.  У нас (`roomtest.c`) — три
+   ожидания `gfx_wait_vsync()` на итерацию, то есть **60 мс (16.7/с)** и
+   без отдельной скорости боя.  Значит **игра идёт примерно на 39 %
+   быстрее эталона**.  Точное соответствие даёт 4 ожидания vsync (80 мс
+   против 83.3) и 5 в бою (100 мс — совпадает точно).
+   Проверять не «на глаз», а секундомером по одинаковому отрезку
+   (SDLPoP рядом на том же экране), и только после того, как кадр
+   перестанет иногда вылезать за период (см. п.2) — иначе замедление
+   спрячет проблему бюджета вместо того, чтобы её показать.
 
 ---
 

applications/PoP/docs/README.md

@@ -1,4 +1,50 @@
-# Форматы ресурсов Prince of Persia — сводка
+# `applications/PoP/docs` — индекс + сводка по форматам ресурсов
+
+## Индекс документов (актуальность на 2026-08-01)
+
+**Живые планы — читать перед работой:**
+
+| Документ | О чём |
+|----------|-------|
+| [`../roomtest/TASKS_OPEN.md`](../roomtest/TASKS_OPEN.md) | **Что берётся в работу сейчас** (не в этой папке, но входная точка) |
+| [`../roomtest/BUGS_OPEN.md`](../roomtest/BUGS_OPEN.md) | Открытые баги roomtest (закрытые — в `BUGS_CLOSED.md` рядом) |
+| [`impl_diff.md`](impl_diff.md) | **Осознанные расхождения с SDLPoP**: где мы сделали не дословно и почему |
+| [`perf_l13_room23.md`](perf_l13_room23.md) | **Сцена и метод замера кадра** (каскад плит, ур.13 к.23): как воспроизвести, зонды, канал `clog`, сводка по кадрам, габариты спрайтов и ответ про `uint8_t`.  2026-08-17 |
+| [`perf_green_phase.md`](perf_green_phase.md) | **ЗЕЛЁНАЯ фаза (слой фона)**: раскладка тактов, способы ускорения (G1..G6), журнал правок — рабочий документ между сессиями.  2026-08-17 |
+| [`perf_cyan_phase.md`](perf_cyan_phase.md) | **ЦИАН фаза (персонажи + передний слой)**: раскладка тактов, способы ускорения (C1..C7), журнал правок — рабочий документ между сессиями.  2026-08-17 |
+| [`perf_backlog.md`](perf_backlog.md) | Отложенная оптимизация отрисовки с замерами 2026-08-10 + **как мерить** (wait-state'ы, границы кадра).  Позиции 1–7 переехали в фазовые документы выше |
+| [`quicksave_plan.md`](quicksave_plan.md) | **QuickSave/QuickLoad**: разбор (это enhancement SDLPoP, в оригинале 1989 его НЕТ), инвентаризация нашего состояния, формат снимка, шаги QS1..QS6.  План, код не начат.  2026-08-17 |
+| [`levels_plan.md`](levels_plan.md) | Следующий этап: уровни 2+, второй тайлсет, читы SDLPoP |
+| [`levels_12_15_plan.md`](levels_12_15_plan.md) | **Уровни 12/13** (тень, Джафар, падающие плиты) + что такое 14/15 и 0.  2026-08-13 |
+| [`midtable_analysis.md`](midtable_analysis.md) | **Слои отрисовки**: как устроены back/mid/fore и objtable в оригинале, чего стоит порт, развилки.  2026-08-13 |
+| [`roomnav_skip.md`](roomnav_skip.md) | **Комнаты для отладочного телепорта**: какие пропускать и почему (посчитано по данным уровней).  2026-08-13 |
+| [`layout_plan_v2.md`](layout_plan_v2.md) | Раскладка кода по окнам/банкам/страницам + замеры скорости отрисовки |
+| [`room_model_plan.md`](room_model_plan.md) | `kid_room ≠ drawn_room` (straddle): сделан S1, остальное впереди |
+| [`host_tests_plan.md`](host_tests_plan.md) | Модульные тесты движка под ucsim_z80: два шва, регрессии из `BUGS_CLOSED.md`, дифф против SDLPoP |
+| [`shadow_render.md`](shadow_render.md) | **Вид Тени (OR+XOR)** — отложено: почему XOR несовместим с прозрачностью `#FF`, замер подготовки источника, четыре варианта |
+| [`ideas_backlog.md`](ideas_backlog.md) | Осознанно отложенные гипотезы (мышь, PRNG) |
+| [`prng_alternatives.md`](prng_alternatives.md) | Запасные генераторы, если упрёмся в бюджет кадра |
+
+**Исполненные планы, оставленные как справочники:**
+
+| Документ | Чем ещё полезен |
+|----------|-----------------|
+| [`PORT_PLAN.md`](PORT_PLAN.md) | Общая карта фаз со статусами; §6 (модель движения), §10 (режим памяти) |
+| [`KID_PLAN.md`](KID_PLAN.md) | Модель персонажа: `char_type`, `actions_*`, устройство `play_seq` — нужна для скелета/тени/визиря |
+| [`gates_spikes_plan.md`](gates_spikes_plan.md) | Раскладка объектов уровня 1 по комнатам, декод `LINKLOC`/`LINKMAP`, точные ссылки на seg-код |
+
+**Форматы ресурсов** (ниже по этому файлу): `POP-DAT-FormatSpecifications.pdf`
+/ `.txt` (первоисточник), `APPLEII_RESOURCE_FORMAT.md`,
+`MSDOS_RESOURCE_FORMAT.md`.
+
+Удалены 2026-08-01 как полностью исполненные и перекрытые кодом:
+`clip_char_plan.md`, `double_buffer_plan.md`, `loose_floors_plan.md`,
+`size_optimization_plan.md` (его §8 про скорость отрисовки перенесён в
+`layout_plan_v2.md` §9).  Ищутся в истории git, если понадобятся.
+
+---
+
+## Форматы ресурсов — сводка
 
 **Каноническая спецификация форматов** — `POP-DAT-FormatSpecifications.pdf`
 (+ текстовая конверсия `POP-DAT-FormatSpecifications.txt` для grep/цитирования):
@@ -70,7 +116,11 @@ DOS-упаковщика). Это значит: раскладку `BLUETYPE`/`B
 дворца/подземелий) практичнее взять их оттуда напрямую, чем писать свой
 декодер сжатия пикселей DOS `.DAT`. 
 
-## Что дальше (не сделано в этом заходе)
+## Что дальше по форматам (не сделано и пока не нужно)
+
+Порт читает уровень напрямую из `res200N.bin` (`roomtest/pop_level.c`), а
+графику берёт из распакованных PNG `SDLPoP/data/` — поэтому ни один пункт
+ниже сейчас не блокирует работу.
 
 1. Точный кодек сжатия пикселей спрайтов в сыром DOS `.DAT` (нужен только
    если понадобится читать именно нашу локальную копию `MSDOS/*.dat`

applications/PoP/docs/clip_char_plan.md

@@ -1,112 +0,0 @@
-# План: порт `clip_char()` — обрезка спрайта персонажа
-
-Статус: в работе с 2026-07-28.  Контекст: баг «спуск Кида с кнопки в комнате 8»
-(Kid просвечивает в щель между кнопкой и ближним столбом, мусор на кромке).
-
-## Симптом
-
-room 8, Kid спускается (climbdown) с тайла-кнопки у ближней колонны.  Спрайт
-Кида нарисован ЦЕЛИКОМ, включая часть, которая в оригинале обрезана по линии
-пола: видно «просвет» Кида в щели между кнопкой и колонной и мусор на кромке.
-
-## Корень
-
-Не портирован `clip_char()` (SDLPoP `seg006.c:1749`, вызывается из
-`add_kid_to_objtable`/`add_guard_to_objtable`, `seg008.c:1671/1690`, ПОСЛЕ
-`set_char_collision`/`set_objtile_at_char`/`redraw_at_char*` и ПЕРЕД
-`add_objtable`).  Оригинал кладёт в objtable не только позицию спрайта, но и
-прямоугольник клипа `obj_clip_{top,bottom,left,right}`; блиттер рисует только
-внутри него.  Мы рисуем без клипа вообще.
-
-## Что делает оригинал (дословно)
-
-`reset_obj_clip()` → `left=0, top=0, right=320, bottom=192`.
-
-Дальше (упрощая C-трюк с глобалью `curr_tile2`, которую ставит каждый
-`get_tile`: `X == wall || tile_is_floor(curr_tile2)` — это «тайл X = стена
-ИЛИ пол»):
-
-```
-T_L = get_tile(room, char_col_left,  char_top_row)
-T_R = get_tile(room, char_col_right, char_top_row)
-if (T_L — стена или пол) &&
-   ( (action == stand && (frame == 79 || frame == 81))   /* прыжок вверх / зацеп */
-     || (T_R — стена или пол) )
-{
-    clip_row = Char.curr_row + 1;
-    clip_y   = y_clip[clip_row];          /* y_clip[] = {-60, 3, 66, 129, 192} */
-    if (clip_row == 1 || (clip_y < obj_y && clip_y - 15 < char_top_y))
-        obj_clip_top = char_top_y = clip_y;
-}
-```
-
-Смысл: `y_clip[row+1]` — верхняя граница СВОЕЙ полосы ряда.  Если над головой
-пол/стена — всё, что выше этой линии, не рисуется (персонаж «уходит под пол»).
-Для ряда 0 (`clip_row == 1`) клип применяется БЕЗУСЛОВНО.
-
-Метрики из `set_char_collision` (seg006:0723):
-- `char_x_left  = obj_x/2 + 58` (и `-= char_width_half`, если смотрит вправо)
-- `char_x_right = char_x_left + char_width_half`, `char_width_half = (w+1)/2`
-- `char_top_y   = obj_y - h + 1`; если `>= 192` → `0`
-- `char_top_row = y_to_row_mod4(char_top_y)`
-- `char_col_left = MAX(get_tile_div_mod(char_x_left), 0)`,
-  `char_col_right = MIN(get_tile_div_mod(char_x_right), 9)`
-
-Второй блок `clip_char` — `obj_clip_right` (doortop / стена / зеркало для
-виса-полёта-подъёма при взгляде влево, кадры 137..139) и ветка кадров 224..228
-(выход в дверь уровня).  **Фаза 2**, не в этом заходе.
-
-## Наши точки касания
-
-- `roomtest/pop_kid.c` `kid_draw()` — сам считает `obj_x/obj_y/w/h` и блитит
-  через `gfx_blit_cols(bx, top + POP_YOFF, img, flip)`; запоминает
-  прямоугольник в `kid_l{x,y,w,h}[page]` для `kid_heal()`.
-- `roomtest/pop_map.c` — там `get_tile()`, `tile_is_floor()`, `y_to_row()`,
-  `get_tile_div_mod_m7()`, Kid-структура.  Аналогичный расчёт габарита уже
-  есть в `check_spike_below()` (строка ~1198) — брать за образец.
-- `libbgi/common/gfx_blit_cols.c` — клип по экрану есть (при `y < 0`
-  пропускает `sy` верхних строк колонки), но произвольной верхней границы нет.
-
-## Шаги
-
-1. **libbgi**: `gfx_blit_cols_part(int x, int y, const void *img, uint8_t flip,
-   int sy, int h)` — «пропустить `sy` верхних строк спрайта, нарисовать `h`».
-   Реализация = тело `gfx_blit_cols` с предустановленными `sy`/`h` (источник
-   `+= sy`, экранный `y += sy`).  Прототип в `libbgi/include/gfx.h`.
-   Стоимость: 0 в общем пути (обычный `gfx_blit_cols` вызывает то же ядро).
-2. **pop_map.c**: `int pop_clip_char_top(int obj_x, int obj_y, uint16_t w,
-   uint16_t h)` — порт первого блока `clip_char`; возвращает КОМНАТНЫЙ y
-   (0 = клипа нет).  Экспорт в `pop_map.h`.
-3. **pop_kid.c**: в `kid_draw()` после расчёта `top` —
-   `ct = pop_clip_char_top(...)`; если `ct > top` → `sy = ct - top`,
-   рисовать `gfx_blit_cols_part(bx, ct + POP_YOFF, img, flip, sy, h - sy)`;
-   в `kid_l*[page]` класть ОБРЕЗАННЫЙ прямоугольник (иначе heal чистит лишнее
-   и стирает кромку пола).  То же для `kid_draw_splash` — там оригинал делает
-   `reset_obj_clip()`, т.е. splash НЕ клипится (ничего не менять).
-4. **Сборка**: `make -C libbgi`, `make -C applications/PoP/roomtest`,
-   `make size-check`; вывести свободное место в W2/W3 (порог 512 Б).
-5. **Проверка в MAME** (`mame_hdd_test_disk`, полный рестарт после
-   пересборки образа): комната 6 → переход в 8 → влезть на кнопку → спуск.
-   Сверять с эталоном: живой SDLPoP той же позой (см. `pop_check_sdlpop_first`).
-
-## Риски / что проверить отдельно
-
-- `char_top_row` считается `y_to_row_mod4` — у нас `y_to_row()` даёт −1 для
-  полосы у потолка; `get_tile(row −1)` уже умеет ряд 2 верхнего соседа.
-- Kid ниже комнаты (`char_top_y >= 192` → `0`) — обязателен ресет, иначе клип
-  прыгнет.
-- `clip_row == 1` (ряд 0) — клип БЕЗУСЛОВНЫЙ: проверить, что не режет Кида в
-  обычной стойке на ряду 0 (условие внешнего `if` про пол/стену над головой
-  должно отсекать).
-- Клип меняет прямоугольник heal → возможен «хвост» на второй странице
-  дабл-буфера: проверять оба кадра (SPACE — выключить дабл-буфер).
-
-## Дальше (Фаза 2, отдельно)
-
-`obj_clip_right` (doortop/стена/зеркало) — нужен для виса и подъёма при
-взгляде влево; и `obj_clip_left` для зеркала (уровень 4).  Требует клипа по
-колонкам в `gfx_blit_cols` (обрезка справа = уменьшить `w`) — дёшево, но
-без тестовой сцены проверять нечем.
-
-См. memory: `pop_clip_char_todo`, `pop_backtable_vs_midtable`,
-`pop_check_sdlpop_first`, `gfx_blit_noclip_fast`.

applications/PoP/docs/double_buffer_plan.md

@@ -1,69 +0,0 @@
-# Double buffer (два экрана + флип) — план
-
-Цель: убрать мерцание/тиринг при перерисовке слоёв (Kid ↔ fore/пол-оверлей)
-и гарантировать, что на экране ВСЕГДА готовый кадр с правильным порядком
-слоёв.  Нужно для отладки fore-слоя (видно момент композиции, а не
-промежуточные состояния heal-рендера).  **Тумблер обязателен** —
-однобуферный режим удобнее для отладки багов рисования.
-
-## Что уже готово (libbgi — трогать НЕ нужно)
-
-- Две графических страницы 0/1: `gfx_set_draw_page(p)` (двигает
-  `_gfx_addr_base` 0xC000/0xC140 — рисуют все примитивы),
-  `gfx_set_visible_page(p)` (ESTEX $54 SELPAGE — display-учёт DSS).
-- `gfx_wait_vsync()` — луч (bit5 порта 0xFE), момент без разрывов.
-- Паттерн из gfx.h: `set_draw_page(hidden); draw(); wait_vsync();
-  set_visible_page(hidden);`
-- Замечание gfx.h: у каждой страницы СВОЯ плоскость палитры
-  (page0→pal0, page1→pal1) — для seamless грузить одну палитру в ОБЕ.
-
-## Текущая модель рендера roomtest (однобуфер)
-
-`roomtest.c`: `draw_page=0`, `visible_page=0` фиксированы.  Фон комнаты
-рисуется ОДИН раз в видео-ОЗУ + теневую копию (GFX_BANK_TRANSPARENT).
-Цикл: 3× `gfx_wait_vsync` (пейсинг) → `pop_ctrl_tick` → `kid_heal()`
-(восстановить прямоугольник Кида из тени) → `kid_tick`/`pop_phys_tick`
-→ `kid_draw` → `pop_fore_over_kid`.  Мерцание = heal+draw+fore длиннее
-бланка, луч ловит промежуток.
-
-## Работа на стороне PoP
-
-1. **Инициализация обеих страниц**: `pop_room_draw` в page 0 И page 1
-   (теневая копия одна — общая, из неё heal'ит любая страница).
-2. **Палитра в обе плоскости**: сейчас `gfx_pal_fload(0,...)` + sync.
-   Продублировать в plane 1 (проверить сигнатуру gfx_pal_fload/sync —
-   plane-параметр).
-3. **Per-page heal-история** (ядро): вынести `kid_lx/ly/lw/lh` в
-   массивы `[2]`, индекс = страница, в которую рисуем.  `kid_heal(page)`
-   восстанавливает СВОЙ прошлый прямоугольник (кадр -2, т.к. рисуем
-   через страницу).  То же для fore/пол-оверлея, если они рисуют вне
-   футпринта Кида.
-4. **Ping-pong в цикле**:
-   ```
-   uint8_t back = dbuf ? (front ^ 1) : 0;
-   gfx_set_draw_page(back);
-   kid_heal(back); kid_tick; phys; kid_draw; fore;
-   gfx_wait_vsync();
-   if (dbuf) { gfx_set_visible_page(back); front = back; }
-   ```
-5. **Тумблер** `dbuf`: off → draw==visible==0, без флипа, heal[0] —
-   бит-в-бит текущее поведение.  Управление — клавишей (напр. F2) или
-   compile-флагом.
-6. **Пейсинг**: сейчас 3× vsync/лог.кадр.  При флипе — один vsync перед
-   свопом; недостающий пейсинг добрать `gfx_set_fps_div(3)` или ручным
-   счётом кадров, чтобы скорость игры не изменилась.
-
-## Порядок
-
-- D1: обе страницы + палитра в обе плоскости; ping-pong без per-page
-  heal (проверить, что флип работает, фон корректен на обеих).
-- D2: per-page heal-история (kid_l*[2]) — убрать «хвост» Кида.
-- D3: тумблер dbuf + сверка однобуферного пути с текущим (регресс-нет).
-- D4: пейсинг (fps_div) — вернуть исходную скорость.
-
-## Связанные
-
-Рендер-модель — [[pop_fore_layer]], [[pop_background_strategy]];
-heal — kid_heal/gfx_heal.  Будущие динамические слои (loose-floors
-[[двойной буфер требует их per-page перерисовки]]) должны рисоваться в
-обе страницы по той же дисциплине.

applications/PoP/docs/gates_spikes_plan.md

@@ -1,8 +1,23 @@
 # Интерактивные объекты (кнопки/гейты/пики) + HP/смерть — ПОДРОБНЫЙ план
 
-Статус: **план** (2026-07-20).  Реализация — отдельной сессией.  Документ
-самодостаточный: рассчитан на старт «с чистого листа» (пустой контекст).
-Всё сверено с `applications/PoP/SDLPoP/src/` и данными `res2001.bin`.
+> **Статус: РЕАЛИЗОВАНО (2026-08-01).**  Все фазы плана (P0 персистентный
+> per-room `room_modif`, S пики, B кнопки+ворота) сделаны и играются:
+> `roomtest/pop_trob.c` (trob-диспетчер, `LINKLOC`/`LINKMAP`, ворота, дверь
+> уровня, факелы, зелья), `pop_map.c` (HP, смерть на пиках, урон падения),
+> `pop_redraw.c` (пометки перерисовки вместо прямых блитов).  Ограничения
+> из §0 закрыты: тайлы персистентны, HP/смерть есть, loose обобщён в trob;
+> L3-вверх (climb-up в комнату сверху) тоже сделан (`pop_leave_dir = 3`).
+> Из §5 остаётся открытым только **переход на следующий уровень через дверь
+> уровня** — он вынесен в `levels_plan.md`.
+>
+> **Документ оставлен как СПРАВОЧНИК**, а не как план: §1 (раскладка
+> объектов уровня 1 по комнатам, декод связей кнопка→цель) и §2 (точные
+> ссылки на механику SDLPoP) продолжают экономить время при отладке.
+> Текущие задачи — `../roomtest/TASKS_OPEN.md`.
+
+Составлен 2026-07-20.  Документ самодостаточный: рассчитан на старт
+«с чистого листа» (пустой контекст).  Всё сверено с
+`applications/PoP/SDLPoP/src/` и данными `res2001.bin`.
 
 Правило проекта (см. `applications/PoP/CLAUDE.md`): **SDLPoP — источник истины**,
 перед кодингом читать соответствующий код seg*.c, не гадать.
@@ -35,7 +50,7 @@ roomtest — живой прототип порта PoP: комната 1 уро
   - `pop_room_link(room, side)` — связь (side 0=L,1=R,2=U,3=D; 0=нет).
   - `pop_level_start_room/pos/dir()`.
 - `pop_bg.c/.h` — отрисовка тайлов (порт seg008 draw_tile), fore-окклюзия над
-  Kid (`pop_fore_over_kid`, порт set_char_collision+redraw_at_char/char2),
+  Kid (`pop_fore_over_char`, порт set_char_collision+redraw_at_char/char2),
   **loose-полы** (shake/bake/mob).  `draw_tile` — статическая, знает
   `draw_gate_back` (грань гейта из левой комнаты).
 - `pop_kid.c/.h` — анимация Kid (интерпретатор seqtbl `play_seq`, порт seg006),

applications/PoP/docs/host_tests_plan.md

@@ -0,0 +1,142 @@
+# План: модульные тесты движка roomtest под ucsim_z80
+
+Обвязка общая — `testkit/` в корне репозитория (там же объяснение, почему
+прогон именно под z80, а не хостовым gcc). Наборы лежат в
+`../roomtest/tests-host/`.
+
+Задача плана: **перестать чинить одно и то же дважды**. За два прогона
+уровня 1 (2026-08-03) закрыто восемь корней, и часть из них — регрессии
+соседней механики, внесённые предыдущим фиксом. Такие вещи ловятся тестом
+за миллисекунды, а в MAME — часами ручного вождения Кида.
+
+## Что уже есть
+
+| набор | модуль | статус |
+|-------|--------|--------|
+| `t_geom` | `pop_geom.c` | 39 проверок, включая побитовую сверку asm-LCG с 32-битной формулой на 128 шагах |
+
+`pop_geom.c` выбран первым, потому что не тянет ничего за собой. Дальше
+начинаются швы.
+
+## Фаза 1. Два шва (блокирует всё остальное)
+
+### 1.1 Доступ к странице уровня
+
+`pop_level.c` ходит по абсолютным адресам: `gfx_w0_map(lvl_page)`, затем
+разыменование `(uint8_t *)(LVL_DATA_OFF + …)`. В тестовом бинаре это
+обращение в никуда.
+
+Нужен макрос `W0PTR(off)`:
+
+- на таргете — `((uint8_t *)(off))`, то есть ровно как сейчас;
+- в тестах — смещение в обычном массиве-подложке.
+
+Правка механическая и компайл-таймовая, на размер продукта не влияет.
+Заодно снимает магию абсолютных констант из тела функций.
+
+Тестовая подложка должна уметь: загрузить синтетическую комнату (10×3
+байта fg + mod) и целый синтетический уровень на 24 комнаты, чтобы
+проверять межкомнатные вещи.
+
+### 1.2 Журналирующий рендерер
+
+Вместо `pop_bg.c`/`pop_cdraw.c` в тестовый бинарь линкуется модуль с теми
+же прототипами, который **не рисует, а записывает вызовы**: какой тайл
+помечен к перерисовке, каким кодом, с каким счётчиком страниц.
+
+Это не обход проблемы, а самостоятельная ценность: `BUG-GATE-ANIM-1` был
+ровно такой формы — ворота меняли состояние, но пометка на перерисовку не
+ставилась. Проверяется утверждением, а не глазами.
+
+Минимум, который надо перехватывать: `pop_set_redraw`,
+`pop_set_redraw_above`, `pop_loose_mob_spawn`, `pop_gate_redraw`.
+
+## Фаза 2. Регрессионные кейсы из `BUGS_CLOSED.md`
+
+После швов `BUGS_CLOSED.md` превращается в готовую спецификацию: у каждой
+записи есть симптом и ожидаемое поведение. Кандидаты, которые ловятся
+логикой (без отрисовки и без железа):
+
+| баг | что закрепить тестом |
+|-----|----------------------|
+| `BUG-LVLSTATE-1` | запись тайла переживает выход из комнаты |
+| `BUG-RESPAWN-1` | рестарт уровня возвращает ВСЕ тайлы из эталонной копии |
+| `BUG-RESPAWN-2` | рестарт возвращает таблицу стражей; убитый снова жив |
+| `BUG-GATE-ANIM-1` | смена состояния ворот ставит пометку `POP_RD_GATE`; закрывающиеся — на обе страницы, открывающиеся — на одну |
+| `BUG-COLL-1` | `check_collisions` сканирует ряд справа налево и выбирает НАИМЕНЬШУЮ занятую колонку |
+| `BUG-STANDUP-1` | `bumped_floor` у трупа (`alive >= 0`) только выравнивает и не трогает последовательность |
+| `BUG-DEATH-1` | `hitp_curr == 0` при живом Киде переводит его в «умирает» ровно один раз |
+| `BUG-LOOSE-2` | кусок, начавший падать, долетает и кладёт щебень ПОСЛЕ смены комнаты |
+| `BUG-CEIL-2` | loose-плита ряда 2 верхнего соседа живёт как «ряд −1» |
+
+`BUG-LOOSE-2` стоит взять первым: он до сих пор помечен в `BUGS_OPEN.md`
+как непроверенный именно потому, что гонку «уйти из комнаты раньше, чем
+долетит плита» через мост MAME воспроизвести не удалось. На уровне логики
+это несколько строк — заспавнить кусок, сменить комнату, тикать до
+приземления, проверить щебень в данных уровня.
+
+Не берутся (нужна картинка либо железо): `BUG-DOOR-CLIP`, `BUG-CEIL-1`,
+`BUG-CEIL-3`, `BUG-OCCL-1`, `BUG-KBD-4`, `BUG-3`.
+
+## Фаза 3. Сценарные тесты
+
+Сейчас шаг кадра размазан по `main()` в `roomtest.c`. Вынести его в
+`pop_frame_tick()` — тогда появляются тесты вида «поставить Кида в
+известное состояние, скормить N тиков ввода, проверить итог»:
+
+```
+дано:  комната 5, Кид на кнопке (0,6)
+когда: 40 тиков без ввода
+тогда: комната по-прежнему 5, Кид на полу ряда 2
+```
+
+Это тот самый BUG-STANDUP-1, который ловили потиковой трассой в MAME.
+
+Ввод подаётся не через `kbd_raw_down()`, а через подменяемый источник —
+это же даст возможность проигрывать записанные сценарии.
+
+## Фаза 4. Дифф против SDLPoP
+
+`SDLPoP/src/` лежит в дереве, собирается на хосте, и там **уже стоят
+отладочные трассы** (`DBG kidobj tilepos=…` в seg008, `DBG make_loose_fall`
+в seg007). Значит эталон можно заставить печатать потиковую трассу
+автоматически.
+
+Схема: общий формат скрипта ввода и общий формат трассы (тик, frame, x, y,
+room, col, row, action, alive, hp). Гоняем обе реализации, диффим, первое
+расхождение — номер тика и есть баг. Это ровно то, что делалось руками
+через MAME, только бесплатно и повторяемо: `BUG-COLL-1` и `BUG-STANDUP-1`
+такой дифф нашёл бы за секунды.
+
+**Лицензия.** SDLPoP — GPLv3, правило подпроекта — читать и переписывать,
+не линковать. Оракул обязан быть **отдельным исполняемым файлом**,
+общающимся через файлы трасс, а не слинкованным с нашим кодом в один
+бинарь.
+
+Требование к детерминизму: сиды PRNG должны совпадать. У нас
+`POP_PRANDOM_EXACT` даёт ту же последовательность, что в оригинале, и это
+уже закреплено тестом `geom_lcg_matches_reference`.
+
+## Чего эти тесты не поймают
+
+Отрисовку, банки и W-окна, тайминги, клавиатуру — за этим остаётся MAME.
+
+И отдельный класс: **баги порядка вызовов**. Свежий пример — окно
+fore-клипа (`pop_fore_set_clip`) одно на всех, и его ставит каждый, кто
+рисует персонажа; когда порядок «Кид/страж» стал переменным, окно осталось
+стражьим, и Кид нарисовался поверх передних столбов. Это не «функция
+вернула не то», unit-тест такое не видит. Ловится инвариантом,
+вкомпилированным в safe-сборку: «в момент `pop_fore_over_char` окно клипа
+принадлежит Киду». Отдельный инструмент, дополняющий тесты.
+
+## Порядок работ
+
+1. Шов `W0PTR` + подложка уровня.
+2. Журналирующий рендерер.
+3. `BUG-LOOSE-2` — закрыть висящий вопрос.
+4. Остальные кейсы из таблицы фазы 2.
+5. `pop_frame_tick()` + сценарные тесты.
+6. Дифф против SDLPoP.
+
+Правило приёмки: тест не считается написанным, пока не проверен мутацией —
+сломать проверяемое место и убедиться, что набор краснеет.

applications/PoP/docs/ideas_backlog.md

@@ -0,0 +1,91 @@
+# Идеи и вопросы «на подумать» (PoP)
+
+Не план работ, а список того, что осознанно отложено: каждая запись —
+гипотеза с причиной, по которой её стоит проверить, и с тем, что мешает
+сделать это прямо сейчас.
+
+## Зелье «переворот экрана» (upside-down)
+
+**Вопрос пользователя (2026-08-01).**  Тайлы фона у нас лежат строками, а
+кадры Кида/стражей — КОЛОНКАМИ (`transpose_cols` в `pop_pack_kid.py`, ради
+бесплатного горизонтального зеркала).  Значит вертикальный переворот для
+персонажей заметно сложнее, чем для фона.  Верно; но прежде чем это чинить,
+надо знать три факта.
+
+**Факт 1 — когда оно вообще нужно.**  Зелье переворота — тип 4
+(`proc_get_object`, `seg006.c:1885` → `toggle_upside()`).  Скан всех уровней
+по данным (`res200N.bin`, тайл 10 = зелье, тип в backtable): тип 4
+встречается **впервые на уровне 9** (две склянки), и больше нигде.  Тип 3
+(перо, медленное падение) — уровень 7.  То есть **до уровня 9 механика не
+нужна вообще**, и «на первом этапе просто не реализовывать» — не компромисс,
+а точное соответствие данным уровней 1..8.
+
+**Факт 2 — что именно делает оригинал.**  НЕ переворачивает спрайты.
+`flip_screen` (`seg009.c:1042`) → `flip_not_ega` (`seg009.c:1023`) меняет
+местами СТРОКИ готового offscreen-буфера (top↔bottom, порядок пикселей
+внутри строки не трогает — это вертикальное зеркало, не поворот на 180°).
+Вызывается вокруг отрисовки кадра целиком (`seg003.c:296..301`): перевернул
+буфер → дорисовал → перевернул обратно.  Так что в оригинале это
+post-process всего экрана, и вопрос «как перевернуть колоночный спрайт»
+там просто не возникает.
+
+**Факт 3 — почему нам этот приём не подходит как есть.**  У нас нет шага
+«готовый offscreen → экран»: рисуем прямо в видеостраницу, а heal берёт фон
+из ОЗУ-копии этой же страницы.  Переворот всей страницы построчно — это
+320×192 Б копирования КАЖДЫЙ кадр, что мимо бюджета на порядок.
+
+**Варианты, которые надо будет взвесить (не сейчас):**
+1. **Предпечённые перевёрнутые атласы.**  Второй набор кадров
+   Кида/стража, перевёрнутый по вертикали ещё в `pop_pack_kid.py` (там уже
+   есть транспонирование — добавляется одной строкой).  Рантайм: выбор
+   набора + зеркальная арифметика Y.  Память: ещё ~28 страниц EMM при
+   бюджете ~3.3 МБ — не проблема.  Похоже, самый дешёвый по тактам путь.
+2. **Фон рисовать с обратным Y** — для row-major тайлов строка остаётся
+   непрерывным accel-прогоном, меняется только адрес назначения; цена —
+   вызов на строку вместо вызова на тайл.  Померить, прежде чем закладывать.
+3. **Аппаратная помощь** — до проектирования проверить, есть ли у
+   акселератора направление копирования «вниз» (обратный инкремент адреса);
+   если есть, вариант 1 может и не понадобиться.  Смотреть
+   `docs/new/06-accel.md` и `docs/reference/accel_r.txt`.
+
+**Почему не сейчас.**  Уровни 1..8 этого не требуют, а к уровню 9 у нас уже
+будет ответ на вопрос «сколько стоит кадр» (задачи CLIP-1/T-2) — без него
+выбирать между вариантами выше бессмысленно.
+
+## Заменить генератор псевдослучайных чисел
+
+Сейчас стоит LCG оригинала, шаг на ассемблере (~1 020 тактов), бит-в-бит
+совместимый с SDLPoP.  Есть более дешёвые Z80-генераторы (86–148 тактов),
+но потолок выигрыша — 2 814 тактов за кадр, 0.65 %, и он растворяется в
+обёртках вызова.  Тексты процедур, разбор качества и порядок действий —
+`prng_alternatives.md`.  Первый шаг там не про генератор: слить приведение
+к диапазону в ту же asm-процедуру, чтобы на вызов был один `call`, а не три.
+
+## Отключать мышь на время игры
+
+**Гипотеза.** Мышь на Sprinter — источник прерываний (обёртки RST 30h,
+см. memory `mouse_api`).  Игре она не нужна вообще: управление —
+raw-клавиатура (`<kbd_raw.h>`), которую мы и так забираем у DSS целиком.
+Значит каждое мышиное прерывание за кадр — украденные такты в бюджете,
+который у нас и без того занят на 86 %.
+
+**Откуда взялось (2026-07-30).** При замере бюджета по 100 кадрам три
+кадра выбились до 552–647 К тактов (1.28–1.51 кадра) при типичных 371 К.
+Причиной оказалось движение мыши на ХОСТЕ: при неподвижной мыши 225
+кадров подряд прошли без единого превышения.  То есть эффект реальный и
+измеримый, просто в тесте он был наведён извне.
+
+**Что проверить.**
+1. Есть ли у драйвера мыши (RST 30h) функция «выключить/включить» —
+   разобрать список из 14 обёрток; если нет явной, посмотреть, что делает
+   «hide cursor» и снимает ли она обработчик.
+2. Сколько тактов реально стоит одно мышиное прерывание на нашем железе
+   (замер: breakpoint на входе ISR + totalcycles, при движении мыши).
+3. Не ломает ли отключение выход в DSS: состояние обязано
+   восстанавливаться при `exit`, включая аварийный (atexit).
+
+**Почему не сейчас.** Выигрыш проявляется только когда игрок реально
+двигает мышью, то есть в норме его нет; а риск оставить систему без мыши
+после выхода — заметный.  Делать после того, как закроем стражей и
+займёмся бюджетом всерьёз (там же, где батчинг кроссбанковых вызовов и
+возможный возврат `pop_bg` в резидент `--w3`).

applications/PoP/docs/impl_diff.md

@@ -0,0 +1,441 @@
+# Осознанные расхождения с SDLPoP
+
+Правило подпроекта (`../CLAUDE.md`): расхождение нашей реализации с
+`SDLPoP/src/` — по умолчанию **баг у нас**.  Этот файл — список исключений:
+мест, где мы сознательно сделали иначе, потому что платформа/ABI/бюджет
+кадра требуют другого, а НАБЛЮДАЕМОЕ поведение обязано совпадать.
+
+Формат записи: что делает оригинал → что делаем мы → почему → чем платим и
+что проверять при регрессе.  Если запись перестала быть верной (портировали
+дословно, отказались от обхода) — удалять, а не оставлять «для истории»:
+история в git.
+
+---
+
+## D-1. История флагов перекрытия у бокового шва: сдвиг вместо тега комнаты
+
+**Файлы:** `roomtest/pop_map.c` (`pop_coll_shift`, `pop_coll_invalidate`,
+`check_collisions`), `roomtest/roomtest.c` (`enter_room_side`).
+**Связанный баг:** BUG-GATE-PASS-1 (`roomtest/BUGS_CLOSED.md`).
+**Дата:** 2026-08-09.
+
+### Как в оригинале
+
+`check_collisions` (seg004:0004) вместе с `get_row_collision_data`
+(seg004:0185) держит **10 слотов** флагов перекрытия и рядом —
+**параллельный массив номера комнаты**:
+
+```c
+row_coll_flags_ptr[tile_col] = curr_flags;   /* tile_col — колонка ВНУТРИ разрешённой комнаты (0..9) */
+row_coll_room_ptr [tile_col] = curr_room;    /* и номер этой комнаты */
+...
+for (short column = 9; column >= 0; --column) {
+    if (curr_row_coll_room[column] >= 0 &&
+        prev_coll_room[column] == curr_row_coll_room[column]) {
+        if ((prev_coll_flags[column] & 0x0F) == 0 &&
+            (curr_row_coll_flags[column] & 0x0F) != 0)
+            bump_col_left_of_wall = column;
+        ...
+```
+
+Ключ слота — пара **(колонка в своей комнате, номер комнаты)**.  Решётка
+комнаты 8 и до перехода 8→6, и после лежит в слоте 9 с `room = 8`: история
+переживает смену комнаты, переход флага 0→1 виден, `bumped()` срабатывает.
+Комнату оригинал резолвит на лету через `find_room_of_tile` (seg006:005D),
+никакого кэша всех комнат у него нет.
+
+### Что делаем мы
+
+Индекс — **колонка ОТРИСОВАННОЙ комнаты**, диапазон −2…11 (14 слотов,
+`COLL_C0`/`COLL_N`/`COLL_IDX`), номер комнаты рядом не хранится.  При смене
+комнаты тот же физический тайл менял бы слот на ±10, поэтому раньше история
+просто выбрасывалась (`pop_coll_invalidate` → `prev = 3` = «уже
+перекрывал» → бампа нет).  Именно это и был BUG-GATE-PASS-1.
+
+Теперь при **боковом** переходе история не выбрасывается, а
+**перенумеровывается**: `pop_coll_shift(∓10)` сдвигает `coll_curr`,
+`coll_above`, `coll_below` на 10 слотов и заполняет освободившиеся
+тройками.  `enter_room_side` зовёт её сразу после `pop_map_set_edges`.
+
+Корректность держится на том, что `check_leave` двигает `Char.x` ровно на
+∓140 = 10 тайлов по 14 px, и координата грани (`pop_x_bump[col + …]`)
+сдвигается на те же 140 вместе с габаритом Кида, — **сами флаги
+инвариантны**, меняется только номер слота.  Сдвигаются `curr/above/below`,
+а не `prev`: `prev` на следующем кадре всё равно перезапишет
+`move_coll_to_prev`, выбирая источник как раз из этих трёх.
+
+Переходы **вверх/вниз** и все прочие входы в комнату (старт уровня,
+респавн, чит-навигация) остаются на полной инвалидации: там колонки не
+сдвигаются, но тайлы под ними принадлежат другой комнате — история
+действительно недействительна.
+
+### Почему не дословно (вариант A)
+
+Дословный порт — 10 слотов + параллельный массив номера комнаты, индекс по
+колонке разрешённой комнаты, бамп только при совпадении номеров; тогда
+`pop_coll_invalidate` не нужен вовсе, история сама «не совпадает» там, где
+колонка сменила комнату.
+
+Не взяли по одной причине: **десяти слотов нам не хватит**.  Оригинал
+перебирает узкое окно вокруг Кида (от `col(char_x_left_coll) − 1` до
+`col(char_x_right_coll) + 2`), поэтому коллизии слотов у него практически
+не случаются.  Мы держим четырнадцать колонок (−2…11) — при узком окне это
+не мешает, а вот в десять слотов колонки −2/−1 и 8/9 сядут поверх 8/9.
+
+**Окно перебора с 2026-08-09 у нас такое же, как в оригинале** (было: все
+четырнадцать колонок каждый кадр).  Признак годности слота при этом не
+массив номеров комнат, как у оригинала, а ГРАНИЦЫ окна — четыре байта,
+которые `move_coll_to_prev` переносит в `prev` вместе с флагами; сравнение
+идёт по пересечению двух окон.  Очистки массивов нет вовсе, то есть это
+дешевле оригинала, а смысл тот же (у него слот вне окна помечен
+`row_coll_room = −1` и в цикл бампа не попадает).  `check_chomped_flags`
+тоже ограничен окном — иначе протухшие слоты дали бы фантомный перемол.
+
+### Чем платим
+
+- Расхождение структур: если в будущем понадобится знать, из какой комнаты
+  пришёл тайл конкретного слота, этого у нас нет — придётся идти в вариант A.
+- Границы окна надо переносить везде, где переносятся флаги: `pop_coll_shift`
+  двигает и их, `move_coll_to_prev` снимает их в `prev`.  Забыть один из
+  переносов = молча потерять или, наоборот, разрешить лишний бамп.
+- Сдвиг работает только для чисто горизонтальных переходов на ровно 10
+  колонок.  Любая будущая диагональ/иная ширина комнаты его сломает молча.
+- `coll_last_row`: `pop_coll_invalidate` прячет прошлый ряд, чтобы
+  `pop_coll_shift` мог отменить инвалидацию.  Порядок вызовов в
+  `enter_room_side` (сначала `pop_map_set_edges`, потом `pop_coll_shift`)
+  стал значимым.
+
+### Что проверять при регрессе
+
+Это сердце коллизии, вокруг которого разбирался BUG-SEAM-PINGPONG.  После
+любой правки здесь — прогон швов:
+
+1. Уровень 1, комнаты 6 ↔ 8, закрытая решётка, **обе** стороны.
+2. Оба режима подхода: мелким шагом (упереться) и с разбега (не пройти
+   насквозь).
+3. Проверить, что пинг-понг у шва не вернулся (экран не перескакивает
+   туда-сюда на кадре бампа о ворота).
+4. `make -C roomtest/tests-host` — наборы `t_wall`/`t_char` ходят по этой же
+   геометрии.
+
+---
+
+## D-2. Кнопка в шве: перерисовываем, хотя оригинал не перерисовывает
+
+### Что делает оригинал
+
+Тайл-«трансформер» (кнопка, ворота, пика) перерисовывается только если он в
+ОТРИСОВАННОЙ комнате: `redraw_11h` → `redraw_tile_height` →
+`get_trob_pos_in_drawn_room` (seg007:0258), а та для `trob.room != drawn_room`
+возвращает 30 — заведомо несуществующий tilepos, то есть «не рисовать».
+Исключение сделано ровно одно — факелы (`animate_torch`, seg007:03CF, ветка
+`trob.room == room_L && tilepos % 10 == 9`).
+
+Кнопка соседа слева при этом ВЛИЯЕТ на картинку: `get_tile_to_draw`
+(seg008:253) подменяет нажатый `tiles_15_opener` на `tiles_1_floor`, а
+`load_leftroom` (seg008:360) кладёт результат в `leftroom_[row]`, откуда он
+приходит в `draw_tile` как `tile_left`.  У пола правая грань есть, у кнопки
+нет — значит в оригинале нажатие кнопки, видимой через левый шов, меняет
+картинку только при следующей ПОЛНОЙ отрисовке комнаты.
+
+### Что делаем мы
+
+Перерисовываем шов сразу: `seam_row_sig` (roomtest.c) подмешивает в сигнатуру
+ряда бит «кнопка нажата» (`pop_doorlink2(mod) & 0x1F > 1`) для тайлов
+`0x0F`/`0x06`, и change-driven редрой `pop_room_redraw_seam_left` срабатывает
+на нём так же, как на openness ворот.
+
+### Почему
+
+Голый порт давал видимый залип (SEAM-BUTTON-STALE, roomtest/BUGS_CLOSED.md): кнопка
+(1,9) комнаты 11 — она же (1,−1) комнаты 24 — оставалась нарисованной в том
+состоянии, в каком была на входе в комнату, хотя связь срабатывала.  Сигнатура
+шва следила только за `room_modif`, а у кнопки `modif` — это ИНДЕКС LINKLOC,
+константа уровня: нажатие живёт в `doorlinks2` и в сигнатуру не приходило
+никогда.  Добавить кнопку в сигнатуру — те же три сравнения на кадр, что уже
+делались для ворот; воспроизводить артефакт оригинала смысла нет.
+
+### Чем платим
+
+- Резидент +200 Б (`_CODE` 24 739 → 24 939), куча W2 1795 → 1595 Б.  Если
+  станет тесно — `seam_row_sig` переносится в банк 7 к
+  `pop_room_redraw_seam_left`, ценой одного трамплина на кадр.
+- Сигнатура ряда стала разнотипной: для кнопки это булев бит, для остальных
+  тайлов — modif.  Значения между собой не сравниваются (сравнивается только
+  ряд сам с собой), но при добавлении нового типа тайла в шов про это надо
+  помнить.
+
+### Что проверять при регрессе
+
+Уровень 5, кнопка нижних ворот комнаты 24 (она же (1,9) комнаты 11), оба
+направления: нажать её из комнаты 11 и войти в 24; и наоборот — войти в 24
+поверху и наступить на неё, стоя в шве.  Картинка кнопки обязана совпадать
+со статусом ворот в обоих случаях.
+
+---
+
+## Перо (медленное падение) ловит ТОЛЬКО Кида
+
+**Оригинал** (`fall_accel`, seg006:057C): `is_feather_fall` — глобальный флаг,
+и медленное падение достаётся ЛЮБОМУ персонажу, который окажется в `Char`,
+пока эффект жив.  То есть страж, сошедший с уступа в те же секунды, парит
+вместе с Кидом, хотя зелье пил не он.  SDLPoP считает это багом и чинит
+опцией `fix_feather_fall_affects_guards`.
+
+**Мы** берём поведение С ФИКСОМ: `pop_feather` проверяется вместе с
+`Char.charid == CHARID_0_KID` — и в `fall_accel` (`pop_map.c`), и в опкоде
+`JMP_IF_FEATHER` интерпретатора seqtbl (`pop_kid.c`), чтобы физика и анимация
+не разъехались.
+
+**Чем платим.**  Сцена, где страж падает при живом пере, будет выглядеть иначе,
+чем в DOS-оригинале (у нас он падает нормально, там — парит).  На уровне 7,
+единственном с этим зельем, такой сцены нет: зелье в комнате 1, стражи — в
+других комнатах.
+
+**Что проверять при регрессе.**  Уровень 7: выпить зелье в комнате 1, тут же
+столкнуть стража в провал — он обязан падать БЫСТРО, а Кид рядом — медленно.
+
+---
+
+## Синее зелье («−HP») не ставит свою вспышку
+
+**Оригинал** (`proc_get_object`, seg006:1892): ветка `case 5` только глушит
+звуки, играет `sound_13_kid_hurt` и ставит `hitp_delta`.  Экран краснеет не
+здесь, а общим механизмом «Кид ранен» (`flash_if_hurt`, seg003:0AFC).
+
+**Мы** раньше ставили в этой ветке ещё и `pop_flash_*` (красную вспышку на 2
+кадра) — то есть красили экран дважды: своей вспышкой и кадром урона.
+Приведено к оригиналу: ветка правит только `hitp_delta`, краснеет `pop_kid_hurt`.
+
+**Что проверять при регрессе.**  Уровень 2, комната 13, зелье `(1,3)`: выпить —
+HP убавляется на единицу, экран краснеет РОВНО один раз (без двойного строба).
+
+---
+
+## Переворот (зелье инверсии) применяется НА ГРАНИЦЕ КАДРА, а не мгновенно
+
+**Оригинал** (`toggle_upside`, seg000:15E9): `upside_down = ~upside_down` и
+`need_redraw_because_flipped = 1` — флаг переключается прямо в момент глотка,
+то есть в середине кадра.  Оригиналу это ничего не стоит: он ВСЕГДА рисует в
+offscreen неперевёрнутым, а зеркалит только при выводе на экран
+(`flip_screen` вокруг `copy_screen_rect`, seg000:939/946).  Внутренние
+координаты у него от переворота не зависят вообще.
+
+**Мы** offscreen-буфера не имеем (две видеостраницы + теневая ОЗУ-копия на
+каждую), поэтому рисуем зеркально сразу — переворот «зашит» в координаты
+каждого слоя.  Из-за этого момент переключения важен: зелье выпивается из
+`play_seq`, то есть в СЕРЕДИНЕ кадра, и остаток кадра рисовался бы уже
+зеркально поверх ещё неперевёрнутого фона.  Хуже всего пламя факела — оно
+ЗАПЕКАЕТСЯ в ОЗУ-копию (`pop_torch_draw`, у него нет heal: каждый следующий
+кадр непрозрачно накрывает предыдущий).  Кадр пламени, положенный в
+зеркальную позицию на старом фоне, оставался там навсегда — по комнате
+рассыпались лишние языки огня.
+
+Поэтому у нас два флага: `pop_upside_want` (пишут зелье, смерть Кида, чит U)
+и `pop_upside` (читают все слои отрисовки).  Переключение — ровно одно место,
+начало кадра, вместе с перерисовкой: главный цикл делает
+`pop_upside = pop_upside_want` и зовёт `pop_flip_screen`.
+
+Сама перерисовка при этом СОВПАДАЕТ с оригиналом: там на
+`need_redraw_because_flipped` вызывается `redraw_screen(0)` — полная
+отрисовка, а не отражение уже нарисованного.  У нас то же самое —
+`pop_flip_screen` рисует комнату заново (и получает чистый фон по
+построению), а вторую страницу дабл-буфера отдаёт копией акселератора.
+
+**Что проверять при регрессе.**  Уровень 9: выпить зелёное зелье — картинка
+переворачивается ровно один раз, лишних языков пламени по комнате нет.  Чит
+U даёт тот же результат (он идёт тем же путём).
+
+---
+
+## Окклюзия воротами: спрашиваем про рисуемого персонажа, а не жёстко про Кида
+
+**Оригинал** (`draw_tile_fore`, seg008:0D15) первой строкой:
+
+```c
+if (tile_left == tiles_4_gate && Kid.curr_row == drawn_row &&
+    Kid.curr_col == drawn_col - 1 && Kid.room != room_R)
+        draw_gate_fore();
+```
+
+То есть бары ворот попадают в foretable — поверх всего нарисованного — когда
+на тайле ворот стоит **именно Кид**.  Это следствие устройства оригинала:
+foretable ОДНА на весь проход тайлов, персонажи в неё уже добавлены, и
+отдельного «переднего слоя на персонажа» там нет.
+
+**Мы** ради скорости не рисуем foretable целиком, а возвращаем куски тайлов
+поверх ТОЛЬКО в прямоугольнике персонажа (`pop_fore_over_char`, см. memory
+`pop_fore_layer_cost`: полный проход стоил 78 % кадра).  Проход идёт по
+персонажу, значит и вопрос естественно задавать про него —
+`pop_gate_over_char(ch)`, а не про глобального `Kid`.
+
+**Чем платим.**  Наш вариант — надмножество оригинального: страж (или тень),
+стоящий в проёме ворот, у нас уходит ЗА решётку, а в оригинале остался бы
+нарисованным поверх неё, пока на том же тайле нет Кида.  Визуально это
+правильнее, но формально расхождение.  Обратной разницы нет: во всех случаях,
+где оригинал рисует бары поверх, рисуем и мы.
+
+**Что проверять при регрессе.**  Уровень 10, комната 7, тайл (2,6): Кид,
+стоящий в проёме ворот, виден ЗА прутьями.  Решение покрыто хост-тестами
+(`tests-host/t_char.c`, набор `char_gate_*`) — отрисовка в харнесс не
+линкуется, поэтому проверяется предикат.
+
+---
+
+## Тень рисуется спрайтами КИДА, а не XOR-силуэтом
+
+**Файлы:** `roomtest/pop_cdraw.c` (выбор набора атласов по `charid`/`frame`).
+**Дата:** 2026-08-18 (решение принималось раньше, записано здесь).
+
+**Оригинал** рисует тень тем же кадром Кида, но ДВАЖДЫ — вторым проходом со
+сдвигом на один пиксель и через XOR.  Получается тёмный силуэт с контуром,
+а не «второй Кид».
+
+**Мы** рисуем тень обычными спрайтами Кида, обычным блиттером — она выглядит
+как Кид.
+
+**Почему.**  Приём оригинала — read-modify-write по уже нарисованному, а
+читать данные из ВИДЕО-ОЗУ (там, где спрайты) на Sprinter нельзя: читается
+только ОЗУ-копия.  Блочный XOR у акселератора есть и работает как раз по
+ОЗУ-копии, но с нашей прозрачностью он несовместим: прозрачность сделана
+подавлением записи 0xFF, а XOR прозрачные пиксели тоже смешает — под него
+нужен набор с прозрачным 0x00 (замер: memory `accel_block_ops`,
+`sprinter_vram_transparency`).  То есть «сделать как в оригинале» всё равно
+упирается в отдельный набор спрайтов.
+
+**Чем платим.**  Тень визуально неотличима от Кида (уровни 4/5/6/12).  На
+механику не влияет: слот, окна `Char`, ИИ и коллизия у тени свои и от
+картинки не зависят.
+
+**План.**  Отдельный АТЛАС ТЕНИ (готовый силуэт), а не воспроизведение
+XOR-прохода: один набор спрайтов вместо второго пути блита.  До тех пор
+расхождение сознательное — багом не заводить.
+
+**Что проверять при регрессе.**  Уровень 6 комната 1: тень стоит слева
+через провал, поза совпадает с позой Кида-в-стойке.  Родственная запись —
+«Слияние с тенью» ниже.
+
+---
+
+## Слияние с тенью: мигания Кида спрайтами тени нет
+
+**Файлы:** `roomtest/guards.c` (`autocontrol_shadow_level12`),
+`roomtest/pop_cdraw.c`.
+**Дата:** 2026-08-13.
+
+**Оригинал** (`draw_objtable_item`, seg008:20CA) во время вспышки слияния
+(`united_with_shadow` считает 42 → 0) рисует КИДА как тень на чётных
+значениях счётчика: тот же кадр уходит не обычным прозрачным блиттером, а
+парой OR+XOR со сдвигом на пиксель.  Получается мерцание «Кид/тень»
+примерно полторы секунды.
+
+**Мы** рисуем всё это время обычного Кида, а само событие обозначаем белой
+вспышкой фона (`pop_flash_color = POP_FLASH_WHITE`, 18 кадров) — она в
+оригинале тоже есть и ставится тем же кодом.
+
+**Почему.**  У нас Кид и соперник рисуются из РАЗНЫХ атласов своими
+палитрами (`pop_cdraw.c`), а «тень» — это персонаж слота Guard с палитрой
+комнаты; блиттеров OR/XOR в libbgi нет вовсе, прозрачность сделана
+0xFF-подавлением записи.  Воспроизвести эффект — значит завести Киду второй
+набор спрайтов и второй путь блита ради 42 кадров за всю игру.
+
+**Чем платим.**  Момент слияния читается только по вспышке и по тому, что
+тень исчезла, — без «двоящегося» силуэта.  На механику не влияет: счётчик
+`pop_united_shadow` тикает и уходит в −1 независимо от отрисовки, а от него
+зависят и повторный подъём тени, и появление плит в комнатах 2/13.
+
+**Что проверять при регрессе.**  Уровень 12: после слияния экран белеет,
+соперник пропал, HP-потолок вырос на единицу, тень в комнате 15 больше не
+появляется.  Логика покрыта `tests-host/t_shadow.c`.
+
+---
+
+## Отложенный старт падающих плит (уровень 13): фаза 0 у нас «не анимируется»
+
+**Файлы:** `roomtest/pop_map.c` (`pop_check_fall_flo`, `pop_loose_tick`),
+`roomtest/pop_trob.c` (`animate_loose`).
+**Дата:** 2026-08-13.
+
+**Оригинал** (`check_fall_flo`, seg000:1317) раздаёт шести плитам ряда 2
+верхней комнаты модификатор `−(prandom(0xFF) & 0x0F)`, то есть 0..−15, и
+заводит на каждую trob.  Фаза считает вверх, проходит ноль и дальше идёт
+обычным отсчётом до провала — плита падает через `n + 11` кадров.  Ноль там
+безопасен: плиту держит в игре СПИСОК trob, а не значение модификатора.
+
+**Мы** списка trob для loose текущей комнаты не держим — плита анимируется
+ровно тогда, когда её фаза не ноль (`pop_loose_modif[pos] != 0`).  Значит
+счёт, дойдя до нуля, оборвался бы навсегда.  Компенсируем двумя правками,
+которые работают только в паре:
+
+* тик перескакивает ноль (`if (m == 0) m = 1`);
+* стартовое значение берётся на единицу «отрицательнее» (`−n−1`).
+
+**Чем платим.**  Ничем в наблюдаемом поведении: суммарная задержка остаётся
+`n + 11` кадров, проверено арифметикой на обоих концах диапазона (n = 0 и
+n = 15).  Платим связностью — две правки в разных функциях, и убрать любую
+одну нельзя.
+
+**Что проверять при регрессе.**  Уровень 13, вход в комнату 23 (она же
+стартовая): плиты сверху сыплются ВРАЗНОБОЙ, а не разом и не «никогда».
+Логика покрыта `tests-host/t_jaffar.c`
+(`jaffar_negative_phase_counts_through_to_fall` и парный контроль на другом
+уровне).
+
+---
+
+## Чит навигации по комнатам не запускает бесшовный переход уровня
+
+**Файлы:** `roomtest/roomtest_cold.c` (`pop_dbg_roomnav`), `roomtest/roomtest.c`,
+`roomtest/pop_state.c` (`pop_nav_hold`).
+**Дата:** 2026-08-13.
+
+**Оригинал** (`play_level_2`, seg000:0900) проверяет `Kid.room == 23` КАЖДЫЙ
+кадр: уровень 12 кончается самим фактом присутствия Кида в комнате 23, двери
+у него нет.  Никакого «как он туда попал» там нет и быть не может —
+телепорта между комнатами в игре 1989 года не существует.
+
+**Мы** держим этот триггер, пока Кид попал в комнату ЧИТОМ навигации
+(`+`/`−`), и отпускаем на первой же смене комнаты обычным ходом.
+
+**Почему.**  Чит перебирает комнаты ПО НОМЕРУ (1..24 с обёрткой), то есть
+любой обход уровня 12 неизбежно наступает на 23-ю — и уровень молча
+становится 13-м.  Поймано на первом же прогоне 2026-08-13: проверяющий час
+смотрел «комнату 20 уровня 12», которая на самом деле была комнатой 20
+уровня 13, и сравнивал её с картой не того уровня.  Комнату 23 уровня 12
+читом не посмотреть в принципе.  Это ровно та же болезнь чит-телепорта, что
+BUG-CHEAT-FIGHT-1 (выход из боя), и лечится там же.
+
+**Чем платим.**  Ничем в игре: в обычном прохождении Кид входит в комнату 23
+ногами, флаг снят, переход срабатывает как в оригинале.  Расхождение видно
+ТОЛЬКО при включённых читах.
+
+**Что проверять при регрессе.**  Уровень 12: пройти в комнату 23 ногами —
+уровень меняется на 13-й без заставки и без сброса HP.  Обойти уровень
+читом `+` через 23-ю — уровень НЕ меняется.
+
+---
+
+## Чит «убить стража» (K) идёт через штатный путь смерти
+
+**Файлы:** `roomtest/pop_guard.c` (`pop_guard_kill`).
+**Дата:** 2026-08-13.  Решение пользователя.
+
+**Оригинал** (seg000:786) ставит `guardhp_delta = -guardhp_curr` И
+`Guard.alive = 0`.  А гейт события смерти в `play_guard` (seg006:1490)
+требует `Char.alive < 0` — то есть у оригинала чит убивает стража В ОБХОД
+`on_guard_killed`.  На 13-м уровне это заметно: победа над Джафаром по читу
+не ставит `leveldoor_open = 2`, и выход на 14-й не открывается.
+
+**Мы** `Guard.alive` в чите не трогаем: применённая дельта обнуляет HP, и
+`play_guard` сам переводит стража в «умирает», вызвав `on_guard_killed` —
+брызги, вспышка, флаг выхода.  То есть чит даёт ровно «как будто убил Кид».
+
+**Почему.**  Отладочный прогон 13-го уровня иначе требует каждый раз честно
+выигрывать бой с Джафаром (skill 9, 6 HP) — это дорого по времени, а
+проверять надо совсем другое.
+
+**Чем платим.**  Ничем в игре: читы включаются флагом `pop_cheats`, в
+релизной сборке они выключены.  Расхождение наблюдаемо только с читами.
+
+**Что проверять при регрессе.**  Уровень 13: `K` на Джафаре → белая вспышка,
+уход ВЛЕВО открывает дверь уровня.  Честная победа в бою даёт то же самое.

applications/PoP/docs/l9_invert_plan.md

@@ -0,0 +1,428 @@
+# L9-INVERT — план реализации зелья переворота (уровень 9)
+
+Рабочий план, по которому задача делается с чистого контекста.  Доска —
+[`../roomtest/TASKS_OPEN.md#l9-invert`](../roomtest/TASKS_OPEN.md); правила
+подпроекта — `../CLAUDE.md` (SDLPoP = источник истины, диагноз железа —
+только артефактом).
+
+## 0. Что и зачем
+
+Зелья типа 4 на уровне 9 (комната 7 тайл `(1,7)`, комната 10 тайл `(0,4)`)
+переворачивают картинку вверх ногами.  В оригинале это `toggle_upside()`
+(seg000:15E9): `upside_down = ~upside_down`, `need_redraw_because_flipped = 1`.
+Больше зелье не делает НИЧЕГО — ни вспышки, ни урона (seg006:1885, ветка
+`case 4`).  Снимается: смертью Кида (seg000:1224, при `alive >= 0`) и стартом
+уровня (seg003:38/188).  Управление НЕ инвертируется.  Второе зелье
+переворачивает обратно.
+
+Оригинал переворачивает готовый offscreen на выводе (`flip_screen` перед
+копированием прямоугольников на экран, seg000:939/946).  Нам этот путь
+закрыт: страниц ровно две (`gfx_set_visible_page` → ESTEX $54 SELPAGE, бит 0),
+рабочей третьей нет.  Поэтому:
+
+- **уже нарисованное** переворачиваем ОДИН РАЗ построчной копией
+  акселератора (решение пользователя 2026-08-12);
+- **всё, что рисуется дальше**, рисуем зеркально: фон (row-major) — новыми
+  vflip-блитами, персонажи (column-major) — заранее подготовленными
+  зеркальными кадрами.
+
+Полоса HP и лейбл комнаты живут в борту (`y = 194 + POP_YOFF`, поле —
+`POP_PLAYFIELD_H = 192`) и не переворачиваются, как и в оригинале.
+
+---
+
+# Часть I — libbgi
+
+## I.0 РАЗВЕДКА ЖЕЛЕЗА — ЗАКРЫТА 2026-08-12
+
+**Оба факта подтверждены, ядро и обёртка написаны и проверены в MAME**
+(`tests/pageflip`, 5/5 PASS — прямая копия, vflip, целость рамки, широкая
+копия 320 = два прохода, неприкосновенность источника).
+
+- **Р1 подтверждён**: Port_Y можно менять между read- и write-триггером,
+  если ПЕРЕД вторым OUT стоит STOP (`LD B,B`) — он разоружает accel, и fetch
+  immediate-операнда OUT уже безопасен.  Приём не новый: ровно так работает
+  `_bgi_scroll_cols_raw` (ядро `gfx_scroll_v`), то есть он был в проде
+  задолго до этой задачи — указал пользователь.  Значит и обходной путь
+  через ОЗУ-буфер не нужен;
+- **Р2 подтверждён**: обе страницы адресуемы одновременно, копия между ними
+  идёт по разнице баз (`_gfx_addr_shadow_base` / `_gfx_addr_base`), строку
+  выбирает Port_Y.
+
+Сделано: `libbgi/bgi256/_bgi_flip_rows_raw.c` (ядро) +
+`libbgi/common/gfx_copy_page.c` (обёртка, режимы `GFX_COPY_DIRECT` /
+`GFX_COPY_VFLIP`) + `tests/pageflip`.  Пункты I.1 и I.3 ниже — ЗАКРЫТЫ этим
+же коммитом; описание оставлено как контракт.
+
+### Исходный текст разведки (для истории)
+
+Два факта, на которых стоит вся схема, сейчас НЕ подтверждены артефактом.
+Пока их нет, остальные пункты не начинать (memory `defer_unexplained_quirks`).
+
+**Р1. Смена Port_Y между burst-чтением и burst-записью.**  Схема требует:
+армировать копию, `LD A,(HL)` (burst-чтение строки src), сменить Y,
+`LD (DE),A` (burst-запись в другую строку).  Между триггерами НЕЛЬЗЯ
+выполнять инструкции, читающие ОПЕРАНД из памяти — fetch операнда
+перезабивает буфер акселератора кодом (memory `accel_operand_fetch_retrigger`).
+Значит:
+
+- смена порта — только `out (c),a` (ED 79, регистровая форма); `out (#89),a`
+  (D3 89) читает immediate байт и УБЬЁТ буфер;
+- новое значение Y — только из регистра (`ld a,d`), не `ld a,#n` и не из
+  памяти;
+- `C` = 0x89 и оба значения Y должны лежать в регистрах ДО триггера чтения.
+
+Проверка: `tests/accflip` по образцу `tests/accop` — заполнить строку
+источника известным паттерном, скопировать в другую строку со сменой Y,
+прочитать VRAM побайтно и сравнить.  Отрицательный результат — стоп-сигнал:
+переворот придётся делать через промежуточный ОЗУ-буфер (строка 320 Б), и
+бюджет вырастет примерно вдвое.
+
+**Р2. Адресация двух страниц в одном окне W3.**  `gfx.h` утверждает, что
+страница 1 «начинается на 320 байт дальше (0xC140)», но это комментарий, а не
+замер.  Нужно снять дампом: как адрес строки складывается из Port_Y и
+смещения в окне, и видны ли обе страницы одновременно.  От ответа зависит,
+делается ли копия A→B одним проходом или через смену видеобанка.
+
+Итог разведки записать в `libbgi/docs` (или `docs/new/06-accel.md`
+дополнением) и в memory — это знание переиспользуется во всех будущих
+экранных эффектах.
+
+## I.1 Ядро копии с реверсом Y
+
+`libbgi/bgi256/_bgi_copy_rows_raw.c` умеет только ИНКРЕМЕНТ Port_Y на строку
+(`y0` + шаг вперёд; страйды патчатся SMC при входе).  Нужен вариант, где
+одна сторона идёт вниз, другая вверх.
+
+- предпочтительно: новый leaf `_bgi_flip_rows_raw.c` (правило «1 функция =
+  1 модуль»), а не флаг в существующем — горячий путь блиттера трогать не
+  надо, и DCE не потащит лишнего в программы без переворота;
+- вход тот же (`__sdcccall(1)`: src→HL, dst→DE, дальше стек), плюс
+  `y0_src` / `y0_dst` и признак направления;
+- DI-окно — одна строка, как в остальных ядрах (арминг в каждой скобке:
+  в окне EI между чанками CBL-ISR армирует акселератор своим размером,
+  см. `docs/accel-fill-budget.md`).
+
+## I.2 Публичные vflip-блиты для row-major — СДЕЛАНО 2026-08-12
+
+Ассемблера не потребовалось вовсе: у row-major картинки вертикальное
+зеркало — это порядок строк, а он задаётся ЗНАКОМ src-страйда, который
+`_bgi_blit_rows_raw` и так принимает знаковым (`int sstride`) и патчит SMC
+в adc-цепочку.  Обёртки просто дают адрес ПОСЛЕДНЕЙ строки и `-stride`,
+цена кадра та же, что у обычного блита.
+
+Написаны `gfx_blit_noclip_vflip`, `gfx_blit_part_noclip_vflip`,
+`gfx_blit_part_vflip`; `tests/pageflip` расширен до 8 проверок, все PASS.
+
+Грабли, которые поймал тест: у клипающего варианта первая строка источника
+обязана считаться от высоты ДО клипа (`h0`), иначе обрезка сверху экрана
+сдвигает картинку — сначала формула брала уже укороченную `h`.
+
+### Контракт (исходное описание)
+
+Все row-major блиты приложения идут ровно через три функции (`pop_tile.c:281`,
+`:283`, `:286`, `:325`, `:327`):
+
+| есть | нужен vflip-двойник |
+|---|---|
+| `gfx_blit_noclip` | `gfx_blit_noclip_vflip` |
+| `gfx_blit_part_noclip` | `gfx_blit_part_noclip_vflip` |
+| `gfx_blit_part` (с клипом) | `gfx_blit_part_vflip` |
+
+Семантика: `(x,y)` — левый ВЕРХНИЙ угол результата на экране (как у обычных
+блитов), строки источника выводятся снизу вверх.  Это позволяет вызывающему
+не менять арифметику позиции, а только пересчитать `y` под поле.
+
+`gfx_blit_cols*` (column-major) vflip-двойников НЕ получают: реверс идёт
+внутри колонки, а accel копирует блок только вперёд.  Для персонажей —
+часть II.4.
+
+`gfx_heal*` не трогаем: heal симметричен, он восстанавливает прямоугольник из
+ОЗУ-копии по экранным координатам, а координаты вызывающий уже даёт
+перевёрнутые.
+
+Тест: `tests/blitvflip` — эталонный спрайт, побайтная сверка VRAM.
+
+## I.3 Копия прямоугольника экран→экран
+
+```c
+#define GFX_COPY_DIRECT  0
+#define GFX_COPY_VFLIP   1
+void gfx_copy_rect(uint8_t src_page, int sx, int sy,
+                   uint8_t dst_page, int dx, int dy,
+                   uint16_t w, uint16_t h, uint8_t mode);
+```
+
+- `w > 256` режется на burst'ы вызывающим ядром (320 = 160+160 либо 256+64 —
+  выбрать по замеру, разницы в тактах на строку почти нет);
+- **горизонтального флипа не будет**: accel копирует блок только вперёд,
+  побайтовый реверс дал бы 320 burst'ов на строку вместо двух.  Если он
+  когда-нибудь понадобится — только через ОЗУ-буфер с CPU-реверсом;
+- клип не нужен (вызывающий гарантирует границы), но проверка «прямоугольник
+  в пределах экрана» в safe-варианте библиотеки — обязательна.
+
+Тест: `tests/pagecopy` — прямой режим и VFLIP, побайтная сверка.
+
+## I.4 Чего в списке пользователя не хватало
+
+1. **Размерный регресс**: после каждого шага `make size-check`; новые модули
+   не должны утянуть за собой рост в программах, которые их не зовут (проверка
+   на `examples/` и `tests/`).
+2. **Обе сборки библиотеки** — fast и safe (`sprinter-cc --safe`): гарды
+   параметров в safe, критичные — в обеих.
+3. **Документация**: `docs/sprite-api-design.md` (раздел про блиттер),
+   `docs/TODO.md`, справочник API; факты разведки I.0 — в `docs/new/06-accel.md`.
+4. **IM2/CBL**: длинные серии коротких DI-окон не должны ломать кадровые
+   прерывания и клавиатуру — проверить `tests/kbdpoll`-сценарием после
+   внедрения (клавиатура вычерпывается idle-хуком, а переворот идёт вне
+   ожидания кадра).
+5. **Порядок «страница ↔ ОЗУ-копия»**: копия должна идти банком
+   `GFX_BANK_NORMAL`, иначе перевёрнутый фон не попадёт в ОЗУ-копию и heal
+   начнёт восстанавливать старую картинку.  Это ключевой инвариант всей
+   схемы — вынести отдельным утверждением в тест.
+
+---
+
+# Часть II — приложение (roomtest)
+
+## II.1 Состояние и момент переключения — СДЕЛАНО 2026-08-12
+
+Проверено в MAME (уровень 9, комната 7): нажатие чита переворачивает всю
+комнату целиком за один кадр, повторное — возвращает.  Персонажи и
+анимируемые тайлы (факелы) пока рисуются НЕ зеркально — это шаги II.3/II.4.
+
+Что появилось:
+
+- `pop_upside` + `pop_upside_dirty` (порт `upside_down` и
+  `need_redraw_because_flipped`) в `pop_map.c`;
+- ветка `case 4` в `pop_proc_get_object`: только тоггл, без вспышки и урона
+  (как seg006:1885);
+- сброс в `pop_start_level` (seg003:38/188) и по смерти Кида (seg000:1224);
+- `pop_flip_screen()` в банке 8: `gfx_copy_page(VFLIP)` в скрытую страницу →
+  показать её → `gfx_copy_page(DIRECT)` во вторую → инвалидация слотов
+  персонажей, метки «фон трогали» и полосы HP;
+- **чит-клавиша U** — это ПОРТ, а не костыль: в оригинале переворот тоже
+  висит на чит-клавише (seg000:0793).  Без неё эффект проверяется только
+  честным проходом уровня 9 до комнаты 7 — чит-телепорт до зелья не
+  дотягивается (оно на `(1,7)`, а навигация ставит Кида на нижний ряд).
+
+Цена: резидент +602 Б (новые функции libbgi линкуются в него), куча
+1707 → 1050 Б.  Это аргумент за [MEM-COLD2](../roomtest/TASKS_OPEN.md#mem-cold2)
+до начала II.4.
+
+### Контракт (исходное описание шага)
+
+- `pop_upside` (uint8_t) — рядом с `pop_feather` в `pop_map.c`, экспорт в
+  `pop_map.h`;
+- тоггл — в `pop_proc_get_object`, ветка `potion_type == 4` (сейчас там TODO,
+  как было у пера).  Ничего кроме тоггла: ни вспышки, ни звука — так в
+  оригинале;
+- сброс: `pop_start_level` (уже переехал в `roomtest_cold.c`) и смерть Кида —
+  по образцу seg000:1224 (в `kid_phys`/там, где ловится `alive >= 0`);
+- переключение (функция `pop_flip_screen()`, банк 8 — холодный код):
+  1. `gfx_copy_rect(front, …, back, …, GFX_COPY_VFLIP)` — скрытая страница
+     получает перевёрнутый чистый фон (accel читает ОЗУ-копию, персонажей в
+     ней нет);
+  2. флип страниц, чтобы игрок сразу увидел результат;
+  3. `gfx_copy_rect(new_front, …, new_back, …, GFX_COPY_DIRECT)` — вторая
+     страница дабл-буфера получает то же;
+  4. инвалидация: `pop_cd[].valid = 0` для обоих слотов, `pop_mirror_heal`
+     -состояние, `pop_hp_invalidate()`, метки «фон трогали» (`pop_cd_touch`)
+     на обе страницы, `seam_sig` — чтобы шов перерисовался.
+
+## II.2 Геометрия — единая точка пересчёта
+
+```c
+/* pop_bg.h рядом с POP_YOFF/POP_PLAYFIELD_H */
+#define POP_FLIP_Y(y, h)  (2 * POP_YOFF + POP_PLAYFIELD_H - (y) - (h))
+```
+
+Применяется ТОЛЬКО к тому, что внутри поля.  Правило: любая функция,
+получающая экранный `y`, либо сама зеркалит его по флагу, либо принимает уже
+зеркальный — смешивать нельзя, иначе получим двойной переворот (это самый
+вероятный класс багов здесь).  Решение: зеркалит ВЫЗЫВАЮЩИЙ, у примитивов
+семантика не меняется.
+
+## II.3 Фон — СДЕЛАНО 2026-08-12
+
+Флаг проведён в ЕДИНСТВЕННУЮ точку — `pop_blit_b`/`blit_b_clip`
+(`pop_tile.c`): позиция пересчитывается макросом `FLIP_TOP` (он один на весь
+слой — дублировать нельзя, иначе двойной переворот), а блит выбирает
+vflip-двойник.  Тем самым зеркалятся и полная отрисовка комнаты, и точечные
+редрои, и анимации trob, и fore-слой, и кладка — все они ходят через эту
+функцию.
+
+Тонкость клипованного пути: при зеркале обрезка СВЕРХУ экрана съедает
+НИЖНИЕ строки источника, поэтому кусок пересчитывается как
+`sy' = h - sy - dh`.
+
+Проверено в MAME (уровень 9, чит U): комната перевёрнута целиком — пол
+вверху, дверь уровня и кладка вверх ногами.  Персонажи пока обычные (II.4).
+
+Цена: три функции libbgi ушли в резидент, куча 1574 → 450 Б, поэтому тем же
+заходом сделан **MEM-COLD2 п.1** — `enter_room_side`/`enter_room` уехали в
+банк 8 (куча вернулась к **1231 Б**, банк занят на 14.6%).  Рабочие массивы
+комнаты остались в `_DATA` и видны обеим половинам; `enter_room` обязана быть
+`__banked` — её зовёт главный цикл.
+
+### Контракт (исходное описание)
+
+Одна точка: `pop_tile.c` (блит куска атласа) выбирает vflip-двойник по
+`pop_upside` и пересчитывает `y`.  Тогда автоматически попадают:
+
+- полная отрисовка комнаты (`pop_room.c`);
+- точечные редрои (`pop_redraw.c`: ворота, пики, кнопки, дверь уровня,
+  дрожащие плиты);
+- анимации `pop_trob` (факелы, пузырьки зелий);
+- fore-слой и оверлеи кромки, кладка стены (`pop_bg.c`);
+- падающие куски loose (`pop_room.c`, `pop_loose_mob_*`).
+
+Проверить отдельно: `wall_pattern` (кладка рисуется своей геометрией) и
+оверлеи кромки — у них позиция считается от ряда, а не от `y` спрайта.
+
+## II.4 Персонажи (column-major)
+
+Нужны зеркальные кадры: 34 атласа, 228 563 Б (kid0..27 + sword, guard g0..g4).
+
+- реверс колонки — через стек (`pop`/`push`), ~10 тактов номинала на байт;
+- источник маппится в W0, приёмник — новая EMM-страница; на спрайт: прочитать
+  колонки в буфер W2 (максимальный кадр — 40×16 ≈ 640 Б), развернуть, писать
+  в приёмник (перемаппинг W0 на спрайт — один OUT);
+- `pop_cdraw.c` выбирает набор атласов (оригинал/зеркальный) по `pop_upside`;
+- **кэш ключуется по СТРАНИЦЕ атласа**, а не по кадру: страница = 8 кадров,
+  3-10 КБ, ~0.2-0.4 растрового кадра на переворот.
+
+**Стратегия наполнения — ЛЕНИВЫЙ ПОСТРАНИЧНЫЙ** (решение пользователя
+2026-08-12): страница переворачивается при первом обращении к ней в
+перевёрнутом режиме.  Реально в ходу 5-10 страниц из 34, и если игрок зелье не
+трогал, не тратится ни такта, ни страницы.
+
+**Время жизни кэша — ДО КОНЦА УРОВНЯ**: освобождаем страницы при смене
+уровня, а не при снятии эффекта.  На уровне 9 переворот случается минимум
+дважды (второе зелье возвращает всё назад), плюс его снимает смерть Кида —
+готовить пачку заново каждый раз было бы обидно.
+
+После [UI-SPRITES](../roomtest/TASKS_OPEN.md#ui-sprites) страницы `kid27` и
+`g0` станут чисто «полевыми» (деления HP уедут в константы резидента), и
+исключений в кэше не останется — эту задачу логично сделать ДО II.4.
+
+## II.5 Клип — ЧАСТЬ СДЕЛАНА 2026-08-12 (поле), остаётся clip_char
+
+**Клип ПОЛЯ сделан.**  Симптом (нашёл пользователь): после телепорта в
+перевёрнутом виде ниже поля — мусор.  Причина: спрайты, которые в обычном
+виде торчат ВЫШЕ поля (полоса кладки у потолка, её режет `pop_t_clip_top`),
+после отражения торчат НИЖЕ и лезут в борт, где живёт полоса HP.
+
+Фикс в `blit_b_clip`: при перевороте режем по ОБЕИМ границам поля всегда, а
+не по `pop_t_clip_top` — зеркальный спрайт может вылезти и там, где в
+обычном виде клип не ставили.  Плюс в `pop_blit_b` быстрый путь (без клипа)
+теперь пропускает в клипующий всё, что выходит за поле.
+
+Проверено в MAME: телепорт по комнатам в перевёрнутом виде — борта чистые,
+комнаты рисуются зеркально (факелы, чомперы, пол).  То есть **переходы
+между комнатами в перевёрнутом виде работают**.
+
+Осталось из этого пункта: `clip_char` (верх поля ↔ низ) и клип падающей
+плиты — они про ПЕРСОНАЖЕЙ и падающие объекты, то есть идут вместе с II.4.
+
+### Контракт (исходное описание)
+
+- `clip_char` (`pop_map.c:2287`, таблица `y_clip[5] = {-60,3,66,129,192}`) —
+  режет верх спрайта по линии ряда; при перевороте линия становится нижней.
+  Симметрия сама не сойдётся: нужен зеркальный расчёт `y_clip` и обмен
+  «сверху/снизу» местами;
+- то же для зеркала уровня 4 (`pop_map.c:2732`) — на уровне 9 зеркал нет, но
+  код общий, поэтому ветку надо хотя бы не сломать;
+- `pop_clip_sprite` (`pop_room.c:1069`) — клип падающей плиты;
+- `pop_room_clip_borders` — борта симметричны (28 сверху и снизу), но
+  проверить, что чистится именно поле.
+
+## II.6 Проверка
+
+- **хост-тест** (`tests-host`): арифметика `POP_FLIP_Y` и зеркальный `y_clip`
+  — сцена «Кид у верхней кромки» в обычном и перевёрнутом режиме даёт
+  симметричные значения клипа.  Логику отрисовки хост-тесты не видят, поэтому
+  здесь проверяем только счёт;
+- **MAME**: уровень 9, комната 7 — выпить зелье `(1,7)`, проверить: картинка
+  перевернулась целиком, Кид ходит и цепляется корректно, факелы анимируются
+  перевёрнуто, ворота/пики перерисовываются перевёрнуто, полоса HP осталась
+  внизу и не зеркальная; второе зелье (комната 10) возвращает как было;
+  смерть Кида снимает эффект;
+- **регресс**: обычные уровни (1-8) не должны измениться ни на пиксель —
+  прогнать пару комнат и сверить скриншоты с прежними.
+
+---
+
+# Часть III — ENTER-ROOM-FAST — СДЕЛАНО 2026-08-12
+
+Комната теперь рисуется ОДИН раз — в скрытую страницу, — тут же
+показывается флипом, а вторая страница получает её `gfx_copy_page(DIRECT)`.
+Процесс рисования тайлов больше не виден: игрок получает готовый кадр.
+Проверено в MAME: старт уровня и чит-переход между комнатами, два
+последовательных снимка идентичны (обе страницы синхронны, мерцания нет).
+
+Побочно понадобилось: видимую страницу главный цикл больше не ведёт сам, а
+перечитывает у железа в начале кадра (`front = gfx_get_visible_page()`) —
+её меняют и вход в комнату, и переворот, причём оба из банка, где локальные
+переменные `main` недоступны.
+
+# Часть III (исходное описание)
+
+Идея пользователя, самостоятельная ценность (сейчас при входе в комнату видно,
+как рисуются тайлы): рисовать комнату ОДИН раз в скрытую страницу, показать её
+флипом, а во вторую страницу залить `gfx_copy_rect(…, GFX_COPY_DIRECT)`.
+
+- сейчас `enter_room_side` рисует комнату дважды (цикл `for (pg = 0; pg < 2)`)
+  — вторая отрисовка (~полмиллиона тактов) меняется на копию (~115-200 К);
+- процесс рисования перестаёт быть виден: игрок видит только готовый кадр;
+- делается тем же `gfx_copy_rect`, что и I.3, то есть ничего дополнительно
+  писать не надо.
+
+Проверять отдельно: состояние ОЗУ-копии второй страницы после копии
+(инвариант из I.4 п.5), метки «фон трогали», и что heal на второй странице
+работает.
+
+---
+
+# Порядок работ
+
+1. I.0 разведка (`tests/accflip`) → факты в docs + memory.
+2. I.1 ядро + I.3 `gfx_copy_rect` (+ `tests/pagecopy`).
+3. II.1 состояние и `pop_flip_screen` — уже можно посмотреть в MAME:
+   картинка обязана перевернуться целиком, дальше она «поедет» по мере
+   перерисовок (это ожидаемо на этом шаге).
+4. Часть III (ENTER-ROOM-FAST) — дешёвый выигрыш на том же кирпиче,
+   заодно обкатывает копию в бою.
+5. I.2 vflip-блиты (+ `tests/blitvflip`) → II.3 фон.  После этого сцена
+   должна выглядеть правильно во всём, кроме персонажей.
+6. UI-SPRITES (деления HP в резидент) → II.4 зеркальные кадры персонажей.
+7. II.5 клип → II.6 проверка и регресс.
+
+Критерий готовности каждого шага — артефакт (побайтный тест в MAME либо
+скриншот сцены), а не «код написан».
+
+# Риски
+
+- **Р1 не подтвердится** (нельзя менять Y между триггерами) — переворот
+  пойдёт через ОЗУ-буфер строки, бюджет вырастет вдвое (всё ещё ≈0.5
+  логического кадра), схема в целом выживает;
+- **двойной переворот координат** — самый вероятный баг: часть кода зеркалит
+  `y` сама, часть получает уже зеркальный.  Лечится правилом из II.2 и тем,
+  что зеркалит только вызывающий;
+- **кэш зеркальных кадров и память**: 34 страницы EMM в худшем случае; по
+  `sprinter_emm_budget` на старте свободно 215 — влезает, но проверить
+  фактический остаток на уровне 9 (там уже загружены атласы фона, Кида,
+  стража и уровень);
+- **fore-слой поверх персонажа**: он рисуется по футпринту спрайта, а
+  футпринт после переворота другой — проверить именно на сцене с колоннами.
+
+# Решения пользователя (2026-08-12)
+
+1. **Кэш зеркальных кадров — ленивый постраничный**, наполняется по первому
+   обращению (см. II.4).
+2. **Живёт до конца уровня**, освобождается при смене уровня.
+3. **ENTER-ROOM-FAST делается сразу**, шагом 4 — на готовом `gfx_copy_rect`,
+   до того как на копию завяжется переворот.
+
+Открытых вопросов не осталось: план исполняется как есть, новые развилки —
+только если разведка I.0 даст отрицательный результат по Р1.

applications/PoP/docs/layout_plan_v2.md

@@ -0,0 +1,532 @@
+# roomtest — план v2: размер кода и раскладка по окнам/банкам/страницам
+
+> **Замер 2026-08-08, после MEM-BANK2 (актуальная сборка, ALLOCS=3000).**
+> `_CODE` 22 556 Б, данные 4 375, куча 4 301.  Банки: 1 (`guards.c`) 2 289,
+> 2 (`pop_bg.c`, ГОРЯЧАЯ половина фона) 5 872, 3 (`pop_map.c`) 8 483,
+> 4 (`pop_cdraw.c`) 5 664, 5 (`pop_ctrl.c`) 2 040, 6 (`pop_trob.c`) 2 889,
+> 7 (`pop_room.c`, ХОЛОДНАЯ половина фона) 6 035 — все из 16 384.
+>
+> Слой фона разрезан надвое по ЧАСТОТЕ ВЫЗОВА (`TASKS_CLOSED.md#mem-bank2`):
+> общие листья — в резидент `pop_tile.c` (W1 замаплен всегда, таблицы видны
+> обеим половинам), горячий fore-проход остался в банке 2, холодная отрисовка
+> комнаты и точечные перерисовки уехали в банк 7.  Стык — три тонкие
+> `__banked`-обёртки, чтобы трамплин платил только холодный путь.
+> **Банк 2: 90.4 % -> 35.8 %.**  Резидент вырос на 2 КБ (листья) — куча
+> 6 333 -> 4 301 Б, это плата за то, что таблицы должны быть видны из двух
+> банков.
+>
+> Число банков дублируется: `--bank N=` в Makefile И `const uint8_t n_banks`
+> в `roomtest.c`.  Расхождение — не ошибка сборки, а зависание до первого
+> кадра.
+>
+> **Замер 2026-08-01 (историческая отметка).**  `_CODE` 25 119 Б, `_DATA` 3 709,
+> куча ~2.4 КБ.  Банки: 1 (`guards.c`) 1 896, 2 (`pop_bg.c`) 13 792,
+> 3 (`pop_map.c`) 6 331, 4 (отрисовка стража) 2 236 — все из 16 384.
+> **Резидента `--w3` больше нет**: отрисовка уехала в банк 2, и это сняло
+> главное ограничение резидента (из банка его было не достать) — банк→банк
+> работает, трамплин сохраняет страницу окна на стеке.  Отрисовка стража
+> вынесена из банка 2 в собственный банк 4, потому что банк 2 подошёл к
+> потолку (16 021 из 16 384) — коммит `2f3e854`.
+>
+> **Свободного места в банке 2 теперь 10.5 КБ**, в банке 7 — 10.3 КБ; туда
+> просятся чомперы, зеркало и второй тайлсет (palace).  Прежде чем начинать
+> `levels_plan.md` §3 — всё равно посчитать, куда это ляжет.  Следующий
+> свободный номер банка — 8, гранулярность — файл.
+>
+> Из плана ниже **не сделаны шаги 5 (данные: `room_modif`, `dl1/dl2`,
+> `_kbdraw_down`; потенциал ~1.5 КБ) и 7 (дедуп `draw_tile`, отложен по
+> решению пользователя)**.
+
+Статус: **план для отдельной сессии**, составлен 2026-07-29 по свежему замеру.
+Заменял `size_optimization_plan.md` (v1, 2026-07-21) — тот удалён 2026-08-01
+как полностью перекрытый этим документом.  Документ самодостаточный
+— рассчитан на старт с пустого контекста.
+
+Повод: перед стражами и боёвкой (новый код ~5–8 КБ) надо понять, куда он
+поместится, и заранее развести код так, чтобы банкованные модули не упёрлись в
+ограничения окна W3.
+
+---
+
+## СТАТУС ВЫПОЛНЕНИЯ (обновлено 2026-07-29, коммит ecf5ecf)
+
+| Шаг | Статус | Факт |
+|-----|--------|------|
+| 1. `kid_data.h` → EMM-страница + `load_frame`/`cur_frame` | **сделан** | `_CODE` −3 247 Б; попутно найден и обойдён баг кодогенерации SDCC (см. ниже) |
+| 2. `pop_geom.c` (дедуп геометрии + PRNG) | **сделан** | −41 Б `_CODE`, −11 Б W3; ценность — не байты, а bank-safe слой |
+| 3. `pop_map` без вызовов графики | **сделан** (фазы 1a/1b) | через пометки перерисовки, см. ниже |
+| 4. Разгрузка/перебалансировка W3 | **сделан** | резидент = `pop_bg` + `pop_gdraw` (отрисовка стража, 2026-07-29); W3 14 376 → 12 819 (свободно 3 565 Б) |
+| 5. Данные (`room_modif`, `dl1/dl2`, `_kbdraw_down`) | не начат | потенциал ~1.5 КБ |
+| 6. Контракт банка стражей + пробник | **пробник сделан** | `tests/w3bankgfx` — модель подтверждена в MAME, см. ниже |
+| 7. Дедуп семейства `draw_tile` | отложен по решению пользователя | «мороки много, выгода не так велика» |
+
+**Замер сейчас против замера §1:** `_CODE` 24 881 → 24 421, куча W2 2 076 → 2 592 Б,
+W3-резидент 14 376 → 11 632 (свободно 2 008 → 4 752 Б).  Сумма кода упала
+на ~3.2 КБ (данные Kid уехали в EMM), остальное — перераспределение.
+
+**Замер 2026-07-29 (после стража).**  Появление стража съело кучу до 805 Б;
+разгрузка — вынос ОТРИСОВКИ стража в резидент (`pop_gdraw.c`, `--w3`), логика
+и состояние остались в W1/W2, чтобы банк `guards.c` их видел (R2).  Итог:
+`_CODE` 26 149 → 25 703, куча **805 → 1 245 Б**, W3-резидент 11 656 → 12 819
+(свободно 4 728 → 3 565 Б), банк 1 — 236 / 16 384 Б.  Граница «что резидент»
+теперь формулируется одним правилом: **резидент = только то, что рисует и
+зовётся исключительно из главного цикла**; всё, что может понадобиться банку,
+остаётся в W1/W2.
+
+### Что сделано вместо §5.3 (вынос loose в W3)
+
+Вместо переноса кода между окнами выбран (по обсуждению с пользователем)
+**порт архитектуры оригинала**: логика ставит пометку, отрисовка идёт
+отдельным проходом — `set_redraw_*` (seg007) + `redraw_needed` (seg008:0178).
+Появился `pop_redraw.c/.h`; `pop_trob` и `pop_map` больше не рисуют тайлы.
+Наши самодельные счётчики (`spike_rest`, `button_rest`, `ldoor_rest`,
+`loose_bake`, `loose_rest`, `ceil_rest`, `ceil_bake`, `land_bake`) удалены —
+их роль (вторая страница дабл-буфера) взял счётчик страниц в пометке.
+
+**Два исключения остались** (обе — функции ТОЛЬКО главного цикла, звать из
+банка нельзя):
+- `pop_process_trobs` — пламя факела и пузырёк зелья (покадровый оверлей);
+- `pop_loose_tick` — падающий кусок (mob): spawn/tick/pos.  В оригинале это
+  отдельная подсистема (`mobs` + `draw_moving`), разделение на логику и
+  отрисовку — задел следующей фазы.
+
+### Пробник банка (2026-07-29): модель ПОДТВЕРЖДЕНА
+
+`tests/w3bankgfx` (huge + `--w3 res.c` + `--bank 1=bank1.c`, графика 256):
+
+- банк рисует примитивом libbgi НАПРЯМУЮ — работает; страница W3 внутри
+  банка до блита, после блита и после возврата из вызванной им W1/W2-функции
+  одна и та же (0xF0), резидент — 0xF3.  То есть `_bgi_begin`/`_bgi_end`
+  корректно возвращают ИМЕННО банковую страницу (правило R4);
+- вызов W1/W2-функции из банка работает, и она тоже может рисовать;
+- резидент W3 жив и вызывается после возврата из банка (R3).
+
+**Дополнительно выяснено (важно для стражей):** писучие статики
+`__banked`-модуля линкуются В СТРАНИЦУ БАНКА (0x1C000+) — снаружи их не
+прочитать, из W1/W2 по 0xC000 видна резидентная страница.  Значит всё
+состояние банкованного кода (позиции стражей, таймеры боя) обязано жить в
+W1/W2 как обычные глобалы, а банк — только код.
+
+Ещё одна мина, найденная там же: инлайновый `in a,(#0xE2)` посреди тела
+функции затирает A, куда SDCC уже положил параметр (у нас из-за этого цвет
+заливки стал номером страницы, и «резидент не рисовал»).  Читать порт
+отдельной `__naked`-функцией.
+
+### Найденная по дороге ловушка компилятора
+
+`(const T *)КОНСТАНТА + var*K` SDCC 4.5 может собрать неверно: умножение
+делает в 16 битах, а потом берёт только младший байт (`ld c,l` / `inc b`).
+Кадры Kid с индексом ≥ 52 читались из чужой строки таблицы, у бега/шага
+пропадал `FRAME_NEEDS_FLOOR` и персонаж проваливался сквозь пол.  Лечение —
+считать адрес в `uint16_t` и кастовать один раз.  Тот же паттерн в
+`pop_level.c` компилируется ПРАВИЛЬНО, т.е. полагаться на «у соседа
+работает» нельзя.  Подробности: memory `sdcc_z80_const_ptr_index_bug`.
+
+---
+
+## 0. Что уже сделано из v1 (не повторять)
+
+- `--opt-code-size` и `--max-allocs 100000` **уже включены по умолчанию** в
+  `bin/sprinter-cc` (v1 §2.1 закрыт, выигрыш получен).
+- Лишние блиты переднего слоя убраны (v1 §7 п.0): `fore_tile` больше не рисует
+  `bottom_id`, `_CODE` −388 Б.
+- `gfx_blit_noclip` в libbgi (v1 §8 шаг 1): фоновые блиты в 2.9× дешевле.
+- `--w3` как резидент окна 3 реализован и обкатан (memory `w3_resident_code`).
+
+---
+
+## 1. ЗАМЕР (сборка 2026-07-29, коммит 1214785)
+
+Команда: `--memory small --gfx 256 --w3 pop_trob.c pop_map.c --w3 pop_bg.c`.
+
+### 1.1 Окна
+
+| Область | Занято | Свободно | Примечание |
+|---|---|---|---|
+| W1+W2 `_CODE` | 24 881 Б | — | 0x4100…0xA231 |
+| W1+W2 `_HOME`+`_GSINIT`+`_DATA`+`_BSS` | ~4 240 Б | — | до 0xB2E4 |
+| **W1+W2 куча** | 0 (никто не malloc'ит) | **2 076 Б** | 0xB2E4…0xBB00 |
+| W1+W2 стек | — | 1 279 Б | 0xBB00…0xBFFE |
+| **W3 резидент** | 14 376 Б | **2 008 Б** | 0xC000…0xF828 |
+| EMM-страницы | 37 атласов + 1 уровень | ~215 страниц свободно | `sprinter_emm_budget` |
+
+**Итого запаса до стены: ≈ 4 КБ** (2 КБ в W1/W2 + 2 КБ в W3).  Стражи туда
+не влезут.
+
+### 1.2 Код по модулям (точно, из `.rel`)
+
+```
+W1/W2 (_CODE 24 881):            W3 резидент (_W3CODE 14 376):
+  pop_kid      6 963               pop_bg     11 643
+  pop_map      6 157               pop_trob    2 733
+  roomtest     2 583
+  pop_level    1 425
+  pop_ctrl     1 145
+  crt0           333
+  libc+libbgi ~6 275
+```
+
+### 1.3 Крупнейшие функции/данные (из `.lst`)
+
+```
+pop_bg   : draw_tile 3080, other_overlay_tile 1146, wall_pattern 944,
+           mob_render 720, mob_tick_one 661, overlay_mid_tile 498,
+           fore_only_tile 409, climb_overlay_tile 391, tile_table 371
+pop_map  : check_loose_fall_on_kid 674, check_bumped 567, jump_up_or_grab 413,
+           get_tile 266, do_knock 243, check_press 238, check_leave 212
+pop_kid  : kid_seqtbl 2310 + kid_frames 1205 + kid_seq_off 230 = 3745 Б ДАННЫХ
+           (в _CODE!), собственно кода ~3.2 КБ
+roomtest : enter_room+main ~2.1 КБ
+pop_level: room_bg_ptr 1084 (+ 515 Б таблиц LINKLOC/LINKMAP в _DATA)
+```
+
+### 1.4 `_DATA` (3 710 Б)
+
+```
+pop_trob 963  (room_modif[24][30] = 720 + trobs + rest-массивы)
+pop_level 515 (копии LINKLOC/LINKMAP уровня)
+pop_map 163, roomtest 141, pop_kid 130, pop_bg 115, pop_ctrl 13
+libc: _irq_state 818, _kbdraw_state 515, _gfx_pal_buf 256, прочее ~200
+```
+
+### 1.5 Находки замера (мелкие, но чинить)
+
+1. **`--w3` берёт ОДИН файл на флаг.**  В `Makefile` написано
+   `--w3 pop_trob.c pop_map.c --w3 pop_bg.c`, и это значит «W3 = pop_trob и
+   pop_bg», а `pop_map.c` компилируется как обычный исходник в W1/W2.  Судя по
+   `.sprinter-cc-roomtest/w3_pop_map.rel` (устаревший артефакт), когда-то
+   pop_map был в W3.  **Решить осознанно** (см. §4) и записать явно:
+   `--w3 pop_trob.c --w3 pop_bg.c`.
+2. `libc` тянет `_irq_state` 818 Б + `_kbdraw_state` 515 Б в `_DATA`.
+   `__irq_vec_buf` (513 Б) — таблица векторов IM2; `__kbdraw_down` (512 Б) —
+   битмап клавиш на 512 скан-кодов.  Оба можно ужать (см. §5.4), это ~0.7 КБ
+   в самом дефицитном окне.
+
+---
+
+## 2. ПРАВИЛА ПЛАТФОРМЫ, ОТ КОТОРЫХ ПЛЯШЕТ РАСКЛАДКА
+
+Это главное, что изменилось по сравнению с v1: модель банкинга уточнена по
+`bin/sprinter-cc` (справка `--w3`/`--bank`) и по коду libbgi.
+
+**(R1) Резидент W3 (`--w3`) и банки W3 (`--bank`) делят одно окно.**
+Резидент лежит на своей странице 0xC000…0xFFFF; трамплин на время вызова
+`__banked` подменяет страницу W3 на банковую и возвращает резидентную назад.
+
+**(R2) Из банка резидент W3 НЕДОСТИЖИМ — и транзитивно тоже.**
+Пока исполняется банк, резидентной страницы в адресном пространстве нет.
+Значит нельзя не только `bank → pop_bg()`, но и `bank → pop_map() → pop_bg()`.
+**Это ключевое ограничение при выборе, что делать банком.**
+
+**(R3) Резидент → банк работает** (через трамплин в W1), резидент → W1/W2 —
+тоже.
+
+**(R4) Графические примитивы libbgi звать можно откуда угодно.**
+`_bgi_begin` читает текущую страницу W3 из порта 0xE2, а `_bgi_end` её
+возвращает — то есть скобка корректна и из банка, и из резидента.  Нельзя
+только одно: **звать `_bgi_begin`/`_bgi_end` ИЗ кода, который сам лежит в W3**
+(после подмены страницы исчезнет исполняемый код — проверено, белый экран).
+Поэтому `pop_bg` (резидент W3) обязан пользоваться готовыми примитивами
+(`gfx_blit*`, `bar`, …), а батчинг скобки на весь `draw_tile` (v1 §8 шаг 1)
+для него **невозможен** без переноса самого `draw_tile` в W1/W2.
+
+**(R5) `--w3` кладёт в W3 код И rodata модуля** (`--codeseg/--constseg
+W3CODE`), а писучие статики оставляет в `_DATA` (W2).  То есть `const`-таблицы
+переносятся в W3 бесплатно вместе с модулем (так уже лежит `tile_table` 371 Б).
+
+**(R6) Данные в EMM-странице читаются, только пока страница в окне.**
+`gfx_w0_map(page)` / `gfx_w0_unmap()` — окно W0 (0x0000…0x3FFF), первые 0x100
+занимает ISR-стаб.  Так уже работает `pop_level`.  Цена — пара `OUT` на
+маппинг, поэтому годится для «пачками», а не для чтения по байту в горячем
+цикле.
+
+---
+
+## 3. ЧТО ДЕЛАТЬ НЕЛЬЗЯ (анти-паттерны, чтобы не потерять время)
+
+- **Нельзя банковать `pop_bg`.**  Он вызывается из pop_map, pop_trob, roomtest,
+  pop_kid — то есть из главного цикла на каждом кадре; плюс он сам держит
+  `tile_table` и всю отрисовку.  Банк дал бы трамплин на каждый блит.
+- **Нельзя банковать `pop_map`, пока `pop_map` зовёт `pop_bg`** (R2).  Сейчас
+  зовёт: `pop_loose_tick` и компания (~30 вызовов графики).
+- **Нельзя тащить `kid_frames` в EMM «в лоб»**: он читается несколько раз за
+  кадр из коллизии (`kid_cur_dx`/`kid_cur_flags` → `dx_weight`,
+  `char_x_forward_edge`, …).  Нужен кэш кадра (см. §5.1) — иначе маппинг
+  страницы окажется в горячем пути.
+- **Нельзя «причёсывать» семейство `draw_tile` ради экономии, не имея
+  пиксельного теста.**  Мы неделю выравнивали слои по SDLPoP; любой рефактор
+  этой зоны проверять диффом страниц (заморозка кадра клавишей `1` + сравнение
+  VRAM обеих страниц, приём из memory `mame_mcp_bridge`).
+
+---
+
+## 4. ЦЕЛЕВАЯ РАСКЛАДКА
+
+Принцип: **W3-резидент = «толстая графика, которую зовёт только главный цикл»;
+W1/W2 = ядро, которое должно быть достижимо ОТОВСЮДУ (включая банки); банки =
+новая холодная логика (стражи, боёвка, будущие уровни)**.
+
+```
+W1/W2 (всегда отображено)          W3 резидент (стр. 0xC000)      Банки W3
+──────────────────────────         ─────────────────────────      ─────────
+libc + libbgi                      pop_bg   (отрисовка тайлов)    guards.c
+pop_kid  (интерпретатор+рисование)  pop_trob (анимации тайлов)     fight.c
+pop_map  (коллизия/физика/предметы) pop_loose.c (loose+потолок)    debug/roomnav
+pop_geom (общая геометрия/тайлы)    enter_room-часть roomtest?
+pop_ctrl (ввод/диспетчер)
+roomtest (главный цикл)
+```
+
+Почему так:
+
+- **`pop_map` остаётся в W1/W2** — его зовут и главный цикл, и (в будущем)
+  банк стражей; в W3 его класть нельзя именно из-за R2.  Для этого из него надо
+  вынести графическую часть (loose/потолок) — она уезжает в W3 к `pop_bg`
+  (§5.3).  После выноса `pop_map` становится **чистой логикой без единого
+  вызова графики** — тот самый bank-safe API.
+- **`pop_kid` остаётся в W1/W2**: `play_seq`/`kid_set_seq`/`Kid` нужны и
+  стражам (у стражей ТА ЖЕ seqtbl), а `kid_draw` зовёт только libbgi (R4).
+- **`pop_trob` остаётся резидентом**: его зовёт только главный цикл, и он сам
+  зовёт `pop_bg` — идеальный житель W3.
+- **Банк стражей не зовёт ничего из W3.**  Рисование стражей — либо через
+  libbgi напрямую (R4), либо (лучше) резидентный `guard_draw()` в W1/W2 рядом
+  с `kid_draw`, а банк только считает состояние.  Тот же приём мы уже
+  используем для `pop_item_taken`/`pop_loose_fell`/`pop_ceil_fell`: банк
+  выставляет флаг — резидент рисует.
+
+---
+
+## 5. ПЛАН РАБОТ
+
+Порядок выбран так, чтобы каждый шаг был проверяем отдельно и давал место
+следующему.
+
+### Шаг 1. `kid_data.h` (3 745 Б) → EMM-страница + порт `load_frame` — **самый большой выигрыш**
+
+Сейчас `kid_seqtbl` (2310) + `kid_frames` (1205) + `kid_seq_off` (230) лежат в
+`_CODE` окна W1/W2 — это 15 % всего дефицитного пространства.
+
+Как переносить:
+
+1. `pop_extract_kid_data.py` дополнительно пишет `kid_data.bin` (те же три
+   таблицы подряд, фиксированные смещения).
+2. Грузим её в отдельную EMM-страницу тем же способом, что уровень
+   (`pop_level_load` — готовый образец), хэндл держим в `pop_kid`.
+3. **Порт `load_frame` (seg006) и глобала `cur_frame`** — в оригинале ровно
+   так и сделано: раз за тик кадр копируется в структуру, а весь остальной код
+   читает `cur_frame`, а не таблицу.  У нас `kid_cur_dx()/kid_cur_flags()`
+   станут чтением из `cur_frame` (5 байт в `_DATA`).
+4. `play_seq` оборачивается в один `gfx_w0_map(kid_data_page)` … `unmap` на
+   вызов (в тике, не в отрисовке — конфликта с атласом в W0 нет).
+
+Выигрыш: **−3 745 Б из W1/W2**, цена — один маппинг страницы за тик и 5 байт
+`_DATA`.  Дополнительный бонус: `load_frame`/`cur_frame` — шаг К СХОДСТВУ с
+оригиналом, а не отход от него.
+
+Риск: сломать `play_seq` (сердце анимации).  Проверка: прогон по комнатам с
+эталонными позами (вис, подтягивание, прыжки, подъём меча).
+
+### Шаг 2. Модуль `pop_geom.c` — дедуп + bank-safe фундамент
+
+Сейчас продублировано между модулями:
+
+| что | где | сколько |
+|---|---|---|
+| `y_to_row`/`y_to_row_mod4` | pop_bg + pop_map | 2 копии |
+| `char_dx_forward` | pop_kid + pop_map | 2 копии |
+| `x_bump[20]` | pop_kid (uint8) + pop_map (int16) | 20 + 40 Б, РАЗНЫЕ типы |
+| `y_land[5]` | pop_kid + pop_map | 10 + 10 Б |
+| `tile_is_floor` | pop_map (+ проверка кодов в roomtest) | 2 места |
+| 32-битный LCG `prandom` | pop_bg (`prandom`) + pop_trob (`trob_prandom`) | 2 копии по ~60 Б + 2 сида |
+
+Собрать в один W1/W2-модуль `pop_geom.c`: таблицы `x_bump/y_land/dir_front/
+dir_behind`, `y_to_row`, `char_dx_forward`, `get_tile_div_mod(_m7)`,
+`tile_is_floor`, `prandom`.  Выигрыш прямой — сотни байт (оценка 250–400 Б),
+но главное — **это и есть тот «чистый» API, который потом сможет звать банк**
+(R2): вся геометрия оказывается в W1/W2 по определению.
+
+Осторожно: `prandom` у pop_bg и pop_trob — РАЗНЫЕ последовательности с разными
+сидами (стены vs фазы факелов).  Объединять функцию можно, **сиды — нет**:
+передавать сид указателем/по индексу, иначе поедет раскладка кладки.
+
+### Шаг 3. Вынести loose/потолок из `pop_map` в W3
+
+`pop_map` — единственный модуль W1/W2, который зовёт графику, и делает это
+ровно в одном логическом блоке: `pop_loose_tick` + `check_press` + `do_knock` +
+`fell_on_your_head` + `check_loose_fall_on_kid` + плита-потолок (~1.4–2 КБ).
+
+Вынести их в `pop_loose.c`, собираемый `--w3` рядом с `pop_bg`/`pop_trob`.
+Тогда:
+
+- `pop_map` = чистая логика (bank-safe, R2 соблюдён);
+- W1/W2 худеет ещё на ~1.5–2 КБ;
+- W3 растёт на столько же — а место там появится после шага 4.
+
+### Шаг 4. Перебалансировка резидента W3
+
+После шага 3 в W3 будет тесно (14.4 + 2 ≈ 16.4 КБ > 16 КБ).  Разгружаем:
+
+1. **`wall_pattern` (944 Б) + `mob_render`/`mob_tick_one` (1381 Б)** — кандидаты
+   на переезд в W1/W2: их зовёт только `pop_bg`/`pop_loose`, но сами они уже
+   пользуются только libbgi (R4), значит из W1/W2 работают и остаются
+   достижимыми из банка.
+2. `tile_table` и мелкие const-таблицы pop_bg (371 + ~300 Б) можно унести в
+   EMM-страницу **уровня** (там ~13.8 КБ свободно) — но только если чтение
+   происходит под уже замапленной страницей.  Сейчас `draw_tile` читает
+   `tile_table` ВНЕ W0-контекста → потребуется явный маппинг на тайл.  **Не
+   делать раньше замера**: 30 тайлов на входе в комнату × map/unmap — терпимо,
+   а вот в покадровых редроях (пики/loose/кнопка) — уже горячий путь.
+3. Если и этого мало — `enter_room` (~2.1 КБ, зовётся только при смене комнаты)
+   переносится в резидент W3 или в БАНК (он вызывается из главного цикла =
+   резидента, значит банк допустим по R3).
+
+### Шаг 5. Данные
+
+1. **`room_modif[24][30]` = 720 Б** (pop_trob, `_DATA`).  Нужен произвольный
+   доступ каждый кадр (анимации, ворота) — в EMM не годится.  Но 24 комнаты ×
+   30 байт хранятся ЦЕЛИКОМ, хотя одновременно живут modif'ы только текущей
+   комнаты и соседей по швам.  Вариант: хранить полный массив в EMM-странице
+   уровня, а в `_DATA` держать кэш на 2–3 комнаты (свою + левого/правого
+   соседа) с записью обратно при смене комнаты.  Выигрыш ~600 Б, цена —
+   аккуратность на швах (кнопка в одной комнате открывает ворота в другой).
+   **Делать последним** — это самая «тонкая» правка по семантике.
+2. **`dl1[256]`+`dl2[256]` = 512 Б** (pop_level, `_DATA` — копии LINKLOC/
+   LINKMAP уровня) — читаются при нажатии кнопки
+   и при отрисовке нажатой кнопки.  Кандидат на чтение прямо из страницы
+   уровня (она и так маппится) — но проверить, что `pop_doorlink2` не зовётся
+   из отрисовки в тот момент, когда в W0 атлас.  Выигрыш ~500 Б.
+3. **`_kbdraw_down[512]` 512 Б** (libc): проверено — это **байт на скан-код**
+   (`libc/kbd/_kbdraw_state.c`), хотя комментарий называет его битовой картой.
+   Упаковка в биты даёт −448 Б, но добавляет сдвиг/маску в ISR-трамплин и в
+   `kbd_raw_down`.  Трогать осторожно: raw-клавиатура уже дважды была
+   источником залипаний (memory `kbd_raw_fifo_drain`,
+   `kbd_overrun_wipe_modifiers`) — правку сопровождать прогоном docs/kbd-games.
+4. **`__irq_vec_buf` 513 Б** (libc IM2): таблица векторов обязана быть
+   выровнена и полна — не трогать.
+
+### Шаг 6. Контракт банка стражей (проектируется ДО написания кода)
+
+Когда дойдём до стражей:
+
+- `guards.c` собирается `--bank 1=guards.c`, режим `huge` (или `big` с
+  `BANKED=W1`, если W3 окажется тесен для трамплинов).
+- **Банк зовёт только:** `pop_map` (чистая логика после шага 3), `pop_kid`
+  (`play_seq`, `kid_set_seq`, `cur_frame`), `pop_geom`, libc/libbgi.
+- **Банк НЕ зовёт:** `pop_bg`, `pop_trob`, `pop_loose` (резидент W3) — ни
+  прямо, ни через промежуточные функции.  Нужна отрисовка — выставляет флаг,
+  рисует резидент (идиома `pop_item_taken`).
+- Первым делом — **пробник** (`tests/` или `--bank` на пустышке): банк зовёт
+  `pop_map`-функцию, та зовёт libbgi-примитив; убедиться в MAME, что скобка
+  W3 корректно возвращает банковую страницу (R4) — это проверка модели, а не
+  веры в неё.
+
+### Шаг 7. Мелкий дедуп в `pop_bg` (после того, как появится тест страниц)
+
+- Пять функций-редроев (`pop_spike_redraw`, `pop_loose_shake_draw`,
+  `pop_floor_bake`, `pop_button_redraw`, `pop_leveldoor_redraw`) отличаются
+  только прямоугольником heal, банком и набором тайлов — свести к одному
+  параметризованному хелперу (оценка −150…250 Б).
+- `env_b/wall_b/fore_b/pot_b` — четыре одинаковых обёртки над `blit_b`
+  (оставить: экономия единицы байт, читаемость дороже).
+- `overlay_mid_tile` / `fore_only_tile` / `climb_overlay_tile` / `draw_tile`
+  — общая структура «взять code/lcode, посчитать x/dmy/dby, разобрать слои».
+  Тут экономия потенциально сотни байт, но это **та самая зона риска из §3** —
+  только с пиксельным диффом до/после и по одному слою за раз.
+
+---
+
+## 6. Ожидаемый итог
+
+| Шаг | W1/W2 | W3 | Риск |
+|---|---|---|---|
+| 1. kid_data → EMM + load_frame | **−3 745** | — | средний (сердце анимации) |
+| 2. pop_geom (дедуп) | −250…400 | — | низкий |
+| 3. loose → W3 | −1 500…2 000 | +1 500…2 000 | низкий (перенос как есть) |
+| 4. разгрузка W3 (wall_pattern, mob) | +2 300 | −2 300 | низкий |
+| 5. данные (room_modif, LINKLOC, kbd) | −1 000…1 600 | — | средний/высокий |
+| 7. дедуп редроев pop_bg | — | −150…250 | средний |
+
+Суммарно: **W1/W2 освобождается ~4.5–6 КБ**, W3 остаётся примерно в нынешнем
+объёме, но становится «правильно заполненным» — в нём только то, что банк
+никогда не позовёт.  Плюс открывается путь к банкам: стражи и боёвка получают
+до 16 КБ на банк, не трогая резидент.
+
+---
+
+## 7. Как мерить и проверять (обязательно к каждому шагу)
+
+1. **До/после по `.rel`** — точные размеры на модуль:
+   `for f in .sprinter-cc-roomtest/*.rel; do grep '^A ' $f; done`
+   (области `_CODE`/`_W3CODE`/`_DATA`).  Итоги окон печатает сам `sprinter-cc`.
+2. **Функции** — из `.lst` (метки `_name:` и адреса), скрипт в истории этой
+   сессии; полезно ловить «функция распухла после рефактора».
+3. **MAME**: любой перенос кода между окнами/страницами — это класс «молча
+   ломается» (`sprinter_memory_modes`).  Минимум: комната 1 (loose), 12
+   (вис/подтягивание), 15 (меч), 9 (дверь уровня), 6 (кнопка/ворота).
+4. **Пиксельный дифф** для правок отрисовки: заморозить кадр (`1`), сравнить
+   обе страницы дабл-буфера через `vram` (см. memory `mame_mcp_bridge`) и/или
+   сверить с эталонным рендером `render_room.py`.
+5. **Скорость** — после шагов 1 и 4 замерить кадр маркерами в порт 0xFE
+   (приём из v1 §8), чтобы маппинг страницы за тик не съел бюджет.
+
+## 8. Ссылки
+
+- `bin/sprinter-cc` — справка по `--w3`, `--bank`, `--memory`, `--memory-manual`.
+- `runtime/crt0_banked.s`, `runtime/bank.s` — трамплины и захват резидентной
+  страницы W3.
+- `libbgi/common/_bgi_begin.c` / `_bgi_end.c` — механика скобки W3 (R4).
+- memory: `w3_resident_code`, `pop_banking_architecture`, `sdcc_banking`,
+  `bank_local_data_pattern`, `sprinter_memory_modes`, `memory_modes_implemented`,
+  `sprinter_emm_budget`, `mame_mcp_bridge`, `avoid_32bit_arith_z80`,
+  `libc_one_function_per_module`.
+- `applications/PoP/roomtest/TASKS_OPEN.md` — что из этого берётся в работу сейчас.
+
+---
+
+## 9. Скорость отрисовки: замеры и запас
+
+Перенесено из удалённого `size_optimization_plan.md` §8 (замер 2026-07-27) —
+единственная его часть, которая не была перекрыта этим документом.
+Профилирование в MAME: маркеры в порт 0xFE + `wpiset … totalcycles` (приём из
+memory `mame_mcp_bridge`); в самом `roomtest.c` для этого уже стоят полосы
+бордюра `PROF()`.  Кадр Sprinter = **430 080 тактов**.
+
+**Стоимость блита почти НЕ зависит от размера** — платим за проход по цепочке
+`gfx_blit → gfx_blit_part → _gfx_blit_full` (16-битная арифметика, клип,
+пересчёт src, нарезка полос >256), а не за пиксели:
+
+| путь (спрайт 32×3) | тактов |
+|---|---|
+| `gfx_blit` (общее ядро, с клипом) | 13 288 |
+| линейное ядро без клипа | 4 617 |
+
+Отсюда `draw_tile(0,0)` тайла шва (9 блитов) стоил **183 690 тактов = 43 %
+кадра**; сам `bar` — только 13 308.
+
+**Сделано:** `gfx_blit_noclip()` в libbgi, фоновые блиты `pop_bg` уходят на
+него, когда спрайт целиком на экране (~2.9×, подтверждено в MAME).  Позже
+тем же приёмом закрыты спрайты персонажей (`gfx_blit_cols_part_noclip`).
+**Не закрыт heal** — задача CLIP-1 в `../roomtest/TASKS_CLOSED.md`.
+
+**ВАЖНО:** W3-скобку (`_bgi_begin`/`_bgi_end`) ставит САМА libbgi — вызывать
+её из модуля, собранного с `--w3`, нельзя: после `_bgi_begin` окно W3 занято
+видеобанком и код вызывающего исчезает из адресного пространства (проверено:
+белый экран).
+
+**Запас, когда перестанет хватать бюджета кадра:**
+
+1. **Батчинг W3-скобки** — одна `_bgi_begin`/`_bgi_end` на весь `draw_tile`
+   вместо скобки на блит; нужен публичный batch-API в libbgi.
+   **Осторожно, и это стало важнее, чем было:** между begin/end стоит `DI`,
+   длинная серия задержит кадровое прерывание — а по разбору KBD-1
+   (`../roomtest/TASKS_CLOSED.md`) длинные DI-окна и есть причина потери байт
+   клавиатуры.  Батчинг эту проблему УХУДШИТ, если делать его вслепую.
+2. **Решётка ворот одним спрайтом** — `draw_gate_back` рисует бары по одному
+   (до 7 блитов).  Сгенерировать в атласе «столб решётки» и выводить одним
+   `gfx_blit_part` с обрезкой по фазе `gate_bot_y & 7`: 7 блитов → 1.
+3. **Не перерисовывать статичные части шва** — грань ворот, пол и кромка при
+   анимации решётки не меняются (см. OPT-1 в `../roomtest/BUGS_CLOSED.md` —
+   решено не делать, стоимость транзиентная).
+4. **T-1 / T-2** (`../roomtest/BUGS_OPEN.md`) — перерисовка пик по причине и
+   idle-skip Кида: самый большой оставшийся резерв, потому что убирает работу
+   целиком, а не удешевляет её.

applications/PoP/docs/levels_12_15_plan.md

@@ -0,0 +1,462 @@
+# Что осталось на уровнях 12, 13, 14, 15 и 0
+
+Статус: разбор по `../SDLPoP/src/`, 2026-08-13.  Продолжает
+[`levels_plan.md`](levels_plan.md) (машинерия уровней и тайлсеты — уже
+сделаны).  Здесь только СПЕЦСОБЫТИЯ, которых у нас ещё нет.
+
+Правило проекта: источник истины — SDLPoP; все ссылки ниже даны на функцию и
+строку, чтобы порт начинался с чтения, а не с гипотезы.
+
+---
+
+## 0. Что из этой области УЖЕ есть
+
+Проверено грепом по `roomtest/`:
+
+| механика | где у нас | статус |
+|---|---|---|
+| слот соперника, общий на всех Char | `pop_guard.c`, `pop_cdraw.c` | готово |
+| `check_shadow` (спецвход тени) | `guards.c:310` | готово для уровней 4/5/6 |
+| `do_init_shad` + таблицы `init_shad_5/6` | `guards.c:284` | готово |
+| ИИ тени 4/5/6 | `guards.c:599/658/680` | готово |
+| диспетчер `autocontrol_shadow` | `guards.c:711` | ветки 12 НЕТ |
+| боёвка (удар/блок/парирование/HP соперника) | `guards.c`, `pop_ctrl.c` | готово |
+| `flash_color` / `flash_time` | `pop_map.c`, `roomtest.c` | готово |
+| `add_life` | `pop_map.c` | готово |
+| таблицы уровней (`guard_type`, `guard_hp`, `entry_pose`, `level_type`) | `pop_level_cold.c:41..52` | готово, включая 12=SHADOW, 13=VIZIER |
+| loose-полы, `make_loose_fall`, mob | `pop_map.c`, `pop_room.c` | готово (без спецкейсов ур. 13) |
+
+То есть каркас есть весь; ниже — недостающие спецсобытия.
+
+---
+
+## 1. Уровень 12 — тень: встреча, бой, слияние
+
+### 1.1 Подъём тени в комнате 15 (`check_shadow`, seg002:0070)
+
+```c
+if (current_level == 12) {
+    if (!united_with_shadow && drawn_room == 15) {
+        Char.room = drawn_room;
+        if (get_tile(15, 1, 0) == tiles_22_sword) return;   // меч ещё лежит
+        shadow_initialized = 0;
+        do_init_shad(init_shad_12, 7 /* fall */);
+        return;
+    }
+}
+```
+
+Отличия от наших веток 5/6: тень поднимается **в падении** (seq 7), условием
+служит содержимое тайла (меч уже подобран) и флаг `united_with_shadow`.
+Таблица `init_shad_12 = {0x0F, 0x51, 0xE8, 0, 0, 0, 0, 0}` — то есть
+x=81, y=232, вправо, колонка 0, ряд 0.
+
+**Что добавить:** ветку в `pop_check_shadow` + константу `init_shad_12` +
+глобалы `united_with_shadow`, `shadow_initialized`.
+
+### 1.2 ИИ тени (`autocontrol_shadow_level12`, seg002:1184)
+
+Самая содержательная функция уровня.  Три режима:
+
+1. **Первый кадр в комнате 15**: пока Кид не подошёл (`Opp.x < 150`) —
+   `shadow_initialized = 1`; иначе тень ещё раз падает (`do_init_shad`).
+2. **Кид с мечом** (`Char.sword >= sword_2_drawn`) → тень дерётся обычным
+   `autocontrol_guard_active` (у нас есть, `guards.c:535`).  Особый случай:
+   если тень уже ранена (`offguard != 0 && guard_refrac != 0`) — она убирает
+   меч (`move_4_down`).
+3. **Кид убрал меч** → тень тоже убирает и идёт навстречу; на дистанции
+   `< 10` — **СЛИЯНИЕ**:
+
+```c
+flash_color = color_15_brightwhite;  flash_time = 18;
+add_life();                       // +1 к максимуму HP
+united_with_shadow = 42;          // время вспышки Кид-тень
+Char.charid = charid_0_kid;  savekid();   // Кид ПЕРЕЕЗЖАЕТ на место тени
+clear_char();                     // тень со сцены
+```
+
+Плюс «если Кид бежит к тени — тень бежит к Киду» (кадры бега 3..14 и
+шага 127..132).
+
+**Что добавить:** `autocontrol_shadow_level12` в `guards.c` + ветку в
+диспетчере `autocontrol_shadow` (там уже три ветки, будет четвёртая).
+
+### 1.3 Общий урон (`do_delta_hp`, seg000:1518)
+
+```c
+if (Opp.charid == charid_1_shadow && current_level == 12 && guardhp_delta != 0)
+    hitp_delta = guardhp_delta;      // ранил тень — ранил себя
+```
+
+Три строки, но без них бой с тенью теряет смысл.  У нас `do_delta_hp`
+портирован — добавить условие.
+
+### 1.4 Таймер вспышки (`do_timers`, seg003:503)
+
+```c
+if (united_with_shadow > 0) {
+    --united_with_shadow;
+    if (united_with_shadow == 0) { --united_with_shadow; /* → -1 */ ... }
+}
+```
+
+`united_with_shadow` живёт как счётчик, потом как «уже слились» (−1).
+На него смотрят `check_shadow` и `check_can_guard_see_kid`.
+
+### 1.5 Луч видимости (`check_can_guard_see_kid`, seg003:702)
+
+```c
+if ((Guard.charid != charid_1_shadow || current_level == 12) && ...
+```
+
+У нас (`guards.c:103`) условие про тень **нужно сверить**: на уровне 12 тень
+ОБЯЗАНА быть видимой (иначе Кид не достанет меч и бой не начнётся).
+
+### 1.6 Меч исчезает (`sword_disappears`, seg002:0536)
+
+```c
+if (current_level == 12 && Char.room == 18) {
+    get_tile(15, 1, 0);
+    curr_room_tiles[curr_tilepos] = tiles_1_floor;
+    curr_room_modif[curr_tilepos] = 0;
+}
+```
+
+Срабатывает при уходе Кида ВПРАВО из комнаты 18 (`leave_room`, ветка 1).
+У нас есть `pop_level_set_tile` — порт на пять строк.
+
+### 1.7 Переход 12 → 13: НЕТ двери уровня, есть «бесшовный выход»
+
+Проверено по данным (`res2012.bin` / `res2013.bin`) — портала действительно
+нет, уровень кончается **фактом попадания в комнату**:
+
+```c
+// play_level_2, seg000:900
+} else if (custom->tbl_seamless_exit[current_level] >= 0) {
+    if (Kid.room == /*23*/ custom->tbl_seamless_exit[current_level]) {
+        ++next_level;
+        stop_sounds();
+        seamless = 1;
+    }
+}
+```
+
+`tbl_seamless_exit[12] = 23` (пара «уровень, комната» читается из оригинального
+`PRINCE.EXE`, options.c:724).  Дальше геометрия складывается так:
+
+| | комната | ряд 1 | что происходит |
+|---|---|---|---|
+| ур. 12 | 13 | `floor bigpil empty empty wall wall …` | Кид бежит ВЛЕВО с колонки 0 |
+| ур. 12 | 23 | `empty ×6, floor floor floor floor` | попал сюда → **уровень сменился** |
+| ур. 13 | 23 | `floor bigpil floor ×6 bigpil floor` | старт: ряд 1, кол 9, `seq_84_run` |
+
+Связи: `комната 13.left = 23`, и в комнату 23 больше ниоткуда не войти.
+Номер комнаты у обоих уровней **один и тот же (23)**, стартовая позиция
+уровня 13 — `BP_START = 23, поз 19 (ряд 1, кол 9), dir 0`, а
+`tbl_entry_pose[13] = 2` даёт «вбегающий» вход (`seq_84_run`, seg003:172).
+То есть Кид вбегает в комнату слева-направо… нет, `Char.direction =
+~level.start_dir` — влево, тем же ходом, каким выбежал из уровня 12.  Швов не
+видно.
+
+Что делает флаг `seamless` (всего два места, оба косметические):
+
+* `start_level`, seg003:158 — **НЕ сбрасывает HP**: Кид уносит на уровень 13
+  то здоровье, с которым добежал;
+* `show_level`, seg008:1861/1870 — не показывает заставку «LEVEL 13» и тут же
+  гасит флаг.
+
+Двери уровня при этом на карте есть, но не при делах: у уровня 12 она одна
+(комната 3, tilepos 23) — это ВХОД (стартовая комната 12-го — 3), а у уровня
+13 их две (комната 3 tilepos 13 и комната 5 tilepos 24) — это выходы,
+открываемые кнопкой из `Jaffar_exit`.
+
+**Что это значит для нас.**  Наш переход уровня сейчас идёт только через
+`SEQ_END_LEVEL` в двери.  Для 12-го нужен второй триггер — проверка в главном
+цикле «`pop_current_level == 12 && cur_room == 23` → `pop_next_level++`» плюс
+флаг `seamless`, который пропустит сброс HP в `pop_start_level`.  Обе правки
+маленькие и локальные.
+
+---
+
+## 2. Уровень 13 — Джафар
+
+### 2.1 Кто такой Джафар
+
+`tbl_guard_type[13] = 3` → `VIZIER.DAT` (у нас в `pop_level_cold.c` уже 3).
+`tbl_guard_hp[13] = 6`.  Отдельного ИИ у него нет:
+
+```c
+void autocontrol_Jaffar() { autocontrol_guard(); }   // seg002:0697
+```
+
+То есть **бой с Джафаром — обычный бой стражи**, отличаются только спрайты,
+HP и три спецсобытия ниже.  Это хорошая новость: боёвка у нас есть.
+
+### 2.2 Встреча (`meet_Jaffar`, seg002:0544)
+
+```c
+if (current_level == 13 && leveldoor_open == 0 && Char.room == 3) {
+    play_sound(sound_29_meet_Jaffar);
+    guard_notice_timer = 28;      // Джафар ждёт 28/12 ≈ 2.33 с
+}
+```
+
+Срабатывает при уходе Кида ВПРАВО (`leave_room`, ветка 1).
+Пара к нему — в `autocontrol_guard_inactive` (seg002:0734), она у нас уже
+портирована (`guards.c:401`), но **без условия по уровню**:
+
+```c
+if (can_guard_see_kid) {
+    if (current_level != 13 || guard_notice_timer == 0) move_down_forw();
+}
+```
+
+**Что добавить:** глобал `guard_notice_timer` + его тик в `do_timers`
+(seg003:509) + оба условия.
+
+### 2.3 Победа (`on_guard_killed`, seg006:1929)
+
+```c
+} else if (current_level == 13) {
+    flash_color = color_15_brightwhite;  flash_time = 18;
+    is_show_time = 1;
+    leveldoor_open = 2;              // ← ключ к выходу
+    play_sound(sound_43_victory_Jaffar);
+}
+```
+
+и парная `Jaffar_exit` (seg002:0517), срабатывающая при уходе Кида ВЛЕВО:
+
+```c
+if (leveldoor_open == 2) { get_tile(24, 0, 0); trigger_button(0, 0, -1); }
+```
+
+То есть смерть Джафара не открывает дверь сама — она ставит флаг, а дверь
+открывается кнопкой, «нажатой» при уходе влево.  `trigger_button` у нас есть.
+
+### 2.4 Падающие плиты (`check_fall_flo`, seg000:1319)
+
+```c
+if (current_level == 13 && (drawn_room == 23 || drawn_room == 16)) {
+    curr_room = room_A;                       // комната СВЕРХУ
+    for (curr_tilepos = 22; curr_tilepos <= 27; ++curr_tilepos)
+        make_loose_fall(-(prandom(0xFF) & 0x0F));   // ОТРИЦАТЕЛЬНЫЙ модификатор
+}
+```
+
+Вот это и есть «плиты появляются»: при входе в комнаты 23/16 шесть плит ряда 2
+комнаты СВЕРХУ получают отрицательную фазу — то есть отложенный старт, и
+сыплются на Кида вразнобой.  Зовётся из `check_the_end` при смене комнаты.
+
+**Три спецкейса уровня 13 в loose-механике**, без них это не работает:
+
+| место | что | зачем |
+|---|---|---|
+| `animate_loose`, seg007:823 | при `modif & 0x80` НЕ останавливать тряску | иначе отрицательная фаза не досчитает до нуля и плита не упадёт |
+| `loose_make_shake`, seg007:949 | на уровне 13 сотрясение НЕ трясёт плиты | иначе отложенные плиты сбрасываются в 0x80 |
+| `fell_on_your_head`, seg007:1218 | плита бьёт и в БЕГЕ (кадры 5..14) | на прочих уровнях бегущего не задевает |
+
+У нас первый пункт критичен: `pop_loose_tick` трактует бит 7 как «тряска» и
+на `>= 0x84` гасит фазу — отрицательный старт умрёт, не начавшись.  Заодно
+это ровно та же ветка, что мы правили сегодня в
+[`LOOSE-ROOM-CHANGE`](../roomtest/BUGS_OPEN.md#loose-room-change), так что
+код на виду.
+
+### 2.5 Поза входа
+
+`tbl_entry_pose[13] = 2` — у нас в таблице уже есть; проверить, что режим 2
+(`seg003:172`) реализован.
+
+---
+
+## 3. Уровень 14 — принцесса и конец игры
+
+Боя нет вовсе (`tbl_guard_type[14] = -1`).  Всё сводится к одному событию:
+
+```c
+// check_the_end, seg000:1299
+if (current_level == 14 && drawn_room == 5) end_sequence();
+```
+
+`end_sequence` (seg001:573) → `end_sequence_anim` (seg001:332): катсцена
+«Кид добежал до принцессы» — обнимаются, появляется мышь, затухание, Hall of
+Fame.  Персонажи там играются ТЕМ ЖЕ интерпретатором `seqtbl`
+(`seq_108_princess_turn_and_hug`, `seq_101_mouse_stands_up`), то есть движок
+у нас уже подходит — нужны спрайты принцессы (`PRINCESS.DAT`) и раскадровка.
+
+**Оценка:** это не игровая механика, а ролик.  Логично делать вместе с интро
+и межуровневыми вставками — отдельным банком, как и договаривались
+(см. memory `pop_banking_architecture`).  На проходимость игры не влияет:
+достаточно довести Кида до комнаты 5 и показать заглушку.
+
+---
+
+## 4. Уровень 15 — «уровень зелий» (защита от копирования)
+
+Не часть сюжета.  Это экран проверки подлинности из оригинала: после
+уровня `copyprot_level` игра подменяет номер на 15, показывает комнату с
+**14 зельями, на которых нарисованы буквы**, и требует выпить нужное.
+
+Механика (всё под `USE_COPYPROT` в SDLPoP):
+
+| место | что делает |
+|---|---|
+| `play_level`, seg003:53 | `level_number == copyprot_level` → грузим 15 |
+| `redraw_screen`, seg003:273 | поверх зелий рисуются БУКВЫ (`copyprot_letter`) |
+| `load_alter_mod`, seg008:1204 | одно зелье в комнате делается «открытым» (тип 6) |
+| `animate_potion`, seg007:259 | на уровне 15 своя ветка перерисовки |
+| `up_pressed`/`do_pickup`, seg005:657 | выпитое зелье убирает букву из таблицы |
+| `seq` эффект зелья, seg006:1896 | синие зелья на уровне 15 отнимают ПОЛОВИНУ HP |
+| выход, seg000:700 | из 15 возвращаемся в `copyprot_level` |
+
+**Рекомендация: не портировать.**  Это анти-пиратский экран 1989 года,
+требующий книжки-манускрипта; SDLPoP держит его выключенным по умолчанию
+(`enable_copyprot`).  Единственное, что стоит взять — **половинный урон
+синего зелья**, если вдруг захочется полной совместимости; остальное только
+съест банк.  Если решим делать — это отдельная фича «уровень 15», а не часть
+основного прохождения.
+
+---
+
+## 5. Уровень 0 — демо-уровень (аттракт)
+
+`res2000.bin` у нас распакован.  Это тот самый ролик, который крутится на
+титульном экране: Кид сам бежит, дерётся со стражем и убегает.
+
+Как устроено:
+
+| место | что |
+|---|---|
+| `do_demo`, seg006:1409 | на уровне 0 вместо чтения клавиатуры зовётся `do_demo()` + `control()` |
+| `autocontrol_kid`, seg002:702 | Кид управляется тем же `autocontrol_guard` |
+| `do_auto_moves`, seg002:1089 | проигрыватель ЗАПИСИ ходов: таблица `(time, move)` |
+| `on_guard_killed`, seg006:1928 | на уровне 0 после убийства стража Кид убегает (`checkpoint = 1`, сброс демо) |
+| `demo_index` / `demo_time` | позиция в записи; у нас уже объявлены в `guards.c:267` |
+
+**Хорошая новость:** движок автодвижений (`do_auto_moves`) у нас уже есть —
+он нужен был тени на уровнях 4/5/6, и `demo_time`/`demo_index` объявлены там
+же.  То есть демо-уровень — это в основном таблица ходов + ветка «Кидом
+управляет ИИ» в `pop_ctrl`.
+
+**Когда делать:** вместе с интро/титульным экраном, не раньше.  На
+прохождение не влияет.
+
+---
+
+## 6. Порядок работ
+
+Порядок задан пользователем 2026-08-13: **строго по номерам уровней**, а не
+по дешевизне кода — уровень 13 не имеет смысла раньше, чем на него можно
+попасть.
+
+1. ✅ **Уровень 12** — тень: `init_shad_12`, `autocontrol_shadow_level12`,
+   `united_with_shadow`, общий урон, «убил тень — убил себя»,
+   `sword_disappears`, появление плит.  Сделано 2026-08-13, хост-набор
+   `roomtest/tests-host/t_shadow.c` (45 проверок); живой проверки в MAME
+   ещё не было — доска [`L12-SHADOW`](../roomtest/TASKS_OPEN.md#l12-shadow).
+2. ✅ **Переход 12 → 13** (§1.7) — room-триггер вместо двери и флаг
+   `pop_seamless` (не сбрасывать HP).  Сделано там же.
+3. ✅ **Уровень 13** — Джафар: `guard_notice_timer`,
+   `on_guard_killed`/`Jaffar_exit`, три спецкейса loose (§2.4) и
+   `check_fall_flo`.  Плюс СПРАЙТЫ визиря (VIZIER.DAT) — без них он
+   рисовался обычным стражем.  Сделано 2026-08-13, хост-набор
+   `roomtest/tests-host/t_jaffar.c` (44 проверки); живой проверки в MAME ещё
+   не было — доска [`L13-JAFFAR`](../roomtest/TASKS_OPEN.md#l13-jaffar).
+4. **Уровень 14** — довести до комнаты 5 и поставить заглушку вместо ролика;
+   сам ролик — в общую задачу «катсцены».
+5. **Уровень 0 и 15** — отложить: аттракт и защита от копирования на
+   прохождение не влияют.
+
+---
+
+## 7. Сверка констант с ОРИГИНАЛЬНЫМИ данными (сделана 2026-08-13)
+
+Всё ниже снято скриптом прямо с `../SDLPoP/data/LEVELS/res2013.bin` и
+`res2012.bin` — не из головы и не из констант SDLPoP.
+
+### 7.1 Падающие плиты уровня 13 — константы сходятся ТОЧНО
+
+Комнаты, у которых в ряду 2 вообще есть loose:
+
+| комната | loose в колонках | комната снизу |
+|---|---|---|
+| 17 | 2, 3, 4, 5, 6, 7 | **23** |
+| 1  | 2, 3, &nbsp;&nbsp; 5, 6, 7 | **16** |
+| 14 | 2 | 24 |
+
+Связи: `комната 23: up = 17`, `комната 16: up = 1`.  То есть
+`loose_tiles_room_1 = 23` и `room_2 = 16` — это ровно те две комнаты, над
+которыми лежит ПОЛНАЯ гряда плит, а `first_tile = 22, last_tile = 27` — ровно
+ряд 2, колонки 2..7:
+
+```
+комната 23 → сверху 17: 22:LOOSE 23:LOOSE 24:LOOSE 25:LOOSE 26:LOOSE 27:LOOSE   [6/6]
+комната 16 → сверху  1: 22:LOOSE 23:LOOSE 24:empty 25:LOOSE 26:LOOSE 27:LOOSE   [5/6]
+```
+
+Два вывода:
+
+* диапазон 22..27 — **надмножество**: в комнате 1 тайл 24 пустой, и
+  `make_loose_fall` его молча пропустит (проверяет тип тайла).  Копировать
+  константы можно как есть;
+* пара «комната 14 → 24» НЕ входит в спецсобытие намеренно — одна плита, это
+  обычный loose.
+
+**Важное следствие, которого не было в плане:** стартовая комната уровня 13 —
+**23** (`BP_START = 23`, поз 19, dir 0), а `check_fall_flo` зовётся из
+`draw_level_first` → `check_the_end` (seg003:217).  Значит плиты начинают
+сыпаться СРАЗУ при входе на уровень, это его первый кадр, а не событие
+где-то в середине.
+
+### 7.2 Джафар — один страж со skill 9
+
+В `res2013.bin` заполнен ровно один слот стража:
+
+| комната | тайл | ряд, кол | направление | skill |
+|---|---|---|---|---|
+| 1 | 7 | 0, 7 | 255 (влево) | **9** |
+
+И это сходится с `meet_Jaffar`: событие срабатывает, когда Кид уходит ВПРАВО
+из комнаты 3, а `комната 3: right = 1` — то есть ровно туда, где стоит
+Джафар.  Skill 9 у нас поддержан: `NUM_GUARD_SKILLS = 12`, все шесть таблиц
+вероятностей (`guards.c:411..415`) имеют индекс 9.  HP = `tbl_guard_hp[13] = 6`
+(в `pop_level_cold.c` уже стоит).
+
+`Jaffar_exit` тоже проверен: **комната 24, tilepos 0 = `opener`** (кнопка),
+модификатор 0 — то есть `trigger_button(0,0,-1)` жмёт реальную кнопку, а не
+пустой тайл.
+
+### 7.3 Уровень 12 — меч на месте
+
+`комната 15, tilepos 1 = SWORD` — условие подъёма тени
+(`get_tile(15,1,0) == tiles_22_sword`) на наших данных выполняется.
+`комната 18: right = 19` — `sword_disappears` срабатывает при уходе вправо.
+
+Комната 15 целиком (по ней видно всю сцену встречи с тенью):
+
+```
+ряд 0:  floor   SWORD   floor   torch   torch   LOOSE   LOOSE   floor   empty   empty
+ряд 1:   wall    wall    wall   empty   empty   empty   empty    wall   floor   floor
+ряд 2:   wall  opener  pillar   empty   empty   empty   empty    wall  pillar   empty
+```
+
+### 7.4 `pop_loose_tick` действительно убьёт отрицательную фазу
+
+Подтверждено чтением кода: `m = ++pop_loose_modif[pos]; if (m & 0x80) { if (m
+>= 0x84) → сброс в 0 }`.  Для стартового `0xF0..0xFF` первый же тик даёт
+`m >= 0x84` → фаза обнуляется, плита не падает.  **Это и есть та правка №1 из
+таблицы §2.4**, и она обязательна.
+
+### 7.5 `init_shad_12` и байтовое переполнение `y`
+
+`init_shad_12 = {0x0F, 0x51, 0xE8, 0, 0, 0, 0, 0}` → frame 15, x 81,
+**y 232**, вправо, колонка 0, ряд 0, action 0 + `seq 7 (fall)`.  Поле `y` в
+`char_type` — `byte` (беззнаковое), то есть 232 лежит НИЖЕ поля (192), и
+падение уводит его дальше с переполнением байта: тень «падает» из-под экрана и
+появляется сверху.  У нас `pop_char_t.y` тоже `uint8_t` — поведение
+переносится без правок; при портировании просто не «чинить» это как ошибку.
+
+Отдельно про ряд: `curr_row` берётся ИЗ ТАБЛИЦЫ и равен **0**, хотя
+`pop_y_to_row(232)` дал бы −1.  `do_init_shad` копирует семь полей как есть и
+ряд не пересчитывает, так что «согласовать» их — значит разойтись с
+оригиналом.  Закреплено тестом `shadow12_rises_when_sword_gone`.

applications/PoP/docs/levels_plan.md

@@ -0,0 +1,209 @@
+# План: от одного уровня к нескольким (загрузка, переходы, тайлсеты)
+
+Статус: план, 2026-08-01.  Продолжает `PORT_PLAN.md` §7 (Фаза 1: «переходы
+между экранами» → теперь между УРОВНЯМИ).  Текущая точка: `roomtest` играет
+уровень 1 целиком в одной комнате-за-комнатой модели, но уровень нельзя
+ни выбрать, ни закончить.
+
+Источник истины — `../SDLPoP/src/` (правило `../CLAUDE.md`).  Ключевые
+места: `seg000.c: load_lev_spr/play_level_2/init_game`, `seg005.c:
+up_pressed/go_up_leveldoor`, `seg006.c: play_seq → SEQ_END_LEVEL`,
+`seg002.c` (спецсобытия уровней), `data.h:835..850` (потабличные различия
+уровней).
+
+---
+
+## 0. Что уже готово (не проектировать заново)
+
+- **Формат и загрузчик уровня.**  `pop_level.c/.h` читает сырой
+  `res200N.bin` (2305 Б) в отдельную EMM-страницу; путь — параметр
+  `pop_level_load(const char *)`.  Мультиуровневость здесь стоит одной
+  функции формирования имени.
+- **Стартовая позиция уровня** уже разобрана: `pop_level_start_room()`,
+  `pop_level_start_pos()`, `pop_level_start_dir()` — реализованы и пока
+  НЕ вызываются (см. `../roomtest/TASKS_CLOSED.md` L1-START).
+- **Страж по данным уровня**: `pop_level_guard()` (порт `enter_guard`),
+  сохранение состояния между комнатами (`pop_guard_state_save`).
+- **Палитра разложена по слотам ровно как в оригинале** (`pop_pack_kid.py`
+  `build_palette`): env 0x50, wall 0x60, pot 0x40, kid 0x70, меч 0x80,
+  страж 0x90.  Это тот же раскрой, что `set_pal_arr(0x50/0x60)` в
+  `seg000.c:1140..1148`, — значит смена тайлсета не требует переиндексации
+  спрайтов Кида (см. §3).
+- **Все 16 файлов уровней распакованы**: `../SDLPoP/data/LEVELS/res2000..
+  res2015.bin` (0 — демо-уровень).
+
+---
+
+## 1. Что реально различается между уровнями (замер по данным, не по памяти)
+
+Таблицы из `../SDLPoP/src/data.h:840..847` + инвентарь тайлов, снятый прямо
+с `res200N.bin` (маска `fg & 0x1F`):
+
+| Ур. | Тайлсет | Страж | Новое против предыдущих |
+|-----|---------|-------|--------------------------|
+| 1 | dungeon | обычный | — (текущая база) |
+| **2** | **dungeon** | **обычный** | **ничего нового: тот же набор объектов минус меч** |
+| 3 | dungeon | СКЕЛЕТ | чомперы |
+| 4 | palace | обычный | **тайлсет palace**, зеркало (спецсобытие `mirror_level`) — **СДЕЛАНО** |
+| 5 | palace | обычный | новых ТАЙЛОВ нет; спецсобытие **тень крадёт зелье** (комната 24) — [L5-SHADOW](../roomtest/TASKS_OPEN.md#l5-shadow) |
+| 6 | palace | ТОЛСТЫЙ | падение на входе (спецсобытие) |
+| 7 | dungeon | обычный | — |
+| 8, 9 | dungeon | обычный | — |
+| 10, 11 | palace | обычный | — |
+| 12 | dungeon | ТЕНЬ | seamless-выход (комната 23), исчезающий меч |
+| 13 | dungeon | ВИЗИРЬ | мышь, особый выход |
+| 14 | palace | нет | — |
+| 15 | dungeon | нет | финал |
+
+Прямое следствие для порядка работ: **уровень 2 не требует ни одного нового
+ассета и ни одной новой механики** — он проверяет ровно машинерию перехода.
+Это и есть первый шаг.
+
+Прочие потабличные различия, которые придётся завести массивами по 16:
+`tbl_level_type` (тайлсет), `tbl_guard_type` (−1 = стражей нет),
+`tbl_guard_hp`, `tbl_level_color` (вариантные палитры, 1.3), `tbl_entry_pose`.
+
+---
+
+## 2. Шаг 1 — машинерия перехода (цель: уровни 1 → 2 → 3) — **СДЕЛАН 2026-08-04**
+
+> **Итог.**  Всё в этом разделе портировано и проверено в MAME: уровень 1 →
+> Shift+L → уровень 2 (комната 5, дверь захлопывается за спиной, большие
+> колонны рисуются) → уровень 3.  Разбор что именно сделано и что по
+> уровню 2 осталось — `../roomtest/TASKS_CLOSED.md`, запись **L2**.
+>
+> Сверх плана пришлось доделать две вещи, без которых уровень 2 не играется:
+> **`find_start_level_door`** (стартовый тайл уровня 2 — это правая половина
+> двери уровня) и **большую склянку** `add_life` (тип зелья 2, комната 20).
+
+Порядок именно такой; каждый пункт проверяем в MAME отдельно.
+
+**2.1 Выход с уровня.**  Портировать `up_pressed()` ветку двери
+(`seg005.c:410..423`) + `go_up_leveldoor()` (`seg005.c:497`): дверь рядом
+(при/за/перед персонажем) И `drawn_room != level.start_room` И створка
+открыта полностью (`curr_room_modif >= 42` — вариант `fix_exit_door`) →
+`Char.x = x_bump[...] + 10`, направление влево, `seq_70_go_up_on_level_door`.
+Затем оживить опкод `0xF1 END_LEVEL` в `play_seq` (`../roomtest/pop_kid.c:418`
+— сейчас пустой `break`): `++pop_next_level`, как `seg006.c:662`.
+
+**2.2 Цикл уровня.**  В `main()` после тика: `if (pop_next_level !=
+pop_current_level) → load_level(pop_next_level)`.  Порядок сноса/подъёма
+состояния (порт `load_lev_spr` + `play_level_2`):
+`pop_level_free` → `pop_level_load("LEVELS\\res200%d.bin")` →
+`pop_trob_reset` → `pop_guard_reset` → сброс tile-override'ов
+(`ovr_*` в `roomtest.c`) → `enter_room(pop_level_start_room())` →
+`kid_init(поза/позиция/направление из данных уровня)`.
+**HP через уровень переносится** (в оригинале `hitp_beg_lev`), не сбрасывать
+в максимум — сверить с `seg000.c` `init_game`/`play_level_2`.
+
+**2.3 Стражи по уровню.**  Завести `tbl_guard_type[16]`/`tbl_guard_hp[16]`;
+`-1` = стражей на уровне нет (уровни 14, 15) — `pop_guard_enter` обязан это
+понимать, иначе на 14-м полезут стражи из мусора.  Для шага 1 (уровни 2, 3)
+достаточно обычного стража, но проверку `-1` заложить сразу.
+
+**2.4 Чит «следующий уровень» (Shift+L).**  Реализуется ровно тем же
+`pop_next_level` — и без него отладка уровней превращается в прохождение
+игры руками.  Делать в этом же шаге, не позже (см. §4).
+
+**Приёмка шага 1:** дверь уровня 1 → уровень 2 играется целиком → его дверь
+→ уровень 3 стартует (чомперы могут быть ещё не портированы — тогда
+фиксируем как известное ограничение, а не «баг»).
+
+---
+
+## 3. Шаг 2 — второй тайлсет (palace, уровни 4+) — **СДЕЛАН**
+
+> **Закрыт (ревизия 2026-08-11 по коду).**  В дереве есть всё, что
+> проектировалось ниже: `pop_pack_bg.py` печёт ДВА набора атласов
+> (`pop_*` из VDUNGEON, `pal_*` из VPALACE, каскад с обменом приоритетов),
+> `pop_bg_load` принимает тип набора и ставит флаг `pop_palace`, по которому
+> `pop_room.c` выбирает дворцовую ветку (`wall_pattern` дворца — сплошная
+> заливка + пять mono-полос, `PALACE_WALL_MONO_IDS`), решётчатые тайлы
+> 25-29 есть и в `tile_table` (`pop_tile.c`), и в коллизии — `tile_is_floor`
+> совпадает с `seg006:0628` тайл в тайл.  Уровень 4 проходится smoke-тестом.
+>
+> Текст ниже оставлен как справочник по раскрою палитры и по тому, почему
+> смена тайлсета — это перезапись 32 записей, а не переиндексация спрайтов.
+
+**Ассеты.**  `toolchain/pop_pack_bg.py` уже читает PNG каскадом
+VDUNGEON→VPALACE (та же логика, что в игре), но печёт ОДИН набор атласов
+(`pop_env0..4.atl`, `pop_wall.atl`, `pop_fore.atl` ≈ 75 КБ).  Нужен второй
+набор из VPALACE (`pal_env*.atl` / `pal_wall.atl`), плюс `torch_debris` —
+тайл, который встречается только на palace-уровнях.  По EMM это ещё ~6
+страниц при бюджете ~3.3 МБ — не проблема.
+
+**Палитра — главный технический вопрос, и он уже решён раскроем.**
+Тайлсет живёт в слотах `0x50..0x5F` (env) и `0x60..0x6F` (wall); Кид, меч,
+страж, склянки — в других слотах.  Значит смена тайлсета = перезапись 32
+записей палитры (`gfx_pal_set` на обе страницы, как `flash_bg` в
+`roomtest.c`), а НЕ перезагрузка `kid.pal` и не переиндексация спрайтов.
+Сделать `pal_dungeon.bin` / `pal_palace.bin` (по 32 записи) и грузить при
+смене типа уровня.  Проверить артефактом: скриншот palace-комнаты против
+рендера `render_room.py` для того же уровня.
+
+**Вариантные цвета уровней** (`tbl_level_color`, `level_var_palettes` — это
+уже 1.3, в 1.0 их нет): по той же механике, тот же диапазон слотов.  Решение
+на будущее — сначала базовые два тайлсета, потом при желании цвета.
+
+**Выбор набора в коде.**  `pop_bg_load()` сейчас грузит фиксированные имена;
+превратить в `pop_bg_load(type)` с двумя таблицами имён + выгрузка старых
+атласов при смене типа (`atlas_free`).  Переключение — только на границе
+уровня, не в кадре.
+
+---
+
+## 4. Читы SDLPoP: что взять на следующем этапе
+
+Из `../SDLPoP/README.md` (раздел Cheats).  У нас уже есть: **K** — убить
+стража, **I** — бессмертие (наш, в оригинале нет), **S** — выдать меч (наш),
+**+/−** — обход комнат (`ROOMNAV`, наш).
+
+**Брать сразу вместе с переходами уровней** (без них отладка дороже самой
+работы):
+
+| Чит | Что даёт | Цена |
+|-----|----------|------|
+| **Shift+L — следующий уровень** | единственный вменяемый способ тестировать уровни 2..15 | тривиально: `++pop_next_level` из §2.2 |
+| **R — воскресить Кида** | у нас респавн по ↑ + таймаут; порт `resurrect` ближе к оригиналу и не мешает управлению | низкая |
+| **Shift+S / Shift+T — +1 HP / +максимум** | отладка боёвки без «ровно трёх попыток»; честная замена нашему читу бессмертия | низкая, HP-машинерия уже есть |
+| **[ и ] — сдвинуть Кида на пиксель** (debug-чит SDLPoP) | прямо бьёт в наш класс багов «окклюзия/шов на один пиксель» — воспроизведение позы без ловли момента | тривиально |
+
+**Брать во вторую очередь:**
+
+| Чит | Почему позже |
+|-----|--------------|
+| **H / J / U / N + Ctrl+B — смотреть соседние комнаты** | требует честной модели `drawn_room ≠ Kid.room` (наш S3-straddle, каркас есть: `update_kid_render_dx`).  Зато потом заменяет самодельный `ROOMNAV` и попутно закрывает straddle-задачу |
+| **Shift+W — медленное падение (feather)** | ветка `JMP_IF_FEATHER` (опкод `0xF7`) в `play_seq` уже есть, но не проверена ничем — чит станет её единственным тестом |
+| **C / Shift+C — номера комнат** | у нас номер рисуется палочками именно потому, что текст тянет 2 КБ знакогенератора в W2 (`roomtest.c`).  Ждёт своего шрифта |
+
+**Не брать:** `Shift+I` (переворот экрана), `Shift+B` (blind mode) —
+развлекательные, к отладке порта отношения не имеют.  `−/+` (время) — нужен
+таймер уровня, которого у нас нет (Фаза 6).
+
+**Отдельно, дорого, но очень ценно — `F6`/`F9` (quicksave/quickload точного
+состояния).**  Это сериализация `Char` + `room_modif` всех комнат + trob'ов +
+состояния стражей.  Даёт то, чего нам сейчас сильно не хватает:
+воспроизводимый регресс в MAME («вот кадр, где баг») вместо ручного подхода
+к позиции.  Кандидат сразу после того, как заработают уровни.
+
+---
+
+## 5. Риски и что проверить артефактом до кодинга
+
+1. **Размер кода.**  Замер сборки 2026-08-01: `_CODE` 25 119 Б,
+   куча ~2.4 КБ, банк 2 (`pop_bg`) 13 792 / 16 384, банк 3 (`pop_map`)
+   6 331, банк 1 (`guards`) 1 896, банк 4 (`pop_gdraw`) 2 236.  Чомперы,
+   зеркало, скелет и второй тайлсет пойдут в банк 2 — там осталось 2.6 КБ.
+   **Прежде чем начинать §3, посчитать, куда лягут новые тайлы**, иначе
+   повторится история «банк 2 упёрся в потолок» (коммит 2f3e854).  Свободные
+   номера банков есть (5+), гранулярность — файл.
+2. **Спецсобытия уровней** (`seg002.c`: `level3_set_chkp`, `sword_disappears`,
+   `Jaffar_exit`, зеркало, мышь) — их НЕ надо портировать заранее.  Для
+   уровней 2 и 3 нужен только чекпойнт уровня 3.  Остальное — по мере
+   подхода к уровню.
+3. **Чомперы** (уровень 3 и почти все дальше) — отдельная механика
+   (`animate_chomper` + коллизия + смерть); шаблон работы тот же, что у
+   пик/ворот, см. `gates_spikes_plan.md`.
+4. **`tbl_guard_type = -1`** на уровнях 14/15: без проверки страж
+   «появится» из неинициализированных данных.
+5. **Уровень 0 (демо)** существует в данных, но в скоуп не входит.

applications/PoP/docs/loose_floors_plan.md

@@ -1,143 +0,0 @@
-# Loose floors (проваливающиеся полы) — план порта
-
-Разбор SDLPoP (seg007 loose/trob/mob, seg008 draw_loose).  ПЛАН, ещё не
-реализовано.  Тайл в комнате 1: `[2,6] = 0x0B = tiles_11_loose`.
-
-## 1. Хранение состояния
-
-- **Тип тайла**: `curr_room_tiles[tilepos] & 0x1F == 11` (tiles_11_loose).
-  Бит `0x20` = «solid» loose (авто-падающий вариант, ур.13 — от шага НЕ
-  падает).  После падения тайл → `0` (tiles_0_empty).
-- **Модификатор** `curr_room_modif[tilepos]` = состояние анимации:
-  - `0` — покой (обычный loose-пол);
-  - `0x80..0x83` — **трясётся** (бит7); за ~4 кадра затухает обратно в 0;
-  - `1..11` — **обратный отсчёт до падения** (на нём что-то стоит);
-    достигает `loose_floor_delay = 11` → падает.
-
-## 2. Анимация тряски (shake) — когда включается
-
-- **Триггер = do_knock** (seg007:0FE0): на ЖЁСТКОМ приземлении в кадрах
-  посадки играет `SEQ_KNOCK_DOWN` → взводит `knock` → `check_knock()` →
-  `do_knock(room, curr_row − (knock>0))`.
-- `do_knock(room, row)`: по всем колонкам ряда — если тайл loose →
-  `loose_make_shake()`.
-- `loose_make_shake()` (seg007:0FB4): если `modif==0` (и не ур.13) →
-  `modif = 0x80`, `add_trob(type 1)`.
-- **Отсюда кейс пользователя**: Kid падает/приземляется на `[2,4]` →
-  do_knock трясёт ВСЕ loose-тайлы ряда 2 → `[2,6]` трясётся.  (Через
-  knock-смещение ряда может задеть и соседний ряд.)
-- `animate_loose` (кадрово): `++modif`; при бите7 трясёт до `>=0x84` →
-  сброс в 0, `trob.type=-1`.  `loose_shake()` играет звук
-  (sound 20/21/22) по таблице `loose_sound[]`.
-
-## 3. Анимация падения (fall) — когда включается
-
-- **Триггер = make_loose_fall(1)** (seg007:0EF6), вызывается когда:
-  - Kid СТОИТ на loose-тайле — `check_press()` (seg006): кадр с
-    FRAME_NEEDS_FLOOR над loose → make_loose_fall(1);
-  - зацеп/подтягивание на loose (`check_grab`, `check_jump_up`);
-  - пробой сверху: кадр 79 (jumphang) над loose → make_loose_fall(1);
-  - авто-падающие (ур.13) — `make_loose_fall(-(prandom&0x0F))`.
-- `make_loose_fall(modifier)`: если НЕ solid (`tiles & 0x20 == 0`) и
-  `(sbyte)modif <= 0` → `modif = modifier`, `add_trob(type 0)`.
-- `animate_loose`: `++modif`; когда `modif >= 11` (loose_floor_delay) →
-  `remove_loose()` (тайл → empty) + `add_mob()` (спавн падающего куска).
-
-## 4. Падающий кусок (mob)
-
-- `add_mob()` кладёт `curmob` в `mobs[]` (до 14).  `do_mobs()` каждый
-  кадр: `move_mob()` (гравитация, y растёт) + `check_loose_fall_on_kid()`
-  (урон Киду/страже, если попал).
-- Приземление куска → тайл под ним `curr_room_tiles[...] = tiles_14_debris`
-  (seg007 move_mob:1053).  Т.е. **loose(11) упал → сверху empty(0), снизу
-  debris(14)**.
-
-## 5. Отрисовка по статусу
-
-- Куски тайла: `loose_fram_left[]={41,69,41,70,70,41,41,41,70,70,70,0}`,
-  `loose_fram_right[]={42,71,...}`, `loose_fram_bottom[]={43,73,...}`
-  (env-спрайты, seg008:518/596/608).
-- Индекс кадра = `get_loose_frame(modifier)` (seg008): `0` = ровный
-  (41/42/43); `1..10` = дрожащие варианты (69–74); при бите7/большой
-  задержке — низкие индексы.
-- **До падения**: рисуем loose с `get_loose_frame(modif)` (0 = ровно,
-  иначе колеблется).  **После**: сверху empty, снизу debris(14) — обычная
-  статическая отрисовка (у нас уже есть tile 0x0E/14 debris в tile_table).
-
-## 6. Что нужно в нашем движке (сейчас НЕТ)
-
-Наш `pop_bg` рисует комнату СТАТИЧЕСКИ один раз.  Loose-полы требуют
-**динамического тайлового слоя**:
-1. **Массив модификаторов** `room_modif[30]` (у нас есть `bg[30]` — можно
-   переиспользовать/рядом) — состояние каждого тайла.
-2. **Очередь trob** (список анимируемых тайлов) + `animate_loose` пер-кадр
-   → перерисовка ТОЛЬКО изменившихся тайлов (как heal-прямоугольник Kid).
-3. **make_loose_fall / do_knock / loose_make_shake** — триггеры (из
-   физики Kid: приземление→knock, стойка на loose→fall).
-4. **mob-система** (падающий кусок): минимум 1–2 mob'а, гравитация,
-   приземление → debris.  Урон Киду (`check_loose_fall_on_kid`) — можно
-   Фазой 2.
-5. **Перерисовка тайла**: `draw_tile(row,col)` у нас уже умеет loose
-   (`code==11`, `loose_fram_*` в env) — нужно вызывать его выборочно с
-   текущим модификатором (сейчас draw_tile берёт статический bg).
-
-**Порядок реализации (предложение):**
-- L1: room_modif[] + выборочная перерисовка тайла по модификатору
-  (draw_loose с get_loose_frame) — статика→динамика одного тайла.
-- L2: trob-очередь + animate_loose (тряска по do_knock на приземлении).
-- L3: make_loose_fall (стойка на loose) + отсчёт + remove → empty.
-- L4: mob (падающий кусок → debris снизу).
-- L5: урон Киду от падающего куска.
-
-## Конкретика из SDLPoP (сверено 2026-07-18, готово к реализации)
-
-Таблицы (seg008.c), индекс = `get_loose_frame(modif)`:
-- `loose_fram_left[]  = {41,69,41,70,70,41,41,41,70,70,70,0}`
-- `loose_fram_right[] = {42,71,42,72,72,42,42,42,72,72,72,0}`
-- `loose_fram_bottom[]= {43,73,43,74,74,43,43,43,74,74,74,0}`
-- `get_loose_frame(m)`: если `(m&0x80)` (или delay>11) → `m&=0x7F; if(m>10) return 1;` → `return m;`
-- `y_loose_land[] = {2,65,128,191,254}` (mob), `loose_floor_delay = 11`.
-
-Триггеры (call-sites):
-- **make_loose_fall(modifier=1)** — из `check_press()` (seg006): когда Kid
-  СТОИТ на тайле (FRAME_NEEDS_FLOOR, action < hang_climb / turn / bumped) и
-  `get_tile_at_char()==11`; ИЛИ `frame==79` (прыжок вверх) и
-  `get_tile_above_char()==11` (пробой сверху).  `tile_is_floor(11)==1` —
-  Kid стоит на loose (start_fall НЕ зовётся).  Тело:
-  `if(!(tile&0x20) && (sbyte)modif<=0){ modif=modifier; add_trob(type0); }`
-- **do_knock(row)** — на ЖЁСТКОМ приземлении (SEQ_KNOCK_DOWN→check_knock,
-  seg003): по всем колонкам ряда `if(tile==11) loose_make_shake()`
-  (`if(modif==0){ modif=0x80; add_trob(type1); }`).
-- **animate_loose** (каждый кадр, seg007:816): `++modif`; если `&0x80`
-  (тряска): `if(modif>=0x84){modif=0; trob=-1;}`; иначе (отсчёт):
-  `if(modif>=11){ remove_loose(tile→0); trob=-1; add_mob(); } else shake`.
-
-## Интеграция в наш движок (roomtest) — подход
-
-Наш движок ПЕКЁТ комнату один раз (двойной буфер: своя ОЗУ-копия на
-страницу).  Loose требует динамики + общего состояния pop_map↔pop_bg:
-1. **Общая МУТАБЕЛЬНАЯ копия комнаты**: roomtest.c держит `uint8_t
-   room_fg[30]` (копия room1_fg) и передаёт ОДИН указатель и в
-   `pop_room_draw`, и в `pop_map_set` → мутации loose видны обоим.
-   (Сейчас g_fg — `const`; сделать неконстантным.)
-2. **Состояние**: `uint8_t pop_loose_modif[30]` (0 / 0x80.. / 1..11).
-3. **Модель** (pop_map): `check_press()` в `pop_phys_tick` (make_loose_fall
-   при стоянии на 11), `animate` каждый кадр.
-4. **Перерисовка** (pop_bg, на back-странице каждый кадр):
-   - тряска/отсчёт (код всё ещё 11): `gfx_heal(tile rect)` (вернуть
-     печёный фон) + нарисовать loose-кадр (left/right/bottom по
-     get_loose_frame) банком SPRITE;
-   - падение (11→0): mutate `g_fg[pos]=0` + «запечь пустоту» на ОБЕИХ
-     страницах (bake-счётчик 2: чёрный bar + draw_tile empty банком NORMAL
-     на текущей странице 2 кадра подряд) → дальше heal показывает пусто.
-5. **L4 mob**: падающий кусок → debris(14) снизу (y_loose_land); пока
-   отложено — упавший loose = пусто.  **L5** урон — позже.
-
-Риск: перерисовка динамического тайла в двойном буфере (per-page heal +
-bake) — единственное тонкое место; остальное — прямой порт логики выше.
-
-## Связанные
-
-Триггеры завязаны на физику Kid ([[pop_hang_state]] check_press/check_grab,
-приземление land/SEQ_KNOCK_DOWN).  Отрисовка — [[pop_fore_layer]] /
-[[pop_background_strategy]] (draw_tile уже знает loose_fram_*).

applications/PoP/docs/midtable_analysis.md

@@ -0,0 +1,275 @@
+# Слои отрисовки: как устроен оригинал и чего стоит порт
+
+Разбор 2026-08-13, по `../SDLPoP/src/seg008.c`.  Повод — семь дефектов
+падающих плит на уровне 13, из которых три оказались не багами кода, а
+следствием того, что у нас нет слоя, в котором объекты и куски тайлов
+сортируются между собой.  Решение по этому документу ещё не принято.
+
+---
+
+## 1. Как это работает в оригинале
+
+### 1.1 Три таблицы, а не «слои»
+
+`draw_tables` (seg008:1373) рисует ровно в таком порядке:
+
+```
+restore_peels();
+draw_wipes(0);
+draw_table(0);   // BACKTABLE
+draw_table(3);   // MIDTABLE
+draw_wipes(1);
+draw_table(1);   // FORETABLE
+```
+
+Это грубое разделение на три уровня глубины.  Куда попадёт кусок тайла,
+решает переменная `ptr_add_table`, которую вызывающий переставляет перед
+`draw_tile*`: по умолчанию `add_backtable`, в оверлее кромки —
+`add_midtable` (`draw_other_overlay`, seg008:1499), а `add_foretable`
+вызывается явно и точечно.
+
+### 1.2 Объекты живут НЕ в таблицах, а в objtable — и привязаны к ТАЙЛУ
+
+Персонажи, падающие куски, мечи, брызги попадают в `objtable`, и у каждой
+записи есть поле `tilepos` — тайл, которому объект принадлежит.
+
+Ключевое: объекты рисуются **не отдельным проходом после фона**, а ВНУТРИ
+обхода тайлов.  В `redraw_needed_tile` (seg008:207) стоит:
+
+```c
+if (tile_object_redraw[tilepos]) {
+    if (tile_object_redraw[tilepos] == 0xFF)
+        draw_objtable_items_at_tile(tilepos - 1);
+    draw_objtable_items_at_tile(tilepos);
+    tile_object_redraw[tilepos] = 0;
+}
+if (redraw_frames_fore[tilepos]) draw_tile_fore();
+```
+
+То есть на каждом тайле: сначала его фоновые куски, потом объекты ЭТОГО
+тайла, потом его передние куски.
+
+### 1.3 Порядок глубины складывается из ТРЁХ независимых механизмов
+
+| механизм | что даёт |
+|---|---|
+| порядок обхода тайлов: ряды **2, 1, 0**, колонки 0..9 (seg008:129) | тайл, обойдённый позже, рисуется поверх |
+| сортировка объектов ВНУТРИ одного тайла (`sort_curr_objs`, seg008:1553) | кто из объектов одного тайла поверх кого |
+| три таблицы back/mid/fore | грубая глубина для кусков тайлов |
+
+Сортировка внутри тайла (`compare_curr_objs`, seg008:1572) — пузырьком, и
+правил в ней три:
+
+```
+объект типа 1 (ТЕНЬ) — всегда первым;
+оба объекта — падающие плиты (0x80):  y1 < y2   → по УБЫВАНИЮ y;
+любая другая пара:                    y1 > y2   → по ВОЗРАСТАНИЮ y.
+```
+
+Обратный порядок для пары плит — не описка: две плиты из `loose_fall` летят
+в 6 пикселях друг от друга, и верхняя обязана лечь поверх нижней.
+
+### 1.4 Что из этого следует
+
+**«Сортируемый midtable» — неточное имя.**  Глобальной сортировки среднего
+слоя в оригинале нет.  Есть привязка объекта к тайлу и сортировка внутри
+тайла; всё остальное решает порядок обхода.  Это принципиально дешевле
+общей сортировки: объектов на один тайл обычно 1-2.
+
+---
+
+## 2. Что делаем мы
+
+Наш кадр — жёсткая последовательность проходов, без привязки объектов к
+тайлам:
+
+```
+фон:      pop_loose_tick (физика кусков) -> pop_process_trobs -> pop_redraw_needed
+                                                  -> редрой шва
+объекты:  pop_loose_mob_draw   (куски ПОД Kid, отсортированы по y между собой)
+          pop_char_draw(OPP/KID)  (порядок задаёт guard_over_kid)
+          pop_loose_mob_draw_over (куски ПОВЕРХ Kid)
+перед:    pop_fore_over_char  — ТОЛЬКО в окне вокруг персонажа
+```
+
+Отличия, из которых растут все три оставшихся дефекта:
+
+1. **Объект не знает своего тайла.**  Глубина «кусок против Кида» считается
+   отдельной формулой (`pop_room.c`, поле `defer`), а «кусок против КУСКА
+   ТАЙЛА» не считается вовсе — куски тайлов рисуются раньше всех объектов.
+2. **Передний слой считается только вокруг персонажа.**  Это наша
+   оптимизация (memory `pop_fore_layer_cost`: полный проход стоил 78 %
+   кадра).  Падающая плита в чужом углу комнаты передних частей тайлов
+   поверх себя не получает — отсюда «плита перед колонной».
+3. **Оверлей кромки идёт после персонажей** и потому безусловно поверх
+   всех, тогда как у оригинала он в midtable и сортируется.
+
+---
+
+## 3. Что затрагивает порт
+
+| участок | объём правки |
+|---|---|
+| `pop_room.c` — куски | привязать к тайлу, убрать `defer`, убрать собственную сортировку |
+| `pop_cdraw.c` — персонажи | то же: объект вместо слота, привязка к тайлу |
+| `pop_bg.c` — `overlay_mid_tile`, `fore_only_tile`, `ceil_over_kid_tile` | вызов из обхода тайлов, а не из отдельного прохода |
+| `pop_redraw.c` — пометки | добавить «на этом тайле есть объект» (порт `tile_object_redraw`) |
+| `roomtest.c` — главный цикл | вместо трёх проходов один: обход тайлов с объектами внутри |
+| окно fore-клипа (`pop_t_fclip_*`) | смысл меняется: клип по тайлу, а не по персонажу |
+
+Плюс новая структура objtable и её сортировка — но маленькая, на тайл.
+
+---
+
+## 4. Плюсы
+
+* **Уходят разом** MOB-CLIP-RIGHT, MID-OVERLAY-LAYER и «плита перед
+  колонной»: все три — следствие отсутствия привязки к тайлу, а не
+  самостоятельные баги.
+* **Уходят подпорки.**  Перерисовка соседнего тайла поверх куска,
+  `defer`, ручная сортировка кусков, отдельный проход `draw_over` —
+  всё это заменяется одним механизмом.
+* **Совпадение с оригиналом по построению.**  Дальше любой вопрос «что
+  поверх чего» решается чтением seg008, а не экспериментом в MAME.
+* **Возможный выигрыш по кадру.**  Сейчас fore-проход считает окно вокруг
+  персонажа и всё равно перебирает до девяти тайлов; при привязке к тайлу
+  передние части рисуются только там, где реально есть помеченный объект.
+  Но это НАДО ЗАМЕРИТЬ, а не обещать.
+
+---
+
+## 5. Минусы и риски
+
+* **Риск регресса широкий.**  Трогается порядок отрисовки ВСЕГО: Кид,
+  соперник, меч, брызги, зеркало, куски, оверлеи, полоса потолка.
+  Уровни 1-11 приняты и держатся на текущем порядке.
+* **Наша оптимизация fore-окна может не пережить порт в прежнем виде.**
+  Она даёт 3.2x на самом дорогом проходе (memory `pop_fore_layer_cost`).
+  Если привязка к тайлу заставит рисовать передние части шире — можно
+  потерять больше, чем выиграть.
+* **Дабл-буфер.**  У оригинала один экран с dirty-rect, у нас две страницы
+  со своими копиями фона и heal.  Пометка «на тайле есть объект» обязана
+  быть счётчиком страниц, как остальные наши пометки, — иначе объект
+  перерисуется на одной странице и не перерисуется на другой.
+* **Банки.**  Отрисовка размазана по трём банкам (`pop_bg` 2, `pop_cdraw` 4,
+  `pop_room` 7) плюс резидент.  Единый обход тайлов с объектами внутри
+  означает, что цикл обхода зовёт код из всех трёх — надо проверить, что не
+  упрёмся в границы банков и трамплины.
+* **Объём.**  Это не правка, а этап: сопоставимо с тем, что делалось для
+  fore-слоя.
+
+---
+
+## 6. Развилки
+
+**A. Полный порт** — objtable с привязкой к тайлу, сортировка внутри тайла,
+объекты внутри обхода.  Максимально близко к оригиналу, максимальный риск и
+объём.
+
+**B. Частичный: только привязать КУСКИ к тайлам.**  Персонажей оставить как
+есть.  Закрывает MOB-CLIP-RIGHT и «плиту перед колонной», не трогает
+проверенный порядок персонажей.  Дешевле и безопаснее; MID-OVERLAY-LAYER
+остаётся.
+
+**C. Отложить** до этапа BG-ONCE и делать вместе — там всё равно
+пересматриваются слои, и два пересмотра подряд дороже одного.
+
+Рекомендация: **B или C**.  Вариант A целиком оправдан только если мы
+одновременно берёмся за BG-ONCE — тогда это один пересмотр слоёв вместо
+двух, и замер кадра делается один раз.
+
+---
+
+## 7. ЗАМЕРЫ (сделаны 2026-08-13, уровень 13)
+
+Метод — маркеры-пустышки в РЕЗИДЕНТЕ вокруг измеряемого вызова плюс
+брейкпоинты с `printf totalcycles` (memory `z80_profiling_method`).  В
+банковый код брейкпоинт ставить нельзя: 0xC000 — общее окно всех банков.
+
+| что | такты | доля логического кадра |
+|---|---|---|
+| логический кадр целиком | **1 289 526** | 100 % |
+| `pop_redraw_needed` | **978** | 0,08 % |
+| **fore-проход, ОДИН персонаж** | **128 778** | **10 %** |
+
+Плюс два счётчика за прогон ~229 логических кадров:
+
+* fore-проход вызван **10 раз** — на 96 % кадров он не выполняется вовсе
+  (пропуск неизменившегося персонажа, `pop_char_skip_mask`).  Средняя цена
+  по кадру выходит ~0,4 %, но КАК ТОЛЬКО персонаж движется — платим все 10 %
+  каждый кадр, и при двух персонажах это ~20 %;
+* **максимум объектов на одном тайле = 2** (комната 16, пара из
+  `loose_fall`: плита сбивает плиту, дальше летят обе).  В комнате 23, где
+  гряда падает в пустоту, максимум 1.
+
+### 7.1 Что эти числа меняют в оценке
+
+**Сортировка внутри тайла — бесплатна.**  Два объекта, пузырёк на два
+элемента.  Возражение против варианта A, которое закладывалось в §5, снято.
+
+**`pop_redraw_needed` можно не считать вовсе.**  978 тактов против 128 778 у
+fore-прохода — соотношение 131 к 1.
+
+**Единственный настоящий риск порта — окно клипа fore-прохода.**  Если
+привязка объектов к тайлам заставит рисовать передние части шире нынешнего
+окна вокруг персонажа, мы потеряем 10 % кадра, и потеряем их НА ДВИЖЕНИИ,
+когда бюджет и так самый напряжённый.
+
+### 7.2 Насколько узко оригинал помечает передний слой — ВЫЯСНЕНО
+
+Пометки `redraw_frames_fore[]` ставит ровно одна функция — `set_redraw_fore`
+(seg007:0550), и зовут её из трёх мест.  Ни в одном нет «пометить всё».
+
+**Персонаж — `redraw_at_char` (seg003:0576).**  Помечается ПРЯМОУГОЛЬНИК
+футпринта:
+
+```c
+for (tile_row = x_top_row; tile_row <= char_bottom_row; ++tile_row)
+    for (tile_col = x_col_left; tile_col <= x_col_right; ++tile_col)
+        set_redraw_fore(get_tilepos(tile_col, tile_row), 1);
+```
+
+с двумя уточнениями: при вынутом мече прямоугольник расширяется на колонку в
+сторону клинка, а для КИДА берётся объединение с футпринтом ПРОШЛОГО кадра
+(`prev_char_*`) — чтобы освободившиеся тайлы тоже вернули свои передние
+части.
+
+**Падающий кусок — `draw_mob` (seg007:~1147).**  Каждый кадр помечается
+СОСЕД СПРАВА (`++tile_col`), и второй тайл, если кусок висит на границе
+рядов:
+
+```c
+++tile_col;
+tilepos = get_tilepos(tile_col, tile_row);
+set_redraw2(tilepos, 1);
+set_redraw_fore(tilepos, 1);
+top_row = y_to_row_mod4(ypos - 18);
+if (top_row != tile_row) { ... то же для top_row ... }
+add_mob_to_objtable(ypos);
+```
+
+**Анимация тайла — `draw_trob` (seg007:01E6):** один тайл.
+
+**Вывод: пометка переднего слоя в оригинале НЕ ШИРЕ нашего окна.**  Она
+пообъектная — футпринт персонажа и 1-2 тайла на кусок.  Значит полный порт
+objtable **не отнимает** нашу оптимизацию fore-окна, а формализует её:
+вместо «окно вокруг персонажа» будет «тайлы, помеченные объектами», что
+как минимум не шире, а для одиночного куска заметно уже.
+
+Риск, вокруг которого крутилась вся оценка, снят.
+
+### 7.3 Побочный результат: готовый рецепт для MOB-CLIP-RIGHT
+
+`draw_mob` даёт точный ответ на вопрос, как оригинал прячет правую часть
+куска за соседним полом: он НЕ рисует сосед поверх куска (наша подпорка) и
+НЕ полагается только на `clip.right`.  Он помечает соседний тайл СРАЗУ
+двумя пометками — `set_redraw2` (фон) и `set_redraw_fore` (передний слой).
+Дальше порядок делает всё сам: фон соседа рисуется ДО куска, его передние
+части — ПОСЛЕ.
+
+Это же закрывает и «плиту перед колонной»: передние части соседнего тайла
+(колонна) ложатся поверх куска, потому что тайл помечен.
+
+**Рекомендация после разбора: вариант A (полный порт).**  Оба возражения
+против него сняты замерами и этим разбором — сортировка внутри тайла
+бесплатна (максимум 2 объекта), окно переднего слоя не теряется.

applications/PoP/docs/perf_backlog.md

@@ -0,0 +1,335 @@
+# Оптимизация отрисовки — что НЕ сделано (замеры на 2026-08-10)
+
+Список отложенных идей с измеренной ценой.  Всё измерено брейкпоинтами в
+MAME (`z80_profiling_method`) на роомтесте, уровень 1 комната 1.
+
+Прежде чем брать что-то отсюда — перечитать «Как мерить» ниже: половина
+прошлых гипотез не подтвердилась, и подтвердились не те, что казались
+очевидными.
+
+## Как мерить (иначе цифры не сходятся)
+
+- **Такт `totalcycles` ≠ номинальный T-такт Z80.**  У ОЗУ Sprinter
+  wait-state'ы, замеренная стоимость ≈ **2,4× справочной** (`get_tile`: 574
+  против 1 422).  Считать по таблице тактов нельзя.  Подробности —
+  memory `sprinter_wait_states_2x`.
+- **Растровый кадр = 430 000 тактов.**  Главный цикл спейсится тремя
+  `gfx_wait_vsync`, поэтому работа сверх 430 000 стоит СРАЗУ целый лишний
+  кадр.  Граница дискретная: 3 растровых кадра на логический или 4.
+- **Адреса символов меняются после КАЖДОЙ пересборки** (`roomtest.map`,
+  `bank*_*.sym`).  Маркер со старым адресом молча не срабатывает, и разбивка
+  выглядит правдоподобно, но врёт.
+- **Сцена между сессиями не воспроизводится точно**: позиция Кида до
+  пикселя, состояние плиты (2,6), фаза факелов.  Сравнивать «до/после» можно
+  только по ОДНОЙ функции с одинаковыми входами, а не по общей работе за
+  кадр.
+- Кто делит: брейкпоинт на `__divsint`/`__divuint`/`__divuchar` с печатью
+  адреса возврата — `bpset <addr>,1,{printf "ret=%04X\n",w@(sp); g}`.  Если
+  адрес возврата в банке (>= 0xC000), поставить тот же брейкпоинт с условием
+  `w@(sp)==<адрес>` и БЕЗ `g`: машина встанет с нужным банком в окне, и
+  `dasm` покажет вызывающего.
+- **Брейкпоинт по адресу в банке ловит ВСЕ банки.**  0xC000..0xFFFF — общее
+  окно, и один и тот же адрес есть у семи модулей сразу.  Либо ловить через
+  трамплин (`hl==<адрес>&&(de&0xff)==<банк>`), либо перепроверять, что
+  срабатывания идут из нужной фазы: иначе в интервал попадает чужой код и
+  цифры врут (так я намерил несуществующие 134 730 тактов в прологе
+  `pop_char_fore`).
+- Трасса вызовов графики с параметрами: скрипт в истории сессии, ставит
+  маркеры фаз на трамплин `___sdcc_bcall_ehl` (условие `hl==<адрес>&&(de&0xff)==<банк>`)
+  и брейкпоинты на листья libbgi с печатью аргументов
+  (`__sdcccall(1)`: arg1 = HL, arg2 = DE, дальше стек с sp+2).
+
+## Профиль на 2026-08-10
+
+Сцена: комната 1, два факела, стража нет.
+
+| сцена | работа за кадр | период |
+|---|---|---|
+| Кид в покое, факел не задет (пропуск работает) | 244 026 (57 %) | 3 кадра |
+| Кид стоит на факеле (перерисовывается каждый кадр) | 366 240 (85 %) | 3 кадра |
+| Кид в щебне (2,4), движется | ~357 000 (83 %) | 3 кадра |
+| Кид (0,5) в движении | 421 254 (98 %) | **4 кадра** |
+
+Одна перерисовка персонажа = **~137 000 тактов = 32 % растрового кадра**,
+из них полезной работы (heal 20×19 + спрайт 12×41) — меньше трети.
+
+## Профиль дворца (уровень 4) на 2026-08-10
+
+Сцена: уровень 4, Кид НЕПОДВИЖНО стоит на (1,7) (комната с решёткой),
+стража нет.  Разбивка одного логического кадра брейкпоинтами на границах
+фаз (адреса `PROF()` из `roomtest.lst` + базы `_CODE = 0x42AD`):
+
+| фаза | тактов | доля работы |
+|---|---:|---:|
+| ввод + читы + heal | 59 340 | 11 % |
+| логика (kid_tick, phys_tick, страж, боёвка) | 85 356 | 16 % |
+| `pop_loose_tick` | 27 396 | 5 % |
+| `pop_process_trobs` | 106 107 | 21 % |
+| `pop_redraw_needed` | 447 | — |
+| шов / смена уровня / вспышка | 5 448 | 1 % |
+| `guard_over_kid` + `pop_char_skip_mask` | 4 788 | 1 % |
+| `pop_char_draw(KID)` | 52 206 | 10 % |
+| соперник + `loose_mob_draw_over` + `hp_draw` | 4 086 | 1 % |
+| **`pop_char_fore(KID)`** | **171 693** | **33 %** |
+| `pop_room_clip_borders` + прочее | 742 | — |
+| **ИТОГО работа** | **517 609** | 120 % растрового кадра → период **4 кадра** |
+
+По цветам бордюра: синий (`PROF(2)`) 144 696 (28 %), зелёный (`PROF(4)`)
+139 398 (27 %), циан (`PROF(6)`) 233 515 (45 % работы = 54 % растрового
+кадра, начинается на 74 % первого кадра и кончается на 123 %).
+
+## СДЕЛАНО 2026-08-10: метка «фон трогали» стала маской ТАЙЛОВ
+
+Было: один union-прямоугольник на страницу.  Три факела трогают по пятну
+16x18 в колонках 1, 6 и 8, а их объединение — полоса `x 40..280` на всю
+комнату; Кид, стоящий где угодно между крайними факелами, в неё попадал и
+перерисовывался каждый кадр со всем fore-проходом.
+
+Стало: `uint16_t pop_cd_dmask[2][3]` — бит на колонку, слово на ряд, набор на
+страницу.  Колонка берётся сдвигом (`x >> 5`), ряд — цепочкой сравнений;
+проверка в `cd_quiet` — три `AND` через резидентный `pop_cd_hit`.
+
+Гранулярность тайла — это гранулярность ОРИГИНАЛА: пометки там тоже по
+тайлам (`redraw_frames_anim[tilepos]`, `set_wipe`), персонажи привязаны к
+тайлу через `tile_object_redraw[tilepos]`, а единственное подтайловое
+уточнение (`wipe_heights`) — по высоте, не по ширине.  Полутайл (16 px) не дал
+бы ничего: пламя рисуется с отступом 8 px и шириной 16, то есть занимает
+середину тайла и задевает обе половины.
+
+Замер на той же сцене, где снимался профиль ниже (Кид неподвижно на (1,7)):
+
+| | было | стало |
+|---|---:|---:|
+| циан (спрайты + fore) | 233 515 | **24 781** |
+| работа за кадр | 517 609 | **306 553** |
+| период | 4 растровых кадра | **3** |
+
+---
+
+## СДЕЛАНО 2026-08-10: деление в луче видимости стража (Кид у шва)
+
+`tile_at_kid` (`guards.c`) считала колонку честным `/` и `%`, тогда как везде
+уже стоит резидентная таблица `POP_TILE_DIV` (это и есть `tile_div_tbl`
+оригинала).  У SDCC z80 это `__divsint` плюс `__modsint`, а тот внутри снова
+зовёт `__divsint` — ~5 400 тактов на вызов.
+
+Зовут её В ЦИКЛЕ по колонкам между стражем и Кидом
+(`check_can_guard_see_kid`, seg003:761).  Когда Кид стоит У ШВА, его
+`curr_col = −1`, луч тянется через всю комнату, и за кадр набегало ВОСЕМЬ пар
+делений — около 43 000 тактов, 10 % растрового кадра, в фазе ЛОГИКИ.
+
+Замер: брейкпоинт на `__divsint` с печатью адреса возврата дал `ret=C033`
+восемь раз за кадр; остановка на нём и дизассемблирование с правильным банком
+показали `HL−65`, `ld de,#14`, `call __divsint` по смещению 0x24 банка 1 —
+`tile_at_kid`.  После фикса пар `C033` не остаётся ни одной.
+
+**Заодно снята ложная тревога.**  В прошлом замере я записал, что на шве
+пролог `pop_char_fore` разбухает до 134 730 тактов.  Это была ошибка зонда:
+брейкпоинт на `fore_tile` стоял по адресу, который совпадает с кодом ДРУГИХ
+банков, и в интервал попадали чужие срабатывания.  Чистый замер (Кид в
+колонке 0, спрайт свисает за левый край, окно `x −8..5`): пролог **16 950** —
+ровно как в середине комнаты, весь fore-проход 41 803, `pop_room_clip_borders`
+14 364.  Урок в «Как мерить» выше: адрес в банке нужно либо проверять на
+уникальность, либо ловить через трамплин с условием на банк.
+
+---
+
+## 0. Дворцовая кладка в fore-проходе — **СДЕЛАНО 2026-08-10**
+
+Все три шага выполнены; замер после — в конце пункта.  Ниже сохранён исходный
+разбор: он объясняет, почему предфильтра `fore_tile` мало и откуда взялись
+габариты кусков.
+
+**Было: 139 863 такта за кадр (32 % растрового кадра), полезных пикселей —
+ровно ноль.**
+
+Замер (уровень 4, Кид на (1,7)).  Окно fore-клипа в этот момент —
+`x 229..241, y 106..147` (прочитано из `pop_t_fclip_*` брейкпоинтом).
+`pop_fore_over_char` обходит 6 тайлов:
+
+| тайл | тактов |
+|---|---:|
+| (0,6) (0,7) (1,6) (1,7) | 2 800 – 4 600 каждый |
+| **(2,6) — стена** | **74 310** |
+| **(2,7) — стена** | **65 553** |
+
+Ряд 2 этой комнаты — стена, и он лежит ПОД ногами Кида, то есть попадает в
+его fore-окно всегда.  Внутри одного тайла стены `wall_pattern_palace`
+делает 6 × `wpp_fill` (≈ 3 100 каждый) + 5 × `pop_wall_b` (≈ 9 760 каждый)
+≈ 60 000 тактов.
+
+Ни один кусок в окно не попадает:
+- верхняя заливка стоит на `dmy - 59 = 157`, окно кончается на `y = 147`;
+  все остальные куски ещё ниже;
+- тайл (2,6) занимает `x 192..223`, окно начинается с `x = 229` — он
+  промахивается и по горизонтали тоже.
+
+Тайл всё равно проходит, потому что предфильтр в `fore_tile` (pop_bg.c,
+`x0 < fclip_x1 && x0 + 40 > fclip_x0 && y0 - 8 < fclip_y1 && y0 + 70 >
+fclip_y0`) намеренно грубый — габарит 40×78 на тайл.  Дальше `wpp_fill`
+честно режет по окну и выходит с пустым прямоугольником, но 3 100 тактов на
+арифметику клипа уже потрачены, а `pop_wall_b` о существовании окна не знает
+вовсе: он идёт в `atlas_image` + `gfx_w0_map`, читает `w`/`h` и только там
+обнаруживает, что рисовать нечего.
+
+Что делать (по возрастанию объёма):
+1. **Ранний выход из `wall_pattern_palace`**: самый верхний пиксель узора —
+   `dmy - 59`, самый нижний — `dby + высота нижнего декаля`.  Один
+   `if (pop_t_fclip_on && (fclip_y1 <= dmy - 59 || fclip_y0 > dby + h))
+   return;` плюс такая же проверка по `x` убивает оба тайла целиком почти
+   даром.
+2. Прогнать `pop_wall_b` в этом узоре через ту же проверку окна, что уже
+   есть у `wpp_fill` (нужны размеры кусков — см. п. 2 ниже, «размеры из
+   каталога атласа»).
+3. Сузить сам предфильтр `fore_tile` до реального габарита узора вместо
+   40×78 — тогда лечится не только дворец.
+
+Порядок в подземелье тот же, но дешевле: `wall_pattern` в подземелье делает
+до 3 блитов и ни одной заливки (~29 000 на тайл против ~60 000).  Это же
+объясняет, почему после перехода на дворцовый тайлсет период вырос.
+
+Сверено с SDLPoP (`seg008.c:1943 wall_pattern`, ветка
+`!is_dungeon && GRAPHICS_VGA`): состав узора у нас дословный — 5
+`add_wipetable` + 4 декаля + нижняя заливка + нижний декаль.  Расходимся не
+составом, а тем, что оригинал складывает всё в `foretable` и рисует одним
+`draw_table()`, у которого «посетить тайл» стоит копейки (см. п. 6).
+
+### Что сделано и сколько дало
+
+1. **Ранний выход** из `wall_pattern_palace` по окну fore-клипа (узор целиком
+   в `x [xh*8, xh*8+32)`, `y [dmy−59, dby]`).
+2. **Отсев каждого декаля** (`wp_blit`) по реальному габариту вместо
+   заведомо большего 64×64 в `pop_blit_b`.  Размеры сняты из каталогов
+   атласов: `pal_wall.atl` — группы 3..5 = 8×7, 6..8 и 9..11 = 32×12,
+   12..14 = 30×5, 15..17 = 32×3.
+3. **То же для ПОДЗЕМЕЛЬЯ**: ранний выход `wall_pattern` (габарит там выше —
+   левая марка уходит на `dby+POP_YOFF−67`) плюс `wp_blit` на RNDBLOCK
+   (32×21), обоих разделителях (9×21) и обеих марках (`pop_wall.atl`:
+   16/17 = 7×10, 14/15 = 14×5).
+
+Замер: уровень 4, комната 18, Кид сдвигается читом `]` по пикселю (skip
+выключен, идёт полный путь), в fore-окне ШЕСТЬ тайлов, ТРИ из них —
+дворцовая стена.
+
+| участок | тактов |
+|---|---:|
+| пролог `pop_char_fore` до первого `fore_tile` | 17 208 |
+| обычный тайл | 4 000 – 4 600 |
+| **тайл стены (было 60 000 – 74 000)** | **~12 700** |
+| хвост + чистка бортов | 6 055 |
+| **fore-проход целиком (было 171 693)** | **70 681** |
+
+Кадр целиком в этой сцене: работа **419 839**, период **3** растровых кадра
+(было 517 609 и 4).
+
+Остаток в проходе — пролог 17 208, это уже пункт 1 ниже (футпринт из физики).
+Отдельная находка: когда Кид стоит НА ШВЕ (окно `x −8..5`), пролог разбухает
+до **134 730** — 86 % прохода; причина не разобрана, см. пункт 1.
+
+---
+
+## 1. Футпринт персонажа — брать из физики, а не считать заново
+
+**Цена: 11 574 такта на каждый fore-проход** (от входа в `char_footprint` до
+первого `fore_tile`).
+
+`redraw_at_char` (seg003:0430) берёт ГОТОВЫЕ `char_col_left/right`,
+`char_top_row`, `char_bottom_row` — их в этом же кадре посчитала физика
+(`set_char_collision`, seg006:0723).  У нас `char_footprint` (pop_bg.c)
+считает их заново внутри fore-прохода.
+
+Мешает то, что физика (банк 3) держит их в статиках, а слой фона — банк 2.
+Надо опубликовать их так же, как уже опубликованы `pop_cd[who].fpx/fpy/fpw/fph`.
+
+**Заодно:** оригинал расширяет футпринт ТОЛЬКО на одну колонку при вынутом
+мече и объединяет с футпринтом ПРОШЛОГО кадра (`prev_char_col_left/right`).
+Мы вместо этого расширяем окном fore-клипа и посещаем 6 тайлов там, где
+оригинал посетил бы 4.  Разница видна в замере: fore-проход стоит 58 764
+там, где реально рисует, и **112 758 там, где не рисует ничего** — вся
+разница в числе посещённых тайлов.
+
+Осторожно: окно клипа заводилось под клинок и брызги (они уходят
+вперёд-вверх за габарит кадра).  Менять — с прогоном боя и падений.
+
+## 2. Размеры ленты — из каталога атласа, а не через окно 0
+
+**Цена: ~750 тактов на `atlas_image` + часть из 6 396 на «чтение w/h и
+арифметика клипа», на КАЖДЫЙ блит фона.**
+
+Сейчас `pop_blit_b`, чтобы узнать размер куска, зовёт `atlas_image` (тот
+мапит страницу в W3, читает запись каталога, возвращает W3 назад), потом
+`gfx_w0_map` и читает `w`/`h` из шапки ленты.
+
+А размеры **уже лежат в каталоге**: запись 8 байт — `offset u16, fw u8,
+fh u8, nx u8, ny u8, резерв u16`, и у всех фоновых лент `nx = ny = 1`, то
+есть `fw`/`fh` в точности равны `w`/`h` из шапки (проверено по
+`pop_env0.atl`).  `atlas_image` их читает и выбрасывает.
+
+Вариант A (0 байт памяти): `atlas_image_wh()` рядом с `atlas_image` —
+вернуть заодно размер.
+Вариант B (без маппинга вовсе): снять каталоги при загрузке в резидентную
+таблицу.  Объём: фон (env0-4 + wall + fore + pot) = **313 лент**, по 2 байта
+= **626 Б**; всё вместе с Кидом и стражем = 600 лент = 1200 Б.  Свободной
+кучи на 2026-08-10 — 2873 Б.
+
+Ожидаемый выигрыш скромный: ~2 000–3 000 из ~16 000 накладных на блит.
+
+## 3. Один `gfx_w0_map`/`unmap` на группу блитов
+
+**Цена: ~5 500 тактов на блит** (unmap плюс возвраты по цепочке
+`pop_pot_b` → `pop_blit_b` → трамплин).
+
+Куски одного прохода часто лежат на одной странице атласа, а мапим и
+размапливаем на каждый.  Мешает то, что `pop_blit_b` — общий лист для всех
+вызывающих; нужна форма «открыть страницу, N блитов, закрыть».
+
+## 4. Единый проход по тайлам вместо трёх
+
+У оригинала за кадр ОДИН обход тайлов — `redraw_needed_tiles` (seg008):
+контекст тайла (`curr_tile`, `curr_modifier`, `draw_xh`, `draw_main_y`)
+ставится по разу на тайл в `load_curr_and_left_tile`, а `redraw_needed`
+смотрит **семь** независимых счётчиков (`wipe_frames`, `redraw_frames_full`,
+`redraw_frames_anim`, `redraw_frames2`, `redraw_frames_floor_overlay`,
+`redraw_frames_fore`, `tile_object_redraw`) и делает только помеченное.
+
+У нас **три** обхода: `pop_redraw_needed`, `pop_process_trobs` и
+`pop_fore_over_char`.  Плюс один `kind` на тайл вместо семи счётчиков — две
+разные причины перерисовки одного тайла конфликтуют.
+
+Это большой рефакторинг всего слоя фона; браться только если понадобится
+ещё заметный запас.
+
+## 5. objtable: персонажи, привязанные к тайлу
+
+Оригинал кладёт персонажей в `objtable` и рисует их в
+`draw_objtable_items_at_tile(tilepos)` во время обхода тайлов — порядок
+окклюзии получается сам.  У нас отдельный fore-проход НА КАЖДОГО персонажа.
+Со вторым персонажем (страж) цена удваивается.
+
+## 6. Отложенные таблицы back/mid/fore
+
+`add_backtable`/`add_midtable`/`add_foretable` только КЛАДУТ запись в массив,
+рисование — один `draw_table()` в конце.  Поэтому «посетить тайл» у
+оригинала стоит копейки.  У нас блит идёт сразу из обхода.
+
+## 7. Мелочи с известной ценой
+
+| что | цена | где |
+|---|---|---|
+| `pop_clip_char_top` — трамплин банк 4 → банк 3 ради одной проверки тайла над головой | 8 892 | `pop_cdraw.c` / `pop_map.c` |
+| `pop_loose_tick` при полном отсутствии падающих плит в комнате | 27 438 | `pop_map.c` |
+| `obj_x * 8 / 7` — единственное оставшееся `__divsint` в горячем пути | ~2 400 | `pop_char_draw` |
+| `cd_sig_make` + возврат из `pop_char_draw` | 7 944 | `pop_cdraw.c` |
+| `pop_loadkid` + расчёт координат кадра | 7 410 | `pop_cdraw.c` |
+
+## Что уже проверено и НЕ сработало
+
+- **Маска «у тайла есть передний слой» (`FORE_ANY`) + контекст тайла один
+  раз.**  Сделано (коммит `a9f4521`), эффект **нулевой**: в футпринте Кида
+  тайлы почти всегда С передним слоем, а снятое второе чтение кода съедено
+  проверкой маски.  Оставлено как сближение с оригиналом.
+- **«Быстрый путь для окна коллизии целиком внутри комнаты».**  Не
+  срабатывал почти никогда: Кид в колонке 0 даёт окно с −1.  Заменён на
+  разбиение окна на непрерывные пробеги.
+- **Флаг «фон трогали» вместо позиционной метки** — нулевой выигрыш,
+  факелы гасили пропуск для всех сразу (см. `pop_cdraw.h`).

applications/PoP/docs/perf_cyan_phase.md

@@ -0,0 +1,172 @@
+# ЦИАН фаза (персонажи + передний слой) — анализ и оптимизация
+
+Рабочий документ: живёт между сессиями.  Внизу **журнал правок** — каждая
+запись с замером до/после.  Сцена, рецепт воспроизведения и зонды —
+[`perf_l13_room23.md`](perf_l13_room23.md); там же ответ про 8-битные
+габариты.  Парная фаза — [`perf_green_phase.md`](perf_green_phase.md).
+
+Границы фазы в `roomtest.c`: от `PROF(6)` (строка 620) до `PROF(0)`
+(строка 677).  Содержимое: `pop_check_mirror`, `pop_loose_mob_draw`,
+соперник, `pop_char_draw(KID)`, `pop_loose_mob_draw_over`, `pop_fore_needed`,
+`pop_hp_draw`, `pop_char_fore(KID)`, `pop_cd_clear`,
+`pop_room_clip_borders`.
+
+**Бюджет: ≤ 400 000 тактов (растровый кадр = 430 000).**
+
+| состояние | было (2026-08-17, `c312e4a`) | стало (`af189a1`) |
+|---|---:|---:|
+| покой, Кид пропущен | 20 550 | 20 550 |
+| Кид перерисовывается, кусков нет | 193 000 | 192 000 |
+| **пик каскада (6 кусков + Кид)** | **631 800** | **270 510 ✔** |
+
+**ЦЕЛЬ ФАЗЫ ВЫПОЛНЕНА** (270 510 при бюджете 400 000, запас 32 %).
+
+---
+
+## 1. Что решило дело
+
+### C1. Пометки «фон трогали» в `mob_render` подавлены — −55 000
+
+`pop_loose_mob_tick` помечает **весь коридор** куска одним вызовом, а три
+блита внутри `mob_render` метили подмножества того же прямоугольника по
+**4 502 такта** каждый.  Механизм — `pop_cd_mute()`/`pop_cd_unmute()`
+(в `pop_tile.c`; отдельное значение того же флага `pop_cd_batch`, чтобы у
+`pop_cd_touch` на общем пути осталась ОДНА проверка).
+
+Добавлена пометка в `mob_spawn_copy`: кусок, рождённый ВНУТРИ тика
+(`loose_fall` сбил плиту), получает слот с начала таблицы, то есть уже
+пройденный циклом, — своей пометки в этом кадре он бы не получил, а нарисован
+был бы.  Без этого пропущенная пометка = стёртый и не перерисованный
+персонаж.
+
+### C4. Кусок клипуется САМ, вместо чистки бортов после — −138 000
+
+Самая крупная и самая неожиданная статья.  В `mob_render` стоял
+`pop_clip_sprite`, то есть кусок рисовался в борт целиком и взводил
+`border_dirty`; `pop_room_clip_borders` потом стирал ДВЕ полосы во всю ширину
+экрана (320×28 и 320×28) — **150 978 тактов в КАЖДОМ кадре**, пока хоть один
+кусок торчит выше поля.  А гряда 13-го уровня рождается ровно у потолка
+(`y = 2`), то есть почти весь каскад.  Стало 1 722.
+
+Теперь окно клипа (`pop_t_win_set(0, POP_YOFF, 320, POP_PLAYFIELD_H)`)
+ставится ТОЛЬКО когда кусок реально задевает борт: внутри поля блиты идут
+быстрым путём.
+
+### Композит куска: три блита → один — −163 000
+
+Части `env 70 / 74 / 72` складываются в ОДИН getimage-блоб при загрузке
+тайлсета (`mob_spr_build` в `pop_room.c`).  Мотив прямо из
+[[blit_cost_model]]: у блита ~8 800 такта постоянных накладных против ~5 000
+на пиксели, а шесть кусков в воздухе давали 18 вызовов = **258 708 такта**,
+больше половины фазы.
+
+Тонкости, которые пришлось соблюсти:
+
+- части **перекрываются** (74 и 70 обе идут от `mob_x`), поэтому композит
+  собирается попиксельно с пропуском `0xFF` — ровно как три прозрачных блита
+  друг поверх друга;
+- габариты частей **читаются**, а не берутся константами: у тайлсетов правая
+  часть разная (26 px в подземелье, 25 во дворце);
+- блоб лежит в обычной памяти (W2), поэтому блит идёт мимо `atlas_image` и
+  `gfx_w0_map/unmap` — ещё ~1 350 такта на вызов.  Новый резидентный лист
+  `pop_mem_b` (`pop_tile.c`);
+- страйд блоба = его ширина; сначала считается точный габарит, потом
+  копирование.  Промежуточная версия объявляла блоб шириной 63 при
+  фактических 58 и переносила пять прозрачных колонок на каждом кадре;
+- собирается на КАЖДУЮ смену тайлсета; резервный путь на три блита остался
+  (`mob_spr_ok`).
+
+### Общие правки, попавшие и в эту фазу
+
+- `blit_b_clip`: байтовый габарит + file-scope вместо локалей (кадр 22 → 12 Б,
+  обращений `(ix)` 211 → 51).  Подробности — в
+  [`perf_green_phase.md`](perf_green_phase.md) §G3.
+- `pop_blit_b`: аргументы в file-scope (76 → 11 обращений `(ix)`).
+
+---
+
+## 2. Раскладка на 2026-08-17 (до правок) — для истории
+
+Подфазы (три готовых `PROF(6)`: 0x4BCE / 0x4C26 / 0x4C93), пик:
+
+| участок | покой | пик |
+|---|---:|---:|
+| `pop_check_mirror` + `pop_loose_mob_draw` + соперник | 23 250 | 154 512 |
+| `pop_char_draw(KID)` + `pop_loose_mob_draw_over` + `pop_fore_needed` + HP | 3 726 | 445 284 |
+| `pop_char_fore(KID)` + `pop_cd_clear` + **чистка бортов** | 1 722 | 150 978 |
+
+Разбор одного `pop_blit_b` (157 замеров быстрого пути, зонды b1..b5):
+
+| участок | такты | доля |
+|---|---:|---:|
+| `atlas_image` + `gfx_w0_map` + чтение габарита | 1 086 | 7 % |
+| ядро блита (libbgi, `gfx_blit_noclip`) | 10 422 | 64 % |
+| `pop_cd_touch` — пометка «фон тронут» | 4 502 | 28 % |
+| `gfx_w0_unmap` + возврат | 264 | 2 % |
+| ИТОГО | 16 273 | |
+
+Клипованный путь тогда же: ядро `blit_b_clip` 14 088, итого 16 409.
+После правок: клипованный блит 11 848, быстрый ~13 900 (у него больше
+пикселей).
+
+---
+
+## 3. Что осталось в запасе (если понадобится ещё)
+
+Фаза в бюджете, поэтому это задел, а не план.
+
+### C5. Один `gfx_w0_map`/`unmap` на группу блитов
+
+1 086 + 264 на вызов.  Для композита куска уже не нужно (он в обычной
+памяти), но остаётся для тайлов фона: куски одного тайла часто лежат в одной
+странице атласа.  Мешает то, что `pop_blit_b` — общий лист для всех
+вызывающих; нужна форма «открыть страницу, N блитов, закрыть».
+
+### C6. Размеры ленты — из каталога атласа
+
+`fw`/`fh` уже лежат в записи каталога (8 байт: `offset u16, fw u8, fh u8,
+nx u8, ny u8, резерв u16`), и у всех фоновых лент `nx = ny = 1`, то есть они
+равны `w`/`h` из шапки.  `atlas_image` их читает и выбрасывает.
+
+### C7. objtable вместо отдельного fore-прохода на персонажа
+
+Позиции 5 и 6 старого `perf_backlog.md` — большой рефакторинг.  Оригинал
+кладёт персонажей и куски в `objtable` и рисует их при обходе тайлов
+(`draw_objtable_items_at_tile`), порядок окклюзии получается сам; у нас
+отдельный fore-проход НА КАЖДОГО персонажа.
+
+### Снять временную оснастку
+
+Шесть вызовов `pop_dbg_b1..b6` внутри `pop_blit_b` — ~400 такта на блит
+(`call` + `ret` × 6), плюс `pop_dbg_kind`/`m16` в `pop_redraw_needed`.
+Снимать ПОСЛЕ того, как оптимизация закончена: без них не мерить.
+
+---
+
+## 4. Что НЕ делать
+
+- **Не ставить W3-скобку из кода с `--w3`** — белый экран
+  (memory `gfx_blit_noclip_fast`).
+- **Не ускорять передачу пикселей** — предел железа
+  (memory `blit_cost_model`).
+- **Не возвращать клип куска по `clip.right = 40`** оригинала
+  (`add_mob_to_objtable`, seg007:1161): единицы этого поля не выяснены,
+  буквальные 40 экранных пикселей срезают правый задний угол плиты
+  (прогон 2026-08-13).
+- **Не сужать коридор heal «по палаццовому следу»** — габариты частей у
+  тайлсетов разные; брать высоту СОБРАННОГО композита (так и сделано).
+
+---
+
+## 5. Журнал правок
+
+| дата | что сделано | циан: покой / Кид / пик | коммит |
+|---|---|---|---|
+| 2026-08-17 | базовый замер | 20 550 / 193 000 / **631 800** | `c312e4a` |
+| 2026-08-17 | C1 подавление пометок в `mob_render` + пометка в `mob_spawn_copy` | — / — / **577 050** | `a3c473d` |
+| 2026-08-17 | C4 кусок клипуется сам вместо чистки бортов; `blit_b_clip` байты+file-scope | — / — / **438 546** | `a3c473d` |
+| 2026-08-17 | `pop_blit_b` аргументы в file-scope | — / — / **435 180** | `b2da0b8` |
+| 2026-08-17 | **композит куска: один блит вместо трёх** | — / — / **273 078** | `b2da0b8` |
+| 2026-08-17 | точный габарит композита (было 63 при 58) | 20 550 / 192 000 / **270 510 ✔** | `af189a1` |
+| 2026-08-17 | замер после фиксов уровня 1 | — / — / **379 482** | `40f0d46` |
+| 2026-08-17 | **регресс после фиксов уровня 2** — без изменений | — / — / **379 488 ✔** | `ec1f384` |

applications/PoP/docs/perf_green_phase.md

@@ -0,0 +1,327 @@
+# ЗЕЛЁНАЯ фаза (слой фона) — анализ и оптимизация
+
+Рабочий документ: живёт между сессиями.  Внизу **журнал правок** — каждая
+запись с замером до/после.  Сцена, рецепт воспроизведения и зонды —
+[`perf_l13_room23.md`](perf_l13_room23.md); там же ответ про 8-битные
+габариты.  Парная фаза — [`perf_cyan_phase.md`](perf_cyan_phase.md) (её цель
+достигнута).
+
+Границы фазы в `roomtest.c`: от `PROF(4)` (строка 450) до `PROF(6)`
+(строка 620).  Содержимое: `pop_loose_tick`, `pop_process_trobs`,
+`pop_redraw_needed`, шов, смена уровня, сигналы провалов, вспышка.
+
+**Бюджет: ≤ 400 000 тактов (растровый кадр = 430 000).**
+
+| состояние | было (`c312e4a`) | стало (`af189a1`) |
+|---|---:|---:|
+| покой в комнате 23 | 35 760 | 35 760 |
+| дрожат 6 плит-потолков | 366 000 | 335 400 |
+| **пик каскада** | **805 000** | **546 900** |
+
+**ЦЕЛЬ ФАЗЫ НЕ ДОСТИГНУТА: 546 900 против 400 000 (1,37×).**  Что осталось
+сделать и почему это именно раскол `draw_tile` — §3.
+
+---
+
+## 1. Раскладка ПОСЛЕ правок (замер `af189a1`)
+
+Пик — кадры 24-28 (посадки плит), больше не кадры провалов.
+
+| участок | покой | дрожь | пик |
+|---|---:|---:|---:|
+| `pop_loose_tick` | 36 234 | 36 234 | **156 762** |
+| `pop_process_trobs` | 1 050 | 1 050 | 1 050 |
+| **`pop_redraw_needed`** | 924 | 288 800 | **380 568** |
+| хвост (шов, смена уровня, сигналы, вспышка) | 9 336 | 9 336 | 10 776 |
+
+`pop_loose_tick` изнутри на пике: два цикла по тайлам 9 852,
+**`pop_loose_mob_tick` 154 074** (heal шести летящих кусков), остальное мелочь.
+
+### Цена одной перерисовки: было → стало
+
+| вид | было | стало | чем |
+|---|---:|---:|---|
+| `RDA_CEIL` — дрожащая плита-потолок | 48 785 | **43 536** | G2 + G3 |
+| `RDA_CEIL_GONE` — запечь колодец | 251 335 | **138 318** | **G1** (клип полосы) + G2 + G3 |
+| `RD_FLOOR` — щебень на месте посадки | 198 805 | **179 914** | G2 + G3 + снятая двойная пометка |
+
+Штук за кадр: `RDA_CEIL` до 6, `RDA_CEIL_GONE` до 2, `RD_FLOOR` до 2.
+
+### Детальный профиль `RD_FLOOR` (179 914) — главная оставшаяся статья
+
+Снят зондами по каждому блиту (`pop_dbg_b1/b5`) и по рамкам
+(`pop_bar_black`, `pop_cd_batch_begin/end`):
+
+| участок | такты |
+|---|---:|
+| вход `pop_floor_bake` + `gfx_set_bank` | 2 382 |
+| `pop_bar_black` 60×39 (включая `pop_cd_touch` 4 502) | ~15 500 |
+| **контекст `draw_tile` #1** (5 чтений тайлов, `63*row`, индексация таблицы) | **13 584** |
+| 4 блита тайла #1 | 50 718 |
+| **диспетчер между блитами #1** (все `if (code == …)`) | **11 388** |
+| **контекст `draw_tile` #2** | **13 584** |
+| 4 блита тайла #2 | ~54 000 |
+| **диспетчер между блитами #2** | **11 388** |
+| хвост | 6 474 |
+
+Итого: **105 500 — сами блиты (реальные пиксели), 74 400 — накладные**, из
+которых 27 168 контекст двух `draw_tile` и 22 776 их диспетчер.
+
+---
+
+## 2. Что сделано (с чем сравнивать)
+
+### G1. Окно клипа для точечной перерисовки — −90 000
+
+`pop_t_win_set(x, ytop, w, h)` / `pop_t_win_clear()` в `pop_tile.c`: ставит
+уже существующее окно `pop_t_fclip_*` на прямоугольник, который перерисовка
+восстанавливает.  Работает в обе стороны — и предфильтр `pop_blit_b`
+отсеивает куски мимо окна ДО `atlas_image`/`gfx_w0_map`, и `blit_b_clip`
+режет остальные по нему.
+
+Где сработало: `pop_ceil_bake_empty` — куски ряда 0 высотой 63 px рисовались
+целиком, хотя восстановить надо девять строк полосы.  **Блит 21 447 → 7 619**,
+вся перерисовка 251 335 → 138 318.
+
+Где НЕ сработало — см. §4, отрицательные результаты.
+
+Побочно: пока окно стоит, `pop_blit_b` не ставит пометку «фон трогали»
+(признак fore-прохода), поэтому вызывающий обязан пометить прямоугольник сам.
+В `pop_ceil_shake_draw` добавлен явный `pop_cd_touch` на область heal'а; в
+`pop_ceil_bake_empty` и `pop_floor_bake` метит `pop_bar_black`, а лишний
+второй вызов на ту же область снят.
+
+### G2. Контекст тайла — file-scope, а не локали `draw_tile` — −55 000
+
+Порт `load_curr_and_left_tile` (seg008:0339): у оригинала это
+`curr_tile`/`curr_modifier`/`draw_xh`/`draw_main_y`/`draw_bottom_y` —
+переменные модуля, а не локали.
+
+Причина в кодогене: в `draw_tile` **57 вызовов**, и каждое живое через вызов
+значение SDCC спиливал в стековый кадр — 26 байт кадра и **513 обращений
+`-N(ix)`** (при ~46 замеренных тактах на обращение это ~23 600, что и
+намерено).  Стало **33 обращения**, кадра нет, банк 7 −703 Б.
+
+### G3. `blit_b_clip` — байтовый габарит + file-scope
+
+Два шага, и важен порядок наблюдений:
+
+1. **Байтового габарита ОДНОГО НЕ ХВАТИЛО.**  `sx/sy/dw/dh` → `uint8_t`
+   (корректно: кадры атласов ≤ 56×63) дало 211 → 173 обращения, а
+   22-байтовый кадр остался: значений, живых через шесть вызовов ядер libbgi,
+   всё равно больше, чем регистров у Z80.
+2. **Решило вынесение из локалей** (`bc_*`): 51 обращение, кадр 22 → 12 Б.
+
+Клипованный блит 14 088 → 11 848.  Заодно `blit_b_oversize` больше не ходит
+через `blit_b_clip` (там теперь байтовый габарит) — рисует напрямую
+`gfx_blit_part`; это путь под полноэкранные подложки интро/финала.
+
+### G4. Мелочи
+
+- `pop_blit_b`: аргументы в file-scope (третий и дальше SDCC передаёт стеком,
+  каждое чтение шло через `-N(ix)`) — 76 → 11 обращений.
+- `pop_loose_mob_tick`: пометки всех кусков ОДНИМ пакетом
+  (`pop_cd_batch_begin/end`) — было по 4 502 такта на кусок.
+  176 772 → 168 600.
+- Коридор heal куска — по фактической высоте СОБРАННОГО композита (было 24
+  строки константой, стало 20).  168 600 → 156 762.
+
+---
+
+## 3. Что осталось: раскол `draw_tile` (позиция G5)
+
+**Оставшийся разрыв: −147 000.**  Он весь в двух местах.
+
+### G5. Расколоть `draw_tile` на узкие части, как в оригинале
+
+**Ожидание: −50 000 … −60 000.**
+
+У оригинала `draw_tile` (seg008:01C7) — это девять независимых вызовов:
+`draw_tile_floorright`, `draw_tile_anim_topright`, `draw_tile_right`,
+`draw_tile_anim_right`, `draw_tile_bottom`, `draw_loose`, `draw_tile_base`,
+`draw_tile_anim`, `draw_tile_fore`.  Для ряда −1 он зовёт шесть из них
+(`draw_tile_aboveroom`, seg008:01F2), для полосы у потолка — те же шесть плюс
+`draw_tile_wipe(3)` (`redraw_needed_above`, seg008:02C1).
+
+У нас всё это — ветки `if (row >= 0)` ВНУТРИ одной функции, то есть контекст
+(13 584) и диспетчер (11 388) оплачиваются целиком всегда.  Расколов, каждая
+точечная перерисовка сможет звать только нужные части:
+
+- `pop_floor_bake`: вместо второго полного `draw_tile(row, col+1)` — только
+  его правую грань и базу;
+- `pop_ceil_shake_draw` / `pop_ceil_bake_empty`: дословный
+  `draw_tile_aboveroom`;
+- `pop_loose_shake_draw`, `pop_spike_redraw`, `pop_gate_redraw` — то же.
+
+Риск средний: у `draw_tile` собрано много инвариантов (BUG-LOOSE-3,
+BUG-LATTICE-DOORTOP, BUG-SEAM-WEDGE-1), проверять придётся прогонами всех
+уровней.  Поэтому делать отдельным заходом, а не хвостом другой правки.
+
+### G6. Меньше блитов в `RD_FLOOR`
+
+**Ожидание: неизвестно, надо мерить.**  105 500 из 179 914 — это 7,6 блита,
+и они рисуют настоящие пиксели.  Сократить можно только сократив то, что
+восстанавливается: бар сейчас 60×39 от `yb+26`, а плита занимает по вертикали
+меньше (её куски: левая грань `POP_LOOSE_FRAM_LEFT` 32×13 на `dmy = yb+62`,
+низ `POP_LOOSE_FRAM_BOTTOM` 32×3 на `dby = yb+65`, правая грань в соседе
+26×16 на `dby−1`).  То есть плита живёт в `yb+47 .. yb+65`, а бар начинается с
+`yb+26` — **21 лишняя строка сверху**.
+
+Проверять осторожно: бар заодно стирает и то, что рисует ДРУГИЕ куски тайла
+(орнаментная лента `stripe_id` на `dmy−27 = yb+35` попадает как раз в
+«лишнюю» часть).  Сузишь бар — надо убедиться, что ничего не осталось.
+
+### G7. heal летящих кусков — 154 074 (28 % фазы)
+
+Шесть кусков × ~25 700: сам heal 64×20 (по модели ~19 700) + пакетная
+пометка + накладные `mob_tick_one` (16-байтовый кадр, 99 обращений `(ix)`).
+**Сам heal у предела железа** — это 1 280 пикселей на кусок, оптимизировать
+нечего, кроме площади.  Площадь уже подрезана до габарита композита.
+
+Остаётся `mob_tick_one` (~4 500 на кусок = 27 000 на кадр) — то же лечение
+file-scope, что у `draw_tile`.
+
+### G8. Пометка соседа — узкой полосой, а не полным тайлом (идея пользователя)
+
+**Ожидание: заметное, но не мерено.  Взять ПОСЛЕ обхода всех уровней**
+(решение пользователя 2026-08-17: пока идёт отлов багов слоёв, каждая правка
+добавляет переменных в картину).
+
+Когда плита (1,8) падает, помечаются ДВА тайла:
+
+| пометка | что делает |
+|---|---|
+| `(1,8)` → `RD_LOOSE_GONE` | бар 40 на своём x, бар 32 на соседе, `draw_tile(1,8)` + `draw_tile(1,9)` |
+| `(1,9)` → `RD_FLOOR` | бар **60** на x соседа, `draw_tile(1,9)` ЕЩЁ РАЗ |
+
+То есть сосед перезапекается ЦЕЛИКОМ и ПОВТОРНО, хотя потревожили у него
+только левые 28 пикселей — там, куда свисает правая грань упавшего тайла.
+`draw_tile(1,9)` при этом вызывается дважды на одну пометку.
+
+Что такое эти числа (чтобы не сузить лишнего):
+
+- **60 = 32 свой тайл + 28 СОБСТВЕННЫЙ свес.**  Правая грань пола (кадр 42,
+  26 px) рисуется в клетке соседа с `x+32`, занимая `x+32..x+57`.  Для запечки
+  САМОГО тайла 60 уже минимальны — сужать их нельзя;
+- сузить можно только тот случай, когда тайл помечен ПОТОМУ ЧТО ИЗМЕНИЛСЯ ЕГО
+  ЛЕВЫЙ СОСЕД: тогда нужна полоса 28 px у левого края, а не весь тайл.
+
+Почему выигрыш не символический: `pop_floor_bake` стоит **179 914** тактов,
+из них 105 500 — сами блиты.  Узкая полоса срезала бы и площадь бара
+(60×39 → 28×39), и часть блитов — окно клипа там теперь стоит обязательным
+(см. §4), так что отсев достаётся даром.
+
+**Условия, из-за которых это не «просто уменьшить число»:**
+
+1. `pop_floor_bake` — ОБЩАЯ функция: её же зовут кнопка (`pop_button_redraw`),
+   зеркало, подобранный предмет и щебень на месте посадки.  Там меняется сам
+   тайл и 60 нужны целиком.  Значит нужен отдельный вход (напр.
+   `pop_floor_bake_edge(row, col)`) или параметр-прямоугольник — именно под
+   пометку «изменился мой левый сосед».
+2. Прежде чем выкидывать вторую пометку целиком, сверить ВЕРТИКАЛЬНЫЕ
+   диапазоны: `pop_loose_bake_empty` кроет `63*row+46 .. +65` (20 строк), а
+   `pop_floor_bake` — `yb+26 .. yb+64` (39 строк).  То есть сосед покрыт
+   ВТОРЫМ баром не полностью, и просто снять пометку нельзя.
+3. Ширина полосы = свес ЛЕВОГО тайла, а он зависит от типа тайла (у loose это
+   8 px по комментарию в `pop_loose_bake_empty`, у пола 26).  Брать по
+   максимуму (28) — безопасно.
+
+### G9. Снять временную оснастку
+
+Шесть `pop_dbg_b1..b6` внутри `pop_blit_b` — ~400 такта на блит; при 15
+блитах зелёной это 6 000 на кадр.  Плюс `pop_dbg_kind`/`m16` (2 вызова на
+перерисовку) и `pop_dbg_m5..m15`.  Снимать ПОСЛЕ окончания оптимизации: без
+них не мерить.
+
+---
+
+## 4. Копия второй страницы — и почему она ТРЕБУЕТ окна клипа
+
+Точечные запечки ставятся с `pages = 2`, срабатывают два кадра подряд (по разу
+на страницу дабл-буфера) и оба раза считают одно и то же.  После первого раза
+нужный прямоугольник уже лежит в ОЗУ-копии первой страницы, и его можно
+скопировать: `gfx_copy_page` берёт источником ОЗУ-копию НЕактивной страницы
+(то есть ЧИСТЫЙ фон — спрайты рисуются банком без тени и в копию не попадают),
+а приёмник обновляет и в видео-ОЗУ, и в ОЗУ-копии.  Идея пользователя: тот же
+приём, что при перевороте экрана (зелёное зелье), только без зеркала.
+
+| | полная запечка | копия |
+|---|---:|---:|
+| щебень / кнопка (60×39) | 179 914 | ~35 000 |
+| колодец полосы потолка (64×9) | 138 318 | ~17 500 |
+
+**ДВА УСЛОВИЯ КОРРЕКТНОСТИ.**  Оба нарушались и оба дали видимые баги.
+
+1. **Запечка обязана быть ОГРАНИЧЕНА копируемым прямоугольником.**
+   `draw_tile` рисует тайлы ЦЕЛИКОМ, то есть пишет ШИРЕ бара; копия переносит
+   ровно бар, и всё, что легло вне него, на второй странице остаётся прежним —
+   страницы расходятся, это видно как МЕРЦАНИЕ через кадр.  У полосы потолка
+   окно стояло с самого начала (G1), у `pop_floor_bake` — нет, и он мерцал
+   торцами полов, плит и кнопок (найдено пользователем 2026-08-17: уровень 1,
+   комната 6, Кид на кнопке (0,2)).  Поэтому в `pop_floor_bake` окно теперь
+   стоит КАК УСЛОВИЕ КОРРЕКТНОСТИ, хотя по скорости само по себе убыточно
+   (см. §5) — снимать его нельзя.
+2. **Копия годится только если содержимое тайла между двумя кадрами не
+   изменилось.**  У анимированного тайла (кнопка с идущим таймером связи)
+   пометка обновляется КАЖДЫЙ кадр и картинка каждый раз другая.  Поэтому
+   `pop_set_redraw`/`pop_set_redraw_above` гасят слот копии при ПЕРЕпометке
+   (`pop_bake_slot_reset*`).
+
+Плюс слот `bake_pg`/`bake_pg_above` помнит, НА КАКОЙ странице сделана первая
+запечка: копируем только если первая была на ДРУГОЙ странице и дабл-буфер
+включён.  Это покрывает переплетение двух запечек в одном кадре, однобуфер
+(чит SPACE) и смену комнаты (`pop_bake_forget`).
+
+---
+
+## 5. Отрицательные результаты — НЕ повторять
+
+### Окно клипа в `pop_floor_bake` — по СКОРОСТИ проверено ТРИ раза, каждый раз хуже
+
+**Но оно всё равно стоит на месте: без него ломается копия второй страницы
+(§4).**  Ниже — только про скорость самого окна.
+
+| попытка | было | стало |
+|---|---:|---:|
+| до G3 | 187 266 | 198 279 |
+| после G3 | 182 124 | 188 460 |
+| после `pop_blit_b` file-scope, с детальным зондом | 179 914 | 188 417 |
+
+Третья попытка объяснила причину: клипованный путь стоит **+1 500 такта на
+КАЖДОМ** из 7,6 блитов (+11 400), а режет он только редкие высокие куски — в
+трассе такие нашлись (34 878 → 25 872 и 28 818 → 24 090, всего −13 700), но в
+среднем по 12 перерисовкам их нет.  Запись стоит в коде.
+
+### Прочее (проверено раньше)
+
+- **Не откладывать запекание на другой кадр** — запечка пишет ОЗУ-копию, из
+  которой восстанавливает heal; отложенная даёт призрак плиты на месте дыры.
+- **Не батчить смежные колонки в `pop_ceil_shake_draw`** — плиты стартуют со
+  случайными задержками, в кадре дрожат разрозненные колонки, пробег почти
+  всегда длиной в одну.
+- **Не ускорять передачу пикселей** — предел железа (3+3 такта на байт,
+  memory `blit_cost_model`).  В пиковом кадре «железный» минимум всех блитов
+  ≈150 000 из 916 458.
+- **`LOOSE-SHAKE-RUNS`** (пометки по сменам кадра): наивный вариант выигрыша
+  НЕ даёт — пять смен × две страницы = те же десять перерисовок.  Работает
+  только версия «пары и тройки», ~20 % и только на дрожащих плитах; оценка
+  2026-08-13, не перемерена.  Подробности —
+  `roomtest/TASKS_OPEN.md#loose-shake-runs`.
+
+---
+
+## 6. Журнал правок
+
+| дата | что сделано | зелёная: покой / дрожь / пик | коммит |
+|---|---|---|---|
+| 2026-08-17 | базовый замер | 35 760 / 366 000 / **805 000** | `c312e4a` |
+| 2026-08-17 | G2 контекст тайла в file-scope | — / — / **747 954** | `a3c473d` |
+| 2026-08-17 | G1 окно клипа в `pop_ceil_bake_empty` | — / — / **663 250** | `a3c473d` |
+| 2026-08-17 | G3 `blit_b_clip` байты + file-scope | — / 335 400 / **575 730** | `a3c473d` |
+| 2026-08-17 | `pop_blit_b` file-scope; пакетная пометка кусков | — / — / **557 706** | `b2da0b8` |
+| 2026-08-17 | коридор heal по высоте композита | 35 760 / 335 400 / **546 900** | `9a50ab2` |
+| 2026-08-17 | **копия второй страницы вместо второй запечки** | — / — / **423 558** | `5ef721e` |
+| 2026-08-17 | `mob_tick_one` в file-scope; снята оснастка из горячих путей | 35 760 / 326 130 / **414 456** | `18ee60e` |
+| 2026-08-17 | фикс мерцания: окно клипа в `pop_floor_bake` как условие корректности копии | замер после фикса — ниже | `35b7cd5` |
+| 2026-08-17 | замер после фиксов уровня 1 (мерцание торцов, потолочный fore, сосед под плитой, блеск меча) | 35 760 / — / **417 630** | `40f0d46` |
+| 2026-08-17 | **регресс после фиксов уровня 2** (чёрные бары, чит бессмертия) — в пределах шума | — / — / **419 526** | `ec1f384` |

applications/PoP/docs/perf_l13_room23.md

@@ -0,0 +1,239 @@
+# Сцена и метод замера: каскад плит, уровень 13 комната 23
+
+Общий документ для двух фазовых: [`perf_green_phase.md`](perf_green_phase.md)
+(слой фона) и [`perf_cyan_phase.md`](perf_cyan_phase.md) (персонажи + передний
+слой).  Здесь — как воспроизвести сцену, чем мерить, сводка по кадрам и
+разбор габаритов спрайтов (он общий для обеих фаз).
+
+Сцена: старт уровня 13.  Комната 23 стартовая, ряд 2 комнаты СВЕРХУ (17) —
+шесть loose-плит в колонках 2..7 (`res2013.bin`: коды `11` в позициях 22..27),
+`check_fall_flo` раздаёт им отложенный старт `0xF0..0xFF`, и они сыплются
+вразнобой.  Кид стоит у правого края и не двигается.
+
+Все числа — такты `totalcycles` MAME (системный клок ~21,5 МГц, **НЕ** такты
+Z80: у ОЗУ Sprinter wait-state'ы, ≈2,4× номинала — memory
+`sprinter_wait_states_2x`).  **Растровый кадр = 430 000.**  Логический кадр
+спейсится тремя `gfx_wait_vsync`, поэтому работа сверх 430 000 стоит сразу
+целый лишний растровый кадр.
+
+Сборка: `make LEVEL=13` на `c312e4a`, `_CODE = 0x4100`, база модуля
+`roomtest.c` = **0x42AD**.  **Адреса зондов меняются после КАЖДОЙ
+пересборки** — брать заново из `.sprinter-cc-roomtest/roomtest.map` и
+`roomtest.lst`.
+
+---
+
+## 1. Как воспроизвести сцену
+
+**Только перезапуском программы.**  Проверено и отвергнуто:
+
+- **выход из комнаты и возврат** (чит `+`/`-`) — не работает: провалившаяся
+  плита-потолок уходит в страницу уровня насовсем (`pop_level_set_tile` в
+  `roomtest.c` по сигналу `pop_ceil_fell`, плюс `animate_loose` в
+  `pop_trob.c`), и при повторном входе `check_fall_flo` не находит ни одной
+  `TILE_LOOSE`;
+- **рестарт уровня** (`pop_kid_dead = 1` + чит навигации) — не работает по
+  другой причине: `pop_start_level()` сам заходит в стартовую комнату 23,
+  взводит гряду, и она доваливается ЗАОЧНО (через `trob` комнаты 17), пока
+  телепорт уносит Кида в комнату 24;
+- **поставить сцену руками** (записать `pop_ceil_modif[2..7]` и копию ряда
+  сверху `pop_t_above[2..7]` отладчиком) — записи ложатся, но пока машина
+  БЕЖИТ, их успевает обнулить тот же доваливающийся `trob`.
+
+Рабочий рецепт (идея пользователя, самый чистый): **`ESC` → зонды →
+`roomtest`**.  `ESC` выходит в DSS, запуск заново стартует уровень 13 с нуля,
+Кид сразу в комнате 23, каскад начинается через ~5 логических кадров после
+отрисовки комнаты.  Зонды обязаны стоять **ДО** набора `roomtest` — за время
+набора (9 клавиш ≈ 1,8 с) и загрузки атласов каскад успевает пройти целиком.
+
+## 2. Канал вывода замеров
+
+`printf` из действия брейкпоинта в `error.log` **не** попадает.  Читается
+verb'ом **`clog N`** плагина `mamebridge` — а его нет в MCP-обёртке
+(`mame_mcp.py` знает только `cmd`).  Годится прямой файловый IPC:
+положить `/tmp/mame_mcp/req_<ЧИСЛО>.txt` с телом команды и прочитать
+`resp_<ЧИСЛО>.txt`.  **Имя обязано содержать ЧИСЛО** (`init.lua`:
+`entry:match("^req_(%d+)%.txt$")`) — с буквенным id запрос молча не
+обслуживается.
+
+Скрипты сессии (в scratchpad, при необходимости пересоздать): `mrpc.py` —
+клиент IPC; `run.sh` — цикл «`bpclear` → `ESC` → зонды → `roomtest` → `clog`»;
+`parse*.py` — разбор трассы по кадрам.
+
+Форма зонда: `bpset <addr>,1,{printf "<метка> %d",totalcycles; g}`.
+Для `pop_dbg_kind` — `printf "K %d %d",a,totalcycles` (аргумент `uint8_t`
+приходит в `A`, `__sdcccall(1)`).
+
+## 3. Зонды
+
+Адреса `out (_io_border), a` (полосы бордюра) из `roomtest.lst` плюс
+однобайтовые пустышки `pop_dbg_*` из резидентного `pop_state.c`.  Резидент
+важен принципиально: у банковых функций один адрес 0xC000+ есть у восьми
+модулей сразу, и брейкпоинт ловит все банки (так в прошлой сессии намерили
+несуществующие 134 730 тактов).
+
+| зонд | адрес | что |
+|---|---|---|
+| A | 0x43E8 | `PROF(2)` — начало кадра (ввод + heal) |
+| — | 0x46AF | `PROF(2)` — начало логики |
+| C | 0x47D1 | `PROF(4)` — начало слоя фона (**зелёная**) |
+| D | 0x4BCE | `PROF(6)` — начало спрайтов (**циан**) |
+| M | 0x4C26 | `PROF(6)` — кадр Кида |
+| F | 0x4C93 | `PROF(6)` — fore поверх Кида |
+| E | 0x4CB7 | `PROF(0)` — конец работы, ждём vsync |
+| m5/m6/m7 | 0x4DC6 / C7 / C8 | границы внутри зелёной |
+| m9..m12 | 0x4DCA..CD | внутренности `pop_loose_tick` |
+| m13/m14/m15 | 0x4DCE / CF / D0 | `pop_ceil_shake_draw`: вход / heal / draw_tile |
+| kind / m16 | 0x4DD1 / D2 | вид и цена одной перерисовки в `pop_redraw_needed` |
+| b1..b5 | 0x4DD3..D7 | участки одного `pop_blit_b` |
+
+Полезные адреса состояния (из `roomtest.map`): `pop_t_room` 0x95F2,
+`pop_current_level` 0x9945, `pop_ceil_modif` 0x9C9E, `pop_t_above` 0x95EE
+(указатель), `pop_kid_dead` 0x9C4E, `pop_dbg_rdmax` 0x95B1.
+Запись в память через MCP — по адресу `0x10000 | addr` (логический вид Z80);
+присваивание выражением дебаггера (`print b@... = 1`) **не работает**.
+
+**Грабли:** проверять, что запущен РОВНО ОДИН MAME (`pgrep -f mame.arm | wc -l`).
+Мост говорит с одним, замеры собираются с другого, и точки «не срабатывают».
+
+---
+
+## 4. Сводка по кадрам
+
+**Базовый замер (`c312e4a`, ДО оптимизации):**
+
+| фаза каскада | работа | синяя | зелёная | циан | период (растр.) |
+|---|---:|---:|---:|---:|---:|
+| покой в комнате 23 | 190 860 | 134 550 | 35 760 | 20 550 | **3** |
+| дрожат 6 плит | 537 400 | 142 700 | 366 000 | 28 700 | **4** |
+| провалы + полёт, ПИК | **1 437 150** | 142 700 | **663 250** | **631 200** | **5–6** |
+| максимум по секции | | 142 830 | **805 000** | **631 800** | |
+
+**После оптимизации (`af189a1`, 2026-08-17):**
+
+| максимум по секции | работа | синяя | зелёная | циан |
+|---|---:|---:|---:|---:|
+| было | 1 437 150 | 142 830 | 805 000 | 631 800 |
+| стало | **916 458** | 142 830 | **546 900** | **270 510** |
+| | −36 % | — | −32 % | −57 % |
+
+**Регресс после обхода уровней 1-2 (`ec1f384`, 2026-08-17), 418 кадров:**
+
+| максимум по секции | работа | синяя | зелёная | циан |
+|---|---:|---:|---:|---:|
+| после оптимизации (`af189a1`) | 916 458 | 142 830 | 546 900 | 270 510 |
+| после фиксов ур. 1 (`40f0d46`) | 873 930 | 158 874 | 417 630 | 379 482 |
+| **после фиксов ур. 2 (`ec1f384`)** | **878 550** | **158 880** | **419 526** | **379 488** |
+
+Фиксы второго уровня (чёрные бары, чит бессмертия) на бюджет не повлияли:
+разница с предыдущим замером +4 620 работы и +1 896 зелёной — шум прогона.
+
+**Регресс после обхода уровней 3-7 (`3bcaf51`, 2026-08-18), 2435 кадров:**
+
+| максимум по секции | работа | синяя | зелёная | циан |
+|---|---:|---:|---:|---:|
+| после фиксов ур. 2 (`ec1f384`) | 878 550 | 158 880 | 419 526 | 379 488 |
+| **после фиксов ур. 3-7 (`3bcaf51`)** | **880 170** | **159 774** | **419 520** | **380 244** |
+| разница | +1 620 | +894 | −6 | +756 |
+| | +0,2 % | +0,6 % | 0,0 % | +0,2 % |
+
+Все четыре секции — в пределах шума прогона (сравнить с +4 620 / +1 896
+выше, которые уже признаны шумом).  Зелёная совпала с точностью до 6 тактов.
+
+Что за это время добавилось в горячий путь: `pop_spike_frame` и
+`pop_chomp_pose` (SPIKE-BAKED) — один резидентный `call` на слой и ТОЛЬКО на
+тайлах-ловушках, в этой комнате их нет; и снятие раннего выхода для трупа
+(DIED-ON-BUTTON) — цепочка физики на мёртвом Киде, а он тут жив.  Замер это
+подтверждает: цена не сдвинулась.
+
+Распределение периода тоже совпало с эталоном кадр в кадр: **3 растра в
+2408 кадрах, 4 в 24, 5 в одном** — против «3 в 392, 4 в 24, 5 в одном»
+у `ec1f384` (кадров в этом прогоне больше просто потому, что дольше стояли в
+покое после каскада).  То есть за бюджет вылезает ровно тот же кусок сцены и
+ровно на столько же кадров.
+
+**Регресс после обхода уровней 8-9 (`0dd2f6a`, 2026-08-18), 2701 кадр:**
+
+| максимум по секции | работа | синяя | зелёная | циан |
+|---|---:|---:|---:|---:|
+| после фиксов ур. 3-7 (`3bcaf51`) | 880 170 | 159 774 | 419 520 | 380 244 |
+| **после фиксов ур. 8-9** | **880 272** | **159 822** | **419 562** | **380 202** |
+| разница | +102 | +48 | +42 | −42 |
+
+Разброс ±100 тактов на 880 000 — это 0,01 %, то есть чистый шум прогона
+(циан вообще ушёл в минус).  Период снова совпал кадр в кадр: 4 растра в
+24 кадрах, 5 в одном.
+
+Что добавилось за это время и почему не подорожало: фиксы стража
+(`c40ae3f`) правят только вход в комнату — кода в кадре не прибавилось; фикс
+боя у шва (`a498255`) добавил два сравнения в `check_leave`, а в этой сцене
+Кид неподвижен и до порогов не доходит.  Отладочная трасса `DBG_KIDOBJ`
+выключена дефайном и в сборку не попадает.
+Скачок циан на фиксах ПЕРВОГО уровня (270 510 → 379 482) объяснён там же:
+восстановлены потерянные половины слоёв (`set_redraw2`, ряд −1 foretable), то
+есть это плата за корректность, а не регрессия.
+
+Период кадра по прогону: **3 растра в 392 кадрах, 4 в 24, 5 в одном** — то
+есть за бюджет вылезает только сам каскад.
+
+Цель — каждая секция ≤ 400 000.  **Синяя и циан в бюджете**; зелёная 419 526,
+то есть 1,05× цели (и ниже растрового кадра 430 000), остаток разобран в
+[`perf_green_phase.md`](perf_green_phase.md) §3 (нужен раскол `draw_tile` на
+узкие части, как в оригинале) и в идее G8 (сузить инвалидацию соседнего тайла
+до 28-пиксельной полосы).
+
+Где что расходуется и как это чинить — в фазовых документах:
+[зелёная](perf_green_phase.md), [циан](perf_cyan_phase.md).
+
+### Общий вывод по пиковому кадру базового замера (1 437 150)
+
+| | такты | доля |
+|---|---:|---:|
+| блиты (все 27–28 вызовов `pop_blit_b`) | 488 100 | 34 % |
+| из них «железный» минимум пикселей (модель `198*h + 5,96*w*h`) | ~150 000 | 10 % |
+| синяя (ввод + heal + логика) | 142 700 | 10 % |
+| **наши накладные: `draw_tile`, IX-кадры, диспетчер, пометки** | **~1 150 000** | **~80 %** |
+
+Узкое место — НЕ передача пикселей (она на пределе железа, 3+3 такта на байт,
+memory `blit_cost_model`), а 16-битная арифметика в стековых кадрах.
+
+---
+
+## 5. Габариты спрайтов: можно ли всё перевести на `uint8_t`
+
+Просканированы каталоги ВСЕХ `.atl` (109 файлов) и исходные PNG наборов
+`TITLE`/`PV` — тех, что понадобятся для интро, финала и роликов между
+уровнями.
+
+**Игровой кадр — весь укладывается в байт:**
+
+| набор | максимум |
+|---|---|
+| фон подземелья/дворца (`*_env*`, `*_wall`, `*_fore`, `pop_pot`) | **48 × 63** |
+| Кид (`kid0..27`, `sword`) | **56 × 63** (kid3, idx 0) |
+| страж / скелет / Джафар | **53 × 42** |
+| спрайты комнаты принцессы (`PV.DAT`: персонажи, песочные часы, факел, звёзды) | **49 × 60** |
+
+**Больше 255 — только полноэкранные подложки титров и сюжетных экранов.**
+Их восемь, и все рисуются ОДИН раз при показе экрана:
+
+| ресурс | размер | где (`data.h`, `full_image[]`) |
+|---|---|---|
+| `TITLE/res51` | 320 × 200 | `TITLE_MAIN`, xpos 0 ypos 0 |
+| `TITLE/res41` | 320 × 200 | `STORY_FRAME`, xpos 0 ypos 0 |
+| `PV/res951` | 320 × 200 | фон комнаты принцессы (`chtab_9_princessbed`) |
+| `TITLE/res42..res45` | 272 / 267 / 264 / **256** × 134..142 | «presents», «Prince of Persia», «Mechner» |
+| `TITLE/res54` | 272 × 65 | заголовок Hall of Fame |
+
+Высота нигде не превышает 200 — в байт лезет.  По ширине не лезут ровно эти
+восемь, и ни одна из них не участвует в игровом кадре.
+
+**Вывод: горячий путь можно переводить на 8-битные габариты целиком.**
+Для подложек — решение пользователя (2026-08-17): работу с роликами вынести в
+отдельный банк с версиями блита под большие спрайты либо звать libbgi напрямую
+— клип и проверка выхода за экран им не нужны (рисуются в x = 0/24/48/96,
+заведомо внутри 320×200).  Ширина 320 всё равно потребует ДВУХ burst-скобок
+акселератора на строку — как уже сделано в `pop_vflip`.
+
+Существующая страховка уже есть и остаётся: `pop_blit_b` уводит кадр с
+`img[1] | img[3] != 0` на общий путь `blit_b_oversize`.

applications/PoP/docs/prng_alternatives.md

@@ -0,0 +1,148 @@
+# Генераторы псевдослучайных чисел: запасные варианты
+
+Что сейчас стоит в порте, какие есть альтернативы и сколько на них реально
+можно выиграть.  Заготовка на случай, если упрёмся в бюджет кадра —
+**сейчас менять ничего не нужно**.
+
+## Что стоит сейчас
+
+`pop_geom.c`, ветка `POP_PRANDOM_EXACT=1` (по умолчанию) — LCG оригинала
+`s = s*214013 + 2531011`, шаг написан на Z80-ассемблере (единственное такое
+место в порте).  Схема Горнера по разреженной записи константы:
+
+```
+214013 = ((((1<<1)+1)<<2 + 1)<<4 + 1)<<10 - 3
+```
+
+17 удвоений, три сложения, одно вычитание; величина `3*s`, нужная в конце,
+попадается по дороге на втором шаге.  Тело — **≈1 020 тактов** по статическому
+подсчёту.  Бит-в-бит совместим с SDLPoP, поэтому по картинке можно сверяться
+с эталоном.
+
+Вторая ветка, `POP_PRANDOM_EXACT=0` — xorshift16 + шаг Вейля на C.
+Совместимость теряется.
+
+Замер в MAME, комната 3, 175 кадров (медиана кадра):
+
+| вариант | кадр | prandom → torch_draw |
+|---|---|---|
+| C, бит-в-бит (16-битные половины) | 403 632 | 10 933 |
+| C, xorshift16 + Вейль | 397 986 | 7 927 |
+| **asm, бит-в-бит (сейчас)** | **400 800** | **9 331** |
+
+## Вариант A — комбинированный LFSR + LCG, ~148 тактов
+
+Период > 4 млрд (lcm(65536, 65535) ≈ 4.29e9), младшие биты не вырождены.
+
+```z80
+prng16:
+    seed1=$+1
+    ld hl, 9999
+    ld b, h
+    ld c, l
+    add hl, hl
+    add hl, hl
+    inc l
+    add hl, bc
+    ld (seed1), hl
+    seed2=$+1
+    ld hl, 987
+    add hl, hl
+    sbc a, a
+    and 101101b
+    xor l
+    ld l, a
+    ld (seed2), hl
+    add hl, bc
+    ret
+```
+
+Устройство: `seed1` — LCG `x = 5x + 1` (по модулю 2^16; `inc l` вместо
+`inc hl` — экономия байта, на период не влияет).  `seed2` — 16-битный
+LFSR Галуа: сдвиг влево, и если выехала единица, XOR младшего байта с маской
+`0x2D` (примитивный многочлен `x^16 + x^5 + x^3 + x^2 + 1`).  На выходе
+сумма обоих состояний — она и разрушает регулярность младших бит LCG.
+
+**Что мешает взять как есть:** сиды зашиты в код (SMC), а нам нужны ДВЕ
+независимые последовательности — раскладка кладки и анимация тайлов.
+Пришлось бы передавать состояние через указатель, как сейчас у `pop_prandom`
+(это +20…40 тактов, не принципиально).
+
+## Вариант B — xorshift(7,9,8), ~86 тактов
+
+Самый быстрый, период 65535.
+
+```z80
+xrnd:
+    ld hl, 1       ; seed must not be 0
+    ld a, h
+    rra
+    ld a, l
+    rra
+    xor h
+    ld h, a
+    ld a, l
+    rra
+    ld a, h
+    rra
+    xor l
+    ld l, a
+    xor h
+    ld h, a
+    ld (xrnd+1), hl
+    ret
+```
+
+**Две оговорки.** Ноль — неподвижная точка, а сид раскладки кладки у нас
+считается как `номер комнаты + смещение ряда + колонка` и вполне может
+оказаться нулём: нужен либо guard, либо шаг Вейля поверх.  И тот же SMC-сид,
+что в варианте A.
+
+## Чего НЕ брать: RND из Apple II
+
+Оригинальный `Prince-of-Persia-Apple-II`:
+
+```
+RNDseed := (5 * RNDseed + 23) mod 256
+```
+
+```asm
+RND
+ lda RNDseed
+ asl
+ asl
+ clc
+ adc RNDseed
+ clc
+ adc #23
+ sta RNDseed
+ rts
+```
+
+Полный период 256 (`a ≡ 1 mod 4`, `c` нечётное), и для своего движка он
+работал.  Нам не годится: у LCG по модулю 256 младшие биты вырождены — бит 0
+просто чередуется.  Наши вызовы это увидят: раскладка кладки берёт
+`prandom(1)` (ОДИН бит) и `prandom(4)`, то есть вместо шума получилась бы
+аккуратная шахматка.
+
+## Сколько реально можно выиграть
+
+Меньше, чем кажется по числам 86/148 против 1 020.  Тело генератора — уже не
+весь расход: остаются обёртка `pop_prandom`, приведение к диапазону
+`pop_rnd_fit` и ABI вызова.  Верхняя граница выигрыша видна из замера выше:
+между нынешним asm-LCG и самым дешёвым из проверенных вариантов разница
+**2 814 тактов за кадр (0.65 %)** при двух вызовах за кадр, и это ПОТОЛОК —
+любой из вариантов A/B ниже него не опустится.
+
+Порядок действий, если понадобится:
+
+1. Сначала убрать обёртки: слить `pop_rnd_fit` в ту же asm-процедуру, чтобы
+   на вызов приходился один `call`, а не три.  Это ничего не ломает и не
+   трогает совместимость с эталоном.
+2. И только если этого мало — менять генератор, начиная с варианта A
+   (качество последовательности у него не хуже LCG, в отличие от B).
+
+Важно помнить: число вызовов вырастет с боёвкой.  Сейчас их два за кадр
+(факелы), а `guard_advance` / `guard_block` / `guard_strike` дёргают
+`prandom(255)` каждый по разу за кадр боя — то есть при драке станет 5–6, и
+цена вопроса вырастет во столько же раз.

applications/PoP/docs/quicksave_plan.md

@@ -0,0 +1,324 @@
+# QuickSave / QuickLoad — разбор оригинала и план реализации
+
+Статус: **план, код не начат** (2026-08-17).  Задача на доске —
+[`../roomtest/TASKS_OPEN.md#qsave`](../roomtest/TASKS_OPEN.md#qsave).
+
+---
+
+## 0. Важная оговорка об «оригинале»
+
+**В оригинальном PoP 1989 года (DOS/Apple II) QuickSave/QuickLoad НЕТ.**
+Там вообще нет сохранения посреди уровня: игра рассчитана на один заход в
+60 минут, а «продолжение» — это только пароль/чекпоинт уровня 7.  Поэтому
+`Prince-of-Persia-Apple-II/` и `MSDOS/` тут не источники — искать в них
+нечего.
+
+Источник истины — **SDLPoP**, где быстрое сохранение добавлено как
+enhancement: `seg000.c`, блок `#ifdef USE_QUICKSAVE`, клавиши **F6** (save)
+и **F9** (load).  Ниже разобран именно он.  Это значит, что правило
+«расхождение с SDLPoP = баг у нас» здесь работает мягче: мы не обязаны
+повторять его байт-в-байт, но обязаны повторить его **устройство**, потому
+что оно решает ровно те проблемы, которые возникнут и у нас.
+
+---
+
+## 1. Как это устроено в SDLPoP
+
+### 1.1 Точка вызова — отдельная фаза кадра, не обработчик клавиши
+
+Клавиша только взводит флаг (`need_quick_save` / `need_quick_load`,
+`seg000.c:558`), а вся работа делается в `check_quick_op()` — она вызывается
+из главного цикла **между кадрами**, когда движок в согласованном состоянии.
+Это принципиально: загрузка посреди тика переписала бы `Char` под ногами у
+`play_seq`.
+
+Отказ штатный, не фатальный: `quick_save()`/`quick_load()` возвращают
+успех/неуспех, и игра печатает `QUICKSAVE` / `NO QUICKLOAD` внизу экрана и
+продолжается.
+
+### 1.2 Формат — плоская последовательность переменных, без структуры
+
+```c
+#define process(x) ok = ok && process_func(&(x), sizeof(x))
+```
+
+Один макрос и один и тот же список обходится **и на запись, и на чтение**
+(`quick_process(process_save)` / `quick_process(process_load)`).  Поля
+пишутся встык, без имён и тегов; совместимость держится ровно одним
+средством — **строкой версии в начале файла**:
+
+```c
+const char quick_version[] = "V1.16b4 ";
+```
+
+При загрузке она сравнивается, и при несовпадении файл просто отвергается
+(`quick_load`, возврат 0).  То есть формат нарочно хрупкий и нарочно
+одноразовый — это снимок конкретной сборки, а не сейв-формат.
+
+**Это стоит перенять целиком.**  Мы платим за версионирование одним байтом
+и получаем право менять состав снимка при каждой правке движка.
+
+### 1.3 Что именно сохраняется
+
+Полный список — `quick_process`, `seg000.c:257-366`.  По смыслу он делится
+на пять групп:
+
+| группа | поля |
+|---|---|
+| уровень | `level` (2305 Б целиком), `checkpoint`, `upside_down`, `drawn_room`, `current_level`, `next_level`, `leveldoor_open` |
+| анимируемые объекты | `mobs_count`, `mobs[14]`, `trobs_count`, `trobs[30]` |
+| Кид | `Kid`, `hitp_curr/max/beg_lev`, `grab_timer`, `holding_sword`, `united_with_shadow`, `have_sword`, `kid_sword_strike`, `pickup_obj_type`, `offguard` |
+| соперник | `Guard`, `Char`, `Opp`, `guardhp_curr/max`, `demo_index`, `demo_time`, `curr_guard_color`, `guard_notice_timer`, `guard_skill`, `shadow_initialized`, `guard_refrac`, `justblocked`, `droppedout`, `is_guard_notice`, `can_guard_see_kid` |
+| прочее | кэш коллизии (`*_row_coll_room/flags`, `prev_collision_row`), вспышка (`flash_color/time`), звук (`is_screaming`, `is_feather_fall`, …), **`random_seed`**, время (`rem_min`, `rem_tick`), весь блок управления (`control_*`, `ctrl1_*`) |
+
+Два наблюдения, важные для нас:
+
+1. **Состояние ОТРИСОВКИ не сохраняется вообще.**  Ни экранных буферов, ни
+   пометок перерисовки, ни того, что уже нарисовано.  Вместо этого при
+   загрузке комната перерисовывается с нуля.  Это резко упрощает задачу и
+   ровно то, что нам нужно при дабл-буфере.
+2. **`random_seed` сохраняется.**  Без него загрузка не воспроизводима:
+   после неё факелы, чомперы и `prandom` в боёвке пойдут иначе.
+
+### 1.4 Что делается при загрузке
+
+`restore_room_after_quick_load()` (`seg000.c:395`) — это и есть вся
+«сложность» операции:
+
+- `load_lev_spr(current_level)` — **перезагрузка графики уровня** (тайлсет
+  мог смениться: подземелье/дворец);
+- `different_room = 1`, `next_room = drawn_room = Kid.room` — принудительно
+  «мы в другой комнате», чтобы движок перерисовал всё;
+- `load_room_links()` — связи комнат заново;
+- `draw_game_frame()` — отрисовать кадр (важно для состояния падения);
+- `hitp_delta = guardhp_delta = 1` — принудительный редрой полос HP;
+- если `Guard.room != drawn_room` — стража «выключить» (`direction =
+  dir_56_none`, `guardhp_curr = 0`), как в `clear_char()`;
+- `loadkid_and_opp()` — восстановить окно `Char`/`Opp`;
+- сбросить таймеры текста и `exit_room_timer`.
+
+Плюс визуальный приём: перед загрузкой экран заливается чёрным на 5 тиков —
+чтобы переход читался глазом и не выглядел «дёрганием».
+
+### 1.5 Чего в SDLPoP решили НЕ восстанавливать
+
+- звуки — просто `stop_sounds()`;
+- перо (`is_feather_fall`) — без фикса `fix_quicksave_during_feather`
+  сохранение под пером запрещено вовсе, а при загрузке эффект гасится;
+- есть опциональный **штраф**: `USE_QUICKLOAD_PENALTY` отнимает минуту
+  игрового времени за квиклоад.  Нам не нужен (у нас пока нет игрового
+  таймера).
+
+---
+
+## 2. Чем наша архитектура отличается
+
+| | SDLPoP | у нас | следствие для задачи |
+|---|---|---|---|
+| уровень в памяти | `level_type` в ОЗУ, 2305 Б, мутабельный | EMM-страница (`pop_lvl_page`), плюс рабочая копия комнаты в W2 | снимок читает страницу через W0-маппинг, а не `memcpy` |
+| модификаторы тайлов | внутри `level.bg` | отдельный `room_modif[24][30]` в `pop_trob.c` (**static**) | нужен экспортируемый сериализатор из банка 6 |
+| код | один бинарник | 8 банков + резидент | сериализатор обязан жить там же, где данные, и зваться через трамплин |
+| экран | один буфер | **дабл-буфер**, у каждой страницы своя теневая копия | после загрузки перерисовать ОБЕ страницы, иначе через кадр мелькнёт старое |
+| ОЗУ | сколько угодно | куча 2969 Б, стек 1279 Б | буфер снимка целиком в ОЗУ не положить — писать потоком |
+| диск | `fopen` | DSS: 8 манипуляторов, 9-й ВЕШАЕТ систему ([[dss_fd_limit]]) | закрывать файл гарантированно, гард уже есть в libc |
+| ГСЧ | один `random_seed` | **три** независимых: `pop_t_seed`, `trob_seed`, `pop_fight_seed` | сохранять все три, иначе загрузка невоспроизводима |
+
+---
+
+## 3. Инвентаризация нашего состояния
+
+Собрано по `.sprinter-cc-roomtest/roomtest.map` (данные всех модулей, включая
+банковые, лежат в W2 — банк влияет только на код).  Отмечено, что глобально
+(видно снаружи), а что `static` и требует аксессора.
+
+### 3.1 Мутабельные данные уровня
+
+| что | где | размер | доступ |
+|---|---|---|---|
+| тайлы `fg` (провалившиеся плиты, открытые двери, съеденные предметы) | EMM-страница уровня | 720 Б | `pop_level_set_tile` пишет; чтения наружу нет — **нужен аксессор** |
+| `room_modif[24][30]` | `pop_trob.c`, static | 720 Б | **нужен сериализатор** (банк 6) |
+| `room_seen[24]` | `pop_trob.c`, static | 24 Б | там же |
+| `trobs[30]` + `trobs_count` | `pop_trob.c`, static | 91 Б | там же |
+| `trob_seed` | `pop_trob.c`, static | 4 Б | там же |
+| `mobs[14]` | `pop_room.c`, **глобален** | 210 Б | напрямую |
+| `mobs_live` | `pop_room.c`, static | 1 Б | аксессор |
+
+### 3.2 Персонажи и бой
+
+`Kid`, `Char`, `Opp` (`pop_kid.c`), `Guard` (`pop_guard.c`) — по 16 Б,
+все глобальные.  Рядом: `hitp_curr/max/beg_lev/delta`, `guardhp_curr/max/delta`,
+`guard_skill`, `guard_refrac`, `justblocked`, `kid_sword_strike`, `offguard`,
+`holding_sword`, `can_guard_see_kid`, `is_guard_notice`,
+`pop_guard_notice_timer`, `pop_guard_hurt`, `pop_united_shadow`,
+`pop_shadow_init`, `pop_fight_seed`, `knock`.
+
+### 3.3 Прогресс и физика
+
+`pop_current_level`, `pop_next_level`, `pop_checkpoint`, `pop_have_sword`,
+`pop_item_taken`, `pop_leveldoor_open`, `pop_leveldoor_right`,
+`pop_leveldoor_ybottom`, `pop_kid_dead`, `pop_kid_hurt`, `pop_feather`,
+`pop_upside` / `pop_upside_want`, `pop_flash_time` / `pop_flash_color`,
+`pop_droppedout`, `pop_fell_out`, `pop_leave_dir`, `pop_leave_timer`,
+`pop_loose_*`, `pop_ceil_modif`, `pop_ceil_fell`, `pop_debris_at`,
+`pop_seamless`, `pop_jumped_mirror`.
+
+### 3.4 Ввод
+
+`control_x/y/shift/forward/backward/up/down/shift2` (`pop_state.c`) — как в
+SDLPoP, сохраняются.
+
+### 3.5 Что НЕ сохранять (восстанавливается перерисовкой)
+
+`room_fg/room_bg`, `lcol_*`/`rcol_*`/`below_fg`/`above_*`, `seam_*`,
+`cur_room`, `pop_t_*` (весь кэш слоя фона, окна клипа, `pop_cd_*`),
+`trob_drawn`, `mob_spr`, слоты `pop_cd`, метки `pop_redraw`, запечки
+(`bake_pg`).  Всё это — производное; после загрузки оно обязано быть
+сброшено и пересчитано, а не восстановлено.
+
+**Оценка объёма снимка: ≈ 1,9 КБ** (720 + 720 + 210 + 91 + 64 + ~60
+скаляров + запас).
+
+---
+
+## 4. Куда писать снимок: файл, а не EMM-страница
+
+Рекомендация: **основной путь — файл `QUICKSAVE.SAV`; EMM-страница —
+необязательный второй слот.**
+
+> Пересмотрено 2026-08-17 по вопросу пользователя «почему EMM, а не файл».
+> Первая редакция плана рекомендовала EMM — это была ошибка: она взвешивала
+> скорость и недооценивала главный сценарий использования.  Разбор оставлен
+> целиком, потому что довод переносится и на другие «положить в память
+> вместо диска» решения.
+
+**Решающий довод: EMM-страница не переживает рестарт программы,** а именно
+рестарт — тот случай, ради которого QuickSave и нужен.  Пример из этого же
+проекта: сцену каскада плит на 13/23 воспроизводит ТОЛЬКО `ESC` → запуск
+заново ([`perf_l13_room23.md`](perf_l13_room23.md) §1, где перечислено,
+почему не годятся ни возврат в комнату, ни рестарт уровня, ни запись
+состояния отладчиком).  Тем более снимок в ОЗУ не переживает перезапуск
+MAME, обязательный после каждой пересборки образа.
+
+| сценарий | EMM | файл |
+|---|---|---|
+| «переиграть это место ещё раз» | работает, мгновенно | работает, на HDD быстро |
+| «вернуться к багу после рестарта» | **не работает** | **работает** |
+
+Второй сценарий не закрывается ничем другим; первый закрывается обоими, и
+разница в скорости там некритична — 1,9 КБ на HDD ([[mame_hdd_test_disk]] —
+быстрый путь против дискеты) не заметны на фоне полной перерисовки комнаты,
+которая при загрузке делается в любом случае и стоит дороже.
+
+Доводы за EMM, которые при перепроверке оказались слабыми: лимит
+манипуляторов DSS ни при чём (открываем и закрываем ровно один файл, гард
+`_fd_guard` в libc и так стоит), а «не нужен путь и права» — экономия одной
+строки.
+
+Что остаётся за EMM: мгновенный слот для «переиграть» без обращения к диску.
+Делается тем же сериализатором и добавляется, если понадобится.  Поэтому
+обход состояния писать сразу так, чтобы «куда» было параметром — как у
+SDLPoP через `process_func`.
+
+**Проверить ДО кодинга:** пишется ли `test_hdd.chd` из-под MAME.  Если образ
+только на чтение, файловый путь упрётся в это на первом же шаге и порядок
+работ придётся менять.  Проверка дешёвая — записать пробный файл на `D:` из
+roomtest.
+
+---
+
+## 5. Формат снимка
+
+```
++0   "PQS1"                 4 Б  магия
++4   версия сборки          1 Б  (инкремент при ЛЮБОМ изменении состава)
++5   pop_current_level      1 Б
++6   длина полезной части   2 Б  (контроль, что обход совпал)
++8   ... поля встык, ОДИН порядок на запись и на чтение ...
+```
+
+Версия проверяется первой; несовпадение — отказ, как в SDLPoP.  Никаких
+тегов и выравнивания: снимок одноразовый и живёт ровно одну сборку.
+
+Обход — один список и один макрос, как `process(x)`:
+
+```c
+static void qs_walk(qs_io_t io)   /* io = запись или чтение */
+{
+    QS(pop_current_level); QS(pop_checkpoint); ... 
+}
+```
+
+Так состав нельзя рассинхронизировать между сохранением и загрузкой —
+единственная реальная опасность плоского формата.
+
+---
+
+## 6. Что делать при загрузке (наш аналог `restore_room_after_quick_load`)
+
+Порядок важен, каждый пункт закрывает конкретный отказ:
+
+1. **Сменился уровень?** → `pop_level_load_num()`, `pop_bg_load(tileset)`,
+   атласы стража по типу.  Это дорого, но ровно тот же путь, что при
+   переходе уровня (`pop_level_switch`), — переиспользовать его, а не писать
+   заново.
+2. Залить экран чёрным (приём SDLPoP: переход должен читаться глазом).
+3. Восстановить состояние обходом `qs_walk`.
+4. **Сбросить всё производное:** `pop_trob_reset` (но НЕ трогая
+   восстановленные `room_modif`/`trobs` — нужен отдельный «мягкий» сброс,
+   только `trob_drawn` + метки), `pop_redraw_reset`, слоты `pop_cd`,
+   `pop_bake_forget`, `pop_cd_clear`, сигнатуры пропуска перерисовки.
+5. `pop_room_load(Kid.room)` — рабочая копия комнаты и срезы соседей.
+6. **Полная отрисовка комнаты в ОБЕ страницы дабл-буфера.**  Это наше
+   главное отличие от SDLPoP: одной перерисовки мало, вторая страница
+   останется со старой картинкой и мигнёт через кадр.
+7. Принудительный редрой полос HP (`hitp_delta = guardhp_delta = 1`).
+8. Если `Guard.room != Kid.room` — выключить стража
+   (`Guard.direction = DIR_56_NONE`, `guardhp_curr = 0`), как `clear_char`.
+9. `pop_loadkid_and_opp()` — согласовать окно `Char`/`Opp`.
+
+---
+
+## 7. Разбиение на шаги
+
+| шаг | что | критерий готовности |
+|---|---|---|
+| **QS1** | Аксессоры/сериализаторы для `static`-состояния банковых модулей: `pop_trob.c` (`room_modif`, `room_seen`, `trobs`, `trob_seed`), `pop_room.c` (`mobs_live`), страница уровня (чтение `fg`) | хост-тест `tests-host/t_qsave.c`: обход туда-обратно на синтетическом состоянии даёт байт-в-байт исходное |
+| **QS0** | Проверить, что `D:` пишется из-под MAME (пробный файл из roomtest) | файл создался и читается обратно после рестарта программы |
+| **QS2** | Ядро: `qs_walk` + запись/чтение файла `QUICKSAVE.SAV`, магия и версия, отказ при несовпадении | сохранение и загрузка **в той же комнате, без движения** — картинка и состояние не изменились |
+| **QS3** | Восстановление отрисовки (§6), включая обе страницы дабл-буфера | загрузка после перехода в другую комнату; нет мерцания через кадр |
+| **QS4** | Клавиши **F6/F9** (или свободные из `pop_cheat.h`) через `<kbd_raw.h>`, флаги `need_quick_save/load`, обработка **между кадрами** | загрузка посреди боя/падения не ломает `play_seq` |
+| **QS5** | Загрузка с **другого уровня** (перезагрузка уровня и атласов) | сохранить на ур. 2, уйти на ур. 12, загрузить — тайлсет и стражи верные |
+| **QS6** | Опционально: второй слот в EMM-странице тем же сериализатором | мгновенное «переиграть» без обращения к диску |
+
+Порядок не переставлять: QS0 первым (он может изменить весь план), QS3 без
+QS2 нечего проверять, а QS5 обязан идти после QS3 — иначе смена тайлсета
+замаскирует ошибки восстановления.
+
+**Главный критерий приёмки всей задачи:** сохранить состояние, выйти по
+`ESC`, запустить roomtest заново, загрузить — и оказаться там же.  Именно
+этого сценария сейчас нет ничем, и ради него задача и делается.
+
+---
+
+## 8. Риски и открытые вопросы
+
+1. **`static` в банковых модулях.**  Их нет в карте символов, то есть
+   отладчиком снимок не проверить.  Возможно, стоит сделать `room_modif` и
+   `trobs` НЕ-static — так же, как уже сделано с `mobs` в `pop_room.c` и
+   ровно по той же мотивации (там это записано прямым комментарием).
+2. **Место в банке 6.**  `pop_trob` занимает 3802/16384 — запас есть, но
+   сериализатор лучше писать компактным обходом, а не 30 отдельными
+   вызовами.
+3. **Три ГСЧ.**  Проверить, что сохранены ВСЕ: пропуск любого даст
+   «загрузилось, но играется иначе» — самый неприятный класс бага, потому
+   что выглядит как случайность.
+4. **Согласованность `Char` и `Kid`.**  У нас окно `Char` — отдельная копия;
+   если сохранить их рассогласованными (снимок посреди тика), загрузка
+   воскресит рассогласование.  Отсюда требование QS4: только между кадрами.
+   Урок свежий — ровно на этом стыке жил
+   [BUG-CHEAT-IMM-1](../roomtest/BUGS_CLOSED.md#bug-cheat-imm-1).
+5. **Дабл-буфер.**  Самый вероятный источник «почти работает»: забыть вторую
+   страницу. Симптом — мерцание через кадр
+   (см. `roomtest/CLAUDE.md`, раздел про дабл-буфер).
+6. **Открытый вопрос:** нужен ли снимок в файле вообще, или EMM-страницы
+   достаточно.  Решать после QS3, по факту использования.

applications/PoP/docs/room_model_plan.md

@@ -1,5 +1,21 @@
 # PoP roomtest — модель `kid_room ≠ drawn_room` (баг #4)
 
+> **Статус: ЖИВОЙ ПЛАН, сделан частично (сверено 2026-08-01).**
+> - **S1 — сделан:** `kid_room` заведён отдельно от `cur_room`,
+>   `update_kid_render_dx()` (`roomtest.c`) даёт рендер-смещение ∓140, а
+>   `pop_kid_set_render_dx` применяет его в отрисовке.  Фактически это пока
+>   каркас: `enter_room` держит `kid_room == cur_room`, так что смещение
+>   всегда 0.
+> - **S2/S3/S4 — не сделаны и не срочны.**  Исходный повод (баг #4,
+>   пинг-понг у шва) закрыт иначе — поправкой odd-pixel в
+>   `char_x_forward_edge` + `pop_leave_timer` (разбор корня —
+>   `../roomtest/BUGS_CLOSED.md`, BUG-SEAM-PINGPONG).
+>
+> **Зачем документ остаётся.**  Полная straddle-модель понадобится для:
+> (а) читов осмотра соседних комнат `H/J/U/N` (`levels_plan.md` §4),
+> (б) сцен, где Кид и страж в разных комнатах кадра, (в) остатков окклюзии у
+> шва (S4).  Брать из `../roomtest/TASKS_OPEN.md`, когда дойдёт очередь.
+
 Порт straddle-модели SDLPoP: персонаж может находиться в СОСЕДНЕЙ комнате,
 пока на экране ещё ТЕКУЩАЯ (drawn_room).  Источник истины — SDLPoP.
 
@@ -62,7 +78,9 @@ drawn_room с `curr_col=-1/10` + снапшоты соседей `g_lcol/g_rcol`
 ### S4. Полировка
 - Окклюзия/ceiling у шва при straddle, BUG-OCCL-1 (глубина), правый край.
 
-## Связанные баги (bug_list.md)
+## Связанные баги — все ЗАКРЫТЫ (`../roomtest/BUGS_CLOSED.md`)
 BUG-CEIL-1 (руки при прыжке вверх), BUG-CEIL-2 (loose в потолке),
 BUG-CEIL-3 (потолок над анимируемыми воротами), BUG-OCCL-1 (тень дальней
-колонны).  Memory: `pop_seam_room_model`.
+колонны) — починены без полной straddle-модели.  То есть S4 «полировка
+окклюзии» осталась актуальной только для окклюзии У ШВА при straddle.
+Memory: `pop_seam_room_model`.

applications/PoP/docs/roomnav_skip.md

@@ -0,0 +1,65 @@
+# Комнаты для отладочного телепорта (`+` / `-`)
+
+Считано скриптом прямо по `../SDLPoP/data/LEVELS/res20NN.bin`, 2026-08-13.
+Задача: обход комнат читом идёт последовательно, и в КАЖДОЙ комнате Киду
+должно найтись место для материализации без падения и смерти.
+
+## Критерии пропуска
+
+| причина | как определяется |
+|---|---|
+| **недостижима** | до комнаты нельзя дойти от стартовой обходом связей (BFS по left/right/up/down) |
+| **нет пола** | ни одного тайла, на котором можно стоять (`tile_is_floor`, seg004) |
+| **пол опасный** | стоять есть на чём, но обычного пола (код 1) нет — только пики, расшатанные плиты и прочее |
+
+Про достижимость важно: считать «сколько комнат на неё ссылаются» НЕ
+годится.  На уровне 1 комнаты **13** и **18** ссылаются только друг на
+друга (13.down = 18, 18.up = 13), то есть входящая связь у каждой есть, а
+из остального уровня в них не попасть.  Ловит это только обход от старта.
+
+Чит ищет место снизу вверх: сперва обычный пол (код 1), потом любой
+проходимый тайл (`pop_dbg_roomnav`, `roomtest_cold.c`).  Поэтому «пол
+опасный» — это комнаты, где он свалится на fallback и Кид может погибнуть.
+
+## Таблица по уровням
+
+| ур. | старт | достижимо | пропускать |
+|---|---|---|---|
+| 1 | 1 | 21/24 | **13** (недостижима), **18** (недостижима), **24** (недостижима) |
+| 2 | 5 | 24/24 | **14** (пол опасный), **17** (пол опасный) |
+| 3 | 9 | 22/24 | **17** (пол опасный), **19** (пол опасный), **20** (нет пола), **21** (пол опасный), **23** (недостижима/нет пола), **24** (недостижима/нет пола) |
+| 4 | 1 | 24/24 | **19** (нет пола), **20** (нет пола) |
+| 5 | 7 | 19/24 | **1** (недостижима), **3** (недостижима), **5** (недостижима), **6** (недостижима), **19** (недостижима/нет пола), **21** (пол опасный), **22** (нет пола) |
+| 6 | 24 | 14/24 | **2** (пол опасный), **3** (нет пола), **4** (недостижима), **7** (нет пола), **8** (недостижима/нет пола), **11** (пол опасный), **13** (недостижима), **14** (недостижима), **16** (недостижима), **17** (недостижима), **19** (недостижима/нет пола), **20** (недостижима), **21** (недостижима/пол опасный), **22** (недостижима), **23** (нет пола) |
+| 7 | 17 | 24/24 | **3** (пол опасный), **17** (нет пола), **21** (пол опасный) |
+| 8 | 1 | 21/24 | **9** (нет пола), **10** (пол опасный), **11** (недостижима), **15** (недостижима), **17** (пол опасный), **19** (недостижима), **20** (пол опасный), **21** (нет пола) |
+| 9 | 11 | 24/24 | **8** (нет пола), **18** (пол опасный) |
+| 10 | 1 | 19/24 | **3** (нет пола), **4** (пол опасный), **6** (недостижима), **9** (нет пола), **11** (пол опасный), **13** (нет пола), **18** (нет пола), **20** (нет пола), **21** (недостижима), **22** (недостижима), **23** (недостижима), **24** (недостижима) |
+| 11 | 6 | 23/24 | **3** (нет пола), **5** (нет пола), **9** (нет пола), **10** (нет пола), **11** (нет пола), **12** (нет пола), **17** (нет пола), **18** (недостижима), **23** (нет пола) |
+| 12 | 3 | 24/24 | **5** (нет пола), **6** (пол опасный), **8** (пол опасный), **10** (нет пола), **11** (нет пола), **17** (нет пола), **18** (пол опасный), **19** (пол опасный), **22** (нет пола) |
+| 13 | 23 | 11/24 | **2** (нет пола), **4** (пол опасный), **5** (недостижима), **6** (недостижима/пол опасный), **7** (недостижима), **8** (недостижима/пол опасный), **9** (недостижима), **12** (недостижима), **14** (недостижима), **15** (недостижима), **18** (недостижима/пол опасный), **19** (недостижима/пол опасный), **20** (недостижима), **21** (недостижима), **22** (недостижима/нет пола) |
+| 14 | 4 | 6/24 | **7** (недостижима/нет пола), **8** (недостижима), **9** (недостижима), **10** (недостижима), **11** (недостижима), **12** (недостижима), **13** (недостижима), **14** (недостижима/пол опасный), **15** (недостижима), **16** (недостижима), **17** (недостижима/пол опасный), **18** (недостижима), **19** (недостижима), **20** (недостижима), **21** (недостижима), **22** (недостижима), **23** (недостижима), **24** (недостижима) |
+| 15 | 6 | 6/24 | **1** (недостижима), **2** (недостижима), **7** (нет пола), **9** (недостижима/пол опасный), **10** (недостижима/пол опасный), **11** (недостижима/пол опасный), **12** (недостижима/пол опасный), **13** (недостижима/пол опасный), **14** (недостижима/пол опасный), **15** (недостижима/пол опасный), **16** (недостижима/пол опасный), **17** (недостижима/пол опасный), **18** (недостижима/пол опасный), **19** (недостижима/пол опасный), **20** (недостижима/пол опасный), **21** (недостижима/пол опасный), **22** (недостижима/пол опасный), **23** (недостижима/пол опасный), **24** (недостижима/пол опасный) |
+
+## Спецкомнаты — пропускать независимо от таблицы
+
+| ур. | комн. | почему |
+|---|---|---|
+| 12 | 23 | **seamless exit**: попадание МЕНЯЕТ УРОВЕНЬ на 13-й.  Чит-триггер придержан (`pop_nav_hold`), но в обходе комнате делать нечего |
+| 6 | 1 | **falling exit**: Кид проваливается вниз и уходит на 7-й уровень |
+| 7 | 17 | **falling entry**: экран сразу переводится на комнату НИЖЕ (в таблице уже «нет пола») |
+| 7 | 14 | проходится СВЕРХУ ВНИЗ; чит для неё уже особый — ставит Кида в ряд 0 |
+| 5 | 24 | тень ждёт в колонке −1 ряда 0; посадка рядом начинает схватку, которой там быть не должно |
+| 13 | 23, 16 | вход роняет гряду плит (`check_fall_flo`) — материализация под падающей плитой |
+
+## Уровень 15
+
+Экран защиты от копирования, не часть сюжета (см.
+[`levels_12_15_plan.md`](levels_12_15_plan.md) §4).  Портировать не
+планируем — **пропускать целиком**.
+
+## Как применять
+
+Список — данные, а не логика: держать таблицей в отладочном коде рядом с
+`pop_dbg_roomnav` и пропускать помеченные комнаты, чтобы `+` всегда попадал
+в пригодную.  Пересчитывать скриптом, если поменяются данные уровней.

applications/PoP/docs/shadow_render.md

@@ -0,0 +1,160 @@
+# Отрисовка Тени (charid_1_shadow) — изыскания, отложено
+
+Статус на 2026-08-11: **отложено по решению пользователя.**  Тень пока
+рисуется как обычный персонаж — простой копией из атласов Кида
+(`pop_cdraw.c`, банк 0x5C, аппаратная прозрачность `#FF`).  Вернуться к
+«правильному» виду, когда будут сделаны все уровни: тогда будет известно,
+какими именно кадрами тень вообще пользуется.
+
+Этот файл собирает всё, что уже выяснено, чтобы не переоткрывать.
+
+---
+
+## 1. Как тень выглядит в оригинале
+
+Тень рисуется **двумя блитами ОДНОГО И ТОГО ЖЕ спрайта Кида**
+(`seg008:1602`, `add_objtable`):
+
+```c
+case 1: // shadow
+    add_midtable(obj_chtab, obj_id + 1, obj_xh, obj_xl,     obj_y, blitters_2_or,  1);
+    add_midtable(obj_chtab, obj_id + 1, obj_xh, obj_xl + 1, obj_y, blitters_3_xor, 1);
+```
+
+OR на месте, XOR со сдвигом на пиксель вправо.  XOR гасит совпавшее,
+остаются края — отсюда «контурный» вид.  Это ЗАМЫСЕЛ оригинала, а не
+артефакт SDLPoP: подтверждено печатью из живого SDLPoP (метка `DBGMIRROR`
+в `add_objtable`) — и тень, и отражение идут из `chtab=2` (собственные
+спрайты Кида), `swordbits=0`, обычными кадрами:
+
+```
+type=4 chtab=2 img=40 dir=0 clipL=137 clipT=3 charid=0 frame=41   <- отражение
+type=1 chtab=2 img=41 dir=0 clipL=137 clipT=3 charid=1 frame=42   <- тень
+```
+
+Единственное различие между отражением и тенью — блиттер.
+
+## 2. Чем мы располагаем
+
+Блочные AND/OR/XOR/NOT акселератора подняты в libbgi 2026-08-11 (полный
+набор строками и колонками, `gfx_blit_op` / `gfx_blit_part_op` /
+`gfx_blit_cols_op` / `gfx_blit_cols_part_wx_op`; регресс — `tests/accop`,
+10/10 PASS).  Механика и ловушки — memory `accel_block_ops` и шапка
+`libbgi/common/_gfx_blit_full_op.c`.  То есть примитивов достаточно, дело
+не в них.
+
+## 3. Две причины, по которым «в лоб» не получается
+
+### 3.1 XOR несовместим с нашей прозрачностью `#FF`
+
+Аппаратная прозрачность (бит 3 видеобанка) подавляет запись байта `#FF`,
+то есть смотрит на **результат** операции:
+
+| операция | прозрачный пиксель источника | итог |
+|---|---|---|
+| AND | `#FF & bg = bg` | работает даром |
+| OR  | `#FF \| bg = #FF`, запись подавляется | работает даром |
+| XOR | `#FF ^ bg = ~bg`, подавления нет | **инверсия фона по всему футпринту** |
+
+Совпадение с «ничего не делать» у XOR получается только там, где фон равен
+0 (`#FF ^ 0 = #FF` → подавляется).  В DOS-оригинале прозрачный индекс = 0 —
+нейтральный и для OR, и для XOR, поэтому там оба блиттера работают на одном
+наборе спрайтов.  У нас прозрачный `0xFF` (`pop_pack_kid.py`: `0 -> 0xFF`,
+`i -> 0x70 + i`).
+
+Замаскировать `#FF` внутри операции нельзя в принципе: побитовые AND/OR/XOR
+не умеют «выбрать по условию», а `#FF` — нейтраль только для AND.  Значит
+источнику XOR-прохода нужен **прозрачный `0x00`**, то есть отдельный набор
+спрайтов.
+
+### 3.2 Операция читает ОЗУ-копию экрана, а не видео-ОЗУ
+
+Чтение страниц `#50..#5F` всегда отдаёт ОЗУ-копию (memory
+`sprinter_vram_transparency`), а персонажи рисуются банком `0x5C` («не
+писать в копию» — на этом держится даровой heal).  Поэтому второй проход
+**не увидит результат первого**: два блита оригинала выродились бы в
+«просто XOR», контурного эффекта не будет.
+
+Лечится не банком `0x50` (он ломает heal — копия перестанет быть чистым
+фоном), а **однопроходным композитом**: всё складывается в буфере
+акселератора за один проход по колонке j футпринта
+
+```
+буфер := s[j]        ; спрайт
+буфер |= bg[j]       ; вертикальное чтение экрана
+буфер ^= s[j-1]      ; тот же спрайт, предыдущая колонка = сдвиг на +1 px
+запись               ; вертикальная запись колонки
+```
+
+что **точно эквивалентно** двум блитам оригинала (крайние колонки: `x` —
+только OR, `x+w` — только XOR) и вдобавок дешевле их: 4 burst'а на колонку
+против 6.  Такому композиту тоже нужен источник с прозрачным `0x00` — уже
+на обоих шагах.
+
+## 4. Сколько стоит подготовить источник с прозрачным `0x00`
+
+Замер 2026-08-11 (`tests/convbench`, watchpoint по IO-записи в MAME, кадр =
+430 080 тактов).  Цикл безветвочный (`ADD A,A / SBC A,A / CPL / AND` —
+маска из бита 7: прозрачный `#FF` отличается от цветов Кида `0x70..0x7F`
+именно им), 59 номинальных T-states на байт, по факту **145.3 такта/байт**
+(2.5× wait-state'ов ОЗУ):
+
+| объём | кадров | секунд |
+|---|---|---|
+| 1 страница атласа, 16 КБ | 5.5 | 0.11 |
+| весь атлас Кида, 28 страниц × 16 КБ = 448 КБ | 155 | 3.2 |
+| он же **по реальному размеру данных (186 КБ)** | 64 | **1.3** |
+
+Последняя строка — замечание пользователя: 28 атласов занимают 186 КБ, а не
+448 КБ; обрабатывать по фактическому размеру ленты вместо целой страницы
+даёт 2.4× (ценой проверки границы в цикле).  Потолок разгона самого цикла —
+ещё примерно вдвое (раскрутка убирает `djnz`, чтение через SP парами +
+таблица 256 Б вместо арифметики), то есть **~0.7 с** на 186 КБ.  Порядок
+величины при этом не меняется.
+
+**Окна:** источник и приёмник — разные EMM-страницы, а окно под атласы одно
+(W0), поэтому конвертация гоняется «страница-источник в W0 →
+страница-приёмник в W3» целыми страницами; побайтно переключать окно нельзя.
+EMM-бюджет: +28 страниц (448 КБ) из ~3440 КБ свободных — не проблема
+(memory `sprinter_emm_budget`), и он одинаков в любом из вариантов.
+
+## 5. Варианты (когда вернёмся)
+
+1. **Конвертация в рантайме при загрузке уровня с тенью** (4, 5, 6, 12):
+   диск и упаковщик не трогаем, цена — 1.3 с (или 0.7 с после разгона) на
+   загрузку такого уровня.
+2. **Лениво, постранично** — 0.11 с (5.5 кадра) при первом обращении тени к
+   странице; рывок один раз на страницу, суммарно меньше, чем вариант 1.
+3. **Второй набор `.atl` от упаковщика** (`pop_pack_kid.py`, прозрачный
+   `0x00`): 0 с рантайма, +186 КБ на образе и вторая ветка в загрузчике
+   атласов.
+4. **Только OR-проход** (то, чем можно обойтись бесплатно): OR с нашим
+   `#FF`-атласом работает как есть, тень получается сплошным силуэтом в
+   палитре Кида, без контурного эффекта.  Расхождение с оригиналом — тогда
+   записью в `docs/impl_diff.md`.
+
+**Ключ к выбору — какие кадры тень вообще использует.**  Предположение
+пользователя: только бег, длинный прыжок (из зеркала), питьё зелья и
+боёвка; прыжки с места и подтягивания — нет.  Если так, конвертировать
+(или паковать) нужно единицы страниц, а не 28, и разница между вариантами
+почти исчезает.  Список снимать по факту — когда уровни 5/6/12 будут
+проходиться.
+
+## 6. Что ещё придётся проверить глазами
+
+Палитра.  У нас индексы разложены группами по 16 (`pop_pack_bg.py`):
+`0x30` VGA16, `0x40` chtab_1, `0x50` env, `0x60` wall, `0x70` kid, `0x80`
+sword, `0x90` guard.  Отсюда ожидания (аналитические, в MAME НЕ
+проверялись):
+
+- OR-проход ложится удачно: `0x7X | 0x5Y = 0x7Z` — результат остаётся в
+  палитре Кида, а младший ниббл получается ровно тот же, что дал бы DOS
+  (там OR шёл по 4-битным индексам внутри одной палитры);
+- XOR-проход уводит результат в группы `0x0Z` (поверх OR-результата) и
+  `0x2Z` (по чистому фону) — **обе группы палитры у нас не заполнены**, то
+  есть контур рискует оказаться просто чёрным.
+
+Значит к «посмотреть глазами» добавляется вопрос, чем заполнять `0x00..0x0F`
+и `0x20..0x2F` — по сути это и будет выбор цветов тени.  В DOS такого
+вопроса не было: XOR двух 4-битных индексов всегда оставался внутри той же
+16-цветной палитры.

applications/PoP/docs/size_optimization_plan.md

@@ -1,335 +0,0 @@
-# roomtest — план оптимизации по размеру + переход на huge/banking
-
-Статус: **план для отдельной сессии** (2026-07-21).  Документ самодостаточный
-(рассчитан на старт с пустого контекста).  Цель — освободить место: сейчас
-`applications/PoP/roomtest` в режиме `small` почти упёрся в потолок 32 КБ.
-
-Правило проекта (`applications/PoP/CLAUDE.md`): механику/раскладку памяти
-сверять с исходником и с memory (`sprinter_memory_modes`, `sdcc_banking`,
-`bank_local_data_pattern`, `pop_banking_architecture`).  Перед оптимизацией —
-`make size-check`-подобный замер до/после (здесь — руками по `.map`).
-
----
-
-## 0. Как мерить
-
-- Сборка: `cd applications/PoP/roomtest && make roomtest.exe` (режим `small`,
-  `--gfx 256`).  Карта символов — `.sprinter-cc-roomtest/roomtest.map`
-  (адреса сдвигаются при каждой пересборке!).
-- Размеры областей — из `.map` (`_CODE`, `_DATA`, `_BSS`).
-- Вклад модулей в `_CODE` — атрибуция диапазонов между символами по модулю
-  (скрипт-однострочник на python в истории; группировать символы `.map` по
-  3-й колонке-модулю и суммировать `addr[i+1]-addr[i]`).
-- MAME-проверка после изменений раскладки ОБЯЗАТЕЛЬНА (режимы памяти —
-  типовой источник «молча ломается», см. `sprinter_memory_modes`).
-
-## 1. ТЕКУЩЕЕ СОСТОЯНИЕ (замер 2026-07-21)
-
-Режим `small` = единое пространство **W1+W2 = 0x4000..0xBFFF (32 КБ)**; CODE с
-0x4100, DATA/BSS/heap цепляются ЗА CODE автоматически (`--data-loc 0` =
-linker chains), стек — вверху W2.
-
-| Область | Размер | Диапазон |
-|---------|--------|----------|
-| `_CODE` | ~27 250 Б (0x6A6F) | 0x4100–0xAB6F |
-| `_HOME` | 227 Б | 0xAB6F |
-| `_DATA` | 3 449 Б (0x0D79) | 0xAC78–0xB9F1 |
-| `_BSS`  | 290 Б | |
-
-**Образ ≈ 31.2 КБ; до верха W2 (0xBFFF) остаётся ≈ 1.3 КБ на кучу+стек.**
-Куча в roomtest почти не используется (атласы/уровень — в EMM-страницах),
-но запас критично мал.
-
-### Вклад модулей в _CODE (по .map, приблизительно)
-```
- 7003  pop_bg      (вся отрисовка тайлов/слоёв/wall_pattern)
- 6326  pop_kid     (из них ~3745 Б — СТАТ. ТАБЛИЦЫ kid_data.h, см. ниже)
- 3762  pop_map     (коллизия/физика/пики)
- 1455  pop_trob    (кнопки/ворота/пики-каркас)
- 1224  pop_level   (загрузка уровня, doorlink)
-  914  roomtest    (главный цикл)
- ~7000 libc/libbgi (gfx_blit*, atlas_load, kbd_raw, open/read, irq, div/mul…)
-```
-
-### Крупные СТАТИЧЕСКИЕ данные (сейчас в _CODE как `const`)
-- **`kid_data.h` — самый большой кусок, ~3.7 КБ**, живёт в _CODE (атрибутируется
-  pop_kid):
-  - `kid_seqtbl[2310]` — байткод последовательностей (play_seq).
-  - `kid_frames[241]` × 5 Б = 1205 Б — таблица кадров (image,dx,dy,flags,sword).
-  - `kid_seq_off[115]` × 2 Б = 230 Б — смещения seq.
-- `pop_bg`: `tile_table[31]`×12 = 372 Б + ~20 мелких const-таблиц (COL_XH,
-  WALL_FRAM_*, SPIKES_FRAM_{RIGHT,LEFT,FORE}, LOOSE_FRAM_*, DOOR_FRAM_SLICE,
-  BLUELINE_*, LPOS/RPOS, FLOOR_LEFT_OVERLAY) — суммарно ~0.5–0.7 КБ.
-- `pop_map`: `x_bump[20]`, `y_land[5]`, `wall_dl/dr`, `dir_front/behind` — ~100 Б.
-- В `_DATA` (W2, не CODE): `room_modif[24][30]`=720 Б + копии LINKLOC/LINKMAP=512 Б
-  (pop_trob/pop_level) + рабочие массивы roomtest.
-
----
-
-## 2. ПУТЬ A — оптимизация КОДА (без смены модели)
-
-1. **Компиляторные флаги** (`bin/sprinter-cc`): попробовать `--opt-code-size`
-   у SDCC и подобрать `--max-allocs` (сейчас дефолт 100000; меньше = мельче код,
-   но медленнее компиляция; см. `mdview2_size_budget` — там `--max-allocs`
-   давал −1.4 КБ).  Замерить каждый модуль отдельно.
-2. **Дедуп подстановки нажатой кнопки**: логика `opener→floor / closer→stuck`
-   по таймеру связи ПРОДУБЛИРОВАНА в `draw_tile` и `fore_tile` (pop_bg.c).
-   Вынести в `static inline`/helper `subst_pressed_button(code,mod)`.
-3. **wall_pattern / prandom** (pop_bg): 32-битный LCG (`unsigned long`) —
-   пользователь не любит 32-бит (см. `avoid_32bit_arith_z80`); но это PRNG
-   оригинала (нужен для совпадения раскладки стен) — трогать осторожно, только
-   если найдётся 16-битный эквивалент, дающий ТУ ЖЕ последовательность.
-4. **Ревизия дублей**: `y_to_row` определён в pop_bg И pop_map; мелкие
-   геометрические хелперы дублируются — свести в один internal-модуль.
-5. `/simplify`-проход по последним правкам Фазы B (pop_trob/pop_bg).
-
-Ожидаемый выигрыш пути A: единицы–первые сотни байт на пункт; в сумме,
-оптимистично, ~1–2 КБ.  Недостаточно как единственная мера.
-
----
-
-## 3. ПУТЬ B — вынос СТАТ. ДАННЫХ в EMM-страницы (с атласами / с level)
-
-**Идея (по замечанию пользователя):** EMM-страницы атласов и уровня
-использованы лишь частично (страница 16 КБ, данных меньше), в «хвосте» —
-свободное место.  Часть `const`-таблиц можно хранить ТАМ, а не в _CODE/_DATA,
-если таблица читается ИМЕННО ТОГДА, когда нужная страница уже в W0.
-
-**Механика W0:** атласы блитятся из W0 (`_gfx_w0_state`: `_gfx_w0_cur` —
-спрайт-страница в W0; ISR-стаб `_gfx_w0_isr` возвращает её после прерывания).
-Уровень (pop_level) маппит свою страницу в W0 на время извлечения
-(`gfx_w0_map`/`gfx_w0_unmap`).  → пока страница в W0, CPU может читать и
-данные из неё по адресам 0x0000..0x3FFF.
-
-**Категоризация таблиц по W0-контексту (задача сессии — уточнить по каждой):**
-
-- **(a) Читается, когда в W0 АТЛАС** → хранить в свободном хвосте атлас-страницы.
-  Кандидаты — таблицы, которые нужны В МОМЕНТ блита конкретного атласа.
-  ГРАБЛИ: `draw_tile` читает `tile_table`/`COL_XH` ДО блита (чтобы решить, какой
-  спрайт/куда) — в этот момент в W0 может быть ДРУГАЯ страница (DSS/предыдущий
-  атлас).  Т.е. большинство draw-таблиц читаются ВНЕ W0-атлас-контекста →
-  «в лоб» не переносятся.  Нужен аудит КАЖДОГО чтения: гарантирована ли нужная
-  страница в W0 в этот тик.
-- **(b) Читается, когда в W0 LEVEL** → хранить с уровнем (в его странице; там
-  ~13.7 КБ свободно из 16).  Кандидаты: константы декода doorlink, разбор
-  комнат — всё, что pop_level делает под `gfx_w0_map(lvl_page)`.
-- **(c) Нужна и там, и там** → дублировать в обеих страницах ЛИБО оставить
-  резидентной (если дубли дороже экономии).
-- **(d) Читается в чистой ЛОГИКЕ (W0 не важен)** → перенос требует ЯВНОГО
-  `gfx_w0_map` на каждое чтение (дорого, особенно в горячих циклах) → как
-  правило оставить резидентной.
-
-**Отдельно `kid_data.h` (3.7 КБ — самый жирный кандидат):**
-- `kid_frames`/`kid_seqtbl` читаются в `play_seq` (ЧИСТАЯ логика, каждый тик) И
-  в `kid_draw` (блит из kid-атласа, kid-страница в W0).  Т.е. частично (a),
-  частично (d).  Перенос всей таблицы в kid-атлас-страницу заставит `play_seq`
-  делать `gfx_w0_map` на каждый шаг байткода → замерить стоимость (может убить
-  бюджет спрайтов, см. `sprite_engine_perf`).  Вариант: держать в EMM отдельной
-  страницей данных Kid и маппить один раз на кадр вокруг kid_tick+kid_draw.
-- Это самый большой одиночный выигрыш (−3.7 КБ из _CODE), но и самый рискованный
-  по скорости — приоритетный к ПРОТОТИПИРОВАНИЮ и замеру.
-
-**Паттерн переноса writable/const данных в банк/страницу:** см. memory
-`bank_local_data_pattern` (--codeseg/--constseg/--dataseg BANKn + trampoline-fix
-+ mkexe -p 0) и `sdcc_static_storage_gotcha`.
-
-### 3.1 Свободное место в страницах (замер 2026-07-21, страница = 16384 Б)
-```
-BG-атласы:           размер   свободно
-  pop_env0.atl        10578     5806
-  pop_env1.atl        12449     3935   <- САМАЯ ТЕСНАЯ из bg
-  pop_env2.atl        10798     5586
-  pop_env3.atl         5032    11352   <- много места
-  pop_env4.atl         8498     7886
-  pop_wall.atl        11543     4841
-  pop_fore.atl         7763     8621
-Kid-атласы (28 стр): free min=6161  max=15452  avg=9722
-Level (res2001.bin):  данные 2305, свободно ~13823 (16384 − 0x100 стаб − 2305)
-```
-
-**Выводы по вместимости:**
-- **Макс. данных в ОДНОМ атлас-банке = свободный хвост ЭТОЙ страницы** (см.
-  таблицу).  Связывающее ограничение — самая тесная нужная страница (env1 =
-  3935 Б; не перегружать её).
-- Если страница будет маппиться в **W0** — минус ~0x100 Б на ISR-стаб (как
-  level).  Атлас-страницы стаб УЖЕ содержат (atlas_load патчит) → данные класть
-  в хвост ПОСЛЕ атласа.
-- **`kid_data.h` (3.7 КБ) влезает в kid-страницу** (min free 6161) или в
-  отдельную выделенную страницу данных Kid — предпочтительно отдельную (маппить
-  раз на кадр, не конфликтуя с kid-атласами блита).
-- **Level-таблицы** — вагон места в level-странице (~13.8 КБ).
-- **BG draw-таблицы** (~0.7 КБ) влезут в env3/fore/env4 (много free), НО см.
-  граблю W0-контекста в §3(a) — читаются ли они, когда нужная страница в W0.
-- **Выделенная страница ТОЛЬКО под данные** (не делить с атласом) = до ~16 КБ
-  (−0x100 стаб при W0-маппинге).  EMM-бюджет это позволяет (см.
-  `sprinter_emm_budget`: 215/3440 КБ free на старте).
-- **Принудительно уменьшать макс. атлас (репак мельче) — КРАЙНИЙ случай:** это
-  резко поднимет число атлас-банков (сейчас 5 env-страниц адресуются как id>>5;
-  дробление ломает эту адресацию и множит страницы).  Сначала использовать
-  СУЩЕСТВУЮЩИЙ свободный хвост и отдельные data-страницы.
-
----
-
-## 4. ПУТЬ C — переход на huge (banked code)
-
-### 4.1 Что такое huge сейчас (`bin/sprinter-cc`, `runtime/crt0_banked`)
-- `--memory huge`: `MODE_CODE_LOC=0x4100`, **`MODE_DATA_LOC=0x8000` (ФИКС.)**,
-  banked code в W3.  crt0_banked, как crt0_small, авто-детектит W2.
-  Помечено `[TODO]` — не обкатано.
-- Отличие от small: small цепляет DATA сразу за CODE (`--data-loc 0`); huge
-  ФИКСИРУЕТ DATA на 0x8000.
-
-### 4.2 ТРЕБОВАНИЕ (по пользователю): huge должен переносить DATA динамически
-Сейчас huge жёстко кладёт DATA на 0x8000.  Если РЕЗИДЕНТНЫЙ CODE вылезет за
-0x8000 (W1 = только 0x4000..0x7FFF ≈ 16 КБ; резидент > 16 КБ лезет в W2) →
-коллизия с DATA.  **Надо научить huge класть DATA динамически ЗА резидентным
-CODE (как small: `--data-loc 0` + crt0 считает старт), а не на фикс 0x8000.**
-Тогда huge = «small-раскладка резидента (W1+W2, DATA за CODE) + ДОП. код в
-банках W3».  Это первый пункт работ по huge.
-
-### 4.3 КОНФЛИКТ: графика тоже хочет W3 (ключевой риск)
-`pop_banking_architecture` прямо говорит: **графику нельзя в W3** (блиты/атласы
-используют окна; см. §4.5).  Поэтому в банки W3 можно выносить ТОЛЬКО
-НЕ-графические блоки, и такой банк НЕ должен во время своего исполнения держать
-графику в W3.  Если W3-банкованная функция ЗОВЁТ графику (которой нужен W3),
-трамплин обязан сохранить/восстановить банк вокруг вызова (проверить, что
-banking-ABI это делает — `sdcc_banking`).  Альтернатива без этого риска —
-**big + BANK_W1** (банк кода в W1, не W3), рекомендованная в
-`pop_banking_architecture` именно из-за W3-графики.  Сессия должна выбрать:
-huge(W3) с аккуратным save/restore ИЛИ big(BANK_W1).
-
-### 4.4 Какие блоки МОЖНО вынести (не работают с графикой напрямую)
-Замер graphics-ref по модулям (grep `gfx_|blit|env_b|wall_b|fore_b|setfillstyle|
-bar(|GFX_BANK|initgraph`):
-```
-pop_bg.c    : 83  — РЕЗИДЕНТ (вся отрисовка)
-roomtest.c  : 23  — РЕЗИДЕНТ (главный цикл + флип страниц)
-pop_level.c : 17  — использует gfx_w0_map (W0, не W3-блиты) — ПОГРАНИЧНЫЙ
-pop_kid.c   : 12  — kid_draw = графика; НО play_seq — чистая логика (можно split)
-pop_ctrl.c  :  0  — КАНДИДАТ В БАНК (ввод/диспетчер control)
-pop_map.c   :  0  — КАНДИДАТ В БАНК (коллизия/физика, ~3.8 КБ) — лучший по объёму
-pop_trob.c  :  0  — КАНДИДАТ В БАНК (кнопки/ворота/пики-логика)
-```
-- **Лучшие кандидаты в W3-банк(и): pop_map + pop_trob + pop_ctrl** (нет прямой
-  графики; вместе ~5.3 КБ CODE).  Освобождают резидент → он влезает в W1.
-- **Осторожно с межбанковыми вызовами:** pop_map/pop_trob ЗОВУТ pop_bg
-  (перерисовка loose/пик/кнопок/шва) и pop_kid (play_seq/kid_set_seq).  Это
-  кросс-банк вызовы через трамплин (`sdcc_banking`: стек +3 байта, виртуальный
-  24-битный адрес).  Правило `pop_banking_architecture`: «один файл = один банк
-  = прямые вызовы», main резидентен.  Проверить, что трамплин сохраняет W3
-  вокруг вызова в графический pop_bg (см. §4.3).
-- **pop_kid split** (по желанию): вынести play_seq/seqtbl-интерпретатор
-  (логика + таблицы kid_data.h) в банк, оставить kid_draw/kid_heal резидентными.
-  Даёт и −код, и −данные из резидента, но требует аккуратного разделения TU
-  (1 функция = 1 модуль, см. `libc_one_function_per_module`).
-- **pop_level: пограничный** — не блитит, но маппит уровень в W0; банковать
-  можно, если W0-логика совместима с трамплином (проверить ISR-стаб взаимодействие).
-
-### 4.5 Почему графику нельзя в W3 (контекст)
-Блиттер держит спрайт-страницу атласа в **W0** (`_gfx_w0_state`,
-`_gfx_w0_isr`).  Ускоритель/адресация видео — отдельная тема (см.
-`sprinter_accelerator`, `sprinter_graphics`).  W3 в banked-раскладке — окно
-кода-банка; смешивать с окном, которое графика перемапливает, нельзя без
-save/restore.  Детально — `pop_banking_architecture`, `graphics_constraints`.
-
----
-
-## 5. РЕКОМЕНДУЕМЫЙ ПОРЯДОК РАБОТ (для след. сессии)
-
-1. **Замер-базлайн** (CODE/DATA/BSS + per-module) — зафиксировать до.
-2. **Путь A** дешёвые пункты (флаги, дедуп кнопки, дедуп y_to_row) — быстрый −1..2 КБ.
-3. **huge §4.2**: научить huge класть DATA динамически (как small) — инфраструктурный
-   пререквизит, без него банкинг не даст гибкости.  Обкатать в MAME на текущем
-   резиденте (пока без выноса — просто huge-раскладка = small + пустой W3).
-4. **huge §4.4**: вынести pop_map (+pop_trob, +pop_ctrl) в W3-банк(и); проверить
-   кросс-банк вызовы в pop_bg (§4.3) в MAME.  ЛИБО выбрать big+BANK_W1.
-5. **Путь B** (по остатку нужды): прототип выноса `kid_data.h` в EMM-страницу
-   Kid с маппингом раз на кадр; замерить скорость (`sprite_engine_perf`).
-   Затем аудит draw-таблиц по W0-контексту (§3 a/b/c/d).
-
-## 6. Ссылки
-- `bin/sprinter-cc` (§162+ — резолв memory-mode → CODE_LOC/DATA_LOC).
-- `runtime/crt0_small.*`, `runtime/crt0_banked.*`, `runtime/bank.s`.
-- memory: `sprinter_memory_modes`, `memory_modes_implemented`,
-  `setwin2_for_w2_alloc`, `sdcc_banking`, `bank_local_data_pattern`,
-  `pop_banking_architecture`, `avoid_32bit_arith_z80`,
-  `libc_one_function_per_module`, `sprite_engine_perf`, `mdview2_size_budget`.
-- `applications/PoP/roomtest/bug_list.md` — открытые баги Фазы B (не блокируют
-  оптимизацию, но держать в уме при рефакторе pop_map/pop_bg).
-
----
-
-## 7. Лишние блиты в горячем пути (добавлено 2026-07-27)
-
-Найдено при разборе окклюзии по эталону SDLPoP: **наш «передний слой» рисовал
-спрайты, которых в оригинале там нет** — это и артефакты, и лишняя работа
-каждый кадр.  Исправлено: `fore_tile` (вызывается для КАЖДОГО тайла футпринта
-Kid, обычно 2–4 за кадр) рисовал ещё и `bottom_id` — переднюю кромку пола; в
-оригинале `draw_tile_fore` (seg008:690) добавляет только `add_foretable`-часть,
-а `bottom` идёт через `draw_tile_bottom` в backtable (ПОД персонажем).
-Итог: −2..4 блита за кадр, `_CODE` −388 Б, ушла «тень» у основания колонны.
-
-**Что проверить тем же методом (по одному вопросу к каждому месту: а есть ли
-этот спрайт в оригинале в ЭТОЙ таблице?):**
-
-1. `pop_room_draw`/`draw_tile` — вызовы на входе в комнату не критичны по
-   скорости, но по ним стоит сверить состав слоёв (backtable vs foretable).
-2. `overlay_mid_tile` — сейчас точный порт midtable-части `draw_tile2`;
-   проверить, не рисуем ли `base_id` там, где оригинал его не рисует
-   (loose: base=0, потому что кадр плиты идёт через `draw_loose` в backtable).
-3. `pop_loose_mob_tick` — перерисовка соседнего тайла (`draw_tile(mob_row,
-   mob_col+1)`) КАЖДЫЙ кадр падения: в оригинале это `set_redraw_full` на
-   один кадр; можно ограничить только тайлом, который реально пересекается
-   с куском.
-4. `pop_ceil_shake_draw` — heal 64×8 + два `draw_tile(-1,·)` на кадр тряски;
-   проверить, нужен ли второй тайл (правую грань loose в полосе потолка
-   оригинал не рисует вовсе — `draw_tile_aboveroom` без `draw_tile_anim_right`).
-5. `fore_only_tile` для полосы потолка: вызывается для всех колонок габарита,
-   а оригинал (`redraw_needed_above`) — только для колонок с флагом
-   `redraw_frames_above`; сузить до колонок, реально задетых спрайтом.
-6. `wall_pattern` внутри fore/overlay — тяжёлая (PRNG + до 4 блитов); проверить,
-   не зовём ли её там, где оригинал ограничивается `wall_fram_main`.
-
----
-
-## 8. Скорость отрисовки: замеры и запас (2026-07-27)
-
-Профилирование в MAME (маркеры в порт 0xFE + `wpiset … totalcycles`, приём из
-memory `mame_mcp_bridge`).  Кадр Sprinter = **430 080 тактов**.
-
-**Стоимость блита почти НЕ зависит от размера** — платим за проход по цепочке
-`gfx_blit → gfx_blit_part → _gfx_blit_full` (16-битная арифметика, клип,
-пересчёт src, нарезка полос >256), а не за пиксели:
-
-| путь (спрайт 32×3) | тактов |
-|---|---|
-| `gfx_blit` (общее ядро, с клипом) | 13 288 |
-| линейное спрайтовое ядро без клипа (`putsprite` при `gfx_sprite_clip(0)`) | 4 617 |
-
-Отсюда `draw_tile(0,0)` тайла шва (9 блитов) стоил **183 690 тактов = 43 %
-кадра**; сам `bar` — только 13 308.
-
-**СДЕЛАНО (шаг 1):** в libbgi добавлен `gfx_blit_noclip()`
-(`common/gfx_blit_noclip.c`, прототип в `include/gfx.h`) — блит без клипа в
-ТЕКУЩЕМ банке через линейное ядро; `pop_bg.blit_b` уходит на него, когда
-спрайт целиком на экране и не нужен `g_clip_top`.  Выигрыш ~2.9× на каждом
-фоновом блите (подтверждено в MAME).
-**ВАЖНО:** W3-скобку (`_bgi_begin/_bgi_end`) ставит САМА libbgi — вызывать её
-из модуля, собранного с `--w3`, нельзя: после `_bgi_begin` окно W3 занято
-видеобанком и код вызывающего исчезает из адресного пространства (проверено:
-белый экран).
-
-**ЗАПАС (шаг 2), когда перестанет хватать бюджета кадра:**
-
-1. **Батчинг W3-скобки** — одна `_bgi_begin/_bgi_end` на весь `draw_tile`
-   вместо скобки на блит; нужен публичный batch-API в libbgi (как у
-   спрайтового движка).  Осторожно: между begin/end стоит `DI` — длинная
-   серия задержит кадровое прерывание.
-2. **Решётка ворот одним спрайтом** — `draw_gate_back` рисует бары по одному
-   (`env 52`, до 7 блитов).  Сгенерировать в атласе «столб решётки» (повтор
-   бара на высоту тайла) и выводить одним `gfx_blit_part` с обрезкой по фазе
-   `gate_bot_y & 7`: 7 блитов → 1.
-3. **Не перерисовывать статичные части шва** — грань ворот (env 47, 26×62),
-   пол (41) и кромка (43) при анимации решётки не меняются; если стирать
-   только полосу баров, уйдут ещё 3 блита из 9.
-4. См. также §7 (лишние блиты, которых нет в оригинале).

applications/PoP/poc/res/bg/pop_bg_atlas.h

@@ -2,33 +2,46 @@
  * Сгенерировано toolchain/pop_pack_bg.py — НЕ править вручную.
  *
  * Прямая адресация (ноль remap-таблиц в W2):
- *   ENV фон id N  -> atlas env_bg[N>>5], idx N&31
+ *   ENV фон id N  -> atlas env_bg[N>>4], idx N&15
  *   WALL   id N  -> atlas wall,          idx N
  *   FORE   id N  -> atlas fore,          idx N
+ *
+ * ДВА ТАЙЛСЕТА (порт tbl_envir_ki[tbl_level_type], seg000:1108):
+ *   0 = подземелье (pop_*), 1 = дворец (pal_*).  Набор id и раскладка
+ *   у них ОДНИ И ТЕ ЖЕ — меняются только файлы и 32 записи палитры
+ *   (env 0x50..0x5F, wall 0x60..0x6F), см. *tile.pal.
  */
 #ifndef POP_BG_ATLAS_H
 #define POP_BG_ATLAS_H
 
-#define POP_ENV_SHIFT   5
-#define POP_ENV_MASK    31
-#define POP_ENV_PAGES   5
+#define POP_ENV_SHIFT   4
+#define POP_ENV_MASK    15
+#define POP_ENV_PAGES   10
+#define POP_TILESETS    2
 
-/* Палитра: env-слоты, wall-слоты (сприйт-пиксель i -> база+i). */
+/* Палитра: env-слоты, wall-слоты (спрайт-пиксель i -> база+i). */
 #define POP_PAL_ENV     0x50
 #define POP_PAL_WALL    0x60
 
-/* Имена файлов атласов (грузятся atlas_load). */
-static const char *const pop_env_atl[POP_ENV_PAGES] = {
-    "pop_env0.atl",
-    "pop_env1.atl",
-    "pop_env2.atl",
-    "pop_env3.atl",
-    "pop_env4.atl",
+/* Имена файлов атласов по тайлсету (грузятся atlas_load).  Таблицы
+ * видны только тому, кто попросил POP_BG_ATLAS_NAMES: иначе копия
+ * строк уедет в каждый включивший заголовок модуль. */
+#ifdef POP_BG_ATLAS_NAMES
+static const char *const pop_env_atl[POP_TILESETS][POP_ENV_PAGES] = {
+    { "pop_env0.atl", "pop_env1.atl", "pop_env2.atl", "pop_env3.atl", "pop_env4.atl", "pop_env5.atl", "pop_env6.atl", "pop_env7.atl", "pop_env8.atl", "pop_env9.atl" },
+    { "pal_env0.atl", "pal_env1.atl", "pal_env2.atl", "pal_env3.atl", "pal_env4.atl", "pal_env5.atl", "pal_env6.atl", "pal_env7.atl", "pal_env8.atl", "pal_env9.atl" },
 };
-#define POP_WALL_ATL    "pop_wall.atl"
-#define POP_FORE_ATL    "pop_fore.atl"
-#define POP_POT_ATL     "pop_pot.atl"   /* chtab_1: зелья */
+static const char *const pop_wall_atl[POP_TILESETS] = { "pop_wall.atl", "pal_wall.atl" };
+static const char *const pop_fore_atl[POP_TILESETS] = { "pop_fore.atl", "pal_fore.atl" };
+static const char *const pop_tile_pal[POP_TILESETS] = { "pop_tile.pal", "pal_tile.pal" };
+#endif  /* POP_BG_ATLAS_NAMES */
+#define POP_POT_ATL     "pop_pot.atl"   /* chtab_1: зелья, от набора не зависит */
 #define POP_PAL_POT     0x40
+/* Пузырёк зелья: красный набор = id 16..22 (кадры оригинала),
+   зелёный (перо/переворот) и синий (вред/открыть) = те же кадры
+   под id 30..36 и 40..46 (draw_tile_anim, seg008:652). */
+#define POP_POT_BUBB_GREEN 30
+#define POP_POT_BUBB_BLUE  40
 #define POP_BG_PAL      "pop_bg.pal"
 
 #endif

applications/PoP/poc/res/kid/kid_atlas.h

@@ -37,5 +37,5 @@ static const char *const kid_atl[KID_PAGES] = {
 };
 #define KID_PAL_FILE "kid.pal"
 #define KID_SWORD_ATL "sword.atl"   /* chtab_0: меч в руке */
-#define KID_SWORD_ID0 20  /* индекс в атласе = sword_tbl.id - ID0 */
+#define KID_SWORD_ID0 0  /* индекс в атласе = sword_tbl.id - ID0 */
 #endif